Hi, Thanks for the responses...
The "lack of activity" was someone complaining in another page, but I can't find it again, so forget it :) I've created a branch, master-ksh93-upgrade. I haven't the time currently to try to build it, but hopefully others might. Thanks! -jon On 8/22/20 4:04 PM, Chase wrote: > 1. It is based on master, I remember you saying not to add new > features to autotools since the focus should be on making it work. > 2. I believe cloning will have to be done via git clone --recursive > now, and we will probably have to lock ourselves to a specific SHA at > a time until I can make a quick script that makes a patch file due to > the files we need to merge manually so that we dont get out of sync > with master (builtins.c and init.c, formerly userinit.c but that seems > to have been merged into init.c years ago), i tried merging them into > the project itself but they depended on our symbols, I was thinking > maybe I could just make our files into a shared library, but that > needs ksh's symbols, so its a cyclical dependency. I wrote in > README-DEVELOPER about our new update process, its pretty simple: go > into ksh93, git pull, merge the changes of builtins.c and init.c with > our own. > I am not an expert by any means, most of the info I got was from here: > https://github.blog/2016-02-01-working-with-submodules/ > 3. I don't think anything has been set in stone yet, I've heard some > chatter about cmake, but I think they are open to anything except > meson, as ksh2020 used meson and as a result excluded a few more > obscure unixen, such as AIX and HPUX. Right now their main focus is > bugfixing, but more on that in #5 > 4. They did, this is the last bug I need to solve, they both fail for > the same reason, valgrind says its an invalid read and gdb says its a > corrupted pointer, the head of ksh said he would be willing to look at > it, but the code needs to be public to try out. > 5. I have high hopes for this ksh fork. The original ksh is now in > maintenance mode and had told the community to fork it. I am not sure > what you mean by the lack of activity, the documentation does mention > the ksh-community fork and that having no activity despite being the > fork people rallied around, but this is a different fork. The head of > the project is very active, willing to accept patches (I sent a few > upstream to make our dtksh work), and keeps things relatively stable > as opposed to ksh2020 which ripped large portions of the code we > needed out. > > Thank you for your time, > -Chase > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, August 22, 2020 2:30 PM, Jon Trulson <j...@radscan.com> wrote: > >> Hi Chase, a few comments/questions: >> >> 1. is this patchset based off of master or the autotools branch? I >> would need to know this in order to create a separate branch for >> this (which I agree with doing, considering we are essentially >> throwing away our own ksh and would then be dependent on someone >> else's implementation ). >> 2. How does the clone/checkout/build experience change? We do not >> currently have any git submodules, so checking out and building >> the code will different. Could you provide instructions/advice >> for others wanting to take a look? >> 3. I see they still seem to be using iffe and maybe nmake - do they >> have any plans for updating the build mechanism(s)? >> 4. WRT the failing tests - Do they work in our current ksh >> implementation? This isn't necessarily a stopper, but would be >> important to know. >> 5. What's your feel for the future of this particular ksh repo... >> They do seem to be fixing things, but also mention a lack of >> activity. >> >> >> News: https://github.com/ksh93/ksh/blame/master/NEWS >> >> TODO: https://github.com/ksh93/ksh/blob/master/TODO >> >> >> Seems promising, and no doubt our ksh is on the old side, so it would >> be good to get this going if we can... >> >> -jon >> >> >> >> On 8/20/20 7:59 PM, Chase via cdesktopenv-devel wrote: >>> Hi all, >>> So these patches make us use the new ksh93 as a git submodule >>> (https://github.com/ksh93/ksh), though I would like this put in its >>> own separate branch. Reason being everything is working except two >>> test cases, EventHandlerTest and CallDataTest4, both of which crash >>> when trying to display environment variables related to callback >>> data, the head of the new ksh has been willing to help, but I need >>> to make the modifications public, plus I would like any solaris/bsd >>> bugs to be ironed out now, as I do not have any way of testing them >>> myself. >>> >>> Thank you for your time, >>> -Chase >>> >>> >>> >>> >>> _______________________________________________ >>> cdesktopenv-devel mailing list >>> cdesktopenv-devel@lists.sourceforge.net >>> <mailto:cdesktopenv-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>> >> >> -- >> Jon Trulson >> >> "Entropy. It isn't what it used to be." >> -- Sheldon >> > -- Jon Trulson "Entropy. It isn't what it used to be." -- Sheldon
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
