858 replies to this topic

[PAP]

By the way, did you succeed in exchanging Lua programs with the computer like a standard Basic program? Or do you plan to release it as a text file? 

As text files? Are you serious?
It is easy to trasfer Lua programs to the computer. As you know better than me, Lua programs are saved as "MEM" variables. They can be transferred to an image file and stored to the computer exactly as every other CP files. Don't tell me that you have never tried this?

From my side I should have finished the "isolation" of the different chunks, and the export function seems to work fine - its syntax has changed a bit, but the result is the same. I would like to add some new features before releasing a new version, this should take one or 2 days.

Since you have decided to implement data hiding using the export function, don't forget to take care about the case I mentioned in a previous post: what happens if you try to export a variable which is declared as local? An easy solution is to simply ignore the "local" declaration, but this is not a good idea ("local" is in Lua syntax, it should play some role even now). It would be better if an error is occured in that case, so that variables or functions not declared as local are, in fact, local, but they can be exported, if you explicitly say so with export. On the other hand, variables or functions declared as local cannot be exported.

Edit: hey what's happening to my "quote" tags?  [/color]

You have probably erased a [ or a / during editing your post . It happens to everybody from time to time.

[SoftCalc]

In case of misunderstanding, I never said that I want to upload CPLua itself, only CPLua programs that I think they might be useful to others. I'm not the developer, I'm only a tester.

<{POST_SNAPBACK}>

Yes, I understood, but having CPLua programs on classpad.org and not CPLua itself doesn't make a lot of sense. When Orwell feels confortable officially releasing CPLua I'll be happy to have Ricky setup a section on Classpad.org.

[Orwell]

As text files? Are you serious?

I just wanted to see your reaction

It is easy to trasfer Lua programs to the computer. As you know better than me, Lua programs are saved as "MEM" variables. They can be transferred to an image file and stored to the computer exactly as every other CP files. Don't tell me that you have never tried this?

In fact I barely never use my ClassPad for simple calculations (I still have my old AFX for that), and I must admit that I never really learned to use it. When I will find more time I will try to read some parts of the manual

[PAP]

I just wanted to see your reaction 

You wanted what? You want my reaction? Here you are:

I've edited my previous post. I've added something about the data hinding thing. I think it's important.

[2072]

I think that it's time to start publish CPLua programs. I tried to do so, but it seems that I cannot, as a forum member, create a new "category" in ClassPad files. There are currently only 2 categories; "Add-Ins" and "Basic programs". Obviously, CPLua programs don't fit to any existing category. I would like to create a new category, "CPLua programs", preferrably with subcategories, such as "Numerical Analysis Lua programs" (this is where I want to upload files), "Lua Games", or whatever. Does anyone know if it is possible to create new categories in the "File sharing" section for ClassPad? If it's not possible, how can I contact a moderator, in order to ask him/her to add such a category in File sharing?

<{POST_SNAPBACK}>

In fact the File Sharing works a bit like the DMOZ internet directory: you upload your file in the most accurate category (in this case it would be "Classpad related files") when sufficient LUA classpad programs will be uploaded, a new category will be created (exceptionally I will create one now) and so on for each sub-category, when enough file matching a single criteria are present then it's interesting to create a special category to regroup them.

It works this way because it's easier to browse the file sharing else you would have to change of category just to see one file etc...

So for now I'll only create a category called "Classpad LUA programs", then if it's needed an administrator will create sub-categories. Because if I create a sub-category called "Numerical Analysis Lua programs" now, the "Classpad LUA programs" category will be empty making surfers loose their time... You see the logic?

[Orwell]

Since you have decided to implement data hiding using the export function, don't forget to take care about the case I mentioned in a previous post: what happens if you try to export a variable which is declared as local? An easy solution is to simply ignore the "local" declaration, but this is not a good idea ("local" is in Lua syntax, it should play some role even now). It would be better if an error is occured in that case, so that variables or functions not declared as local are, in fact, local, but they can be exported, if you explicitly say so with export. On the other hand, variables or functions declared as local cannot be exported.

<{POST_SNAPBACK}>

As I already said it in a post above, I cannot see if a variable has been declared local or not
But when you suggested that all global elements should be automaticaly exported, I answered that there could be a problem if the programmer forgets to add the "local" keyword before the elements that he does not want to export. You told me that the programmer was responsable to take care of that.
What about know? I think it is also the programmer's responsabiliy to not export elements that he declared as local. And even if he does so, since he's asking explicitely to export it, I see no real objection for that. I think the chance that someone attemps to export a local element is quite lower than forgetting the local keyword for something that does not have to be exported...

By the way, I'd like to say now that the syntax of the export function is as follows:

export{ A=a, B=b, ... }

Where a,b are the elements to export, and A,B are their corresponding names in the calling chunk. Of course, it is not really needed to change the names of the exported elements (you can write '{a=a, b=b}' (but never '{a, b}' )), but it is useful in several situations, take a look on the chapter 15 of the book e.g.
There is something other I'd like to do: change loadfunc()'s name to require(). Since I will also add a new feature to it, I find that it is a better name because it doesn't really differ from the Lua built-in function 'require' (which was actually disactivated in CPLua), and it can be used in the same way.

This kind of changes will unfortunately often happen. That's why I don't feel quite comfortable about releasing the program now, because several people will certainly start some new "big" projects, and there will certainly be many incompatibilities between the different versions. As long as I didn't release the "1.0" version, I do not want to care about compatibility with previous versions. I hope you will understand this decision...
It's okay to start releasing Lua programs, but don't forget to write the version of CPLua that was used to create it

In fact, the same goes for the Lua program themselves: like PAP said, for now they are stored as MEM variables in the ClassPad. I'm sure this is not a good idea, and as SoftCalc suggested it I should create a new category for Lua (I don't know which new code to use however ). If I use this new category, all already existent programs will not be editable nor runnable anymore! (that does not mean that i'm unable to write a conversion tool (it's quite easy), but I'd like to avoid the need of such a tool for each new released version )

[PAP]

I think it is also the programmer's responsabiliy to not export elements that he declared as local. And even if he does so, since he's asking explicitely to export it, I see no real objection for that. I think the chance that someone attemps to export a local element is quite lower than forgetting the local keyword for something that does not have to be exported...

In other words, the "local" definition will no longer needed. Everything will be local, unless exported. Thinking of it again, it's better than my idea.

By the way, I'd like to say now that the syntax of the export function is as follows:

export{ A=a, B=b, ... }

Where a,b are the elements to export, and A,B are their corresponding names in the calling chunk. Of course, it is not really needed to change the names of the exported elements (you can write '{a=a, b=b}' (but never '{a, b}'  )), but it is useful in several situations, take a look on the chapter 15 of the book e.g. 
There is something other I'd like to do: change loadfunc()'s name to require(). Since I will also add a new feature to it, I find that it is a better name because it doesn't really differ from the Lua built-in function 'require' (which was actually disactivated in CPLua), and it can be used in the same way. 

The ability to export a function/variable with a different name can be very convenient in some cases. I really like it, I often use the corresponding facility in Fortran 95. Furthermore the name require for the function that loads a chunk is more appropriate. Good news. What the new features of this function will be?

This kind of changes will unfortunately often happen. That's why I don't feel quite comfortable about releasing the program now, because several people will certainly start some new "big" projects, and there will certainly be many incompatibilities between the different versions. As long as I didn't release the "1.0" version, I do not want to care about compatibility with previous versions. I hope you will understand this decision... 
It's okay to start releasing Lua programs, but don't forget to write the version of CPLua that was used to create it 
In fact, the same goes for the Lua program themselves: like PAP said, for now they are stored as MEM variables in the ClassPad. I'm sure this is not a good idea, and as SoftCalc suggested it I should create a new category for Lua (I don't know which new code to use however  ). If I use this new category, all already existent programs will not be editable nor runnable anymore! (that does not mean that i'm unable to write a conversion tool (it's quite easy), but I'd like to avoid the need of such a tool for each new released version  )

Maybe I'll wait for the next version before uploading anything, since I will surely use export and require to fully respect the data hiding aspect.
We all know that a project in developement will surely change, and keeping compatibility with previous versions is a headache. But please, whatever you do, do it in such a way so that we will not loose our programs. It's obvious that we will need to change them to be compatible with newer CPLua versions, maybe we will need to make large changes, but nobody wants to loose his work completely.

[Orwell]

In other words, the "local" definition will no longer needed. Everything will be local, unless exported. Thinking of it again, it's better than my idea.

The local keyword is really useful in several situations; it is just not needed anymore for elements that are visible in the entire chunk.
For example:

x=3
do
 local y=4
 z=5
 print(x)
end
print(y,z)

this will print "3", "nil", and "5" because the y variable is local to the do/end block, so there are no changes here.

What the new features of this function will be?

The built-in libraries (or "packages", I will use this name now) like 'math', 'string' etc were loaded automatically at the beginning of the program, and I've changed it: you have to load it manually in each chunk where you want to use it. For example if you need the "math" package, you must write require("math") before calling it. This is like executing a script that exports the "math" table (except that in this case this "script" is in C and not in Lua), so that means that you can create your own package in a very natural way: write a script that creates and exports a new table "mypack", save it as "mypack" in any directory, then use require() to load it, like the built-in packages. Note that if "mypack" is in the main directory you can simply write require("mypack"), otherwhise you will need to specify its directory: require("mydir/mypack").
Naturally you can export any kind of variable (tables, values, several functions...) but the package system is a nice and clean way to do it

Maybe I'll wait for the next version before uploading anything, since I will surely use export and require to fully respect the data hiding aspect.
We all know that a project in developement will surely change, and keeping compatibility with previous versions is a headache. But please, whatever you do, do it in such a way so that we will not loose our programs. It's obvious that we will need to change them to be compatible with newer CPLua versions, maybe we will need to make large changes, but nobody wants to loose his work completely.

<{POST_SNAPBACK}>

Don't worry, there is allways a solution for this kind of problems

[PAP]

The local keyword is really useful in several situations; it is just not needed anymore for elements that are visible in the entire chunk.

That's what I wanted to say, and that's what I want to see implemented. Of couse, local will still be useful within functions.

The built-in libraries (or "packages", I will use this name now) like 'math', 'string' etc were loaded automatically at the beginning of the program, and I've changed it: you have to load it manually in each chunk where you want to use it. For example if you need the "math" package, you must write require("math") before calling it. This is like executing a script that exports the "math" table (except that in this case this "script" is in C and not in Lua), so that means that you can create your own package in a very natural way

That's also what I wanted to see implemented. I had already a directory called "LuaUtils" and I placed "utilities" there. Btw, "package" is the name that Mathematica uses for exactly the same thing .

[Orwell]

Phew, today I have had to change several things to ensure a perfect isolation between chunks. This is more difficult than one could think

By the way, the doscript() function now takes an optional second argument, which should be a table containing all arguments that you want to pass to the script. This table will appear in the executed script as a table "args".
Let's take an example: this is the called script "test":

require("table")
if(args==nil) then print("no arguments.")
else
print("arguments:")
table.foreach(args, print)
end

And if I call it with

doscript("mydir/test", { x=3, y=5, target="boat" })

this script will naturally print

arguments:
x          3
y          5
target   boat

[Orwell]

I think it's time for a new version. There are several things I'd like to change, but this could take a little time so I give you this one now.
Version 0.6 is available here.

Note that you must now load every package with "require()" before using it.
If you plan to use 'math.sin()' e.g, write "require("math")" at the beginning of the script. The "cas" package is available, but incomplete. It is however already possible to write something like

exp = cas.expr("x^2-3x")
exp2 = cas.expr("sin(x)*x")
exp = (exp / "x^3+1" + exp2)
print( exp:integ() )

But the number of emulated CAS functions is still quite limited. I will see with SoftCalc how this could be done "easily"

Maybe you will also notice that the "Overwrite" mode works correctly, and the line numbers that appear in the error reports are now correct too

If you find any bug or problem, please report it (as allways)

[unique33]

Fatal exception errors :

when using cas package , but as you said it is incomplete yet .

[PAP]

If you find any bug or problem, please report it (as allways)

The data hiding seems to be respected now, at least my first tests show that everything in a chunk is now hidden unless exported (more tests to come soon). For now, I have some remarks and a small (but annoying) bug to report:

(1) The require function applies to the entire chunk. This means that if a function declared at chunk A requires a chunk B then all functions in the chunk A "know" the entities declared at chunk B. This breaks the data hiding (but only slightly, and only in a "per chunk" basis). It would be better if we could load a chunk in a "per function" basis, that is, a require inside a function should affect that function only, so that all other functions in the chunk cannot "see" the entities loaded by require. I realize, however, that this may be difficult to implement, and I can live without such a facility.
(2) The second argument of export does not offer something really useful, as it is now. The name of the exported entities can be changed, but this is done at the chunk that they are defined, not at the chunk that they are used. I think that it would be better if we can export e.g., two entities A and B, with a simple command export{A,B}, then load them with require("chunk name",{C=A,D=B}) so that the chunk that loads A and B knows them as C and D, respectively. This permits to load the same entities into another chunk with different names by using, e.g., require("chunk name",{E=A,F=B}).
(3) The default libraries suppported by Lua contain only very basic facilities. Most of them are almost surely needed to any program, so there is no need to load such simple libraries. For example, the "math" library contains very basic functions, not something special; there is no need to load the "math" library whenever I want to simply compute 2^3 or to compute sin(x); these are elementary calculations and should not be hidden. That is, such basic libraries should be loaded by default (as it was in Lua 0.5). This does not break the data hiding at all. Even Fortran 95, which has a huge vocabulary, does not require loading of the built-in functions. As it is now, it reminds me C, where you have to load a package (or header, whatever it is), just to print something on the screen (#include<stdio.h>). Almost all my chunks start with require("math");require("table"). Furthermore, if you forget to load one of these basic libraries (and you need them), the interpreter responds with an "encrypted" message, and it's not so easy to figure out what happened, at least in the beginning. Anyway, it's nothing serious, although it is annoying sometimes.
(4) There is a small bug concerning the "math" library: This library is supposed to register the exponentiation operator. This is no longer true, due to a bug to CPLua 0.6: The expression 2^3 should be valid, but it isn't, whereas math.pow(2,3) works as expected.

[PAP]

Fatal exception errors :
when using cas package , but as you said it is incomplete yet .

Indeed, require("cas") works, but issuing cas.expr("x") causes a fatal exception error instantly...

[Orwell]

(1) The require function applies to the entire chunk. This means that if a function declared at chunk A requires a chunk B then all functions in the chunk A "know" the entities declared at chunk B. This breaks the data hiding (but only slightly, and only in a "per chunk" basis). It would be better if we could load a chunk in a "per function" basis, that is, a require inside a function should affect that function only, so that all other functions in the chunk cannot "see" the entities loaded by require.

Hey, now this is really exagerated. First of all you you have to remind that if you use the "local" keyword correctly, Lua offers all the needed facilities for data hiding. Just read the entire book, you'll see that it's true. However I agreed with you that this could bring some (rare) problems if the programmer is not careful enough when writing his own libraries, so I did my best to isolate the different chunks. But now you want the "require" command to load the symbols locally in a function?! I designed "require" exactly like the "#include" facility in C/C++, you have to write it at the beginning of every chunk, and it concerns the whole chunk. You said that you realize that it could be difficult to implement, but I'm not sure that you realize how much this could be difficult. Do not forget that this is not obligatory because Lua is powerful enough to permit it without any changes, and that for now you are the only one here wanting that to be implemented.

(2) (...) I think that it would be better if we can export e.g., two entities A and B, with a simple command export{A,B}, then load them with require("chunk name",{C=A,D=B}) so that the chunk that loads A and B knows them as C and D, respectively. This permits to load the same entities into another chunk with different names by using, e.g., require("chunk name",{E=A,F=B}).

First, the way that I implemented it corresponds to the arguments given in Chapter 15 of the book. Second, why are you saying that now ?

(3) That is, such basic libraries should be loaded by default (as it was in Lua 0.5). This does not break the data hiding at all. Even Fortran 95, which has a huge vocabulary, does not require loading of the built-in functions. As it is now, it reminds me C, where you have to load a package (or header, whatever it is), just to print something on the screen (#include<stdio.h>). Almost all my chunks start with require("math");require("table"). (...)

The built-in libraries (or "packages", I will use this name now) like 'math', 'string' etc were loaded automatically at the beginning of the program, and I've changed it: you have to load it manually in each chunk where you want to use it. For example if you need the "math" package, you must write require("math") before calling it. This is like executing a script that exports the "math" table (except that in this case this "script" is in C and not in Lua), so that means that you can create your own package in a very natural way

That's also what I wanted to see implemented.

(4) There is a small bug concerning the "math" library: This library is supposed to register the exponentiation operator. This is no longer true, due to a bug to CPLua 0.6: The expression 2^3 should be valid, but it isn't, whereas math.pow(2,3) works as expected.

Good point, I forgot about it. This is an example of feature that was added as "global" by lua, and that I had to change (difficultly) as local for each chunk.

Sorry for the "fatal error" bug, I will see what's happening.

[PAP]

I cannot understand your offensive stand. I have many things to say:

I agreed with you that this could bring some (rare) problems if the programmer is not careful enough when writing his own libraries, so I did my best to isolate the different chunks. But now you want the "require" command to load the symbols locally in a function?! I designed "require" exactly like the "#include" facility in C/C++, you have to write it at the beginning of every chunk, and it concerns the whole chunk.

Indeed, you did your best to implement isolation of chunks, and I'm satisfied with the result of your work. What I said about the "per function" (not "per chunk") isolation was just a remark. Can I make some remarks or not? I never said that it's very important, and I never said that it is quite necessary to implement it in CPLua. But I'm not exagerating. The "per function" isolation makes the code clearer, it's easy to realize why. But I already said that I can live without it.

You said that you realize that it could be difficult to implement, but I'm not sure that you realize how much this could be difficult.

Don't be so sure. I'm a programmer too, you know. I'm not developing CPLua, you do that, but I'm programming in several languages for years. I think that I can easily realize that "per function" isolation is really difficult to implement.

About the "math", "table" libraries: You are trying to prove that I said I want to load the basic libraries everytime I need them. That's not true. You probably didn't understood what I was saying, or I was not clear due to my poor english, or both. But the fact is that I never said such a thing. Since Lua is directly related to C, the "math" library has only a few, very primitive mathematical functions. Data hiding does not means that even primitive things are hidden. Again, I already said that it's not so important to me. But imagine a new programmer who is trying to write a simple program that computes 2^3 in Lua. He will get an "encrypted" error message. What he will do next? He will realize that the "math" library is needed, or he will be disapointed? I think that he will uninstall CPLua immediately, and he will lose the opportunity to write Lua programs, just because the "math" library is not autoloaded.

First, the way that I implemented it corresponds to the arguments given in Chapter 15 of the book. Second, why are you saying that now ?

First, the book is not the bible, including Chapter 15 . Second, I'm saying that now, because I now realize that it can be implemented in a better way. I'm trying to test everything in time, but I also have other things to do.

Do not forget that this is not obligatory because Lua is powerful enough to permit it without any changes, and that for now you are the only one here wanting that to be implemented.

I know, I know. But I don't like the "you are the only one here" thing. I'm trying to help the developement of the project, simply because I need a powerful programming language on my ClassPad. I think that I have several useful things to say. If I'm bothering you, just tell it. I can stop posting anything if you like. Furthermore, it seems that, unfortunately, only a few people are currently testing CPLua, and posting anything helpful here. Sadly, "the only one here wanting this or that implemented" is very close to "the only one" in general.

Good point, I forgot about it. This is an example of feature that was added as "global" by lua, and that I had to change (difficultly) as local for each chunk.
Sorry for the "fatal error" bug, I will see what's happening.

I have a feeling that we will see version 0.61 soon. It's natural, a new version with big changes has always some ugly bugs burried here and there.

[PAP]

with all the security i tell you that the future of this proyect is the same of SDK...

Although you asked the developer of CPLua, not me, I think that I have something to say, as a CPLua user. The future of this project is definitely different than the future of SDK. Look at the posts here, you will not find anything about games, although Lua can be used for game programming. You are right, most Add-Ins written in SDK are games, and most of them are, indeed, boring games. Until now, CPLua is not used for that. Although there are several things that I don't really like in Lua, such as poor matrix support, it is still a powerful language. I will never use Lua on my computer, but, as far as ClassPad is concerned, Lua is the best programming language you can use so far. In fact, Lua is your only option, if you want to program in ClassPad, because CP Basic is too poor, and cannot even be compared with Lua. The only thing that currently works better in CP Basic is the CAS support, but we hope that this will change in time. Even if the CAS will not finally supported by CPLua, you can still write very useful programs, and the interpreter is remarkably fast. Thanks to Lua, I'm now able to do serious programming in ClassPad. Such a thing is definitely impossible with the built-in basic. I hope that, in time, many ClassPad owners will start to use CPLua, and if they do, they will find that it's now possible to use ClassPad efficiently.

casio dont want to do any new thinks (in my opinion)... or what? we wait a year for a new high resolution screen? of we wait six month for a new OS with only have a Verify function??? were is the CAS evolution? were is the big libary of programs for the classpad??? its imposible to belive that of 100 programs for the classpad, 94 are games, and more, are bad!...

I totally agree. You asked for the CAS evolution? Well, there is no such a thing. You asked for better OS releases? There is no such a thing either. I personally don't expect much by casio, I can easily bet that the next OS releases will be, as usual, useless. I was considering to buy another calculator, until Orwell has started this project.

[unique33]

I converted the html edition of Programing in Lua to the pdf one !
now it is downloadable :

Science.r8.org

[Orwell]

Can I make some remarks or not?

Naturally, and I still need remarks and suggestions from everyone, but the problem is that you are dreaming about a Fortran 95 interpreter (or compiler) for ClassPad, or at least you want an interpreter for a true mathematical language; however Lua is a general purpose language and I have no intention of changing it. Believe me, there will be much more users using Lua to create games or small utility programs than users wanting to implement some numerical analysis routines. Perhaps (and I hope that) there will also be programmers to implement some useful programs for civil engineering, like Fourier Transform calculation etc. However I know that numerical analysis is interesting, and that's why I agree to add some useful features for that. But I don't want to modify the Lua language too deeply. Lua is Lua, not Fortran. Maybe there will be people that already knows Lua and that will be quite interested in CPLua, but they could be a little upset by the way CPLua manages chunks etc.
I think that the Lua language already provides enough features to write proper programs, you just have to use it correctly. I don't take the book "Programming in Lua" as the bible, but it shows many interesting things about that. I know that many programmers will start working in Lua without even taking a serious look on it, that's why I installed a correct isolation between chunks, but hey, from my point of view this should be enough
It seems that you are convinced that C programmers are unable to write their code properly. It is true that it is no allways as clear as possible, but it's not general... C and Lua languages are powerful, but they require an important responsability from the programmer. If you want to write proper code, no problem; if you don't want, no problem neither. This is certainly the reason why you don't like it

Now you propose to use Lua lenguage and with all the security i tell you that the future of this proyect is the same of SDK...

Don't be so sure There are many Basic programmers that do not want to try the SDK because C++ is not an easy language (and this is certainly true), and because they cannot program it directly on their calculator. I think CPLua will seduce them

Finally my question is: Is posible do a Basic to Lua,C to lua, Pascal to Lua, translator???

I don't think it is possible... Those languages are not enough similar for that.

I converted the html edition of Programing in Lua to the pdf one !
now it is downloadable :
Science.r8.org

Nice work!
If you want I can upload it on a better server, so people would not have to wait before downloading it

[PAP]

the problem is that you are dreaming about a Fortran 95 interpreter (or compiler) for ClassPad, or at least you want an interpreter for a true mathematical language; however Lua is a general purpose language and I have no intention of changing it.

Maybe you are right, I surrended to this temptation, just because Lua is expandable enough to simulate at least part of a true mathematical language. I will try to avoid thinking of Lua as a ClassPad Fortran substitute in the future. However, I still think that some of the features of such a powerful mathematical language should be implemented in CPLua, provided that this is not terribly difficult. For example, we have discussed here the implementation of data hiding in CPLua, you agreed to implement it, and, due to your work, it's finally done. I think that the result is an achievement for CPLua. The project didn't lose anything by copying something from another powerful language. I still think that I have something useful to say, concerning the developement of this project, despite the fact that I'm accustomed to Fortran 95, and I may sometimes asking too much.

Believe me, there will be much more users using Lua to create games or small utility programs than users wanting to implement some numerical analysis routines.

Unfortunately, you are right, but, surpisingly, I haven't seen any game programmer posting here, or asking for a feature useful for games. It's strange, there are plenty of them.

However I know that numerical analysis is interesting, and that's why I agree to add some useful features for that. But I don't want to modify the Lua language too deeply. Lua is Lua, not Fortran.

Again, you are right, Lua is not Fortran, and will never be. There is nothing bad on that. Nevertheless, it can be used for numerical analysis programs, I'm doing this already, as you know. Now that the data hiding is respected, the code is much more clearer. I really like it.

I know that many programmers will start working in Lua without even taking a serious look on it, that's why I installed a correct isolation between chunks, but hey, from my point of view this should be enough huh.

Ok, I agree, it's enough. Maybe you could add some mathematical functions, we have dicussed this already, and you said that some of them are not so difficult to implement. For now, I'm adding these functions in a Lua package.

C and Lua languages are powerful, but they require an important responsability from the programmer. If you want to write proper code, no problem; if you don't want, no problem neither. This is certainly the reason why you don't like it

Again, you are right, I don't like this. But I like Lua, because it makes CP programmable.

[unique33]

Nice work!
If you want I can upload it on a better server, so people would not have to wait before downloading it

yes, upload it on a better server . thanks .

[Orwell]

After a lot of tests (try/crash/retry/crash...) I finally found the bug on the "cas" package.
It was a little bit subtle (like most bugs that appear on the calculator and never on my computer), and first I didn't think of that problem at all, but it is ok now
By the way, the "^" problem has been fixed too, and I admit that PAP was not completely wrong when he said that the math package could be loaded by default, so I've changed it
The basis functions, and the "math" and "coroutine" packages are now loaded by default. I didn't find that the "table" package was really required so I didn't change it, but let me know if you think that it should be changed too

Version 0.61 is released.

[PAP]

Version 0.61 is released.

My project aiming to compute of all the roots of a given function within a given interval has been finally completed. The program makes extensive use of recursive functions, and uses a large number of Lua packages (for Romberg integration, Simplified Bisection, together with several utility functions). Due to its complexity, I consider this project as a "heavy" test for CPLua. Well, guess what, CPLua has passed this test succesfully!
CPLua performance in this project is really impressive. For example, the program is able to detect that the function exp(x/3)/2-cos(x) has 14 roots within the interval {-40,4}, and computes all these roots with great accuracy. The computation time for this example is somewhat less that 8 seconds. Perfect performance, considering that the program is running on a calculator, and using an interpreter. The fact that CPLua permits to write such a complex program in a structured, fully modularized code that respects the data hiding is impressive as well. Without CPLua, I couldn't even imagine to implement such a program in a calculator. I know that I said it already, but, after this test, I want to say it again: CPLua rocks!

The basis functions, and the "math" and "coroutine" packages are now loaded by default. I didn't find that the "table" package was really required so I didn't change it, but let me know if you think that it should be changed too

I think that it's perfect, as it is now. There is no need to load the "table" package by default. Afterall, a require("table") on the top of a chunk will inform the user that table operations are used in the current chunk .
A small, unimportant remark: require("math"), is not needed anymore, and, of course, it produces an error in the current version, as expected. The error message is, however "File '/math' not found". It would be nice if this error message can be changed to "Package 'math' is loaded by default". But if this change needs more than 1 minute to be implemented, skip it, it's just for clarity, not important at all.

PS 1: I have also tested the "cas" package. I have several remarks, but I think it's better to post them separately.
PS 2: I would like to post a screenshot of CPLua running the program mentioned above, but I was unable to do this. In the past, I used CP manager for running a program and take a virtual CP screenshot. However, CP manager is expired now, and permits only data transfering. Furthermore, even if CP manager worked, I cannot install the CPLua Add-In in the virtual CP, so I cannot run a CPLua program from the virtual CP. The manual says that you can transfer a "PICT" image to another CP, but says nothing concerning transfering such an image to the PC in a computer-readable format. To post a screenshot here, I need to transfer a "PICT" file from my CP to the computer, then convert it to "JPG" or any other image format. Orwell, you have used CPLua screenshots in several posts. How you did it? I suspect that you used the PC version of CPLua (running via the SDK). If this is true, then you are currently the only one that can post images showing CPLua in action.

[Orwell]

I'm happy that this test was successful, it is indeed a nice proof that CPLua can be used for some quite consistent projects without any problem

About CPLua screenshots: you are right, I am currently working with the Windows version of CPLua. This is very useful to develop the application, and it's quite faster for debugging... It took me a lot of time to find the problem in the "cas" package because it didn't appear on the computer version, and I had to make each single test on the calculator, after reinitializing, retransfering, retyping the test program etc On the computer I can use a real keyboard to enter Lua programs, and when a bug appears the debugger can stop the execution and bring me to the problematic instruction etc

I said that I should perhaps provide the executable together with the ClassPad Add-In, but actually I forgot to do it with the last version And since I'm currently performing deep changes on the console window I think I cannot give you the current executable; it is certainly better to wait for the next release
By the way, concerning your comments about the "cas" package: you certainly noticed that many characters are not displayed correctly in the console window, and this is one of the things I'm working on

[PAP]

It took me a lot of time to find the problem in the "cas" package because it didn't appear on the computer version, and I had to make each single test on the calculator, after reinitializing, retransfering, retyping the test program etc

What a headache. I'm afraid that you will have similar problems in the future, during the developement of CPLua. I hope that you will have the courage to finish this excellent project.

since I'm currently performing deep changes on the console window I think I cannot give you the current executable; it is certainly better to wait for the next release

It's ok for me. I wanted to take a screenshot just to show to anyone interested what you can do using CPLua. We now know that you can do very useful things, why not to show them? I will continue to use the CP version even if you release a computer version of CPLua for two reasons: first, I want to test the real thing, second, it's not so bad to use CP for programming; you can use the stylus to write really fast, it just needs some time to get used to it. A computer executable will be certainly useful, anyway.

About the "cas" package: Running a simple table.foreach(cas,print), I can see that the package currently supports integ, _mt, sum, expr, tostring, prod, add. I'm not sure that I understand what each of these functions do, especially _mt. I also don't know on what extent each of them is implemented. I certainly need some information concerning this package. Nevertheless, integ currently computes only indefinite integrals, as we already know.
Each "cas" function returns a "userdata" variable. I tried to convert it to a Lua expression without success. Such a conversion is certainly needed. Imagine a Lua program that uses the cas to compute an indefinite integral, then the result is used to the definition of a Lua function. I tried something like
function f(x)
local I
I=cas.integ("x^2")
return I
end
and, as I was afraid, i didn't worked: print(f(1)) returns the function as a userdata variable, "x^3/3", and it does not replace x with 1. Thinking that Lua is based on strings, I tried to add I=cas.tostring(I) in the above function, in order to convert the userdata thing to a string; it didn't worked neither. We need a way to convert a cas expression to a Lua expression, something like cas.toLuaexpr. But this conversion is not a trivial task. For example, cas.integ("exp(x/2)") returns "2 e^(x/2)", and this should be converted to the Lua expression 2*math.exp(x/2). What do you thing on this? Is it possible to convert the result of a "cas" function into a Lua expression? If not, I'm afraid that the CAS support will not be useful.

Aaaah, a small mistake (typically, not a bug): The sample program is not working anymore, due to data hiding. If you wish to keep it appear each time you start CPLua, you obviously need to add a require("draw") at the beginning.

[Orwell]

Nothing can stay hidden from you isn't it?

Okay let's start from the beginning. These are implementation details, but well you asked for it
The "_mt" field should never be used explicitely. This is a metatable which is associated to every userdata returned by cas.expr(). If you try table.foreach(cas._mt,print), you will see that it contains a list of typical metamethods: __index, __tostring, __add etc. This is used to define the operations that you can perform on the userdata. For example, if "x" is a userdata returned by cas.expr() and if you try to print it, the metamethod cas._mt.__tostring will be called. The __index field allows you to write x:integ() instead of cas.integ(x), but this is exactly the same operation
Concerning the conversion from userdata to Lua expressions: I can do even better than that With a new "__call" field in the metatable we will be able to call userdatas like any ordinary functions, thus this can be used for evaluating the expression. However this has not been implemented yet, but it's already planned
Behind each userdata is hidden a real CPExpression from the ClassPad SDK; the goal is to provides several bridges from Lua to the services provided by this class. However this class is really difficult to use, and I'm still looking for an easy way to port it in the Lua language

Aaaah, a small mistake (typically, not a bug): The sample program is not working anymore, due to data hiding. If you wish to keep it appear each time you start CPLua, you obviously need to add a require("draw") at the beginning.

Huh? A mistake? What mistake?
If you didn't download the last version so soon you wouldn't have noticed it

[PAP]

Nothing can stay hidden from you isn't it?

Well, yes

Concerning the conversion from userdata to Lua expressions: I can do even better than that With a new "__call" field in the metatable we will be able to call userdatas like any ordinary functions, thus this can be used for evaluating the expression. However this has not been implemented yet, but it's already planned

Excellent. I can't wait to see this implemented. It will be very useful.

Behind each userdata is hidden a real CPExpression from the ClassPad SDK; the goal is to provides several bridges from Lua to the services provided by this class. However this class is really difficult to use, and I'm still looking for an easy way to port it in the Lua language

I know, you already said that SDK is poorly documented, concerning the CAS. But what about the conversion of, e.g., exp(x) to math.exp(x) or ln(x) to math.log(x)? It will be done by the "__call" field, I guess.

Huh? A mistake? What mistake? If you didn't download the last version so soon you wouldn't have noticed it

It is a mistake. Don't tell me that it was correct in version 0.6 and I didn't noticed it?
Anyway, I will try to download a new version as soon as it is available. Then I will try to find a bug, mistake, whatever. Even if there are no bugs, I will ask some questions, if I don't understand something, and/or I will propose new things to be implemented. All these activities are called "help the developer"

[Orwell]

I know, you already said that SDK is poorly documented, concerning the CAS. But what about the conversion of, e.g., exp(x) to math.exp(x) or ln(x) to math.log(x)? It will be done by the "__call" field, I guess.

There is no need to make this conversion: if a CPExpression contains something like "exp(x)", and if I ask it to evaluate the result, it already knows how this must be calculated We are talking about C++ functions here, since we already jumped to "the other side", so calling Lua functions doesn't make sense

It is a mistake. Don't tell me that it was correct in version 0.6 and I didn't noticed it?

I saw it and corrected it after you downloaded the last version. I was hoping that you wouldn't notice it, but you're a too good tester for that

[PAP]

As I already said, I think that it's time to start publishing CPLua programs. I decided to start a topic for the Lua Numerical Analysis library (LuaNumAn) I'm developing. I wanted a fully documented library, because I hate undocumented programs. It took me some time to write the corresponding documentation, but it's finally ready. I've uploaded the first version of this library in the File Sharing. For now, it is just to show what ClasPad is able to do with CPLua . I hope that publishing Lua programs will make more ClassPad users to be interested on CPLua.

[Orwell]

Good news
I don't have much time for now but I will certainly take a look

[PAP]

Ehm, I don't want to be indiscreet, but I have noticed that Kilburn was able to publish screenshots of CPLua programs (actually, games), although I thought that you are the only one who currently can do this. So, my question is simple: how did he get the Window$ executable, since you have never published it? You have probably gave to him the executable privately, or Kilburn and Orwell is the same person, or we have a belgian conspiracy here. Whatever the answer is, I'm a little bit angry .

[SoftCalc]

As I already said, I think that it's time to start publishing CPLua programs. I decided to start a topic for the Lua Numerical Analysis library (LuaNumAn) I'm developing. I wanted a fully documented library, because I hate undocumented programs. It took me some time to write the corresponding documentation, but it's finally ready. I've uploaded the first version of this library in the File Sharing. For now, it is just to show what ClasPad is able to do with CPLua . I hope that publishing Lua programs will make more ClassPad users to be interested on CPLua.

It looks like like there needs to be a CPLua sub-forum.

[PAP]

It looks like like there needs to be a CPLua sub-forum.

Indeed. CPLua is growing up.

[Orwell]

Ehm, I don't want to be indiscreet, but I have noticed that Kilburn was able to publish screenshots of CPLua programs (actually, games), although I thought that you are the only one who currently can do this. So, my question is simple: how did he get the Window$ executable, since you have never published it? You have probably gave to him the executable privately, or Kilburn and Orwell is the same person, or we have a belgian conspiracy here. Whatever the answer is, I'm a little bit angry .

Actually I'm wondering the same thing
I suppose he has drawn those images himself since I never sent the executable...

[PAP]

Actually I'm wondering the same thing
I suppose he has drawn those images himself since I never sent the executable...

Ok, it's not so important. The "Tower of Hanoi" and the 3D graphics had some interest, but only before dowloading the programs. When I saw the code, I realized that the "Tower of Hanoi" simply lets you play the game, and it does not implement the recursive algorithm for solving the problem . The 3D graphics programs are extremely slow to be of any interest .

Ehm, what about a new version with some more CAS supported? Are you working on CPLua now, or you don't have time for this?

[Orwell]

Ehm, what about a new version with some more CAS supported? Are you working on CPLua now, or you don't have time for this?

I'm spending (almost) my whole free time on CPLua 0.7. I didn't made much modifcations on the cas for now because I think that there are some other important features that need to be added (I made an "input()" function e.g ).
Unfortunately university has started again this monday so I can't spend the whole day on it... But there are still the evenings
I think that the 0.7 version will be one of the last version before 1.0

[PAP]

Unfortunately university has started again this monday so I can't spend the whole day on it... But there are still the evenings
I think that the 0.7 version will be one of the last version before 1.0

Indeed, University has started again .
Looking forward to see verison 0.7. Btw, Kilburn claims that his programs are "for Lua 0.64". There is no such a thing. Either he has made a mistake, or I should become very suspicious.

[Kilburn]

Btw, Kilburn claims that his programs are "for Lua 0.64". There is no such a thing. Either he has made a mistake, or I should become very suspicious.

Sorry, I made a mistake. Please, don't be so suspicious!!! The screenshots have been made with the Presentation app. I just erased the status bar with Paint. I could make the algorithm for "Tower of Hanoi", but I don't have time now. And I am just beginning in Lua!

[PAP]

Strange and annoying bug: Consider the following program:

require("table")

function sub(x)
local res
res=x
res1=x1+2
return res
end

local a,b
local foo={7,5}
a=foo
print("foo before calling sub:")
table.foreach(foo,print)
b=sub(a)
print("foo after calling sub:")
table.foreach(foo,print)

The purpose of the function sub(x) is to simply add 2 to the first element of the input table x (it's a useless function, but it is just to show the bug). In this example, b=sub(a) returns {9,5}, as expected. The problem is that, after calling sub(x), the table foo is changed to {9,5}! This is a bug, since the variable foo is not known inside sub(x). In general, foo has nothing to do with sub(x).
Furthermore, if you replace sub(x) with:

function sub(x)
local res={}
res1=x1+2
res2=x2
return res
end


then foo remains unchanged, but b is equal to {7,5}, not to {9,6}, as it should!

I'm afraid that I cannot understand this behavior.