freenode/#sbcl - IRC Chatlog
Search
10:24:35
scymtym
minion: memo for stassats: yeah, sorry. i'm at home with sick child at the moment. will have another look later
13:12:39
pfdietz
I tried to "approved" way of loading all the projects in the QL dist. Yeah, lots and lots of failures.
13:26:55
pfdietz
There was one package that invoked an SBCL internal symbol that got renamed. Breaks on a package lock in the reader.
13:28:50
pfdietz
Anyway, I got it working sort of okay for my purpose, which was to get grist for the random testing mill.
13:35:56
jackdaniel
what about ~/common-lisp ? I have some stuff lingering there. there is also ~/.cache/common-lisp which could be removed for certainity
13:41:16
stassats
too bad ASDF is like cancer, and you can't avoid it unilaterally, the whole software ecosystem has to be changed at once
13:41:27
jackdaniel
http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html this may be relevant
13:42:33
jackdaniel
providing alternative which can read sane asd files (as a compat layer) may be a way forward
13:47:53
stassats
well, i'm not updating ASDF in SBCL any time soon, so that'll stabilize things some
13:49:02
jackdaniel
ECL stopped at 3.1.8 branch, all forward breaks a lot of stuff (especially with shared libraries etc)
13:49:22
jackdaniel
if asd files were only delcarative it could simplify things a lot, but since they are actual lisp sources..
13:49:59
jackdaniel
I had a stab at defining format first, but it got starved due to lack of time: https://gist.github.com/dkochmanski/cf40e6ebc48251364da515df08b7c23c (ftr)
14:00:36
nyef``
I rarely plan more than six months out, and any time I'm dealing with ASDF other than the most basic of basic uses it's an unplanned diversion.
14:00:44
_death
other implementations will likely have to converge to most-recent-version-on-a-popular-implementation, and sbcl is in a good position now that it has a fairly recent version
14:07:56
nyef``
Typically, handler-case involves a dynamic-bind and a DX FLET, and one or the other is sufficient, right?
14:18:28
pfdietz
I'll mutate subexpressions by e ==> `(flet ((f () (the nil ,e))) (f)) and see what happens.
14:29:15
stassats
i want people to experience what it's like to deal with asdf, so that they do something about it
14:29:52
stassats
but i've asked Xach whether he would keep the failing projects if asdf in sbcl is fixed
14:31:36
nyef``
Really, shouldn't quicklisp be the first to discover these, given that it has its own asdf that it can install?
14:36:02
fe[nl]ix
the configuration language of ASDF is Lisp itself, so it's no surprise that it breaks when people start using or depend on internals
14:37:17
fe[nl]ix
if somebody's code starts depending on the iteration order over hash tables and an implementor breaks it, what would you say ?
14:38:42
nyef``
If somebody's code starts depending on being able to FLET CALL-NEXT-METHOD (as the example in AMOP shows!), and an implementor package-locks it (as the CLHS dictates), what would you say?
14:39:29
fe[nl]ix
several times ASDF broke its user's code because they were relying on unspecified details of SBCL's CLOS
14:40:29
nyef``
stassats: Package locks don't block FLET unless the symbol is already fbound, and CALL-NEXT-METHOD is a "local function".
14:41:55
stassats
"the restrictions on redefinition and shadowing of call-next-method are the same as for symbols in the COMMON-LISP package which are fbound in the global environment."
14:42:22
nyef``
But that's not what SBCL does right now, because it ISN'T fbound in the global environment.
14:43:35
nyef``
I was thinking to define it, so that we can get arglist hints and a docstring, and add the package-lock magic to wherever it was (make-method-lambda ?) to prevent errors from the normal case.
14:56:54
stassats
if i do (maybe-terminate-block cast t) during ir1tran, then it's treated the same way as NIL combinations and the bug goes away
14:58:24
nyef``
... TRACE tells me that :LAMBDAS-CONVERTED isn't being passed to PRINT-TIME. Direct manipulation tells me that *LAMBDA-CONVERSIONS* is being maintained properly.
15:04:14
stassats
suppose it's the right fix, now i need to revisit the fix i did for the EQUAL transform, where i'm ignore NIL lvar-types
15:40:03
nyef``
(< Y Y) is NIL, thus the IF (not having an alternative branch) returns NIL, leading to the entire expression being (THE INTEGER NIL)?
15:43:08
stassats
in reality, there's a conflict between (integer 1) and (or (integer 0 0) (integer 2 2))