Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

O.K. finished both debug-Windows-installer packages and placed them on my 
Dropbox
(https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0).

To install at your own risk ;):

  * make sure that either ooRexx got uninstalled already or make sure that 
rxapi is not running
(kill it e.g. with Taskmanager or Sysinternals ProcessExplorer),
  * make sure that on the installation dialog you uncheck "install rxapi as a 
Windows service" (not
sure about the exact wording)

Have to run.

---rony

P.S.: Did not have the time to see/test whether currently the NSIS installer 
would allow parallel
installation of 32- and 64-bit ooRexx (and uninstall them independently from 
each other).





___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

Rebuilt ooRexx from trunk:

On 29.11.2018 18:29, Rick McGuire wrote:
> On Thu, Nov 29, 2018 at 12:17 PM Rony G. Flatscher  > wrote:
... cut ...

> 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.
Indeed!

>   * the first time launching "rexxtry.rex" caused a hang on start-up; 
> pressing ctl-c and then
> rerun "rexxtry.rex" succeeds;
>   o 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.
Fixed!

---rony

P.S.: Have to leave so cannot test on Linux and MacOSX, next slot with enough 
free time will be
Saturday.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rick McGuire]

On Thu, Nov 29, 2018 at 12:17 PM Rony G. Flatscher 
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:  

Re: [Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

A few more observation, when rxapi.exe is not running:

  * starting "rxapi.exe" manually and then running "rexxtry.rex" would hang it 
as reported; doing a
ctl-c  to kill "rexxtry.rex" and then rerun "rexxtry.rex" then works

  * using the cygwin tools one can see rxapi with "ps -W", however trying to 
kill it submitting the
process id does not work:

F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits>ps -W | grep rxapi
10776   0   0  10776  ?  0 18:21:58 C:\Program 
Files (x86)\ooRexx\rxapi.exe

F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits>kill 10776
kill: 10776: No such process

---rony

On 29.11.2018 18:16, Rony G. Flatscher 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.
>
> 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)
>
>   * the first time launching "rexxtry.rex" caused a hang on start-up; 
> pressing ctl-c and then
> rerun "rexxtry.rex" succeeds;
>   o 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)
>
>   * 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.
>
> ---
>
> 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
>
> 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:   

[Oorexx-devel] Ad Windows-versions ()rev 11542) ...

[Rony G. Flatscher]

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.

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)

  * the first time launching "rexxtry.rex" caused a hang on start-up; pressing 
ctl-c and then rerun
"rexxtry.rex" succeeds;
  o 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)

  * 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.

---

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

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.12
Test execution: 00:06:04.43
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