Pike-devel February 2007

pike-devel@lists.lysator.liu.se

3 participants
11 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

Returning 0 vs throwing errors in Stdio
by Peter Bortas ＠ Pike developers forum 27 Apr '07

27 Apr '07

I'd like someone to expand on the advantages of the following change in 7.7: > o Stdio > The functions read_file(), read_bytes(), write_file() and > append_file() now always throw errors upon errors, to allow easier > use as errno doesn't have to be checked. read_file() and > read_bytes() still returns 0 if the file does not exists. Specificly for read_file() on files you lack permissions for. > Stdio.read_file("/etc/shadow"); (1) Result: 0 vs > Stdio.read_file("/etc/shadow"); Failed to open "/etc/shadow": Permission denied /pkg/pike/intel-debian3_1/7.7.13/pike/7.7.13/lib/modules/Stdio.pmod/module.pmod:1820: Stdio->read_file("/etc/shadow",UNDEFINED,UNDEFINED) As I see it it only makes it harder to properly handle errors. If Pike had a well developed system for handling errors it would be an improvement, but now it's only going to lead to more and buggier code. Unless someone can come up with a good explanation* for why it should be changed it should be reverted. * Like for example "I've extended and documented the error classes. It's obvious and clear how to use them now!". That'd be nice.

7 16

replacing autoconf?
by Martin Bähr 23 Feb '07

23 Feb '07

hi, i think from time to time there is a suggestion to get rid of these autotools. here is a compelling article that makes me want to look at cmake: http://dot.kde.org/1172083974/ greetings, martin.

3 2

new debian pike maintainer?
by Martin Bähr 21 Feb '07

21 Feb '07

hello, marek has resigned from being a debian maintainer. which means that among other things the pike packages need a new maintainer. i remember mentioning that someone among the developers became a debian maintainer some time ago and would be interested in maintaining pike packages. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411684 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411685 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411677 greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix offering: programming, training and administration - anywhere in the world -- pike programmer pike fishing in new zealand open-steam.org|webhaven.co.nz unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (caudium|gotpike).org is.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/

5 7

7.6.102 beta
by Peter Bortas ＠ Pike developers forum 18 Feb '07

18 Feb '07

http://pike.ida.liu.se/pub/pike/beta/7.6.102/Pike-v7.6.102.tar.gz There are two changes since 7.6.100: * A builfix for Darwin PPC * A fix for a broken treeopt rule.

7 19

Re: Pike and JSON
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 06 Feb '07

06 Feb '07

>> From comments in Bill's code it seems to be based on some C# >> implementation by Are Bjolseth, in turn based on something else, >> but I didn't manage to look at it for very long periods of time; >> its inlined refdocs makes one want to gnaw off a leg. :-) > > This is the first time I have ever read a programmer complaining > about too many comments! They are actually not too many, just unreadably full of xml, for a source code environment not especially equipped to cope with whatever format they happen to be written in.

1 0

Pike and JSON
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 06 Feb '07

06 Feb '07

As I have been working much with JSON (http://json.org/ or RFC 4627, http://rfc.roxen.com/4627 for those who have missed it), I recently hacked up some tools and very sloppy Pike support for it. (The first 95% of the decoder bits were kindly contributed by Martin Nilsson.) Neither encoder nor decoder is quite up to pike standards, API-wise nor code quality wise, so we are reluctant to commit them into pike core as is, but if someone wants to shape them up a bit and get them all the way, feel free. The code (and three quick examples, one that indents a JSON file for readability, a JSON-to-pike-literal translator and a minifier, the latter of which is particularly un-recommended to use for anything but data in the printable ASCII range) is here: http://svn.devjavu.com/ecmanaut/trunk/tools/json/ http://ecmanaut.devjavu.com/projects/ecmanaut/changeset/5 The latter URL is a Trac view of the initial commit, for the curious. Both encoder and decoder only really handle Pike native types. Neither verifies the correctness of their input/output. The encoder will happily output illegal JSON if you feed it structures illegal according to the JSON specification (your mapping indices must be strings to produce valid JSON). It presently wastes some resources to sort keys of mappings, not letting you turn that off. It can not produce the three values null, true and false. It also does not quote strings properly, so control characters and Unicode escapes may not come out as legal JSON. And the APIs are lightly wrapped semi-smelly beasts. But I think those are my only gripes. :-) Usage is at least straight-forward (more detailed docs in the code): string encode_json( mixed data ); mixed decode_json( string|Stdio.File input );

2 2

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