freenode/#clasp - IRC Chatlog
Search
20:15:23
drmeister
cracauer: Is there anything wrong with copying an entire source tree including git directory to another directory name?
20:25:08
cracauer
it's also useful to preserve last-written time so that you can see what you touched since the copy.
20:47:37
frgo
hm - now, when doing ./waf configure, I get: "err: ld: library not found for -lSystem" with gmp being tested during configure. Woe. I thought that worked. I am using the right llvm 12 now.
21:26:42
drmeister
You built in the past - perhaps something is hanging around. If you had a separate machine that had not built clasp before - you should be able to build on there.
21:27:28
frgo
Yes I am installing all libs via homebrew. I've not yet built successfully on Big Sur.
21:38:15
drmeister
I've built clasp on a couple of systems using exclusively homebrew packages - so I think it's working.
21:38:30
drmeister
If homebrew upgraded something and that broke the build - I'd very much like to know that.
21:39:02
luni
ok but maybe it depends from the processor anyways... maybe new version are fully sipported
21:40:17
luni
yes on catalina there were no issue at all but after the update i messed up a lot of things
21:45:04
drmeister
It's on the net. I have so many freakin' computers here. My 12 year old self is so excited.
21:55:15
drmeister
Re: WSB - once I realized that the WSB thing was about sticking it in the eye of Wall Street parasites it became a moral imperative to join in.
22:13:45
drmeister
That's a side-show. The game is GME. This explains it better: https://www.reddit.com/r/wallstreetbets/comments/l8izo3/beware_those_who_are_shilling_other_stocks/
22:18:23
drmeister
This is why I prefer to invest in myself and my people. But this looks like a protest and I have a soft spot for protests.
22:20:45
Bike
from what i can tell it's more like some bored stock traders on reddit are milking redditors in more or less a ponzi scheme. the reactions calling for social media to ban talking stocks or whatever are pretty funny though.
22:21:12
drmeister
Anyway, don't look to me for investing advice :-) I'm about to throw some money down a hole for a "principle".
22:22:33
drmeister
I'm sure after this that investment houses are going to start hiring "meme directors".
3:59:19
drmeister
I've been slowly working on the GCing of code. I just kicked the supports out from under the code and ObjectFile_O objects are being garbage collected but Code_O objects are not.
3:59:52
drmeister
Something is holding on to them - I'll have to write a tool to track ownership of objects back to roots.
4:00:18
Bike
hm, could it be other code? but i suppose they shouldn't be referring to each other directly
4:03:22
drmeister
It's also surprising how fast the system is. I expected it to get bogged down with all the code it has to slog through - but I don't notice any slowdown at all.
4:04:42
drmeister
I have a function (llvm-sys:release-object-files) - it zeros the linked list of object files.
4:04:58
drmeister
Then I do a GC and there is a cascade of object files that get finalized - but no code objects.
4:07:22
drmeister
ObjectFile_O objects point at Code_O objects. The Code_O objects are new - and nothing else should know about them let alone point to them.
4:08:13
drmeister
Oh wait ObjectFile_O objects have other raw pointers that I may be pointing at Code_O objects.
4:09:36
drmeister
If I clear the linked list of ObjectFile_O objects the ones that were being kept alive get collected.
4:10:00
drmeister
But their memory remains full of pointers to the Code_O objects so they remain alive.
4:10:22
drmeister
Until the old memory for ObjectFile_O gets overwritten the Code_O objects would remain.
4:38:32
Bike
let's see, we make irbuilders in... landing-pad, cmprunall, compintrinsics, cmpir, cmpeh, translate, arguments, codegen-special-form...
4:43:43
drmeister
It was the pointers in an ObjectFile_O - I removed them all except one Code_O pointer - and I zero that out in the ObjectFile_O dtor.
4:45:06
drmeister
Still there should be a 1:1 correspondence between ObjectFile_O collection and Code_O collection.
4:47:03
drmeister
This is with boehm. The interesting thing is that it should be safe to GC code all the time. Return addresses on the stack are interior pointers and should keep code alive.
4:47:48
drmeister
This isn't the case with MPS - it doesn't support interior pointers for non-moving objects.
4:56:37
drmeister
Something is up. A few Code_O objects are being collected - but not nearly enough.
4:57:25
drmeister
I know - I'll track what Code_O objects are associated with what ObjectFile_O objects
5:06:36
drmeister
Perhaps I am not holding on to enough ObjectFile_O objects. My Code_O objects weren't pointing to their ObjectFile_O objects.
5:07:02
drmeister
Code_O objects are also kept alive by FunctionDescription_O objects because entry points are interior pointers.
5:09:26
drmeister
Ok - that leads to the next problem. What the eff is holding on to all the llvm objects?