libera/#clasp - IRC Chatlog
Search
17:13:05
drmeister
yitzi: I'm doing `export CLASP_STAGE_COUNT=3` and then `ninja -C build load_cclasp-boehm`
17:25:00
yitzi
drmeister: try adding `(defun 1- (num) (- num 1)) (defun 1+ (num) (+ num 1))` to init.lisp
17:31:02
drmeister
It's when it tries to get the (file-write-date source-path) in clasp-builder.lisp:581
17:36:54
drmeister
You know what - I don't want to stop there. I had a goofy idea that we could run the static analyzer with just the bytecode compiler and I thought stopping at an earlier stage would be useful.
17:37:31
drmeister
What I do want to do is rebase or merge 'vm' into 'yitzchak_vm-lpt' - how do you recommend that I do that?
17:37:45
yitzi
I think that is a good idea, but I would feel better if we could fix one thing at a time. :)
17:39:01
yitzi
If we can get the static analyzer to work on clasp (I can work on cando later) we can merge yitzchak_vm-lpt back into vm
17:39:38
drmeister
I have improvements in the python debugging extension in vm that would be helpful here.
17:41:31
yitzi
I am working on reusing the cclasp faso files in the eclasp image. That will make the build even faster.
18:00:27
drmeister
I think the issue is that the system (list of files) should be limited to just what was loaded.
18:02:22
drmeister
I can iterate faster on debugging it I run the static analyzer only with bytecode.
18:07:42
yitzi
If you want to you can try moving #@"cclasp-translations.lisp" from the start of stage 5 to the end of stage 4
18:09:06
drmeister
Ok, I set it up so that load-stage returns the list of system entries that it actually loaded, in the order they were loaded.
18:13:33
yitzi
Ok....I am confused. You can't change the return value of load-clasp....compile-clasp depends on that.
18:13:47
drmeister
I see - I may not have needed to do what I did if I'd move the cclasp-translations.lisp to the end of stage 4
18:14:47
drmeister
It won't change the return value of load-clasp unless you CLASP_STAGE_COUNT = <something less than the last stage>
18:16:12
yitzi
I'd have to see the code. Plus, I don't really understand what you are trying to accomplish.
18:28:28
drmeister
Bike: I want to create a 'vm-boehm' branch that merges 'vm', 'yitzchak_vm-lpt' and your changes that eliminate the interpreter and aclasp/bclasp compiler.
18:33:43
Bike
activation frames, environments, and lambda list handlers are still on the chopping block
18:45:28
drmeister
It went and created a pull request? I don't want a pull request - I want a branch!?
18:55:28
yitzi
So I presume that bytecode-compile and bytecode-reference don't need to be compiled twice anymore?
19:01:53
yitzi
If I am understanding the various feature expressions correctly it appears that we can ditch the aclasp stage 0 if we get rid of epilogue-aclasp.lisp
19:22:32
drmeister
We should look through the aclasp files so that they load in an order where they will be bytecode compiled properly so we go in to those files like aclasp but we come out like bclasp.
19:23:50
yitzi
Yeah, there aren't really any aclasp specific things left. I think we can make 1 or 2 stages
19:24:13
drmeister
We should only have one long sequence of loads that sets us up to compile-file all of the files to create the image.
19:24:44
drmeister
Bike: We should be able to get rid of LambdaListHandler_O - can you point me to what you are looking at?
19:26:37
yitzi
Well, its already a sequence of loads. The issue is whether there are different features present. That is what distinguishes stages (in addition to potentially being a subset).
19:28:31
drmeister
Bike: give me a sec and I'll try removing the TEMPLATED_FUNCTION_VariadicFunctor classes that refer to LambdaListHandler
19:28:43
drmeister
This: `class TEMPLATED_FUNCTION_VariadicFunctor< RT(*)(ARGS...), Pols, clbind::pureOutsPack<PUREOUTS...>,LambdaListHandler> : public core::BuiltinClosure_O {`
19:29:02
drmeister
The LambdaListHandler template parameter was there to help us transition away from LambdaListHandler_O.
19:32:09
drmeister
https://github.com/clasp-developers/clasp/blob/vm-boehm/include/clasp/clbind/function.h#L125
19:32:25
drmeister
And this one... https://github.com/clasp-developers/clasp/blob/vm-boehm/include/clasp/clbind/function.h#L195
19:33:26
drmeister
https://github.com/clasp-developers/clasp/blob/vm-boehm/include/clasp/clbind/function.h#L396
19:33:51
drmeister
A few day ago we were using those classes when I was debugging the bytecode wrappers.
19:34:50
drmeister
So I duplicated those two classes and added a separate template parameter - either `LambdaListHandler` or `Simple`
19:35:13
drmeister
Then I made bytecode wrappers work with `Simple` - you see those classes right after the ones I said you can delete.
19:35:29
drmeister
Notice - they don't use Frame or LambdaListHandler_O - that's because they are called from bytecode wrappers.
19:36:00
drmeister
I kept both classes for the time being so I could switch back and forth to debug it.
19:36:18
drmeister
You are now removing those vestigal, useless template classes. We keep the `Simple` ones.
19:42:59
Bike
toggling that did not work because it tries to include wrappers_methoids.h instead, except that file doesn't exist
19:44:14
Bike
the stuff i pushed to the vm-sans-interpreter branch builds fine. i'm just trying to cut more now, and that's not working
19:44:47
drmeister
I know - I'm using it already - but since we don't have compile-file for bytecode I'm rethinking my options.
4:29:38
Bike
i mean, i know there's the implicit "this" parameter, but other than that it should be the same, right?