jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
tyson2 has joined #commonlisp
SunClonus has quit [Read error: Connection reset by peer]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
AetherWind has joined #commonlisp
AetherWind is now known as AWLYGJ
AWLYGJ is now known as awlygj
decweb has quit [Ping timeout: 252 seconds]
jmdaemon has joined #commonlisp
varjag has quit [Ping timeout: 264 seconds]
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
dra has quit [Ping timeout: 260 seconds]
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
awlygj has quit [Client Quit]
mrcom has joined #commonlisp
awlygj has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life has joined #commonlisp
younder has quit [Remote host closed the connection]
decweb has joined #commonlisp
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
ldb has joined #commonlisp
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
X-Scale has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
gorignak has joined #commonlisp
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
Lycurgus has joined #commonlisp
decweb has quit [Ping timeout: 240 seconds]
Lycurgus has quit [Quit: leaving]
Inline has joined #commonlisp
random-nick has quit [Ping timeout: 256 seconds]
jack_rabbit has quit [Remote host closed the connection]
jack_rabbit has joined #commonlisp
josrr has quit [Remote host closed the connection]
mooncat has joined #commonlisp
chiselfuse has quit [Ping timeout: 255 seconds]
chiselfuse has joined #commonlisp
<clothespin> tried loading cleavir on another system, :ctype-tfun is missing and cannot be found on the web
<bike> yeah that one's an actual issue
<bike> see, the ctype project (i linked it earlier) has a "tfun" optional subsystem. originally i named this system ctype-tfun, and that's what's in quicklisp. but that's not the naming convention asdf wants, and while fixing it i made it ctype/tfun instead
<bike> i delayed changing cleavir on the theory that people would have the old quicklisp version, but i think that's a bust
<bike> so you just need to change ctype-tfun to ctype/tfun. i just pushed a change for that.
tyson2 has joined #commonlisp
<clothespin> i copied ctype-tfun from another machine
<clothespin> quicklisp isn't foolproof
<clothespin> and old school developers who have built up a lot of systems in their quicklisp/dist/quicklisp/software/ directory often are like "it works on my machine"
<AmyMalik> O_O
<AmyMalik> hearing about this distresses me. disclaimer: the only thing I know about lisp is (that (it kinda looks '(like this)))
<AmyMalik> but it sounds like quicklisp is one of those incompatible implementations
<Mondenkind> quicklisp is a package manager
<AmyMalik> ah
<Mondenkind> the package management situation in common lisp is not great, but also not particularly worse than other languages, so
<clothespin> one should blow away that directory from time to time to experience what a noob on a fresh machine experiences
<AmyMalik> lemon crisp
<AmyMalik> i think if i ever started doing things with CL I'd prefer to work without QL if reasonably possible
<clothespin> an mv quicklisp/local-projects/
<bike> this is more a problem with my dependency management than anything else.
<BrokenCog> I'm trying to figure out multiple-value-bind ... what do I need to do in a function to return multiple values?
<clothespin> (values a b c)
<BrokenCog> ah values. thanks.
<clothespin> there's also (values)
<clothespin> don't forget that
<BrokenCog> right.
rtypo has quit [Ping timeout: 260 seconds]
<ldb> quicklisp, aka download latest software in one expression
<ldb> and it doesn't do much other than that
<AmyMalik> it sounds slow
<AmyMalik> can i get the archives on blu-ray instead?
<ldb> kind of, if you pay for the shipping
ldb has quit [Quit: update emacs]
<clothespin> have you ever typed "building clasp" into google?
<BrokenCog> AmyMalik: are you being sarcastic about this? if not ... what would be a 'not slow' alternative?
<AmyMalik> I don't know
<AmyMalik> my brain's broken today
AmyMalik has left #commonlisp [Now, I'm the vixen with a knife, and I want blood.]
<BrokenCog> okay. is pip (in python realm) slow?
<clothespin> it's like searching for "taylor shift"
<BrokenCog> Taylor lost her shift recently.
* BrokenCog wonders if I said something wrong ...
<clothespin> my friend has a dog named pip
ldb has joined #commonlisp
X-Scale has quit [Quit: Client closed]
bilegeek has joined #commonlisp
decweb has joined #commonlisp
<markasoftware> Nilby: I'm not sure I understand how someone would use CLIM as a replacement for sly/the REPL. It's just a GUI framework, not an IDE?
<ldb> McCLIM has some applications shipped, including a GUI repl
<beach> markasoftware: I think Nilby is saying that we need to create a CLIM-based IDE so that people will be more exposed to it.
<beach> markasoftware: And, yes, as ldb is saying, there is the CLIM listener that is shipped with McCLIM.
hineios2 has quit [Ping timeout: 260 seconds]
hineios2 has joined #commonlisp
<ldb> personally, I rarely utilized fancy features from sly, or parenthesis editing features from emacs
<beach> ldb: So what does that observation imply?
<ldb> So I don't feel any reason not using CLIM for development even if CLIM based IDE lacks these features or only provides inferior version.
<beach> Ah, I see.
<beach> So what we are working on is an editor for Common Lisp code that analyzes the code at typing speed, so that you don't have to compile it to discover simple typos, and that highlights elements based on semantics instead of just syntax, also at typing speed.
<beach> We hope that this editor will persuade some programmers to use it rather than SLIME or SLY for Common Lisp code. Then, there will be more exposure to CLIM as Nilby wants. And we can start thinking about other elements of an ide.
<beach> Mind you, some elements already exist, like the "backtrace inspector", and Clouseau (the object inspector).
jack_rabbit has quit [Remote host closed the connection]
jack_rabbit has joined #commonlisp
Inline has quit [Quit: Leaving]
mason has joined #commonlisp
Inline has joined #commonlisp
epony has quit [Remote host closed the connection]
epony has joined #commonlisp
<beach> Any remarks? "That just can't be done!", "Sounds awesome! I will use it right away!", ...
<ldb> Semantic syntax highlithing is hard for a programmable language
<beach> How so?
<ldb> I guess that needs to try expand the macros
<beach> Oh, we plan to compile the code. So that include expanding macros, yes.
<beach> ... where "compile" means just the first phase of a compiler. Not code generation.
<ldb> like what clang can be used to do, provide lsp intergation
* ldb that's not a compliment on lsp protocol
<beach> Is that a question? As far as I know, LSP works by using a communication protocol. What we are planning is an editor that runs in the same Common Lisp process as the code being developed.
<ldb> I mean clangd provides syntax highlighting and completion for C/C++ to the editor, via lsp protocol. but yeah lsp isn't a must when everything is integrated
<beach> Right.
<beach> Static languages are must simpler (though C++ has lots of complicated syntax of course) that a language such as Common Lisp that has reader macros, macros, compile-time execution, etc.
<beach> *than a language
<beach> The advanced features of Common Lisp is of course the reason why something like SLIME or SLY can't do a very sophisticated analysis of the code.
<ldb> oh right, with constexpr added to C++ now they also need a interpreter for compile time, which is a setback in my opinion because Lisp can already run compiled code at compile time
Lycurgus has joined #commonlisp
<beach> Interesting!
<ldb> And for dependently typed languages, they also depends on fast interpreter for compile time type checking.
<beach> I see, yes.
mason has left #commonlisp [#commonlisp]
mooncat has quit [Quit: Connection closed for inactivity]
decweb has quit [Ping timeout: 276 seconds]
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #commonlisp
dtman34 has quit [Ping timeout: 256 seconds]
Lycurgus has quit [Quit: leaving]
dtman34 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
ldb has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
tibfulv_ has quit [Remote host closed the connection]
tibfulv has joined #commonlisp
<markasoftware> Is there any ongoing work to add CLIM backends for GTK, Qt, Cocoa, or native Windows? The CLX backend limits use to Linux and lack of native widgets frankly looks dated
X-Scale has joined #commonlisp
<beach> markasoftware: It is better to ask those things in #clim. I am not personally interested in backends that require foreign code, so I would much prefer that someone work on McCLIM to create a better look for the existing gadgets.
<beach> That way, people could use pure Common Lisp code to create native-looking GUIs.
<beach> markasoftware: Whereas your suggestions would create debugging nightmares for many people trying to use McCLIM.
ronald_ has quit [Ping timeout: 264 seconds]
ronald has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
<beach> I mean, how hard can it be? You just look at the native widgets of GTK, Qt, Cocoa, and Windows, and you create CLIM drawing forms that will produce that look.
<beach> Sounds much easier than to create an FFI-based backend.
ronald has joined #commonlisp
jack_rabbit has quit [Ping timeout: 260 seconds]
awlygj has quit [Quit: leaving]
awlygj has joined #commonlisp
X-Scale has quit [Quit: Client closed]
<beach> I think we are experiencing a kind of prisoner's dilemma. If more people collaborated on improving the looks of McCLIM, then everyone would benefit because of easier debugging. But individually, it is easier to go with an FFI solution. So most people choose to solve their own problems, and everyone loses as a result.
jack_rabbit has joined #commonlisp
varjag has joined #commonlisp
msavoritias has joined #commonlisp
bilegeek_ has joined #commonlisp
bilegeek has quit [Ping timeout: 276 seconds]
bilegeek__ has joined #commonlisp
varjag has quit [Ping timeout: 264 seconds]
bilegeek_ has quit [Ping timeout: 260 seconds]
wacki has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
dcb has quit [Quit: Connection closed for inactivity]
dnhester26 has joined #commonlisp
shka has joined #commonlisp
<beach> It is especially sad, because improving the looks of McCLIM is not particularly hard, and it can be done incrementally.
mgl_ has joined #commonlisp
attila_lendvai has joined #commonlisp
traidare has joined #commonlisp
dnhester26 has quit []
wheatengineer has joined #commonlisp
jon_atack has joined #commonlisp
mgl_ has quit [Ping timeout: 255 seconds]
jonatack has quit [Ping timeout: 264 seconds]
wheatengineer has quit [Ping timeout: 268 seconds]
dnhester26 has joined #commonlisp
jonatack has joined #commonlisp
jon_atack has quit [Ping timeout: 246 seconds]
czy has joined #commonlisp
varjag has joined #commonlisp
<dnhester26> phoe: thanks for the clarification, that'll be useful when I need to code it. I need to do something else right now more pressing, but hopefully will get back to that in a few days and will see how to go about doing that
<minion> dnhester26, memo from phoe: no, classes won't get cleaned up afterwards; you will need to explicitly remove them from the system
<dnhester26> beach: I couldn't find the commit. have you pushed the code?
<dnhester26> Once you pushed, if it works, the results should show up on the page (although the github build takes a while), and if not, it should show up here: https://github.com/lisp-docs/cl-language-reference/actions
<ixelp> Workflow runs · lisp-docs/cl-language-reference · GitHub
rendar has joined #commonlisp
<dnhester26> you can see all the deployments have failed since adding MOP in that link
<beach> dnhester26: I think I did. Let me check...
<dnhester26> when I pulled it didn't show up? which branch are you in?
<beach> master
<beach> https:/github.com/robert-strandh/CLOS-MOP-HTML clearly shows that modifications were made a few days ago.
<beach> dnhester26: Oh, maybe we are talking about different commits.
treflip has joined #commonlisp
waaron has joined #commonlisp
<dnhester26> beach: ah yeah, I wasn't pulling every time from that repo, I just copied the files, turned them into markdown, and added them to the technical reference
<dnhester26> beach: is that the same as your website? I didn't even know about the repo, I just copied the files form your website with wget
<beach> Yes, that's the GITified version of the website. But the website has been updated as well, so that should work too.
dra has joined #commonlisp
dra has joined #commonlisp
dra has quit [Changing host]
X-Scale has joined #commonlisp
<dnhester26> ah ok, I had to make manual changes afterwards, so it's probably just faster to make the new changes by hand :(
varjag has quit [Ping timeout: 256 seconds]
<ixelp> Remove obsolete files. · robert-strandh/CLOS-MOP-HTML@007d5c0 · GitHub
<beach> Yes.
<dnhester26> ok
<Nilby> clothespin: sorry i forgot to mention for running cleavir examples i had to change ctype-tfun to ctype/tfun, and add quite a few directories to my load path
<Nilby> markasoftware and beach: My thoughts on CLIM would take a long blog post, so perhaps I should have kept my mouth shut. CLIM has a different interaction style than many UIs, e.g with a REPL and emacs style, and I think that is part of it's strength. I have great respect for everyone who worked on McCLIM, but I think it doesn't yet achieve what old CLIM did (basically Symbolics Genera version) or what modern CLIM could. I don't fault
<Nilby> anyone, but I think a more radical approach might be needed to make progress.
<beach> Nilby: Do you have any suggestions?
<dnhester26> beach: I just pushed, but just from looking at the last build, there are still broken links: here's the list https://plaster.tymoon.eu/view/4117#4117
tok has joined #commonlisp
<beach> dnhester26: Some of those pages are the ones I deleted.
<dnhester26> ah ok, the links just need to be updated... ok, I'll remove the links myself, no worries
<beach> And some of the ones listed as broken represent the file I added.
<dnhester26> make-method-lambda-symbol in all
<dnhester26> i'm going to edit the pastebin as I make changes
<beach> OK.
younder has joined #commonlisp
<Nilby> beach: What I've done is with my own software is force myself to use it exclusively, despite bugs and lack of features. Then I am forced to add or fix the most important things that stands in the way further development. This is the was all of old Lisp, Unix, Linux, Emacs, etc were developed.
<beach> Nilby: I started using Second Climacs for Common Lisp editin some time ago for precisely that reason, but there were still too many features missing, so I went back to Emacs. But this is about to change soon.
<Nilby> It can be very uncomfortable and frustrating, but I think worth it.
<beach> Sure, I agree. It is just that some more features that I use all the time were needed before I could make such a commitment.
<beach> dnhester26: OK, I see the problem with that broken link. I'll try to fix it during the day.
<dnhester26> beach: ok, thanks, there a a few links needing to be fixed, I left the pastebin with the ones that I wasn't sure. Could you fix it directly in the reference?
<beach> I have no idea what to do in the reference, because I don't know what you did.
<beach> dnhester26: I don't see a problem with table-class-inheritance.html
<beach> dnhester26: I fixed the link in make-method-lambda.
<beach> dnhester26: The make-instances-obsolete is a file I never created apparently, so that will take me some time to fix.
<beach> Oh, wait, some of those links should probably be to the CLOS specification and not to the MOP. That will be easier to fix.
<beach> Anyway, I'll work on those. Thanks for pointing them out.
<dnhester26> beach: ok, the reference if you just pull the latest all the files are there. If you are on emacs in any file of the project you can open the files with the same name, just omit the html extension since they are .md
<dnhester26> they are on the meta-object-protocol folder in the dosc
<dnhester26> if not, I can port the changes after you make them
<dnhester26> I just pushed the latest changes
jmdaemon has quit [Ping timeout: 240 seconds]
chiselfuse has quit [Ping timeout: 255 seconds]
<dnhester26> If I'm calling a function recursively probably about 10 to 20 times max, which takes 5 parameters, do I have to worry about anything in CL? stack issues, compiler issues, etc? it's really not so much memory and I don't want to change the whole code...
<beach> I would appreciate if I didn't have to deal with the reference. I am already allergic to HTML, and it is going to be painful to fix those links.
<dnhester26> beach: ok, no worries. I'll deal with the links, just let me know what to change them to
<beach> dnhester26: You don't need to worry about a few dozen recursive calls.
<dnhester26> ok, great, thanks
chiselfuse has joined #commonlisp
cage has joined #commonlisp
younder has quit [Remote host closed the connection]
waaron has quit [Quit: WeeChat 4.1.2]
younder has joined #commonlisp
waaron has joined #commonlisp
bilegeek__ has quit [Quit: Leaving]
dino_tutter has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
mgl_ has joined #commonlisp
mgl_ has quit [Ping timeout: 256 seconds]
Alfr has quit [Quit: Leaving]
dnhester26 has joined #commonlisp
equwal has quit [Ping timeout: 256 seconds]
equwal has joined #commonlisp
glozzom has quit [Ping timeout: 256 seconds]
glozzom has joined #commonlisp
Alfr has joined #commonlisp
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
X-Scale has quit [Quit: Client closed]
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
mgl_ has joined #commonlisp
thuna` has joined #commonlisp
rendar has quit [Ping timeout: 246 seconds]
occ has joined #commonlisp
mgl_ has quit [Ping timeout: 264 seconds]
thuna` has quit [Remote host closed the connection]
random-nick has joined #commonlisp
thuna` has joined #commonlisp
traidare has quit [Ping timeout: 276 seconds]
Gleefre has quit [Remote host closed the connection]
mgl_ has joined #commonlisp
mgl_ has quit [Ping timeout: 255 seconds]
decweb has joined #commonlisp
josrr has joined #commonlisp
tyson2 has joined #commonlisp
jryans has quit [Quit: Connection closed for inactivity]
rtypo has joined #commonlisp
Gleefre has joined #commonlisp
<dnhester26> I've been tinkering for a while with this with no luck. Maybe someone can help me?
<dnhester26> I have CLOS Object, and I have a so called reader which I see is of the class SB-PCL::READERS, and I have some data
<dnhester26> I simply want to do (setf (slot-value my-object (get-slot-from-reader my-reader) my-data))
<dnhester26> Does anyone have any idea on how to do this?
<dnhester26> at this point I'm happy with sbcl
<dnhester26> since sb-pcl is a sbcl class
<dnhester26> I would obviously prefer something portable, but I've already worked on this for a few hours with no luck
<dnhester26> and I just need to get the result
<dnhester26> I feel like I'm missing something basic
<dnhester26> the reader is, I beleive, an accessor function
<dnhester26> maybe I should be calling it with funcall? that just occurred to me and will try it now
<beach> mop slot-value-using-class
<ixelp> slot-value-using-class
<beach> Are you sure that's the right class name for the slot reader?
<beach> It ought to be something like STANDARD-READER-METHOD.
<beach> Also, as I often point out, the term "CLOS object" is meaningless since every Common Lisp object is an instance of some class, and all classes are defined as part of CLOS.
szkl has joined #commonlisp
<dnhester26> ok, thanks for the clarification, one sec, will look into what you wrote
<beach> Also, I encourage you to use the CLOSER-MOP compatibility library, rather than implementation-specific versions.
<dnhester26> beach: thanks, I was trying to no avail
<dnhester26> beach: it didn't work, would you mind please taking a look? this is the place where I'm getting the reader: https://plaster.tymoon.eu/view/4118 as you can see I explored with the inspector, that last function is the accessor function yet for some reason I can't seem to be able to use it, do you know what can I do?
<dnhester26> sorry to bother
younder has quit [Remote host closed the connection]
<beach> I have no idea what I am looking at.
younder has joined #commonlisp
<beach> mop slot-definition-readers
<ixelp> slot-definition-readers
<beach> Is that what you need?
<dnhester26> ok, hm, the 8th slot in the inspect is the name of the accessor function that I would call to access a value, so doing (setf (my-accesor my-obj) my-value) should work
<beach> READERS is a list of names of generic functions.
<beach> The 8th slot says INITARGS: (:JOBPOST)
<dnhester26> I believe slot 8 is probably the result of that function you just sent me, now how can I use them?
<beach> Oh, sorry, REDERS
<beach> READERS
<beach> READERS is a list of names of generic functions.
<beach> You can use any of them to access the slot.
<dnhester26> yeah, those are the accessors, so how do I use them? If I get the list of readers, how can I use them to set the slot? doing (setf ((car readers-list) obj) value) is not working for me
<beach> You can't use a reader to set the slot. You have to use a writer.
<beach> Something like (funcall (first (slot-definition-writers)) new-value object)
<dnhester26> ah, so just do that with the: 9. WRITERS: ((SETF ...) (SETF ...))
<beach> Something like (funcall (first (slot-definition-writers slot-definition)) new-value object)
<dnhester26> ah even though it returns a list of lists?
<dnhester26> will try it out
<dnhester26> thanks so much
<beach> (SETF ...) is the name of the function.
<beach> And FUNCALL takes a function designator, and the name of a function is a function designator.
<beach> And a slot writer takes two arguments, the new value first, and then the object.
<dnhester26> ah wow, that's something that I don't quite understand because it looks like a function call missing an argument
<dnhester26> ok, thanks, will try it
<beach> So although it is a list of lists, it is better seen as a list of function names.
<beach> But there is something simpler you can do...
<beach> You can call (reinitialize-instance object :<initarg> <new-value>)
<beach> Provided your slot has an initarg of course.
yitzi has joined #commonlisp
<beach> So (reinitialize-instance object :jobpost <new-value>) in this case.
<dnhester26> ah, yes, we have 4. INITARGS: (...)
<dnhester26> that's better than setting with the funcall?
<dnhester26> because it doesn't rely on closer-mop?
<beach> It is certainly simpler.
<dnhester26> is there any difference in the outcome?
<dnhester26> will try both
<beach> I use it all the time, especially when my slots don't have writers on them.
<beach> ... which happens a lot.
<beach> Well, there is a difference in that different generic functions are called.
<Nilby> dnhester26: do you mean something like https://plaster.tymoon.eu/view/4119#4119
igemnace has quit [Read error: Connection reset by peer]
<beach> So if someone put a method on REINITIALIZE-INSTANCE specialized to that class that calls ERROR, then you can't use that technique.
<dnhester26> beach: results: the funcall did not work here's the error: https://plaster.tymoon.eu/view/4120#4120 however the reinitialize-instance worked! I just used the initarg provided instead of the writers, so thank you very much, now at least it works, I didn't really need to use the reader/writer more than the initargs, I just needed the functionality. Now I'm just a bit curious about why the writer still doesn't work, but that's not a p
<dnhester26> ressing need
<dnhester26> Nilby: I have to read the spec on using `when` and `position`, I don't really understand what's going on, but if `(setf (slot-value my-object (get-slot-from-reader 'foo my-reader)) my-data)` that line works, then yeah, that's exactly what I need, thank you
<beach> You might have to stick in a (fdefinition (first ...)) for it to work.
<beach> I was convinced that FUNCALL could take names of the form (SETF ...).
<beach> Let me check that...
<dnhester26> Nilby: I'll look `mop:slot-definition-name` because that seems to be the crux of the approach, correct?
<dnhester26> beach: thanks
<beach> I was wrong. There is a difference between a "function designator" and an "extended function designator" and for some reason FUNCALL is picky.
<beach> But I would use reinitialize-instance instead.
<Nilby> dnhester26: yes, its's just getting the slot name by searching for a matching reader in the slots
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
<dnhester26> beach: thank you. Where can I read about that to learn?
zetef has joined #commonlisp
<dnhester26> Nilby: great, thanks, I will try that approach as well now that I'm at it
mrcom has quit [Remote host closed the connection]
<Nilby> the fun thing is that when someone asks "can the CLOS MOP do this?" the answer is usually yes
<beach> dnhester26: In the standard I guess. REINITIALIZE-INSTANCE is a standard function.
<beach> dnhester26: I think I fixed all broken links. Some of the ones you reported are not broken.
<dnhester26> Nilby: thanks, yeah, it seemed like something that should be simple and I had all the ingredients, I just didn't know how to put them together. I appreciate the help! :D
zetef_ has joined #commonlisp
igemnace has joined #commonlisp
<dnhester26> beach: thanks will read on that as well, I meant where to learn about extended function designator. I will update the links when I get a chance
zetef has quit [Ping timeout: 264 seconds]
<beach> Oh, the glossary.
zetef_ has quit [Read error: Connection reset by peer]
<dnhester26> ah, ok, thanks
zetef has joined #commonlisp
kevingal has joined #commonlisp
chiselfuse has quit [Ping timeout: 255 seconds]
chiselfuse has joined #commonlisp
jrx has joined #commonlisp
mrcom has joined #commonlisp
vyrsh has joined #commonlisp
<vyrsh> I found this book called little typer and it says that dependent types is a hackers paradise? what do they mean by that? also common lisp is dynamically typed so does this still apply to the language?
<dnhester26> Wow I was just reading the section 7.3 on instance reinitialization. It's just unbelievable how everything in CL is just accessible. I feel like all the frustration of not being able to do things in other languages is released in CL, like taking off a straightening jacket. The only issue is figuring out how to actually do things haha, thank you beach and Nilby for the help
<bike> vyrsh: dynamic typing and dependent types are very different things.
<bike> practically unrelated
traidare has joined #commonlisp
<beach> dnhester26: Pleasure! Good luck!
<bike> i think if you want to know what the book meant by what it said you should keep reading the book.
<dnhester26> thanks! :D
<beach> dnhester26: You are right. The philosophy of Common Lisp is to push everything as far as possible without crossing the border of performance penalties. Today, things could have been pushed a bit further, but they pushed as much as they dared at the time.
<clothespin> bike: how big is the CL runtime in clasp? Like, how much memory does it take up once loaded?
<dnhester26> beach: what could be pushed more? is it related to what you are doing with SICL?
<bike> clothespin: a lot. VSZ of my clasp process is a little over a gigabyte right now.
<clothespin> wow.
<bike> we don't really have reducing that as a priority, so.
<beach> dnhester26: I can't think of anything right now. And no, I am not a language designer, though I could perhaps fix a few problems in Common Lisp if given the opportunity. SICL is just an implementation of the standard (and the MOP). Perhaps using better techniques.
<dnhester26> beach: got it, thanks so much
<bike> of course that includes the entire runtime, including stuff beyond CL like clbind, the llvm interface, swank, bla bla bla
younder has quit [Remote host closed the connection]
<beach> dnhester26: The problem with the newbies coming here and having opinions about the language is that they usually know nothing about language design or compiler techniques, so their suggestions wold often be disastrous for performance.
<clothespin> bike: it seems with the size of the memory that comes on gpus today, it would make sense to have much of common lisp in a gpu runtime, but a GB is extreme
<bike> for your GPU thing i have to imagine using a subset or a DSL. like, why would GPU code want to use the MOP for instance?
<clothespin> i wonder how clisp stays so small
<bike> trying to stay small, is a big part of that
<bike> clisp uses a bytecode compiler, which is going to be way way _way_ simpler and smaller than all the llvm stuff clasp has going. clasp also has a bytecode compiler and it's super small compared to the native code compiler
<clothespin> bike: if you looked at the nvidia grace-hopper arch you might see why even CLOS might be useful on a gpu
<dnhester26> beach: I hear, I'm just trying to learn and ask questions, not suggesting anything, that's already way beyond me since I'm not experienced or learned enough in CL, nevermind compiler techniques or language design
<beach> dnhester26: Oh, sure. I wasn't referring to you.
younder has joined #commonlisp
<dnhester26> ok, wasn't sure, I was just asking in general since you said it could be pushed further
<beach> Yes, if I think of something I'll let you know.
<bike> clothespin: i can imagine using method dispatch and stuff. i'm thinking more of having code on the GPU redefine a class, or define a method at runtime on compute-discriminating-function, or the like. but i readily admit gpu code is not my forte
<Nilby> i'd bet clisp or something could be compiled with cuda
<clothespin> defining metaobject on a gpu is not necessary, but accessing them might be
<clothespin> PCL for instance isn't threadsafe
<clothespin> but you may want to operate on CLOS objects in a bunch of threads
<clothespin> generic function dispatch for instance
<vyrsh> bike: I read little schemer and liked that a lot. little typer is interesting but Ive not read a programming book that long so I hope I can complete it.
<clothespin> bike: I would start this project by examining some CL runtimes, and trying to find one that is simple/small enough to start getting code ported to the gpu
<Nilby> if you exclude the filenames, files, streams, system construction, environment, chapters i think CL would be fine on GPU, especially with no-gc or mini-gc
mgl_ has joined #commonlisp
<clothespin> does sicl have a runtime, or does it use the host lisp's runtime?
jrx has quit [Ping timeout: 264 seconds]
awlygj has quit [Quit: leaving]
jrx has joined #commonlisp
prokhor has quit [Ping timeout: 268 seconds]
<clothespin> does clasp use sicl?
prokhor has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
<yitzi> closthespin: Clasp does not use SICL. Much of its initial C and Lisp code came from ECL. It uses some Lisp systems that were created or inspired by SICL. For example Cleavir and Eclector.
<clothespin> thank you
<yitzi> Sorry about the handle typo.
<clothespin> it appears SICL has a runtime of it's own
<yitzi> SICL isn't a functioning Lisp implementation yet. beach is currently reworking the bootstrapping procedure.
Equill has quit [Ping timeout: 260 seconds]
<yitzi> Others (myself included) have worked on the various systems that will be assembled to create the complete ANSI lisp implementation. Some parts like LOOP, printer, etc can be loaded into an existing Lisp implementation and tested against ansi-test to verify that they behave correctly. The idea is to make it easier to assemble a Lisp implementation by using these modular systems.
<clothespin> does SICL have a thread-safety approach to design?
<beach> clothespin: SICL doesn't exist as an implementation (yet).
<beach> ... as yitzi said.
<clothespin> yes, but you can implement code which is not designed to work in multithreaded environments and that is a design choice
<clothespin> I'm simply asking if thread safety is a factor in the design of what has be done thusfar
<beach> clothespin: For thread safety, we define the "rack" of a standard object to have its structure remain in the presence of threads modifying the object.
<beach> clothespin: Yes, it is.
<clothespin> then, given SICL's BSD license, it may be a good starting point to see if I can get some of the lisp code for sequences, for instance, to run on a GPU
<beach> clothespin: We extracted the sequence module. It is called Consecution.
<clothespin> cleavir name
<beach> clothespin: Most modules are now extracted in fact.
<beach> Thanks.
<beach> clothespin: For CONSes, there is the Constrictor system.
zetef has quit [Remote host closed the connection]
dnhester26 has quit [Remote host closed the connection]
<beach> clothespin: So while the SICL Common Lisp implementation is not ready yet, the SICL project (the purpose of which is mainly to create modules for people implementing Common Lisp systems) is making great progress.
<clothespin> gpus are moving to a place where memory is numa and processors are heterogeneous
josrr has left #commonlisp [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
<clothespin> but basically what Nvidia is doing is SMPish
josrr has joined #commonlisp
<clothespin> and this "rack" needs to be shared among different processor types
dnhester26 has joined #commonlisp
<clothespin> it's not going to be enough to have one lisp implementation for the gpu and one lisp implement for the cpu and glue them together
<younder> A GPU is more of a co processor. It is always controlled by a CPU. So GPU's are programmed for libraries run from a CPU.
<clothespin> the point im making is that in a shared memory architecture you can't have fundamentally two different runtimes
a51 has quit [Quit: WeeChat 4.2.1]
<clothespin> and that's what gpus are moving to, i cite cuda
<younder> Well, with NVIDIA libraries like rapids more of the code is run in GPU RAM. Modern AI supporting gPU's have a lot of .RAM up to 65 GB. The PCIE connection has become a bottleneck. That is why more and more of the processing is moved to the GPU. Then there is nvlink which allows rapid GPU to GPU transfer without involving the CPU.
occ has quit [Quit: Leaving.]
<clothespin> in the future more setups are going to be like grace-hopper
<clothespin> so it doesn't even use pcie
<clothespin> i think it uses nvlink over a custom hardware bus for cpu - gpu transfers
<clothespin> by the time i get anything up and going, i'll see hardware like grace-hopper
wacki has joined #commonlisp
<bike> again speaking from a place of naivete as to GPUs, i don't think any of SICL's choices of memory representation should be too arduous for this? racks are just simple vectors, closures are flat...
<bike> tagged pointers might get weird across architectures
<bike> (but you should be able to use most of the sicl components regardless of how you handle that)
szkl has quit [Quit: Connection closed for inactivity]
occ has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
phoe has quit [Quit: leaving]
occ has quit [Ping timeout: 252 seconds]
jrx has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2.50)]
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
phoe has joined #commonlisp
msavoritias has quit [Ping timeout: 276 seconds]
dnhester26 has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
rogersm has joined #commonlisp
jjnkn has joined #commonlisp
Gleefre has joined #commonlisp
wacki has quit [Read error: Connection reset by peer]
X-Scale has joined #commonlisp
wacki has joined #commonlisp
dcb has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
manwithluck has quit [Ping timeout: 256 seconds]
manwithluck has joined #commonlisp
tok has quit [Read error: Connection reset by peer]
tok has joined #commonlisp
mgl_ has quit [Ping timeout: 256 seconds]
dnhester26 has quit [Remote host closed the connection]
tok has quit [Ping timeout: 246 seconds]
tyson2 has joined #commonlisp
ronald has quit [Ping timeout: 256 seconds]
ronald has joined #commonlisp
dnhester26 has joined #commonlisp
epony has quit [Remote host closed the connection]
rogersm has quit [Quit: Leaving...]
zxcvz has joined #commonlisp
zxcvz has quit [Quit: zxcvz]
traidare has quit [Ping timeout: 260 seconds]
rgherdt has quit [Ping timeout: 240 seconds]
mgl_ has joined #commonlisp
ronald_ has joined #commonlisp
ronald has quit [Read error: Connection reset by peer]
mgl_ has quit [Ping timeout: 252 seconds]
epony has joined #commonlisp
mgl_ has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
bjorkintosh has quit [Quit: Leaving]
rogersm has joined #commonlisp
Lycurgus has joined #commonlisp
Lycurgus has quit [Changing host]
Lycurgus has joined #commonlisp
vyrsh has quit [Ping timeout: 255 seconds]
msavoritias has joined #commonlisp
tyson2 has quit [Read error: Connection reset by peer]
rgherdt has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
jack_rabbit has quit [Ping timeout: 276 seconds]
<aeth> all of CL on the GPU doesn't really make much sense
<aeth> The GPU doesn't really have a call stack, though CUDA afaik emulates one. Linked lists don't make sense except perhaps as CDR coded, while homogeneous vecs are native. The usual dynamic typing tricks wouldn't really work well afaik and branching has a huge penalty so you'd almost want a DSL that heavily uses type inference and just feels sort of dynamically typed. Etc.
<aeth> On the other hand, the latter would be more ergonomic than having to DECLARE types and may have a use outside of the GPU.
X-Scale has quit [Ping timeout: 250 seconds]
Lycurgus has quit [Quit: leaving]
jack_rabbit has joined #commonlisp
<aeth> Oh, and you may have to do a lot of work to bring in bignums and rationals despite probably never using them on the GPU.
<aeth> Although that may be worth it even if you go for a subset. Just for consistency of numeric towers.
rendar has joined #commonlisp
rogersm has quit [Remote host closed the connection]
rogersm has joined #commonlisp
rogersm has quit [Ping timeout: 264 seconds]
Inline has quit [Quit: Leaving]
Inline has joined #commonlisp
Odin-LAP has quit [Quit: Going,]
dnhester26 has quit []
chiselfuse has quit [Remote host closed the connection]
jjnkn has quit [Quit: leaving]
chiselfuse has joined #commonlisp
Guest81 has joined #commonlisp
tyson2 has joined #commonlisp
<younder> April will hopefully compile to SPIRV and execute APL on the GPU this year.
Guest81 has quit [Quit: Client closed]
<younder> But first I have to do something to improve SLY/SBCL debugging.
<Mondenkind> linked lists make sense. there is a call stack. the branching penalty is different from cpus; not per se worse or better
ronald has joined #commonlisp
ronald_ has quit [Ping timeout: 256 seconds]
ldb has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.1]
yitzi has quit [Remote host closed the connection]
traidare has joined #commonlisp
<ldb> good afternnon
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
bjorkintosh has joined #commonlisp
treflip has quit [Remote host closed the connection]
davidt has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
davidt has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #commonlisp
rgherdt has quit [Ping timeout: 255 seconds]
SunClonus has joined #commonlisp
rgherdt has joined #commonlisp
SunClonus has quit [Read error: Connection reset by peer]
traidare has quit [Ping timeout: 260 seconds]
rgherdt has quit [Ping timeout: 255 seconds]
_cymew_ has quit [Ping timeout: 268 seconds]
igemnace has quit [Read error: Connection reset by peer]
fe[nl]ix has quit [Quit: Valete!]
fe[nl]ix has joined #commonlisp
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
jmdaemon has joined #commonlisp
igemnace has joined #commonlisp
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
Inline has quit [Quit: Leaving]
Odin-LAP has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
rendar has quit [Ping timeout: 246 seconds]
amb007 has joined #commonlisp
rgherdt has joined #commonlisp
mgl_ has quit [Ping timeout: 264 seconds]
shka has quit [Ping timeout: 256 seconds]
Inline has joined #commonlisp
amb007 has quit [Ping timeout: 260 seconds]
SunClonus has joined #commonlisp
Lycurgus has joined #commonlisp
ldb has quit [Remote host closed the connection]
attila_lendvai has quit [Ping timeout: 240 seconds]
dino_tutter has quit [Ping timeout: 255 seconds]
mjhika has joined #commonlisp
mjhika has left #commonlisp [#commonlisp]
<aeth> Mondenkind: Lisp cons-style linked lists on the GPU outperform linked lists on the CPU at any tasks? Maybe.
<aeth> doesn't seem like it just based on how GPUs work, though
<aeth> This thread from earlier this month leaves me with the impression that you only get a call stack if you implement it yourself, at least for graphics shaders rather than compute kernels, but it's definitely possible compute kernels just... implement it. https://news.ycombinator.com/item?id=38937129
<ixelp> Vcc – The Vulkan Clang Compiler | Hacker News
<aeth> Seems to be a very similar project to Clasp on the GPU, btw.
<bike> what do you know, opencl c forbids recursion (at least according to wikipedia)
<aeth> yes
<aeth> and I think the main part is due to this lack of a call stack at least on older GPUs, when these APIs were designed > 10 years ago
<aeth> even if they all have it now
<aeth> (Vulkan itself is newer, but is derived from Mantle, from 2013)
<aeth> There are quite a few relevant posts linked in that HN thread and linked in the links from that thread.
<bike> when you say "lack of a call stack" in relation to hardware you mean like what, lacking a call (jump and save return address) instruction?
<aeth> They almost... lack real functions entirely. The intuitive model of functions from these HN posts seem to be that they all get inlined.
<bike> okay, but that's not, like, a statement about hardware