Pike-devel May 2016

pike-devel@lists.lysator.liu.se

8 participants
25 discussions

Optimised map
by Martin Karlgren 09 Jan '17

09 Jan '17

Hi, Having realised the benefits of functional programming, I’ve been quite annoyed by the rumour of how expensive function calls are in Pike. I decided to look into f_map and could see how much seemingly unnecessary work it does when it calls apply_svalue once for each entry in the array – it should be possible to reuse the pike_frame if it’s about to be thrown away after the function call (if it has other refs on the other hand, it can’t be reused – it’s probably used as a scope in some other frame). I’ve pushed my optimised variant in marty/optimised_map – it seems to work quite well and provides a major speedup. In fact, it’s a bit faster than the corresponding foreach variant. I haven’t verified correctness in various corner cases, and some input on whether it’s correct to do the things init_frame_reuse_context does only once before multiple function calls would be nice too. The *_reuse_context stuff in interpret.c should be applicable wherever the same svalue is applied repeatedly with the same number of arguments (I haven’t looked for it outside of f_map really). What do you all think? Good idea or did I overlook something? Without optimisation: map: 1.660797 array index: 1.335115 array append: 1.17917 With optimisation: map: 0.877659 array index: 1.351158 array append: 1.189812 Test program: int main() { array base = allocate(10000000, 1); float gmap = gauge { array res = map (base, lambda(int i) { return i + 2; }); }; float garrayindex = gauge { array res = allocate(sizeof(base)); foreach (base; int idx; int i) { res[i] = i + 2; } }; float garrayappend = gauge { array res = ({}); foreach (base, int i) { res += ({ i + 2 }); } }; werror ("map: %O\n", gmap); werror ("array index: %O\n", garrayindex); werror ("array append: %O\n", garrayappend); } /Marty

4 12

Promises in Pike vs other languages
by Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum 09 Nov '16

09 Nov '16

I have spent some time looking at the new stuff in Concurrent.pmod that Grubba has added to 8.1. Mostly it is code relating to the concept of Promises and Futures which are very popular amongst JavaScript people these days. I have noted that there seems to be some rather striking differences between how JavaScript treats promises and how Pike does it. I'm not sure this is a good thing(tm) and therefore I'd like to bring this up before 8.1 stabilizes. In Pike, we have two methods that register callback functions, Future.on_success() and Future.on_failure() as opposed to JS where only one method, then(), is used to register both callbacks. I don't mind having two different methods, but for easier transition between the two languages (i.e. for people writing both client-side and server-side code) having the same API would probably help. A bigger problem imho is the difference in how promises are actually resolved. In JavaScript, the return value of then() is always a *new* promise which then allows for chaining. In Pike, we return the same promise object. This means that code like my_promise->on_success(foo)->on_success(bar) in Pike would result only in a call to bar() once my_promise is resolved whereas in JavaScript, foo() would be called and it's return value would be the input to bar in a new promise. The whole creation of promises is also somewhat awkward in Pike. In JS, you simply pass a callback that will do all the work and that will recieve a success callback and a failure callback as arguments and off you go. In Pike, I'm not sure what the best way to do it is. I really like the idea of having promises in Pike, but would it not be much better if we tried to implement an API more similar to what the JS folks are used to? At least I think so... Here are three links to good resources I've found regarding promises in JS. I'm sure there are a ton of others as well. https://promisesaplus.com/ http://www.mattgreer.org/articles/promises-in-wicked-detail/ http://bluebirdjs.com/docs/api-reference.html

4 10

Re: Promises in Pike vs other languages
by Per Hedbor () ＠ Pike (-) developers forum 07 Oct '16

07 Oct '16

Something I would recommend, from having written heaps of asynchronous object based systems, with or without remote computers involved, is to treat all references to the promise object going away as an error, and avoid un-needed circular references. This makes it easy to detect when you accidentally forget the object. Also, having the object be callable is rather convenient, it can then be put as a normal callback in all the various function based API:s we already have. >From the MiniRPC module, used extensively in the mini codebase: // This is an object representing a function to be called when // whatever task is being requested has been completed. // // In the RPC case the 'call_id' and 'par' are used to send the return // value, and function_name is for debug purposes. // class ReturnFromCall(protected int call_id, protected object par, protected string function_name) { protected void destroy() { // this should check the done function callback instead.. if( call_id ) { werror("Return was never called for "+function_name+"\n"); if( par ) this.error("Return was never called\n"); } } protected string _sprintf( int flag, mapping opts ) { // It's rather nice to have a _sprintf for backtraces. But // without a function_name it's harder :) return sprintf("ReturnCall(from %O)", function_name ); } protected void error(string err) { // .. this is sort of special in the RPC code .. call_id = 0; destruct(this); } void `()(mixed ... x ) { // Wanted addition #2: Callable promises? call_id = 0; destruct(this); } mixed try( function x ) //! Call @[x], if the call fails report an error message to //! the remote side. // // syntax of the day: // foo( foo->try() { code to run..; return res;}); // // It might be useful to have a functon that also returns the // value calculated { if( mixed err = catch{return x();}) { // code goes here to log etc.. this.error(err); } } } Also, I personally belong to the "future/promises don't really add much" camp, but feel free to add the API. :) (In my opinion it's just another way to complicate asynchronous programming)

4 7

Re: Setting socket options: so many, uhh, options!
by Chris Angelico 15 Sep '16

15 Sep '16

On Tue, Mar 10, 2015 at 10:05 PM, Mirar @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Wait, I said REUSEPORT? What's the difference to REUSEADDR? Mysteries > of TCP sockets... Here's a decent explanation, I think: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and… ChrisA

3 6

Documentation breakage
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 29 Jul '16

29 Jul '16

When preparing a new Debian package of 8.0.240, I noticed that some documentation disappeared, apparently due to the following. The error in Nettle.Sign is already corrected but not the others, AFAICT, and I'm guessing that @exp should be @expr. Patch below, which I home someone can apply right away. ERROR: <Invalid error container: Tools.AutoDoc.AutoDocError(SourcePosition(File: /build/pike8.0-8.0.240/src/modules/Gmp/mpz_glue.c, lines: 668..668), "DocParser", "@exp cannot be used like this: @exp{ ... @}")> ERROR: <Invalid error container: Tools.AutoDoc.AutoDocError(SourcePosition(File: /build/pike8.0-8.0.240/lib/modules/__builtin.pmod/Nettle.pmod/Sign.pike, lines: 102..102), "DocParser", "@item is not allowed inside @array (allowed children are: @elem)")> ERROR: <Invalid error container: Tools.AutoDoc.AutoDocError(SourcePosition(File: /build/pike8.0-8.0.240/lib/modules/Crypto.pmod/ECC.pmod, lines: 286..286), "DocParser", "@item is not allowed inside @array (allowed children are: @elem)")> ERROR: <Invalid error container: Tools.AutoDoc.AutoDocError(SourcePosition(File: /build/pike8.0-8.0.240/lib/modules/Crypto.pmod/RSA.pmod, lines: 368..368), "DocParser", "@item is not allowed inside @array (allowed children are: @elem)")> --- a/lib/modules/Crypto.pmod/ECC.pmod +++ b/lib/modules/Crypto.pmod/ECC.pmod @@ -283,9 +283,9 @@ class Curve { //! @returns //! Returns @expr{0@} (zero) on failure, and an array //! @array - //! @item mapping(string(7bit):string(7bit)|int) 0 + //! @elem mapping(string(7bit):string(7bit)|int) 0 //! The JOSE header. - //! @item string(8bit) 1 + //! @elem string(8bit) 1 //! The signed message. //! @endarray //! --- a/lib/modules/Crypto.pmod/RSA.pmod +++ b/lib/modules/Crypto.pmod/RSA.pmod @@ -365,9 +365,9 @@ class State { //! @returns //! Returns @expr{0@} (zero) on failure, and an array //! @array - //! @item mapping(string(7bit):string(7bit)|int) 0 + //! @elem mapping(string(7bit):string(7bit)|int) 0 //! The JOSE header. - //! @item string(8bit) 1 + //! @elem string(8bit) 1 //! The signed message. //! @endarray //! --- a/src/modules/Gmp/mpz_glue.c +++ b/src/modules/Gmp/mpz_glue.c @@ -665,7 +665,7 @@ static void mpzmod_create(INT32 args) /*! @decl int cast_to_int() *! Casts the object to an integer. *! @deprecated - *! Use @exp{(int)@} instead. + *! Use @expr{(int)@} instead. */ static void mpzmod_get_int(INT32 args) {

2 2

Revamping the Pike site
by Pontus Östlund 10 Jun '16

10 Jun '16

Hi guys! As awesome a programming language Pike is, the official Pike site does not really reflect that - to say the least ;) The site today does not exacly shout that the language it self is constantly developed and rapidly progressing. I thought I might do something about that. And so I have. Most things are starting to come together, so in a few weeks I feel we can go live with the new site. But before that happens I would love to have your thoughts and feedback on it. At the moment I have the site on my laptop which is not accessible from outsdie, but I’ve put toghether a page with some screenshots and some explainations which you can checkout. I have also revamped the module refdoc to better align with the new site. And since the module refdoc is 100% static HTML pages I’ve put a sample of it online on Github. Page with screenshots and som explainations of the new site: http://poppa.github.io/pike-dumps/ <http://poppa.github.io/pike-dumps/> Module refdoc: http://poppa.github.io/pikedoc/ <http://poppa.github.io/pikedoc/> So feel free to comment and give feedback. Oh, and since there are some really, really, really, really, really, really old content on the site we need to clean up some old stuff that’s no longer viable. I’ve already done some of that on my local copy, but I’ll put together a list of stuff we need to look into. But lets take that later... Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

8 34

Error building 8.1: test-pike not found
by Pontus Östlund 27 May '16

27 May '16

Hi guys! When I try to build Pike 8.1 from Git I get an error saying pike-test is not found. What’s that about? Making all in build/linux-4.4.0-22-generic-x86_64 ./precompile.sh --cache precompile.pike --api=3 >"/home/poppa/src/pike-git/devel/src/builtin.c" "/home/poppa/src/pike-git/devel/src/builtin.cmod" || { rm "/home/poppa/src/pike-git/devel/src/builtin.c"; exit 1; } precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/master.pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=Q) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/pike: not found precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/master.pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQ) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/tpike: not found precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/test-pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQQ) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/test-pike: not found precompile: pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQQQQQ) /home/poppa/src/pike-git/devel/src/builtin.cmod:2091: Syntax error: string(8bit) is not a valid type. precompile: /usr/local/bin/pike80 /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQQQQQ) /home/poppa/src/pike-git/devel/src/builtin.cmod:2091: Syntax error: string(8bit) is not a valid type. precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/master.pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=Q) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/pike: not found precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/master.pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQ) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/tpike: not found precompile: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/test-pike /home/poppa/src/pike-git/devel/bin/precompile.pike --api=3 /home/poppa/src/pike-git/devel/src/builtin.cmod (method=QQQ) ./precompile.sh: 135: ./precompile.sh: /home/poppa/src/pike-git/devel/build/linux-4.4.0-22-generic-x86_64/test-pike: not found Failed to find a Pike executable that could run /home/poppa/src/pike-git/devel/bin/precompile.pike. Makefile:512: receptet för målet ”/home/poppa/src/pike-git/devel/src/builtin.c” misslyckades make[3]: *** [/home/poppa/src/pike-git/devel/src/builtin.c] Fel 1 Makefile:1156: receptet för målet ”module_objects” misslyckades make[2]: *** [module_objects] Fel 2 Makefile:149: receptet för målet ”_make_in_builddir” misslyckades make[1]: *** [_make_in_builddir] Fel 2 Makefile:66: receptet för målet ”compile” misslyckades make: *** [compile] Fel 2 Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

3 3

Re: Error building 8.1: test-pike not found
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 27 May '16

27 May '16

As a workaround, you can back your wt to 9cb2319, compile pike, and then go back to HEAD to precompile with the pike you just built.

2 1

Re: Promises in Pike vs other languages
by Chris Angelico 25 May '16

25 May '16

On Wed, May 25, 2016 at 10:30 PM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>I think the biggest benefit is that your async programming becomes/or >>looks more sequential/synchroneous which tend to be easier to follow, >>or in other words less spaghetti-ish. > > > And I definitely beg to differ that. > > Take this future-less code from a chat server: > > | void rpc_call_muc_join(ReturnCall x, mapping args ) > | { > | [string muc,string who] = get_args(args, > | "muc",stringp, > | "inviter",ornull(stringp)); > | > | Channel channel = get_destination( muc ); > | int when = now(); > | > | channel->when_available() > | { > | if( !channel->exists() ) > | client_error(x, "No such channel" ); > | > | channel->joined( user->id, when ) { > | me->join_channel( channel ) { > | channel->add_message( msg( "joined", > | "user_ids",({format_destination(me)}), > | "by",format_destination(me), > | "when", now)) { > | x(true); // return true. > | }; > | }; > | }; > | }; > | } > > > Todays quiz: Is it really harder to read, and how many asynchronous levels > do you think there is in it? :) If you want your asynchronous code to look truly clean, the way synchronous code does, there needs to be a way to have a function pause its execution and let something else carry on. Python can do this, either with generator functions or with the new async/await keywords. Adapting the style to Pike syntax, it'd be something like this: async string talk_to_socket(string msg) { array(string) ips = await resolv("destination.ip.address"); foreach (ips, string ip) { Stdio.File sock = Stdio.File(); sock->open_socket(); if (await sock->connect(ip, 5678)) break; } await sock->write("helo\n"); await sock->write(msg + "\n"); string data = await sock->read(1024, 1); sock->close(); return data; } Whenever you say "await", you trigger a sub-action, and the current call gets suspended. It functions pretty much like cooperative threading; effectively, any 'await' can result in a context switch. Without language support like that, everything's going to be a pile of (probably lambda) functions, one way or another. ChrisA

1 0

Re: Promises in Pike vs other languages
by Per Hedbor () ＠ Pike (-) developers forum 25 May '16

25 May '16

>Your example did not contain any definitions of functions in >functions. That's sort of debatable, since x(){} is just a shorthand syntax for x(lambda(){});, which does define a local function. :) I do see the conflict, however.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel May 2016