Pike-devel November 2007

pike-devel@lists.lysator.liu.se

5 participants
14 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

pike-svn repo import into git
by Martin Bähr 23 Feb '08

23 Feb '08

hi, importing the pike-svn repo into git took 3 days. git-svn seems to have some issues there, as the process got slower and slower (and in the end git-svn had more than 300MB in ram (allocated 1GB)) the resulting repo had 178645 objects and a size of 1178MB. git-svn allocates another 1.5GB for statusinformation on each branch. (and because tags are branches, the 1729 tags result in as many branches) however, after packing, the resulting repo ocupies a mere 44MB!!! that alone is a good reason for me to use git, as it it gives me the whole repo in the same space as the checkout of a single revision in svn. you can clone this repo from http://www.iaeste.at/~mbaehr/pike-svn.git the svn import info is removed from that repo. when we switch to svn i'll try to make a repo available that contains the svn info to spare anyone else who wants ot use git-svn a 3day import. greetings, martin.

5 9

7.6 release plans?
by H. William Welliver III 07 Jan '08

07 Jan '08

Hi All, I was wondering if there were any plans to do a new 7.6 release in the near future. There's a bug that's critical for me in the .112 Mysql module that causes a segfault, that's been fixed in 7.6 CVS. Because of this, I was thinking about holding off on a release on my end if a new pike version was looming on the horizon. If not, that's okay, too, I can try to come up with a workaround. Bill

4 8

Nettle
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 27 Nov '07

27 Nov '07

Pike v7.6 release 117 running Hilfe v3.5 (Incremental Pike Frontend) > Crypto.DES3()->set_encrypt_key("\x01\x23\x45\x67\x89\xab\xcd\xef"+"\x01"*8); DES3_INFO: Key is weak. src/post_modules/Nettle/cipher.cmod:785: Nettle.DES3_State()->set_encrypt_key("\1#Eg\211«Íï\1\1\1\1\1\1\1\1") HilfeInput:1: HilfeInput()->___HilfeWrapper() > Well, never you mind! I need to use this particular key for testing, and don't care that it's weak (it's just a test key anyway). The autodoc says /*! @decl CipherState set_encrypt_key(string key, void|int force) but that doesn't seem to work either: > Crypto.DES3()->set_encrypt_key("\x01\x23\x45\x67\x89\xab\xcd\xef"+"\x01"*8, 1); Compiler Error: 1:Too many arguments to set_encrypt_key. Compiler Error: 1:Expected: function(string : { this_program = object(implements 65740) }) Compiler Error: 1:Got : function(string, int(1..1) : void | mixed) > What gives?

1 1

Pike 7.8
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 25 Nov '07

25 Nov '07

Crosspost from user mailing list. This is the outcome of the technical side of this years Pike conference. We came to the conclusion that once the following list of items are fixed we are ready to release Pike 7.8. 1. New syntax for getters and setters. The previous syntax where mixed `->foo() {} void `->=foo(mixed v) {} created a virtual symbol foo in the class are now replaced with mixed `foo() {} void `=foo(mixed v) {} I say replaced, but the old syntax remains. Perhaps it should be changed to return syntax error before the release. Also there was a discussion about how modifiers should be handled. Currently the actual getter and setter functions are made private and the "union" of them are used as the visibility for the virtual symbol. This was argued against at the conference and I think the consensus was that the modifiers should apply to the getter and setter functions themselves and a "variable prototype" should be used to change the visibility of the virtual symbol (with the assumtion that typically you would want the virtual symbol public anyway). One (bizarre) example would be protected void foo; public int `foo() { return x; } private void `=foo(int y) { x = y*2; } The new syntax was implemented promptly, but as I said the old one still remains and nothing has been done w.r.t. the modifiers. 2. Adding a method for deprecating methods and symbols. This topic sparked a debate of how new modifiers can be introduced without having to reserve more keywords, with lots of ideas from other languages tossed around. These syntaxes (syntacies? :) were brought up [weak, shared] int f(); @weak @shared int f(); weak shared int f(); where the last one (keyword solution look alike) was most discussed for several reasons. It would not modify the look of the language by introducing extra syntax, but it would also be complicated to implement was the entire prototype has to be parsed backwards. It was also noted that parametrization of modifiers would be desirable, which would complicate the grammer even more. weak shared(Top) int(1..3) f(string s); The conclusion was that further studies needed to be done to solve the new keyword issue. This was not considered a problem for introducting a new deprecation method though, as it was not something anyone was concerned about the looks for. The agreed upon new keyword is __deprecated__, which when added to a symbol should generate a warning when this symbol is used. To supress deprecation warnings a new pragma directive, no_deprecated_warnings, should be added. 3. To pave the way for "real" static (or "shared" as we would call it to avoid confusion) the keyword "static" will be deprecated. While it technically has nothing to do with the __deprecated__ mechanism, its warnings will also be supressed by the new pragma. The (hopefully) not used keyword "nomask", which is an alias for "final" should also be deprecated. It was agreed that a semantic change in protected to make protected symbols accessible in other objects from the same class, was a good ides. 4. The iterator API should be changed to not use LFUNs, but instead more user friendly symbols. No compatibility layer that would enable both old and new iterators at the same time will be implemented due to the complexity (4 combinations of old/new iterator objects being looped over by code using the old/new API). There will of course be a #pike 7.6 mode to use the old API. 5. Support for mutliple backends to be selected between at runtime is something that is needed, since a Pike compiled with epoll support will not work on a system with only poll. 6. In some situations the Stdio.File and file.fd objects reference each other and leak objects/file descriptors. This should be fixed before Pike 7.8. 7. Martin Stjerholm wanted his work with Locale.Charset.EncodeError / DecodeError to be finished before 7.8. It was also suggested that Charset was moved to a top level module. 8. We need to ensure that there are no performance regressions in Pike 7.8. A quick profiling shows that we do have some performance problems which needs to be addressed. Some work begun immediatly by automatically finding between which versions performance dropped. Another action item was to make Pikefarm parse and save the benchmark data performed by xenofarm clients into a database and provide an interface to be able to query and graph the status. 9. The HTTPS regressions since Pike 7.6 should be fixed before Pike 7.8. This was most likely fixed during the conference. 10. The precompiler should move to Tools.Standalone so that cmods works as external modules properly. 11. One item that was discussed during the last day, and thus didn't make the "official" list of 7.8 items was how zero_type/UNDEFINED worked in Pike. After lot of discussions this was agreed upon: class A { int x = 0; int y = UNDEFINED; } A a = A(); zero_type( a->x ); // This should be 0 zero_type( a->y ); // This should be 1 zero_type( a->z ); // This should be 1 has_index( a, "x" ); // This should be 1 has_index( a, "y" ); // This should be 1 has_index( a, "z" ); // This should be 0 (So far this is how Pike currently behaves.) mapping m = ([ "x" : 0, "y" : UNDEFINED, ]); zero_type( m->x ); // This should be 0 zero_type( m->y ); // This should be 1 zero_type( m->z ); // This should be 1 has_index( m, "x" ); // This should be 1 has_index( m, "y" ); // This should be 1 has_index( m, "z" ); // This should be 0 Here the expression m->y will return 0 with zero type 0. This is due to all subtype flags being cleared by the mapping. For symmetry with with the object case this was agreed to to be changed.

10 32

JPEG issues
by Mirar ＠ Pike developers forum 17 Nov '07

17 Nov '07

Anyone had problems like this? | iris% pike | Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend) | > string s=Stdio.read_bytes("DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) | zsh: segmentation fault pike | iris% gdb `which pike` | ... | (gdb) run | [New Thread 47468888552080 (LWP 335)] | Pike v7.6 release 112 running Hilfe v3.5 (Incremental Pike Frontend) | > string s=Stdio.read_bytes("DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) It's in 7.6.112 to 7.7.39, at least. Image here: http://www.mirar.org/DSC00354.JPG Problem got bad when I upgraded to Ubuntu 7.10, but I'm not sure if that is because of a new jpeglib or a more paranoid glibc. AMD64. Sometimes I get this: | Pike v7.7 release 39 running Hilfe v3.5 (Incremental Pike Frontend)> string s=Stdio.read_bytes("www/DSC00354.JPG"); object img=Image.JPEG.decode(s); img->scale(632,474); string t=Image.JPEG.encode(img,(["quality":95])); | (1) Result: Image.Image( 632 x 474 /* 877.6Kb */) | *** glibc detected *** pike-7.7: double free or corruption (out): 0x0000000000a38490 *** | ======= Backtrace: ========= | /lib/libc.so.6[0x2ac4e5d7eb0a] | /lib/libc.so.6(cfree+0x8c)[0x2ac4e5d826fc] | /usr/lib/libjpeg.so.62[0x2ac4e76b9ffa] | /usr/lib/libjpeg.so.62[0x2ac4e76ba0fb] | /usr/lib/libjpeg.so.62(jpeg_destroy+0x10)[0x2ac4e76b9540] | /usr/local/pike/7.7.39/lib/modules/_Image_JPEG.so[0x2ac4e7483cb8] | /usr/lib/libjpeg.so.62[0x2ac4e76a98ea] | /usr/lib/libjpeg.so.62[0x2ac4e76a6fca] | /usr/lib/libjpeg.so.62[0x2ac4e76a5ef6] | /usr/lib/libjpeg.so.62(jpeg_write_scanlines+0x9f)[0x2ac4e76a2dff] | /usr/local/pike/7.7.39/lib/modules/_Image_JPEG.so[0x2ac4e7485bb9]

1 0

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