From vsedach at gmail.com  Wed May 20 18:31:31 2009
From: vsedach at gmail.com (Vladimir Sedach)
Date: Wed, 20 May 2009 12:31:31 -0600
Subject: [bknr-devel] Motivation for not interning symbols when loading a
	store
Message-ID: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com>

Hello,

I'm genuinely perplexed why the BKNR datastore throws an error when it
tries to load a store that contains symbols that are not present in a
given package. Why not just intern them?

Vladimir



From hans.huebner at gmail.com  Wed May 20 19:02:38 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 20 May 2009 21:02:38 +0200
Subject: [bknr-devel] Motivation for not interning symbols when loading
	a store
In-Reply-To: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com>
References: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com>
Message-ID: <fd2982320905201202y23892b58ga5c05bcada51fba@mail.gmail.com>

On Wed, May 20, 2009 at 20:31, Vladimir Sedach <vsedach at gmail.com> wrote:
> I'm genuinely perplexed why the BKNR datastore throws an error when it
> tries to load a store that contains symbols that are not present in a
> given package. Why not just intern them?

I have never seen this as a problem, and it would be easy to change.
Maybe you can send me a patch that I could look at?  I'd like to see
interning on load be controlled by a special variable,
*intern-symbols-on-load*.

-Hans



From vsedach at gmail.com  Thu May 21 18:18:09 2009
From: vsedach at gmail.com (Vladimir Sedach)
Date: Thu, 21 May 2009 12:18:09 -0600
Subject: [bknr-devel] Motivation for not interning symbols when loading
	a store
In-Reply-To: <fd2982320905201202y23892b58ga5c05bcada51fba@mail.gmail.com>
References: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com>
	<fd2982320905201202y23892b58ga5c05bcada51fba@mail.gmail.com>
Message-ID: <c07e645b0905211118q15ba6924uaf43a5c6f4c3920b@mail.gmail.com>

The patch is trivial, but I'd like to know the reason for the current behavior.

There's also something fishy about %decode-symbol's :intern keyword
parameter. When it's not true, %decode-symbol returns nil. The only
time this is possibly the case occurs in snapshot-read-layout:

(defun snapshot-read-layout (stream layouts)
  (let* ((id (%decode-integer stream))
         (class-name (%decode-symbol stream :usage "class"))
         (nslots (%decode-integer stream))
         (class (find-class-with-interactive-renaming class-name))
         (slot-names (loop repeat nslots collect (%decode-symbol stream

:intern (not (null class))

:usage "slot")))
         (slots (if class
                    (find-class-slots-with-interactive-renaming class
slot-names)
                    slot-names)))
    (setf (gethash id layouts)
          (cons class slots))))

So if find-class-with-interactive-renaming doesn't find a class, all
%decode-symbol does is read the stream and throw what it reads away? I
don't get whether that's intended behavior or a bug.

Vladimir

On Wed, May 20, 2009 at 1:02 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Wed, May 20, 2009 at 20:31, Vladimir Sedach <vsedach at gmail.com> wrote:
>> I'm genuinely perplexed why the BKNR datastore throws an error when it
>> tries to load a store that contains symbols that are not present in a
>> given package. Why not just intern them?
>
> I have never seen this as a problem, and it would be easy to change.
> Maybe you can send me a patch that I could look at? ?I'd like to see
> interning on load be controlled by a special variable,
> *intern-symbols-on-load*.
>
> -Hans
>



From hans.huebner at gmail.com  Thu May 21 19:31:49 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 21 May 2009 21:31:49 +0200
Subject: [bknr-devel] Motivation for not interning symbols when loading
	a store
In-Reply-To: <c07e645b0905211118q15ba6924uaf43a5c6f4c3920b@mail.gmail.com>
References: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com> 
	<fd2982320905201202y23892b58ga5c05bcada51fba@mail.gmail.com> 
	<c07e645b0905211118q15ba6924uaf43a5c6f4c3920b@mail.gmail.com>
Message-ID: <fd2982320905211231x684455aao5bd7a776648dda6e@mail.gmail.com>

On Thu, May 21, 2009 at 20:18, Vladimir Sedach <vsedach at gmail.com> wrote:
> The patch is trivial, but I'd like to know the reason for the current behavior.

The reason is that we want to be able to read snapshots with new
software releases without neccessarily interning all symbols found in
them.

> There's also something fishy about %decode-symbol's :intern keyword
> parameter. When it's not true, %decode-symbol returns nil. The only
> time this is possibly the case occurs in snapshot-read-layout:
> [...]
> So if find-class-with-interactive-renaming doesn't find a class, all
> %decode-symbol does is read the stream and throw what it reads away? I
> don't get whether that's intended behavior or a bug.

That is indeed the intended behavior.  If a snapshot references a
class that does not exist in the running Lisp image and that is not
interactively renamed, objects of that class should just be skipped.
I have used that mechanism when upgrading software releases, finding
it easier to hack the store so that old snapshots can be read rather
than having to do in-image upgrades (load old software, load snapshot,
load new software, dump).

-Hans



From vsedach at gmail.com  Fri May 22 21:37:26 2009
From: vsedach at gmail.com (Vladimir Sedach)
Date: Fri, 22 May 2009 15:37:26 -0600
Subject: [bknr-devel] Motivation for not interning symbols when loading
	a store
In-Reply-To: <fd2982320905211231x684455aao5bd7a776648dda6e@mail.gmail.com>
References: <c07e645b0905201131q6f90e7ebjdeb8a1c3a5694ded@mail.gmail.com>
	<fd2982320905201202y23892b58ga5c05bcada51fba@mail.gmail.com>
	<c07e645b0905211118q15ba6924uaf43a5c6f4c3920b@mail.gmail.com>
	<fd2982320905211231x684455aao5bd7a776648dda6e@mail.gmail.com>
Message-ID: <c07e645b0905221437r528988a4w29323b67ff2e30b1@mail.gmail.com>

That makes sense. I don't think it's a good idea to include the
automatic interning option in, since that will change the semantics of
store loading, plus is probably an indication that the datastore user
is probably making a design mistake in his/her application code
(which, in hindsight, is what prompted my original query).

Thank you,
Vladimir

On Thu, May 21, 2009 at 1:31 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> On Thu, May 21, 2009 at 20:18, Vladimir Sedach <vsedach at gmail.com> wrote:
>> The patch is trivial, but I'd like to know the reason for the current behavior.
>
> The reason is that we want to be able to read snapshots with new
> software releases without neccessarily interning all symbols found in
> them.
>
>> There's also something fishy about %decode-symbol's :intern keyword
>> parameter. When it's not true, %decode-symbol returns nil. The only
>> time this is possibly the case occurs in snapshot-read-layout:
>> [...]
>> So if find-class-with-interactive-renaming doesn't find a class, all
>> %decode-symbol does is read the stream and throw what it reads away? I
>> don't get whether that's intended behavior or a bug.
>
> That is indeed the intended behavior. ?If a snapshot references a
> class that does not exist in the running Lisp image and that is not
> interactively renamed, objects of that class should just be skipped.
> I have used that mechanism when upgrading software releases, finding
> it easier to hack the store so that old snapshots can be read rather
> than having to do in-image upgrades (load old software, load snapshot,
> load new software, dump).
>
> -Hans
>