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/>
waleee has quit [Ping timeout: 256 seconds]
waleee has joined #commonlisp
waleee has quit [Ping timeout: 240 seconds]
lisper29 has joined #commonlisp
calamarium has joined #commonlisp
fitzsim has joined #commonlisp
lisper29 has quit [Quit: Leaving]
puke has quit [Ping timeout: 268 seconds]
yitzi has quit [Remote host closed the connection]
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 268 seconds]
sailorCat has quit [Ping timeout: 252 seconds]
theruran has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
NotThatRPG has joined #commonlisp
CrashTestDummy has joined #commonlisp
sailorCat has joined #commonlisp
istewart has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jon_atack has quit [Ping timeout: 256 seconds]
jonatack has joined #commonlisp
istewart has quit [Remote host closed the connection]
chomwitt has quit [Ping timeout: 268 seconds]
istewart has joined #commonlisp
molson_ has quit [Remote host closed the connection]
molson has joined #commonlisp
jonatack has quit [Ping timeout: 264 seconds]
jonatack has joined #commonlisp
rtypo has quit [Ping timeout: 268 seconds]
thonkpod_ has quit [Ping timeout: 264 seconds]
thonkpod_ has joined #commonlisp
HER is now known as hernan
hernan is now known as hernan604
hernan604 is now known as HER
jonatack has quit [Ping timeout: 264 seconds]
jonatack has joined #commonlisp
decweb has quit [Ping timeout: 256 seconds]
istewart has quit [Quit: Konversation terminated!]
wacki has joined #commonlisp
wbooze has quit [Remote host closed the connection]
wbooze has joined #commonlisp
random-nick has joined #commonlisp
cmack has quit [Ping timeout: 255 seconds]
cmack has joined #commonlisp
Posterdati has quit [Remote host closed the connection]
chomwitt has joined #commonlisp
Posterdati has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Pixel_Outlaw has quit [Quit: Leaving]
awlygj has joined #commonlisp
sailorCat has quit [Ping timeout: 252 seconds]
sailorCat has joined #commonlisp
Th30n has joined #commonlisp
pve has joined #commonlisp
skeemer has quit [Ping timeout: 240 seconds]
dino_tutter has joined #commonlisp
shka has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
brokkoli_origin has quit [Ping timeout: 264 seconds]
attila_lendvai has joined #commonlisp
donleo has joined #commonlisp
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
semarie has quit [Quit: WeeChat 4.3.2]
semarie has joined #commonlisp
chomwitt has quit [Ping timeout: 268 seconds]
chomwitt has joined #commonlisp
chomwitt has quit [Ping timeout: 268 seconds]
mgl_ has joined #commonlisp
brokkoli_origin has joined #commonlisp
X-Scale has joined #commonlisp
X-Scale has quit [Client Quit]
rtypo has joined #commonlisp
sl1ght has joined #commonlisp
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
X-Scale has joined #commonlisp
mwnaylor has quit [Ping timeout: 268 seconds]
cognemo has quit [Ping timeout: 268 seconds]
cognemo has joined #commonlisp
Th30n has quit [Ping timeout: 256 seconds]
mwnaylor has joined #commonlisp
wacki has quit [Ping timeout: 252 seconds]
wacki has joined #commonlisp
X-Scale has quit [Ping timeout: 250 seconds]
mwnaylor has quit [Ping timeout: 268 seconds]
X-Scale has joined #commonlisp
danse-nr3 has quit [Ping timeout: 264 seconds]
cognemo has quit [Ping timeout: 246 seconds]
cognemo has joined #commonlisp
cognemo has quit [Ping timeout: 255 seconds]
X-Scale has quit [Ping timeout: 250 seconds]
Gleefre has joined #commonlisp
calamarium has quit [Remote host closed the connection]
varjag has joined #commonlisp
synchromesh has quit [Read error: Connection reset by peer]
synchromesh has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
King_julian has joined #commonlisp
cognemo has joined #commonlisp
yitzi has joined #commonlisp
Th30n has joined #commonlisp
X-Scale has joined #commonlisp
oneeyedalien has joined #commonlisp
danse-nr3 has joined #commonlisp
X-Scale has quit [Ping timeout: 250 seconds]
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
wacki has joined #commonlisp
puke has joined #commonlisp
hexa6`` is now known as hexa6
King_julian has quit [Ping timeout: 268 seconds]
oneeyedalien has quit [Quit: Leaving]
FragmentedCurve_ has joined #commonlisp
King_julian has joined #commonlisp
FragmentedCurve has quit [Quit: Leaving]
FragmentedCurve_ has quit [Client Quit]
FragmentedCurve has joined #commonlisp
cage has joined #commonlisp
yitzi has quit [Remote host closed the connection]
shawnw has quit [Quit: Konversation terminated!]
Gleefre has joined #commonlisp
fitzsim has quit [Ping timeout: 256 seconds]
decweb has joined #commonlisp
<Gleefre> If anyone is interested, I have updated & repasted my old portability test for MACROEXPAND-ALL (which I accidentally deleted from plaster): https://plaster.tymoon.eu/view/4452#4452
<Gleefre> A few interesting things: (1) trivial-macroexpand-all doesn't provide the lexenv argument where it is possible to on Allegro, Lispworks, CormanCL and MKCL. (And so does swank, which seems to have been source for trivial-macroexpand-all)
<Gleefre> (2) I found a new type of bug: some implementations inaccurately remove MACROLET/SYMBOL-MACROLET, not handling declarations inside correctly.
<beach> Gleefre: So these are versions of "native" MACROEXPAND-ALL supplied by each Common Lisp implementation?
wbooze has quit [Remote host closed the connection]
<Gleefre> Yeah, something like that
<beach> I see.
danse-nr3 has quit [Ping timeout: 256 seconds]
wbooze has joined #commonlisp
<Gleefre> One sad thing about Allegro's & Lispworks's versions is that I wasn't able to find any documentation on them; although it might not just be available online or I didn't search in the right place / for correct words.
<Gleefre> I found them through wrappers in swank & trivial-macroexpand-all, but that's it.
<cdegroot> dbotton: time for four million checkboxes in CLOG ;-)? https://twomillioncheckboxes.com/ (I have no clue where this is coming from, someone built a one million checkboxes site and now people seem to be showing off stacks this way?)
<ixelp> Two Million Checkboxes
<dbotton> certainly doable lol
<dbotton> and in a few lines of code
X-Scale has joined #commonlisp
NotThatRPG has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.3]
<dbotton> Here is a chat app in a few lines of code https://github.com/rabbibotton/clog/blob/main/demos/02-demo.lisp
<ixelp> clog/demos/02-demo.lisp at main · rabbibotton/clog · GitHub
<dbotton> (I need to update the code to be simpler, soon)
<gilberth> Gleefre: The tricky part is macroexpand-all respecting a given lexical environment. Are you aware of <http://clim.rocks/gilbert/meall.lisp> which implements this for many implementations. Actually the CLtL2 ENCLOSE would suffice to implement this. You may want to include that implementation as well.
<gilberth> What I'm after is a reliable macroexpand-all that you can actually use in macro. It should be possible to just macroexpand-all a given body and get about the same code generated by the compiler. Insofar I found most implementations of macroexpand-all provided by implementatins unreliable as usually they are written as an afterthought and don't share too much with the compiler.
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<gilberth> I once tested this meall.lisp with some large code body and compared the resulting binary code. Once subjecting everything to it and once not doing that. It turned out that with CCL e.g. OR really is a special operator. The compiler is too stupid to compile the expansion of OR to equivalent code.
<gilberth> Anyhow, in the end of day I want to be able to actually walk code. Reliable. From within any macro. So far I'm not aware of any other about portable implementation.
<gilberth> The trick of meall.lisp is that I ask the compiler to construct new lexical environments or figure out declarations.
X-Scale has quit [Ping timeout: 250 seconds]
<Gleefre> gilberth: Interesting! I'm not sure how well can I test it though, as I only have simple test cases - and they won't catch implementation-specific problems. The idea was to test implementation-provided macroexpand, after all.
mgl_ has quit [Ping timeout: 264 seconds]
zxcvz has joined #commonlisp
<Gleefre> While it works on SBCL, dunno if there are any hidden problems. That's not mentioning depending on hacks, which sadly are indeed necessary :(
<gilberth> Gleefre: Well, as you can see I abandoned all hope to use the implementation provided ones.
rtypo has quit [Ping timeout: 252 seconds]
X-Scale has joined #commonlisp
King_julian has quit [Ping timeout: 264 seconds]
zxcvz has quit [Client Quit]
<gilberth> Surprisingly, my approach would have been portable if ENCLOSE would be have been standard. I still would prefer when COMPILE or EVAL would take an environment argument.
<gilberth> I know that ccl:macroexpand-all has bugs. I only would need to recall them.
rtypo has joined #commonlisp
<Gleefre> gilberth: one could try fixing implementations instead, dunno.
Th30n has quit [Ping timeout: 252 seconds]
<Gleefre> Also, since an implementation is allowed to add additional special forms, is it really possible to make a portable code-walker? It'd need to know how to walk special forms after all.
wbooze has quit [Ping timeout: 268 seconds]
<gilberth> There are different use cases though. I'm interested in being able to reason and transform code. In the context of an IDE though, do you really want to see MULTIPLE-VALUE-BIND, PROG1, or even DESTRUCTURING-BIND expanded? When you're about to debug your macros or ponder what some macros of some lib do?
<gilberth> Gleefre: As I said, macroexpand-all in implementations often is an after thought and implemented separately from the compiler. I will never trust those to be in sync with what the compiler does.
<gilberth> Gleefre: Sure, there are implementation defined special operators. They are trivial to add with my approach. For macro expansion at least. I have not yet given a code walker protocol a thought.
shka has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
<gilberth> Heh, the most common is some named LAMBDA. Whenever I see those I wonder why nobody came up with saying e.g. (lambda (x) (declare (function-name inc)) (+ x 1)) instead.
<Gleefre> By the way, tested meall.lisp on sbcl/ccl/clisp/ecl/acl/abcl; and it seems to be broken on ECL.
yitzi has joined #commonlisp
<gilberth> On ECL? Do you have a test case I can look at?
ryanbw has quit [Ping timeout: 268 seconds]
mgl_ has joined #commonlisp
<Gleefre> Just anything like (meall:macroexpand-all '(lambda ())) or (meall:macroexpand-all '(defun foo ()))
<gilberth> Huh? /me goes about to test.
<Gleefre> Might be a version mismatch, I have 23.9.9 fwfw
<gilberth> I see. I trip on ext:lambda-block which must be one of those implementation defined special forms :(
fitzsim has joined #commonlisp
<gilberth> Oh there is debugging PRINTs left in meall.lisp :(
<Gleefre> That's a problem with hacks :( Implementations change over time, and your code gets destroyed. When implementation provides macroexpand-all, it won't get completely broken because of small change; and there is no need to track versions if that happens, e.t.c.
<gilberth> Must be one of those named functions. I get #'(ext:lambda-block ...)
<gilberth> That's new: Extended function name syntax.
<gilberth> Gleefre: Special forms are not added that often. And I would need to handle those anyway, even if the implementation defined macroexpand-all would work. I mean, that implementation defined macroexpand-all would yield me that funny special form fine, and then? And when a new special form is added I won't trust implementations getting their neglected macroexpand-all fixed.
<Gleefre> I don't think you want to analyze the code returned by macroexpand-all when using it in a macro.
<gilberth> I do want. But why would I expand the code in the first place?
<Gleefre> If there is a chance of getting an implementation-specific special form in the result, you are probably already going to a get (a lot of) implementation-specific stuff, and even if it's just function calls, you can't really process those.
lucasta has joined #commonlisp
<Gleefre> I personally am interested in using macroexpand-all for the side effects; although I'm not sure if it has any benefits.
ryanbw has joined #commonlisp
<Gleefre> re: trusting implementations getting macroexpand-all fixed -- well, one might go fix it himself, I guess, unless it is a closed-source implementation. If it is, I personally wouldn't care much I guess.
<gilberth> Gleefre: Anyhow. I teached this superfluous ext:lambda-block to meall.lisp.
<gilberth> What I'm after is some type inteferrence. Or telling whether a variables is used at all or some operation is invoked at all.
<Gleefre> Well, in this case macroexpand-all is not the right tool I guess; but a full-fledged code-walker... I had never really used any of those though.
<gilberth> And I'd like to have it for noffi. It's depressing that when you say (let ((x (foo))) (bar-macro x)) the BAR-MACRO cannot tell that X is the result of FOO. And thus doesn't know anything about the type. It doesn't help either that in CL you cannot define new types of types.
<gilberth> Gleefre: Expanding macros is the first step a code walker has to take. And I need to come up with code. Hence, the very first step is to have something that works with transformations applied.
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
<gilberth> And pure walking is not sufficient. I would need to run a whole bunch of classic dataflow analysis on the code in my case.
<Gleefre> Sounds reasonable, yeah.
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
<gilberth> Anyhow, I just wanted to point to that trick of mine to use the compiler of the Lisp implementation to construct derived lexical environments and deal with DECLARE. The two things that you cannot otherwise do yourself. Custom special forms pose an only very minor problem in comparision.
NotThatRPG has quit [Ping timeout: 268 seconds]
<gilberth> I mean, you can't even tell whether (declare (foo x)) is a FOO declaration or a type declaration. And once you try by digging up implementation defined functions to query FOO for being a type you recognize that those [internal] interfaces are broken as well. SBCL e.g. fails to report some declarations as declarations (in the (DECLAIM (DECLARATION FOO)) sense.
<Gleefre> I wonder if you could get away with a custom "let" (binding macro) & "messaging" via macrolet/symbol-macrolet in yours example.. Although it wouldn't be as nice to use as the plain let, I guess.
NotThatRPG has joined #commonlisp
<gilberth> I am about to do that. But it has its limits.
<gilberth> The broader aspect is that I learned that CL is missing building blocks to implement DSL that can be seamlessly integrated and that usually anything around the infrastructure needed is fragile at best even if you find implementation defined interfaces like that macroexpand-all or the CLtL2 API which too often is broken beyond repair.
<bike> work needs doing, for sure
<gilberth> Like e.g my comment "No luck with SBCL. It hides type information both with SB-CLTL2:VARIABLE-INFORMATION and SB-WALKER::ENV-VAR-TYPE" in meall.lisp.
<gilberth> The package prefix says it all. It should have been the compiler package.
* Gleefre is currently reading sbcl source code because of that comment
<bike> i think the problem with that is that, as you mentioned, compilers don't actually want to do this analysis on the source level because doing it on the source level sucks
<gilberth> bike: Still, their lexical environments must have that information. I see to problem rather in that any CLtL2ish lexical environment access is written as an afterthought just to be able to claim to have it while not really caring about it.
<bike> oh, i certainly agree
<craigbro> peanut gallery comment: sounds like nim macros, where static type information is available to them (and to the runtime in general)
<bike> the problem there i suppose is that the cltl2 accessors aren't actually very... good? like you don't want to write a compiler in terms of those, it would be messy
<gilberth> SBCL e.g. fails to report some declaration (in (declaim (declaration foo)) with the CLtL2 interface. I looked at the code, it turned out that handling those implementation defined declarations is some CASE keys in the compiler and SB-CLTL2 is not aware of those. No shared code at all. Not even close in the source.
X-Scale has quit [Ping timeout: 250 seconds]
<gilberth> Long story short: I tried to actually implement a new declaration and was not able to make it work.
<bike> and also there's just not very many people doing what you're doing, so the extensions are sorta neglected
<bike> which of course turns into a vicious cycle
<gilberth> Indeed.
<bike> trucler is closer to what a compiler might actually want, and i've written a compiler with it and it's fine, but it has even less implementation buy-in than cltl2 at the moment
wbooze has joined #commonlisp
Inline has joined #commonlisp
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
danse-nr3 has joined #commonlisp
X-Scale has joined #commonlisp
<beach> bike: It does, but I suggested using CLtL2 as a "default" for the implementations that are currently not supported by Trucler. That way, new native support can be added incrementally. And I tried asking gilberth for help with support for one Common Lisp implementation, but he declined, apparently because it wouldn't solve a more difficult problem that he has.
<beach> And paulapatience has agreed to add CLtL2 support in Trucler.
<yitzi> bike: I can do an implementation for Trucler at some point.
<beach> yitzi: Do you mean to add support for some Common Lisp implementation to Trucler? That would be great!
<yitzi> Yes. I think it has CCL and SBCL right now, so I can do ABCL, Clasp or ECL at some point.
<beach> Oh? Who provided CCL?
<yitzi> bike might be better for Clasp, so maybe ABCL?
<yitzi> marco added CCL initially
<beach> Hmm. OK.
<beach> Maybe ECL is more widely used than ABCL? Just guessing.
<yitzi> Adding Clasp and ECL will probably be related. ABCL will be very different.
<beach> Sounds right.
X-Scale85 has joined #commonlisp
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale85 has quit [Ping timeout: 250 seconds]
X-Scale has joined #commonlisp
edgar-rft_ has joined #commonlisp
X-Scale has quit [Ping timeout: 250 seconds]
cage has joined #commonlisp
edgar-rft has quit [Ping timeout: 255 seconds]
danse-nr3 has quit [Remote host closed the connection]
<skin> What about LispWorks or Medley?
<beach> For Trucler? I understand Medley is not yet very conforming, but the commercial Common Lisp implementations would be good to support.
<yitzi> Medly doesn't have a conforming LOOP, can't load ASDF, etc. There are other issues as I recall. I don't believe they can make it through ansi-test.
<paulapatience> I'm in the process of adding the augmentation methods to SBCL. For CCL I don't understand enough of how it works.
<paulapatience> (For Trucler)
<paulapatience> They're not important for an initial implementation though. I only started adding them because Cleavir needs them.
X-Scale has joined #commonlisp
danse-nr3 has joined #commonlisp
<beach> Oh, so heisig wrote the query methods for CCL but not the augmentation methods.
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
<beach> ... and that's what I asked gilberth for help with.
<paulapatience> Yes, and the augmentation methods were also missing for SBCL
<paulapatience> Technically still are
<beach> I see.
Lord_Nightmare has joined #commonlisp
<yitzi> paulapatience: Can I push some tweaks to liebler?
<yitzi> Sorry wrong channel
edgar-rft_ is now known as edgar-rft
X-Scale has quit [Ping timeout: 250 seconds]
zetef has joined #commonlisp
zetef has quit [Client Quit]
mon_key_phn has joined #commonlisp
rainthree has joined #commonlisp
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
wacki has joined #commonlisp
rainthree has quit [Ping timeout: 256 seconds]
Lord_of_Life has quit [Ping timeout: 252 seconds]
Lord_of_Life has joined #commonlisp
awlygj has quit [Quit: leaving]
mgl_ has quit [Ping timeout: 264 seconds]
mgl_ has joined #commonlisp
<craigbro> I am trying to debug an ASDF configuration, and I'm looking for some way to trace it's search for a .asd file
mgl_ has quit [Ping timeout: 256 seconds]
<masinter> yitzi I added a (98%) conforming LOOP last month
<craigbro> I have looked at asdf:*default-source-registries* and when enumerating the values, I see that it is looking in the appropriate place for my configuration files
<yitzi> masinter: tested against ansi-test?
<yitzi> masinter: And, if Medley had good CLOS and ASDF it might able to benefit from some of the s-expressionists systems like Khazern (LOOP), Invravina (pretty-printer), etc.
<craigbro> I'm trying to add a project directory as a :tree, so I have (:tree (:home "project/)) in .config/common-lisp/source-registry.conf.d/project.conf
<craigbro> with the right amount of "s hehe
<masinter> yitzi alas, ansi-test, "good CLOS" are both a stretch, and asdf will require some tooling -- there are things that are easy when you are doing text-file development and can edit the package definition and reload... harder when you want to manipulate the package definition without reloading
<yitzi> ok, well I understand it is an uphill climb. Well done on improving your LOOP.
jrx has joined #commonlisp
X-Scale has joined #commonlisp
jrx has quit [Remote host closed the connection]
<yitzi> Did you write it from scratch or is it based on MIT LOOP?
<masinter> I used a portable LOOP implementation from somewhere, but I don't have access to the source. That URL is the Medley import -- SACL?
<masinter> ("Yuji Minejima <ggb01164@nifty.ne.jp>")
<ixelp> Yuji Minejima's Sacla project page
<masinter> I didn't have to change much
<masinter> the hash table and package iterators are different and there was some fiddling to get package definitions that work in the Medley context, and at least one bug
<yitzi> masinter: Did you see the like I posted. Its probably where your loop originated
<yitzi> s/like/link/
<masinter> yitzi yes, that's the one i started with.... .
<yitzi> Cool.
<masinter> the release with it included was last month -- online.interlisp.org has it
mgl_ has joined #commonlisp
yitzi has quit [Remote host closed the connection]
X-Scale has quit [Ping timeout: 250 seconds]
mon_key_phn has quit [Quit: Connection closed for inactivity]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
X-Scale has joined #commonlisp
<ixelp> Mesh Morphs by Shinmera · Pull Request #78 · Shirakumo/trial · GitHub
<Shinmera> whoops wrong link. That one shows my descent into madness
<ixelp> Yukari Hafner: "mesh morphs are FINALLY working in trial. (the sw…" - TyNET
<craigbro> wrt my issues with asdf config one nixos, I just cheated and added the directories I wanted to scan for .asd files to the ql:*local-project-directories* ...
yitzi has joined #commonlisp
mgl_ has quit [Ping timeout: 268 seconds]
NotThatRPG has joined #commonlisp
NotThatRPG has quit [Client Quit]
cage has quit [Quit: rcirc on GNU Emacs 29.3]
X-Scale has quit [Ping timeout: 250 seconds]
pve has quit [Quit: leaving]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
mwnaylor has joined #commonlisp
shawnw has joined #commonlisp
yitzi has quit [Remote host closed the connection]
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
wacki has joined #commonlisp
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
wbooze has quit [Remote host closed the connection]
Inline has quit [Quit: Leaving]
wbooze has joined #commonlisp
skeemer has joined #commonlisp
NotThatRPG has joined #commonlisp
wacki has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
shka has quit [Quit: Konversation terminated!]
yitzi has joined #commonlisp
dino_tutter has quit [Ping timeout: 268 seconds]
amb007 has quit [Ping timeout: 268 seconds]
NotThatRPG has quit [Ping timeout: 260 seconds]
calamarium has joined #commonlisp
NotThatRPG has joined #commonlisp
<calamarium> I have a function that executes successfully but returns the wrong output. I'm used to using edebug-defun in Elisp to step through a function and set breakpoints to identify the problem. What's the idiomatic way to do this in Common Lisp? (using sbcl and sly if that matters)
sl1ght has quit [Ping timeout: 272 seconds]
<thuna`> CLOSE on a synonym stream doesn't close the stream it points to, but what about with the ABORT argument?
thuna` has quit [Remote host closed the connection]
<gilberth> What about it?
<gilberth> I mean what of the effects of making the synonym stream should be tried to be undone?
<yitzi> Can you give a spec reference for CLOSE being a NOP on synonym streams?
<gilberth> https://novaspec.org/cl/f_close It says "The effect of close on a constructed stream is to close the argument stream only." Following the link "constructed stream" gives "constructed stream n. a stream whose source or sink is a Lisp object. Note that since a stream is another Lisp object, composite streams are considered constructed streams." Follow that gives ...
<ixelp> close | Common Lisp Nova Spec
<gilberth> ... "composite stream n. a stream that is composed of one or more other streams. “make-synonym-stream creates a composite stream.”
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
donleo has quit [Ping timeout: 264 seconds]
<yitzi> Well, I guess under that I would interpret that abort non-NIL passed to the synonym stream close only aborts operations that synonym stream has not finished passing to the synonym.
<gilberth> And it isn't exactly a NOP. The composite stream itself still is closed.
<yitzi> If there was such a thing as a buffered synonym stream
<gilberth> Yes.
Gleefre has quit [Ping timeout: 250 seconds]
<gilberth> Oh. SBCL is buggy then. And so are CLISP and ABCL. CCL's and ECL's author have read the spec. Hmm.
<masinter> make a cleanup committee ISSUE and submitit it to X3J13 ...oh wait ...
<gilberth> Cleanup about what? The spec is fine IMHO.
<gilberth> At least with the CLOSE dictionary entry to be precise.
Gleefre has joined #commonlisp
<gilberth> Meanwhile, I still want a better solution for the Novaspec. Half the information of any given dictionary entry is in the glossary. And some albeit few glossary terms actually have some place in the spec itself where it is defined.
<masinter> thiere is now a better spec thanCLHS?
<gilberth> Yes, there is. https://novaspec.org/cl/
<ixelp> Common Lisp Nova Spec
<masinter> I added to Medley's HELPSYS (for looking up in the Interlisp Reference Manual) that it now looks up common lisp symbols in the CLHS. I could add NoaSpec as an option
<gilberth> The machine readable index is at https://novaspec.org/cl/apropos.js