Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

SQL
by Bill Welliver 22 Dec '03

22 Dec '03

I started working on an interface to the SQLite database engine (www.sqlite.org) today. The preliminary results are promising, but I'm now at the point where I should decide what direction to take the work. My initial thought is that this should be handled in the same manner as the other database interfaces. I'm not sure how well some of the interface design aspects will fit with the SQLite view of things, though. I was wondering if anyone can give me an idea of what I need to impliment in order to have it accessible through Sql.sql. Bill

7 10

More conference items: book and mailing list
by Bill Welliver 21 Dec '03

21 Dec '03

Hi All, [apologies in advance for the cross-posting, i wasn't sure of the coverage on both lists] I've been going through some of the items from the conference, and I thought I'd take a little initiative. To that end, here's an update: 1. A pike book I've decided to start work on Pike book. My target is somewhere between the tutorial and the source code or modref. That is, a relatively complete reference to the most important parts of the language such as constructs and important features, but not a function reference (important functions such as Stdio and the like will be covered). My plan is to assume basic programming knowledge that isn't necessarily assumed in the current tutorial online. I've gotten a good bit of feedback regarding what's missing, from programming savvy individuals that have tried to pick up pike. I've placed a first crack at a table of contents here: http://hww3.riverweb.com/dist/PikeManual.txt Any and all feedback would be greatly appreciated (additions, deletions, reorganizations, etc) Also, unrelated to this effort, I was wondering who owned the copyright on the current tutorial... does anyone know? I was thinking of getting a few copies of this material printed and bound, but don't want to end up with a lawyer at my door. If there's interest from anyone out there, please let me know. 2. The pike(a)roxen.com mailing list archive As part of my research into topic #1 above, I got thinking that there's a large amount of good information locked away in the mailing list archives. Unfortunately, the only way to get at it right now is to use the mailing list archive server, which is relatively inconvenient. In order to remedy this situation, I've put a very simple, searchable archive online here: http://modules.gotpike.org:8000/list/ It's not fulltext search (my mysql is apparently not happy about doing fulltext), but it does use substring searching, so it's at least as good as a simple grep. It will probably move to a more suitable location in the future. Thanks to Martin Bahr for the archive mailbox, going back 7 years. As always, comments and feedback are welcome... Bill

7 10

How to dump pike modules in a fakeroot/sandbox environment?
by Rainer Groesslinger 21 Dec '03

21 Dec '03

Martin Stjernholm, Roxen IS wrote: > If the files aren't moved to another location, how can it become a > problem that the pike binary wants to load > [/my/fakeroot/path]/lib/master.pike? I am sorry I misunderstood you there. Of course they are moved from the virtual /usr (= /fakeroot/usr) to the real /usr after 'make INSTALLARGS="--traditional" buildroot="/fakeroot" install' completed. (Before that, I use make CONFIGUREARGS="--prefix=/usr --disable-make_conf \ --with-relocatable-dumped-modules") As you suggested I looked at PIKE_MODULE_RELOC and I also found out about the configure param called "--with-relocatable-dumped-modules" but it doesn't seem to change anything :( I still have the problem that pike is being built in a working directory, then installed to /fakeroot/usr (given /usr as the --prefix and /fakeroot as the buildroot) and after that process is complete, it is moved to the real /usr/... Even if I try to set PIKE_MODULE_RELOC (or use --with-relocatable-dumped-modules) some modules still look in /fakeroot/usr/... (some work, but Regex doesn't and if I run e.g. 'pike --features' also Yp among a few others give me a decode warning referencing to /fakeroot/usr/...) Perhaps I missed something or I am using --with-relocatable-dumped-modules the wrong way ? -- Rainer Groesslinger <rainer.groesslinger(a)gmx.net>

3 5

C#-like properties
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 21 Dec '03

21 Dec '03

And in case it helps jog your memory, the intended application that time was to implement classes which behaved just like builtin types, like strings. Maybe it was related to the discussion on "secure strings", I don't remember exactly.

1 0

Re: SQL
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 21 Dec '03

21 Dec '03

Just testing against (<"Sql","sql","sql_util","module">) should be ok (and much faster). / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-12-20 15:54: >Subject: Re: SQL >-------------------------------------------------------------------- >That makes sense, but would anyone be opposed to me making the >constraint more specific? Alternately, is there any opinion about >possibly making some changes to allow others to add SQL database >support without having to add it to the core? Perhaps Sql.providers.* ? > >Bill > >On Saturday, December 20, 2003, at 09:25 AM, Johan Sundström (achtung >xmas!) @ Pike (-) developers forum wrote: > >> Most probably so, but we kind of know the ones with [Ss]ql prefixes to >> be a non-growing static collection, unlike the *_result classes. :-) >> >> / Johan Sundström (achtung xmas!) >> >> Previous text: >>> 2003-12-20 14:02: >>> Subject: Re: SQL >>> -------------------------------------------------------------------- >>> I think the constraint is there to prevent you from instantating the >>> things in Sql which _aren't_ protocols, which tend to have names >>> starting with "sql": >>> >>>> indices(Sql); >>> (1) Result: ({ /* 15 elements */ >>> "sybase", >>> "msql", >>> "postgres", >>> "sql_result", >>> "mysql", >>> "sql_util", <-- this one >>> "odbc", >>> "sql", <-- this one >>> "Sql", <-- and this one >>> "rsql", >>> "module", <-- the test seems to miss this one tho >>> "postgres_result", >>> "odbc_result", >>> "oracle", >>> "mysql_result" >>> }) >>>> >>> >>> (Also, the names ending with "_result" are excempt for the same >>> reason.) >>> >>> / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >>> > > > > / Brevbäraren >

2 1

Arithmetic tests and --without-bignums
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 20 Dec '03

20 Dec '03

The function pcharp_to_svalue_inumber(), used by the compiler to parse integer literals, clamps literals to [MIN_INT_TYPE..MAX_INT_TYPE] when AUTO_BIGNUM is not defined, i.e. a literal such as e.g. 12345678912345 will typically become the literal 2147483647. Is this intentional? The testsuite does not like it: test_any([[int a=0xffffffff; return a+17]], 0x100000010); test_any([[int a=0xffffffff; return a-17]], 0xffffffee); test_any([[int a=0xffffffff; return a*17]], 0x10ffffffef); [...] test_any([[int a=0xffffffff; return a<<17]], 0x1fffffffe0000); test_any([[ int a=0xffffffff; return a/17 ]], [[ (0xffffffff == -1)?-1:0x0f0f0f0f ]]); test_any([[ int a=0xffffffff; return a%17 ]], [[ (0xffffffff == -1)?16:0 ]]); test_any([[ int a=0xffffffff; return a>>17 ]], [[ (0xffffffff == -1)?-1:0x7fff ]]); All these fail due to the clamping. In order to perform the intended tests, all the literals greater than 17 have to be written as 0xffff|(0xffff<<16), 0x10000001<<4, etc. The question is, should this clamping be performed in the first place?

3 4

Re: SQL
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 20 Dec '03

20 Dec '03

You need to rename it to something else. A database protocol is not allowed to start with the letters "sql", for some reason. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-12-19 23:36: >Subject: Re: SQL >-------------------------------------------------------------------- >ok, so what do i need to do to have sqlite be a supported "protocol"? > >I have a sqlite.pike and sqlite_result.pike in the Sql.pmod directory, >each inheriting the proper files, but still no workie... > >any thoughts? > >bill > >On Fri, 19 Dec 2003, Martin Nilsson (saturator) @ Pike (-) developers forum wrote: > >> And Sql.Sql does that for you when you call its big_query and the lower >> level has no big_query method. >> >> / Martin Nilsson (saturator) >> >> Previous text: >> >2003-12-19 21:41: >> >Subject: Re: SQL >> >-------------------------------------------------------------------- >> >>you could just fake big_query() by executing the query at once, storing >> >>it in an array inside the object returned, and then have the methods >> >>access the array. >> > >> >This is exactly what Sql.sql_result does. You can do >> > >> > Sql.sql_result(xxx->query("blah")) >> > >> >to convert a normal query result to a big_query result. >> > >> > / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >> > >> > > > > / Brevbäraren >

3 4

doc building
by Peter Bortas ＠ Pike developers forum 19 Dec '03

19 Dec '03

7.5 loops forever trying to build the documentation: /pkg/pike/src/Pike/7.5/src/intel-rh9/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pkg/pike/src/Pike/7.5/src/intel-rh9/master.pike -x extract_autodoc -q --srcdir=/pkg/pike/src/Pike/7.5/src \ --imgsrc=/pkg/pike/src/Pike/7.5/refdoc/src_images --builddir=doc_build/src \ --imgdir=doc_build/images % find . -name "intel-*" | grep src /pkg ./pike/src/Pike/7.5/src/intel-rh9 ./pike/src/Pike/7.5/src/intel-rh9/doc_build/src/intel-rh9 ./pike/src/Pike/7.5/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9 ./pike/src/Pike/7.5/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9 ./pike/src/Pike/7.5/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9 ./pike/src/Pike/7.5/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9/doc_build/src/intel-rh9 *snip* ... And it goes on and on ... Not that I care to build the documentation at all. What's the configure flag to turn it off?

1 0

Re: SQL
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 19 Dec '03

19 Dec '03

I will not find the solution for you over this 33K modem... Read Sql.pike. / Martin Nilsson (saturator) Previous text: >2003-12-19 23:36: >Subject: Re: SQL >-------------------------------------------------------------------- >ok, so what do i need to do to have sqlite be a supported "protocol"? > >I have a sqlite.pike and sqlite_result.pike in the Sql.pmod directory, >each inheriting the proper files, but still no workie... > >any thoughts? > >bill > >On Fri, 19 Dec 2003, Martin Nilsson (saturator) @ Pike (-) developers forum wrote: > >> And Sql.Sql does that for you when you call its big_query and the lower >> level has no big_query method. >> >> / Martin Nilsson (saturator) >> >> Previous text: >> >2003-12-19 21:41: >> >Subject: Re: SQL >> >-------------------------------------------------------------------- >> >>you could just fake big_query() by executing the query at once, storing >> >>it in an array inside the object returned, and then have the methods >> >>access the array. >> > >> >This is exactly what Sql.sql_result does. You can do >> > >> > Sql.sql_result(xxx->query("blah")) >> > >> >to convert a normal query result to a big_query result. >> > >> > / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >> > >> > > > > / Brevbäraren >

1 0

Re: fork()ing into background (was Pike 7.6)
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 19 Dec '03

19 Dec '03

That makes sense. Maybe there should be some provision to be able to remove defines (as well as adding new ones). / Martin Stjernholm, Roxen IS Previous text: >2003-12-19 03:43: >Subject: Re: fork()ing into background (was Pike 7.6) >-------------------------------------------------------------------- >How about arguments like module paths and defines? Should these be part >of the "environment" passed on to the newly started Pike? > >Any thoughts? > >Bill > >On Wednesday, December 17, 2003, at 07:15 PM, Martin Stjernholm, Roxen >IS @ Pike developers forum wrote: > >>> Would it be necessary to put this in master(), as that's where the >>> easiest access to agv/c would be? >> >> Some support in the master is necessary, but the function itself >> probably belongs in the Process module. There are already two >> variables _pike_file_name and _master_file_name in the master for >> this. >> >> / Martin Stjernholm, Roxen IS > > > > / Brevbäraren >

1 0

Jump to page:

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