freenode/#sbcl - IRC Chatlog
Search
13:49:55
stassats
but the issue here is that when a cast is deleted it notes since it is introduced by THE and is present in the original code
13:51:05
stassats
so i guess THE should break up the source path of the cast, would anyone care that their cast is deleted?
13:55:34
stassats
but if say it's a (the fixnum x) and it's decided that it is a fixnum, it may not be a fixnum on a 32-bit platform
13:55:53
flip214
and even for automatic casts like mine here (with a type on a structure slot), I'd like to know if it gets deleted IIF the types become incompatible
14:01:16
stassats
these casts are in a block of their own, and they are unreachable, so one of the IFs destinations becomes unreachable, but why are both IF legs having casts?
14:13:45
stassats
so, some optimization pass turns (the vector (if x y #())) into (if x (the vector y) #())
14:18:45
stassats
especially since user introduced and not deleted casts slide up, so compiler generated deleted branches receive user supplied casts => a note
14:20:22
stassats
i.g. (defun foo (m) (setf m (list 1)) (if (vectorp m) (the vector m) #())) still produces a note, but not two notes
14:21:32
flip214
stassats: would you care to tell me whether it was lisp experience or some SBCL diagnose thingie that made you find that so quickly?
14:22:36
nyef
flip214: My belief is that stassats knows a whole bunch of lot about how Python's IR1 works and is treated. Certainly far more than I.
14:22:38
stassats
first i set (setf *break-on-signals* 'compiler-note) to see where the note is issued, went there, poked my nose at what's going on
14:23:05
stassats
printed out some blocks with print-all-blocks, then went up the optimization tree to see from what it's being buchered
14:24:39
stassats
you don't always know where to look, but it helps to know where certainly not too look
14:26:39
stassats
((some people say "well, it's always the last place" but if you order all places you can look at by the probability of finding something there, the last place would be at the end of the queue))
14:27:56
flip214
[well, "the last place" is correct by definition, because you won't look any farther when you've found it]
14:28:20
flip214
I'm well aware that I don't have the slightest clue, but perhaps that'll change in the distant future....
14:31:34
hajovonta
stassats: I've noticed that with SBCL+Hunchentoot+Windows, the core cpu consumption is 100%
14:32:48
nyef
You'll learn quite a bit about IR2 and whatnot by bringing up a new backend, or fixing issues with one of the under-maintained backends, but that doesn't particularly help with IR1.
14:33:34
hajovonta
hm,.. thanks. I think I have something from October since it was the month when I got the computer that runs Windows
14:35:36
stassats
nyef: it's a combination of fixing bugs, gaining a clue to do some new optimization (which is equivalent of making a new bug and fixing it), then gaining more clue to fix harder bugs, rinse and repeat
14:38:05
nyef
stassats: I'm aware of how it happens. I'm some amount of the way through the process myself. You happen to be much further along when it comes to IR1.
17:29:31
|3b|
does that include all the ones that start threads and let DEFTEST try to kill them at the end?
17:31:30
stassats`
i had a rough fix for interrupt problems, but i've lost and don't remember what it did
17:31:32
|3b|
as far as i could tell that is the problem with :all-threads-have-abort-restart hanging
17:42:43
stassats`
scymtym_: i think after i mark all tests as :broken-on :win32 you could also start running the test suite
17:46:18
scymtym_
stassats`: even if the test suite finishes reliably, there will be no detailed reports since i patch the required functionality into the test harness during the build
18:00:43
stassats`
safepoints are nice, and the compiler instrumentation seems to be adequate, but the runtime part should be just thrown out and rewritten
18:02:06
stassats`
it's already hard as it is getting concurrency code right, but when you have to wade through undocumented code it's 10x harder
18:14:05
stassats`
interrupt-thread is not that important for applications, but a must for interactive development
18:24:20
stassats`
there is support for cmd.exe color, i guess msys2 i had used way back when adding colors to test output used cmd.exe
18:50:16
nyef
Maybe the solution is to document how safepoints work, then make the decision on throwing out the current runtime implementation or not?
18:52:13
scymtym_
stassats`: tests finished: https://ci.cor-lab.org/job/sbcl-master-windows/label=Windows_7_64bit/1433/console (this is not the most recent commit)
18:54:49
|3b|
ACTION wonders if "skipped" tests should be split into "not applicable" and "too broken to even try to see if it works"
18:55:52
|3b|
ACTION similarly thinks "expected failure" might not suggest quite the right thing as far as implementation quality... "known failure" or something might be closer
18:58:16
|3b|
ACTION is thinking about how windows build sounds a lot better if it can reliably finish its test suite with no unexpected failure/unhandled error, even if the actual implementation hasn't changed