Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

external modules
by Bill Welliver 06 Jul '04

06 Jul '04

I've run into some pretty pesky bugs while running external module compilations. Among other problems, they include "incompatible type selected for pike floats" and such. the problem seems to stem from run_autoconf doing funny things with autoheader generated includes. Basically what ends up happening is that run_autoconf runs autoheader, and you end up with a config.h that contains acconfig.h, which has all of the required definitions undefined (the defined version is machine.h, which should get included anyhow). If I comment out the run_autoconf line from dynamic_module_makefile, the modules compile correctly as they had previously (2 months ago or more). This seems to be a relatively new problem. Any idea what a solution to this might be? Perhaps not running run_autoconf when we're building external modules? Bill

1 0

Module sources
by Kaos ＠ Pike developers forum 06 Jul '04

06 Jul '04

Hi, I'm trying to compile the sample module[1] but ends up with a configure error: configuring in Hello running /bin/bash /home/kaos/dev/Pike/7.4/src/modules/../configure --prefix=/home/kaos --without-GL --without-GLUT --without-GTK --without-Image --without-Crypto --without-Gdbm --without-SDL --cache-file=../.././config.cache --srcdir=/home/kaos/dev/Pike/7.4/src/modules/Hello configure: error: can not find sources in /home/kaos/dev/Pike/7.4/src/modules/Hello configure: error: /home/kaos/dev/Pike/7.4/src/modules/../configure failed for Hello configure: error: /home/kaos/dev/Pike/7.4/src/modules/configure failed for modules make: *** [configure] Error 1 Pike (7.4 from CVS) compiles fine if I remove the Hello module from the source tree. System (build dir): linux-2.4.25-gentoo-i686 Tried to look at other modules configure.in and Makefile.in, but none of my attempts to adapt have had any success. I'm not a make/configure veteran, so I may have missed a tiny obvious detail, but the files should (as stated on the site) compile as is. I did try to put it in post_modules, but made no differ. Any hints welcome. Thanks, Andreas -- (1) http://pike.ida.liu.se/projects/docs/cmods/hello.tgz

2 2

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

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