OK, this is also in 4525. I have narrowed it down -- it dies on the
second call to sysfileexists -- will add more details and scenario to
tracker.
Mike
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
http://bit.ly/mfc
IBM UK (MP8), PO Box 31, B
The ooRexx 4.0 Beta files on SourceForge have been refreshed. The
subversion level is 4525.
All bugs reported during this beta, to date, have been fixed in this build.
The files are available at:
https://sourceforge.net/project/showfiles.php?group_id=119701
Those people participating in the be
Most of the commits in that range were to the branch where I tried
replacing the the C runtime functions with native ones. Add to that
the fact we're updating both the trunk and beta branch with all bug
fixes, the commit numbers ratchet up pretty quickly.
However, it looks like the version that M
> The only other difference between 4507 and 4523 is the fix for
> SysFileSearch(). Nothing at all related to rxapi.
Sorry ... I meant Rexx APIs, not rxapi.
I have exactly one call to SysFileSearch in all my Rexx programs, and
definitely nowhere near the failing case (in fact I don't even remem
Rony G. Flatscher schrieb:
> Here is another run, where this error occurs for the "exit" statement!
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> D:\Dokumente und Einstellungen\Administrator>rexxtry say hallo
> HALLO
>
The only other difference between 4507 and 4523 is the fix for
SysFileSearch(). Nothing at all related to rxapi.
Rick
On Mon, Apr 27, 2009 at 2:32 PM, Mike Cowlishaw wrote:
> OK, here's update ...
>
>> I think Mike and I might have got crossed up by slow e-mails.
>> (Maybe.) His subject title
OK, here's update ...
> I think Mike and I might have got crossed up by slow e-mails.
> (Maybe.) His subject title says 4521. But, the build with your fix
> in it was 4523.
>
> Anyhow, I pointed him to a 4523 build that is a fresh check out from
> the beta branch, rather than a build from my tr
Rick,
I think Mike and I might have got crossed up by slow e-mails.
(Maybe.) His subject title says 4521. But, the build with your fix
in it was 4523.
Anyhow, I pointed him to a 4523 build that is a fresh check out from
the beta branch, rather than a build from my trunk. That way we can
be sur
On Mon, Apr 27, 2009 at 9:55 AM, Mike Cowlishaw wrote:
> Something else changed between these builds ... now the first time GoServe
> calls Rexx it works fine, but on the second call it crashes with a C05
Mike, I did the build from trunk, rather than the beta source tree.
Let me get you a b
This could conceivably be caused by the same change, but I'm probably
going to need something to recreate this so I can debug.
Rick
On Mon, Apr 27, 2009 at 12:55 PM, Mike Cowlishaw wrote:
>
> Something else changed between these builds ... now the first time GoServe
> calls Rexx it works fine, b
Something else changed between these builds ... now the first time GoServe
calls Rexx it works fine, but on the second call it crashes with a C05
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
http://bit.ly/mfc
IBM UK (MP8), PO Box 31,
All,
I'm planning on refreshing the beta builds on SourceForge today. All
the bugs reported so far have been verified as fixed, except for
Mike's of course. I'm hopeful that one is also. It seems there is a
good chance of it.
I know David is busy, so I'm planning on doing the Linux builds also
It's fixed for me also.
The new test build is almost ready, I'll let Mike know as soon as it
is available.
--
Mark Miesfeld
On Mon, Apr 27, 2009 at 9:20 AM, Rick McGuire wrote:
> I think I've fixed this! A big thanks to Rony...his method for
> reproducing this was 100% effective once Mark gave
I saw your commit and am building from trunk right now. (Guess I
should have built from the beta.) But, I think trunk is good enough
for Mike to just try.
--
Mark Miesfeld
On Mon, Apr 27, 2009 at 9:20 AM, Rick McGuire wrote:
> I think I've fixed this! A big thanks to Rony...his method for
> r
I think I've fixed this! A big thanks to Rony...his method for
reproducing this was 100% effective once Mark gave me the key to
getting it to work. The problem only seemed to occur if our buffering
is turned off for stdin. When buffering was turned off, I would
consistently see the bogus charact
I hadn't thought of trying Rexxtry. Thanks Rony!
An even simpler scenario: start Rexxtry, then just type a single letter
command (and Enter) that is valid and does nothing (so returns very fast)
(I have a c.rex that contains only a comment), and repeat, fast.
Below is what I just got --- almos
This is useful. I now have a consistent means of reproducing this,
I'm able to gather a little more debug info. Unfortunately, what I've
gotten so far just confirms what I already new...that the bogus
character is coming from the C runtime routine.
RIck
On Mon, Apr 27, 2009 at 11:17 AM, Mark Mi
On Mon, Apr 27, 2009 at 8:09 AM, Rick McGuire wrote:
> Ok, I've got the magic incantation correct now too. The key was not
> picking up the EOL for the exit command but physically hitting enter.
> I seem able to reproduce this reliably now too.
That's good. I tried commenting out _setMode(file
> Okay, it's built. I sent Mike the link to get it.
OK, will give it a try. Fingers-crossed ...
Mike
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Ok, I've got the magic incantation correct now too. The key was not
picking up the EOL for the exit command but physically hitting enter.
I seem able to reproduce this reliably now too.
Rick
On Mon, Apr 27, 2009 at 11:05 AM, Mark Miesfeld wrote:
> Okay, I'll try that.
>
> Tried with 3.2.0 about
Okay, I'll try that.
Tried with 3.2.0 about 10 times and it never happened.
On 4.0.0, it happens for me every single time I paste the lines into
the console window.
--
Mark Miesfeld
On Mon, Apr 27, 2009 at 8:01 AM, Rick McGuire wrote:
> Hmmm, this is starting to push the issue back to being an
On Mon, Apr 27, 2009 at 7:47 AM, Rick McGuire wrote:
> Have you tried reproducing using the patched version? I tried this
> technique this morning both the unpatched and official beta version
> and didn't get any failures.
Yes, I just tried with the patched build I did earlier this morning
and
Hmmm, this is starting to push the issue back to being an I/O problem.
Here's something to try. In SysFile::setStdIn(), try commenting out
the line
_setMode(fileHandle, _O_BINARY);
and see if you can recreate the problem. I'm wondering if switching
the mode while characters are already in t
I'm just about to try that. I was seeing how reliable it was that I
saw RXIT. Seems to be ever time when I paste the text into the
window.
I think another key is that Rony says he sees it when:
> immediately issuing a say statement (typing while rexxtry.rex starts up).
So here, the keyboard bu
Have you tried reproducing using the patched version? I tried this
technique this morning both the unpatched and official beta version
and didn't get any failures.
Rick
On Mon, Apr 27, 2009 at 10:42 AM, Mark Miesfeld wrote:
> Well, okay. By pasting lines into a console window, I got RXIT:
>
>
Well, okay. By pasting lines into a console window, I got RXIT:
D:\Interpreters\Rexx>rexx -v
Open Object Rexx Version 4.0.0
Build date: Apr 20 2009
Addressing Mode: 32
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2009.
All Rights Reserved.
This program and the accompanying
Pretty regularly I can get that problem too when opening a command line
window, and first thing I would do is using rexxtry and immediately
issuing a say statement (typing while rexxtry.rex starts up). Here's an
example that works *quite reliably* for me:
Microsoft Windows XP [Version 5.1.2600
Okay, it's built. I sent Mike the link to get it.
--
Mark Miesfeld
On Mon, Apr 27, 2009 at 5:48 AM, Mark Miesfeld wrote:
> I've applied the patch and am building the install package right now.
> I'll let you know when it's ready Mike.
>
> Rick, I'm hopeful about this. On Windows I really think
I've applied the patch and am building the install package right now.
I'll let you know when it's ready Mike.
Rick, I'm hopeful about this. On Windows I really think we should
only use GlobalAlloc and its relatives instead of malloc. The only
time I use malloc is when I'm going to free it right
Ok, I have one more thing to try. I'm starting to think this might be
a memory-management issue, not an I/O issue. The buffer used for the
I/O is one of the few places in the ooRexx code where malloc() is used
to allocate memory. In fact, it wouldn't surprise me if this is the
first malloc reque
Sorry to report that the dreaded 'r' still appears with Rick's latest
(build 4507).
Maybe best to just document this in the readme as a probable Windows
problem?
Everything else is working beautifully!
Mike
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw
31 matches
Mail list logo
