New Track Issue created.
1 Like
Which “Flavor” of Rexx would we want to focus on?
- Regina Rexx
- NetRexx
- ooRexx
0 voters
1 Like
I went looking for opinion pieces of the kind “oorexx vs netrexx vs reginarexx”. One such response was https://groups.google.com/g/comp.lang.rexx/c/kW81-6pAyI0 and the opinions seemed to go more toward ooRexx. I don’t have much of an opinion myself. I don’t use the language and only know about it because of its pattern-matching sublanguage.
1 Like
Whichever you choose, it’ll need to run on Linux.
1 Like
So Regina or NetRexx, the latter targeting the JVM.
1 Like
The discussion seems to be very Windows-centric.
Knowing nothing about it, I’d suggest a none-JVM option is likely to be easier for the average person to install, and faster for our infrastructure to run (interpreted languages tend to be 6x faster than compiled ones), so Regina feels like the best option
Those are not the only three options, I am aware that there are 9 open source and free implementations. But I agree about the suggested requirements of Linux, Non-jvm (or other virtual machine) based equivalents. Things that focus on the Rexx language itself, with minimal setup dependencies.
I voted for Regina. If not Regina, then ooRexx.
I was thinking of starting this myself too. I was already looking up some testing frameworks and found this: GitHub - neopragma/t-rexx: Unit testing framework for Rexx
Since I believe other people have a lot more experience on Rexx than I have, it would be best to leave it to professionals. Other than that, I’d like to help out in any way I can.
You would have to return everything that your procedure returns pushed to stack since Rexx procedures don’t know how to return stems. There are many exercises that want you to return arrays. When doing COBOL track, I was thinking that it would be easier to return just strings instead of tables. So maybe the same applies here.
Not so! I was a jq newbie when I started that track. If you have the drive to learn Rexx and really want an exercism track, go for it! You’ll become an expert very quickly!
4 Likes
One particular attraction of the COBOL track, for me, is the simplicity of the unit testing (sorry to say, but the xUnit (and similar) examples I have seen in some tracks are very clever, but just too complicated, IMHO). From a solution contributor’s perspective, easy to read, and understand, and from a solution author’s perspective, I would imagine, easy to implement and maintain.
I believe a REXX track would benefit from a similar approach. The testing framework mentioned by @kapitaali looks promising in this regard.
Regarding string return values instead of stack-based returns or stems, I entirely agree.
You would need to run the stack server to implement a data stack using Regina (not sure how problematic this would be on the exercism infrastructure).
Alternatively, you could EXPOSE stems, and adopt a convention for returning values. Simplest of all, IMHO, would be the use of strings as suggested by @kapitaali. Regina offers a rich set of string manipulation capabilities with which to facilitate this.
Since my exercism experience, so far, is limited to contributing solutions, I’m going to try my hand authoring a COBOL exercise or two. I hope to then be in a better position to help out in implementing a REXX track.
2 Likes
The tests in Problem Specifications can indicate whatever it wants to, but it is up to the track to translate it to what makes sense for the language. So, try not to take too much from the technical structure of the test information presented there.
Also, hopefully, the tests themselves do not drive a specific implementation, as much as possible.
Given the tags on the language request, nothing’s going to happen until someone puts their hand up as maintainer. I’m still working on the 8th and openeuphoria tracks, so I’m not volunteering.
I am interested in contributing to both the COBOL and (potential) REXX track.
I did notice the REXX track requires a maintainer, however, since I have no experience in performing such a role, I have not nominated for it.
Am I being realistic, or too cautious ?
I am happy to volunteer if my current experience is acceptable. The approach I would take to performing the role would be to read through the commits of similar, existing tracks (I have forked the COBOL track), mimic and adapt steps taken there.
Open to suggestions / advice.
I got some experience in the role of maintainer by taking on the preparation of the vbnet track for the Exercism V3 launch. If found the documentation fairly clear and the staff exceptionally helpful. I could not have done it without @ErikSchierboom who went out of his way to be kind to me, a git-ignoramus. Starting from scratch in the V3 environment is certainly an easier place to start from than taking a partially-built V2 track and making it work in V3.
So as long as you’re capable of climbing a steep learning curve you should do okay. You certainly won’t be alone, and you will always be able to find someone who can help you out. The caveat is that we are all volunteers, so things that might take O(n) in private industry may take O(n log n) or longer in Exercism-land. So set yourself realistic targets and don’t fret too much if the targets aren’t met in as timely a manner as you may have wished. Occasionally things do happen quickly. Rejoice in these times.
1 Like
Thank you for your advice.
REXX and git I already know. Need to get up to speed on the pragmatics of managing an Exercism track on github.
So, I’m volunteering to maintain a REXX track !
1 Like
Thank you. So, just to confirm, further communication on this matter is most appropriately performed via github ?
Mostly here, I think. At least for planning. PR’s will be another thing.
Greetings everyone,
Just a general update on the Rexx track, and since this topic thread exists I thought I would use it rather than start a new one.
Presently, 66 exercises are implemented, and the track documentation is mostly complete.
Much effort has been expended in refining the unit test framework, and test runner. The two are closely linked, and will undergo further (extensive) changes.
Various commitments have prevented me working on the track for a number of months, but I plan to resume activity this coming February (when I can devote my full attention to it) with the intention of launching it by April.
Now, onto completing 12In23 !
6 Likes