IRC channel logs

2020-01-12.log

back to list of logs

<ilikeheaps>Is it easy to make one's own Guix installer? For starters just changing default keyboard layout. I think I found the installer's definition: https://github.com/lfam/guix/blob/master/gnu/system/install.scm
<ilikeheaps>Is it just as easy as modifying that and making a disk image with `guix system`?
<ilikeheaps>(I guess linking the main repository would be more reasonable: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm )
<ilikeheaps>Oh geez, I thought I had a different channel open, sorry for that
<NieDzejkob>yeah, just `guix system disk-image /path/to/install.scm' iirc
<NieDzejkob>possibly with some --file-system option
<NieDzejkob>I had to do that to use a non-libre kernel and make my wifi work :/
<oriansj>I guess it was techinically related in the using guix to bootstrap your own installer image
<ilikeheaps>Thanks!
<oriansj>ilikeheaps: hopefully making something fun?
***ng0_ is now known as ng0
<oriansj>janneke: this one might be more fun: (while (< 1 (free_mem #t)) (begin (free_mem) (display #\newline)))
<oriansj>it takes a prime number of cells per loop and only stops when you get to exactly ZERO free cells; thus hitting garbage collection in multiple points
<oriansj>(5 to be exact)
<NieDzejkob>why is primality notable/desirable here?
<oriansj>makes for a wonderful garbage collection test; ensures that if you free up one too many cells it will produce different output and fail a test but if you free up one too few cells it will also produce different output and fail a test.
<oriansj>the loop only consumes exactly 5 cells, and you need to hit exactly 3 cells to terminate in exactly 2 loops with 1,000,000 cells (initialization eats up 3 cells per primitive)
<oriansj>and it also finally generated a result I have been trying to hit; worst case insert_ordered
<oriansj>because, it requires me to allocate exactly all of the memory, garbage collect all but the last cell and then garbage collect that last cell (hitting the stack limit of C and forcing me to turn it into an iterative form)
<oriansj>oh and patches are up
<oriansj>It is far better remove problems from being in the space of the garbage collection foundation as soon as possible (So correctness is essential for these primitives)
<oriansj>greetings apetresc
<oriansj>now to put some of the garbage collection optimizations back
<ilikeheaps>oriansj: well, nothing very interesting I think; just want to set the keyboard layout and enable wifi drivers with non-libre kernel to avoid the hassle every installation
<oriansj>The most important performance enhancement in mes-m2 garbage collection has been restored and enabled; patches are up
<oriansj>ilikeheaps: well that sounds like a useful skill to learn and share. I'm sure other people with with similar hardware problems find knowing how to do that quite interesting.
<oriansj>good news is the build and test time for mes-m2 on a 100Mhz 386 is only 40s
<oriansj>(when using M2-Planet+mescc-tools for the build)
<oriansj>or about 3seconds on a modern x86+gcc
<oriansj>garbage compaction is working again (with an approximate 7% improvement to performance net)
<oriansj>janneke: I think I have one more GOOD performance enhancement in mes-m2; lazy garbage collection.
<oriansj>although at this point, I feel like I am more timing the speed of bash than mes-m2
<oriansj>and MES_MAX_STRING is supported but defaulted to 4096 (because no s-expression should be longer than that)
<oriansj>(and add support for a growing arena)
<oriansj>and actually I have a silly idea; like really silly
<dddddd>those are the best ones :P
<oriansj>what if mes-m2's default pool size was just 1 cell?
<oriansj>now that it supports cheap expansion (like really cheap)
<oriansj>like 29 clock cycles per cell added cheap
<janneke>oriansj: that's great; exciting!
<janneke>sorry i don't have much time this weekend; enjoying the read-up though
<oriansj>well with that tweak, mes-m2 now completes all tests in 0.43 seconds (when built by M2-Planet)
<oriansj>that is freaking crazy
<oriansj>from 16seconds to 0.43 seconds
<oriansj>and I have added baseline support for MES_DEBUG too while I am at it
<oriansj>patches are up
<oriansj>and make clean test spends 1.4 seconds compiling mes-m2 and 0.01 seconds to actually run all of the tests (Big drop from 70seconds with mes.c)
<vagrantc>so, can mes-m2 build "regular" mes ?
<oriansj>vagrantc: still need to add support for modules into mes-m2
<oriansj>it was more comparision between the performance of mes.c running the tests vs mes-m2 running the same tests
<vagrantc>just curious mostly :)
<oriansj>I'm still making progress, but I figured it was better to hammer out potential bugs in mes-m2's maxwell core before I go after adding support for modules
<oriansj>janneke: and I've added support for MES_MAX_TOKEN (the max string length for a name in mes-m2, currently at 4096 chars)
<oriansj>I might tweak it down to 64chars later; after we get MesCC running on mes-m2 (assuming nothing needs that sort of insane)