[Gcl-devel] Re: readtable-case is in, but cvs head temporarily broken

[Camm Maguire]

Greetings!

"Paul F. Dietz" <address@hidden> writes:

> I don't know if this was the problem you were talking about,
> but this took over an hour to build on my machine (Athlon XP+ 1800),
> and then ended with a READ error in gcl_pcl_impl_low.lisp.
> 
> That time is a large slowdown from even the previous build
> time (25 minutes on the same machine).
> 

Thanks for the feedback.  It should be back to where it was now.  Just
shows how easy it is (for me at least) to introduce massive slowdowns
in pursuit of ansi compliance and "clean" code.  I had fixed the
make-sequence errors, including checking the size against the implied
length of the type.  To do this, I normalized the type, which called
make-sequence again to handle the list at the end of normalized array
types, which then normalized the type 'list, etc. before finally
returning the result.  In addition, subtypep1 was used to distinguish
lists from arrays.  All this just to concatenate a string(!), which is
where the bulk of the calls to make-sequence lay.  On the one hand,
this is encouraging as it indicates that problems can arise in system
functions entirely apart from the compiler algorithms I'm worrying
about.  On the other, the need to put in accelerators obviously makes
the code more fragile, as the origin of the logic and the accelerator
must be kept in sync.  I've tried to deal with this to some degree by
basing the compiler's type manipulation logic on the centralized logic
in gcl_predlib (as opposed to the earlier entirely separate
streamed-down implementation) and memoizing the results flushing at
the end of compile-file. 

In some respects I find it useful for optimization purposes to study
the interpreter action in saved_pre_gcl.  This comprises the bulk of
the GCL compile time.  One might easily dispense with its slowness by
loading compiled results as they accumulate, working on the evaluator,
or just generally sweeping it under the rug of fast modern hardware,
but then this just delays and masks issues such as these which appear
to creep up so easily in lisp.  Perhaps I'm going about things the
wrong way.  I'm trying not to avoid the lisp built-in functions but
rather make them serviceable.

On the test suite front, it would be most helpful if you could look at
the recent work and suggest how the BUGS list should be updated.  I've
tried to address make-hash-table, make-sequence,
set-syntax-from-character, print-symbol, readtable-case, and the list
functions in this pass, though some errors which get squashed
resurface occasionally as others are addressed.  I could use a little
clarification on how SET-SYNTAX-FROM-CHAR.SHARP.1 and the remaining
failures in print.symbol.random.? are supposed to behave if you have a
moment.

Take care,



>       Paul
> 
> Camm Maguire wrote:
> > Greetings!  There appears to be a small problem with the commit I
> > n\made last night.  Just a heads up, will try to fix it today.
> >
> >>From the changelog:
> >   * enhanced reader-error support, readtable-case support,
> > proper-list
> >     type support, list function ansi fixes, hasfillp slot for arrays and
> >     vectors, character traits, setf gethash interpreter fix, make-hash-
> >     table ansi fixes, simple-vector-p ansi fix, print-symbol fixes, set-
> >     syntax-from-char fixes, rework loose package syntax, prohibit loose
> >     right paren in reader
> > Take care,
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah