The best way to deal with these is to open a patch tracker ticket:
https://sourceforge.net/p/oorexx/patches/?source=navbar
Rick
On Mon, Jan 22, 2018 at 8:32 AM, Jason Martin wrote:
> cmake find ncurses fixed/broke/fixed/broke
>
> create symlink in /usr/include to ncurses.h in /usr/include/
Erich,
If you are going to make these dot variables special, a better way of doing
this would be to handle it in the translator. I suggest adding a
SpecialDotVariable class that has an pointer to the resolved value and the
evaluate method would just return it directly. This would avoid having to
d
would not longer show `>I> .TRUE => 1` but just `>L> 1`
> So I wasn't sure if this might drag us into some incompatibility
> discussion.
>
> On Sat, Feb 10, 2018 at 11:38 PM, Rick McGuire
> wrote:
>
>> Erich,
>>
>> If you are going to ma
Hmmm, if that's the case, then the .File~isCaseSensitive method is probably
returning an incorrect result on the Mac since the unix version of the
SysFileSystem class is hardcoded to return true. Is there an api that can
be used to check this?
Is this guaranteed that it will always be one type or
Probably because oorexx doesn't issue that error anywhere. Not sure where
that comes from, but it doesn't appear anywhere in the oorexx code.
Rick
On Tue, Mar 13, 2018 at 5:09 PM, Walter Pachl wrote:
> White attempting to install bsf4oorexx we ran into this problem:
>
> "dir | rxqueue"
> do i=1
I'm not sure, but I suspect there may be something wrong with your
configuration. You don't show any output for your cmake command, but
normally it would put out a lot of messages about checking for symbols that
are used to generate the config.h file. Either a) something about your
platform caused
Thanks for including the pthread.h file, that helped me locate the problem
I had to revert a change I had made to CMakeLists.txt and add some comments
to ensure it doesn't get "fixed" that way again. Please update and try
again.
Rick
On Sun, Mar 18, 2018 at 10:12 AM, Rony G. Flatscher wrote:
>
On Mon, Mar 19, 2018 at 10:10 PM, Michael Lueck wrote:
> Greetings ooRexx'ers,
>
> I just got done with the 16.04 x86 package testing.
>
> ooTest Framework - Automated Test of the ooRexx Interpreter
>
> Interpreter:REXX-ooRexx_5.0.0(MT)_32-bit 6.05 19 Mar 2018
> OS Name:LINUX
OK, I got inspired by Gil's symposium presentation yesterday and have
started working on an implementation on this. I created a sandbox version
of 5.0.0 at url
https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/addresswith
This is very much a work in progress now that won't even build yet, but
Quick question for Gil since you've played with this more. For OUTPUT and
ERROR, is the default operation REPLACE or APPEND?
Rick
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slas
Hmmm, I'm very much of the opposite opinion. I could have something working
in a week or two. I've got a fair amount of the code written already,
although I'm now at the tedious part of doing the command parsing and
getting all of the error messages defined. The only part I'm really missing
is the
Does the pipes-based version have real user isolation? In other words, do
you end up with one process per user? That would be a very good thing if we
can get the real isolation. However, I think I share your opinion about
trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has
b
1) After a little think time at the dog park, I restructured my code a bit
and now am able to cleanup implement the full ADDRESS WITH semantics.
2) I'm planning on adding File as one of the objects support with USING
3) I have been able to implement the APPEND/REPLACE options for all USING
types
ldn't want to do this on each command
> handler call, but as a one-time setup only, I noticed that there's no way
> to do that because of the fixed command handler interface.
>
> Might we have an additional full-path argument to command handlers?
>
> On Sat, Mar 31,
ck to the interpreter. All the rest of the details will be
handled inside the interpreter.
Rick
> Gil
> PS I now have a checkout of the sandbox and have begun looking at
> integrating the changes needed in order to implement redirection. More
> questions will be forthcoming! GB
>
Ok, the AddressWith sandbox version is now building cleanly. Next step is
to scaffold up some unit tests using a dummy command handler, but thing
should be ready to incorporate the I/O redirection pieces.
Rick
--
Check out
Gil,
The addressWith sandbox version now builds cleanly. Basically, everything
is in place except for the code in SystemCommands.cpp that performs the I/O
redirects with the shell. As part of this, I added a dummy TEST address
handler to SystemCommands so I can start writing unit tests to test of
his being an
> error. I suspect, though, that just ignoring the redirection will be more
> "surprising" than getting a message saying that the FOO command handler
> doesn't handle I/O redirection.
>
I'm leaning that way too. Getting an error vs. having the command not
ret
ut yes, WITH should be supported and
>
>- REPLACE never seems to work for OUTPUT, e. g. `address "" "" with
>output replace stem stem. `, not only for USING STREAM where it is
>explicitly forbidden
>- have the FIFO / LIFO redirections been i
is
>explicitly forbidden
>
> Still working through unit tests...will look into.
>
>- have the FIFO / LIFO redirections been intentionally left out?
>
> That must be a Regina extension...those are not part of the ANSI
standard. I will take a look at what Regina d
The interface vector will always be supplied, so it is necessary to test
each of the streams. It would be a simple matter for a single check API to
be added.
Rick
On Mon, Apr 2, 2018 at 12:46 PM, Erich Steinböck wrote:
> You'll be passed a small interface vector with just 6 functions:
>> IsInpu
On Mon, Apr 2, 2018 at 5:33 PM, Erich Steinböck
wrote:
>
>>>- `address '' '' with` be allowed with no actual redirection?
>>>
>>> That's probably not what you're thinking it is. That would be considered
>> the implicit ADDRESS VALUE form
>>
>
> What's the "implicit ADDRESS VALUE form"?
> How
I added RexxQueue output support because I discovered that it was actually
support on input because it already supported on input because the
RexxQueue class supported makearray.
Rick
--
Check out the vibrant tech communit
Since last night, I've been getting lots of timeouts when trying to commit
changes. I basically have just been trying over and over until it finally
works. There are no reports of outages on the SF status page. Anybody else
having problems?
Rick
I still have to write a bunch of unit tests for the global Address With
setup and overrides, but all of the base redirection mechanisms are now
passing the unit tests. The missing piece right now is the redirection in
the system handlers.
Any Linux gurus out there willing to take a look at how to
Now that I've gotten all of these mechanisms working, I'm starting to think
we might need a little more. My thinking to this point is that the
WriteOutput() and WriteError() calls are line-at-a-time operations. But I
realized that the handler might be reading larger buffers of data composed
of mult
x and
> tested that it runs rexxtry with both 'address cmd rem' and 'address cmd
> rem with', the latter giving the appropriate error message. My next step
> is to begin integrating my package code. I also have a plan to be able to
> run my testcases against my build once
Oops, no that is the correct fix. Trying to commit some changes right now
but sourceforge is still having issues.
Rick
On Wed, Apr 4, 2018 at 4:39 PM, Erich Steinböck
wrote:
> On Ubuntu gcc, I'm receiving below compile error.
> Compile runs fine if I remove "LineinInvoker::" .. didn't yet check
2018 at 1:20 PM, Rick McGuire wrote:
>
>
> On Wed, Apr 4, 2018 at 11:14 AM, Gil Barmwater
> wrote:
>
>> Yes, I ran into this issue when developing my package. I had assumed
>> that there was an equivalent to Linein() and Lineout() in Windows so I made
>> my in
On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck
wrote:
> I have a working redirecting context on Ubuntu (no tests run yet).
> But I guess I need to think a little more about the blocking issue.
> What we're doing here is, fork a child (which runs the command) and
> connect us to the child through
On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck
wrote:
> I have a working redirecting context on Ubuntu (no tests run yet).
> But I guess I need to think a little more about the blocking issue.
> What we're doing here is, fork a child (which runs the command) and
> connect us to the child through
This article seems to describe the exact situation you are dealing with:
https://www.geeksforgeeks.org/non-blocking-io-with-pipes-in-c/
Rick
On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck
wrote:
> I have a working redirecting context on Ubuntu (no tests run yet).
> But I guess I need to think
On Thu, Apr 5, 2018 at 8:29 PM, Gil Barmwater
wrote:
> Let me start by saying that I know next to nothing about *ix but perhaps
> the sequence in Windows may shed some light here. The example I used for
> my package, and which is the basis of what I'm doing for ADDRESS...WITH on
> Windows, does
I also found this:
https://linux.die.net/man/2/pipe2
which allows you to create the pipe as non blocking.
Rick
On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck
wrote:
> I have a working redirecting context on Ubuntu (no tests run yet).
> But I guess I need to think a little more about the bloc
Gil,
Been doing a little reading on the Windows Pipe and I/O functions. and it
appears you could also encounter a problem, though in a slightly different
way. If you are still writing data to the pipe and the buffer is full,
WriteFile() will block until the other end of the pipe reads enough data
nd is there a maximum size for a line of
> input?
>
> Gil
> On 4/6/2018 9:43 AM, Rick McGuire wrote:
>
> Gil,
>
> Been doing a little reading on the Windows Pipe and I/O functions. and it
> appears you could also encounter a problem, though in a slightly different
>
t;proper" linends, I would think that since this is
> Windows-specific code, you wouldn't need to use the platform EOL marker.
>
> Gil
>
> On 4/6/2018 10:56 AM, Rick McGuire wrote:
>
> Gil,
>
> ReadInput returns just the data for the next line, with no line
> t
Now that the ADDRESS WITH activity is moving along somewhat, I thought I
might revisit an idea that has been kicking around since the early days of
the project. This was a question of allowing some form of call-by-name to
the language.
I've been mulling this over for some time and decided it was f
On Wed, Apr 11, 2018 at 2:26 PM Gil Barmwater
wrote:
> Just a quick update on my progress so far. I've gotten all the code in
> (hopefully) the right places and I have a clean build. My initial tests
> are working but I've just hit my first problem which I need to debug.
> Hopefully, it will no
These sound like good questions to ask on StackOverflow.
Rick
On Thu, Apr 12, 2018 at 2:37 AM, Erich Steinböck wrote:
> checking the code in as it is is also an option...it gets more eyeballs on
>> the problem
>>
> I checked in the code for a Unix redirecting command handler.
> It's still work-
Sounds like a good suggestion, though I suspect most people would prefer
to use this object via the Use Arg aliasing, so they never have to deal
with that. Trivial to add though.
Rick
>
>
> ---rony
>
>
> On 11.04.2018 16:28, Rick McGuire wrote:
>
> Now that the ADDRESS WIT
On Thu, Apr 12, 2018 at 6:29 AM, Mike Cowlishaw wrote:
>
>
> Now that the ADDRESS WITH activity is moving along somewhat, I thought I
> might revisit an idea that has been kicking around since the early days of
> the project. This was a question of allowing some form of call-by-name to
> the lang
On Thu, Apr 12, 2018 at 9:21 AM, Mike Cowlishaw wrote:
>
>
>
> I had similar thoughts, but I found that using '&' on both ends made
> things more understandable to the "normal" user. That is, the symmetry of
> using & on both the caller and receiver side connected these very firmly
> and only req
a "value=" synonym for the "setValue"
>method as this would allow to apply the ooRexx attribute value assignment
>pattern?
>
> ---rony
>
>
> On 11.04.2018 16:28, Rick McGuire wrote:
>
> Now that the ADDRESS WITH activity is moving along somewhat, I
On Thu, Apr 12, 2018 at 12:19 PM Mike Cowlishaw wrote:
>
>
> Or .. how about simple parentheses -- as already used in PARSE for a
>> similar purpose, for example?[I think we also considered CALL
>> (foo) a,b once, to allow call by a variable name.]
>>
>
> Considered? It has been implemented
up, presumably due to the output pipe being
> full. I plan to experiment with ways around this but will generate the
> patch file with the code as it stands now.
>
> Gil
>
> On 4/11/2018 2:32 PM, Rick McGuire wrote:
>
>
> On Wed, Apr 11, 2018 at 2:26 PM Gil Barmwater
ght you were a committer. Attaching a patch also works.
>
> One other item that I discovered is that I can get a deadlock in Windows
> as well. I had not tested sending a lot of data to redirected output but
> when I did, my package locked up, presumably due to the output pipe being
>
> as well. I had not tested sending a lot of data to redirected output but
> when I did, my package locked up, presumably due to the output pipe being
> full. I plan to experiment with ways around this but will generate the
> patch file with the code as it stands now.
>
> Gil
ows
> as well. I had not tested sending a lot of data to redirected output but
> when I did, my package locked up, presumably due to the output pipe being
> full. I plan to experiment with ways around this but will generate the
> patch file with the code as it stands now.
>
> G
e the process
completes? Otherwise, a command that creates a large amount of output will
fill the pipe up.
Rick
On Thu, Apr 12, 2018 at 5:03 PM, Rick McGuire wrote:
> I decided to post a question to StackOverflow to see if anybody has an
> suggestions. I'm sort of thinking the solu
ipe since we wouldn't get to the wait loop
> until the input data is all written. Sounds like the thread approach might
> be the most straightforward way to go.
> Gil
>
> On 4/12/2018 5:39 PM, Rick McGuire wrote:
>
> It looks like spinning off a thread to do this is pretty easy using
at 6:58 AM, Rick McGuire wrote:
> Ok, I have things working with a separate thread filling the input pipe,
> but I'm able to get a hang with a simple example (see below). As I
> suspected, the problem is caused by waiting for the process to complete
> before reading from the
> return from the command be the value from the executed command itself in
> all of these scenarios (rather than from "rxqueue")?
>
> ---rony
>
> On 13.04.2018 13:12, Rick McGuire wrote:
>
> I hate it when code compiles and runs on the first attempt :-) Just move
ERROR and FAILURE conditions are related to the execution of the command
itself. Other sorts of failures in the redirection should probably be
SYNTAX condition, probably in the Error_Execution category.
Rick
On Fri, Apr 13, 2018 at 11:37 AM, Erich Steinböck <
erich.steinbo...@gmail.com> wrote:
>
On Fri, Apr 13, 2018 at 6:00 PM, Erich Steinböck wrote:
> What I did for Windows with the separate thread should be easily adapted
>> for Linux
>
> I've rewritten the Linux handler with separate threads for INPUT and ERROR
> (if requested), while handling OUTPUT in the main thread.
> I'm just sta
On Fri, Apr 13, 2018 at 6:40 PM, Erich Steinböck wrote:
>
>>- How do I wait for SysThreads to terminate? Or check if they're
>>still running?
>>
>> For the Windows version, I called terminate on the thread object that
>> will clean things up.
>>
>
> When terminate() returns, I know that d
We haven't needed it yet anywhere, but it looks fairly trivial to add a
waitForTermination() method to the SysThread class. Unfortunately, I'm in
the middle of migrating to a new PC, and neither my old PC or the new one
is really functional at this time.
Rick
On Fri, Apr 13, 2018 at 6:40 PM, Eric
My new laptop arrived yesterday and I finally got things to the pointer
where I can build. My new machine is a dual drive system, so all of my
builds moved from C: to E:, which required rerunning the cmake command
because the source trees have moved. I nuked the CMakeFiles directory,
issued the com
I added a waitForTermination() method to SysThread...pretty trivial to do.
The unix version hasn't even been compiled yet.
Rick
On Thu, Apr 5, 2018 at 5:58 PM, Erich Steinböck
wrote:
> I have a working redirecting context on Ubuntu (no tests run yet).
> But I guess I need to think a little more
I have one additional open issue with my variable references prototype, and
that's whether to support a default value or not on USE ARG if aliasing is
requested. Right now I don't support it at all.
There is a case for supporting a default value that would be assigned to
the aliased variable if i
On Mon, Apr 16, 2018 at 8:04 AM, Mike Cowlishaw wrote:
>
>
>
> One other point I should probably make related to this is that the
> referencing operator (currently spelled "&") ...
>
>
> I trust that spelling is still considered an open issue. :-)
>
> I'm warming to using '>' on both sides ..
On Mon, Apr 16, 2018 at 8:53 AM, Erich Steinböck wrote:
> One other point I should probably make related to this is that the
>> referencing operator (currently spelled "&")
>>
>
> Can this maybe done with existing ooRexx syntax? Like
> `call routine alpha, .Reference~new(beta), gamma` and a simp
On Mon, Apr 16, 2018 at 9:54 AM, Rony G. Flatscher
wrote:
> On 16.04.2018 14:08, Rick McGuire wrote:
>
>
> On Mon, Apr 16, 2018 at 8:04 AM, Mike Cowlishaw
> wrote:
>
>>
>>
>> One other point I should probably make related to this is that the
>&g
Yep, it probably should. I'll take a look at it.
Rick
On Mon, Apr 16, 2018 at 10:04 AM, Erich Steinböck <
erich.steinbo...@gmail.com> wrote:
> Should this print "line" twice? It currently prints two null strings.
>
> ~~~
> stem. = "line"
> stem.0 = 2
> address "" "cat" with input using ( stem.
This raises all sorts of issues as to what is getting returned, how to
handle mismatches in assignment values and the fact that any errors can
only get detected at the point of return. I don't really see this as being
a very clean change.
Rick
On Mon, Apr 16, 2018 at 10:10 AM, Rony G. Flatscher
Now that the spelling of the character has been sorted out, does anybody
have an opinion on the actual question of this thread?
Rick
On Sun, Apr 15, 2018 at 7:45 AM, Rick McGuire wrote:
> I have one additional open issue with my variable references prototype,
> and that's whether t
at this somewhat redefines the
meaning of the default value.
Rick
On Tue, Apr 17, 2018 at 12:33 PM, Rony G. Flatscher wrote:
>
> On 17.04.2018 16:18, Rick McGuire wrote:
>
> Now that the spelling of the character has been sorted out, does anybody
> have an opinion on the actual qu
I've been doing a little sandbox work on Erich's suggestion that return
could be able to return more than one value and we can have an assignment
that can handle multiple variables That is,
a, b, c = foo()
where foo does
return expr1, expr2, expr3
I think this might be doable, but some work ne
of another method call. None of these are particularly well defined
once you consider the possibility of multiple results getting returned. I
think I'm shelving this bit of work as a result.
Rick
On Tue, Apr 17, 2018 at 4:25 PM, Rick McGuire wrote:
> I've been doing a little sa
On Thu, Apr 19, 2018 at 1:21 PM, Erich Steinböck wrote:
> I just committed the Unix implementation of a redirecting system command
> handler, that passes all tests in (an updated) ADDRESS.testGroup.
>
> It handles OUTPUT in the main thread, and INPUT and ERROR in additional
> threads when require
It has not been officially released yet.
Rick
On Thu, Apr 19, 2018 at 7:39 PM, Michael Lueck
wrote:
> Greetings ooRexx'ers,
>
> So, the announcement for ooRexx v5 at the symposium... does that mean
> v5.0.0 is officially released?
>
> If so, how should I modify my svn check out syntax to pull
Right now, monitor objects would not work (an oversight on my part). I'll
look into adding them. Output should be easy. Input is sort of implicitly
supported because the last step is to send a makeArray to the object.
The reads from the pipes are done a buffer at a time and the error output
that
nce warning)
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe' : return
> code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2&#x
Test away. I don't know of any pending work on Windows at least. Erich will
have to speak for the other platforms.
Rick
On Wed, Apr 25, 2018 at 7:55 AM, Rony G. Flatscher
wrote:
> A question ad implementation status: is the functionality in trunk already
> regarded to be fully
> implemented and
files/oorexx-
> docs/5.0.0beta/rexxref.pdf"
> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/rexxref.pdf>
> is from 2018-03-28 and does not have the new syntax documented.
>
> ---rony
>
> On 25.04.2018 13:59, Rick McGuire wrote:
>
> Test
That is the correct behavior. If you are doing the output to a stream
object directly rather than using the STREAM resource (or USING with a
.File object), the stream is neither opened nor closed during the
processing. In fact, an OutputStream object need not support a close
method, so it would be
?
> Gil
>
> On 4/25/2018 2:20 PM, Rick McGuire wrote:
>
> That is the correct behavior. If you are doing the output to a stream
> object directly rather than using the STREAM resource (or USING with a
> .File object), the stream is neither opened nor closed during the
> proce
Just committed a fix for the hang problem. I'm now getting a few more
errors that I will take a look at when I have a chance.
Rick
On Thu, Apr 26, 2018 at 6:31 AM, Rony G. Flatscher
wrote:
> Using the latest version of the "addresswith" sandbox ("r11438") as of
> yesterday evening and running i
ixes
that issue because the threads can read the data from the pipe, while the
main thread can wait for the process to terminate before closing the
handles.
Rick
On Thu, Apr 26, 2018 at 8:56 AM, Rick McGuire wrote:
> Just committed a fix for the hang problem. I'm now getting a few more
On Fri, Apr 27, 2018 at 11:04 AM, Rony G. Flatscher wrote:
> The default environment that address sends the command to can be set with
> "address nameOfEnvironment" or "address value (expression-yielding-name)".
>
> Seeing the examples in the testGroup files is it correct to assume that
> supplyi
I discovered this week that David Ashley's rxsock6 was in the 5.0.0 build,
but there were no tests or docs for the new version. So I set out to make
sure things were working ok and do a little cleanup. I immediately ran into
some major issues that are going to require a bit of rework.
Unfortunatel
In cleaning up the rxsock6 code, I found a great example of how variable
references make things easier. The original rxsock code was written with
functions and the interface passed in stem variable names that were used to
return information, with the function main return value being an error
code.
error output.
>
>
> Um, no...as I explained earlier, the information read from stdin and
stderr is buffered and is not written to the "collector" objects until the
command in question completes.
Rick
>
> On 27.04.2018 18:03, Rick McGuire wrote:
>
>
>
> On F
On Sat, Apr 28, 2018 at 9:53 AM, Rony G. Flatscher
wrote:
> Trying to make the question clearer: while developing the code for the
> monitor's LINEIN method by accident I noticed that any error in this method
> will cause the input monitor to be regarded to be closed: in one version I
> was using
What part of "this is not real time" are you not understanding. All of the
data is buffered, so the first thing that happens is all of the input data
is read and buffered and then written to the pipe. The output data is
similarly buffered and not written out until the command completes.
Also, you
On Sun, Apr 29, 2018 at 10:23 AM, Rony G. Flatscher wrote:
> The following address-with program using arrays hangs on input using an
> input array:
>
> inArray=("first input.", "| second input. ", "| third input. ") -- input
> data
> outArray=.array~new
> errArray=.array~new
> say "inArray~ite
On Sun, Apr 29, 2018 at 11:41 AM, Rony G. Flatscher wrote:
> On 29.04.2018 16:35, Rick McGuire wrote:
>
>
> On Sun, Apr 29, 2018 at 10:23 AM, Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> The following address-with program using arrays hangs on
No, not really. a ::attribute is just a method that allows access to an
object variablewhich is just a variable like any other, just in a
different home. You still need the expose instruction to make the magic
happen.
Rick
On Wed, May 2, 2018 at 9:16 AM, Rony G. Flatscher
wrote:
> Experimen
r data
> dispatching ...
> Date: Sun, 29 Apr 2018 15:46:50 +0200
> From: Rony G. Flatscher
>
> To: oorexx-devel@lists.sourceforge.net
>
> On 28.04.2018 18:53, Rick McGuire wrote:
> > What part of "this is not real time" are you not understanding. All of the
> &g
Note that there's a useful implication to this. It would allow something
like this
expose finished
finished = .false
someobject~doSomeWork(>finished)
-- do some more stuff
guard on when finished -- wait for the thread to continue
Where the doSomeWork method could be something like this
On Wed, May 2, 2018 at 10:31 AM, Rony G. Flatscher
wrote:
> On 02.05.2018 15:27, Rick McGuire wrote:
>
> No, not really. a ::attribute is just a method that allows access to an
> object variablewhich is just a variable like any other, just in a
> different home. You still
On Thu, May 3, 2018 at 4:55 AM, Rony G. Flatscher
wrote:
>
>
> On 02.05.2018 17:12, Rick McGuire wrote:
>
> The question would be whether this should be just documented or whether
>> access via variable reference to attributes should be blocked if a
>> concurrently exe
sort and sortWith perform string comparisons by default. Use the
NumericComparator class to sort the strings as numbers.
The sections of the reference you are citing are for the different string
comparison operators. sort and sortWith do not use those operators, but
rather the compareTo method whi
On Mon, May 14, 2018 at 1:41 PM CV Bruce wrote:
> It’s pretty clear that in all your test cases, the data is being treated
> as text.
>
> If the cases where the data is in the format of “testxx” it will always be
> treated as a text string. Specifying just that portion of the variable that
> is n
You’ll need to write your own comparator class for that.
On Mon, May 14, 2018 at 2:42 PM Leslie Turriff wrote:
> On 2018-05-14 12:48:22 Rick McGuire wrote:
> > You can override that using sortwith and a numericcomparator instance.
> How would I combine numericCom
k the same way everywhere. This situation inflicts a very high
> astonisment factor for the user. Classic Rexx is so very intuitive and
> has
> few deficiencies in regards to built-ins; ooRexx, not so much.
>
> On 2018-05-14 13:53:02 Rick McGuir
t, start, length))
> On 2018-05-14 14:14:01 Rick McGuire wrote:
> > And as I have already pointed out, that is documentation for something
> that
> > does not apply for sorting. That is the documentation for the string
> > comparison operators, not the string compareTo() m
ote:
> On 2018-05-14 14:39:36 Rick McGuire wrote:
> > On Mon, May 14, 2018 at 3:27 PM, Leslie Turriff
> wrote:
> > It's frustration, really; I didn't mean to be sharp. It seems as
> > if much of the time, things that seem straightforward, in ooRexx tur
r requirements.
Rick
Rick
On Mon, May 14, 2018 at 4:01 PM, Leslie Turriff wrote:
> On 2018-05-14 14:39:36 Rick McGuire wrote:
> > Frankly, a request for a NumericColumnComparator would fall pretty far
> down
> > the list of things I might work on, but once you have written one
&
0e0" because both happen to be
numeric data. Under those rules, there is no definable sort order for the
data items.
Rick
>
> On Mon, 14 May 2018, 4:10 pm Rick McGuire, wrote:
>
>> That would be a very bad thing. If the data in the array was a mix of
>> numeric and non-n
201 - 300 of 2843 matches
Mail list logo
