Pike-devel October 2004

pike-devel@lists.lysator.liu.se

12 participants
49 discussions

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

#'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

-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

Unicode escapes
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 Oct '04

31 Oct '04

I'm thinking of adding an escape mechanism to be able to format wide strings a bit better. Right now there's the choice between sprintf %s which just let wide chars straight through, and %O which quotes them along with all other control chars. Neither is really good if you want to e.g. print a string to stdout which possibly can contain some wide chars. For that I'd like to add a %S that only quotes wide chars in some way. The question is what quoting method to use. Java and many other languages has one with "\u" which always is followed by four hexadecimal digits. (Java doesn't say anything about chars wider than 16 bits, but I guess it's "\U" followed by eight hexadecimal digits, as in some generic Unicode technical papers.) Java also specifies a way to keep it unambiguous: If a string already contains a sequence like "\u4711" it's quoted by inserting another "u", i.e. it becomes "\uu4711". The \u and \U scheme is better than the \4711 and \x9c9 escapes that Pike uses in strings since there's no ambiguity where the escape sequence ends (%O uses tricks like "\4322""33" to cope with them but that doesn't work very well in strings without quotes around them). The ad-hoc quoting scheme "<nnnnn>" used in some places in describe_svalue would also be replaced by this for consistency.

1 0

Re: string[x..<y]
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 30 Oct '04

30 Oct '04

I mean a[<-1..] of course; a[sizeof(a)..] is represented easily.

1 0

free_program
by Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum 30 Oct '04

30 Oct '04

Where is the code for really_free_program?

1 1

Re: string[x..<y]
by Mirar ＠ Pike developers forum 30 Oct '04

30 Oct '04

(This will of course completely destroy the case where you want to use the end-operator with another type then int, but meh...)

1 0

Re: string[x..<y]
by Mirar ＠ Pike developers forum 30 Oct '04

30 Oct '04

Note the difference to this: arr[ ..< 1] == arr[ ..sizeof(arr)-2] arr[ ..< 0] == arr[ ..sizeof(arr)-1] arr[ ..<-1] == arr[ ..sizeof(arr)+0] arr[ ..<-2] == arr[ ..sizeof(arr)+1] On the other hand, I don't think it matters much as long as it's defined. But to be consistent with arr[-1] the first one might be a tad better.

2 1

Re: string[x..<y]
by Mirar ＠ Pike developers forum 30 Oct '04

30 Oct '04

(I send in my comments too quick...) On the *third* hand, I think stop using negative indexing to mean the end of arrays would be even better, and if arr[<x] simply means reverse(arr)[x], it's absolutely even better and seems very consistant with everything.

1 0

Re: string[x..<y]
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 30 Oct '04

30 Oct '04

Sorry, I didn't mean to ignore Nilssons Int.inf class, but I was referring to a real bignum Int.inf there.

1 0

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