libera/#clasp - IRC Chatlog
Search
11:29:10
yitzi
Bike: Absolutely. There are some x86 C declarations around, but it seems doable to me.
12:42:24
cracauer
There seems to be a change in Mac's brew's openvpn that makes it fail to start for me.
13:01:49
Bike
the bytecode compiler is generating mismatched mv/stack states at merge points... grr...
14:20:11
yitzi
You'll need to pull it and rerun koga. It pull pull a different asdf branch. It changes uiop:compile-file* for all build methods. Should be atomic for all.
14:22:43
yitzi
No. It leaves the silliness of the other implementations alone. It makes COMPILE-FILE* = COMPILE-FILE for Clasp, basically.
14:30:56
yitzi
The changes to ASDF are here: https://gitlab.common-lisp.net/yitzchak/asdf/-/compare/master...clasp-bytecode-2?from_project_id=46
14:34:32
drmeister
By "You'll need to pull it and rerun koga" - do you mean I pull recent changes to clasp - or that I go into src/lisp/modules/asdf and pull that branch?
14:38:47
yitzi
Pull the bytecode-asdf branch of clasp and then rerun koga. After that your asdf branch should be clasp-bytecode2
15:36:18
drmeister
1. On owlsnest I can ql:quickload the systems that were causing problems when multiple processes tried to build them at the same time and the multiple processes do not have a problem.
15:37:09
drmeister
I was not 100% certain about this because I was running with bytecode for my interactive session and using faso/fasp files for the multiprocessing and that was confusing my experiments.
16:16:19
drmeister
apptainer is annoying because unlike docker - it always starts from the beginning
18:58:44
yitzi
Do you have the paste from the sclasp normally? Maybe it is getting stuck on linking.
19:17:00
drmeister
I ran the sclasp-boehmprecise build on zeus just before this and it finished fine.
19:26:52
yitzi
I'll run the build on my laptop. That way I can kick the fans into high gear and pretend that I am flying jet.
19:32:19
drmeister
I started the apptainer build for the fourth time. I did `export CLASP_SNAPSHOT=1` before I started it. Hopefully the environment will propagate into the apptainer build.
19:34:06
bike
there's nothing obvious in the logs so far except that jupyterhub was erroring and restarting every so often
19:36:35
yitzi
Why don't you remove tljh? Its not being used right? My term is over on Wednesday so I should have time to figure how to do a manual install or get tljh to work.
19:43:18
drmeister
yitzi: Does apptainer run cando as a regular process? Can I connect to it with udb?
19:46:13
yitzi
because the last thing printed on your paste comes from snapshot_save_impl and the next thing that prints from is prepareRelocationTableForSave. I can see it here https://plaster.tymoon.eu/view/3804#3804
19:47:35
yitzi
Don't know about connecting to it udb. I would guess you have to run udb in apptainer?
19:49:59
drmeister
The apptainer build is currently building C++ code and there are lots of clang++ processes running.
20:15:16
drmeister
The apptainer build is at the point where it hangs and it's currently using about 100% CPU
20:18:37
drmeister
yitzi: To enable DBG_SL_STEP and the other macros in that file you uncomment them one at a time.
20:41:36
drmeister
I started a jupyterlab kernel and it started up and built all the quicklisp code and then I started a second one and it's building everything again.
20:48:15
drmeister
yitzi: Have you tried the new asdf changes with jupyterlab building with faso/fasp?
21:11:39
drmeister
yitzi: When I look at the ASDF output - I see fasl and fasp files - I thought they should be faso and fasp files?
21:21:55
bike
so here's my first thought - what if asdf is expecting fasl files, doesn't see any, builds fasps. then fasps are in the cache, but asdf is only expecting fasls, so asdf will keep building again
21:27:27
drmeister
I must have run using bytecode accidentally before - now there are just fasp files.
21:34:53
drmeister
No - the ASDF changes yitzi made work for bytecode but they don't work for faso/fasp, which is what I need for speed.
21:40:49
drmeister
(compile-file-pathname "test.lisp") -> #P"/home/meister/Development/cando/test.fasp"
21:47:22
bike
yeah, ok. so maybe try removing the clasp specifics there? so that it doesn't pass output-type
21:47:54
bike
looking at yitzi's changes, i think they basically stop specifying :output-type in the compiler
21:48:11
drmeister
I'm running clasp (building quicklisp code) to see what `cando -f generate-bytecode --base` generates when I use (compile-file-pathname i :output-type :object)
22:01:18
bike
by the way, i stuck the bytecode compilation stuff in a repo https://github.com/clasp-developers/bytecode-to-bir it's private, but i think that mean anyone in clasp-developers can see it
22:04:49
drmeister
There is a difference - when running with `cando -f generate-bytecode --base` (compile-file-pathname "test.lisp" :output-type :object) -> "test.fasl".