Pike-devel September 2007

pike-devel@lists.lysator.liu.se

5 participants
12 discussions

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

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

13 Mar '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) >

3 2

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

Getopt mark II
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 19 Apr '08

19 Apr '08

(or rather Getopt mark III, since I've already rewritten the current one, although no functionality was changed then) I've been working a bit on a new Argument parser, and would like some input. In reality there will be two different way of using the argument parser, which really doesn't share any code but is convenient to do at the same time. The first one is a "I just want to get this over with" kind of interface: void main(int num, array argv) { mapping args = Arg.parse(argv); argv = args[Arg.REST]; } The output will contain ([ "foo":1 ]) if the argument is --foo and ([ "foo":"bar" ]) if the argument is --foo=bar. There is no fancy stuff to handle default values (just or it with another mapping) or options that may or may not have values (e.g. -bar=foo will produce ([ "b":1, "a":1, "r":"foo" ]) and --foo x --bar will just produce ([ "foo":1 ]) and then stop processing the line). The other mode is the (supposedly) easy yet powerful mode that you would use for more mature applications. class Parser { inherit Arg.Options; Arg verbose = NoArg("-v")|NoArg("--verbose")|Env("VERBOSE"); Arg level = HasArg("-l")|HasArg("--level"); } void main(int n, array argv) { Parser p = Parser(argv); // Index magic. Some like it, some not so much. if( p->verbose ) werror("Level %s\n", p->level); } Which is extended in class Parser { // The name for now. inherit Arg.OptionsSupreme; Arg verbose = NoArg("-v")|NoArg("--verbose")|Env("VERBOSE"); // These are used in the automatically generated --help response. string help_pre = "This program is like awesum."; string verbose_help = "Increases the verbosity of the program."; // Called when/if verbose is set to a value. void verbose_cb(string arg) { werror("Verbosity is on.\n"); } } Does this match the long list of requirements that I've heard from others?

5 17

Snapshot tarballs and packaging/debian
by Magnus Holmgren, FR Ryd (Nu med m�l och syfte) ＠ Pike (-) developers forum 03 Oct '07

03 Oct '07

I have a few questions relating to pike in Debian (as you may know, the previous maintainer has retired from Debian and orphaned his packages). I've figured out that one can get a fresh tarball from http://pike.ida.liu.se/generated/pikefarm/packages/7.6/latest. What's the difference between that and checking out from CVS and running "make source" (which is what I suspect Marek has done), if any? Is there any archive of such tarballs except for the official releases? How did the packaging/debian subdirectory originally come to be? Do you synchronize with the Debian package yourself or has Marek been sending you patches? I see that export.pike adds new records to packaging/debian/changelog. AFAICT, export.pike --tag first increments the build number (to an even number, typically), then tags, then increment the build number again, so that an even build number represents a known state of the source, whereas an odd build number can include any number of commits inbetween.

17 129

Re: debian packages of 7.6.112
by Magnus Holmgren, exim.org ＠ Pike developers forum 26 Sep '07

26 Sep '07

Er, wait. It's not in _/usr/lib_, which is why you use $LD_LIBRARY_PATH to point to it. I guess pike could set it somewhere...

1 0

Re: how to stop an iterator
by H. William Welliver III 26 Sep '07

26 Sep '07

> yeah, but next() is optional and not used by foreach There's no indication that next() is optional. At the very least, the documentation is somewhat lacking, if for no other reason than the api including two parallel sets of functions for interacting with the iterator, one of which is relatively more "standard" than the other without stating clearly which functions are actually used. I think most people who have used other languages with iterators will feel more comfortable with ->next() and friends, and be confused that they're not actually used. I know I was, and I'm probably not alone. > and += returns the iterator itself, so you can't return UNDEFINED > there. > since += never fails the only option is to test wether you still > have an > item there or not, and then ! is a good choice for that test. Well, you can very easily return undefined from `+=(), and it doesn't make any difference. That, at the very least, should have prompted an error, but instead, it kept right on running. I'm not sure that the semantics of this are appropriate, as the side effect is important (or should be, even if you're always supposed to return this_object() from `+=()). > it would be different if next() where the standard way of advancing > the > iterator. Well, it is the "standard" way, [by "standard", I mean the pattern employed by C++, Java, Objective-C, etc] Pike just happens to use operator overloading instead. Anyhow, my problem is solved. If I find time, I may update the documentation to be a little more clear about what's required and what's optional. Bill

2 1

how to stop an iterator
by H. William Welliver III 26 Sep '07

26 Sep '07

I'm writing an iterator and under 7.7.34 (at least), I can't seem to get a loop using it to end, even though next() and `+=() both return UNDEFINED at the end, but the foreach loop doesn't ever seem to end. Am I missing something? Bill

2 1

static variables with function scope
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 18 Sep '07

18 Sep '07

Hi. Some of you may have noticed that I implemented static variables with function scope a day or two ago. Example: int inc() { static int counter; return counter++; } The problem in Pike is that the intended lifetime of the variable isn't always obvious; consider nested classes: class X { int inc() { static int counter; return counter++; } } int main() { function(:int) X1 = X()->inc; function(:int) X2 = X()->inc; write("X1:%O,%O\n" "X2:%O\n", X1(), X1(), X2()); } Should the above output X1:0,1 X2:0, or X1:0,1 X2:2? ie should the variable be stored in X or in the top-level class? Pike also has nested functions; consider: function(:int) X() { int inc() { static int counter; return counter++; }; return inc; } int main() { function(:int) X1 = X(); function(:int) X2 = X(); write("X1:%O,%O\n" "X2:%O\n", X1(), X1(), X2()); } Same question. I believe that the most useful would be to store the variable in the closest surrounding scope (ie X1:0,1 X2:0 for both of the above), and then have some extra syntax for specifying some other scope. The question is what the syntax should be? Any suggestions?

11 34

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 September 2007