Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

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

What am I missing?
by Ryan Elgram 20 Apr '03

20 Apr '03

Running FreeBSD 5.0 Making GL Linking GL /usr/bin/ld: cannot find -lGL Linking failed: /usr/local/downloads/Pike-v7.4.20/bin/smartlink /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386/smartlink gcc -Wl,-Bshareable -static-libgcc -I/usr/X11R6/include -I. -I/usr/local/downloads/Pike-v7.4.20/src/post_modules/GL -I/usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386 -I/usr/local/downloads/Pike-v7.4.20/src -DHAVE_CONFIG_H -I/usr/local/include -I/usr/X11R6/include -I/usr/local/include/pth -pipe -fPIC -DDYNAMIC_MODULE -O -o module.so top.o auto.o -g -O2 -pipe -I/usr/local/include/pth -L/usr/local/lib/pth -lGL -lm -lpthread -lcrypt /usr/lib/libgcc.a -lc /usr/lib/libgcc.a *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386/post_modules/GL. *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386/post_modules/GL. *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386/post_modules. *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386. *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20/build/freebsd-5.0-current-i386. *** Error code 1 Stop in /usr/local/downloads/Pike-v7.4.20.

2 1

FreeBSD 5.0
by Ryan Elgram 18 Apr '03

18 Apr '03

I am having some difficulties compiling under FreeBSD 5.0. I have installed libgmp4 but the pike install never seems to find it. If I install without-bignums ... it will configure fine, but during make I am getting some errors about it not being able to locate pike to run something.pike. Does anyone have an special considerations they would like to share when installing under FreeBSD?

2 2

Jump to page:

2026

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