freenode/#clasp - IRC Chatlog
Search
2:25:42
Serenitty[m]
I'm compiling Clasp again on a decade-old office computer. The compilation went smoothly and quickly, but now that it's linking, X is completely frozen. It still seems to be linking, though (I'm running the build in a TTY).
2:26:55
Serenitty[m]
I copied the binaries from the other computer onto a DVD to bring it over here, but unfortunately, I only burned the externals. Better than nothing, I guess.
2:31:46
Bike
the linking uses LTO, meaning it does a lot of actual compiling during link, and on a huge file
2:32:53
Serenitty[m]
I wish computers got stronger after getting a workout. But alas, it does not work that way.
2:34:48
Serenitty[m]
I'm getting a new laptop for free from the government for school. Should I install Gentoo on it? I've been using Arch for a few years. robink
2:35:48
robink
Serenitty[m]: Er, if you're comfortable with Arch, it seems like it'd be a bit demanding to ask that you switch. *I* like Gentoo (and I've not used Arch), but I'd only recommend Gentoo (especially for first-time use) if you're willing to sink >=48 hours into getting little more than the basics set up.
2:36:16
robink
Serenitty[m]: You may have a smooth first-time install, and the learning curve may not be too sharp, but even for semi-experienced Linux users it can be an...intense experience.
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 ?