freenode/#clasp - IRC Chatlog
Search
15:13:50
Bike
okay, so what i get in the log is it tries to calculate a dispatch function, and then it prints the " |" spacer a million times.
15:14:38
drmeister
It may be an infinite recursive loop where printing is invoking a generic function and so on.
15:15:44
drmeister
What is it trying to print? There is a _safe_rep_(whatever) facility and (core:safe-repr whatever) to print objects using a path that doesn't use any generic functions.
15:16:00
Bike
i don't know. the function it tries to get a dispatcher for is generic-function-name, though.
15:17:09
Bike
dispatch-miss does call generic-function-name in the logger... guess i can change that
15:18:26
drmeister
Yes - I started developing this "safe-repr[esentation]" code path so we can print things without invoking the Common Lisp printer.
15:19:04
drmeister
The code is in debugger.cc - you can add more printing code - just don't use the Common Lisp printer.
17:17:30
Bike
safe-repr is so safe that they only information it prints about instances is their address
17:50:33
drmeister
Yes - you can add more printing code. I think of it as c++ to crawl into objects to print what we need in a completely safe way.
17:51:56
drmeister
I got asked to come up with a proposal by tomorrow for a couple million dollars for a couple of years.
18:06:55
drmeister
Put lots of logging into your interpreter - print everything. Look at my dtree interpreter. I didn’t put that in because I thought it was pretty
18:30:12
Bike
okay, so i have DEBUG_MONITOR in the options, and then i can use monitor_file and stuff?
18:55:22
drmeister
#define DTLOG(x) if (_sym_STARdebug_dtree_interpreterSTAR.boundp()&&_sym_STARdebug_dtree_interpreterSTAR->symbolValue().notnilp()) { FILE* fout= monitor_file("dtree-interp"); fprintf( fout, "%s", (x).str().c_str()); fflush(fout); }
18:57:35
drmeister
The monitor_file("whatever") will return a FILE* pointer (it will open the file if it doesn't exist and close it when the thread exists). The file that is opened by monitor_file("whatever") will be in the /tmp/clasp-log-<pid>/whatever-<thread-id> file.
18:59:01
drmeister
If you want to correlate entries from one file to another print (core:next-number) - it just returns a new number that incremented using a 64bit atomic counter.
19:00:27
drmeister
I had my dtree interpreter print (core:next-number) and when there was a dispatch miss the dtree compiler code printed the (core:next-number) and then I just matched them up. One is after the other.
19:23:18
Bike
looks like a shifted/unshifted stamps problem, but then i don't understand how it could be working in my tests
19:25:08
drmeister
Wow - that's just like my weekend. You see why I was not over the moon about redoing this. I do like the look of your interpreter though.
19:27:32
Bike
i just don't get how it can possibly be working when i load it in an existing image, is all
21:08:56
Bike
prededed by T_sp tinstance = args->next_arg(); Instance_sp instance((gc::Tagged)tinstance);
21:10:29
drmeister
That's still consistent with dereferencing being the point of failure. I think your instance tagged pointer is screwed up. Can you put a print statement in front of T_sp value = instance->instanceRef(index); ?
21:14:16
drmeister
My connection sucks - if I disappear it's because my electromagnetic waves don't want to propagate.
21:14:57
Bike
also, args is a vaslist - just one passed to the function, but dispatch_args is another vaslist copied from it
21:15:10
drmeister
If you push this to a branch I could take a look at it. I've got mad debugging skillz after this weekend.
21:16:35
drmeister
Why? No idea yet. But you are mucking around with the lowest level of the runtime.
21:17:38
drmeister
You could put an ASSERT(instance.generalp()); in front of the instance->instanceRef(index); Then turn on DEBUG_ASSERT - you should probably build with that anyway.
21:25:10
Bike
now it's segfaulting while trying to print the pointer. i think it's trying to actually print the object. does %p not work in bformat?