On Thu, Nov 29, 2018 at 12:17 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> Created the 32- and the 64-bit versions of Rick's rxapi sandbox.
>
> It becomes possible to run the 32- and 64-bit ooRexx interpreters
> concurrently, at the same time, which is really *great*!
>
> This allows among other things to run both interpreters in parallel on the
> same machine, which especially in the Windows case is really a *big* boon!
> One important reason for still using the 32-bit ooRexx on a 64-bit Windows
> machine may be Microsoft Office (MSO), which still gets installed in 32-bit
> in many locations, such that one needs a 32-bit version of ooRexx to
> interface with it (driving Excel, Word, Outlook via OLE)! Then 64-bit
> Windows apps would need the 64-bit ooRexx version which until now was not
> possible!
>
> So this solution is *really* great for this feature alone!
>
> If I understand the naming of the named pipe correctly, it may be even the
> case in the future to run different versions of ooRexx at the same time,
> which will help in testing and comparing them runtime wise.
>
This is correct. The named pipes include both the version name and the
bitness.
>
> The greatest thing with it is, that it has become possible to run ooRexx
> without any administrative rights! To test the coexistancy of 32- and
> 64-bit ooRexx interpreters I merely added the "bin"-directory, where the
> freshly generated ooRexx binaries get put by the CMake based production, in
> one terminal and the same with the other bitness version of ooRexx in
> another terminal. Then I started in both terminals "samples/rexxtry.rex"
> and issued the following statement in both terminals, one running 32-bit
> ooRexx, the other running 64-bit ooRexx:
>
> out=.array~new; address "" "dir" with output using (out); say out~items; say
> out
>
> In both cases the output would be the same, showing the 46 items the "dir"
> command would create, followed by the output of the dir-command as stored
> in the "out" array.
>
> This will allow among other things application providers to supply their
> preferred version of ooRexx in their application without interfering with a
> Rexx version that the user may have system widely installed.
>
> ---
>
> Some remarks on the build process and running the interpreters initially:
>
> - both, the 32- and 64-bit build process will pause at the point where
> the img-file gets created; it is necessary to kill the rxapi-process (this
> despite the fact, that no rxapi was running when starting the compilation
> process so assuming that it is actually the rxapi that just got created)
>
> I just committed changes that should fix that problem.
>
> -
> - the first time launching "rexxtry.rex" caused a hang on start-up;
> pressing ctl-c and then rerun "rexxtry.rex" succeeds;
> - the reason seems to be that the very first time "rxapi" gets
> started, but causes that input hang on "rexxtry.rex"; killing
> "rexxtry.rex"
> with ctl-c and running it immediately afterwards works ("rxapi" runs
> already in this case)
>
> Same issue. I'm actually happy to see this problem show up because I was
only able to get it to fail with rexximage, but not with rexx. It should
have happened with both.
>
> -
> - when creating the NSIS-installer with
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO
> -DDOC_SOURCE_DIR=..\..\..\oorexxDocs -DOS_DIST=windows
> F:\work\svn\oorexx\sandbox\rick\rxapi
> and then running
> nmake nsis_template_installer
> would not add the pdb-files to the installation package. Rather I had
> to do a
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=DEBUG
> F:\work\svn\oorexx\sandbox\rick\rxapi
> and running
> nmake nsis_template_installer
> would add the pdb to the installation exe file.
>
> Ok, this should be a simple fix, I'll take a look at it later. Did the
installer actually work? I was starting to work on that when I encountered
the hang issue and got sidetracked.
>
> -
>
> ---
>
> Installing the nsis-package does not yet work without problems:
>
> - rxapi needs to be killed by hand as the installer cannot identify
> which rxapi is running (and aborts),
> - "Installing rxapi as a Windows service" hangs: remedy: kill the
> running "rxapi" manually
>
> Typed the above too quickly. Yes, the installer has to change a bit for
this. The "as a service" thing makes no sense any more and it needs to kill
the process rather than stop the service.
>
> -
>
> Running "rexxtry.rex" the first time will not allow input, however ctl-c
> works to kill it. Afterwards it will work (see above; reason probably not
> being able to communicate with "rxapi" when starting for the first time).
>
> Running the ooRexx tests works without an error (tested the 32-bit
> version):
>
> ooTest Framework - Automated Test of the ooRexx Interpreter
>
> Interpreter: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 29 Nov 2018
> OS Name: WindowsNT
> SysWinVer: WindowsNT 6.01
>
> Tests ran: 22657
> Assertions: 363281
> Failures: 0
> Errors: 0
>
> File search: 00:00:08.535000
> Suite construction: 00:00:03.120000
> Test execution: 00:06:04.430000
> Total time: 00:06:16.304000
>
> All BSF4ooRexx test units work without failures and errors as well.
> ---rony
>
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
