Re: [Kidbasic-devel] Fwd: File access?

[tony007 <sup...@go...>]

Ian,

I've forwarded the icons you did to my friend ( Salim ) and asked him to go
ahead with making a set for basic256. I've not heard back from him yet so I
don't know how he's getting on and whether they'll be ready for the next
release? As soon as I hear back I'll mail this list with any info.

Didn't get to do much over the weekend unfortunately due to hardware
problems and other commitments but started looking at using QGraphicsScene
to render the graphics. I don't know if you guys have noticed but when
running ballanim.kbs there is a lot of flickering and I'm hoping this might
go away with the introduction of QGraphicsScene, though I'm not certain till
I've got it working. It does mean a bit of a change to setting the image and
mask in the Interpreter thread as the drawing needs to be defered till the
signal gets back to the RunController in the gui thread ( at least I think
that will fix the update problems I'm having ). If you haven't done it
already I'll put the dockwindow menus in the View menu tonight ready for the
next release.

Quick question about the file reading: Does read() ignore blank lines or if
not, will this get confused with EOF?

tony

On 20/11/06, Ian Larsen <dr...@gm...> wrote:
>
> Ferry,
>
> I've added the file access from your branch with the following changes:
>
> - Removed "mode" support.  I think this will be confusing for kids.
> Files are all open read/write.
>
> - Removed error return code.  File errors halt execution with an error
> in the text output window.  EOF's returns a blank string, so you can
> check for end of file conditions that way.
>
> - All writes are appended to the end of the file, after which file
> position is returned to the previous position for reading.  This way
> data isn't ever overwritten, but reads still occur sequentially, which
> I think will be the most intuitive for new programmers.
>
> I think this will be the easiest method for file I/O for kids.  We
> might want to consider a fileClear function to wipe a file clean, so
> new data can be written.
>
> I'll be making a new release soon with these new features.  Thanks to
> all for the excellent work.  I really appreciate the help with this,
> and it's coming along much faster and better than I could do myself.
>
> -Ian
>
>
>
> On 11/19/06, Ferry Hendrikx <fer...@gm...> wrote:
> > All done and committed to the repository (rev 134). We now have 4 file
> > operations:
> >
> > - int open(string name, string mode)
> >   - mode can be one of "read" or "write", defaulting to "read".
> >
> > - string read()
> >   - read one token from the file
> >
> > - int write(string token)
> >   - write one token to the file
> >
> > - int close()
> >   - close the file
> >
> > Cheers
> >
> > /Ferry
> >
> >
> > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > Let's start with those four, and see if we get requests for others.
> > >
> > > We can probably just use open, read, write, and close, instead of
> > > prepending an "f," since I don't forsee implementing READ and DATA in
> > > basic256.
> > >
> > > -Ian
> > >
> > >
> > >
> > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > I agree, keeping it simple is best.
> > > >
> > > > We therefore have at least 4 new functions:
> > > >
> > > >   error = fopen( filename )
> > > >   - open the file (for read and write? or separate them out?)
> > > >   - return simple true or false
> > > >
> > > >   token = fread()
> > > >   - return the next token in the file
> > > >   - ignore line breaks?
> > > >
> > > >   fwrite( token )
> > > >   - write the token to the end of the file
> > > >
> > > >   fclose()
> > > >   - close the file
> > > >
> > > > Are these 4 enough or do we need any further functions?
> > > >
> > > > For example:
> > > >
> > > >   feof  ??
> > > >   - way to tell when we've reached the end of the file
> > > >
> > > >   fseek  ??
> > > >   - seek into the file
> > > >
> > > > Cheers
> > > >
> > > > /Ferry
> > > >
> > > >
> > > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > >
> > > > > I think supporting one open file (at a time) would be plenty for
> our
> > > > > purposes, and would make implementation a bit easier.
> > > > >
> > > > > Instead of reading characters though, I think the default function
> of
> > > > > a file read command should be to emulate the input statement, and
> read
> > > > > entire tokens.  That way a kid could type in a file:
> > > > >
> > > > > 1  aString  2.23  -3  10
> > > > > 11  24  Ian  34
> > > > >
> > > > > and calling read would return 1, then "aString", and so forth.
> > > > > We could have the data type default to string for simplicity,
> counting
> > > > > on the programmer to change it to the type he wants with int(),
> for
> > > > > example, or we could attempt to decide what the type is based on
> the
> > > > > token.
> > > > >
> > > > > My inclination is to return strings only, to keep things simple
> and predictable.
> > > > >
> > > > > -Ian
> > > > >
> > > > >
> > > > >
> > > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > > I definitely agree that we want to avoid the classic basic
> approach.
> > > > > >
> > > > > > The FOPEN (and others) approach is reasonable and we should
> probably
> > > > > > be working at the character level, as dealing with UTF-8 etc
> would be
> > > > > > a real pain...
> > > > > >
> > > > > > We could take a C-like approach and have a gets(number)
> function? e.g.
> > > > > > returns <number> characters in a string from the currently open
> file
> > > > > > (until end of line?)
> > > > > >
> > > > > > Hmm.. also, do we want to support one open file or more than
> one?
> > > > > >
> > > > > > Cheers
> > > > > >
> > > > > > /Ferry
> > > > > >
> > > > > >
> > > > > > On 11/17/06, Ian Larsen <dr...@gm...> wrote:
> > > > > > > Actually, I haven't given it much thought, but you're right,
> it would
> > > > > > > be good to have that.
> > > > > > >
> > > > > > > We could have an FOPEN, FREAD, and FWRITE command.  I'm just
> unsure of
> > > > > > > whether they should work at the byte or character level.
> > > > > > >
> > > > > > > What I usually do is write an example program or tutorial
> first, and
> > > > > > > then code the commands.  It helps to focus on what is actually
> > > > > > > necessary to teach kids.
> > > > > > >
> > > > > > > Traditionally BASIC used READ and DATA statements for data
> input, but
> > > > > > > personally I was never crazy about that approach, most
> importantly
> > > > > > > because I think data should be a separate entity from the
> program that
> > > > > > > reads/alters it.
> > > > > > >
> > > > > > > The approach that LISP takes for file input is nice.  You can
> use the
> > > > > > > lisp read command on an open file to read a token, or
> read-line to
> > > > > > > read a line.  There's also read-char and read-byte.  This
> might be the
> > > > > > > best way to handle it, so kids can have a text file of data
> separated
> > > > > > > by white space and just read each token in one at a time.
> > > > > > >
> > > > > > > -Ian
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/16/06, Ferry Hendrikx <fer...@gm...> wrote:
> > > > > > > > Has anyone given any thought to file access? It would be
> useful to be
> > > > > > > > able to open, read and write text files...
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > >
> > > > > > > > /Ferry
> > > > > > > >
> > > > > >
> > > >
> > >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>