> What clearup is necessary at the end of a program using librdf? Can I just > let everything drop, or is there > (for example) storage cleanup that is necessary?
> I'm working on wrapping librdf in Racket (a scheme-lineage lisp, > <http://racket-lang.org>, and see > <https://bitbucket.org/nxg/racket-librdf>). [skipped] Hello Norman, I cannot claim expertise in C, but I'm speaking from my experience coding Ruby wrapper for Redland, Redlander. As I learnt the hard way, one should pay attention to the description of the output of methods. Some methods return a new value, others return a pointer to a shared resource. For instance, read the description for "librdf_statement_get_subject". The output node value that you wrap in Racket must be *copied* from the SHARED pointer of "librdf_statement_get_subject". Otherwise, neither the statement nor the subject node can be safely garbage-collected. Redland API provides methods for creating *new* values from shared pointers, e.g.: "librdf_new_node_from_node" could be used in this case. As a side note, something is still "leaking" in my bindings, as I'm occasionally getting "*** glibc detected *** /bin/ruby: corrupted double-linked list: 0x0000000002d86fd0 ***" despite my best efforts ;-) Best regards, Slava Kravchenko On Wed, Mar 13, 2013 at 7:00 PM, <[email protected]> wrote: > Send redland-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.librdf.org/mailman/listinfo/redland-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of redland-dev digest..." > > > Today's Topics: > > 1. What needs to be tidied away at the end of a librdf program? > (Norman Gray) > 2. Re: What needs to be tidied away at the end of a librdf > program? (David Brooks) > 3. [Raptor RDF Syntax Library 0000532]: configure.ac: required > file `src/raptor_config.h.in' not found (Mantis Bug Tracker) > 4. [Raptor RDF Syntax Library 0000533]: Remove the > raptor_last_known_good tag from Git (Mantis Bug Tracker) > 5. Re: What needs to be tidied away at the end of a librdf > program? (Norman Gray) > 6. Announcing the first release of Kalimba (Slava Kravchenko) > 7. Addenda to: Announcing the first release of Kalimba > (Slava Kravchenko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Mar 2013 22:24:22 +0000 > From: Norman Gray <[email protected]> > To: [email protected] > Subject: [redland-dev] What needs to be tidied away at the end of a > librdf program? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Greetings. > > What clearup is necessary at the end of a program using librdf? Can I just > let everything drop, or is there (for example) storage cleanup that is > necessary? > > I'm working on wrapping librdf in Racket (a scheme-lineage lisp, > <http://racket-lang.org>, and see <https://bitbucket.org/nxg/racket-librdf>). > > I'm getting some access violations (see stack traces below) in Racket program > finalisation code, which is scrupulously freeing everything in sight. I > rather suspect that this is because librdf isn't necessarily designed to work > in the presence of a garbage collector, which may or may not respect > interdependencies between librdf objects which aren't manifest in the higher > layer. This may be a fault in my wrapping, or a fault in librdf, but I'm not > reporting it at a librdf bug because I haven't investigated it in much detail. > > I haven't investigated it because I suspect it doesn't matter, if it only > happens in cleanup code (and that's a fairly big 'if' which I haven't yet > fully convinced myself of). > > So, the point: is it likely to be safe for me to simply skip the at-exit > cleanup, and let everything be tidied up by the program exit? I'm guessing > yes; the only exception I can think of is storage cleanup, and I'd suppose > that a call to librdf_storage_sync would take care of that. > > Thanks for any advice. > > Best wishes, > > Norman > > ---- > > #0 0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at > raptor_uri.c:492 > 492 if(uri->world->uris_tree) > (gdb) where > #0 0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at > raptor_uri.c:492 > #1 0x0000000104cb3195 in raptor_free_term (term=0x100515230) at > raptor_term.c:407 > #2 0x0000000104cb2a8d in raptor_statement_clear [inlined] () at > /Data/tools/000-build/raptor2-2.0.9/src/raptor_statement.c:203 > #3 0x0000000104cb2a8d in raptor_free_statement (statement=0x100515230) at > raptor_statement.c:236 > #4 0x000000010029d51f in scheme_run_atexit_closers () > #5 0x00000001002a196a in scheme_do_close_managed () > #6 0x00000001002a1e42 in scheme_run_atexit_closers_on_all () > #7 0x00007fff8d2ff30b in __cxa_finalize () > #8 0x00007fff8d300f57 in exit () > #9 0x00000001000479d9 in def_exit_handler_proc () > #10 0x0000000100063ba1 in scheme_do_eval () > #11 0x0000000100083763 in apply_k () > #12 0x00000001000847ae in scheme_top_level_do_worker () > #13 0x00000001000478dd in scheme_do_exit () > [...] > > -- > Norman Gray : http://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Mar 2013 13:11:06 +1300 > From: David Brooks <[email protected]> > To: Norman Gray <[email protected]> > Cc: [email protected] > Subject: Re: [redland-dev] What needs to be tidied away at the end of > a librdf program? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hmm, I wonder if this also behind the issues I've found with the Python > bindings at program exit -- see > http://bugs.librdf.org/mantis/view.php?id=531 > > > Regards, > Dave > > On 13/03/13 11:24 AM, Norman Gray wrote: >> Greetings. >> >> What clearup is necessary at the end of a program using librdf? Can I just >> let everything drop, or is there (for example) storage cleanup that is >> necessary? >> >> I'm working on wrapping librdf in Racket (a scheme-lineage lisp, >> <http://racket-lang.org>, and see <https://bitbucket.org/nxg/racket-librdf>). >> >> I'm getting some access violations (see stack traces below) in Racket >> program finalisation code, which is scrupulously freeing everything in >> sight. I rather suspect that this is because librdf isn't necessarily >> designed to work in the presence of a garbage collector, which may or may >> not respect interdependencies between librdf objects which aren't manifest >> in the higher layer. This may be a fault in my wrapping, or a fault in >> librdf, but I'm not reporting it at a librdf bug because I haven't >> investigated it in much detail. >> >> I haven't investigated it because I suspect it doesn't matter, if it only >> happens in cleanup code (and that's a fairly big 'if' which I haven't yet >> fully convinced myself of). >> >> So, the point: is it likely to be safe for me to simply skip the at-exit >> cleanup, and let everything be tidied up by the program exit? I'm guessing >> yes; the only exception I can think of is storage cleanup, and I'd suppose >> that a call to librdf_storage_sync would take care of that. >> >> Thanks for any advice. >> >> Best wishes, >> >> Norman >> >> ---- >> >> #0 0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at >> raptor_uri.c:492 >> 492 if(uri->world->uris_tree) >> (gdb) where >> #0 0x0000000104cad080 in raptor_free_uri (uri=0x100515230) at >> raptor_uri.c:492 >> #1 0x0000000104cb3195 in raptor_free_term (term=0x100515230) at >> raptor_term.c:407 >> #2 0x0000000104cb2a8d in raptor_statement_clear [inlined] () at >> /Data/tools/000-build/raptor2-2.0.9/src/raptor_statement.c:203 >> #3 0x0000000104cb2a8d in raptor_free_statement (statement=0x100515230) at >> raptor_statement.c:236 >> #4 0x000000010029d51f in scheme_run_atexit_closers () >> #5 0x00000001002a196a in scheme_do_close_managed () >> #6 0x00000001002a1e42 in scheme_run_atexit_closers_on_all () >> #7 0x00007fff8d2ff30b in __cxa_finalize () >> #8 0x00007fff8d300f57 in exit () >> #9 0x00000001000479d9 in def_exit_handler_proc () >> #10 0x0000000100063ba1 in scheme_do_eval () >> #11 0x0000000100083763 in apply_k () >> #12 0x00000001000847ae in scheme_top_level_do_worker () >> #13 0x00000001000478dd in scheme_do_exit () >> [...] >> > > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Mar 2013 02:35:45 +0100 > From: Mantis Bug Tracker <[email protected]> > To: [email protected] > Subject: [redland-dev] [Raptor RDF Syntax Library 0000532]: > configure.ac: required file `src/raptor_config.h.in' not found > Message-ID: <[email protected]> > Keywords: [Raptor RDF Syntax Library] installation > Content-Type: text/plain; charset="utf-8" > > > The following issue has been SUBMITTED. > ====================================================================== > http://bugs.librdf.org/mantis/view.php?id=532 > ====================================================================== > Reported By: arto > Assigned To: > ====================================================================== > Project: Raptor RDF Syntax Library > Issue ID: 532 > Category: installation > Reproducibility: always > Severity: block > Priority: normal > Status: new > Syntax Name: > ====================================================================== > Date Submitted: 2013-03-13 02:35 > Last Modified: 2013-03-13 02:35 > ====================================================================== > Summary: configure.ac: required file > `src/raptor_config.h.in' > not found > Description: > There seems to be a regression in the installation procedure from a Git > checkout, wherein the ./autogen.sh procedure documented at > http://librdf.org/raptor/INSTALL.html now aborts with the error: > > configure.ac:29: required file `src/raptor_config.h.in' not found > > > Steps to Reproduce: > $ git clone git://github.com/dajobe/raptor.git raptor > $ cd raptor > $ ./autogen.sh > > > Additional Information: > Please see the attached log for a full transcript. > > Running `autoreconf -fi` manually, followed by ./autogen.sh, fixes the issue > and > allows the installation to proceed; however, according to the installation > instructions, this should be unnecessary (and it also used to be that > ./autogen.sh was sufficient in and of itself). > > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2013-03-13 02:35 arto New Issue > 2013-03-13 02:35 arto File Added: raptor-autogen.log > > ====================================================================== > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Mar 2013 02:50:24 +0100 > From: Mantis Bug Tracker <[email protected]> > To: [email protected] > Subject: [redland-dev] [Raptor RDF Syntax Library 0000533]: Remove the > raptor_last_known_good tag from Git > Message-ID: <[email protected]> > Keywords: [Raptor RDF Syntax Library] installation > Content-Type: text/plain; charset="utf-8" > > > The following issue has been SUBMITTED. > ====================================================================== > http://bugs.librdf.org/mantis/view.php?id=533 > ====================================================================== > Reported By: arto > Assigned To: > ====================================================================== > Project: Raptor RDF Syntax Library > Issue ID: 533 > Category: installation > Reproducibility: N/A > Severity: trivial > Priority: none > Status: new > Syntax Name: > ====================================================================== > Date Submitted: 2013-03-13 02:50 > Last Modified: 2013-03-13 02:50 > ====================================================================== > Summary: Remove the raptor_last_known_good tag from Git > Description: > Please consider removing the misleading 'raptor_last_known_good' tag from the > Git repository, as contrary to its name it actually refers to a commit from > way > back in 2006: > > commit b5d6ebcdd884f1ff9d4be1b1cbe5a12570df933d > Author: Dave Beckett <[email protected]> > Date: Sun Feb 19 03:55:26 2006 +0000 > > #changes > > > Additional Information: > $ git tag -d raptor_last_known_good > $ git push origin :refs/tags/raptor_last_known_good > > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2013-03-13 02:50 arto New Issue > ====================================================================== > > > > ------------------------------ > > Message: 5 > Date: Wed, 13 Mar 2013 09:51:50 +0000 > From: Norman Gray <[email protected]> > To: David Brooks <[email protected]> > Cc: [email protected] > Subject: Re: [redland-dev] What needs to be tidied away at the end of > a librdf program? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=iso-8859-1 > > > David and all, hello. > > On 2013 Mar 13, at 00:11, David Brooks <[email protected]> wrote: > >> Hmm, I wonder if this also behind the issues I've found with the Python >> bindings at program exit -- seehttp://bugs.librdf.org/mantis/view.php?id=531 > > I've had broadly similar problems in this space before > <http://bugs.librdf.org/mantis/view.php?id=365>, but I didn't link to that in > the message because I'm not sure that these are immediately related. As Dave > Beckett notes in the comments to that problem, there isn't an easy answer to > this (of course!). > > It occurs to me that I should perhaps try building librdf with a GC library > such as the Boehm one, and see what happens.... > > Best wishes, > > Norman > > > -- > Norman Gray : http://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > > > > ------------------------------ > > Message: 6 > Date: Wed, 13 Mar 2013 13:42:40 +0300 > From: Slava Kravchenko <[email protected]> > To: "[email protected]" <[email protected]>, > [email protected] > Subject: [redland-dev] Announcing the first release of Kalimba > Message-ID: > <camd1medzboznuqwf+quteaoyo+ikjfybzbcqs47mqxewxhc...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello everybody! > > I'm extremely happy to announce that the first public version of Kalimba > has been released! > > Kalimba is a Ruby gem (library) which provides ActiveRecord-like > capabilities for your RDF data. You may think of it as a sibling of Spira, > except that Kalimba is: > > - high performance-oriented, > - lightweight, > - based on Redlander* gem, which is based on Redland (librdf.org) and > thus is not directly related to RDF.rb, > - has more "Ruby-ish" API. > > * Redlander is currently the only "backend" for Kalimba, but owing to the > modular architecture, more backends can be added. Even RDF.rb with its own > backends. > > There are many exciting things in store for Kalimba/Redlander development, > but it's already not a basic library and is being tested in production (in > a private project). > > Best regards, > > Slava Kravchenko > https://plus.google.com/109894007099276378025 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.librdf.org/pipermail/redland-dev/attachments/20130313/81429c91/attachment-0001.html> > > ------------------------------ > > Message: 7 > Date: Wed, 13 Mar 2013 13:58:08 +0300 > From: Slava Kravchenko <[email protected]> > To: "[email protected]" <[email protected]>, > [email protected] > Subject: [redland-dev] Addenda to: Announcing the first release of > Kalimba > Message-ID: > <camd1mebtyqquofgva9-s-5y5rbnz9agbqxwtovfdgpzmg6-...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > In all the excitement I forgot to provide the links to the project. My > apologies. > > Kalimba gem is hosted at rubygems.org: > - https://rubygems.org/gems/kalimba > > The only backend is "kalimba-redlander": > - https://rubygems.org/gems/kalimba-redlander > > If you want to go "deeper" and learn about Redlander gem: > - https://rubygems.org/gems/redlander > > The development repositories are hosted at github. You can find the > corresponding links as "homepage" links at rubygems.org. > > Best regards, > > Slava Kravchenko > https://plus.google.com/109894007099276378025 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.librdf.org/pipermail/redland-dev/attachments/20130313/543c352c/attachment-0001.html> > > ------------------------------ > > _______________________________________________ > redland-dev mailing list > [email protected] > http://lists.librdf.org/mailman/listinfo/redland-dev > > End of redland-dev Digest, Vol 121, Issue 3 > ******************************************* _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
