libera/#clasp - IRC Chatlog
Search
13:15:47
yitzi
drmeister: The link command is created by clasp techically. Its buried in the snapshot C++ code.
13:33:37
Bike
this is so weird. i thought nuking .cache and .slime/fasl would be enough but apparently not.
13:34:04
Bike
yeah, i checked there, i don't see any fasls... there's bitcode, and there was a faso for sockets, but not asdf
13:35:15
yitzi
If we could get this issue fixed with the analyzer then I build the modules properlly
13:35:47
Bike
yeah, i did that too... i don't _think_ there's anything there, but let me check again
14:27:20
yitzi
sysroot is .... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
14:28:03
yitzi
the option is -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
14:42:03
drmeister
Keep that in mind - we could cut out the iclasp-boehm build step. Just load all of the cclasp code and then go to the static analyzer. Run the whole thing in bytecode.
14:56:33
drmeister
The gdb frame filters and frame descriptors thing would let me change the trampoline frames so they display lisp names and arguments.
15:24:43
drmeister
Bike: You have 'vm' with the interpreter and aclasp/bclasp compiler completely disabled - right?
15:26:33
drmeister
::notify yitzi (Q1) Do you use quicklisp to load the static analyzer? (Q2) Can we merge 'vm' into 'yitzchak_vm-lpt'?
15:41:48
Colleen
yitzi: drmeister said 15 minutes, 15 seconds ago: (Q1) Do you use quicklisp to load the static analyzer? (Q2) Can we merge 'vm' into 'yitzchak_vm-lpt'?
15:43:34
yitzi
rebase is probably better. Or we just merge yitzchak_vm-lpt and commit to fixed the static analyzer now.
15:45:11
yitzi
But it doesn't really matter. You can make changes to that branch if you want. You have the bridge.
16:03:45
drmeister
yitzi: Can you fix the CLASP_STAGE COUNT thing - it looks like clasp-builder.lisp isn't listening to it.
16:05:10
drmeister
Here's what I'm thinking. I will make changes in the 'vm' branch to improve debugging with the vm. Better backtraces mainly.
16:05:28
drmeister
Then I'll merge that into yitzchak_vm-lpt and use it to fix the static analyzer problem.
16:08:47
drmeister
Actually - forget the bclasp thing - I'll load_vclasp-boehm and then run from that.
16:09:04
drmeister
It doesn't take any longer and it will give me the option of compiling some stuff to native code.
16:21:22
Bike
now most of the stuff to remove is environment classes and lambda list handlers, but i'll need the analyzer for that, i think
16:47:39
yitzi
They are defined in foundation.lisp ... might be nice to have in clasp-builder, though. Trying to define and see if that works.
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.