Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

need access to upload pike binary
by H William Wellliver III 17 Mar '17

17 Mar '17

Hi, I've finally had some time to get a proper build environment for MacOS X and have a Pike binary built that contains no external dependencies. However, I don't seem to have access any more to upload the file as I used to (previously I had ssh access to what was called at one time pelix). Can someone contact me privately to let me know how best to get the file uploaded? Thanks in advance! Bill

1 0

Re: Proposal: Create Stdio.Port from systemd-provided socket
by Chris Angelico 12 Feb '17

12 Feb '17

On Sun, Feb 12, 2017 at 6:40 PM, Mirar @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I'm guessing that the original was "stdin", then someone had the same > problem you had and expanded the API without breaking backwards. Entirely possible. I've deleted the branch for this feature, since it's not needed (although at some point, I might make a pure-Pike helper function that does the proper verification; my app currently short-cuts things a bit, since it never needs more than one socket), and made a small docs tweak to link "stdin" mode with listen_fd. Thanks for the info, Mirar and Arne! This is where this mailing list is awesome :) ChrisA

1 0

Pike 8.0.404 RC
by Peter Bortas 07 Feb '17

07 Feb '17

This will go out as a release the next couple of days as a release unless someone finds something broken. Pike 8.0.404 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.404/Pike-v8.0.404.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.404/Pike-v8.0.404-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.404/Pike-v8.0.404-win32-oldli… Changes since Pike 8.0.388 (release 7) ---------------------------------------------------------------------- New Features ------------ o Mysql.SqlTable sizeof() on an SqlTable now returns the number of rows in the table. o Web - Updated {en,de}code_jwt() to support HMAC signatures. - Added decode_jwk{,_set}(), which decode RFC 7515-style JOSE keys. Runtime ------- o Stdio.Buffer & String.Buffer Allocated constant program identifiers for both of the above. Bug fixes --------- o Protocols.DNS The size and precision fields of T_LOC records are now properly decoded. o System.TM When a System.TM object was created without any arguments some operations would crash on Windows, and possibly other platforms. Building -------- o Configure Fixed issues with the LDSHARED test on some BSD-derivatives. o Stdio Fixed compilation issue on platforms without readdir_r(). -- Peter Bortas

1 0

Beta 8.0.398
by Peter Bortas 02 Feb '17

02 Feb '17

There will be another build before next Tuesday, so this will never leave beta. But it had to be built to test a fix for a crash in System.TM on Windows yesterday, so I might as well share it: Pike 8.0.398 beta: https://pike.lysator.liu.se/pub/pike/beta/8.0.398/Pike-v8.0.398.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.398/Pike-v8.0.398-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.398/Pike-v8.0.398-win32-oldli… -- Peter Bortas

1 0

Protocols.SMTP.ClientHelper()->rfc2822date_time()
by Chris Angelico 25 Jan '17

25 Jan '17

What exactly is this function, and how does it differ from Calendar.Time.format_smtp()? The docs for the latter state that it's "as seen in Date: headers in mails", which seems to be the same purpose. They appear to give the same output. Should the ClientHelper function have a docs reference to format_smtp? Is there a reason to use ClientHelper instead? ChrisA

2 1

src/configure has modification time in the future.
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 15 Jan '17

15 Jan '17

The test `cd "$srcdir" && ls -1t configure configure~ | head -n 1` = "configure" in src/configure.in seems unreliable. If the current kernel's stat() doesn't support nanoseconds or ls doesn't compare them, the test fails if the modification times of both files are in the same second, which can happen if src/run_autoconfig --no-recurse is triggered. Perhaps if you use a file name that lexically precedes "configure", such as "config-time-test", instead of "configure~".

1 0

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

I was thinking of working on Protocols.DNS
by Jeff Hungerford 09 Jan '17

09 Jan '17

I'd like to do some work on Protocols.DNS ; there are a lot of record types which are currently unhandled. I'd like to start adding support (encoding / decoding, tests, and docs) for them. I'd also like to fix a bug I introduced back in 2004. I almost understood how RFC 1876 location records encode precision, but didn't get it quite right. Would it be possible for me to get commit access to Git, or should I just package everything up as patches, and send them to someone who already has access? I have read, and accept the policies and guidelines for Git access. -Jeff hungerf3(a)house.ofdoom.com

2 1

Simplified operators
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 04 Jan '17

04 Jan '17

So I've been bugfixing and merging the code from the simplified operators branch. I just fixed so that UNDEFINED is always ignored when adding arrays, mappins and multisets, and not just as first argument. Previously: Pike v8.1 release 6 running Hilfe v3.5 (Incremental Pike Frontend) > `+( UNDEFINED, ({1}), ({2}) ); (1) Result: ({ /* 2 elements */ 1, 2 }) > `+( ({1}), UNDEFINED, ({2}) ); Bad argument 2 to `+(). Expected array. Unknown program: `+(({1}),UNDEFINED,({2})) HilfeInput:1: HilfeInput()->___HilfeWrapper() The remaining issue I have is what to do when an addition LFUN returns UNDEFINED. I interpret Pers commit message as he was leaning towards having an object return UNDEFINED mean to not involve the object, though there was no code to back that up. I lean towards having returning UNDEFINED be an error, since the object can just as well return the value it was given. In any event, the current behaviour is wrong: Pike v8.1 release 6 running Hilfe v3.5 (Incremental Pike Frontend) > class A { mixed ``+(mixed x) { return UNDEFINED; } } > `+( ({1}), A(), ({2}) ); (1) Result: ({ /* 1 element */ 2 })

1 1

Christmas beta 2
by Peter Bortas 30 Dec '16

30 Dec '16

On request since there was some regression since the last release. Pike 8.0.388 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.388/Pike-v8.0.388-win32-oldli… Documented changes since Christmas beta 1: ------------------------------------------------------------------- New features ------------ o Thread _sprintf() improvements: Thread.Mutex now prints the ID of the thread holding the lock, and thread IDs are shown as hexadecimal numbers.

3 3

Jump to page:

2025

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