#lisp on 2021-03-20 — irc logs at freenode.irclog.whitequark.org

03:57 <fiddlerwoaroof> Is it possible to reset the list being collected into by loop?

04:03 <beach> Good morning everyone!

04:10 <Spawns_Carpeting> Good morning

04:11 <fiddlerwoaroof> j

04:16 <beach> Spawns_Carpeting: Are you new here? I don't recognize your nick.

04:17 <beach> Xach: That is surprising indeed. What implementation was that?

04:18 <beach> fiddlerwoaroof: I don't think there is a way to access the list collected.

04:19 <fiddlerwoaroof> Yeah, I decided to switch to a with/do instead of collect

04:19 <beach> Yeah, much better.

04:21 <Spawns_Carpeting> beach: yes

04:22 <Spawns_Carpeting> First time in this channel. I just discovered lisp a few days ago and have been attempting to learn it

04:22 <beach> Great! Welcome!

04:23 <beach> Feel free to ask questions. If they become numerous and truly trivial, depending on traffic here, you may be asked to take them to #clschool.

04:24 <Spawns_Carpeting> That's a good channel to know about thanks

04:25 <beach> Sure.

04:35 <beach> Spawns_Carpeting: What programming language(s) did you use in the past?

04:37 <Spawns_Carpeting> Mostly Python, C and C++

04:37 <Spawns_Carpeting> So coming from those and then trying lisp... the difference is really big

04:37 <beach> Indeed.

04:38 <beach> The semantics of Common Lisp is closer to Python than to C and C++, but performance of a good Common Lisp implementation is closer to C++ than to Python.

04:39 <Spawns_Carpeting> I have been using CLISP and SBCL. CLISP seems really terribly slow but SBCL is incredibly fast

04:40 <beach> Yeah. CLISP uses a bytecode interpreter for its evaluator (but I think there is work to do something better) whereas SBCL compiles to native code.

04:41 <moon-child> clisp is still under development?

04:41 <beach> moon-child: Somewhat, I think. Yes.

04:41 <Spawns_Carpeting> Emacs lisp is pretty neat too, that's what introduced me to it all

04:42 <beach> Sure.

04:44 <beach> I have a funny anecdote about Emacs Lisp. When RMS announced Emacs in 1984 (I think it was), I answered his email saying it would be better to first write a good Lisp system and then implement Emacs in it, rather than writing a very rudimentary Lisp system specifically for Emacs.

04:44 <beach> He answered (I believe I remember it literally): "Sounds good! Let me know when you have implemented it!"

04:45 <Spawns_Carpeting> wow you had RMS's email? that's pretty cool

04:45 <Spawns_Carpeting> I guess it was a mailing list or something but still

04:46 <beach> Yes, email was pretty much the only option then.

04:48 <beach> I haven't seen him much lately, but when we organized the "Libre Software Meeting" for many years (starting in 2000 I think) he was a regular visitor. And I invited him to spend a few weeks at our laboratory at some point as well.

04:50 <beach> Hmm, so I guess I am currently working on what he "encouraged" me to do. :) Only some 37 years later.

04:50 <Spawns_Carpeting> You are working on a lisp implementation?

04:50 <beach> Yes.

04:50 <beach> minion: Please tell Spawns_Carpeting about SICL.

04:50 <minion> Spawns_Carpeting: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL

04:52 <Spawns_Carpeting> That sounds fun, also very impressive

04:52 <beach> Thanks.

04:52 <Spawns_Carpeting> You certainly must know quite a lot about the language ha!

04:54 <beach> Many people who hang out here are very knowledgeable. Not only about Common Lisp, but about many other things. That's a huge reason why I like #lisp. I am certainly not *the* expert.

04:54 <beach> Spawns_Carpeting: Oh, and don't waste your time on SICL at this point. It is not ready yet. I would stick to SBCL if I were you.

04:54 <Spawns_Carpeting> That's the cool thing about freenode in general, lot's of knowledge available

04:55 <beach> Indeed. But I hear rumors that many channels are a lot less friendly and a lot more tolerant of ignorant babble than #lisp.

04:58 <Spawns_Carpeting> I need to head to sleep it's 1am here. It was nice meeting you beach: I will certainly be back with hopefully not too basic of questions !

04:58 <beach> Sleep well.

05:02 <beach> So north America is already on daylight savings time, I guess.

05:03 <fiddlerwoaroof> beach: yeah, my life has been sort of miserable because kids don't recognize DST

05:03 <beach> I can see that.

05:03 <beach> Here in France, we worry more about the cows than about the kids.

05:07 <beach> I say "we", but I worry about neither myself. I was only reporting what I see on the TV news.

05:07 <fiddlerwoaroof> I hope to make it to Europe one of these years

05:08 <beach> You haven't been here yet?

05:08 <fiddlerwoaroof> No, I don't even have a passport :)

05:08 <beach> Oh, yeah, then definitely! It's a great place!

05:09 <beach> Maybe for ELS2022.

05:11 <fiddlerwoaroof> Yeah, that would be fun. I've been sort of planning on a trip to Europe in '22 for other reasons

05:11 <beach> I see.

09:55 <CL-ASHOK> is it possible to do the following (defun (my-variable) (let ((my-variable (+ my-variable 1)....

09:55 <CL-ASHOK> i.e. is the parameter variables in a different namespace to the lexical scope of the let

09:55 <CL-ASHOK> and I can re-use them

09:56 <CL-ASHOK> or do I need to have seperate names?

09:56 <beach> Hold on a minute....

09:56 <beach> First of all, DEFUN takes a function name as the first parameter.

09:57 <CL-ASHOK> sorry I missed that part

09:57 <beach> Did you just omit it?

09:57 <CL-ASHOK> yes

09:57 <CL-ASHOK> sorry

09:57 <beach> The parameter is in the same namespace as other variables.

09:57 <beach> So you can do what you suggested.

09:58 <beach> Except you should use the function 1+ rather than (+ ... 1)

09:58 <CL-ASHOK> Thanks! So does it just override the value of my-variable?

09:58 <beach> Within the scope of the LET, yes.

09:59 <CL-ASHOK> thanks!

09:59 <beach> Pleasure.

09:59 <CL-ASHOK> (p.s. looks strange what I'm doing but I'm trying to implement some function overloading with &key)

10:00 <beach> I don't see the relation. What do you mean by "function overloading" and how is it related to &key?

10:01 <CL-ASHOK> Function overloading is when you have functions with the same name but accepting different parameters

10:01 <CL-ASHOK> e.g. get-data (field1 field2) and get-data (field3)

10:02 <CL-ASHOK> so I'm using &key to make these fields optional and accessible, e.g. (defun get-data (&key (field1 nil) (field2 nil) (field3 nil)...

10:02 <beach> I guess you could do that with &rest and/or &optional, but I don't see how to do it with &key.

10:02 <CL-ASHOK> then using a let where I check if they are supplied, to determine the correct function to execute

10:03 <CL-ASHOK> but I don't want to keep creating new names, so its good to be able to reuse the names (like in my original question)

10:03 <beach> Then you would have to call it like this: (get-data :field1 ... :field2 ...)

10:03 <CL-ASHOK> yes

10:04 <beach> That looks like just a function with keyword arguments to me. Nothing special.

10:04 <CL-ASHOK> Yeah, nothing special. I will just a control flow within the function to do different things with it, depending on which combination of keyword arguments are supplied

10:05 <beach> OK. Can I assume you know about the SUPPLIED-P option to keyword parameters?

10:06 <beach> e.g. &key (field1 nil field1-p) (field2 nil field2-p)...

10:06 <CL-ASHOK> I do now! Thanks!

10:06 <beach> OK.

10:06 <CL-ASHOK> more cleaner than checking if they are nil

10:06 <beach> Especially if NIL is a valid argument for one of them.

10:07 <CL-ASHOK> yep

10:07 <CL-ASHOK> Is it field1-p or field1-supplied-p or it doesn't matteR?

10:08 <beach> It's your choice. Just a variable. I tend to use the shorter form.

10:08 <CL-ASHOK> Thanks, really appreciate it :)

10:09 <beach> Sure. Good luck.

11:16 <marcoxa> Hi everybody... just wanted to point you to my latest blog post on HELP. https://within-parens.blogspot.com/2021/03/he-asdf.html Give it a spin.

11:20 <_death> marcoxa: hmm, it has a "<" package, which conflicts with yaclml

11:21 <_death> this is a case where I can accept that local package nicknames make sense

11:27 <marcoxa> _death quick answer. XHTMLambda (https://common-lisp.net/project/xhtmlambda/) is better that yaclml, obviously :) Plus, I think that the "<" package nickname is uset by at least two other HTML/XML libraries.

11:28 <_death> marcoxa: I wasn't aware of it, and should check it out.. but the issue remains ;)

11:29 <_death> since I have yaclml in my core, I would have to recompile a new core in order to test helambdap

11:29 <_death> or rename the package

11:31 <marcoxa> Well. I never compile stuff in a core. I guess renaming package and nicknames ("<" is a nickname for XHTMLambda) can at least make you try things out.

11:31 <_death> marcoxa: well, after renaming it, it gives a compilation error on sbcl, because collection-utilities.lisp has a loop form that has "finally return (values ...)" which is not valid syntax.. it should be "finally (return (values ...))"

11:32 <_death> the are other loop forms with the same issue

11:36 <_death> sbcl also catches a type error in xhtml-lambda-producer, where mapc is used with a non-list

11:36 <marcoxa> Good catch. I don't use fascist implementations, so I get away with a lot :) :) :) You can get the new fix from the repo. I am afraid there may be other instances of the same.

11:38 <marcoxa> If you get other bugs, please open issues on the repo. I have to run for a few hours now.

11:43 <_death> if there's a (defstruct foo bar) helambdap will try to intern FOO-BAR (the conc-name and the slot name) in the package where BAR belongs.. so that means if I have (defstruct foo structure) it will try to intern a symbol in the CL package :/

11:43 <Xach> marcoxa: http://report.quicklisp.org/2021-03-20/failure-report/helambdap.html#helambdap

11:47 <_death> it also had an issue where it passed a string to package-shortest-name.. I removed the type declaration and replaced sn assignment form with (if (stringp p) p (package-name p))

11:50 <_death> ok, likely the biggest issue I have with now, is that the resulting website requires javascript to propertly browse

11:50 <_death> *properly

11:57 <_death> oh, wait.. there's no javascript, sorry.. it's just an "Uncaught DOMException: Access to property denied".. maybe because of a frames setting

12:29 <MrtnDk[m]> @Josh_2 beach Thank y'all for correcting me. I learned from that. (Did Josh_2 leave the room/channel for some reason? I can't seem to tag them)?

12:31 <beach> MrtnDk[m]: Some people disconnect when they go do something else.

12:37 <MrtnDk[m]> beach Yeah, I guess I do that too sometimes, when I'm on IRC.

12:57 <nij> Hello folks! Is there a way in swank/sly to view and select all variables that are bound?

12:57 <nij> For example, for the symbol 'slynk:stop-server, I hope to search for it by typing "sly server" in an ivy buffer. That way, I don't have to remember whether it's "stop-server" or "server-stop".

12:59 <MrtnDk[m]> nij What du you mean by Swank? 😁

13:02 <nij> Ah sorry, slime!

13:04 <beach> MrtnDk[m]: Swank is the Common Lisp side of the communication between a Common Lisp implementation and Emacs that makes SLIME and Sly possible.

13:07 <nij> Yeah, beach, it's my fault. What makes more sense are the pairs (slime,sly) and (swank,slynk).. but I talked instead (swank,sly), which was confusing.

13:08 <beach> nij: Sure, but I don't think that was the reason for the question asked by MrtnDk[m].

13:09 <nij> I see!

13:31 <marcoxa> Xach. Already corrected in the repo.

13:33 <marcoxa> _death excellent catch with the defstruct case. Let me look into it. I will also look into package-shortest-name.

13:52 <marcoxa> _death the problem with servig static webpages are browser dependent. To test the generate docs you need to have a HTTP server running on a parent directory. I either use hunchentoot or the simpler node/npm http-server to serve static pages to check the docs.

13:55 <_death> marcoxa: I see

13:57 <MrtnDk[m]> beach is right, nij . My question came from a place of ignorance. I haven't really coded common lisp with Emacs yet. I just use my mobile cell gizmo with "CL REPL" to learn a little. I am mainly trying to learn Scheme, but CL is a very strong dialect of Lisp.

14:06 <marcoxa> _death I think I fixed also the issue with PACKAGE-SHORTEST-NAME. I just pushed a fix (which may wreck havoc down the road).

14:21 <CL-ASHOK> Best book to learn lisp macros from? On Lisp or Let over Lambda?

14:22 <CL-ASHOK> or any other suggestions :)

14:24 <marcoxa> _death I also fixed the structure/conc-name bug.

14:25 <marcoxa> Very nice catch.

14:37 <beach> CL-ASHOK: I haven't read Let over Lambda (yet). But I learned about macros from On Lisp, and I was quite pleased with that. Graham shows some very sophisticated techniques.

14:39 <CL-ASHOK> Thanks @beach Looks like On Lisp is recommended as a precursor to LoL

14:39 <beach> CL-ASHOK: You should know, though, that macros are not very frequent. When you need them, it is good that they exist, but it is a common newbie mistake to overuse macros.

14:39 <Josh_2> Afternoon

14:39 <beach> Hello Josh_2.

14:39 <Josh_2> The macros in LoL are pretty crazy

14:40 <CL-ASHOK> @beach agreed - I haven't touched them for a while, thought I'd dip my feet as I've noticed I'm writing a lot of similar code that can be re-used

14:40 <nij> beach: i recently learned that PG started writing that book when he was a undergrad xD

14:41 <beach> CL-ASHOK: Sure. But the main abstraction mechanism remains functions, possibly generic functions. Macros should be used only when the semantics of a function call won't work.

14:42 <beach> nij: Impressive.

14:43 <CL-ASHOK> thanks

14:46 <nij> beach: OH sorry it was grad school, not undergrad. As in "It's scary to think how little I knew about Lisp hacking when I started writing that book. But there's nothing like writing a book about something to help you learn it. The book, On Lisp, wasn't published till 1993, but I wrote much of it in grad school."

14:46 <nij> http://www.paulgraham.com/worked.html

14:47 <beach> Ah, OK.

14:50 <MrtnDk[m]> Which interpreter is most free? Does guile support common lisp?

14:50 <Xach> MrtnDk[m]: what does free mean to you? and guile does not support common lisp.

14:51 <Xach> MrtnDk[m]: what does free mean to you? and guile does not support common lisp.

14:51 <nij> Are they different lisp dialects?

14:51 <MrtnDk[m]> Josh_2 Welcome back & thank thee (and beach ) for correcting me on and.

14:52 <beach> MrtnDk[m]: Also, most modern Common Lisp systems compile (on the fly) to native code. So maybe you don't want to ask explicitly for an interpreter. You may get the wrong information then.

14:52 <MrtnDk[m]> nij Are which ones different Lisp dialects?

14:52 <beach> nij: Scheme is a different language from Common Lisp. And Guile is mostly an implementation of Scheme.

14:54 <beach> MrtnDk[m]: Several Common Lisp systems are free: SBCL, CCL, and ECL are probably the ones that most people here use.

14:55 <beach> MrtnDk[m]: ABCL is good if you want one that runs on the JVM.

14:55 <MrtnDk[m]> Thanks beach & Xach ... you are right beach. I phrased the question like that out of ignorance. Xach Good question about freedom. I was thinking GPL3+, but I'd also like one that integrates well with Emacs, and I'd like one that is part of (or at least packaged for) Debian. Guix would be my secondary choice.

14:56 <beach> MrtnDk[m]: SLIME for Emacs works with any Common Lisp implementation that supports SWANK, and I believe all the ones I cited do that.

15:01 <Josh_2> has anyone used allegro cache?

15:04 <MrtnDk[m]> beach I will look them up.

15:18 <beach> Josh_2: I am sure someone has.

15:42 <Josh_2> isn't there a CL based database around

15:42 <Josh_2> made by the folks at the law firm I think

15:43 <Josh_2> I can't find the repo :(

15:44 <Lycurgus> what I more often see is the image considered to be a database, unlike say gen in smalltalk and what not

15:44 <Lycurgus> *gem/gemstone

15:45 <Lycurgus> or prolog doing regular relational algebra which could be in lisp

15:45 <Josh_2> I think some persistant image based storage would be very useful

15:46 <Josh_2> where the lisp image acts as the storage mechanism, this would mean my deployment would be extremely easy to install

15:47 <Lycurgus> that's what I was referring to; I think regular rdms cl pkgs are more consistent with the overall cl cultural ethos

15:49 <Lycurgus> *rdbms

16:14 <SAL9000> Are there any maintained CL bindings to libgit2?

16:15 <SAL9000> there is https://github.com/russell/cl-git but it's clearly out of date

16:49 <_death> hmm, sbcl gives a warning for (defun foo (a) (let ((b (sqrt a))) (coerce b 'float))) .. it's true that sqrt may return a complex if provided with a negative value, but I don't see why there should be a warning there and not when the coerce form is replaced by (float b)

17:00 <fiddlerwoaroof> SAL9000: what are you trying to do? I couldn't find any good wrappers around libgit2 when I looked, so I started re-implementing all the datastructures and file readers for git: https://github.com/fiddlerwoaroof/cl-git.gi

17:00 <fiddlerwoaroof> https://github.com/fiddlerwoaroof/cl-git.git

17:00 <fiddlerwoaroof> It mostly works, for getting data out of git repositories, but it doesn't handle "delta compression" yet

17:00 <fiddlerwoaroof> There's also Shinmera's legit that just shells out to a git executable

17:01 <SAL9000> fiddlerwoaroof: I have some work on (for lack of better terms) partial copying between Git repositories, with history preservation. That work is in Python and has become a massive non-debuggable hairball... clearly rewrite-in-Lisp time :-)

17:01 <fiddlerwoaroof> Ah, like the subtree split commands?

17:01 <SAL9000> I'd like to avoid shelling out because this needs to run on Windows where fork is *expensive* (even more so with corporate antivirus... sigh)

17:02 <SAL9000> Hm, maybe? It's more complex than that. I try to "re-attach" history in both directions.

17:04 <SAL9000> Given 2 repos A and B, containing files a and b respectively, I synchronise the set of shared files c (i.e. union(a, b)) between the repositories, copying the equivalent of git log --full-history -- [the_files]

17:05 <SAL9000> fiddlerwoaroof: I like your 'git-issue' thing by the way, it's cute :-) Have you considered using git notes instead, to avoid "polluting" the commit log?

17:21 <fiddlerwoaroof> SAL9000: someone pointed those out to me when I mentioned it once, they don't show up in `git log` as nicely, and most git hosting services don't have a UI for them

17:21 <SAL9000> Yeah, no-one uses them -> they're not supported by things -> no-one uses them :(

17:21 <fiddlerwoaroof> But, it's probably a better solution in many ways.

17:22 <SAL9000> What's the current solution to C groveling, I guess? c2ffi?

17:22 <SAL9000> Looks like if I want a libgit2 CL binding I'll have to make my own.

17:22 <fiddlerwoaroof> I started writing cl-git so I could write a git webui

17:22 <SAL9000> SWIG recently (mid-2019) ditched all the CL backends, too

17:23 <fiddlerwoaroof> I've mostly just manually written out the C wrappers

17:23 <SAL9000> that's a lot of functions... ~700 iirc

17:23 <fiddlerwoaroof> Well, I've only ever needed three or four functions from a library

17:23 <SAL9000> I'm thinking use grovelling to wrap the C API, then the manual work can instead be spent making it "Lispy" :)

17:24 <fiddlerwoaroof> Also, most of the FFI I do is objective-c, which is easier to wrap in a bunch of ways

17:24 <fiddlerwoaroof> https://github.com/rpav/cl-autowrap looks like it might work, though?

17:25 <SAL9000> cl-autowrap uses c2ffi, which is what I mentioned earlier :)

17:25 <SAL9000> I tried it earlier but my work machine's AV decided to explode in my face about "untrusted code", sigh. Will try again later on personal machine.

17:26 <fiddlerwoaroof> Yeah, I try to avoid anything that requires building LLVM

17:45 <CL-ASHOK> how to stay connected and read previous messages? I always get disconnected when I move away for a bit from freenode

17:45 <MrtnDk[m]> SBCL, CCL and ECL.

17:50 <beach> CL-ASHOK: The logs are indicated in the channel topic.

17:50 <semz> CL-ASHOK, an irc bouncer can do that. alternatively, just read the logs afterwards through one of the links in the topic.

17:52 <CL-ASHOK> thanks both!

17:58 <bendersteed> ye

18:10 <loke[m]> One can also access Freenode via Matrix. That will give you a log as well.

18:10 <loke[m]> I'm using Matrix right now.

18:15 <aeth> you can also run an in-terminal IRC client inside of tmux or screen on a server

18:15 <contrapunctus> CL-ASHOK: I use an XMPP client and a Biboumi instance to stay connected.

18:41 <MrtnDk[m]> <loke[m] "I'm using Matrix right now. "> Me 2😂👍

18:43 <fiddlerwoaroof> Matrix has some issues with generating duplicate messages

18:43 <fiddlerwoaroof> e.g. when you "edit" a message on matrix, it shows up in IRC as a second message

18:56 <MrtnDk[m]> fiddlerwoaroof

18:56 <MrtnDk[m]> It's a fundamental difference. In IRC, you fire an event, for instance "privmsg", and it's distributed to the connected clients via the linked IRC serves. Then that event is done with, and hence cannot be meddled with. Your client might retain the message however. On matrix, it's the servers that keep the history, and the protocol allows for messages to be edited and even deleted. Of cause that won't be effective on the IRC

18:56 <MrtnDk[m]> side.

18:56 <MrtnDk[m]> It's a fundamental difference. In IRC, you fire an event, for instance "privmsg", and it's distributed to the connected clients via the linked IRC serves. Then that event is done with, and hence cannot be meddled with. Your client might retain the message however. On matrix, it's the servers that keep the history, and the protocol allows for messages to be edited and even deleted. Of cause that won't be effective on the IRC

18:56 <MrtnDk[m]> side.

18:59 <MrtnDk[m]> beach Thou mentioned CCL, SBCL and ECL. What about CLISP? How does that compare to the others? (I plan on using Emacs as mentioned, and I'm a beginner/learner).

19:01 <fiddlerwoaroof> MrtnDk[m]: I think CLISP is generally not recommended

19:02 <fiddlerwoaroof> It makes some questionable implementation decisions, from what I remember, and the available releases are all pretty old (although it is actively developed, if your'e willing to build from source)

19:02 <MrtnDk[m]> fiddlerwoaroof I had the feeling, there might be a reason it wasn't mentioned in the first place, but I'm curious as to what the reason is. The description seems pretty promising.

19:02 <beach> MrtnDk[m]: Listen to fiddlerwoaroof and others. I am off for today.

19:02 <fiddlerwoaroof> MrtnDk[m]: yeah, the problem is that when you use Matrix on IRC and make used of the extra functionality, it can be annoying for people still using IRC

19:03 <MrtnDk[m]> "GNU CLISP is a Common Lisp implementation. It conforms to the ANSI Common Lisp standard, and offers many extensions. It runs on all desktop operating systems (GNU and Unix systems, macOS, Windows) and is particularly memory-efficient."

19:03 <MrtnDk[m]> beach beach Ok, take care, have a great Saturday and thank you for the help! 😎👍

19:04 <fiddlerwoaroof> As a rule, I'd prefer sbcl or ccl, especially if you're just getting started

19:05 <aeth> MrtnDk[m]: I mean, just look at the website. Last stable release: 2010-07-07. https://clisp.sourceforge.io/

19:06 <aeth> While the Common Lisp *standard* itself doesn't change over time, plenty of extensions are added to every still-active implementation over time.

19:06 <aeth> Plus, there's generally a space vs speed tradeoff. So "particularly memory-efficient" might imply "particularly slow for Common Lisp implementations". And with CLISP, it does. :-)

19:07 <MrtnDk[m]> aeth Ahh ... thank you. So while it's really good on paper, it kinda sucks for practical use.

19:09 <MrtnDk[m]> I'm guessing for Ubuntu / Raspbian, SBCL or ECL would be the natural choice, and since I don't need embedding at this point, SBCL?

19:09 <fiddlerwoaroof> I'd say SBCL or CCL

19:09 <fiddlerwoaroof> And probably SBCL

19:11 <MrtnDk[m]> CCL doesn't seem to be available, be or is it named differently in Debian?

19:13 <fiddlerwoaroof> Hmm, it doesn't look like its available from the repositories

19:14 <fiddlerwoaroof> Guix has it as ccl

19:15 <aeth> CCL isn't in Fedora's repositories, either. It doesn't seem to be as popular with packagers for whatever reason. Maybe because it started as a Mac-first implementation.

19:15 <fiddlerwoaroof> `guix environment ccl` gives me one that seems to work

19:16 <fiddlerwoaroof> the funny thing about ccl is that it doesn't run on my new Mac :)

19:16 <fiddlerwoaroof> I hope they get a fundraiser going like sbcl did

19:17 <MrtnDk[m]> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609047

19:17 <aeth> I get CCL from Roswell

19:19 <aeth> I might just try building it from the source, though. That's what I do with SBCL these days

19:19 <aeth> I'm still on 2.1.0, though. SBCL itself updates faster than I do.

19:22 <MrtnDk[m]> So, for an "lisp idiot" like me, who cannot tell the difference anyhow, SBCL seems like the goto on Debian based systems .. and perhaps CCL as bonus on systems with Guix (not on my raspberry ATM).

19:23 <aeth> SBCL usually produces the fastest native code.

19:24 <aeth> Note, though, that most CLs bring the whole compile-time environment with them at run-time. Tree shakers exist, but mostly for commercial implementations, and it's actually quite hard to find a substantial number of things that you actually can remove.

19:24 <aeth> So an elaborate compiler also means increased RAM usage (and potentially slower compilation times)

19:25 <aeth> It's an AOT compiler, though, so it's not going to have the startup time cost of the JIT compilers that you're thinking of unless there's no preexisting FASL.

19:26 <fiddlerwoaroof> I just added anti-aliasing to my toy raytracer, now it takes about a second per row :(

19:26 <MrtnDk[m]> ʘ‿ʘ FASL?

19:26 <fiddlerwoaroof> FASt Load file

19:27 <fiddlerwoaroof> If you've used python it's roughly equivalent to the .pyc files

19:28 <aeth> Except that most CLs are native code compilers rather than bytecode (CLISP is bytecode, though)

19:28 <aeth> So it's sort of like if you had to compile a C file on first run instead of using precompiled binaries. Except CL compilers are much, much faster than C compilers and especially C++ compilers.

19:31 <aeth> MrtnDk[m]: FASL is the generic term, but most have a variation of that instead of "FASL". SBCL does use .fasl, though.

19:32 <MrtnDk[m]> I found this link for unofficial CCL for Debian. The webpage is not from yesterday though: https://mr.gy/blog/clozure-cl-deb.html

19:33 <fiddlerwoaroof> Building CCL from source isn't hard, if CCL already supports your hardware

19:33 <fiddlerwoaroof> However, it sounds to me like you should just use sbcl

19:34 <fiddlerwoaroof> Writing lisp is a lot more fun than researching implementations :)

19:35 <fiddlerwoaroof> I think I'm going to need to implement a threadpool for this raytracer

19:35 <fiddlerwoaroof> 10 minutes for 1024x768 is too slow, even for a toy :)

20:07 <MrtnDk[m]> fiddlerwoaroof: I played a little with LOGO on my home computer back in the day. I liked how I could draw real time: Goto x,y ; pendown; move to x2,y2 ; turn 120 ;;; etc. Can you something like that in lisp?

20:20 <_death> MrtnDk[m]: sure.. mpv https://adeht.org/dump/vid-2021-03-20T2217.mp4

21:31 <zalitis> Hi! Could someone please help me understand an issue with nested lists and setf? I'm trying to set the value for just one element in a nested list structure but, for some reason, multiple elements get affected. Here's some code:

21:31 <zalitis> LISP> *my-list*

21:31 <zalitis> (((150.0 0.0 30 0 1 1) (-150.0 -1.3113417e-5 30 0 1 1))

21:31 <zalitis> ((150.0 0.0 30 0 1 1) (-150.0 -1.3113417e-5 30 0 1 1))

21:31 <zalitis> ((150.0 0.0 30 0 1 1) (-150.0 -1.3113417e-5 30 0 1 1)))

21:31 <zalitis> LISP> (elt (elt (elt *my-list* 0) 0) 5)

21:31 <zalitis> 1 (1 bit, #x1, #o1, #b1)

21:31 <zalitis> LISP> (setf (elt (elt (elt *my-list* 0) 0) 5) 3)

21:31 <zalitis> 3 (2 bits, #x3, #o3, #b11)

21:31 <zalitis> LISP> *my-list*

21:31 <zalitis> (((150.0 0.0 30 0 1 3) (-150.0 -1.3113417e-5 30 0 1 3))

21:31 <zalitis> ((150.0 0.0 30 0 1 3) (-150.0 -1.3113417e-5 30 0 1 3))

21:31 <zalitis> ((150.0 0.0 30 0 1 3) (-150.0 -1.3113417e-5 30 0 1 3)))

21:31 <zalitis> LISP>

21:34 <zalitis> This happens when using SBCL with SLY.

21:34 <Josh_2> next time can you use a paste service

21:34 <_death> use a pastebin next time.. the issue is that you have the same object referenced multiple times in the list

21:34 <zalitis> Oops, sorry

21:40 <MrtnDk[m]> Josh_2 Maybe he can use #Flood if it's still around?

21:44 <zalitis> The way I constructed *my-list* was to push the same thing to it four times. Is there any way I could make sure that each element ends up as a unique object, even if the values are the same?

21:45 <_death> copy-list

21:46 <_death> or if each item is a nested list, copy-tree.. in general, you can write your own copy operation

21:49 <zalitis> copy-tree did the trick. Thanks a lot!