[Bese-devel] Re: Is dynamic-forms-demo working in the latest box set? I get a `NIL' is not of the expected type `ARRAY'

[Lou Vanek]

Popovich, Thomas wrote:

> Hi Lou,
> 
> Thanks again.
> 
> Can you somehow "remove the "bese-devel" from the to list"  as I usually
> post from a gmail address   ... and we can not access gmail from work.
> (so it's a 2 step process   write a msg go home.. and post it)

When I remember, I like to post to both the personal acct and the dev list
so that others may keep track and possibly benefit from similar experiences.
If not for now, but for the future, so similar questions don't have to be repeated.
Since this letter is going to two mailboxes I would think you can simply
ignore the bese-devel ML, can't you? I'm pretty think when it comes to
how Big Gov does things, but I'd like to continue to be polite and keep
bese-devel cc'ed unless this is privileged conversation, which I have no
reason to believe this is.

> 
> PS:
> 
> How did you narrow it down to that stmt?

Like you, I did a grep, and there is only one line that has adjust-array
in it. I have vim set up so that I can do this very quickly. This is one
reason why I am suspicious of locking myself into any proprietory IDE.

> Frame:
> 
> 11: (ADJUST-ARRAY NIL 1)
> 
> 
> is seemingly bad looking.  I'm new at debugging tracebacks in Lisp - the
> traceback should have linenumber and filename (if you compiled the file
> from a file... that would be nice)  Anyway the traceback seems to lack
> that info.

To be clear, I am just an innocent bystander. Marco is the one who wrote, owns,
and maintains UCW. I just happened by and noticed something cool, so I stopped
and tried to get UCW to work with Clisp. RoR is nice if you can live w/in it's
capabilites envelope, but I think I found something a little better. Still not
sure. ActiveRecord still beats the crap out of anything I've been able to get
to work with Clisp, but I may be able to get Drew's postgresql module to work
and that would be almost as good.

That said, coming from a C/C++ background I, too, am a little surprised there
aren't linenumbers/filenames, but the CL programming environment (I am slowly
understanding) is different: code tends to evolve via Lisp programming sessions
where the same expression may be re-evaluated over and over by hand instead of
running make. Good CLs will be able to show you the entire form in each frame
so there is little to no ambiguity as to what is going on, so line numbers are
of little consequence. Alas, however, I'm using Clisp, and things aren't so nice.
Or I haven't found the magic button yet that is able to unknot all these compiled
functions.

Yes, I'm sorta new to Lisp myself and had a terrible time acclimating to
these dense tracebacks, especially since Clisp compiles most of the information
away and I haven't been able to figure out how to get at most of it, even when
I think I'm doing something bright with "declaim".

What I do is look for the frame that initially signals the error and then
scrutinize 3 or 4 frames directly "above" in the stack. I noticed that
frame 10 is where the error was initially raised, so frames 11,12,13, and 14
would probably tell me what caused it.
Looking at frame 11 showed an array method with possibly a null "pointer,"
so to speak (my C background is showing). Anyway, that's bad.
So looking at frames 12 - 14 I noticed that the functions that were
successively called were:

...
((METHOD IT.BESE.UCW:RENDER (IT.BESE.UCW:SELECT-FIELD))
((METHOD IT.BESE.UCW::BUILD-DATA-MAP (IT.BESE.UCW:SELECT-FIELD))
(IT.BESE.UCW::INTEGER-TO-STRING 0)
(ADJUST-ARRAY NIL 1)
   BOOM

I noticed that build-data-map is defined only 5 times, all in the same file.
(Again, egrep quickly showed this and vim readily displayed all matches at once.)
Since the backtrace said 'build-data-map' was called with a SELECT-FIELD argument
that narrowed the search down to just one defmethod.

Sure enough, there is an 'integer-to-string' function called in this
build-data-map method, so I looked for where integer-to-string is defined
(if you're using vim and ctags it's "g C-]") and there is the 'adjust-array'
statement. To make sure I was looking at this right I double-checked the
Lisp Hyperspec and looked up adjust-array, and, yes, the first argument
to adjust-array is supposed to be an array object. Slime would
probably have told me the same thing faster.



> e.g.
> more frames:
>  11: (ADJUST-ARRAY NIL 1)
>  12: (IT.BESE.UCW::INTEGER-TO-STRING 0)
>  13: ((METHOD IT.BESE.UCW::BUILD-DATA-MAP (IT.BESE.UCW:SELECT-FIELD))
> #<IT.BESE.UCW:SELECT-FIELD "" @ #x21fb014a>)
> 
> I usually get the fnct name and grep the source.
> Do you have a pointers to how to more "effectively" get to the line of
> the problem.  I suspect that you can train SLIME to teach emacs code
> locations but I have not explored that yet.

I debug using both vim and emacs/slime. Clisp doesn't give very good
info in slime so I usually use emacs just to do evaluations, but use vim
to quickly jump around in the code and look for things. It's a bizarre
arrangement but it works for me because I have vim tricked out the way I like
with a bunch of syntax files, plugins, macros, function key mappings, etc.
It's mostly boils down to integrating egrep and ctags into vim and mapping
the most commonly used routines to just a few keystrokes. I'm sure the same
can be done in emacs. I used to be an emacs snob but I let most of my
emacs knowledge atrophy once I found vim to be more productive, at least
on non-lisp projects.

Lou Vanek
--
"My name is Ozymandias, King of Kings:
Look upon my works, ye Mighty, and despair!"