From: Erik H. <eh...@gm...> - 2009-06-02 07:40:02
|
On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <ale...@gm...> wrote: > Ok, I've tried Qi II... > > I found out the problem with the readtable case: > ABCL uses an ad-hoc readtable for loading compiled code ("fasl" > files). These files consist partly of textual Lisp forms, partly of > binary files for compiled functions. So the textual code when read > back is read with default readtable settings, including :upcase > behavior, even if some symbols to be read are not uppercase. Well, the problem is a little bit deeper: (intern "a") --> |a| however, if you run (dump-form t (intern "a")) I don't expect you to see "|a|", based on what I see in Symbol.writeToString() and the fact that %stream-output-object effectively uses that to produce its output. I think that's the deeper issue we're looking at here. > To circumvent the problem, I changed the fasl readtable to have a > default case of :preserve instead of :upcase. This fixes the issue > with Qi and should not give other problems, since this readtable is > only used to read back printed Lisp code, which has already the > correct case. Well, since it's our FASL format and our reader, I guess we can work with this workaround for now. Could you commit it please. When you do, I'll file an issue on our issue(s) with writeToString() and the fact that it differs from using PRINT. > However, probably the optimal solution would be to both write and read > the fasl code with default i/o settings, since case is not the only > possible source of confusion: *print-base* comes to my mind, for > example. Well, the issue is not the default reader settings, but the problem that the "|" characters don't get added in the right place. As I said before: I have an issue with the fact that we have all these writeToString things: they are generally incompatible with regular PRINT code. Next to that it's not completely transparent (to me) when the regular PRINT code is being used and when the writeToString stuff. > Qi II has still the other issue Qi had: the Qi REPL is run in package > :cl-user instead of :qi. However, I launch the REPL myself with > (qi::qi) since I have no saved image, so maybe I'm missing the fact > that the qi function expects to be called when *package* is already > :qi. > > Apart from that, things seems to run fine. I've only tried some > snippets from the 15-min tutorial though. If you have some test suite > to verify Qi is functioning properly, let me know. Thanks for taking your time to have this evaluation! Let's get Qi working soon and add it to our list of "known working" programs! Bye, Erik. |