On 2/7/2011 at 08:55 PM, in message
aanlktinwkojvd-z15hbvr-bc6ac55goluhv1g49d2...@mail.gmail.com, Mark Miesfeld
miesf...@gmail.com wrote:
Excellent Jean-Louis. I forgot to methion DESTDIR.
If you can build on a Mac and have copious free time, maybe you'd like
to tackle building an
On 09.02.2011 12:02, Erico Mendonca wrote:
On 2/7/2011 at 08:55 PM, in message
aanlktinwkojvd-z15hbvr-bc6ac55goluhv1g49d2...@mail.gmail.com, Mark Miesfeld
miesf...@gmail.com wrote:
Excellent Jean-Louis. I forgot to methion DESTDIR.
If you can build on a Mac and have copious
I don't know if Mark H. has the Regina VM mods somewhere; they would be a
good starting point. I suggest we put the source for use on VM and z/OS in a
seperate branch which is in EBCDIC - or maybe we can have an svn plugin that
does the translation for us?
best regards,
René Jansen.
On Tue, Feb
Some of the scripts to create a distributable package for ooRexx are located in
platform/unix/macos. The problem I ran into was that between 4.0.1 and 4.1 the
install strategy for ooRexx was completely changed. There are also parts of
the creation process that take part in the make install
Rony,
I don't think there is a problem with that. For example there is the GUI
Application 'PackageMaker', and there is the command line program
'packagemaker' I have written some scripts to create packages from the
Makefile. See: platform/unix/macosx/MakeRexxPackage
I think from my current
On Feb 9, 2011, at 9:39 AM, Rony G. Flatscher wrote:
Bruce,
thank you very much for your pointers, feedback and your help!
On 09.02.2011 17:26, CVBruce wrote:
I don't think there is a problem with that. For example there is the GUI
Application 'PackageMaker', and there is the command
On 09.02.2011 19:00, CVBruce wrote:
On Feb 9, 2011, at 9:39 AM, Rony G. Flatscher wrote:
P.S.: They are also creating menus, such that one gets a comparable
menu-system to the Windows installation.
I'm not sure what this means.
Oh, ok: on Windows there is a menu entry Open
Hi,
I had to add a path to the ooRexx (4.1.0) libraries in /usr/lib/ooRexx. In
other *nix systems are these picked up automatically or do you have to add a
path to them?
In 4.0.1, I symlinked the libraries from /opt/ooRexx/lib/ooRexx/ to /usr/lib,
and I didn't require a specific path to
Ok, so the behavior I'm seeing is somewhat standard? Does this mean that the
libraries are going to stay where they are, or are they going back to
/opt/ooRexx/lib/ooRexx?
Thanks,
Bruce
On Feb 9, 2011, at 10:28 AM, Mark Miesfeld wrote:
On Wed, Feb 9, 2011 at 10:18 AM, CVBruce
On Wed, Feb 9, 2011 at 10:36 AM, CVBruce cvbr...@gmail.com wrote:
Ok, so the behavior I'm seeing is somewhat standard? Does this mean that the
libraries are going to stay where they are, or are they going back to
/opt/ooRexx/lib/ooRexx?
Well, they're going to stay there until one of the
On Wed, Feb 9, 2011 at 2:08 PM, Mark Miesfeld miesf...@gmail.com wrote:
On Wed, Feb 9, 2011 at 10:36 AM, CVBruce cvbr...@gmail.com wrote:
Ok, so the behavior I'm seeing is somewhat standard? Does this mean that
the libraries are going to stay where they are, or are they going back to
Hi
From the doc, I understand that 'guard on' can wait until a change is made
to an exposed variable.
According to my tests, it works when the variable is exposed in the current
method, like that :
::method guardGenerate
expose status stopped
guard on when status ==
On Wed, Feb 9, 2011 at 2:34 PM, Jean-Louis Faucher
jfaucher...@gmail.com wrote:
Hi
From the doc, I understand that 'guard on' can wait until a change is made
to an exposed variable.
According to my tests, it works when the variable is exposed in the current
method, like that :
::method
On Wed, Feb 9, 2011 at 12:14 PM, CVBruce cvbr...@gmail.com wrote:
I was just looking at configure.ac.
I see that around line 105, someone has added in a bunch of ORX* variables.
Is there a reason that they were added there, for all platforms, as opposed
to around line 215, which is the
Ok, sorry for the brain fart. for some reason, I thought ORX were MacOS
specific.
Thanks.
Bruce
On Feb 9, 2011, at 12:23 PM, Mark Miesfeld wrote:
On Wed, Feb 9, 2011 at 12:14 PM, CVBruce cvbr...@gmail.com wrote:
I was just looking at configure.ac.
I see that around line 105, someone
On 09.02.2011 16:54, CVBruce wrote:
Some of the scripts to create a distributable package for ooRexx are located
in platform/unix/macos. The problem I ran into was that between 4.0.1 and
4.1 the install strategy for ooRexx was completely changed. There are also
parts of the creation
I will put my 2 cents in here :-)
mark is correct that we initially thought we could get away without symlinks
for
the ooRexx libraries in 4.1.0. It turned out not to be the case for a number of
reasons. So now we need to correct our error.
There are two possibilities.
1. Move the libraries
If you are putting the programs into /usr/bin, then the corresponding place to
put the libraries would be /usr/lib. It would be inconsistent, in my mind to
add /usr/lib/ooRexx to the system path.
I just changed my copy of configure.ac to move ooRexx back to /opt/ooRexx, for
Mac OS X only.
I
Not that I can think of. Just be aware that our roadmap is to place everything
in system subdirectories where that makes sense. Or at least place symlinks in
the system subdirectories.
David Ashley
On 02/09/2011 03:58 PM, CVBruce wrote:
If you are putting the programs into /usr/bin, then the
Then I think we are on the same path. I headed down the second option,
symlinks into system subdirectories.
Bruce
On Feb 9, 2011, at 2:10 PM, David Ashley wrote:
Not that I can think of. Just be aware that our roadmap is to place
everything
in system subdirectories where that makes sense.
Rony,
I've fixed configure.ac, preflight.in and postflight.in, per your suggestions,
in a copy of the 4.1.0 release:
https://oorexx.svn.sourceforge.net/svnroot/oorexx/sandbox/bruce/trunk/
As before the suggested method for creating a new version would be
export CFLAGS=-arch xxx
export
Hi
Are there some reasons to not support :
do c over string
do index, item over supplier -- currently we don't support two variables,
but...
?
I was also thinking to generators... For fun, I wrote a generator class
whose spec is
::class generator
::method generate : does a reply and start the
Having run across generators and yield in other languages, this
sounds like a very interesting enhancement to ooRexx. Any
architectural reasons why this shouldn't be pursued?
Jean-Louis Faucher wrote:
Hi
Are there some reasons to not support :
do c over string
do index, item over
23 matches
Mail list logo
