Garrett D'Amore wrote: > Roland Mainz wrote: > > Garrett D'Amore wrote: > >> Roland Mainz wrote: [snip] > >> 1) You should remove ident lines now -- you won't be allowed to put them > >> back and fix them later. (Not unless you get some kind of special > >> waiver from ON CRT, and I really don't think one should be granted.) > > > > Umpf... for the Makefiles+code we "own" (e.g. > > usr/src/lib/lib(shell|cmd|dll|sum|pp|ast)/, usr/src/cmd/ksh/ etc.) I'll > > remove the "ident" lines later today... for the other Makefiles I would > > strongly perfer to "defer" the removal of these lines to a very very > > late point (10mins before putback ? :-)) since this is a major source of > > "bitrot". > > You'll need to remove them, and submit the review, before you submit the > RTI. Normally it takes more than 10 minutes for your advocate to > approve them.
As said I can remove them for the Makefiles+code we "own" now and the others as late as possible since the "ident" stuff is the _major_ source of bitrot. I don't want to play the "catch the ident changes"-game over and over again since the time for that comes from my almost non-existing chunk of free time... [snip] > >> b) The normal perf. concerns. The effect of your change may be > >> positive, but some kind of analysis would be useful. (And I'm not > >> talking about your atypical scientific computing applications. I'm > >> talking about impact to things that folks are already doing. A good > >> perf. test might be building ON -- with *stock* Makefiles. Just because > >> you can tune it for ksh93 doesn't mean everyone will do so, so what I > >> want to know is how "untuned" applications will behave. Boot time > >> analysis may be helpful as well. > > > > I can't provide boot time analysis since I am mainly using virtualised > > environments (like VMware) which are not 100% reliable for peformance > > testing but OS/Net builds a bit faster (not much but we definately not > > regress the build time). > > There are test machines available within Sun. You're still inside SWAN, > right? Ask about LRT2 (hint: goto lrt2.sfbay to reserve a machine for > remote access.) > > There are some test suites available for running standardized boot time > testing as well. I forgot the URL, but I bet you can find it on the > onnv.sfbay page. (And probably on the OpenSolaris ON community pages as > well.) Ok... but in the meantime I've booted by VMware installation with and without the binaries from http://www.opensolaris.org/os/project/ksh93-integration/downloads/2008-08-10/ and there isn't a difference (measured until the "Login:" prompt appears) besides "statistical noise" (with and without the new binaries the boot time fluctuates around ~four seconds randomly (on VMware 6.5 with a Ultra24), measured over five boots for "with" and "without" the new binaries). > >> c) kill -l change is slight, but seems also to be "arbitrary". Is > >> there a reason that the old SPACE behavior isn't retained? > > > > That was discussed in the ARC case. The POSIX standard allows both (Don > > Cragun checked and confirmed this) and ksh93 and the AST toolkit output > > the one-per-line syntax since the beginning. And it's easier to parse. > > Hmm... I just worry that if anyone might be surprised by the new > format. No, we already discussed and tested this item to death. See below - we leave it as-is (e.g. as ARC'ed). > If its easy to retain the old format, my preference is to do > so, just to avoid the *chance* of introducing a problem, unless there is > a compelling reason for the change. (I'm not sure the ksh93 legacy > behavior counts or not.) We're going to keep the AST "kill" behaviour since we already disucssed, tested and ARC'ed this stuff (and if we would revert it we have to ARC it again, test it again etc.). And right now we _know_ we don't break anything within OS/Net (the same applies to Solaris 8 where replacing /usr/bin/kill with the ksh93/AST version works without problems, too), SFWNV, X/FOX and the Solaris testing consolidation. [snip] > >> 4) Will we finally get open man pages for these commands as well? "man > >> type" is not terribly useful on OpenSolaris 2008.05. > >> > > > > Try $ type --man # ... all ksh93/AST commands support the options > > "--man" and "--nroff" to obtain/generate manual pages. > > > > Great. But what about ordinary "man"? Having builtin man pages might > be nice (although there are problems that it poses for L10N as well, I > think, so I'm not sure its an unqualified benefit), but we need to have > the same docs in the "normal" man location. (I.e. users that have > decades of typing "man <command>" experience... Mhhh... that's a question for the docs folks... but for those commands coming only from AST+ksh93 we can AFAIK provide opensourced manual pages... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
