858 replies to this topic

[Orwell]

I cant find what's wrong

I'll take a look, thanks for having noticed it.

Orwell, can you build a build-in MyLuaProgram?

I can do that... But does it really have to be "built-in"?
I think it would be possible to do that in Lua (when UI dialogs will be implemented)
The fact is that CPLua is rather large already (more than 400 Kb for the Add-In only), and I'd like to avoid making it too large

[vanhoa]

You think a build-in MyLuaPgrogram make it more and more large?

[Kilburn]

It's not a real priority, just.... gadgets The most important is finishing and debugging the UI package, and I think Orwell must be already very busy... let him make a stable version first before making "lower priroty" requests.

[Orwell]

A built-in MyLuaPrograms would not take much memory (maybe 20~30 Kb?)... but as Kilburn said, there are some other priorities that will take some space too. And I don't have as much time as I want neither
I'm working on CPLua today btw, I hope I will be able to fix several bugs

[vanhoa]

Uhm... Sorry.

[Orwell]

I found what was wrong in vanhoa's code...
Actually he's not using ui.start() and ui.stop() in an appropriate way. I guess I didn't give you enough information about these 2 functions

In the current implementation, when you call ui.start() the application enters a loop and all events are processed inside this loop. When you call ui.stop(), you just set a flag somewhere saying that the loop may break when all events have been handled. Then the call to ui.start() whill stop after the last event.
That means that if you call ui.start() inside an event, you do not continue the initial loop, but you start another loop inside the first one (which is not finished yet since the program is still in an event)!

I said that this loop may be restarted later because I was thinking about something like this:

... -- do some initialisations
b = ui.button{...}
function b:_clicked() ui.stop() end -- tells the first loop to stop when all events have been handled
ui.start() -- enters the first loop
... -- do some other initialisations
b2 = ui.button{...}
function b2:_clicked() ui.stop() end -- tells the second loop to stop when all events have been handled
ui.start() -- enters the second loop

Although calling ui.stop() and then ui.start() inside an event is a very bad idea, it should not cause a crash There is no sense in "stopping" the UI loop inside an event btw, since this loop is already stopped during each event. However it must be possible to enter a second loop inside an event...
I will make some changes on these functions to avoid that kind of problems.

[Orwell]

Okay there was actually another bug in the UI package too, which caused the crash. It shouldn't happen anymore

Concerning ui.start() / ui.stop(): now ui.stop() simply raises an error, which is catched by ui.start(). That means that any instructions written after ui.stop() in an event will never be executed. Thus,

b = ui.button{...}
function b:_clicked() print("a") ui.stop() print("b") end
ui.start()
print("c")

This code will print "a c" and not "a b c" when you press the button, because ui.stop() will immediatly stop the execution of ui.start(). I think it should be less confusing now

[vanhoa]

I know about that but I dont think it is the main problem.

[Orwell]

I said I fixed the other problem too

[vanhoa]

Let me know when you finish.

[Kilburn]

Your reply is very useful...
Did you know that people sometimes may be busy, because they are still studying ?

[vanhoa]

If it is the summer now...

[The_AFX_Master]

Hi guys

This topic seems to be freezed for some time.. Well, i got some news:

Memory benchmarking on OS 3 + CPLUA 0.9D gives me 368Kb of available RAM
the last benchmark that i did with 0.9d and O.S 2.2, gave me 1281Kb, seems to be that O.S 3 knocked out our RAM for now.

Orwell, send me an email to talk more about this when you read this message

Regards

[Orwell]

Well I already knew that for a long time actually... That's why I said not to be too optimist with memory CPLua was using a part of the memory whch was reserved to the OS; now the OS is bigger, and thus there is less unused memory available.
There is still more memory than with the previous versons of CPLua; however 368Kb seems to be a bit low

And sorry for the freezed topic, I don't currently have as much time as I'd like to... But things are still moving

[The_AFX_Master]

Seems to be that i will need a new classpad for heavy tasks !.. btw. Is annoying that we can't install the older O.S again. Anyone know if it is "crackeable", returning to an old O.S?

@ Orwell, nice to see you here again. I was thinking you was abducted by aliens . i need to see less South Park

[PAP]

Memory benchmarking on OS 3 + CPLUA 0.9D gives me 368Kb of available RAM

So, they wasted a lot of memory for... PVM and similar functions?
Btw, AFX_Master, you have paid for OS 3? Traitor!

Well I already knew that for a long time actually... That's why I said not to be too optimist with memory CPLua was using a part of the memory whch was reserved to the OS; now the OS is bigger, and thus there is less unused memory available.
There is still more memory than with the previous versons of CPLua; however 368Kb seems to be a bit low

Orwell, how do you knew that? You too have paid for OS 3?

And sorry for the freezed topic, I don't currently have as much time as I'd like to... But things are still moving

Me too, but things are still moving as well .

[The_AFX_Master]

Btw, AFX_Master, you have paid for OS 3? Traitor!

See your PM box, PAP

Orwell, how do you knew that? You too have paid for OS 3?

Older versions of CPLua has only 180~250 Kb of available RAM. Then, now we have "more" RAM. But afaik, Orwell used a part of the O.S 2.2 RAM with CPLua 0.9d, that gave us the amazing 1 mega ( I'm starting to cry!!!). The new O.S claimed "his" RAM, and ~900Kb are the losts. since the memory was "stolen" to the old O.S. the new O.S is claiming it right now. I don't know if Orwell can steal more memory again.. wait some time

[PAP]

Older versions of CPLua has only 180~250 Kb of available RAM. Then, now we have "more" RAM. But afaik, Orwell used a part of the O.S 2.2 RAM with CPLua 0.9d, that gave us the amazing 1 mega ( I'm starting to cry!!!). The new O.S claimed "his" RAM, and ~900Kb are the losts. since the memory was "stolen" to the old O.S. the new O.S is claiming it right now. I don't know if Orwell can steal more memory again.. wait some time

I know all these things about CPLua memory "stealing" .

[Orwell]

Orwell, how do you knew that? You too have paid for OS 3?

Not at all, but it was important to be sure that CPLua would continue working correctly on OS 3.0. I've just had some interesting contacts

[PAP]

I had a very bad experience with CPLua today. The upcoming LNA version 1.70 includes a function called OrthogonalPoly for performing interpolation by orthogonal polynomials (with error control). Note that this is a rather complicated function, but it is not memory consuming. I decided to rewrite that function for better flexibility. After 2 hours of "heavy" programming, I had a new version of OrthogonalPoly, yielding very satisfactory results. I decided to rewrite the example program for that function, when ClassPad suddently crashed ("Fatal exception blah blah blah") . After recovering, I had a big surprise: All changes where lost, and I have to rewrite OrthogonalPoly from the beggining . Note that, when ClassPad crashed, the file containing OrthogonalPoly was not even open . I was just editing the example program for it.
Conclusions:
(1) There is still a memory leak causing crashes. Unfortunately, it is not easy to reproduce the bug. Just open a file, modify and run it several times. ClassPad will crash, sooner or later, even if the file does not use too much memory.
(2) Saving and closing a modified file does not really save it. When the bug occurs, you lost all changes you have made in the current CPLua session. The only way to avoid data loss is to exit CPLua after saving; only this makes the changes permanent.

[Kilburn]

Saving and closing a modified file does not really save it. When the bug occurs, you lost all changes you have made in the current CPLua session. The only way to avoid data loss is to exit CPLua after saving; only this makes the changes permanent.

Wrong. It doesn't come from CPLua, but from the OS. When your ClassPad crashes, all changes you have made since the last time you turned the CP off are lost. Just turn off your CP and turn it on again to save important changes.

[PAP]

Wrong. It doesn't come from CPLua, but from the OS. When your ClassPad crashes, all changes you have made since the last time you turned the CP off are lost. Just turn off your CP and turn it on again to save important changes.

Nonsense. The most important question is why ClassPad crashes. Please return to your games, I don't think you are able to find why ClassPad crashes.

[Kilburn]

Yeah, maybe you are, and maybe I'm stupid.

And maybe I'm not able to tell why this crash happened, because you didn't tell exactly when CPLua crashed (during execution, or while editing a program ?).
Maybe it's a memory leak, maybe it isn't, what do you know about that, you don't even build C++ add-ins.
It can be everything, a memory leak, an object which hasn't be deleted properly, a segmentation error.

And by the way, I was just correcting what you wrote, because your conclusion was wrong.

Well, I'm going now, let Orwell fix this problem.

[PAP]

Maybe it's a memory leak, maybe it isn't, what do you know about that, you don't even build C++ add-ins.

You are wrong, I know C++, I can build an add-in, but I need to study the SDK, and I don't want to do so. Main reasons: First, C++ is not for mathematical programs, second, I want to write programs in ClassPad, not in the PC; if I want to program the PC, I prefer Fortran 95; it's way more powerful than C++ for my domain of interest.

It can be everything, a memory leak, an object which hasn't be deleted properly, a segmentation error.

Yes, it can be everything, in theory. But I bet it is a memory leak. I was just running a simple program when ClassPad crashed.

[Orwell]

Wrong. It doesn't come from CPLua, but from the OS. When your ClassPad crashes, all changes you have made since the last time you turned the CP off are lost. Just turn off your CP and turn it on again to save important changes.

Nonsense. The most important question is why ClassPad crashes. Please return to your games, I don't think you are able to find why ClassPad crashes.

Well...
Sorry PAP but Kilburn is totally right on that point

And actually he's probably right on the other point too. Such an sudden error has a very low probability of coming from a memory leak. This is most probably due to an erroneous access to the memory, like a segmentation fault or a null pointer exception.
This kind of bug is horrible to fix, because I have to find out what caused the crash and why it did it

But I bet it is a memory leak. I was just running a simple program when ClassPad crashed.

When this makes me say that it is rather not a memory leak
To be clear, a "memory leak" is a situation where some parts of the memory are allocated but never free'd in an iterative process. Then the total free memory constantly decreases until there is not enough free memory for a new allocation, and the ClassPad causes a crash (but in most case the code is protected against this situation, thus even if it happens it will not allways cause a hard crash).

If you see an error with a different message than "insufficient memory", then the cause of the bug is probably not a memory leak. For example a message "TLB Error" means that CPLua tried to access a part of the memory which was reserved to another application (or to the OS), or which had already been free'd. This is generally due to a bad pointer manipulation and is very difficult to track and fix

The best thing to do is to try to find out what was the exact situation when the bug appeared, and how it could be reproduced. Then I will be able to debug the application and see which operation caused the crash.

I'm really sorry for the inconvenience... I'm doing my best to have a very low probability of encountering various crashs and bugs in CPLua, but I don't have enough control and knowledge about the OS to make it equal to zero

[PAP]

If you see an error with a different message than "insufficient memory", then the cause of the bug is probably not a memory leak. For example a message "TLB Error" means that CPLua tried to access a part of the memory which was reserved to another application (or to the OS), or which had already been free'd. This is generally due to a bad pointer manipulation and is very difficult to track and fix

The message I saw was "insufficient memory", then ClassPad crashed. That's why I insist it was a memory leak. The program I was running was rather simple, without big memory demands. The only "special" thing about this program is this: it was printing several messages in the screen (more than 3 screens long in total). In a previous CPLua version, printing long output was problematic, maybe this is the reason for the leak?

The best thing to do is to try to find out what was the exact situation when the bug appeared, and how it could be reproduced. Then I will be able to debug the application and see which operation caused the crash.

Like I said, it's not easy to reproduce the bug. Open a program, modify it and run it several times. It took me 2 hours of programming to encounter that bug. But I know what I'm saying: if you program in CPLua, you will see that bug, sooner or later .

I'm really sorry for the inconvenience... I'm doing my best to have a very low probability of encountering various crashs and bugs in CPLua, but I don't have enough control and knowledge about the OS to make it equal to zero

There is no need to be sorry, however. That kind of things happen in new software still in developement.
Btw, that "really sorry for the inconvenience" reminds me... Window$ XP crashes (something similar is printed ).

[Kilburn]

The message I saw was "insufficient memory", then ClassPad crashed. That's why I insist it was a memory leak. The program I was running was rather simple, without big memory demands. The only "special" thing about this program is this: it was printing several messages in the screen (more than 3 screens long in total). In a previous CPLua version, printing long output was problematic, maybe this is the reason for the leak?

Maybe not. Well, it may be a kind of memory leak. If I remember, this problem happens when many pointers allocated with "new" aren't deleted correctly (or aren't deleted at all).


And, if you know C++, you probably don't know how buggy some fonctions from the CPSDK are. (The built-in linked list class is almost unusable)

[vanhoa]

Orwell, plz add these function to CPLua (a numeric package)

[PAP]

Orwell, plz add these function to CPLua (a numeric package)

Orwell, please don't add these functions to CPLua. It's not even necessary to explain why. Just try to open the rar file.

[vanhoa]

"It's not even necessary to explain why"?

[Orwell]

Orwell, please don't add these functions to CPLua. It's not even necessary to explain why. Just try to open the rar file.

This is the reaction that I was expecting from you
But I guess vanhoa will need some explanations though

[The_AFX_Master]

Simple, Implementing a built-in numerical analysis library is uncommon on a general purpose programming language. Regarding to the Classpad, including that lib will make CPLua more unstable (?), possibly slow, And will throw away the job of PAP developing LNA for us. I see it pretty logic, PAP put effort to do LNA, and the most important.. to put a users guide on LNA (thing that the library that vanhoa is propossing, for sure lacks).

I'm agree in not to put that thing on CPLua.. I thing that memory management & execution speeds are priorities on the beta version of CPLua. To have a well working language interpreter, first debug it, then put on it some apps...

btw: Orwell, what about adding (if it's possible without a lot of work) a communication protocol on CPLua?.. some functions to send and receive data using the calc-to-calc cable?. Some clustering would be amazing.

btw2: How goes CPLua 0.9?

[PAP]

Unless PAP and Orwell are the only two people who use CPLua or read this forum it is necessary to explain why?

Ok, I didn't wanted to say anything about it, but you asked for it....
vanhoa's library has only a few functions which are incomplete, and they are written by a person who admits that doesn't know much (probably nothing) about Numerical Analysis. Furthermore, even if the library was perfect, it hasn't place in a general-purpose programming language, just like The_AFX_Master said. My opinion is that this library will simply consume ClassPad's memory.

Simple, Implementing a built-in numerical analysis library is uncommon on a general purpose programming language. Regarding to the Classpad, including that lib will make CPLua more unstable (?), possibly slow, And will throw away the job of PAP developing LNA for us. I see it pretty logic, PAP put effort to do LNA, and the most important.. to put a users guide on LNA (thing that the library that vanhoa is propossing, for sure lacks).

Hmm, basically I agree with you. However it will not "throw away" LNA, even if it will become part of CPLua. I just don't want to see unecessary (and incomplete) things in CPLua.

[far2055]

I think Orwell said that he is going to make CPLua able to accept user plug-ins. So the best gift that he could give to CPLua users! so there wouldn't be any argument about adding any special library to CPLua.

I think CPLua should stay a general purpose language just as Lua.

[Orwell]

Simple, Implementing a built-in numerical analysis library is uncommon on a general purpose programming language. Regarding to the Classpad, including that lib will make CPLua more unstable (?), possibly slow

I don't think that CPLua would be less stable or slower... However it would need a lot of work to adapt it properly, to test it, to write the documentation... And more annoying: CPLua is already (very) large I'd like to avoid increasing its size for unnecessary stuff

btw: Orwell, what about adding (if it's possible without a lot of work) a communication protocol on CPLua?.. some functions to send and receive data using the calc-to-calc cable?. Some clustering would be amazing.

I've had it in mind for a long time now...

btw2: How goes CPLua 0.9?

Well, my studies are currently more important... But don't worry, I'm not dead yet

I think Orwell said that he is going to make CPLua able to accept user plug-ins. So the best gift that he could give to CPLua users! so there wouldn't be any argument about adding any special library to CPLua.

Hmm... it's not like each user could choose the plug-ins he wants to load into CPLua. What I meaned is that CPLua is now flexible enough to create some new utilities (project manager, on-calc documentation, ...) besides the text editor and the Lua interpreter which are embedded into CPLua (but which are completely different things). And unfortunately the ClassPad does not support dynamic libraries, so all those "plug-ins" must be activated when CPLua is compiled, and you cannot remove them after that And as I said, CPLua is already quite large, so we should avoid adding too much "gadgets" in it

[Kilburn]

And unfortunately the ClassPad does not support dynamic libraries

I was wondering if converting a C function into a byte array (machine language) was possible. I think it is possible, then maybe we could compile libraries for ClassPad.

[vanhoa]

and then you can make your own C language because you have the compile sourcee

[Kilburn]

But ClassPad will take hours to compile a simple "Hello World" program.