Pike-devel May 2005

pike-devel@lists.lysator.liu.se

5 participants
15 discussions

negative indices in array ranges
by Martin Baehr 14 Aug '26

14 Aug '26

hi, instead of having to do: reverse(reverse(foo/"/")[1..]); i'd very much prefer: (foo/"/")[..-2]; are there any reasons that speak against supporting this other than me not being able to offer a patch? greetings, martin.

13 51

negative indices in array ranges
by Mirar ＠ Pike developers forum 14 Aug '26

14 Aug '26

levels might possibly be from -1 and up, -1 meaning infinite.

10 25

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 09 Apr '26

09 Apr '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

4 3

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

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

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