Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

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

Re: werwhat? two bugs
by Mirar ＠ Pike developers forum 31 Jul '08

31 Jul '08

4 7

werwhat? two bugs
by Mirar ＠ Pike developers forum 31 Jul '08

31 Jul '08

What's going on here? | > for (int i=0; i<20; i++) werror((int)(((array(string))map(allocate(4,10000),random))*"")+"\n"); | 893854041314521p21222729747995344996322460933134167912308396922p465893192590510p409578404318720p249661099356465p9779173639706553527891623852799p763437599009880p923963626066665p195530491701805328348545865448 | 914429367511157p851488744731279p771291049428341p3407258449383175982468099614413597240422810389 Where did my linebreaks go and where did the p come from? In a sidenote, why doesn't | > random(10000000000000000); | (3) Result: 694383321 work as expected, when | > random(100000000000000000000000000000); | (2) Result: 1637481850962819326860743609 does?

4 7

Git repository bug
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 31 Jul '08

31 Jul '08

I found a bug in the git repository: git blame README-CVS gives the following output at the end: 9eb55816 (Mikael Brandström 2002-04-06 20:49:08 +0000 250) o A descripti 9eb55816 (Mikael Brandström 2002-04-06 20:49:08 +0000 251) o If you know 9eb55816 (Mikael Brandström 2002-04-06 20:49:08 +0000 252) variables a 9eb55816 (Mikael Brandström 2002-04-06 20:49:08 +0000 253) o Or, if you 9eb55816 (Mikael Brandström 2002-04-06 20:49:08 +0000 254) bugfix alon but these lines are older, and were copied from the file README. Even CVS gets the annotations correct here, because in fact the ,v file was copied: 1.9 (nilsson 16-Oct-01): o A description of what it is that bugs and when. 1.11 (jhs 15-Feb-02): o If you know how, then also give us a backtrace and dump of vital 1.10 (nilsson 05-Nov-01): variables at the point of crash. 1.11 (jhs 15-Feb-02): o Or, if you found the error and corrected it, just send us the 1.10 (nilsson 05-Nov-01): bugfix along with a description of what you did and why. (OTOH, the CVS repository will of course give you incorrect results if you check out an old version of Pike, as README-CVS will appear alongside README even before it shoud exist.)

2 5

Svn repository
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 30 Jul '08

30 Jul '08

A new Subversion conversion of the Pike repository, with better properties, is now available at svn+ssh://pike.ida.liu.se/pike/data/repos/Pike/ Please report any errors. Suggestions for even more improved properties are also welcome.

1 0

Jump to page:

2026

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