On Mon, Nov 25, 2019 at 04:03:41PM -0700, Jon Trulson wrote:
Well perhaps both of you could explain the situation... I've loosely
monitored the ksh situation over the last couple of years and they have
been making great progress on stripping out older stuff.  But I haven't
even downloaded or built their stuff, unlike both of you have I assume,
so what is the situation here?

I was not aware there were two versions - a new ksh2020.  What I did not
want to do is incorporate an old (though newer than ours) ksh
implementation that would not be supported going forward.  Then we are
still in the same boat essentially.

Is there much of a point otherwise?

If CDE is to incorporate a new ksh, my preference would be for the latest
upstream stable.

As for hash - what is it used for?  Do we need it?  I think it's
unlikely they would want to re-introduce something they have already
removed, though feel free to ask.  But first, do you know if we really
need it?

hash is a generic hash table implementation.  AST carried a lot of research
type stuff like this.  It's been a while since I've looked at ksh source, but
my recollection is that ksh didn't use this from libast.  If it's required for
something, I would recommend the POSIX hcreate/hsearch/hdestroy functions for
a generic hash table.  That's not a trivial replacement, but it's doable and
POSIX compliant systems will have those functions in their C libraries.

I confess not spending much time in investigating ksh - there are other
things going on I'm more interested in for the shorter term, like
autotools support, utf8, and the "Documentation Problem" that nobody
wants to touch.

Also Chase, there were a couple of reasons I didn't like the patch:

1. 38MB single patch.  How does one review that?
2. patch did not build/work.  Likely untested on other systems like fbsd
as well.
3. I found out that we were just incorporating a "new" old ksh that
would not be supported going forward.

I'm all for upgrading ksh, but for such a large and important subsystem,
I insist that it be done right, and preferably will not require *me* to
go back and fix a bunch of problems that should have been identified and
fixed before it was submitted.

I have already more than enough work to do in what limited spare time I get.

So, you guys tell me - what is a reasonable plan going forward WRT ksh?
Is 'hash' the only problem?  Am I underestimating the work that might
be required to autotools any version we end up incorporating?  Have
either of you done any POC testing to see if it will even work in principle?

Inquiring minds want to know. :)


-jon


On 11/25/19 2:27 PM, Chase via cdesktopenv-devel wrote:
Ksh2020, I submitted a patch importing the ksh93v branch, but Jon said he 
wanted to do away with nmake entirely and import ksh2020. As he has push access 
and I don't, that's what I've been working on :)


Thank you for your time,
-Chase

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 25, 2019 3:19 PM, Marcin Cieslak <sa...@saper.info> wrote:

On Mon, 25 Nov 2019, Chase via cdesktopenv-devel wrote:

So as I was upgrading our ksh, I have ran into a problem, hash.h, commonly found in 
libast, is no where to be found in the new sources, come to find out that they have 
removed the entire hash part of the library because it was "unused". The way I 
see it we have three paths going forward if we still want to use the latest and greatest 
ksh, from easiest to hardest:
1.) Ask upstream to revert their patch removing the code
2.) Readd the code and maintain it ourselves (I think this should only be done 
if #1 fails)
3.) Refactor our code not to use their hash code
I lean towards #1, but I thought I'd consult the group before I did anything.

o
Hi Chase,

do you meaning as you were upgrading to the 2020 neo-ksh version or ksh93v?
I had a look at ksh93v build system this weekend and with few improvements
I think it could be pushed to CDE as is (without a much promised solution
with a shared library :))

Marcin




_______________________________________________
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

--
David Cantrell <dcantr...@redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT



_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Reply via email to