libera/commonlisp - IRC Chatlog
Search
22:28:23
_death
while debugging something, I wanted to TRACE a function, evaluate a form that calls it, and then UNTRACE it..
22:42:44
_death
jcowan: sure.. but that's too much typing while debugging.. and I knew no error would be signaled
22:49:46
jcowan
What is "dead"? The last release was in 2014, but it is still being maintained. Java weevils will tell you CL is dead, but there are plenty of other weevils who will tell you Java is dead.
23:45:03
yitzi
greyrat: Keep in mind that bordeaux-threads does not support GCL and that several platforms that used GCL to support Maxima now use SBCL or something else.
0:06:35
kagevf
xaltsc: "clisp" is an implementation of Common Lisp - similar to SBCL, ABCL, ECL, and so on ; use "CL" to abbreviate "Common Lisp"
0:17:55
lad
is there a way to hook into the eval function such that I can define my own special symbols?
0:20:51
lad
I want these symbols to be able to self-evaluate: http://pastie.org/p/2HHTbH3yyf4oIqmamUs5rB
0:23:55
lad
I need to figure out how to get around Lthis ock on package COMMON-LISP violated when DO as a constant while in package COMMON-LISP-USER.
0:25:19
Bike
DO is a part of the standard CL package, so you can't define it as a constant. You can define your own package that uses the CL package but shadows DO, and then SOLFEGE:DO can be defined however
0:35:40
pjb
(defpackage "LAD" (:use "CL") (:shadow "DO")) (in-package "LAD") (defconstant do 'do) (defmacro do (&rest stuff) `(cl:do ,@stuff))
0:41:10
lad
http://pastie.org/p/5OfiqsD6UDmqoxakurCNy0 <- line 12 has an issue, what is a good way around this?
0:41:33
lad
say i don't want to define constants, just bindings that I can use within a macro, for example
0:46:04
pjb
Note: with let, they're not constant, so you can shadow them or rebind them: (with-solfege (setf do 42) (list do re mi)) #| --> (42 re mi) |#
0:47:22
lad
pjb, i think those symbols should be able to be rebound since they are relative to a scale
0:50:19
yitzi
lad: Why do you not want to do keywords? The deftype will just have `(member :do :di :re ...)`
0:51:28
pjb
The advantage of symbol-macros is that they're lexical bindings, and you can shadow them in a let (let ((si 42)) (list la si do)) #| --> (la 42 do) |#
0:52:34
lad
yitzi, i don't want to use ":" everywhere. the solfege language doesn't use colons at all so I don't want them
0:56:19
lad
pjb, symbol-macros seems to be exactly what i need in this case. otherwise i'd have to do it via a macro-expanding-to-let form. very interesting, thank you
4:05:51
jeosol
beach: btw, I noticed you extracted some statistics about # of :before, :after modifiers for one of you codebase. I was going to ask how you extracted those numbers
4:39:04
jeosol
I remember the days of using C++, one of the microsoft VC++ editor has some introspection
5:22:03
beach
So binding a special variable using something like LET, as in (let ((*x* <form>)) ...) must be the same as (progv '(*x*) (list <form>) ...) right?
5:22:33
beach
If so, binding special variables using LET or similar is just some kind of syntactic sugar for PROGV.
5:23:40
White_Flame
hmm, as LET binds in parallel, and PROGV binds in order, not sure that's exactly possible
5:24:09
White_Flame
as far as the visibility goes when mixing lexicals & specials in a singular LET form
5:27:42
White_Flame
I guess the init values are evaluated first, then the bindings are made, then forms are executed, though it's a bit hard to glean
7:58:57
lukego
Hey anyone have an idea why static-vectors version 20210807-git - same version as in latest quicklisp - would be failing to build in a certain env with this error? The function (COMMON-LISP:SETF STATIC-DISPATCH::COMBINATION-FUNCTION) is undefined.
8:00:02
lukego
seems weird especially since the error is preceded by this message: The function (COMMON-LISP:SETF STATIC-DISPATCH::COMBINATION-FUNCTION) is undefined.
8:08:13
jackdaniel
the word static seems to indicate, that the function may be expected at compilation time perhaps?
8:08:37
jackdaniel
i.e something tries to call it from the macro and the functio ndefinition is not wrapped in eval-when
8:10:23
scymtym
lukego: is it really the combination of static-vectors and static-dispatch? i had those as completely separate in my mental model
8:34:29
lukego
jackdaniel: yeah that's how it reads to me too, but it seems weird because it builds fine in other similar environments, same code on another SBCL and Linux userspace of a similar vintage...
8:35:02
lukego
scymtym: oh, sorry, I see what you mean, no it's just static-dispatch and that's a typo/thinko
8:35:47
lukego
maybe it's a different in the way compile-time and load-time are staged in this environment...
8:37:06
jackdaniel
and on both environments you've tried with same initial conditions? i.e an empty cache
8:37:58
lukego
not really, I have a pretty loose understanding of how the environments are initialized in many ways, more moving parts than I can really account for. I'll try doing separate COMPILE-OP and LOAD-OP etc.
8:39:59
lukego
the new failing case is when I try to add my dependencies to the upstream packaging of Quicklisp in NixOS/nixpkgs. I used a similar setup before and there I did some specific tweaks e.g. forcing packages to be loaded during packaging to realize various initialization steps...
8:40:26
lukego
but that wasn't due to Lisp weirdness so much as Nix weirdness i.e. package directories being migrated to read-only storage after build and not being able to generate artifacts there
8:44:29
lukego
The good thing is that in this framework I probably have an easy way to apply local patches to projects and can start fixing things without quasi-permanently forking them and having them go stale on me
9:06:37
lukego
at least accumulating individual bits of duct-tape is at this point preferable to ~/quicklisp/local-projects/ being a completely ad-hoc and outdated mirror of half my dependencies :)
9:07:29
lukego
also this would be sharable because it turns out that other people are actively doing stuff with the Lisp packages in Nix land.
9:26:01
jackdaniel
yes and no :) you may create a bundle with quicklisp (then dependencies will be also downloaded) into the destination folder
9:26:32
jackdaniel
that said "only compile" may be a bit misleading - in order to compile foo that depends on bar, you need to first load bar
9:26:56
jackdaniel
(i.e cl-jinx depends on alexandria and uses its function in macro expansions - i.e alexandria:parse-lambda-list)
9:30:13
lukego
jackdaniel: thanks yeah that seems good enough for having a simple env to make bug reports from
9:39:01
jackdaniel
for source code distribution. instead of depending on quicklisp in CI you build a bundle artifact you may load with only asdf
9:44:15
lukego
Sounds nice. Generally I'm always looking for moar import/export of well-defined passive data. Often this seems to be hiding behind operational APIs. For example Quicklisp releases are defined by text files listing the source for each package - and CLPM too as I understand it - but these seem to be treated mostly as internal implementation details while for me it's the primary artifact of interest
9:46:21
lukego
i.e. for me the really phenomenal thing about Quicklisp is that it defines a set of relatively up-to-date software versions that are known to actually work together. that's huge -- especially in that often the reason they work is that Xach has given authors a heads-up when they break. The fact that it also has a client to automatically install stuff is just a cherry on the top.