freenode/#clasp - IRC Chatlog
Search
16:49:41
drmeister
Is the instruction that it printed screwed up - does it have zero length? I think I have to put something in to check for that.
16:50:45
Bike
drmeister: i can use compile-file-parallel, i'm asking which file to compile in babel to reproduce the issue.
16:51:24
drmeister
Oh - I used the (setf (fdefinition 'compile-file) ...) . and then I (load "~/quicklisp/setup.lisp") and then I (ql:quickload "babel")
16:52:56
drmeister
I'm wonder if it's an infinite loop because it's printing the same instruction or if it's a screw up in the length of the function and it is disassembling what it thinks is a very, very, very long function.
16:53:31
drmeister
Can you dump a few lines - say where it goes from looking ok to where it goes crazy?
16:56:43
drmeister
The llvm disassembler is screwing up when dumping the 'sarl' instruction (what is that?) It thinks it's zero length and so it goes into an infinite loop because I don't test for that - I will fix that.
16:57:19
drmeister
The first hex value is the IP. The <#424+1898> I think is the instruction # counting from the start and the instruction offset from the start of the function.
16:57:41
drmeister
Notice how the <#424+1898> the first number increments by one and the second is stuck.
16:58:44
drmeister
Yeah - I don't recognize it - but the last instruction set I memorized was Z80 and that was 30 years ago.
17:01:18
drmeister
It might be an illegal instruction after the tail end of the function and the function end is not exactly the end of the function (I define the end of the function as the start of the next symbol - a bit dangerous -but on macOS I don't have a choice). The disassembler is confused or something.
17:01:59
Bike
i just restarted and set up the discriminating function again and i get a similar bad result, except with `cld` instead of `sarl %cl, %edx`
17:04:34
drmeister
I just put in a sanity check - if it hits a zero length instruction it stops disassembling.
17:04:37
Bike
also, doing some basic timing on bclasp versus bespoke, and i'm not seeing a difference for fast method calls, which is kind of surprising
17:04:48
drmeister
I pushed the change - it's untested but small enough that I'm confident it will compile.
17:07:16
Bike
for the discriminating function timing, it might just be that the method function is most of the time, rather than discrimination. dunno
17:47:41
Bike
ok, now that i have cut down on doing stupid things, fast method calls are a few times slower with bclasp. right.
17:50:13
Bike
wondering what the best way to determine the number of arguments a fast method call wants is
17:57:56
scymtym
drmeister: "past it" as in it works now or as in then you ran into another problem?
17:59:44
scymtym
note that you could also read the s-expression using READ as in the wip-sexp branch of the leap parser: https://github.com/scymtym/leap-parser/blob/wip-sexp/src/grammar.lisp#L202-L228
18:01:07
scymtym
the advantage of that solution is that esrap then reports lisp syntax errors in the usual way with the correct location and all
18:04:59
drmeister
scymtym: I'm not going to put arbitrary Common Lisp code in there - just a label that maps to a Common Lisp function. I'm crazy but I'm not that crazy.
18:32:46
kpoeck
The message I like most in ansi-tests: No unexpected failures. 8 unexpected successes:
18:37:26
drmeister
kpoeck: I very much appreciate the work you are doing here - it's bringing clasp closer and closer to the standard and eliminating problems before they can arise.
18:56:32
Bike
practically anything that prints to stdout (rather than *standard-output*) is some ancient debugging thing we should remove
18:58:39
kpoeck
./../src/core/singleDispatchGenericFunction.cc:266 slowMethodLookup for COPY-SYMBOL ../../src/core/singleDispatchGenericFunction.cc:267 mc-> FIXNUM ../../src/core/singleDispatchGenericFunction.cc:271 ac->className -> SYMBOL ../../src/core/singleDispatchGenericFunction.cc:272 mc->isSubClassOf(ac) -> 0 ../../src/core/singleDispatchGenericFunction.cc:273 class-precedence-list of ac -> SYMBOL ../../src/core/singleDispatchGener
19:04:23
Shinmera
kpoeck: Use tab completion on IRC names -- and if it can't mark up code samples correctly a pretty big part of its functionality is ruined.
19:06:31
Bike
ok, testing like three small things at once now, probably will push em through in like half an hour
19:10:00
kpoeck
Shinmera: I am sorry that I mistyped your name, but please don't be so negative in your comments
19:11:00
Shinmera
I'm not bothered, I'm just saying if you use tab completion you need to type less and make less mistakes.
19:11:49
Shinmera
As for Staple, erroring on code snippets is a big problem, so I don't consider that fine enough.
19:35:55
kpoeck
drmeister: is the following idiom supported by clasp asdf: https://github.com/McCLIM/McCLIM/blob/master/Extensions/fonts/mcclim-fonts.asd#L15
19:38:08
Shinmera
Could write that as :perform (astdf:load-op :after (op c) (uiop:symbol-call :mcclim-truetype :autoconfigure-fonts))
19:40:49
kpoeck
That the code in (defmethod component-depends-on ((o prepare-op) (c (eql (find-system :cl-unicode)))) ...)
19:42:15
Bike
probably should do some compute-applicable-methods and stuff to make sure it's getting put together right
19:53:52
kpoeck
Bike: compiling your latest fixes to see if staple-server is happy now (the eclector thing)
20:03:21
drmeister
ACTION is looking forward to staple-server and getting a documentation server up and running.
20:03:46
drmeister
ACTION is especially looking forward to not having to do it himself! Oh frabjous day!
20:05:03
drmeister
shiho: What kind of node does the $ operator generate? As in [$(...),$(...)] . Does it generate anything special?
20:06:02
drmeister
Since we need to do some post-processing on the nodes within a $(...) we need to have some way of recognizing $(...)
20:06:51
drmeister
Anyway, I'm back from my swim, ate my 500 calorie veggie crepe and I'm back working in the SMARTS salt mine.
21:18:00
Bike
not rewinding the vaslist or applying for fast method calls reduces the time for a million calls from 60 ms to 37 ms
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).