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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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)
[View Less]
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
Just to make sure we're talking about the same thing, the patch I
posted has been applied, but the patch I didn't post hasn't.
5c6616146a1f1cdb18a8ed6f973a63ee73df9278 is the current version of
Sign.pike on the 8.0 branch, isn't it? The fix on the 8.1 branch is in
b238c808a70a4c671a2a7ecbdd083e41f469f41b.
--- a/lib/modules/__builtin.pmod/Nettle.pmod/Sign.pike
+++ b/lib/modules/__builtin.pmod/Nettle.pmod/Sign.pike
@@ -99,9 +99,9 @@ string(7bit) jose_sign(string(8bit) mess
//! @returns
//! …
[View More]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
//!
[View Less]
1
0
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:…
[View More] @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)
{
[View Less]
On Fri, Jul 22, 2016 at 1:05 AM, Martin Bähr <mbaehr(a)realss.com> wrote:
> Excerpts from Chris Angelico's message of 2016-07-22 00:46:18 +1000:
>> Hah. Actually, I've been pushing more people onto Pike who aren't
>> developers, and unfortunately there are a number of trickinesses to
>> working on Windows. I've largely come to the conclusion that "Windows
>> sucks" is a valid excuse for nearly any bug that I can't repro on
>> Linux, but for all those non-…
[View More]developers who want stuff to "just work",
>> getting them to install Debian might be a lot of hassle...
>
> would the linux environment in windows 10 help with that?
> pike should work on it, though gtk support won't (unless you get an X
> server) so maybe a dealbreaker for you :-(
>
Lacking GTK would be a killer; so would any additional complexity that
lands on the end user, as they're already tending to balk at "install
this .msi, then get this .zip and extract it, then double-click
gypsum.pike". Also, doesn't help with all the people on Win 7/8. So
it's probably going to stay with the native Windows builds for now.
That said, though, I don't think the glob changes would break anything I do.
ChrisA
[View Less]
We had that impromptu Pike dev meetup on the 7th, and I took notes on
some of the things we discussed. Dumping them here before we all
forget about it.
In attendence: Zino, Nilsson, Grubba, Marcus, Tobi, Arne
Status report
-------------
Per tradition grubba made a short status report about what has changed
since the last meeting:
- Some non-enabled new SSL server stuff is not yet compatible with Chrome
- We enforce C89 now
- GMP is required and always loaded in 8.1
- Threads are allowed …
[View More]while compiling in 8.0
- pragma #dissasemble/#dissassemble (new in 8.1)
8.2 TODO
--------
We went though what everyone wants in before we split branch 8.2. In
no particular order:
- Compiles on Windows
For now and until he protests this is zino's problem.
- Something about Mpz. Don't remember the details.
- Something about lfuns proxy-requested by Per. Don't remember the details.
- Add MPI support
zinos project. Not really a blocker.
- Stop using declarations on the top of the function in C?
Debatable
- Get the fastcall, fast frames improvements in
- glob("C:\*.gif")
alt 1:
Add Future.glob()
depricate glob()
import Future
alt 2:
Consider this a Windows problem and call up the 3 Windows users by phone.
alt 3: //Never do this
Add heuristics.
alt 4:
add 8.2::glob
dspecial depricate glob
constant glob=8.2::glob
alt 5:
Add String.glob() or similar
depricate glob()
Maybe reintroduce glob() in a later release
We where leaning towards 5.
- Stop dumping modules
- Move/Remove the Markdown non-module
Random notes
------------
- Make a list of all modules and make a note about why each of them
are included. Remove the ones with no motivation for them.
Nilsson is responsible for the list-making.
- Check if anything runs on eureka, otherwise, kill it
- Check if we have anything on pelix, otherwise kill it
- TravisCI / Coverage
- Opera Critic (https://github.com/jensl/critic)
Someone said they would have a look att setting that up for Pike
last meeting. No one could remember who.
- Xenofarm
Dates are broken somewhere on the buildmachine which prevents some
of the clients from building.
- _Roxen module, move the useful stuff somewhere and kill it
Make one canonical HTTP module.
- Rewrite dirnodes to make them have fewer confusing edge-cases
nilsson, grubba
- dot-operator is confusing as hell
- Use merges to make it easier to track that bugfixes has been merged
in which branch
Arne will check.
- Remove configurability of Calendar
Nisson
- Make Calendar discoverable for users
- Take a look at Image.Orient
- Take a look at Image.Graph
- Documentation for stuff that inherits ::this_program
- Ticket support?
(I don't remember what this was about at all)
--
Peter Bortas
[View Less]
The documentation of the new f_hash() claims that its return value is
architecture independent. SipHash reads its input as a series of
little-endian 64 integers, which means that the hash value depends on
endianess for wide strings.
I have at some point written byte order independent versions of siphash
for both 16 and 32 bit strings. Those can be found in commit
21f218e51d55d8c07aff9db0cf45e4ac83050a5e as part of the bloom filter
branch. If nobody objects, I will merge that commit into pike 8.…
[View More]1 and
integrate it with f_hash().
Something unrelated: I am going to be in linköping from tomorrow until
saturday next week. Anyone up for a mini pike meetup?
Arne
[View Less]