dejagnu version update?
I've changed the subject to match the 2015, 2017 and 2018 email threads.
On May 13, 2020, at 3:26 AM, Thomas Schwinge wrote:
>
> Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> vs. "new") that ought to return identical results, I found that they
> didn't:
> I have not found any evidence in DejaGnu master branch that this not
> working would've been a "recent" DejaGnu regression (and then fixed for
> DejaGnu 1.6) -- so do we have to assume that this never worked as
> intended back then?
Likely not.
> Per our "Prerequisites for GCC" installation documentation, we currently
> require DejaGnu 1.4.4. Advancing that to 1.6 is probably out of
> question, given that it has "just" been released (four years ago).
:-) A user that wants full coverage should use 1.6, apparently.
> As the failure mode with old DejaGnu is "benign" (only causes missing
> execution testing), we could simply move on, and accept non-reproducible
> results between different DejaGnu versions? Kind of lame... ;-|
An ugly wart to be sure.
So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6,
and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want
to not update dejagnu to require 1.6?
I had previously approved the update to 1.5.3, but no one really wanted it as
no one updated the requirement. Let's have the 1.6 discussion. I'm not only
inclined to up to 1.6, but to actually edit it in this time.
Anyone strongly against? Why?
back to cvs, cool
As seen in recent bug report: CVS Commits 2020-05-12 20:40:40 UTC I guess that git thing was a bust and we're back to using cvs now. At least Ian did up the remote patches to make cvs work better.
Re: dejagnu version update?
On May 14, 2020, at 11:11 AM, Tom Tromey wrote: > >> "Rob" == Rob Savoye writes: > > Rob> Not that team, the folks I talked to thought I was crazy for wanting > Rob> to refactor it. :-) > > I don't think refactoring dejagnu is crazy, but I think it's pretty hard > to imagine rewriting the gdb test suite in Python. It's 260 KLOC. So, TCL is subject to being easy to parse, and if you can reliable move each feature to a new system with a re-engineering style system that is complete enough to handle converting code from TCL to python, for example; one merely needs to complete the work for a few of the odd corner cases one might use. At some point, I do think as an industry, we do need tools to migrate code from system to system, updating the language used. C++ may well fall outside of the possibility for the next 30-90 years, but TCL, lisp and python might not be so unreasonable in a shorter timeframe. I one saw someone convert TCL into lisp I think it was, which I thought was neat. One day, would be nice if language implementors and designers implemented conversions into and out of their language from _the_ re-engineering toolkit as they did their language. 10 or 30 years after they decide, oh, no more support for you, you're dead, you can then migrate to the next new wiz bang language. Yes, I say this all, even knowing that people can't even do the python 2.7 -> 3.x conversion program yet. Anyway, love to have software that can move code wholesale. Love to move the testsuite into a new language.
Re: WWDC thread: support for darwin/macOS going forward
On Jun 22, 2020, at 3:51 PM, Eric Gallager wrote: > > Hi, at Apple's WWDC this year they have announced that they are doing > yet another architecture transition, so I was wondering what exactly > would be the best way to go about adding support for it? I usually use emacs and git to add ports to gcc. Just email the changes into the patches list and someone will approve them, then you check them in. All pretty trivial and standard. The hard part, the base port to the CPU is already done, so mainly just finishing touches and polishing. If you want to do the work and need a little hand holding through the process, I'd like to think we have enough people to help get you started. Another completely different way, would be to find the right type of person that can do the port for $500, and offer them money. I once did a port to a brand new architecture for $100 when I was in school. That port brought up emacs, gcc, bash and a some other real nice to have bits of software. It was a great learning experience and I used that emacs and bash a lot, so, the end result was even useful. So, do you want to contribute patches? The neat thing about saying yes, is that you might find others that have time or inclination to also contribute, but that would rather contribute to something already underway rather than be the first.
