Personally I don't like the font used in the text parts and the lack of
page-breaks.
Also the class object pictures is to low-res compared to the running text.
Maybe I have read to many IBM manuals, that has an easy reading font and
mostly, page-breaks at a suitable place.
/hex
René,
Go ahead and give me all the good news, as I have determined that I'm NOT the
guy to port ooRexx to z/os. While z/os USS is true to the letter of the law
where Unix is concerned, it is not true to the spirit of the law. It doesn't
contain all of the programs and utilities that one would
'For what it's worth' .. the *binary* .class files of the NetRexx
compiler/interpreter worked first time when copied across to (EBCDIC) VM. And
'Hello World' complied (and the result was readable) :-).
I found that to be a compelling example that 'write once, run anywhere' really
could be real,
I too would be happy to see ooRexx on MVS, I'm just not the person to do it.
Yes, I have access to a z/os system, but NO, I do not have the expertise to do
it. Surely someone else has access to a z/os system. What about Mr. REXX
himself, Mike Cowlishaw? He's an IBM fellow. I'm sure he could
I too would be happy to see ooRexx on MVS, I'm just not the
person to do it. Yes, I have access to a z/os system, but NO,
I do not have the expertise to do it. Surely someone else has
access to a z/os system. What about Mr. REXX himself, Mike
Cowlishaw? He's an IBM fellow.
Umm, a
I just downloaded oodGuide.pdf from
http://build.oorexx.org/builds/docs/8164/. When I looked at it (using Adobe
Reader X vsn 10.1.3), I got this Adobe error for pages 26 and 27 (neither of
which displayed):
There was an error processing a page. There was a problem reading this
document.
On Wed, Aug 8, 2012 at 7:52 AM, Oliver Sims
oliver.s...@simsassociates.co.uk wrote:
I just downloaded oodGuide.pdf from
http://build.oorexx.org/builds/docs/8164/. When I looked at it (using Adobe
Reader X vsn 10.1.3), I got this Adobe error for pages 26 and 27 (neither of
which displayed):
Another download didn't work either. But another another did. Many thanks.
Ref name - many thx - techies never look at legal stuff (and sometimes
suffer consequences)...
--
Oliver Sims
-Original Message-
From: Mark Miesfeld [mailto:miesf...@gmail.com]
Sent: 08 August 2012 14:52
To:
I would like to move this conversation to the REXXLA list.
Just what is the status of REXX at IBM? Does REXXLA have an official IBM
contact?
As a developer of a REXX-related product, I have to justify my existence every
year. And when we tell IBM that we are working on a REXX product, we get a
This is on win7 64bit and oorexx 4.2.0 8149.
Using the new SYSFILETREE , maybe it also applies to the old SYSFILETREE!, I
have a question.
In what order is the result returned in the steam ?
Reading a windows path, it seems the result is returned in alphabetic order,
but reading a networkpath
On Wed, Aug 8, 2012 at 11:07 AM, hakan hexi...@users.sourceforge.net wrote:
This is on win7 64bit and oorexx 4.2.0 8149.
Using the new SYSFILETREE , maybe it also applies to the old SYSFILETREE!,
I have a question.
There is nothing in the reworked code that would change this from the
previous
Ok, I see
I haven't tried the old sysfiletree with UNC path so have no clue if it
differs in result returned, probably not.
The new sysfiletree seems to work with UNC path's from Win7 anyhow and the
returned values is in arbitrary order, the same arbitrary order is returned if
the the path is
I noticed this issue with a samba share. If you try doing a 'dir' from
the command line, my guess would be you would get the same results. My
search lead me to this fix:
http://www.samba.org/samba/docs/man/manpages-3/vfs_dirsort.8.html
--
Brandon Cherry
On 8/8/2012 3:10 PM, hakan wrote:
Ok,
I was going to bring this up, but probabaly after I had done some more
testing. However since /hex just brought up SysFileTree, I'll do it
now.
I had wanted to include the new SysFileTree code in 4.1.2 because it
definitely fixes some reproducible bugs in Linux.
In Windows, I gave a version to
There really shouldn't be an difference in the garbage collector on 64-bit
vs 32.bit. The code itself is really independent of the size of the
objects, but that's not a definitive statement that there might not be
something strange going on.
You might try rebuilding with _DEBUG and VERBOSE_GC
Thanks Rick. I meant to ask you about any debugging flags.
--
Mark Miesfeld
On Wed, Aug 8, 2012 at 12:48 PM, Rick McGuire object.r...@gmail.com wrote:
There really shouldn't be an difference in the garbage collector on 64-bit
vs 32.bit. The code itself is really independent of the size of
Brandon is correct.
tried dir \\mypath and got the same arbitrary order.
I think this should be mentioned in the manual.
/hex
-
Ursprungligt Meddelande:
Från: Brandon Cherry bran...@safedatausa.com
Till: Open Object Rexx Developer Mailing List
As an IBMer what I am about to say is my own opinion and does not
represent any official or unofficial direction from IBM.
Essentially Rexx is dead at IBM. There are no development or maintenance
plans of any kind. And good luck getting any bug fixes. When IBM open
sourced ooRexx in 2004 it was
** Reply to message from Earl Hodil eho...@mail.open-softech.com on Wed, 8
Aug 2012 09:03:48 -0400
I'm still working on porting ooRexx to zOS (evenutally both to USS and TSO).
(took off the last week, but back in town now and picking up the threads...)
taf
would be happy to see ooRexx on
Okay, I put print outs in the SysFile tree code and in the loop test
it turns out it is not dynamically allocating memory when running in a
loop. Well, it does allocate 2 buffers but frees them each time.
But, it turns out I wasn't comparing apples to orange running on
64-bit and 32-bit. It
Hi David,
as I tried to say, it is not so bleak. The Rexx TSO team has a healthy list of
issues to work through and we might even get the Stream-I/O library on it.
I do share your opinion that there is nobody in the higher ups at IBM that sees
Rexx as the strategic language it is - in other
Am I correct in assuming this loop never wrote out any lines? I've been
trying to recreate this with a simple sample, but the memory size looks
dead stable so far.
Rick
On Wed, Aug 8, 2012 at 5:10 PM, Mark Miesfeld miesf...@gmail.com wrote:
Okay, I put print outs in the SysFile tree code and
Mark,
I'm seeing the same growth with both versions and it looks like it is a
classic memory fragmentation problem. An external call context keeps a
hashtable of all object references it hands out to external functions like
SysFileTree that protects those objects from garbage collection.
On Wed, Aug 8, 2012 at 3:21 PM, Rick McGuire object.r...@gmail.com wrote:
I'm seeing the same growth with both versions and it looks like it is a
classic memory fragmentation problem. An external call context keeps a
hashtable of all object references it hands out to external functions like
... Rexx once was once SAA procedures language ...
... and this positioning of Rexx was afterwards hailed by some as the
greatest success of the IBM Sales Prevention Department.
-- Oliver
_
From: René Jansen [mailto:rvjan...@xs4all.nl]
Sent: 08 August 2012 21:23
To: Open Object
25 matches
Mail list logo
