3 ms·

The debugging tools need to know about that. Usually you would look into the stack trace and see which methods has been called and editing the method object bri

by lispm 8y ago

The debugging tools need to know about that. Usually you would look into the stack trace and see which methods has been called and editing the method object brings us to the source code. Best when things are NOT optimized for low DEBUG and high SPEED. When I was working more with those things I wrote some browsers for browsing methods in CLIM and for MCL. The Lisp Machine should already have some tools, IIRC. LispWorks also has a generic function browser. One enters a generic function and argument types -> LispWorks shows which methods are used for those. FOO (FLOAT STRING) -> MULTIPLE-VALUE-PROG1 CALL-METHOD (METHOD FOO (FLOAT T)) (METHOD FOO (REAL T)) CALL-METHOD (METHOD FOO :AFTER (T T))

crististm 8y ago
Indeed, having good runtime debug tools is absolutely necessary for debugging dynamic objects [1]. I've come to this conclusion during this particular experience and I've confirmed it time and again. I've recently seen an older video of Gregor Kiczales on Aspect Oriented Programming and if I did not read in too much he emphasizes the same issue with proper debugging tools. Thanks for the tip; it might be what I needed for me to download LispWorks and try again. [1] Some kernel developers just don't get this even after you show them a call using a function pointer. Read the code they say. Right...
- TeMPOraL 8y ago
  Been working on getting a CLIM codebase (that is older than ANSI CL standard) running under modern open source implementations (SBCL, CCL). This too was my primary problem. CLIM spec was written with CLOS in mind, and implementations tend to absolutely abuse CLOS and MOP. I spent many long hours untangling all the mixins introducing :around methods. Good runtime debugging is absolutely crucial for this kind of code - something which open source CL implementations do not really have. Even prettified by Emacs, the inspector can get you only so far. Hell, this is the only time in my life where SBCL itself crashed completely when I did simple "jump to symbol definition" in Emacs...

by lispm 8y ago

crististm 8y ago

Indeed, having good runtime debug tools is absolutely necessary for debugging dynamic objects [1]. I've come to this conclusion during this particular experience and I've confirmed it time and again. I've recently seen an older video of Gregor Kiczales on Aspect Oriented Programming and if I did not read in too much he emphasizes the same issue with proper debugging tools. Thanks for the tip; it might be what I needed for me to download LispWorks and try again. [1] Some kernel developers just don't get this even after you show them a call using a function pointer. Read the code they say. Right...

TeMPOraL 8y ago
Been working on getting a CLIM codebase (that is older than ANSI CL standard) running under modern open source implementations (SBCL, CCL). This too was my primary problem. CLIM spec was written with CLOS in mind, and implementations tend to absolutely abuse CLOS and MOP. I spent many long hours untangling all the mixins introducing :around methods. Good runtime debugging is absolutely crucial for this kind of code - something which open source CL implementations do not really have. Even prettified by Emacs, the inspector can get you only so far. Hell, this is the only time in my life where SBCL itself crashed completely when I did simple "jump to symbol definition" in Emacs...