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 ov
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 pro
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 CXX
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 sens
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
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 d
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 t
Yes, most of Postflight.in was written for 4.0.1. I was not aware of changes
made to 4.1.0 so it needs updating.
It also doesn't work as well as I'd like because of rxapi.
Bruce
On Feb 9, 2011, at 12:56 PM, Rony G. Flatscher wrote:
>
> On 09.02.2011 16:54, CVBruce wrote:
>>
>> Some of the sc
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 p
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 wrote:
>
>> I was just looking at configure.ac.
>>
>> I see that around line 105, someone has added in
On Wed, Feb 9, 2011 at 12:14 PM, CVBruce 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 apple-darwin se
On Wed, Feb 9, 2011 at 11:51 AM, CVBruce wrote:
> As you may have seen, I now have ooRexx 4.1.0 compiling on x86_64, i386, and
> ppc. So I will resume working on install packages and disk images.
Great.
> I don't feel that my make file skills are up to creating a target to build
> the mac os
Ok, I'm lost again.
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 apple-darwin section.
Thanks,
Bruce
---
I agree that is the direction, and I've been making haste slowly towards that.
The scripts exist to make an install package for 4.0.1, but I wasn't aware of
the location changes for 4.1.0 and I have to go back and rework the scripts.
If the consensus is that I can put the files in any location
On Wed, Feb 9, 2011 at 2:34 PM, Jean-Louis Faucher
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 guardGenerate
>
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 == .generator~canProduc
On Wed, Feb 9, 2011 at 2:08 PM, Mark Miesfeld wrote:
> On Wed, Feb 9, 2011 at 10:36 AM, CVBruce 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,
On Wed, Feb 9, 2011 at 10:36 AM, CVBruce 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 developers decide
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 wrote:
>
>> I
On Wed, Feb 9, 2011 at 10:18 AM, CVBruce wrote:
> 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 /u
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 them.
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 "
Hi Bruce,
While studying a phenomenon with loading the JVM via rexx I stumbled
over a MacOSX-Cocoa-specific problem. Studying the background of this
problem yields the following situation: the main (first) thread must
create a CFRunLoop, if GUI-related event handlers are to be used. For
that reaso
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 c
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 line program
> 'packagemaker' I have written some scripts
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
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 por
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
On 09.02.2011 12:02, Erico Mendonca wrote:
On 2/7/2011 at 08:55 PM, in message
> , Mark Miesfeld
> 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 install
>>> On 2/7/2011 at 08:55 PM, in message
, Mark Miesfeld
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 installable package?
>
It appears the only "official" method for creating
30 matches
Mail list logo
