Martijn Dekker <mart...@inlv.org> wrote: > Op 16-06-20 om 17:37 schreef Alan Coopersmith: > > We are maintaining ksh93 packages, but not doing active development work on > > them. Our packages are still based on the last stable release from AT&T - > > 2012-08-01 with an unfortunately high number of local patches applied: > > https://github.com/oracle/solaris-userland/tree/master/components/ksh93 > > > > We really don't want our ksh93 to be a separate fork, but got stuck here > > due to past decisions it's a bit too late to undo now. > > Maybe not, because 2012-08-01 is precisely the version that we are > basing our rebooted development on at the new ksh93 repository. This new > project is really picking up steam as we speak. Many bugs have been > fixed already and many more fixes are coming. Stability, correctness and > POSIX compliance are the immediate goals. Feature development can wait.
Is my impression correct that you did not use the modifications from Redhat people that introduced non-portability, many bugs and a slowdown? Be careful when looking at changes from these people, since they e.g. did throw away the ksh93 specific malloc() that is much faster than the system malloc() since it does not need to take care of multi-threading. Also note that ksh93 depends on being able to use a freed()d piece of memory even after the next malloc (if that returned a different start address) as it has been in AT&T malloc() in the time before multi threaded environments. > I would like to invite you (as I do everyone) to submit any of your > fixes that are suitable for incorporating upstream to > https://github.com/ksh93/ksh as pull requests, documenting in each > commit message what it fixes and how it fixes it. I pulled the snapshot, compiled and had a quick check for speed. ++ It still uses the mature and highly portable ksh93 build environment. ++ It still compiles out of the box on Solaris - It does not compile/use libshell. - Using the default compile setup, it is 5.5% slower than the OpenSolaris ksh93. Mesured with the "configure" script from Schilytools. - Using the additional compile options "-O -fast -xspace", it is still 2.5% slower than the OpenSolaris ksh93. So this version is as fast as the current Bourne Shell (bosh) but not as fast as the OpenSolaris variant. It still is faster than shells other than bosh. Note that OpenSolaris decided to use ksh93 because it was the fastest shell available. It may be that the speed is based on the fact that ksh93 and it's libraries all use shared libraries and ELF LAYZYLAD and this way may avoid the need to load or fork() a huge binary. Also note that OpenSlaris implements kernel support for compiled ksh93 scripts. Is this still supported? Do you see a way to support libshell and the other OpenSolaris specific enhancemtns like compiled in compatibility to the Solaris binary commands from /usr/bin/ and /usr/xpg?bin in the ksh93 builtins? > Please, have a look at our commit history and let me know if you like > what you see. We'd be delighted to have any fixes you are willing to > share, and hope we will prove worthy to become the new ksh93 upstream. I did not yet lookinto that, but I am interested... In general, I am looking for code that could be used for the ksh93 in the OpenSolaris base sources that are compiled using the build environment from OpenSolaris. So it would be important to have a source tree with the same structure that allows comparing. Jörg -- EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
