Pike-devel November 2004

pike-devel@lists.lysator.liu.se

11 participants
34 discussions

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

3 2

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

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

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