freenode/#clasp - IRC Chatlog
Search
19:08:34
drmeister
I'm not used to getting positive updates - I'm immediately suspicious when anyone says anything nice to me.
19:26:36
kpoeck
The problem in iterate is here: https://gitlab.common-lisp.net/iterate/iterate/blob/master/iterate.lisp#L2474
19:27:53
kpoeck
As far as I can see, there is no structure redefinition, just calling the constructor
19:32:37
kpoeck
(defmethod clos:update-instance-for-redefined-class ((instance structure-object) added-slots discarded-slots property-list &rest initargs))
19:33:31
kpoeck
I did (load "/Users/karstenpoeck/quicklisp/dists/quicklisp/software/iterate-20180228-git/package.lisp")
19:33:55
kpoeck
and (compile-file "/Users/karstenpoeck/quicklisp/dists/quicklisp/software/iterate-20180228-git/iterate.lisp" :print t)
19:35:52
Bike
Hm. Not sure what to do here. I mean conceptually, redefining a structure class is what's happening here, somehow. That's not okay to do. Maybe we want to support it to be nice, but what if the slot definitions change? It's not obvious how the instance should be updated.
19:37:53
drmeister
Yeeesh - I thought the standard said that structure classes absolutely can not be redefined.
19:39:21
drmeister
Clasp's structs are implemented with the same underlying machinery as classes - so we might be able to support this.
19:42:46
Bike
we have the same underlying representation, but that might change, and anyway the behavior for standard objects is based on how regular slot definitions work
19:43:35
Bike
(making sure we're on the same page: update-instance is called by the gf machinery when it finds a stamp mismatch)
20:02:46
Kevslinger
drmeister: When I try running the dev-fork jupyterlab, I get an error right after "Starting Jupyter-lab" that says "ModuleNotfoundError: No module named jupyter_client.session"
20:03:40
kpoeck
To the best of my knowledge -i'd put in print in the defstruct macro - every defstruct is just called once
20:03:40
Kevslinger
After doing some digging, I found that the jupyter_client package in /opt/clasp/lib/python3.7/site-packages contains a session.py file which is a symlink to a hardcoded /Users/meister/Development/widget-dev/ipywidgets7.1/jupyter_client/session.py
20:30:33
kpoeck
(ql:quickload "opticl") loads now (with the workaround for clos:update-instance-for-redefined-class)
20:57:46
drmeister
Kevslinger: Argh - sorry about that - I had the debug version from widget-dev symlinked in.
20:59:06
drmeister
Kevslinger: Is there a session.py.symlinked_away file in the jupyter_client directory?
20:59:50
Kevslinger
I copied the session.py from my local session.py into the /opt/clasp jupyter_client directory
21:00:17
drmeister
I think shiho's is working for an extremely specific reason - she's using my old laptop and there is a file on the other end of the link in my directory on that laptop.
21:01:17
drmeister
In order to get logging from the Python code I use a nasty trick of moving session.py to session.py.symlinked_away and then creating a symlink from session.py to the one in widget-dev
21:02:21
drmeister
I hastily gave you a tarball of my /opt/clasp directory instead of building a clean one - booh me.
21:03:06
drmeister
It's not a big problem though - just replace the session.py with the session.py.symlinked_away version.
21:04:26
drmeister
Copying the one from your directory probably will work - but it could also be a different version - so be careful.
21:06:39
drmeister
And there was no reason that you should - Martin told me that was what he uses when he want's to remind himself that a particular file is the original and that he symlinked to some other file.
21:07:21
drmeister
Perhaps session.py.this-is-the-original-and-the-other-file-is-a-symlink would be more clear.