|
|
|
Alessio Stalla
|
Hello Mark,
as promised, I made a quick attempt at running Qi on ABCL. I'm CC'ing the ABCL mailing list. I've gotten Qi to load (but only interpreted, see below), just making trivial modifications to "Qi 9.2.txt" (basically just adding a few read-time conditionals for ABCL). If I understood it correctly this is not Qi's source but is rather auto-generated from another file, however I don't know how to do the generation myself, so I directly modified the end product - it should be easy to backport my little fixes to the source. However, Qi is not working properly. (qi::qi) gives me the Qi REPL: if I type simple expressions at the REPL, like (and true false), it gives me errors about undefined functions (e.g. and in the case before). I initially thought it was the thing you mentioned - the readtable behavior reverting to upcase somewhere - since for non-alphabetic functions, like mathematical operators, things work smoothly. However, evaluting this: (READTABLE-CASE (EVAL *READTABLE*)) returns :PRESERVE, so it seems the readtable is set up ok while Qi is running. Then I investigated a little bit more and discovered it's actually a package problem: prefixing all symbols with qi: works. In fact, (EVAL *PACKAGE*) ==> #<PACKAGE "COMMON-LISP-USER"> I don't know how to fix this, but maybe you can point me to the right direction. I've also seen test suites in the Qi directory but I don't know how to run them (should I just load them?). Instead, regarding compilation: 1. I spotted a bug in ABCL that prevented it to correctly compiling files with a space in their name (the generated Java class contained the space in its name and this is not valid). 2. ABCL's compiled files usually (always?) have a textual prologue with a few Lisp forms that load the actual code. This textual prologue starts with a commented Emacs mode-line. Since Qi redefines ; to be a regular character, ABCL chokes when loading Qi interpreted (which changes the meaning of ;) and then Qi compiled. I temporarily commented out the code writing the mode-line in my copy of ABCL. 3. After fixing 1. and 2., loading the compiled file works up to a certain point, then it basically crashes without much explanation ("maximum error depth exceeded"??). However, while loading it complains about the redefinition of many Common Lisp operators, so maybe the problem is related to packages just like in the interpreted case. In summary, we could be a little step away from Qi working on ABCL, if it all amounts to an incorrect handling of packages. Yes, I'm being too optimistic today :) Cheers, Alessio ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Kevin Reid
|
On May 31, 2009, at 8:37, Alessio Stalla wrote:
> 2. ABCL's compiled files usually (always?) have a textual prologue > with a few Lisp forms that load the actual code. This textual prologue > starts with a commented Emacs mode-line. Since Qi redefines ; to be a > regular character, ABCL chokes when loading Qi interpreted (which > changes the meaning of ;) and then Qi compiled. I temporarily > commented out the code writing the mode-line in my copy of ABCL. This sounds like an ABCL bug: recognition of compiled files ought not to depend on the current readtable, yes? (However, CLHS just says of LOAD that "The manner in which a source file is distinguished from a compiled file is implementation- dependent.") -- Kevin Reid <http://homepage.mac.com/kpreid/> ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
|
Alessio Stalla
|
On Sun, May 31, 2009 at 2:56 PM, Kevin Reid <[hidden email]> wrote:
> On May 31, 2009, at 8:37, Alessio Stalla wrote: > >> 2. ABCL's compiled files usually (always?) have a textual prologue >> with a few Lisp forms that load the actual code. This textual prologue >> starts with a commented Emacs mode-line. Since Qi redefines ; to be a >> regular character, ABCL chokes when loading Qi interpreted (which >> changes the meaning of ;) and then Qi compiled. I temporarily >> commented out the code writing the mode-line in my copy of ABCL. > > This sounds like an ABCL bug: recognition of compiled files ought not > to depend on the current readtable, yes? > > (However, CLHS just says of LOAD that "The manner in which a source > file is distinguished from a compiled file is implementation- > dependent.") > The problem is not how abcl distinguishes a source file from a compiled one, but how the compiled code interacts with the readtable while loaded. The hyperspec just says: "load binds *readtable* and *package* to the values they held before loading the file". In Qi's case, the readtable is the default one (no copy-readtable is ever done afaik). When loading Qi interpreted, the form (SET-SYNTAX-FROM-CHAR #\; #\v) is evaluated, and the default readtable is side-effected. Then the same readtable is used while loading the compiled file, and this is what causes the problem. (Apparently it is necessary for Qi to be loaded first in order to compile Qi itself). So, the default readtable being used is not an ABCL bug imho; it's probably what other implementations do as well. What is a little more dubious is ABCL inserting something in the compiled file (the mode line) which was not there in the source file, and which can have unforeseen behavior if the readtable happens to be modified. On the other hand, even if abcl didn't do so, things could go equally wrong if some code redefined e.g. the syntax associated with the open paren #\( , so probably it is really Qi's behavior (modifying the readtable without first copying it) which is questionable. Since the fix was easy, I didn't ask Mark to change Qi but directly modified abcl. Probably the safest thing to do is to control whether the mode line is output looking at some variable. Qi could then set this variable to its liking, while the default would remain what abcl does now. Alessio ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Robert Dodier
|
In reply to this post
by Alessio Stalla
--- On Sun, 5/31/09, Alessio Stalla <[hidden email]> wrote: > Probably the safest thing to do is to control whether the > mode line is output looking at some variable. Qi could > then set this variable to its liking, while the default > would remain what abcl does now. I dunno. Introducing another global variable just increases confusion with little benefit. I'll advise against it. Sounds like resolving the problem is up to Qi; I don't see why ABCL shouldn't be able to emit arbitrary junk into its compiled files. Be that as it may, in the interest of playing nice with Qi, ABCL might suppress the mode line. But it should be unconditional, either always or never. Watching from the sidelines, Robert Dodier ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Alessio Stalla
|
The problem is non-existent, since I was actually trying the wrong
version of Qi... the current one does not have the problem. But, in general, I agree that adding a new variable for such an insignificant thing would be overkill. Bye, Alessio On Mon, Jun 1, 2009 at 6:55 PM, Robert Dodier <[hidden email]> wrote: > > --- On Sun, 5/31/09, Alessio Stalla <[hidden email]> wrote: > >> Probably the safest thing to do is to control whether the >> mode line is output looking at some variable. Qi could >> then set this variable to its liking, while the default >> would remain what abcl does now. > > I dunno. Introducing another global variable just increases > confusion with little benefit. I'll advise against it. > > Sounds like resolving the problem is up to Qi; I don't see > why ABCL shouldn't be able to emit arbitrary junk into its > compiled files. Be that as it may, in the interest of playing > nice with Qi, ABCL might suppress the mode line. But it > should be unconditional, either always or never. > > Watching from the sidelines, > > Robert Dodier > > > > > ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Alessio Stalla
|
In reply to this post
by Alessio Stalla
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. 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. 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. 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. Bye, Alessio On Mon, Jun 1, 2009 at 11:06 AM, Alessio Stalla <[hidden email]> wrote: > Oh, sorry, you're right! I downloaded it from the Google Code page, > and I didn't look at the lambda associates page... well, it helped > uncover a bug in abcl, so, it wasn't completely wasted time :) > > Now, on to Qi II... > > Bye, > Alessio > > On Mon, Jun 1, 2009 at 2:10 AM, Mark Tarver <[hidden email]> wrote: >> Hi, >> >> You're running a very old Qi there. Qi I; Qi II is the one to use. Actually >> in Qi II ; is not redefined by SET-SYNTAX.., >> though the readtable is made case preserving. >> >> Mark >> ----- Original Message ----- From: "Alessio Stalla" >> <[hidden email]> >> To: <[hidden email]> >> Cc: <[hidden email]> >> Sent: Sunday, May 31, 2009 1:37 PM >> Subject: Qi on ABCL >> >> >>> Hello Mark, >>> >>> as promised, I made a quick attempt at running Qi on ABCL. I'm CC'ing >>> the ABCL mailing list. >>> >>> I've gotten Qi to load (but only interpreted, see below), just making >>> trivial modifications to "Qi 9.2.txt" (basically just adding a few >>> read-time conditionals for ABCL). If I understood it correctly this is >>> not Qi's source but is rather auto-generated from another file, >>> however I don't know how to do the generation myself, so I directly >>> modified the end product - it should be easy to backport my little >>> fixes to the source. >>> >>> However, Qi is not working properly. (qi::qi) gives me the Qi REPL: if >>> I type simple expressions at the REPL, like (and true false), it gives >>> me errors about undefined functions (e.g. and in the case before). I >>> initially thought it was the thing you mentioned - the readtable >>> behavior reverting to upcase somewhere - since for non-alphabetic >>> functions, like mathematical operators, things work smoothly. However, >>> evaluting this: >>> >>> (READTABLE-CASE (EVAL *READTABLE*)) >>> >>> returns :PRESERVE, so it seems the readtable is set up ok while Qi is >>> running. Then I investigated a little bit more and discovered it's >>> actually a package problem: prefixing all symbols with qi: works. In >>> fact, (EVAL *PACKAGE*) ==> #<PACKAGE "COMMON-LISP-USER"> >>> >>> I don't know how to fix this, but maybe you can point me to the right >>> direction. >>> I've also seen test suites in the Qi directory but I don't know how to >>> run them (should I just load them?). >>> >>> Instead, regarding compilation: >>> >>> 1. I spotted a bug in ABCL that prevented it to correctly compiling >>> files with a space in their name (the generated Java class contained >>> the space in its name and this is not valid). >>> 2. ABCL's compiled files usually (always?) have a textual prologue >>> with a few Lisp forms that load the actual code. This textual prologue >>> starts with a commented Emacs mode-line. Since Qi redefines ; to be a >>> regular character, ABCL chokes when loading Qi interpreted (which >>> changes the meaning of ;) and then Qi compiled. I temporarily >>> commented out the code writing the mode-line in my copy of ABCL. >>> 3. After fixing 1. and 2., loading the compiled file works up to a >>> certain point, then it basically crashes without much explanation >>> ("maximum error depth exceeded"??). However, while loading it >>> complains about the redefinition of many Common Lisp operators, so >>> maybe the problem is related to packages just like in the interpreted >>> case. >>> >>> In summary, we could be a little step away from Qi working on ABCL, if >>> it all amounts to an incorrect handling of packages. Yes, I'm being >>> too optimistic today :) >>> >>> Cheers, >>> Alessio >>> >> >> > ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Erik Huelsmann
|
On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> 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. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Alessio Stalla
|
On Tue, Jun 2, 2009 at 9:39 AM, Erik Huelsmann <[hidden email]> wrote:
> On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> 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. Hmm, I see. >> 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. Sure. I'll also commit the fix for class-name-from-filespec in jvm.lisp which included spaces in the class name. >> 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. Ok, thanks for clarifying this. > 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. What if writeToString() simply called PRINT? >> 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! Yes, I believe we're close. Bye, Alessio ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Erik Huelsmann
|
On Tue, Jun 2, 2009 at 11:47 AM, Alessio Stalla <[hidden email]> wrote:
> On Tue, Jun 2, 2009 at 9:39 AM, Erik Huelsmann <[hidden email]> wrote: >> On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> 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. > > Hmm, I see. Well, I looked closer at the issue and when run from the REPL, (dump-form (intern "a") *standard-output*) produces |a| as expected. So, it looks like something in Qi may be binding *print-escape* or *print-readably* to NIL and DUMP-FORM isn't installing a binding of its own. I'll do some tests this evening at home, if you can describe to me what steps I need to take to be able to run Qi II. With kind regards, Erik. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
|
Alessio Stalla
|
On Wed, Jun 3, 2009 at 1:27 PM, Erik Huelsmann <[hidden email]> wrote:
> Well, I looked closer at the issue and when run from the REPL, > (dump-form (intern "a") *standard-output*) produces |a| as expected. > So, it looks like something in Qi may be binding *print-escape* or > *print-readably* to NIL and DUMP-FORM isn't installing a binding of > its own. > > I'll do some tests this evening at home, if you can describe to me > what steps I need to take to be able to run Qi II. You should be able to run Qi II by doing the following: 1. download Qi II from the lambdassociates.org website (not the one on Google Code which is an old version) 2. put the files attached to this mail in the Lisp folder, overwriting existing files 3. start up abcl and load install.lsp (which compiles Qi and quits abcl) 4. load run_abcl.lsp you should get at the Qi prompt. Evaluating (and true false) lowercased should give false (duh). You can load test.qi to run test code. That's all. Bye, Ale ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ armedbear-j-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |