Pike-devel October 2020

pike-devel@lists.lysator.liu.se

4 participants
16 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

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

SSL hang during handshake
by H William Welliver 25 Nov '20

25 Nov '20

Hi all- I’ve been doing some experiments with SNI and have noticed a potential problem: If SSL.Context->find_cert_domain() doesn’t return a matching certificate, the server handshake doesn’t complete. This causes the client to hang indefinitely. SSL.Context->add_cert() supports (but does not require) a fallback certificate to be specified. Because the server does not control the value it receives, an improperly configured SSL Context could cause a denial of service. I propose to change SSL.ServerConnection so that an alert message is sent if a certificate cannot be chosen. Does that seem like a reasonable approach? If I don’t hear any objections in the next day or so, I’ll add this to master and 8.0 (where the problem definitely exists). Bill

3 3

Concurrent.Promise() and the executor
by Tobias S. Josefowitz 26 Oct '20

26 Oct '20

I have just noticed that that Concurrent.Promise()->create() just plainly calls the passed executor with success and failure as callbacks/arguments. It is my understanding that the whole purpose of the executor is so that any errors thrown (intentionally or inadvertently) can be caught and converted to a rejection of the promise. If not for that (which is handy), I cannot see any purpose or justification for the executor. I think this qualifies as a bug that should just be fixed. I have pushed a commit to that extent to master. I think this should also go onto 8.0. Objections? Agreement all around? However, this opens up another issue, if rejecting with the error caught results in double finalisation, the error thrown about that (i.e. out of Promise()->create() from the callers perspective) will only have very limited hints about the "original" error thrown (it is present in the backtrace as argument to [-2], e.g. failure(), as the original error object/array, but visibility in prints is severly limited). I wonder if doing something along the lines of diff --git a/lib/modules/Concurrent.pmod b/lib/modules/Concurrent.pmod index dbbd509334..01e1d19e98 100644 --- a/lib/modules/Concurrent.pmod +++ b/lib/modules/Concurrent.pmod @@ -776,15 +776,27 @@ class Promise if (executor) { mixed err = catch(executor(success, failure, @extra)); - // This unfortunately does hide the real error in case of - // double-finalization, i.e. - // fail("I reject!"); - // error("I rejected.\n"); - // in the executor will leave our caller with an error about the - // Promise already having been finalized, not giving anyone too much - // information about where the double-finalization occured... - if (err) - failure(err); + if (err) { + // If rejecting the promise fails due to double-finalization, we + // outright lie about the backtrace here so that it includes the + // position where the "original" error is double thrown, which + // probably makes most related debugging easier but maybe some very, + // very hard... + if (mixed err2 = catch(failure(err))) { + mixed bt; + + catch(bt = err[1]); + + catch { + if (arrayp(err2) && arrayp(bt) && sizeof(bt) + && Program.inherits(bt[-1], __builtin.backtrace_frame)) { + err2[1] = err[1] + err2[1][<2..]; + } + }; + + throw(err2); + } + } } } TL;DR mangling the backtrace to pretend control flow was: site of error() -> Promise()->create() -> failure() -> finalise() would do more good than harm. I cannot say, on one hand I think this would really help people running into this problem, but at the same time it admittedly is just all kinds of wrong.

1 1

Annotations, some documentation
by H William Welliver 23 Oct '20

23 Oct '20

Hello, Pike friends: I’ve put together a first draft of a document describing annotations as well as a simple use of them outside the Pike “runtime". I’d be very glad if folks would have a look and provide feedback. I’ve not included any material regarding the “proposals” I’ve made in the last few days. Please have a look and let’s have a conversation about where things are versus where they (might) want to be. http://wiki.gotpike.org/PikeDevel/Annotations As always, your comments and suggestions are heartily welcome! Bill

1 0

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 2020