[armedbear-devel] [fset-devel] FSet on ABCL

[Alessio Stalla]

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 at gmail.com> wrote:
> On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott at sympoiesis.com> wrote:
>> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla
>> <alessiostalla at 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
>