Pike-devel May 2020

pike-devel@lists.lysator.liu.se

5 participants
13 discussions

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

Crypto.Password and Blowfish
by Stephen R. van den Berg 20 Jul '20

20 Jul '20

Has anyone attempted to add support for Blowfish encryption to Crypto.Password? I have some $2y$... prefixed passwords (interfacing with the PHP password_verify()) which I need to verify. -- Stephen.

4 11

Operator assignment and strict_types
by Marc Simpson 07 Jul '20

07 Jul '20

Hi folks, It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents. For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain: int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types Similarly, operator assignment on aggregates fails to elicit a warning: array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]); I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner. Have there been any discussions around addressing this inconsistency? Thanks, Marc

3 3

Any interest in an open source HTTP daemon in Pike? (Spike)
by Stephen R. van den Berg 12 Jun '20

12 Jun '20

I've written (for internal use) an HTTP daemon in Pike, using roughly the following featureset: - Mainly meant to run (custom) pike modules processing requests. - Also serves static content (through a simple config file). - Supports multiple virtual servers, with multiple mountpoints each. - Supports database connection pools. - Supports integrated memory caching. - Uses the Shuffler for all network I/O. - Supports websockets. - Gzips output automatically. - Uses statically precompiled .gz files if available and new enough. - It has been fondly baptised as a "Spike" daemon. - It integrates well with an nginx reverse proxy (and thus I did not add SSL support so far), which then adds HTTP/2 and SSL support. - It only runs on Pike 8.1, not Pike 8.0 (mostly because of the broken Shuffler in 8.0). - The whole source is about 15 KB (5 KB when gzipped). If there is interest, I'll clean up the code a bit more, and make it available via a git repo somehwere. -- Stephen.

2 4

Protocols.HTTP.params_encode() and _decode()
by Stephen R. van den Berg 30 May '20

30 May '20

After having needed to program (HTTP) parameter decoding/encoding for the nth time, I decided to add some proper code for generic use. Any objections to the interface and/or naming? Is the solution fast enough? -- Stephen.

2 7

Annotation question
by H William Welliver 28 May '20

28 May '20

Given: A.pmod/B.pike inherit Pike.Annotation; A.pmod/C.pike inherit Pike.Annotation; and test.pike: @A.B; @A.C: string foo; function bar; class gazonk { @A.B; } I can do: > object o = ((program)"test.pike")(); > mkmapping(indices(o), annotations(o)); (1) Result: ([ /* 3 elements */ "bar": 0, "foo": (< /* 1 element */ A.C >), "gazonk": 0 ]) But I’m puzzled as to why gazonk is 0 and not (<A.B>). Also, how would I query program(“test.pike”) to see that it has A.C defined within it? I have not dug too far into this yet, just hoping there’s an obvious answer I’ve missed. Thanks in advance! Bill

1 0

Re: GL build error on MacOS 10.14
by Marc Simpson 28 May '20

28 May '20

On Thu, May 28, 2020 at 8:48 AM Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > >Also, GL is deprecated as of 10.14, > > Hm? They can't seriously expect people to use Vulcan or some crap > like that, can they? "Metal", apparently: https://appleinsider.com/articles/18/06/28/why-macos-mojave-requires-metal-…

1 0

GL build error on MacOS 10.14
by H William Welliver 28 May '20

28 May '20

[I’m not very familiar with this module, so I’ll leave this as a bug report rather than fixing it myself] On MacOS 10.14, master fails to build the GL module with the following error: /Users/hww3/devel/pike/src/post_modules/GL/GLSL.cmod:800:5: error: use of undeclared identifier 'GL_LUMINANCE8_EXT Thats in glext.h but is guarded by GL_EXT_texture, so defining that before the include seems to make the error go away. Also, GL is deprecated as of 10.14, so in order to cut down on noise, I added -DGL_SILENCE_DEPRECATION to my build. Not sure if that’s desirable in general. Also, I noticed a bunch of grumbling in the Kerberos and GSSAPI modules about deprecations. Think that’s harmless noise (for now). Bill

2 1

Protocols.HTTP.Server.Request and a reference back to the listening socket?
by Stephen R. van den Berg 28 May '20

28 May '20

Once you have an accepted connection in Protocols.HTTP.Server.Request, is there a reference to the original listening socket the connection was accepted on? Why don't we preset the set_id()/query_id() value on the accepted socket with the one from the listening socket? -- Stephen.

1 1

Re: RFC: Attributes in Markdown text
by Chris Angelico 22 May '20

22 May '20

On Fri, May 22, 2020 at 9:28 AM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > > >How does that sound? > > > > Sounds good to me. The expectations should be to move it from Tools to > Parser (or something) also once the changes are done. Cool. The changes are done, including that move - which actually is a move *back*. For compatibility reasons, I've kept a little shim in Tools, so you can still call Tools.Markdown.parse() as before. At the moment, it's on branch rosuav/markdown-parser-extensibility but I'm fairly sure there won't be any backward compatibility problems. If anyone else can test any of their Markdown code, I'd appreciate it, just as a quick check. If no objections and no issues found, I'll merge it into master some time next week. ChrisA

1 0

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 2020