David Ashley wrote:
>
> 1. ooRexx 3.2.0 MUST be built as a 31-bit application
>
Yeah, I see the problem I'm having is it's trying to build 64. Is there
a configure option
to suppress that behavior?
> 2. There are some minor problems which can be worked around
> 3. This will all be much easier w
I used to see this all the time in Solaris like three years ago and then
you guys fixed it.
Anybody know what this turned out to be for Sol?
May if I #ifdef whatever's #ifdef'ed for Solaris, it will run on Linux
for Z.
(cd .libs && rm -f librexxutil.la && ln -s ../librexxutil.la
librex
Jack Woehr wrote:
> Anybody else building any version of OORexx on Linux 390?
>
>
Well, it has been done. But no one has offered the result back to the
project. Some things to remember when attempting this
1. ooRexx 3.2.0 MUST be built as a 31-bit application
2. There are some minor problems w
Anybody else building any version of OORexx on Linux 390?
--
Jack J. Woehr# "Self-delusion is
http://www.well.com/~jax # half the battle!"
http://www.softwoehr.com # - Zippy the Pinhead
-
This SF.Net email is
Ok, everything is running cleanly again. There were multiple problems
here...one was a regression introduced by the fixes for the macrospace
code. That caused random crashes. The test failures were caused by a
bug that's been in there for at least 9 months, but the code wasn't
getting driven unt
On Thu, Oct 16, 2008 at 9:08 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> When running a lot of tests inside the debugger, if the test runs all
> the way to completion, the output window closes before I get a chance
> to see the results. Is there any option that will force a "Hit enter
> to cont
Rick,
There isn't a pause option. I'll add one real quick, give me a few minutes.
--
Mark Miesfeld
On Thu, Oct 16, 2008 at 9:08 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Mark,
>
> When running a lot of tests inside the debugger, if the test runs all
> the way to completion, the output windo
Mark,
When running a lot of tests inside the debugger, if the test runs all
the way to completion, the output window closes before I get a chance
to see the results. Is there any option that will force a "Hit enter
to continue" after dumping the test results?
Rick
--
On Thu, Oct 16, 2008 at 7:11 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Could you rerun this and show a larger piece of the stack trace? My
> initial guesses have not panned out, so I need all the information I
> can get.
Rick, I'll run it first thing after work today and collect a complete
s
Mark,
Could you rerun this and show a larger piece of the stack trace? My
initial guesses have not panned out, so I need all the information I
can get.
Rick
On Thu, Oct 16, 2008 at 10:05 AM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 16, 2008 at 3:29 AM, Rick McGuire <[EMAIL PROTECT
On Thu, Oct 16, 2008 at 3:29 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
> I suspect there's a memory heap corruption problem in here. Those can
> show up much later than the triggering cause, which can make them
> seriously difficult to diagnose. I don't think I've ever seen one
> manifest its
On Wed, Oct 15, 2008 at 10:33 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 5:44 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
>> In the current trunk version, there are test failures if you run the
>> entire test suite. The same tests run individually don't exhibit the
>>
12 matches
Mail list logo
