Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Split me harder :-)
by Stephen R. van den Berg 12 Aug '08

12 Aug '08

Congratulations on a succesful move to 7.8. The git repositories have already been adjusted to track the new 7.8 tree. I'm in the process of setting up a tracking git on git clone git://pike-git.lysator.liu.se/pike as soon as Peter starts the ssh daemon there :-). It will be a copy of git://git.cuci.nl/pike excluding my personal branches (of course). -- Sincerely, Stephen R. van den Berg. Father's Day Special at the local clinic -- Vasectomy!

1 0

cvs build fails and where is the git repo?!
by Arne Goedeke 11 Aug '08

11 Aug '08

I was trying to build pike 7.7 from cvs and it failed when running configure for the Pipe module. There it complains that sources (interpret.c) are missing. === configuring in Pipe (/home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/modules/Pipe) configure: running /bin/sh /home/el/src/Pike/7.7/src/modules/../configure '--prefix=/usr/local' --cache-file=../.././config.cache --srcdir=/home/el/src/Pike/7.7/src/modules/Pipe configure: error: cannot find sources (interpret.c) in /home/el/src/Pike/7.7/src/modules/Pipe configure: error: /home/el/src/Pike/7.7/src/modules/../configure failed for Pipe configure: error: /home/el/src/Pike/7.7/src/modules/configure failed for modules It seems like interpret.c is the default.. however it should be overwritten by that AC_INIT(pipe.c) in configure.in, afaik. something unrelated: I have a copy of the bugless git repo that compiles but has a missing specs file. I put one there (replacing the path and such) but cannot build cmods using pike -x: ** Old style module ** Running autoconf (with extra compat macros) autoconf --include=/home/el/src/pn.git/build/linux-2.6.25-gentoo-r7-i686/bundles/include/pike configure.in:4: error: possibly undefined macro: AC_MODULE_INIT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. The module builds correctly using a pike 7.6. Also.. whats the url of a current working git repo, I got mine using rsync and cannot update because origin seems to be old/wrong. arne

8 29

resolv
by Mirar ＠ Pike developers forum 10 Aug '08

10 Aug '08

3 3

resolv
by Mirar ＠ Pike developers forum 10 Aug '08

10 Aug '08

all_constants() even. And you have to use both if you want to look for something that *can* become a constant?

1 0

eol-style properties
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 06 Aug '08

06 Aug '08

I added some logging to the subversion export script to find which files were modified by the end-of-line normalization. The complete list is currently as follows: nt-tools/init_nt nt-tools/tools/lib These are a bit special in that they use LF line terminations, but contain literal CR characters on some lines as part of shell arguments. I think it's safest to simply remove the eol-style property on these particular files, and treat them as "binary". packaging/fink/README packaging/fink/nettle.info packaging/fink/pike7.6.info The newest versions of these files in 7.6 use CRLF line terminations, but I think that is an accident, as the earlier versions did not, and neither do those which are currently in 7.7. Comments from fink people? packaging/windows/Copying.txt packaging/windows/finalizer.pike packaging/windows/nilsson-pike.iss packaging/windows/pike.iss These are used to create Windows dists, potentially from trees checked out on Unix, so CRLF eol-style is probably best here. For the ISS files it might even be required. I'll change the property. src/UnicodeData-ReadMe.txt src/UnicodeData.txt The earliest versions of the Unicode database used CRLF line terminations, but everything since Unicode 3.1.0 was imported using LF line terminations. Normalizing should be safe, but to be historically accurate I could set CRLF eol-style on those old versions. It would mainly affect 7.0 and older which still have the old Unicode versions at HEAD. src/modules/_Crypto/rijndael_cbc_d_m.txt src/modules/_Crypto/rijndael_cbc_e_m.txt src/modules/_Crypto/rijndael_ecb_d_m.txt src/modules/_Crypto/rijndael_ecb_e_m.txt src/modules/_Crypto/rijndael_ecb_iv.txt src/modules/_Crypto/rijndael_ecb_tbl.txt src/modules/_Crypto/rijndael_ecb_vk.txt src/modules/_Crypto/rijndael_ecb_vt.txt These used to have CRLF line terminations, but were explicitly changed to LF in the last day of 2001 (commit by nilsson). The file rijndaeltest.pike which uses these files has the corresponding line termination hardcoded in, so native eol-style will not work here. I'll change it to CRLF eol-style for the old versions, and LF eol-style for the newer. This only affects 7.4. src/post_modules/Nettle/byte-hashes.sha1 src/post_modules/Nettle/byte-messages.sha1 These have CRLF line terminations, but sha1test.pike which uses them strips all CR characters before processing, so either LF or CRLF terminations should work equally well. Unless someone protests, I'll keep native eol-style and perform the normalization for these files. src/post_modules/COM/examples/ads.pike src/post_modules/COM/examples/shelltest.pike src/post_modules/COM/examples/word.pike src/post_modules/COM/examples/word2.pike These have CRLF line terminations, presumably because they have been developed on Windows. Since they are pike scripts, the line termination chosen will not affect their function. So the question is whether there is a compelling reason to have CRLF terminations in these particular files even when checked out on Unix. Comments?

4 12

Re: SQLite glue segfault in 7.7
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 04 Aug '08

04 Aug '08

> Not sure how you define "new"... I don't believe it's been available > before 7.7. I never looked at it because I have my own, but figured > it might be worthwhile to start using the one bundled. A bit late reply, but anyway: If SQLite is new in 7.7 I definitely think this should be fixed.

4 4

mapping.c, PIKE_MAPPING_KEYPAIR_LOOP, Broken code below?
by Stephen R. van den Berg 04 Aug '08

04 Aug '08

In src/mapping.c: #ifdef PIKE_MAPPING_KEYPAIR_LOOP #error Broken code below! #define GC_RECURSE(M, MD, REC_KEYPAIR, TYPE, IND_TYPES, VAL_TYPES) do { Which apparently is compiled in under some circumstances, and avoided under other circumstances. What's the deal with that piece of code? -- Sincerely, Stephen R. van den Berg. The ultimate Darwin Award winner: Going first in a Russian roulette game with a normal gun (no revolver).

3 2

postgres.pike documentation, can someone give me a hint?
by Stephen R. van den Berg 02 Aug '08

02 Aug '08

I tried do make postgres.pike do a fallback to the pgsql driver, but apparently this doesn't go down well with the documentation generator. I'm not quite sure what the best fix is. Can/should the initial doc blob be moved below the first #ifdef? -- Sincerely, Stephen R. van den Berg. Every successful person has had failures but repeated failure is no guarantee of eventual success.

2 1

'if' with failing 'else' block
by Arjan van Staalduijnen 01 Aug '08

01 Aug '08

This morning I've been busy tracking a bug in my code, for which I have no explanation as to why it is a bug. The situation is I have an if-else test where, in case of a match, the if-block gets executed, but in case of a non-match, the else-block does NOT get executed. If I turn the whole test around by adding a NOT to the test, and swapping the if and else blocks, everything works. This is the code which has the bug: string key_name = "IssueID_shortname"; array qresult = myDB->Query("SHOW keys FROM dbFinalPublicationPassive.tbIssueDetails"); if (qresult && has_value(qresult->Key_name || ({}), key_name)) do_log("Index %O was already set", key_name); else { do_log("Adding index %O", key_name); myDB->Query("ALTER TABLE dbFinalPublicationPassive.tbIssueDetails" " ADD INDEX IssueID_shortname (IssueID, ShortName)"); } This code does not have the bug: string key_name = "IssueID_shortname"; array qresult = myDB->Query("SHOW keys FROM dbFinalPublicationPassive.tbIssueDetails"); if (!(qresult && has_value(qresult->Key_name || ({}), key_name))) { do_log("Adding index %O", key_name); myDB->Query("ALTER TABLE dbFinalPublicationPassive.tbIssueDetails" " ADD INDEX IssueID_shortname (IssueID, ShortName)"); } else do_log("Index %O was already set", key_name); Anyone has a clue? (Pike 7.4.464) Regards, Arjan __________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

5 7

file_peek() minimum delay set to 1 millisecond
by Stephen R. van den Berg 31 Jul '08

31 Jul '08

In the poll() branch, files/file.c:file_peek() raises the minimum poll time from zero to one millisecond. This is wreaking havoc on poll-performance. Is there any reason to do so? I.e. I was trying to refactor _PGsql and downsize it is much as possible, i.e. trying to use Pike native modules instead of direct system calls, and it seems to work rather nicely, except for this poll-mess. I.e. I could take out the special poll code, if the standard files/file.c module would not introduce that extra delay. This is what we're talking about: diff --git a/src/modules/files/file.c b/src/modules/files/file.c index 6daf5c3..642f951 100644 --- a/src/modules/files/file.c +++ b/src/modules/files/file.c @@ -844,14 +844,20 @@ static void file_peek(INT32 args) struct pollfd fds; int timeout; timeout = (int)(tf*1000); /* ignore overflow for now */ +#if 0 if (!timeout) timeout = 1; +#endif fds.fd=FD; fds.events=POLLIN; fds.revents=0; - THREADS_ALLOW(); - ret=poll(&fds, 1, timeout); - THREADS_DISALLOW(); + if(timeout) { + THREADS_ALLOW(); + ret=poll(&fds, 1, timeout); + THREADS_DISALLOW(); + } + else + ret=poll(&fds, 1, 0); if(ret < 0) { It's a 40% speed difference caused by extra latency in the pgsql driver case. -- Sincerely, Stephen R. van den Berg. "Very funny, Mr. Scott. Now beam down my clothes!"

9 114

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