[cello-devel] Hello, anybody there already?

Kenny Tilton ktilton at nyc.rr.com
Tue Mar 2 15:43:25 UTC 2004

Frank Goenninger wrote:

>Hi Kenny -
>I knew I'd make you into sending some message if you are online ;-)
>Hey, extremely good progress on the re-factoring. I was quite sure
>it'd take you a couple of days for such a massive thing.
>Regarding the DLL weird behaviour: 
>I thought about when to (re-)load a DLL is really necessary. On Unix,
>you get back some condition (of type "simple-error" IIRC) when the right
>DLL has not yet been loaded. So an idea would be to catch that error
>and do the (re-)load attempt then. This guarantuees that even if the
>global flag says "Yes, the DLL is loaded" you have a save execution
>because the handler will take care of it.
That could be tricky and implementation-dependent. Esp. if there is not 
a specific error to indicate the specific condition--no matter what goes 
wrong, I'll reload the DLL. But it could be a fallback. Hopefully I will 
just figure out what I am doing wrong. :) I already found a couple of 
"duhhh" mistakes in this regard, I just need to keep on learning/debugging.

>>I'm here, back on the re-factoring job after some time on Lisp + music.
>How was the Supercollider Fest? Had a few good sounds going?
Definitely. A seven-year veteran came from a couple hundred miles away 
and ended up making a nice presentation of his work, which was done for 
his PhD. What he did was use Supercollider to sonify medical data to 
help doctors diagnose heart conditions.

>>Going well, just got cl-magick working again. I now have separate, 
>>standalone sub-systems:
>>cl-magick (still a little cleaning here)
>>cello-glut (widgets, but no magick and only glut fonts)
>>cello-ftgl (cello-glut + cl-ftgl)
>>cello-magick (not sure if I want to bother with this one)
>>...and then:
>>cello (the whole shooting match)
>Now that really pleases my system architecture nerves... :)

:) yeah, but the permutations really got to me (multiply by three, 
because I develop under ACL+projectmanager, then retest with ACL+ASDF, 
then test with LW+ASDF. Make a change, start all over. So progress on 
functionality is at a standstill. But now the refactoring is done and I 
will simply have to get back to work on functionality and leave porting 
to those who need it for their platforms. That eventually will include 
me and OS X + Lispworks, but possibly not for a few months.

> - painful but necessary" (I keep saying this to my people
>here on the team ...
especially something the size of Cello and with an intended audience of 
"all Lisp programmers" and especially Lisp newbies. It is such a large 
effort that I'll go broke if I try to do it myself alone, so open source 
either works or does not. Your contribution will be huge once we get it 
merged in with my latest release and whatever Thomas has on his hard 
drive, because it (a) is open source at work and (b) can draw in more 
potential contributors.

I think the best thing I cna do is round out the widget set so the 
screenshots/capabilities prove irresistible.

>Structured error messages. Ouch! Yes, I know... It's boring... But...
>When trying to locate where some error message originated from I had to
>"grep" the source for a specific pattern. It would have helped to have
>a clean error indication like:
>"*** Error OGB:C1000 - CRITICAL !"
>"*** Could not load font 'ARIALN'."
Agreed. There must be a hundred places that could use sanity checks like 
that which would shorten the learning curve for newbies tremendously. 
Me, I can just look at a backtrace and work backwards in a few seconds 
to the original error, but anyone else faces hours of debugging.

>In Debug mode I often also make the error location visible:
>"*** DEBUG INFO: Function "Blabla", Checkpoint 2."
>Also, I most of the time introduce a package-global struct "error-info":
>(defstruct error-info
>  severity       ;; usually assigned: :critical, :error, :warning :info
>  package        ;; nickname of current package
>  id             ;; unique error number within the current package
>  message        ;; the message associated with that id. Might be a
>                 ;; "format" string
>  location-info) ;; Only shown when in debug mode: function, checkpoint

>A function "errmsg" could build a structured message like the above 
>from that.
>Should I come up with something like that? What do you think? This is 
>currently only a translation of experience with other languages but
>with about 12 years of production software creation and delivery. 
>I'd really like some feedback because I really don't know if you ever
>need something like the above for a production Lisp system!
I started with something like that when I first got involved with Lisp, 
like you harkening back to production projects on mainframe systems. Now 
I just use assert, or:

    (unless font (break "no such font"))

The backtrace lands me in the debugger with the stack right before my 
eyes where I can see which font was being loaded and where the load 
failed and what code was trying to load that font, so I do not need too 
much more info from the error. Even without source debugging. (lispworks 
is better at that than ACL, though I hear Franz has plans for better 
source debugging).

What happened to me was that I created a formal error scheme and then 
found I was not using it because it did not add enough value. I guess 
the one thing I have learned to do is:

   (break "~a cannot find its assigned font ~a" widget font)

...if I think the salient arguments will be hard to find on the stack. 
Code improvements like that are always welcome. Also, it may be that I 
am spoiled by the commercial Lisp environments I have grown up on. 
Possibly other Lisps are not so easily debugged from a backtrace?


ps. I still have to go back to your changelog and look for things I 
should have incorporated in Portacello 2. I was not ignoring that, I 
just wanted to get something out the door.



Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application

More information about the cello-devel mailing list