From alessiostalla at gmail.com  Tue Nov  8 23:39:32 2011
From: alessiostalla at gmail.com (Alessio Stalla)
Date: Wed, 9 Nov 2011 00:39:32 +0100
Subject: [fset-devel] FSet on ABCL
In-Reply-To: <CAL2Kp+ie=-OKu8oecFG1UNDqCs0nZD0fjsbqAibxs0s_d62oTQ@mail.gmail.com>
References: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
	<CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
	<CAL2Kp+ie=-OKu8oecFG1UNDqCs0nZD0fjsbqAibxs0s_d62oTQ@mail.gmail.com>
Message-ID: <CAL2Kp+goefVxHd0sZPJnndJGnWCSrciFigX9xQs1k0oZVFgwnQ@mail.gmail.com>

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
>



From Scott at sympoiesis.com  Wed Nov  9 03:58:44 2011
From: Scott at sympoiesis.com (Scott L. Burson)
Date: Tue, 8 Nov 2011 19:58:44 -0800
Subject: [fset-devel] FSet on ABCL
In-Reply-To: <CAL2Kp+goefVxHd0sZPJnndJGnWCSrciFigX9xQs1k0oZVFgwnQ@mail.gmail.com>
References: <CAL2Kp+h89JgA36oQFkDuWUpk61v85GvSXSJoXooytvMRHhtJJA@mail.gmail.com>
	<CAF5LJ4AfZL_nCGgjDOortT-9r_daudyXx0s8-kSe_49PrTzvuQ@mail.gmail.com>
	<CAL2Kp+ie=-OKu8oecFG1UNDqCs0nZD0fjsbqAibxs0s_d62oTQ@mail.gmail.com>
	<CAL2Kp+goefVxHd0sZPJnndJGnWCSrciFigX9xQs1k0oZVFgwnQ@mail.gmail.com>
Message-ID: <CAF5LJ4BQH9Ewh7HgW8wpo3Zb-kJdbbFoG3cwj4odq+NJJYT29w@mail.gmail.com>

On Tue, Nov 8, 2011 at 3:39 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> 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.

Okay, good.

> 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?

Not that I recall -- nor does a quick look at the code reveal any such
dependence.

If you can capture a (partial) backtrace, I will take a look at it.

-- Scott



From nikodemus at random-state.net  Thu Nov 10 13:55:33 2011
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Thu, 10 Nov 2011 15:55:33 +0200
Subject: [fset-devel] Fix for SBCL 1.0.53
Message-ID: <CADow0Cqur=m2U8hf39=6m-anmTqgrbjx5LQBKJk=KReWokB3Tw@mail.gmail.com>

As of recently SBCL's fixnums are 63 bits long on 64-bit platforms --
which breaks FSET. Sticking the following definitions into port.lisp
in place of the current ones should make things better.

...but I didn't actually verify that the rest of FSET works sanely
with these values. (I'm not on fset-devel, so CCing Scott directly and
Xach for Quicklisp's convenience.)

(defconstant Tuple-Key-Number-Size
  (ecase (integer-length most-positive-fixnum)
    (62 41)     ; SBCL, 64-bit
    (61 40)	; ECL, 64-bit
    (60 40)	; SBCL, OpenMCL, Scieneer CL, 64-bit
    (48 32)	; CLISP, 64-bit
    (31 18)	; Symbolics L-machine, I-machine
    (29 17)	; Allegro, CMUCL, SBCL, LispWorks (most), ECL, 32-bit
    (24 15)	; CLISP, 32-bit
    (23 14))	; LispWorks 4 on Linux
  "This limits the number of tuple-keys that can exist in a session.")

(defconstant Tuple-Value-Index-Size
  (ecase (integer-length most-positive-fixnum)
    (62 21)
    (61 21)
    (60 20)
    (48 16)
    (31 13)
    (29 12)
    (24 9)
    (23 9))
  "This limits the number of key/value pairs in any tuple.")

Cheers,

?-- Nikodemus



From Scott at sympoiesis.com  Thu Nov 10 17:44:45 2011
From: Scott at sympoiesis.com (Scott L. Burson)
Date: Thu, 10 Nov 2011 09:44:45 -0800
Subject: [fset-devel] Fix for SBCL 1.0.53
In-Reply-To: <CADow0Cqur=m2U8hf39=6m-anmTqgrbjx5LQBKJk=KReWokB3Tw@mail.gmail.com>
References: <CADow0Cqur=m2U8hf39=6m-anmTqgrbjx5LQBKJk=KReWokB3Tw@mail.gmail.com>
Message-ID: <CAF5LJ4BVf4ZdbjBim5fNUar2XAnuT4OiUENSS74n+Har7Ub=OA@mail.gmail.com>

Thanks for the heads-up!  I'll update FSet over the weekend.

-- Scott

On Thu, Nov 10, 2011 at 5:55 AM, Nikodemus Siivola
<nikodemus at random-state.net> wrote:
> As of recently SBCL's fixnums are 63 bits long on 64-bit platforms --
> which breaks FSET. Sticking the following definitions into port.lisp
> in place of the current ones should make things better.
>
> ...but I didn't actually verify that the rest of FSET works sanely
> with these values. (I'm not on fset-devel, so CCing Scott directly and
> Xach for Quicklisp's convenience.)
>
> (defconstant Tuple-Key-Number-Size
> ?(ecase (integer-length most-positive-fixnum)
> ? ?(62 41) ? ? ; SBCL, 64-bit
> ? ?(61 40) ? ? ; ECL, 64-bit
> ? ?(60 40) ? ? ; SBCL, OpenMCL, Scieneer CL, 64-bit
> ? ?(48 32) ? ? ; CLISP, 64-bit
> ? ?(31 18) ? ? ; Symbolics L-machine, I-machine
> ? ?(29 17) ? ? ; Allegro, CMUCL, SBCL, LispWorks (most), ECL, 32-bit
> ? ?(24 15) ? ? ; CLISP, 32-bit
> ? ?(23 14)) ? ?; LispWorks 4 on Linux
> ?"This limits the number of tuple-keys that can exist in a session.")
>
> (defconstant Tuple-Value-Index-Size
> ?(ecase (integer-length most-positive-fixnum)
> ? ?(62 21)
> ? ?(61 21)
> ? ?(60 20)
> ? ?(48 16)
> ? ?(31 13)
> ? ?(29 12)
> ? ?(24 9)
> ? ?(23 9))
> ?"This limits the number of key/value pairs in any tuple.")
>
> Cheers,
>
> ?-- Nikodemus
>