libera/commonlisp - IRC Chatlog
Search
12:38:09
icer
My working remote slime/swank debugging broke after trying to update sbcl to the downloaded latest from Ubuntu 20.04's default. I've tried reverting, recompiling, but now it's always complaining about swank-io-package stuff missing and swank indentation things missing. Any ideas?
12:45:55
beach
icer: You can use completion to get the full IRC handle of the person you are addressing.
12:51:34
icer
jackdaniel: Ok, I can connect to the binary running on my local machine, but to the same binary over ssh port forwarding, the same errors occur.
12:55:50
icer
jackdaniel: I md5summed the binary to confirm its the same. There is no ~/.slime on the remote system.
13:01:17
_death
jackdaniel: when I think of DO, I tend to recall the little box on PG's ANSI Common Lisp, I think with the headline "The point of DO".. in it he quotes from the paper "The Evolution of Lisp"
13:03:26
icer
I still connect and get the "Can't locate module: SWANK-IO-PACKAGE::SWANK-INDENTATION", which is odd considering it's the same binary.
13:03:56
_death
the quotation is about how iteration over a single variable is often not very useful on its own, and how DO allows iterating multiple variables, and consequently the DO body can often be empty
13:07:40
_death
icer: a while ago I added a restart to be able to continue from this error, btw.. https://github.com/death/slime/commit/9f5cc8c7cf042f821ee3f2c838c6b617e8aeaf6d
13:09:53
icer
_death: nice retart idea. So, are fasls not built into the image? My Makefile uses (asdf:make). Or is swank something I need to manually quickload on the remote?
13:14:56
icer
_death: I don't do an explicit load, just a ql:quickload of the project's asd system, then build, which shouldn't call the entrypoint. At one point I tried adding --eval '(swank-loader:init)' before the build command.
13:33:57
icer
_death: It takes a couple minute to deploy - slow connection. In the meantime I tried sshing in to the remote and trying to emacs/slime locally on the remote and got a swank version mismatch 24 vs 26.1, which apt tells me 24 is on the remote, and I know 26.1 is local to my dev machine. May be the issue.
13:43:36
icer
_death: how do I make slime recompile after I patch the file for your restart? I did a slime C-c C-c, and compiled, but that didn't seem to be enough.
13:46:46
icer
_death: odd, the swank-loader line doesn't seem to have an effect, the remote is still looking for the v24 swank rather than what I tried to build into the image.
13:53:38
icer
_death: yes, I forgot to "purge" it, I'll see if that works. I've also quickloaded swank, but that didn't work.
14:17:44
icer
_death: so.. same as dev machine, used quicklisp to install swank and melpa in emacs to install slime on remote. Tried using emacs/slime on remote for a remote-local connection, and it fails, same failure to load swank-indentation :(
14:29:27
_death
icer: in fact I do this for all lisp-related things.. I have a "third-party" directory of CL code repos (it's a subdirectory of quicklisp, ~/quicklisp/third-party due to historical reasons, as I started by converting all QL libraries I had.. https://gist.github.com/death/2fb6218858c6212ebea052f2e3d4f0b3 )
14:31:38
_death
icer: well, it's just the way I work.. maybe others can help you do it in a way that is more practical for you
14:36:46
_death
to pick up new changes, I have a basic program that fetches for each repo, and I can then review the changes and merge/rebase
14:42:09
_death
I do use melpa for emacs packages (not slime), but also keep them in a big git repo, so that I can review changes, revert, etc.
15:21:10
gin
if I just need to do a boolean check for whether an item exists in list, is either of FIND or POSITION more preferred than the other?
15:57:48
beach
There is an irritating contradiction of terminology in the Common Lisp standard that would be good to fix some day. Usually "bound" means "has a value", so that BOUNDP returns true if and only if the variable has a value and MAKUNBOUND makes the variable have no value. But that terminology is not great, as is evident in the dictionary entry on PROGV.
15:59:17
beach
So it is possible to have a binding for a special variable, but it has no value in that binding.
16:00:49
beach
1. Let "bound" mean that a binding exists, but it can have no value. That solution would require renaming BOUNDP and MAKUNBOUND which makes this solution hard.
16:01:50
beach
2. Keep "bound" to mean "has a value", but introduce a new term for what we now call a "binding".
16:08:39
beach
The glossary does not mention "having a value" in association with "bind", "bound", "binding", so that suggests solution 1.
16:08:59
Nilby
How about accepting that natural language is imprecise and adding a denotational semantics definition like scheme?
16:11:27
Nilby
beach: I know. It makes my head swim to to think of it for all of CL. Even the scheme version is challenging.
16:11:37
beach
MichaelRaskin: There is no glossary entry for "bindings". Do you mean for "binding"? For lexical variables, they are the same.
16:11:45
MichaelRaskin
I have an impression that mentioning the remaining variables being bound (which is against the glossary definition, which asks these names to denote something, which they don't withing dynamic extent) is just so that «bindings are undone» covers them
16:12:24
MichaelRaskin
beach: I mean entry for «binding» that gives examples of different kinds of bindings
16:13:49
MichaelRaskin
The spec for progv says «The bindings of the dynamic variables are undone on exit from progv.»
16:13:59
Nilby
Also it's not clear how useful denotational semantics is to anybody, since I and many others wrote a scheme without looking too much at it.
16:14:55
MichaelRaskin
This seems to cover the variables that are deprived of their values for the dynamic extent of progv
16:16:01
MichaelRaskin
I am not yet suggesting, I am trying to understand why the phrase «bound and then made to have no value» was written
16:16:21
Nilby
I agree there's more to it than just being bound and unbound which it would be nice to have a precise term for.
16:17:22
beach
If it has no value, then makunbound did not undo the binding introduced by the inner LET.
16:18:57
beach
_death: Exactly, so the PROGV page says *x* is still bound, but BOUNDP returns false.
16:19:56
MichaelRaskin
Technically speaking. doesn't «then made to have no value» have power to also make the variable unbound there?
16:20:00
beach
_death: If that is what you think, you have to invent a new term for what (let ((*x* 234)) does
16:22:09
_death
beach: why? it binds *x* to 234.. I am saying that you're right there's a distinction missing.. the progv form creates a binding with the value being a marker
16:22:15
beach
MichaelRaskin: Only if you accept that "to be unbound" does not mean "has no binding".
16:23:17
MichaelRaskin
[in the current extent and scope]» meaning «has no binding [accessible in the current extent and scope]»
16:23:55
beach
MichaelRaskin: But the binding is accessible. You can do (setq *x* 234), and it affects that very binding.
16:25:13
Nilby
LET just doesn't allow the trick that progv does, but one could imagine or make a LET that allowed you to make something locally unbound.
16:25:13
MichaelRaskin
In practice makunbound doesn't seem to do anything to the lexical binding. Which might be a bigger question than whether progv specification is too sloppily worded
16:26:37
pjb
Perhaps the problems comes from the difference between variables and slots, and the fact that dynamic variables use the symbol-value slot (or at least, the symbol-value operator).
16:27:58
pjb
Yesterday I described varname : [*]--> value saying that the symbol varname named the variable [ ] (a slot) and the binding is the arrow *--> between the variable (or slot) and the value.
16:29:17
MichaelRaskin
Just LET. I am not sure if by the letter of the standard it should work. In practice it does.
16:29:20
pjb
I think the spec of PROGV uses "bound" incorrectly in "the remaining symbols are bound and then made to have no value." they mean that the variables named by those symbols are created, and made unbound.
16:30:52
beach
pjb: But that is unfortunate, because then (let ((*x*)) does not "create a binding" but it "creates a variable".
16:31:13
MichaelRaskin
Specification of MAKUNBOUND is vague enough that I am not sure how to deduce from it that it only affect special variables
16:31:50
beach
MichaelRaskin: That is entirely possible, but I can guarantee you that that is what is meant, since the name of the variable is evaluated.
16:33:21
pjb
Notably any unbound slot or variable, still exists. There's some place designated by the slot accessor or the variable name, that can be assigned a value, ie. bound to it.
16:34:17
pjb
For me, the binding is the *--> arrow, not the : association between varname (or slot place form) and [ ] the actual box where the reference to the value is stored.
16:34:33
beach
The way I see things is that special variables come with a stack of "things", where each entry in the stack has a value or a marker indicating that there is no value there.
16:35:12
beach
The glossary suggests "binding", but that is inconsistent with MAKUNBOUND and BOUNDP.
16:36:05
beach
But then we have a problem that a "special variable" is a not a variable, but a stack of variables.
16:36:48
pjb
(and it's multiple stacks, one for each thread, unless the thread access a global stack).
16:37:34
beach
Nilby: An environment is way more than a single association between a single symbol and a single value/no-value-marker.
16:38:11
pjb
I think "variable" can recover both a single slot, or a stack of them or more complex storage forms.
16:38:51
pjb
Also, temporary dynamic bindings can be implemented using the same slot, but saving and restoring the value on the execution stack.
16:39:25
pjb
I think we'd need a formal specification of CL. Terminology can be deduced from the formal notions.
16:42:05
beach
So then we must accept that (setq *x* 234) does not alter the current binding of *x*)
16:42:45
beach
Because if it was preceded by (makunbound '*x*) then it doesn't HAVE a binding to be altered.
16:45:01
_death
I would say that special variables always have a binding.. makunbound merely sets the value to a marker
16:45:54
edgar-rft
here's howto export a binding -> https://res.cloudinary.com/ratebeer/image/upload/w_250,c_limit/beer_8237.jpg
16:48:03
_death
and boundp tests for (i) does it have a binding (ii) if it does, is the value this marker
17:11:26
_death
the question is, I guess, from this implementational model, how do we abstract to create good wording for the language specification
17:13:01
_death
in ordinary CL conversation we say that (defvar *x*), without prior reference to *x*, marks *x* as a special variable, and that this special variable is unbound
17:39:14
White_Flame
looking at the disassembly, it's only checking the low byte tags for #x09. I wonder what the rest of the word implies
17:41:08
White_Flame
(and obviously the #x50100109 is not a "value" in the lisp sense, but rather a specific machine word encoding here)
17:46:28
Nilby
Yes. Not very important to know, but at least now I can see that unbound things might look like dark red when I scroll through memory as pixels.
20:36:07
Michal
Does anybody have any recommendations for machine learning libraries in Common Lisp?
20:44:03
Qwnavery
It's a hard one because I'm unaware of any ML projects that have GPU accellerated support
20:46:28
Michal
I thought it was much faster than Python, but I heard Python had an optimised library via numphy
20:46:55
Michal
What's CUDA? I'm very new to all of this. I just finished Andrew Ngs course and wanted to try stuff out
20:53:00
Qwnavery
Michal: cool, to get started with CUDA you'll need the Proprietary Nvidia CUDA drivers https://developer.nvidia.com/cuda-downloads