🚀 go-pugleaf

In article <1990Sep21.161025.14703@agora.uucp> billsey@agora.uucp (Bill Seymour) writes:
> In article <82=R02Cb02ds01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes:
> :
> :Now, the (RSN) v4.1k version of ls will continue to provide internal wildcard
> 
> 	And this one will fix that annoying problem with both 3.1 and 4.1 that
> puts my 3000 into 'real, real slow speed' mode? It doesn't happen each time,

[ Just to avoid confusion, the problem exists in v3.1 and v4.0k ... v4.1k
  has yet to be released. ]

Yes, the problem has been found!  There are several other, quite different
ways it can manifest itself also, BTW.  Henrik Clausen found that *his*
manifestation of the problem disappeared if the standard Lattice "cres.o"
startup code was used in place of the custom "mycres.o" code (thanks again,
Henrik!).

This also explains why v3.1 has the problem, as that code is identical
in both 3.1 an 4.0k.

Not having a 3000/2.0 myself, I haven't bothered to try and isolate
exactly *what* in "mycres.o" was causing the problem though.  The price
paid for this solution is an increase of a few hundred bytes, which I
think is "reasonable".  Another plus, is that is by using the standard
startup code, it allows me to use the Lattice getenv() function, rather
than having to "roll my own" (though *that* fn() adds nearly a full 1K
to the executable).  Also, it means one less piece of code that needs to
be supported.

There was one further complication with this.  Someone was getting
"instant Guru's" using a test version of ls that was built using the
Lattice v5.05 "cres.o", but when it was recompiled using the SAS
v5.10 version, the problem went away.  Since this was done under a
beta version of a commercial product, I'm not sure where the problem
really was, but that's why I've been waiting for my copy of SAS v5.10
to show up before releasing v4.1k of "ls".

Which showed up yesterday ...!!!


So, in summary, "ls" v4.1k will be along in not too long ... after some
final beta testing, and it will be a bit larger than I'd like (feature
enhancements aside).  I will try and reduce the "bloat" in a subsequent
revision, but I want to get something that works well with both 1.3 and
2.0 out ASAP.

/kim

-- 
UUCP:  kim@uts.amdahl.com   -OR-   ked01@juts.ccc.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
BIX:   kdevaughn     GEnie:   K.DEVAUGHN     CIS:   76535,25