libera/#commonlisp - IRC Chatlog
Search
14:54:07
jcowan
edgar-rft: Probably no one cares any more, but Guile 3's JIT makes it essentially as fast as Guile 1, so lilypond could be updated. Although it would still run unbearably slowly on a Vax.
15:28:48
beach
Tell me that the phrase "use-package checks for name conflicts between the newly IMPORTED [my emphasis] symbols, and those already accessible in package" is wrong.
15:30:29
beach
The glossary says "import v.t. (a symbol into a package) to make the symbol be present in the package".
15:33:47
beach
Since I am now working on the package system, I am slowly convincing myself that the entire package system could be defined in an external library.
15:34:23
beach
There are some minor interactions with symbols, like changing the home package of those symbols.
15:37:51
beach
Those interactions could be handled by the standard way that we have developed, i.e., the library has a generic function that it calls, and client code has to define a method on it.
15:48:25
Bike
slime-quit-lisp, i think? usually i'd just restart it, and this is assuming C-c C-c isn't working
15:52:22
edgar-rft
jcowan: I's not neccessarily my opinion but the people on the lilypond mailinglist who frequently are running Guile tests say otherwise. As far as I know the main problem is that it's the unneccessary Guile "compile" step that slows everything down. Lilypond passes the Guile results directly to C++ and therefore needs a fast Guile *interpreter*, it throws away the compiled code anyway.
16:13:22
jcowan
use-package imports the exported symbols of the package being used en masse, contra pjb's remark
16:58:22
lisp123
Is there a way to get the full call stack when calling a function? I have one with many nested loops & recursion and debugging is going slow
17:03:58
Bike
if you (declare (optimize debug)) appropriately you will probably get more complete call stacks, e.g. by preventing tail call optimization
17:21:09
pve
lisp123: are you aware that you can do all kinds of cool stuff in the slime debugger? (you probably are, just checking)
19:02:50
dieggsy
is there a manual way of checking a list of arguments against the acceptable parameter list of a function without actually calling it?
19:03:26
dieggsy
basically check if an apply will succeed (based on num args, keywords, etc.) before actually applying it
19:11:36
Bike
dieggsy: no, for several reasons, first of which is that the implementation doesn't actually have to save the lambda list of a function
20:08:06
aeth
dieggsy: there should be a way to do it because swank/slime displays the arguments in the minibuffer in emacs
20:09:02
aeth
and worst case scenario, it's unparsed, but (alexandria:parse-ordinary-lambda-list '(x y &key z))
20:09:08
Bike
which, besides behing extensions, are intended for human use rather than anything programmatic so they can have inaccuracies
20:09:23
Bike
and on high optimization that information can be removed even on implementations that do sometimes save it
20:27:37
Bike
doesn't look like sbcl's introspection distinguishes between a lambda list of () and not having the lambda list
20:39:54
scymtym
Bike: if i remember correctly, SB-INTROSPECT:FUNCTION-LAMBDA-LIST was changed about two months ago to return a second value which indicates exactly that