Pike-devel February 2006

pike-devel@lists.lysator.liu.se

7 participants
18 discussions

Process.run
by Peter Bortas (nu med mindre Opera) ＠ Pike (-) developers forum 15 Jul '08

15 Jul '08

I just checked in a Process.run() in 7.7: http://pike.ida.liu.se/development/cvs/diff.xml?module=Pike&file=7.7/lib/mo… The rational for that is that I was once again reminded by a user this week that getting Process.create_process() or Process.Process right without some corner case blocking is hard. It's not obvious that if you bind pipes to booth stderr and stdout you have to take in to account that OS buffers are not limetless. Process.run() is a thin wrapper around Process.Process that collects stdout, stderr and exitcode and return them in a mapping. This could potentially result in huge strings, but will do what most users want and even already do when they call create_process() with both pipes bound. Something like this should be in 7.8, but I'm open to suggestions for other things that might be usefull to return in the mapping or for changing member names.

5 7

Pike 7.6
by Martin Nilsson (DivX Inc.) ＠ Pike (-) developers forum 23 Aug '06

23 Aug '06

It is time for a new release of Pike 7.6. Is there anyone who can do the release notes? If not, we'll just wait a bit longer...

9 12

sprintf %O
by Martin Nilsson (Opera) ＠ Pike (-) developers forum 20 Mar '06

20 Mar '06

While the new multiline sprintf %O looks snazzy, it will break code for everyone that uses it to ensure that a string contains no "bad" characters. Think log files, one line per entry. This needs to be reverted IMO as the effects on applications are hard to determine. For reference: Pike v7.7 release 23 running Hilfe v3.5 (Incremental Pike Frontend) > "foo\nbar"; (1) Result: "foo\n" "bar"

9 19

make doc broken
by Peter Bortas (nu med mindre Opera) ＠ Pike (-) developers forum 05 Mar '06

05 Mar '06

make doc has was broken somewhere between 7.6.66 and now. Whoever did it feel free to fix. /home/zino/hack/Pike/7.6/build/linux-2.6.12-1-686-smp-i686/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/zino/hack/Pike/7.6/build/linux-2.6.12-1-686-smp-i686/master.pike -x extract_autodoc -q --srcdir=/home/zino/hack/Pike/7.6/lib \ --imgsrc=/home/zino/hack/Pike/7.6/refdoc/src_images --builddir=doc_build/lib \ --imgdir=doc_build/images Bad argument 1 to `()(). Expected string. Unknown program: `()(743)

3 15

language.h in 7.7
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 01 Mar '06

01 Mar '06

Where is language.h supposed to be generated and why isn't it anymore? make in fresh checkout on an ubuntu machine stops at main.c as lex.h can't include language.h.

2 7

cyclic.c
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 28 Feb '06

28 Feb '06

In cyclic.c, shouldn't the thread be used to actually identify the cycle, not only as a component in the hash? Otherwise there is no use in setting th (or having) in the CYCLIC struct.

1 0

Working on new stable
by Peter Bortas (nu med mindre Opera) ＠ Pike (-) developers forum 24 Feb '06

24 Feb '06

It's time to make a new stable release. Does anyone have outstanding fixes they want included check them in by sunday so I can make a beta.

1 1

glibc-2.3.5 and threads/Process
by Hedda (www.linkmeet.com is now international) ＠ Pike (-) developers forum 21 Feb '06

21 Feb '06

(Everything is using Pike 7.6.66, but .64 has the same problem) I have a problem to get threads or Process to work properly with glibc-2.3.5 (or something related). I'm using Mandriva 2006 and Gcc-4.0.1. gcc-2.96 works just as badly. All my glibc-2.3.4 system works. /* Here is the program that hangs (after 2-6 "Ho!" and the same number of "Bar" usually, but sometimes it works) */ int xx=0; void main () { mixed a() { return allocate(10, thread_create) ( lambda() { write("Ho!\n"); for (int x=0; x<10; x++) { for (int e=0; e<50; e++) if (Process.create_process(({"/bin/cat","/dev/null"}))->wait()) return e; } write("Hej!\n"); __signal_watchdog(); return -1; } )->wait() - ({-1}); }; mixed b() { return ({}); }; a(); write("Bar\n"); b(); write(( file_stat("/bin/cat") && file_stat("/dev/null") && all_constants()->thread_create && (cpp("__NT__")/"\n")[1]=="__NT__" ) +"\n"); write("xx"+xx+"\n"); } void __signal_watchdog() { xx++; return; } /* end program */ I have tried to build Pikes on the working systems and do "make bin_export" (Even with --without-dynamic-modules), but the result is the same. But if I try the Pike built by Roxen ( http://download.roxen.com/4.0/ in the Roxen Webserver 4.0.425 Fedora Core 4 x86 package) it runs the program above without problems, but it still hangs my Roxen about 2 times a day (when it's under heavy load). "hangs" means that it uses 0 CPU and doesn't do a thing, and needs to be killed with -9. So my question is: Has anyone else got glibc-2.3.5 to work perfectly with Pike (make verify)? And then: Is this Pike's or glibc's fault? If it's glibc's fault, then I need some help to write a bug-report. I did get some related warnings while compiling Pike: /home/hedda/Pike-v7.6.66/src/dynamic_load.c: In function 'exit_dynamic_load': /home/hedda/Pike-v7.6.66/src/dynamic_load.c:647: warning: variable 'tmp' might be clobbered by 'longjmp' or 'vfork' /home/hedda/Pike-v7.6.66/src/object.c: In function 'call_destroy': /home/hedda/Pike-v7.6.66/src/object.c:677: warning: variable 'e' might be clobbered by 'longjmp' or 'vfork' /home/hedda/Pike-v7.6.66/src/program.c: In function 'store_constant': /home/hedda/Pike-v7.6.66/src/program.c:5299: warning: variable 'e' might be clobbered by 'longjmp' or 'vfork' But when I fix the warnings by using "volatile"-declarations of these variables, the above program still doesn't work, so I guess it's unrelated. Grubba had the theory: >"~ Your header-files probably don't match your thread-libraries. ~" >(14133489) /Henrik Grubbström (Lysator)/-- But that doesn't seem to be the case, as this is happening on two different systems, and they _should_ be OK. But there might of course be a Mandriva 2006-problem with its headerfiles or something.

2 1

PCRE benchmark problem?
by Adam Montague 18 Feb '06

18 Feb '06

Running "pike -x benchmark" using a fairly recent pike 7.7, I get really bad results on the "Tag removal u. Regexp.PCRE" test. So bad that I've actually never bothered to let it finish, it just sits there sucking up CPU for a long time. If I change the number of times the test is run from 2000 to 200 I can see that it actually does work, its just incredibly slow. Is this normal, or is my PCRE lib performing horribly badly for some reason? Here's what it looks like after changing n to be 200 instead of 2000 in Tools.pmod/Shoot.pmod/TagRemovePCRE.pike Tag removal u. array_sscanf 3.936s 3.135s ? (2) (96 /s) Tag removal u. division.... 3.909s 3.055s ? (2) (65 /s) Tag removal using a loop... 4.081s 3.070s ? (2) (16 /s) Tag removal u. Regexp.PCRE.161.214s 143.930s ? (1) (1 /s) Tag removal u. Parser.HTML. 5.003s 4.590s ? (1) (65 /s) Tag removal u. search...... 5.088s 4.680s ? (1) (64 /s) Tag removal using sscanf...24.450s 22.770s ? (1) (1 /s) Thanks Adam

3 2

patch to support schemas in Sql.postgres()->list_fields
by Adam Montague 15 Feb '06

15 Feb '06

This patch lets you do db->list_fields("schema.table") on Sql.postgres objects, which is needed if you have tables with the same names in different schemas. It also fixes the check for has_relexpires which wasn't using a valid SQL query. Adam

2 3

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 February 2006