Pike-devel

pike-devel@lists.lysator.liu.se

3044 discussions

tan(pi/2)
by Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum 29 Nov '04

29 Nov '04

Pike v7.6 release 24 running Hilfe v3.5 (Incremental Pike Frontend) > atan(tan(1.0)); (1) Result: 1.000000 > atan(tan(Math.pi/2)); (2) Result: -1.570796 > tan(Math.pi/2); (3) Result: -22877332.000000 Wazzaaa?

5 6

#'symbol, string[x..<y] - LPC compatibility (update)
by lynX＠eat.pike.pages.de 27 Nov '04

27 Nov '04

(misdirected to pike(a)roxen.com .. updated version) hi there pikers.. we're currently in the process of making the lpc code of the psyc muve server executable for both lpc and pike drivers. that is we're making a hybrid language with a stack of #define macros which compile to the respective syntaxes. there is one thing that however cannot be solved with current pike compilers. lpc has a syntax for runtime generated bytecode lambdas (something pike doesn't provide by the way.. so what), which use a syntax that goes #'symbol. all we hope for is to be able to keep this stuff in an #ifdef LPC, but that doesn't work currently. martin nilsson has submitted a cvs patch which tells the preprocessor.h to ignore unknown #' when in !OUTP(). that looks good and works fine, but a new problem is produced by the ' in #': the lexer will additionally want to see a closing tick for an apparent char definition. that can be circumvented by appending a //' to the line, as in input_to(#'bla); //' it will be a mess of circumventions in our code if we keep it like this, so i tried to change the behaviour. unfortunately the tick gobbler is deep in calcC() and i would have to pass the flags variable all the way down the chain of calcN() functions. any suggestions for this one? i was surprised the preprocessor is parsing the ifdef'd out code at all, it could run ahead looking for the next ^(\s*)#e(lse|ndif) and thus improve compilation time. then tobij pointed out that multiline string syntaxes like #" and "\ could theoretically mask an #endif in a string definition. ugh. the other issue i was trying to address today is to support the LPC syntax for ranges "from behind": string[2..<2]. looks like i would have to add a new opt_int_relative_range to the basic_type definition in language.yacc, then copy the code for opt_int_range with maybe a negated 2nd argument and then handle the case when the string is at our hands. funny problem is, i couldn't find the code where the interpreter actually applies the range to the string. can anyone give me a hint where that happens? the virtues of [x..-y] and [x..<y] syntaxes have been discussed before, so i'll simply presume the majority supports the string[2..<2] plan. i just realized however, that it doesn't stop at that.. i would have to add all variants of [..<] [<..] and [<..<] to the grammar with or without arguments. maybe a bunch of define macros in our code are less work then.. ;-( sorry for rushing in and going straight for the language core.. but that's what we need -- symlynX » psyc://lynX@symlynX.com » irc://ve.symlynX.com/#PSYC xmpp:#PSYC@ve.symlynX.com » https://ve.symlynX.com:34443/LynX/ network chat technology since 1988 » http://psyc.pages.de

14 53

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

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