GNU bug report logs - #66261
Disassembling a regexp's bytecode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66261 in the body.
You can then email your comments to 66261 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: Disassembling a regexp's bytecode
Date: Thu, 28 Sep 2023 22:28:16 -0400

[Message part 1 (text/plain, inline)]

Tags: patch

I'd like to add a function that lets us see a regexp's bytecode directly
from within Emacs (recompiling with REGEX_EMACS_DEBUG can be quite useful
in many cases, but it's much more invasive and it's often overkill).

The patch below is what I use currently, but clearly it's not ready for
`master`.  Before I try and clean it, I'd like to discuss some issues to
figure out how best to solve them:

- First, in order to easily use the same code between REGEX_EMACS_DEBUG
  and my new `re--describe-compiled`, I need to print sometimes to
  `stderr` and sometimes to a string, which I do using `open_memstream`.
  AFAIK `open_memstream` is not directly available in Windows (and
  maybe under some other Unixes either, tho it's in POSIX-2008, IIUC).
  Could someone help me get an `opem_memstream` emulation working
  (maybe via gnulib)?

- I'm thinking of always providing this function.  Another option would
  be to do it under the control of a compilation flag, tho it doesn't
  seem worth adding a new flag just for that.  I guess we could
  reuse REGEX_EMACS_DEBUG (tho it's too invasive IMO), or
  ENABLE_CHECKING, but I'd rather just always offer the function.
  After all, it might encourage users to look more carefully at their
  regexps and maybe even to help us improve our regexp engine, who knows.


        Stefan


 In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2023-09-16 built on pastel
Repository revision: 0954f127b8840bf843a2acfb18d2e18e526166e1
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign'
 PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'

[regexp.patch (text/patch, attachment)]

Message #8 received at 66261 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 66261 <at> debbugs.gnu.org
Subject: Re: bug#66261: Disassembling a regexp's bytecode
Date: Fri, 29 Sep 2023 18:06:13 +0300

> Date: Thu, 28 Sep 2023 22:28:16 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> - First, in order to easily use the same code between REGEX_EMACS_DEBUG
>   and my new `re--describe-compiled`, I need to print sometimes to
>   `stderr` and sometimes to a string, which I do using `open_memstream`.
>   AFAIK `open_memstream` is not directly available in Windows (and
>   maybe under some other Unixes either, tho it's in POSIX-2008, IIUC).
>   Could someone help me get an `opem_memstream` emulation working
>   (maybe via gnulib)?

Gnulib doesn't have such an emulation, AFAICT.

Why cannot you fall back to temporary files when open_memstream is not
available?

> - I'm thinking of always providing this function.  Another option would
>   be to do it under the control of a compilation flag, tho it doesn't
>   seem worth adding a new flag just for that.  I guess we could
>   reuse REGEX_EMACS_DEBUG (tho it's too invasive IMO), or
>   ENABLE_CHECKING, but I'd rather just always offer the function.
>   After all, it might encourage users to look more carefully at their
>   regexps and maybe even to help us improve our regexp engine, who knows.

I would suggest to have it under ENABLE_CHECKING first, and only
remove the condition if there's a demand.  (I assume that most people
who debug regexps build Emacs with --enable-checking.)

Message #11 received at 66261 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66261 <at> debbugs.gnu.org
Subject: Re: bug#66261: Disassembling a regexp's bytecode
Date: Fri, 29 Sep 2023 11:47:50 -0400

>> - First, in order to easily use the same code between REGEX_EMACS_DEBUG
>>   and my new `re--describe-compiled`, I need to print sometimes to
>>   `stderr` and sometimes to a string, which I do using `open_memstream`.
>>   AFAIK `open_memstream` is not directly available in Windows (and
>>   maybe under some other Unixes either, tho it's in POSIX-2008, IIUC).
>>   Could someone help me get an `opem_memstream` emulation working
>>   (maybe via gnulib)?
> Gnulib doesn't have such an emulation, AFAICT.
> Why cannot you fall back to temporary files when open_memstream is not
> available?

Doesn't seem worth the trouble (and I must admit that the idea of using
a temp file hurts my sense of aesthetics, on top of it 😀.  Tho, it'd be
OK if it were done for me by gnulib).

>> - I'm thinking of always providing this function.  Another option would
>>   be to do it under the control of a compilation flag, tho it doesn't
>>   seem worth adding a new flag just for that.  I guess we could
>>   reuse REGEX_EMACS_DEBUG (tho it's too invasive IMO), or
>>   ENABLE_CHECKING, but I'd rather just always offer the function.
>>   After all, it might encourage users to look more carefully at their
>>   regexps and maybe even to help us improve our regexp engine, who knows.
>
> I would suggest to have it under ENABLE_CHECKING first, and only
> remove the condition if there's a demand.  (I assume that most people
> who debug regexps build Emacs with --enable-checking.)

OK, I'll make it conditional on ENABLE_CHECKING as well as on the
presence of `open_memstream`.


        Stefan

Message #14 received at 66261 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 66261 <at> debbugs.gnu.org
Subject: Re: bug#66261: Disassembling a regexp's bytecode
Date: Fri, 29 Sep 2023 19:24:39 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 66261 <at> debbugs.gnu.org
> Date: Fri, 29 Sep 2023 11:47:50 -0400
> 
> >> - First, in order to easily use the same code between REGEX_EMACS_DEBUG
> >>   and my new `re--describe-compiled`, I need to print sometimes to
> >>   `stderr` and sometimes to a string, which I do using `open_memstream`.
> >>   AFAIK `open_memstream` is not directly available in Windows (and
> >>   maybe under some other Unixes either, tho it's in POSIX-2008, IIUC).
> >>   Could someone help me get an `opem_memstream` emulation working
> >>   (maybe via gnulib)?
> > Gnulib doesn't have such an emulation, AFAICT.
> > Why cannot you fall back to temporary files when open_memstream is not
> > available?
> 
> Doesn't seem worth the trouble (and I must admit that the idea of using
> a temp file hurts my sense of aesthetics, on top of it 😀.  Tho, it'd be
> OK if it were done for me by gnulib).

Then just let it write to stderr, it's okay to do that in
ENABLE_CHECKING code.

Message #17 received at 66261 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66261 <at> debbugs.gnu.org
Subject: Re: bug#66261: Disassembling a regexp's bytecode
Date: Fri, 29 Sep 2023 12:33:36 -0400

>> Doesn't seem worth the trouble (and I must admit that the idea of using
>> a temp file hurts my sense of aesthetics, on top of it 😀.  Tho, it'd be
>> OK if it were done for me by gnulib).
>
> Then just let it write to stderr, it's okay to do that in
> ENABLE_CHECKING code.

Good idea.  It's best if I can get the string to ELisp (it's common
for Emacs's stderr to be discarded or hard to reach when started by the
desktop environment), but stderr is better than nothing, when
`open_memstream` is not available.

Thanks,


        Stefan

Message #22 received at 66261-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66261-done <at> debbugs.gnu.org
Subject: Re: bug#66261: Disassembling a regexp's bytecode
Date: Fri, 29 Sep 2023 14:56:34 -0400

Pushed to `master` with a short mention in search.texi.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.