IRC channel logs
2024-01-26.log
back to list of logs
<rlb>civodul: looks like it's actually hanging in test-signal-fork <rlb>warning: call to primitive-fork while multiple threads are running; <rlb> further behavior unspecified. See "Processes" in the <rlb> manual, for more information. <rlb>That's the last thing in the test-signal-fork.log. If that doesn't mean anything to anyone, I'll delve later. <daviid>ieure: where did you look and/or how did you searched, to 'only' see guile-gi? i wonder <rlb>sneek: later tell civodul not sure what it means yet, but it looks like the test-signal-fork parent is hanging forever in scm_i_signals_post_for() when it locks up. <natmeo>am I being silly, or are backtraces virtually useless for code that's executed from the repl (i.e. from geiser) <natmeo>it says the name of the function where the error was raised, but not the location <apteryx>right, a REPL has no associated file name <apteryx>I wouldn't say it makes the backtrace useless though; what would other languages show? Have you tried the same e.g. in Python? <natmeo>apteryx: i dont do interactive in python though, beside jupyter lab <natmeo>I mean I understand _compiled_ code doesnt have this problem <natmeo>but i'm wonderinf if something that was evaluated partially in emacs (i.e. defun) could pass metadata about code location into the compilter <lloda>the repl numbers your inputs so i don't see why that couldn't be used as 'source info', in principle <lloda>idk how useful that would be <natmeo>ultimately i would expect the backtrace to show me the exact place in source where the problem occured, whether it was evaluated locally in repl, remotely from geiser, or compiled from source <dthompson>the important missing detail here is that read-syntax gets the source location comes from the port object. when you're using the repl, input is read from stdin which has no file name. <natmeo>sure, what I am asking is whether in case of evaluation _from geiser_ there's any technical limitation that would prevent geiser from shipping source location metadata <natmeo>beside "no one implemented this" I mean <dthompson>the technical limitation is that geiser has no control over the source location metadata <dthompson>the scheme reader uses the port file name and current line/column information to associate metadata with each scheme value it reads <ArneBab>natmeo: I’m not sure whether it’s possible to mutate the filenames in stdin from the process writing there, and whether Guile would then change what it reads accordingly. If not, you may be able to implement a custom protocol for communication with Guile where you send the filename and line numbers for every block of code, but that would likely be lots of effort. <dthompson>if you compile a file from geiser all the source is there <dthompson>because guile has a file port to get metadata from <dthompson>evaling stuff in geiser just sends expressions over stdin, no way to get source info <dthompson>maybe if the guile reader was implemented in elisp it could then send over an expression that constructs syntax objects with the source info from the buffer <dthompson>but writing a completely separate reader seems like a bad idea <dthompson>the simplest things to do is C-c C-k to compile your module when source location becomes important <natmeo>yes i figured that out.. earlier today <old>what if there was a file in between geiser and the reader? <old>instead of communicating directly via a pipe I guess <old>communicate over a named temporary file. You get the source location that way? <dthompson>old: that would always tell you the same file name that is different from the file you were working in? <old>right, instead of <stdin> I guess <dthompson>to do this properly would require some new protocol <dthompson>a custom port implementation might be the thing <old>Is nREPL any different in that sens? <old>there's some implementatin of nREPL for Guile and Emacs. Can't recall the name <dthompson>let's assume that geiser could make this happen... the source info might be useful but it might be completely out-of-date depending on what edits happened between the time of eval and the time of inspection <dthompson>*if* the custom ports interface allows full control over the location metadata then it would be possible for geiser to acpture the source info in emacs and pass it over <old>sounds like nREPL could be it then. From my understnading, it is a RPC between the IDE and the runtime <old>so it is much more robust than simply sending s-exp to be evaluated <lispmacs[work]>hi, I'm trying use hall for the first time, and install (my own) local guile code using guix. It seems that hall does not install a required guile.m4 file needed for the configure file to work, and I'm wondering how I should be getting that file in the project <lispmacs[work]>do I just download it from somewhere, or am I suppose to install it with one of the autotools, or...? <lispmacs[work]>I copied it over, looks like there are some other m4 files I'm missing as well (pkg.m4)