Pike-devel December 2003

pike-devel@lists.lysator.liu.se

12 participants
52 discussions

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

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

17 Dec '03

> 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 Previous text: >2003-12-17 03:30: >Subject: Re: fork()ing into background (was Pike 7.6) >-------------------------------------------------------------------- >Yes, on SunOS 5.9 > >> Good. I think the problem with threads at startup was on e.g. Solaris. >> Did you test there? >> > >Would it be necessary to put this in master(), as that's where the >easiest access to agv/c would be? > >> It doesn't. It's useful to start new pike scripts at any time in a >> multithreaded application. fork only works at startup before any >> threads are started. >> > > > > / Brevbäraren >

1 0

Re: fork()ing into background (was Pike 7.6)
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 17 Dec '03

17 Dec '03

Did it work to start threads in the subprocess? / Henrik Grubbström (Lysator) Previous text: >2003-12-17 03:30: >Subject: Re: fork()ing into background (was Pike 7.6) >-------------------------------------------------------------------- >Yes, on SunOS 5.9 > >> Good. I think the problem with threads at startup was on e.g. Solaris. >> Did you test there? >> > >Would it be necessary to put this in master(), as that's where the >easiest access to agv/c would be? > >> It doesn't. It's useful to start new pike scripts at any time in a >> multithreaded application. fork only works at startup before any >> threads are started. >> > > > > / Brevbäraren >

2 1

Pike 7.6
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 16 Dec '03

16 Dec '03

So what are the items for the Pike 7.6 todo check list?

5 7

mcpcom
by Mirar ＠ Pike developers forum 16 Dec '03

16 Dec '03

What does mcpcom do? PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17260 xenofarm 39 19 222m 208m 7720 R 99.9 20.6 0:21.60 mcpcom ^^^^^^^^^ ^^^^

2 2

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 December 2003