Pike-devel May 2005

pike-devel@lists.lysator.liu.se

5 participants
11 discussions

automap: [*] not supported here. bug?
by Martin Bähr 23 Jul '05

23 Jul '05

hi, can you explain why: random(allocate(3,9)[*]); or random(({9,9,9})[*]); don't work, while array foo = allocate(3,9); random(foo[*]); does? greetings, martin.

6 13

Kernel version in build directory names
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 22 May '05

22 May '05

I'd like to remove the -r part from the uname call that creates the build directory names. That means that one would get build directories like this build/linux-x86_64 instead of build/linux-2.6.10-5-amd64-k8-x86_64 The reason is that I find it a bit annoying to have to discard all my pike build dirs every time I install a new kernel. It also doesn't seem relevant to depend on the kernel version since it afaik doesn't affect the build environment. It'd be more apt to depend on the libc version (or actually the version of every lib that pike builds against). Thoughts?

6 9

webmaster?
by Martin Bähr 17 May '05

17 May '05

hi, who is watching the webmaster(a)pike.ida.liu.se address? i got a complaint from someone claiming he had sent mail there but had not received a reaction yet. does it make sense to extend the alias to all people who have write access to the website? greetings, martin.

1 0

Bump version ?
by Xavier Beaudouin 09 May '05

09 May '05

Hello, Seems according to pikefarm that 7.6 has lot of green (excepted some case, but it is usual). Can pike maintainer bump version and release a new pike if possible (This should help to have a new release for Caudium Group and help us to get a stable pike version). Many thanks, /Xavier

1 0

Caudium is looking for a new maintainer...
by Xavier Beaudouin 06 May '05

06 May '05

[Sorry for cross-posting here] Hello, The Caudium Group will release Caudium 1.4 RSN (mostly next week). Because I have less and less time to work with Caudium and I will change job (eg stop to work for an ISP), I will have less and less time to work with Pike / Caudium / .... So this is a open letter for people that wishes to maintain Caudium and make it better than now... I will drop maintainer ship whatever a new maintainer is choosen or not after mid may 2005. So don't hesitate to contact me for that. /Xavier

1 0

modules and the core distribution
by Bill Welliver 03 May '05

03 May '05

I noticed the checkin of a new module the other day and was reminded that we're long overdue for a discussion of Pike distribution bloat. This has come up at the last two conferences, and we always "table" the discussion for later. I think now is a good time to have it since we're not coming up on an impending new stable release. It seems to me that there are a fairly large number of modules distributed with Pike that have a corresponding low number of potential users. I'm not suggesting that the modules don't have merit, but am suggesting that perhaps the audience is so small that it becomes clutter to others. Does it really make sense to keep adding these modules to the core distribution when they could just as easily be distributed separately? As it stands now, Pike distributions are 10MB, and take a painfully long amount of time to compile. I'm sure I'm not the only one who wonders why they have to configure and compile things like HTTPLoop and SDL... (just picking two that I'd remove, not that they're at the top of my list) I realize that there was a time when including things in the core was a necessary evil due to compilation difficulty, but that's not been the case for at least a year or two... Any thoughts? Bill

10 31

Re: modules and the core distribution
by Per Hedbor () ＠ Pike (-) developers forum 03 May '05

03 May '05

> We need to work on configure times, though. > The largest gain (about 400% or so) can be had by generating configure > from an old version of autoconf. And a secondary rather large gain can be had by not having separate configure-scripts for each module, but instead generating a toplevel configure from the subconfigures or something. And removing redundant and other rather unnessesary tests (I'm guilty here, I often add tests for each function even though the presence of one generally means that the others are available too, such as the {get,set,list,llist,lset,lget,fget,fset,flist}xattr methods I just added). And also stopping the module configure scripts as soon as a required feature is found to be missing (as an example, in the GL module, when no GL library is found, stop looking for functions in the non existing library, and inversely, stop looking for more GL libraries once the first has been found)

4 16

Re: modules and the core distribution
by Martin Nilsson (DivX Inc.) ＠ Pike (-) developers forum 02 May '05

02 May '05

But that was an irrelevant comment I just realized.

1 0

Re: modules and the core distribution
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 01 May '05

01 May '05

> I'm willing to work on this (though my available time is somewhat > limited). I think a good first step would be to make individual modules > available for download and install separately (perhaps via monger?). Sounds like a workable approach for a quiet migration to externality. Especially if it would (as I presume is the idea) not impact from what source (in this case the main Pike repository) the modules end up there. Makes it easy to make both small and large pikes without any loss of development support tools for modules presently enjoying such privileges.

1 0

Re: modules and the core distribution
by Martin Nilsson (DivX Inc.) ＠ Pike (-) developers forum 01 May '05

01 May '05

I think SDL, GTK and Stdio (I'm thinking of Readline/Terminfo here) all have a place in a standard distribution since they are essential I/O-modules for a wide range of applications (though in specific domains). But I guess this discussion really shouldn't be about specific modules.

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 May 2005