libera/#commonlisp - IRC Chatlog
Search
4:03:07
doulos05
mason: Yeah, I think I'll just do the podman setup. Part of the point of these servers is to figure out proper partitioning for services, and docker/pods is one of the more straightforward way to do that.
4:03:54
kakuhen
I would help maintain the Fedora package but I have no idea where to even begin with the package repos... that and I need to learn how RPMs work.
4:04:38
kakuhen
MacPorts is also fairly out of date (2.2.6 i believe?) but I won't comment on it to prevent venting frustration with the process of updating it.
4:04:51
mason
doulos05: Hrm, another option would be to download https://sourceforge.net/projects/sbcl/files/sbcl/2.2.8/sbcl-2.2.8-x86-64-linux-binary.tar.bz2/download and manage it with GNU Stow or something. Fewer moving parts than a container.
4:05:58
doulos05
mason: Thanks! The joy of learning on hardware you aren't using for anything important is that if I fuck it up, I can just nuke the instance and start over.
4:06:21
aeth
Fedora has clisp, ecl, and sbcl, but no ccl. Only the sbcl seems particularly out of date. The clisp is a random one from git rather than the last stable version (from July 2010).
4:07:08
kakuhen
I know this because I recently modified the MacPorts package to pull source code from that commit
10:22:56
pjb
pkal: I use: (define-symbol-macro ll (load "loader.lisp")) so I only have to type ll to load the loader.lisp file in the current directory.
10:27:58
pjb
pkal: if you want to reload the file while loading the file: (load *load-pathname*) but beware of infinite recursive loads!
10:42:18
pkal
pjb: By current file I mean the file that is currently being loaded. I want to have a function that will reload the file it was defined in.
11:33:07
nij-
It has completed 20% of its task. In the end, it should return a hash table that contains all info I want.
11:38:04
nij-
I tried (break)ing in the inferior lisp, but it doesn't let me inspect the hash table :(
11:42:00
nij-
Oh, I can peek into the info :) But is there anyway to dump those into a file from the debugger?
11:47:02
beach
nij-: Or you can it `e' in a debugger stack frame and evaluate a form relative to that frame.
11:52:19
nij-
Just curious. Suppose I hit C-c C-c during (let ((x 3)) (sleep 3)), is there any way to inspect the local var X?
11:52:55
beach
With a high enough DEBUG quality, the variable might be available for inspection in the stack frame where it is created.
11:54:16
nij-
Can I press 'e', evaluate some form, and write the value of the local X into some file?
11:57:15
pve
pkal: in that case, you might want to have a look at *load-pathname* and *compile-file-pathname* or the truename variants.
12:07:19
kaskal-
quick question, I did not find any info on cffi docs or source about static library archives, like `libblas.a`, is there not support for it ?
12:13:16
nij-
I'm deeply amazed. Is this feature available for other langs, like python? I never thought I could do this..
12:16:33
beach
Well, with GCC and GDB, the functions have to be in the program for you to be able to call them. But if the program is linked with the right stuff, then sure.
12:17:12
beach
When I taught a course in development tools, I had the students link with Xlib, and from GDB in an empty main() I had them open windows and such.
12:17:13
kaskal-
beach yes I think so too, however I would have expected cffi to be passed a static archive or `.so` without much trouble, or at least if the implementation supports it that cffi wraps it, just like in gcc and clang I can just compile like `$CC my-file.o whatever.a`
12:21:05
hayley
beach: In my GC foolery with SBCL I keep a few useful functions for debugging with me. One prints out a "visualisation" of the page table, and another generates a Netpbm image file of the line table.
12:21:53
hayley
When things go wrong, I call those functions from GDB to figure out help what went wrong.
12:23:28
hayley
There was a story that Marvin Minsky did the same sort of debugger programming, but starting from an empty program and writing more and more assembler code.
12:37:19
nij-
I need to get some experience with C and gdb as well.. lacking of motivation though :/
12:39:24
beach
What amazes me more, and I have said this repeatedly, is that with out FLOSS Common Lisp implementations and our best IDE to go with them, we still can't do what I could do with GDB at the time. For example set a breakpoint and have the program stop there.
12:40:02
beach
And most Common Lisp users still think we have the greatest environment of all, all languages concerned.
12:43:08
pjb
Unless you run more slowly, step by step. Which you could also do in lisp with the right VM.
12:43:09
beach
pjb: I am pretty sure you know that that is not true. If you recompile, you can get a totally different code.
12:44:03
pjb
The option of working at the processor level (VM level) is probably the best, even if slower, since you don't need to patch the code with debugger traps.
12:46:12
beach
nij-: But then you are not debugging the same code that made you want to put in that (BREAK).
12:46:14
_death
in high debug settings, sbcl inserts step instrumentation code.. maybe that could be used to selectively set a breakpoint without recompilation
12:47:16
beach
_death: When I wrote my paper about debugging, I investigated and SBCL breakpoitns are used only by TRACE. The step instrumentation uses a different mechanism.
12:51:54
cls
Hi, I'm trying Lisp for the first time and I'm wondering if there's a standard easy way to extend a defsetf. I've got (defun node-port (port-id) (aref (node-ports (car port-id)) (cdr port-id))), which works fine for access, but all I need to do for update is put the 'value' on the end of the parameters and the aref call. It feels like there should be a straightforward function to define both at once?
12:52:00
beach
nij-: Imagine the following scenario: You ended up in the debugger, but there is a restart that makes the computation continue. On the stack there is an invocation of a function FOO, and some BAR that it calls so that you eventually ended up there.
12:52:01
beach
Now, you want to set a breakpoint in FOO, after BAR returns. You can't. If you insert a (break) and recompile FOO, it will not be the same function as is on the stack.
12:52:52
_death
then, there are different kinds of breakpoints.. breakpoint on execution is one, but what about breakpoint on variable access (maybe just for specials?) or region access (of an array) or some arbitrary condition (slow ;)
12:57:48
_death
in the old days I used debuggers a lot (turbo debugger, watcom debugger, softice, visual c++'s, etc.) .. but when writing lisp I often just insert a break form or do print debugging (incl. tracing).. the lisp debugger (sldb) is useful of course, but its operation is different
13:05:14
jackdaniel
fwiw implementations that share the runtime with languages like c or c++ may be debugged with gdb
13:06:03
beach
Don't you then have to know how your implementation represents objects in order to inspect them?
13:08:33
jackdaniel
isn't that true generally for gdb? (i.e can you inspect a struct object without knowing how it is represented)?
13:11:33
_death
it may also be the case that the constraint of not having such debuggers creates incentives that may actually be considered good, such as using small named functions that are repl-friendly (don't assume too much context)
13:11:34
hayley
Or, if lazy, one can use the print() function in SBCL to do something between printing and inspecting a tagged pointer.
13:11:34
jackdaniel
perhaps a clever macro that calls into the runtime's type-of could automate that in gdb
13:13:05
beach
Hey everyone, we want you to use Common Lisp because it has a lousy development environment. But that's good, because then your code will be better!
13:13:28
_death
beach: this is just a hypothesis that I've not tried to test.. I often see analogues of what Don Norman called "affordances" everywhere
13:13:53
hayley
a la "p print(0x100001337)" prints a cons cell somewhere in dynamic space. (Please help, I remember those numbers.)
13:14:14
_death
beach: it's not that DE is lousy, but that it provides enough alternative (repl, first-class functions, expression oriented..)
13:14:27
jackdaniel
it is true that the value of a good debugger grows when: 1) the recompilation cost is big, 2) it is hard to interact with the environment otherwise
13:14:41
hayley
I have heard someone say that expressive languages and GC are only good for large programs, so inexpressive languages encourage smaller programs. And this was a good thing to that someone.
13:14:59
jackdaniel
in this sense debuggers are more important for embedded platforms accessed via jtag than for lisp environment with slime and repl attached
13:15:31
hayley
They missed that expressive languages prevent large programs from becoming huge programs.
13:15:32
jackdaniel
that's not to say that a good debugger is not valuable, it is just about how critical it is to have it
13:28:57
_death
and then, we also have some nice inspectors, which are often a big part of a debugger
13:35:58
jcowan
beach: "Members" is the term used by the C standards, except for bit fields, which are called fields for some reason.