pranavats has left #commonlisp [Disconnected: Hibernating too long]
karlosz has joined #commonlisp
<beach>
I think I use only the public interface for traversing ASDF systems in SICL.
<mfiano>
How do you deal with feature component expressions, and other things that aren't system designators in themselves?
<beach>
grep for asdf: in Code/Boot/*
<beach>
I guess I probably don't handle everything you need.
<mfiano>
Ok, thanks anyway. I really just need to be able to walk the graph and collect a list of system names. Here I'm loading the systems as I traverse them, but it is just an example.
<beach>
I am pretty sure I do that.
<beach>
(asdf:system-depends-on <system>)
<mfiano>
Inspecting, thanks.
<beach>
Sure.
<mfiano>
This would have the same problem with bordeaux-threads, if it were to loop over defsystem-depends-on also.
<mfiano>
THe problem is FIND-SYSTEM cannot take as input results from these 2 accessors directly
<mfiano>
FIND-SYSTEM expects a system designator, whereas dependencies are component designators
<ixelp>
SICL/asdf-programming.lisp at master · robert-strandh/SICL · GitHub
<beach>
I saw no mention about threads, so I didn't take that into account.
<beach>
There is also some code in utilities.lisp.
<mfiano>
Ok, thanks anyway. I am not impressed with a lot about ASDF after spending the last two weeks trying to understand the more complicated parts for an application I'm researching.
<mfiano>
In utilities.lisp, it seems you skip right over conses there, essentially what I was thinking of changing mine to be, but was wondering was implications that might have for some of the systems out there in the wild.
<mfiano>
Line 193 I'm referring to
<beach>
I am not trying to find a general solution. Just enough for SICL bootstrapping to work.
<ixelp>
staple/toolkit.lisp at master · Shinmera/staple · GitHub
<mfiano>
Yes, of course. And the same for me. I guess I could manually verify them to see if I need them, but in 2 years I will not know why it broke when some transitive dependency decides to do that.
<Shinmera>
I use the who-uses-symbol function quite frequently when I find something that's not exported from the package I see the symbol in.
<easye>
Nice code Shinmera
<mfiano>
Nice
<mfiano>
Shinmera: A second pair of eyes really helps me some times. I was digging through ASDF all day yesterday and missed this. Works for my needs beautifully. Thanks again!
lucasta has quit [Remote host closed the connection]
karlosz has joined #commonlisp
Alfr has quit [Quit: Leaving]
Alfr has joined #commonlisp
tyson2 has joined #commonlisp
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
Cymew has joined #commonlisp
random-nick has joined #commonlisp
Cymew has quit [Ping timeout: 240 seconds]
jmdaemon has quit [Ping timeout: 246 seconds]
karlosz has quit [Quit: karlosz]
overclucker has quit [Ping timeout: 248 seconds]
xaltsc has quit [Quit: WeeChat 3.7.1]
Gleefre has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
karlosz has joined #commonlisp
masinter has quit [Remote host closed the connection]
haoms has joined #commonlisp
haoms has left #commonlisp [#commonlisp]
karlosz has quit [Quit: karlosz]
NotThatRPG has quit [Ping timeout: 260 seconds]
overclucker has joined #commonlisp
NotThatRPG has joined #commonlisp
anticomputer_ has joined #commonlisp
anticomputer has quit [Ping timeout: 240 seconds]
Cymew has joined #commonlisp
karlosz has joined #commonlisp
Cymew has quit [Ping timeout: 276 seconds]
karlosz has quit [Quit: karlosz]
Cymew has joined #commonlisp
edgar-rft has quit [Quit: Leaving]
<Shinmera>
Sure wish COERCE was extensible via a COERCE-OBJECT generic function.
splatt990 has quit [Quit: Gateway shutdown]
<phoe>
NotThatRPG: regarding #34 on Alexandria, AFAIK SUBTYPEP is supposed to always work on standard simple types, so (subtypep 'list '(or null cons)) should result in T T
<beach>
phoe: Did you tell me when you created Ecclesia? You may have, and I forgot, but it doesn't ring a bell.
<beach>
phoe: And, do you have any future plans for it?
<Alfr>
phoe, don't think it does, when OR is involved.
<phoe>
beach: git says Nov 22 2020
<phoe>
that repo should be deleted though since it's never been maintained past that point, unless you have some plans for it
<phoe>
I don't
<beach>
phoe: Right. I mean, did you ever make me aware of creating it?
<phoe>
oh, that; I don't recall, probably did back when we talked about it
<beach>
OK.
<phoe>
but then maybe we never talked about it later on
<beach>
Yes, it should probably be removed.
<beach>
But it is always hard to know what code is used.
<phoe>
Alfr: yes, you are correct, I reread CLHS SUBTYPEP
<Shinmera>
I knew you were going to post something exactly as fucking pointless as that.
<phoe>
beach: I vote for deleting it then but I don't think I have the necessary repo permissions at s-expressionists
<Shinmera>
Please going forward don't bother replying to me, thanks.
<yitzi>
Could also archive it
<beach>
phoe: OK. I guess there is no harm in deleting it. If it turns out it is used, it can easily be re-created from Cleavir.
<beach>
yitzi: Is that a GitHub thing?
<phoe>
beach: yes
<yitzi>
Yes.
<beach>
Good plan. I'll investigate.
<phoe>
Bike: afaik you have admin access to s-expressionists on github, could you archive https://github.com/s-expressionists/Ecclesia and change the repo description to point to cleavir?
<ixelp>
GitHub - s-expressionists/Ecclesia: Utilities for parsing Lisp code - previously known as cleavir-code-utilities
<phoe>
Shinmera: is it possible for COERCE to get extended like that without breaking the spec? if it was the case then maybe a SBCL patch would work and pave the way for other implementations to follow
<phoe>
clhs coerce
<yitzi>
beach: Its on the "settings" -> "General" at the very bottom of the page.
<phoe>
there seems to be nothing about implementation-defined coercions in there
<phoe>
nothing that allows them... but nothing that forbids them either
<semz>
especially due to the "All the following forms should signal an error" part
<phoe>
semz: that part is about something else though
<semz>
examples are technically not normative either way
<phoe>
these are all about situations like attempting to coerce "foo" into a string of length 2
<phoe>
so, sequence length mismatches
<yitzi>
I have also wished for an extensible coerce.
<phoe>
so have I
<Shinmera>
1.6 says An implementation can have extensions, provided they do not alter the behavior of conforming code and provided they are not explicitly prohibited by this standard.
<yitzi>
Although, would a generic be enough since types are involved? Would one need a dispatch table like pprint?
<phoe>
well, conforming code will not have (defclass my-type ...) and then (coerce x 'my-type)
jon_atack has quit [Ping timeout: 240 seconds]
jon_atack has joined #commonlisp
<Shinmera>
yitzi: I personally don't care about coercing to more complex type descriptors, and would instead use additional keyword arguments to control the coercion as necessary.
<yitzi>
ok
<Shinmera>
There seems to be a trivial-coerce library, but it has dependencies that make it far from trivial.
<Shinmera>
And it also doesn't integrate with the existing coerce, which is what I'm interested in in the first place.
<phoe>
you'd need (coerce object type &key ...) then, though
<phoe>
or do you have another idea?
<Shinmera>
sure.
<beach>
For what it's worth, SICL COERCE trampolines to a generic version, using CTYPE to canonicalize the type.
<Shinmera>
iirc the implementation can add more optional/key args, no?
pkal has quit [Remote host closed the connection]
<phoe>
yes, it seems so
pkal has joined #commonlisp
<phoe>
on SBCL, CL:APROPOS has an extra &optional arg and CL:MAKE-HASH-TABLE has extra keys
<Alfr>
Shinmera, don't think so, see safe call in 3.5.1.3 .
<phoe>
but I have no idea about adding a whole new &OPTIONAL where it didn't exist
<Shinmera>
Alfr: that doesn't say anything about whether an implementation can extend the arglist or not.
<Alfr>
But a program could depend on such an error being signaled ...
* Alfr
runs away and hides.
<Shinmera>
So?
<phoe>
one could argue that such a program deserves to get broken
* phoe
runs away and hides too
<Shinmera>
That section only says that an error must be signalled if you call it wrong. It says nothing about whether the arglist must be exactly as specified.
<Bike>
adding keyword parameters to standard functions is already done in several implementations. i don't think the standard explicitly allows it, but it doesn't disallow it, and if i remember correctly the pages on a few functions do mention implementaiton extensions
<Shinmera>
That's what I recall, too
<edwlan[m]>
but (handler-case (coerce a b c) (program-error () “error”)) is conforming code and implementation extensions can’t change the behavior of conforming code
<Bike>
"If an implementation supports additional keyword arguments to compile-file, compile-file-pathname must accept the same arguments." says compile-file-pathname.
<Alfr>
Shinmera, yes, e.g. ... (handler-bind ((program-error ..)) .. (coerce foo bar baz) 'we-never-get-here)
<Bike>
again, i don't think there is anything ruling out the lambda list for a standard function being extended.
<Bike>
the program-error stuff has to work if the extended lambda list is violated, but that's different.
<Shinmera>
edwlan[m]: again, it is not clear that this is actually conforming code that you wrote
<Shinmera>
because section 3513 only talks about lambda list mismatch, not whether the list must be implemented exactly as specified.
<Bike>
also, making a program rely on that behavior like that would be kind of stupid, informally speaking
<edwlan[m]>
That’s true
<edwlan[m]>
But the standard’s definition of allowable extensions seems to be designed so that you can’t observe the extensions if you’re writing code against the specified behavior of the language
<Bike>
implementations _are_ explicitly banned from adding extra return values, in 1.6, presumably because it could break multiple-value-call forms in confusing ways
<Bike>
actually definitely because of that, looking at the xj issue
<Shinmera>
edwlan[m]: "observable" is pretty vague, and could potentially prohibit literally anything unspecified
<edwlan[m]>
Yeah, that’s my concern about 1.6
Krystof has quit [Ping timeout: 268 seconds]
<Shinmera>
It's not worth worrying about it, because it would be useless to read it that way.
<Bike>
like the safe code rules aren't there so you can write silly code. they're there so that you can declare safety and then be confident that any bugs result in an error instead of weirdness.
<Bike>
Shinmera: aaaaanyway, so what kind of uses do you have in mind for this coerce extension?
<Shinmera>
It's come up in the past, but right now I have several types of "primitive shapes" and I would like to offer a convenient interface to construct another primitive based on an existing one. Eg if I have a convex hull, I'd like to construct an oriented bounding box that encapsulates it for use in a spatial query structure
<Alfr>
Bike, not arguing against extending it, but rather that implementations may want to simply document the discrepancy.
<Shinmera>
so being able to do (coerce mesh 'box) would be a neat and "intuitive" way to go about it.
<Bike>
if an implementation extends coerce it should definitely document that, yes. for example, if you do (documentation 'compile-file 'function) in sbcl you'll get a bevy of extra keywords
<Bike>
Shinmera: i see. so you're coercing to a class. then you could just have a coerce-object and specialize it on a prototype maybe rather than the keywords.
<Shinmera>
Maybe, but that would make the interface cumbersome.
skin has left #commonlisp [#commonlisp]
<Bike>
would it? I'm thinking like, we have coerce as a normal function, and then if it doesn't know what to do with a type specifier it tries resolves it to a class, and then does (coerce-object arg (class-prototype class)). so you'd just write (coerce mesh 'box) and have (defmethod coerce-object ((object mesh) (prototype box)) ...)
<phoe>
Bike: that requires an implementation-defined COERCE-OBJECT, and that sounds like the right thing to do tbh
<Shinmera>
Yes but for instance (coerce sphere 'mesh :segments 32)
<Shinmera>
Unless you want to squeeze that into the type specifier somehow, which would make it very awkward
<Bike>
oh, yeah, if you want to provide more information having keywords makes sense
<Bike>
coerce is already kind of a weird grab bag, so making it broadly extensible seems fine
tyson2 has quit [Remote host closed the connection]
<mfiano>
> Bike "again, i don't think there is anything ruling out the lambda list for a standard function being extended." -- this came up from one of my questions not long ago, and I forget where the section was, but it is indeed allowed. The question was in regard to SBCL's MAKE-HASH-TABLE synchronization IIRC.
edgar-rft has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
Gleefre has joined #commonlisp
dcb has joined #commonlisp
<mfiano>
Not finding anything. Probably just not explicitly disallowed.
nij- has joined #commonlisp
david` has quit [Remote host closed the connection]
Cymew has quit [Ping timeout: 276 seconds]
<phoe>
yeah, (mesh :segments 32) would not be a valid type specifier either way
<phoe>
unless you also have a custom TYPEP at which point you're just plugging CTYPES into your implementation or writing your own Lisp anyway
<phoe>
so (coerce object typespec &rest args), why not
<NotThatRPG>
BTW, if anyone has a chance to review my recent MR for Alexandria, I would be grateful!
Gleefre has quit [Remote host closed the connection]
<nij->
MR?
<splittist>
Merge Request?
<NotThatRPG>
splittist: Yes
<NotThatRPG>
There has been a little bit-rot...
<nij->
Merge request pipeline #8353 failed for 98deba44 1 hour ago ?
<Bike>
NotThatRPG: can you not just do (push foo (gethash key table nil))? i do that sometimes
<Shinmera>
phoe: neato!
<NotThatRPG>
Bike: This gives functionality like Python's default dict: you can initialize it arbitrarily
<Shinmera>
Though I would probably specify the defgeneric as &key, rather than &rest
<phoe>
Shinmera: yeah that's just API design shenanigans
<phoe>
I specified the defgeneric as &REST so that methods can be &KEY if needed
<Shinmera>
Also wonder if SBCL's cross compilation is gonna be an issue for this
<NotThatRPG>
Also, `ensure-gethash` actually makes a record which gethash with a default doesn't necessarily.
<Bike>
so you don't want to evaluate the default form unless it's needed? i see
<phoe>
Shinmera: might be, I have no idea what sorts of edge cases and custom optimizations for COERCE this hack of mine is going to trip up
<phoe>
probably some since slime's M-. on COERCE shows a few entries
<Shinmera>
Either way, sounds like a good thing to bring up on sb-devel
<phoe>
but I checked if it can be done at all, and it seems so
<Bike>
phoe: the optimizations should all be on standard types, and i assume there'd be the usual restrictions on defining methodss with standard types, so i think it's ok optimizationwise
<nij->
Where can I find the paper presented in ELS?
<ixelp>
ELS 2023, Amsterdam - European Lisp Symposium
<Bike>
there'd be a problem if you wanted to allow things like a method to enable (coerce my-custom-object 'list)
<Bike>
nij-: i think they are still editing the proceedings together.
<phoe>
yeah, I don't try to fix all the little error cases
<phoe>
I think that all cases that originally call COERCE-ERROR would need to fall back to the gf and let it signal an error if necessary
<phoe>
actually let me update the paste with this...
<nij->
got it
<NotThatRPG>
Bike: Anyway, doing this I figured out that the Alexandria regression tests are busted on many implementations and put in some fixes for those.
<NotThatRPG>
The tests don't always admit the full range of behavior permitted by the spec...
<phoe>
(coerce 42 'list) returning (42) would probably be the CL definition of going "¯\_(ツ)_/¯"
<phoe>
but yeah then the optimizers for compiled code all need to get fixed
<phoe>
Shinmera: mind bringing it to sb-devel? I think this paste is as good as a simple proof of concept is gonna get
<phoe>
or should I take the full responsibility for creating this cursed thing
<Shinmera>
It's your code
McParen has joined #commonlisp
<phoe>
Shinmera: done
<Shinmera>
Great, thanks a lot! :)
<Shinmera>
Now about that Verbose patch...
* phoe
dissolves into thin air
<phoe>
I'll try to remember how Verbose works and then submit it eventually
<Shinmera>
:)
<phoe>
also thank you for utilizing the permission to mercilessly ping me that I have given you
jeosol has quit [Quit: Client closed]
<Shinmera>
Well, it did take me years to remember.
NotThatRPG is now known as NotThatRPG_away
tyson2 has joined #commonlisp
jonatack has joined #commonlisp
NotThatRPG_away has quit [Ping timeout: 268 seconds]
zxcvz has joined #commonlisp
notzmv has quit [Ping timeout: 250 seconds]
jealousmonk has joined #commonlisp
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 268 seconds]
zxcvz1 has joined #commonlisp
zxcvz has quit [Ping timeout: 276 seconds]
zxcvz1 is now known as zxcvz
Guest8250 is now known as xristos
xristos has joined #commonlisp
xristos has quit [Changing host]
karlosz has joined #commonlisp
<jcowan>
Shinmera: You could get an (imperfect) generalization of COERCE by writing your own COERCE-OBJECT generic function, writing methods for the cases of COERCE that call COERCE itself, and then using COERCE-OBJECT in your code.
<Shinmera>
wow thanks for repeating the same pointless thing as p j b already wrote.
<jcowan>
sorry, not caught up
<Shinmera>
even then you coulda guessed that such a trivial idea I could have thought up myself
<phoe>
jcowan: tl;dr we're at the point where we're tryin to hook an additional GF into SBCL's COERCE implementation
<jcowan>
Thus sacrificing conformance
semarie has quit [Ping timeout: 248 seconds]
<Shinmera>
jesus christ
<phoe>
actually we've been reading the spec and there seems to be nothing forbidding an extension in that place
<jcowan>
I guess that depends on how you read "If a coercion is not possible, an error of type type-error is signaled." I read it as saying that if none of the given coercion rules is applied, type-error must be signaled.
<Shinmera>
can we not repeat the entire discussion? thanks.
<edwlan[m]>
I think that would be “must be signaled” jcowan
<edgar-rft>
(coerce 'shit 'gold)-> nil
semarie has joined #commonlisp
<jcowan>
edwlan[m]: So you think that "If a token consists solely of dots (with no escape characters), then an error of type reader-error is signaled, except in one circumstance:" etc. is not a requirement because it does not have a "must"?
<edwlan[m]>
I was misremembering the error terminology
<phoe>
but then "if a coercion is not possible" is not "if a coercion is not among the above set of rules and is not extended by the implementation"
tyson2 has quit [Remote host closed the connection]
zxcvz has quit [Quit: zxcvz]
<jcowan>
Right, that is a possible reading.
<jcowan>
The remaining problem is that even with a generic function you cannot, for example, coerce a general matrix containing characters into a character matrix.
<phoe>
yes, you'd need custom classes for that because the CL type system is not expressive enough
<phoe>
unless you mean array types, maybe it could work
<jcowan>
Not so much that it's not expressive enough, it's that 'string is EQL to 'string, whereas types expressible only by lists aren't EQL to anything useful.
<phoe>
yeah, you'd probably need to pass ctypes into that GF
<jcowan>
By "matrix" I just mean an ordinary CL array of rank 2.
tyson2 has joined #commonlisp
Cymew has joined #commonlisp
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
<phoe>
(coerce '((1 2 3) (4 5 6) (7 8 9)) '(array fixnum (3 3))) doesn't seem to work by normal rules, I'd assume a similar situation with characters would also be problematic
<jcowan>
Yes, I just picked characters at random, fixnums illustrate the same point.
<jcowan>
Hmm. A tricky solution would be to represent the type "(array fixnum (* *))" for COERCE-OBJECT purposes as "|(array fixnum (* *)|" and then EQL parameter specialization would work.
zxcvz has joined #commonlisp
Cymew has quit [Quit: Konversation terminated!]
Cymew has joined #commonlisp
zxcvz has quit [Client Quit]
lucasta has joined #commonlisp
nij- has joined #commonlisp
<nij->
How to get the namestring of a pathname?
<nij->
(? #P"/abc/def") => "/abc/def"
<edgar-rft>
you already said it: (namestring #P"/abc/def") => "/abc/def"
<nij->
Thanks.. I wonder why it's not called pathname-namestring.
Cymew has quit [Ping timeout: 265 seconds]
vassenn has joined #commonlisp
<nytpu>
when saving an image in SBCL, are the initializers for top-level variables (defvar, let over defun, etc) recomputed every time the image is loaded or just done once on initial source compiling? and is there a way to control that behavior (non-portably, naturally)
<nytpu>
on one hand it's nice to have expensive initializers like computing a lookup table done once and that's it; but it'd also be nice to hold a file handle in a defparameter, but IIRC SBCL closes all file descriptors when dumping an image so it'd have to be re-run every load.
tyson2 has quit [Remote host closed the connection]
NotThatRPG has joined #commonlisp
vassenn has quit [Quit: Leaving]
Cymew has joined #commonlisp
<edwlan[m]>
sbcl provides initialization hooks for that sort of thing
McParen has left #commonlisp [#commonlisp]
<phoe>
Shinmera: if I've become sort of a relay now: why not CHANGE-CLASS
<Shinmera>
because change-class changes. Coerce does not.
<phoe>
on right, COERCE is a pure function
<phoe>
oh right*
<phoe>
would you like to continue that mail thread or should I get to it someday?
<phoe>
Krystof has some nice points in there to think about
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
Cymew has quit [Ping timeout: 260 seconds]
Krystof has joined #commonlisp
Ellenor has quit [Quit: Bye Open Projects!]
thuna` has joined #commonlisp
Gleefre has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
Ellenor has joined #commonlisp
jeosol has joined #commonlisp
thuna` has quit []
waleee has joined #commonlisp
pkal has quit [Remote host closed the connection]
lottaquestions has quit [Quit: Konversation terminated!]
pkal has joined #commonlisp
lucasta has quit [Remote host closed the connection]
akoana has joined #commonlisp
asarch has joined #commonlisp
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
alejandrozf has joined #commonlisp
tyson2 has joined #commonlisp
Alfr has quit [Remote host closed the connection]
Alfr has joined #commonlisp
Alfr has quit [Read error: Connection reset by peer]
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #commonlisp
NotThatRPG has quit [Ping timeout: 268 seconds]
jmdaemon has joined #commonlisp
lucasta has joined #commonlisp
Krystof has quit [Ping timeout: 252 seconds]
rgherdt has quit [Remote host closed the connection]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
X-Scale has joined #commonlisp
NotThatRPG has joined #commonlisp
Alfr has joined #commonlisp
NotThatRPG has quit [Client Quit]
borodust has quit [Quit: Leavin']
borodust has joined #commonlisp
NotThatRPG has joined #commonlisp
bird_ has quit [Ping timeout: 246 seconds]
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azimut has joined #commonlisp
pve has quit [Quit: leaving]
karlosz has quit [Quit: karlosz]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
Gleefre has quit [Remote host closed the connection]