freenode/#lisp - IRC Chatlog
Search
5:57:22
dim
I guess I don't understand what makes the **keys calling convention in Python something interesting for your CL design here
5:58:37
drmeister
Well, (1) we started with alists and now we are kind of stuck with them (2) we have a LOT of very small dictionaries - so alists aren't such a bad idea.
6:00:04
dim
each time I'm using alist or plist directly I wish I had done some abstraction layer to use a gethash like API on top of them
6:00:05
drmeister
buffergn0me: Yeah - you are right about plists and **keys. There are a couple of other things I haven't mentioned. Namely someone else chose the alists and so we are kind of stuck with them.
6:00:48
jackdaniel
buffergn0me: arguably alists are better organized, each entry has both key and value and there is no mistake about which entry is what (separate lists)
6:01:41
dim
drmeister: how much work would you anticipate moving from alist to your own abstraction would be here?
6:01:49
phoe
Except if you go (setf ([] alist "d") 3) you want this to become a no-op, because the value 3 is already present in ("c" . 3)
6:02:37
buffergn0me
Haha, that is a fair point. I was just reading an article by Wirth about how no one ever uses abstract data types...
6:02:58
dim
drmeister: nobody ever has the time, when you look at it that way, the other angle being how much time are you going to spend because you did NOT move from alist to your own abstraction? how much deeper do you want to dig this hole?
6:02:59
drmeister
See, we translated jupyter widgets to Common Lisp. Then we translated nglview (a molecular viewer) and now we are translating bqplot (Bloomberg plotting library).
6:04:57
phoe
this means to me, "do all of the mutation unless the key is already present in the alist somewhere"
6:05:01
dim
drmeister: my remark is more to the level of “hiding it in a macro”, I think you might consider making it obvious in a data structure / api
6:05:25
jackdaniel
phoe: what's the point of such juggling if he can simply hardcode test in setf expanded copied from alexandria?
6:05:50
drmeister
dim: It made the code very hard to read with all the (cdr (assoc key table :test 'string=))
6:05:53
phoe
jackdaniel: that's what I mean - he can insert that test into the setf-expander from alexandris
6:06:09
buffergn0me
The last number I encountered from someone that benchmarked was 100 entries for list vs hash table break-even
6:06:31
jackdaniel
I've seen a lot of "if, unless, conditionally", sounds much more compliacted. but maybe I'm not following careful enough
6:06:50
buffergn0me
That was about a decade ago, it's probably even worse for hash tables today because of larger cache sizes
6:11:57
dim
I think you might find https://github.com/gwkkwg/cl-containers/blob/master/tests/test-containers.lisp#L142 relevant to your current situation
6:15:35
dim
your main immediate problem is providing an API that handles both push or replace a value for a given dictionnary key, right?
6:18:25
dim
well anyway good luck, my day is done. You seem to always have interesting problems to solve drmeister, have fun!
8:54:20
_death
[] is a terrible name.. there is an association between trying to ape other languages and envy of them
12:05:18
pjb
drmeister: you have 3 solutions: 1- wrap your (cdr (assoc key table :test 'string=)) in a functional abstraction. 2- intern those strings into some package (intern key "PYTHON-SYMBOL"). 3- internalize the strings themselves: (setf (gethash key *interned-strings*) key) with (defparmeter *interned-strings* (make-hash-table :test 'equal) or 'equalp for case insensitivity.
12:05:56
pjb
then (cdr (assoc (intern key "PYTHON-SYMBOLS" table))) or (cdr (assoc (gethash key *interned-strings* table)))
12:07:02
pjb
drmeister: it's rather trivial to write either a macro or a reader macro so that dict["a"] can be interpreted as ([] dict "a").
13:44:47
easye
Anyone know of any open concolic testing CL code <https://en.wikipedia.org/wiki/Concolic_testing>?
13:46:15
easye
err, the language tested doesn't have to be Common Lisp (actually I am interested in many others: JavaScript, EVM, etc.), but is there any concolic testing analysis expressed in CL?
14:31:15
phoe
drmeister: fun trivia, dict["a"] is an M-expression, which was the proposed syntax for Lisp back in the day
14:33:45
pjb
https://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/m-expression/index.html
15:41:09
gendl
Hi, any idea why asdf would suddenly start ignoring asdf/output-translations:*output-translations* ?
15:41:35
gendl
(((#P"/Users/dcooper8/.cache/common-lisp/ccl-1.11-f96-macosx-x64/**/*.*" T) (T T) (T #P"/Users/dcooper8/.cache/common-lisp/ccl-1.11-f96-macosx-x64/**/*.*")))
15:42:39
gendl
same thing with compiling systems etc -- the fasls are just going directly in with the sources
15:43:17
gendl
i'm not sure when this started happening, as far as I know I didn't touch my asdf version... have been running 3.3.1 for a while.
16:17:16
gendl
... working on it... Just started a bare vanilla lisp with asdf, and the output-file is working correctly. So, apparently we're doing something to step on the output-translations at some point. Tracking it down...
16:26:02
gendl
Just cleared all old .fasl files, in ~/.cache/common-lisp, quicklisp/cache/, and the ones which were ending up next to source files, restarted, and now it seems back to normal.
16:26:38
gendl
apparently something was reading one or more stale .fasl files which was causing things to get wedged.