Hi,
to follow up on the topic of running FSet on ABCL, I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine. However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization?
Bye, Alessio
On Thu, Oct 27, 2011 at 1:19 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson Scott@sympoiesis.com wrote:
On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla alessiostalla@gmail.com wrote:
Greetings,
as part of my nth plan to conquer the world (which of course I won't unveil right now), I tried FSet on ABCL. I managed to make it run, but I had to patch it; you can find the patch attached (it's taken against the version in Quicklisp, but I believe it's the latest version).
Thanks for the patch!
Did you run the test suite? Were any non-default JVM settings required, e.g. stack size?
Do you have any performance comparisons (of FSet operations in particular) vis-a-vis, say, SBCL?
I haven't run the test suite yet, nor made any performance comparisons. Regarding JVM settings, in order to compile and load FSet (under SLIME) I had to increase the maximum heap size from the (iirc) 64M default. I set it at 256M but it may well be that a lower value is sufficient. In the next few days I'll do a few tests and benchmarks and I'll keep you informed on the results.
Besides some minor #+abcl porting stuff, the one thing that stuck out was the DEFLEX macro for defining global lexical variables, which conflicts with ABCL's implementation of symbol macros. (deflex var) expands basically into (define-symbol-macro var (symbol-value 'var)). The problem: ABCL stores symbol macros in the value cell of symbols, so you can't have a symbol which is both a variable and a symbol macro. Now, I believe deflex as written is non portable CL. This is because accessing the symbol-value of an unbound variable is, to my interpretation, unspecified [*]; and if you use defvar/defparameter with var, then you cannot use it as a symbol macro. Thus, I patched it (taking inspiration from Rob Warnock's version of deflex/defglobal).
Heh -- I had seen Rob's implementation and wondered why he created a second symbol. Now I know :-)
I don't particularly like the second interned symbol solution... I tried initially with a gensym, but it's hard to get right the interplay between compile-time, load time, and the file compiler possibly losing gensym identity, so I guess Rob's approach is the most practical.
I don't think a symbol for which there is no special declaration in scope can be considered to name a dynamic variable, and thus to have a value cell at all.
On a strict reading, you're probably correct. But I had never seen an implementation for which this was not the case.
Yes, me neither, and I'd like to get ABCL fixed in that regard. You might keep your implementation of deflex as-is; in the meantime I will use my patched version, until ABCL is fixed.
Thanks, Alessio