kidbasic-devel — Mailing list for developers of KidBASIC

Re: [Kidbasic-devel] all that work for nothing?

[<web...@bi...>]

Amine,

> It has been 2 weeks now since I sent my last message to this
> mailing list. I thought my contribution would be somewhat useful but
> it seems nobody want it... If I knew that from the start I wouldn't
> spend all that time on it...

Please do not worry. Your work will not be lost. Just not always
possible to do something quickly. And, I think it would be logical at
first to translate into French interface BASI256 (basic256_fr.ts), is not it?  

--
Blessing,
Sergei Irupin
RUSSIA

[Kidbasic-devel] all that work for nothing?

[Amine Brikci-N. <nh...@Li...>]

Hi,

It has been 2 weeks now since I sent my last message to this mailing list. I
thought my contribution would be somewhat useful but it seems nobody want
it... If I knew that from the start I wouldn't spend all that time on it...

Amine.

[Kidbasic-devel] add to mail list

[Сергей И. <bib...@ya...>]

<br /><br />-- <br />С уважением, Сергей Ирюпин [lamp]<br />http://rnd-lug.blogspot.com/

[Kidbasic-devel] french translation of why.html

[Amine Brikci-N. <nh...@Li...>]

Hello,

Here is the french translation of why.html

Amine.

Re: [Kidbasic-devel] french translation

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

Thank you for your translation work.  If you send the file to this
list we'll be happy to include it.

-Ian Larsen

On Tue, Apr 6, 2010 at 10:20 PM, Amine Brikci-Nigassa
<nh...@li...> wrote:
> Hello,
>
>
> I compiled BASIC-256 from SVN on my Debian Sid (Sidux actually) and my son
> loves it.
>
> I began to translate the reference guide to french. I will try to commit it
> but if I don't find how (I'm not used to SVN), I'll send the doc.lisp file
> to this mailing list.
>
> If someone else is in charge of the french translation, please tell me...
>
>
> Best regards,
>
> Amine.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Kidbasic-devel mailing list
> Kid...@li...
> https://lists.sourceforge.net/lists/listinfo/kidbasic-devel
>
>



-- 
My PGP Public Key:
http://www.scrapshark.com/pubkey.txt

[Kidbasic-devel] french translation

[Amine Brikci-N. <nh...@Li...>]

Hello,


I compiled BASIC-256 from SVN on my Debian Sid (Sidux actually) and my son
loves it.

I began to translate the reference guide to french. I will try to commit it
but if I don't find how (I'm not used to SVN), I'll send the doc.lisp file
to this mailing list.

If someone else is in charge of the french translation, please tell me...


Best regards,

Amine.

[Kidbasic-devel] Documentation and translation

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

All,

In addition to finishing anonymous string array support today, I
worked on the documentation/translation system a bit.

I've finally fixed all the lisp programs that were generating
documentation from before, so translations of the online documentation
should be very easy to do at this point.

The changes are in the /doc directory of the svn server.  Here's how it works:

The autogen.lisp file runs and reads language specific information
from the doc.lisp file stored in each language's directory under /doc,
and generates the manuals and reference page based on that.  It then
stores the results in the that language's directory.

So, to translate, all one has to do is copy the /doc/en/ directory and
translate the doc.lisp file there, and autogen.lisp does the rest.

I've made the changes to the german doc.lisp file, which I think is
the only other language for which we have translated documentation.

The nice part is that it generates a web page, in addition to a series
of separate html files that can be downloaded (maybe as a zip file),
at the same time.

I'm going to reorganize the web site so that each language gets its
own directory, as follows:

/en/index.html, /en/reference.html ... etc.
/de/index.html ... etc.

Hopefully this will make translating very simple.  Let me know if you
have suggestions.

-Ian

Re: [Kidbasic-devel] Language problem

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

All,

I've added command line support for languages in the devel branch.  It
works like this:

> basic256 -l de myprog.kbs

That command would start basic in German and load "myprog.kbs" in the editor.

The code to do this is in Main.cpp, and adding other command line
options should be extremely simple, should we need to do that.

As far as the new release goes, I'd like to finish adding support for
bracketed lists as array initializers before I release 0.9.2.
Currently these are working for numeric arrays, but not strings.  It's
just a matter of me finding a few hours to work on it, as I'm fairly
busy with school at the moment.

I'll let everyone know a few days ahead of time so last minute
translation can be done, if necessary.

-Ian




On 2/19/07, tony007 <sup...@go...> wrote:
> Hi Immo
>
>  1. There's a post in the developers forum by a guy who has a French machine
> and can't run the application because it's looking for a French translation
> file. He said he'd like to be able to use it with either Dutch of English so
> this would allow him to do so.
>  2. Ok.
>
>  Ian,
>
>  Do you have a plan for a next release? I can add the language change this
> week if that won't hold things up?
>
>  Cheers,
>  tony
>
>
> On 17/02/07, Immo-Gert Birn <imm...@gm...> wrote:
> > Am Thu, 15 Feb 2007 21:05:36 +0000
> > schrieb tony007 <sup...@go...>:
> >
> > > Hello chaps,
> > >
> > > Is there any reason why we couldn't allow the user to specify the
> > > language on the command line? It could function as it currently does
> > > if nothing is specified but would allow users to override the default
> > > setting. The results may be a little unpredictable but I think
> > > ( without testing ) that it will be ok if the host OS and the
> > > selected language are both using the latin charset. Am I right?
> > >
> > > tony
> >
> > Hi,
> >
> > from my point of view: just go ahead if you need it. Two remarks,
> > though:
> > 1) Why do you need this ? (I am just curious)
> > 2) Recently I added a feature that the basic file to be initially opened
> > can be passed on the command line. This makes it possible to open a
> > .kbs file with BASIC256 when double-clicking it in explorer. This has
> > to be re-worked in case an other command line option gets added (no big
> > deal, it just has to be done).
> >
> > Best regards, Immo
> >
> >
> -------------------------------------------------------------------------
> > 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] Language problem

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

Hi Immo

1. There's a post in the developers forum by a guy who has a French machine
and can't run the application because it's looking for a French translation
file. He said he'd like to be able to use it with either Dutch of English so
this would allow him to do so.
2. Ok.

Ian,

Do you have a plan for a next release? I can add the language change this
week if that won't hold things up?

Cheers,
tony

On 17/02/07, Immo-Gert Birn <imm...@gm...> wrote:
>
> Am Thu, 15 Feb 2007 21:05:36 +0000
> schrieb tony007 <sup...@go...>:
>
> > Hello chaps,
> >
> > Is there any reason why we couldn't allow the user to specify the
> > language on the command line? It could function as it currently does
> > if nothing is specified but would allow users to override the default
> > setting. The results may be a little unpredictable but I think
> > ( without testing ) that it will be ok if the host OS and the
> > selected language are both using the latin charset. Am I right?
> >
> > tony
>
> Hi,
>
> from my point of view: just go ahead if you need it. Two remarks,
> though:
> 1) Why do you need this ? (I am just curious)
> 2) Recently I added a feature that the basic file to be initially opened
> can be passed on the command line. This makes it possible to open a
> .kbs file with BASIC256 when double-clicking it in explorer. This has
> to be re-worked in case an other command line option gets added (no big
> deal, it just has to be done).
>
> Best regards, Immo
>
> -------------------------------------------------------------------------
> 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] Language problem

[Immo-Gert B. <imm...@gm...>]

Am Thu, 15 Feb 2007 21:05:36 +0000
schrieb tony007 <sup...@go...>:

> Hello chaps,
> 
> Is there any reason why we couldn't allow the user to specify the
> language on the command line? It could function as it currently does
> if nothing is specified but would allow users to override the default
> setting. The results may be a little unpredictable but I think
> ( without testing ) that it will be ok if the host OS and the
> selected language are both using the latin charset. Am I right?
> 
> tony

Hi,

from my point of view: just go ahead if you need it. Two remarks,
though:
1) Why do you need this ? (I am just curious) 
2) Recently I added a feature that the basic file to be initially opened
can be passed on the command line. This makes it possible to open a
.kbs file with BASIC256 when double-clicking it in explorer. This has
to be re-worked in case an other command line option gets added (no big
deal, it just has to be done).

Best regards, Immo

[Kidbasic-devel] Language problem

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

Hello chaps,

Is there any reason why we couldn't allow the user to specify the language
on the command line? It could function as it currently does if nothing is
specified but would allow users to override the default setting. The results
may be a little unpredictable but I think ( without testing ) that it will
be ok if the host OS and the selected language are both using the latin
charset. Am I right?

tony

[Kidbasic-devel] Translation

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

All,

I've added a /doc directory to our subversion repository.  This
contains one file currently, called doc.lisp.  I've also attached this
to this email.

This is part of the program I use to auto-generate all of the
documentation.  Translating this should be extremely straightforward,
and this way we can keep the documentation up to date in all languages
without having to hand-copy html files.

The other part of the program generates the html files.  I haven't
uploaded it because I have to alter it to reflect the changes made to
the web site.

-Ian

[Kidbasic-devel] Release 0.9.2

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

All,

I've made an update to the trunk, for anyone keeping track.  I added a
list notation for setting the contents of arrays and for the poly
command.  It works like this:

rem Array initialization
dim a(9)
a = {1,2,3,4,5,6,7,8,9}

rem new Poly command
poly {10,10,20,20,10,30}

The old poly command still works as always.  This will be included in
release 0.9.2.

-Ian

[Kidbasic-devel] Release 0.9.2

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

All,

I'm preparing to do a 0.9.2 release.  The source is in trunk/

Any last minute changes or translations should be done soon if you'd
like them included.  Thanks!

-Ian

Re: [Kidbasic-devel] Changes to BASIC256

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

Hello Immo-Gert,

Sorry it's been a while...I've been pretty busy lately and haven't had
much time for Basic.

Anyway, tonight I took a look at the changes you made and they look good.

I found a better way to do sound, however, so I completely changed the
sound command.  It now takes a frequency and duration argument and
plays a beep through the PC speaker.  I think this is a lot more fun
and instructive than having to go through playing the .wav files.

It only works on Windows currently, but implementing it on Linux
shouldn't be difficult.  All that has to be done is to create a sin
wave at the appropriate frequency and length and write it to /dev/dsp.

Once I finish that up on Linux I'll do a new release, hopefully this weekend.

As always, thanks for your help,
-Ian

On 1/19/07, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> with change list 212 I did a few changes:
> o I added an icon.
> o The sound command takes sound files from the directory where the
> executable resides unless a '/' or '\' is in the sound file name. Thus
> 'sound "click.wav"' takes the sound file from the BASIC256 install
> directory, while 'sound "../click.wav"' tries to use the specified path
> directly.
> o In case there is exactly one command line argument specified, the
> file is loaded into the editor after start up. This allows to associate
> *.kbs files with the BASIC256 executable,thus a doubleclick on a kbs
> file opens BASIC256 and loads the file.
>
> Since this is my first c++ change ever, it would be great if you could
> have a close look on this. As always, in case you do not like the
> changes, simply revert them.
>
> Finally, I would like to propose to make a 0.9.2 release soon.
>
> Best regards,
> Immo
>

Re: [Kidbasic-devel] Open Bugs

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

Hello all,

I've been away for a couple of days and I see that development hasn't
stopped. :-)  I'll be catching up on new bug reports and such later
today, hopefully fixing some and making a bug-fix release.  I don't
think anything we've done since the last release needs to be
translated.

I'm also going to be uploading a finished copy of the lisp
documentation generating program   so our translators have a single
place to make changes for that.

-Ian

On 12/20/06, Ferry Hendrikx <fer...@gm...> wrote:
> > Still there might be an issue: Currently, BASIC256 remembers the last
> > color even if a new program was started using Program->New:
> > Step 1:
> > Write a program
> >   clg
> >   color clear
> > and execute it.
> > Step 2:
> > Use the new button to start a new program:
> >   line 10,10,300,10
> > and execute it. Noting will be drawn as the current color is still set
> > to CLEAR.
> > I think this is a bug.
>
> This issue has now been fixed in the development branch (rev 209). The
> colour now defaults to black when starting a new program.
>
> 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] Open Bugs

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

> Still there might be an issue: Currently, BASIC256 remembers the last
> color even if a new program was started using Program->New:
> Step 1:
> Write a program
>   clg
>   color clear
> and execute it.
> Step 2:
> Use the new button to start a new program:
>   line 10,10,300,10
> and execute it. Noting will be drawn as the current color is still set
> to CLEAR.
> I think this is a bug.

This issue has now been fixed in the development branch (rev 209). The
colour now defaults to black when starting a new program.

Cheers

/Ferry

[Kidbasic-devel] POLY command changes (rev 208)

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

Hi all,

I've removed the need for the 'count' on the POLY command. The parser
still recognises it, however the interpretor completely ignores any
values passed and simply plots (size of array) / 2 points.

This does mean however that if you create an array size 10, it will
plot a 5 sided polygon. Also, if you only populate 8 of those 10 array
entries, the last two array entries will be zero-filled and hence the
final point of the polygon will be at (0,0).

Cheers

/Ferry

[Kidbasic-devel] New features

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

Immo,

I'm forwarding your message to the mailing list.

1) I'm wondering if the Rainbow example bug is due to the version of
QT4 that I distribute with the Windows binary.  If you could check
this once more after the next release I'd appreciate it.  I'm going to
compile the latest QT version before the release, is that what you
used?

2) I've added a SOUND command in the devel branch.  Currently it takes
a path to a .wav file as an argument and plays that.  It works fine on
windows, but I haven't yet tested it in Linux.  It uses the QSound
system, which should be cross-platform, but I'm not sure how well that
works.

3) The semicolon character is now a shortcut for the REM command.

4) I'll fix the interpreter so the color resets to black before a
program is run.

-Ian


---------- Forwarded message ----------
From: Immo-Gert Birn <imm...@gm...>
To: kidbasic-devel <kid...@li...>
Date: Thu, 14 Dec 2006 18:49:03 +0100
Subject: Open Bugs
Hi all,

I had a look at the two open bugs.

1) Win98 rainbow example does not work
I could reproduce the issue and found that the newest version (as
made from current dev source) does not have the issue any more. More
details can be found in the bug description. Probably the bug report can
be closed.

2) Concentric circles - What is wrong?
Evidently the bug submitter would like to have circles that are not
filled. Anyway, I think that the current behavior is fine. Probably the
bug report (which is not about a bug) can be closed, too.

Still there might be an issue: Currently, BASIC256 remembers the last
color even if a new program was started using Program->New:
Step 1:
Write a program
 clg
 color clear
and execute it.
Step 2:
Use the new button to start a new program:
 line 10,10,300,10
and execute it. Noting will be drawn as the current color is still set
to CLEAR.
I think this is a bug.

@Ian: We shall postpone the IF-thing after the 1.0 release. I see your
point and basically I am fine with whatever you will finally decide.

Best regards,
Immo

[Kidbasic-devel] Open Bugs

[Immo-Gert B. <imm...@gm...>]

Hi all,

I had a look at the two open bugs.

1) Win98 rainbow example does not work
I could reproduce the issue and found that the newest version (as
made from current dev source) does not have the issue any more. More
details can be found in the bug description. Probably the bug report can
be closed.

2) Concentric circles - What is wrong?
Evidently the bug submitter would like to have circles that are not
filled. Anyway, I think that the current behavior is fine. Probably the
bug report (which is not about a bug) can be closed, too.

Still there might be an issue: Currently, BASIC256 remembers the last
color even if a new program was started using Program->New:
Step 1:
Write a program
  clg
  color clear
and execute it.
Step 2:
Use the new button to start a new program:
  line 10,10,300,10
and execute it. Noting will be drawn as the current color is still set
to CLEAR. 
I think this is a bug.

@Ian: We shall postpone the IF-thing after the 1.0 release. I see your
point and basically I am fine with whatever you will finally decide.

Best regards,
Immo

[Kidbasic-devel] Open Bugs

[Immo-Gert B. <imm...@gm...>]

Hi all,

I had a look at the two open bugs.

1) Win98 rainbow example does not work
I could reproduce the issue and found that the newest version (as
made from current dev source) does not have the issue any more. More
details can be found in the bug description. Probably the bug report can
be closed.

2) Concentric circles - What is wrong?
Evidently the bug submitter would like to have circles that are not
filled. Anyway, I think that the current behavior is fine. Probably the
bug report (which is not about a bug) can be closed, too.

Still there might be an issue: Currently, BASIC256 remembers the last
color even if a new program was started using Program->New:
Step 1:
Write a program
  clg
  color clear
and execute it.
Step 2:
Use the new button to start a new program:
  line 10,10,300,10
and execute it. Noting will be drawn as the current color is still set
to CLEAR. 
I think this is a bug.

@Ian: We shall postpone the IF-thing after the 1.0 release. I see your
point and basically I am fine with whatever you will finally decide.

Best regards,
Immo

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

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

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

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