freenode/#clasp - IRC Chatlog
Search
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.
14:48:34
whoman
does anyone have an intuition on how much cpp of clasp is generated and how much is hand written ? or its all hand?
15:00:42
whoman
yeah.. just that i see a lot of repetition and such in a few files so i wasnt sure how much of that is done by hand; i forget which file i was looking at last