freenode/#clasp - IRC Chatlog
Search
16:59:17
bendlas
does anybody have a current docker image? i'd like to take a look at how well MPS works, but am on a weak machine ..
17:05:35
bendlas
so, the cleavir in clasp .. do you co-develop that with sicl, or how does that work?
17:28:56
frgo
::notify attila_lendvai I would like to align with you on how we define a protocol for integrating extensions into the build process automatically.
18:08:55
beach
bendlas: Pretty much. Cleavir is an independent module of SICL, and I may break it out into a separate repository one day.
18:10:06
beach
bendlas: Cleavir is meant to be implementation independent and customizable, so what Clasp needs and that will fit into that goal, probably SICL needs as well.
18:30:50
kpoeck
I wonder a bit about the latest fix in disassembly.lsp https://github.com/clasp-developers/clasp/commit/83ea38b6c4bedff1959a9e7032d689cba50e020d
18:32:04
kpoeck
In the ansi-tests now every disassembly-test errors with There are no applicable methods of GET-NAME for receiver class CLOSURE-WITH-SLOTS
18:43:14
frgo
Hm, I can see the error, too. But I don't see what that commit has to do with that error.
18:49:25
Bike
frgo: i assume that switching the default to :asm takes the call down a different path.
22:44:02
drmeister
I ran into a bug with our mps implementation that only surfaced when the Ravenbrook folks added a few sanity checks - I've been dealing with that for the last two days.
22:44:48
drmeister
The Ravenbrook folks would like some more detail on what we would like for compiling MPS objects into fasl files and then reloading them.
22:45:11
drmeister
Since we don't have any capability like that right now I'm scratching my head on what to tell them.
22:47:16
drmeister
I was thinking if we could create separate MPS pools that we allocate objects within that we then get the address for and write out as data into an LLVM module. Then when we load the module we tell the MPS where that data is and it moves those objects into regular MPS memory.
22:53:59
drmeister
I don't want to dump all of the memory - just some of it. Everything associated with a compilation unit.
22:57:01
drmeister
The current approach generates code to build objects at load time. The objects are built as a side effect of evaluating the toplevel forms. For instance - a defclass generates code that builds a class. But we need the class definitions earlier at startup - to represent AST's for inlining for instance.
22:57:42
drmeister
I'd like a fasl that runs in an environment where all of the classes that would be constructed by the fasl are available at the beginning of evaluating the toplevel forms of the fasl.
22:58:18
drmeister
Our fasls evaluate every toplevel form in the order that they are found in the source code.
22:59:43
drmeister
Yeah - it's like a core dump - but I'm thinking something more selective. Where we can specify what goes into the core dump.
23:05:57
drmeister
If we reload a core - we wouldn't evaluate the top level forms at startup anymore - right?
23:06:50
drmeister
But we have a lot of side-effects that we will need to track down so that we can regenerate them at startup. C++ code that gets evaluated.
23:08:56
drmeister
I thought we could do something more selective - like save the memory effects of defclass in separate pools and write them out into the core/fasl file - then at load-time recreate the classes from the core data and then run the top-level forms in that environment while we eliminate the side-effects of 'defclass' at load time.
23:09:52
stassats
the only proper solution is to write to disk whatever you want to be in memory when you start up
23:12:44
stassats
drmeister: mps is probably not using a contiguous and amorphous blob of memory, so you need to identify all the regions and their respective metadata
23:16:35
drmeister
mps has these things called pools. I can specify the pools and the tables of roots.
23:20:07
drmeister
There are inter-pool pointers. There is an AMC pool for general objects, an AMCZ pool for objects that don't have internal pointers like strings - I think that's all that we really need.
23:23:39
drmeister
Then what? Write them out to a file descriptor? I think giving me back a start pointer and a size for a block of memory that I can use to write into an llvm Module - that would be ideal.
23:25:29
drmeister
Then I can write it into the Module as a big blob of bytes and when I reload the module I can call an mps function with the start and the size and it ... what? treats it like a block of read only MPS memory? Relocates the objects out into MPS memory? It would be good not to have this big useless block of memory around.