freenode/#clasp - IRC Chatlog
Search
13:04:19
drmeister
Oh noooos! The dreaded "Diamond inheritance problem" that demonstrates that multiple inheritance is scary.
13:14:17
heisig
He probably means C++, where you explicitly have to tell the compiler about diamond inheritance, or it will accidentally emit several versions of each slot.
13:15:16
beach
I guess they didn't know about my fast generic dispatch technique when they designed the language.
13:15:42
beach
Or, more likely, at the time, table-based techniques were faster, so they did what they could with such techniques.
13:16:22
jackdaniel
sad consequence of that is that you can't add subclasses to the party from a shared object (because it is already finalized in this sense)
13:17:28
heisig
There is vtable dispatch for virtual member functions in C++. Which gives rise to such beautiful things as the visitor pattern.
13:17:57
beach
jackdaniel: You know perfectly well that it dispatches (using vtables or whatever they are called) on the first (implicit) argument.
13:19:09
beach
I hear it used to be fast at the time. That can't be the case anymore with such dispatch techniques.
13:20:59
kpoeck
I have to admit that I needed 5 google searches before having a c++ test program that did runtime dispatch
13:21:30
jackdaniel
beach: you are right, according to link from kpoeck dispatch may be dynamic in c++. as of first implicit argument it is not that relevant, I didn't claim c++'s gfs are as capable as cl's
13:24:01
jackdaniel
and I didn't know not only perfectly well, but at all. this part is interesting: "Since C++ does not support late binding, the virtual table in a C++ object cannot be modified at run-time, which limits the potential set of dispatch targets to a finite set chosen at compile time. "
13:38:19
drmeister
Hello - I'm getting ready for the day - I have a presentation to give down near Washington.
13:40:19
drmeister
Bike: It looks like everything is building fine. The problem was that "with-module" macro - I should not have written it to do optimization at the end of the macro - it hides the optimization step.
13:40:27
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile.lsp#L11
13:40:46
drmeister
Later today I'll move the optimization step out into the callers so that it is explicit.
13:41:44
drmeister
LLVM is aggressive about removing functions that aren't pinned/referenced in the module in some way.
13:51:54
Bike
really seemed like it was in optimize-module-for-compile-file as called by the remove builtins thing
13:51:54
Colleen
Bike: drmeister said 7 hours, 46 minutes ago: - I found the problem - yeesh - I was optimizing the module before creating the static ctor that invokes the startup function. Since the startup function wasn't declared external and wasn't referenced by anything it was removed!!!
13:51:54
Colleen
Bike: drmeister said 7 hours, 21 minutes ago: The problem wasn't the always_inline - that was fine. We just need to add the functions to inline, inline them, remove them, add the ctor and only THEN optimize the module.
13:51:54
Colleen
Bike: drmeister said 6 hours, 59 minutes ago: I pushed all of the changes and everything seems to build.
13:59:43
drmeister
I'm almost certain that optimize-module-for-compile-file was removing the RUN-ALL and that referenced the other functions and so they were removed and so on.
14:00:21
drmeister
The problem was that I moved the make-boot-function-global-variable call OUTSIDE of the (with-module ...) macro.
14:00:22
Bike
based on the before/after i'm pretty sure the function was removing it, yes, i just thought it was the earlier call
14:01:26
drmeister
That function creates a function that acts as a C++ static constructor and it will not be removed by optimization - it is pinned into the module and it references RUN-ALL - so that gets pinned into the module, and RUN-ALL references everything else - so everything gets pinned into the module.
14:02:56
drmeister
The one call to optimize-module-for-compile-file I know was the one at the end of the with-module macro and the other call that does inlining and optimization is the one in link-inline-remove-builtins.
14:04:04
drmeister
And it was the first one at the end of with-module that I think was removing ALL of the functions because they were all internal and none were referenced by external functions (there are none at that point) or global variables.
14:06:33
drmeister
I added a comment about optimization here: https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file.lsp#L295
14:07:05
drmeister
I also put in a test to check if the function being referenced by the static CTOR disappears before we need it.
14:07:46
drmeister
We now lookup the RUN-ALL function by name rather than holding on to a reference.
14:08:03
drmeister
Yesterday we were holding on to a reference and then the function was being removed - that was bad.
14:09:30
drmeister
Since I had optimization turned off - non of this function removal was happening. You had it turned on and because I'd moved the make-boot-function-global-variable call OUTSIDE of the (with-module ...) macro --> KABOOM
15:12:15
kpoeck
Beach: Loop test 11.8 is already deactivated: https://gitlab.common-lisp.net/ansi-test/ansi-test/blob/master/iteration/loop11.lsp#L52
15:23:22
Bike
drmeister: still builds. if i run iclasp-boehm -i cclasp-boehm-image.fasl it works, but build/clasp immediately segfaults
15:28:19
Bike
it segfaults before printing banners or checking for debug-startup, so it's probably some kind of basic issue with linking...
18:17:54
Bike
drmeister: merged and pushed. slime and quicklisp works. the segfault thing is still happening though.
18:38:08
drmeister
They are assembled differently. I could see there being issues with the new stuff
21:19:53
drmeister
We should create a chem-info-equalp function to compare chem-info data structures.