Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Pike 7.6 release
by Bill Welliver 21 Jun '05

21 Jun '05

Hi, What are the chances of getting a new Pike 7.6 release out in the next month or so? It's been quite a while (almost/over a year?) and there are some good bug fixes that would be nice to get out. Actually, I have a patch to backend in 7.7 that could probably stand to be backported (I'm not 100% sure the problem exists in 7.6 though)... I'm not completely familiar with the procedures involved with a new release, but would be willing to help out. Any thoughts? Bill

1 0

Calendar woes
by Peter Bortas ＠ Pike developers forum 15 Jun '05

15 Jun '05

Oh well, change the day too.

1 0

Relocatable modules
by Jonas Walld�n ＠ Pike developers forum 06 Jun '05

06 Jun '05

What is the status of PIKE_MODULE_RELOC? In the 7.4 master it's disabled with the comment "currently broken" but not in 7.6 or 7.7. Still, it's being used in 7.4 on Windows, right? I tried enabling it (--with-relocatable-dumped-modules) in a test build of 7.4 on Darwin but didn't succeed which wasn't surprising given the comment above. However, not even in a shiny new 7.7 build could I get it working: ceylon:pike-reloc $ ./moved77/pike/7.7.21/bin/pike "Couldn't load master program from /tmp/pike-reloc/install77/pike/7.7.21/lib/master.pike.\n" Oh well, at least providing the paths explicitly should work: ceylon:pike-reloc $ ./moved77/pike/7.7.21/bin/pike -m /tmp/pike-reloc/moved77/pike/7.7.21/lib/master.pike -M /tmp/pike-reloc/moved77/pike/7.7.21/lib/modules/ -P /tmp/pike-reloc/moved77/pike/7.7.21/lib/modules/ -I /tmp/pike-reloc/moved77/pike/7.7.21/include/ Could not resolv Getopt. (Perhaps the installed pike tree has been moved.) /tmp/pike-reloc/moved77/pike/7.7.21/lib/master.pike:2388: master()->__lambda_65601_2_line_2385("Getopt",UNDEFINED) What am I missing here? Also, a related question is what the whole point of the Master Cookie is? Overcome limitations that one cannot find the path of the currently executing process? At least on Darwin that can be solved with some system calls such as NSModuleForSymbol(), and maybe other systems have similar calls nowadays?

4 10

Relocatable modules
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 05 Jun '05

05 Jun '05

Of course, the string ${PIKE_MODULE_PATH} should also be changed to something else in this case.

1 0

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

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