freenode/#clasp - IRC Chatlog
Search
13:00:49
Colleen
Bike: drmeister said 5 hours, 48 minutes ago: Is regular inlining of things like primop:two-arg-- still broken?
13:31:46
attila_lendvai1
hi! did the build get slower? or is dev broken? or did i break it? seems to be stuck at "(DEFSTRUCT (COMPILER-STYLE-WARNING (:TYPE VECTOR) ...))"
13:34:06
Nephromancer
@attilla_lendvai1 are you talking about the docker image? one of the other undergrads in our lab was having some issues with that this morning
13:35:17
attila_lendvai1
Nephromancer: no, i'm just building dev + a bitvector cleanup of mine locally
13:46:36
attila_lendvai1
BTW, the cando docker file has apt-get install references to llvm-5.0 stuff. i guess that's a mistake
14:04:17
Bike
defstruct has been slow to compile for a while. dunno about increasing memory, though.
15:15:54
drmeister
I'm getting an error when loading jupyter lab that chem:define-tests is not defined - is this something that you are adding? It has to do with smarts.
15:18:17
drmeister
https://github.com/drmeister/cando/blob/102ad64eb4bc9459d4c582819991da25400d4438/src/chem/chemInfo.cc#L314
16:30:34
Bike
i did somethin, and now C-c C-c resultsin different source offset numbers from a full compile file. but M-. goes to the right place either way.
16:32:41
Bike
oh. i see. emacs's idea of source position is different from clasp's, but they're both right up to next-sexp, so it works.
16:39:09
Bike
drmeister: you put in something to hedge if compiled-function-file is not passed a function?
16:39:33
drmeister
Yes - because when there are no debugging frames any error threw it into an infinite loop
16:40:32
drmeister
What we need is better way of getting backtraces what we have is hacked together bullshit.
16:41:14
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/lsp/top.lsp#L1010
16:42:55
Bike
with C-c C-c i got offset 161, with compile-file it was 38... but the only thing between 38 and 161 is whitespace and comments, which emacs ignores anyway
16:48:24
Bike
with inlining i hit another problem instead. also finicky. inlining makes the compile enormously slower anyway so i don't want to bother right now
16:49:25
karlosz
after inlining my system funcall instruction it complains that one of the slots are unbound
16:49:29
Bike
but i don't think that's what it's doing. i've messed up and given it incorrect offsets before, and it's caused errors
16:54:13
attile_lendvai
then it must be my changes... :/ we'll see, i rebased them to some older commit and started a build
16:55:30
karlosz
i was thinking about using stealth mixins and specializing methods on stuff like delte-instruction
16:56:35
karlosz
so delete-instruction can specailize on a liveness mixin to update the liveness information associated with the instruction
17:12:13
karlosz
Bike: im not sure what exactly the current liveness pass computes, but incremental liveness analysis requires keeping track of sets of uses, not just variables
17:14:02
karlosz
so when deleting an instruction that uses a variable, you can delete it from the live-in and live-out use sets
17:14:26
karlosz
its not absolutely required to keep track of uses instead of variables, must uses guarantee least fixed point solution
17:15:02
attile_lendvai
i'm compiling the point in the git log where clasp is switched to llvm6 and it seems to be less memory hungry and faster (but it might be just something subjective)
17:15:27
karlosz
Bike: it does, but unless the program is in SSA, the defs and uses need to be matched up
17:55:22
karlosz
so it looks like local functions with non local escapes and complex lambda lists dont get inlined either
17:57:17
Bike
optional we could do. &rest or &key would require something to allocate the list at runtime.
17:59:24
karlosz
makes sense. might have to be a new instruction since doing that isimplementation dependent
18:53:28
drmeister
It seems to me that there is nothing fundamentally wrong with building the image at startup the way we do - but we don't have the right definition of a compilation-unit.
18:55:22
drmeister
Can you summarize again the problem with your make-instance optimization? What is out of place?
18:58:07
Bike
drmeister: it's been a while, so i don't remember the particular issues i was running into at the end. might have been related to the structs i used having their own constructors
19:09:48
drmeister
In the 'allinone' branch there is a version of Clasp that compiles cclasp by compile-filing all of the source files as if they are one from the point of view of compiling lexical variables.
19:10:54
drmeister
If we add the ability to compile classes as literals - then the class definitions will be created the first time they are needed and then on they would be referenced.
19:11:26
drmeister
The first time I tried it - it used a lot of memory and crashed my laptop. So I'm trying it on your machine.
19:12:02
drmeister
I don't have the classes being treated as literals yet - that would be next if I can get the thing to work at all.
19:12:34
drmeister
But if this were in place - would it solve all of our problems. I've asked this before - but I'm describing it again after mulling it over for a few days.
19:13:28
drmeister
The problem now is that an inline definition in file #5 needs Cleavir AST classes that are defined in file #350
19:15:14
drmeister
And each separate file generates its own table of literals and so even if we compiled classes as literals - they wouldn't be set up at the right time unless we compile everything as one big compilation unit.
19:16:48
drmeister
That's why I'm asking about your make-instance optimization - that ran into a startup problem. It's a useful complementary case to the problem with inlining.
19:18:13
drmeister
If I'm wrong about this allinone+literal-classes idea then I want to ditch it and move to saving core files.