freenode/#clasp - IRC Chatlog
Search
2:37:07
robink
Serenitty[m]: Once it's up and running, it's pretty darned easy to maintain (only difference from, say, Ubuntu is it doesn't ship with nearly as many GUI wizards), it's (usually) the install that's the painful part.
2:37:40
robink
Serenitty[m]: Every so often it'll be a little more challenging setting up some random package once it's been merged, but 90%+ of the issues I've had have been during the initial install or trying to get some package merged.
2:38:40
robink
Serenitty[m]: So if you've been through the initial install, and it didn't kill you, then sure, it's worth a go.
2:38:45
Serenitty[m]
I tried GuixSD, but I didn't like the way that the package manager worked. If you're going to try to keep packages separate, I'd prefer something like Haiku's system where packages are files that are mounted into the filesystem at boot, so you still have a single (virtual) /bin directory, and so on. I don't know of any Linux distributions that do that, though.
2:39:23
robink
Serenitty[m]: There might be one or two container-based distros that are aiming in that direction. Not sure what they're (or would be) called, or how far along they are (or if they exist).
2:39:48
robink
Serenitty[m]: Lennart Pottering suggested a distro based around UnionFS and Btrfs subvolumes/snapshots.
2:40:08
robink
Serenitty[m]: I'm a little wary, in part because that sounds like it could introduce issues you'd avoid w/ a package manager, but also because it's Lennart suggesting it :>
2:42:41
Serenitty[m]
You can drag and drop a single file into the /packages directory, and suddenly virtual files appear all throughout the filesystem. To uninstall it, just delete that one file.
2:45:17
Serenitty[m]
They even include the kernel in one of these packages, so the bootloader has its own simple implemention of the package manager to get it out.
2:45:59
robink
Bike: I thought it'd be POSIX-y enough that you could get a runtime environment capable of hosting Clasp up and running.
2:46:32
robink
Bike: I mean I'm assuming Haiku doesn't ship with LLVM (and it may not ship with libgmp, boehm-gc, etc), but I assume those would compile without an enormous amount of effort.
2:48:21
robink
Bike: Well, prior to the apparent removal of gettid(), there were some assumptions of "Not Darwin? Obviously it's Linux!" in the codebase.
2:49:28
Bike
regular development is pretty much done by me and meister at the moment, and we both have darwin. (i used to use arch, but there are circumstances)
2:49:46
Bike
and we don't have build testing set up (yet) so we only tend to notice problems we run into
2:50:03
Serenitty[m]
I don't get why it would be hard to port to another Unix-like OS when it already runs on two which are very different from each other.
2:51:19
Serenitty[m]
Ah, so what you're saying is that it isn't necessarily harder, it's just an extra amount of work that probably won't get done?
2:56:32
Bike
as you've already seen, the build and compiler are atrociously slow, and we've been trying to focus on that
2:56:45
Serenitty[m]
I think they have a FreeBSD compatibility layer or something like that. If it gets up and running there, perhaps it'll work on Haiku, too. But since you said it's all low-level trickery, perhaps that wouldn't work.
2:56:53
Bike
if the thing would build in just a couple minutes like most lisp implementations, it would be a lot easier to do that kind of work and maintenance
2:59:25
Bicyclidine
there aren't really any obvious bottlenecks. the compiler can generate inefficient code, so the compiler built by itself is inefficient
3:00:42
Serenitty[m]
So, are bclasp and cclasp the same compiler, it's just that cclasp is built by bclasp, whereas bclasp is built by aclasp (a different compiler)?
3:01:37
Bicyclidine
they're different compilers. bclasp is the simple compiler meister wrote, cclasp is the optimizing compiler using the Cleavir system
3:02:15
Serenitty[m]
I see. Wouldn't it make sense to have cclasp build itself? Wouldn't that make things faster?
3:03:28
Bicyclidine
in general we'd like to move towards building from a host (clasp or not), but there are difficulties in doing so
3:04:21
Serenitty[m]
So right now the cclasp (the main compiler) is built by a compiler that generates slower code, thus making cclasp run slower?
3:06:03
Bicyclidine
the build sequence is that bclasp is built, then bclasp is used to compile cclasp, then cclasp builds itself
3:06:23
Bicyclidine
but the cclasp that builds itself is the bclasp-compiled cclasp, so it runs slow, and build takes a while
3:51:37
robink
drmeister: Just about to test out my first-draft ebuild (waiting for a direct checkout of your 'dev' branch to finish compiling), will provide a link once I verify that it works and it gets pushed to my overlay.
4:20:14
robink
Final link of 'dev' branch completed; will keep 'dev-inctweaks' around in my fork for a couple of days, but changing default branch to (upstream) 'dev'.
4:23:01
robink
drmeister: https://github.com/Haifen/robinkverlay/blob/master/dev-lisp/clasp/clasp-9999.ebuild https://raw.githubusercontent.com/Haifen/robinkverlay/dev-lisp/clasp/clasp-9999.ebuild https://github.com/Haifen/robinkverlay/commit/1ecf1acee26f62a05849ed98f075b1de95c61f9d
4:23:59
robink
drmeister: There's probably a glaring problem with that version (not even tried to merge it yet), but it's up and available.
4:25:17
robink
https://github.com/Haifen/robinkverlay/commit/50e94c29b4b20f3ed06be7fe2c134afb8acaf26c
4:29:51
robink
objcopy --only-keep-debug iclasp-boehm iclasp-boehm.debug && strip iclasp-boehm && objcopy --add-gnu-debuglink=iclasp-boehm.debug works without issue
4:30:18
robink
oops, last command should be 'objcopy --add-gnu-debuglink=iclasp-boehm.debug iclasp-boehm'
13:16:19
drmeister
I'm down at Saige trying to shake out a warning that is coming up when satiating functions.
13:35:52
drmeister
In Python keyword arguments are passed in to functions as dictionary objects with strings as keys.
13:37:08
fredokun1
you mean the closest thing to a python dictionnary (with string keys, to simplify) is a hashtable ... especially lookup is fast
13:37:34
fredokun1
one big difference for me is that python dicts are transparent (as are the alists) whereas CL's hashtables are opaque
13:37:36
drmeister
I'm not sure how much of an issue this is with other jupyter widgets but we have one widget that uses this property of keyword arguments -> dictionary with string keys -> JSON dictionary for updating widget on the client side.
13:38:47
Bike
the thing that i've noticed is that ** in calls lets you append dicts together like they were plists
13:41:34
drmeister
Sorry - my thinking is a bit jumbled at the moment. I'm trying to figure out how to clarify things.
13:43:07
drmeister
Maybe my suggestion of converting from alists to hash-tables for representing JSON dictionaries was not well thought out. I'm trying to recreate my thought processes that led me to that suggestion.
13:43:54
drmeister
Translating this function to Common Lisp - I would want it to look like a regular Common Lisp function - with keyword arguments.
13:45:42
drmeister
In that Python code they get a **kwargs dictionary and then they do a lot of manipulation with it.
13:45:50
fredokun1
A macro could do the trick ? Like a "defpymethod" (that's ugly but you see the point ...)
13:46:55
fredokun1
you want the calls to be standard keyword arguments calls... and you want the definition to have a hashtable argument 'kwargs' ?
13:47:39
drmeister
I was translating the plist of arguments into an alist for cl-jupyter to send out as a JSON dictionary.
13:49:48
fredokun1
If it's only for the JSON encoding, it's very easy to add a specific method to encode hashtables to JSON object (encode-json is generic)
13:50:12
drmeister
On further consideration I think I may have made a poor suggestion to change the way that cl-jupyter represents JSON dictionaries from alists to hash-tables. I can add add an intermediate translation from keyword arguments (plist) -> hash-table -> alist (for cl-jupyter).
13:50:18
fredokun1
for the decoding part, the simplest for now is to use an explicit alist->hashtable conversion
13:50:56
Bike
i thought the basic problem we had was that we wanted to use (non a)lists for various things, but the converter expects all lists to be alists.
13:53:58
fredokun1
I can implement hashtable and sequence encodings easily and quickly... The question is : where should I to that ?
13:56:02
drmeister
There are no JSON lists - right? Just JSON dictionaries(objects) and arrays - correct?
13:56:40
drmeister
The current encoding is here: https://github.com/fredokun/cl-jupyter/blob/master/src/myjson.lisp
13:58:11
drmeister
If I want to work with hash-tables I can write an encoder of hash-tables->alists to pass to myjson for encoding to JSON dictionaries.
13:58:48
fredokun1
yes but it's almost as simple and more efficient to directly write an hashtable encoder
13:59:11
fredokun1
for the decoding, I prefer to stick with alists so yes you would need an explicit conversion
14:00:34
fredokun1
it's a problem if you want a direct encoding of a vector that would be interpreted e.g. as a Json object
14:01:31
fredokun1
I don't see a big issue here. And I understand that hashtables might be more efficient/closer to the python way of doing things
14:02:02
fredokun1
maybe we could make the hashtable representation the default in the encoding/decoding of COMM messages ?
14:02:57
drmeister
I think my problem was I was thinking too literally - trying to write code that worked with dictionaries as alists while trying to duplicate Python code that was working with Python dictionaries.
14:04:02
drmeister
I think your first suggestion is most interesting - add an encoder that converts hash-tables to JSON dictionaries.
14:04:22
fredokun1
I think there's a separation to make at some point... It seems you would like a "python-styled" part and I think it's doable with a few macros. But it's separate from the Json things.
14:04:59
drmeister
(defmethod encode-json (stream (thing hash-table) &key (indent nil) (first-line nil)) ...)
14:06:20
fredokun1
we also need a alist->hashtable conversion function, easy because it's only json (string keys, etc.)
14:07:38
drmeister
If you could allow it to work with string or symbol keys by converting the key using (string key) - then the hash-tables could be :test #'EQ and use symbol keys. I can ensure that the keys are camel case as in :|useWorker|
14:09:26
fredokun1
agreed : symbols are the best ! I have still an important question: where should I do that ?
14:12:33
drmeister
How about this. I'll clean up the cl-jupyter code interface to cl-jupyter-widgets (I was about to do it and then I came up with this hair brained scheme). Then I'll submit a pull-request. You merge it and then add the hash-table encoder.
14:13:52
drmeister
I want to give you a cl-jupyter that runs on its own and has the absolute minimum number of hooks to interact with cl-jupyter-widgets.
14:14:44
fredokun1
That would be great... You can even create a branch in the cl-jupyter repo you have right access. Then I can make the pull request to master myself...
14:16:42
fredokun1
It will be an occasion to try cl-jupyter with clasp. I'm very interested because it seems you don't have the bug I'm experciencing with sbcl
14:20:23
fredokun1
I have to go soon. It was nice to talk to you again drmeister+bike, and sorry once again for being slow answering my emails.