Search
Sunday, 25th of September 2022, 23:05:58 UTC
23:11:03
drmeister
Yes, it is that carefree with allowing conditions to be signalled...
23:11:15
drmeister
https://usercontent.irccloud-cdn.com/file/wXPx3OF8/image.png
23:11:36
drmeister
Note how the inner functions don't return.
23:14:14
drmeister
https://usercontent.irccloud-cdn.com/file/uzooDkTf/image.png
23:19:42
yitzi
Some of the tinkering with the source registry may not be needed anymore in that script.
23:21:31
yitzi
Hmmm....that changes the error to a segmentation fault
23:28:13
drmeister
I'm trying to come up with a simple reproducer and I'm not getting one yet.
23:29:38
yitzi
The call ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY in that script probably isn't needed. Removing it causes a segmentation fault
23:30:45
yitzi
We moved the SYS host to point to the root of the source tree, so ASDF should look there automatically.
23:32:21
drmeister
The main branch of clasp doesn't have static-vectors - do you know why?
23:32:56
drmeister
I'm asking because my vm-boehm branch of clasp does have static-vectors and that directory is where it is failing.
23:33:53
drmeister
static-vectors is in both repos.sexp
23:33:53
yitzi
static-vectors are used in eclasp.
23:34:18
yitzi
If you don't build cando then it won't get pulled.
23:34:38
drmeister
Crap - then I'm sitting in a directory that came from cando
23:34:55
drmeister
That had cando in it at one time.
23:35:06
drmeister
So it's different from my clasp repo
23:35:37
yitzi
`--deep-clean` will zap them. .... but you'll have to rebuild
23:36:14
yitzi
Just running `clasp --norc` and then `(require :asdf)` followed by `(ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY
23:36:14
yitzi
(LIST :SOURCE-REGISTRY (LIST :TREE (MERGE-PATHNAMES #P"../" (UIOP/OS:GETCWD)))
23:36:14
yitzi
:INHERIT-CONFIGURATION))` causes the error.
23:36:22
yitzi
While in the build folder
0:13:18
drmeister
https://www.irccloud.com/pastebin/2FgWixPj/
0:13:43
drmeister
You will see that it does a lot of scanning before it causes the error.
0:14:45
drmeister
Change this... (MERGE-PATHNAMES #P"../" (UIOP/OS:GETCWD))
0:14:50
drmeister
to (uiop/os:getcwd)
0:16:15
drmeister
What's interesting is that it dies after processing a lot of directories.
0:16:47
drmeister
I'm also running clasp/main alongside it doesn't die.
0:17:25
drmeister
Hang on - I'll have them scan the same root directory.
0:27:41
drmeister
There's a problem with the vm.
0:28:14
drmeister
https://www.irccloud.com/pastebin/wAp7AaL3/
0:29:40
drmeister
I'm loading this...
0:29:42
drmeister
(trace asdf/source-registry::process-source-registry-cache)
0:29:42
drmeister
(trace UIOP/STREAM:SAFE-READ-FILE-FORM
0:29:42
drmeister
UIOP/STREAM:read-file-form
0:29:42
drmeister
UIOP/STREAM:CALL-WITH-INPUT-FILE
0:29:42
drmeister
UIOP/STREAM:SLURP-STREAM-FORM
0:29:43
drmeister
core:universal-error-handler
0:29:45
drmeister
(setf *default-pathname-defaults* #P"/home/meister/Development/clasp/")
0:29:46
drmeister
(ASDF/SOURCE-REGISTRY:INITIALIZE-SOURCE-REGISTRY
0:29:46
drmeister
(LIST :SOURCE-REGISTRY (LIST :TREE #P"/home/meister/Development/clasp/")
0:29:47
drmeister
:INHERIT-CONFIGURATION))
0:30:00
drmeister
And I get that vm error.
2:32:59
Bike
random evening thought: compiling discriminators in a dedicated thread might be easier for making it work as well as for performance reasons
2:33:05
Bike
have to get it working to begin with first, tho
2:50:33
drmeister
We are blowing through the top of the stack.
2:53:55
Bike
hmm. the sjlj unwind ought to make sure the destination dynenv is on the stack before it does anything
3:02:44
drmeister
I mean - the stack pointer is exceeding the top of the stack.
3:14:19
Bike
like the bytecode stack pointer?
3:17:49
drmeister
https://usercontent.irccloud-cdn.com/file/7SAfcNZH/image.png
3:35:50
drmeister
nargs words (arguments) are pushed onto the stack and then bytecode_call returns with those words popped off the stack - correct?
3:39:45
drmeister
Uh return values.
3:43:27
drmeister
Bike: Is there a simple relationship between the vm._stackPointer on entry to bytecode_call and on normal return?
9:12:27
Guest1362
** NICK 040AAGS3Q
Monday, 26th of September 2022, 11:05:58 UTC