I’m using sweeprolog as my daily driver, kudos @oskardrums for writing it! I love the features, but I’m experiencing some instability with top-level commands. For example, when running sweeprolog-restart, my emacs crashes - particularly disruptive as it simultaneously closes all of my open docs, prolog-related or not.
For clarity: I’m on (doom) emacs 29.1 operating as a daemon. Anyone else experiencing this?
Thanks, that’s great to hear 
Hmm
That’s certainly not good… If you can share more details that can help investigating this crash, I’d be happy to look into it.
Thanks @oskardrums, I’ll try to gather more info. in the meanwhile If you can think about anything that would help you, share it here and I’ll send the response.
Thanks, if you have a core dump or some kind of trace from the crash, that’d be ideal. Otherwise, just the basics about your setup might help: which versions of SWI-Prolog, Emacs, and Sweep you are using, and maybe how you’ve installed them.
EDIT:
P.S. small tip: the command M-x sweeprolog-submit-bug-report creates a bug report buffer prepopulated with some of the commonly relevant data points.
Here are more info (and the output of sweeprolog-submit-bug-report below).
nix, while I installed the sweeprolog package via:(package! sweeprolog
:recipe
(:type git
:host nil
:repo "https://git.sr.ht/~eshel/sweep"
:branch "main"
:files ("*.el" "sweep.pl")))
I check the logs via journalctl --user -u emacs.service but nothing of substance is logged there. That said, when the “crash” happens, the entire content of the *messages* buffer is wiped out, which leads me to think that the crash is happening but maybe is being restarted without printing anything?
The info from sweeprolog-submit-bug-report:
Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
Package: Sweep v0.25.2
current state:
==============
(setq
sweeprolog--directory "/home/carlo/system/config/emacs/.local/straight/build-29.1/sweeprolog/"
sweeprolog--initialized t
sweeprolog-init-args '("-q" "--no-signals" "-g" "create_prolog_flag(sweep,true,[access(read_only),type(boolean)])" "-l" "/home/carlo/system/config/emacs/.local/straight/build-29.1/sweeprolog/sweep.pl")
sweeprolog-swipl-path nil
system-configuration-features "CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB"
)
Thanks for the info
I’m not entirely sure the issue is confined to cases when Emacs is running as a daemon, because I remember seeing a crash during PL_cleanup (which sweeprolog-restart calls), and I rarely run Emacs as a daemon. Does this crash reproduce for you with Emacs running as a daemon?
It might be a good idea to update to the latest version (0.26.0), there were some changes around how Emacs communicates with top-level threads which may be relevant if you’re restarting Sweep while there are top-levels running.
I might have been a little unclear before, when I use the daemon, this crash is not something that happens randomly, but a deterministic behavior. The PL_cleanup seem promising, how can I try to activate it manually to see if it crashes?
I’ll try updating sweep and report back!
Cleanup and restart Prolog in the same process is not well supported by various of the extension packages that use C code. Many such packages tend to store things that are constant in a Prolog session. They should implement an uninstall handler to clear these cached handles, but they don’t. Also, the order in which things would need to be shut down cleanly is not always clear.
So, unfortunately, restarting should be considered unsafe when extensions are involved and quite likely there are still bugs without extensions. That makes sweep not very usable with emacs server mode 
It is more like using the built-in editor: you get a Prolog process with an editor. This may crash, in particular when not well tested foreign extensions are involved. When working in such scenarios, I tend to have two. One I use for editing with the code loaded such that all nice features work and one I use for testing and debugging.
I’ve also had Emacs crash when trying to restart the top-level, generally after a bunch of stuff has been loaded, including packages with C code (particularly my automake pack). I’ve just been working around this by using a separate terminal window to actually run my code, but obviously being able to live fully in Emacs would be superior…
At some point I’ll try to track this down, but we have a brand-new baby in the home now, so my time is rather limited and fragmented 
I see, that does sound a lot like the issue @jan described above.
Congratulations! I suppose that’s one thing Emacs can’t really help you with 
Ok, I updated sweep at the latest version (see below for details) and now I can’t get it started (in daemon or in standalone mode). When I try to open a top-level, I get
Process sweeprolog-top-level failed with code 0
How can I debug what’s going wrong here?
Additional details:
Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
Package: Sweep v0.26.0
current state:
==============
(setq
sweeprolog--directory "/home/carlo/system/config/emacs/.local/straight/build-29.1/sweeprolog/"
sweeprolog--initialized t
sweeprolog-init-args '("-q" "--no-signals" "-g" "create_prolog_flag(sweep,true,[access(read_only),type(boolean)])" "-l" "/home/carlo/system/config/emacs/.local/straight/build-29.1/sweeprolog/sweep.pl")
sweeprolog-swipl-path nil
system-configuration-features "CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB"
)
Thanks for the clarification, I’ve looked a bit into it and I suspect this has to do with our recent transition to using a pty for the communication between Emacs and the top-level thread. This seems to run into troubles when Emacs is running as a daemon, although I’m not sure exactly why just yet.
Could you please try setting sweeprolog-top-level-use-pty to nil before starting any top-levels (maybe in your init file) and check if you still see this crash?
This should be fixed in the latest master (commit 3521dc3e7bd4098e472974f93ac292c63005eeb3), sorry about that!
EDIT: just to be clear - this was an unrelated issue to the Emacs daemon crash
I’m extremely happy to report that this was indeed the case, and now I can even restart sweeprolog from emacs daemon!
And yes the startup problem was fixed in latest master.
Thank you for the solution and the very quick responses 
Great! This should only be considered a workaround though, hopefully I’ll figure why the Emacs daemon crashes when we use a pty, and come up with a nicer solution.
Sure, thanks for testing and reporting
I’ve now pushed an update that addresses this issue. @meditans you should be able to set sweeprolog-top-level-use-pty back to t without fear of the Emacs daemon shutting down when you close a top-level