2014-11-09T00:01:15Z Bike quit (Ping timeout: 265 seconds)
2014-11-09T00:01:47Z Bike joined #sbcl
2014-11-09T00:01:49Z fitzsim` joined #sbcl
2014-11-09T00:02:36Z fitzsim quit (Read error: Connection reset by peer)
2014-11-09T00:02:51Z |3b| quit (Read error: Connection reset by peer)
2014-11-09T00:03:36Z joshe quit (Ping timeout: 265 seconds)
2014-11-09T00:08:21Z kanru` joined #sbcl
2014-11-09T00:41:09Z carvite quit (Ping timeout: 260 seconds)
2014-11-09T00:41:43Z carvite joined #sbcl
2014-11-09T02:04:25Z edgar-rft joined #sbcl
2014-11-09T02:24:41Z Hache_ quit (Remote host closed the connection)
2014-11-09T03:39:03Z christoph_debian quit (Ping timeout: 258 seconds)
2014-11-09T03:52:57Z christoph_debian joined #sbcl
2014-11-09T04:28:11Z |3b|`` joined #sbcl
2014-11-09T04:28:34Z |3b|`` is now known as |3b|
2014-11-09T04:31:39Z LiamH quit (Quit: Leaving.)
2014-11-09T04:56:33Z leo2007 quit (Quit: rcirc on GNU Emacs 25.0.50.1)
2014-11-09T05:02:52Z leo2007 joined #sbcl
2014-11-09T05:07:09Z jdz quit (Ping timeout: 260 seconds)
2014-11-09T05:14:44Z scymtym_ quit (Ping timeout: 255 seconds)
2014-11-09T05:51:50Z psilord joined #sbcl
2014-11-09T06:09:58Z rpg quit (Quit: rpg)
2014-11-09T07:37:15Z oleo__ joined #sbcl
2014-11-09T07:38:41Z oleo is now known as Guest59548
2014-11-09T07:39:24Z Guest59548 quit (Ping timeout: 258 seconds)
2014-11-09T08:59:55Z jackdaniel quit (Quit: leaving)
2014-11-09T09:00:46Z jackdaniel joined #sbcl
2014-11-09T09:13:49Z angavrilov joined #sbcl
2014-11-09T09:54:20Z leo2007 quit (Ping timeout: 258 seconds)
2014-11-09T10:01:46Z leo2007 joined #sbcl
2014-11-09T10:13:22Z caps joined #sbcl
2014-11-09T10:17:18Z caps left #sbcl
2014-11-09T10:17:47Z oleo__ quit (Quit: Verlassend)
2014-11-09T10:34:43Z oleo joined #sbcl
2014-11-09T11:20:14Z pppp2 joined #sbcl
2014-11-09T12:42:31Z leuler joined #sbcl
2014-11-09T12:42:34Z Hache_ joined #sbcl
2014-11-09T13:24:19Z stassats joined #sbcl
2014-11-09T13:53:17Z pppp2 quit (Ping timeout: 264 seconds)
2014-11-09T14:04:07Z scymtym_ joined #sbcl
2014-11-09T14:06:36Z scymtym_: Krystof: i have a basic core comparison job in place: https://ci.cor-lab.org/job/sbcl-master-compare-outputs/17/console. the SBCL's from which the cores originate have been built in different directories. could that explain the differences? (each comparison is done via cmp -i 1024 "${sbcl_core}" "${other_core}")
2014-11-09T14:07:53Z stassats: scymtym_: was that the only  fixup vector assertion?
2014-11-09T14:08:05Z stassats: can you see at which tests they fail?
2014-11-09T14:08:17Z Krystof: scymtym_: hm, interesting
2014-11-09T14:08:30Z Krystof: (by "interesting" I mean "curses!")
2014-11-09T14:08:52Z Krystof: do you have access to the build trees?
2014-11-09T14:08:58Z scymtym_: stassats: hang on
2014-11-09T14:09:24Z Krystof: if so, can you run `diff -qr x86_64-{sbcl,clisp}/obj/from-xc ?
2014-11-09T14:10:04Z scymtym_: Krystof: only for the most recent build. you should have access, too: https://ci.cor-lab.org/job/sbcl-master/featureset=1,label=ubuntu_trusty_32bit/
2014-11-09T14:10:13Z scymtym_: download sbcl.tar.gz
2014-11-09T14:10:44Z stassats: we do embed file names into source locations
2014-11-09T14:10:50Z stassats: or used to
2014-11-09T14:10:56Z scymtym_: where featureset={2 -> fancy, 6 -> clisp host, 7 -> ccl host} label=ubuntu_trusty_{32,64}bit
2014-11-09T14:11:03Z Krystof: not during the cross-compilation
2014-11-09T14:11:11Z Krystof: thanks
2014-11-09T14:11:16Z scymtym_: i suspect, i have to leave in a second, but will hopefully be back later
2014-11-09T14:11:51Z stassats: so, you only compare cold cores?
2014-11-09T14:12:00Z Krystof: yes
2014-11-09T14:12:11Z stassats: but i was meaning to fix that anyway
2014-11-09T14:12:15Z stassats: (half a year ago)
2014-11-09T14:12:18Z Krystof: though the warm ones don't differ because of filesystem stuff (they use logical pathnames)
2014-11-09T14:12:25Z Krystof: they differ because of compilation time
2014-11-09T14:12:46Z stassats: well, they don't always use logical pathnames, there's something broken there
2014-11-09T14:13:47Z scymtym_: stassats: i will look at the failing tests later, but you can access the logs as well: https://ci.cor-lab.org/job/sbcl-master/731/featureset=1,label=ubuntu_trusty_32bit/consoleFull where 731 is the build number
2014-11-09T14:14:45Z stassats: which ones are failed?
2014-11-09T14:15:42Z scymtym_: if you start from https://ci.cor-lab.org/job/sbcl-master/731/, yellow and red "balls", if inspecting one of those, click on console
2014-11-09T14:15:51Z scymtym_: ok, i have to go, sorry
2014-11-09T14:27:39Z stassats: got to speed up char-downcase and char-upcase and char-equal, not really happy about the added complications, though
2014-11-09T14:38:53Z stassats: so, what (char-lessp #\` #\b) is supposed to return?
2014-11-09T14:40:17Z stassats: we donwcase, but all other implementations upcase
2014-11-09T14:41:17Z stassats: i accidentally made it upcasing in my changes
2014-11-09T14:46:12Z stassats: would anybody complain if i left it upcasing? that seems to be what everybody else is doing
2014-11-09T14:50:41Z loke_ quit (Ping timeout: 244 seconds)
2014-11-09T15:00:38Z loke_ joined #sbcl
2014-11-09T15:10:02Z Krystof: GAH
2014-11-09T15:10:33Z stassats: since C# and Java do different things, i'll leave it as is
2014-11-09T15:13:04Z Krystof: scymtym_: OK, I know at least one thing that is causing these differences because of filesystem location
2014-11-09T15:13:24Z stassats: VOP lambdas used to do that
2014-11-09T15:15:39Z Krystof: in this case it's a lambda context name.  (:in "/path/to/file.lisp")
2014-11-09T15:16:22Z Krystof: will fix
2014-11-09T15:16:30Z Hache_ quit (Remote host closed the connection)
2014-11-09T15:16:51Z LiamH joined #sbcl
2014-11-09T15:31:40Z jlarocco joined #sbcl
2014-11-09T16:17:10Z loke_ quit (Remote host closed the connection)
2014-11-09T16:41:00Z nyef joined #sbcl
2014-11-09T16:41:08Z nyef: Hello all.
2014-11-09T16:41:18Z stassats: hi
2014-11-09T16:41:35Z nyef: Krystof: Congratulations on sorting out the reproducible build issues!
2014-11-09T16:41:36Z stassats: nyef: need some help with non x86oids and gencgc
2014-11-09T16:42:07Z nyef: stassats: Ah, I was going to bug you about a couple of the more recent nlx-and-dead-code bugs.
2014-11-09T16:42:24Z stassats: specifically, gc_heap_exhausted_error_or_lose doesn't work on arm and ppc
2014-11-09T16:42:30Z stassats: for different reasons
2014-11-09T16:42:33Z nyef: Lovely.
2014-11-09T16:43:01Z nyef: I'm currently essentially without a build environment right now, but I can take a look.
2014-11-09T16:43:05Z stassats: ppc fails because of the check for unblocked gc signals in funcall2
2014-11-09T16:43:48Z nyef: ... IIRC, PPC has an actual trap in the alloc overflow path, so that's plausible.
2014-11-09T16:44:09Z stassats: and the gc signals are blocked because, let me find a line
2014-11-09T16:45:19Z stassats: in maybe_save_gc_mask_and_block_deferrables
2014-11-09T16:45:53Z stassats: because the interrupt comes from alloc, it has sigset, and that branch doesn't clear thread_sigmask(SIG_UNBLOCK, &gc_sigset, 0);
2014-11-09T16:47:47Z nyef: Hrm.
2014-11-09T16:48:03Z stassats: so, what to do?
2014-11-09T16:48:22Z nyef: Hang on, it has a sigset or it doesn't?
2014-11-09T16:49:55Z attila_lendvai joined #sbcl
2014-11-09T16:50:02Z attila_lendvai quit (Changing host)
2014-11-09T16:50:02Z attila_lendvai joined #sbcl
2014-11-09T16:50:06Z stassats: alloc is implemented with signals, so it has an interrupt context
2014-11-09T16:50:15Z stassats: and sigset comes from there
2014-11-09T16:50:27Z stassats: that is in gencgc 4482
2014-11-09T16:51:21Z nyef: Hrm. Our copies of gencgc.c seem to be out-of-sync.
2014-11-09T16:51:27Z nyef: But it's close to that, yes.
2014-11-09T16:54:45Z nyef: Bloody twisty interrupt logic.
2014-11-09T16:55:13Z nyef: Okay, so that's the PPC issue, about which I'm not prepared to comment without further study. What's the ARM issue?
2014-11-09T16:55:36Z stassats: and arm fails because of do_pending_interrupt, and the gc tries to chew foreign frames
2014-11-09T16:55:50Z stassats: we had a problem with that before which were solved by removing do_pending_interrupt
2014-11-09T16:57:47Z stassats: basically what happens is allocating something large sets auto_gc_trigger, dirtying PA, then it fails to allocate it, goes to gc_heap_exhausted_error_or_lose, and do_pending_interrupt causes a GC
2014-11-09T16:57:56Z stassats: do we want a gc before gc_heap_exhausted_error_or_lose?
2014-11-09T16:58:06Z stassats: how do we fix do_pending_interrupt, since it works on ppc
2014-11-09T16:59:02Z nyef: What's different between the PPC and ARM trap-handling paths?
2014-11-09T16:59:37Z nyef: Oh, for the...
2014-11-09T16:59:45Z stassats: ffca?
2014-11-09T17:00:00Z nyef: Where's the trap code?
2014-11-09T17:00:42Z stassats: does it matter?
2014-11-09T17:00:44Z nyef: I see the SWI that will cause a trap, but where's the trap code that tells the runtime what to do about the trap?
2014-11-09T17:01:06Z stassats: i think the trap delivers itself alright, but the gc starts on that interrupt context, and it's from C, the register values are no good
2014-11-09T17:03:06Z stassats: nyef: it looks at SWI itself
2014-11-09T17:03:21Z nyef: Hrm, okay, this isn't how I remembered the trap dispatch working.
2014-11-09T17:03:51Z stassats: it was a bit different, it looked at SWILT or SWIAL
2014-11-09T17:03:57Z nyef: If the instruction is not e7f001f0 then it's treated as interrupt-handle-pending.
2014-11-09T17:04:19Z nyef: Right, I take it there was good reason to ditch the condition-code magic?
2014-11-09T17:04:46Z stassats: well, you did that, after you changed to the magic instruction for internal errors
2014-11-09T17:05:04Z stassats: then then SWI was used only for PA
2014-11-09T17:05:18Z nyef: Okay, right... Ringing a vague bell.
2014-11-09T17:05:52Z nyef: This is odd, then, as the code path winds up being effectively the same as on PPC.
2014-11-09T17:06:01Z nyef: Modulo saving and restoring reg_OCFP.
2014-11-09T17:06:35Z stassats: how does PPC decide that the current frame is not a lisp one?
2014-11-09T17:07:24Z nyef: ... PPC, like all non-x86oid ports, has split lisp and C stacks, and maintains ffca.
2014-11-09T17:07:51Z stassats: arm does maintain ffca, except for alloc
2014-11-09T17:07:59Z nyef: That might do it.
2014-11-09T17:08:26Z nyef: "except for" is a pretty big warning sign when it comes to an invariant.
2014-11-09T17:08:35Z stassats: nope, it does maitain
2014-11-09T17:09:09Z stassats: one of the intermediate unpublished versions did not
2014-11-09T17:09:26Z stassats: now comes the question whether it's doing this correctly
2014-11-09T17:09:39Z stassats: how does ffca work with threads, by the way?
2014-11-09T17:10:55Z stassats: can be checked in gdb
2014-11-09T17:11:10Z nyef: It should be thread-local.
2014-11-09T17:12:00Z nyef: ... we don't have arm threads yet, do we?
2014-11-09T17:12:15Z stassats: they didn't materialize from nothing yet
2014-11-09T17:13:20Z nyef: There's a foreign-function-call-active slot in the thread objdef, conditionalized on sb-thread.
2014-11-09T17:13:38Z stassats: now i'm unclear how does ffca works after alloc => pending interupt => sb-ext:gc => collect_garbage
2014-11-09T17:14:15Z stassats: only if pending interupt saves it
2014-11-09T17:14:36Z nyef: Alloc is in C, so if it comes from lisp there's either an alien-funcall or an fake-foreign within a trap.
2014-11-09T17:14:48Z nyef: That sets ffca.
2014-11-09T17:15:14Z stassats: it is in c, but it's mucked by call_into_c and call_into_lisp
2014-11-09T17:15:17Z nyef: Pending-interrupt is in C, and ffca is set, so that should prevent fake-foreign and also not record the interrupt trap.
2014-11-09T17:15:25Z nyef: Err... not record the interrupt context.
2014-11-09T17:15:26Z stassats: so, the interrupt handler should save it for the current context
2014-11-09T17:15:44Z nyef: (IIRC, fake-foreign actually does the saving of the context.)
2014-11-09T17:16:49Z psilord quit (Quit: Leaving.)
2014-11-09T17:17:58Z nyef: call_into_c and call_into_lisp are the "interworking" functions that change the register conventions between Lisp and C modes, and FFCA is specifically FOR indicating the current mode of the register set.
2014-11-09T17:18:55Z stassats: but we care about ffca at the time do_pending_interrupt was called, i'm trying to find how that happens
2014-11-09T17:20:34Z nyef: do_pending_interrupt is called from a trap handler, without having already called fake_foreign.
2014-11-09T17:22:08Z stassats: now i don't see where the gc queries it either
2014-11-09T17:23:43Z nyef: Hrm. Bug 1389433, your diagnosis seems... less than correct. It's not that it figures that it'll be a constant, it's that it realizes that the value doesn't exist (hence is of type NIL) because the control-flow went elsewhere.
2014-11-09T17:24:38Z stassats: well, the same thing doesn't happen with a literal constant, and we do treat singleton type like constants, but first we typecheck
2014-11-09T17:24:49Z stassats: so, something happens that disassociates the two
2014-11-09T17:25:08Z nyef: Yes, the fact that it's working on dead code.
2014-11-09T17:25:10Z stassats: and it also will create a closure, even though the value is not used
2014-11-09T17:25:37Z stassats: and if i had a correct diagnosis, i would be able to fix it
2014-11-09T17:27:18Z nyef: You have a closure, which foxes the normal DCE action of DFO, plus a control-flow branch that kills some code *conditionally*, and you're constant-propagating something in to trip that control-flow path...
2014-11-09T17:29:00Z nyef: Hrm. It starts to look like we need to do DCE as part of IR1-PHASES.
2014-11-09T17:29:46Z stassats: ok, i see how the context are handled
2014-11-09T17:32:03Z nyef: A couple of things that pfdietz reported recently should be covered by http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/dce-phase but there's still the extra code-deletion notes thing that I just don't have the project bandwidth to track down right now.
2014-11-09T17:37:19Z stassats: maybe_gc calls fake_foreign_function_call, but indiscriminately, whether FFCA is set or not
2014-11-09T17:39:17Z lacedaemon joined #sbcl
2014-11-09T17:39:25Z fe[nl]ix quit (Ping timeout: 260 seconds)
2014-11-09T17:39:32Z stassats: why does it work on ppc?
2014-11-09T17:39:40Z stassats: does it?
2014-11-09T17:39:43Z jlarocco quit (Quit: This computer has gone to sleep)
2014-11-09T17:41:23Z nyef: Ugh.
2014-11-09T17:41:33Z nyef: That, right there, is very iffy.
2014-11-09T17:42:32Z nyef: I would suggest that it only "works" on PPC by accident.
2014-11-09T17:42:51Z stassats: if the registers are innocuous enough
2014-11-09T17:43:00Z nyef: Right.
2014-11-09T17:43:08Z nyef: And PPC has more registers to be innocuous with.
2014-11-09T17:43:12Z stassats: maybe it's not called? let me check
2014-11-09T17:43:19Z nyef: Hah!
2014-11-09T17:43:48Z stassats: it's not
2014-11-09T17:44:14Z nyef: Not in this case, maybe.
2014-11-09T17:44:34Z stassats: this is the only case where do_pending_interrupt is used
2014-11-09T17:45:15Z nyef: Hrm.
2014-11-09T17:45:33Z nyef: Still seems iffy at best.
2014-11-09T17:45:34Z stassats: could it be because of the blocked gc signals?
2014-11-09T17:46:49Z stassats: or pa is not set
2014-11-09T17:46:57Z stassats: not tripped
2014-11-09T17:47:08Z stassats: don't want to recompile the whole shebang to check, though
2014-11-09T17:47:27Z stassats: maybe i can check it from [gl]db
2014-11-09T17:49:57Z stassats: if we decided that we don't need a gc there, we may dispense with do_pending_interrupt
2014-11-09T17:50:14Z jlarocco joined #sbcl
2014-11-09T17:50:35Z stassats: we probably do need it
2014-11-09T17:50:37Z snafuchs quit (Ping timeout: 260 seconds)
2014-11-09T17:51:01Z snafuchs joined #sbcl
2014-11-09T17:55:32Z stassats: pseudo_atomic_bits = 1362952193
2014-11-09T17:56:32Z stassats: that would be interrupted
2014-11-09T17:57:02Z stassats: but there's no whiff of the trap being delivered, so, signal blockage?
2014-11-09T17:57:05Z nyef: ... That seems an odd value, but I don't remember how the pa mechanism is implemented on all the platforms offhand...
2014-11-09T17:57:23Z kanru` quit (Ping timeout: 250 seconds)
2014-11-09T17:58:05Z lacedaemon quit (Ping timeout: 260 seconds)
2014-11-09T17:58:18Z fe[nl]ix joined #sbcl
2014-11-09T17:59:05Z stassats: it's probably something unitialized, we only used lower bits
2014-11-09T18:00:14Z nyef: Okay, I can see that, especially using a random dword-aligned value as a "clear" value.
2014-11-09T18:00:23Z edgar-rft quit (Quit: continuation expired by nuclear meltdown)
2014-11-09T18:00:47Z stassats: but some places set it to 0
2014-11-09T18:00:49Z stassats: go figure
2014-11-09T18:01:04Z stassats: anyhow, 1 is set
2014-11-09T18:01:33Z stassats: when a signal is blocked, where does the control return after a trap?
2014-11-09T18:02:04Z stassats: is reg_ZERO our own contraption?
2014-11-09T18:04:19Z stassats: yep, that explains why twllei	reg_ZERO, trap_PendingInterrupt does not work
2014-11-09T18:05:07Z jlarocco quit (Quit: This computer has gone to sleep)
2014-11-09T18:05:51Z fe[nl]ix quit (Read error: Connection reset by peer)
2014-11-09T18:06:01Z fe[nl]ix joined #sbcl
2014-11-09T18:07:11Z stassats: so much fun
2014-11-09T18:14:00Z nyef: Typical. There's just so MUCH buried treasure in these backends, some dating back to before they were created.
2014-11-09T18:14:45Z stassats: fixing do_pending_interrupt and conditionally calling fake_foreign_function_call is clear
2014-11-09T18:14:54Z stassats: what to do with gc signals blocking on ppc now?
2014-11-09T18:15:49Z nyef: First two questions are "why are they blocked" and "is it safe to unblock them".
2014-11-09T18:16:29Z stassats: non ppc code path blocks all blockables and then unblocks the gc signals specifically
2014-11-09T18:17:02Z lacedaemon joined #sbcl
2014-11-09T18:17:13Z fe[nl]ix quit (Ping timeout: 260 seconds)
2014-11-09T18:17:56Z nyef: You might need to audit the entire interrupt-blocking system and its uses to figure out what's what. /-:
2014-11-09T18:22:38Z stassats: so, how do i unconditionally trap?
2014-11-09T18:23:14Z stassats: ok, trap "Trap Unconditionally" is staring at me
2014-11-09T18:34:51Z stassats: ok, no handler for signal 5
2014-11-09T18:34:56Z stassats: so, it's called, now to handle it
2014-11-09T18:49:52Z stassats: whaddayaknow
2014-11-09T18:50:06Z stassats: actually running the gc unblocks the signals
2014-11-09T18:50:19Z stassats: Heap exhausted (no more space for allocation).
2014-11-09T18:50:28Z stassats: an actual lisp error
2014-11-09T18:50:29Z stassats: yay
2014-11-09T18:50:31Z stassats: that's ppc
2014-11-09T18:50:40Z nyef: So, progress, or even everything "working"?
2014-11-09T18:51:09Z stassats: what if there's no gc pending and it still wants to bail out?
2014-11-09T18:51:22Z stassats: everything _seems_ to be working
2014-11-09T18:51:47Z stassats: but i didn't fix maybe_gc on ppc, yet it works
2014-11-09T18:52:34Z stassats: and after fixing maybe_gc on arm, it doesn't work
2014-11-09T18:52:44Z stassats: blockables unblocked
2014-11-09T18:53:10Z nyef: Maybe some difference in how the sigaction is set up?
2014-11-09T18:53:30Z nyef: Or some other detail about signals masked or not masked in signal handlers?
2014-11-09T18:53:51Z stassats: strange
2014-11-09T18:53:59Z stassats: it didn't even reach the previous point
2014-11-09T18:54:04Z stassats: the point i had changed
2014-11-09T18:56:58Z stassats: no, it does reach it
2014-11-09T18:57:04Z stassats: it's after maybe_gc
2014-11-09T18:57:10Z stassats: sigh
2014-11-09T18:57:37Z stassats: undo_fake_foreign_function_call calls block_blockable_signals
2014-11-09T18:57:48Z stassats: i mean, are you kidding me?
2014-11-09T19:00:17Z stassats: it's never going to be correct, is it?
2014-11-09T19:00:25Z stassats: how something incomprehensible can be correct?
2014-11-09T19:02:44Z stassats: am i the only one who wants to tear it down and rewrite?
2014-11-09T19:03:32Z nyef: No, you're not.
2014-11-09T19:03:46Z nyef: But a full rewrite is not the right action to take.
2014-11-09T19:04:07Z nyef: The "right thing" is to preserve the "old" sigmask (or sigmasks) and restore them during undo.
2014-11-09T19:04:09Z stassats: at least interrupts and threads
2014-11-09T19:04:25Z stassats: why does ppc work now?
2014-11-09T19:05:13Z nyef: Here's another "obvious" issue with interrupts: "deferrable" signals are those signals for which we install a lisp-side handler. This set should be DYNAMIC, added to as we install lisp-side handlers, and removed-from as we uninstall lisp-side handlers.
2014-11-09T19:05:29Z nyef: There's a specific use-case which calls for SIGCHLD to not be deferred.
2014-11-09T19:06:02Z nyef: (Because it gets handled by a C library.)
2014-11-09T19:09:01Z stassats: yay, SB-KERNEL::HEAP-EXHAUSTED-ERROR on arm now
2014-11-09T19:09:34Z stassats: can continue as well
2014-11-09T19:09:39Z stassats: ok, ship it
2014-11-09T19:10:50Z nyef: For your next trick, SPARC?
2014-11-09T19:11:59Z stassats: i don't have it
2014-11-09T19:12:07Z stassats: and it's so broken i don't want to deal with it
2014-11-09T19:12:30Z nyef: Heh. Really?
2014-11-09T19:12:34Z nyef: Neat.
2014-11-09T19:12:44Z stassats: signals on sparc may arrive without a context
2014-11-09T19:12:51Z nyef: ... In Linux?
2014-11-09T19:13:07Z stassats: no, that was solaris
2014-11-09T19:13:45Z stassats: but yeah, i guess it could be fun
2014-11-09T19:13:49Z stassats: i'm now thinking about arm64
2014-11-09T19:13:50Z nyef: I'm somewhat less concerned about non-linux systems than I am about the compiler backend.
2014-11-09T19:14:17Z nyef: ARM64 should be easier to add thread support to than ARM32.
2014-11-09T19:14:26Z nyef: Purely on the strength of the available register set.
2014-11-09T19:14:43Z stassats: should be faster too
2014-11-09T19:16:40Z nyef: Really, what I want to see is all of the non-x86oid backends up to the same standard of "expected to work" and feature parity where possible.
2014-11-09T19:17:37Z stassats: arm and ppc are up there
2014-11-09T19:17:51Z nyef: If that means that DX allocation doesn't work on Alpha32, that's fine. If it means that Alpha32 doesn't support gencgc, that's not.
2014-11-09T19:19:01Z stassats: ok, pushed my changes
2014-11-09T19:19:19Z pkhuong: just kill alpha
2014-11-09T19:19:37Z stassats: nyef: maybe you should write an alpha emulator
2014-11-09T19:20:00Z stassats: i wonder if the arm change breaks ppc, didn't cross test
2014-11-09T19:20:14Z nyef: pkhuong: But I have a dual-cpu alpha system just waiting for a set of hard drive rails... or for me to figure out how to net-boot it with a network filesystem or network block store for the root disk.
2014-11-09T19:21:01Z stassats: the speed up for char-downcase is even nicer on ARM
2014-11-09T19:21:02Z nyef: stassats: No "maybe" about "should write an alpha emulator", although IIRC I only got as far as it trying to exit PALmode for the first time.
2014-11-09T19:21:31Z stassats: incidentally, i got access to POWER8
2014-11-09T19:21:52Z nyef: I did an experiment to see how well it would work if implemented in CLWEB, and that was pretty cool.
2014-11-09T19:22:37Z stassats: implementing gencgc on arm was a weekend deal or something similar
2014-11-09T19:22:39Z stassats: plus residual bugs
2014-11-09T19:22:59Z stassats: like the one today
2014-11-09T19:23:59Z nyef: Mmm. I'm expecting similar for MIPS, along with a LOT of rough edges, stale bits of code that haven't been updated since they were first implemented around 22 years ago, and such.
2014-11-09T19:24:11Z nyef: On the other hand, my good MIPS system doesn't run Linux.
2014-11-09T19:24:25Z stassats: and i think the decision to use alloc_tramp instead of a signal was a good one
2014-11-09T19:25:24Z stassats: are deferred signals handled by do_pending_interrupt?
2014-11-09T19:25:37Z nyef: Should be, IIRC.
2014-11-09T19:25:56Z stassats: on the one hand, doing anything when the heap is exhausted is not a good idea
2014-11-09T19:25:58Z nyef: Yeah, it's not the PAI path, but it IS the path taken for the end of WITHOUT-INTERRUPTS.
2014-11-09T19:26:23Z nyef: On the other hand, doing anything complex from an interrupt-handler is ALSO not a good idea.
2014-11-09T19:26:23Z stassats: but on the other, if we expect sb-kernel::heap-exhausted-error to be handled, we might expect everything to work
2014-11-09T19:27:15Z stassats: eh, with full time work on SBCL many things could be sorted out
2014-11-09T19:28:17Z nyef: On the one hand, I'd love to have that kind of time to dedicate to SBCL. On the other hand, I'd also like to be dedicating it to OTHER things.
2014-11-09T19:28:57Z stassats: well, i mean, the money kind of full time work
2014-11-09T19:29:38Z nyef: You mean... subsidized full-time work?
2014-11-09T19:30:35Z nyef: If someone didn't have to work for a living, and they decided to work on SBCL full-time or even "part-time" (meaning 20 hours a week), it'd be pretty much the same effect.
2014-11-09T19:30:53Z stassats: it's not that motivating
2014-11-09T19:31:40Z stassats: if i didn't have to work for a living i'd probably forget about computers
2014-11-09T19:32:43Z nyef: If I didn't have to work for a living, I'd be working on my own projects, which include SBCL hacking.
2014-11-09T19:33:27Z nyef: It'd likely be a "seasonal" thing, meaning that it comes and it goes, but the "on" seasons would likely be a bit more intense than I currently manage.
2014-11-09T19:35:09Z lacedaemon quit (Ping timeout: 260 seconds)
2014-11-09T19:35:19Z fe[nl]ix joined #sbcl
2014-11-09T19:35:42Z stassats: i'd like to hire minions to debug sbcl
2014-11-09T19:37:17Z stassats: debugging assistants
2014-11-09T19:55:15Z stassats quit (Ping timeout: 250 seconds)
2014-11-09T19:56:18Z prxq joined #sbcl
2014-11-09T20:00:44Z leuler: I just happened to look through some disassemblies on x86-64. SB-IMPL::SYMBOL-QUOTEP has grown out of proportion with UPPER-CASE-P and LOWER-CASE-P being much larger now.
2014-11-09T20:00:55Z leuler: Maybe these functions should no longer be inlined, at least here, and/or SYMBOL-QUOTEP should call a local function in the macro expansion of ADVANCE.
2014-11-09T20:01:00Z leuler: Should this be dependent on the unicode feature in the build?
2014-11-09T20:05:43Z oleo__ joined #sbcl
2014-11-09T20:07:11Z oleo is now known as Guest37634
2014-11-09T20:07:45Z oleo__ quit (Read error: Connection reset by peer)
2014-11-09T20:08:03Z Guest37634 quit (Ping timeout: 258 seconds)
2014-11-09T20:11:33Z oleo__ joined #sbcl
2014-11-09T20:11:54Z oleo__ is now known as oleo
2014-11-09T21:34:12Z pkhuong: leuler: works for me.
2014-11-09T21:34:26Z pkhuong: In fact I'd like to see benchmarks with almost all inlining disabled
2014-11-09T21:35:01Z pkhuong: I'm pretty sure most of our inlining is useless or just laziness for code generation
2014-11-09T21:55:00Z prxq quit (Ping timeout: 264 seconds)
2014-11-09T22:24:34Z angavrilov quit (Remote host closed the connection)
2014-11-09T22:26:26Z attila_lendvai quit (Quit: Leaving.)
2014-11-09T22:27:17Z nyef: Maybe we should have conditional inlining, where we only inline if there's a distinct VOP cost saving over a full-call OR the inlined code is "more specialized" than the full generic version? That might be a bit difficult to specify and implement, though.
2014-11-09T22:29:57Z csziacobus joined #sbcl
2014-11-09T22:37:43Z csziacobus: would it be possible to move docstrings into a seperate file instead of reader conditionalizing?
2014-11-09T22:39:40Z |3b| wonders if i will have any better luck with win32/win64 sbcl this time
2014-11-09T22:41:43Z leuler: pkhuong:, nyef: I need to go now. Sorry for starting a discussion and then not continuing ...
2014-11-09T22:41:43Z |3b|: and if not, how hard it would be to find/fix the problems
2014-11-09T22:41:48Z leuler quit (Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs))
2014-11-09T22:42:58Z nyef: csziacobus: You mean having a file with a whole lot of (setf (documentation ...) ...) forms?
2014-11-09T22:43:42Z csziacobus: nyef: yeah, something like that, having it all in one place instead of ad hoc forms, similar to how SICL does it
2014-11-09T22:53:39Z csziacobus quit (Quit: csziacobus)
2014-11-09T22:58:07Z csziacobus joined #sbcl