Search
Saturday, 22nd of September 2018, 12:45:32 UTC
13:15:11
stassats`
the default debian repository location is too slow
13:15:21
stassats`
i think i'll be installing the packages 10 hours
13:16:46
stassats`
don't know how many are left and whether restarting is going to speed it up
13:18:29
Xach
stassats`: i can build the image and push it to docker hub, then you can just get that
13:19:30
Xach
ACTION kicks off the process
13:28:21
stassats`
sparc-funcdef.sh is doing nothing
13:30:51
stassats`
not that fixing it helps anything
13:31:41
stassats`
always love /* FIXME */, fix what?
13:33:22
stassats`
now to remember when was the last time i built sparc-solaris
13:33:47
adlai
s/FIXME/It can easily be shewn that.../
13:34:07
stassats`
judging by https://bugs.launchpad.net/sbcl/+bug/1248181, in 2013
13:36:16
stassats`
and a94d7288b6ea5c9fa46b3788600f835b6c6f5efb is after that, bingo
13:39:31
stassats`
sparc-linux builds fine, just not with 1.0.28
13:39:53
stassats`
yet that's what we provide
13:42:01
stassats`
bet i won't be able to build sparc-solaris for at least that reason too, using 1.0.23
13:43:33
Xach
stassats`: I think you can pull quicklisp/quicklisp-base:debian8 and get a starting point. it is pretty big too though.
13:45:28
stassats`
let's see what finishes first
13:46:04
stassats`
that pulls at over 10MB/s
13:46:09
stassats`
compared with 200KB/s
13:52:03
stassats`
ugh, now i'm fumbling with docker
14:02:12
stassats`
or was that for the host
14:02:55
stassats`
The value #(0 0 0 0) is not of type (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (65536))., right sparc-solaris doesn't build with 1.0.23
14:15:21
stassats`
trying to crank it, but things aren't going well
14:15:30
stassats`
arithmetic error DIVISION-BY-ZERO signalled
14:15:42
stassats`
after printing everything as Removed:
14:16:27
stassats`
ok, the mounts appear to be incorrect
14:42:48
stassats`
ok, wrangled docker more, cranking
14:52:55
stassats`
github seems to be slow as well, still updating
15:11:13
stassats`
i think i'm rate limited by github
17:00:21
stassats
ugh, cl-ftp errored out while i was out and i didn't get much progress
21:04:04
Xach
http://report.quicklisp.org/2018-09-22/failure-report.html shows a lot of new problems
21:05:19
Xach
looks like it's a lot of internal package fallout
21:06:25
Shinmera
yay, one of mine was hit
21:20:36
stassats
Shinmera: can't you use the cycle counter from SB-EXT:CALL-WITH-TIMING?
21:21:39
Shinmera
probably could, I just dug through what time does to do what's failing now
21:23:31
stassats
failed AVER: (GETHASH SB-PCL::GF (SB-PCL::METHOD-COMBINATION-%GENERIC-FUNCTIONS SB-PCL::OLD-MC)) is newish but not new
21:36:26
stassats
Shinmera: i can export from sb-sys
21:39:02
Shinmera
The sbcl-specific stuff is here. I don't know if there's already exported ways to do the same https://github.com/Shinmera/trivial-benchmark/blob/master/samples.lisp#L85-L138
21:39:41
stassats
SB-EXT:*GC-RUN-TIME* SB-KERNEL:*EVAL-CALLS*
21:39:58
stassats
sb-ext:get-bytes-consed
21:41:12
stassats
Xach: nothing involving the compiler, so I'm in the clear
21:41:29
stassats
and xmls-tools clearly broken
21:42:35
stassats
maybe consider using https://github.com/rpgoldman/xmls-tools ?
21:43:41
Shinmera
stassats: thanks! I don't think I can use call-with-timing, though, as trivial-benchmark does its own time diffing.
21:44:10
Shinmera
so it needs relative values to compare
21:44:32
stassats
ok, i'll export sb-sys, it's one notch above being completely internal
21:46:08
Shinmera
Will test tomorrow, off to sleep for now
21:53:29
stassats
you can continue using SB-IMPL::read-cycle-counter for compatibility with older sbcls
21:54:51
stassats
and UNIX-TO-UNIVERSAL-TIME i won't export, that's something that can be done without involving sbcl
Sunday, 23rd of September 2018, 0:45:32 UTC