Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

mmap'ing a device with System.Memory
by Chris Angelico 01 Dec '24

01 Dec '24

Currently this isn't possible - if you attempt to open System.Memory("/dev/some-device") it rejects it due to being unable to query the length of the file. It would be nice to be able to, for example, stick Pike on a Raspberry Pi, and then mmap /dev/gpiomem to manipulate things. Would it be of value to have a way to bypass that length check? I think that that's the only thing stopping it, although I'm not entirely certain. ChrisA

1 0

macOS Homebrew MySQL / MariaDB support
by Bertrand Lupart 04 Oct '24

04 Oct '24

Hello, Looks like Pike’s Homebrew formula is lacking MySQL / MariaDB support : $ brew info pike ==> pike: stable 8.0.1738 (bottled) […] $ pike --features auto_bignum machine_code dynamic_modules threads out-of-band_data double_precision_float Bz2 Crypto.AES.GCM Crypto.ECC.Curve GL GLUT GSSAPI Gettext Gmp Gz HTTPAccept Image.GIF Image.JPEG Image.PNG Image.TIFF Image.XFace Kerberos MIME Nettle PDF.PDFlib Protocols.DNS_SD Regexp.PCRE Regexp.PCRE.Widestring SQLite Standards.JSON System.FSEvents.EventStream WhiteFish Yp Surprisingly, looks like that was removed a while ago : https://github.com/Homebrew/homebrew-core/commit/3d9568bc86dc58c869c6e68a2e… Any reason why this change was made ? Bertrand

2 1

Understand the behaviour of Stdio.Buffer()->match()
by Chris Angelico 08 May '24

08 May '24

I'm a bit confused by this behaviour, and am unsure whether it needs to be better documented, or perhaps is a bug. int main() { object buf = Stdio.Buffer("#44"); write("Matches: %O %O\n", buf->sscanf("#%2[4]"), (string)buf); buf = Stdio.Buffer("#4"); write("Doesn't: %O %O\n", buf->sscanf("#%2[4]"), (string)buf); buf = Stdio.Buffer("#44"); write("Matches: %O %O\n", buf->match("#%2[4]"), (string)buf); buf = Stdio.Buffer("#4"); write("Doesn't: %O %O\n", buf->match("#%2[4]"), (string)buf); } When using sscanf, the successful match returns ({"44"}) and leaves the buffer empty, and the unsuccessful match returns an empty array and leaves the "4" in the buffer. This makes sense; the hash was matched and consumed, but the 2-character requirement meant that nothing was matched. Using match instead produces a somewhat odd result though. If there's enough text in the buffer, it returns "44" and leaves the buffer empty; this corresponds to sscanf's behaviour. In the other case, though, it returns "#%2[4]" (the pattern), and leaves "4" in the buffer. Is this intentional? (If the first character of the buffer isn't a hash, both return 0 and leave the buffer unchanged. This behaviour is also correct. It's only the partial match that seems curious.) ChrisA

3 3

Re: Understand the behaviour of Stdio.Buffer()->match()
by Chris Angelico 08 May '24

08 May '24

On Wed, 8 May 2024 at 17:57, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Yes, although I'm still not sure this follows the principle of least > astonishment: > > If no matches results in "", and the result is the sum of the matches, > wouldn't you expect the result in this case to be ""+4+7, i.e. the > string "47"? If an arithmetic sum is expected then you should get 0 > from a non-match IMO... Well, you do get zero for a non-match, so ... I guess so? :) > object buf = Stdio.Buffer("asdf"); > buf->match("qwer"); (1) Result: 0 But I don't think that's quite the same as a null sum. ChrisA

2 1

Re: Understand the behaviour of Stdio.Buffer()->match()
by Chris Angelico 08 May '24

08 May '24

On Wed, 8 May 2024 at 17:04, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > The behaviour of match() when there is not exactly one thing matching > seems a bit weird in general: > > Pike v9.0 release 2 running Hilfe v3.5 (Incremental Pike Frontend) > > object buf = Stdio.Buffer("#4,7"); > > buf->match("#%d,%d"); > (1) Result: 11 > > That IS a bit weird, although not undocumented - if it matches multiple strings, it returns their concatenation. But since it's defined as returning the *sum*, this quirk happens. It's designed for a single match pattern and for that it generally does fine. Definitely an amusing consequence though! ChrisA

2 1

Re: Understand the behaviour of Stdio.Buffer()->match()
by Chris Angelico 08 May '24

08 May '24

On Wed, 8 May 2024 at 16:28, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Thanks for the report. > > Fixed in Pike master. match() now returns "" in this case. Ah! Thank you! ChrisA

1 0

Pike Meet-up 2024-Q2
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 07 May '24

07 May '24

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 6 month mark from the latest conference is coming up soon, it seems time to announce the second such meeting for 2024: Pike Meet-up 2024-Q2 Date: 2024-05-11 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB Storgatan 46 Linköping Welcome! /grubba

1 1

Re: Running an HTTP(S) server using an externally-provided file descriptor
by Chris Angelico 02 May '24

02 May '24

On Thu, 2 May 2024 at 19:15, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Hi again Chris. > > > On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) > > developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > > > > Does SSL.Port()->listen_fd() not work? > > > > Inside HTTP.Server.Port, it kinda does, I think? I didn't run into any > > actual problems. > > > > Inside HTTP.Server.SSLPort though, it doesn't, because omitting (or > > zeroing) the port number results in the default of 443 being used. So > > at best, you would have to pick a port and hope that it's not in use, > > listen on that, and then replace it with listen_fd(). I didn't try > > that but it seems rather inelegant. > > Hmm... With your fixes, wouldn't it it work to just give an > appropriate SSL.Port object to HTTP.Server.Port()? You would > miss out on the generation of the default certificate, but > otherwise it ought to behave the same. > Huh. That would be rather nice, if it works. Currently, the two codebases look pretty different. It would be rather neat if SSLPort could simply inherit Port and provide a default parameter. ChrisA

1 0

Re: Running an HTTP(S) server using an externally-provided file descriptor
by Chris Angelico 02 May '24

02 May '24

On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Hi Chris. > > > See branch rosuav/pre-listening-ports for a first attempt at this. > > > > With Stdio.Port(), it's possible to receive an open socket as a file > > descriptor and start accepting connections on it. (Notably, this > > allows systemd to provide a socket as FD 3, allowing unprivileged > > programs to listen on privileged ports.) Currently, this isn't > > possible with Protocols.HTTP.Server.Port or its friends. > > This reminds me of the original lpc4 Spider webserver installation > at Lysator. > > > For unencrypted connections, this isn't too hard. Instead of having it > > construct a Port, it can receive one already listening. For SSLPort > > though, it inherits SSL.Port, so this doesn't work. What would be a > > good API for making this possible? > > Does SSL.Port()->listen_fd() not work? Inside HTTP.Server.Port, it kinda does, I think? I didn't run into any actual problems. Inside HTTP.Server.SSLPort though, it doesn't, because omitting (or zeroing) the port number results in the default of 443 being used. So at best, you would have to pick a port and hope that it's not in use, listen on that, and then replace it with listen_fd(). I didn't try that but it seems rather inelegant. On Thu, 2 May 2024 at 18:21, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > If I understand correctly, the problem is that while you can construct > an Stdio.Port or an SSL.Port from a file descriptor, you can't do so > with a Protocols.HTTP.Server.SSLPort, because the create function of > this class (taking 1-6 arguments) unconditionally calls > Port::socket::bind(). > > In which case I guess the solution would be to add a variant create() > taking either zero arguments or an SSL.Context (to mimick the one of > SSL.Port) while leaving the current one as it is for compatibility? This may be the solution to both problems. Let me see if I understand you correctly. The variant create would take just the Context, and then before the SSLPort becomes useful, you call listen_fd() and then set the callback? ChrisA

3 2

Running an HTTP(S) server using an externally-provided file descriptor
by Chris Angelico 02 May '24

02 May '24

See branch rosuav/pre-listening-ports for a first attempt at this. With Stdio.Port(), it's possible to receive an open socket as a file descriptor and start accepting connections on it. (Notably, this allows systemd to provide a socket as FD 3, allowing unprivileged programs to listen on privileged ports.) Currently, this isn't possible with Protocols.HTTP.Server.Port or its friends. For unencrypted connections, this isn't too hard. Instead of having it construct a Port, it can receive one already listening. For SSLPort though, it inherits SSL.Port, so this doesn't work. What would be a good API for making this possible? (Protocols.WebSocket.Port and Protocols.WebSocket.SSLPort inherit from their non-websocket equivalents, so they broadly "come along for the ride".) Incidentally, this actually means it is easier to use opportunistic TLS than mandated, since a regular Port can, with a handful of lines of code, be enhanced to call on SSL.File directly. But API-wise it would be a bit quirky if Port supports this feature and SSLPort doesn't. Recommendations? ChrisA

3 2

Jump to page:

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