Menu
▾
▴
Re: [Rlib-users] patch, problems, question
|
From: Shannon W. <swe...@ro...> - 2005-05-13 14:30:06
|
Bob Doan wrote:
> Hi
>
>
>>I've got a patch for html.c that adds a "suppress_head" parameter to not
>>output the <body> and <head> tags. It's in my cvs tree - is there a way
>>to commit it or should I send a patch to the list (or you)?
>
>
> Unified diff please.
>
> Can you send it to rli...@li...
>
Ok, sent.
>
>
>>Secondly - I've been having a segfault problem lately that started a few
>>weeks ago (from CVS build). What happens is when rlib has an error (say
>>a BAD_OPERAND or bad SQL) it will segfault, the apache child will die,
>>and it won't print out an error message - I just see a message in apache
>>error log that the child died. However it only happens after it's been
>>running for awhile - if I immediately restart the server it will run ok
>>and rlib will show the error message. If it's been running for more than
>>5 or 10 minutes say, that's when it crashes.
>>
>>I wish I had time to track it down more than that, but I haven't at the
>>moment. I realize it will be hard to look into unless it can be
>>duplicated. It's more if a heads up and to see if anyone else is
>>experiencing this.
>
>
> Hym... Dunno. We have The lasted RLIB in a production environment and
> it's not crashing.
>
Are you using it with PHP 4.3.x under Apache 1.3.x?
When I get a chance I'm going to run it under gdb and see where the
segfault lies - or at least find a way to consistently reproduce it.
>
>>Thirdly, I'm interesting in adding support to the PHP binding to lookup
>>a variable in a hash (in addition to a single variable, as now). I
>>figure this can be done with another attribute to the <field> tag -
>>"index" for example. I looked into it a bit and I can add this much to
>>php/environment.c if rlib_php_resolve_memory_variable gets two
>>parameters. I can see where to add it to the structure to keep the
>>"index" string (in parsexml.c). The tough part is pcode.c -- how can I
>>get access to that index string in rlib_new_operand?
>>
>>Or, what's the better way to implement it?
>
>
> Well.. Hym...... In the long term it would be good if RLIB could hash
> and haves lists(arrays) of data for other purposes.
>
> This would be kinda hard.
>
> What would be easier to be able to pass RLIB custom functions (even from
> binding languages like PHP)
>
> So some new api like
> rlib_add_function(r, "custom_function", pointer_to_function)
>
> Then in the xml you could:
> <field value="custom_function('ht_name', 'ht_value')">
>
> In order to do this we would have to also make public rlib's stack
> (push, pop)
>
> In php you would do:
>
> function custom_function() {
> $ht_value = rlib_SPECIAL_POP($rlib);
> $ht_name = rlib_SPECIAL_POP($rlib);
> $value = $$ht_name[$ht_value];
> $ht_name = rlib_SPECIAL_PUSH($rlib);
> }
>
>
> Freaky eh?
>
Definitely. The ability to hook into a custom function would be great.
The PHP interface seems a little low level, though, I wonder if there's
a way to hide some details.
If it gets that far, it might not be too much of a stretch to run built
in PHP functions on rlib data. That would open up a great wealth of
functions, obviously.
In the short term however, can you think of a way to get
rlib_php_resolve_memory_variable access to an optional index string so
that if Z_TYPE_PP(data) == IS_ARRAY it can look it up?
Thanks,
Shannon
|
