Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Re: Language comparisions
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 03 Sep '03

03 Sep '03

This is how you implement zip using zipWith in Haskell: Prelude> zipWith (\a b -> (a,b)) [1,3,5,7] [2,4,6,8] [(1,2),(3,4),(5,6),(7,8)] Prelude> (Actually, zip is defined as zip = zipWith (\a b -> (a,b)) which works due to curryficiation.)

1 0

[Conference] Accomodation
by Bertrand LUPART 02 Sep '03

02 Sep '03

Hey all, We didn't had all the answers we expected from Paderborn or german people about the youth hotel yet, but we think it's time for booking now. We are looking forward sleeping at the "Heiersburg" youth hotel located in Paderborn (http://www.jugendherberge.de/jh/paderborn/) - it's about 30 minutes walk from the conference place - it's cheap (17.5 EUR / night) - it could be nice to be many at the same place - it looks nice - it's not easy for non-native german people to look for accomodations in Paderborn :) So, here are the booking i'll do tonight at 23h00 (GMT+2), please correct me if wrong, and contact me if you want to get a room there too: * The hardcore Pike and Caudium conferencers, from the 25 to the 29 september (4 nights - arrival at Paderborn the 25 in the morning): - bill (Bill WELLIVER) - vida (David GOURDELIER) * The Caudium-only conferencers (ie the unlucky ones), from the 26 to the 29 september (3 nights - arrival at Paderborn the 26 late in the evening): - bertrand (Bertrand LUPART) - daffy (Olivier WARIN) - grendel (Marek HABERSACK) - kiwi (Xavier BEAUDOUIN) Not sure to come, yet: - barbiche (Frédéric RENAULT) - benoit (Benoit PLESSIS) -- Bertrand LUPART Linkeo.com - R&D | http://www.linkeo.com/ +33 1 72 71 71 82 | 17, rue de la Banque - F75002 Paris Systèmes de gestion d'email entrant | Email management systems

1 0

Gentoo Linux ebuilds for pike-7.4.20 available
by Rainer Groesslinger 01 Sep '03

01 Sep '03

Hello guys, first, I am new to the list, just subscribed some hours ago. Well, I am also new to pike, I heard of pike for the first time yesterday but I have to admit that it looks really promising and I'll have a closer look at it ;) I have committed an ebuild for pike-7.4.20 to gentoo's portage tree. Gentoo users can install it just like every other ebuild, too. For reference, you can also take a look at it using our viewcvs: http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/pike/ This is the initial commit of a pike ebuild so I'd be warmly interested in every sucess and failure story regarding the ebuild ;-) With your feedback I hope to steadily improve the pike ebuilds and get it into the stable tree quite soon. -- Rainer Groesslinger http://dev.gentoo.org/~scandium/

7 21

Gentoo Linux ebuilds for pike-7.4.20 available
by Johan Sundstr�m (p� s�ljakt) ＠ Pike (-) developers forum 31 Aug '03

31 Aug '03

http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/pike/pike-7.4.20.ebuild?…

1 0

Problems with Backtrace
by kaylus ＠ Pike developers forum 29 Aug '03

29 Aug '03

Pardon my ignorance, but here it goes. I am at the moment writing a general LPC-type server in Pike, mainly for my own amusement, and have run into a problem. First let me give a rundown. I'm sorry if it's long-winded, I like to put all the information out so I don't confuse with my incorrect jargon and don't miss anything important. The server sets up all the constants (located in inherited file) binds to a port and listens. Once a connection attempt is found it sends it to a socket class. The socket class then attempts to clone the player object, (compiles the program pointed to by a #define) and calls the logon() in the compiled object. The server itself, handling connections, cloning of objects, and basically everything works just fine. An LPC-alike clone mud can be built. I have a constant: add_constant("this_user", function_object(backtrace()[-2]->fun)); Which works wonderfully enough while it is inside the player program. My problem: I have a "bin" system for the player commands. It matches the input, searches for an object compiled under that name (i.e. /lib/cmds/who.p when they type who), compiling if not, then calls the do_cmd() function within it. If the this_user() constant is called from within the called command function it returns 0. A backtrace returns an array of 3 Zeroes. The "function_object(backtrace()[-2]->fun)" works fine within it, only the constant has a problem. Currently I am circumventing this by using a #define for the backtrace, but it is rather annoying and unsightly. I was wondering if there was some other way of doing this, or if I was doing something hideously wrong. At least some way of hitting the backtrace info from within such an above example, I can always set checking to make sure it's hitting the right backtrace entry, just need the info first *grin*. Kaylus p.s. Sorry if this was somewhat lengthy, pointless, blather that is hard to read. It's 2am and i've been trying to figure it out for quite some time. Please ignore slight errors in the message!

3 8

Compile-error CASE_INFO_SHIFT0_HIGH
by Martin Baehr 27 Aug '03

27 Aug '03

when trying to compile the released 7.4.20 pike source on a mandrake system, i get the following error: system info: Mandrake Linux release 9.0 (dolphin) for i586 gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) libc.so.6 -> libc-2.2.5.so libpthread.so.0 -> libpthread-0.9.so make output: (sorry for the german errormessages) Compiling /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c: In function `find_ci_shift0': /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: `CASE_INFO_SHIFT0_HIGH' undeclared (first use in this function) /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: (Each undeclared identifier is reported only once /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: for each function it appears in.) WARNING: Compiler failure! Trying without optimization! cc1: warning: -Wuninitialized is not supported without -O /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c: In function `find_ci_shift0': /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: `CASE_INFO_SHIFT0_HIGH' undeclared (first use in this function) /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: (Each undeclared identifier is reported only once /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c:287: for each function it appears in.) Compilation command was: /opt/pike-7.4/pike.src/Pike-v7.4.20/build/linux-2.4.19-16mdk-i686/smartlink gcc -DPIKE_SRC_ROOT=/opt/pike-7.4/pike.src/Pike-v7.4.20 -I. -I/opt/pike-7.4/pike.src/Pike-v7.4.20/src -I/usr/X11R6/include -g -mcpu=i686 -I/usr/X11R6/include -W -Wall -Wno-unused -Wcomment -Wformat -Wimplicit-function-declaration -Wmultichar -Wswitch -Wuninitialized -Wpointer-arith -Wchar-subscripts -Wno-long-long -c /opt/pike-7.4/pike.src/Pike-v7.4.20/src/builtin_functions.c -o builtin_functions.o make[3]: *** [builtin_functions.o] Fehler 1 make[3]: Verlassen des Verzeichnisses Verzeichnis =BB/opt/pike-7.4/pike.src/Pike-v7.4.20/build/linux-2.4.19-16mdk-i686=AB make[2]: *** [pike] Fehler 2 make[2]: Verlassen des Verzeichnisses Verzeichnis =BB/opt/pike-7.4/pike.src/Pike-v7.4.20/build/linux-2.4.19-16mdk-i686=AB make[1]: *** [all] Fehler 2 make[1]: Verlassen des Verzeichnisses Verzeichnis =BB/opt/pike-7.4/pike.src/Pike-v7.4.20/build/linux-2.4.19-16mdk-i686=AB make: *** [compile] Fehler 2 greetings, martin. -- Pike Conference 2003 - Sep 25-27 - http://pike.ida.liu.se/conferences/2003/

2 2

module build/install procedure
by Bill Welliver 23 Aug '03

23 Aug '03

I've been fiddling with the existing build tools, as a precursor to a proposal for a module repository ala CPAN, and I've got a few observations: 1. It appears that as far as pike is concerned, C modules can reside anywhere in the module tree, as long as they're a .so file. 2. The dynamic module makefile, however, appears to have no provision for making modules that don't live at the root of the namespace 3. Similarly, the dynamic module makefile doesn't seem to want to deal with modules that either a) have no compiled module component, or b) have more than 1 pike file component, which is assumed to be called module.pmod.in and ends up as ModuleName.pmod, derived from the directory name that is being built in. Can anyone comment on any of these statements? Would it be good to remove these limitations, or perhaps add an external_dynamic_module_makefile that does that? Ideally, it would be good to have a method that handles these variations on the standard pike-distribution-module theme. Also, I've got some other thoughts that anyone is welcome to comment on: 1. We should have a way to insert information into the modref when a new module is installed. This way, if I add a new module, the inline documentation is integrated with the existing modref. Now, I'm not very knowledgable on how this works, but I'm guessing that it would probably involve both installing documentation as part of the build procedure, along with some of the source [xml] files that would be needed to rebuild the documentation after inserting the new material. 2. In order to do an integrated module install/remove feature, we probably need a "receipts" store to keep track of what files belong to with modules, so we can be sure that we delete all of a module, or don't overwrite portions another module accidentally. Part of this could probably be accomplished by making a wrapper to mkdir,install,etc that added or removed entries from a contents file ala the solaris package manager. Obviously, a CPAN for pike [with auto download-build-install] is really just icing on the cake. It's something that we really can't do without having a seamless module management experience, both for users and developers. I'm willing to put some time in on this, but I am hesitant to go mucking around with some of this stuff without getting a blessing from the full-time developers. As always, comments and suggestions are welcome! Bill

4 4

Re: [caudium-devel] Pike conference
by Bertrand LUPART 20 Aug '03

20 Aug '03

>>> CIF rewrite >> IIRC, Grendel began that. > Right, but as I said many times - I'm not going to be able to finish > that > alone. It's enough work to fill 8h/day for 6 months for one person. True, but we may organize for that. >> What more feature people want? > I have some ideas I'd like to present during some discussion on the > conference. (for example object-oriented approach to HTML/RXML/XML - > presentation of the web pages to the caudium modules/scripts as a > collection > of objects on which operations can be performed to alter their > content/properties; Rewriting the Caudium core to separate it from > Pike /in > C, probably/ so that Pike runs in a separate process as a "script > server" > accessible either locally via various IPC means or remotely with > XML-RPC or > whatever protocol seems to fit) That's beyond the CIF :) But sounds really cool. >> I'd change (read: allow to change/make default) the select multiple to >> checkboxes, since many people aren't familiar with these. > What will you do if you have 100 options? (for example 100 modules) > Paging > doesn't seem to be a good idea, and a selection page 10 screens long > is even > worse... I wasn't thinking about the add module page, but modules in general. 100 checkbox are not worse than the add module page in standard mode :) Off course, each one could choose that. > All in all, the look of the CIF is the smallest concern. The beast > sleeps > beneath the surface. And it's a huge beast. Enormous. Yep, but we may be aware of some kind of functionnality before coding things. Could you explain breifly how you started to recode this? >>> RXML parser, and the future of RXML >> >> Grendel has a piece of code for the new RXML parser. > Yep, and some (unpublished) code for a new HTML/RXML parser for code > that > isn't XML-compliant. Thanx, my webmaster will be happy. >> - parser speed (read: Martin's RXML Vs PHP bench) >> - enhancement of do_output_tag() > you wanted to say, reimplementation+redesign, I hope? :) I meant something reliable ;) >> Something allready exists on riverweb. Could we steal some code? > I think it's about quite a different thing. The repository should be > accessible not only from the web with mouse clicks, it should mainly > be a > way to organize the modules/extensions to pike/caudium together with > their > docs so that it's easy to access/find any of those in a canonical way. _nice_ >> It should be integrated into caudium's website for people not having >> CVS >> write access to share their code. > Yep, I agree. There should be a single Caudium module (probably using > another single, Pike, module) that would present a view of the > repository. Could the CIF benefit of these functionalities? >>> Marketing / popularity enhancement >> >> What kind of people do we want to target? Coders? Web-literate >> webmasters? >> Newbies? > The most important target would be the ISPs, I think. Once you get > Caudium > in there, you will slowly win the others. That's because it's useless > to > have an army of drooling webmasters/coders without ISP where they could > install Caudium. That's egg and chicken problem. Would ISPs install Caudium if noone care to use it? Is there any hosting service that provides Caudium hosting except kazar.net? (and linkeo, but that's a different thing) Another target is people that manage their servers. >> It's hard for people to hear about Caudium stuff, coz everything is >> talked >> into mailing lists you have to subscribe to. > Well, Bertrand, I might surprise you but... this is internet, you know > :) - > most of discussions take place on mailing lists/usenet forums :) I may not have been well understood. The difference between mailing list and usenet forums is that you don't have to subscribe to: you just have to select any group, lurk, easily read past message, make a search on it with google (easy to follow a thread), no more read it if you want w/o unsubscribing... Off course, you have archives for mailing list, but never seen a single one that present threads in a usable way. IIRC, our mailing list archives is protected against spammers, ie no search engine would archive that (trying to verify that since yesterday evening, but listes.oav.net seems down) That's why i asked some time ago if we couldn't sync the mailing list and a usenet server. Then we talked about which group, coz we wanted a good group. Then the better killed the best and we didn't come to a solution :) > But I guess > a web-based forum would be a good thing for Caudium to have (another > thing > that would have to be written, I guess) I know people like this kind of stuff. I definitly thinks that this kind of things sux. If someone wants to write a forum, abstraction interface for data is planned for CAMAS 1.3: it could connect to NNTP (or even a database for a full forum behaviour) >> Then, writing tutorials, docs and packaging stuff is mandatory if we >> want >> new people to come. For example, i'm very responsible for allmost 0 >> CAMAS >> layout docs and darwin packaging. > I guess Caudium needs a rewrite first, docs then. And before you > protest, > think about it... [snip] Why do you think i'll protest? :) I fully agree, but docs means tutorials or sample code. I was told by a newbie yesterday that caudium website hardly lacks sample code. > Somebody who is willing to inform "press" about events in the Caudium > community, somebody to arrange for Caudium articles to be published > (s/he > wouldn't necessarily write the articles herself, of course), Press is a good medium. Dunno if that's a coincidence, but look at the unique host visits of caudium.net on march. This was when vida's article made it in the french press. > to contact the > various ad companies which work on the link exchange basis (and, yes, > linkexchange.com is Microsoft, but they should be interested in > exchanging > banners with a site that has PR6 in Google); Is that efficient? I personnaly never nor click nor even look at banner contents. > and the other person would be > responsible for, let's call them, milestones in the caudium > development, for > coordination of various efforts, task assignment - i.e. somebody to > fulfill > the goals set by the project leader in their greater detail. That would be a great thing. -- Bertrand Lupart C'est au pied du mur qu'on voit le mieux le mur -- Bertrand Lupart Recursion: n,m See: Recursion

1 0

Pike conference
by Bill Welliver 19 Aug '03

19 Aug '03

I've updated the list to include Bertrand's comments. Please note that I have no official affiliation with this conference; I'm just trying to keep things rolling [at least as far as the caudium stuff is concerned], so if I'm stepping on someone's feet, please let me know :) Here's a list of the topics thrown out on the caudium devel list. Are there any others that I missed? (they get more directly pike related as you go down the list) My thinking [and previous experience] is that we should think about whether we will discuss all of these topics, how much time we should devote to them, and see if someone wants to take a lead on that (sort of a session chair and/or discussion facilitator). They'd be responsible for having any supporting material (slides, handouts, presentations, etc) and for making sure that any discussions/outcomes were preserved for use later. Obviously, a session chair could delegate some of the responsibility to others. Once you had an idea of what we were going to do and who would coordinate the various pieces, you could get a schedule together. Another thing to consider is if there will be enough people of different interestes to consider splitting up the group and having 2 or more concurrent sessions going at once. I'm not sure whether that's feasible or desireable, but figured I'd mention it anyhow. I guess we probably need to know who is in overall command of the conference. Martin, do you know who's running the show? Is anyone from Paderborn listening? :) Any thoughts? Bill Caudium 1.4 release plan Pike interface redesign (security) License change (code rewrite vs RIS grant vs separation of core) CIF rewrite RXML parser, and the future of RXML Martin's Stale code from his previous job ecommerce and other projects State of CAMAS/1.2/1.3 release Caudium module repository / website Plans for 2.0+ i18n /l10n Licensing policy Organization/management of the effort Marketing / popularity enhancement Hack sessions Bug Squash Sessions Pike module repository ala CPAN Pike module build system (problems, etc) Pike Namespace management _______________________________________________ Caudium-devel mailing list devel(a)caudium.info http://listes.oav.net/wws/info/caudium-devel Archives are : http://listes.oav.net/wws/arc/caudium-devel

3 2

module build/install procedure
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 19 Aug '03

19 Aug '03

Sorry, minor typo there. MODDIR must end with a slash, so it should be set to Tools.pmod/Standalone.pmod/ in the example.

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