Pike-devel February 2008

pike-devel@lists.lysator.liu.se

6 participants
8 discussions

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

15 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

Fully tracked git repositories of Pike/Roxen/Chilimoon/Caudium
by Stephen R. van den Berg 25 Feb '08

25 Feb '08

I've setup 2 permanent and live git-mirrors: one for Pike (called pike) and one for Roxen/Chilimoon/Caudium (called roxen). I.e. they are both synced with the CVS versions at 06:00 every day. For Pike: git-clone git://git.cuci.nl/pike For Roxen/Chilimoon/Caudium: git-clone git://git.cuci.nl/roxen Use "git-branch -r" to view all the tracked branches. E.g. "git-log origin/7.6" to view the complete history of the pike 7.6 tree. As for Pike, I reconnected the source tree beyond what was done in the SVN dump earlier. I.e. all Pike branches now share a common origin and ancestry at Wed Aug 9 10:21:42 1995, the first checkin of ulpc.old. The repositories are clean and complete, and could be used as an instant master if anyone would like to abandon the CVS repositories. Any suggestions as to possible incorrectness of the repositories are welcome. I'm quite proficient with git and reconnecting history at the moment, so any amendments shouldn't take long. Some interesting trivia perhaps: the whole source repository, including all history of all Pike versions is about 36MB in size, and for all Roxen revisions the full-history source repository is about 24MB in size, Caudium adds another 13MB. Incidentally, in trying to sync the old Roxen versions, I got an error in Roxen 1.3, the file /cvs/Roxen/1.3/server/nfonts/32/bell_gothic/bn,v seems to contain a bogus revision number: "unexpected '\x0' reading revision number in RCS file" So that branch is not synced beyond the main developmentline. In order to fix this, either that file needs to be fixed, or deleted (temporarily?) or I'd need a personal copy of the RCS files of 1.3; can any of those options be arranged (mast/grubba?)? P.S. It is, of course, possible to create a "roxen" git without either Roxen or Caudium; but since it (at best) saves you 24MB or 13MB in space, it's not really a big problem. If one should insist, removing the offending tags from the repository, then repacking it, will shrink the size. P.P.S. If anyone wonders why the original git archive is smaller than what you find on your own disk after cloning my versions, that's because you didn't try running "git-repack -d -a -f --window=100" yet. -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "Good moaning!"

2 3

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

debian package of pike (and caudium)
by Henrik Andreasson 23 Feb '08

23 Feb '08

Hi! How is it going with the debian packages of pike, anything I can to to help? The package is still owned by debian-qa-team maybe a new version that adopts the package would be good? Shamless request: I'm going to take over the caudium package but I'm not yet a debian developer so maybe somebody on the list could help me in the beginning with the uploads? //Henrik Andreasson "kinneh"

8 9

ASN.1
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 15 Feb '08

15 Feb '08

I just saw that Crypto.SHA1 and Crypto.SHA256 are missing the asn1_id method. Looking at the old crypto library the id should be /* * SHA1 OBJECT IDENTIFIER ::= { * iso(1) identified-organization(3) oiw(14) secsig(3) * algorithm(2) 26 * } * * 0x2b0e 0302 1a */ static char sha_id[] = { 0x2b, 0x0e, 0x03, 0x02, 0x1a, }; or > (string)({ 0x2b, 0x0e, 0x03, 0x02, 0x1a }); (1) Result: "+\16\3\2\32" but actually encoding it from start generates > Standards.ASN1.Types.Identifier(1,3,14,3,2,26)->get_der(); (2) Result: "\6\5+\16\3\2\32" Why are the leading bytes missing/added? Similar discrepancies can be seen for MD2/MD4/MD5. SHA256 has an PKCS id (2.16.840.1.101.3.4.0.1) that should be added to that algorithm, if we can only figure out if the two extra bytes at the beginning should be there.

2 3

Sprintf wrap removes space
by C. Schalkwijk 07 Feb '08

07 Feb '08

Thanks for the leads, but the problem with the proposed solution is that the code wrapping the text is used in a generic way. The code processes fields containing data. It wraps text in such a way that it fits the field's dimensions, without word breaks! Therefore I need the text to remain absolutely unchanged (other than inserting an EOL) and still prevent word breaks. In my opinion, removing characters from a string (when not requested) is faulty behaviour and should not occur. 'possibly skipping or adding spaces' is not desired. Greetings Coen __________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

4 11

sprintf wrap removes space
by C. Schalkwijk 04 Feb '08

04 Feb '08

the following string: "\6\6\6\6\6\6\6\6\6\6\6 \3\6\6" results in: "\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n*\6\n\3*\n\6\n\6" when using: "%-=*s" (width set to 1 (one)) While I want it to be: "\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n\6\n*\6\n \n\3*\n\6\n\6" What am I doing wrong? Thanks in advance! __________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

3 5

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 2008