emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: BLV for function slots + BL obarray/hmap for symbol lookup?


From: Arthur Miller
Subject: Re: Q: BLV for function slots + BL obarray/hmap for symbol lookup?
Date: Sun, 30 May 2021 14:17:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Arthur Miller [2021-05-30 04:30:24] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>>>     (setq-local obarray (obarray-copy obarray))
>>> [...]
>>>> (setq-local obarray (copy-sequence obarray))
>>>
>>> obarray-copy != copy-sequence
>> My Emacs 27.1 says void function obarray-copy,
>
> Indeed, it's not provided.
>
>> but copy-sequence worked.
>
> Not really, no.  You just haven't noticed the breakage yet.

Shallow copy, as Michael pointed it out? I'll see to update my Emacs.

>>  Aren't obarray just vectors?
>
> No, they're very special vectors.  E.g.:
>
>     (let ((oa (make-vector 1 nil)))
>       (intern "foo" oa)
>       (intern "bar" oa)
>       (intern "baz" oa)
>       oa)
>
>     ==>
>
>       [baz]
>
> Yet, `foo` and `bar` are definitely still in there.

Yes, manual says use size 0 when making an obarray, so I understand the
space is allocated elsewhere, when interning is happening.

>> For your previous mail; yes I am quite aware this is very use-case
>> specific solution. Anything done elsewhere, outside that particular
>> buffer after the copy is performed will not be visible in that buffer,
>> as well as no definition will escape to rest of the Emacs, so this
>> buffer can only be used to change state of this particular buffer and
>> nothing else, and that can be quite brittle. For the bad and good. I
>> haven't experimented enough yet, just a bit, I am not sure how it will
>> work with Emacs state internally, gc? etc.
>
> AFAIK I think it can be made to work, yes.
> I don't expect any problem from "Emacs state internally" or the GC.
>
> The only source of trouble I can foresee is if "normal code" ends up
> running while your obarray is the one held in the global `obarray` var.
> This is because "normal code" will occasionally load files (via
> `require` or autoloads, typically) and that can quickly lead to
> confusion.
>
Allright, thanks for the clarifications.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]