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:
>
> - 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 ).
>
> - 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?
>
> - I see they still seem to be using iffe and maybe nmake - do they have any
> plans for updating the build mechanism(s)?
>
> - WRT the failing tests - Do they work in our current ksh implementation?
> This isn't necessarily a stopper, but would be important to know.
>
> - 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
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> 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
