freenode/#sbcl - IRC Chatlog
Search
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))
15:49:10
sjl
nyef``: the standard is kinda unclear about what listen should do on a binary input stream
15:49:20
stassats
although, i didn't have a good experience with wait-until-fd-usable when i tried using it
15:49:37
sjl
clisp folks seem to think (listen binary-stream) should always return nil to be conforming: https://clisp.sourceforge.io/impnotes/non-block-io.html#rbnh
15:49:52
sjl
> The [ANSI CL standard] specification for LISTEN mentions “character availability” as the criterion that determines the return value. Since a CHARACTER is never available on a binary STREAM (i.e., a stream with STREAM-ELEMENT-TYPE being a subtype of INTEGER), LISTEN returns NIL for such streams.
16:06:48
nyef``
oleo: You are, somehow, doing something "wrong". But we don't know what because we don't know what you're doing.
16:13:17
oleo
i already copied my files over from my laptop too, and will try to make the image with them, or run the existing image (which was made on the laptop)
16:16:29
|3b|
(compile nil '(lambda (a) (when (every 'zerop (mapcar 'third a))))) => ; note: implementation limitation: couldn't inline expand because expansion refers to the optimized away object #<SB-C::CTRAN 1 {101DB68C23}>
16:19:16
|3b|
(mostly just the "is it seeing something i'm not" level of caring as is frequently the case with code deletion notes)
16:19:41
stassats
looks like the type error confuses constraint-propagate, and it derives all sorts of nonsense types
16:20:37
stassats
|3b|: there's nothing you can really do except rewrite it to a LOOP or (unless (find-if-not #'zerop a :key #'third))
16:38:18
stassats
we can't fix you being silly, but we can fix the compiler to produce more concrete errors
16:46:51
stassats
going to src/runtime, editing the makefile to avoid disabling PIE, and make -j8 libsbcl.so
16:54:50
_death
I want opinion on https://github.com/death/sbcl/commit/a07ad9d65805c63e33e5376c9cda97d6962b8900
17:34:43
sjl
is https://www.pvk.ca/Blog/2013/04/13/starting-to-hack-on-sbcl/ still a good starting guide for contributing to SBCL?
17:53:08
stassats
now (defun muffle-warning (&optional condition) (invoke-restart ...)) is conflicting with NIL
18:05:10
corci
Project sbcl-master » safepoints,ubuntu_trusty_32bit build #2879: UNSTABLE in 56 min: http://ci.cor-lab.de/job/sbcl-master/featureset=safepoints,label=ubuntu_trusty_32bit/2879/
18:10:43
scymtym
stassats: re corci: the options are limited. i think reverting to the previous behavior "notify on new failure and successes" is our best bet. i could try not notifying for individual configurations
18:15:47
oleo
welp, seems to have been some fuckup with my quicklisp directory that caused it, using the one from the laptop restores it
18:39:21
oleo
yah, it's actually only the mcclim-20171103-git folder which somehow got screwed or so, i now copied the contents of a backup and it works
19:27:10
corci
Project sbcl-master » safepoints,ubuntu_trusty_32bit build #2880: STILL UNSTABLE in 57 min: http://ci.cor-lab.de/job/sbcl-master/featureset=safepoints,label=ubuntu_trusty_32bit/2880/
19:29:14
scymtym
stassats: are you finished with that change? otherwise i would like to add tests (error-source-path.impure.lisp) and improve source paths for malformed LABELS/FLET bindings
19:30:03
scymtym
also, could WITH-CURRENT-SOURCE-FORM be used and if not, could it be improved to make it applicable?
19:32:24
scymtym
i had this idea where refining a source path form e.g. (let ((x 1))) to x would leave only one possibility for x
19:33:43
stassats
we identify conses, but there's always a cons, just need to record "car of a cons n"
19:34:04
scymtym
so (with-current-source-form ('(let ((x 1)))) (with-current-source-from ('x) ...)) should be able to produce a path for x when there are no other occurrences
19:40:22
corci
Project sbcl-master-windows » Windows_7_64bit build #1792: FAILURE in 15 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_64bit/1792/
20:09:29
corci
Project sbcl-master-windows » Windows_7_64bit build #1793: STILL FAILING in 15 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_64bit/1793/
20:22:58
corci
Project sbcl-master-windows » Windows_7_32bit build #1793: FAILURE in 29 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_32bit/1793/
20:28:53
corci
Project sbcl-master » without-unicode,ubuntu_trusty_64bit build #2881: UNSTABLE in 36 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=ubuntu_trusty_64bit/2881/
20:42:41
scymtym
precise source paths for malformed LET[*], FLET and LABELS (and eliminated a bit of redundant code)
20:46:40
scymtym
stassats: i'm planning to make a NEWS entry along the lines of "More accurate source locations in warnings and errors referring to bindings established by LET, LET*, FLET and LABELS". does that represent your changes properly?
20:54:07
corci
Project sbcl-master » fasteval,ubuntu_trusty_64bit build #2881: UNSTABLE in 1 hr 1 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fasteval,label=ubuntu_trusty_64bit/2881/
20:54:58
phoe
stassats: would it make sense to emit style-warnings if the compiler detects that EQ is used to compare numbers and/or characters?
21:08:29
corci
Project sbcl-master-windows » Windows_7_32bit build #1794: STILL FAILING in 8 min 17 sec: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_32bit/1794/
21:08:58
corci
Project sbcl-master-windows » Windows_7_64bit build #1794: STILL FAILING in 8 min 46 sec: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_64bit/1794/
21:14:19
phoe
So I can assume that this is a thing that the compiler should warn the programmer about.
21:16:00
stylewarning
scymtym: at least the standard leaves which Boolean eq returns for eql numbers and characters undefined
21:17:28
phoe
"However, numbers with the same value need not be eq, and two similar lists are usually not identical. "
21:17:58
phoe
" An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number. "
21:19:02
stassats
phoe: it's already determined to return NIL, so the subsequent forms will report as being deleted
21:19:30
stassats
there could be a mode of some kind which actually explains the origins of source deletion notes, since they are not always apparent
21:21:07
stassats
scymtym: yes, but my change is only for the FLET and LABELS, are you provinding LET and LET*?
21:21:52
scymtym
stassats: only malformed bindings for LET[*], improving unused LET[*] bindings remains
21:24:41
scymtym
GC invariant lost, file "gencgc.c", line 1562 while running tests. that's currently expected, right?
21:39:16
stylewarning
|3b| my reading of the standard is that it is undefined up to which value is selected from the set of Booleans.
21:42:32
|3b|
stylewarning: but only for number/character values for which EQL would return true... no false positives, only false negatives (at least by the definition used by EQL)
21:43:08
|3b|
so (eq 5 x) will never return true for anything aside from X=5, and maybe not even then
21:54:01
corci
Project sbcl-master-windows » Windows_7_32bit build #1796: FIXED in 28 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_32bit/1796/