libera/#clasp - IRC Chatlog
Search
16:37:06
drmeister
All the header files are in /usr/include/c++/12 and the compiler is looking in /usr/include/c++
16:37:48
bike
anyway - if you didn't see the google chat - i have the planner writing out derivatives now. if you want something else to look at for a bit
16:48:40
drmeister
The clasp build was working last week so I'm doing partial apptainer builds for clasp and cando and then check what is different.
16:53:26
drmeister
I can't develop the spiroligomer design stuff if I can't run on the cluster because I need the data from the cluster run to work on clustering and connecting spiroligomer parts together.
16:57:24
drmeister
Ubuntu arbitrarily drops support for "kinetic whatever" for "lunar whatsit" and then I have to spend days trying to figure out what is broken with their damn packaging.
16:57:58
drmeister
And you try googling for this stuff. Just try. You get 20 years of "I can't install xxx on yyy".
17:20:59
drmeister
The clasp apptainer clang++ searches these directories and the cando apptainer clang++ does not.
19:05:57
drmeister
yitzi: If I apt-get install emacs AFTER cando builds - that should work better - right?
19:06:23
Colleen
yitzi: drmeister said 2 hours, 49 minutes ago: On zeus the apptainer build has fully broken again. I'm setting it up to do everything right up to ninja build and then I'll poke around. conda isn't installed at that point - do you have any other insight why it might be broken and sometimes work?
19:06:36
drmeister
Why am I installing emacs? On the cluster everything is so old that emacs is also old and doesn't do a lot of stuff that I need.
19:11:39
drmeister
I'm going to use the clang-15 rather than clang-16. I switched to clang-15 to make it more similar to the clasp build and I don't want to mess with this anymore.
19:13:37
yitzi
ok, but keep in mind that clang-16 probably the default on lobster. If something breaks that would be the first place I would look.
19:52:07
drmeister
Yeah - but why does the clasp build work but not the cando build? Now the packages they install are identical I need to do some more comparison to the clasp apptainer build.
19:57:11
drmeister
I tried building with llvm-15 and llvm-16 and it failed on both. Going back to the clasp build to see if that works.
20:00:35
yitzi
I am trying to compile Clasp on Linux ARM and just spent an hour trying to debug atomics, when the issue was a letter "z" that mistakenly typed into the :THREADS feature keyword.
20:00:38
drmeister
Should I change the mygc.c file to a mygc.cc file? Then the path will be correct.
20:16:39
drmeister
I'm not removing the build-apptainer directory each time - could that be messing with me?
20:22:21
drmeister
Doing the same thing over and over again and hoping for a different result = insanity
20:22:29
yitzi
On my keyboard the z is right above the "windows" button which I push a lot cause I use gnome desktop. So the z shows up as a typo a lot.
20:22:52
drmeister
Doing something over and over again with very, very, very small changes = developing an apptainer build system.
20:35:23
drmeister
I wiped it out and started the cando apptainer build again and this time it got through the C++ compilation.
20:42:55
yitzi
Yep. The Linux one is building under an emulator on my Linux Box. the M1 is on my Mac Book Pro
20:43:31
drmeister
yitzi: There was an issue with libunwind in MacOS that I thought needed to be resolved by Apple before we could do that. What did you do?
20:45:05
yitzi
I don't remember what the libunwind issue was. I did not do much. There were some weird errors that I initially attributed to calling convention. I eventually gave up and tried the Linux ARM instead and I think that forced me to go through the #ifdef and make sure the logic was right.
20:45:22
drmeister
In principle MacOS Ventura has the libunwind library fixed well enough that we could build on M1 but I didn't move because there was a complication.
20:46:43
yitzi
The main thing that you need the arm llvm etc, so you need the appropriate homebrew. You can bootstrap from a x86 sbcl though.
20:56:49
bike
mostly the trampoline stuff and fixing up features. i'm kind of surprised all the calling convention stuff apparently works.
20:59:44
drmeister
Adding multiple entry points removed a LOT of headaches for supporting other calling conventions.
21:04:29
bike
this is apropos of nothing, but i was working on CVM today, and got everything working with FDEFNs. how hard would it be to support them in clasp? the idea is basically like the class-holders but for function definitions.
21:07:10
bike
i mean, i can take care of it on the compiler end, i'm just wondering about the runtime
21:19:27
drmeister
What are they again? Do they help with hot swapping functions? Do they insert an indirection in calling?
21:22:13
bike
it's basically the same as the class holders. when you compile a call like (FOO), that ends up as (funcall #<FDEFN>) essentially, and then whenever you do (setf fdefinition) on foo it updates the fdefn.
21:22:32
bike
it shouldn't add an indirection. it should let us remove the function sell cell from symbols without slowing anything down
21:29:17
bike
yeah, cos we could put the fdefns in a global hash table or something instead, without requiring a lookup very often (there would be a lookup when doing fdefinition of an unknown symbol, but that's uncommon)
21:33:09
bike
i think the basic advantages for us are (a) it's a step closer to first class environments, which have various uses like sandboxing, and (b) right now every time you gensym it allocates two "undefined function" functions, which is a surprisingly big slowdown during bytecode compilation
22:08:32
bike
oh, and i guess another advantage is that it should make setf function lookups a bit faster, since right now we have to flip through the (setf foo) cons and such
22:49:24
yitzi
Figuring out how to chroot into a ARM qemu emulator was a major accomplishment today. Not sure I wanna test the VM anymore then that.
23:00:25
yitzi
cl-bench crashed with some kind of rosetta error for the M1 build. So there a few issues, but pretty minor so far.
23:28:26
yitzi
crap....now I am getting the same error that made me think there was a calling convention problem. Bugger.
23:36:08
drmeister
There shouldn't be any calling convention issues because with multiple entry points we get the efficiency of messing with the calling convention without actually messing with the calling convention.
23:37:24
yitzi
It may not be. Its like there is random junk being passed instead of the proper arguments. Get it first in the compilation of generated-encodings.lisp
23:38:38
yitzi
Well, made progress... but I think that the x86 llvm got used by mistake in the many koga invocations.
23:39:53
drmeister
https://undo.io/about-us/undo/news/undo-software-deliver-support-64-bit-arm-devices#:~:text=UndoDB%20can%20be%20used%20in,fix%20bugs%20much%20more%20quickly.