kidbasic-devel

[Kidbasic-devel] File access?

[Ferry H. <fer...@gm...>]

Has anyone given any thought to file access? It would be useful to be
able to open, read and write text files...

Cheers

/Ferry

Re: [Kidbasic-devel] File access?

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

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
>

Re: [Kidbasic-devel] File access?

[Ferry H. <fer...@gm...>]

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
> >
>

[Kidbasic-devel] Fwd: File access?

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

---------- Forwarded message ----------
From: Ian Larsen <dr...@gm...>
Date: Nov 16, 2006 4:20 PM
Subject: Re: [Kidbasic-devel] File access?
To: Ferry Hendrikx <fer...@gm...>


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
> > >
>

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

[Ferry H. <fer...@gm...>]

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
> > > >
> >

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

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

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
> > > > >
> > >
>

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

[Ferry H. <fer...@gm...>]

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
> > > > > >
> > > >
> >
>

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

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

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
> > > > > > >
> > > > >
> > >
> >
>

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

[Ferry H. <fer...@gm...>]

Ian,

Glad to hear you're happy with the contributions!

As you note below, some kind of "clear" (or reset) operation for files
sounds good. Maybe it should simply truncate an already open file?

For example:

  open(filename)
  reset()             <-- truncates file
  write(string)     <-- writes to the start of the file

Comments?

Cheers

/Ferry


On 11/21/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

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
>

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
>
>
>

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
> >
> >
> >
>

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

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

As far as the focus bug, I'm not sure if it's a big problem.  I'm not
sure how often anyone undocks the window at all, I'm apparently the
only one who's run into that particular bug.

Syntax highlighting could start with simply highlighting reserved
words.  I think that would be helpful to beginners.  We probably won't
be able to do much more than that without writing another parser.

-Ian


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