Hi,
I've recently came across bknr while searching for a persistence layer for a small toy program I'm making (which isn't even web based), and found it quite interesting and with a nicely laid-out documentation (well, for the datastore, indexing and XML bits, less so for the web component).
While playing around trying to understand the several pieces (mainly the datastore) I got stuck in the XML tutorial (tutorial.lisp in xml-impex) at:
(parse-xml-file "xml-impex/tutorial.xml" (list (find-class 'book)))
To reach that point I had to change
(asdf:oos 'asdf:load-op :bknr-impex) to (asdf:oos 'asdf:load-op :bknr.impex).
I always get the following error:
The value NIL is not of type CXML::DTD. [Condition of type TYPE-ERROR]
I'm not entirely sure if this is a problem on my end, or if the tutorial is outdated.
I'm using SBCL 1.0.35-3 in Fedora 12 FWIW, plus a recent svn tree. Any pointers are appreciated, and I'm of course more than happy to provide any further information if this is indeed something that shouldn't occur.
Best regards,
Frederico
Hi Frederico,
the XML import/export functionality has long regressed because it is unused, and I can't easily resurrect it. I never used the import aspect of the XML impex facility and at some point switched to writing specialized exporters for those formats that I need (i.e. http://bknr.net/trac/browser/trunk/projects/bos/m2/export.lisp#L94).
I'm sorry that the documentation and source code still gives the misleading impression that there is an XML import/export facility. I'm going to make a little update to indicate the state of this subsystem.
Did you have specific requirements for the impex facility?
-Hans
On Sun, May 23, 2010 at 05:29, Frederico Muñoz fsmunoz@gmail.com wrote:
Hi,
I've recently came across bknr while searching for a persistence layer for a small toy program I'm making (which isn't even web based), and found it quite interesting and with a nicely laid-out documentation (well, for the datastore, indexing and XML bits, less so for the web component).
While playing around trying to understand the several pieces (mainly the datastore) I got stuck in the XML tutorial (tutorial.lisp in xml-impex) at:
(parse-xml-file "xml-impex/tutorial.xml" (list (find-class 'book)))
To reach that point I had to change
(asdf:oos 'asdf:load-op :bknr-impex) to (asdf:oos 'asdf:load-op :bknr.impex).
I always get the following error:
The value NIL is not of type CXML::DTD. [Condition of type TYPE-ERROR]
I'm not entirely sure if this is a problem on my end, or if the tutorial is outdated.
I'm using SBCL 1.0.35-3 in Fedora 12 FWIW, plus a recent svn tree. Any pointers are appreciated, and I'm of course more than happy to provide any further information if this is indeed something that shouldn't occur.
Best regards,
Frederico
bknr-devel mailing list bknr-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel
Hi Hans,
First of all my thank you for your quick reply, it seems that we both are awake at odd hours ;)
2010/5/23 Hans Hübner hans.huebner@gmail.com:
Hi Frederico,
the XML import/export functionality has long regressed because it is unused, and I can't easily resurrect it.
I see, I sort of suspected that that might be a possibility, hence my initial message. It's quite natural for some "code rot" to settle in in areas that aren't used.
I never used the import aspect of the XML impex facility and at some point switched to writing specialized exporters for those formats that I need (i.e. http://bknr.net/trac/browser/trunk/projects/bos/m2/export.lisp#L94).
Right, I'm not familiar with cxml (well, I'm barely familiar with Lisp) but I understand the general idea.
I'm sorry that the documentation and source code still gives the misleading impression that there is an XML import/export facility. I'm going to make a little update to indicate the state of this subsystem.
No problem at all, documentation in general lags a bit when code changes frequently.
Did you have specific requirements for the impex facility?
That's a good question actually... at this stage I do not have any specific requirements. Without burdening you with details which aren't of interest this is merely a "pet project", an idea that I had about a strategy game, and which I'm using as a way to actually use Lisp a bit more. As such I'm still in the early stages and do not have specific requirements, or at least they are so vague that they are bound to change drastically. I'm not a big fan of XML, although in recent times I've came to at least recognise that it is useful as a way to exchange data, and with templating adapting it to different output forms. With that in mind the XML impex in the bknr documentation appeared as something that could be useful, but I can also use something else (like specialised importers/exporters, as you said).
I have a more general question though, which I hope you don't mind me asking: in general terms do you have plans to maintain the bknr datastore (I didn't yet investigate the web part of it, which I understand is done mainly by reading the code), or is it something that you see has having served its purpose? I'm only asking because it's quite natural for developers to reach a point where they change focus, even in terms of the language they use, let alone specific frameworks. I've actually learned quite a bit by reading the bknr documentation, and even listening to the audio of the 2008 Lisp conference that you gave, so in several ways bknr has already been quite useful to me, and I can only thank you in making it available. Since I'm on the very early stages of my project this is relatively important to me (relatively because this is not something that I do professionally, unlike you, and as such not even guaranteed to be finished).
Best regards,
Frederico
Hi Frederico,
the problem with maintaining the datastore is keeping up with compiler changes. I do have some deployed applications (using SBCL), and I plan to use it (with CCL) in the nearer future. Whenever I'm working on something new or do a major update on my deployed applications, the store will receive some love. I cannot make any predictions or promises if and how this will happen, but I am not considering the project to be closed.
Best, Hans
Hi Hans,
2010/5/24 Hans Hübner hans.huebner@gmail.com:
Hi Frederico,
the problem with maintaining the datastore is keeping up with compiler changes. I do have some deployed applications (using SBCL), and I plan to use it (with CCL) in the nearer future. Whenever I'm working on something new or do a major update on my deployed applications, the store will receive some love. I cannot make any predictions or promises if and how this will happen, but I am not considering the project to be closed.
Perfect, that's all I needed to hear, and I'm glad you didn't take my question the wrong way. As long as you plan to continue using it than I'm a happy camper.
Best regards,
Frederico
Hello,
2010/5/23 Hans Hübner hans.huebner@gmail.com:
the XML import/export functionality has long regressed because it is unused, and I can't easily resurrect it. I never used the import aspect of the XML impex facility and at some point switched to writing specialized exporters for those formats that I need (i.e. http://bknr.net/trac/browser/trunk/projects/bos/m2/export.lisp#L94).
For some odd reason I've been looking at the xml-impex code (well, one of the reasons is that the documentation made it look really cool, even if I'm not even sure if I'm actually going to use it :) ), and have it kind of working... I'm using the tutorial output as a guide, which makes it a bit easier. I've added some missing functions (children-to-initforms, etc), massaged some cxml parameters here and there (small API changes) and I've successfully imported objects, which is, well, cool.
Now, since you don't use the facility I don't want to burden you with doubts concerning a subsystem that you've deprecated; although my Lisp skills are sub-par I'm more or less enjoying the code (even if it is a bit hairy here and there, especially since I don't even have experience with SAX).
I have one very general doubt though that perhaps you could eventually (time permitting) address: I've been reading former revisions in order to understand the changes, and there was a quite large rework some time ago. Of particular importance is that it *seems* (and, again, the compounding of my poor grasp of Lisp, XML, SAX and programming in general could be at work here...) that the way to use it was actually going to change in terms of the exporter: whereas before write-to-xml was self-sufficient in terms of generating output (as in the tutorial), I've noticed that code re-factoring seems to indicate that with-xml-export/with-xml-export* would be the entry point for a user. What's leading me to this conclusion is the fact that the cxml sink is only created in those macros.
I also note the presence of an *objects-written* hash-table (which is supposed to be updated, but isn't).
I've got the exporter also working (well, mildly, it at least produces the expected output for the first part of the tutorial), but I was hoping you could shed some light on what was your plan with the changes above. I'm not asking for code, just a general idea of what was the goal you were going for. Knowing that I can work on implementing those changes, instead of somewhat reverting the code to fit the tutorial (which could be changed).
Best regards,
Frederico
Hi Frederico,
first off, thank you for putting time into resurrecting the XML import/export facility. I'll happily review your patches and incorporate them into the main line once you think that they work well enough.
2010/5/25 Frederico Muñoz fsmunoz@gmail.com:
II've been reading former revisions in order to understand the changes, and there was a quite large rework some time ago. Of particular importance is that it *seems* (and, again, the compounding of my poor grasp of Lisp, XML, SAX and programming in general could be at work here...) that the way to use it was actually going to change in terms of the exporter: whereas before write-to-xml was self-sufficient in terms of generating output (as in the tutorial), I've noticed that code re-factoring seems to indicate that with-xml-export/with-xml-export* would be the entry point for a user. What's leading me to this conclusion is the fact that the cxml sink is only created in those macros.
I really can't remember what my plans were at the time, so if you can come up with an idea how the user interface should look like (or chose either of the two), I'd appreciate it. It may be that my wish to change the interface was related to memory usage with larger stores.
Thanks! Hans
Hi Hans,
2010/5/26 Hans Hübner hans.huebner@gmail.com: (...)
I really can't remember what my plans were at the time, so if you can come up with an idea how the user interface should look like (or chose either of the two), I'd appreciate it. It may be that my wish to change the interface was related to memory usage with larger stores.
OK, I'll try to come up with something sensible. I'll take a look at use-case scenarios (both inside and outside bknr) to get an idea on how people generally use this sort of facilities, and try to make something sensible with it (and ideally not very removed from what is in the tutorial, that I found quite easy to follow).
I can't vouch for either a deadline of code quality, but I think that if I can get it at least working for the examples in the tutorial it will be better than the current state.
I'll keep you posted when I have something real to show.
Regards,
Frederico
-
Frederico Muñoz -
Hans Hübner