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

[Ian L. <dr...@gm...>]

Great, I'm looking forward to see what Salim comes up with.

The flickering problem is due to the following reason, and is
intentional because it serves an instructive point for kids.

Each graphics operation completes before program execution continues.
Since a graphics refresh takes a certain amount of time, (about 200ms
on my machine), and CLG is a graphics operation, you're seeing the
ball drawn for 200ms, then a blank screen for 200ms, and so forth.
This is what causes the flicker.

No matter how fast the graphics are redrawn, flicker will always be a
problem when done like this, because each graphics operation is
essentially a relatively slow constant time operation, so you'll
always see a blank screen for as long as you see any other change.

This is why I included the FASTGRAPHICS mode, which is essentially
double buffering, and removes this problem.  If you issue the command
FASTGRAPHICS in a basic256 program, only the back-end buffer will be
modified for any drawing command, and you won't see the changes until
you issue a REFRESH command.  This is why the ballaccel.kbs demo
doesn't flicker.

The reason it's done like this is so that you can write a simple pong
game, for example, and not have to worry about the graphics getting
out of sync with the collision test code.  Because the interpreter
runs in its own thread which cannot do its own redraw (widget updates
have to be done from the main thread) the threads have to be
synchronized on any visible graphics update.

So having two modes allows the advanced kids to write a decent looking
animation, while keeping it really simple for beginners.

Is QGraphicsScene available before QT-4.2?  This may cause problems
when compiling on some Linux distributions which include an older
qt-4.

To answer your other question, read() ignores all whitespace between
tokens (spaces, tabs, newlines).  So unless there's only whitespace
before the end of a file, a token will be returned.

-Ian



On 11/22/06, tony007 <sup...@go...> wrote:
> 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
> >
>
>
> -------------------------------------------------------------------------
> 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
>
>
>