Pike-devel October 2016

pike-devel@lists.lysator.liu.se

4 participants
18 discussions

negative indices in array ranges
by Martin Baehr 14 Aug '26

14 Aug '26

hi, instead of having to do: reverse(reverse(foo/"/")[1..]); i'd very much prefer: (foo/"/")[..-2]; are there any reasons that speak against supporting this other than me not being able to offer a patch? greetings, martin.

13 51

negative indices in array ranges
by Mirar ＠ Pike developers forum 14 Aug '26

14 Aug '26

levels might possibly be from -1 and up, -1 meaning infinite.

10 25

pike_frame->fun = FUNCTION_BUILTIN
by Arne Goedeke 16 Apr '26

16 Apr '26

In INIT, EXIT and some gc callbacks the fun in Pike_fp is set to FUNCTION_BUILTIN. there are some places in the code (e.g. ADT.List()->_get_iterator) where ->fun is used in INHERIT_FROM_INT et al, which segfaults (except with PIKE_DEBUG). I am not sure where to fix this. Should the *_FROM_INT macros check for FUNCTION_BUILTIN or is this better to be handled in the individual INIT/EXIT methods ? does anyone object to making ADT.Stack and ADT.Queue inherit ADT.List? arne

3 2

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 09 Apr '26

09 Apr '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

4 3

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Were you not able to get any C code to play through SDL either? Does your SDL library have a mixer compiled in it (I think it is optional)?

5 4

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

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

Clean-room Engine.IO implementation committed to git 8.0/8.1
by Stephen R. van den Berg 23 Nov '16

23 Nov '16

Please review, any comments are welcome. The docs still need improvement, working on that. Currently tackling Socket.IO. -- Stephen.

4 8

Lambdas, captured variables
by Martin Karlgren 23 Nov '16

23 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 23 Nov '16

23 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

2026

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