libera/#commonlisp - IRC Chatlog
Search
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