Pike-devel November 2004

pike-devel@lists.lysator.liu.se

11 participants
32 discussions

Pike string hashing
by Marcus Agehall (PacketFront) ＠ Pike (-) developers forum 20 Apr '05

20 Apr '05

I'm a bit curious about the string hashing algorithm used in Pike. What algorithm is it based on and what complexities does it exhibit? Was it selected at random or is there some rationale behind it..?

3 5

MySQL big_query in 7.7
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 10 Apr '05

10 Apr '05

I think the new streaming behavior in Sql.mysql.big_query is nice and as it should be, but it's causing too much headaches in existing applications - the old de-facto behavior is too ingrained. So a proposal is to instead do like this: query: Like today - slow and memory consuming. big_query: A variant of query() that still is nonstreaming. I.e. it only avoids the very bulky response format of query(). streaming_query: Like big_query but guaranteed to stream if it exists. It's database dependent whether other queries can be issued while a streaming_query response object exists. It's of course also database dependent if there are locks on the tables in the server while the response object exists. While at it, we could also consider generalizing the big_typed_query interface that the oracle module provides: big_typed_query: Like big_query but doesn't convert everything to strings. Integers and floats are kept that way, Date/timestamps are Calendar objects, there are objects for representing the NULL value for each type. streaming_typed_query: Streaming variant of big_typed_query.

9 20

matriser
by Mirar ＠ Pike developers forum 12 Dec '04

12 Dec '04

Interesting. Then Pike is erranous: | > object A=Math.Matrix(({1,2,3,4})/2); | > object B=Math.Matrix(({5,6,7,8})/2); | > A*B; | (9) Result: Math.Matrix( ({ ({ 23, 34}), | ({ 31, 46}) }) ) (It should be: | |(9) Result: Math.Matrix( ({ ({ 19, 22}), | ({ 43, 50}) }) ) ) Any suggestion for how to fix? Will any code break if I just fix it straight off? / Mirar Previous text: >12548097 2004-11-08 21:56 /1 lines/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >Recipients: Matematik och logik >Comment to 12548086 >Subject: matriser >-------------------------------------------------------------------- >Det senare. "i:te raden * j:te kolonnen". > >(12548097) /Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)/------------- >

4 9

tan(pi/2)
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 29 Nov '04

29 Nov '04

Pike v7.6 release 13 running Hilfe v3.5 (Incremental Pike Frontend) > float a = Math.pi/2, b = 1.570796; > a; (1) Result: 1.570796 > b; (2) Result: 1.570796 > (a-b)*1000000; (3) Result: 0.357628 > sprintf("%.7f", a); (4) Result: "1.5707964" > sprintf("%.7f", b); (5) Result: "1.5707960" > As you can see, a is larger than b, but the difference is in the seventh decimal so you can't see it in the default print format. More precisely, b < Pi/2 < a. (Pi/2 = 1.5707963..., which can't be represented exactly with any floating point representation.)

2 3

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

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