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

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

Ok, I didn't look closely enough to realise it is intentional.

I'm starting to think it's not worth worrying about now - I can hear you
saying "I told you so" :-) - and that I should concentrate on something a
bit more productive that will actually enhance the user experience.
Yes, QGraphicsScene is new to Qt 4.2 and I guess it will be a problem for
people with < 4.2, which is also a good reason to leave it alone...

What about syntax highlighting in the editor view - any thoughts on that or
anything else ( I've not forgotten about the focus bug )?

tony

On 22/11/06, Ian Larsen <dr...@gm...> wrote:
>
> 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
> >
> >
> >
>