Menu
▾
▴
#1653 Obsolete version of makestring.rex in C:\Program Files\ooRexx\samples\ (Win64)
When installing ooRexx on Windows 10 using the latest installer (ooRexx-5.0.0-11920.windows.x86_64.exe) I get an error when trying to run the sample file makestring.rex
Unable to create test file : C:\Users\po\AppData\Local\Temp\C:\Users\po\Downloads\tstinput.567
Or similar. When building manually and running from the build (without an install step) makestring.rexx runs as it should.
Comparing the dates of the files I can conclude that
makestring.rex in C:\Program Files\ooRexx\samples\ is from 2018-12-09, with obsolete code in routine getTempFileName
makestring.rex from a fresh build is from 2019-04-02 and have the correct code in getTempFileName
So it appears that there is a problem with the creation of the installer on the Jenkins Win slave. My manual build steps are identical to the Win slave build steps until that last step.
Related
Discussion
Anonymous
The only change that has been made makestring.rex is the shebang at the beginning. What you are claiming does not seem possible.
It is not only the Shebang that changed, also the getTempFileName code was changed to handle the new behaviour of sysTempFileName. Compare attached files.
I know it seems weird, but it is a fact. You can confirm my findings if you extract the file directly from the Win installer (the .exe can be unzipped).
I can think of a write protected older version preventing the copying over? Otherwise there is something fishy in the building of the installer, I did not manage to replicate that step, I have something missing in my setup on Windows.
I don't know what you have one your machine, but makestring.rex has had just one update in SVN in its history, and the only thing that changed was the shebang line:
https://sourceforge.net/p/oorexx/code-0/11511/#diff-14
It is not on "my machine", it is from SVN download compared to Win installer from Sourceforge.
I have a fresh copy from SVN and compare with older copies.
Look at the files themselves.
Von meinem iPhone gesendet
Related
Bugs:
#1653I AM looking at the files themselves. Here is the most current version in the SVN repository, which contains no changes to the temp file logic at all. There is nothing in the SVN histories to indicate any such update has been made.
https://sourceforge.net/p/oorexx/code-0/11511/tree/main/trunk/samples/makestring.rex
On Thu, 3 Oct 2019, at 14:02, Rick McGuire wrote:
Well the routine at the foot of that prepends the value of %TEMP% to the
result of SysTempFilename(template).
Has the latter function changed so that it's returning a full path when
given only a leafname as a parameter?
--
Jeremy Nicoll - my opinions are my own.
Dear Rick,
I am downloading from
svn://svn.code.sf.net/p/oorexx/code-0/main/trunk <svn: svn.code.sf.net="" p="" oorexx="" code-0="" main="" trunk=""></svn:>
This is also the place where Jenkins get its data, I just checked the Windows build
Can it be that you are looking in another place? Your SVN source is different than the one Jenkins (and myself) use.
What is the result if you run make string.rex on you machine? Can you try to download & use the official Win 64 installer and see if it is different from what you expect?
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1653I see now that this was a patch I proposed some time ago 15.3.2019, as a result of bug report 1607, it was never accepted I guess.
I can see that Erich silently made the same change some minutes ago, please close this bug report.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1653On Thu, 3 Oct 2019, at 17:28, Per Olov Jonsson wrote:
No, don't. I think you're fixing the wrong part.
In that exec, there's two calls of getTempFileName() -
file_name_in = getTempFileName('tst_input.???')
file_name_out = getTempFileName('tst_output.???')
and getTempFileName() passes the parameter it's been given
straight into SysTempFileName().
The latter is documented to return the template parameter
value with "?" replaced by other characters so that the returned
value names a file that doesn't exist -- though how it's meant
to do that for a parameter that was only a leafname beats me;
what drive/directory is it going to make those tests against?
It is meant to return a value of the same length as its parameter,
in other words in this case, a file leafname.
Later concatenating that to the value of %TEMP% is perfectly ok.
The problem I think might be that SysTempFileName() is
returning a full file path.
The examples of SysTempFileName()'s use (in one of the earlier
draft versions of the v5.0.0 reference manual all show it returning
full paths... but do so when in the example calls it's given a full
path - albeit with ??? in it - as an argument.
--
Jeremy Nicoll - my opinions are my own.
Dear Jeremy,
The change in the sample file makestring.rex was only made/proposed as a reaction to the changed functionality of SysTempFileName() function (which happened already earlier this year https://sourceforge.net/p/oorexx/bugs/1607/ . I do not think this new (different from version 4 of ooRexx) functionality is reflected in the documentation yet, but from what I have seen it is cleaner and more logical over all different platforms so I have no objections to that change whatsoever.
The confusion here was that I had included the patch in my own SVN repository and forgotten about it, sorry about that. makestring.rex must have been failing since March this year on Windows platforms without anyone noticing. I did not notice until I tried the installer for Windows, before I had my own, patched, build.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1653On Thu, 3 Oct 2019, at 22:03, Per Olov Jonsson wrote:
Now that you mention it, I do think I remember reading that that function
had been changed.
I agree that it seems like a sensible change - because of the issue of how on
earth a non-pathed filename could be guaranteed not to be in use - but I
assume that before this change the underlying code used 'current working
directory' or something to make that test - implicitly testing contents of
wherever the unpathed file would be placed by subsequent use.
Surely the SysTempFileName() code must have worked in the past on
Windows, even if whatever it did was unclear. If it didn't work in the
past, how did it get through the testing framework?
Ah.
Why did no-one notice?
I had the impression that in the build-up to a release of V5 that the
project team were running their test framework. Is that not so?
Also... does no-one do joined-up thinking here? Whenever a function
is changed, does no-one find uses of that function in the sample files
and make sure they still work?
I mean... if I contemplate changing a function in my own code, one of
the things I do before making any changes is find all the places I have
ever used it and consider what the impact will be there. Sometimes I
abandon the idea, sometimes I modify it...
--
Jeremy Nicoll - my opinions are my own.
Dear developers,
Before this bugg report is completely forgotten, please make a note to add some further/different tests to ::method test_temp_file_name in SysFileXXX.testGroup to query the SysTempFileName() function.
Please also make a not to amend the documentation.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Hi. P.O.,
I confirm, SysTempFileName tests and rexxref updates are still to be done
Comitted makestring.rex fixes with [r11921] and [r11922]
Related
Commit: [r11921]
Commit: [r11922]