Re: A whole bunch of bug reports and patches

[Trent Lange <lange@CS.UCLA.EDU>]

Rob --

Thanks for the quick response and patches.

I have questions on just a couple of your responses:

>   Things printed to the screen do not appear until a newline is printed.
>
>Is this on stdout or under Hemlock?  Anyway, in either case, you can force
>output with FORCE-OUTPUT, and output is also forced by an input wait.
>Portable programs should do this when showing progress.  Especially under
>Hemlock, this is an important efficiency optimization.

This is under *standard-output* in a normal xterm window;  I haven't
tried Hemlock yet.  Thanks for the FORCE-OUTPUT tip;  I'll use it, but
I'm sure there are going to be quite a number of other programmers
unaware of it.

>   Get note on failure to use assertion from function type declaration
>   because of assignment to one of the arguments, even though it should be
>   easily provable to the compiler that it wouldn't cause any problem:
>
>o.k.  I made a change to suppress the note in the case where there is
>already an argument type declaration just as good as the argument type in
>the FTYPE declaration.  That isn't what you meant, but it was easy.using

Is there actually an optimization hit for this?  The compiler note isn't
clear on what function type declaration assertion was being prevented --
is just the type of the variable, or the entire function type declaration?

>   using one of the function variables is a good trick to speed up small
>   functions, and it would be a shame if it's counterproductive.
>
>With Python, there shouldn't be any difference between assigning an
>argument and rebinding under (SPEED 3).  Under lower settings, the compiler
>does take care to preserve the real argument value so that it can be
>displayed in a backtrace.

Nice.  Of course, I'd like my programs to be "portably optimal"; i.e.
having the same code be as efficient as possible even under stupid
compilers -- so it would be a minor problem if this example that helps
under other compilers hurts with Python.

>   CONCATENATE, when called with OUTPUT-TYPE-SPEC simple-string and all of
>   its sequences declared as type simple-string, always gives the following
>   optimization note for ASH
>
>This is part a questionably correct transform, part the above-noted
>alarmist efficiency notes.  You should get reasonably good code in unsafe
>policies.  

If the efficiency problem can't be easily declared away, could this note
also be suppressed since there's nothing a programmer can do about it?

Actually, this and the above FTYPE declaration note suppression seems to
be a good reason to have a couple of options on levels of compilation
notes;  one like the current default, where all possible notes are shown,
and one that would be normally used, in which only notes that a
programmer could do something about would be shown.  Perhaps there is
such an option already described in the manual;  I just haven't yet had the
heart to print out the entire 180 pages of the User's Manual.  This does
bring up another point -- because of the length of the manuals, it would
be convenient to have chapter-sized postscript chunks available to print
out (along with a separate TOC, of course) when needed.

And back to one more optimization question;  probably by far the biggest
one of all:  is there any way to optimize the MOVE-FROM-SINGLE (cost 13)
that always happens when a declared single-float value is returned
from a function or block?  This is an absolute killer when it comes
consing.  I would hope there's a way to get around this and keep the
values in a register if the single-float return value of a function
is going to be immediately used as an argument as part of a known
single-float computation, as in e.g. (+ 2.0 (returns-single-float x)).
Is this part of the needed Sparc optimizations you talked about?

And finally:

>[b.t.w.  I just picked up and merged the latest PCL with our sources.  This
>version is not in the current release, but you can find it the the pcl/ RCS
>tree.  I was going to send changes to Gregor, but I hadn't gotten around to
>it.  Have you duplicated this work?]

Well darn, I suppose I have;  I should have brought this up to you earlier.
Essentially all I did to merge PCL was to do a DIFF on your 15a source
version with the straight PCL Rev2, and merged those differences in
(most of them anyway, I may have missed one or two).  But the revision of
PCL I've been working on-and-off on is significantly different than
the current latest (Rev 4b);  I've personally needed many of the other
elements of the CLOS AMOP, and so have put them in, along with a number
of optimizations.  I plan on sending a "beta" version to Gregor in a
couple of weeks when I get a chance to finish the changes.  So I would
suggest waiting before sending your changes to Gregor;  if all goes
well here, they'd soon be superseded.  I'm sorry I didn't mention this
to you earlier and saved some work.

Did you make any additional changes besides those earlier differences?
I had a couple of minor problems in making PCL work with your sources.
The first one was that the PCL walker doesn't handle SYMBOL-MACROLET
as a special form.  I ended up having to UNINTERN the CMU SYMBOL-MACROLET
and use the PCL 4b version to get it to work.  I couldn't make head nor
tails of their walker;  I'll probably end up posting a plea for somebody
to write a SYMBOL-MACROLET walker template when I send out the revision,
unless you've already found a better way.

Another question about PCL and CMU-Lisp:  is there a way to patch PCL's
MAKE-TOP-LEVEL-FORM to use the Name received, like the LCL3.0 patch of
setting lucid::*compiler-message-string* does?  This is actually a very
major issue for debugging PCL code, since without it the names of the
method specializers never show, either when the defmethod is being compiled
or in the debugger.

Anyway, thanks again for the response,

- Trent