Pike-devel May 2016

pike-devel@lists.lysator.liu.se

8 participants
25 discussions

write callbacks and Stdio.File.set_buffer_mode()
by Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum 25 May '16

25 May '16

If I set a Stdio.File object to buffer mode with both an input and an output buffer, is there a point in having a write callback registered? I can simply output data to the buffer and it will be written to the stream, right?

2 3

Re: Protocols.WebSocket client mode
by Peter Bortas 19 May '16

19 May '16

On Wed, May 18, 2016 at 6:40 PM, Marcus Agehall (nu med K-märkt fastighet och ny elcentral) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > My personal stance is that as long as you don't break existing > APIs/features, backporting new ones is not a problem. Others may > disagree with this though. That's not the whole truth. The general answer to "can I add to stable" is no. It can be added as an exception if discussed and the following is met: - The addition must be obviously safe. - It should add something that is _needed_ today. Not something that might be useful in some theoretical situation or large code cleanup. - It's checked in to the development branch before stable. Stable is a contract that should say to anyone using it that upgrades between minors are safe. Part of trying to do a release every month (in practise I predict around six successful release per year) is acctually to get stricter on this but also to make feature releases once per year. (Apparently the KOM-export script is broken again, so copy-pasting this to email. Will probably show up again whenever KOM-export gets fixed.) Regards, -- Peter Bortas

1 0

Protocols.WebSocket client mode
by Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum 18 May '16

18 May '16

I've been spending some time in the realm of Protocols.WebSocket lately. I've been working on a client mode for it as it only contains the server side parts at the moment. I now have a working version for Pike 8.0 (which is the version that I want it for) but when I tried to port it to 8.1 I ran into a bit of a problem. It seems that the 8.1 branch has been rewritten to work with Stdio.Buffer, which is good. But from what I can tell, SSL.File does not support that API. Is there a reason for this? Also, any objections to extending the WebSocket module in 8.0 to also provide a client mode?

4 9

SSL.File()->nonblocking_mode is protected
by Chris Angelico 17 May '16

17 May '16

I'm messing around with SSL.File in a threaded server, and have run into a strange difficulty. The object defaults to nonblocking mode, which is fine; but how do I set it to blocking mode? Here's my current code: //sock is a straight Stdio.File initially string handshake = sock->read(9, 1); if (sizeof(handshake) >= 2 && handshake[0] == 0x16 && handshake[1] == 0x03) { //Probable SSL handshake Pike.SmallBackend backend = Pike.SmallBackend(); sock->set_backend(backend); sock = SSLFile(sock, SSL.Context()); write("nonblocking_mode: %O\n", sock->is_nonblocking()); sock->accept(handshake); backend->call_out(sock->set_blocking, 0); while (sock->is_nonblocking()) backend(1.0); } But this depends on being able to figure out when the socket has gone into blocking mode. To do that, I'm using my own subclass of SSL.File: class SSLFile { inherit SSL.File; int is_nonblocking() {return nonblocking_mode;} } to get around the fact that nonblocking_mode (the exact thing I'm looking for!) is flagged 'protected'. Why is this? And would an is_nonblocking method be a reasonable addition? ChrisA

1 0

Re: glob() in 8.1
by Peter Bortas ＠ Pike developers forum 16 May '16

16 May '16

For the record: I will push for 8.2 at the latest Q1 next year. Going for a 9.0 in Q2 instead would be manageble I think. I'm somewhat worried that it was easy to construct a plausible test case where the the glob behaviour will break old code: Pike v7.8 release 834 running Hilfe v3.5 (Incremental Pike Frontend) > array files = ({ "C:\\foo.bat", "C:\\bar.exe" }); > glob("C:\\*.exe", files); (2) Result: ({ /* 1 element */ "C:\\bar.exe" }) Pike v8.1 release 4 running Hilfe v3.5 (Incremental Pike Frontend) > array files = ({ "C:\\foo.bat", "C:\\bar.exe" }); > glob("C:\\*.exe", files); (1) Result: ({ }) Handling this with deprication isn't possible in a nice way, but I do think it's a change we want to make. How about this butt ugly gludge: Make a pike-global flag switching to the new behaviour. Depricate-warn for any use of glob in 8.2 that isn't first setting that flag or using the compatibility interface to directly specify a version. The flag could be full-hog ugly: Make it a command line switch. Or something you set in the master. Or a new builtin. :-/ I guess I'm talking about "import from Future". Ugh.

1 0

Re: New stable release: 8.0.240
by Peter Bortas 15 May '16

15 May '16

On Sun, May 15, 2016 at 4:18 PM, Peter Bortas <bortas(a)gmail.com> wrote: > polishing and a recommended upgrade. New for this release is a MacOSX > binary build. Please note that the Mac build is a executable installer > that requires gmp and nettle from macports to run though. I haven't built a MacOS release since leaving Roxen many years ago, but I brought out a Mac Mini from storage and set it up this weekend. If someone tells me how to build a .pkg I'll try to do that for the next release. I assume it has something to do with packaging/macosx/framework_Info.plist? That file has been rotting since 7.7 though, so input from developers on MacOSX would be valuable here. -- Peter Bortas

1 0

Re: glob() in 8.1
by Jonas Walld�n ＠ Pike developers forum 13 May '16

13 May '16

Granted more manageble for code I maintain myself, but it doesn't eliminate the problem in theory. I think it ultimately depends on what 8.1 is intended to be when it is released: a drop-in upgrade in 8.0 environments, or a major step like 7.x to 8.0? If it will become Pike 9.0 and introduce a bunch of other incompatibilities I'd be more open to that change, but not otherwise.

1 0

Re: glob() in 8.1
by Per Hedbor 13 May '16

13 May '16

Well. Is [ and \ really that common in glob patterns? (the addition of quoting and making [ a control character being the incompatible changes) It is possible to use 8.0::glob (not yet in place). Or this, which is future compatible (8.0:: would be removed after a while): add_constant( "glob", lambda(array|string a, array|string b) { array(string)|string compat(array|string what) { if(arrayp(what)) return map(what,this_function); return replace(what, (["\\":"\\\\", "[":"\\[" ])); }; return !!glob(compat(a),b); }); (since I don't think any of the array version are used in roxen, it can be simplified a bit.. :)) Anyway, the glob function in 8.1 complies with the definition of glob in wikipedia, whatever that is worth. As for why glob was modified: The lack of quoting made it impossible to match * or ?. The [ is less important to me at least, I just added that to be feature complete (or, well, to the 'basic' glob pattern syntax). After perusing the roxen source there are very few locations where the pattern is not a simple constant *.<ext>, only a few places takes the pattern as input from the user (web developer). In most cases this seems to then be matched to a mime type ([ and \ being somewhat uncommon in those) or a file (not path) name (no \, theoretically [ can occur), Of course, custom code can do whatever. On Fri, May 13, 2016 at 4:10 PM, Jonas Walldén @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Just saw Per's checkin (781fcde2) in 8.1: > > > Extended glob pattern syntax: > > o \ can now be used to quote special characters in the pattern > > o [ can be used for ranges of characters ([bx] [a-c0-9] [^a] etc). > > > > Also changed glob to return the matching glob instead of 1 when an > > array is passed as the first (pattern) argument. > > > > This can be used to remove some loops where you want to do > > different things depending on which pattern matched. > > > > Both these changes are incompatible. > > Can we please put this in a new method or use opt-in with an extra > flag? I'm not too worried about the return value, but the changes in > glob parsing sound problematic to me. > > At least for our customers there are plenty of globs in user data > (RXML code, system configs, custom modules etc) that could misbehave > silently, i.e. without producing compile-time errors.

2 2

glob() in 8.1
by Jonas Walld�n ＠ Pike developers forum 13 May '16

13 May '16

Just saw Per's checkin (781fcde2) in 8.1: > Extended glob pattern syntax: > o \ can now be used to quote special characters in the pattern > o [ can be used for ranges of characters ([bx] [a-c0-9] [^a] etc). > > Also changed glob to return the matching glob instead of 1 when an > array is passed as the first (pattern) argument. > > This can be used to remove some loops where you want to do > different things depending on which pattern matched. > > Both these changes are incompatible. Can we please put this in a new method or use opt-in with an extra flag? I'm not too worried about the return value, but the changes in glob parsing sound problematic to me. At least for our customers there are plenty of globs in user data (RXML code, system configs, custom modules etc) that could misbehave silently, i.e. without producing compile-time errors.

1 0

Pike 8.0.240 release candidate
by Peter Bortas 09 May '16

09 May '16

I did an effort to get a Windows 10 environment up this weekend, but it's not done. So here is a release candidate together with an old classically compiled Windows version. If no one finds anything bad (where bad is worse than the latest stable) this will be the release next weekend. Pike 8.0.240 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.240/Pike-v8.0.240.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.240/Pike-v8.0.240-win32-oldli… -- Peter Bortas

3 2

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