freenode/#clasp - IRC Chatlog
Search
14:06:00
scymtym
drmeister: your builder should not assume a particular order for MAKE-NODE calls. RELATE calls for a given LEFT node however occur in order
14:07:45
drmeister
scymtym: C1CCC1 (three-member ring) needs the two '1's to be handled differently. The first one would set a 'ring tag' and the second one will test the ring tag.
14:08:32
drmeister
Is that beyond the scope of the parser and/or the builder and should be left to the thing that runs the final code?
14:18:23
drmeister
Or I can keep track of these ring tags while parsing and then fix them up with a second pass after parsing is complete. Maybe I'll do that.
14:18:58
drmeister
esrap gives me the character position of everything - I just need to record that.
14:19:41
scymtym
drmeister: you could track that information in the parent node (if any, i don't remember) of the AST subtree
14:20:48
scymtym
when the first C1 is added, you could set a flag in the parent (or in a hash-table in the builder) to indicate that tag "1" has already occurred in the current subtree
14:29:30
scymtym
if you have some kind of pattern compilation phase after parsing, handling ring tags there sounds fine
15:10:45
scymtym
yeah, in my experience, doing too much during parsing will often cause problems later
15:12:17
drmeister
We need to recognize things like C1CCC1 where the first '1' means set-ring-tag and the subsequent ones mean 'test-ring-tag'
15:12:55
drmeister
And [$(C1CCC1),$(C1CCCC1)] must be from left to right set-ring-tag, test-ring-tag, set-ring-tag, test-ring-tag
15:13:47
drmeister
So yeah - we have to walk the tree and figure out which '1' comes first and modify that node to be a setter and not a tester.
15:14:38
drmeister
I used nonstandard syntax in our old parser C1CC[C;?1] but that is going to be eliminated.
15:15:00
drmeister
Besides this we need the colon operator to associate tags with atoms for later recovery.
15:15:52
drmeister
Those :1, :2, :3 are tests that always return true but have a side effect that associates the current atom with the tag in a separate hash table.
16:43:00
Bike
or failing that, i guess i can just load babel normally, then manually parallel-compile whichever file the problem is, if you tell me which
16:46:36
Bike
i tried to disassemble a generic function, and it printed something normally but then printed the same instruction thousands of times until i aborted
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