Missatge de Rony G. Flatscher <[email protected]> del dia dg., 5 de febr. 2023 a les 13:29:
> 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. > A real pleasure. Really. I've enjoyed myself a lot. And I hope it's useful :) > 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! > Sure :) Rexxtry.rex is in the "C:\Program Files\ooRexx" directory. This is the "same" directory of the docs, or the "parent" directory of the source (I'd prefer to call it the "caller's" directory, I think it's a more accurate description; but I disgress). "Call json.cls" is one of the cases where Rexx works as documented. And the search order begins... by the "same" directory, as per the docs. That's why the version in "C:" is called. > 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. > That's exactly our bug. If I understand you properly, the only difference between this last test and the previous one is the addition of ".\". This is, precisely, one of the cases where what Rexx does and what's in the docs *differ*. ".\" should mean "in *this* directory". But what does "this" mean, i.e., "this" relative to what? Well, according to the docs, we have to respect the search order. And, in the first place... "this" should be relative to the "same" directory, that is, the very same "same" directory (sorry). That's the caller's directory, that is, where rexxtry resides. BUT... here's this bug we are talking about: since the callee's filespec begins with ".\", the search path is bypassed (it should not be!). This means that the filespec is resolved (more or less) like in the command line (to be true, the resolution mechanism provided by the SearchPath Windows API --what Rexx for Windows uses-- differs from the command line one, with the clear intention to get the programmers and users altogether completely braindamaged, I'm obliged to presume). But when you're in the command line (and, in this case, when you call SearchPath), "." means the *current* directory, not the *same* or caller's directory. Hence, the F: version of json.cls gets called. If you had instead tried "Call C:json.cls", you'd have had the C: version called. This is maybe the easiest way not to get lost: "Call C:json.cls", and "Call F:json.cls". Of course, the current directory of C: *and* of F: have to point to the right places. > So it seems that removing "." may have side effects that are not (yet) > covered by the test cases? > To the contrary: if you had tried the Ubuntu version of the interpreter after having applied my patch ( https://sourceforge.net/p/oorexx/bugs/1865/?limit=25#687f), then "Call json.cls" and "Call ./json.cls" would have had the same effect. As one would expect, both would have called the version in the *same *directory. To call the version in the *current* directory without using a complete, absolute path, you'd have had to resort to F:json.cls or the like :) > What is your view? > > Best regards > Hope that helps, Josep Maria > ---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_4 and > test_search_order_5 will 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
