kidbasic-devel

Re: [Kidbasic-devel] Bug, Feature and Translation

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

Hello,

I've changed the permissions on the shell account so you should be
able to write the files that are there currently.

Feature requests:
Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
command anyway so that it uses some type of list, instead of having to
fill an array to use it.  We'll keep the original functionality, too,
but I think it's a bit involved for a simple command.

What this will mean is that a "list" type will be added to Basic256,
or it will be possible to define an unnamed array, like this: [1, 30,
4, 5].  Any additional ideas are welcome.

Sound is a top priority, as soon as I find the time to do it.  Break
points are a great idea that many people have requested, so they'll be
next.  The U/I improvements all sound like good ideas to me, too.

> - The IF/THEN statement could get an ELSE and an ENDIF.

I'd rather not.  I think it's instructive to have to use GOTO as
opposed to higher level constructs so kids can figure out what the
computer's actually doing.

The lisp program wouldn't be as difficult to use as you think.  I can
separate it into two files: the first would be the actual program that
reads and outputs the html, and the second would be the kbcommand
portion that just has the documentation in it.  So the files would be:

generate.lisp (translators wouldn't touch this.)
translation_en.lisp (translators change the English portions to chosen language)

That way, to do a translation you'd just need to copy the
translation_en.lisp and alter any english string.  This would allow me
to change generator.lisp to whatever format I want, and it would still
use the translation without modification.

-Ian



On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> thank you very much for your reply.
> Again this will be a longer e-mail. I will write about these topics:
> 1) Feature requests
> 2) Shell access
> 3) Documentation
>
> ad 1) Feature requests
> - The top feature request is regarding sound. At least "my" kids
>   like it to produce some noise with the computer. We discussed
>   this already in a previous mail. I told them the current state.
>   One kid had the same idea that you had: some SOUND command together
>   with some ready to use, short sounds would be sufficient.
> - It would be great if the POLY command would fill the inner
>   areas of the figure with the current color. Maybe there could be
>   a 3rd parameter to the command indicating whether the poly should be
>   filled.
>   But I know that this is not that easy to achieve.
> - The IF/THEN statement could get an ELSE and an ENDIF.
> - Some "break point facility" would be great.
> But overall the kids are very happy with Basic256 and like it a lot.
> Some (minor) UI issues I do still have are:
> - The Variable Window could get a close button. Using the
>   menu is "cumbersome".
> - I would like to be able to select a mono spaced font for the Main
>   Window (the source code).
> - Syntax Highlighting should be switchable (for those that do not
>   like to read colorful code).
> - A Clear-button for the Graphics and the Text Window would be nice.
> - The variable(s) that changed with a program step could be highlighted
>   (for instance shown in dark red) in the Variable Window.
>
> ad 2) Regarding shell access
> You are right, I do have shell access. While I can create new files in
> the htdocs project directory, I can not modify existing ones, as they
> are not group writable:
>   [igb_ppp@sc8-pr-shell1 htdocs]$ ls -l
>   total 340
>   ...
>   -rw-r--r--  1 drblast kidbasic 18458 Dec  8 16:16 reference_de.html
>   ...
>   [igb_ppp@sc8-pr-shell1 htdocs]$ touch reference_de.html
>   touch: cannot touch `reference_de.html': Permission denied
>
> ad 3) Documentation
> While I am not familiar with lisp I think it would be ok, but not in the
> current form: With the current approach of the program, every new
> language would mean a new program (or some loop over all languages,
> which would be in the same program, would be required). This makes it
> harder to change the program in the future. Some separation between the
> texts and the program would be good. It is not necessary to have xml
> for the texts (in fact I do not like xml too much), I could also imagine
> a format similar to the lisp code, but only taken out of the program.
> Of course all other texts (like Command, Example, Note, the title, ...)
> need to be translated, too.
>
> BTW, when do you plan to release version 1.0?
>
> Thank you and best regards,
> Immo
>
> Am Sun, 10 Dec 2006 15:46:34 -0800
> schrieb "Ian Larsen" <dr...@gm...>:
>
> >  Ok, let me try not to leave anything out:
> >
> > The way you're committing your translation to svn is fine, it seems to
> > be working out well.  You don't have to change anything there.
> >
> > The bug/request tracker is great for individual requests.  What
> > doesn't work so well is when people put multiple requests in one
> > tracker item - then it can't be closed until everything is addressed,
> > which defeats the purpose of the tracker.
> >
> > > Regarding the documentation: it would be good to have the
> > > command documentation separated into some yaml or xml format.
> >
> > The way I generate the documentation is with a Lisp program, which is
> > attached and looks like this:
> >
> > (kbcommand
> >   "Tan"
> >   "tan ( <i>expression</i> )"
> >   "Computes the tangent of <i>expression</i>. <i>Expression</i> must
> > be in radians."
> >   :seealso "Sin, Cos"
> >   :note "The tan function does not produce an exact result.")
> >
> > This generates the single HTML page and all of the individual ones
> > that are included in the zip file.
> >
> > Now, as far as the xml goes, I can easily generate xml with the Lisp
> > file too.   Would you rather that, or would it be easier if I just
> > made the lisp program available so that you could translate that?
> > (gnu CLisp understands special characters via unicode)
> >
> > I really like the idea of having the documentation in subversion, we
> > just need to agree what format will be easiest to work with.
> >
> >
> > > @Ian, regarding the current German online reference: would it
> > > be possibe to give me shell access to the project html files and
> > > write permisson for the German documentation?
> >
> > Sure.  In fact, I think you already have access, you just need to set
> > up an ssh key and you should be able to log in.  That includes all of
> > the developers, too, if you need to change anything.
> >
> > Maybe we should set up a subversion folder for the web site, too.  It
> > might be easier to change if we all had an up-to-date copy.   If
> > you're going to go through the trouble of translating everything, it
> > will probably be easier this way.
> >
> > > From my class I do have some feature requests. Again the question:
> > > shall I use the project request tracker or rather send an e-mail?
> >
> > Let's talk about them over email and add the ones to the tracker that
> > make sense for the 1.0 release.
> >
> > -Ian
> >
> >
> > On 12/10/06, Immo-Gert Birn <imm...@gm...> wrote:
> > > Hello all,
> > >
> > > this is going to be a longer mail, sorry.
> > >
> > > First of all I have to commit to a stupid mistake: I did not
> > > subscribe to the kidbasic-devel mailing list. Thus I did not get
> > > your replies and the "new release" announcement. Anyway, thank you
> > > for welcoming me.
> > >
> > > I did already some svn commits to update the German translation. I
> > > hope this was ok. I am not sure whether I should add a log message
> > > - what do you think?
> > > It is also not clear for me whether I do something wrong when using
> > > lupdate: the ts-files generated always have lines
> > >   ...location filename="../<filename>" ...
> > > Normally I simply delete these lines using an editor before svn
> > > commit in order to keep the diff small. Don't you also get these
> > > lines? Additionally, I do always revert all lupdate changes to
> > > files other than the German translation - I hope this is ok.
> > >
> > > I filed the bug about the "step" in long vertical and horizontal
> > > lines drawn with the LINE command. Ian already resolved this -
> > > thank you. Is it ok to use the bug tracker or do you prefer an
> > > e-mail?
> > >
> > > From my class I do have some feature requests. Again the question:
> > > shall I use the project request tracker or rather send an e-mail?
> > >
> > > Regarding the documentation: it would be good to have the
> > > command documentation separated into some yaml or xml format. This
> > > would allow to generate the online reference and the release
> > > documentation (as included in the windows zip file) for all
> > > languages and ease the translation. In case you agree, I can start
> > > to do this - probably I'll choose yaml for the text format and
> > > write some ruby scripts. But this would mean that the documentation
> > > for new commands is done in the English master file only and then
> > > translated. I would very much like to have the documentation
> > > language files as well as the needed scripts and html templates in
> > > some folder in the svn repository. This would make the maintenance
> > > of these tools transparent, allow bug fixes, and translators could
> > > simply check the svn log and svn diff of the English documentation
> > > in order to catch up with changes. Your ideas and proposals
> > > regarding these topics are very welcome.
> > >
> > > @Ian, regarding the current German online reference: would it
> > > be possibe to give me shell access to the project html files and
> > > write permisson for the German documentation? Then I could simply
> > > update it as I finish some new command, fix bugs or apply small
> > > changes to the file. I do also plan to translate the tutorials and
> > > the "Why basic?" text - I hope this is ok with you.
> > >
> > > Best regards,
> > > Immo
> > >
> > >
>

Re: [Kidbasic-devel] Bug, Feature and Translation

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

Sorry, still not convinced :-)

This hypothetical example:

IF a < b THEN
  print "a is less than b"
  print "the statement was true"
ELSE
  print "a is greater than b."
  print "the statement was true."
ENDIF
  print "Now we are out of the conditional."
  end

Can be written as:

IF a < b THEN GOTO doIfTrue
  print "a is greater than b."
  print "the statement was false"
  goto myEndif
doIfTrue:
  print "a is less than b."
  print "the statement was true"
myEndif:
  print "Now we're out of the conditional."
  end

This second example only requires one more line than the previous
example, and is a much better example of how the computer actually
operates.  Not only that, but including ENDIF would necessitate using
it every time, so simple IF statements would look like this

IF a < b THEN
  print "a is less than b"
ENDIF

instead of the much simpler

IF a < b THEN print "a is less than b."

I just think the second one-liner is much more intuitive, and probably
a more common case in simple programs than performing multiple actions
after an IF.

-Ian



On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> shell access is fine now, I updated the German command reference.
>
> It would be great if you could separate the texts out of the lisp
> program - I could adapt my translation relatively fast to the new file
> format. For the svn directory I would like to suggest
> branches/devel/doc. In that directory the lisp program and the
> translation files could reside.
>
> The POLY plans sound good. The POLY command is indeed not too easy to
> use right now.
> I like the "unnamed array" idea - but it should be possible to use
> variables for the individual values. I am not sure whether one still
> should be forced to pass the number of sides to the program - I could
> live without this. I could also imagine an (optional) syntax
> [[0,0],[0,100],[100,0]]. Internally this could be treated as list (I
> really don't thing about nested arrays) and would be absolutely
> identical to [0,0,0,100,100,0], but it would be more clear what the
> different points are.
>
> I knew in advance that you would not like the IF/THEN ELSE ENDIF. Anyway
> I would like to make some points to convince you (maybe):
> - Sometimes GOTO/GOSUB will not help, you need to have more than one
> command in the THEN branch. I know that this is possible by using : to
> separate the commands, but this is ugly.
> - There is already the case of a command with a "body": the FOR/NEXT
> command.
> Maybe the ELSE is really not needed, but I think the ENDIF _is_ needed.
>
> Best regards,
> Immo
>
> Am Mon, 11 Dec 2006 09:20:53 -0800
> schrieb "Ian Larsen" <dr...@gm...>:
>
> > Hello,
> >
> > I've changed the permissions on the shell account so you should be
> > able to write the files that are there currently.
> >
> > Feature requests:
> > Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
> > command anyway so that it uses some type of list, instead of having to
> > fill an array to use it.  We'll keep the original functionality, too,
> > but I think it's a bit involved for a simple command.
> >
> > What this will mean is that a "list" type will be added to Basic256,
> > or it will be possible to define an unnamed array, like this: [1, 30,
> > 4, 5].  Any additional ideas are welcome.
> >
> > Sound is a top priority, as soon as I find the time to do it.  Break
> > points are a great idea that many people have requested, so they'll be
> > next.  The U/I improvements all sound like good ideas to me, too.
> >
> > > - The IF/THEN statement could get an ELSE and an ENDIF.
> >
> > I'd rather not.  I think it's instructive to have to use GOTO as
> > opposed to higher level constructs so kids can figure out what the
> > computer's actually doing.
> >
> > The lisp program wouldn't be as difficult to use as you think.  I can
> > separate it into two files: the first would be the actual program that
> > reads and outputs the html, and the second would be the kbcommand
> > portion that just has the documentation in it.  So the files would be:
> >
> > generate.lisp (translators wouldn't touch this.)
> > translation_en.lisp (translators change the English portions to
> > chosen language)
> >
> > That way, to do a translation you'd just need to copy the
> > translation_en.lisp and alter any english string.  This would allow me
> > to change generator.lisp to whatever format I want, and it would still
> > use the translation without modification.
> >
> > -Ian
>

Re: [Kidbasic-devel] Bug, Feature and Translation

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

I'm not going to wade into the debate about IF/THEN...   ;)

For POLY: as it stands right now it has the advantage that you can
programmatically generate points for it. I don't want to lose that
ability... maybe, as was suggested earlier, we can add unnamed arrays,
that points can be passed in (via named arrays) or specified directly
(via unnamed arrays).

We don't strictly need to pass in the number of points so this could
be removed; POLY could simply plot all the points it finds in the
array, ignoring any left-overs.

Cheers

/Ferry

> On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> > Hello,
> >
> > shell access is fine now, I updated the German command reference.
> >
> > It would be great if you could separate the texts out of the lisp
> > program - I could adapt my translation relatively fast to the new file
> > format. For the svn directory I would like to suggest
> > branches/devel/doc. In that directory the lisp program and the
> > translation files could reside.
> >
> > The POLY plans sound good. The POLY command is indeed not too easy to
> > use right now.
> > I like the "unnamed array" idea - but it should be possible to use
> > variables for the individual values. I am not sure whether one still
> > should be forced to pass the number of sides to the program - I could
> > live without this. I could also imagine an (optional) syntax
> > [[0,0],[0,100],[100,0]]. Internally this could be treated as list (I
> > really don't thing about nested arrays) and would be absolutely
> > identical to [0,0,0,100,100,0], but it would be more clear what the
> > different points are.
> >
> > I knew in advance that you would not like the IF/THEN ELSE ENDIF. Anyway
> > I would like to make some points to convince you (maybe):
> > - Sometimes GOTO/GOSUB will not help, you need to have more than one
> > command in the THEN branch. I know that this is possible by using : to
> > separate the commands, but this is ugly.
> > - There is already the case of a command with a "body": the FOR/NEXT
> > command.
> > Maybe the ELSE is really not needed, but I think the ENDIF _is_ needed.
> >
> > Best regards,
> > Immo
> >
> > Am Mon, 11 Dec 2006 09:20:53 -0800
> > schrieb "Ian Larsen" <dr...@gm...>:
> >
> > > Hello,
> > >
> > > I've changed the permissions on the shell account so you should be
> > > able to write the files that are there currently.
> > >
> > > Feature requests:
> > > Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
> > > command anyway so that it uses some type of list, instead of having to
> > > fill an array to use it.  We'll keep the original functionality, too,
> > > but I think it's a bit involved for a simple command.
> > >
> > > What this will mean is that a "list" type will be added to Basic256,
> > > or it will be possible to define an unnamed array, like this: [1, 30,
> > > 4, 5].  Any additional ideas are welcome.
> > >
> > > Sound is a top priority, as soon as I find the time to do it.  Break
> > > points are a great idea that many people have requested, so they'll be
> > > next.  The U/I improvements all sound like good ideas to me, too.
> > >
> > > > - The IF/THEN statement could get an ELSE and an ENDIF.
> > >
> > > I'd rather not.  I think it's instructive to have to use GOTO as
> > > opposed to higher level constructs so kids can figure out what the
> > > computer's actually doing.
> > >
> > > The lisp program wouldn't be as difficult to use as you think.  I can
> > > separate it into two files: the first would be the actual program that
> > > reads and outputs the html, and the second would be the kbcommand
> > > portion that just has the documentation in it.  So the files would be:
> > >
> > > generate.lisp (translators wouldn't touch this.)
> > > translation_en.lisp (translators change the English portions to
> > > chosen language)
> > >
> > > That way, to do a translation you'd just need to copy the
> > > translation_en.lisp and alter any english string.  This would allow me
> > > to change generator.lisp to whatever format I want, and it would still
> > > use the translation without modification.
> > >
> > > -Ian
> >
>
> -------------------------------------------------------------------------
> 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] Bug, Feature and Translation

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

I'm sorry, I didn't explain that correctly.

The way the parser works, it's either one way or the other.  If you
include ENDIF you can't have the option to leave it out in the
program, because the parser will never know when your conditional
ends.

It has to either assume the IF ends at the end of the line, or else
you have to explicitly tell it where the conditional ends, every time.

There may be a sort of compromise here, if we add a special command
for defining the beginning of a block:

IF a < b THEN DO
 print 1
 print 2
 print 3
ENDIF

But I'll have to take a look at that and see it that's possible to implement.

-Ian



On 12/12/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> of course I meant that the variant without ENDIF would be possible,
> too. But anyway, I was just a proposal and you are the project lead. At
> least I tried :-).
>
> Best regards,
> Immo
>
> Am Mon, 11 Dec 2006 15:07:32 -0800
> schrieb "Ian Larsen" <dr...@gm...>:
>
> > Sorry, still not convinced :-)
> >
> > This hypothetical example:
> >
> > IF a < b THEN
> >   print "a is less than b"
> >   print "the statement was true"
> > ELSE
> >   print "a is greater than b."
> >   print "the statement was true."
> > ENDIF
> >   print "Now we are out of the conditional."
> >   end
> >
> > Can be written as:
> >
> > IF a < b THEN GOTO doIfTrue
> >   print "a is greater than b."
> >   print "the statement was false"
> >   goto myEndif
> > doIfTrue:
> >   print "a is less than b."
> >   print "the statement was true"
> > myEndif:
> >   print "Now we're out of the conditional."
> >   end
> >
> > This second example only requires one more line than the previous
> > example, and is a much better example of how the computer actually
> > operates.  Not only that, but including ENDIF would necessitate using
> > it every time, so simple IF statements would look like this
> >
> > IF a < b THEN
> >   print "a is less than b"
> > ENDIF
> >
> > instead of the much simpler
> >
> > IF a < b THEN print "a is less than b."
> >
> > I just think the second one-liner is much more intuitive, and probably
> > a more common case in simple programs than performing multiple actions
> > after an IF.
> >
> > -Ian
> >
> >
> >
> > On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> > > Hello,
> > >
> > > shell access is fine now, I updated the German command reference.
> > >
> > > It would be great if you could separate the texts out of the lisp
> > > program - I could adapt my translation relatively fast to the new
> > > file format. For the svn directory I would like to suggest
> > > branches/devel/doc. In that directory the lisp program and the
> > > translation files could reside.
> > >
> > > The POLY plans sound good. The POLY command is indeed not too easy
> > > to use right now.
> > > I like the "unnamed array" idea - but it should be possible to use
> > > variables for the individual values. I am not sure whether one still
> > > should be forced to pass the number of sides to the program - I
> > > could live without this. I could also imagine an (optional) syntax
> > > [[0,0],[0,100],[100,0]]. Internally this could be treated as list (I
> > > really don't thing about nested arrays) and would be absolutely
> > > identical to [0,0,0,100,100,0], but it would be more clear what the
> > > different points are.
> > >
> > > I knew in advance that you would not like the IF/THEN ELSE ENDIF.
> > > Anyway I would like to make some points to convince you (maybe):
> > > - Sometimes GOTO/GOSUB will not help, you need to have more than one
> > > command in the THEN branch. I know that this is possible by using :
> > > to separate the commands, but this is ugly.
> > > - There is already the case of a command with a "body": the FOR/NEXT
> > > command.
> > > Maybe the ELSE is really not needed, but I think the ENDIF _is_
> > > needed.
> > >
> > > Best regards,
> > > Immo
> > >
> > > Am Mon, 11 Dec 2006 09:20:53 -0800
> > > schrieb "Ian Larsen" <dr...@gm...>:
> > >
> > > > Hello,
> > > >
> > > > I've changed the permissions on the shell account so you should be
> > > > able to write the files that are there currently.
> > > >
> > > > Feature requests:
> > > > Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
> > > > command anyway so that it uses some type of list, instead of
> > > > having to fill an array to use it.  We'll keep the original
> > > > functionality, too, but I think it's a bit involved for a simple
> > > > command.
> > > >
> > > > What this will mean is that a "list" type will be added to
> > > > Basic256, or it will be possible to define an unnamed array, like
> > > > this: [1, 30, 4, 5].  Any additional ideas are welcome.
> > > >
> > > > Sound is a top priority, as soon as I find the time to do it.
> > > > Break points are a great idea that many people have requested, so
> > > > they'll be next.  The U/I improvements all sound like good ideas
> > > > to me, too.
> > > >
> > > > > - The IF/THEN statement could get an ELSE and an ENDIF.
> > > >
> > > > I'd rather not.  I think it's instructive to have to use GOTO as
> > > > opposed to higher level constructs so kids can figure out what the
> > > > computer's actually doing.
> > > >
> > > > The lisp program wouldn't be as difficult to use as you think.  I
> > > > can separate it into two files: the first would be the actual
> > > > program that reads and outputs the html, and the second would be
> > > > the kbcommand portion that just has the documentation in it.  So
> > > > the files would be:
> > > >
> > > > generate.lisp (translators wouldn't touch this.)
> > > > translation_en.lisp (translators change the English portions to
> > > > chosen language)
> > > >
> > > > That way, to do a translation you'd just need to copy the
> > > > translation_en.lisp and alter any english string.  This would
> > > > allow me to change generator.lisp to whatever format I want, and
> > > > it would still use the translation without modification.
> > > >
> > > > -Ian
> > >
>