freenode/#clasp - IRC Chatlog
Search
13:04:16
kpoeck
I am getting spurious errors with find-class returning nil although the class is clearly defined
13:06:03
kpoeck
I have tried to defined a minimal test case in https://github.com/clasp-developers/clasp/issues/636
13:09:53
drmeister
kpoeck: Interesting about the spurious find-class issues - and you have a test - excellent!
13:10:51
drmeister
You may be used to using 'clasp', which is a symlink to 'cclasp-boehm', which is a single executable.
13:11:16
drmeister
'iclasp-boehm' contains only the linked C++ code and it loads the cclasp image as a fasl file.
13:11:27
kpoeck
The seg fault is not urgen, I have a second installation with older code that works fine
13:13:39
drmeister
Huh, I built the latest dev last night and I just counted the number of lines of llvm-ir using: wc `find . -name '*.ll' -print` --> 9,985,761
13:23:25
drmeister
That's a substantial reduction in code! Yet it says that it took more than 4 hours to build.
13:25:13
Bike
kpoeck: WITH_READ_LOCK will end at the end of the block it's in (so just after the "foundp =" there). it's raii stuff.
13:25:44
Bike
kpoeck: this particular function is organized like that because signaling an error while holding a lock is problematic
13:29:35
drmeister
Looking at the code I don't see how it could fail, even in a multithreaded situation, to report classes that are present.
13:30:05
Bike
i'm pretty willing to believe i'm missing something, when it comes to multithreading, though
13:31:11
drmeister
Ugh - actually I'm rebuilding cclasp - so I don't have anything to test with for a bit.
13:32:59
drmeister
If we have really knocked the amount of llvm-ir down by more than half then the build should be noticeably faster.
13:38:44
drmeister
I've seen wildly inconsistent build times before. I think it is something to do with macOS throttling processes that are in windows in the background.
14:26:44
drmeister
The build isn't any slower - it must have been power management issue that caused that 4h build.
14:27:26
drmeister
But inline.lsp and fli.lsp are taking a long time (707 and 866 seconds respectively).
14:27:52
drmeister
So it sits there doing serial compilation for a long time. I'm going to pull those two forward to start them first.
14:31:55
drmeister
But the overall build time was 1h7m - that's longer than the 27 min I saw before.
17:03:13
beach
I guess it could be. I am assuming Quicklisp loads all the installed systems, so the total amount of space could be significant.
17:08:52
stassats
have you noticed the RAM prices recently? it's all the clasp users buying more memory