libera/#sicl - IRC Chatlog
Search
7:29:06
ln43
everything ok, but during the boostrapping, using (defparameter *b* (boot)), i get: Loading file #P"e:/Users/xyz/portacle/all/quicklisp/local-projects/Acclimation/language-japanese.lisp" into E5
7:31:27
ln43
#<SB-SYS:FD-STREAM for "file e:\\Users\\xyz\\portacle\\all\\quicklisp\\local-projects\\Acclimation\\language-japanese.lisp" {100B347833}>:
7:32:30
hayley
I'd expect the file to be encoded using UTF-8. Let's see how you change the default encoding in SBCL...
7:37:46
ln43
now i' looking the sbcl docs about setting the default external format (8.1 The Default External Format) but if i try to set that global variable i get: Symbol "*DEFAULT-EXTERNAL-FORMAT*" not found in the SB-EXT package.
7:59:12
ln43
it's like for problems that without a known solution is difficult to figure out what to do
8:13:17
ln43
ok so maybe i should modify something inside Portacle to use something like (setq slime-lisp-implementations (sbcl ("/opt/sbcl/bin/sbcl") :coding-system utf-8-unix))
8:34:09
jdz
ln43: I think that will only change the encoding used by Emacs to communicate with the SBCL process, not the encoding SBCL will use when reading files.
8:49:26
ln43
initially i was installing only the dependencies listed here https://github.com/robert-strandh/SICL
8:56:49
beach
ln43: There is not much anyone can do with SICL at the moment, so it doesn't seem important to keep the information accurate.
8:59:15
ln43
ah ok, it was missing here: https://github.com/robert-strandh/SICL/blob/master/get-dependencies.sh
11:07:06
heisig
Hello mfiano! Yes, the number of SIMD related SBCL bugs is getting closer and closer to zero :)
11:09:10
heisig
mfiano: Have you seen Bela's recent benchmark: https://programming-language-benchmarks.vercel.app/problem/spectral-norm ?
11:18:35
mfiano
I shared it in #lifecafe yesterday. I thought the sight of seeing solely rust above lisp would be enough to annoy hayley enough to try optimizing a few ms :)
11:19:11
heisig
That will make for some very interesting discussions with my fellow C++ programmers :)
11:20:44
heisig
Oh, my train will arrive soon. See you guys later. But yes, I am suddenly very motivated to add a few more micro-optimizations :)
12:00:58
hayley
To some extent, I am absolved of micro-optimizing AVX code, as my desktop uses a Zen 1 processor and thus only does vector ops 128 bits at a time.
12:04:04
hayley
A pity, but I would not have understood what I got into by buying Zen 1 early in 2018 I guess.
12:07:30
mfiano
i dunno what i'm talking about though. just found it interesting. i am too used to lisp with its tagged pointers ruining my day
12:09:18
mfiano
https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/ for example
12:10:11
hayley
I'd have to check, but any larger integer type is "emulated" the same way i128 is, surely.
12:26:25
hayley
Speaking of things mfiano annoyed me with, he also reminded me to poke at the Luckless hash table some more. I got it to about 80% the performance of NonBlockingHashMap, regardless of thread count.
12:27:31
hayley
However, my very precise and safe way of handling integer overflow was just to use (safety 0) which I wouldn't really support for such a complex data structure.
12:29:33
hayley
What I ended up doing for 42nd at Threadmill was to use (safety 1) and specifically disable bounds checks on SBCL, as the compiler does not seem to detect that the probing loop only produces valid indices.
13:56:28
lonjil
LLVM technically speaking supports basically any bit size integers, unfortunately the support library for doing math with them doesn't support anything beyond 128 bits for anything except bit-wise ops.
13:59:41
mfiano
I was only half joking when I said Lisp ruined my day. Nothing inlining or #0ANUM etc can't help with
15:29:55
pjb
An array that is not an array (it has no dimension), containing a number that is not a number! (read-from-string "#0A1D+-0") #| --> #0A1D+-0 #| not-a-number |# ; 8 |#