libera/#clasp - IRC Chatlog
Search
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".
22:17:31
drmeister
So, they are being deleted then - and since they are being deleted, asdf is generating them every time.
22:27:30
drmeister
quicklisp/asdf rebuild everything again and again when :build-mode :faso is used.
22:30:17
drmeister
In :build-mode :faso (compile-file-pathname "x.lisp" :output-type :object) -> "x.faso")
22:30:25
drmeister
In :build-mode :faso (compile-file-pathname "x.lisp" :output-type :fasl) -> "x.fasp")
22:39:10
drmeister
If I edit lisp-action.lisp and then in src/lisp/modules/asdf I run make - that's all I need to do - right?
22:41:24
drmeister
I start `cando --base` and it starts building trivial-with-current-source-form and then esrap.
22:41:48
yitzi
You edit lisp-action then you go into src/lisp/modules/asdf and run make. then ninja -C build in the root
22:46:22
yitzi
Looks like there is work to do in the bundle-op stuff. I don't think quicklisp is using that.
23:00:22
drmeister
https://github.com/clasp-developers/clasp/blob/bytecode-asdf/src/gctools/snapshotSaveLoad.cc#L2356
23:01:42
drmeister
This asdf thing couldn't be effecting the apptainer build could it? I think there's almost zero chance of that.
5:08:09
drmeister
There's still a problem in the apptainer build running multiple cando processes all trying to build quicklisp code at the same time.
5:14:39
drmeister
In that last case I started six jobs (72 processes) and one job remained in the end - five died.