freenode/#clasp - IRC Chatlog
Search
21:58:11
kpoeck
The version from eclector from clasp 03.0 is incopatible from the latest quicklisp version 0.4.0
21:58:50
kpoeck
fixup is now (defgeneric fixup (client object seen-objects mapping)) and used to be (defgeneric fixup (object seen-objects mapping))
22:00:19
kpoeck
Can is use (asdf:register-immutable-system :eclector) to advise clasp not to load the quicklisp version?
22:01:32
drmeister
kpoeck: Could you say this part again? I'm having trouble parsing it: "The version from eclector from clasp 03.0 is incopatible from the latest quicklisp version 0.4.0"
22:05:01
Shinmera
The proper solution would be first class environments, but for now register-preloaded-system should at lest circumvent the problem
22:05:58
kpoeck
than I do (load "~/quicklisp/setup.lisp") and first thing that does is rebuilding asdf
22:06:42
kpoeck
Ok, (load "~/quicklisp/setup.lisp") takes Time real(907.308 secs) run(907.328 secs) consed(11520463536 bytes)
22:07:34
drmeister
I build asdf on my macbook pro in ~190seconds and 120 seconds with compile-file-parallel.
22:08:12
drmeister
kpoeck: Ok - we are working on improving compile times. I wrote a compile-file-parallel that could have a dramatic impact - but it's not working yet.
22:08:29
drmeister
llvm is not going to get any faster - so we have to improve things by going parallel.
22:15:33
drmeister
It is a great source of frustration that we are forced to build serially when we use quicklisp.
22:29:42
stassats
now thinking which parts of sbcl's compiler could benefit from parallelization, can't let clasp get ahead
22:31:13
stassats
i think the each form could be compiled independently, while serializing dependencies
22:38:11
stassats
yeah, i think parallelizing the compiler itself is not a great idea, but compiling multiple forms using within compile-file could be worthwhile
22:38:47
stassats
or across multiple files, but that means dealing with asdf, and i don't want to deal with asdf as much as asdf doesn't want to deal with me
22:39:59
drmeister
When I was at the llvm dev meeting it was pretty clear there are no massive speed improvements coming down the pike.
22:40:37
stassats
i should have started making my build system five years ago, but i guess now is a good time as ever, or i'll be thinking in five years "should've done it 10 years ago"
22:42:45
stassats
too bad C-c C-c is already faster than any compilation speed up can make it, and there's no pressure to parallelizing
22:43:11
stassats
i can't imagine what it's too work with the horrendous recompile cycles on large c++ projects
22:43:38
drmeister
The best time to plant a tree is five years ago, the second best time is four years ago. But the third best time... the third best time is today.
22:45:30
Shinmera
The only thing I seem to be planting is projects that just land me bugs to fix years later
22:46:53
stassats
that's why i always strategically delay "i'll be smarter in five years, i'll do it quicker"
22:48:52
drmeister
::notify scymtym We went with post-processing the tree after the parser and builder code is done with it to handle the ring-tag-set/test.
1:45:18
drmeister
I ran into a conceptual problem with our SMARTS code (regex for molecular fragments).