libera/#commonlisp - IRC Chatlog
Search
20:37:34
jeosol
_death: his development is much further along. I sent him a message. Barring any licensing issues, I explore the library further once I hear back from him. Perhaps we can coalesce around a library and some development effort to it
20:41:19
_death
jeosol: cool.. personally I'm not doing "deep learning" nowadays (except for small stuff like translating swedish subtitles to english, but py4cl2 is sufficient there :) but good to keep up to date with Lisp libraries
20:53:55
jeosol
_death: so you call python/tensorflow/torch libraries from the cl side to do related work?
20:55:19
jeosol
It will take lots of efforts to get close to related libraries in python land. I don't think that's the goal except we get an army of developers - maybe get some of the core nets in CL. But again, people will say, if you can access the libraries from python, what's the point
20:56:55
_death
jeosol: not swedish, just watching some series.. in that case I do call python, yes.. with a library like "nlu" it's even easy
20:57:47
jeosol
that's how I use the libraries for now too, I write python, them call it from the CL side
20:58:37
_death
jeosol: no.. and in fact it takes a long time (minutes) to translate, since nlu uses the CPU.. but the results are pretty good
20:58:47
jeosol
tensorflow is awkward in a sense, I them learned that it was because of the underlying C++ implementation
20:59:18
jeosol
hahaha - not real time. But you are getting good results. I should look into that library
21:00:19
_death
it uses pyspark.. in some cases there may be a way to use the GPU, but I think it's not supported with the versions I used
21:00:53
jeosol
I see. I was planning to buy a GPU at some point but hoping also it will help my related CL programs.
21:01:24
jeosol
that's good at least it's working for you - calling an existing model. I think that's now most of the models are used anyway
21:02:11
jeosol
They have lots of parameters, and have been trained on larger corpus of words. Same in the vision/object recognition space
21:02:26
_death
for trying existing models I also used OpenCV's DNN support (I wrote some opencv bindings).. there's the onnx zoo where some models are usable
21:03:25
_death
and also there was some experiment using zeromq to communicate with javascript code which used some tensorflow..
21:04:00
jeosol
lisp123_: you won't go wrong with that. I have only used SBCL for several years and code will probably break with CCL
21:04:34
jeosol
_death: I guess that's why most won't see the need. One can already access these libraries from CL side
21:05:34
jeosol
I remember hearing about cl-cuda library but interested to see what kind of speed up I'd get with a GPU
21:06:16
_death
jeosol: possibly.. I do have pure CL libraries for machine learning tasks, but they're not "deep learning" ones
21:06:25
jeosol
For now I am trying to invest time in parallel build to get my application to build fast, looking into Fare's poiu
21:07:19
jeosol
stylewarning: not sure he is here, but he does use SBCL for computational and matrix related work
21:07:44
lisp123_
jeosol: thanks. I wish we weren't heading towards everything is tested on SBCL and may not work on other implementations
21:07:51
jeosol
I have gotten good performance with SBCL but I have not done much benchmarking with other languages
21:07:52
_death
jeosol: it depends on the task, implementation, and hardware.. it could easily go from the order of hours to minutes
21:08:13
stylewarning
lisp123_: it takes a lot of work to do high performance testing and porting to other compilers
21:09:03
stylewarning
lisp123_: we ported our stuff to ccl, allegro, and ecl; no doubt they’ve bit rotted, and allegro requires a long exchange with Franz engineers and never quite resolving the problems
21:09:33
jeosol
_death: interesting ... I do simulation work (fluid mechanics + numerical differentiation) . I was running a model that took 60 minutes, a friend said he used GPU and was able to get it to 400 seconds.
21:10:35
_death
jeosol: sounds plausible.. I think in my last job I've also seen some x10 speedup for some cpu->gpu task
21:10:49
jeosol
lisp123_: yeah, I think shinmera maintains a page that shows tests with several CL libraries: I think the SBCL column is mostly green all the way down, maybe followed by CCL
21:11:45
jeosol
_death: thanks for that metric. I thought my friend was BSing me. I don't have a gpu to test
21:12:33
lisp123_
jeosol: I do, I just also like that there is diversity since new ideas come from that - but all that said, its not like I would make that much effort to make my code portable (behind the basic stuff) so hopefully my comment isn't taken the wrong way :-)
21:12:41
Shinmera
unfortunately creating that page did not have the intended effect of pushing people to increase coverage.
21:13:10
jeosol
Shinmera: great work. It will be nice if they do. I see you have a column for SICL already
21:15:16
jeosol
lisp123_: I see what you mean. I think SBCL and CCL are the big free implementations. Early when I started, I once looked into Franz, but there was a timing limit and some limit what you could do. Then CMUCL, then just SBCL since.
21:16:49
moon-child
Shinmera: I see some cells are marked with an asterisk, but there's no mention of its meaning?
21:17:43
Shinmera
if you activate the long list view with the button in the top right you can see more detailed explanations.
22:40:34
Oladon
Why does emacs highlight any function that starts with "check-" in red? Is there some convention there I don't know about?
22:45:05
aeth
Those are actual conventions though, while I haven't seen any check- other than the built-in cl:check-type, though
23:27:07
edgar-rft
Oladon: red highlight is probably because of CL:CHECK-TYPE -> http://www.lispworks.com/documentation/lw50/CLHS/Body/m_check_.htm
3:17:23
beach
merazi: http://www.total-knowledge.com/~ilya/mips/ugt.html#:~:text=UGT%20%28abbr.%29%3A%20Universal%20Greeting%20Time.%20UGT%20is%20convention,time%20of%20any%20member%20of%20channel%20is%20irrelevant.
3:20:00
merazi
I'm learning Scheme, a lisp implementation (I know it's not the same as Common Lisp), and I wanted to be part of the lisp community.
3:31:14
beach
merazi: I should tell you, usually #commonlisp is fairly lively, but this is Sunday morning in Europe, and many people here are Europeans with families, so it is a bit slow during the weekend.
3:32:30
merazi
That's completely understandable, I won't be here 24/7 but I'll hang out occasionally.
3:58:11
jcowan
merazi: Not to steal you away or anything, but there is a #scheme channel as well as the #lisp channel, which is about all the Lisps.
3:59:13
merazi
I'm already in the #scheme channel and... *click* Now I am in the #lisp channel as well :)
4:05:55
beach
That dictionary entry says how a conflict should be resolved when an imported symbol conflicts with an existing inherited symbol, and when it conflicts with a symbol that is present.
4:05:59
beach
But what about this scenario: A new symbol conflicts with a symbol that is present, but the present symbol is a shadowing symbol, and there are external symbols in the used packages that would conflict if it weren't for the fact that the present symbol is a shadowing symbol.
4:06:00
beach
So here is my question: Should a conflict be reported that contains also the inherited symbols? If not, what happens if the user uninterns the present symbol? Should the new symbol also be a shadowing symbol right away, or should a new conflict be reported?
4:09:18
beach
I am leaning toward not including inherited symbols in the conflict report and to make it shadowing if the present symbol is a shadowing symbol.