From: "Ludovic Courtès" <ludo@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: Pierre Neidhardt <mail@ambrevar.xyz>, 33848@debbugs.gnu.org
Subject: bug#33848: Store references in SBCL-compiled code are "invisible"
Date: Wed, 26 Dec 2018 17:14:09 +0100 [thread overview]
Message-ID: <877efwe04u.fsf@gnu.org> (raw)
In-Reply-To: <87tvj2yesd.fsf@netris.org> (Mark H. Weaver's message of "Mon, 24 Dec 2018 13:12:23 -0500")
Hello!
Mark H Weaver <mhw@netris.org> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>>
>>>> For now I lean towards looking for a way to address the issue
>>>> specifically for SBCL.
>>>
>>> Don't forget that we currently have 5 Lisp compilers.
>>> Besides, it's not clear that this can be fixed on the compiler's side, it could
>>> very well be that patches will be required on a per-project basis.
>>
>> I know little about CL but maybe we can find a solution that works for
>> all five compilers. At least that would be the first approach I would
>> suggest following.
>
> I can't imagine a solution that would work for all five compilers, but
> perhaps that's a failure of imagination on my part. Of course, you're
> welcome to search for such a solution. Can you give me a rough outline
> of what you have in mind?
I have nothing specific in mind, I’m just brainstorming with everyone
here. :-)
For a similar situation in C++, there’s a fairly simple and local
workaround:
https://issues.guix.info/issue/30265#8
I’m not familiar with CL but I thought that it we could achieve
something similar, that would be great—I’m not suggesting to change the
CL compilers in any non-trivial way.
For example I guess we could always store the file name as a literal
byte vector/list and add a call to turn that into a string.
Does that make sense?
Thanks,
Ludo’.
next prev parent reply other threads:[~2018-12-26 16:15 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-23 14:19 bug#33848: Store references in SBCL-compiled code are "invisible" Ludovic Courtès
2018-12-23 15:05 ` Pierre Neidhardt
2018-12-24 14:57 ` Ludovic Courtès
2018-12-23 16:45 ` Mark H Weaver
2018-12-23 17:32 ` Ludovic Courtès
2018-12-23 22:01 ` Pierre Neidhardt
2018-12-24 15:06 ` Ludovic Courtès
2018-12-24 17:08 ` Pierre Neidhardt
2018-12-26 16:07 ` Ludovic Courtès
2018-12-24 18:12 ` Mark H Weaver
2018-12-24 23:58 ` Pierre Neidhardt
2018-12-26 16:14 ` Ludovic Courtès [this message]
2018-12-27 10:37 ` Pierre Neidhardt
2018-12-27 14:03 ` Mark H Weaver
2018-12-27 14:45 ` Ludovic Courtès
2018-12-27 15:02 ` Pierre Neidhardt
2018-12-27 16:15 ` Pierre Neidhardt
2018-12-27 17:03 ` Ludovic Courtès
2018-12-27 18:57 ` Pierre Neidhardt
2018-12-27 21:54 ` Ludovic Courtès
2018-12-27 22:05 ` Pierre Neidhardt
2018-12-27 22:59 ` Ludovic Courtès
2018-12-28 7:47 ` Pierre Neidhardt
2021-03-30 10:15 ` Pierre Neidhardt
2021-03-30 20:09 ` Ludovic Courtès
2021-03-31 7:10 ` Pierre Neidhardt
2021-03-31 16:12 ` Pierre Neidhardt
2021-03-31 20:42 ` Ludovic Courtès
2021-03-31 20:57 ` Pierre Neidhardt
2021-04-01 17:23 ` Mark H Weaver
2021-04-02 15:13 ` Ludovic Courtès
2021-04-01 6:03 ` Mark H Weaver
2021-04-01 7:13 ` Pierre Neidhardt
2021-04-01 7:57 ` Ludovic Courtès
2021-04-01 8:48 ` Pierre Neidhardt
2021-04-01 9:07 ` Guillaume Le Vaillant
2021-04-01 9:13 ` Pierre Neidhardt
2021-04-01 9:52 ` Guillaume Le Vaillant
2021-04-01 10:06 ` Pierre Neidhardt
2021-04-01 10:07 ` Pierre Neidhardt
2021-04-01 15:24 ` Ludovic Courtès
2021-04-01 17:33 ` Mark H Weaver
2021-04-02 22:46 ` Mark H Weaver
2021-04-03 6:51 ` Pierre Neidhardt
2021-04-03 20:10 ` Mark H Weaver
2021-04-05 19:45 ` Ludovic Courtès
2021-04-05 23:04 ` Mark H Weaver
2021-04-06 8:16 ` Ludovic Courtès
2021-04-06 8:23 ` Pierre Neidhardt
2021-04-30 20:03 ` Mark H Weaver
2021-05-01 9:22 ` Pierre Neidhardt
2021-05-11 8:46 ` Ludovic Courtès
2021-04-06 17:23 ` Leo Famulari
2021-04-06 23:21 ` Mark H Weaver
2021-04-06 11:19 ` Mark H Weaver
2021-04-08 10:13 ` Ludovic Courtès
2021-04-13 20:06 ` Mark H Weaver
2021-04-14 10:55 ` Ludovic Courtès
2021-04-14 22:37 ` Leo Famulari
2021-04-15 7:26 ` Mark H Weaver
2021-04-16 9:44 ` Pierre Neidhardt
2018-12-27 13:52 ` Danny Milosavljevic
2018-12-27 14:29 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877efwe04u.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=33848@debbugs.gnu.org \
--cc=mail@ambrevar.xyz \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.