Project: Cplua
#641
Posted 03 September 2006 - 05:40 PM
#642
Posted 03 September 2006 - 09:19 PM
I'm planning to add a "recent files" list btw
#643
Posted 03 September 2006 - 11:41 PM
#644
Posted 04 September 2006 - 08:27 AM
I don't really have time to implement it in CPLua, but it will be possible to add it in CPLua's new interface (maybe by another person)
#645
Posted 05 September 2006 - 02:28 PM
Welcome back (I'm answering 5 days later because I was in short vacations too).Okay I'm back at home but with some new interesting things
Wow-wow-wow, calm down. I never said that the ui package is not useful. I only said (and I insist) that, in my opinion, it is not as useful as other forumers think. But asume for a moment that I have said loudly: "the ui package is totally unuseful" (I repeat, I never said such a thing). Is that enough to make you "definitely" stop working on CPLua?PAP, if you say that it isn't useful then I will definitely stop working on CPLua
For future LNA developement, based on version 0.9, it is absolutely neccessary to eliminate the memory leakage.CPLua 0.9B should be ready soon, but there are some things I'd like to do before that (the memory problem is still present ).
The first CPLua window is not that bad, but it can always become better. Curious to see what changes you have made.Then I think about some major changes in CPLua's presentation (I never really liked the first window with the Lua logo and I have a better idea )
Centering widgets automatically is not a must; it will be very practical, though. If implemented, I bet that most users will use it frequently.Aaargh. I feel the headache coming. Well, let's see if some other people will ask for it first
#646
Posted 05 September 2006 - 03:41 PM
I was just kidding. But actually, I was not talking about the UI package. It's something else that you asked before, and it's now 100% operational. But I will let you guess what it is until the next releaseWow-wow-wow, calm down. I never said that the ui package is not useful. I only said (and I insist) that, in my opinion, it is not as useful as other forumers think. But asume for a moment that I have said loudly: "the ui package is totally unuseful" (I repeat, I never said such a thing). Is that enough to make you "definitely" stop working on CPLua?
Well, I just found (early in this morning ) where does this bug come from And unfortunately (as I expected) the bug (or should I say the 2 bugs) are in the OS, not in CPLua. I hope I will find a workaround to make CPLua 0.9B work correctly on OS 2.24, before the release of OS 3.0For future LNA developement, based on version 0.9, it is absolutely neccessary to eliminate the memory leakage.
My current problem is that I can't release CPLua 0.9B now as I did for CPLua 0.9A, because there are some new incompatibilities with CPLua 0.8 (and thus people cannot switch between 0.8 and 0.9B as easy as between 0.8 and 0.9A). But I will certainly find a solution
#647
Posted 05 September 2006 - 04:02 PM
I have asked many things in the past, I cannot guess which one has been implemented . I'm dying to know . Tell me, tell me, and tell me .It's something else that you asked before, and it's now 100% operational. But I will let you guess what it is until the next release
#648
Posted 05 September 2006 - 11:09 PM
After a long, long time, DLMfit now runs correctly on the ClassPad again, without any memory error
And it's even faster now than with CPLua 0.8!
I will make a few more tests to see if everything is ok, and then I will be able to release CPLua 0.9B
#649
Posted 06 September 2006 - 02:19 AM
.. go ahead! we're waiting for this Cristmas gift!
#650
Posted 07 September 2006 - 02:09 PM
I will now spend a little time on the "documentation" to complete and reorganize it, because there are a lot of things to say Be patient, it's just a question of hours.
Btw, I'm starting to see the end of my "to-do" list
Most of the last points are only minor or facultative improvements. They are interesting too (e.g: improve the console window, complete the draw package, improve the general interface), but the current state of CPLua is already close of CPLua 1.0
#651
Posted 07 September 2006 - 08:30 PM
I'm proud to see that my DLMFit still serves as a test program. However, DLMFit is not the heavier part of LNA anymore. I think that you should also try DShoot; it's based on Shoot, which is currenty the most heavy method included in LNA, in terms of memory requirements and execution time. Furthermore, don't forget LNAtest, which uses several heavy methods, and compares execution time with that expected (based on CPLua 0.8). You could also run DemoAll (included in LNAdrive), then choose "Run them all" from the menu: it will run all driver programs, including DLMFit and DShoot.Yes!!
After a long, long time, DLMfit now runs correctly on the ClassPad again, without any memory error
And it's even faster now than with CPLua 0.8!
Of course, I will do all these tests as soon as version 0.9B will be available...
Yeaaaah!Okay I think CPLua 0.9B is ready.
#652
Posted 07 September 2006 - 09:05 PM
There are a lot of things to say for this new version. There were several major changes from the previous versions too, thus please read the following notes carefully
1. First (and most important) thing: the memory bug that appeared in CPLua 0.9A has been completely fixed CPLua 0.9B is a lot more stable than CPLua 0.9A!
2. Second (and even important as 1): the format for Lua programs has changed. The new format is close to a standard text format, and can be read more easily than the previous one.
The current versions of CPLua are still able to load sources saved with the old format, but this will probably not be the case with the future versions.
Thus, you should convert your programs to the new format, to be able to use them in the future. To do that, simply open your files and save it. They will be saved into the new format.
3. The format of lua data files has changed too; but this time the old format cannot be used anymore. That means that every files that were created with the IO package of CPLua 0.8, should be created again because CPLua 0.9 (and the future versions) will NOT be able to read it. The function file:create() has changed a little bit too.
4. Here is what PAP has been longing for. Text file support
The IO package now support text files. Those files can be read by CPLua's editor (or even executed as Lua scripts, because it is the same format as Lua source files).
5. The UI Package is (almost) complete. You can now create windows, widgets, notebooks, lineedits, textedits, buttons, multibuttons, dropdownbuttons, radiobuttons, spinboxes, checkboxes, comboboxes, menubars, and toolbars. I only need to create the functions to access the dialog windows (input, message boxes etc).
6. You already saw it in CPLua 0.9A, but there is a new find/replace utility
7. CPLua has been upgraded to Lua 5.1.1. This is just a minor update
8. The file manipulation in the IO package has been improved. Remember that when you were writing in a file with CPLua 0.8, all the data was actually kept in memory by CPLua, and then it was only written when the file was closed. This used a lot of memory. But this is over now, because CPLua does not need to know anymore the size of the whole data to create the file
9. pict.load() can now access the picture directly into the MCS file. It uses a "copy-on-write" system: the data remain in the file if you don't modify it; thus no memory must be allocated. If you try to draw on the picture however, it is automatically copied in memory.
10. There are some new functions.
a. dispose() : This function can be used in the same way as require()... but it does exactly the opposite This is a function that you can use to unload a library when you don't longer need it. If the library is not needed anymore by any of the loaded files, its memory is then free'd
For example, suppose you have a library "lib" that exports a variable 'A':
print(A) -- prints nil require("lib") -- loads A print(A) -- A = ... dispose("lib") -- unloads A print(A) -- prints nilI have a feeling that it could be useful for LNATests
b. dostring() : This function can execute the string given as parameter. For example:
dostring( "print(\"hello!\")" ) -- prints "hello!"c. waitinput() : This function waits for an input (key or pen). It returns a string "key" or "pen" with the corresponding informations.
d. pict.copy() : Just a simple function to duplicate a picture. Sometimes useful
e. difftime(h,m,s) : returns the number of second elapsed since the time h:m:s.
f: table.copy() : It isn't really a "new function", but you must know that it now performs a deep copy by default. That means that if you want to copy a matrix for example, you don't have to call table.copy() for each line. This function accepts a second (boolean optional) parameter; if it is true, the copy is a deep copy; otherwhise, it is a shallow copy.
... I guess that's all.
Oh, and I changed the examples a little bit too Btw if you think about some simple programs that could serve as examples, feel free to post it here and I will add it with the future versions
#653
Posted 08 September 2006 - 08:03 AM
Very good news. Memory problems seem to be eliminated, but not always. I have also some doubts concerning stability. LNA 1.70 does not work as in CPLua version 0.8. I suspect that there is a compatibility problem, due to the new CPLua file format. I will send you a pm explaining the problems in a few minutes.Phew. CPLua 0.9B is finally ready.
Yes! Thank you very much!Here is what PAP has been longing for. Text file support
Oh, no, now I have to do the conversion to all my CPLua files . But I'm not really complaining, I knew that this will happen some day.Thus, you should convert your programs to the new format, to be able to use them in the future. To do that, simply open your files and save it. They will be saved into the new format.
Oh, and a small remark: wouldn't be more practical if difftime(h,m,s) returns time elapsed in h:m:s format (just as LNA's DiffTime works), instead of number of seconds?
#654
Posted 08 September 2006 - 09:19 AM
I don't disagree, but actually there is a standard C function called difftime that returns a number in seconds. I thought it would be better to respect that formatwouldn't be more practical if difftime(h,m,s) returns time elapsed in h:m:s format (just as LNA's DiffTime works), instead of number of seconds?
#655
Posted 08 September 2006 - 04:26 PM
LNA (PAP)
#656
Posted 08 September 2006 - 08:15 PM
I found a memory leak, as follows. Lua 0.8 have the same problem!, but a bit smaller
arr={} n=input() for c1=1,n arr[c1]={} for c2,n arr[c1][c2]=(c1*c2)^2 end end statusbar(collectgarbage("count") waitkey()
good, this small code creates a whole (i know how to operate with sparse matrix) square matrix with dimension n*n that each Aij = (i*j)^2.
Cplua 0.9
n=64 : memory usage:68.3 kb
n=65 : memory usage:118.6 kb the jump, one row+one col = 50kb!!!!
n=66 : memory usage:120.1 kb
maximum memory reached: ~ 121kb with n=67
Cplua 0.8
n=64 : memory usage:63.95 kb
n=65 : memory usage:114.6 kb the jump, one row+one col = 51kb!!!!
n=66 : memory usage:115.8 kb
maximum memory reached: ~ 150kb with n=80
Then, CPLua, duplicates the memory usage on some aplications when it reach 64~68 kb, jumps over 50 kb more!. Orwell, surely you know this, but i hope that it help you to improve the memory "flood" in CPLua.
Don't forget the draw package, it's slower now than 0.8
Thanks in advance, sorry for excesive queries
#657
Posted 08 September 2006 - 08:49 PM
CPLua 0.9 may use a different amount of memory than CPLua 0.8, but there is no leak.
Note: Actually when I worked on the "mat" package for CPLua 0.72, it was to give a way of using less memory for simple matrices. But the problem is that it was a lot slower than using some regular tables
I'm more concerned about the draw package: it's not suppose to be really slower
Can you send me a code that shows the difference in speed?
#658
Posted 09 September 2006 - 02:18 AM
I made another experiment to reach maximum mem. I can generate a 64*192 matrix in 3 parts of 64 square matrix. At least 200 kb must be the maximum. but i can't reach 180 kb without a fatal exeption error or "alloc failed 384->768 , 3380 -4". Lua allocates memory in packages ?.. then when the first package is filled, Lua allocate on the second, and soon?
I'm quite confused. And i need to know at with some precision what are the real limits on CPLua referred to memory usage because I'm started a new project with omegavirus, that will need hard matrix handling.. Seems to be that this week would be of pure and hard benchmarking.
ps: I will send you the code that "lags" with cplua 09, but not in 08. in advance: it uses 44 K of memory!. a lot!, i'm working in a new version that is a faster. but this code is a reference.
#659
Posted 09 September 2006 - 07:33 AM
Yes, approximately. This is rather confortable though, but that's true that the Lua tables use a lot of memory (this is because they actually are hashtables, so it needs a complex structure to be able to quickly find an element by its index inside the table).With matrix algebra there is no problem, i made a library that replaces "in action" nil values by zeros, then i need to store only the non-nil elements, but if . The problem i how much memory are available on the classpad for CPLua? as i said, with a single matrix i can reach 180 kb as top value. CP calculus memory is only 180 kb?
You should re-download CPLua 0.9B, because I made an update yesterday Btw, the value "3380" is the total free memory still available when the error happened. So you were indeed very close to the limit.I made another experiment to reach maximum mem. I can generate a 64*192 matrix in 3 parts of 64 square matrix. At least 200 kb must be the maximum. but i can't reach 180 kb without a fatal exeption error or "alloc failed 384->768 , 3380 -4".
That's correct. If you see a big difference between n=64 and n=65 in your last example, its because some Lua tables have been resized from 64 to 128 possible entries, hence the difference in memory consumptionLua allocates memory in packages ?.. then when the first package is filled, Lua allocate on the second, and soon?
Don't worry too fast. I just discovered something really interesting I'll give you more details laterI'm quite confused. And i need to know at with some precision what are the real limits on CPLua referred to memory usage because I'm started a new project with omegavirus, that will need hard matrix handling.. Seems to be that this week would be of pure and hard benchmarking.
44k is not "a lot of memory" for me Remember that this value also takes the size of the loaded scripts, functions and packages into account, plus all the structures needed by the interpreter to work, not only the data used by the Lua program. A Lua program of approx 2 Kb will require more than 6Kb when it is loaded into the interpreterps: I will send you the code that "lags" with cplua 09, but not in 08. in advance: it uses 44 K of memory!. a lot!, i'm working in a new version that is a faster. but this code is a reference.
#660 Guest_SEUCV_*
Posted 09 September 2006 - 03:48 PM
#661
Posted 09 September 2006 - 07:30 PM
I think I will start to write in my native language here. Nobody will undertand anything, but several people do something similar .el Cplua puede ser utilizado en una casio afx 2.0 plus? otra cosa, como puedo hacer para conseguir el add-in oficial de casio para graficos en 3D y por ultimo, en donde se puede conseguir una nuea version del CAS para mejorar esos errores que ustedes mencionan en otros post. Gracias
#662
Posted 09 September 2006 - 07:42 PM
And I noticed that writing/reading to/from memory is much slower now
#663
Posted 09 September 2006 - 09:31 PM
SEUCV: No es posible instalar CPLua en una algebra FX2 ya que esta dise?ado para la Classpad. Lamentablemente, los errores de CAS no son solventables ahora, ya que esta calculadora no dispone de ROM actualizable. recuerda que ese CAS es un prototipo. Grandes cosas surgen ahora con LUA y las aplicaciones prometen ser poderosas (mas que ninguna calculadora en el mercado). Pero necesitas una Classpad, asi lo he hecho yo. No se si existe un add-in de casio para graficos 3d, pero hay uno por ahi, pero consegui este
3d graph
#664
Posted 09 September 2006 - 10:49 PM
So CPlua es an "an intuitive language", can u talk me about the SDK?
I hope i ve posted in the correct forum
#665
Posted 09 September 2006 - 11:01 PM
I speak spanish too, people, i will answer on spanish,
Bien Cesar, te respondo. CPLua es un lenguaje de programacion bastante potente para la Classpad. Creo que no es logico usar CPLua sin programar . precisamente por ser un lenguaje interpretado, y tener acceso a los codigos fuente. CPLua es muy sencillo, yo aprendi hace 3 meses, y mis conocimientos de programcion vienen de CASIO Basic (lenguaje de la Algebra FX), Fortran 90 y algo de C++ los dos ultimos muy de manera superficial. Entonces estamos iguales... tenemos las mismas maquinas. CPLua es intuitivo, no hay problemas mas alla de no abusar de la calculadora. El SDK es mas poderoso, pero requiere de conocimientos medianamente avanzados de C/C++. es muy practico para proyectos grandes. Creo firmemente en que se debe hacer la escalera.. Basic, Lua, SDK.. o por lo menos en tu caso Lua,SDK. De todas maneras pienso escribir un tutorial de Lua en cuanto tenga algo de tiempo
#666
Posted 10 September 2006 - 01:14 AM
Im sorry Im using the edit option... I'll found this
Lua 5.1 Reference Manual by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, Waldemar Celes will be eough reding that manual or there's something more specific for ClassPad LUA or beginners?
#667
Posted 10 September 2006 - 02:08 AM
I speak spanish too, people, i will answer on spanish,
I think you should answer in spanish and english because is like having a conversation infront of some people and talking to the ear to the person next to you
#668
Posted 10 September 2006 - 03:27 AM
Lua 5.1 Reference Manual by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, Waldemar Celes will be eough reding that manual or there's something more specific fot ClassPad LUA or beginners?
there are the LUA language creators. The manual only explain the syntax of the LUA functions, then, it's for programmers who want know the structure and environment of the LUA language, here is a book, would be useful for you Cesar
#669
Posted 10 September 2006 - 06:40 AM
The answer is yes, definitely. Like any other programming language, you have to read some documentation first, then try simple examples, then read about more advanced Lua topics, then try more complicated axamples. You won't get it in a few minutes, but it is not as difficult as it seems. Your previous experience with programing languages will be helpful.i ve got a very poor knowlegde of programation, c++, or something like that, my only experience with programation was with Visual Basic, but very basic , so my question is: can someone like me use CP lua?
The SDK is another story. You need to know C++, to read the SDK manual, and much more time, but you will be able to write faster programs in the PC, then transfer them on ClassPad.
#670 Guest_SEUCV_*
Posted 10 September 2006 - 02:47 PM
#671 Guest_Seucv_*
Posted 10 September 2006 - 02:49 PM
#672
Posted 10 September 2006 - 03:33 PM
#673
Posted 12 September 2006 - 03:01 AM
you mean the 351 pages book "Programing in Lua"?? or the others in documentation?there are the LUA language creators. The manual only explain the syntax of the LUA functions, then, it's for programmers who want know the structure and environment of the LUA language, here is a book, would be useful for you Cesar
#674
Posted 12 September 2006 - 12:59 PM
you mean the 351 pages book "Programing in Lua"?? or the others in documentation?
Yes, i mean. You can use the official LUA manual on lua.org as a extra support for built in lua packages
#675
Posted 12 September 2006 - 07:51 PM
PD. Should I post my questions here or in a new topic?
#676
Posted 12 September 2006 - 10:08 PM
#677
Posted 12 September 2006 - 10:38 PM
If you have some long questions, it is perhaps better to start a new topic. Then if someone else has the same questions later he will find the answers more easilyShould I post my questions here or in a new topic?
#678
Posted 13 September 2006 - 02:35 PM
I already fixed several bugs (and added a few more memory ), but now I just had a new idea and I'd like to have your opinion:
Currently, doing
require("myLib")is the same as
require("main/myLib")because there is no package in CPLua called "mylib", and thus it searches in the "main" folder if no folder is specified.
I just thought that it would perhaps be easier if CPLua searched in the folder of the file that calls require(). To be more precise:
Suppose you have a folder "Fol" with 2 files A and B.
If the file A requires the file B, you will have to write
require("Fol/B")at the beginning of file A. My suggestion is that
require("B")is equivalent to
require("Fol/B")because A is in the folder "Fol". I think it would be easier if you want to rename folders etc, then you wouldn't have to change all the paths.
Note: if you call require() from a new file (not saved), and if no folder is specified, CPLua would then look in the "main" folder.
Can I have your opinion about this change?
#679
Posted 13 September 2006 - 06:20 PM
#680
Posted 13 September 2006 - 06:32 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users