rlib-devel

[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?

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] 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?

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.

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: 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

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...>]

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.
>