Re: Fwd: Fails to bring up a back trace

[Basile Starynkevitch <basile@starynkevitch.net>]

On 11/30/23 11:17, tomas@tuxteam.de wrote:
> On Thu, Nov 30, 2023 at 10:47:36AM +0100, Basile Starynkevitch wrote:
>> On 11/30/23 05:58, tomas@tuxteam.de wrote:
>>> On Thu, Nov 30, 2023 at 10:43:45AM +1300, Davin Pearson wrote:
>>>
>>> [...]
>>>
>>>> Yet it fails to bring up an error backtrace.
>>> I fear this is too scant a context to feed educated guesses. But
>>> this, at least, looks wrong to me:
>>>
>>>> I also tried the following command:
>>>>
>>>> emacs --geometry 2048x1024 --eval "(setq debug-on-error)" --debug-init &
>>> ... it should be "(setq debug-on-error t)".
>>
>> A possible approach to backtracking on Linux might be to improve or enhance
>> GNU emacs to use Ian Taylor's libbacktrace open source library. The
>> libbacktrace source code is on
>> https://github.com/ianlancetaylor/libbacktrace
> [...]
>
> Hi, Basile
>
> I think (but I may be wrong, of course) the OP's problem was much simpler
> and they were just after a plain boring Lisp stack trace.


But recent GNU emacs can be built to use the libgccjit library to 
translate emacs lisp code to machine code, and can also be built to 
accept emacs modules, that is dlopen-ed shared libraries. See 
https://phst.eu/emacs-modules.html

I tend to believe that a plain boring Lisp stack trace is not always 
enough (since emacs lisp bytecode is sometimes translated to maching 
code, or because of emacs modules).


>
> That saie, I'm still a fan of your work :)


Thanks. The issue is find funding and ITEA or HorizonEurope consortium 
supporting https://github.com/RefPerSys/RefPerSys/

>
> Cheers

-- 
Basile Starynkevitch
  <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/