858 replies to this topic

[Orwell]

Actually the "x" that you passed was a Lua variable, not a CAS object.
If you want it to represent the real CAS variable "x", write

require("cas")
x = cas("x") -- make 'x' a CAS object
f = -x^2 -- 'f' is a CAS object too because x is an object 
print(cas.Fmax(f,x,-1,1,4)) -- call CAS function

Btw, I juste realized that the variables saved in the ClassPad memory are all available with the CAS package (e.g. if you define a list L in the Main mode, print(cas("L")) will show the same list in CPLua). I guess I should add some options to manage CAS variables then (like an option to access the variable manager etc :unsure

[-Tom-]

Thanks! I must get used with this a little more...
I want to ask, if that previous problem (with Quad(or any other)Reg) can be solved? Becouse if now then I will not bother with it any more and I will find another way to do what I need, but for sure will not so comfortable.

[Orwell]

I have to make a few more tests to see what happens with it... I don't have much time now but don't worry I will take a look

Btw , I'd like to add some precisions:
In my code above, 'x' becomes a CAS variable, then you can use it to create some other variables, like f = -x^2.
But be aware that you cannot use it as simple Lua variables, and for example the "math" package will not work with it:

x = cas("x") -- make 'x' a CAS object
f = math.sin(x) -- incorrect!

Instead, you may only use simple operations (+, *, ^, ...) and all the CAS functions. Thus here, to have f = sin(x) you must write instead

x = cas("x") -- make 'x' a CAS object
f = cas.sin(x) -- correct.

[-Tom-]

Ok, I will wait then! Thanks for explanations. My exams are also coming soon... so good luck!

[-Tom-]

Someone will be angry at last on me... but I have still another question

fMax works fine, but I would like to get acces to one of its results. I returns {MaxValue=111 , x=222} , how to extract only x ?

Anyone????

[Orwell]

Hmm this is a problem concerning the fMax function itselfs... I really don't know how to do that, even in the Main mode

[Kilburn]

fMax works fine, but I would like to get acces to one of its results. I returns {MaxValue=111 , x=222} , how to extract only x ?

Anyone????

I often use a 'trick' in functions that don't use [] to access to an element of a list.
For MaxValue for a function -2x^2+3x-1:

MaxValue=cas("sum(subList(getRight(fMax(-2x^2+3x-1)),1,1))")

With getRight, you get only {111, 222}, with subList, you can keep only {111} and with sum, you can get 111. But I think Orwell implemented a function to have a value in a list, but I forgot its name...
To get x, you must replace 1,1 by 2,2:

X=cas("sum(subList(getRight(fMax(-2x^2+3x-1)),2,2))")

So you get the part 2 to 2 of the list = the 2nd element.

[-Tom-]

Thanks a lot!!

[Orwell]

Thanks Kilburn, I didn't know those functions

To access an list element directly you can use the function cas.elem() :

x = cas("x")
f = -2x^2+3x-1
res = cas.fMax(f)
x_max = cas.elem( cas.getRight( res ), 2)

I think this should work

[-Tom-]

This question goes to Orwell:

IO is useful and I must thank You for it.. but tell me if it is possible to open other files, not made by Lua? I'm interested in PICT files. I think PICT files are also binary files..

[Orwell]

Well... PICT files are binary files indeed, but how do you want to read it? I cannot easily extract the content of the file (or just a part of it) and return it as a lua table or anything else... Lua was not made to manipulate binary data after all

[MicroPro]

CASIO haven't released the specification of PICT files?

[Orwell]

The sources of BitEdit should help a lot

[Kilburn]

You have the BitmapEditorExample in CPSDK. It's that picture structure that I used in Kaos Generator for screen captures.


EDIT:

I found the picture structure: void BitmapDocument::Read(CPReadFile& f) { Destroy(); PegBitmap *pBmp = new PegBitmap; f.ReadBytes(pBmp,sizeof(PegBitmap)); if (f.ErrorFlag()) { delete pBmp; return; } DWORD dwSize = (pBmp->wWidth+7)/8*pBmp->wHeight; UCHAR *bits = new UCHAR[dwSize]; f.ReadBytes(bits,dwSize); if (f.ErrorFlag()) { delete bits; delete pBmp; return; } pBmp->pStart = bits; SetBitmap(pBmp); } //------------------------------------------------------------------------------ void BitmapDocument::Write(CPWriteFile& f) { if (m_bitmap) { f.WriteBytes(m_bitmap,sizeof(PegBitmap)); if (!f.ErrorFlag()) { DWORD dwSize = (m_bitmap->wWidth+7)/8*m_bitmap->wHeight; f.WriteBytes(m_bitmap->pStart,dwSize); } } } BitmapDocument is a subclass of CPDocument, but I think you should easily understand the structure.

[Orwell]

Don't worry I had already found it

[Orwell]

Exams are finally gone

I will have a bit time this week to work on CPLua So tell me what you want most (sprites I guess, but I still don't know what is the best way to use them... PICT files could be useful, but I don't like the fact that you can only save one picture in each file; I could make it as a temporary solution though)

[-Tom-]

I think very useful would be finding solution for data exchange with other Add-ins, or to extract data to PC. PAPs text files were best solution, but maybe there is other way? And still this problem with running commands in CAS was not solved.

[Kilburn]

Exams are finally gone

Yeaaaahhhhhhhhhhh!!!!!!!!!!!!

[Orwell]

I think very useful would be finding solution for data exchange with other Add-ins, or to extract data to PC. PAPs text files were best solution, but maybe there is other way?

Text files could be used indeed for other Add-ins... I will try to manage something. However this will simply make some "TEXT" variables, and there is currently no direct way to get them back on the PC as a real text file. You could use the CP Manager to receive those files, but then the only thing you could do is to edit them (I don't exactly know how) and copy-paste it in a real file...

And still this problem with running commands in CAS was not solved.

Well,

require "cas"
cas("{1,2,3,4}=>a") -- "=>" is the assignment key on the Standard keypad
cas("{7,4,2,3}=>b")
cas("Quadreg a,b")
print(cas("Acoef"))

seems to work as it should now...

[PAP]

Text files could be used indeed for other Add-ins... I will try to manage something. However this will simply make some "TEXT" variables, and there is currently no direct way to get them back on the PC as a real text file. You could use the CP Manager to receive those files, but then the only thing you could do is to edit them (I don't exactly know how) and copy-paste it in a real file...

Glad to see that I'm not the only one that wants text files output. Orwell has right, they cannot be edited in our PC, but at least we could be able to see their contents in ClassPad itself. I also don't know how we can copy-paste their contents in a real text file. Such a thing would be very useful for printing (the same holds true for CPLua programs, saved as "MEM" variables).

[Orwell]

Hmm, CPLua 0.8 RC1 is ready, but I can't upload it right now... I hope the problem with my FTP will be solved quickly.

at least we could be able to see their contents in ClassPad itself. I also don't know how we can copy-paste their contents in a real text file. Such a thing would be very useful for printing (the same holds true for CPLua programs, saved as "MEM" variables).

Unfortunately, there is an important problem with textfiles (like with other variables): there is no standard for their format. The type "TEXT" doen't even exist! That means that I could write a "text" file from Lua, but for exemple TextManager will not read it, because I don't use the same header for my files. TextManager can only read its own files, and this is the same for CPLua. I agree that text files is a common way to share data's between programs on a computer, but this is not the case on the ClassPad...

[Orwell]

I thought about it again... text files are a real headache to manage. More precisely, writing it should be easy, but reading t efficiently is a nightmare. I would spend a lot of time to make functions to read data's from files, it wouldn't be easy to use, and I still think that only a few people would really need it.

So what I suggest is this: I will add an option on the menu of the console window to save its content in a text file, and I will make the editor able to read every "text files". This way you will be able to save the results of a program as simple text and edit it later. I'll also provide functions to create a text file and write (formated) strings; it will be possible to read it too, but only 1 line or the whole file at once. This should be seen as a limited way to exchange data's with other programs than CPLua; for other things you should use the current functions of the "io" package

There will also be an option in the menu of the Graph window to save it in a PICT file btw.

I will have to define exactly what I mean by "text file", and I'll suggest all people who create add-ins to use the same format when storing some text, for compatibility between programs.
Lua programs should also respect this format, but this isn't currently the case. I will make the future versions support both formats, but each existing Lua programs should be opened and saved again in the better way

[Kilburn]

There will also be an option in the menu of the Graph window to save it in a PICT file btw.

Could you use an option like draw.onbitmap() to draw directly on a bitmap? It's possible in C++ with BeginDraw(PegBitmap*)

[-Tom-]

This is satisfying solution, at least for me. Especially this idea with PICT files - great!! Awaiting release!
I know... suggestions are somewhere else, but I must ask: is it possible in future to make Add-in similar to My Programs? I have already more than 40 programs... and its hard to manage them all. I already prepared myself some kind of menus, and I run programs from them, but I treat it as a temporary solution. I hope it is possible.

[Orwell]

This is satisfying solution, at least for me. Especially this idea with PICT files - great!! Awaiting release!

Planned project for tomorrow:

pic = newpict(width, height)
pic = loadpict(folder,file)
savepict(pic,folder,file)
draw.pict(x,y,pic)
draw.onpict(pic)

We should be able to save pictures (sprites) with other Lua elements with the "io" package too

is it possible in future to make Add-in similar to My Programs? I have already more than 40 programs... and its hard to manage them all.

I'll think about it

[MicroPro]

We should be able to save pictures (sprites) with other Lua elements with the "io" package too.

You mean as well as MEM files?

[Orwell]

The following functions were added to the "draw" package today:

* pic = pict.new(width, height)
	// Create a new picture of given size and return it
	
* pic2 = pict.part(pic, x1, y1, x2, y2)
	// Create a new picture 'pic2', which is a copy of the specified rectangle of picture 'pic'
	
* pic = pict.load(folder, file)
	// Load a picture from the PICT variable at "folder/file".
	// If you don't specify the folder, the file will be searched in the "main" directory:
	// 'pict.load("foo")' is the same as 'pict.load("main", "foo")'.
	
* pict.save(pic, folder, file)
	// Save a picture to a PICT variable.
	// 'pict.save(pic, "foo")' is the same as 'pict.save(pic, "main", "foo")'.
	
* w,h = pict.size(pic)
	// Return the size (width and height) of the picture 'pic' 
	
* pic_capt = pict.capture()
	// Make a copy of the entire screen (160*240) and return it as a picture.

* pic_scr = pict.screen()
	// Return the content of the graph window, as a picture.
	// This is not a simple copy: any drawing operation on this picture will
	// be visible on screen.
	
* pic_buf = pict.buffer()
	// Return the content of the hidden buffer, as a picture.
	// This is not a simple copy: any drawing operation on this picture will
	// change the content of the buffer.

* draw.onpict(pic)
	// Send all drawing operation on the specified picture.
	
* dst = draw.onwhat()
	// Return the current destination of the drawing operations, as a picture.

* draw.pict(x, y, pic, rasterOp="copy")
	// Draw the picture 'pic' at the specified point.
	// 'rasterOp' is a string among the followings: "copy" (default), "inv", "dstinv", "or", "xor".
	// This modifies the way the picture is actually drawn; use this for different effects like
	// transparency, color inversion etc.

The pictures can be saved with the "io" package too; for example, the following code runs correctly:

require "io"
require "draw"

f = io.file("foo")   -- file "main/foo"
f:create("foo", "bar")   -- create it
f:open("w")   -- open it for writing

p = pict.new(10,10)   -- create a new picture (sprite) with size 10*10
p2 = pict.new(8,8)   -- create another picture with size 8*8

f:write(p)   -- save it in the file
f:write(p2)   -- write as many pictures as needed
f:close()   -- close file

This way you can save several sprites into one file; however if you store them separately in PICT files you will be able to edit them with BitEdit

[-Tom-]

f = io.file("foo") -- file "main/foo"
f:create("foo", "bar") -- create it
f:open("w") -- open it for writing

p = pict.new(10,10) -- create a new picture (sprite) with size 10*10
p2 = pict.new(8,8) -- create another picture with size 8*8

f:write(p) -- save it in the file
f:write(p2) -- write as many pictures as needed
f:close() -- close file[/code]
This way you can save several sprites into one file; however if you store them separately in PICT files you will be able to edit them with BitEdit

Great! Those functions will be great for Killburn, but what with text files?
And, to this last part of code: how to read it later?

[Orwell]

Text files will come later, I didn't take the time to work on it yet.

Reading sprites is made in the "natural" way:

require "io"
require "draw"

f = io.file("foo") -- file "main/foo"
f:open("r") -- open it for reading

p = f:read() -- read the first picture
p2 = f:read() -- read the other one

f:close() -- close file

draw.pict(10, 54, p) -- draw the first pict

[-Tom-]

Is everything ok with files? I cannot download latest version...

[Orwell]

My FTP works again now, but I will try to add text files support before releasing the next version (give me 2 or 3 days)

[Kilburn]

YEAAAAAAAHHHHHHH!!!!!!!

[MicroPro]

Someone must write a especial CPLua documentation...

[Orwell]

"2 or 3 days" later... erm

CPLua 0.8 RC1 is finally out.

Major changes from CPLua 0.72:
- New refactoring of the windows used by Lua programs (console & graph); it makes it easier to create other kind of windows for future packages
- functions to handle sprites (called "pictures" in CPLua) added in the "draw" package
See the file functions.txt and the new example "Logo" to see how it works.
- Upgrade to Lua 5.1 (final)
- Improvements on memory usage (& complete rework of the isolation between chunks)

I'm sorry for the text files... I asked Brian to give me some advices about it, but he seems really busy these days But I don't forget it

This is a release candidate version, there might be some bugs due to the major changes in CPLua. If you see something weird, please report it here and I will fix it for the official release

Have fun!

[PAP]

"2 or 3 days" later... erm

No, no, no, don't be shy, we all have other things to do, it's easy to understand that CPLua developement needs a lot of time. Btw, I also said that LuaNumAn 1.50 will be released "before Christmas", and, erm, it hasn't been released yet .

CPLua 0.8 RC1 is finally out.

Great news. All programs of LuaNumAn 1.50 are running flawlessly (14 large scripts). Even the DLMfit script works (traditionally, this script caused crashes in previous "candidate" versions, due to faulty grabage collection).
I noticed some small changes:
(1) The tabs in the editor windows are now resizing, in order to fit a filename which is long. In other words, a small (but annoying) bug has been removed.
(2) The graphics window doesn't have a border, as in previous versions. Probably the border was an artifact from the console window, and it has been removed due to the windows refactoring. I think it is better as it is now.
(3) A new directory named "CPLua" is created in CP when installing CPLua 0.8RC1. It includes only one file, named "Prefs". What is it? If I delete it, my ClassPad will explode?
I don't have time to test the "draw" package and the sprites facility (but Kilburn will probably want to test it thoroughly).

I'm sorry for the text files... I asked Brian to give me some advices about it, but he seems really busy these days But I don't forget it

Hmm, too bad that text files are so difficult to implement. Maybe in version 0.9 then... We need a way to export CPLua programs as computer text files (this facility is very very useful, and should be implemented somehow).

[omegavirus]

the new Lua crashes my ClassPad here is what happened: first tap at the begining "nuevo (new)" it is the first option in the menu at the top then tap "cerrar (close)" in the menu where you change the keyboard, the font etc... and the it crashed... target= 0000007C PC=1004ACF4 ... thats all

[Kilburn]

I have the same bug But I have PC=1004AD04

[PAP]

the new Lua crashes my ClassPad here is what happened: first tap at the begining "nuevo (new)" it is hte fist option in the menu at the top then tap "cerrar (close)" in the menu where you change the keyboard, the font etc... and the it crashed... target= 0000007C PC=1004ACF4 ... thats all

In fact, this bug appears every time you use the "Close" menu option. I also get the hexadicimal number PC=1004ACF4 .

I also noticed another bug, concerning the editor. To reproduce the bug, open an existing file, then open another one. You will see that you cannot switch between them (if you press on the tabs to switch the file edited, nothing happens) . The only way to escape is to close one of these files. Note that this bug only appears in a new CPLua session; if you close one of the files, then open it again, it works as expected.

[Orwell]

Great news. All programs of LuaNumAn 1.50 are running flawlessly (14 large scripts). Even the DLMfit script works (traditionally, this script caused crashes in previous "candidate" versions, due to faulty grabage collection).

Actually I used DLMFit as benchmark to check the gain in performances concerning the memory usage
Note that the problem with those programs don't really come from the garbage collection; it's just that LuaNumAn is rather large, and each chunk loaded in Lua requires a lot of memory (3 to 5 times its size as source code! ). Btw, I noticed that you allways load the libraries at the beginning of each chunk. That means that even if you use a function at the very end of the program (LuaPlot for example), you reserve a lot of memory for it at the beginning, hence the memory crashes. Maybe you should consider using doscript() instead of require() for functions like LuaPlot: you may also pass some arguments to the called script, and return some value, but the advantage is that you only load the chunk when you really need it require() could also be used near the end of a program, not only at the beggining.

(1) The tabs in the editor windows are now resizing, in order to fit a filename which is long. In other words, a small (but annoying) bug has been removed.

Yes, but as you noticed it, there is now another strange bug I will have to find another workaround.

(2) The graphics window doesn't have a border, as in previous versions. Probably the border was an artifact from the console window, and it has been removed due to the windows refactoring. I think it is better as it is now.

In fact I had to remove it for better compatibility with the 'pict' functions

(3) A new directory named "CPLua" is created in CP when installing CPLua 0.8RC1. It includes only one file, named "Prefs". What is it? If I delete it, my ClassPad will explode?

It's just a file containing your preferences: the keyboard and the font you choosed (there will certainly be more options later). It is saved each time you close CPLua. I'm sorry about this, but I didn't have many choices

Hmm, too bad that text files are so difficult to implement. Maybe in version 0.9 then... We need a way to export CPLua programs as computer text files (this facility is very very useful, and should be implemented somehow).

If you just want to exchange Lua programs with text files on the computer, you can copy/paste the code from the emulator... Note there will never be a "magic tool" to transform a MCS files with Lua programs (even saved as TEXT variables) into a simple txt file on the computer... You will allways have to deal through the emulator. I agree it could be convenient to be able to save the output of a program however.

the new Lua crashes my ClassPad here is what happened: first tap at the begining "nuevo (new)" it is hte fist option in the menu at the top then tap "cerrar (close)" in the menu where you change the keyboard, the font etc... and the it crashed... target= 0000007C PC=1004ACF4 ...

Sigh... Certainly a problem coming from some last-minute change... Sorry, I will check this.

Thanks for your fast comments

[Kilburn]

The only way to escape is to close one of these files.

No, if you run the opened file, the bug disappears too.

It's just a file containing your preferences: the keyboard and the font you choosed (there will certainly be more options later). It is saved each time you close CPLua. I'm sorry about this, but I didn't have many choices

The shortcut list of My Programs is stored in the system folder. I discovered that in the Debug Mode, when I didn't have OS v.2.22. But Greg Williams is from Saltire, I guess, so........ secret functions.....

And a tiny bug that was here since CPLua 0.6x: When you turn on the tiny or small keyboard over a text, some pixels are 'stuck on the keyboard, and they don't disappear if you scroll the window.