libera/commonlisp - IRC Chatlog
Search
17:39:14
White_Flame
looking at the disassembly, it's only checking the low byte tags for #x09. I wonder what the rest of the word implies
17:41:08
White_Flame
(and obviously the #x50100109 is not a "value" in the lisp sense, but rather a specific machine word encoding here)
17:46:28
Nilby
Yes. Not very important to know, but at least now I can see that unbound things might look like dark red when I scroll through memory as pixels.
20:36:07
Michal
Does anybody have any recommendations for machine learning libraries in Common Lisp?
20:44:03
Qwnavery
It's a hard one because I'm unaware of any ML projects that have GPU accellerated support
20:46:28
Michal
I thought it was much faster than Python, but I heard Python had an optimised library via numphy
20:46:55
Michal
What's CUDA? I'm very new to all of this. I just finished Andrew Ngs course and wanted to try stuff out
20:53:00
Qwnavery
Michal: cool, to get started with CUDA you'll need the Proprietary Nvidia CUDA drivers https://developer.nvidia.com/cuda-downloads
2:34:43
sukaeto
late to the conversations, but I (think I) understand what beach is saying re: binding
2:36:03
sukaeto
they sometimes use it the way a compiler writer would - as in "this variable is bound to this value"
2:36:28
sukaeto
they also use it in the logical sense - as in "this variable is not free in this form. It is bound."
2:39:20
sukaeto
in the second sense, you're saying the variable is bound by the *context*. (progv '(*x*) () (boundp '*x*)) <- *x* is bound in the sense that it won't be susceptible to variable capture, no matter where that progv is put
5:05:52
beach
lisp123: You can figure out the answer by checking for those in existing code. So if I take SICL for instance, we seem to have 25 :before, 31 :after, and 53 :around.
5:10:11
lisp123
I was wondering how useful they were since you could also bundle some of that code into the primary methods. In Sonja Keene's book, they note it as useful for code reuse (this was for :before and :after at least), where more specific classes can do some additional side effects on top of the primary method, either before or after
5:12:14
beach
lisp123: When I taught a small class at the university of Auckland, I showed the students how, if you don't have auxiliary methods, then you might sometimes have to change the interface to obtain certain optimizations, so that's a no-no for stable APIs. They were totally convinced.
5:12:36
beach
lisp123: So you can obtain the same effect with only primary methods, but you can't then also have your software modular.
5:13:11
beach
You probably haven't seen that issue, since I bet your code is fairly small, and you write mainly for yourself.
5:13:47
lisp123
Yes, I don't use much state at all or have large code at all, hence wanted to ask what was used in bigger projects.
5:14:29
lisp123
So basically, the primary method gives the primary interface which clients use, and then you add some stuff before/after/around it?
5:14:35
beach
Then you just have to take my word for it, that auxiliary methods are a must for larger projects, and especially for stable libraries.
5:15:25
beach
Yes, one common thing to do is to have the library define an :around method that can intercept the client call, and do special things then.
5:17:43
beach
Common Lisp has a lot of that kind of stuff, i.e., features that are almost never used, but when you need them, you really can't do without them. Since other languages often don't have these features, they have to sacrifice modularity, maintainability, performance, etc.
5:18:49
beach
For instance: custom metaclasses, custom method combinations, custom function types, reader macros, macros, etc., etc.
5:19:07
lisp123
Yes, its very well thought through. I basically assume anything in CL is there for a very good reason
5:19:40
beach
So the incorrect conclusion made by people who don't like Common Lisp is that, since these features are rarely used, they aren't really useful. Very wrong!