Pike-devel

pike-devel@lists.lysator.liu.se

4 participants
3044 discussions

Re: More conference items: book and mailing list
by Johan Sundstr�m (achtung xmas!) ＠ Pike (-) developers forum 22 Dec '03

22 Dec '03

That sounds like a view based on the presumption that a cookbook's purpose is to teach you how to make a spoon out of a fork, and vice versa. I think a cookbook can be just as much about teching the basic workings of how to make the tools do the work for you, so people don't try to invent their own objects, mappings et cetera through arrays, strings and whatnot. Or to write C code, or Basic, in Pike. Of course it would not be a book for you, or for me, but it would still be useful to those new to the Pike mindset, as much as the other (more ambitious) book being discussed. A recipe that basically only points a newbie to how the MIME module, or Locale.Charset.(en|de)coder modules are employed to do Really Powerful Stuff, is very much better than a recipe that shows a Perl hacker how to do something similar a tenth as easily and with ten times more bugs, by hand. If eighty percent of the book was covered by the refdocs already, but in a less terse and requiring-a-working-knowledge of Pike basics (as we prefer to keep the refdocs to the point) manner, I'd still call it a very useful book indeed. / Johan Sundström (achtung xmas!) Previous text: >2003-12-22 15:42: >Subject: Re: More conference items: book and mailing list >-------------------------------------------------------------------- >I'll restate that cookbooks in general is a bad idea. If something is so >complicated to do that you need a recipie, you either should introduce a >language construct or make a module. > > / Martin Nilsson (saturator) >

1 0

Re: More conference items: book and mailing list
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 22 Dec '03

22 Dec '03

I'll restate that cookbooks in general is a bad idea. If something is so complicated to do that you need a recipie, you either should introduce a language construct or make a module. / Martin Nilsson (saturator) Previous text: >2003-12-22 13:37: >Subject: Re: More conference items: book and mailing list >-------------------------------------------------------------------- >> A book is a great idea, two would be even better. Let me explain ... >> It would be nice if the first book is a guide to pike and a programmers >> cookbook, the second book should be for advanced topics [...] > >Well, we could indeed be working on two books. :-) I, too, think a >cookbook style Pike book would be good. As a matter of fact, we have >already started a tiny bit on that project; it's in a stray repository >at the pike site in /pike/data/cvsroot/projects/cookbook/ -- borrowing >ideas from the "cookbook" series, and Python cookbook in particular. > >Uwe Assmann also liked the idea about Pike books (and especially so >the cookbook style one), so we officially have all the backing we want >and need from IDA. :-) > > / Johan Sundström (achtung xmas!) >

1 0

Re: More conference items: book and mailing list
by Johan Sundstr�m (achtung xmas!) ＠ Pike (-) developers forum 22 Dec '03

22 Dec '03

> A book is a great idea, two would be even better. Let me explain ... > It would be nice if the first book is a guide to pike and a programmers > cookbook, the second book should be for advanced topics [...] Well, we could indeed be working on two books. :-) I, too, think a cookbook style Pike book would be good. As a matter of fact, we have already started a tiny bit on that project; it's in a stray repository at the pike site in /pike/data/cvsroot/projects/cookbook/ -- borrowing ideas from the "cookbook" series, and Python cookbook in particular. Uwe Assmann also liked the idea about Pike books (and especially so the cookbook style one), so we officially have all the backing we want and need from IDA. :-) / Johan Sundström (achtung xmas!) Previous text: >2003-12-22 09:42: >Subject: Re: More conference items: book and mailing list >-------------------------------------------------------------------- >A book is a great idea, two would be even better. Let me explain ... >It would be nice if the first book is a guide to pike and a programmers >cookbook, the second book should be for advanced topics such as garbage >collectors, runtime/compile time types etc. We do not want to put people >off pike by making appear too complex and intellectual. The cookbook >aspect of the first book should explain how to use the standard modules, >the modref does not help here - if we had some place to upload some of >our code then we can all help with those modules we have experience of. > >Anyway just my thoughts >-- >Kevin Mulholland >IT & Manufacturing Systems Manager >Landis+Gyr Ltd >desk 00 44 1952 602014 >mobile 00 44 780882 5979 >-- > > > > / Brevbäraren >

1 0

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

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