858 replies to this topic

[Orwell]

Indeed, this is the same bug.
I'm still trying to fix it...

[PAP]

Btw 1: We need a web page to post small programs demostrating a bug, or a strange behavior. We may also post screenshots there. I think that we could use a subdirectory of http://orwell01.free.fr/Release/CPLua/ for that (by your permission, of course).
Btw 2: Ehm, shall we expect version 0.7 today?

[Orwell]

Btw 1: We need a web page to post small programs demostrating a bug, or a strange behavior. We may also post screenshots there. I think that we could use a subdirectory of http://orwell01.free.fr/Release/CPLua/ for that (by your permission, of course).

What about a new topic in CPLua's subforum?

Btw 2: Ehm, shall we expect version 0.7 today?

We do, but there are allways new suggestions at the last minute... (see your post above for example)

[PAP]

What about a new topic in CPLua's subforum?

Won't help. You cannot upload anything here, except for the "File Sharing", but this is not the proper place for that, plus they want everything as *.rar archives.

[Orwell]

It's almost ready
Let me just the time to upload it and write some words about the new features

[omegavirus]

jajajajajaja: Orwell you have us in your hands just waiting for the new version and it seems to be an eternal waiting

[Orwell]

Here we are!

The Add-In and the executable of CPLua 0.7 are available -->here<--.

I already talked about the new features: the interactive mode, the new functions waitkey(), waitpen(), input() etc. Finally I didn't add many other things in this version, except the possibility to evaluate a CAS expression with a given value (basically you can call it like a simple function). The syntax of the new functions is written in the file 'functions.txt'.

Feel free to ask any precision about the program, if you need more information about something; I didn't took time to make a complete documentation about it yet, but it is planned too

It is possible that some new bugs (or crashes...) appear in this version. Please report it here (or in another topic?)... Due to the lack of time I couldn't make any intensive tests, so I'm counting on you to track any bugs

Enjoy

PS: I'd like you to compare the execution speed of this version with the previous ones. Since I changed several things here, it could be slower or faster - I don't exactly know Tell me how it goes...

[unique33]

1) the scroll bar does not work in the output window, for example run the Dromberg program

2) some problems with the font , see the output screen of DRomberg program

3) try :
require("cas")
exp=cas.expr("math.sin(x)")
y=cas.integ(exp,"x")
print(y)

output :
nothing !

maybe I do some thing wrong .

[Orwell]

1) the scroll bar does not work in the output window, for example run the Dromberg program

You're right... I wonder what's happening

3) try :
require("cas")
exp=cas.expr("math.sin(x)")
y=cas.integ(exp,"x")
print(y)

output :
nothing !

maybe I do some thing wrong .

Yup, "math.sin(x)" is not an operation recognized by the cas. You have to use the same operation as in Main mode. The Lua math functions have nothing to do with the cas Just write: cas.exp("sin(x)")

[unique33]

when a program is running , if you press the Menu toolbar (For example)
Fatal exeption error

[Orwell]

when a program is running , if you press the Menu toolbar (For example)
Fatal exeption error

I cannot reproduce that bug
When did it happen?

[unique33]

I cannot reproduce that bug
When did it happen?

I was running the sphsurfg program ! in the middle of execution I pressed the menu toolbar !

[PAP]

1) the scroll bar does not work in the output window, for example run the Dromberg program

Indeed, but it's more than that: if the output is more than one screen, the text doesn't scroll to the last line, and you cannot see the end of the output, either by using the cursor keys or the scroll bar. This bug occurs in the ClassPad, and in the Window$ executable.

2) some problems with the font , see the output screen of DRomberg program

In fact, the problem is in the print function: it used to print its arguments with a space between them. Now it prints a squared box between the printed arguments, but only in ClassPad. The Window$ executable does not have this bug.

math.sign has a bug: math.sign(a,0) should print 0, no matter what the first argument is. Currently it simply returns the first argument, for example math.sign(-2.3,0) yields -2.3. In other words, it acts as if the second argument is a positive number (but 0 is not a positive number). Afterall, all implementations of sign return 0 in this case. I'm not speaking about the Fortran 95 implementation only, I'm speaking about all implementations of this function, in every language I know.

It seems that Lua program execution is slower now. You can see the difference by running my driver program DRK4Rich which solves systems of differential equations. In version 0.61, the first example (a simple differential equation) was solved almost instantly, now you should wait more than 2 seconds. The second example (a system of 2 differential equations) needs more time as well. Unfortunately, I cannot measure how much slower version 0.7 is, but it is certainly slower.

[unique33]

when you open more than 1 program tha tab menu does not cut the extra file name lenght

a suggestion :
it is good to have the break functianality in the fullscren mode , what is your Idea ?

[Orwell]

Indeed, but it's more than that: if the output is more than one screen, the text doesn't scroll to the last line, and you cannot see the end of the output, either by using the cursor keys or the scroll bar. This bug occurs in the ClassPad, and in the Window$ executable.

*Taking his super Bug Exterminator*

In fact, the problem is in the print function: it used to print its arguments with a space between them. Now it prints a squared box between the printed arguments, but only in ClassPad. The Window$ executable does not have this bug.

Got it. It's easy to change...

math.sign has a bug: math.sign(a,0) should print 0, no matter what the first argument is. Now it simply prints the first argument, i.e., math.sign(-2.3,0) yields -2.3. In other words, it acts as if the second argument is a positive number (but 0 is not a positive number). Afterall, all implementations of sign return 0 in this case. I'm not speaking about the Fortran 95 implementation only, I'm speaking about all implementations of this function, in every language I know.

You didn't specify what should happen when you specify '0' as sign argument But it's ok, I'll correct it

It seems that Lua program execution is slower now. You can see the difference by running my driver program DRK4Rich which solves systems of differential equations. In version 0.61, the first example (a simple differential equation) was solved almost instantly, now you should wait 2 seconds. The second example (a system of 2 differential equations) needs more time as well. Unfortunately, I cannot measure how much slower version 0.7 is, but it is certainly slower.

Okay, I will try some other settings

when you open more than 1 program tha tab menu does not cut the extra file name lenght

I know, but it's a headache... I'll see it later.

a suggestion :
it is good to have the break functianality in the fullscren mode , what is your Idea ?

Normally the "ESC" key is supposed to break the program too. But I said "normally"...

[PAP]

when you open more than 1 program tha tab menu does not cut the extra file name lenght

Indeed. Open any file, then open DRomberg (or any file with 8 characters) to reproduce this bug. The first time you open it, the tab is smaller than it should, and extra text appear in the nearby tabs. If you open more files, however, and you change the editor view to another tab, the screen seems to be refreshed, and everything is ok.

I have a feeling that this night will be long...

[unique33]

this time I was not in the middle of running a program !
I have opened a file without saving it , I pressed the menu toolbar and I recieved the fatal ....
it asks for saving the changes . but it does not take time that the fatal .... appear !

[Orwell]

Indeed. Open any file, then open DRomberg (or any file with 8 characters) to reproduce this bug. The first time you open it, the tab is smaller than it should, and extra text appear in the nearby tabs. If you open more files, however, and you change the editor view to another tab, the screen seems to be refreshed, and everything is ok.

I know, I know... But this is PEG's fault, not mine

> Unusable scrollbar: fixed
> Character problem with print(): fixed
> math.sign(): fixed
> problems when plotting a lot of points: problem catched
> fatal exception when clicking in the menu bar: not seen yet

I have opened a file without saving it , I pressed the menu toolbar and I recieved the fatal ....

What do you call "the menu toolbar" exactly?
The menu at the top of the window or the "menu" key at the bottom?

Okay so I think I see... Give me 5 minutes

[unique33]

I mean the "menu" key ate the bottom , excuse me because of my English

[PAP]

this time I was not in the middle of running a program !
I have opened a file without saving it , I pressed the menu toolbar and I recieved the fatal ....
it asks for saving the changes . but it does not take time that the fatal .... appear !

I'm trying to reproduce this, but I cannot get any fatal error yet.

math.table works as it should, by the way. Even in tables similar to what in other languages is called "lists", such as {1,2,{3,4},5,{6,7,8}}.

Interactive mode has the same scrolling problem: If you enter several expressions, and you need more screen space, then game over...

[unique33]

Cplua -> new file -> open more than 1 file (or maybe more tha 1 new file)-> press menu key

[PAP]

Cplua -> new file -> open more than 1 file (or maybe more tha 1 new file)-> press menu key

unique33 has right. Open 3 files, then press Menu: Fatal exception error.

[Orwell]

unique33 has right. Open 3 files, then press Menu: Fatal exception error.

I'm tracking the error for 15 minutes, but it's like the problem that I had with the CAS: try/crash/init/transfer/retry/crash/....

[PAP]

I'm tracking the error for 15 minutes, but it's like the problem that I had with the CAS: try/crash/init/transfer/retry/crash/....

Oh, the same headache. Wish you will have courage for this. As I said, the night seems to be looooong.

[Orwell]

Wow, it seems that I corrected the error while tracking it
I think that I let something unclear by mistake and it seems that the SHC compiler didn't like it too much It should be ok now

Edit: PEG's stupid bugs again
The error appears again when I remove my debug instructions >_<

[unique33]

It,s good to have an exit menu option for Cplua , the close menu does not work at the start up screen! it just work in the new file and Interactive .
have you worked on it yet ?

[Orwell]

It,s good to have an exit menu option for Cplua , the close menu does not work at the start up screen! it just work in the new file and Interactive .
have you worked on it yet ?

You can notice that all ClassPad applications have a "Close" option in the menu of their main windows, and actually it never close it...
There is no (supported) way to return to the main menu without a press to the "menu" key

[Orwell]

I need to go to sleep now - this night won't be that long...
I didn't find the bug yet but I can give you a temporary version that does not crash... But you will have a message box each time you close a file (yes, opening this box makes the bug disappear).

Good night

[unique33]

what is your Idea about pressing ESC key instead of K_EXE to return to the editor window , K_EXE needs the hand , but ESC key doesn,t need .
I think it,s more easy !

have a nice night .

[PAP]

Recent bug-hunting news (temporary 0.71 version):

I'm afraid that the "unusable scroll bar" bug has not been completely fixed. DRomberg works now, but only because it prints 2-screens text length. If the output is more than that, the bug remains. To reproduce it, try this:
A={}
for i=1,100 do
A[i]=math.random()
print(i,A[i])
end
You will see that you can only scroll down half a screen, and you can see the output until i=46. After that, you don't see anything, including, of course, the "Press EXE..." message at the end. Be aware that a simple loop such as
for i=1,100
print(i)
end
works as expected, and you can see all the output, although the output has the same rows, as the previous example. Really strange. The bug has probably something to do with printing wide lines, because this loop:
for i=1,100
print(i,i,i)
end
or this one:
for i=1,100
print(math.random())
end
do not print all output either.

Furthermore, if the output needs more than one screen, you can only see the first screen, and the rest cannot be seen until the program ends execution. This is not a exactly a bug, but it is really annoying, since you cannot see what the program prints right now. In version 0.61, the screen scrolled down during execution, so that the last line in the screen was the last output.

The Window$ version has a strange behavior, concerning the "Save changes" window. This window is somewhat messed up, plus it has strange buttons: sometimes it has only 1 button ("OK"), sometimes 3 buttons ("OK", "Cancel", "Retry"). The ClassPad vesion always has 3 buttons: "Yes", "No", "Cancel".

If a file is modified, and you try to close it, then you press "No" in the "Save changes" window, you will get a fatal error. This happens only if this file was previously saved, then modified. It does not happen if you close a new file which is not saved yet. You probably already know this, but, if you don't, it may help to track the fatal error bug.

I got a very strange behavior, concerning the editor's menu. I was editing a program, and suddently I was not able to press any menu item (I tapped on menu items, but nothing happened). I was thus forced to close CPLua to escape. However, I cannot reproduce this bug. It happened once, and that's all.

Program execution is still slower than version 0.61. I don't know if you changed some settings in this temporary version, however.

I have changed all LuaNumAn programs. They now use table.copy and math.sign, whenever appropriate. Everything works as expected, and the output is exactly the same, as before .

print works as expected now, but it adds 3 spaces between printed arguments. If I remeber well, previous versions added 2 spaces. Anyway, as I already said, a function for formatted printing, such as my Lua function Printf (included in LuaNumAn) should be added (I think that it's easy to add such a function, since it is quite similar to the C's function printf).

[Orwell]

I'm afraid that the "unusable scroll bar" bug has not been completely fixed.

I think I got it now: the console window is currently limited to 1000 characters, that's why there is no output after a while
I'll find a trick to avoid it.

The Window$ version has a strange behavior, concerning the "Save changes" window. This window is somewhat messed up, plus it has strange buttons: sometimes it has only 1 button ("OK"), sometimes 3 buttons ("OK", "Cancel", "Retry"). The ClassPad vesion always has 3 buttons: "Yes", "No", "Cancel".

That's right, I already observed that, but I have absolutely no clue about what's happening
I think that it appeared after I tried to change some settings in the project configuration of Visual Studio, I will create a new project file for CPLua to see if the problem is still there.

If a file is modified, and you try to close it, then you press "No" in the "Save changes" window, you will get a fatal error. This happens only if this file was previously saved, then modified. It does not happen if you close a new file which is not saved yet. You probably already know this, but, if you don't, it may help to track the fatal error bug.

Good point, indeed it will certainly be helpful. Btw, did you notice that the "strange behavior" on the executable only happens with those same files that were previously saved, then modified? Maybe there is a link, but I really don't know how

I got a very strange behavior, concerning the editor's menu. I was editing a program, and suddently I was not able to press any menu item (I tapped on menu items, but nothing happened). I was thus forced to close CPLua to escape. However, I cannot reproduce this bug. It happened once, and that's all.

That's strange... Let me know if it happens again.

Thanks for your reports, I don't have any lessons this afternoon nor tomorrow, thus I will spend some time on tracking those bugs

[Orwell]

All known bugs have been exterminated

The official release of CPLua 0.71 is now available.
By the way, I think I will now give a "Release Candidate" version before releasing a new major version, because of the unavoidable remaining bugs

[unique33]

If you recieve the "Insufficient memory system to run" , then Cplua stop working ang goes back to the Classpad start up menus !
so you will lose all of your work !
Is there any solution to this problem ?

[Orwell]

Does it happen because you have a huge amount of programs and variable in your ClassPad? Perhaps you should free more space and retry

[PAP]

If you recieve the "Insufficient memory system to run" , then Cplua stop working ang goes back to the Classpad start up menus !
so you will lose all of your work !
Is there any solution to this problem ?

I don't think that this is a bug. It happened to me, even in previous version, but the reason was a bug in a Numerical Analysis program that caused a large amount of unecessary computations. Probably, ClassPad runs out of RAM. The only solution to programmer's bugs is saving before executing...

Btw, everything seems to work fine now. I have only noticed that, although scrolling text in large outputs works well, printing in the output window becomes considerably slower. You can see the difference after printing 50 lines of data output or so. Maybe it is due to the workaround for the output limit of 1000 characters. Not really important anyway (afterall, it's a calculator not a computer). The fact that output window seems to work as it should is more important.

Orwell, you have changed the settings you said last night about program execution? I think that my programs run slightly faster than version 0.70. I'm not sure, I'm planning to reinstall version 0.61, measure the execution time somehow (by a chronometer - ClassPad doesn't have time measurement facilities ), then reinstall version 0.71 to see if there is any difference in computation times. But I will try to do this the next days, unfortunately I have a lot of paperwork to do.

[Orwell]

Orwell, you have changed the settings you said last night about program execution? I think that my programs run slightly faster than version 0.70. I'm not sure, I'm planning to reinstall version 0.61, measure the execution time somehow (by a chronometer - ClassPad doesn't have time measurement facilities ), then reinstall version 0.71 to see if there is any difference in computation times. But I will try to do this the next days, unfortunately I have a lot of paperwork to do.

I was going to say that I just tried your "DKrone" program to evaluate the speed of CPLua 0.71
You were speaking about "less than 8 seconds" when you presented it, and I count ~6 seconds of execution with the last version

I have only noticed that, although scrolling text in large outputs works well, printing in the output window becomes considerably slower. You can see the difference after printing 50 lines of data output or so. Maybe it is due to the workaround for the output limit of 1000 characters. Not really important anyway (afterall, it's a calculator not a computer). The fact that output window seems to work as it should is more important.

Well this happened when I used a standard class for the console window, and not my own I had written a fast method to display text, and CPLua 0.7 is not using it anymore. But i didn't say my last words yet

[PAP]

I was going to say that I just tried your "DKrone" program to evaluate the speed of CPLua 0.71
You were speaking about "less than 8 seconds" when you presented it, and I count ~6 seconds of execution with the last version

Yes, "DKrone" can be used as a nice benchmark, because it does plenty of computations . However, I have improved the library "Krone" 5 days ago. If you used DKrone from LuaNumAn 1.10, the 6 seconds you measured (actually somewhat more than 6 seconds, say 6.5) is the expected computation time in version 0.61. So, we can conclude that program execution remains the same in the new version, as far as speed is concerned. But I'm still not sure, I will need to perform the test again, maybe using a more time-consuming example in DKrone.
Btw, I didn't uploaded the new version of LuaNumAn because I wanted to modify everything for version 0.71 first . It's almost done, I only need to write the documentation for the plotting functions now included in LuaNumAn. If you want to see what decent documentation means, see the pdf accompanying LuaNumAn .

[SoftCalc]

I don't think that this is a bug. It happened to me, even in previous version, but the reason was a bug in a Numerical Analysis program that caused a large amount of unecessary computations. Probably, ClassPad runs out of RAM. The only solution to programmer's bugs is saving before executing...

This is just a polite way of crashing when the ClassPad runs out of memory.

There is a function in the SDK to check the amount of available memory. This is a useful function for example when deciding how big of an array to allocate. If there isn't enough memory you can decide not to solve a problem and return an error, or maybe to solve the problem but with less accuracy.

The SDK function is...
static bool CPWindow::MemoryCheck(unsigned int HeapSize, bool bDisplayError = true, bool bPushToQueue = false);

Maybe this could be useful in CPLua.

[Orwell]

If you want to see what decent documentation means, see the pdf accompanying LuaNumAn .

I did, and I must say that I was impressed
I know that I will have to write a decent documentation for CPLua, but I don't know if I will go that far

In fact, the Lua interpreter allways checks if the memory allocations happen correctly. The problem is that it calls a "realloc" function and then it tests the returned pointer to see if it's valid; and if it is not, an error message will appear in the console window (and the Lua program will be stopped). I suppose that the CP breaks the program during the realloc operation, and that's why you can see this error
I think I will try to add a call to MemoryCheck before the call to realloc.

[Nanard]

orwell: yon can perhaps add a a function to measure execution time (cf http://www.cpsdk.com...wtopic.php?t=63) even if it's not real time units, that could be usefull