Pike-devel November 2016

pike-devel@lists.lysator.liu.se

9 participants
52 discussions

Possibly fixed error
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 23 Nov '16

23 Nov '16

The following code void main() { write("%O\n", combine_path_nt("/", "/v1/RPC")); string path = "/v1/RPC"; write("%O\n", combine_path_nt("/", path)); } consistently give the following output on Windows Pike 8.0.182 "/v1/RPC" "//v1/v1/RPC" but works as expected on Windows Pike 8.0.358. Can anyone think of a fix that would make this bug go away, or is it just luck in how the compiler puts things together?

3 3

Patches from Debian
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 23 Nov '16

23 Nov '16

The Debian package has accumulated a few patches through the years. Could you perhaps consider applying some of them? https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/bad_size_t_… Fix undefined behaviour/buffer overruns on 64-bit architectures caused by broken redefinition of size_t. Basically the same change as was made to image_jpeg.c in 2008. https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/undefined_h… Protocols.DNS_SD apparently doesn't include the necessary header declaring htons() (arpa/inet.h *or* netinet/in.h depending on platform). The code might compile anyway, but crash later. The rest are actually all HURD related, but should be harmless enough: https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/pthread_stu… Check whether pthread_atfork() is a stub and not just whether it exists. https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/misplaced_M… The conditional #define MAXPATHLEN comes after the first use of it (in src/modules/_Stdio/efuns.c). https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/hurd.patch?… 1. Let realpath() allocate memory itself. 2. Include mach/message.h directly where mach_msg_type_number_t is used. 3. Don't build shared objects any differently than on Linux (-shared, not -Wl,-Bshareable).

3 5

Debug symbols in GL and GTK2
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 23 Nov '16

23 Nov '16

How come src/post_modules/GL/Makefile.in and src/post_modules/GTK2/Makefile.in delete -g*, -W*, and -O* flags from CFLAGS? efb49e63aff070c by Grubba on 2000-09-02 only says "Attempt at fixing a few warnings" and ed4662949516b507 by Per on 1999-11-20 is even terser with "Fixed makefile" (that's from the GTK 1 module). By contrast, GLUT's makefile doesn't do this.

1 0

Pike 8.0.352 release candidate
by Peter Bortas 22 Nov '16

22 Nov '16

Only real change compared to 3.0.350 is that the change entry about fixing websockets is now true. Pike 8.0.352 beta/release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.352/Pike-v8.0.352-win32-oldli…

3 2

About the new pike.lysator.liu.se
by Pontus Östlund 22 Nov '16

22 Nov '16

As you may have noticed pike.lysator.liu.se <http://pike.lysator.liu.se/> has gotten a new outfit. I also took the freedom to remove old - I mean really, really, really old - stuff. There were a lot of misinformation on the site, so I've tried to the best of my ability to fix that. I've removed some stuff that was drained with broken external links and what not (fex the /applications/ and /projects/ directories). I've also re-structured some stuff, most notably under the /about/ section (but I've added some redirect patterns in the redirect module so nothing should be broken there). There's still some stuff left to fix, most notably the module refdoc. But that will hopefully be fixed next week. I've made alot of changes to the various refdoc related stuff, which all is available in the 8.1 branch, and I will move that to the 8.0 branch so that the 8.0 refdoc can be built with the new refdoc structure/template. For those of you that have write access to the Pike site there's http://pike.lysator.liu.se/README.xml <http://pike.lysator.liu.se/README.xml>. This only contain some quick pointers at the moment. If you have any further questions feel free to email me directly. Any other comments/feedback regarding the new site is more than welcome! Happy Pike coding! 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>

2 1

Current state of C/C++ library wrapping
by Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum 22 Nov '16

22 Nov '16

What is the current situation for generating wrappers for C/C++ libraries so they can be used in Pike? I know there is some experimental stuff in SWIG, but it seems very old. Are there any up-to-date tools for doing this?

2 1

Code review request: branch rosuav/gtk2-drag-drop
by Chris Angelico 22 Nov '16

22 Nov '16

I'm aware that GTK2 is a bit of a dark and dusty corner in Pike, with few devs understanding everything that goes on in there. Nonetheless, I'm hoping someone can eyeball my code, at least from a general Pike dev point of view. Are there pitfalls that I haven't noticed? Things that I've done inefficiently? As mentioned in another thread, I've used some C99 here. Is this now permitted? If not, I can rejig that. If nobody has any comments (at least this time I know to keep an eye on LysKOM!), I'll merge it into 8.1, but I'd rather have at least one additional pair of eyeballs run over the code before that happens, just in case. ChrisA

3 5

Re: MIME.Message and RFC 2047 encodings
by Chris Angelico 22 Nov '16

22 Nov '16

On Wed, Nov 23, 2016 at 1:35 PM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > IÃ'm sorry, but your code is incorrect, and it cannot be done > correctly either. As I explained, the encoding rules depend on the > grammar of the paricular header field. Use of the _text functions is > correct only for headers which grammar declare them to be "text". > Headers which instead use the "phrase" non-terminal in their grammar > (such as the "From:" and "To:" headers) need to be treated > differently. There is even an example in RFC1522 which is not > correctly decoded by your class. Looks like the LysKOM to mailing list gateway is finally up again - yay! Small oddity of encoding (unless that's a typo in that "I'm" above) but that's no biggie. Thank you thank you thank you to whomever is responsible for this. ChrisA

1 0

Lambdas, captured variables
by Martin Karlgren 22 Nov '16

22 Nov '16

Hi all, I’m sometimes annoyed by the trampoline garbage that results when referencing variables in the surrounding scope from a lambda function (“closure”). Also, all variables in the frame referenced by the lambda will be kept around, even if just a single one is actually used in the lambda. void foo() { string var1; mapping var2; string bar = “whatever"; function f = lambda(string arg) { write("%O, %O\n", bar, arg); }; … other code that prevents tail-call optimization ... return f; } int main(int argc, array argv) { function f = foo(); f(“gazonk”); f = 0; // The lambda and the variables referenced in the frame used to execute “foo” are now garbage. } A possible workaround is to cut the reference to the “foo” frame: function f = lambda(string var1, string var2) { return lambda(string arg) { write("%O, %O, %O\n”, var1, var2, arg); }; }(var1, var2); However, this is pretty verbose. Maybe it would make sense to introduce some kind of syntactic sugar, for example: lambda[var1, var2](string arg) { }; This could perhaps translate to the construct above, and I think this syntax would map pretty well to how explicitly captured variables work in other languages. Some languages allow renaming of captured variables – not sure if it’s necessary or not. "lambda[myvar1 = var1, myvar2 = var2]() {}" or something. Ideally, variables from the surrounding scope not present in the capture list should not be usable in the lambda, to avoid unintended trampolines. Obviously, this would follow the same pass-by-value/pass-by-reference semantics of the various Pike types as in function arguments, which I personally think is a good thing. (A special case would be "lambda[](string arg) { }” which would prevent referencing any variables from surrounding scopes at all.) What do you all think? /Marty

4 8

MIME.Message and RFC 2047 encodings
by Chris Angelico 22 Nov '16

22 Nov '16

Currently, Pike's MIME.Message parser doesn't handle non-ASCII headers with specified encodings: > MIME.Message("Hello, world!", (["Subject": "Hello, \U0001F310"])); (10) Result: Message(([ ])) > (string)_; (11) Result: "Subject: Hello, \U0001f310\r\n" "Content-Length: 13\r\n" "\r\n" "Hello, world!" Going the other way: > MIME.Message("Subject: =?UTF-8?B?SGVsbG8sIPCfjJA=?=\r\n\r\nHello, world!"); (13) Result: Message(([ ])) > _->headers; (14) Result: ([ /* 1 element */ "subject": "=?UTF-8?B?SGVsbG8sIPCfjJA=?=" ]) I'm currently working with IMAP and RFC[2]822 messages. I could either implement RFC 2047 parsing in my app, or enhance MIME.Message to return Unicode strings automatically. Would this functionality be welcomed in trunk? ChrisA

3 12

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