2015-12-20T01:33:17Z pkhuong: fe[nl]ix: I'll move my stuff over tomorrow morning
2015-12-20T01:46:14Z fe[nl]ix: pkhuong: thanks
2015-12-20T01:47:27Z fe[nl]ix: I plan to have http2 working soon, with Letsencrypt certificates, if you're interested
2015-12-20T02:26:01Z DeadTrickster quit (Read error: No route to host)
2015-12-20T02:30:06Z csziacobus quit (Quit: csziacobus)
2015-12-20T02:33:37Z Bicyclidine joined #sbcl
2015-12-20T02:46:35Z sjl quit (Ping timeout: 260 seconds)
2015-12-20T02:54:18Z guicho joined #sbcl
2015-12-20T03:02:46Z attila_lendvai quit (Ping timeout: 240 seconds)
2015-12-20T03:43:01Z sjl joined #sbcl
2015-12-20T03:47:26Z sjl quit (Ping timeout: 240 seconds)
2015-12-20T05:27:49Z sjl joined #sbcl
2015-12-20T05:32:32Z sjl quit (Ping timeout: 246 seconds)
2015-12-20T06:06:13Z robgssp joined #sbcl
2015-12-20T06:07:07Z robgssp: question about require'ing builting modules
2015-12-20T06:07:25Z robgssp: at a fresh sbcl prompt, (require :sb-introspect) works fine
2015-12-20T06:08:20Z robgssp: but after (sb-ext:save-lisp-and-die "sbcl.core") and loading that with `sbcl --core ./sbcl.core`, (require :sb-introspect) throws an error
2015-12-20T06:08:55Z robgssp: what changes between the core dump and reload?
2015-12-20T06:14:26Z mordocai: robgssp: Works fine for me in sbcl 1.3.1 on gentoo x86_64
2015-12-20T06:15:21Z |3b|: are you running it on same system, in same shell?
2015-12-20T06:19:26Z robgssp: I can reproduce the bug on sbcl 1.3.0 on arch x64 and 1.3.1 on nixos x64
2015-12-20T06:21:19Z robgssp: to be clear, the core saving happens from an image that hasn't yet loaded sb-introspect
2015-12-20T06:21:56Z mordocai: Ah, that wasn't what I tried. One sec
2015-12-20T06:22:28Z mordocai: Yeah, okay. I can reproduce it that way.
2015-12-20T06:22:37Z robgssp: the same behavior happens on sbcl 1.1.12 on fedora 20 fwiw
2015-12-20T06:23:48Z robgssp: this isn't somehow expected behavior, right? this is broken?
2015-12-20T06:25:00Z mordocai: You know what, I actually can't reproduce sorry. I had a typo in my require.
2015-12-20T06:25:44Z mordocai: So to be clear on what i'm doing: I run sbcl with no options. I then (sb-ext:save-lisp-and-die "sbcl.core"). Then I sbcl --core ./sbcl.core. Then in that repl I (require :sb-introspect)
2015-12-20T06:25:58Z robgssp: yeah
2015-12-20T06:26:18Z mordocai: Okay, that is working for me. I had a typo in introspect the first time which is why I thought it failed for me. Sorry.
2015-12-20T06:26:19Z robgssp: or :sb-posix or any of the other builtins
2015-12-20T06:27:40Z |3b|: if it can find the contribs, it should load. if it can't, it should say so
2015-12-20T06:28:01Z |3b|: what error specifically do you get?
2015-12-20T06:28:39Z |3b|: where "contribs" are the "builtin modules" that require loads
2015-12-20T06:29:28Z |3b|: do you have any local or system init files? (.sbclrc etc), and have you tried without loading them?
2015-12-20T06:29:47Z |3b|: do environment variables change between runs? (SBCL_HOME in particular)
2015-12-20T06:30:00Z adhoc quit (Ping timeout: 260 seconds)
2015-12-20T06:30:35Z lnostdal_ joined #sbcl
2015-12-20T06:31:53Z robgssp: http://lpaste.net/147487
2015-12-20T06:33:13Z robgssp: with no user init, that's the error
2015-12-20T06:33:47Z lnostdal quit (Ping timeout: 246 seconds)
2015-12-20T06:35:06Z robgssp: http://lpaste.net/147488
2015-12-20T06:35:18Z robgssp: user init introduces asdf, which changes the error somewhat
2015-12-20T06:35:34Z robgssp: environment variables are the same between runs
2015-12-20T06:35:49Z robgssp: SBCL_HOME is unset
2015-12-20T06:40:52Z robgssp: also sb-rt is easier to spell and less likely to be loaded indirectly
2015-12-20T06:48:05Z robgssp quit (Remote host closed the connection)
2015-12-20T06:48:13Z guicho quit (Quit: さようなら)
2015-12-20T07:04:49Z DeadTrickster joined #sbcl
2015-12-20T07:28:54Z sjl joined #sbcl
2015-12-20T07:33:15Z sjl quit (Ping timeout: 240 seconds)
2015-12-20T07:51:37Z clique joined #sbcl
2015-12-20T07:59:08Z gingerale joined #sbcl
2015-12-20T08:06:15Z psy_ quit (Ping timeout: 240 seconds)
2015-12-20T08:38:52Z adhoc joined #sbcl
2015-12-20T08:59:44Z sjl joined #sbcl
2015-12-20T09:02:18Z clique quit (Ping timeout: 252 seconds)
2015-12-20T09:04:06Z sjl quit (Ping timeout: 240 seconds)
2015-12-20T09:33:39Z adhoc quit (Quit: leaving)
2015-12-20T09:36:24Z sjl joined #sbcl
2015-12-20T10:12:21Z stassats joined #sbcl
2015-12-20T10:12:37Z stassats: there is a constraint propagation problem too
2015-12-20T10:12:51Z stassats: copy propagation and constraint propagation, the constraint one is more severe
2015-12-20T10:16:42Z yuankode joined #sbcl
2015-12-20T10:21:28Z stassats` joined #sbcl
2015-12-20T10:26:05Z lnostdal__ joined #sbcl
2015-12-20T10:27:35Z adhoc joined #sbcl
2015-12-20T10:29:26Z lnostdal_ quit (Ping timeout: 240 seconds)
2015-12-20T10:56:32Z stassats quit (Ping timeout: 272 seconds)
2015-12-20T11:01:34Z attila_lendvai joined #sbcl
2015-12-20T11:01:34Z attila_lendvai quit (Changing host)
2015-12-20T11:01:34Z attila_lendvai joined #sbcl
2015-12-20T11:05:16Z Xof: stassats`: right, it's surprising to me that the first case doesn't blow up stand-alone
2015-12-20T11:05:53Z stassats`: the constraint problem has three loops, and it endless tries to reprocess successors
2015-12-20T11:06:28Z stassats`: and it was present in the past, just with different types
2015-12-20T11:06:56Z stassats`: i'll relegate the copy-propagation problem, since it needs a lot of code, this one needs three loops
2015-12-20T11:07:40Z stassats`: http://paste.lisp.org/display/244652
2015-12-20T11:08:00Z stassats`: incidentally, if i delay constraint propagation after type checks are generated, it succeeds
2015-12-20T11:08:19Z stassats`: but it says ";; We delay the generation of type checks until ;; the type constraints have had time to ;; propagate, else the compiler can confuse itself."
2015-12-20T11:10:02Z Xof: would we not solve both of these problems by implementing type checks in ir2 instead of ir1?
2015-12-20T11:10:26Z stassats`: the copy propagation problem is not related to type checks
2015-12-20T11:10:31Z Xof: I mean, the compiler scalability is also a general issue
2015-12-20T11:10:49Z stassats`: it's all about branches, which type checks now use more of
2015-12-20T11:11:13Z Xof: right, and if type checks were implemented opaquely-to-ir1, there would be fewer branches
2015-12-20T11:11:33Z stassats`: but my main test case for it is without any type checks
2015-12-20T11:11:56Z stassats`: and i can sense a solution to it, but not quite there yet
2015-12-20T11:12:20Z stassats`: but it needs like a 1000 blocks to go really bad, so it's not as pressing
2015-12-20T11:12:53Z Xof: well except that we have actual users who have it go bad
2015-12-20T11:13:14Z stassats`: i think it's all in constraint propagation in fricas
2015-12-20T11:13:55Z stassats`: well, at least in the test case i was presented yesterday
2015-12-20T11:14:33Z Xof: ok
2015-12-20T11:14:46Z stassats`: may well be both once this one is resolved
2015-12-20T11:15:19Z stassats`: and the copy propagation is easier, it's not about correctness there, just wastefulness
2015-12-20T11:15:32Z stassats`: constraint propagation just loops
2015-12-20T11:19:36Z stassats`: and it'd be quite complicated to do type checks in ir2
2015-12-20T11:19:59Z stassats`: would mean doing manually what ir1 already does
2015-12-20T11:32:20Z sjl quit (Ping timeout: 246 seconds)
2015-12-20T11:41:48Z lnostdal__ is now known as lnostdal
2015-12-20T12:33:06Z attila_lendvai quit (Ping timeout: 240 seconds)
2015-12-20T12:40:11Z stassats` quit (Ping timeout: 255 seconds)
2015-12-20T12:40:54Z stassats joined #sbcl
2015-12-20T12:45:35Z stassats quit (Ping timeout: 255 seconds)
2015-12-20T12:49:54Z stassats joined #sbcl
2015-12-20T12:54:35Z stassats quit (Ping timeout: 255 seconds)
2015-12-20T12:54:51Z stassats joined #sbcl
2015-12-20T13:44:45Z stassats: slightly reduced test case which fails on both old and new sbcl http://paste.lisp.org/display/244652#1
2015-12-20T13:48:41Z stassats: and rolling things back into LOOP http://paste.lisp.org/display/244652#2
2015-12-20T13:56:40Z stassats: some more http://paste.lisp.org/display/244652#3
2015-12-20T14:01:08Z nyef: G'morning.
2015-12-20T14:01:11Z guicho joined #sbcl
2015-12-20T14:35:08Z attila_lendvai joined #sbcl
2015-12-20T14:35:08Z attila_lendvai quit (Changing host)
2015-12-20T14:35:08Z attila_lendvai joined #sbcl
2015-12-20T15:38:43Z guicho quit (Quit: さようなら)
2015-12-20T17:00:16Z scymtym: can anyone see a reason why http://paste.lisp.org/display/244662 does not say (assert (= 42 …))? otherwise i'm changing it before committing my actual change
2015-12-20T17:07:51Z Xof: looks like a thinko, yes
2015-12-20T17:41:26Z stassats: can't get rid of type checks in my test case, so it must be caused by the code inserted during ir1-phases
2015-12-20T17:41:41Z stassats: maybe it's due to constraints being propagated again
2015-12-20T17:48:27Z stassats: there's a bit that says ";; Has the consequent been changed?"
2015-12-20T17:49:45Z stassats: although a subsequent iteration should reach an equilibrium
2015-12-20T18:03:07Z stassats: for it to proceed constraints have to be different
2015-12-20T18:05:01Z stassats: which can happen if a block is destined from two different if legs
2015-12-20T18:09:54Z stassats: although examining if-consequent, they always appear to be in the same order in the loop
2015-12-20T18:19:50Z stassats: the difference is always just one constraint
2015-12-20T18:28:03Z DeadTrickster_ joined #sbcl
2015-12-20T18:31:39Z stassats: and it flips between present in an old constraint, to being present in the new constraint
2015-12-20T18:33:02Z DeadTrickster_ quit (Ping timeout: 246 seconds)
2015-12-20T18:34:47Z stassats: pretty strange
2015-12-20T18:39:17Z stassats: also considering that there is a union operation being done before that
2015-12-20T19:01:43Z stassats: it seems that SB-C::%TYPEP-WRAPPER throws a wrench, applied my earlier patch that uses SB-C::%SOURCE-TRANSFORM-TYPEP when generating a type check and the problem disappears
2015-12-20T19:17:41Z drmeister: Does this happen very often?  Are there any prescriptions to figure out what is going wrong?    "Heap exhausted during garbage collection: 0 bytes available, 96 requested"
2015-12-20T19:17:47Z drmeister: I've been getting it all morning
2015-12-20T19:19:12Z stassats: it happens every time you exhaust heap
2015-12-20T19:19:28Z stassats: (duh)
2015-12-20T19:21:39Z drmeister: It's happening intermittently.
2015-12-20T19:23:59Z drmeister: If I've got some infinite loop allocating memory I'd expect it to happen every time.
2015-12-20T19:24:31Z drmeister: But no, it's intermittent and appears to happen in a pattern that costs me the maximum amount of time to diagnose the problem.  Grrrrr
2015-12-20T19:26:48Z nyef: drmeister: Sounds like you're either running a really large dataset, or there's a bit of a (possibly conservative) leak going on.
2015-12-20T19:27:47Z stassats: removing SB-C::%TYPEP-WRAPPER doesn't help, after all
2015-12-20T19:28:00Z drmeister: I didn't think it was that large.  I'll check the memory usage when it happens again.
2015-12-20T19:30:33Z stassats: but removing %TYPEP-WRAPPER reveals some things
2015-12-20T19:35:20Z drmeister: Does this look excessive?
2015-12-20T19:35:22Z drmeister: https://www.irccloud.com/pastebin/zNDDFtmp/
2015-12-20T19:35:36Z stassats: for what?
2015-12-20T19:35:48Z drmeister: 1GB heap?   I have 16GB ram on this machine.
2015-12-20T19:36:19Z Xof: you can get a bigger heap with the --dynamic-space-size argument
2015-12-20T19:36:35Z Xof: as for whether it's excessive -- it depends what you were doing
2015-12-20T19:36:36Z stassats: 1GB is the default
2015-12-20T19:40:00Z drmeister: The intermittent behavior might be because I'm just barely hitting the limit. I'll try raising it.
2015-12-20T19:49:54Z drmeister: I raised it to 4GB - and running it in a way that previously crashed no longer crashes.   Thank you!
2015-12-20T19:52:25Z drmeister: It's the scraper that I wrote for Clasp - I'm building Cando - which is roughly twice as much source code as Clasp.
2015-12-20T19:52:51Z stassats: does it hold everything in memory?
2015-12-20T19:54:06Z drmeister: It does.  It builds a linked list of every tag in every source file (all in memory at the same time) and a couple of hash tables.
2015-12-20T19:54:52Z drmeister: There was no reason to make it more memory efficient until this happened.
2015-12-20T19:55:04Z drmeister: Everything is fine, until it isn't.
2015-12-20T19:55:39Z stassats: constraint propagation was fine too
2015-12-20T19:55:51Z stassats: or rather nobody noticed that it was broken
2015-12-20T20:27:53Z nyef: And then there was that damage with array type unions.
2015-12-20T20:27:55Z nyef shudders
2015-12-20T20:29:09Z scymtym_ joined #sbcl
2015-12-20T20:30:32Z gingerale quit (Remote host closed the connection)
2015-12-20T21:28:22Z attila_lendvai: is there a way to convince slime to slime-macroexpand-all completely? whatever it returns I can continue to slime-macroexpand-1 (I guess due to compiler macros in CFFI)?
2015-12-20T21:39:40Z DeadTrickster_ joined #sbcl
2015-12-20T22:07:23Z DeadTrickster_ quit (Ping timeout: 264 seconds)
2015-12-20T22:33:17Z sjl joined #sbcl
2015-12-20T22:38:54Z sjl quit (Ping timeout: 272 seconds)
2015-12-20T23:17:39Z yuankode left #sbcl
2015-12-20T23:32:00Z stassats quit (Ping timeout: 260 seconds)
2015-12-20T23:53:46Z attila_lendvai quit (Ping timeout: 240 seconds)