21 replies to this topic

[huhn_m]

I have some questions that I need awnsered:

1) Do we need comments?
2) Do we need variable spacing (e.g. should the compiler watch for and remove tailing, leading, additional spaces)?
3) Give me one reason why we would need an extra variable type for colors
4) Would you like the compiler to output byteode (e.g. to distribute it)? This would decrease load times and make the transmitted programs smaller by a factor of up to 5 (estimation!).
5) Do you want a Live Interface (LI) that, when the calc is connected to a computer with internet access and LI software, would make it possible to search the web for programs in a common repository and download them automatically to the calc?
6) Who is willing to write this *$"$!& editor?
7) Do you want MLC2 to become a CVS / Community Project after th first full version release? If yes, would you have the time and will to help getting it to the next level?
8) What is more important: Verbose Error output by the compiler or size and speed optimization? (This only affects the compiler! The interpreter will ALWAYS be optimized for speed since it can only catch verry few errors.)
9) Do you want a wiki for documentation (I don't have the time to write it but I could put it on my new server and set it up. You only need to write it). If yes, would you help write it?
10) Will you download the Beta even it is, in its current state useless for actuall development?
11) Do you have the need for a PC Compiler and Interpreter?
12) If yes, would you write one? I would give you all the needed specs!

I hope many of you will anwser these questions! This project relies on your help. (At least I would like to get some encouragement from time to time )

[Marco]

1) No. Who would comment his programs? On such a small calc, it was a waste of memory, and as it's uncomfortable to type in things, no one will make comments (I also don't know any Casio Basic program with comments altough they support it)

2) YES!! Every compiler should do so, else coding gets quite uncomfortable. Just ignore all multiple space and line break chars, except in strings.

3) No reason, just make it an integer. An additional type would complicate things where it isn't necessarry (I'd also advice against color constants like cl_white and so on; who would use them?). The programmers should take care for theirselves that the var's value doesn't exceed color range. --> Keep it simple, as simple as possible, but not simpler (A. Einstein)

4) Yeah. As it produces bytecode anyways, this feature would be easy to add and very usefull

5) No. Too complicated (in programming and also in use), no one would use it. You would waste your time and memory on the calc for a useless feature

6) Dunno

7) What is a CVS / Community Project?

8) Error output, because no programmer can use a compiler which is damn small and fast, but doesn't show you the errors proper. Most time the compiler will be used is when a MLC programmer is in developing a program, and he will make LOTS of mistakes. But once you have a bytecode of the ready program, you need not to compile again (see point 4) so speed does'nt matter that much but error output is very important

9) Yes. No.

10) Maybe or maybe not. But you should distribute some demos with it in the case testers might be not up to write MLC programs

11) Actual not as I'm not up to write MLC programs. But for MLC programmers it would be usefull I think. Indeed MLC is mainly for oncalc - programming, but it's usefull if you can write and test it also on PC if you want, especially test programs you downloaded somewhere on your PC before transmitting them to the calc.

12) No, sorry :-(

[huhn_m]

thanks for the reply.

CVS = Congurent Version System...actually this means that everyone can edit the code and submit his/her changes to an unstable branch in the CVS. This branch is loocked at some time and then stabilized so that a version can be released.

9) yeah ... this is the problem ...

same goes for the editor. I don't know but the editor is nor priority for me so unless someone else helps me I think the betas are all only Proof Of Concept since no external code will be compiled. I am completely against the model with char replacement that was used in MLC1 since it hinders expandability and is not exactly a clean way to code

There is one demo distributed. More are not currently needed because of the limited feature set.

[Deimos]

1) Do we need comments?
I think they would be useful, especially for developenent, and i'd like to see them i final MLC, but it's nothing urgent and can wait.

2) Do we need variable spacing (e.g. should the compiler watch for and remove tailing, leading, additional spaces)?
Nope, i think extra spaces should cause errors, just like in MLC1 (unless removing additional spaces is very easy, then why not? ).

3) Give me one reason why we would need an extra variable type for colors
Color should be of an integer type IMO.

4) Would you like the compiler to output byteode (e.g. to distribute it)? This would decrease load times and make the transmitted programs smaller by a factor of up to 5 (estimation!).
Would be nice to have that, but only as an option selectable in compiler's menu.

5) Do you want a Live Interface (LI) that, when the calc is connected to a computer with internet access and LI software, would make it possible to search the web for programs in a common repository and download them automatically to the calc?
Sounds good, but i have a feeling that it wouldn't work as good in reality Anyway, the idea is nice, and i'd like to see something like this (a flash100 plugin maybe?).

6) Who is willing to write this *$"$!& editor?
Unfortunately i can't offer my help here - i simply lack the skills

7) Do you want MLC2 to become a CVS / Community Project after th first full version release? If yes, would you have the time and will to help getting it to the next level?
It doesn't really matter for me, as long as there is MLC (about helping, answer is just like above).

8) What is more important: Verbose Error output by the compiler or size and speed optimization? (This only affects the compiler! The interpreter will ALWAYS be optimized for speed since it can only catch verry few errors.)
Verbose error output, or better two versions of compiler - developer's version with error warning, and user's version with size/speed optimization.

9) Do you want a wiki for documentation (I don't have the time to write it but I could put it on my new server and set it up. You only need to write it). If yes, would you help write it?
Yes/Yes

10) Will you download the Beta even it is, in its current state useless for actuall development?
Yes, i'm suposed to be a beta tester after all

11) Do you have the need for a PC Compiler and Interpreter?
Not really.

[huhn_m]

thanks for the input.
Comments:
I also think they would be good. In the light of the distributable bytecode
it even makes sense since it doesn't waste space in the final file.

Of course the bytecode can either be saved or directly interpreted from memory without an intermediate file. This is how it works now but it would not be a problem to save the buffers.

I think space removing should be quite easy. It is not a priority right now but eventually it should make it. I simply remove all trailing and leading spaces (should be easy) and all spaces after the space after the actuall command (except it is in a string), what should be more difficult but no hinderance at all!

Hmm ... I don't know but I think you should just look at the error output it does now. I considder this the normal outout (speed and size optimized) and then decide if you really need more information. It is not as if the compiler just said "Error at line x" but it says for example "unknown command at line x" or "integer to big at line x, integers need to be >=0 <= 65536" and so on. I think you should look at the beta and show me different ways of what information need to be presented (e.g. what parameter (number) would be possible but might be quite a slowdown).

The two versions are an option but not really the prefered one.

[huhn_m]

another Question:

How would you like the folowing to be handled by the compiler:

A function (e.g. the #TEXT command) gets a variable (e.g. %varX) passed but in its last pass the compiler finds, that this variable never gets a value assigned. What would you want the compiler to do?

A) Error and abort compile process
Warning and replace the variable with 0
C) Simply replace with 0, no warnings in the compiler, they are messy.
D) Reserve space in the datasegment and initialize with 0 and then read
this data - IMO quite senseless and a waste of memory.

I would prefer the last one. Here is a code example:

%varX=15
#TEXT %varX,10,"Hello World",9

#TEXT %varX,10,"Hello World",9
%varX=14+13

Here the initial value of 0 is used but it makes sense not to replace the variable with 0 since the function might run again and have a different value then.

#TEXT %varX,10,"Hello World",0

this assumes that nowhere in the WHOLE code a value is assigned to varX.

I would greatly advise for version A since this would force coders to write clean code, keeps the memory clean and so on.

[huhn_m]

since nobody seems to be interrested I changed the working mechanism of the program and made it run in a way that frees some runtime memory.

The decission made is D now since it was easiest to implement.

If you don't participate I'll do all the decission making on my own!!!

[burntfuse]

1) Maybe if you have a lot of memory, but I wouldn't recommend them, since they'll just take up a lot of space, and take time to type.
2) At the beginning of lines, yes (to indent functions and stuff). Anywhere else, no.
3) No reason - it should be an int.
4) Yes, as long as you make sure that the format you choose can be easily used with later versions that have different memory allocation, etc. (I had this problem with MLC1)
5) No.
6) Well, considering I don't even have a Casio...
7) Yes!!! I have to admit that I couldn't do any work on it myself, but maybe others could.
8) Verbose output by the compiler. It doesn't have to be complex - just something like "jp z,error_vardoesntexist", and then at error_vardoesntexist would be "ld hl,vardoesntexist_message / jp show_error_message". It wouldn't slow down the execution that way. Besides, no one wants to have to look back at tables of error codes in the manual.
9) Another good idea! If there was a section for MLC1, I'd happily write all of it myself.

[Deimos]

If you don't participate I'll do all the decission making on my own!!!

Sry i didn't reply, but i had to change my motherboard, which got damaged :/
But if the way you chose is easiest to implement, then i don't see why not to use it, at least for the beta.

[huhn_m]

@burntfuse... the wiki is already up and running! feel free to use it.
I'll inform you if my server runs out of traffic or disc space

@deimos: Ok. thats an excuse had the same problem myself roughly a year ago.

!Normal error output (as it is of no) does NOT only contain error codes. Instead it is sth. like. "Parameter is expected to be integer at line" or "function does not need parameters".

All these do not slow down execution at all since they are a compiler thing. The interpreter does only know verry few errors (only stack overflow / underflow and division by zero for now)

[SRM]

Sorry, I had a one week hollyday at skiing. I'm back now.

1) Do we need comments?
I never use them.

2) Do we need variable spacing (e.g. should the compiler watch for and remove tailing, leading, additional spaces)?
I don't relly see the use of it.

3) Give me one reason why we would need an extra variable type for colors.
Nope. As in MLC 1, we should use the integer variable : %color=1 for exemple.

4) Would you like the compiler to output bytecode (e.g. to distribute it)? This would decrease load times and make the transmitted programs smaller by a factor of up to 5 (estimation!).
It is a really good idea for players but not for programmers. I think the best way would be an option in the selecting game menu, like : F1:finalize the project. This would create an other program already compiled. This way, the programmer can still works on it and the player frees space and time. When a project is finished, the programmer should give the two versions of the program. This way, the player can play and can also watch the programming methode to learn about it.

5) Do you want a Live Interface (LI) that, when the calc is connected to a computer with internet access and LI software, would make it possible to search the web for programs in a common repository and download them automatically to the calc?
If you think it's easy to do and to use, why not. Else, don't spend your time. Perhaps you should explain a little more what's your project.

6) Who is willing to write this *$"$!& editor?
i lack the skills

7) Do you want MLC2 to become a CVS / Community Project after th first full version release? If yes, would you have the time and will to help getting it to the next level?
I prefer people to suggest some features and then the selected programmers implement it after a vote. This would avoid bugs. On an other hand, it could be a good idea to show the bytecode to people to help debugging and optimising it. But they would be simply allowed to make suggestions.

8) What is more important: Verbose Error output by the compiler or size and speed optimization? (This only affects the compiler! The interpreter will ALWAYS be optimized for speed since it can only catch very few errors.)
Programmers need a detailled verbose error. However, if the compiling option is implemented, the error searching wouldn't work on already compilled programs.

9) Do you want a wiki for documentation (I don't have the time to write it but I could put it on my new server and set it up. You only need to write it). If yes, would you help write it?
Yes/Yes

10) Will you download the Beta even it is, in its current state useless for actuall development?
Yes, i'm suposed to be a beta tester after all

11) Do you have the need for a PC Compiler and Interpreter?
Yes.

[CrimsonCasio]

0) are you still reading this?
yes

1) Do we need comments?
i used to comment my basic programs while writing them, then strip them out manually afterwards, i think its nice to have the ability.

2) Do we need variable spacing (e.g. should the compiler watch for and remove tailing, leading, additional spaces)?
i dont think its needed, but if its easy go for it.

3) Give me one reason why we would need an extra variable type for colors
i cant

4) Would you like the compiler to output byteode (e.g. to distribute it)? This would decrease load times and make the transmitted programs smaller by a factor of up to 5 (estimation!).
please yes. programmers should have the ability to distribute the source and the bytecode at their descresion, either both or just one as they wish.

5) Do you want a Live Interface (LI) that, when the calc is connected to a computer with internet access and LI software, would make it possible to search the web for programs in a common repository and download them automatically to the calc?
not needed, unless it could interface with the casiocalc filesharing, in which case it would be a nice tie-in.

6) Who is willing to write this *$"$!& editor?
i wish i could

7) Do you want MLC2 to become a CVS / Community Project after th first full version release? If yes, would you have the time and will to help getting it to the next level?
I would prefer it be kept in your more-than-capable hands.

8) What is more important: Verbose Error output by the compiler or size and speed optimization? (This only affects the compiler! The interpreter will ALWAYS be optimized for speed since it can only catch verry few errors.)
verbose.

9) Do you want a wiki for documentation (I don't have the time to write it but I could put it on my new server and set it up. You only need to write it). If yes, would you help write it?
moot, i see theres one up already

10) Will you download the Beta even it is, in its current state useless for actuall development?
unfortunately, no, i dont have the time.

11) Do you have the need for a PC Compiler and Interpreter?
an interpreter at least would be wonderfull.

12) If yes, would you write one? I would give you all the needed specs!
i have neither the time nor ability to do that im am sure

keep up the good work

[huhn_m]

Question:

I'm currently writing the Int to String routine. Do you want the integers to be made always with 5 numbers (like include leading zeros) or do you want them to be always without leading zeros or do you want this to be affected by a flag the MLC2 programmer can set if he wants to have it in his game or not. (All of the three are quite easy to implement)

Also neg. numbers will NOT make it in V0.3 since I didn't have enough time to investigate into them.

[SRM]

I don't see the use of leading zeros. The best is to give the string the length of the int. Exemple :

%1=5
%2=3260
CSTR $1,%1		   //$1="5" is better than $1="00005"
CSTR $2,%2		   //$2="3260" is better than $1="03260"

Huhn_m, you made a mistake in the doc : you wrote CINT at the place of CSTR (at the end of the doc)

[huhn_m]

the sense of the leading zeros is, that it quarantees a certain cursor position and so helps in formating. Also the lowest chiffre in a scoreboard for example would always be under each other.

And no, I didn't exchange them ...

CINT is convert str to int
CSTR is convert int to str

Unless you have another version than me

[SRM]

Ok, so a flag would be the best. Then, everybody is happy. Else, there would be people that like and others that doesn't.


CINT, CSTR : it's in the doc you give with the beta 2. In the command list, samples about CSTR only use CINT... . I don't blame you.

[calculusrunner]

Hey everyone, some of you might remember me from the old MLC board at EPS. I just got an AFX 2.0 off eBay for $20 shipped, so I'll hopefully be able to contribute something (especially if I get around to building a link cable).

My thought on the string is that a flag would be good, but if its easier it might be better to have two commands (CSST for convert to short string and CLST for convert to long string, or something like that). That way programmers wouldn't have to use extra code to set a flag, just use the appropriate command for the appropriate situation.

[SRM]

Welcome.

I hope you won't discourage yourself participating to the project, as lots of people did yet.

[huhn_m]

Hey!

Welcome. Sorry, but the string thing is already coded and is directed at
a Flag solution. Another solution would also be possible anyways. Its just
that the MLC2 code would look like:

#CLST %1,*$String

and the compiler would transalte this to the bytecode:

PUSH *$String
PUSH %1
PUSH cLongOnFlag
SET_FLAG
CSTR

While the short (standard version) would translate to

PUSH *$String
PUSH %1
PUSH cLongOffFlag
SET_FLAG
CSTR

While you are building the link cable you can also use winG100 to test
my releases.

I also found the bug in the FOR loops and corrected it (there was a word written to the bytecode while it should have been a byte and so 00 bytecode was added and since this is the "ADD" command it left the
stack somewhat messy ) However, there also appeared another bug that causes the FOR Loop to terminate (properly!) after about 260 iterations.

I will try to figure this out later.

[SRM]

Good job. It seems it was hard to find.

[huhn_m]

I'm really sorry for the delay.
I caught a cold in the beginning of the last week and though I had much
time at hand I have not written or analysed a singly line in this time.
I had quite a little head ache and felt unable to really concentrate on the stuff.

However, I restarted today, corrected another bug I just found and am still working on 2 things:

Lines don't seem to get drawn using the line command though they do using the rect command (that talks back to the line command). This is strange but should not be such a huge problem to overcome.

More strange and wiered is the problem with the for loops. I sit now nearly 2 hourse in front of this code debugging it and I just can not explain why it is unable to run over the number 153 (thats 99h ... strange coincidence ...). It just seems as if the <to> value get set to 0 at a certain point but I can not explain why since this value is retireved from the MLC2 programs stack and should not change at all ...

However, I'll do further inverstigation.


In the meanwhile I have also done some improvements already that will also come with Beta3R2 although they were originally intended for the Beta4. Beta4 is accordingly delayed for the 1st of April. THen TES IV:Oblivion comes out and I don't know if I want to code this much but I'll try to Beta4 is going to be the first candidate to be actually REALY usable since I want the keyboard system done till then and the other loop kinds. Maybe I'll even include the first grey scale version since I have to send in my notebook as it has a failure and I will code on the PC starting from the last week in march (for an estimated 3 weeks ) .... so bear with me! I do what I can

marcus


PS: I updated the release schedule-.