858 replies to this topic

[Orwell]

I've seen different different people saying that Basic is too slow, or too limited, not enough extensible etc...
But its main advantage is that you can program it directly on your calculator, you don't need to work on a computer and there is no need of compiler.

I thought it would be cool to have a faster, powerful language which could be used to create games, tools etc... This is why I started to work on this project: a "Lua" interpreter for ClassPad

"Lua" is a "powerful light-weight programming language designed for extending applications".
It is used to create scripts for C applications, which can compile the interpreter and run Lua code.
It is really fast and totally extensible!

All the necessary documentation about the Lua syntax and instructions may be found at www.lua.org and especially in these manuals:
http://www.lua.org/manual/5.0/
http://www.lua.org/pil/
Note: you don't have to worry about the C api. This is my part of the job


I have made an editor for Lua scripts, and I worked on the interpreter to port it on the ClassPad. I added some classPad specific functions like getkey(), getpen(), drawing functions etc. Here is a screenshot of the current sate of this project:



As you can see it uses a smaller font and a tiny keyboard, so you can view a large part of the code on the screen
However if you don't really like it you will be able to change the font and the keyboard (for now, only the keyboard may be changed in the "settings" menu).

I wrote a small sample program, so you can test if it really works (). If you're suspicious, try changing some parts of the code, and run it again!

I'm sorry there are many little display bugs, like when windows are resizing or when you try to open the menu, but well this is just a beta, and they will disappear as soon as possible

Here is the Add-In!

What I need now are your suggestions, comments, and remarks. I suppose you have ideas of new functions to implement, which are not present in Basic and which you would like to be available with this language. I already implement some parts of the standard library: basis, strings, tables, and math functions are currently available.
Here is the list of the ClassPad specific functions for now.

I hope you will really enjoy it, and that there will be many CPLua programmers in the future

Note: I tried to create an editor myself, but it is really complex and I think I won"t have enough time for that... Finally I think I will use a standard Peg Editor

[2072]

"Lua" is a "powerful light-weight programming language designed for extending applications".
It is used to create scripts for C applications, which can compile the interpreter and run Lua code.
It is really fast and totally extensible!

<{POST_SNAPBACK}>

LUA is also used to code World of Warcraft Add-ons

[SoftCalc]

Cool! I'll have to try this out when I get the time.

Can you call the CAS from Lua? Let me know if you'd like to know how to integrate ClassPad commands and functions.

[Orwell]

I can add any function I want, as long as it is possible with the SDK... Thus I can create an equivalent Lua function for each SDK function
I think it will be great to add CAS support, but since I have never used it I will have to see how it works with the SDK first

[PAP]

I tried your Add-In, and my first comment on this project is: WOW!
Felicitations! ("congrats" in french).
Yes, I was suspicious, and I have changed parts of the sample code to see if it really works. It does! It was a piece of cake to define and use a recursive function (without even reading any documentation). Such a thing is common in serious programming languages, but not in ClassPad Basic, which has a very poor function support. In fact, ClassPad Basic is nothing, compared to Lua. Furthermore, a simple browsing of the Lua manual shows that this language has many capabilities. You say that it is only an interpreter language, but, still, it seems to be very fast. Really impressive! This project could improve programming in ClassPad. I really like it, and I will try to give any help I can.

I have several questions/comments/remarks/suggestions. Here we go:
(1) I expected that this project should be a "Language", not an Add-In. CP Add-In installer has an option called "install language". I don't know if it works or not, since ClassPad does not have a similar option in the "Communications" menu. I have never seen a "Language" available for the ClassPad, but this project should be the first one.
(2) Yes, there are many display bugs, but, as you said, this is only a "beta" version. I say that it is a "pre-alpha" version, since you cannot save a program and all changes in the demo program are lost if you exit the Add-In. I think that your first priority should be to implement the ability to save a Lua program somehow. This will permit to the users to try the language and the Add-In, and give you feedback for further developement. Furthermore, it is not possible to select text and cut/copy/paste. This is really annoying. Please, improve the editor as soon as possible, or at least make the built-in editor available during programming in Lua. I was planning to spend my weekend on writing/testing Lua programs in ClassPad. Unfortunately, I can't do it, since I cannot save a program and I cannot copy/paste text...
(3) There are several keyboard problems. For example, the multiplication key works only in the tiny keyboard. The corresponding ClassPad key does not work. Furthermore, most keys in the standard built-in soft keyboard don't work as well.
(4) The fact that the CAS is not supported is a serious limitation. I know that implementing the CAS in CPLua is a really hard work. It will be much harder, since you say that you don't use the CAS anyway. Maybe SoftCalc will be able to help. For me, a fully working CPLua language without CAS support will be marginally useful. However, a Lua language with CAS support can transform ClassPad to a great calculator! If you try to implement the CAS, I may be able to offer testing, and I will really enjoy it. Nevertheless, it will be nice to have a Lua language in ClassPad, even without the CAS support. Many game programmers will like it. Although I didn't bought ClassPad for this, maybe I will try to write a Lua game, just to master the language.
(5) The smaller font is really useful. You can see larger parts of the code in one screen. The tiny keyboard is a nice feature, and it offers the insert/overwrite ability.
(6) The CP-specific function list is short for now, but I'm sure you are planning to add more functions in the list. Let us know!
(5) Can you tell me a website that offers a programmer's guide for Lua, available for download? The links you posted let you download a reference manual, but not a programmer's guide.
(6) Is there a Lua interpreter for <{GNULINUX}> platforms? I want to test Lua capabilities, and I want to do it now! I can't wait for a better Add-In to do this in ClassPad.

Currently, the Add-In is more or less a demo, so I will spend my weekend on reading about the Lua language. Keep up the good work!

[Orwell]

Thanks a lot for your comments

I'm currently working on the editor, there should be a new version soon with more features like selections, copy/paste etc.

I have no other documentations about Lua than the 2 manuals that I mentioned above, but i think it should be enough to understand it correctly... There is also a Wiki and many tutorials, check on www.lua.org to find it

You are right, we need to be able to save our code when quitting the app: I would like to make a system where you can save runnable scripts but also some independant global functions that you will be able to call from any script you write

[GameAddins]

I have several questions/comments/remarks/suggestions. Here we go:
(1) I expected that this project should be a "Language", not an Add-In. CP Add-In installer has an option called "install language". I don't know if it works or not, since ClassPad does not have a similar option in the "Communications" menu. I have never seen a "Language" available for the ClassPad, but this project should be the first one.

Unfortunately the add-in language support on ClassPad is for different localizations (e.g. Dutch, Austrian etc.).

[SoftCalc]

I can add any function I want, as long as it is possible with the SDK... Thus I can create an equivalent Lua function for each SDK function 
I think it will be great to add CAS support, but since I have never used it I will have to see how it works with the SDK first 

<{POST_SNAPBACK}>

Try using the CPExpression class.

[Orwell]

I spent the day working on the editor...

As I said I decided to use a simple CPEditBox and not my own editor, so there are now selection, cut/copy/paste and undo/redo features. (There are also less display bugs btw )
Unfortunately I couldn't reproduce the "overwrite" option... I will have to see how to do it properly. (SoftCalc, any idea? ) I was also thinking about auto indentation, but that won't be so easy now...

I created my own "Lua" PegFont and added a choice between 3 different fonts (see the settings menu).

The "x" key on the standard keyboard is still not working correctly. I will see that later.

I'm planning to work on the save/load functionnalities now, then I will try to add more features in Lua (like CAS support)

You can download the add-in again to get the newer version.

Here is a new screenshot of the editor:
Before -> After
->
Can you find all the differences?

[PAP]

Good work. Unfortunately, I was away from my computer this week-end, so I have tested the previous (first) CPLua version, together with learning Lua. For this, I have tried several programs on my CP. Lua is definitely an easy-to-learn language, especially if you already know any other language, even Basic. Unfortunately, the reference manual (which is available for download) is not written for a begineer in programming, and I'm afraid that it will disappoint newbies. Not a serious problem, since a begineer will probably try the Basic first. Nevertheless, anyone who has some experience in programming will easily learn how to write Lua programs. I have found that it is easy to define and use recursive, complicated functions (writing the well-known "Tower of Hanoi" algorithm in Lua was a piece of cake). It is also easy to write a game using the CP-specific functions currently supported. If the game is rather simple, it runs remarkably fast, but if you try a more complicated game you will notice the interpreter limitations. Nevertheless, the Lua interpreter is undoubtely faster than the Basic interpreter.

Unfortunately, Lua has only simple mathematical functions, and this only by using the "math" library. Its limited mathematical capabilities reminds me those of C/C++, and I'm not surprised, since Lua is directly related to C. However, If you manage to implement the CAS, there will be no problem. Anyway, my personal opinion is that a mathematical language should be a better selection for a ClassPad Add-In (yes, I have Fortran in mind) --- but I know that this is extremely difficult, and I'm not asking for a CPFortran. I will be more than satisfied with a CPLua version who supports the CAS.

Using the first version, I have encountered some "Fatal exception errors", the CP-version of the "blue screen of death" --- bah, that reminds me the time I used Window$. I wasn't doing anything special when my CP hanged, just running a Lua program. Not a problem, really, considering that I was using the first version. I have downloaded the second version today, and it didn't hanged (not yet, at least). I assume that you adressed stability problems in this version.

The virtual buttons in the "tiny" keyboard are too small and I make many typos, so I switched to the normal keyboard, although the "tiny" keyboard is actually a useful collection of most often used keys. I don't think that I am the only one who likes this keyboard, but finds it difficult to use. It will be nice if you implement a keyboard similar to the "tiny", but larger, even by removing the arithmetic part of the keyboard. But don't spend too much time on this, saving/loading and the CAS are much much more important.

Some remarks concerning the second version:
(1) The "Lua" font is OK, but the "Small6" font looks ugly to me. Several characters are not supported by the Lua font. For example, the CP keys for the most common variables ("x", "y", "z") are producing a "checked square", although the characters are shown correctly if you switch to the normal font.
(2) The Insert/Overwrite switch button doesn't work anymore, but this is a minor problem.
(3) Cut/Copy/Paste capabilities work as expected, even by using the normal keyboard.
(4) Undo/Redo is a very useful feature, although it is restricted to one level (adding more levels will be nice, but I can live without such a thing).
(5) The new version has a "drag-and-drop" capabity, which works as Cut/Paste (although you forgot to say something about it ). However, I think that "drag-and-drop" should be switchable on or off by a menu item, since it may become a problem, especially if you use small fonts.

PS 1: It will be nice if you add CPLua version numbering, so that we can easily refer to the version we have tested.
PS 2: If you implement saving/loading capabilities, you will make the life of beta-testers much easier --- but you already know this...

you don't need to work on a computer and there is no need of compiler.

What's wrong with a compiler? I'm not asking for a compiler, I'm just wonderning about your statement...

[Orwell]

As I said, due to the fact that I now use a standard Text Editor and not my own, there were some useful improvements made like copy-paste etc... But it is slighty less easy for me to customize it as I want I think I could do something if I had the original code from Peg, to see how it works and to adapt it to add overwrite, or to disable drag&drop etc... Maybe I will try to find it though

Don't worry about the CAS, Lua is extensible enough to add it succesfully

About the Lua manual, you're right, I don't find it is really easy for beginners. I think that adding some small examples would be great

Unfortunately there are still some "Fatal exception errors" and I try to find out what happens. Btw there is a huge problem, when you try to use 2 variables like 'var' and 'Var' whose name are very similar. Lua is case-sensitive so there should be no problem, but it leads to crash on the calculator I must find where the problem is but I have no clue about it (there are no bugs on the computer version)

Some remarks concerning the second version:
(1) The "Lua" font is OK, but the "Small6" font looks ugly to me.

It is actually ugly, it was just a wink to SoftCalc who created this font I didn't plan to let it in the future versions

Several characters are not supported by the Lua font. For example, the CP keys for the most common variables ("x", "y", "z") are producing a "checked square", although the characters are shown correctly if you switch to the normal font.

There are two solutions: Extand the Lua character set or convert those caracters as more usual ones. But this require customisation of the editor etc... I'll try it though.

(2) The Insert/Overwrite switch button doesn't work anymore, but this is a minor problem.

See above

(4) Undo/Redo is a very useful feature, although it is restricted to one level (adding more levels will be nice, but I can live without such a thing).

Can't do anything about that for now

PS 1: It will be nice if you add CPLua version numbering, so that we can easily refer to the version we have tested.

I will add a cute small 'About' box somewhere

PS 2: If you implement saving/loading capabilities, you will make the life of beta-testers much easier --- but you already know this...

It's almost done, but I was also away this week-end so I couldn't finish it completely. Maybe for this evening... (I hope )

Thanks again for your suggestions and tests

[PAP]

Don't worry about the CAS, Lua is extensible enough to add it succesfully 

If by "adding the CAS" you mean that built-in CAS-related functions and commands will be available in Lua, then CPLua will be a tremendous CP upgrade, not just an Add-In: imagine a Lua implementation that can do symbolic integration, or solve differential equations!
I know I have said it already, but I cannot resist the temptation to say it one more (last) time: A CPLua version that supports the CAS will transform ClassPad to a great calculator!

About the Lua manual, you're right, I don't find it is really easy for beginners. I think that adding some small examples would be great 

I think I can do that. As soon as a version supporting Load/Save is released, I can create a "CPLua examples" topic, and post several examples there, provided that you agree with that, of course...

Unfortunately there are still some "Fatal exception errors" and I try to find out what happens. Btw there is a huge problem, when you try to use 2 variables like 'var' and 'Var' whose name are very similar. Lua is case-sensitive so there should be no problem, but it leads to crash on the calculator I must find where the problem is but I have no clue about it (there are no bugs on the computer version) 

I don't get such problems, at least not in the examples I tried so far, using the current version. For example, the code

x=1 X=2 print(x) print(X)

works as expected. As a case-sensitive language, CPLua seems to store "x" and "X" in separate variables. I'm trying to reproduce the hangs I got using the previous version right now, and see if those hangs are actually related to case-sensitive problems...

There are two solutions: Extend the Lua character set or convert those caracters as more usual ones. But this require customisation of the editor etc... I'll try it though.

Maybe converting to more usual characters is a fast way to solve the problem, at least for now, where many more important things should be addressed...

It's almost done, but I was also away this week-end so I couldn't finish it completely. Maybe for this evening... (I hope  )

I'm really interested on how you will do that. My idea is that Lua code can be stored as a CP text file, peharps into a separate folder, named "CPLua". ClassPad will "see" these files as simple text, but the CPLua Add-In may be able to load and run these files.
Looking forward to see the Load/Save capability implemented. This will speed up testing and debugging. If you finish it today, I'm afraid that I will spend the whole night on testing .

[unique33]

As you know the classpad battery life is too short , so if it is possible please provide an executable one for PC , so the Lua programming will become so easy , thanks

[omegavirus]

As you know the classpad battery life is too short , so if it is possible please provide an executable one for PC , so the Lua programming will become so easy , thanks

<{POST_SNAPBACK}>

If you connect the class pad to the computer whit the USB it does not spend battery

[unique33]

If you connect the class pad to the computer whit the USB it does not spend battery 

<{POST_SNAPBACK}>

yeah , but on pc we have the real keyboard , with the classpad virtual keyboard you can write the program 1 character per second but on the pc more than one character , the copy pase will be so easy on the PC , .... I think all things are easy on the PC . if Lua files will be in the form that we could save them on the pc then transfer it to the classpad it will be so nice ( like the basic language or SDK ) , in this case the programming become so faster !

[Orwell]

You're right, I know an editor on computer would be great...
I will see if I have enough time to do it myself, otherwise I will ask f4 to adapt his Basic editor for the Lua syntax

Sorry to keep you waiting for load/save operations, I was quite busy during these last days, but don't worry it's coming

[PAP]

You're right, I know an editor on computer would be great...
I will see if I have enough time to do it myself, otherwise I will ask f4 to adapt his Basic editor for the Lua syntax

Don't spend too much time on this. An editor on computer would be useful, but I think that, for now, the current CPLua editor is OK, provided that the small problem that occurs when switching the keyboard on/off will be fixed.

Sorry to keep you waiting for load/save operations, I was quite busy during these last days, but don't worry it's coming

Take your time, we are waiting, although we need the load/save operations desparately .

I encountered a bug these days: I was modifying a simple Lua program that draws circles in the screen iteratively (using auxiliary functions). Suddently, I was not able to run the program, because the interpreter complained about a missing right parenthesis ")" in the first code line. However, the first line was

function DrawCircle(x,y,R,w)

that is, it was syntactically correct. I have checked the whole program thorougly, and I'm sure that everything was correct. Trying to figure out what happened, I decided to cut all the code, then paste it again. After that, a "Fatal exceprion error" occured when I tried to run the program. I suspect that the code I was seeing in the screen was not the code actually stored in the editor --- that is, maybe there is an editor bug that occurs after heavy editing. Unfortunately, I'm not able to give you the code (you know why... no load/save operations yet )

[Orwell]

provided that the small problem that occurs when switching the keyboard on/off will be fixed.

Erm... can you remember me what it was about? I can't find this problem anymore...

I encountered a bug these days: I was modifying a simple Lua program that draws circles in the screen iteratively (using auxiliary functions). Suddently, I was not able to run the program, because the interpreter complained about a missing right parenthesis ")" in the first code line. However, the first line was

function DrawCircle(x,y,R,w)

that is, it was syntactically correct. I have checked the whole program thorougly, and I'm sure that everything was correct. Trying to figure out what happened, I decided to cut all the code, then paste it again. After that, a "Fatal exceprion error" occured when I tried to run the program. I suspect that the code I was seeing in the screen was not the code actually stored in the editor --- that is, maybe there is an editor bug that occurs after heavy editing. Unfortunately, I'm not able to give you the code (you know why... no load/save operations yet )

<{POST_SNAPBACK}>

This is annoying... we will make different tests with it later to find out what's happening

[Orwell]

Version 0.4 is finally out

For now we will be able to save and load Lua files.
I decided to create 2 different categories: runnable scripts, and global functions. Scripts are saved in a "LuaScrip" directory, and functions are in "LuaFunc". You can set the type of your code when saving it the first time.

The scripts can be executed directly, and it is possible to call some other saved scripts with the "doscript()" function. The interpreter will load the file in the LuaScrip directory and run it. You can also load a global variable with "loadfunc()". The interpreter will load the file once, and add its content to the local functions. Thus every global functions (in LuaFunc directory) loaded with loadfunc will be callable from anywhere inside the calling script

With this system you can create "general purpose" functions and you don't have to copy it everytimes you need it. For convenience, any file saved in the LuaFunc directory should have the same name as the main function inside of it.

Here are some new screenshots:


The Add-in is still available here. I also added the 2 new functions "doscript" and "loadfunc" in the functions list.

I think this system should be very useful. Anyway, if you think you have a better idea, let me know!

[Brazzucko]

Hey this is a Brazilian software, I have hearting something about that by a friend when I was studding in the Rio de Janeiro .

I have a small manual ( that he give to me, but now I don?t remember where I have it ), but it?s in Portuguese ( Brazilian version) .

[BiTwhise]

Exciting project

Might have a closer look at this at some point, when I find time

Good luck on with it!

[PAP]

Erm... can you remember me what it was about?  I can't find this problem anymore...

It occurs when you turn off a normal keyboard: The bottom part of the screen is not updated (it remains blank, although there is more code to be shown on the screen). But this "bug" does not occur always. I've seen it in version "0.3" several times, but only after some editing time.

Version 0.4 is finally out

Yeah ! Time for testing!
I'll try to write some "heavy" numerical analysis methods in Lua. Such programs make extensive use of auxiliary functions, and will be a very nice test for CPLua. I'll let you know as soon as I have something to say about this...

[PAP]

Well, maybe I was to hasty, concerning heavy numerical analysis testing...
There is a serious bug concerning the normal keyboard in version 0.4: In fact, everytime I try to switch on a normal keyboard, CPLua crashes with an ugly and hated "Fatal exception error" . Furthermore, when that happens, all functions and programs currenlty edited are lost, even if you have saved them .
Tiny keyboard works, but it's very tiny to me, and I cannot write a single command without typos. Since the normal keyboard is now unusable, I cannot write a testing program, as I planned. Pleeease, make the normal keyboard working again...
The bug concerning the blank bottom part of the screen also happened in version 0.4, using the tiny keyboard.

The idea of global functions and scripts is very nice, and it reminds me the aspect of "data hashing", which is heavily used in Fortran 95 programs, and enforces structural programming. However, I don't like the fact that all CPLua functions should be saved to the same folder, and all scripts in another folder. It will be much more convenient to be able to load a function or run a script which is saved to any folder. A CPLua project may include several functions and scripts, and all this stuff should be saved into a separate folder. For example, Cubic Splines Fitting is a separate project, and should be saved to a folder named, e.g., "CubicSpl". Now, this folder should contain both functions and scripts. Furthermore, a project may need a function which is defined in another project. In the previous example, "CubicSpl" needs a function for solving tridiagonal systems, which should be saved in another project (and folder), named "Tridiag", or something like that. A script in "CubicSpl" should be able to load that function, with a command such as loadfunc("Tridiag\TriSyst").
In other words, saving every function in the same folder is confusing (and annoying); the same holds true for scripts. Any folder should contain functions and scripts.
To conclude, I strongly suggest to make the functions doscript() and loadfunc() able to load a file with full path. This will help a lot to organize separate projects. Don't let it as it is now, Lua seems powerful enough to write something serious in a calculator, but nobody wants to save everything in one folder.

[Orwell]

Well, maybe I was to hasty, concerning heavy numerical analysis testing...
There is a serious bug concerning the normal keyboard in version 0.4: In fact, everytime I try to switch on a normal keyboard, CPLua crashes with an ugly and hated "Fatal exception error" . Furthermore, when that happens, all functions and programs currenlty edited are lost, even if you have saved them .
Tiny keyboard works, but it's very tiny to me, and I cannot write a single command without typos. Since the normal keyboard is now unusable, I cannot write a testing program, as I planned. Pleeease, make the normal keyboard working again...

Eeeek
Sorry for the inconvenients, I will see it immediatly.


The bug concerning the blank bottom part of the screen also happened in version 0.4, using the tiny keyboard.

The idea of global functions and scripts is very nice, and it reminds me the aspect of "data hashing", which is heavily used in Fortran 95 programs, and enforces structural programming. However, I don't like the fact that all CPLua functions should be saved to the same folder, and all scripts in another folder. It will be much more convenient to be able to load a function or run a script which is saved to any folder. A CPLua project may include several functions and scripts, and all this stuff should be saved into a separate folder. For example, Cubic Splines Fitting is a separate project, and should be saved to a folder named, e.g., "CubicSpl". Now, this folder should contain both functions and scripts. Furthermore, a project may need a function which is defined in another project. In the previous example, "CubicSpl" needs a function for solving tridiagonal systems, which should be saved in another project (and folder), named "Tridiag", or something like that. A script in "CubicSpl" should be able to load that function, with a command such as loadfunc("Tridiag\TriSyst").
In other words, saving every function in the same folder is confusing (and annoying); the same holds true for scripts. Any folder should contain functions and scripts.
To conclude, I strongly suggest to make the functions doscript() and loadfunc() able to load a file with full path. This will help a lot to organize separate projects. Don't let it as it is now, Lua seems powerful enough to write something serious in a calculator, but nobody wants to save everything in one folder.

<{POST_SNAPBACK}>

This is another possibility, and I thought seriously about it, but I was very disappointed when I saw that ClassPad could not manage subfolders (I had never taken a serious look on it until now ). Thinking about it again, I must agree with your point of view. I will see what I can do

[Orwell]

addKeypad("Standard", m_dummy->Keypad(), false);

	m_dummy = new DummyFrame();

Erm.

New version coming soon

[PAP]

This is another possibility, and I thought seriously about it, but I was very disappointed when I saw that ClassPad could not manage subfolders (I had never taken a serious look on it until now  ). Thinking about it again, I must agree with your point of view. I will see what I can do

Indeed, subfolders are ideal for organizing things (imagine a "central" folder named "CPLua" containing subfolders with different projects). Unfortunately, ClassPad does not support this (I cannot see why). Anyway, organizing projects in different folders (even without subfolders) is much more convenient than having everything in the same folder. Looking forward to see such a thing implemented... I have a feeling that version 0.4 will be short-lived, and version 0.5 will be released soon...

[PAP]

     
Erm.
New version coming soon 

Every programmer makes mistakes (in fact, the only way to avoid bugs is to avoid programming ). I think that I will stay connected. I have another feeling that new version will come very soon...

[Orwell]

version 0.41 is uploaded

I also corrected the bug about the keypad (I hope...)
Let me know If I let some other stupid things somewhere... (and thanks to the Debug mode of my editor )

[PAP]

version 0.41 is uploaded 
I also corrected the bug about the keypad (I hope...)

Normal keyboard works now, but...
(1) The bug about the blank at the bottom of the screen remains (it happens when you switch off any kind of keyboard).
(2) If you change the keyboard type when a keyboard is active, strange things happen. For example, if a normal keyboard is active and you change the keyboard type to tiny, the tiny keyboard works as expected, but the normal keyboard is still active (and cannot be switched off anymore).
(3) The multiplication operator in both the CP keyboard and the Normal virtual keyboards are not working. We already know this, but I now realize that pressing these keys produces a "x" (in "Default" font) while, the multiplication operator is printed as an asterisk (in "Default" font, again). Unfortunately, the asterisk key on the Normal keyboard is not working as well. So, if you want to type a multiplication operator, you must use the tiny keyboard.

I really like the tabs for each opened file. It's easy to switch between them. However, if you try to close a file, you will always be asked to "Save changes", even if the file is not changed after last save. Not something serious, it can remain as it is for now.
Btw, An option to Copy/Duplicate a file will be useful, if it can be easily implemented. The ability to delete or move a file will be very useful as well.

Using the CP variable manager, I have copied a function from the LuaFunc folder to the LuaScrip folder. After that, I can open that function in CPLua from the script folder. In other words, the distinction between function and script folders is more ore less meaningless. I really think that the ability to load and save functions or scripts in any folder is the best choice. Can we expect such a thing soon?

[Orwell]

Using the CP variable manager, I have copied a function from the LuaFunc folder to the LuaScrip folder. After that, I can open that function in CPLua from the script folder. In other words, the distinction between function and script folders is more ore less meaningless. I really think that the ability to load and save functions or scripts in any folder is the best choice. Can we expect such a thing soon?

<{POST_SNAPBACK}>

It's already done...

I'm working on some other "esthetical" bugs, as allways (and I'm starting to get kind of tired of it ). As you said, version 0.5 should come really quickly.

BTW, i started figuring out how to use the CAS with the SDK, and I'm currently thinking about a good way to implement it in Lua (functional or rather object oriented approach?)

[PAP]

It's already done... 
I'm working on some other "esthetical" bugs, as allways (and I'm starting to get kind of tired of it  ). As you said, version 0.5 should come really quickly. 
BTW, i started figuring out how to use the CAS with the SDK, and I'm currently thinking about a good way to implement it in Lua (functional or rather object oriented approach?)

Good news. This project is developping really quickly. Release of version 0.5 will be probably the beginning of my "heavy testing".
About the CAS, the choice is yours, of course, but I 'll rather prefer functional programming. The best choice is "module-oriented" programming, but C++ is not suitable for this. Object-oriented programming has all the reuse, but has also all the abuse .

[Orwell]

Phew, version 0.5 is out. I hope everything will be ok now

As suggested, files can be saved in any directory.
doscript() and loadfunc() both take now an absolute path as argument (like "MyDir/MyFile"). If no directory is written the file is searched in the "main" directory.
As you can think those 2 two functions are quite similar, but don't do exactly the same thing. It is better to use one or other depending on what you want to do.

Here are some new screenshots:


I hope there won't be too many graphical bugs with the keypad from now

The multiplication operator in both the CP keyboard and the Normal virtual keyboards are not working. We already know this, but I now realize that pressing these keys produces a "x" (in "Default" font) while, the multiplication operator is printed as an asterisk (in "Default" font, again). Unfortunately, the asterisk key on the Normal keyboard is not working as well. So, if you want to type a multiplication operator, you must use the tiny keyboard.

This is now solved, as well as with the x,y,z, and EXP keys

[Orwell]

I tried to draw another keyboard, which should be easier to use.
What do you think?

[PAP]

Yes! This keyboad is exactly what I want! It's large enough, and contains most often used keys. Pleeease implement it as soon as possible!

[PAP]

Phew, version 0.5 is out. I hope everything will be ok now 

First of all, I have to say that all bugs reported in previous versions have been vanished . I can tell that after several hours of editing/running CPLua programs. But this is not the only good thing I have to say, not even the most important...

I have finished my first "real" test of CPLua using v0.5. The result is not satisfactory. It is impressive! Here is why:
I wanted to write a CPLua project that implements the "Brent" method. This algorithm finds the root of a function, and is considered as the most stable method for root finding. This algorithm is of moderate complexity, so I think that it is a good choice for a first "real" test. Furthermore, I wanted the code to be neat and structured. I wanted to make extensive use of data hashing (every function should have access to the variables and functions it needs, and nothing else). I also wanted to use optional function arguments, to make the functions involved in the project more flexible. Well, all these goals have been met in CPLua! Absolutely no problem. Everything worked as expected.
The only thing I don't like is that, if you forget to declare a variable as "local" to a function, that variable is considered as "global", so it is accessible from the calling program. This is annoying, since if you forget to declare a variable as local, the data hashing aspect in broken. Imperative declaration of variables as "global" or "local" will be much more prefferable. But this is a Lua problem, and has nothing to do with CPLua itself. Anyway, the ability to write scripts containing local and/or global functions permits to write very structured, "module-oriented" code. I bet that you cannot do such a thing in any calculator, at least not using its built-in programming language. The ability to write such a structured code in ClassPad is impressive at least. It is now possible to implement complex numerical analysis methods in ClassPad! Don't even think to do that in CP Basic.
Conclusion: I think that v 0.5 should be considered as the first CPLua "milestone": it is the first version that permits to implement a complex project. The CAS is not supported yet, but, judging from how fast CPLua is been developed so far, we should expect the first CAS support rather soon. I want to say it loudly: This project rocks!

My plans concerning further testing are as follows: I'll try to implement a very complex algorithm that computes all the roots of a given function within a given interval. This is a difficult problem in numerical analysis, and needs high level Calculus (see my posts about that in "Bug Reports" topic). I've already developed such a project in Fortran, so all I need to do is to translate it in Lua. Its implementation in CPLua will need several recursive functions and sub-projects, and I think that it is a really heavy test. Judging from the results of the first test, I cannot find a reason why this test would fail. Of course, results concerning this test will be posted as soon as they are available...

Aaah, a small (new) bug: If a keybord is active, and the console output is large enough, you see part of the output, as expected. Now, if you scroll down using the scroll bar in order to see the rest of the output, the scroll bar does not work anymore, so you cannot use it to scroll up again. Cursor keys, however, are working as expected. This is probably a bug concerning screen refresh, and it may be easily corrected.

[Orwell]

These are good news for me too

Don't worry about this new bug, it is there from the beginning and I know it well: the problem comes from the scrollbar which is acting really funny. But since I will perhaps change many things in the console window in the future I just let it like that for now

As you said the global/local problem comes from the Lua language and I can't do anything about that...

Thanks for your compliments, but I must say that the biggest part of this work comes from the creators of the Lua language and it's C API I'm especially working on the editor and on some special ClassPad features, so all the merit is not for me... Thanks to them!

[PAP]

Thanks for your compliments, but I must say that the biggest part of this work comes from the creators of the Lua language and it's C API  I'm especially working on the editor and on some special ClassPad features, so all the merit is not for me... Thanks to them!

Well, thanks to everyone involved. Your work up to now is really good, and it will be hard in the future (I have the CAS support in mind), so you deserve a large part of the merit. Afterall, the idea to import Lua in ClassPad is yours!
To be honest, I will never use Lua in my computer, given that Fortran 95 is much more powerful. But in a calculator, Lua seems to be the best choice, and its capabilities are far beyond what you could expect from a calculator programming language...

[Orwell]

Afterall, the idea to import Lua in ClassPad is yours!

<{POST_SNAPBACK}>

Well... no.
mastermage got the idea, long time ago, and he made some tries with it. Unfortunately he had no time to work on it
Recently, after I finished my battleship add-in and came back from hollydays I thought about the idea he had to port the Lua language, and since I knew that he wasn't working on it anymore I decided to see by myself how it could be done. And when I saw that it didn't seem to be so impossible to do, I made more and more tests, had more and more nice results, and here we are
Thanks to him, I had never used this language before and even didn't know anything about it. He got the idea, and I'm glad to realize it

[Orwell]

New keyboard, new version!
v. 0.51 is available

[unique33]

I think I can do that. As soon as a version supporting Load/Save is released, I can create a "CPLua examples" topic, and post several examples there, provided that you agree with that, of course...

please start the topic !

---------------------
Is there any Input statments ? like :
Input
Input Functions
,...
---------------------
please explain about the math.rad function
try this code :

u=math.rad(180)
print(math.sin(u))