858 replies to this topic

[Orwell]

Is there any change with the Camparition of a number with nil?
the thermodynamic tables contain nil values by deafult and
I should find a way to compare number with nil .

I didn't made any changes about this...

Is there any change in the printf Function?
run my "CATT/PsatV" program to see the error!

Nope, but could you give more details about the problem you have?

Also write a single statement program with the printf function . the "Done"
word will follow the printf and do not go to the next line.

Indeed, by default printf (unlike print) does not add a line feed character ('\n') at the end of the strings, you have to write it yourself

About the Translation:
I Do not know if a Persian font (character set) will be posible or not .
If the font does not mater . So send me the Translation code too.

Unfortunately for translations I was only talking about the standard languages of the CP (English/French/Spanish/German/Portuguese); it will be quite more difficult to manage some other languages

I think there is a bug with the require function:

Oops
You're right, I forgot this detail.
The fact is that the table "a" in file B really has a size of 0, because it is not the same table as in file A, but only a proxy to it (try "for k,v in pairs(a) do print(k,v) end" in file B to see the actual content). I forgot to add some needed things to return the length of the real table... Thanks, I will correct it quickly

[unique33]

Unfortunately for translations I was only talking about the standard languages of the CP (English/French/Spanish/German/Portuguese); it will be quite more difficult to manage some other languages

Ok.No problem.

Oops
You're right, I forgot this detail.
The fact is that the table "a" in file B really has a size of 0, because it is not the same table as in file A, but only a proxy to it (try "for k,v in pairs(a) do print(k,v) end" in file B to see the actual content). I forgot to add some needed things to return the length of the real table... Thanks, I will correct it quickly

all of the other problems that I mentioned befor returns to this problem.

[The_AFX_Master]

Orwell can you release a very small documentation (as readme on CPLua) that shows the syntax of all the functions (with a short description) of the "UI" package. thanks a lot for the info

[Orwell]

I will do it, but you don't actually need it now because this package isn't available with the last version...

[The_AFX_Master]

oopps ! wrong glasses !!!

[MicroPro]

Would you add the 'GetTextSize' in Lua? I copy the whole section about it here:

void SCWindow::GetTextSize  (  const CPString &  str,  
  int &  width,  
  int &  height,  
  PegFont *  font = NULL 
 )

Usage: Find the width and height of text in a given font. If the PegFont is NULL then the default font is used.

Parameters:
str - CPString with text to compute the widtha nd height.
width - reference to int which where the width will be stored
height - reference to int which where the height will be stored
font - PegFOnt to use for size computation. If set to NULL the default font will be used.

Of course if you don't want to include the font parameter, I think that by default the font should be set to the font used in CPLua's graph section.

[The_AFX_Master]

I need to read classpad lists and matrices ....it?s possible? how?

[Orwell]

Would you add the 'GetTextSize' in Lua? I copy the whole section about it here:Of course if you don't want to include the font parameter, I think that by default the font should be set to the font used in CPLua's graph section.

Hmm.. Let me think about it

I need to read classpad lists and matrices ....it?s possible? how?

Use the CAS package
I added a function cas.elem() to access individual elements in lists and matrices.
Thus, if "aList" is a list (which has been created in Main or anywhere else), you may use

aList = cas("aList")  -- get the list
print( cas.elem(aList, 3) )  -- print the third element
cas("{1,2,3,4}=>aList") -- replace content of the list

You may use matrices in a similar way

[PAP]

This weekend I worked on the solution of non-trivial boundary-value problems using LuaNumAn. This is a really difficult topic, and I expected problems (fortunately, the results are more than satisfactory, but this is another story). There is however, a problem, directly related to CPLua. The new LuaNumAn function handling boundary-value problems is extremely memory-consuming. However, the usual CPLua's "soft-break" (where a memory overflow error occurs, but CPLua does not break suddently) appeared only rarely. In most cases, memory overflow caused "Unsufficient Memory" errors, so that CPLua breaks suddently, ClassPad returns to the main menu, and all unsaved work was lost . This means that CPLua's managment of memory overflows needs upgrading.
Note that calling collectgarbage() explicitly reduces unsufficient memory errors, but not always: I have seen a program starting with collectgarbage() (and including collectgarbage() in critical points) to run flawlessly one time, while the exact same program may cause CPLua to crash, when running a second time. I'm really curious to know how this can happen.

Using one or another way, I will overpass the problem. I have, however, a remark (already said by someone else, if I remember well): A "memory-consuming program" in ClassPad means "a program that uses a few hundends of Kb". This is crazy, since ClassPad has 4 Mb of memory, which, as far as I know, cannot be used by user's programs . I really cannot understand why such a huge memory (for a calculator, of course) cannot be used by a program.
Imagine, my problem is not the execution time (which is surprisingly low, given that boundary-value problems need complex algorithms), my problem is the memory, while, at the same time, there are 4 Mb free in my ClassPad. Isn't that crazy?

[Orwell]

However, the usual CPLua's "soft-break" (where a memory overflow error occurs, but CPLua does not break suddently) appeared only rarely. In most cases, memory overflow caused "Unsufficient Memory" errors, so that CPLua breaks suddently, ClassPad returns to the main menu, and all unsaved work was lost . This means that CPLua's managment of memory overflows needs upgrading.

I see... Sorry for all the troubles
As you already know it, memory management is a really difficult problem. Not because it needs some complex algorithms, but simply because there is no algorithm at all. Each part of CPLua may allocate more memory, and each part may cause a crash if there is no more free memory. To avoid this I would have to make tests and "recovery points" everywhere, and this would give a rather ugly code - I wish the ClassPad had support for C++ exceptions.
In theory, the Lua interpreter is completely sure: the amount of free memory is allways checked before a new allocation. When there is not enough memory, it produces a "soft break".
But if you encounter a real crash that means that there is another part of CPLua that allocates to much memory, and I must secure it as well. But I still can't see what part is the source for all the troubles The IO package may be a source of problems, if you used it. By the way I thought about a better solution for it, and I must implement it soon. This will have no consequences on its use.

Note that calling collectgarbage() explicitly reduces unsufficient memory errors, but not always: I have seen a program starting with collectgarbage() (and including collectgarbage() in critical points) to run flawlessly one time, while the exact same program may cause CPLua to crash, when running a second time. I'm really curious to know how this can happen.

There must be a memory leak somewhere then Could you please send me an example of program that causes this kind of problems? I need to make some tests with it.

A "memory-consuming program" in ClassPad means "a program that uses a few hundends of Kb". This is crazy, since ClassPad has 4 Mb of memory, which, as far as I know, cannot be used by user's programs . I really cannot understand why such a huge memory (for a calculator, of course) cannot be used by a program.
Imagine, my problem is not the execution time (which is surprisingly low, given that boundary-value problems need complex algorithms), my problem is the memory, while, at the same time, there are 4 Mb free in my ClassPad. Isn't that crazy?

Well, I'm sure you know the difference between a hard disk and RAM memory The "4 Mb of memory" only concerns the Flash memory (its "hard disk") that you may use to store new Add-ins. An add-in can't use this space for work; all operations have to be made with the RAM memory, which is faster but smaller: there are only 512 Kb of RAM memory (the size of an MCS file). You may have a nice and fast hard-disk of 200 Go on your computer, but if you only have 32 Mo of RAM memory, you will never be able to run HL? on it
Also don't forget that all MCS variables (lists, matrices, pict, basic or lua progs, ...) are in the RAM as well, not in Flash. They also reduce the amount of memory that may be used by the Add-ins.
Btw, I used to work for the Casio AFX calculator before. This calculator has 1 Mo Flash and only 64 Ko RAM. For me, 512 Ko is quite comfortable, but I understand that people allways ask for more If I remember well, you too worked once with a calculator that had only a few Kb of memory

[PAP]

But if you encounter a real crash that means that there is another part of CPLua that allocates to much memory, and I must secure it as well. But I still can't see what part is the source for all the troubles The IO package may be a source of problems, if you used it.

I have encountered plenty of real crashes. I'll send you a program that causes such crashes tonight. Btw, the problem is not the IO package, since the core of LuaNumAn does not use it.

Also don't forget that all MCS variables (lists, matrices, pict, basic or lua progs, ...) are in the RAM as well, not in Flash. They also reduce the amount of memory that may be used by the Add-ins.

I know, but my ClassPad is practically a "Lua mini computer": no add-ins (except CPLua, of course), no Basic programs (I have deleted them, since they are very slow), no presentation files, no spreadsheets, no e-activities, nothing. Just CPLua programs, and a few CAS variables. LuaNumAn itself is no so big; of course, its functions use memory when running, but not too much, so I don't think that the 512 Kb limit is reached by running a LuaNumAn program, even a complex one. Like you said, there must be a memory leak somewhere .

If I remember well, you too worked once with a calculator that had only a few Kb of memory

Indeed, it was an old Casio PB-410; a friend had it, and gave it to me, saying "it's not a computer, you can't write anything useful on it". He was wrong; it had only 1638 bytes RAM (I remember the exact number, because it was a real nightmare), but it was useful.

Btw, a first version of LuaTest (a program that solves some numerical analysis problems, measures the time needed, and compares the results with those stored in a file) is ready. I needed printf's "%b" (backward) directive for better displaying the process, but the "%b" directive is not supported by CPLua's version of printf (I 've posted something about it in the "suggestions" topic). Are you planning to add "%b" support in CPLua?

[Orwell]

I needed printf's "%b" (backward) directive for better displaying the process, but the "%b" directive is not supported by CPLua's version of printf (I 've posted something about it in the "suggestions" topic). Are you planning to add "%b" support in CPLua?

I still have to look how it could be done with the current class used by the console window. Since I will certainly use another (faster) class later, I think that it won't be impossible

[The_AFX_Master]

but if you only have 32 Mo of RAM memory, you will never be able to run HL? on it

Don?t say this ...see my avatar .

[PAP]

Don?t say this ...see my avatar .

I don't want to pollute CPLua's main topic, but I can't resist the temptation to say something. I bet my ClassPad that HL2 cannot be played in a computer with 32 Mb of RAM.
PS: (about your avatar): You still use the crowbar? The gravitational weapon is much more powerful.

[The_AFX_Master]

Crowbar is a classic.... is The "Shelby" of the HL weapons. Gravity gun is a Ferrari "Enzo"

[Orwell]

Just a few words to say that I don't currently have a lot of time to work on CPLua, but I'm still trying to find some free time to complete the UI package. I also found some serious problems in the current implementation of require() and export()... I guess i will have to rewrite them one more time. The new method will use a little more memory, but will be easier and safer.

Btw, about the future UI package:
I currently use this code to add a button into a window:

win = ui.window({name="A name", x=10, y=10, width=100, height=100})
b = ui.button({text="some text", x=5, y=5, width=50})
win:add(b)

The last line add the button at relative coordinates (5,5) into the window.

I was wondering if something like this wouldn't be easier:

win = ui.window({name="A name", x=10, y=10, width=100, height=100})
b = ui.button({text="some text", width=50})
win:add(5, 5, b)

What's your opinion about that?

[Nanard]

hi

I don't think the second method is easier to use, but perhaps easier to understand.
In my mind, a button had no position itself. position had a meaning only if there is there is somthing else.

[PAP]

What's your opinion about that? :)

Among the two methods, the first one seems easier to understand to me. The add function reminds me the add method that many Java swing objects have.
Btw, when the ui will be implemented, a "designer" program will be very useful. This program should let the user define objects graphically, then it will save the corresponding Lua code. Something like the designers existing for Java, Qt, Gtk, Tcl/Tk, etc (I don't mention Visual Basic because i hate it).

I don't think the second method is easier to use, but perhaps easier to understand.
In my mind, a button had no position itself. position had a meaning only if there is there is somthing else.

On the contrary, I think the first method is easier to understand: If a button has no position itself, then a window has no postition itself as well: a window belongs in the screen area, just as a button belongs in a window. So, if the button is to be added by win:add(5,5,b) then the window itself must be added to the screen with scr:add(1,1,win), where scr is an object determining the screen, something like scr=ui.screen().

But in a small screen like ClassPad's, maybe a better idea is to make a button independent. So, if screen is an object determining the whole screen, you could add the button into the window, but you could also add the button into the screen, as an independent object. I'm not sure if this method is really better, but it has more flexibility. For example, you can define the screen, the window and the button as:

scr=ui.screen()
win = ui.window({name="A name", x=10, y=10, width=100, height=100})
scr:add(win)
b = ui.button({text="some text", x=5, y=5, width=50})

Then, you can add the button to the window:

win:add(b)

or, if you like, you can add the button to the screen:

scr:add(b)

However, adding the window to the button should be a runtime error.

[Orwell]

Hmm... this isn't a bad idea
Actually I just created the functions win:show() and win:hide() instead of scr:add(win) and scr:remove(win) .
In my point of view, only windows should be addable to the "screen", but you may add anything to a window. There is less flexibility indeed, but you still may do everything you want

About the designer: again this is a good idea, but it will require a lot of work. I really don't have time for that... maybe someone else will make it later

Here is a list of the functions so far (There isn't many explanations, but I will explain it in details later )

W 		- an UI widget
C		- an UI component
P		- a picture
T 		- a string
I 		- an index
N 		- a number
X,Y,W,H		- x, y, width, heigth

-------------------------------------------------------------
-- GENERAL
-------------------------------------------------------------

	-- loads the UI package
require("ui")

	-- start the UI mode (main loop waiting for events)
ui.start()

	-- stop it (may be restarted later)
ui.stop()

-------------------------------------------------------------
-- WINDOWS
--
-- General interface to hold and display the UI components.
-- You may create new UI windows with 'ui.window()'
-- Components (like widgets, buttons, ...) may be added to 
-- this kind of windows, and events may be defined.
-- You may also access the other windows from CPLua (like the
-- console window), but you cannot add components or define
-- events for it. You may hide/show/resize it however.
-------------------------------------------------------------

	-- create a new (hidden) UI window
	-- NAME (string) = name of the window (should be unique for each win)
	-- FRAME = "none", "thin" or "thick" (optional, default: thin)
win = ui.window({name=NAME, x=..., y=..., width=..., heigth=..., frame=FRAME})

	-- set the scroll mode
	-- MODE = "auto_v", "v", "auto_h", "h", "auto" or "none"
win:setscroll(MODE) 
T = win:getscroll()

	-- return the background picture of the window
	-- use the DRAW package to draw on it
P = win:getpict()

	-- refresh the window (call it after drawing operations on its picture)
win:update()

	-- add or remove some components
win:add(C)
win:remove(C)
win:removeall()

	-- return a window by its name
	-- use "Console" as name for the console window
	-- and "Graph" for the graph window
win = ui.getwin(NAME)

-- the following functions work for all type of windows (not only UI)

win:setsize(X,Y,W,H)
X,Y,W,H = win:getsize()

T = win:getframe()

win:show(HIDE_OTHERS) -- HIDE_OTHERS (bool) is optional (default: false)
win:hide()

T = win:getname()
T = win:gettype()

-- UI Window events
-- define these functions to catch the events
function win:_pendown(x,y) ... end
function win:_penmove(x,y) ... end
function win:_penup(x,y) ... end

function win:_keydown(key) ... end
function win:_keyup(key) ... end

function win:_sized(x,y,w,h) ... end
function win:_parentsized(x,y,w,h) ... end

-------------------------------------------------------------
-- WIDGETS
--
-- A basic component that can act as a container for other
-- components. You may also define events for it.
-- Use it to define some scrollable area inside windows
-- or to create some new kind of custom component.
-------------------------------------------------------------

	-- create a new widget
	-- FRAME = "none", "thin" or "thick" (optional, default: none)
wid = ui.widget({x=..., y=..., width=..., height=..., frame=FRAME})

	-- set the scroll mode
	-- MODE = "auto_v", "v", "auto_h", "h", "auto" or "none"
wid:setscroll(MODE) 
T = wid:getscroll()

	-- return the background picture of the widget
	-- use the DRAW package to draw on it
P = wid:getpict()

	-- refresh the widget (call it after drawing operations on its picture)
wid:update()

	-- add or remove some components
wid:add(C)
wid:remove(C)
wid:removeall()

wid:setsize(X,Y,W,H)
X,Y,W,H = wid:getsize()

T = wid:getframe()

-- Widget events
-- define these functions to catch the events
function wid:_pendown(x,y) ... end
function wid:_penmove(x,y) ... end
function wid:_penup(x,y) ... end

function wid:_keydown(key) ... end
function wid:_keyup(key) ... end

function wid:_sized(x,y,w,h) ... end
function wid:_parentsized(x,y,w,h) ... end

-------------------------------------------------------------
-- NOTEBOOKS
--
-- A container that can manage several widgets and organize
-- it with text-decorated tabs.
-- Each "page" consists of a widget (which holds the content of
-- the page) and its title (which is written on the tab).
-- Each of those widgets may contain several components.
-- You may replace all widgets by some other ones.
-------------------------------------------------------------

nb = ui.notebook({x=..., y=..., width=..., height=..., frame=FRAME})


X,Y,W,H = nb:getsize()
nb:setsize(X,Y,W,H)
T = nb:getframe()

	-- get properties of the page with number "I"
T = nb:gettitle(I)
W = nb:getwidget(I)
T,W = nb:getpage(I)

	-- or replace it
nb:settitle(I,T)
nb:setwidget(I,W)
nb:setpage(I,T,W)

	-- change pages number
nb:setnbrpages(N)
N = nb:getnbrpages()
nb:insertpage(I,T,W)   -- T and W are optional
T,W = nb:removepage(I)
nb:addpage(T,W)  -- T and W are optional

	-- get or set the current page
nb:setcurrent(I)
I = nb:getcurrent()

	-- event: if defined, this function will be called
	-- each time the current page change.
function nb:_currentchanged(I) ... end

-------------------------------------------------------------
-- BUTTON
--
-- A simple, text-decorated button.
-------------------------------------------------------------

b = ui.button({text=TEXT, x=..., y=..., width=...})  -- width is optional

X,Y,W,H = b:getsize()
b:setsize(X,Y,W,H)

T = b:gettext()
b:settext(T)

	-- event: if defined, this function will be called
	-- each time the button is clicked.
function b:_clicked() ... end

-------------------------------------------------------------
-- TEXTEDIT
--
-- An editable text area.
-------------------------------------------------------------

t = ui.textedit({x=..., y=..., width=..., height=..., frame=FRAME})

X,Y,W,H = t:getsize()
t:setsize(X,Y,W,H)
T = t:getframe()

T = t:gettext()
N = t:getlength()
t:settext(T)
t:append(T)
t:clear()

t:cut()
t:copy()
t:paste()

t:undo()

Other planned components : lineedit, spinbox, combobox, menus, toolbars, ... + additional features
I tried to make it as simple and intuitive as possible, but if you already have some suggestions, just let me know.
For example, I'm thinking of adding an optional field "_clicked" in ui.button(), then you could write

win:add( ui.button{text="btn", x=5, y=5, 
   _clicked = function(self) 
	  ... 
   end
})

as well as

b =  ui.button{text="btn", x=5, y=5} 
function b:_clicked() 
   ... 
end
win:add(b)

[Kilburn]

1 word:

AWESOME!



I'm really waiting for the next release.

[-Tom-]

Great step for humanity.... this I was waiting for!

[PAP]

Other planned components : lineedit, spinbox, combobox, menus, toolbars, ... + additional features

W - O - W.
I don't think that I will ever use ui extensively, but such a package will be impressive anyway.

I tried to make it as simple and intuitive as possible, but if you already have some suggestions, just let me know.
For example, I'm thinking of adding an optional field "_clicked" in ui.button(), then you could write

win:add( ui.button{text="btn", x=5, y=5, 
   _clicked = function(self) 
	  ... 
   end
})

as well as

b =  ui.button{text="btn", x=5, y=5} 
function b:_clicked() 
   ... 
end
win:add(b)

I think that second method is certainly more intuitive, plus it resambles the way that widget events are handled in other languages, such as Java.

1 word:
AWESOME!

I'm really waiting for the next release.

Great step for humanity.... this I was waiting for!

Guys, I agree that it's impressive, but can I remind you that ClassPad is a scientific calculator?

[-Tom-]

Yes PAP, it is scientific calc, but I must tell You that I stopped using Lua for some time becouse I could not stand inputting all data again and again after small mistake... and that I couldn't instantly check results of small data change.. I had to use Spreadsheet, but I willcome back to Lua with pleasure if UI willbe ready. This interactivity is really needed, and I hope UI will introduce it. Of course, You can say that I could write more flexible programms. Yes, but I have no time for this...

[Orwell]

It's been a long time since I made the last screenshot...
Well, here are some new ones



PS: Yes, of course it works

[PAP]

It's been a long time since I made the last screenshot...
Well, here are some new ones
PS: Yes, of course it works

Wow, good work. I'm looking forward to use the ui package. The "find" utility is more than welcome. I want the new version now,now, and now!
Btw, I have also some screenshots showing current LNAplot capabilities. Wait a few days, you will see that LNAplot has been greatly upgraded, even without the ui package: it has custom-size plots, multiple plot frames, and... well, I'm not going to tell more for now. By combining these new capabilities with the ui package, I would be able to do very interesting things .

[PAP]

Orwell, can you estimate when the new version of CPLua will become available? I have added several things in LNA these days, and I'm thinking whether it's a good idea to release a new LNA version now, or to wait for the next CPLua version (0.9a maybe?)

Btw, LNAplot functions are now drawing on a picture (not on the buffer). This adds a lot of flexibility, and makes LNAplot way more robust. I suppose that, with the ui package, I will be able to define that picture as the background of a window? If so, it will be very easy to modify current LNAplot functions so that they will fully use the ui package . The result will be, what can I say, interesting at least. I can't wait for the next version .

[Orwell]

Orwell, can you estimate when the new version of CPLua will become available? I have added several things in LNA these days, and I'm thinking whether it's a good idea to release a new LNA version now, or to wait for the next CPLua version (0.9a maybe?)

I don't exactly know... I'm currently adding more and more stuff to CPLua, and I don't know where I should stop
However I think I will release CPLua 0.9A with an incomplete UI package. You won't find all features in it, but the main things will be available (I posted earlier the list of already available commands). This will be helpful to find some possible bugs too.
Btw, I decided to add support for text files (finaly!) But this will be available in another version (CPLua 0.9B ?).
Also, an important thing: I would like to change the format of Lua source files (it will be more like a simple text file). In the next versions you will be able to read the 2 file formats, but gradually I would like everyone to convert their programs into the new format (just open it and save it again). I don't want to wait too much for those changes (if it's not in CPLua 0.9A, it will be in 0.9B).
I'd like to upgrade CPLua to Lua 5.1.1 too.

My last exam will be on Thursday, then I will have more time. Let's say CPLua 0.9A will be ready in a week

Btw, LNAplot functions are now drawing on a picture (not on the buffer). This adds a lot of flexibility, and makes LNAplot way more robust.

Yes, it is a good thing

I suppose that, with the ui package, I will be able to define that picture as the background of a window? If so, it will be very easy to modify current LNAplot functions so that they will fully use the ui package .

That's right, and you could also capture pen or key events on it

[PAP]

I don't exactly know... I'm currently adding more and more stuff to CPLua, and I don't know where I should stop
However I think I will release CPLua 0.9A with an incomplete UI package. You won't find all features in it, but the main things will be available (I posted earlier the list of already available commands). This will be helpful to find some possible bugs too.

Oh no, I have I feeling that I will start bug hunting again .
Btw, there is a small bug in version 0.8 (you are probably aware of it, but I'll post it, just in case: open a file, activate the virtual keyboard, then close the file to return to CPLua's main menu. Now, see what's happenning: normally the menu should be above the virtual keyboard, but it's not (it appears at the center of the screen, as if the virtual keyboard is not activated). Now, if you try to open a file, you will activate... interactive mode! It seems that CPLua gets pen events as if the menu was in the right place. I think that the bug should be easily removed. Basically, it seems that the menu should be redrawn above the virtual keyboard.

Btw, I decided to add support for text files (finaly!) But this will be available in another version (CPLua 0.9B ?).
Also, an important thing: I would like to change the format of Lua source files (it will be more like a simple text file). In the next versions you will be able to read the 2 file formats, but gradually I would like everyone to convert their programs into the new format (just open it and save it again). I don't want to wait too much for those changes (if it's not in CPLua 0.9A, it will be in 0.9B).

It's ok for me. I'll change everything to the new format, as soon as it will be available.

I'd like to upgrade CPLua to Lua 5.1.1 too.

Looking on the internet to see what's new in version 5.1.1...

My last exam will be on Thursday, then I will have more time. Let's say CPLua 0.9A will be ready in a week

Good luck to your exams. Take your time, there are plenty of things to add in LNA, except the use of the ui package. Btw, what is the memory footprint of ui? If it's large, I'm afraid that I will avoid it, since some LNA functions (especially RK4Rich and Shoot) are already real memory devourers.

That's right, and you could also capture pen or key events on it

With all these things, expect a much more efficient LNAplot library soon...

[Kilburn]

It's been a long time since I made the last screenshot...
Well, here are some new ones



PS: Yes, of course it works

CPLua must be implemented in the next ClassPad OS, with official documentation! It's too wonderful

[Orwell]

I spent a lot of time looking for memory leaks in CPLua, and I think I may now surely say that there is no leaks in the add-in.
The memory errors seem to come from the function I use to check the available memory on the handheld, which return some very strange values
I'm currently searching a better solution.

[Orwell]

I'm taking some vacation today until next week

I'm really sorry about CPLua's releases, I was hoping that CPLua 0.9A would be ready before today... Unfortunately I still have a very annoying problem with memory, and I don't think that it would be a good idea to give you a pre-release now because the risks of memory crashes are still high
I know you are waiting for the UI package, but I don't want to give you something with unpredictable bugs in it

Sorry again, and see you in a week

[PAP]

I'm taking some vacation today until next week

Bonnes vacances!

I'm really sorry about CPLua's releases, I was hoping that CPLua 0.9A would be ready before today... Unfortunately I still have a very annoying problem with memory, and I don't think that it would be a good idea to give you a pre-release now because the risks of memory crashes are still high
I know you are waiting for the UI package, but I don't want to give you something with unpredictable bugs in it

Sorry again, and see you in a week

Mieux vaut tard que jamais.
I will be in vacations in one week, but I will download the new version anyway.

[Orwell]

Okay I'm not sure if it is a good idea or not , but since you have been waiting during a very long time for this release, I think I shall release a first version of CPLua 0.9.

Unfortunately, this version is rather unstable for large scripts: the probabilities of memory crashes are high. This is because of a serious problem with memory management, which does not seem to come from CPLua but rather from the CPSDK. I passed a very long time trying to find a solution, but I still can't correct it at 100%

Thus, you should keep using CPLua 0.8 on your CP, because the risks of crash are quite lower. However, this 0.9A (pre)version features an important part of the UI package, and you will be able to use it in some simple Lua programs to see how it works and what you can do with it. I added the list of available functions and some examples in the zip file.

The Windows version of CPLua 0.9A works without any problem. You shouldn't have any problems on the handheld neither when running some small Lua scripts and examples. But for programs that require a lot of memory, you will most likely encounter an error (or a real crash), probably because of a data corruption somewhere in the memory. I'm really sorry about that, and I hope it will be solved quickly.

Finally, I must tell you that I'm leaving (again) for 3 weeks... until the end of August I won't have access to the internet, but I will continue working on CPLua and try to find a solution I know I shouldn't give you something without support and let you deal with it, but I think this is better than nothing.

If you have problems, or questions about the UI package, unfortunately I won't be able to answer before September. I wrote several examples and I tried to make it as simple as possible, but maybe something will appear strange to you. Then don't forget this forum, I hope that several people here will try the package, and even if I can't help you maybe someone else will have found the solution to your problem. So don't hesitate to ask the others I hope you will enjoy it. Btw if you have some new suggestions about the UI, feel free to write it here!

Here is the link for CPLua 0.9A: http://orwell01.free...ua/CPLua09A.zip. Happy hollydays

[Major]

Merci pour tout Julien, et ne t'en fait pas, on va pas laisser de c?t? ton joli travail sous pr?texte qu'il n'est pas parfait ! All?, bonnes vacances en France !

[The_AFX_Master]

Thanks a lot Orwell, Happy Hollydays!

[PAP]

Okay I'm not sure if it is a good idea or not , but since you have been waiting during a very long time for this release, I think I shall release a first version of CPLua 0.9.

IMHO, the best thing in this new version is the "find and replace" capability, which is extremely useful. The "ui" package is impressive, since you can define and use widgets very easily. However, as Orwell already said, CPLua 0.9A is extremely fragile: it cannot even pass the LNAtest (included in my LNA package), which fails due to "insufficient memory", while version 0.8 passes this test. Only small programs can be used.

A remark concerning widget definition: you can define the position of the widget by the coordinates x and y (in pixels). Currently, these coordinates are the upper left corner of the widget. I think it will be much more convenient if you can also define the center of the widget, by using another optional argument, say "align". For example,

button=ui.button(text="foo",x=40,y=20,align="left")

could be used to place a button, with the upper left corner at x=40, y=20, while

button=ui.button(text="foo",x=40,y=20,align="center")

could be used to place the button so that its center will be at x=40, y=20. This will be very useful to place buttons (or other widgets) at the center of a window (such a thing is widely used in practice).

Since I'm working on LNA 1.7 right now, I switched back to version 0.8 for the moment. Looking forward to see a more stable 0.9 version.

[MicroPro]

Sorry if I interrupted you, in the 'math' library there is a variable named 'huge' with the value of '++++++++++++++'! What's its usage?

---------------------------------------------------------
Lua 0.9 and LNA 1.7 and OS 3.0:
ClassPad = A gold mine in your hands!
---------------------------------------------------------

[Kilburn]

It's a huge number, and maybe you can use if x<huge to know if x has underflowed...

I tried 0.9, the ui library is really easy to use. But ui.lineedit is missing...

[PAP]

Lua 0.9 and LNA 1.7 and OS 3.0:

Hmm, you can't have LNA 1.7. It's almost ready, but I didn't released it yet. You probably mean LNA 1.60.

[Orwell]

Okay I'm back at home but with some new interesting things PAP, if you say that it isn't useful then I will definitely stop working on CPLua

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 ). 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 )

A remark concerning widget definition: you can define the position of the widget by the coordinates x and y (in pixels). Currently, these coordinates are the upper left corner of the widget. I think it will be much more convenient if you can also define the center of the widget, by using another optional argument, say "align".

Aaargh. I feel the headache coming. Well, let's see if some other people will ask for it first