Pike-devel November 2016

pike-devel@lists.lysator.liu.se

9 participants
52 discussions

Re: Build of 7.8.866 getting stuck in a loop
by Chris Angelico 23 Nov '16

23 Nov '16

On Wed, Nov 23, 2016 at 9:15 AM, Marcus Agehall (nu med K-märkt fastighet och ny elcentral) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Since we are pretty far into 8.0 now, I'd say it's time to move > forward. > > Most smaller projects would probably not even notice the switch to 8.0 > and the bigger ones, such as Roxen, have already done the switch. > > Others may disagree, but I would say it's perfectly fine to drop 7.8 > and only ship 8.0. I try to still support 7.8, partly because the 8.0 builds for Windows are still on old libraries (incl GTK). And the build process defeated me :( ChrisA

1 0

WebSocket, skips parse_variables at times, why?
by Stephen R. van den Berg 22 Nov '16

22 Nov '16

I'm currently implementing the Engine.IO (and possibly Socket.IO) protocol in Pike (bidirectional realtime communication with JavaScript clients). While doing so I noticed (to my dismay) that in WebSocket, I find the following code snippet: protected int parse_variables() { if (has_index(request_headers, "sec-websocket-key")) return 0; return ::parse_variables(); } I.e. parse_variables() is skipped on real websocket connections. What would be the reason why this is being skipped? I need to parse the variables on the URL of the soon-to-be-upgraded websocket connection; so it would be more convenient if it was handled automatically. -- Stephen.

4 6

Build of 7.8.866 getting stuck in a loop
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 22 Nov '16

22 Nov '16

I think you used the wrong comment character, though... > ...peep.in:39:Unknown preprocessor directive NUMBER. > Cpp() failed

1 0

Build of 7.8.866 getting stuck in a loop
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 22 Nov '16

22 Nov '16

PEEP at 468: nop => PEEP at 468: nop => PEEP at 470: mark global(2) => mark & global(2) PEEP at 471: assign local and pop(1) local(1) => assign local(1) PEEP at 471: push int(0) => push 0 PEEP at 471: push 0 index => int index(0) PEEP at 472: mark local(1) => mark & local(1) PEEP at 473: mark call builtin(23) => mark, call builtin(23) PEEP at 474: push 0 assign local and pop(5) => clear local(5) PEEP at 474: clear local(5) & local(5) => & local(5) clear local(5) PEEP at 475: local(5) clear string subtype index => local index(5) PEEP at 475: global(3) local index(5) => global[local](3,5) PEEP at 476: mark global(3) => mark & global(3) PEEP at 476: local(5) clear string subtype index => local index(5) PEEP at 477: mark local(5) => mark & local(5) PEEP at 477: local(5) clear string subtype index => local index(5) PEEP at 477: global(3) local index(5) => global[local](3,5) PEEP at 474: nop => PEEP at 474: nop => PEEP at 479: call builtin 1(24) pop => call builtin1 & pop(24) PEEP at 480: push 0 assign local and pop(5) => clear local(5) PEEP at 480: clear local(5) & local(5) => & local(5) clear local(5) PEEP at 481: mark local(5) => mark & local(5) PEEP at 481: local(3) local(5) => 2 locals(3,5) PEEP at 481: 2 locals(3,5) clear string subtype index => local[local](5,3) PEEP at 482: push int(0) => push 0 PEEP at 482: push 0 index => int index(0) PEEP at 483: local(4) local(5) => 2 locals(4,5) PEEP at 483: push int(1) => push 1 PEEP at 483: push 1 index => int index(1) PEEP at 480: nop => PEEP at 480: nop => PEEP at 487: push 0 assign local and pop(5) => clear local(5) PEEP at 487: clear local(5) & local(5) => & local(5) clear local(5) PEEP at 488: mark string(147) => mark & string(147) PEEP at 489: local(4) local(5) => 2 locals(4,5) PEEP at 489: 2 locals(4,5) clear string subtype index => local[local](5,4) PEEP at 487: nop => PEEP at 487: nop => PEEP at 490: push 0 assign local and pop(5) => clear local(5) PEEP at 490: clear local(5) & local(5) => & local(5) clear local(5) PEEP at 491: local(5) clear string subtype index => local index(5) PEEP at 491: global(5) local index(5) => global[local](5,5) PEEP at 492: assign local and pop(6) local(6) => assign local(6) PEEP at 492: push int(-2147483648) => push -int(-2147483648) PEEP at 492: push -int(-2147483648) => push int(-2147483648) PEEP at 492: push int(-2147483648) => push -int(-2147483648) PEEP at 492: push -int(-2147483648) => push int(-2147483648) ... ad infinitum. So an integer overflow, but why?

1 0

Build of 7.8.866 getting stuck in a loop
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 22 Nov '16

22 Nov '16

>Here are two: >(gdb) bt >#0 0x000000000055d953 in advance () at ./src/peep.c:910 >#1 asm_opt () at ./src/peep.c:1081 >#2 assemble (store_linenumbers=store_linenumbers@entry=1) at ./src/peep.c:441 [...] >(gdb) cont >Continuing. >^C >Program received signal SIGINT, Interrupt. >0x000000000048a738 in low_make_buf_space (space=space@entry=0, buf=buf@entry=0x98f820 <instrbuf>) at ./src/dynamic_buffer.c:17 >17 ./src/dynamic_buffer.c: Filen eller katalogen finns inte. >(gdb) bt >#0 0x000000000048a738 in low_make_buf_space (space=space@entry=0, buf=buf@entry=0x98f820 <instrbuf>) at ./src/dynamic_buffer.c:17 >#1 0x00000000005571b4 in instr (offset=0) at ./src/peep.c:878 >#2 opcode (offset=0) at ./src/peep.c:884 >#3 low_asm_opt () at ./src/peep_engine.c:4560 >#4 0x000000000055d969 in asm_opt () at ./src/peep.c:1098 >#5 assemble (store_linenumbers=store_linenumbers@entry=1) at ./src/peep.c:441 [...] Looks like it's probably an infinite loop in the peep-hole optimizer. Recompile the pike binary configured --with-debug, and run the script by hand with -a3. Hopefully the looping peep-hole rules will be obvious then. /grubba

1 0

Build of 7.8.866 getting stuck in a loop
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 22 Nov '16

22 Nov '16

Nobody has any idea why the 7.8 build hangs but not the 8.0 build? Is it time to abandon pike7.8 already? Actually I'm not sure if there's any good reason to keep multiple versions in parallel in the same manner as Python; it was just packaged that way when I took over.

3 2

Added permessage-deflate support to WebSocket
by Stephen R. van den Berg 22 Nov '16

22 Nov '16

Added it to both 8.0 and 8.1. It's in use in my Socket.IO implementation, and so far it passes all tests. Since testing it involves using a webbrowser as counterpart, my tests are sadly not comprehensive. Arne, could you check the code and see if it meets your criteria on the proposed visible interfaces? There is a little bit of trickery involved in the rsv bits. In order to know if to decompress, we need to know the RSV1 bit on the *first* frame part of the larger frameset. -- Stephen.

4 11

nettle in fedora/centos does not include the secp192 and 224 curves
by Martin Bähr 22 Nov '16

22 Nov '16

hi, i just discovered that nettle in fedora/centos does not include the secp192 and 224 curves. this is not discovered during build, but instead just leads to a runtime error. (the installation succeeds despite the error) to make building pike work properly, the absence of these needs to be tested, so the code referencing them can be skipped. i verified that, removing the references to those curves makes pike run without error, though i am not sure if this should be a compile option or if automatic detection is better. greetings, martin.

3 2

Performance/memory usage difference?
by Stephen R. van den Berg 22 Nov '16

22 Nov '16

Given two solutions: 1.==================================================== class A { final int b; final C e; class C { final int D() { return b; } }; void create() { e = C(); }; }; or 2.: ================================================ class C { final array b; final array D() { return b; }; void create(array _b) { b = _b; }; }; class A { final array b; final C e; void create() { e = C(b); }; }; ==================================================== Assuming that there are (a lot) more other members and methods in both classes (which are accessed within the class, not cross-class), and further assuming that the A class is being instantiated a *lot*: What would the runtime impact of these two approaches considering CPU time and memory used? I would guess that solution 1 would be slightly more efficient, both memory and CPU-wise. Or am I overlooking something here where due to the nested stack frames of solution 1, the actual CPU or memory usage is higher than expected? -- Stephen.

4 3

Optimization
by Peter Bortas ＠ Pike developers forum 22 Nov '16

22 Nov '16

Change it to has_prefix?

1 0

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 November 2016