On Thu, Jun 19, 2008 at 8:07 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> See my comments below.
>
> On Thu, Jun 19, 2008 at 10:08 AM, Mark Miesfeld <[EMAIL PROTECTED]>
> wrote:
> > ... I just took out the position--; line
> >
>
> All of those look reasonable. Thanks for digging in to this! Go
> ahead and check these in.
>
Okay, I will. <grin>
> > read() returns true at eof, and looks like it is intended to return true
> for
> > that condition. So, I changed getChar() to only return true if it
> actually
> > got a new char:
>
> Well, the problem is in read. Those functions are supposed to return
> true if they read data, and false if they didn't return data for any
> reason.
I'll see about fixing that in read then.
> I had similar problems with linein() trying to get Rexxtry to
> work. I did a quick search for other places where I'd made the
> mistake, but obviously I missed at least one.
>
> > However, since gets() may have collapsed a /r/n into a single byte, I
> added
> > in an extra arg that would report if /r/n was collapsed into /n.
>
> Hmmm....probably the appropriate thing would be to ask the SysFile
> object what the current read position is rather than trying to infer
> it from the length that was returned.
>
Yes, I redid that this morning to use SysFile.getPosition() and cleaned it
up.
> > So it looks like the bufferAddress member of StreamInfo has gotten
> > overwritten. I still get baffled trying to figure those out, so that's
> > where I quit.
>
> These are actually pretty easy to figure out in Visual Studio. Set a
> break point at the place where the buffer pointer is allocated, then
> set a data breakpoing on "this->bufferAddress". This will catch the
> overlay for you when it happens.
>
I'll try that, again. You've pointed out this technique to me before.
<grin> I think the problem I had this time was that I was trying to set
the data breakpoint directly on bufferAddress and couldn't get the debugger
to resolve it. I didn't think to use 'this'.
>
> This is terrific progress! Thanks for taking the time to look at
> these. Don't be too hesitant about checking in fixes for these
> problems in the future. If you have, a fix, and it fixes the problem,
> go ahead and commit it. If you're not certain about the fix, ask for
> a review of the commit. If there's another course that should be
> taken, I can correct it there.
I'm slowly getting less shy.
--
Mark Miesfeld
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel