Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Erich Steinböck
Jack, my fault, I gave you the wrong URL
The build issues are fixed in main/branches/4.2/trunk
svn co https://svn.code.sf.net/p/oorexx/code-0/main/branches/4.2/trunk
 trunk

Sorry for the mix-up.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Jack Woehr
Please excuse me for persisting :) I'd really like to build some version of
OORexx on IBM i PASE.

As I noted I'm doing 4.2.0 because I think it will be easier as a first try.

First off, had to make two changes:

Index: ThreadContextStubs.cpp
===
--- ThreadContextStubs.cpp(revision 11567)
+++ ThreadContextStubs.cpp(working copy)
@@ -576,7 +576,8 @@
 catch (RexxNativeActivation *)
 {
 }
-return false;
+// return false;
+return NULL;
 }


@@ -591,7 +592,8 @@
 catch (RexxNativeActivation *)
 {
 }
-return false;
+// return false;
+return NULL;
 }

Now it's not happy with some PASE gcc/g++ includes:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=2
-DORX_MOD=0 -DORX_FIX=0 -DOOREXX_COPY_YEAR=\"2005-2013\"
-DORX_SYS_STR=\"unknown\" -DORX_CATDIR=\"/usr/bin\"
-DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib -I./api -I./api/platform/unix
-I./common -I./common/platform/unix -I./interpreter
-I./interpreter/behaviour -I./interpreter/execution -I./interpreter/memory
-I./interpreter/package -I./interpreter/concurrency
-I./interpreter/expression -I./interpreter/instructions
-I./interpreter/classes -I./interpreter/classes/support
-I./interpreter/runtime -I./interpreter/parser -I./interpreter/messages
-I./interpreter/streamLibrary -I./interpreter/platform/common
-I./interpreter/platform/unix -g -O2 -g -O2 -DNOOPT -DPTHREAD_KERNEL
-D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DLINUX -DOPSYS_LINUX -MT
librexx_la-RexxNativeActivation.lo -MD -MP -MF
.deps/librexx_la-RexxNativeActivation.Tpo -c
./interpreter/execution/RexxNativeActivation.cpp  -fPIC -DPIC -o
.libs/librexx_la-RexxNativeActivation.o
In file included from ./interpreter/runtime/RexxCore.h:50:0,
 from ./interpreter/execution/RexxNativeActivation.cpp:44:
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename __gnu_cxx::__promote_2<_Tp, _Up>::__type
std::atan2(_Tp, _Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename __gnu_cxx::__promote_2<_Tp, _Up>::__type
std::fmod(_Tp, _Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename __gnu_cxx::__promote_2<_Tp, _Up>::__type
std::pow(_Tp, _Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename
__gnu_cxx::__enable_if<(std::__is_arithmetic<_Tp>::__value &&
std::__is_arithmetic<_Up>::__value), bool>::__type std::isgreater(_Tp,
_Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename
__gnu_cxx::__enable_if<(std::__is_arithmetic<_Tp>::__value &&
std::__is_arithmetic<_Up>::__value), bool>::__type std::isgreaterequal(_Tp,
_Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename
__gnu_cxx::__enable_if<(std::__is_arithmetic<_Tp>::__value &&
std::__is_arithmetic<_Up>::__value), bool>::__type std::isless(_Tp, _Up)':
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___x' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
./api/oorexxapi.h:3697:21: error: 'ARGUMENT_TYPE___y' was not declared in
this scope
 #define __type(t)   ARGUMENT_TYPE_##t
 ^
/QOpenSys/pkgs/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/include/c++/cmath: In
function 'constexpr typename

Re: [Oorexx-devel] Stackbase warnings.

2018-12-04 Thread Erich Steinböck
>
> Could others try applying this patch to see if it gets rid of it
> everywhere?
>
Works on my Ubuntu VM .. but this version of gcc was always less picky
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


[Oorexx-devel] Stackbase warnings.

2018-12-04 Thread Rick McGuire
I was finally able to get rid of the getStackBase() warnings on Windows.
Could others try applying this patch to see if it gets rid of it everywhere?

Rick


stackbase.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] sem_init warning messages.

2018-12-04 Thread Enrico Sorichetti via Oorexx-devel
Hello Rick

The official answer fo macOS  semaphores 
Is to use Grand Central Dispatch's dispatch_semaphore_t.

If You google with dispatch_semaphore_t
You will find quite a few examples 

Or … very dumb suggestion 
Since it seems that named semaphores are still supported 
Why not use under the covers  a named semaphore with a dummy name 
As I said… it might be a dumb suggestion

E

> On 4 Dec 2018, at 22:21, Rick McGuire  wrote:
> 
> It appears that the sem_init deprecation warnings on the Mac are more than 
> just warnings. That function always returns an error on the Mac. 
> Unfortunately, it would prove difficult to replace it with an alternative 
> given how this function is currently constructed. I don't believe this 
> function has ever worked on the Mac, and I doubt it is used very often, since 
> it is fundamentally broken if you are trying to create an unnamed semaphore. 
> No sure how to proceed with this.
> 
> Rick
> ___
> 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


Re: [Oorexx-devel] OpenIndiana revision 11562

2018-12-04 Thread Jason Martin



On 12/04/18 02:57 PM, Erich Steinböck wrote:
Jason, we're currently in the process of switching from a system-wide 
rxapi daemon to a per-user rxapi process.
I wouldn't know if the patch you're referring to still applies ... 
you're providing scarce detail.


That is what I meant by Drop / Close. My rxapi.xml was system-wide like 
the old ones for other OSes.




Regarding rxqueue, all these man page examples work as expected on 
Linux.  Note that external Rexx Queues have to be created before they 
can be used, e. g. q = .RexxQueue~new('myq') or call rxqueue 'o', 'myq'




It's a man page. It looks or reads like I can do this from the command 
line without writing code.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


[Oorexx-devel] sem_init warning messages.

2018-12-04 Thread Rick McGuire
It appears that the sem_init deprecation warnings on the Mac are more than
just warnings. That function always returns an error on the Mac.
Unfortunately, it would prove difficult to replace it with an alternative
given how this function is currently constructed. I don't believe this
function has ever worked on the Mac, and I doubt it is used very often,
since it is fundamentally broken if you are trying to create an unnamed
semaphore. No sure how to proceed with this.

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


Re: [Oorexx-devel] OpenIndiana revision 11562

2018-12-04 Thread Erich Steinböck
Jason, we're currently in the process of switching from a system-wide rxapi
daemon to a per-user rxapi process.
I wouldn't know if the patch you're referring to still applies ... you're
providing scarce detail.

Regarding rxqueue, all these man page examples work as expected on Linux.
Note that external Rexx Queues have to be created before they can be used,
e. g. q = .RexxQueue~new('myq') or call rxqueue 'o', 'myq'

On Tue, Dec 4, 2018 at 4:08 AM Jason Martin  wrote:

> Multiple runs all tests pass.
>
> Drop/Close:
>
> https://sourceforge.net/p/oorexx/patches/205/
>
>
> man rxqueue: This still does not work but I believe there is a bug
> created already.
>
>
> ls | rxqueue MYQ /LIFO
>Place the output from the ls command onto the MYQ queue
> in last-
>in first-out order
>
> export RXQUEUE=MYQ;rxqueue /CLEAR
>Clear the contents of MYQ
>
>
>
> ___
> 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


[Oorexx-devel] Revision 11563

2018-12-04 Thread Enrico Sorichetti via Oorexx-devel
Received 225 copies of 

/opt/ooRexx.svn/api/oorexxapi.h:2268:5: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^
/opt/ooRexx.svn/api/oorexxapi.h:2272:5: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^
2 warnings generated.


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


[Oorexx-devel] Remaining warnings for rev. 11562 on Linux, Mac and Windows ...

2018-12-04 Thread Rony G. Flatscher
As I have compiled ooRexx for all three platforms (temporarily available via my 
Dropbox at
) I 
was able to extract
the warnings the compilers issue on all three platforms, so here they are in a 
simple and
single-e-mail form:

2018-12-04, rev. 11562
==


//\\
linux-compile-warnings
==

rony@rony-linux:~/work/oorexx/trunk$ make
>
Scanning dependencies of target rexx
... cut ...
CMakeFiles/rexx.dir/interpreter/platform/unix/SysFileSystem.cpp.o: In 
function `SysFileSystem::getTempFileName()':
SysFileSystem.cpp:(.text+0x3de): warning: the use of `tmpnam' is dangerous, 
better use `mkstemp'
... cut ...

>
Scanning dependencies of target rexxutil
CMakeFiles/rexxutil.dir/extensions/rexxutil/platform/unix/rexxutil.cpp.o: 
In function `SysTempFileName(char const*, unsigned long, _CONSTRXSTRING*, char 
const*, _RXSTRING*)':
rexxutil.cpp:(.text+0x5c3b): warning: the use of `tempnam' is dangerous, 
better use `mkstemp'
... cut ...

>
Scanning dependencies of target hostemu
... cut ...
[ 88%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp: In function ‘int yyparse()’:
..\..\cmdparse.cpp:1603:35: warning: deprecated conversion from string 
constant to ‘char*’ [-Wwrite-strings]
..\..\cmdparse.cpp:1746:35: warning: deprecated conversion from string 
constant to ‘char*’ [-Wwrite-strings]




//\\
apple-compile-warnings
==

wu114184:oorexx_build rony$ make
>
Scanning dependencies of target rexxapi
... cut ...
[  9%] Building CXX object 
CMakeFiles/rexxapi.dir/common/platform/unix/SysThread.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/common/platform/unix/SysThread.cpp:76:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^

>
Scanning dependencies of target rexx
... cut ...

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysActivity.cpp:140:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^
[ 66%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/platform/unix/SysFileSystem.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysFileSystem.cpp:174:12:
 warning: 'tmpnam' is deprecated:
  This function is provided for compatibility reasons only. Due to 
security concerns inherent in the design of tmpnam(3),
  it is highly recommended that you use mkstemp(3) instead. 
[-Wdeprecated-declarations]
return tmpnam(NULL);
   ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdio.h:186:1:
 note:
  'tmpnam' has been explicitly marked deprecated here
__deprecated_msg("This function is provided for compatibility reasons only. 
 Due to security concerns inherent in the ...
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:180:48:
 note:
  expanded from macro '__deprecated_msg'
#define __deprecated_msg(_msg) __attribute__((deprecated(_msg)))
  ^
[ 70%] Building CXX object 
CMakeFiles/rexx.dir/common/platform/unix/SysThread.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/common/platform/unix/SysThread.cpp:76:32:
 warning: unknown warning group
  '-Wreturn-local-addr', ignored [-Wunknown-warning-option]
#pragma GCC diagnostic ignored "-Wreturn-local-addr"
   ^

>
Scanning dependencies of target hostemu
... cut ...
[ 75%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.o
..\..\cmdparse.cpp:1603:20: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("syntax error"));
   ^
..\..\cmdparse.cpp:1746:16: warning: ISO C++11 does not allow conversion 
from string literal to 'char *' [-Wwritable-strings]
  yyerror (YY_("memory exhausted"));

Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Jack Woehr
On Tue, Dec 4, 2018 at 4:47 AM Rick McGuire  wrote:

> We're not really making changes to 4.2.0 any more, but you can fix the
> errors by changing those lines to
>
>return (RexxPackageObject *)NULL;
>

Hmmm 
./interpreter/api/ThreadContextStubs.cpp: In function '_RexxPackageObject*
GetRoutinePackage(RexxThreadContext*, RexxRoutineObject)':
./interpreter/api/ThreadContextStubs.cpp:579:12: error: cannot convert
'bool' to 'RexxPackageObject {aka _RexxPackageObject*}' in return
  return false;
^
-- 
Jack Woehr
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE:  This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information.  If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited.  If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Jack Woehr
Thanks, Erich. I'll do that. Looking forward to later releases, but I think
for my first try at building on PASE 4.2.0 is easier, perhaps.

On Tue, Dec 4, 2018 at 8:34 AM Erich Steinböck 
wrote:

> Jack, to check out main/releases/4.2.0/trunk you'd use the command
> svn co https://svn.code.sf.net/p/oorexx/code-0/main/releases/4.2.0/trunk
> trunk
>
>
-- 
Jack Woehr
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE:  This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information.  If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited.  If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Erich Steinböck
Jack, to check out main/releases/4.2.0/trunk you'd use the command
svn co https://svn.code.sf.net/p/oorexx/code-0/main/releases/4.2.0/trunk
trunk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

2018-12-04 Thread Rony G. Flatscher
On 04.12.2018 16:06, Rick McGuire wrote:
> Debug compiles the code without a lot of optimizations and also creates the 
> debug information.
> Release compiles with full optimizations and does not create the debug 
> information. RelWithDebInfo
> is the same as Release, but also creates the debug information. 
>
> The installer stuff in CMakeLists.txt is supposed to install the .pdb for 
> both the Debug and
> RelWithDebInfo configurations, so I'm not sure why you are not seeing. 
> Perhaps the case of the
> option matters, but in that case, the Debug version would be missing the 
> information too.
Thank you for your information and also thanks to Enrico, who also spelled out 
all the default build
options and some more interesting CMake properties.

Looking at my build options it turns out that I have a spelling error, I wrote 
"RELWITHDEBUGINFO"
instead of "RELWITHDEBINFO" ("DEB" and not "DEBUG")!
(Did not notice that error as CMake would not warn about it.)

Now the pdb-files and the nsis installation package get built successfully!

---rony





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


Re: [Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

2018-12-04 Thread Enrico Sorichetti via Oorexx-devel
All depends on the setuo …

The CMAKE_BUILD_TYPE 
Has the only effect to chose for the compilation and linking
The appropriate flags

The RELEASE,RELWITHDEBINFO,DEBUG,MINSIZEREL types
Are the ones handled automatically by CMAKE

The variable used for that are of the form
CMAKE_CXX_FLAGS_ 

CMAKE_CXX_FLAGS 
CMAKE_CXX_FLAGS_DEBUG
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_CXX_FLAGS_RELEASE 
CMAKE_CXX_FLAGS_RELWITHDEBINFO 

And cmake will use the appropriate ones 

If no build type is specified 
The compiler and the linker flags are empty 

If You go to the build directory  the command 
Ccmake .
Will open a ncusers based cmake session
Where You can modify some CMAKE options 
It You enter t it will show all ( almost ) the variable used by CMAKE

In my projects I have an include module
to set defaults different from the cmake provided ones 
You should be able to look at them :-)

But cmake is smarter than most people think 

You can for example 

Cmake -DCMAKE_BUILD_TYPE=My … … …

And cmake will use the flags contained in the variables of the form
CMAKE_CXX_FLAGS_MY

E



> On 4 Dec 2018, at 15:25, Rony G. Flatscher  wrote:
> 
> While creating new installation packages from trunk for Windows, I have 
> experimented with the different build types with CMake.
> 
> Question: would the following create a DEBUG or a RELEASE version by default?
> cmake -G "NMake Makefiles" F:\work\svn\oorexx\main\trunk

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


Re: [Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

2018-12-04 Thread Rick McGuire
Debug compiles the code without a lot of optimizations and also creates the
debug information. Release compiles with full optimizations and does not
create the debug information. RelWithDebInfo is the same as Release, but
also creates the debug information.

The installer stuff in CMakeLists.txt is supposed to install the .pdb for
both the Debug and RelWithDebInfo configurations, so I'm not sure why you
are not seeing. Perhaps the case of the option matters, but in that case,
the Debug version would be missing the information too.

Rick

On Tue, Dec 4, 2018 at 9:26 AM Rony G. Flatscher 
wrote:

> While creating new installation packages from trunk for Windows, I have
> experimented with the different build types with CMake.
>
> Question: would the following create a DEBUG or a RELEASE version by
> default?
>
> cmake -G "NMake Makefiles" F:\work\svn\oorexx\main\trunk
>
> nmake
> nmake clean
>
>
> Question: what is the difference between DEBUG and RELWITHDEBUGINFO?
>
> DEBUG: creates the .PDB-files on Windows (however, for debugging they need to 
> be present in the directory from which NSIS took them?)
>
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=DEBUG 
> F:\work\svn\oorexx\main\trunk
>
> RELWITHDEBUGINFO: does not create the .PDB-files on Windows, yet the 
> nsis-exe-file's size is a little larger (ca. 130KB) than the RELEASE version
>   and appr. 30 MB (!) smaller than the DEBUG version
>
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO  
> F:\work\svn\oorexx\main\trunk
>
>
> For creating the installation packages I used the following two
> definitions:
>
> RELEASE:
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELEASE  
> -DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
> F:\work\svn\oorexx\main\trunk
>
> DEBUG and RELWITHDEBUGINFO:
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO 
> -DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
> F:\work\svn\oorexx\main\trunk
>
> nmake
> nmake nsis_template_installer
>
> Here the three installation packages using the three different
> -DCMAKE_BUILD_TYPE on Windows (they are in my Dropbox, 32-bit versions to
> follow:
> 
> 
> ):
>
> 04.12.2018  15:1250.988.523 ooRexx.5.0.0.11562-x86_64-debug.exe
> 04.12.2018  14:3220.485.840 ooRexx.5.0.0.11562-x86_64-release.exe
> 04.12.2018  15:0220.611.448 
> ooRexx.5.0.0.11562-x86_64-relWithDebugInfo.exe
>
> Any answers/insights highly appreciated!
>
> ---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


[Oorexx-devel] Questions ad differences between "RELEASE", "DEBUG" and "RELWITHDEBUGINFO" on Windows?

2018-12-04 Thread Rony G. Flatscher
While creating new installation packages from trunk for Windows, I have 
experimented with the
different build types with CMake.

Question: would the following create a DEBUG or a RELEASE version by default?

cmake -G "NMake Makefiles" F:\work\svn\oorexx\main\trunk

nmake
nmake clean

Question: what is the difference between DEBUG and RELWITHDEBUGINFO?

DEBUG: creates the .PDB-files on Windows (however, for debugging they need 
to be present in the directory from which NSIS took them?)

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=DEBUG 
F:\work\svn\oorexx\main\trunk

RELWITHDEBUGINFO: does not create the .PDB-files on Windows, yet the 
nsis-exe-file's size is a little larger (ca. 130KB) than the RELEASE version
  and appr. 30 MB (!) smaller than the DEBUG version

cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO  
F:\work\svn\oorexx\main\trunk

For creating the installation packages I used the following two definitions:

RELEASE:
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELEASE  
-DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
F:\work\svn\oorexx\main\trunk

DEBUG and RELWITHDEBUGINFO:
cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RELWITHDEBUGINFO 
-DDOC_SOURCE_DIR=G:\oorexx.tmp\oorexxDocs -DOS_DIST=windows 
F:\work\svn\oorexx\main\trunk

nmake
nmake nsis_template_installer

Here the three installation packages using the three different 
-DCMAKE_BUILD_TYPE on Windows (they
are in my Dropbox, 32-bit versions to follow:
):

04.12.2018  15:1250.988.523 ooRexx.5.0.0.11562-x86_64-debug.exe
04.12.2018  14:3220.485.840 ooRexx.5.0.0.11562-x86_64-release.exe
04.12.2018  15:0220.611.448 
ooRexx.5.0.0.11562-x86_64-relWithDebugInfo.exe

Any answers/insights highly appreciated!

---rony

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


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Jack Woehr
Rick, Erich, thanks for your comments.

Erich, if you meant to include a URL for checkout, it did not appear in
your message!


On Tue, Dec 4, 2018 at 5:20 AM Erich Steinböck 
wrote:

> Jack, I believe I fixed that (and one or two other build issues) some time
> ago in main/releases/4.2.0/trunk
> Please try checking out source from this location
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>


-- 
Jack Woehr
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE:  This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information.  If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited.  If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


[Oorexx-devel] Ad killing correct rxapi at uninstall of ooRexx

2018-12-04 Thread Rony G. Flatscher
Now, that it has become possible to have different versions of ooRexx run in 
parallel (even with
different bitnesses), how would one be able to figure out/address the correct 
rxapi process to be
killed? Otherwise after installation the rxapi  process continues running 
(probably until a reboot).

Also with the aim of cleaning out everything known reliably, how would one be 
able to determine the
name and location of the .ooRexx*-lock and -service files, in order to remove 
them upon uninstall?

Maybe a short (external) utility or BIF that would allow to kill that ooRexx 
version's rxapi and
remove its .ooRexx*-lock and -service files may be helpful for cleanup purposes?

---rony


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


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Erich Steinböck
Jack, I believe I fixed that (and one or two other build issues) some time
ago in main/releases/4.2.0/trunk
Please try checking out source from this location
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Build Open ObjectRexx 4.2.0 on IBM i PASE

2018-12-04 Thread Rick McGuire
We're not really making changes to 4.2.0 any more, but you can fix the
errors by changing those lines to

   return (RexxPackageObject *)NULL;

Rick

On Mon, Dec 3, 2018 at 11:57 PM Jack Woehr 
wrote:

> Trying to build on IBM i PASE.
> Freshly downloaded 4.2.0 source from SourceForge.
> OORexx configures, but the build ends as follows, any tips?
>
> Configure command:
> export OBJECT_MODE=64; export LDFLAGS=-Wl,-brtl; ./configure
> export OBJECT_MODE=64; export LDFLAGS=-Wl,-brtl; make # it's gmake
> ...
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=2
> -DORX_MOD=0 -DORX_FIX=0 -DOOREXX_COPY_YEAR=\"2005-2013\"
> -DORX_SYS_STR=\"unknown\" -DORX_CATDIR=\"/usr/bin\"
> -DORX_SHARED_LIBRARY_EXT=\".so\" -I./lib -I./api -I./api/platform/unix
> -I./common -I./common/platform/unix -I./interpreter
> -I./interpreter/behaviour -I./interpreter/execution -I./interpreter/memory
> -I./interpreter/package -I./interpreter/concurrency
> -I./interpreter/expression -I./interpreter/instructions
> -I./interpreter/classes -I./interpreter/classes/support
> -I./interpreter/runtime -I./interpreter/parser -I./interpreter/messages
> -I./interpreter/streamLibrary -I./interpreter/platform/common
> -I./interpreter/platform/unix -g -O2 -g -O2 -DNOOPT -DPTHREAD_KERNEL
> -D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DLINUX -DOPSYS_LINUX -MT
> librexx_la-ThreadContextStubs.lo -MD -MP -MF
> .deps/librexx_la-ThreadContextStubs.Tpo -c
> ./interpreter/api/ThreadContextStubs.cpp -o librexx_la-ThreadContextStubs.o
> ./interpreter/api/ThreadContextStubs.cpp: In function '_RexxPackageObject*
> GetRoutinePackage(RexxThreadContext*, RexxRoutineObject)':
> ./interpreter/api/ThreadContextStubs.cpp:579:12: error: cannot convert
> 'bool' to 'RexxPackageObject {aka _RexxPackageObject*}' in return
>  return false;
> ^
> ./interpreter/api/ThreadContextStubs.cpp: In function '_RexxPackageObject*
> GetMethodPackage(RexxThreadContext*, RexxMethodObject)':
> ./interpreter/api/ThreadContextStubs.cpp:594:12: error: cannot convert
> 'bool' to 'RexxPackageObject {aka _RexxPackageObject*}' in return
>  return false;
> ^
> make: *** [Makefile:2566: librexx_la-ThreadContextStubs.lo] Error 1
> --
> Jack Woehr
> Absolute Performance, Inc.
> 12303 Airport Way, Suite 100
> Broomfield, CO 80021
>
> NON-DISCLOSURE NOTICE:  This communication including any and all
> attachments is for the intended recipient(s) only and may contain
> confidential and privileged information.  If you are not the intended
> recipient of this communication, any disclosure, copying further
> distribution or use of this communication is prohibited.  If you received
> this communication in error, please contact the sender and delete/destroy
> all copies of this communication immediately.
> ___
> 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


[Oorexx-devel] Good News

2018-12-04 Thread Enrico Sorichetti via Oorexx-devel
Hi . 

I moved out of the way the sandbox environment

Updated  my local copy of the main trunk
Updated my local copy of the test suite 

Both to revision 11562

And the test suite run smoothly until the end

Thank You all

E




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