Re: [Oorexx-devel] Playing with the stream library in Rick's sandbox

[Rick M. <obj...@gm...>]

Mark,

If you get a chance, any changes to the Windows version of SysFile
might also be needed in the unix version as well.  I've not gotten to
the point of debugging anything on linux yet, but no sense in
debugging some of these problems twice.

Rick

On Thu, Jun 19, 2008 at 12:34 PM, Mark Miesfeld <mie...@gm...> wrote:
>
> On Thu, Jun 19, 2008 at 8:07 AM, Rick McGuire <obj...@gm...> wrote:
>>
>> See my comments below.
>>
>> On Thu, Jun 19, 2008 at 10:08 AM, Mark Miesfeld <mie...@gm...>
>> 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
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>