syntactically correct, does not optimize on
several compilers for performance. The fastest all around is ((len & 1u)).
Mark
From: Mark L. Gaubatz via Oorexx-devel
Sent: Thursday, April 18, 2019 11:05 AM
To: 'Open Object Rexx Developer Mailing List'
Cc: Mark L. Gaubatz
Subject
Rony:
Too many comparisons are being done from a performance perspective; a minimal
comparison for validation and no comparison for translation is the fastest.
Actual translation should be done with a pair of 256-byte arrays for speed AND
portability across character sets. Speed varies
Rony:
Since the original version of ooRexx, without a declaration of how to view the
multi-dimensional objects sparsely, results are generically indeterminate as
mapping is based on the highest indices used. Thus, either an .array~new(6,7)
specification is required, or the first element
+1 from here as well as from my clients.
Mark
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Restated, instead of a common or mutex lock, they are now going to use a per
interpreter instance lock. A long time overdue, but the author’s assertion of
“truly concurrent Python code” is incorrect and should have been stated
otherwise. The real implication is that when multiple Python
Franz wrote:
I think I do not use the correct editor with KATE for my .ini file, it is too
silly for me.
I attach to you my last 2 test-files.
I think you can tell me what I have to do.
Your MyRexxComp.ini file was last edited and saved using UTF-8 codepage
encoding. This is shown as
