Search
Thursday, 29th of July 2021, 20:02:13 UTC
20:02:50
drmeister
Only a few of them are active I think.
20:04:28
drmeister
For the finalizers - you could generate a printf statement in every finalizer and then watch them print when you run clasp.
20:04:55
drmeister
You can target it by looking for classes that use finalizers - like Stream_O (I think). Hang on.
20:04:55
Bike
oh, do they just run in normal use?
20:05:15
Bike
i'd be satisfied if things didn't just crash and burn then
20:05:32
Bike
i don't know how these tables are accessed is all. they're jused for jump tables but i don't know if they're indexed by stamp or what
20:05:44
drmeister
Yeah - the ones that have this:
20:05:48
drmeister
https://www.irccloud.com/pastebin/BWKehG5H/
20:05:53
Bike
but since i generate it from a hash table the order is kind of arbitrary
20:06:02
drmeister
static bool constexpr NeedsFinalization = true;
20:06:43
drmeister
Right - the jump table.
20:18:27
drmeister
I only see obj_finalize being called from MPS code.
20:18:52
drmeister
I believe gctools__deallocate_unmanaged_instance is for static vector and things like that.
20:19:02
drmeister
No - not static vector.
20:19:10
drmeister
That would still be managed right?
20:20:14
drmeister
I don't think obj_finalize or obj_deallocate are currently being used.
20:20:47
Bike
Alright, I guess that works. Are they stuff we want to keep around for later?
20:21:21
drmeister
obj_finalize looks like it's used by finalizers in MPS - but not boehm - I'm not sure why.
20:23:37
Bike
well, it does look like the table index is just the stamp
20:23:50
Bike
in which case the entries really do need to be ordered correctly
20:24:14
drmeister
I think I implemented that stuff before wtags
20:29:10
Bike
nonetheless, this seems like it could be a really confusing bug later, so let me see if i can get those sorted
0:45:09
drmeister
Is it time to integrate it into the build?
0:48:33
Bike
i built cboehmprecise successfully, so i suppose so
0:49:34
Bike
https://github.com/clasp-developers/clasp/blob/scrape/src/scraper/code-generator.lisp#L1282-L1298 here's the function that generates clasp_gc.cc. right now it's not called by anything
1:47:44
drmeister
Bike: I'm trying to build cando and something is coming up. Did you try it with cando?
1:52:47
drmeister
This should have happened to you as well...
1:52:48
drmeister
https://www.irccloud.com/pastebin/lCLBHz9y/
2:01:24
Bike
oh, i think i recognize this problem though
2:01:29
Bike
maybe i screwed up the merge
2:02:13
Bike
well, the problem i hit before was that the analyzer-generated code uses a define GC_STAMP where the scraper-generated code uses GC_ENUM
2:02:34
Bike
so i changed everything to use GC_ENUM uniformly, but if you don't do that it's missing all the STAMPWTAG_whatever definitions
2:02:57
Bike
wait, are you just using the clasp_gc_cando.cc that's in the branch? i didn't regenerate any of those files
2:03:16
Bike
(well, i might have done clasp_gc.cc, but it would be an accident)
2:03:32
Bike
i changed the gctools to use GC_ENUM instead of GC_STAMP, but clasp_gc_cando.cc still has GC_STAMP
2:11:45
drmeister
Ah - I haven't integrated anything yet.
2:12:50
drmeister
Does the scraper generate the file at this point?
2:13:07
drmeister
"not called by anything"
2:28:01
Bike
Yeah, like I said, I've been calling it and writing it into clasp_gc.cc myself
2:28:33
drmeister
Will all the info we need be in clasp_gc.cc for build_cboehm ?
2:28:55
Bike
i thought for cboehm we just wanted to use the scraper like we've been doing?
2:29:31
drmeister
So all we are doing is moving the location of clasp_gc_xxx.cc and it's always called clasp_gc.cc
3:05:18
beach
Good morning everyone!
Friday, 30th of July 2021, 8:02:13 UTC