2010/5/27 Alan Coopersmith <alan.coopersm...@oracle.com>: > ольга крыжановская wrote: >> Roland also said that perl has the same problem. Since perl in ON >> needs to be build with both Studio and gcc compilers the perl build >> had to downgrade its floating point support from long double to double >> which causes interoperability problems with 3rd party perl software >> and turns Solaris /bin/perl unusable for numeric applications. > > That problem should be solved now that perl integrates to SFW, not ON. > We offered many times to solve many ksh93 integration headaches by > doing the same there...
Grumpf... AFAIK we had this kind of discussion many many times. Lets recall some of the reasons (I'm not listing all, just the "top eight" out of my head, otherwise this email would become much bigger): - ksh93 greatly benefitted from being in OS/Net. All the rules _forced_ us to invent new things&&stragegies to hunt down bugs and adopt the code (I remeber the first year of ksh93 in OS/Net as stress... but IMO it was worth it since we slaughtered many many bugs). We would never be at the static current level (that means ksh93 version "u-", which is not integrated yet (and excluding the mad/crazy command substitution issues we have since we switched command substitutions from |mmap()|'ed files to pipes... something which I'd like to revert again ASAP)) without such rules. Relaxing them by putting ksh93 into SFWNV will IMO cause a slow degradation of quality since noone will care to enforce them. People like John Beck and others really did a very very good job with keeping the quality up and I don't see how this should happen with SFWNV since AFAIK most of the QA people were RIF'ed (please correct me if I am wrong). - As Olga pointed out: The native build system of AST and the way how SFWNV builds things don't work well with each other (it is not suited (and the use of parallel builds, too) for "autoconf" either but in SFWNV noone cares (or seems to care) if "configure" tests which use timeout randomly change between builds (this issue depends on the load of the build machines)). There are a lot of teething things which can go wrong. We had such problems in OS/Net too but solved them by using our own Makefiles and lots of other little tweaks. Moving ksh93 to SFWNV would require to rewrite all this stuff from scratch and this is around 6-9 manmonths of work. - Having our own Makefiles and build configuration allowed some interesting optimisations and addition of features which are not part of the upstream work (for example we have a few very popular extra builtins (like "poll" or AST "egrep"/"grep"/"fgrep") which you won't find in the default upstream configuration) - ksh93 was added as part of a bigger project, basically as starting point for an userland modernisation (but we were carefull not to sell it as this in the initial ARC case, AFAIK PAC&co. would've eaten us alive (feet first to make it extra cruel) like they did when other people like Henk proposed such a move earlier). - All code affected sits in OS/Net. - There were two colliding versions of libcmd, one from AT&T and one from Solaris (both had a common ancestor but evolved and mutated in different universes until we merged them back). Having both in a single, merged libcmd.so.1 has simplified many things (remeber the many phone call we had about this fun ?) - libast&&co. consumes a couple of private interfaces which all live in OS/Net. This is by design and should (in theory) go in both directions, e.g. OS/Net should be able to consume private libast&co. APIs [a] and the libast stuff should be able to use private OS/Net interfaces. We could stop using them but this would come with a _HUGE_ performace and code bloat (e.g. another 140k of code would be needed in the already big libast [b]) price tag and there would still be some interfaces which need to be contracted - April originally estimated seven man-months of work to do this (and noone was interested in doing it since it would cause more pain for exactly _ZERO_ benefits, see [a] below). - ksh88 sits in OS/Net... it was logiacal to put the successor there, too (by using the "grandfathering" rule). All the other things and our future plans listed above pointed to OS/Net, too. [a]=For example: 1. "perl" was planned to use SFIO for a huge performance boost (but this got deferred and the RIF of Tim Sparlin's team stopped active work on this from Sun's side). The matching code changes are still around but we would now require lots of ARC work instead of just doing it without much pain. 2. As part of the modernisation work we planned to investigate and implement to superset libc's stdio implementation and move libast's implementation to libc. The reason/rationale was (and IMO still is) that libc's stdio implementations is one of the slowest (and some people have claimed it's _THE_ worst, too), lacks standards conformance by default and lacks features other implementations have since years (some things have been hacked away by adding horrible hacks or tacking-on new features but this never really solved the issues completely (and the code became incresingly hard to maintain)). These are all problems which cannot be fixed with the existing code. The idea was to do a fresh start: Stuff libast into OS/Net, work out the problems we hit, review the code to make sure all APIs can be extended easily without running into the same problems the original libc stdio implementaton had, run the test suites against libast's stdio and once this all runs smoothly move the stdio implementation to libc (the old implementation will remain, hidden by ELF symbol versioning). Basically most of this work has been done and we were at the point of testing and asking for the funding of a prototype for the code move and inception ARC case when Tim's team was RIF'ed. This was really BAD timing. 3. Same as [2], but for regex API but without any nasty ELF symbol versioning stunts required. The AST implementation is _MUCH_ faster and has a few interesting/usefull extra features which would be nice-to-have (like the ability to select any pattern system via the prefix system, basically ending the 20 year old war of "my pattern system is better then yours". With two implementations (AST+Solaris) this could even be proposed as POSIX standard addition). [b]=If anyone considers to complain: The problem is that many functions in libc are far away from the standards or simply missing. libast is much smaller on platforms like Linux or MacOSX... guess why (which is more or less the full circle back to the beginning of this email thread were Olga asked for |long double| variants of some of the C99 functions in libm.so.2 to avoid having to duplicate this stuff in the AST code) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ksh93-integration-discuss mailing list ksh93-integration-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
