2018-01-17T00:01:27Z nyef``: Uh-oh...
2018-01-17T00:01:35Z nyef``: ... COPY-MORE-ARG doesn't look to be interrupt-safe.
2018-01-17T00:01:53Z stassats: where?
2018-01-17T00:01:58Z nyef``: Everywhere.
2018-01-17T00:02:17Z smurfrobot quit (Remote host closed the connection)
2018-01-17T00:02:28Z stassats: it's even no-interrupt-unsafe in some places
2018-01-17T00:03:41Z stassats: doesn't seem unsafe on x86-64
2018-01-17T00:04:07Z nyef``: Hrm.
2018-01-17T00:04:33Z nyef``: Yeah, just checked there. Going to re-check on PPC. Might be something funky going on there.
2018-01-17T00:04:55Z stassats: is copy-more-arg fixed on ppc?
2018-01-17T00:05:24Z stassats: (:name (compile :copy-more-arg) :fails-on (not (or :x86 :x86-64 :arm :arm64)))
2018-01-17T00:05:27Z stassats: i'd say "no"
2018-01-17T00:05:37Z nyef``: That's what I'm working on right now.
2018-01-17T00:06:54Z stassats: but seems to be interrupt-safe at the moment
2018-01-17T00:08:57Z nyef``: Definitely happening on PPC...
2018-01-17T00:09:01Z smurfrobot joined #sbcl
2018-01-17T00:09:27Z nyef``: Ah. x86-64 has that weird "verified" thing going on.
2018-01-17T00:12:11Z nyef``: ... And an explicit check for this hole. Okay then!
2018-01-17T00:13:25Z nyef``: ARM and ARM64 look vulnerable, though.
2018-01-17T00:14:25Z nyef``: I don't understand the x86 logic, but it appears to at least give lip service to the issue?
2018-01-17T00:18:26Z nyef``: Basically, it's possible to cause (SB-ALLOCATED-SIZE 'CONTROL-STACK) to be less than the number of fixed arguments, and if the stack pointer calculation is based off of that then some of the more-args can be left hanging off the end of the stack for a bit.
2018-01-17T00:19:10Z smurfrobot quit (Remote host closed the connection)
2018-01-17T00:19:47Z sjl quit (Ping timeout: 256 seconds)
2018-01-17T00:34:38Z nyef``: Okay, actually USING one of the arguments near the end forces it to pack in a wired location, which in turn extends the SB, so it's at least not possible to generate wildly incorrect code with this.
2018-01-17T00:45:04Z aeth: Does anyone use the Windows SBCL in wine? I have a Windows license but I don't feel like setting up a VM just to test for Windows compatibility so I'm considering testing in wine for now.
2018-01-17T00:45:33Z stassats: you won't test anything under wine...
2018-01-17T00:46:28Z aeth: Well, the idea is to develop it under wine+SBCL and then later on setup a Windows VM (with GPU passthrough, which is why it's not trivial) to do actual testing.
2018-01-17T00:46:51Z aeth: But I don't even know if SBCL runs under wine
2018-01-17T00:47:19Z nyef``: It was made to do so at some point, even though it shouldn't've been.
2018-01-17T00:47:49Z stassats: develop under whatever os you are running wine, then test it on windows
2018-01-17T00:47:54Z nyef``: Had I been paying attention at the time, I'd've vigorously protested.
2018-01-17T00:48:13Z aeth: stassats: I need to wrap the Windows API
2018-01-17T00:48:45Z stassats: and wine provides sdk?
2018-01-17T00:48:45Z aeth: The only way to not have to mess with foreign dependency bundling is if I write CFFI directly for xlib and the Windows API, afaik.
2018-01-17T00:49:35Z stassats: why do you need a gpu pass through for win api?
2018-01-17T00:49:43Z aeth: OpenGL
2018-01-17T00:50:18Z aeth: cl-opengl would be my only other foreign dependency other than the OSes themselves, ideally
2018-01-17T00:50:22Z stassats: and opengl changes its headers based on what it is attached to?
2018-01-17T00:50:43Z aeth: I should explain what I'm trying to do
2018-01-17T00:50:55Z aeth: I'm trying to replace cl-sdl2 with directly dealing with Windows and Linux APIs
2018-01-17T00:50:56Z stassats: well, my answer would be "don't use wine"
2018-01-17T00:51:28Z aeth: There was one other attempt to do what I'm doing (for Windows, macOS, and Linux) but (1) it's broken and (2) it's consing
2018-01-17T00:51:43Z nyef``: Ah, so you're not actually monkeying with the windowing APIs and whatnot as such, you're providing a container for OpenGL?
2018-01-17T00:51:48Z aeth: Yes
2018-01-17T00:52:02Z aeth: I just need window + OpenGL + input + sound on Windows and Linux
2018-01-17T00:52:11Z stassats: i think my answer is even more "don't use wine" now
2018-01-17T00:52:23Z nyef``: Weren't some of the lispgames people using SBCL+wine to do their windows builds, even if they tested them on windows?
2018-01-17T00:53:02Z stassats: i don't even have a windows license and yet i don't use wine
2018-01-17T00:56:33Z sjl joined #sbcl
2018-01-17T00:56:38Z aeth: nyef``: The thing is, I don't even need to really worry about the concept of building like most of #lispgames if I don't need to bundle any C or C++ libraries afaik.
2018-01-17T00:57:06Z aeth: That's where most of the complexity is
2018-01-17T00:57:46Z stassats: you don't want to grovel headers by hand, do you?
2018-01-17T00:58:27Z aeth: Honestly? Anything would be better than having to deal with cl-sdl2
2018-01-17T00:58:47Z aeth: Almost entirely undocumented, very fancy, and the author is no longer active in the CL community.
2018-01-17T00:59:45Z stassats: the author(s) of sbcl isn't active either
2018-01-17T01:03:30Z aeth: I haven't yet gotten to the point where writing a new CL implementation would probably be easier than just using SBCL.
2018-01-17T01:05:36Z aeth: Also, there are some people on IRC who actually know things about SBCL
2018-01-17T01:05:52Z stassats: minion: what does SBCL stand for?
2018-01-17T01:05:52Z minion: Semisaprophytic Brideweed Common Lisp
2018-01-17T01:06:00Z stassats: minion knows things
2018-01-17T01:29:23Z stassats: is the comment above maybe-convert-to-assignment not telling all the truth?
2018-01-17T01:29:39Z stassats: 'all calls must be tail recursive calls in the called function (i.e. are self-recursive tail calls)'
2018-01-17T01:29:44Z stassats: that doesn't appear to be the case
2018-01-17T01:34:05Z stassats: the logic is entirely convoluted
2018-01-17T01:42:03Z smurfrobot joined #sbcl
2018-01-17T01:44:18Z pfdietz: Latest bug?
2018-01-17T01:44:25Z stassats: yeah
2018-01-17T01:45:17Z pfdietz: I read in ~89K functions from quicklisp and started mutating them.  That was the first new bug out of that.
2018-01-17T01:45:17Z smurfrobot quit (Remote host closed the connection)
2018-01-17T01:49:07Z mood quit (Ping timeout: 256 seconds)
2018-01-17T01:49:26Z stassats: i'm close to seeing what's going on
2018-01-17T01:49:33Z mood joined #sbcl
2018-01-17T01:49:44Z stassats: the unreachable call to F3 is not deleted from lambda-calls-or-closes
2018-01-17T01:50:38Z stassats: the test looks like (lambda (c y) (labels ((f1 () (if y (f3 2))) (l () (loop)) (f2 () (l) (f3 3)) (f3 (x) (f3 x)) (f4 () (f1) (f2))) (f4) c)) now
2018-01-17T02:00:17Z stassats: fixing up lambda-calls-or-closes in delete-ref, which fixes the issue, but there's a chance it breaks something else
2018-01-17T02:13:53Z eschatologist quit (Ping timeout: 276 seconds)
2018-01-17T02:17:13Z eschatologist joined #sbcl
2018-01-17T02:22:08Z stassats: ok, that worked
2018-01-17T02:22:11Z stassats: why hasn't anybody bothered with maintaining lambda-calls-or-closes?
2018-01-17T02:22:30Z stassats: except when doing let conversion
2018-01-17T02:25:39Z stassats: this one was non obvious but easy to fix, an hour or so
2018-01-17T02:29:31Z pfdietz: I'd guess there was no obvious (from tests) problem with it?
2018-01-17T02:30:15Z corci: Project sbcl-master » default,ubuntu_trusty_32bit build #2877: FAILURE in 6 min 7 sec: http://ci.cor-lab.de/job/sbcl-master/featureset=default,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:30:17Z corci: Project sbcl-master » without-threads,ubuntu_trusty_32bit build #2877: FAILURE in 6 min 9 sec: http://ci.cor-lab.de/job/sbcl-master/featureset=without-threads,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:30:22Z corci: Project sbcl-master » fasteval,ubuntu_trusty_32bit build #2877: FAILURE in 6 min 13 sec: http://ci.cor-lab.de/job/sbcl-master/featureset=fasteval,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:31:05Z stassats: non maintaining lambda-calls-or-closes? but somebody should've asked "hmm, what happens when a reference is deleted?" when adding lambda-calls-or-closes
2018-01-17T02:31:34Z stassats: GC invariant lost, file "gencgc.c", line 3289
2018-01-17T02:31:34Z stassats: yay
2018-01-17T02:33:38Z corci: Project sbcl-master-windows » Windows_7_32bit build #1786: FAILURE in 13 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_32bit/1786/
2018-01-17T02:35:10Z corci: Project sbcl-master » without-unicode,ubuntu_trusty_32bit build #2877: FAILURE in 11 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:35:29Z corci: Project sbcl-master » fancy,ubuntu_trusty_32bit build #2877: FAILURE in 11 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fancy,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:35:33Z corci: Project sbcl-master » safepoints,ubuntu_trusty_32bit build #2877: FAILURE in 11 min: http://ci.cor-lab.de/job/sbcl-master/featureset=safepoints,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:35:42Z corci: Project sbcl-master » ccl,ubuntu_trusty_32bit build #2877: ABORTED in 11 min: http://ci.cor-lab.de/job/sbcl-master/featureset=ccl,label=ubuntu_trusty_32bit/2877/
2018-01-17T02:37:23Z corci: Project sbcl-master » default,ubuntu_trusty_64bit build #2877: FAILURE in 13 min: http://ci.cor-lab.de/job/sbcl-master/featureset=default,label=ubuntu_trusty_64bit/2877/
2018-01-17T02:38:51Z stassats: it's all broken, stopping
2018-01-17T02:39:42Z corci: Project sbcl-master » without-threads,ubuntu_trusty_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-threads,label=ubuntu_trusty_64bit/2877/
2018-01-17T02:39:46Z corci: Project sbcl-master » without-unicode,ubuntu_trusty_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=ubuntu_trusty_64bit/2877/
2018-01-17T02:39:46Z corci: Project sbcl-master » fasteval,ubuntu_trusty_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fasteval,label=ubuntu_trusty_64bit/2877/
2018-01-17T02:39:48Z corci: Project sbcl-master » without-unicode,MAC_OS_mavericks_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=MAC_OS_mavericks_64bit/2877/
2018-01-17T02:39:48Z corci: Project sbcl-master » fasteval,MAC_OS_mavericks_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fasteval,label=MAC_OS_mavericks_64bit/2877/
2018-01-17T02:39:49Z corci: Project sbcl-master » default,MAC_OS_mavericks_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=default,label=MAC_OS_mavericks_64bit/2877/
2018-01-17T02:39:50Z corci: Project sbcl-master » without-threads,MAC_OS_mavericks_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-threads,label=MAC_OS_mavericks_64bit/2877/
2018-01-17T02:39:50Z corci: Project sbcl-master » fancy,MAC_OS_mavericks_64bit build #2877: ABORTED in 15 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fancy,label=MAC_OS_mavericks_64bit/2877/
2018-01-17T02:39:51Z stassats: oh no
2018-01-17T02:40:03Z stassats: scymtym: somehow it now reports ABORTED
2018-01-17T03:00:38Z rpg quit (Quit: Textual IRC Client: www.textualapp.com)
2018-01-17T03:31:45Z smurfrobot joined #sbcl
2018-01-17T03:36:26Z smurfrobot quit (Ping timeout: 255 seconds)
2018-01-17T04:05:35Z stassats quit (Ping timeout: 240 seconds)
2018-01-17T04:50:32Z oleo quit (Ping timeout: 276 seconds)
2018-01-17T05:01:05Z |3b| quit (Remote host closed the connection)
2018-01-17T05:03:18Z oleo joined #sbcl
2018-01-17T05:11:21Z Bike quit (Quit: Lost terminal)
2018-01-17T05:19:15Z oleo quit (Quit: Leaving)
2018-01-17T06:00:24Z smurfrobot joined #sbcl
2018-01-17T06:05:50Z smurfrobot quit (Ping timeout: 276 seconds)
2018-01-17T06:47:08Z smurfrobot joined #sbcl
2018-01-17T06:51:43Z smurfrobot quit (Ping timeout: 248 seconds)
2018-01-17T07:05:09Z milanj quit (Quit: This computer has gone to sleep)
2018-01-17T07:17:54Z DeadTrickster joined #sbcl
2018-01-17T07:33:39Z Lord_Nightmare quit (Ping timeout: 256 seconds)
2018-01-17T07:38:30Z Lord_Nightmare joined #sbcl
2018-01-17T07:39:31Z smurfrobot joined #sbcl
2018-01-17T07:44:23Z smurfrobot quit (Ping timeout: 255 seconds)
2018-01-17T07:58:06Z m00natic joined #sbcl
2018-01-17T08:09:31Z smurfrobot joined #sbcl
2018-01-17T08:13:57Z smurfrobot quit (Ping timeout: 240 seconds)
2018-01-17T08:47:52Z MetaYan quit (Remote host closed the connection)
2018-01-17T08:48:08Z MetaYan joined #sbcl
2018-01-17T08:49:14Z shka joined #sbcl
2018-01-17T10:19:04Z angavrilov joined #sbcl
2018-01-17T10:20:18Z milanj joined #sbcl
2018-01-17T10:24:35Z scymtym: minion: memo for stassats: yeah, sorry. i'm at home with sick child at the moment. will have another look later
2018-01-17T10:24:35Z minion: Remembered. I'll tell stassats when he/she/it next speaks.
2018-01-17T10:25:20Z smurfrobot joined #sbcl
2018-01-17T10:30:20Z smurfrobot quit (Ping timeout: 256 seconds)
2018-01-17T11:51:40Z m00natic quit (Remote host closed the connection)
2018-01-17T11:52:10Z m00natic joined #sbcl
2018-01-17T12:42:19Z stassats joined #sbcl
2018-01-17T12:54:31Z stassats: and ASDF keeps breaking old projects
2018-01-17T12:57:46Z |3b| joined #sbcl
2018-01-17T13:08:53Z smurfrobot joined #sbcl
2018-01-17T13:12:39Z pfdietz: I tried to "approved" way of loading all the projects in the QL dist.  Yeah, lots and lots of failures.
2018-01-17T13:13:05Z smurfrobot quit (Ping timeout: 240 seconds)
2018-01-17T13:13:07Z stassats: approved as in not at once?
2018-01-17T13:13:24Z stassats: were those failures due to missing cffi libraries?
2018-01-17T13:25:17Z pfdietz: All sorts of failures.
2018-01-17T13:26:13Z pfdietz: Some packages did things with ASDF internals that no longer work.
2018-01-17T13:26:55Z pfdietz: There was one package that invoked an SBCL internal symbol that got renamed.  Breaks on a package lock in the reader.
2018-01-17T13:27:16Z pfdietz: And a great many other failures I didn't categorize.
2018-01-17T13:27:21Z stassats: is that still in quicklisp?
2018-01-17T13:27:25Z stassats: or is your dist old?
2018-01-17T13:27:32Z pfdietz: December
2018-01-17T13:27:38Z pfdietz: The most recent one, in other words.
2018-01-17T13:28:07Z pfdietz: static-vector was the system with the package lock problem.
2018-01-17T13:28:50Z pfdietz: Anyway, I got it working sort of okay for my purpose, which was to get grist for the random testing mill.
2018-01-17T13:29:16Z stassats: that is strange cause i load static-vectors with no problem
2018-01-17T13:29:50Z pfdietz: Ok, I will have to figure out if I made a mistake somewhere.
2018-01-17T13:30:07Z stassats: using old static-vectors? not from quicklisp?
2018-01-17T13:31:08Z pfdietz: No, it's downloaded with ql:quickload
2018-01-17T13:31:24Z stassats: nothing in local-projects/?
2018-01-17T13:31:28Z pfdietz: Nothing
2018-01-17T13:35:02Z stassats: delete quicklisp and try again?
2018-01-17T13:35:56Z jackdaniel: what about ~/common-lisp ? I have some stuff lingering there. there is also ~/.cache/common-lisp which could be removed for certainity
2018-01-17T13:37:59Z pfdietz: I wiped out the fasls in .cache/common-lisp
2018-01-17T13:38:51Z pfdietz: I'll check ~/common-lisp later when I have access to that machine.
2018-01-17T13:39:05Z stassats: what is ~/common-lisp?
2018-01-17T13:39:15Z stassats: don't tell me some other asdf abomination?
2018-01-17T13:39:20Z jackdaniel: asdf looks there first (it is by default in its central registry)
2018-01-17T13:39:29Z jackdaniel: something like that, yes
2018-01-17T13:39:46Z stassats: "impeach ASDF!"
2018-01-17T13:40:34Z pfdietz: I will be happy if this makes most of the problems go away.
2018-01-17T13:41:16Z stassats: too bad ASDF is like cancer, and you can't avoid it unilaterally, the whole software ecosystem has to be changed at once
2018-01-17T13:41:27Z jackdaniel: http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html this may be relevant
2018-01-17T13:42:33Z jackdaniel: providing alternative which can read sane asd files (as a compat layer) may be a way forward
2018-01-17T13:43:21Z stassats: well, Fare is always asking for new maintainers
2018-01-17T13:43:46Z stassats: but i guess you can't maintain the bad stuff out of asdf
2018-01-17T13:46:04Z _death: I think asdf needs time to "stabilize", so fewer maintainers isn't a bad thing
2018-01-17T13:46:16Z jackdaniel: it is maintainer-starved ;)
2018-01-17T13:46:59Z stassats: but even when it doesn't break old stuff, it's still not good
2018-01-17T13:47:53Z stassats: well, i'm not updating ASDF in SBCL any time soon, so that'll stabilize things some
2018-01-17T13:48:25Z stassats: maybe if other implementations did the same
2018-01-17T13:49:02Z jackdaniel: ECL stopped at 3.1.8 branch, all forward breaks a lot of stuff (especially with shared libraries etc)
2018-01-17T13:49:22Z jackdaniel: if asd files were only delcarative it could simplify things a lot, but since they are actual lisp sources..
2018-01-17T13:49:48Z stassats: SBCL was on 3.1.5 for 2.5 years
2018-01-17T13:49:59Z 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)
2018-01-17T13:50:11Z jackdaniel: s/format/alternative format/
2018-01-17T13:53:09Z Jesin quit (Quit: Leaving)
2018-01-17T13:54:54Z stassats: ok, patching asdf in sbcl, or downgrading would be counterproductive
2018-01-17T13:55:13Z stassats: if some projects are removed from quicklisp due to asdf, i want people to suffer
2018-01-17T13:55:44Z stassats: nothing gets solved until someone is affected
2018-01-17T13:55:45Z _death: you could have a 5 year plan that doesn't include "asdf upgrade" :)
2018-01-17T13:56:00Z stassats: so, the more stuff is broken by asdf, the better
2018-01-17T13:56:32Z stassats: _death: done, our 5 year plan doesn't include that
2018-01-17T13:56:56Z _death: great.. then the problem is solved
2018-01-17T13:57:22Z stassats: and dealing with asdf problems is a waste of my time
2018-01-17T13:57:27Z stassats: i have compiler problems to solve
2018-01-17T14:00:36Z 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.
2018-01-17T14:00:44Z _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
2018-01-17T14:02:16Z stassats: why are transforms called when one of the arguments is of NIL type?
2018-01-17T14:02:57Z pfdietz: And why is that handler-case needed to make the bug happen?
2018-01-17T14:03:09Z stassats: that's not an important question
2018-01-17T14:03:47Z pfdietz: I will take your word for it.
2018-01-17T14:05:04Z stassats: especially since it's not needed
2018-01-17T14:07:08Z stassats: (lambda () (oddp (flet ((f () (the nil 0))) (f))))
2018-01-17T14:07:56Z nyef``: Typically, handler-case involves a dynamic-bind and a DX FLET, and one or the other is sufficient, right?
2018-01-17T14:18:28Z pfdietz: I'll mutate subexpressions by e ==>  `(flet ((f () (the nil ,e))) (f)) and see what happens.
2018-01-17T14:27:39Z Xof: we could go back to 3.1.5
2018-01-17T14:28:31Z stassats: but then nothing would happen to asdf
2018-01-17T14:29:15Z stassats: i want people to experience what it's like to deal with asdf, so that they do something about it
2018-01-17T14:29:35Z jackdaniel: going back would save a lot of frustration to some people ;)
2018-01-17T14:29:52Z stassats: but i've asked Xach whether he would keep the failing projects if asdf in sbcl is fixed
2018-01-17T14:30:10Z stassats: (waiting for a reply)
2018-01-17T14:31:36Z nyef``: Really, shouldn't quicklisp be the first to discover these, given that it has its own asdf that it can install?
2018-01-17T14:31:55Z stassats: it bundles an even older asdf
2018-01-17T14:32:12Z stassats: and discover first, then what?
2018-01-17T14:32:32Z nyef``: Good question.
2018-01-17T14:32:57Z stassats: and Fare says he sent pull requests to the affected projects
2018-01-17T14:33:12Z stassats: so the issues were known
2018-01-17T14:33:23Z nyef``: Oh, WTF? (TIME :LAMBDAS-CONVERTED) still fails?
2018-01-17T14:33:41Z stassats: so ASDF deliberately breaks compatibility, it's not a bug in ASDF, it's a feature
2018-01-17T14:36:02Z 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
2018-01-17T14:36:06Z fe[nl]ix: because they can
2018-01-17T14:36:40Z stassats: some functions and nodes that are NIL are treated differently
2018-01-17T14:37:17Z 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 ?
2018-01-17T14:37:45Z stassats: fe[nl]ix: we have a standard
2018-01-17T14:38:42Z 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?
2018-01-17T14:39:07Z stassats: i would read the standard
2018-01-17T14:39:28Z stassats: and you can't normally flet call-next-method, can you?
2018-01-17T14:39:29Z fe[nl]ix: several times ASDF broke its user's code because they were relying on unspecified details of SBCL's CLOS
2018-01-17T14:39:36Z stassats: it's just that we unlock the package, aren't we?
2018-01-17T14:40:29Z nyef``: stassats: Package locks don't block FLET unless the symbol is already fbound, and CALL-NEXT-METHOD is a "local function".
2018-01-17T14:41:20Z stassats: which is global fbound
2018-01-17T14:41:44Z stassats: which is actually not important
2018-01-17T14:41:46Z nyef``: (describe 'call-next-method)
2018-01-17T14:41:55Z 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."
2018-01-17T14:42:02Z nyef``: Right.
2018-01-17T14:42:22Z nyef``: But that's not what SBCL does right now, because it ISN'T fbound in the global environment.
2018-01-17T14:43:35Z 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.
2018-01-17T14:56:54Z 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
2018-01-17T14:58:24Z 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.
2018-01-17T14:59:24Z nyef``: And now I want to TRACE (FLET NOTE :IN CALL-WITH-TIMING).
2018-01-17T14:59:31Z rumbler31 joined #sbcl
2018-01-17T14:59:57Z Bike joined #sbcl
2018-01-17T15:04:14Z 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
2018-01-17T15:07:43Z nyef``: ... Oh, wow. Eesh.
2018-01-17T15:08:00Z nyef``: Misplaced paren combined with confusing indentation in CALL-WITH-TIMING.
2018-01-17T15:16:51Z sjl quit (Quit: WeeChat 1.9.1)
2018-01-17T15:23:23Z m00natic quit (Remote host closed the connection)
2018-01-17T15:26:21Z stassats: how is (the integer (IF (< Y Y) (EQUAL Y -2))) Y in EQUAL become NIL?
2018-01-17T15:26:38Z stassats: is it due to constraint propagate, or what?
2018-01-17T15:27:06Z stassats: if i turn off constraint-propagate, it doesn't become NIL
2018-01-17T15:30:28Z oleo joined #sbcl
2018-01-17T15:31:07Z nyef``: (EQUAL Y -2) is dead there, isn't it?
2018-01-17T15:31:57Z stassats: no
2018-01-17T15:32:19Z nyef``: (< Y Y) can be T?
2018-01-17T15:33:11Z sjl joined #sbcl
2018-01-17T15:40:03Z nyef``: (< Y Y) is NIL, thus the IF (not having an alternative branch) returns NIL, leading to the entire expression being (THE INTEGER NIL)?
2018-01-17T15:40:37Z scymtym quit (Ping timeout: 256 seconds)
2018-01-17T15:41:24Z eudoxia joined #sbcl
2018-01-17T15:42:32Z stassats: no, that's not what's happening
2018-01-17T15:42:57Z milanj quit (Ping timeout: 248 seconds)
2018-01-17T15:43:08Z stassats: in reality, there's a conflict between (integer 1) and (or (integer 0 0) (integer 2 2))
2018-01-17T15:47:00Z sjl: Does SBCL have a READ-BYTE-NO-HANG equivalent?
2018-01-17T15:48:15Z stassats: sb-sys:wait-until-fd-usable and then read-byte
2018-01-17T15:48:33Z nyef``: How about LISTEN and then READ-BYTE?
2018-01-17T15:48:36Z Jesin joined #sbcl
2018-01-17T15:48:54Z sjl: stassats: thanks, that sounds like it'll work
2018-01-17T15:49:10Z sjl: nyef``: the standard is kinda unclear about what listen should do on a binary input stream
2018-01-17T15:49:20Z stassats: although, i didn't have a good experience with wait-until-fd-usable when i tried using it
2018-01-17T15:49:34Z stassats: so i ended up using iolib
2018-01-17T15:49:37Z 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
2018-01-17T15:49:52Z 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.
2018-01-17T15:51:07Z stassats: listen should work on sbcl
2018-01-17T15:51:21Z milanj joined #sbcl
2018-01-17T16:01:44Z oleo: what the frigging thing
2018-01-17T16:02:29Z oleo: i make an image and it saiz save-lisp-and-die has a without-threads macro or so
2018-01-17T16:02:47Z oleo: and obviously it hinders stuff from working here over
2018-01-17T16:03:08Z oleo: i cant't get my image to open a file
2018-01-17T16:03:15Z oleo: from mcclim
2018-01-17T16:03:19Z stassats: you're not making sense yet
2018-01-17T16:03:29Z oleo: actually from climacs
2018-01-17T16:04:17Z oleo: corrupts the image and room shows up in ldb
2018-01-17T16:04:38Z stassats: the type is coming from PROPAGATE-FROM-SETS, but i don't see the set in the IR
2018-01-17T16:04:50Z oleo: so something is leaking
2018-01-17T16:06:22Z oleo: and i can't get it working since days now on my pc
2018-01-17T16:06:48Z nyef``: oleo: You are, somehow, doing something "wrong". But we don't know what because we don't know what you're doing.
2018-01-17T16:07:00Z oleo: i extra checked my init files if they contain any without-interrupts bodies
2018-01-17T16:07:12Z oleo: and deleted some even
2018-01-17T16:07:16Z oleo: didn't change anything
2018-01-17T16:08:10Z oleo: i'm recompiling now and reinstalling the same version like on my laptop, sbcl-1.4.0
2018-01-17T16:08:55Z oleo: kernel wise and libc wise i'm on the same version as far as i can see between both...
2018-01-17T16:09:50Z oleo: and i don't have the problem on the laptop somehow, it only shows up here on my pc
2018-01-17T16:10:47Z stassats: what does without-interrupts have to do with anything?
2018-01-17T16:11:16Z oleo: that's what it tells somehow
2018-01-17T16:12:05Z stassats: define that define what define it
2018-01-17T16:12:36Z oleo: i'm running the tests stassats, i'll run the image in a few minutes
2018-01-17T16:12:43Z oleo: and see if stuff got fixed or not
2018-01-17T16:13:17Z 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)
2018-01-17T16:13:44Z oleo: that would be really good if i can fix it
2018-01-17T16:16:29Z |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}>
2018-01-17T16:16:41Z |3b|: is that saying anything i should care about?
2018-01-17T16:16:59Z stassats: no
2018-01-17T16:17:20Z stassats: how much do you want to care?
2018-01-17T16:17:48Z stassats: are you willing to learn the compiler and fix the "implementation limitation"?
2018-01-17T16:17:50Z |3b|: not much, at most filing a bug report
2018-01-17T16:17:58Z stassats: no bug report needed
2018-01-17T16:19:16Z |3b|: (mostly just the "is it seeing something i'm not" level of caring as is frequently the case with code deletion notes)
2018-01-17T16:19:41Z stassats: looks like the type error confuses constraint-propagate, and it derives all sorts of nonsense types
2018-01-17T16:20:37Z stassats: |3b|: there's nothing you can really do except rewrite it to a LOOP or (unless (find-if-not #'zerop a :key #'third))
2018-01-17T16:21:22Z |3b|: ok, i'll probably just ignore it for now, not 'real' code anyway :)
2018-01-17T16:33:05Z phoe: I think SBCL is giving me a false "unused variable" warning.
2018-01-17T16:33:07Z phoe: https://pastebin.com/pzSr69Ua
2018-01-17T16:33:37Z phoe: This is the DEFUN that I evaluate and the warning I get, originating from the LABELS.
2018-01-17T16:33:46Z phoe: SBCL 1.4.2 here.
2018-01-17T16:33:53Z stassats: it is unused
2018-01-17T16:34:09Z phoe: (pref (i) (aref *classic-palette* (+ i (* 4 index))))
2018-01-17T16:34:13Z phoe: that's where I use it.
2018-01-17T16:34:37Z jackdaniel: it is lexical not dynamic variable
2018-01-17T16:34:48Z phoe: yes, it's a lexical variable.
2018-01-17T16:34:51Z jackdaniel: pref sees defun's index as index, not get-rgb's
2018-01-17T16:34:59Z jackdaniel: so index in get-rgb is unused
2018-01-17T16:35:02Z phoe: wait
2018-01-17T16:35:04Z phoe: gah
2018-01-17T16:35:07Z stassats: phoe: you're not using slime, i presume?
2018-01-17T16:35:10Z phoe: I was looking at the wrong index.
2018-01-17T16:35:31Z phoe: stassats: I am using slime. lemme take a screenshot.
2018-01-17T16:35:45Z stassats: it highlights "LABELS"
2018-01-17T16:35:49Z stassats: not the DEFUN
2018-01-17T16:35:54Z phoe: https://imgur.com/a/7M9lX
2018-01-17T16:36:00Z phoe: yes, it highlights labels.
2018-01-17T16:36:08Z phoe: I was looking at the index in PREF and not in GET-RGB.
2018-01-17T16:36:23Z stassats: well, pref doesn't introduce a new binding
2018-01-17T16:36:29Z jackdaniel: but pref … what stassats said
2018-01-17T16:36:43Z stassats: but it could've
2018-01-17T16:36:47Z phoe: yes. I'm silly, sorry.
2018-01-17T16:36:52Z phoe: Back to coding.
2018-01-17T16:37:25Z stassats: well, i want get-rgb to be highlighted
2018-01-17T16:38:18Z stassats: we can't fix you being silly, but we can fix the compiler to produce more concrete errors
2018-01-17T16:39:07Z phoe: I think so, yes
2018-01-17T16:42:08Z stassats: and done
2018-01-17T16:42:28Z stassats: (well, left to test and commit)
2018-01-17T16:42:28Z phoe: ...three minutes? really?
2018-01-17T16:42:36Z phoe: you keep on amazing me
2018-01-17T16:43:11Z jackdaniel: amaze him more, I want sbcl.so ;-)
2018-01-17T16:43:22Z stassats: {five years to get this point} yeah, three minutes
2018-01-17T16:43:36Z stassats: jackdaniel: it's already done
2018-01-17T16:44:39Z jackdaniel: :-)
2018-01-17T16:46:51Z stassats: going to src/runtime, editing the makefile to avoid disabling PIE, and make -j8 libsbcl.so
2018-01-17T16:54:50Z _death: I want opinion on https://github.com/death/sbcl/commit/a07ad9d65805c63e33e5376c9cda97d6962b8900
2018-01-17T16:55:10Z stassats: _death: no test case
2018-01-17T16:55:28Z scymtym joined #sbcl
2018-01-17T16:56:01Z stassats: a more descriptive commit message
2018-01-17T16:56:31Z _death: I discussed it a while ago in this channel..
2018-01-17T16:58:52Z _death: is there a public log of this channel?
2018-01-17T16:59:02Z stassats: two
2018-01-17T16:59:15Z stassats: http://ccl.clozure.com/irc-logs/sbcl/sbcl-2017-12.txt
2018-01-17T16:59:22Z stassats: http://irclog.tymoon.eu/freenode/sbcl
2018-01-17T17:00:09Z stassats: huh, why isn't (defun foo () (the nil 0)) warned at CT?
2018-01-17T17:00:45Z stassats: i know how to make it warn, but why is it explicitly ignored?
2018-01-17T17:02:07Z _death: https://irclog.tymoon.eu/freenode/%23sbcl?around=1512867325#1512867325
2018-01-17T17:02:29Z stassats: well, good, now put all that into the commit message and a test case
2018-01-17T17:07:11Z stassats: ok, and it doesn't build when (the nil 0) warnings
2018-01-17T17:07:45Z stassats: who wants to bet it's because of the nil arrays?
2018-01-17T17:08:12Z nyef``: No bet.
2018-01-17T17:08:37Z nyef``: String theory ruins everything. d-:
2018-01-17T17:11:00Z stassats: it is
2018-01-17T17:34:43Z sjl: is https://www.pvk.ca/Blog/2013/04/13/starting-to-hack-on-sbcl/ still a good starting guide for contributing to SBCL?
2018-01-17T17:52:43Z nyef``: sjl: It seems broadly correct still, yes.
2018-01-17T17:53:08Z stassats: now (defun muffle-warning (&optional condition) (invoke-restart ...)) is conflicting with NIL
2018-01-17T18:01:07Z stassats: i still want (the nil 0) to signal, so, moving through
2018-01-17T18:05:11Z 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/
2018-01-17T18:10:43Z 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
2018-01-17T18:12:18Z stassats: ok
2018-01-17T18:13:35Z milanj quit (Ping timeout: 240 seconds)
2018-01-17T18:15:47Z oleo: welp, seems to have been some fuckup with my quicklisp directory that caused it, using the one from the laptop restores it
2018-01-17T18:15:54Z oleo: oO
2018-01-17T18:16:08Z oleo: i even fscked that drive....
2018-01-17T18:16:16Z oleo: not sure what else is left todo there
2018-01-17T18:39:22Z 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
2018-01-17T18:39:23Z oleo: baaaa
2018-01-17T19:00:06Z stassats: phoe: finally got to commit it
2018-01-17T19:08:32Z phoe: stassats: thanks!
2018-01-17T19:17:21Z phoe: stassats: works for flet as well, I assume?
2018-01-17T19:19:28Z stassats: sure
2018-01-17T19:20:55Z phoe: <3
2018-01-17T19:27:10Z 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/
2018-01-17T19:29:15Z 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
2018-01-17T19:29:32Z stassats: yeah
2018-01-17T19:30:03Z scymtym: also, could WITH-CURRENT-SOURCE-FORM be used and if not, could it be improved to make it applicable?
2018-01-17T19:30:07Z stassats: i wish we could highlight individual variales
2018-01-17T19:30:38Z stassats: no idea
2018-01-17T19:31:13Z scymtym: i have thought about that as well
2018-01-17T19:32:24Z 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
2018-01-17T19:33:43Z stassats: we identify conses, but there's always a cons, just need to record "car of a cons n"
2018-01-17T19:34:04Z 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
2018-01-17T19:40:22Z 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/
2018-01-17T19:50:11Z dougk quit (Remote host closed the connection)
2018-01-17T19:58:11Z stassats: GC invariant lost, file "gencgc.c", line 1562
2018-01-17T20:04:54Z stassats: oops, can't self build, due to NIL types
2018-01-17T20:09:29Z 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/
2018-01-17T20:22:58Z 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/
2018-01-17T20:25:13Z milanj joined #sbcl
2018-01-17T20:27:54Z eudoxia quit (Quit: Leaving)
2018-01-17T20:28:53Z 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/
2018-01-17T20:34:04Z stassats: Unhandled SIGILL at 0x1005fa99c2
2018-01-17T20:34:05Z stassats: interesting
2018-01-17T20:42:41Z scymtym: precise source paths for malformed LET[*], FLET and LABELS (and eliminated a bit of redundant code)
2018-01-17T20:46:40Z 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?
2018-01-17T20:54:07Z 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/
2018-01-17T20:54:08Z angavrilov quit (Remote host closed the connection)
2018-01-17T20:54:58Z phoe: stassats: would it make sense to emit style-warnings if the compiler detects that EQ is used to compare numbers and/or characters?
2018-01-17T21:02:53Z scymtym quit (Remote host closed the connection)
2018-01-17T21:03:10Z scymtym joined #sbcl
2018-01-17T21:08:29Z 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/
2018-01-17T21:08:58Z 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/
2018-01-17T21:11:58Z stylewarning: phoe: no
2018-01-17T21:13:01Z stylewarning: Well maybe. It’s a good question I suppose.
2018-01-17T21:13:56Z phoe: I have *never* seen EQ properly used on numbers and/or chars.
2018-01-17T21:14:19Z phoe: So I can assume that this is a thing that the compiler should warn the programmer about.
2018-01-17T21:15:07Z scymtym: could make sense for bignums. so maybe s/nunmbers/fixnums/?
2018-01-17T21:16:00Z stylewarning: scymtym: at least the standard leaves which Boolean eq returns for eql numbers and characters undefined
2018-01-17T21:16:09Z phoe: scymtym: sounds good.
2018-01-17T21:16:14Z phoe: How can EQ be used for bignums though?
2018-01-17T21:16:20Z stylewarning: Even (let ((x 0)) (eq x x)) is undefined
2018-01-17T21:16:49Z phoe: Are things like (eq bignum (incf bignum)) are meant to return T?
2018-01-17T21:16:52Z phoe: or something?
2018-01-17T21:16:56Z |3b|: is it "undefined" or just "not always true when you would expect it"?
2018-01-17T21:17:09Z oleo quit (Quit: Leaving)
2018-01-17T21:17:29Z phoe: "However, numbers with the same value need not be eq, and two similar lists are usually not identical. "
2018-01-17T21:17:33Z |3b|: for example i read it as (eq nil N) is always false for any non-nil N
2018-01-17T21:17:34Z phoe: from CLHS EQ
2018-01-17T21:17:56Z phoe: better:
2018-01-17T21:17:58Z 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. "
2018-01-17T21:18:11Z oleo joined #sbcl
2018-01-17T21:18:15Z phoe: doesn't need to be true at any moment
2018-01-17T21:18:21Z phoe: so can be any boolean
2018-01-17T21:18:32Z phoe: so usually not what you want
2018-01-17T21:18:43Z phoe: therefore (eq 2 2) may be NIL as well as T
2018-01-17T21:19:02Z stassats: phoe: it's already determined to return NIL, so the subsequent forms will report as being deleted
2018-01-17T21:19:30Z stassats: there could be a mode of some kind which actually explains the origins of source deletion notes, since they are not always apparent
2018-01-17T21:21:07Z stassats: scymtym: yes, but my change is only for the FLET and LABELS, are you provinding LET and LET*?
2018-01-17T21:21:52Z scymtym: stassats: only malformed bindings for LET[*], improving unused LET[*] bindings remains
2018-01-17T21:24:41Z scymtym: GC invariant lost, file "gencgc.c", line 1562 while running tests. that's currently expected, right?