Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

on. Rick Rick On Thu, Jan 10, 2019 at 6:44 AM Rony G. Flatscher wrote: > On 09.01.2019 21:11, Rick McGuire wrote: > > This is not an acceptable patch because it imposes a directory structure > that is not necessary and is not necessarily what will be used on the other > platforms.

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

ry. > > [1] https://wiki.debian.org/RpathIssue > > On Thu, Jan 10, 2019 at 11:30 AM Enrico Sorichetti via Oorexx-devel > wrote: > > > > > > > > On 9 Jan 2019, at 21:11, Rick McGuire wrote: > > > > This is not an acceptable patch because it imposes

[Oorexx-devel] Rethinking error messages.

The purpose of the rexx.cat file is (in theory), that by having separation between the executables and the error texts, we can easily translate the error messages. In reality, there has never been any attempt at having multiple versions of the messages, and I suspect we have really been misusing th

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

. Rick On Wed, Jan 9, 2019 at 1:21 PM Rony G. Flatscher wrote: > On 08.01.2019 21:57, Rick McGuire wrote: > > If you are splitting things up into separate bin and lib directories, then > rexx.img needs to be co-located with librexxapi in order for the image file > to be located with

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

If you are splitting things up into separate bin and lib directories, then rexx.img needs to be co-located with librexxapi in order for the image file to be located without it being on the path or the current directory. Rick On Tue, Jan 8, 2019 at 1:21 PM Rony G. Flatscher wrote: > On 08.01.201

Re: [Oorexx-devel] ::constant number format

owlishaw wrote: > OK, I just remembered it as expressions (that evaluate as constants). > Seemed reasonable ... :-) > > Happy New Year, btw! > > Mike > > ------ > *From:* Rick McGuire [mailto:object.r...@gmail.com] > *Sent:* 07 January 2019 20:

Re: [Oorexx-devel] ::constant number format

Because ::constant directives only allowed constant values, not expressions in past releases. This was a special exception to remove the requirement to specify negative numbers as quoted literal strings Rick On Mon, Jan 7, 2019 at 2:53 PM Mike Cowlishaw wrote: > That would certainly be valid in

Re: [Oorexx-devel] ::constant number format

Yes, the "or literal string" part should be removed. Rick On Mon, Jan 7, 2019 at 1:58 PM Erich Steinböck wrote: > rexxref (both 4.2 and 5.0) says "Also permitted is the single character > "-" or "+" followed by a literal string or symbol that is a valid number" > for the :constant directive. >

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Windows != Linux, so no, there has never been a REXX_HOME variable there. Rick On Sat, Jan 5, 2019 at 6:13 PM Jeremy Nicoll wrote: > On Sat, 5 Jan 2019, at 22:08, Rick McGuire wrote: > > > There has never been a REXX_HOME environment variable. > > Yes there has. It got se

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:53 PM Gil Barmwater wrote: > Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to > all of the executables? > There has never been a REXX_HOME environment variable. Rick > On 1/5/2019 9:17 AM, Rick McGuire wrote: > > Actua

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:54 PM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 5 Jan 2019, at 22:32, Gil Barmwater wrote: > > Actually, the path we really need is the location of librexxapi. > > > Why ? > Because ooRexx can be used by any application. so

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

away from the path > > And a pretty complicated script run with no problem > > For some odd reason the performance was terrible > My wild guess is that rexx keeps trying to start the rxapi things > > But it worked > > Enrico > > > On 5 Jan 2019, at 13:07, Rick McGuire

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

of(path)-1); > > path[size] = '\0'; > > printf("* '%s'\n", path ); > > return(0); > } > > linux > > #include > #include > > int main() > { > char path[1024]; > int size; > > size = readlink(

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

(0); > } > > linux > > #include > #include > > int main() > { > char path[1024]; > int size; > > size = readlink( "/proc/self/exe", path, sizeof(path)-1); > > path[size] = '\0'; > > printf("**

[Oorexx-devel] A potential problem related to the rexximage problem.

I found the source of the lingering rexximage processes, but it might have uncovered a potential problem with the new rxapi daemon. On unix-based systems, rxapi is launched by doing a fork() and then calling execvp() to replace the current process image with rxapi, with the rxapi process being loc

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

older builds and I cannot find a binary there either. In > 4.1.2 I can find a rexximage binary in /bin though. Just thought I let you > know. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se > > > > > Am 05.01.2019 um 11:42 schrieb Rick McGuire :

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

pp rexximage.patch > (Stripping trailing CRs from patch.) > patching file rexximage.cpp > Hunk #1 FAILED at 90. > 1 out of 1 hunk FAILED -- saving rejects to file rexximage.cpp.rej > POs-12Core-Pro:rexximage po$ > > > > > > > > Hälsningar/Regards/Grüsse, >

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

I have the germ of an idea on this. Could you try the attached patch to see if the problem goes away? Rick On Fri, Jan 4, 2019 at 3:41 PM Rick McGuire wrote: > H, this debug information doesn't make sense for a couple of reasons. > First of all, if rexximage was hanging this wa

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

benign. > > @P.O., did it start to appear with the debug builds? > > René. > > > On 4 Jan 2019, at 13:03, Rick McGuire wrote: > > > > I´m not sure how rexximage processes could be present without the build > hanging. The only thing I can think of is that rexximage wil

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

I´m not sure how rexximage processes could be present without the build hanging. The only thing I can think of is that rexximage will launch rxapi, which involves a fork operation. But that process should then immediately become the rxapi process. Rick On Fri, Jan 4, 2019 at 11:59 AM Enrico Soric

Re: [Oorexx-devel] dynamic linking on macOS (was: Re: A few questions ad CMake and libraries on Unix)

On Wed, Jan 2, 2019 at 4:15 PM René Jansen wrote: > I finally took the time to read up on the dynamic linker on macOS. Linking > the dylibs into /usr/local/lib is not the solution. (And it requires > sudo/root, which we should not need for a local, portable installation.) > This https://matthew-b

Re: [Oorexx-devel] Still working on getting the docs to build on Windows

renaming, but of course > don't use the message filter or the fop preprocess stage. > > While talking about doc building, then there is also the railroad > diagrams, for which I've done some special setup too. I've documented this > to some extent in one of the how-to-build

Re: [Oorexx-devel] A few questions ad CMake and libraries on Unix

Have you tried this: https://stackoverflow.com/questions/35765106/symbolic-links-cmake Rick On Tue, Jan 1, 2019 at 3:53 PM Rony G. Flatscher wrote: > Dear P.O., > On 01.01.2019 21:44, P.O. Jonsson wrote: > > I have just reinstalled a Mac with a completely clean Mojave Setup (to > avoid old fil

Re: [Oorexx-devel] Still working on getting the docs to build on Windows

I found the directory docbook-xsl-1,76.1 in the publican install and copied it to c:\ and got past that error. Not sure why it was looking for this in c:\. Perhaps I'm missing some environment variable? Now all of the docs are build, but each of the pdfs are getting named ooRexx_Documentation-5.0-O

[Oorexx-devel] Still working on getting the docs to build on Windows

I removed the filter from the publican call so that the errors would display and tried to build just rxmath. Here are the errors: Using XML::LibXSLT on C:/Program Files (x86)/Publican/xsl/pdf.xsl I/O warning : failed to load external entity "file:///C:/docbook-xsl-1.76.1/fo/docbook.xsl" co

Re: [Oorexx-devel] File timestamps

The .File class has a lastModified method that returns a .Date object, but nothing for the other two. Rick On Mon, Dec 31, 2018 at 4:21 AM Bill Turner, WB4ALM wrote: > I am using ooRexx 64-bit V 4.2.0 > > Under LINUX the *SysStat("Modified")* function can be used to get a > file's last modified

Re: [Oorexx-devel] Time('R') and Time('E') question

It should be valid even if they use time 'r' or 'e' This is saved and restored across the call boundaries. Rick On Sat, Dec 29, 2018 at 8:12 PM Bill Turner, WB4ALM wrote: > in the following code snippet, will the elapsed time still be correct if > the called subroutine(s) use other forms of TIM

Re: [Oorexx-devel] Windows doc builds

Open_Object_Rexx-en-US.pdf > > The optional tool publicanmovepdf.bat will try to figure out the correct > name for the pdf, move it to \temp\docs\ (this is where I collect all built > docs; just modify this as you wish in two lines at the bottom of this bat > file) and open it for

Re: [Oorexx-devel] Windows doc builds

5:16 PM Erich Steinböck wrote: > The original installer did some install steps. The ZIP is now the result > of what I had done back then. So .. nothing to do for you now anymore. > > > Rick McGuire schrieb am Fr., 28. Dez. 2018 22:54: > >> Is there an "install the br

Re: [Oorexx-devel] Windows doc builds

t > line of fop.bat (one of the optional tools): > %USERPROFILE%\Downloads\FOP\fop-1.1\fop.bat > This line calls fop's fop.bat, so you have to adjust the path to it. > > > On Fri, Dec 28, 2018 at 6:33 PM Rick McGuire > wrote: > >> Finally got around to trying t

Re: [Oorexx-devel] File unavailable when used immediately after creating/closing

On Fri, Dec 28, 2018 at 2:39 PM Erich Steinböck wrote: > Once in a while one of our regression tests shows an error accessing a > file that had just been created (and closed) before being used. This is > spurious and cannot be immediately reproduced. > > The current test run on the build machine

[Oorexx-devel] Windows doc builds

Finally got around to trying to build the docs on Windows and immediately hit a problem. Your publican tools appear to be missing cdsvn.bat. Also, what adjusts do a need to make for the location where I unzipped fos? Rick ___ Oorexx-devel mailing list Oo

Re: [Oorexx-devel] No WSH any more

Yes, definitely. On Fri, Dec 28, 2018 at 7:13 AM Erich Steinböck wrote: > In our trunk samples/windows/wsh directory we still have a bunch of WSH > samples. And winextensions features a full chapter "Windows Scripting Host > Engine". > > This should all be removed as there is no longer any WSH s

Re: [Oorexx-devel] Time for the *ix users to pitch in.

kept what was there originally. Perhaps there was some requirement for this to run as a system daemon, which makes that a bit obsolete. If there is a better way to handle this, go for it. Rick > > > On Thu, Dec 27, 2018 at 11:48 AM Rick McGuire > wrote: > >> Since it runs in a diff

[Oorexx-devel] Steps for building the docs on Ubuntu

FOP version: This is the easiest, but produces the worst results: 1) install publican sudo apt install publican 2) make sure wkhtmltopdf is not installed sudo apt-get remove --purge wkhtmltopdf At this point, all of the docs are buildable except for the rexxref which will give a java out o

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Since it runs in a different process in normal operation, we could probably just unconditionally put out some messages indicating the source of the problem. Then if someone appears to be having issues, we can just ask them to start it from the command line and report the errors. But yes, go ahead

Re: [Oorexx-devel] Building the docs

Yes, will do. Rick On Thu, Dec 27, 2018 at 4:09 AM Erich Steinböck wrote: > Just uploaded the wkhtmltopdf versions. At first glance, they look quite a >> bit better. >> > Much better, yes. > Still a few points, you'd need to get used to, like the underlined links > or the one-column index. Twe

Re: [Oorexx-devel] Time for the *ix users to pitch in.

d if not, somehow (but how?) give an error > indication "cannot create path/.ooRexx...service" > > On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire > wrote: > >> Ok, from what Bob Martin posted, it sounds like the www-data login does >> not have XDG variables set an

Re: [Oorexx-devel] Building the docs

this to be as similar as possible to what we > have with our ancient Publican+fop on Windows installation. > > On Wed, Dec 26, 2018 at 6:08 PM Rick McGuire > wrote: > >> I just uploaded a fop-docs.zip to the docs folder on Sourceforge. I still >> need to modify the Boo

Re: [Oorexx-devel] Building the docs

I just uploaded a fop-docs.zip to the docs folder on Sourceforge. I still need to modify the BookInfos to add dummy abstracts before I can build the wkhtmltopdf versions. I've got to run out for a few hours, I'll get to that later. Rick On Wed, Dec 26, 2018 at 10:36 AM Erich Steinböck wrote: >

Re: [Oorexx-devel] Building the docs

I'm sort of in a mixed state right now. I just made a clone of my VM. I'm going to set one up for FOP and the other for wkhtmltopdf and generate a full set both ways. Rick On Wed, Dec 26, 2018 at 10:36 AM Erich Steinböck wrote: > Amazing! > How does the generated PDF look like? Images, font, ta

Re: [Oorexx-devel] Building the docs

ng the XLT transformation, which is the step before wkhtmlpdf is used. The FOP build has the same stage, and runs cleanly. I suspect they must be running with a different style sheet. But it does work now. Rick On Wed, Dec 26, 2018 at 8:51 AM Rick McGuire wrote: > I found the secret sauce to get th

Re: [Oorexx-devel] Building the docs

I found the secret sauce to get the rexxref pdf to build using FOP. Before running the make, issue export JAVA_TOOL_OPTIONS="-Xms1g -Xmx2g" This allows the pdf build to run to completion and the build runs significantly faster. I still want to see if I get get things to build with wkhtmltopdf. R

Re: [Oorexx-devel] Building the docs

Rats, the installer gives an error trying to download components. You might have the only working installer for this! I'm still stuck on trying to get this to build on ubunto. If I use Fop, I get a java out of heap exception that I've not had any success at eliminating. If I install wkhtmltopdf, I

Re: [Oorexx-devel] Building the docs

t; > Rony G. Flatscher (mobil/e) > > Am 25.12.2018 um 22:35 schrieb Rick McGuire : > > I went back and tried rebuilding just the rexxref, and it looks like this > is a heap space problem with java. I don't know if there is a way to > increase this. > > Rick > > O

Re: [Oorexx-devel] Building the docs

I went back and tried rebuilding just the rexxref, and it looks like this is a heap space problem with java. I don't know if there is a way to increase this. Rick On Tue, Dec 25, 2018 at 3:36 PM Rick McGuire wrote: > I fired up a build on unbuntu before I left to walk my dog. It lo

Re: [Oorexx-devel] oorexxapi.h

On Tue, Dec 25, 2018 at 1:34 PM Erich Steinböck wrote: > > Based on how the INTERFACE_VERSION defines were set up in oorexxapi.h for > 4.2 > > ~~~ > #define INSTANCE_INTERFACE_VERSION 100 > #define THREAD_INTERFACE_VERSION_4_0_0 100 > #define THREAD_INTERFACE_VERSION_4_1_1 101 > #define THREAD_IN

Re: [Oorexx-devel] Building the docs

I fired up a build on unbuntu before I left to walk my dog. It looks like everything but the rexxref built cleanly, and I think the failure there was related to the ulimit problem. When I try to issue the ulimit command you show, I get the following error: bash: ulimit: open files: cannot modify l

Re: [Oorexx-devel] Building the docs

is using the latest publican and wkhtmltopdf. Since you are using FOP on windows, I wonder if it might be better to delete wkhtmltopdf and allow it to use FOP instead. Rick On Tue, Dec 25, 2018 at 11:39 AM Rick McGuire wrote: > OK, snag #1) fedorahosted.org has gone away and I haven't

Re: [Oorexx-devel] Building the docs

86)\Publican;publican.exe" instead of "publican" > either > add FOP path to PATH: set path=\FOP\fop-1.1;%PATH%, or > create a BAT file (within your PATH) that redirects > publican build --formats=pdf --langs=en-US --common_content=".." > ~~~ > > On

Re: [Oorexx-devel] Building the docs

use "\Program Files (x86)\Publican;publican.exe" instead of "publican" > either > add FOP path to PATH: set path=\FOP\fop-1.1;%PATH%, or > create a BAT file (within your PATH) that redirects > publican build --formats=pdf --langs=en-US --common_content=".

Re: [Oorexx-devel] Building the docs

and unexplained "wkhtmltopdf > died" errors > # https://www.redhat.com/archives/publican-list/2013-August/msg5.html > ulimit -n 8192 > ~~~ > > > > On Tue, Dec 25, 2018 at 1:28 PM Rick McGuire > wrote: > >> I have a working Ubuntu 18.10 now running in

[Oorexx-devel] Building the docs

I have a working Ubuntu 18.10 now running in VirtualBox. It would be nice to be able to build the docs on VM as well. Is there a guide for what needs to be installed for this? Rick ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://

Re: [Oorexx-devel] Time for the *ix users to pitch in.

wxrwxrwx 1 postaff 0 Dec 8 16:19 .ooRexx-5.0.0-64.service > > I assume I can safely delete them? > > Von meinen Macbook gesendet > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se > > > > Am 25.12.2018 um 11:42 schrieb Rick McGuire : &

Re: [Oorexx-devel] Time for the *ix users to pitch in.

ed .. I don't understand why) > > There is one situation that will make rxapi fail to start: if a malicious > user creates a simple file with the same name as the lock/service file of a > user. It might still be a good idea to check whether rxapi can create > those files (XDG

Re: [Oorexx-devel] Time for the *ix users to pitch in.

ervice file of a > user. It might still be a good idea to check whether rxapi can create > those files (XDG or /tmp) and if not, somehow (but how?) give an error > indication "cannot create path/.ooRexx...service" > > On Mon, Dec 24, 2018 at 2:19 PM Rick McGuire > wrote: &

Re: [Oorexx-devel] Setting up VirtualBox

Dec 24, 2018 at 10:41 AM René Jansen wrote: > With Docker you will not need Virtual Box. > > René. > > On 24 Dec 2018, at 10:46, Rick McGuire wrote: > > Yep, I'm already regretting this. So far, all I've gotten is suggestions > for additional stuff to install. I&#x

Re: [Oorexx-devel] Setting up VirtualBox

Yep, I'm already regretting this. So far, all I've gotten is suggestions for additional stuff to install. I'm already putting this effort on the shelf. Rick On Mon, Dec 24, 2018 at 9:38 AM Michael Lueck wrote: > Greetings Rick, > > Rick McGuire wrote: > > I'

[Oorexx-devel] Setting up VirtualBox

I'll probably end up regretting this, but I finally broke down and installed VirtualBox on my new laptop. Any suggestions on which distro I should use for ooRexx development? (duck and run!). I want something easy to install and configure for doing development. My past experience with doing this ha

Re: [Oorexx-devel] Time for the *ix users to pitch in.

itz' feedback, as he was the the one > who suggested using XDG_RUNTIME_DIR? > > On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire > wrote: > >> Sounds like a reasonable solution...have you tried it yet? >> >> Rick >> >> On Sat, Dec 22, 2018 at 8:53 AM E

Re: [Oorexx-devel] Time for the *ix users to pitch in.

ess secure, but will continue to work with a switch. Rick On Sat, Dec 22, 2018 at 9:07 AM Erich Steinböck wrote: > No, not yet. Should we wait for Moritz' feedback, as he was the the one > who suggested using XDG_RUNTIME_DIR? > > On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Sounds like a reasonable solution...have you tried it yet? Rick On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck wrote: > With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running > into an issue if a Unix user switches users with the "su other-user" > command. > The existing envi

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

tion (plus > fix). > I propose > >- changing the current "revision" to "modification" and >- use "revision" for the source-control revision (currently SVN >revision) > > > > On Sun, Sep 28, 2014 at 3:19 PM Rick McGuire >

Re: [Oorexx-devel] Feature 730 sandbox

I've created a bunch myself...I was a little more clever than you because not all of mine run fine :-) I'll merge yours with mine. Rick On Thu, Dec 20, 2018 at 1:37 PM Erich Steinböck wrote: > I created expression constant tests for CONSTANT.testGroup - see attached > patch > All tests run fine

Re: [Oorexx-devel] Test Framework

The substantial change was the test case causing the dog fault which is testing the fix for the ser fault. Your interpreter is obviously back level. On Thu, Dec 20, 2018 at 11:44 AM P.O. Jonsson wrote: > Dear developers, > > I am taking up testing after some time and found that there seems to ha

[Oorexx-devel] Feature 730 sandbox

This really turned out to be much less work than I had first thought. I just checked in the code to my sandbox version and it passes a few preliminary tests. The code is at https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/constant Rick ___ Oorexx-de

Re: [Oorexx-devel] One more feature 730 restriction.

On Wed, Dec 19, 2018 at 11:51 AM Jeremy Nicoll < jn.ml.sfrg...@letterboxes.org> wrote: > On Wed, 19 Dec 2018, at 15:16, Rick McGuire wrote: > > Yes it does. That's why they are called constants. They get evaluated > > once and calls will always return that v

Re: [Oorexx-devel] One more feature 730 restriction.

Yes it does. That's why they are called constants. They get evaluated once and calls will always return that value. ooRexx already has a ::CONSTANT directive, but it was restricted to literal values. This expands the concept to allow the constant value to be computed rather than just a literal. Ri

Re: [Oorexx-devel] One more feature 730 restriction.

And it is also available to USERS of the class as well. So rather than needing to remember a particular value to be passed into a method or return values, the class itself can define named constants. But this is beside the point, because ::CONSTANT already exists and has proven to be useful. The o

Re: [Oorexx-devel] One more feature 730 restriction.

It would be trivial to create such a method, but the evaluation would not take place in the context of the owning class, and more importantly, the returned value would not longer be guaranteed to be a constant. Consider a constant like ::constant loadTime (.datetime~new) attached to a class, it w

[Oorexx-devel] One more feature 730 restriction.

I knew there was something else I wanted to mention about this. The evaluation of the constants really only works well in the context of the class objects they are associated with. Because of this, unattached dynamic constants will be an error. Rick ___

Re: [Oorexx-devel] Discussion/questions on #730 Allow ::CONSTANT specified as expression

I feel the same way about the parens, but it seems like the solution with the fewest complications. I'm going to proceed with these two options. Rick On Tue, Dec 18, 2018 at 5:12 AM Erich Steinböck wrote: > No parens, old rule, in parens, an expression to be evaluated. >> > I have a general dis

Re: [Oorexx-devel] Discussion/questions on #730 Allow ::CONSTANT specified as expression

bc" as its constant value > > Absolutely not. If you want something like this, then code a real method or attribute. This is just going to be a single directive statement with an expression. The expressions have no access to instance variables, but can call methods, functions, etc. as neede

[Oorexx-devel] Discussion/questions on #730 Allow ::CONSTANT specified as expression

I admit this is a feature I've wanted for some time but was not sure how to actually do it. Since Erich opened the feature request, I thought I should give it a closer look. I've gotten far enough into this that I believe it can be done, with some restrictions. There are a few items where decisions

Re: [Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

a .def was used with that export name, it generated what we wanted. Removing the RexxEntry from the specification gives something that works for 32- and 64-bit. This is all a non-factor for other platforms. Rick On Mon, Dec 17, 2018 at 9:56 AM Rick McGuire wrote: > is the build machine on a d

Re: [Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

is the build machine on a different version of the compiler? I'm able to get the failure using the same version as Rony. I think I might be closing in on a fix, but so far, my fix attempts have only worked on one of the two builds. Rick On Mon, Dec 17, 2018 at 9:48 AM Erich Steinböck wrote: > R

Re: [Oorexx-devel] Mac warnings, svn rev. 11627 (CMake, compiler)

And currently, these are not fixable problems, we're aware of them, so please stop reposting these unless we ask you to confirm fixes. This is just noise at this point. Rick On Mon, Dec 17, 2018 at 8:26 AM Rony G. Flatscher wrote: > Here the Mac warnings when compiling svn rev. 11627 (there are

Re: [Oorexx-devel] Error compiling 32-bit Windows version, svn rev. 11627

What compiler version are you using? Rick On Mon, Dec 17, 2018 at 8:10 AM Rony G. Flatscher wrote: > While compiling for the 32-bit Windows version, svn rev. 11627, the > compilation stops with the following error information: > > ... cut ... > [ 72%] Linking CXX shared library bin\orexxole.dll

Re: [Oorexx-devel] r11615 breaks tests for me

Just committed a fix for this. Rick On Sat, Dec 15, 2018 at 5:44 PM Jason Martin wrote: > agrellum@openindiana:~/oorexx-test$ ./testOORexx.rex -X native_api > 3 *-* SVN Revision: $ > 117 *-* ::requires "ooTest.frm" > 79 *-* retCode = 'worker.rex'(arguments) > REX0013E: Error 13 r

Re: [Oorexx-devel] Proposal: How about moving the sources for the binaries to the main source tree.

OK, now I feel stupid...I did this 4 years ago, but we never deleted the files from the test tree, so the ones in the source tree never got updated. I'm going to reconcile any changes between the two trees and remove the tree from the test directory. Rick On Sat, Dec 8, 2018 at 5:59 PM

[Oorexx-devel] Proposal: How about moving the sources for the binaries to the main source tree.

I just started to looking into setting up a CMakeList.txt file for building the test binaries used by the native API tests. While trying to figure out how to change the build process to work with an out-of-source build process, it occurred to me it might be better to have the normal build always bu

Re: [Oorexx-devel] OpenIndiana r11581 testsuite broken

I should probably point out that there have not been any code changes since you first had the problems with the rexxc tests. Rick On Sat, Dec 8, 2018 at 10:51 AM Jason Martin wrote: > ./testOORexx.rex -X native_api > Segmentation Fault (core dumped) > > Next try: > ./testOORexx.rex -R ooRexx/ >

Re: [Oorexx-devel] OpenIndiana r11581 testsuite broken

Those are all the native api tests, which need to be built first. We don't have a portable CMake build for those yet, so you should probably just suppress them. Rick On Sat, Dec 8, 2018 at 10:51 AM Jason Martin wrote: > ./testOORexx.rex -X native_api > Segmentation Fault (core dumped) > > Next

Re: [Oorexx-devel] unix/rexxutil event and mutex functions are really broken.

On Fri, Dec 7, 2018 at 8:56 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 7 Dec 2018, at 14:30, Rick McGuire wrote: > > That's a memory management library and doesn't appear to have anything to > do with cross-proces

Re: [Oorexx-devel] unix/rexxutil event and mutex functions are really broken.

he Boehm GC does it > Enrico > > > > On 7 Dec 2018, at 14:15, Rick McGuire wrote: > > > > Ignoring for a moment the elephant in the corner of the Apple deprecated > (and non-functional) sem_* functions, the *ix versions of the semaphore > functions are really sort of

[Oorexx-devel] unix/rexxutil event and mutex functions are really broken.

Ignoring for a moment the elephant in the corner of the Apple deprecated (and non-functional) sem_* functions, the *ix versions of the semaphore functions are really sort of broken. For the event semaphores, one of the functions is a reset, which uses sem_init() to perform the reset. This probably

Re: [Oorexx-devel] New 5.0.0 Beta Build for Windows

It is possible, but generally the Windows is implied by the .exe extension. Rick On Fri, Dec 7, 2018 at 4:53 AM Jon Wolfers wrote: > Is it possible and sensible for the Windows installers to have 'Windows' > in their name ie: >ooRexx.5.0.0.11579-Windowsx86_32.exe >

Re: [Oorexx-devel] IsWindows10OrGreater() undefined in VS 2015

e source returning WindowsNT? > That would be a much more disruptive change since that’s the one that people use to distinguish platforms. I suspect the registry.rex example is probably out of date since we only run on NT based versions any more. > > On Thu, Dec 6, 2018 at 7:03 PM Rick Mc

Re: [Oorexx-devel] IsWindows10OrGreater() undefined in VS 2015

11:09 AM Rick McGuire wrote: > Yeah, I was afraid of that. They deprecate GetVersionEx(), then don't > provide a replacement gives the same information and their recommended > replacement needs to be updated every new release. I'm thinking we're just > going to need to l

Re: [Oorexx-devel] IsWindows10OrGreater() undefined in VS 2015

Yeah, I was afraid of that. They deprecate GetVersionEx(), then don't provide a replacement gives the same information and their recommended replacement needs to be updated every new release. I'm thinking we're just going to need to live with that warning message in that particular case. I'm a litt

Re: [Oorexx-devel] sem_init warning messages.

a dummy name, but the SysResetEventSem uses sem_init() and I can't find any equivalent that will work with named semaphores. Rick > 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 war

Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

> > > > > *From:* Rick McGuire > *Sent:* den 5 december 2018 22:19 > *To:* Open Object Rexx Developer Mailing List < > oorexx-devel@lists.sourceforge.net> > *Subject:* Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx > interpreters running concurrent

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

ons. Rick On Wed, Dec 5, 2018 at 4:24 PM Jack Woehr wrote: > > > On Wed, Dec 5, 2018 at 1:40 PM Rick McGuire wrote: > >> I have to be frank here, this is not going to be a problem of just >> dumping an error log into an email and expecting us to fix the problems. >>

Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

lain about other reports. > > FYI can’ t compile latest commit because of rexxutil.cpp for windows > changes > > > > > > *From:* Rick McGuire > *Sent:* den 5 december 2018 21:54 > *To:* Open Object Rexx Developer Mailing List < > oorexx-devel@lists.sourceforge.ne

Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang

On Wed, Dec 5, 2018 at 1:10 PM Rony G. Flatscher wrote: > On 05.12.2018 15:08, Rick McGuire wrote: > > Seriously, it would be way better to confine your emails to a single topic > so that all of this stuff does not get propagated in thread replies. > > Hmm, thought I keep all r

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

I have to be frank here, this is not going to be a problem of just dumping an error log into an email and expecting us to fix the problems. You have going to have to diagnose any problems involving this environment on your own. You are the first person to try this and nobody on this list (that I'm

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

I already committed the fix. On Wed, Dec 5, 2018 at 10:26 AM Jack Woehr wrote: > Should I file a bug report? > > > On Wed, Dec 5, 2018 at 7:51 AM Rick McGuire wrote: > >> And this is exactly the reason to use 5.0.0, to give us a chance to fix >> these sort of issues

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

is the first maliciously POSIX compliant system > > On Wed, Dec 5, 2018 at 4:13 AM Rick McGuire wrote: > > It looks like the ARGUMENT_TYPE issue is also fixed in the 4.2 branch that >> Erich pointed out too, but I still recommend you switch to 5.0.0. >> > > -- &

Re: [Oorexx-devel] revision 11569, MacOS, question ad shebang

Seriously, it would be way better to confine your emails to a single topic so that all of this stuff does not get propagated in thread replies. On Wed, Dec 5, 2018 at 8:54 AM Rony G. Flatscher wrote: > revision 11569, MacOS, all ooRexx test units pass > > This time also warnings when running cmak

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

Jack, I looks like the ARGUMENT_TYPE issue is also fixed in the 4.2 branch that Erich pointed out too, but I still recommend you switch to 5.0.0. Rick On Tue, Dec 4, 2018 at 9:01 PM Jack Woehr wrote: > Please excuse me for persisting :) I'd really like to build some version > of OORexx on IBM

<    1   2   3   4   5   6   7   8   9   10   >