Pike-devel April 2003

pike-devel@lists.lysator.liu.se

11 participants
55 discussions

Re: Sad.....
by Xavier Beaudouin 24 Apr '03

24 Apr '03

Le jeudi, 24 avr 2003, à 22:45 Europe/Paris, Martin Nilsson (har bott i google) @ Pike (-) developers forum a écrit : >>> - sometimes compatibilty is not really compatibility >> >> IMHO, it is not a good idea to support outdated and rare platforms >> which >> are in use by two or three individuals on the planet... > > Being able to compile on outdated and rare platforms is in itself of > little value. It does however pay off every time there is a brand new > platform we want to support. E.g. we have fairly good support for 64 > bit > architechtures thanks to our support for rare platforms. Though I am > not > sure Xavier meant portability. s/portability/compatibility/ Was speaking about pike itself. Eg #pike7.2 somethimes is not enougth to help comptability inside some code.... :/ >>> - it is NOT embeddable.... (so we can't make a mod_pike for >>> apache). >> And it will never be, I believe. At least it will not be done by >> the Pike >> team. Why? "Nobody needs it" > > Well, its on top of my wishlist. Good ::)

1 0

IPv6 diff for Pike 7.5.7 (today's snapshot)
by Marek Habersack 24 Apr '03

24 Apr '03

The attached diff is not finished. I've just rediffed and adjusted whatever I could, but I have no more time today for keep working on it. The get_inet_addr function in system.c needs more work to get the families right (basically a few switch statements in there). The patched pike compiles on Linux/Debian, it will compile on any linux with glibc 2.2+, should compile fine on FreeBSD/NetBSD/Solaris. I'm attaching the latest Pike 7.3 diff for the stuff which I used as the basis for the 7.5 one. You can use it for reference wherever I goofed up (which I undoubtedly did). If you do any tweaks on the patch, please send me a diff against the latest 7.5 CVS, thanks, marek

4 9

Re: [caudium-general] ipv6 support
by Xavier Beaudouin 24 Apr '03

24 Apr '03

[... From pike(a)roxen.com mailing list, ] Le lundi, 21 avr 2003, à 21:32 Europe/Paris, Martin Nilsson a écrit : > Marek Habersack wrote: >> They are not up to date since there's no interest in them upstream and >> maintaining them is too much effort if it is to be futile. > > The non-interest of the patches was not due to lack of interest in > IPv6 support, but the fact that it didn't compile on many systems. But > that isn't news to you... I understand that, but you know DVB module in Pike 7.4/7.5 is only Linux specific, so "it didn't compile on many systems" is not really a good argument to the fact that IPv6 support was not accepted. The idea is to start a IPv6 support on at least one Operating System, then trying to port on other depending of access on other system. I really think that IPv6 (even if it is not complete) must be added on pike. Even if Marek work is incomplete, it is really a good start to finish it on other OS... My 0,02€ /Xavier

11 27

Re: IPv6 diff for Pike 7.5.7 (today's snapshot)
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 24 Apr '03

24 Apr '03

Well, yeah. Pike v7.5 release 7 running Hilfe v3.5 (Incremental Pike Frontend) > Stdio.File f = Stdio.File(); > f->connect("::1", "ftp"); (1) Result: 1 > f->query_address(); (2) Result: "::1 21" > f->query_address(1); (3) Result: "::1 4396" > I expect we'll still need a way to specific protocol family when calling open_socket() directly though, since open_socket() can be used to create the socket without actually disclosing either target or destination address yet. The question is how to specify it. Mareks patch adds a third argument, which seems like the logical choice at first, however it has undesired side effects: f->open_socket(0,0); binds the socket to any port on any interface, while f->open_socket(); creates the socket _without_ binding it. By making the family the third argument, it becomes impossible to specify the family without binding the socket. We could of course say that if the third argument is given, the first two are disregarded and the socket is not bound, since it's possible to bind the socket manually with a call to ->bind() afterwards if so desired. But having two dummy arguments isn't very nice either... / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-04-23 23:03: >Subject: Re: IPv6 diff for Pike 7.5.7 (today's snapshot) >-------------------------------------------------------------------- >> To me, it seems a lot cleaner to just give it an address, >> and have the code examine the address to figure out which address >> family it is. > >That's how it works now after Marcus Comstedts latest changes, I >believe. > > / Martin Nilsson (har bott i google) >

4 6

pre-alpha: PiXPull.pmod, PiXTree.pmod
by rjb ＠ Pike developers forum 24 Apr '03

24 Apr '03

Hello, I thought I would make these two toys available for your perusal, even though they are hardly finished. If by some chance they survive scrutiny by thoughtful Pike developers (and maybe gain some improvements|bugfixes as a result), I may follow up with a more "public" announcement (freshmeat maybe), produce some usage samples, test cases,... (and profit ;-) Brief descriptions follow. In addition, the sources include some AutoDoc markup, and before setting up a dedicated webpage I hope to figure out how to extract and format API docs from standalone .pmod's. * PiXPull.pmod aims to be a Pike implementation of an API not unlike the one described and advocated at http://xmlpull.org/ (which is designed for Java). In brief, it is a streaming XML parser, based on the "pull" parsing model rather then the more usual event-callback scheme (SAX, etc.). Currently it neither validates nor parses DOCTYPE declarations (merely skips them), and is not fully compliant with the XML spec in detecting violations of well-formedness (many checks are missing that are too expensive to do in Pike). XML Namespaces are not implemented (this is optional in the XMLPull API), but shouldn't be too hard to add. Other bugs/omissions: - input encoding detection isn't quite there (but at least utf-8, utf-16 and 8-bit encodings supported by Pike should work) - attribute value normalization is buggy - error reporting needs improvement It does however seem to work OK for about all XML input files I tried ;-) Being written entirely in Pike, PiXPull is not lightning-fast... but it does not seem to be significantly slower than pure Java implementations (but is of course no match for compiled native code...) * PiXTree.pmod is a rough sketch of an interface for generating XML output. If PiXPull is pre-alpha, this is just an experimental prototype. Your feedback (if any ;-) will tell me whether this is at all a good idea. Basically, you can do like: import .PiXTree; ... Element html = Element("html"); html( Element("head")(Element("title")("This is the title."))); Element body = Element("body")(Element("h1")("The Title.")); html << Comment("The <body> starts below."); html << "\n"; body << Element("p")("Here is some text in a paragraph."); write( html(body)->toString() ); // defaults to utf-8 encoding // or a number of different permutations ;-) write( Doc(html)->toString("iso8859-1") ); // ..to produce an xml header and use the provided encoding; // note the body has already been attached to html, // you don't want to do it again. The two modules are temporarily to be found at http://bobo.fuw.edu.pl/~rjb/STUFF/PiXPull.pmod http://bobo.fuw.edu.pl/~rjb/STUFF/PiXTree.pmod Enjoy! (or otherwise ;-)

1 1

lfun::`+=()
by rjb ＠ Pike developers forum 23 Apr '03

23 Apr '03

Either I totally failed to understand how it's supposed to work, or these lfuns are quite non-functional: > class T(string t){ T `+=(string s){ t+=s;return this; } } > T o = T(""); > o->t; (7) Result: "" > o+="bar"; Incompatible types Unknown program: `+(HilfeInput()->T(),"bar") Obviously Pike is calling `+(o, "bar"), and ignoring the existence of lfun::`+=() in T...

5 25

lfun::`+=()
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 23 Apr '03

23 Apr '03

(In Pike 7.0 and earlier the fallback case was right-associative(!).)

1 0

Re: sort
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 23 Apr '03

23 Apr '03

Like this: Pike v7.4 release 20 running Hilfe v3.5 (Incremental Pike Frontend) > class foo(string msg) { >> int `>(mixed x) { return 0; } >> int `==(mixed x) { return 1; } >> string _sprintf(int mode, mapping options) >> { >> return mode=='O' && sprintf("%O(%O)", this_program, msg); >> } >> }; > sort( ({ foo("one"), foo("two"), foo("three") }) ); (1) Result: ({ /* 3 elements */ HilfeInput()->foo("three"), HilfeInput()->foo("one"), HilfeInput()->foo("two") }) >

1 0

Re: [caudium-general] ipv6 support
by Xavier Beaudouin 23 Apr '03

23 Apr '03

[ Follow-up from pike(a)roxen.com ml ...] Le mercredi, 23 avr 2003, à 14:57 Europe/Paris, Niels Möller a écrit : > Marek Habersack <grendel(a)caudium.net> writes: > >> All of this is done, but the problem (as I recall) was that the code >> failed >> to compile (even if not used) on Windows NT. > > Ok, so it was a question of a bunch of #ifdef _WIN32? This is getting > even sillier ;-) > > I look forward to seeing your patch. I agree that real IPv6 support > for windows (at least I'm told M$ have some IPv6 stack available) can > be left to somebody that cares for windows, but we can't leave the > pike tree in a state where it doesn't compile. Just a little information but it seems there is a IPv6 stack for NT/2000 here http://research.microsoft.com/msripv6/ With it seems the sources. Since as Marek, I don't have NT/2000 machine to play with (and I don't have also the compiler to work with such thing), I have never tested such options.... /Xavier

1 0

Re: [caudium-general] ipv6 support
by Johan Sch�n (Firefruit) ＠ Pike (-) developers forum 23 Apr '03

23 Apr '03

I think it could be interesting/fun to instead create a platform independent Pike implementation of multicast DNS (i.e. Rendezvous), rather than just using Apple C libraries on OS X. / Johan Schön (Firefruit) Previous text: >2003-04-22 19:09: >Subject: Re: [caudium-general] ipv6 support >-------------------------------------------------------------------- > >Le mardi, 22 avr 2003, à 16:33 Europe/Paris, Niels Möller a écrit : > >> Xavier Beaudouin <kiwi(a)oav.net> writes: >> >>> But as said Grendel, the patch seems no interest for it so we >>> (grendel, me and some others) that we should create our own port >>> opener to avoid such problems in the future.... >> >> Well, if you want some nice clean code that works fine on modern >> systems, but doesn't even compile on older ones, that's the right way >> to go. > >Interressing how some words can be interpreted.... >I just say we may / should create our (Caudium) own port opener. I >didn't say >we will make our own port opener that will be only IPv6 compliant. > >The idea is to make some more Webserver oriented C module to use some >good usage of some operating system options : > >- tux (or something like tux) under linux >- accf_http or accf_data under FreeBSD >- maybe also kqueue support on FreeBSD >- IPv6 (Linux, Kame = *bsd, Solaris...) >- OS X Rendez-vous support >- what ever specific OS thing can be added here. > >> If you want to have a patch be accepted for pike easily and without >> fuzz, it has to work both on modern systems and older systems that >> don't have the latest socket api functions. And it *has* to include >> the corresponding configure checks etc, even if that is the most >> boring part of it. > >AFAIK Marek patch supported that... I am wrong ? > >> Almost any halfway done patch is almost useless (it's not useless, >> it's just slightly less useful than an encouraging wish-list note >> properly registered in some bugtracking system). That's because it's >> usually at least as much work to finish and integrate such a patch, >> than to throw it away and solve the problem at hand from scratch. >> There's no need to get personal about that. > >Ok.. So if we make it from scratch, what the plans to "make it good >really from the begining ?". >And also who will be the project leader for such thing ? > >/Xavier > > >_______________________________________________ >Caudium-general mailing list >general(a)caudium.info >http://listes.oav.net/wws/info/caudium-general >Archives are : http://listes.oav.net/wws/arc/caudium-general > > > / Brevbäraren >

2 1

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