A Brief Guide to CLOS (1998)

Re:A Brief Guide to CLOS (1998) by crististm on Monday September 24, 2018 @05:01AM (#18056062)

> That's kind of the point that one does not care which methods actually run and when

What is the right method for debugging? I've been trying to debug one particular issue in CL code (McCLIM + Climacs) and I've hit the wall in every direction that I tried to see which method was responsible with the issue I've seen.

A plethora of around, before and after in both composition and inheritance that I've lost my way. I've tried various depths of reading and runtime debugging with no significant success. It left me with the image that I should have the whole program in my head to be able to understand it.

It's usually the case that the solution is where you're not looking therefore my question is where (and in what way) should I look at the code to understand what it is supposed to do?

[ Parent | on HN ]

Re:A Brief Guide to CLOS (1998) by lispm on Monday September 24, 2018 @05:24AM (#18056158)

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))

[ Parent | on HN ]

Re:A Brief Guide to CLOS (1998) by crististm on Monday September 24, 2018 @06:26AM (#18056465)

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...

[ Parent | on HN ]

Re:A Brief Guide to CLOS (1998) by TeMPOraL on Monday September 24, 2018 @07:47AM (#18056857)

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...

[ Parent | on HN ]

Re:A Brief Guide to CLOS (1998) by gumby on Monday September 24, 2018 @11:32AM (#18058530)

Typically your debugger will be a listener, so it's easy for you to write explanatory functions and in-the-moment expressions for unpacking what's going on. The latter is what I miss most whenever I end up in gdb.

[ Parent | on HN ]

Re:A Brief Guide to CLOS (1998) by lispm on Monday September 24, 2018 @11:52AM (#18058716)

In Flavors/Genera one has Zmacs commands: 'List Methods', 'Edit Methods' and 'List Combined Methods'. Similar functionality exists for CLOS - I think there is a 'Show CLOS Generic Function' listener command, or similar.

[ Parent | on HN ]