Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Segmentation fault cause
by Stephen R. van den Berg 28 Aug '20

28 Aug '20

Running without these commits, it runs forever. Running with these commits results in segmentation faults every few minutes to hours (this is in heavy threaded/lock code: pgsql driver). I cannot offer a stacktrace yet. commit 4781e5e4fe034cc8b2acef468131d5dbc51ca21f Author: Henrik Grubbström (Grubba) <grubba(a)grubba.org> Date: Sun Jun 28 16:33:02 2020 +0200 Threads.Mutex: Added {try_,}shared_lock(). src/threads.c | 256 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---… [View More]

3 30

Pike, WebSockets, and SSL
by Chris Angelico 12 Aug '20

12 Aug '20

Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only. Is it necessary to close in the write direction only, or can the websocket simply close both ends at once? The exception can't easily be dealt with, since it happens in the backend. Demo code available here. If you don't have a certificate, it'll generate a self-signed; the behaviour is the same. https://github.com/Rosuav/StilleBot/blob/master/ws_halfclose.pike ChrisA

2 4

Re: Type checking of exponentiation
by Chris Angelico 09 Aug '20

09 Aug '20

On Mon, Aug 10, 2020 at 1:02 AM Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > 4^-2 is not an integer. It's 0.0625 (or 1/16, if expressed as a > fraction, which seems to be what 8.1 has chosen here). True. In the original, though, this was guarded such that this expression would only ever have a positive exponent. I couldn't figure out a way to force STR to be interpreted as int(2..) though. The original was … [View More]

1 0

Type checking of exponentiation
by Chris Angelico 09 Aug '20

09 Aug '20

In order to implement an expression evaluator, I have a two-pass compilation that first uses a magic resolver to find external name references, and then compiles the actual code to get a function back. This cut-down version of it showcases a strange phenomenon: //Magic resolver. Any symbol at all can be resolved; it'll come through as 0, but the name //will be retained. Used in the precompilation stage to capture external references. multiset(string) symbols; mixed resolv(string symbol, string … [View More]

2 1

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

19 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

Re: Operator assignment and strict_types
by Marc Simpson 07 Jul '20

07 Jul '20

Thanks! On Tue, Jul 7, 2020 at 5:00 AM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > Hi folks, > > Hi Marc. > > It took some time, but... > > > It looks like operator assignment (op=), increment and decrement > > statements aren't subjected to the same typechecks as their more > > explicit equivalents. > > Correct. > > > For example, neither the post-increment nor += statements … [View More]

1 0

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 … [View More]

3 3

an automap bug
by Mateusz Krawczuk 06 Jul '20

06 Jul '20

Reproduces both on pike 8 from apt repository and pike compiled on master: $ ./pike -v Pike v8.1 release 13 Copyright © 1994-2018 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; read the files COPYING and COPYRIGHT in the Pike distribution for more details. $ $ cat automap1.pike int main() { write( "%O\n", combine_path("foo", ({ "abc", "cde" })[*] ) ); } $ $ cat automap2.pike int main() { … [View More]

2 1

Recursive typedefs and add_constant
by Chris Angelico 29 Jun '20

29 Jun '20

I've run into a weirdness involving a recursive typedef and adding a constant. Example: typedef string|int|array(foo) foo; If compiled on its own, this creates a recursive typedef that can handle arbitrarily-nested arrays of strings and ints. Contrast: typedef multiset(string|int) strint; add_constant("strint", strint); typedef string|int|array(strint) foo; This will reference the added constant, and will allow strings, integers, and multisets of strings/ints, but not recursively. What if … [View More]both names are the same? constant code = #" typedef string|int|array(foo) foo; foo x = 1.0; "; typedef multiset(string|int) strint; void compile_error(string filename, int line, string msg) {write("%s\n", msg);} int main() { write("Without constant:\n"); catch {compile_string(code, "-", this);}; add_constant("foo", strint); write("\nWith constant:\n"); catch {compile_string(code, "-", this);}; } Is the array of foo supposed to be a recursive reference, or a reference to the constant? And is there a way to force one interpretation or the other? A related problem (or a consequence of this) is that repeatedly recompiling a provider of constants can cause strangenesses, up to and including quadratically-increasing compilation time. Consider this cut-down version of part of one of my apps: constant code = #" #ifdef FAST typedef string|mapping(string:string|_echoable_message)|array(_echoable_message) _echoable_message; typedef _echoable_message echoable_message; #else typedef string|mapping(string:string|echoable_message)|array(echoable_message) echoable_message; #endif typedef echoable_message|function(object,object,string:echoable_message) command_handler; bool assess_command(command_handler f) { object|mapping flags = functionp(f) ? function_object(f) : mappingp(f) ? f : ([]); return flags->ok; } protected void create(string n) { #ifndef FAST2 add_constant(\"echoable_message\", echoable_message); #endif add_constant(\"assess_command\", assess_command); } "; int main() { add_constant("commands", ([])); System.Timer tm = System.Timer(); while (1) { compile_string(code)(); write("Compiled in %.2fs\n", tm->get()); } } Running this with -DFAST uses a different name temporarily, dodging the problem. Using -DFAST2 doesn't add the typedef as a constant, also dodging the problem. But otherwise, it quickly starts taking notable time to run each compilation - each iteration about 3-4 times as long as the previous. The question is: Should echoable_message be using the added constant, or should it be defined recursively? I actually don't know what is correct behaviour here. ChrisA [View Less]

1 0

`-> and the context argument
by Stephen R. van den Berg 20 Jun '20

20 Jun '20

The docs say this: mixed `->(string index, object|void context, int|void access) Parameter context Context in the current object to start the search from. If UNDEFINED or left out, this_program::this is to be be used (ie start at the current context and ignore any overloaded symbols). Can someone illustrate this with an example which shows how context can differ and how it could be used? -- Stephen.

2 1

Jump to page:

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