Pike-devel November 2004

pike-devel@lists.lysator.liu.se

11 participants
36 discussions

string_to_utf8() behavior on non-wide strings
by Alexander Demenshin 23 Nov '04

23 Nov '04

Hi, What should be the correct behavior of string_to_utf8() in case if source string is not wide-string? Currently it just converts all 8-bit values to UTF-8 representation, which is not (really) Right Thing (tm) - imagine UTF-8 string passed on... It will be scrambled... Yes, I know, no one would do this intentionally, but "to err is human" - one live example is SQLite module, where this conversion is performed by default, and UTF-8 string may (and eventually will) be passed to SQLite, will be scrambled, and... :) May be it makes sense to do nothing (return source string) in case if source is 8-bit string? Or (at least) check that source is valid UTF-8 stream (I wouldn't choose this way, though)? Regards, /Al

13 114

Strange sscanf() behaviour
by Marcus Agehall (PacketFront) ＠ Pike (-) developers forum 23 Nov '04

23 Nov '04

> array_sscanf("foo - bar 1", "%s%d"); (1) Result: ({ /* 1 element */ "foo " }) That doesn't look right to me. Shouldn't sscanf() check that it's an actual number, not just assume that the '-' signals a new, negative number?

2 1

Stdio.FakeFile
by Marcus Agehall (PacketFront) ＠ Pike (-) developers forum 19 Nov '04

19 Nov '04

I have noticed that Stdio.FakeFile tends to use the error() function a lot. This isn't necessarily bad, but when it throws an error instead of just quietly accepting things like Stdio.File does, it may become a problem. For example, closing a Stdio.File object multiple times does not cause an error. close() just returns 1 each time since the result is that the file is/remains closed. Stdio.FakeFile on the other hand, throws an error if a closed file is closed again. Too me this seems very inconsistent. I don't know if it's Stdio.File or Stdio.FakeFile that has the "wrong" semantics, but I'm willing to bet that it's not Stdio.File... Since Stdio.FakeFile sais it's supposed to mimic a Stdio.File object, I suggest we wipe out these inconsistencies by changing Stdio.FakeFile. Before I start doing this, are there any known things that depend on errors being thrown from Stdio.FakeFile?

2 1

Suggestion to make Pike 7.6.24 run on W9x again
by Axel Siebert 18 Nov '04

18 Nov '04

The function low_stat in fdlib.c uses a sequence of FileTimeToSystemTime, SystemTimeToTzSpecificLocalTime and the obscure function __loctotime_t to convert FILETIME to time_t. Not only is this unnecessarily complex, it completely breaks Pike on W9x - SystemTimeToTzSpecificLocalTime is not supported and always returns FALSE, so low_stat always fails and Pike refuses to find any modules. The following calculation achieves the same result and makes Pike work on W9x again (example for ftLastWriteTime): buf->st_mtime = (time_t)((((INT64)findbuf.ftLastWriteTime.dwHighDateTime << 32) + findbuf.ftLastWriteTime.dwLowDateTime - 116444736000000000) / 10000000); Reference: http://msdn.microsoft.com/library/en-us/sysinfo/base/converting_a_time_t_va… Please consider implementing this change, as I'd really like to use Pike on a W9x system. Regards, Axel

7 16

-x module
by Kaos 17 Nov '04

17 Nov '04

Using pike 7.6.25. I noticed that when i have module.pmod.in/module.pmod, I can't use the @module@ tag since the resulting .so-file is in the parent directory, so the typical "inherit .___Lua;" fails, since there's no such .so to load in the same dir. Not sure where/how to fix this. For now, I don't use @module@, but spell the entire path ( Public.Lang.___Lua ).

3 13

Re: Suggestion to make Pike 7.6.24 run on W9x again
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 15 Nov '04

15 Nov '04

Regarding the last question, I just realized that it can't be so, since the CRT version would make a double compensation then.

4 16

array[*] | array[*]
by Kaos 15 Nov '04

15 Nov '04

Hi, I found out that I can do: > array a = ({ 1, 2, 3 }); > array b = ({ 4, 5, 6 }); > a[*] | b[*]; (1) Result: ({ /* 3 elements */ 5, 7, 7 }) But not: > array c = ({ 3, 0, 2 }); > c[*] || a[*]; Compiler Error: 1:[*] not supported here. Compiler Error: 1:[*] not supported here. > Any hints on where to go patch to make the above work? (expected result: ({ 3, 2, 2 }) ) When is this usefull? For example when I have an array containing the arguments for some function call (or object creation) and get another array with some values to override. //K

3 4

Mysterious segfault...
by Alexander Demenshin 14 Nov '04

14 Nov '04

Hi, I am a little bit tired trying to find out what is going on --with-rtldebug, since there is no debug info available at all, may be someone has a clue... My build: http://pike.ida.liu.se/development/pikefarm/result.xml?id=507_103&pike=7_7 When I try to analyze core with gdb: --snip-- aldem@troll:~/src/pike/cvs/Pike-v7.7-snapshot/build/linux-2.6.8-24.3-smp-i686/post_modules/Shuffler> gdb ../../pike core GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by /home/aldem/src/pike/cvs/Pike-v7.7-snapshot/build/linux-2.6.8-24.3-smp-i686/pik'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/librt.so.1...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 eval_instruction_without_debug (pc=Cannot access memory at address 0x8 ) at interpreter.h:119 119 instr = pc[0]; (gdb) bt #0 eval_instruction_without_debug (pc=Cannot access memory at address 0x8 ) at interpreter.h:119 Cannot access memory at address 0x4 (gdb) --snip-- When I run same command from gdb, exactly same problem (no stack info). Attempt to use valgrind gives: ==24227== Invalid read of size 4 ==24227== at 0x8094F03: eval_instruction_without_debug (interpreter.h:119) ==24227== Address 0x8 is not stack'd, malloc'd or (recently) free'd ...and that's all... No stack info... I am lost... :( Any clues? This is long standing problem and I've no idea what it might be, especially taking into account that 7.6 has no problems... Or should I simply cut it out (rtldebug) and forget about this problem? :) Regards, /Al

5 20

Informix SQL driver for Pike?
by Alexander Demenshin 14 Nov '04

14 Nov '04

Hi, Is there anyone who is working on this? Or has any plans to implement one? I am asking because I am going to make my own unless there is something ready to use (bugs are OK - they could be fixed). NB: I found on some (very old) Roxen docs that "Informix is supported via native driver", but I couldn't find any traces of this driver anywhere... Perhaps this was a mistake... Or joke :) Regards, /Al

2 1

Re: Slackware packages of 7.6.24
by David Gourdelier 12 Nov '04

12 Nov '04

Alexander Demenshin wrote: > On Thu, Nov 11, 2004 at 01:53:41PM -0600, lance dillon wrote: > > >>person is really that performance-needy, then they need to go to a >>regular compiled language. > > > Well, the advantage of scripting language is that all you do you > can test almost instantly - but this is not a real problem nowadays, > since compilation times are quite short. The reason why I use > Pike is not because it is scripting language, only because it is > _nice_ (both features and syntax). In case if it would be compiled > language, I would still use it (instead of C). > > >>It seems to me that the language is plenty fast for the features it >>provides. > > > Depends what you do... And how often... I wouldn't write anything > which needs a lot of CPU in Pike, unless I've enough CPU power... > > Perl was (once) good too, but when I look at SpamAssassin, I am going > crazy... This is an example of what shouldn't be done in languages like > Perl, and (I believe) this shouldn't be done in Pike too. What is special in SpamAssassin except in Perl thus unreadable by design? >>creating a new vm. The problem is that java is not dynamic, it is >>static. > > > It depends on your goal. I don't use dynamic types, mostly, I only need it > _sometimes_, so features provied by languages like C++ or D or C# (I don't > use Java) are more than enough - I just use "variant" type or something > like that. > > >>a c char array. The jvm doesn't allow dynamic code, for example, using >>eval (or compile_string and others under pike). > > > Why not? Invoke java compiler, compile your code, load it - and that's > all. You can even make a simple wrapper, call it "eval" and use it. > The same applies to any (compiled) language - including C/C++. You can > argue that this is not "native" - well, the difference is that (in case > of Pike) you always have compiler (so you can use compile()), in case > of any other language you have to have it installed, but this is not > really important difference, IMHO. > > The (some) advantages of VM (whatever it is) are: > > 1) Reduce (or eliminate) compile time > 2) Reduce run-time > 3) Make possible to distribute precompiled binaries That would be a big advantage for Pike for people who want to do commercial softwares. There is the dump of modules which allow you to avoid distributing the source code for Pike modules but it does it only for Pike modules. >>Hash table lookups are almost always O(1). However, dependent on the >>size of the hash table. > > > Exactly - dependent on size. And - it takes more than pre-computed > index (offset). I strongly believe that any unnecessary operations > must be avoided whenever possible, and index (method) lookup during > run-time is unnecessary in most cases (predicting that someone may > argue this statement: in most cases where _I_ use Pike, at least). > > BTW isn't the fact that every strings are hashed and put in table make that Pike is slow when it's eating lot of memory (like 1GB) ? / David

8 12

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 November 2004