Pike-devel

pike-devel@lists.lysator.liu.se

3044 discussions

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

predef::Iterator
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 18 Apr '03

18 Apr '03

Why is the function that creates the basic iterators called "Iterator" like a class? Now it gets tricky to add an interface class for iterators, since the obvious name for it already is taken. :(

2 5

libkse + freebsd ?
by Xavier Beaudouin 17 Apr '03

17 Apr '03

Hey there, On FreeBSD 5.0, we can have KSE (Kernel Threads) with posix interface with linking with -lkse... Can we add that on Pike 7.5 automatically ? and if so, how, because threads detector in configure.in is somewhat confusing... Maybe we try to detect pthread_create() on -lkse ? /Xavier PS: I add a new pikefarm server RSN :)

2 2

Re: Starting new pike processes from the testsuite
by Mirar ＠ Pike developers forum 15 Apr '03

15 Apr '03

Ah, yes, there is already a SSLPort class. Great. Nevermind then :) / Mirar Previous text: >2003-04-15 17:43: >Subject: Re: Starting new pike processes from the testsuite >-------------------------------------------------------------------- >There should be https server code in the 7.4+ tree, as I'm pretty sure I >committed my changes... > >Bill > >On Tue, 15 Apr 2003, Mirar @ Pike developers forum wrote: > >> If there is HTTPs server code, it probably belongs - would be great - >> in the Protocols.HTTP.Server tree. >> >> / Mirar >> >> Previous text: >> >2003-04-15 11:16: >> >Subject: Starting new pike processes from the testsuite >> >-------------------------------------------------------------------- >> >What's the recommended way of starting separate processes (which are >> >Pike programs) from the testsuite? >> > >> >I want to make a test case for the SSL code, by starting a https >> >process using the SSL.pmod/https.pike program (which I'm not sure it >> >really belongs in the module tree) or some similar code, and then use >> >the client code in the url/http modules to connect to it. >> > >> > / Niels Möller (ny flexiblare bröstkorg) >> > >> > > > > / Brevbäraren >

1 0

Starting new pike processes from the testsuite
by Niels M�ller (ny flexiblare br�stkorg) ＠ Pike (-) developers forum 15 Apr '03

15 Apr '03

Ok, that crash disappeared after a recompile. Good.

1 0

nasties in Stdio
by rjb ＠ Pike developers forum 14 Apr '03

14 Apr '03

Two problems/inconsistencies: Stdio.FakeFile.read(len) will return 0 if len is more than there is data left to read. This is inconsistent with Stdio.File.read(len), which returns less than len, an empty string if no data is left (for a disk file at least). Stdio.Stream declares a prototype string read(int nbytes); and does not allow for a second argument not_all (which would work around the previous issue). Together this creates problems when writing a function to operate on a Stdio.Stream (open for reading), when you want to be able to drop in an instance of either a Stdio.File or a Stdio.FakeFile at runtime. (I checked this on 7.4, can't look at 7.5 right now because the cvs browser seems to be broken) /rjb

2 1

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