Greetings! "Paul F. Dietz" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
