From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Andrea Corallo <akrl@sdf.org>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 42088@debbugs.gnu.org, Sebastian Sturm <mail@sebastian-sturm.de>
Subject: bug#42088: [feature/native-comp] Lockup on opening TypeScript files
Date: Tue, 30 Jun 2020 08:06:47 +0000 (UTC) [thread overview]
Message-ID: <1924395113.150369.1593504407966@mail.yahoo.com> (raw)
In-Reply-To: <jwvd05h2smt.fsf-monnier+emacs@gnu.org>
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Okay after some digging I think I've an idea of what is going on:
>>
>> the code was hanging in `typescript--ensure-cache' in the loop
>>
>> (cl-loop while (re-search-forward typescript--quick-match-re-func nil t)...
>>
>> This because typescript--quick-match-re-func is not set correctly going
>> back and back this is because `typescript--available-frameworks' is set
>> to nil.
>
> Hmm... I'm afraid I can't follow this. Could you provide some details?
Sure,
this is how `typescript--available-frameworks' is computed in
typescript-mode.el.
===
(defconst typescript--available-frameworks
(cl-loop with available-frameworks
for style in typescript--class-styles
for framework = (plist-get style :framework)
unless (memq framework available-frameworks)
collect framework into available-frameworks
finally return available-frameworks)
"List of available typescript frameworks symbols.")
===
The loop is expanded in:
===
(cl-block nil
(let*
((available-frameworks nil)
(--cl-var-- typescript--class-styles)
(style nil)
(framework nil)
(available-frameworks nil)
(--cl-var-- t))
(while
(consp --cl-var--)
(setq style
(car --cl-var--))
(setq framework
(plist-get style :framework))
(if
(memq framework available-frameworks)
(progn)
(setq available-frameworks
(nconc available-frameworks
(list framework))))
(setq --cl-var--
(cdr --cl-var--))
(setq --cl-var-- nil))
available-frameworks))
===
If the two --cl-var-- are confused we never iterate and the block
evaluates to nil. As a result `typescript--available-frameworks' was
(incorrectly) set to nil.
>> IIUC the reason for that is: cl-macs is expanding cl-loop using various
>> `--cl-var--', these looks the same but each of this is a separete
>> uninterned symbol. The native compiler squash them all toghether having
>> to pass them through the reader and a simple testcase like this fails to
>> behave as expected.
>
> How/where exactly do they get squashed?
>
> The printer is normally able to preserve this info (printing #:<foo>
> instead of <foo> for uninterned symbols and using #= and such the refer
> to exactly that symbol) when printing code into the .elc file, so I'm
> wondering why it gets lost when going through the native compiler.
Yes that's the conclusion I came-up shortly after. Turned out that the
native compiler was not configuring the printer to handle uninterned
symbols, so the fix I pushed Sunday:
7f8512765a * Setup correctly the printer while dumping objs in native CU (bug#42088)
I corrected myself and discussed the fix in a mail sent into this thread
but unfortunately this got lost. My sdf mail lost a number of mails in
the last days both incoming and out-coming (possibly including one I sent
you :).
This mail lossage has been extremely annoying sorry.
Andrea
next prev parent reply other threads:[~2020-06-30 8:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-27 16:55 bug#42088: [feature/native-comp] Lockup on opening TypeScript files Sebastian Sturm
2020-06-27 21:25 ` Andrea Corallo
2020-06-28 10:43 ` Andrea Corallo
2020-06-28 20:38 ` Andrea Corallo
2020-06-30 2:33 ` Stefan Monnier
2020-06-30 8:06 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2020-06-30 14:03 ` Stefan Monnier
2020-06-30 14:43 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-06-29 21:01 ` Sebastian Sturm
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=1924395113.150369.1593504407966@mail.yahoo.com \
--to=bug-gnu-emacs@gnu.org \
--cc=42088@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=andrea_corallo@yahoo.it \
--cc=mail@sebastian-sturm.de \
--cc=monnier@iro.umontreal.ca \
/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/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.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.