rlib-devel — RLIB Development Mailing List

[Rlib-devel] Bug

[Lisa M. K. <li...@re...>]

Folks,
    We are considering the rlib reporting engine for an important 
application.  We
are trying to prototype some of our reports, which can involve very 
large amounts
of data. I have had a problem  in which the number of data lines printed 
in a break section seems
to depend pretty strongly on the order of the fields, and in no case is 
the full number of data lines
printed (5000).  I am enclosing a sample data file (cgrdat*.xml) and two 
format files (cgrfmt*.xml)
so you can see the results for yourself (I have been running RLIB 1.3 on 
an HP platform).  We would
appreciate any help you can give us.  Certainly we need to solve this 
problem if we are
to purchase your product.

Many thanks,
Lisa Kowalski
AT&T

[Rlib-devel] RLIB 1.3.5 Released

[Bob D. <bd...@si...>]

Hey All,

RLIB 1.3.5 has been officially released.  It is not the same 1.3.5 that
I had on the SICOM Server. 

You can download it from sourceforge.

Changes from 1.3.4:

* Full Python Bindings (Thanks William!)
* Error Reporting w/ Line Numbers and Expressions!

Use:

rlib_set_output_parameter($rlib, "debugging", "yes");

If you want errors to come out in HTML Reports (This is really
handy!!!!)

The RLIB compiler continues to improve, and will even alert you to
"Parenthesis Mismatch" these days 

This ***MIGHT*** be the last release before the official 2.0 release.

Feedback is appreciated

Thanks!

- Bob

[Rlib-devel] New RLIB 1.3.5 Pre Release

[Bob D. <bd...@si...>]

Everyone,

I have a new RLIB 1.3.5 for testing.

Major Changes include:

1) Compiler bug fixes / regressing testing.  In RLIB 1.3.4 some
expressions were not compiling correctly.  RLIB was not always
respecting LEFT and RIGHT braces.

2) Full Python Bindings (Thanks William!)

3) Friendlier Compiler.  RLIB will now report Line # and Expressions
which caused Compiler Problems>

ex:
RLIB EXPERIENCED A FATAL MATH ERROR WHILE TRYING TO PREFORM THE
FOLLOWING OPERATION: ADD
        * Error on Line 17: The Expression Was [2+'hi']
        * DATA TYPES ARE [string] [number]


4) Errors reported by Environment (Php, Python, ect) instead of just out
stderr (making you look in the Apache error log)

Call:

rlib_set_output_parameter($rlib, "debugging", "yes");

And with HTML Output RLIB will output errors in HTML at the beginning of
the report.  It makes debugging easy


Let me know if I broke anything

Enjoy

- Bob

Re: Array interface and environment (was Re: [Rlib-devel] Example report XML files)

[Bob D. <bd...@si...>]

Nice!!!!!

Applied!

I'll try to get out an official 1.3.5 release.

- bob

On Tue, 2005-08-02 at 13:19 -0600, William K. Volkman wrote:
> Hello Bob,
> On Tue, 2005-08-02 at 10:26, Bob Doan wrote:
> > 
> > Cool.  Send it in when you get a chance and perhaps include an example
> > w/ all the callbacks working????
> 
> Attached you'll find a patch which updates the changed files and
> a .tar.gz file which provides the new files (unpack in rlib directory).
> The new files will have to be added to CVS.  The module
> bindings/interfaces/rlib.py (SWIG generated I think) has to become
> rlibcompat.py (to provide a backward compatible interface).  There
> isn't a replacement for it.  Instead the rlibmodule.c provides
> a full python C extension.  Example programs are in src/examples/python,
> after make install go into python and type:
> 
> >>> import rlib
> >>> help(rlib)
> 
> And you'll see the difference.
> 
> Cheers,
> William.
> 

Re: Array interface and environment (was Re: [Rlib-devel] Example report XML files)

[William K. V. <wk...@us...>]

Hello Bob,
On Tue, 2005-08-02 at 10:26, Bob Doan wrote:
> 
> Cool.  Send it in when you get a chance and perhaps include an example
> w/ all the callbacks working????

Attached you'll find a patch which updates the changed files and
a .tar.gz file which provides the new files (unpack in rlib directory).
The new files will have to be added to CVS.  The module
bindings/interfaces/rlib.py (SWIG generated I think) has to become
rlibcompat.py (to provide a backward compatible interface).  There
isn't a replacement for it.  Instead the rlibmodule.c provides
a full python C extension.  Example programs are in src/examples/python,
after make install go into python and type:

>>> import rlib
>>> help(rlib)

And you'll see the difference.

Cheers,
William.

Re: Array interface and environment (was Re: [Rlib-devel] Example report XML files)

[Bob D. <bd...@si...>]

> Well, since everyone is already passing the rlib struct pointer
> around it seemed convenient ;-)  Using ENVIRONMENT(r) I guess
> would be an option however ENVIRONMENT_PRIVATE(r) would not
> be a good choice.  The problem of course is that I would just
> end up storing a pointer to the rlib struct in the environment,
> which seems redundant.  I need the rlib pointer as that is the
> handle that I have to allow me to search through the objects
> setup to track the rlib instances and local data objects.
> The problem is not the single rlib report instance, it is
> the multiple co-existing ones.

Ok, I see.  I didn't realize you need to track based on the RLIB
instance.  PHP doesn't work that way... it kinda works by the included
module.

> > 
> 
> However the interface code already has to have access to a pointer
> to the rlib structure.  Expanding that to include
> 
> The problem with the string will always be how to resolve the scope,
> by passing the reference the scoping has already been done by the
> the language.  Actually I don't see how this could work in the
> C interface unless your searching the programs symbol table, is that
> the reason for your "should not be a char * but a gpointer now"?

No, it would make the API less confusing as we are actually passing a
real pointer and not a string.

> 
> Anyway I have completed an implementation of the python interface,
> it works pretty much the same as the php one does now.  I did
> add the rlib * to the resolve_memory_variable routine however
> I've not implemented any scoping resolution (same problem of
> documentation on internal operation of python).


Cool.  Send it in when you get a chance and perhaps include an example
w/ all the callbacks working????

- Bob

Array interface and environment (was Re: [Rlib-devel] Example report XML files)

[William K. V. <wk...@us...>]

Hi Bob,
On Mon, 2005-08-01 at 07:36, Bob Doan wrote:
> > I haven't had much time as things have be very busy at work however I
> > am now making pretty good progress.  The functionality is almost up
> > to the PHP interface however I've run into what I consider warts on
> > the interface.  With PHP you pretty much expect that the program
> > activate, process, and then die with every request so having a lot of
> > globals is kinda normal although that might change with PHP 5.
> > With python using globals is considered poor/lazy/hack programming.
> > The first issue, which can't be worked around if I'm going to get
> > the m.variable idiom to work, is that the "environment" needs
> > to track/store/pass a user variable to all of it's functions.
> > I need this to be able to do reference counting on python objects
> > as well as freeing temporary memory.  
> 
> I took a look at your pass rlib struct to the environment patch.  I
> don't really understand why we need to use the rlib struct.  Can't it
> just be a gpointer to something the environment mallocs then frees?

Well, since everyone is already passing the rlib struct pointer
around it seemed convenient ;-)  Using ENVIRONMENT(r) I guess
would be an option however ENVIRONMENT_PRIVATE(r) would not
be a good choice.  The problem of course is that I would just
end up storing a pointer to the rlib struct in the environment,
which seems redundant.  I need the rlib pointer as that is the
handle that I have to allow me to search through the objects
setup to track the rlib instances and local data objects.
The problem is not the single rlib report instance, it is
the multiple co-existing ones.
> 
> Other things like PHP, C can just ignore it.

As was done in the patch.

> I worry that if the environment (3rd party languages: PHP, Python, PERL,
> ect) have more direct acesss to that memory the odds of it being
> clobbered due to a programming mistake are greater.  And debugging those
> things are less then fun ;)

However the interface code already has to have access to a pointer
to the rlib structure.  Expanding that to include the environment
interface doesn't seem that onerous.  And precluding access seems
to be contrary to the point if you consider that the environment
is the environment of the rlib instance.

> > The second is with the
> > adding of the array datasource.  The add_datasource_array call just
> > says I'm going to give you one, the add_query_as passes the name
> > of the array as a string, which is then looked up in the global
> > name space.  My thought here would be to deviate from the other
> > implementations and have the add_datasource_array take a reference
> > to the array and then ignore the query string, this allows me to use
> > normal variable scope resolution so the array doesn't have to be global.
> > The problem of course is that deviations cause major confusion when
> > people are trying to port code (humm, now that I think about it I'll
> > have to look at what the C implementation does, I only looked at the
> > PHP one as that seems to be the predominant usage target).
> 
> This is a tough problem.
> 
> rlib_add_query_pointer_as already exists (Although I don't think its
> binded yet)
> 
> It's main difference is it doesn't strdup the sql pointer.  Although the
> sql pointer should not be a char * but a gpointer now that I think about
> it....
> 
> Maybe Both PHP and Python should support both ways or perhaps only
> "rlib_add_query_pointer_as".  I don't have a problem with the latter as
> it's more correct.  The reason it's global now is because I didn't know
> how to do it any better in PHP at the time due to lack of internal PHP
> documentation.

The problem with the string will always be how to resolve the scope,
by passing the reference the scoping has already been done by the
the language.  Actually I don't see how this could work in the
C interface unless your searching the programs symbol table, is that
the reason for your "should not be a char * but a gpointer now"?

Anyway I have completed an implementation of the python interface,
it works pretty much the same as the php one does now.  I did
add the rlib * to the resolve_memory_variable routine however
I've not implemented any scoping resolution (same problem of
documentation on internal operation of python).

Re: [Rlib-devel] Tweaks to graph example

[Bob D. <bd...@si...>]

Applied

On Sun, 2005-07-31 at 21:50 -0600, William K. Volkman wrote:
> I've made a couple of tweaks to the graph example.
> Patch attached.
> 

Re: [Rlib-devel] Example report XML files

[Bob D. <bd...@si...>]

> 
> I haven't had much time as things have be very busy at work however I
> am now making pretty good progress.  The functionality is almost up
> to the PHP interface however I've run into what I consider warts on
> the interface.  With PHP you pretty much expect that the program
> activate, process, and then die with every request so having a lot of
> globals is kinda normal although that might change with PHP 5.
> With python using globals is considered poor/lazy/hack programming.
> The first issue, which can't be worked around if I'm going to get
> the m.variable idiom to work, is that the "environment" needs
> to track/store/pass a user variable to all of it's functions.
> I need this to be able to do reference counting on python objects
> as well as freeing temporary memory.  

I took a look at your pass rlib struct to the environment patch.  I
don't really understand why we need to use the rlib struct.  Can't it
just be a gpointer to something the environment mallocs then frees?

Other things like PHP, C can just ignore it.

I worry that if the environment (3rd party languages: PHP, Python, PERL,
ect) have more direct acesss to that memory the odds of it being
clobbered due to a programming mistake are greater.  And debugging those
things are less then fun ;)


> The second is with the
> adding of the array datasource.  The add_datasource_array call just
> says I'm going to give you one, the add_query_as passes the name
> of the array as a string, which is then looked up in the global
> name space.  My thought here would be to deviate from the other
> implementations and have the add_datasource_array take a reference
> to the array and then ignore the query string, this allows me to use
> normal variable scope resolution so the array doesn't have to be global.
> The problem of course is that deviations cause major confusion when
> people are trying to port code (humm, now that I think about it I'll
> have to look at what the C implementation does, I only looked at the
> PHP one as that seems to be the predominant usage target).

This is a tough problem.

rlib_add_query_pointer_as already exists (Although I don't think its
binded yet)

It's main difference is it doesn't strdup the sql pointer.  Although the
sql pointer should not be a char * but a gpointer now that I think about
it....

Maybe Both PHP and Python should support both ways or perhaps only
"rlib_add_query_pointer_as".  I don't have a problem with the latter as
it's more correct.  The reason it's global now is because I didn't know
how to do it any better in PHP at the time due to lack of internal PHP
documentation.

Re: [Rlib-devel] postgre vs postgres

[Bob D. <bd...@si...>]

Applied

cvs update -dP is usually the way to go.  (-P prunes empty directories)

I generate the bindings in libsrc w/ this script: generate_bindings.sh

- Bob

On Sun, 2005-07-31 at 18:00 -0600, William K. Volkman wrote:
> Hi Bob,
> On Sun, 2005-07-31 at 07:52, Bob Doan wrote:
> > > 	I keep tripping over this, the PostgreSQL database
> > > is referred to as Postgres (it had common ancestry with
> > > Ingres) however RLIB whacks off the trailing "S" (probably
> > > because its part of SQL).  Any objection to my renaming
> > > all references to "postgre" to "postgres"? (perhaps leaving
> > > some #defines so I don't break everyones code).
> > > 
> > 
> > I went ahead and fixed it.  It's in CVS.  Can you make sure I didn't
> > break anything. 
> 
> Well apparently SWIG regenerated the wrapper for python and
> something got lost.  Patch attached, other than that there
> still is a inputs/postgre directory after I've done a 
> make clean; cvs update -Pd which is a bit confusing...
> I'll have to track down where SWIG gets run and remove
> the python target. 
> > 
> > We need to update the wiki *cough* *cough* ;)
> 
> *REAL* programmers don't need documentation, and the
> users, well they are already lost... ;-)
> 

[Rlib-devel] Tweaks to graph example

[William K. V. <wk...@us...>]

I've made a couple of tweaks to the graph example.
Patch attached.

Re: [Rlib-devel] postgre vs postgres

[William K. V. <wk...@us...>]

Hi Bob,
On Sun, 2005-07-31 at 07:52, Bob Doan wrote:
> > 	I keep tripping over this, the PostgreSQL database
> > is referred to as Postgres (it had common ancestry with
> > Ingres) however RLIB whacks off the trailing "S" (probably
> > because its part of SQL).  Any objection to my renaming
> > all references to "postgre" to "postgres"? (perhaps leaving
> > some #defines so I don't break everyones code).
> > 
> 
> I went ahead and fixed it.  It's in CVS.  Can you make sure I didn't
> break anything. 

Well apparently SWIG regenerated the wrapper for python and
something got lost.  Patch attached, other than that there
still is a inputs/postgre directory after I've done a 
make clean; cvs update -Pd which is a bit confusing...
I'll have to track down where SWIG gets run and remove
the python target. 
> 
> We need to update the wiki *cough* *cough* ;)

*REAL* programmers don't need documentation, and the
users, well they are already lost... ;-)

Re: [Rlib-devel] Example report XML files

[William K. V. <wk...@us...>]

On Sun, 2005-07-31 at 09:59 -0400, Bob Doan wrote:
> Right now really only PHP and C are fully supported. (Callbacks, arrays,
> ect)
...and python, coming soon ;-)

> But for Java,Python,Perl,C# 90% works really well.
> 
> I was hoping to move examples into the wiki for people to learn how to
> do things.
> 
> But so far only Carol and I have been doing things in the wiki, so it's
> going slow

If, as an initial start, you were looking to have the existing
documentation
imported into the wiki I might have some time next week to start doing
that.  If you were planning a complete re-write/reorganize/clean-up that
is a bit harder.

> 
> Also.. Any luck w/ doing Python callbacks??

I haven't had much time as things have be very busy at work however I
am now making pretty good progress.  The functionality is almost up
to the PHP interface however I've run into what I consider warts on
the interface.  With PHP you pretty much expect that the program
activate, process, and then die with every request so having a lot of
globals is kinda normal although that might change with PHP 5.
With python using globals is considered poor/lazy/hack programming.
The first issue, which can't be worked around if I'm going to get
the m.variable idiom to work, is that the "environment" needs
to track/store/pass a user variable to all of it's functions.
I need this to be able to do reference counting on python objects
as well as freeing temporary memory.  The second is with the
adding of the array datasource.  The add_datasource_array call just
says I'm going to give you one, the add_query_as passes the name
of the array as a string, which is then looked up in the global
name space.  My thought here would be to deviate from the other
implementations and have the add_datasource_array take a reference
to the array and then ignore the query string, this allows me to use
normal variable scope resolution so the array doesn't have to be global.
The problem of course is that deviations cause major confusion when
people are trying to port code (humm, now that I think about it I'll
have to look at what the C implementation does, I only looked at the
PHP one as that seems to be the predominant usage target).

Your input on these two issues appreciated.

Cheers,
William.

> On Sat, 2005-07-30 at 19:38 -0600, William K. Volkman wrote:
> > I notice that the products.xml file is in the "common" subdirectory
> > under examples however the major portion of xml files are located
> > in the php subdirectory.  Should they move to common or stay where
> > they are?

[Rlib-devel] Patch to pass rlib structure to environment resolve_memory_variable

[William K. V. <wk...@us...>]

Attached please find a patch that passes the rlib structure
to the resolve_memory_variable routine.  This allows
the python environment to be able to do reference counting
(a future patch).

Re: [Rlib-devel] Example report XML files

[Bob D. <bd...@si...>]

Well.....

Right now really only PHP and C are fully supported. (Callbacks, arrays,
ect)

But for Java,Python,Perl,C# 90% works really well.

I was hoping to move examples into the wiki for people to learn how to
do things.

But so far only Carol and I have been doing things in the wiki, so it's
going slow

Also.. Any luck w/ doing Python callbacks??

- Bob

On Sat, 2005-07-30 at 19:38 -0600, William K. Volkman wrote:
> I notice that the products.xml file is in the "common" subdirectory
> under examples however the major portion of xml files are located
> in the php subdirectory.  Should they move to common or stay where
> they are?
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel
-- 
Bob Doan <bd...@si...>

Re: [Rlib-devel] postgre vs postgres

[Bob D. <bd...@si...>]

Hi,

> 	I keep tripping over this, the PostgreSQL database
> is referred to as Postgres (it had common ancestry with
> Ingres) however RLIB whacks off the trailing "S" (probably
> because its part of SQL).  Any objection to my renaming
> all references to "postgre" to "postgres"? (perhaps leaving
> some #defines so I don't break everyones code).
> 

I went ahead and fixed it.  It's in CVS.  Can you make sure I didn't
break anything. 

We need to update the wiki *cough* *cough* ;)

- bob

[Rlib-devel] Example report XML files

[William K. V. <wk...@us...>]

I notice that the products.xml file is in the "common" subdirectory
under examples however the major portion of xml files are located
in the php subdirectory.  Should they move to common or stay where
they are?

[Rlib-devel] postgre vs postgres

[William K. V. <wk...@us...>]

Hello,
	I keep tripping over this, the PostgreSQL database
is referred to as Postgres (it had common ancestry with
Ingres) however RLIB whacks off the trailing "S" (probably
because its part of SQL).  Any objection to my renaming
all references to "postgre" to "postgres"? (perhaps leaving
some #defines so I don't break everyones code).

Thoughts?

Cheers,
William.

Re: [Rlib-devel] add_function capability and pcode.h

[Bob D. <bd...@si...>]

Applied

On Tue, 2005-07-19 at 20:37 -0600, William K. Volkman wrote:
> The attached patch modifies Makefile.am to include pcode.h in the
> list of installed header files.
> 
> On Tue, 2005-07-19 at 10:35 -0400, Bob Doan wrote:
> > My vote is to install pcode.h because if you are going to to make custom
> > RLIB functions you clearly know what you are doing and probably want
> > thew full pcode stack
> > On Mon, 2005-07-18 at 13:54 -0600, William K. Volkman wrote:
> > > 	I notice that pcode.h is not installed in /usr/include/rlib
> > > however to be able to write a function which can be "add"ed it
> > > pretty much needs defined:
> > > 
> > > rlib_value_stack_pop
> > > RLIB_VALUE_GET_AS_STRING
> > > RLIB_VALUE_GET_AS_NUMBER
> > > rlib_value_new_string
> > > rlib_value_new_number
> > > 
> > > So should those definitions migrate to rlib.h or (the quickest)
> > > add pcode.h to the list of installed headers.
> 

Re: [Rlib-devel] This seems new: Variable Resolution: Assuming 0 value because rval is ERROR or NONE

[Bob D. <bd...@si...>]

Because the variable was used in the Detail Header.  At the point the
variable does not exist (Which is probably not the correct thing)

But I just wanted to make things crash less under the hood to start.

On Wed, 2005-07-20 at 11:29 -0600, William K. Volkman wrote:
> Well I was curious as to why it felt that it had to substitute
> zero for a valid expression.  I will admit to not having
> read the code just yet.
> 
> On Wed, 2005-07-20 at 09:11, Bob Doan wrote:
> > I could probably take that out.  It was for debugging
> > 
> > 
> > 
> > On Wed, 2005-07-20 at 05:43 -0600, William K. Volkman wrote:
> > > In array.xml there is this fragment:
> > >         <Variables>
> > >                 <Variable name="bo" value="2+3" type="expression"/>
> > >         </Variables>
> > > Which appears to be causing this message from pcode.c
> > > Variable Resolution: Assuming 0 value because rval is ERROR or NONE
> > > Due to the "amount" portion not being valid.  I don't recall
> > > seeing this before, CVS update was done this evening, code was
> > > introduced:
> > > 
> > > 2005-07-19  Bob Doan  <bd...@si...>
> > >         * configure.in: 1.3.5
> > >         * libsrc/pcode.c: Tweek the compiler again / Make variables less
> > > picky and not crash on error
> > > 
> > > Is this doing what you expected?
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel

Re: [Rlib-devel] This seems new: Variable Resolution: Assuming 0 value because rval is ERROR or NONE

[William K. V. <wk...@us...>]

Well I was curious as to why it felt that it had to substitute
zero for a valid expression.  I will admit to not having
read the code just yet.

On Wed, 2005-07-20 at 09:11, Bob Doan wrote:
> I could probably take that out.  It was for debugging
> 
> 
> 
> On Wed, 2005-07-20 at 05:43 -0600, William K. Volkman wrote:
> > In array.xml there is this fragment:
> >         <Variables>
> >                 <Variable name="bo" value="2+3" type="expression"/>
> >         </Variables>
> > Which appears to be causing this message from pcode.c
> > Variable Resolution: Assuming 0 value because rval is ERROR or NONE
> > Due to the "amount" portion not being valid.  I don't recall
> > seeing this before, CVS update was done this evening, code was
> > introduced:
> > 
> > 2005-07-19  Bob Doan  <bd...@si...>
> >         * configure.in: 1.3.5
> >         * libsrc/pcode.c: Tweek the compiler again / Make variables less
> > picky and not crash on error
> > 
> > Is this doing what you expected?

Re: [Rlib-devel] This seems new: Variable Resolution: Assuming 0 value because rval is ERROR or NONE

[Bob D. <bd...@si...>]

I could probably take that out.  It was for debugging



On Wed, 2005-07-20 at 05:43 -0600, William K. Volkman wrote:
> In array.xml there is this fragment:
>         <Variables>
>                 <Variable name="bo" value="2+3" type="expression"/>
>         </Variables>
> Which appears to be causing this message from pcode.c
> Variable Resolution: Assuming 0 value because rval is ERROR or NONE
> Due to the "amount" portion not being valid.  I don't recall
> seeing this before, CVS update was done this evening, code was
> introduced:
> 
> 2005-07-19  Bob Doan  <bd...@si...>
>         * configure.in: 1.3.5
>         * libsrc/pcode.c: Tweek the compiler again / Make variables less
> picky and not crash on error
> 
> Is this doing what you expected?
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel

[Rlib-devel] This seems new: Variable Resolution: Assuming 0 value because rval is ERROR or NONE

[William K. V. <wk...@us...>]

In array.xml there is this fragment:
        <Variables>
                <Variable name="bo" value="2+3" type="expression"/>
        </Variables>
Which appears to be causing this message from pcode.c
Variable Resolution: Assuming 0 value because rval is ERROR or NONE
Due to the "amount" portion not being valid.  I don't recall
seeing this before, CVS update was done this evening, code was
introduced:

2005-07-19  Bob Doan  <bd...@si...>
        * configure.in: 1.3.5
        * libsrc/pcode.c: Tweek the compiler again / Make variables less
picky and not crash on error

Is this doing what you expected?

Re: [Rlib-devel] add_function capability and pcode.h

[William K. V. <wk...@us...>]

The attached patch modifies Makefile.am to include pcode.h in the
list of installed header files.

On Tue, 2005-07-19 at 10:35 -0400, Bob Doan wrote:
> My vote is to install pcode.h because if you are going to to make custom
> RLIB functions you clearly know what you are doing and probably want
> thew full pcode stack
> On Mon, 2005-07-18 at 13:54 -0600, William K. Volkman wrote:
> > 	I notice that pcode.h is not installed in /usr/include/rlib
> > however to be able to write a function which can be "add"ed it
> > pretty much needs defined:
> > 
> > rlib_value_stack_pop
> > RLIB_VALUE_GET_AS_STRING
> > RLIB_VALUE_GET_AS_NUMBER
> > rlib_value_new_string
> > rlib_value_new_number
> > 
> > So should those definitions migrate to rlib.h or (the quickest)
> > add pcode.h to the list of installed headers.

[Rlib-devel] Patch for crash from free.c

[William K. V. <wk...@us...>]

Actually I noticed that you may have fixed this today, I
made the change where I did to avoid the overhead of the call
to the free routine.  Feel free to ignore.