Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Protocols.DNS.server anyone used it in a DNS server?
by Stephen R. van den Berg 08 Feb '18

08 Feb '18

Has anyone ever used Protocols.DNS.server in an application (to implement a mini-DNS server)? Is the code available? -- Stephen.

3 3

Re: Pull request - jemalloc
by Tomasz Jamroszczak 07 Feb '18

07 Feb '18

On Tue, 06 Feb 2018 14:58:02 +0100, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Right, then I have no general complaints left (if the USE_JEMALLOC > thing Nilsson pointed out is cleared up). This looks localized > enough that it shouldn't break anything. OK, I'll modify the pull request soon after a few more compilations. > I'm curious what benchmarks have been run with this. Do you have any > before and after comparisons for this Tomasz? From cursory testing of Opera Mini transcoder where both Pike and Presto web browser engine using jemalloc on several machines for a few days I can see 15% - 20% smaller memory footprint at the cost of bigger CPU usage. But there's a lot of moving parts so these numbers should not be trusted. I'll have sound numbers in a week. -- Best Regards Tomasz Jamroszczak

2 2

MPI breaks on SunOS
by Stephen R. van den Berg 06 Feb '18

06 Feb '18

In case nobody noticed, Pikefarm seems to break on SunOS because it tries to compile in MPI without proper libs. -- Stephen.

6 6

Pull request - jemalloc
by Tomasz Jamroszczak 06 Feb '18

06 Feb '18

Hi. I'm first time poster. I'm working for Opera Software and I'm developing Opera Mini server, which involves quite a lot of Pike. I've added handling of jemalloc to Pike build and I'd like to upstream it to Pike repository. What's the procedure (a "pull request") to proceed with the change? -- Best Regards Tomasz Jamroszczak

5 7

Re: Pull request - jemalloc
by Tomasz Jamroszczak 06 Feb '18

06 Feb '18

On Tue, 06 Feb 2018 14:48:01 +0100, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Perhaps I'm missing something, but you are testing for > jemalloc/jemalloc.h in configure, but then include it regardless of > the result. Right. I think the src/global.h should read: #if defined(USE_JEMALLOC) && defined(HAVE_JEMALLOC_JEMALLOC_H) -- Best Regards Tomasz Jamroszczak

1 0

pike version when cross compiling
by H. William Welliver III 02 Feb '18

02 Feb '18

I also noticed that the script run during make install assumes that the version of the pike executable running the installer is the version being installed. Perhaps it should actually look at the version it's installing? For instance, when cross compiling the version could theoretically be different and you'd get confusing results.

1 0

strange error on cross-compiled pike 8
by H. William Welliver III 02 Feb '18

02 Feb '18

I cross compiled pike 8.0.498 on an amd64/linux system for use on an armv5tejl/linux system, and I’m getting a strange error when starting it up: -:1: Type mismatch for callback function `[]=: -:1: Expected: scope(0,function(zero, (0=zero) : 0)). -:1: Got : function(int(128..-129), int(128..-129) : int(0..-16777216)). -:1: Program constant "Buffer" is NULL. program.c:6011: Fatal error: Failed to initialize class '_Stdio' No stack - no backtrace. Aborted At first I thought it might be a dynamic loading problem, but _Stdio shouldn’t be a dynamic module, right? Anything obvious I might be missing?

2 3

strlen
by ceder (-) Per Cederqvist ＠ Pike (-) developers forum 02 Feb '18

02 Feb '18

https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/strlen.… says that strlen is deprecated and that we are supposed to use sizeof instead. At the same time, I see new Pike code beeing committed that use strlen (282a8a93 by Grubba 2018-01-04, a5c5c7cd by Bill 2017-12-22, be932f508271a by Arne 2017-10-31, 26da463c by Martin 2017-02-21, ff2876e2cb by Grubba 2017-01-30) (in some cases this is just an strlen that is moved, but still). To be fair, there is also some new code that uses sizeof(string). I get why strlen(multiset|array|mapping|object thing) is deprecated, but peronally I'd like to keep strlen(string) as a supported function. I think it sometimes produces more readable code.

3 3

gcc-7 fails to compile Pike
by Stephen R. van den Berg 01 Feb '18

01 Feb '18

In pikefarm, the devel2 host has gcc-6 and gcc-7 (Debian 7.2.0-19); by default it picks gcc-7 and then fails. Manually compiling with gcc-6 works, I think I already tried gcc-7 using -O1, and that also works. Still trying to investigate why exactly. The only visible odd warning during compilation is this one: Compiling backend.c In file included from /var/src/roxen/81pike/src/array.h:10:0, from /var/src/roxen/81pike/src/callback.h:10, from /var/src/roxen/81pike/src/backend.h:11, from /var/src/roxen/81pike/src/backend.cmod:13: /var/src/roxen/81pike/src/backend.cmod: In function ‘f_Backend_get_stats’: /var/src/roxen/81pike/src/svalue.h:753:13: warning: iteration 9223372036854775807 invokes undefined behavior [-Waggressive-loop-optimizations] while(num_--) \ ~~~~^ /var/src/roxen/81pike/src/interpret.h:265:6: note: in expansion of macro ‘free_mixed_svalues’ free_mixed_svalues(_sp_, x_); \ ^~~~~~~~~~~~~~~~~~ /var/src/roxen/81pike/src/interpret.h:279:7: note: in expansion of macro ‘pop_n_elems’ pop_n_elems (x2_ - 1); \ ^~~~~~~~~~~ /var/src/roxen/81pike/src/interpret.h:283:39: note: in expansion of macro ‘stack_unlink’ #define stack_pop_n_elems_keep_top(X) stack_unlink(X) ^~~~~~~~~~~~ /var/src/roxen/81pike/src/backend.cmod:947:1: note: in expansion of macro ‘stack_pop_n_elems_keep_top’ stack_pop_n_elems_keep_top(args); ^ ~~~~~~~~~~~~~~~~~~~~~~ /var/src/roxen/81pike/src/svalue.h:753:8: note: within this loop while(num_--) \ ^ /var/src/roxen/81pike/src/interpret.h:265:6: note: in expansion of macro ‘free_mixed_svalues’ free_mixed_svalues(_sp_, x_); \ ^~~~~~~~~~~~~~~~~~ /var/src/roxen/81pike/src/interpret.h:279:7: note: in expansion of macro ‘pop_n_elems’ pop_n_elems (x2_ - 1); \ ^~~~~~~~~~~ /var/src/roxen/81pike/src/interpret.h:283:39: note: in expansion of macro ‘stack_unlink’ #define stack_pop_n_elems_keep_top(X) stack_unlink(X) ^~~~~~~~~~~~ /var/src/roxen/81pike/src/backend.cmod:947:1: note: in expansion of macro ‘stack_pop_n_elems_keep_top’ stack_pop_n_elems_keep_top(args); ^ ~~~~~~~~~~~~~~~~~~~~~~ -- Stephen.

3 9

call_out vs Function.curry
by ceder (-) Per Cederqvist ＠ Pike (-) developers forum 01 Feb '18

01 Feb '18

I was made aware of a feature of call_out that I didn't know about: if the object that the callback function belongs to is destructed before the call_out is supposed to be executed, the call_out is silently ignored. But with Function.curry, this is not the case. Instead you get an error message. Here is a demo program: ---cut here--- #!/usr/bin/env pike class X { void work(int x) { werror("got work %d\n", x); } } int main(int argc, array(string) argv) { X x = X(); call_out(x->work, 1, 1); if (argc > 1) call_out(destruct, 2, x); call_out(x->work, 3, 3); call_out(Function.curry(x->work)(4), 4); call_out(exit, 5, 0); return -1; } ---cut here--- Run it with no arguments to see what happens when the object isn't destroyed: $ ./test.pike got work 1 got work 3 got work 4 Run it with any argument to trigger the destruction of x. Notise how you don't get any error for the 3-second callback, but the 4-second currified callback gives an error: $ ./test.pike 1 got work 1 Cannot call functions in destructed objects. Unknown program: destructed object->function(4) server/pike/8.0.469/lib/modules/Function.pmod:85: Function.__lambda_65958_5_line_85() -:1: Pike.Backend(0)->`()(3600.0) Would it make sense to have Function.curry also ignore calls to destructed objects? The change is trivial: > diff --git a/lib/modules/Function.pmod b/lib/modules/Function.pmod > index 8a5498c483..d0b4a65335 100644 > --- a/lib/modules/Function.pmod > +++ b/lib/modules/Function.pmod > @@ -83,7 +83,7 @@ function(mixed...:function(mixed...:mixed|void)) curry(function f) > { > return lambda(mixed ... args1) { > return lambda(mixed ... args2) { > - return f(@args1, @args2); > + return f && f(@args1, @args2); > }; > }; > } In either case, I think this ought to be documented here: http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Pike/__B…

3 8

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