Re: [cdesktopenv-devel] Upstream ksh problemsX
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 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 Red Hat, Inc. | Boston, MA | EST5EDT ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Upstream ksh problemsX
I think I am going to give this issue a break and see what Marcin has up his sleeve Thank you for your time, -Chase ‐‐‐ Original Message ‐‐‐ On Monday, November 25, 2019 5:03 PM, 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? > > 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? > > 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 ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Upstream ksh problemsX
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? 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? 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 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
Re: [cdesktopenv-devel] Upstream ksh problemsX
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 smime.p7s Description: S/MIME Cryptographic Signature ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Upstream ksh problemsX
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 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
