Hi Josep Maria,
thank you very much for this clear, thorough presentation of the problem description and the
patches, although I am not the right person to assess it in full, yet. So hoping that once Rick and
Erich get to it they can give authorative feedback.
---
Not being the expert in this corner a question to you as you have developed a deep insight in the
meantime: while developing on json.cls there are two json.cls present at the moment (Windows layout):
C:\Program Files\ooRexx\json.cls
C:\Program Files\ooRexx\rexxtry.rex
F:\work\svn\oorexx\sandbox\rony\json\json.cls
current directory is: F:\work\svn\oorexx\sandbox\rony\json
Now while doing interactive tests via rexxtry.rex (i.e. "C:\Program Files\ooRexx\rexxtry.rex") doing
a "call json.cls" will find and call "C:\Program Files\ooRexx\json.cls" and *not* "json.cls" in the
current directory!
However, in the same rexxtry.rex session in the current directory doing a "call .\json.cls" *will*
resolve and call "F:\work\svn\oorexx\sandbox\rony\json\json.cls": so "." will force using the
current directory for finding external Rexx programs.
So it seems that removing "." may have side effects that are not (yet) covered
by the test cases?
What is your view?
Best regards
---rony
On 04.02.2023 14:27, Josep Maria Blasco wrote:
/[Bringing the discussion from the RexxLA list, as per Rony's suggestion]/
*_Summary_*
* The discussion initiated in this RexxLA thread:
https://groups.io/g/rexxla-members/topic/the_external_program_search/96286751 ,
* then moved to
https://groups.io/g/rexxla-members/topic/getting_oorexx_docs_test/96398260
* and finally to
https://groups.io/g/rexxla-members/topic/next_steps_testing_patch/96697943
* A good description of the problem can be found here:
https://groups.io/g/rexxla-members/message/947
* A preliminary test can be found here:
https://groups.io/g/rexxla-members/message/954
* Another, quite exhaustive, review can be found here:
https://groups.io/g/rexxla-members/message/956
I've opened a bug report: https://sourceforge.net/p/oorexx/bugs/1865/ ; Erich observed there some
interesting details about the behaviour of the SearchPath Windows API.
I submitted a patch for the docs, as a first draft to comment;
https://sourceforge.net/p/oorexx/patches/218/
*_Present_*
Yesterday I submitted a patch for CALL.testGroup: https://sourceforge.net/p/oorexx/patches/219/
(will submit an updated version, which addresses some problems, later).
Yesterday I also had the opportunity, after some stimulus by Rony, to try my first compilation of
the interpreter (under Ubuntu 22.04 --- wonderfully easy, btw).
*_Interesting news_*
If in platform/unix/SysFileSystem.cpp we change
return name[0] == '~' || name[0] == '/' ||
(name[0] == '.' && name[1] == '/') ||
(name[0] == '.' && name[1] == '.' && name[2] == '/');
and instead write only
return name[0] == '~' || name[0] == '/';
(in SysFileSystem:hasDirectory), i.e., we eliminate the tests for the "./"and "../"cases, then the
new tests, test_search_order_4and test_search_order_5will pass (they currently don't under 5.0.0).
Additionally, _the whole test suite passes._ Tests were made using
./testOORexx.rex -X native_API
I will upload the corresponding patch soon.
*_Some comments more, and some questions_*
* I get some impression of disorder. Maybe I should have centralized all my
submissions in a
single place (i.e., in a RFE, for example, or in a bug report)? Currently,
it's getting
complicated to collect all the information (that's one of the reasons why I
am writing that
post). In the general case, what's the way to proceed? Should each of the
different
contributions cross-reference each other?
* The patched Unix interpreter passes all the tests, but I don't know whether
I've inadvertently
introduced some subtle form of new bug.
* Patching the Windows interpreter will be much more complicated, and I'm not
certain that I
possess the required skills to tackle the job. I could try to teach myself
C++ (never
programmed in C++ in all my life, I started with the DOS PL/I Optimizing
Compiler, then learnt
machine language and ASSEMBLER for DOS/360 [the "D" version: it had
WXTRNs], and then Pascal
and REXX for VM/SP -- which spoiled me completely :)) and try to program
the required changes,
but I'm afraid this would take me several weeks. The real problem, though,
is not time (I
don't believe we are in a hurry for a new release), but the quality of my
hypothetical work.
I've noticed that C++ does all kind of weird tricks with pointer
arithmetic, and I'm afraid
I'd end up by introducing a number of beginner-level bugs if I attempted to
solve the problem
by myself. Will try it, anyway, if this is what you advise.
* What I can produce rapidly (say in one or two days) is a pseudocode version
(i.e., a working
Rexx program) of what has to be done in the Windows version. Fundamentally,
the use of the
SearchPath API has to be bypassed, and all checks have to be done "by hand"
(like they are
being done, already, in the Unix version).
Josep Maria Blasco
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
