Fix export to only export symbols of current package.

[Ambrevar]

Previously, defclass-star* would fail when overriding a slot of a superclass.
Example recipe:

    (setf hu.dwim.defclass-star::*export-slot-names-p* t)
    (hu.dwim.defclass-star:defclass* foo ()
        ((foo-name :initform "foo name")))

    (defpackage foo-package
      (:use :cl))
    (in-package foo-package)

    (hu.dwim.defclass-star:defclass* bar (cl-user:foo)
        ((cl-user:foo-name :initform "bar name")))

[attila-lendvai]

this broke our codebase in a non-trivial way.

@Ambrevar are you sure that this is the right fix for whatever issue you experienced?

[Ambrevar]

It's been working for Nyxt ever since.
At first glance I can't see what's wrong with the patch. Could you elaborate with what went wrong on your end?

[attila-lendvai]

AFAIU, it fails to export the NAME-OF symbol from hu.dwim.walker, due to which the originally single generic method got split into two, the other one being a now private/isolated NAME-OF in hu.dwim.meta-model.

or to put it another way: our codebase expects that symbols get exported, regardless of what is their home package.

i have rewound the stable tag, and this should fix quicklisp for now, but this needs to be addressed eventually.

[attila-lendvai]

i also opened an issue not to forget this.

[attila-lendvai]

@Ambrevar i just understood that rewinding defclass-star in ql breaks nyxt (until now i didn't know what it is, or that it's part of ql).

how about reverting this single commit, at least for the time being? does nyxt depend on it?

[Ambrevar]

Reverting this single commit is the best course of action for now. Nyxt does not depend on it directly, but the proper behaviour of Nyxt's user configuration does, so reverting this will introduce a bug for Nyxt's user who build from Quicklisp. Anyways, it's not a big deal since Quicklisp is not officially supported anymore by Nyxt. The official way to build it is via Git submodules or Guix / Nix.

[attila-lendvai]

i've reverted it, and updated the stable tag. ql should be all green.

[attila-lendvai]

FTR, i do not consider the current behavior a bug.

the CL symbol exporting operation does not care whether the home package of the symbol being exported is the same package it is being exported from. i do not see any reason why the default behavior should not be aligned with the semantics of CL's own export operation.

and introducing a non-trivial bug into our codebase is only a wakeup call, not the reason for this.