libera/#sbcl - IRC Chatlog
Search
13:48:46
stassats
i hope "Unhandled page fault on write access to 0000000000008060 at address 000000014001EE82 (thread 0009)" can be blamed on wine too
15:01:45
andrew77
@stassats yes, the unhandled page fault was due to freshly build sbcl not being able to locate, erm, its runtime (core and everything); run-sbcl.sh works just fine
15:31:23
andrew77
I've already worked the problem at hand around by unsetting SBCL_HOME, but thanks :)
15:32:39
andrew77
I'm currently dealing with the make-windows-installer script, and, oh my god, why on earth Wix?.. I mean, NSIS was always choice number 1 regarding building windows installers
15:33:18
andrew77
I mean, the damn thing needs .NET, which is entirely different level of PITA for wine
15:35:07
stassats
but what if, gasp, somebody is not using javascript? make it lead to a page with two links?
15:36:43
andrew77
Got it. Then installer it is:) I mean, it is fine for end user, it is just building of that which is troublesome
19:47:32
waleee
Is a large number of "Found string NIL" lines followed by "Found string "Can't displace an array of type ~/sb-impl:print-type-specifier/ ~
20:51:16
karlosz
i think its because during the script SB_XC_HOST gets some extra flags by default which are duplicated in slan
20:53:04
Krystof
it doesn't work; it has lisp-land flags --no-sysinit --no-userinit which come before the runtime flag --core
20:53:52
Krystof
so the --no-sysinit implicitly means "we're done with runtime flags", which means that the subsequent --core doesn't get interpreted by the runtime
21:00:47
stassats
i always run with an explicit lisp too, but i never run slam.sh, because it was broken for me too, but differently
21:02:35
karlosz
i suspect that its because ./make.sh autodetects the presence of sbcl and appends the flags to XC_HOST for you
21:05:09
stassats
it takes a minute to rebuild, so i usually avoid dealing with any slam-related problems by just waiting a bit
21:08:08
stassats
i often end up missing some required rebuild and wasting more time because of that
21:10:39
karlosz
we are privileged to have fast machines nowadays; its a good thing that sbcl build times have not increased faster than machines have gotten faster, like most software
21:11:23
stassats
i still use a cpu from 2013, it's about a minute there two, when using multiple threads
21:12:43
karlosz
must be a fast one then. i usually just build single threaded on laptop cpus. I used to try multithreaded builds, but sometimes they would give weird errors
21:13:12
stassats
because fork() is too slow there anyway, but not using fork doesn't significantly speed it up, so didn't bother upstreaming the changes
21:14:34
karlosz
yes, my main concern is the different generated code for a multithreaded build compared to single threaded ones, due to compile time side effects
21:15:34
karlosz
Krystof told me that his alpha (or maybe hppa) builds used to take a whole day, for perspective
21:16:46
karlosz
just shows you how different cpu speed growth is between 2000 -> 2013 and 2013 -> 2022 i guess
21:18:34
karlosz
m1 seems worth it just for the power savings; running sbcl builds drains battery quite fast
21:25:45
Krystof
alpha and sparc were a nice cadence: set a build off, do some Actual Work, come back to the build log when taking a break