[ I added ast-users back to the forwarding list ] On Wed, 13 Jun 2012 13:04:33 +0200 Lionel Cons wrote: > On 13 June 2012 12:39, Lionel Cons <[email protected]> wrote: > > On 13 June 2012 06:35, Glenn Fowler <[email protected]> wrote: > >> the AT&T Software Technology ast beta 2012-06-12 source release > >> has been posted to the download site > >> http://www.research.att.com/sw/download/beta/ > >> the package names and md5 checksums are > >> INIT 534d4fa288fdcf79141b1ec2e71bee8d > >> ast-base 6a08c19d22027433b0808279e6638097 > >> ast-open 097c6578696efc82143dbf7fd15b7a83 > >> ast-ksh 4e2651f7ca60d73636bbe02576ca50d7 > >> the md5 sums should match the ones listed on the download page > >> if not then don't download > > > > grep wasn't moved to ast-ksh, right?
> Glenn, David, what exactly is the technical problem which prevents > grep, od, tr and xargs from being moved to ast-ksh/libcmd? I don't > understand the technical motivation of not doing this. we've stated our case I'll restate one more time I guess we have a larger than average (internal not-open-source) user base to deal with a lot of ksh usage within that user base is on critical paths any disruptions obviously cause delays, but it can also damage ksh's rep and make it harder for us to convince projects to use our stuff many times ksh and the standard (1) commands are a foot in the door to other software that we first peddle internally, and then externally even the seemingly most simple change can have unforseen consequences adding a builtin like grep is simple technically but all of the consequences are not known operating inside the ksh address space requires a lot of coding discipline we don't yet know all of the details of that discipline or its manifestation on different platforms sure it was exercised some on linux and solaris but we have hp, bsd, aix, mvs, cygwin, windows instantiations that haven't gotten the same treatment so please set aside the mostly valid arguments for moving FOO to libcmd (convenience, efficiency, no approval needed, etc.) and let -lcmdtst burn in for a while -- let it be thouroughly *beta* tested -- let it be tested in a way that if a completely catostrophic flaw were found users would simply edit a non-default setting in a .paths file to work around it -- let it be tested to the point where we have a collection of regression tests that we feel cover all of the problem areas -- in particular for grep we need some pty(1) tests to cover all of the interactive interrupt-laden scenarios also, let the -lcmdtst paradigm itself be thouroughly tested after all, this will be the mechanism for most orgainzation to add their own builtins btw, "thouroughly tested" is not a voting process, ``"worked for me" N times => its good'' for ast it implies a good faith effort to supply regression tests that hook into the build system which automates the testing grunt work (this was learnt over time -- in general in ast the parts that have the most tests are the newer parts -- tests for older parts happen when they contribute to bugs or are otherwise updated) its fairly easy to get a base set of tests to work the first time its much harder to code software that has no regressions as the environment around it evolves please suffer with what may seem to be a non-ideal interface for the better good eventually, if your favorite command migrates from -lcmdtst to -lcmd, *you won't have to do anything* to take advantage of it it I won't explain this position again for the rest of the year on that note how about chanelling this -lcmd energy to working on a short list of candiates for -lcmdtst my first one is ls(1) for practical reasons it seem that windows8 "power shell" (I think its cmd.exe) has dir builtin, and apparently no dir.exe, so debugging the bootstrap uwin env from ksh gets tedious _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
