Pike-devel August 2006

pike-devel@lists.lysator.liu.se

6 participants
23 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

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Were you not able to get any C code to play through SDL either? Does your SDL library have a mixer compiled in it (I think it is optional)?

5 4

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

Process.run
by Peter Bortas (nu med mindre Opera) ＠ Pike (-) developers forum 14 Jul '08

14 Jul '08

I just checked in a Process.run() in 7.7: http://pike.ida.liu.se/development/cvs/diff.xml?module=Pike&file=7.7/lib/mo… The rational for that is that I was once again reminded by a user this week that getting Process.create_process() or Process.Process right without some corner case blocking is hard. It's not obvious that if you bind pipes to booth stderr and stdout you have to take in to account that OS buffers are not limetless. Process.run() is a thin wrapper around Process.Process that collects stdout, stderr and exitcode and return them in a mapping. This could potentially result in huge strings, but will do what most users want and even already do when they call create_process() with both pipes bound. Something like this should be in 7.8, but I'm open to suggestions for other things that might be usefull to return in the mapping or for changing member names.

5 7

Subversion repository
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 05 Nov '06

05 Nov '06

I now have a rather complete conversion of the Pike repository to Subversion (some more copyfrom links could be added, but otherwise everything should be ok). It includes all checkins up to and including 2006-08-29, which when I'm writing this means "everything". The dump file is in pelix:/pike/home/marcus/pike_svn.dump.gz. My suggestion is that we create an accessible repository from this somewhere, to be able to work on tooling, and to check for glitches in the conversion. Once that is ready, I'll make a new conversion for the actual switch. Which means that everything checked into the temporary repository would be discarded. I have not converted projects/ or Pike/ulpc or Pike/extra_tests, as these are not branches of the main Pike development tree. Any opinions on whether to convert some or all of these, and in that case should they be in the same repository or a different one? Some statistics: Conversion: ----------- Number of revisions: 31738 Conversion script run rime: 15h 15mins (on pelix) Dump size (uncompressed): 1.7Gb Dump size (compressed): 384Mb Test import: ------------ Dump import time: 4h 24mins (on bhelliom) Reposiory size: 421Mb (with fsfs)

7 13

pre 7.2 lib/modules/SSL.pmod ,v files
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 03 Nov '06

03 Nov '06

In trying to convert the Pike CVS repositories to Subversion, I've come across something really odd. Looking at the ,v files in /pike/data/cvsroot/Pike/7.2/lib/modules/SSL.pmod, it seems that this module was created on 1997-03-13, and included in such tags as "pike_v0_5_release_47". Yet, there is no trace of this module under /pike/data/cvsroot/Pike/0.5 (or 0.6, or 7.0), under this name or any other as far as I can tell. Where are the missing ,v files? Did somebody miss some CVSROOT/modules magic when copying the repositories from RIS?

7 15

A hefty cleanse
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 14 Sep '06

14 Sep '06

So Ssleay, Pipe, Perl and Mird are gone from 7.7. Was decided upon through a very enlightened consensus, I'm sure. Could we outsiders get a rundown on the rationale behind this too? Don't they work at all? Commit messages talk about removing from "standard Pike". Are they going to appear somewhere else?

4 5

Image.Image()->scale(x) int or float?
by Martin Bähr 28 Aug '06

28 Aug '06

hi, i noticed a minor difference between the documentation and the implementation of Image.Image()->scale(); according to the documentation, if scale() is given only one argument, it must be a float. in reality it accepts an int as well as a float. this is significant in the sense that one could assume that scale(5) is equivalent to scale(5, 0) because that is usually the case when the second argument is optional, whereas in this case it actually is equivalent to scale(5.0) i prefer to assume that the documentation is wrong, but i would like to know if that assumption is correct. greetings, martin.

2 1

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 August 2006