Pike-devel

pike-devel@lists.lysator.liu.se

4 participants
3044 discussions

call_callback
by Mirar ＠ Pike developers forum 08 Dec '03

08 Dec '03

Is there any utility function in Pike that does the following, or an approximate? void call_callback(function f,mixed ... args) { mixed err; err=catch { f(@args); return; }; werror(master()->describe_backtrace(err)); } ...preferably with typechecking. I find that I would like to put a wrapper around my callbacks a lot of the time, to be certain that the code following still is run even if the user (of my library-ish routines) makes an error.

4 6

Problems with MIME.Message
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 06 Dec '03

06 Dec '03

>The first one is a typical problem I get with mails from Eudora. You can >find the mail at http://qo-op.com/break_mime.txt The problem with this one is that the boundary delimiter of the outer multipart occurs as a prefix of the boundary delimiter for the inner multipart. RFC2046 explicitly forbids this: As stated previously, each body part is preceded by a boundary delimiter line that contains the boundary delimiter. The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line. This implies that it is crucial that the composing agent be able to choose and specify a unique boundary parameter value that does not contain the boundary parameter value of an enclosing multipart as a prefix. Complain to the makers of Eudora. >Next is the error log I get from the LMTP server included in Pike 7.5. >It shows that MIME.Message simply brokes really too much. I run the LMTP >server with Pike 7.2.526 in Caudium. The problem here is the Content-Type line: Content-Type: text/html;iso-8859-1 This is a syntax error. It's supposed to be Content-Type: text/html;charset=iso-8859-1 Again, it's the mail that is broken, not MIME.Message. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-12-05 16:20: >Subject: Problems with MIME.Message >-------------------------------------------------------------------- >Hi, > >Last time I mail the Pike devel list about problems with MIME, you ask >me for some examples. Here are some I get on a production server. >I contact your privately since some of the data you can find in these >emails are private. > >The first one is a typical problem I get with mails from Eudora. You can >find the mail at http://qo-op.com/break_mime.txt > >With Pike 7.2.526 it fails with: > >multipart message improperly terminated >/usr/local/pike/7.2.526/lib/modules/MIME.pmod:880: > create("Content-Type: >multipart/related;\n\ttype=\"text/html\";\n\tboundar > y=\"=====================_197842502==_.REL\"\n",0,0) > >MIME: Message() > >And with 7.4.31: > >boundary missing from multipart-body >/usr/local/pike/7.4.31/lib/modules/MIME.pmod/module.pmod:1080: > MIME.Message()->create("Content-Type: >multipart/related;\n\ttype=\"text/ht > >ml\";\n\tboundary=\"=====================_197842502==_.REL\"\n",0,0,0) >object_program(MIME): MIME->Message() >/usr/local/pike/7.4.31/lib/modules/MIME.pmod/module.pmod:1100: > MIME.Message()->__lambda_65685_4_line_1090("Content-Type: >multipart/relate > >d;\n\ttype=\"text/html\";\n\tboundary=\"=====================_197842502==_ > .REL\"\n") > > >Next is the error log I get from the LMTP server included in Pike 7.5. >It shows that MIME.Message simply brokes really too much. I run the LMTP >server with Pike 7.2.526 in Caudium. > >I've added the following debug at line 869 of MIME.pmod to help debugging: > >write("headers[\"content-transfer-encoding\"]=%s\n", >headers["content-transfer-encoding"]); >array(string) arr=tokenize(headers["content-transfer-encoding"]); >write("arr=%O\n", arr); > >The log file also contains all the contents of the mail. I've tried to >find out where the problem but I didn't succeed. > >You can find the log file at http://smtp.linkeo.org/error_log.gz > >-- David Gourdelier > > > > / Brevbäraren >

1 0

Pike benchmarks
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 05 Dec '03

05 Dec '03

Some new benchmarks 7.2.550 vs 7.4.35 vs 7.5.13 using shootout tests: Pike7.2 Pike7.4 Pike7.5 1: 5.62 4.50 2.52 (ackermann) 2: 10.27 6.72 6.84 (ary3) 3: 8.55 6.62 6.42 (fibo) 4: 5.92 4.78 4.61 (hash) 5: 11.05 7.22 6.09 (heapsort) 6: 7.46 6.69 6.56 (lists) 7: 8.19 8.25 6.09 (methcall) 8: 54.21 5.91 6.47 (nestedloop) 9: 6.04 5.23 4.99 (objinst) 10: 7.29 4.79 5.21 (random) 11: 9.95 6.71 4.54 (sieve) 12: 3.13 2.33 2.50 (strcat) Scoring based on position in tests (should probably be updated to include difference in percent): 1: Pike7.5 32 2: Pike7.4 27 3: Pike7.2 13

2 9

Types
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 04 Dec '03

04 Dec '03

As an experiment I changed the type of stringp to tOr(tFunc(tStr,tInt1),tFunc(tNot(tStr),tInt0)) That does however cause compilation warnings that I think are wrong: Getopt.pmod:109: Warning: Calling non-function value. Getopt.pmod:109: Warning: Type called: function(string : int(1..1)) | function(!string : int(0..0))

2 2

C Autodocs
by Bill Welliver 04 Dec '03

04 Dec '03

I've run into what appears to be a limitation in the C autodoc extractor. The problem is that I want to have documentation in a module for a non-root module, such as System.PAM. Currently, that's not possible, and it failes with the following error: DocParser error: "@module: expected module name, got \" System.PAM\"" Tools.AutoDoc.DocParser.AutoDocError(SourcePosition(File: pam.cmod, lines: 60..60), "DocParser", "@module: expected module name, got \" System.PAM\"") Is there another way to do this, or does it require a change to the extractors? What would it take? I'm not familiar enough with the extractors to know where to begin (it looks some real monsters live in the code). If it were possible, would i still be able to add extra docs for the Pike portion? I don't think it would be as useful to have a little line about the pike module inheriting ___PAM or such. Any thoughts? Bill

2 2

More benchmarks
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 03 Dec '03

03 Dec '03

Ok, I guess we are closing in on making a 7.6 release. This is the current shootout benchmark status against some other similar languages. Java PHP Perl Pike Python Ruby TCL 1: 3.60 12.56 4.91 0.63 4.59 9.40 Failed (ackermann) 2: 1.68 11.91 4.76 1.40 3.06 8.61 15.19 (ary3) 3: 2.89 12.13 6.37 1.55 4.46 7.00 11.63 (fibo) 4: 7.94 5.98 5.72 4.69 3.83 18.67 7.75 (hash) 5: 1.48 8.62 3.47 1.09 2.48 6.30 8.33 (heapsort) 6: 5.46 Missing 3.19 2.70 4.73 2.44 27.44 (lists) 7: 2.17 Missing 5.90 1.83 4.76 3.38 Missing (methcall) 8: 7.27 Failed 17.91 0.91 13.95 35.87 34.39 (nestedloop) 9: 3.61 Missing 12.99 3.37 5.99 6.16 Missing (objinst) 10: 1.81 5.80 2.23 1.43 2.92 5.93 5.87 (random) 11: 6.57 Failed 12.19 4.52 9.16 18.39 50.59 (sieve) 12: 3.12 4.50 2.32 1.90 4.21 3.80 7.02 (strcat) I have altered the lists test to use arrays, as intended, and not strings (which lowers the time from 13.1 seconds to 2.7). The languages are gcj/gij 2.3 (the compilation time is included), PHP 4.3.4RC3, Perl 5.8.2, Pike 7.5.13, Python 2.3.2, Ruby 1.8.0 and TCL 8.3. In the year since last benchmark we can see some significant improvements in the Python performance, almost 50% in many tests (though it is still not possible to run ackermann(3,9) without running out of stack). Perl is also doing good with about 25% better since 5.8.0. From test 8 we can see that multipass strength reduction isn't implemented in any other language. On the whole it looks like Perl and Python is now only twice as slow as Pike, so we better watch out...

9 13

More benchmarks
by Niels M�ller (igelkottsr�ddare) ＠ Pike (-) developers forum 02 Dec '03

02 Dec '03

And in English: It might be relevant to also have figures without the compilation time, for Java and other languages where one can choose to do some or all of the compilation work separately.

1 0

Process.create_process() and rlimits
by Bill Welliver 01 Dec '03

01 Dec '03

This message includes a little background, so please read on... I've been beating my head against a wall for the past two days trying to figure out why a perl CGI wasn't running. It turns out that it was being killed automatically by the process creator (Process.create_process) in the CGI module. Despite giving it quite generous (basically unlimited) limits, it was still being stomped on. I commented out the following code (options is passed to Process.create_process): if(limits) options->rlimit=limits; And now everything is working as it should. I don't know what the problem might be, but it was a simple perl script (I pared it down to test), and the line that seemed to make the difference between working and not was: use Sybase::CTLib; First, I think something's funny with the limits support if this simple program was getting killed. Second, has anyone else had similar problems? The rlimit in question looks like this: "rlimit":([ /* 3 elements */ "core":0, "cpu":60, "nofile":64 ]) This program runs in about 1 second from the command line. Also, FWIW, this problem is present in Caudium 1.2 (pike 7.2) and 1.3 (7.4). Any thoughts? Bill

2 1

System.PAM module
by Bill Welliver 01 Dec '03

01 Dec '03

I put together a glue to the Pluggable Authentication Modules framework over the weekend. I've made it available to anyone who'd like to test it at the following address: ftp://ftp.riverweb.com/pub/hww3/pike_modules/System_PAM-1.0.tar.gz This requires a relatively recent version of Pike 7.5, ie .12 or .13 should be fine. The module is documented, though the autodoc extraction for C modules isn't currently working properly. Look at pam.cmod for the raw autodocs. If you're familiar with PAM, you shouldn't have any problems using this, and there are a few examples included. I'd also be interested to hear of any design improvement type suggestions that might be floating out there, as this is my first "real" C module. I've built this module on Solaris and Linux, and have tested it under Solaris. I've tested it with dmalloc, so it shouldn't have any built in memory leaks during normal operation, but I've noticed the Solaris PAM implimentation seems to leak regardless depending on your authentication configuration (eg LDAP). Bill

2 1

module documentation
by Bill Welliver 30 Nov '03

30 Nov '03

I've run into a problem with building module documentation outside the pike tree: when a documentation build directory is within the documentation source directory, you end up with a recursion loop. this is because extract_autodoc creates a parallel tree inside of the documentation build directory, and once the extractor descends into the documentation build directory, it never reaches the end of the directories to recurse. The problem came up because autodoc markup is not extracted from C/CMOD source files using the new extract targets. I wanted to add this, but ran into the problem above. As far as I can see, there are 3 avenues: 1. build documentation outside of the documentation source directory (ie the module build directory) i don't think that this is a very good option, as it only masks the problem. 2. add a check in extract_autodoc.pike to check for the problem and stop recursing into the documentation build directory this stops the problem above, but seems to create a problem with duplicate documentation for the module in question (it ends with an error to this effect). 3. add a separate target that will extract documentation for files specified in the makefile, as say AUTODOC_C_INPUT or something, then extract the pike autodoc as normal. this would require extract_autodoc to be modified to be able to extract from a source file, rather than a directory. Anyone have any constructive thoughts about the problem in general and a solution to it? Bill

1 0

Jump to page:

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