Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

Dynamic modules
by Kaos ＠ Pike developers forum 06 Jul '04

06 Jul '04

I'm having a look at load_module() on my Win2k box, trying to load a custom made .dll file (if I haven't missunderstood the intentions of this function). However, I get an error message with "PE images not supported yet". Looking at the source, I can see where I get this message, but I don't understand how I end up there (dlopen.c). I thought the load_module would wind up in f_load_module in dynamic_load.c, which has its own set of dlopen functions, which seems to use the windows dll functions already.. what am I missing this time? ;o)

1 0

Pike-SSL guru?
by Stephen R. van den Berg 06 Jul '04

06 Jul '04

Do we have one? -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me."

1 0

Warnings from startup script
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 06 Jul '04

06 Jul '04

>I just checked in a patch to Pike to get rid of that silly "Expected >efun constan" in the logfile. The patch works, I'm just wondering if >the patch doesn't have any other unexpected side-effects. The check is there for a reason... Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN? >The loading is so much faster now, the memory usage is down, the >logfiles are clean(er). The logfiles are cleaner as long as those werrors aren't called... / Henrik Grubbström (Lysator) Previous text: >2004-07-03 02:43: >Subject: Warnings from startup script >-------------------------------------------------------------------- >I just checked in a patch to Pike to get rid of that silly "Expected >efun constan" in the logfile. The patch works, I'm just wondering if >the patch doesn't have any other unexpected side-effects. > >The loading is so much faster now, the memory usage is down, the >logfiles are clean(er). > > / Stephen R. van den Berg >

8 58

Warnings from startup script
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 03 Jul '04

03 Jul '04

When is it correct that something that was an efun on encode shouldn't be one at decode? Maybe your problem is in the codec instead? / Martin Stjernholm, Roxen IS Previous text: >2004-07-03 02:43: >Subject: Warnings from startup script >-------------------------------------------------------------------- >I just checked in a patch to Pike to get rid of that silly "Expected >efun constan" in the logfile. The patch works, I'm just wondering if >the patch doesn't have any other unexpected side-effects. > >The loading is so much faster now, the memory usage is down, the >logfiles are clean(er). > > / Stephen R. van den Berg >

4 3

Drowning in the Shuffler (SEGV)
by Stephen R. van den Berg 02 Jul '04

02 Jul '04

Picture this: ChiliMoon 2004, http.pike uses the Shuffler object. It works fine (after a few modifications to the do_log callback), except when I call up a CGI program. cgi.pike uses a wrapper that uses a pair of pipes to pass the data along. Now, doing an add_source for shuffler with the proper end of the pipe, will result in the pipe being read correctly (once, total amount read, no followup read that should have detected the end). After that, the content of that read() is lost. Trying something different, I add three add_source() calls before, and three add_source() calls after the add_source() for the pipe. The three preceding and trailing add_source() calls have a fixed string content. What happens now is: Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9081d48 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9f64770 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45038 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9f5d690 <<-- pipe Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45068 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45098 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c988c8 <<-- const string Shuffle[0x9c98b00]:set_done_callback(0x8d0141c) Shuffle[0x9c98b00]:start() Shuffle[0x9c98b00]:_set_callbacks() Shuffle[0x9c98b00]:__set_calllbacks(Pike) ...CGIWrapper is being done... Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): sending(48) Shuffle[0x9c98b00]:__send_more_callback(): sending(48): sent 48 Shuffle[0x9c98b00]:_give_back(8144) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9081d48 Shuffle[0x9c98b00]:__send_more_callback(): sending(46) Shuffle[0x9c98b00]:__send_more_callback(): sending(46): sent 46 Shuffle[0x9c98b00]:_give_back(8146) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Without the patch attached below, the argument to __send_more_callback becomes -2 (from the leftovers.len), and the program crashes with a SEGV shortly after removing the callbacks. With the patch, the following happens: Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45038 Shuffle[0x9c98b00]:__send_more_callback(): read pending Shuffle[0x9c98b00]:__remove_calllbacks(Pike) Shuffle[0x9c98b00]:_give_back(8192) Shuffle[0x9c98b00]:_set_callbacks() Shuffle[0x9c98b00]:__set_calllbacks(Pike) However, at this point: - Data has been read from the CGIWrapper - But no trace of that appears in the output - I.e. in the output the six constant strings simply stick together. Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9f5d690 Shuffle[0x9c98b00]:__send_more_callback(): sending(17) Shuffle[0x9c98b00]:__send_more_callback(): sending(17): sent 17 Shuffle[0x9c98b00]:_give_back(8175) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45068 Shuffle[0x9c98b00]:__send_more_callback(): sending(16) Shuffle[0x9c98b00]:__send_more_callback(): sending(16): sent 16 Shuffle[0x9c98b00]:_give_back(8176) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45098 Shuffle[0x9c98b00]:__send_more_callback(): sending(15) Shuffle[0x9c98b00]:__send_more_callback(): sending(15): sent 15 Shuffle[0x9c98b00]:_give_back(8177) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c988c8 Shuffle[0x9c98b00]:__send_more_callback(): no sources Shuffle[0x9c98b00]:_give_back(8192) Shuffle[0x9c98b00]:_all_done(0) Shuffle[0x9c98b00]:_all_done(0): Calling done callback: 0x8d0141c Shuffle[0x9c98b00]:sent_data() --> 189 Shuffle[0x9c98b00]:_remove_callbacks() Shuffle[0x9c98b00]:__remove_calllbacks(Pike) Shuffle[0x9c98b00]:exit() Now, besides this patch, which prevents it from segfaulting, I'm a bit lost now. The shuffler innards are a maze of twists, turns and callbacks. I must be close, but the non-linear program flow is difficult to decipher. -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "Very funny, Mr. Scott. Now beam down my clothes!"

8 41

#if constant again
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 02 Jul '04

02 Jul '04

I see Nilssons latest changes has broken the #if constant check again. Is it intentional since there still seems to be a difference in opinion on that, or is it just a confused attempt to make the warning at master.pike:586 optional? In 7.6, the errors for placeholders also are relegated to warnings. Nilsson, can you explain that? Btw, I applaud the initiative to add Pike_vsnprintf. The implementation is a bit simplistic, but it's a start. It does handle wide strings correctly, doesn't it?

2 1

Interpreter locks, I/O, FD_BOXES and the Shuffler
by Stephen R. van den Berg 01 Jul '04

01 Jul '04

As I understand it, the Shuffler, before the callback mechanism was changed in the backend, was using a method which bypassed the Pike interpreter lock to actually shuffle out large amounts of data. How do I check if the new method exercises the lock or not? What do I need to watch out for if I'd like to improve on that? -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "The difficult we do today; the impossible takes a little longer."

1 0

Regexp.PCRE problem
by Alexander Demenshin 27 Jun '04

27 Jun '04

Hi, There is one problem with Regexp.PCRE when study() is called (or Regexp.PCRE.Studied()). exec() code (in cmod) contains the following: ---snip--- #ifdef PCRE_EXTRA_STUDY_DATA if (THIS->extra) opts|=PCRE_EXTRA_STUDY_DATA; #else /* FIXME: Throw an error if THIS->extra is set? */ #endif /* PCRE_EXTRA_STUDY_DATA */ ---snip--- and opts will be used later in call to pcre_exec(), but.. this is a bit incorrect, since this option should be set not in the call to pcre_exec(), but in pcre_extra struct (field "flags"). Hence, any call to exec()/split() etc. for studied PCRE gives an error (with PCRE 4.4): > Regexp re = Regexp.PCRE("([a-z]+)"); > re->split("123abc123"); error returned from exec: ERROR.BADOPTION In case of PCRE 3.9, it passes by, but it is only because there is no symbol PCRE_EXTRA_STUDY_DATA defined. Additionally, PCRE doc says (man pcreapi): ---snip--- Other flag bits should be set to zero. The study_data field is set in the pcre_extra block that is returned by pcre_study(), together with the appropriate flag bit. You should not set this yourself, but you can add to the block by setting the other fields. ---snip--- So, there is absolutely no need to pass any options to pcre_exec() call while handling exec(). I would commit a fix, but I am not sure how to regenerate file pcre_glue.cmod.compiled - or is it enough to make change in cmod and .compiled will be (re)generated automatically? Also, side note - the ovector size is defined as 3000 - isn't this an overkill for most cases? It will consume 12K of stack space with every call to exec() (at least, this space is not dynamically allocated, which would be even worse). Regards, /Al

3 3

Regexp.PCRE problem
by Mirar ＠ Pike developers forum 27 Jun '04

27 Jun '04

I'll patch away those lines now.

1 0

Language Shootout
by Peter Bortas (Kein Paket!) ＠ Pike (-) developers forum 23 Jun '04

23 Jun '04

It seems someone has taken it upon himself to maintain the Great Computer Language Shootout for a bit again: http://shootout.alioth.debian.org/

4 7

Jump to page:

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