libera/#commonlisp - IRC Chatlog
Search
6:14:04
phantomics_
Question: Is there an SBCL function that will return the current call stack? I.e. the stack of the current invocation of the function that the tracing function is called within
6:33:38
phantomics_
Here's what I get from one element in the call stack: #<DISSECT::SBCL-CALL [7] (LAMBDA (I) IN INDEXER-OF) | /home/user/src/lisp/april/varray/varray.lisp>
6:34:33
phantomics_
The problem is, INDEXER-OF is a method that belongs to many different classes. Is there a way to determine which class this specific indexer-of applies to?
7:51:08
artchad
Hey, I have a sbcl image running on a server. In order to connect to that repl I need a swank server running inside that image. So I do `(require:swank)' and `(swank:create-server)'. But after some time the swank server is no longer accessible. It just closes the port. Is that the default behaviour?
7:52:46
artchad
How would I make sure to keep the swank server running for the whole time, because when I ssh into the box, I don't have direct access to the shell where the sbcl process is running. The only way to access that is via swank.
7:55:38
jackdaniel
you may also check swank::*communicatin-style* - if it is NIL then it is not possible to spawn new processes
8:03:37
artchad
well, the preferred-communication-style is :spawn. Maybe it will work now. I've closed the repl and restarted it.
8:50:55
pjb
phantomics_: don't ask implementation specific questions in #commonlisp! Go to #sbcl to get the sbcl specific answer, to #ecl for the ecl specific answer, to #ccl for the ccl specific answer, to #abcl for the abcl specific answer, etc.
10:00:42
jackdaniel
NotThatRPG: I've accepted your message to the ecl-devel mailing list; that said you wouldn't need to wait for moderation if you had subscribed to it
11:14:26
aeth
Anyone interested in copying the stumpwm experience on top of a wayland compositor like wlroots? The long run solution would probably be to go with its own compositor, but there might not be enough time.
11:14:52
aeth
Now that Nvidia is getting alpha, and maybe even beta, quality Wayland support, I'm afraid that the transition to Wayland in the bleeding edge distros like Arch and Fedora will be fairly rapid.
11:16:56
amerlyq
Looking into experience of Qtile transitioning to Wayland -- it's a painful endeavour. And until proper HiDpi support I will live on Xorg till the end of time)
11:17:06
aeth
A quick search of Github shows that there has been an attempt at a compositor before but idk its state https://github.com/malcolmstill/ulubis
11:20:40
aeth
amerlyq: Well, a separate issue (on many of the same types of monitors) is that support for HDR displays is probably never coming to X11, but will eventually come to Wayland and a lot of relatively cheap screens are HDR now.
11:22:15
aeth
(Although a search shows that Nvidia has been trying for years to hack together HDR support on X11 on its own, apparently.)
11:24:30
kakuhen
more specifically, how will we test this wayland port (or whatever new window manager you attempt making)
11:25:14
kakuhen
assuming I can set up an environment for that, then I'd become interested in a (hopefully portable) wayland-based CL-based window manager
11:26:58
aeth
Afaik, there wouldn't really be much to port. Stumpwm is a fairly thin client layer on top of X via clx, much simpler than if it had to rely on xlib or wayland, but with some obvious UI faults that come from that (all of the stuff you bring up from stumpwm like C-t ? don't look like they belong at all) and it is... very X11
11:31:51
aeth
On the other hand, Wayland creates new priorities, like having a built-in way to do screenshots (in stumpwm, I have a one line script in ~/bin to screenshot to the specified subdir of Pictures via `import ~/Pictures/$*/screenshot-$(date -Iseconds).png` instead of a less hacky and more Lisp-native way to screenshot)
12:44:39
NotThatRPG
jackdaniel: Thank you. If that's mailman, you could just add me as an authorized sender. I've had to give up on subscribing to all the implementations' development lists: there are just too many.
12:46:50
hayley
Being subscribed to the SBCL mailing list helps numb my mind telling itself that setting up a mail server was a waste of time.
12:48:28
jackdaniel
I'm not going to press the matter, but I find it reasonable to expect someone broadcasting things on a list to subscribe there ,)
13:37:09
NotThatRPG
jackdaniel: I'm sorry, but there are a lot of implementation developer mailing lists and I simply can't track all of them.
13:38:37
NotThatRPG
jackdaniel: If ECL tracks asdf-announce, which is EXTREMELY low traffic (about 1/year!), I could stop sending announcements to ECL-devel
13:51:49
dim
hi friends! for the curious here asking for a stacktrace yesterday, for the pgloader compile warning "deleting unreachable code", it's available now at https://paste.debian.net/1249706/
13:52:45
dim
5: (SB-C:COMPILER-NOTIFY CODE-DELETION-NOTE :FORMAT-CONTROL "deleting unreachable code" :FORMAT-ARGUMENTS NIL)
13:55:53
hayley
I don't see why there is a handler for what would appear to not even be a warning (if memory serves me right).
13:56:27
hayley
The handler should be for ERRORs or SERIOUS-CONDITIONs, and a compilation note is neither.
13:57:49
jackdaniel
the second branch has (trivial-backtrace:print-backtrace condition nil), but nil is in the position of the keyword argument
13:58:12
dim
4: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS SIGNAL NIL #<CODE-DELETION-NOTE "deleting unreachable code" {1008468C33}>)
13:59:46
jackdaniel
first: trivial-backtrace prints the backtrace with a message "FATAL error: …" (and it is not a fatal error)
14:00:06
jackdaniel
then the control is transferred to the handler-case's case CONDITION that prints "What am I doing here"
14:00:43
jackdaniel
if you replace the last clause name with serious-condition, then handler-case will simply glide over and move to "done"
14:00:53
dim
whenever something I didn't account for is happening, the program stops and might display a backtrace
14:01:27
dim
here the thing that I didn't account for is a compiler warning (note: deleting unreachable code) that I'd like to ignore
14:01:31
jackdaniel
you should replace the last clause in handler case ("What I am doing here?") with serious-condition instead of condition
14:01:48
Bike
when you say "ignore", do you mean you'd like the program to not do anything special, or that you'd like to actually suppress the message
14:02:00
Bike
regardless, you really actually should not treat all conditions as fatal errors, because they're not
14:02:15
jackdaniel
the condition CONDITION subsumes all warnings, errors, notes and innocent signals
14:02:26
Bike
ok, then all you have to do is replace CONDITION with SERIOUS-CONDITION or ERROR or something
14:02:44
jackdaniel
yes, you deliberely handle things like compiler notes and call uiop:quit on them
14:03:12
jackdaniel
yes, serious-condition is an error + some things that are not errors in code (timeout, out of memory etc)
14:03:48
jackdaniel
also I wouldn't write "FATAL error" in your backtrace printer, I'd print the condition class name (because that was confusing)
14:03:52
dim
should I still process warnings-p and failure-p output from the call to (compile nil source)?
14:06:45
dim
(let ((c (make-condition 'simple-error :format-control "error"))) (class-name (class-of c)))
14:10:44
dim
PR updated at https://github.com/dimitri/pgloader/pull/1411 with your feedback jackdaniel and Bike ; thanks
14:11:06
dim
let's see what the unit tests make of the current code, and then I'll ask my debian friend to test again with sid and SBCL 2.2.6
14:13:12
jcowan
aeth: does that mean that fedora/etc. will stop supporting xwayland? That would really be a disaster, and not just for WMs
14:14:17
jackdaniel
dim: in your handler-bind you handle all conditions (except for a few chosen ones) and print the backtrace for them - do you want to print a backtrace i.e for compiler notes?
14:18:05
NotThatRPG
It would be neat if something like UIOP provided some common condition classes usable across implementations
14:19:05
jackdaniel
another interesting trick in a toolbox is to have a macro like handler-case (let's call it handler-case*), that handles the condition, then unwind the stack and returns; then printing the backtrace in this situation could be done in the last serious-condition clause
14:19:34
jackdaniel
putting aside details like properly handling :no-error and multiple return values, writing such macro based on handler-bind is rather trivial
14:29:58
hayley
I believe I have a handler-case* somewhere, based off Pitman's condition system code.
14:31:24
NotThatRPG
@jackdaniel: I don't believe that there's a class that corresponds to compiler notes, for example.
14:32:54
hayley
But (deftype silly-condition () '(and condition (not serious-condition))) is useful.
14:33:39
jackdaniel
some conditions are not silly though! signaling partial results in an otherwise synchronous body is one example
14:34:27
NotThatRPG
hayley: Yes, it would be nice if one could make code that wraps around compilation, that could portably handle different implementations' equivalent of compiler notes (assuming that these are implemented as conditions of some sort).
14:35:13
aeth
jcowan: no, but afaik (based on another IRC channel anyway) Fedora would move exclusively to xwayland
14:40:44
Bike
shinmera and i have been talking about doing that, notthatrpg. it would basically be ripping out part of swank. i think my main conceptual confusion now is why sbcl "compiler errors" aren't actually errors
14:41:02
Bike
also i'll have to check if any implementations have a compile that never signals and only reports problems some other way, which would be annoying
14:46:07
Bike
i will see what i can do. i'm doing a bunch of other stuff for clasp at the moment, though