Pike-devel June 2007

pike-devel@lists.lysator.liu.se

5 participants
18 discussions

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

14 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

Snapshot tarballs and packaging/debian
by Magnus Holmgren, FR Ryd (Nu med m�l och syfte) ＠ Pike (-) developers forum 03 Oct '07

03 Oct '07

I have a few questions relating to pike in Debian (as you may know, the previous maintainer has retired from Debian and orphaned his packages). I've figured out that one can get a fresh tarball from http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest. What's the difference between that and checking out from CVS and running "make source" (which is what I suspect Marek has done), if any? Is there any archive of such tarballs except for the official releases? How did the packaging/debian subdirectory originally come to be? Do you synchronize with the Debian package yourself or has Marek been sending you patches? I see that export.pike adds new records to packaging/debian/changelog. AFAICT, export.pike --tag first increments the build number (to an even number, typically), then tags, then increment the build number again, so that an even build number represents a known state of the source, whereas an odd build number can include any number of commits inbetween.

17 129

packaging/debian/changelog
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 06 Aug '07

06 Aug '07

Saw that the automatically generated entries in this file still says Marek is making them.

4 7

7.6.116 alpha
by Peter Bortas ＠ Pike developers forum 06 Aug '07

06 Aug '07

http://pike.ida.liu.se/pub/pike/beta/7.6.116/Pike-v7.6.116.tar.gz http://pike.ida.liu.se/pub/pike/beta/7.6.116/Pike-v7.6.116.1-win32.exe Completely untested. I haven't tried even to start the pike on any OS. Changes since Pike 7.6.112 ---------------------------------------------------------------------- Changes in Pike: o Fixed infinite loop that could occur when feeding Image.XBM with malformed data. o Added option "file" to Image.PS.decode(). o Image.PS.decode() now reads nonblocking from the pipes. o Added "Regexp.PCRE.Widestring" to the feature list. o Added more methods to enable the buggy unicode decode support in Mysql.mysql: * "broken-unicode" as charset to create() or set_charset(). * set_unicode_decode_mode (-1). Note that all this only applies when compiling with a mysql client lib older than 4.1.0. Otherwise these methods are aliases to enabling the normal unicode decode support. This means that no code using broken-unicode should rely on the BINARY flag on text fields to avoid utf-8 decoding. Build fixes: o Mird: Renamed FDATASYNC() to MIRD_FDATASYNC() to avoid clash with NetBSD header-files.

2 3

error: `LIBS' was not set in the previous run
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 30 Jul '07

30 Jul '07

Has anyone else seen this problem? When building current 7.7 from scratch, it bombs out during the configuration of CommonLog: configure: loading cache ../.././config.cache configure: error: `LIBS' was not set in the previous run configure: error: changes in the environment can compromise the build In config.cache there is the following: ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= (these are the only ac_env/ac_cv_env entries). Maybe this is related to the line LIBS= in PIKE_RETAIN_VARIABLES somehow? Interestingly enough, the problem does not occur on my PS3, which also has ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= in config.cache...

3 8

Conference
by H. William Welliver III 27 Jun '07

27 Jun '07

I take it that the folks who showed interest in hosting the next conference weren't able to make things work. Is anyone else interested in holding a session this fall? Perhaps in mid-to-late september? As martin has indicated, we don't really need much space, a conference room with wifi is about all we'd need. Alternately, if nothing formal materializes, I'm thinking of making the voyage to Europe again this fall and might be able to get together to discuss projects and ideas. Anyone else at Roxen-Netherlands interested in hosting something? I didn't want to post this to the main list until there was at least someone else who felt it a good idea. Thoughts/comments? Bill

4 7

strange error
by Martin Baehr 26 Jun '07

26 Jun '07

this one is puzzling: > mixed fun = lambda(){ return 1; }; > fun[""]; Bad argument 1 to Gmp.mpz(). Expected int|float|Gmp.mpz|Gmp.mpf|Gmp.mpq. Unknown program: Gmp.mpz(HilfeInput()->__lambda_66024_0_line_1) canthat be made to print Indexing on illegal type. instead? greetings, martin.

4 6

xenofarm problems
by Martin Bähr 19 Jun '07

19 Jun '07

hi, i noticed some issues with some pikefarm tests never completing. since i was not sure which tests are useful, i started with all of them, and i find that feature, static and thorough in particular sometimes have issues i have one that is currently stuck in pike 7.6 static, but on a previous build it did not get stuck there (from what i remember) i tried to set a lower cpu time, but that made no difference. the test is now running for more than two days, and it seems to do nothing. in other cases i had a test stuck at using the full cpu load for hours (that probably got stopped now with the lower cpu limit) for pikefarm now i wonder, are these tests even still useful? i don't see anyone else running any of feature, static or thorough. are these not relevant anymore? should other tests be run instead? (i added a doc build test which i found useful already) for xenofarm in general, is there a way to limit the time a test runs? (abort if it is running to long?) greetings, martin.

3 2

Unicode.normalize bug? (was: Convert string to ASCII)
by Martin Bähr 19 Jun '07

19 Jun '07

On Mon, Nov 06, 2006 at 03:22:11PM +0100, Henrik Grubbström wrote: > >(string)filter((array)Unicode.normalize("Å i åa ä e ö.", "DK"), `<, 256); > (1) Result: "A i aa a e o." i get: > (string)filter((array)Unicode.normalize("Å i åa ä e ö.", "DK"), `<, 256); (3) Result: "A i A\245a A\244 e A\266." > (string)filter((array)Unicode.normalize("Å i åa ä e ö.", "DK"), `<, 127); (4) Result: "A i Aa A e A." (tested both 7.7.34 and 7.6.93) is it pike or my terminal? greetings, martin.

4 4

browsing docs in hilfe
by Martin Bähr 19 Jun '07

19 Jun '07

hi, pike documentation now at your fingertips! please take a look at the new doc command in hilfe. it is far from perfect, but i hope it is usable. one flaw that needs fixing is the ability to look at docs from class members without instantiating the class. currently an actual function reference is needed. if you find other issues, please let me know. i am not sure how much overhead the added cache_source() will create. but i hope it is acceptable. actual parsing of docs will only happen when the show_doc() function is used, and then only one class at a time, which should be fast enough for interactive use. the big thing that is missing is of course the docs from the c code. i am not yet sure how to handle those, but i think the best option would be to create a compact version of plaintext docs or possibly encode the AutoDoc objects into files, while pike is being compiled. these files could then be distributed with pike as "runtime docs" formatting of the output might also be improved. right now the docs are displayed as is. for the most part this is readable enough, but so far i have only looked at a few examples. greetings, martin.

10 44

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 June 2007