858 replies to this topic

[Orwell]

Hmm ok, I definitely should not hurry to release a new version. I'm removing CPLua 0.8B until tomorrow; it needs several modifications and I'm afraid that I won't be able to finish it now.
Sorry

[Kilburn]

Good luck

[Orwell]

CPLua 0.8B is available again.
Sorry to have been so long, I have a lot of work these days

I hope there will be less problems with this version. If you find something that does not seem to work correctly, or leads to a crash etc, please report it here... Of course any other comment is appreciated

[PAP]

CPLua 0.8B is available again.

First, the good news:
(1) Data hiding seems to be fully respected now, as you announced.
(2) The "goto error" key <- is extremely useful .
(3) Garbage collection is working again. The DLMfit script doesn't crash anymore; there is no need to add explicit collectgarbage() functions to avoid memory crashes. I have also tried to run all LuaNumAn scripts at once, using the "DemoAll" script. This means that I tried to run 12 scripts, taken from the upcoming LuaNumAn 1.50. Success!

Now, some strange things, concering the CAS:
Consider the code

foo1=cas("approx(1/100)")
foo2=cas("approx(1/1000)")
print(foo1,foo2)
print(foo1(),foo2())

The first print function prints "0.01 1E-3", as it should, so the problem concerning the exponential character seems to be fixed. However, it is not fully fixed: the second print function prints "0.01 nil" . Furthermore, consider the following code:

cas("OnePropZTest \">\",0.05,12,100")
pval=cas("approx(prob)")
print(pval)
print("probablility: "..pval)

This uses CAS to make a one-sample proportional test with p=0.05,S=12,N=100. Then the system variable "prob" is used to get the result (this is the unavoidable peculiar way that ClassPad's CAS uses to get the results of statistical commands). Now, the first print function prints: "6.594843063E-4", which is the value for the system variable "prob". However, the second print function prints: "probability: 6.594843063E-" . In general, print("whatever text"..prob) cuts the last character. Also try this code by changing p from 0.05 to 0.01. You will see that the result is 1.031889584E-28, but the second print function prints: "probability: 1.031889584E-2".
Now, consider to change the second line to

pval=cas("approx(prob)")()

The added parentheses are supposed to evaluate the CAS expression, but they don't: pval is nil.

[Orwell]

Oh that's right, Killburn already told me that the last character was lost with string concatenation, and I forgot about that Thanks, I will see what's happening.
I will see what's going on with the Cas too

Btw, the "goto error" key is currently at an experimental state, I'm not sure that it allways works correctly If someone can find out a situation where this key does not bring you to the erroneous line in the code, just let me know

[Kilburn]

Oh that's right, Killburn already told me that the last character was lost with string concatenation, and I forgot about that

Huh? I told you that? Are you sure it was me?

[Orwell]

Hmm, maybe it was Gaumerie then.
Anyway, all those problems have been fixed now

[unique33]

The waitkey function does not work anymore.

[-Tom-]

The waitkey function does not work anymore.

The same in my progs... Rest looks fine at the moment.

[PAP]

The waitkey function does not work anymore.

Strange. LuaPlot's functions PlotFunc and PlotData use waitkey(), and it works as expected (try it for yourself). Really strange.

[-Tom-]

Strange. LuaPlot's functions PlotFunc and PlotData use waitkey(), and it works as expected (try it for yourself). Really strange.

Yes, works, but not always. If I will write only one line of code I can be sure then that it will work, but most of my programs that worked very well in Lua 0.72 stop now on waitkey() It looks like program cannot see any pushed key any more...

Try this:

require("cas")

tabkl={}
tabzgp={}
l={}
s={}

function round(n,m)
foo=cas.fround(n,m)(0)
return foo
end

print("KRZYWA STATECZNOSCI\r-------------------//\rJesli gestosc wody jest niestandartowa to przejdz na obietosc:\r V=D/(ro*1,003) \r------------------------\rWejdz to danych hydrost. i odczytaj:\rT:")
T=input()
print(T .. "\rZm:")
zm=input()
print(zm .. "\rZg (tabela masowa):")
zg=input()
print(zg .. "\rCzy istnieja powierzchnie swobodne cieczy? \r(T[1],N[0])")
pyt=waitkey()-48

[PAP]

Yes, works, but not always. If I will write only one line of code I can be sure then that it will work, but most of my programs that worked very well in Lua 0.72 stop now on waitkey() It looks like program cannot see any pushed key any more...

I don't think that it is related to the length of the code then (LuaPlot is by far much more than one line of code). Maybe Orwell can figure out what's happenning.

[unique33]

when I use doscript (.8B) it seems that it just perform the operations but there is no output !
but ver.72 works as expected !

[Orwell]

I don't think that it is related to the length of the code then (LuaPlot is by far much more than one line of code). Maybe Orwell can figure out what's happenning.

I made some minor modifications and now everything seems to work fine... I will ask you to try it again with the coming version 0.8C anyway

when I use doscript (.8B) it seems that it just perform the operations but there is no output !
but ver.72 works as expected !

It works fine on my calculator...

[-Tom-]

Hi!
Is a bug with waitkey() already corrected?

[Orwell]

Actually it works fine on my calulator, I couldn't find any problems with it...

[Kilburn]

Hi! As I told Orwell on MSN, there seems to be a bug in tables. Here is a game I created

You have a grid like this

000000000
000000000
000000000
000000000
000000000
000000000
000000000
000000000
000000000

I'll show you only a portion of the gridn for example

000
000
000

You must put atoms on the grid, and when there are 4 atoms on the same cell, they explode and spread on the 4 cells around: For example (CPLua 0.73 RC2)

000 000 000 000 010
000 010 020 030 101
000 000 000 000 010

BUT in CPLua 0.8B you have

000 000 000 000 020
000 010 020 030 202
000 000 000 000 020



And sometimes you can have 80 atoms on the same grid... WITHOUT ANY EXPLOSION!!!
Sorry my source code is quite uncomprehensible, but I will try to correct it. The function endloop() manages the grid and explosion of the atoms.

I give you this game because I couldn't reproduce the bug on another program...

[Orwell]

I couldn't find where this problem comes from neither... The same code runs differently on CPLua 0.72 and CPLua 0.8B.
I don't know if it is a problem with the tables though, since PAP is also using it intensively for matrix operations and didn't report any problem (yet?)
Perhaps I will try to use Lua 5.1 (beta) in the next versions

[PAP]

I don't know if it is a problem with the tables though, since PAP is also using it intensively for matrix operations and didn't report any problem (yet?)

Indeed, I haven't noticed any problem concerning tables yet, although LuaNumAn uses tables extensively. When I add a new method I'm testing all LuaNumAn algorithms by comparing the results with those obtained by a Fortran 95 program, running on my PC: I get exactly the same results, I haven't noticed even a slight difference.
Just an idea: Maybe the problem is related to the peculiar way that Lua uses to perform arithmetic operations; we have already encountered such a problem concerning the "mat" package. Of course, here we speak about tables, not matrices, but you never know...
Btw, as soon as the "io" package will be available, I'm planning to add a test program. This program will run all LuaNumAn driver scripts and it will compare the results obtained with the correct results, stored in a file.

Perhaps I will try to use Lua 5.1 (beta) in the next versions

I'm surprised with this statement: I thought that CPLua versions 0.8x already use Lua 5.1 beta, as you announced (table.getn() is obsolete, table.setn is an error).

[Orwell]

I'm surprised with this statement: I thought that CPLua versions 0.8x already use Lua 5.1 beta, as you announced (table.getn() is obsolete, table.setn is an error).

CPlua 0.8A and 0.8B use Lua 5.1 alpha

[Orwell]

By the way, speaking of the 'io' package:
I've been working on it yesterday, and here is the list of functions that I'd like to implement. Feel free to give me your comments on it (if I forgot something, or if it could be easier etc )

// Returns a handle on the folder "dirName"
d = io.folder(dirName)

	// Returns true if this folder exists
b = d:exists()

	// Creates the folder (does nothing if it already exists)
	// Raises an error in case of failure
d:create()

	// Removes the folder
	// Raises an error in case of failure
d:remove()

	// Rename the folder
	// Raises an error in case of failure
d:rename(name)

	// Returns the folder's name	
s = d:name()

	// Returns a table of strings with this folder's files names
t = d:content()



	// Returns a handle on the first file matching the search criteria's
	// or nil if no file was found
f = io.findf(folder,name)

	// Returns a handle on the next file matching the same criteria's,
	// or nil if no file was found
f = io.findn()



	// Returns a handle on the file "folderName/fileName"
f = io.file(folderName,fileName)

	// Returns true if this file exists
b = f:exists()

	// Create or initialize the file, by specifying its header 
	// (application name, data name, major version, minor version)
	// Raises an error in case of failure
f:create(app, type, majv, minv)

	// Removes the file
	// Raises an error in case of failure
f:remove()

	// Renames the file (or move it)
	// Raises an error in case of failure
f:rename(dirName,fileName)

	// Makes a copy of the file in "dirName/fileName"
	// Raises an error in case of failure
f:copy(dirName,fileName)

	// Returns the header (as a table), the folder name, the name, the size of the file
h = f:header() // h = { app=s1, type=s2, majv=s3, minv=s4 }
s = f:folder()	
s = f:name()
n = f:size()

	// Opens the file. Mode = 
	//	'r' -> Reading (can read numbers, strings, tables, booleans, or nil)
	//	'w' -> Writing (the file's content is erased first)
	//	'a' -> Appending (write at the end of the file's content)
	//	'b' -> Binary data's (Reading only; contains large data like sprites etc)
	// Raises an error in case of failure
f:open(mode)

	// Writes some things in the file (modes 'w' or 'a' only)
	// You may actually write a table with numbers, strings, booleans, or embedded tables;
	// but there cannot be functions, userdatas or threads in it
f:write(sth_1,sth_2,...)

	// Reads "n" things in the file (mode 'r' only)
sth_1,sth_2,...,sth_n = f:read(n)
b = f:eof()	// Returns true if the end of the file was reached (nothing more to read)

	// Access to a binary "slot" (mode 'b' only)
	// Those "slots" contains binary data that cannot be directly use in a Lua program,
	// but they can be passed to a C function to draw a sprite, or create another font etc
slot_i = fb:get(i)
slot_i = fb[i]

	// Closes the file
f:close()

[-Tom-]

When can expect it?
I think 'com' functions would be also useful... 3pin-->3pin or even, if possible CP-->PC

[Orwell]

It depends on the time I will have... Let's say 2 or 3 weeks in the worst case.
But maybe we won't have to wait that long: after today's work the functions "read" and "write" can already save and load strings, numbers, and booleans


Edit: ... I had written something stupid here. Just forget it in case you saw it

Edit2: Okay, the following codes are now working correctly:

require "io"

f = io.file("main","test")
if f:exists() == false then
  f:create("MyApp","MyData")
end

f:open('w')
f:write(1.23456, true, "hello!")
f:close()

require "io"

f = io.file("main","test")

f:open('r')
print( f:read(3) ) -- prints "1.23456   true   hello!"
f:close()

[Orwell]

Finally I won't allow the users to store nil values in the files.
This has several advantages, especially when we want to read a file with an unknown size; we can now use loops more easily:

require "io"

f = io.file("main","test")
f:open('r')

-- a first way to print each element of the file:

i = f:read()
while i ~= nil do
  print(i)
  i = f:read()
end

-- a better way to do the same thing:

while f:eof() == false do
  print( f:read() )
end

-- and even better:

for i in f:content() do
  print(i)
end

f:close()

Note that like the function f:read(), the function f:content()may have an argument specifying the numbers of elements to read between each iteration, so we could write something like this:

-- prints each couple of data's in the file
for i1, i2 in f:content(2) do
  print(i1, i2)
end

[Orwell]

the problem is that there are parts that do not appear, and in the case of this example that's the bottom right part of the grid. I can make the stuff appear if I call the keyboard and then remove it (or if it is already there just remove it) but that doesn't feel right and in addition the keyboard leaves a black line in the place of its top limit on the screen :/.

Seems like there is a problem with the 'refresh' operation... I'll take a look.

Also I am looking for a way to remove characters written through draw.text(). I thought I could draw a blank square (as in " " which is a space) but that doesn't work at all.

Be sure to draw a plain rectangle (not only its border); check the arguments of draw.rect . It should work... If it doesn't, this is a bug

I forgot to mention the bug is only happening in the calculator but not in the computer emulator.

I already knew that, because the 'refresh' operation is completely different in the two versions

[masda70]

Thank you very much , also it seems I had already registered but had forgotten it .

[Orwell]

CPLua 0.8C is available for download.
Look at the file "functions.txt" for short explanations about the new functions and package

I must admit I couldn't take the time to make deep tests on my ClassPad, but the Windows version seems to work fine Let me know if any problem appears.

I'd like to know if you encounter the same problem with waitkey() in this version... If it happens again, try clicking with the pen in the window before hitting a key. If it works after that, then it is a problem with focus between windows and I'll have to correct it
I didn't check the refresh of the screen however, so I'm afraid this bug will still be present :/

[PAP]

CPLua 0.8C is available for download.

First of all, I have to report an ugly bug concerning the "cas" package. Consider the following simple code:

require("cas")
f=cas("sin(x)")
print(f)
print(f(2))

The first print works as expected, but the second produces... a fatal error . In general, if f is a cas object transported to CPLua, print(f()) or print(f(whatever)) causes a system hang.

Now, some remarks concerning the new "io" package:
(1) It would be very nice if "io" can save "TEXT" files, so that we can read them outside CPLua. It would be also useful to be able to read "TEXT" files created outside CPLua. As it is now, the "io" package can only handle "MEM" files (variables). If you try to open a "TEXT" file, you get a "Bad file format" error. I don't know if this is difficult to be implemented (I suspect it is). Btw, it would be also very nice if we could export CPLua programs ("MEM" variables) as normal text; this will permit to pass our programs (in text form) in the computer, then print them.
(2) The syntax of the io's read() function is rather inconvenient. It would be more convenient if the number of items to read can be set to "auto", which means "read as many variables as the left-hand side". For example, if you want to read 3 variables from a file, you have to use a,b,c=foo:read(3). It would be better if the syntax can be modified, so that a,b,c=foo:read() is valid, and equivalent to a,b,c=foo(3), not to a,b,c=foo(1), which is now the default.
(3) Even if a file contains only two items, you can issue a,b,c,d=foo:read(4); if you do, variables c and d take the "nil" value, but you don't get an "end of file error", as I was expecting. This is very dangerous. In a complex program, you may (by mistake) require to read more variables than those saved in a file; if you do, you will not be warned that the flie pointer exceeded the actual length of the file. Of course, you can use a loop until foo:eof(), but very often you know (or you think you know) how many variables are saved in a file. If, for some reason one variable is missing, you will not be warned.

Btw, now that file input-output is implemented, the implementation of C-like functions "printf" and "fprintf" is more urgent than ever...

[Orwell]

First of all, I have to report an ugly bug concerning the "cas" package. Consider the following simple code:

require("cas")
f=cas("sin(x)")
print(f)
print(f(2))

The first print works as expected, but the second produces... a fatal error . In general, if f is a cas object transported to CPLua, print(f()) or print(f(whatever)) causes a system hang.

Yikes.

Now, some remarks concerning the new "io" package:

Erm, I was hoping that this kind of remarks would come a few days ago when I suggested the list of functions... But it's okay, you must have been busy during these last days

(1) It would be very nice if "io" can save "TEXT" files, so that we can read them outside CPLua. It would be also useful to be able to read "TEXT" files created outside CPLua. As it is now, the "io" package can only handle "MEM" files (variables). If you try to open a "TEXT" file, you get a "Bad file format" error. I don't know if this is difficult to be implemented (I suspect it is). Btw, it would be also very nice if we could export CPLua programs ("MEM" variables) as normal text; this will permit to pass our programs (in text form) in the computer, then print them.

Hmmm... This is certainly not easy. I spent a little bit time wondering what kind of files we should be able to manage with this system, and I finally came to the conclusion that CPLua should use its own files, and nothing more.
It's true that I didn't consider the case of TEXT files, however I think it wouldn't be easy to use... Writing text files from Lua shouldn't be a real problem since I can convert most types into strings, but reading it would be a real nightmare The data's stored in Lua Mem files are serialized, so I can "easily" extract them separately, but I guess that in a TEXT files you only have plain text, thus the only way to read it (in C++) would be by extracting each character separately. That means that I would have to implement some functions to extract complete words and not only letters, or rather complete sentence instead of words; but we will never be able to get strings back in the same way that we had written it in the file...
For now, i think that TEXT support is only a headache. Maybe for later...

(2) The syntax of the io's read() function is rather inconvenient. It would be more convenient if the number of items to read can be set to "auto", which means "read as many variables as the left-hand side". For example, if you want to read 3 variables from a file, you have to use a,b,c=foo:read(3). It would be better if the syntax can be modified, so that a,b,c=foo:read() is valid, and equivalent to a,b,c=foo(3), not to a,b,c=foo(1), which is now the default.

I agree, but I have absolutely no way to know how many arguments are expected when you call a function

(3) Even if a file contains only two items, you can issue a,b,c,d=foo:read(4); if you do, variables c and d take the "nil" value, but you don't get an "end of file error", as I was expecting. This is very dangerous. In a complex program, you may (by mistake) require to read more variables than those saved in a file; if you do, you will not be warned that the flie pointer exceeded the actual length of the file. Of course, you can use a loop until foo:eof(), but very often you know (or you think you know) how many variables are saved in a file. If, for some reason one variable is missing, you will not be warned.

Hmm you're right, I sometimes forget that those kind of stupid errors may happen I'll raise an error when you try to read too much things in the file then

Btw, now that file input-output is implemented, the implementation of C-like functions "printf" and "fprintf" is more urgent than ever...

I've been thinking about it, but I wasn't sure that it was really needed, because generally you may use string concatenation to print a complex sentence... but it's true that you cannot specify a special format for printing numbers with only concatenation.
However, I don't see the advantage of a function "fprintf"

[PAP]

Erm, I was hoping that this kind of remarks would come a few days ago when I suggested the list of functions... But it's okay, you must have been busy during these last days

You are right, the remarks about the "io" package should be posted some days before. Sorry, but, like you said, I was very busy these days (and I'm still be).

I finally came to the conclusion that CPLua should use its own files, and nothing more.

It's ok. However, transferring our programs to a computer in a readable format will be very useful. Maybe someone can write an Add-In to convert "MEM" files to "TEXT" files, or -even better- to plain ascii text.

I guess that in a TEXT files you only have plain text, thus the only way to read it (in C++) would be by extracting each character separately.

Aaargh, poor C/C++ again... I can't resist to the temptetion to say that reading/writing a file containing strings, together with variables, matrices, and everything else you want is a problem solved in Fortran more than 30 years ago...

However, I don't see the advantage of a function "fprintf"

There is an advantage: you can easily store rounded real numbers. Of course, you can do such a thing without fprintf, but it's not convenient to do so. Not a big problem, though: I will simply add a Lua version of fprintf in LuaUtils, as I did with printf...

[Orwell]

Aaargh, poor C/C++ again... I can't resist to the temptetion to say that reading/writing a file containing strings, together with variables, matrices, and everything else you want is a problem solved in Fortran more than 30 years ago...

This is not a problem coming from the language, but rather from the SDK API

There is an advantage: you can easily store rounded real numbers. Of course, you can do such a thing without fprintf, but it's not convenient to do so. Not a big problem, though: I will simply add a Lua version of fprintf in LuaUtils, as I did with printf...

Be careful not to write a string in your file, instead of a rounded number
I just implemented a basis "printf" function btw (which made me see an ugly bug somewhere else )

By the way... Implementing some small functions like Printf or Fprintf in separated chunks isn't really a good idea, because generally you need to load some package for it; and each time you load a package in a new chunk you reserve a few Kb to hold it, and thus you are consuming a lot of memory just for some small utility functions :/

[PAP]

Be careful not to write a string in your file, instead of a rounded number

Huh? That's exactly what I was planning to do. I'm a little bit frustrated now: If I save a rounded number as a string, then close and open the file again, how could CPLua "know" that this was once upon a time saved as a string, not as a number?

By the way... Implementing some small functions like Printf or Fprintf in separated chunks isn't really a good idea, because generally you need to load some package for it; and each time you load a package in a new chunk you reserve a few Kb to hold it, and thus you are consuming a lot of memory just for some small utility functions :/

You are right, but they could fit to the "io" package; afterall, they are output functions.

[Orwell]

Huh? That's exactly what I was planning to do. I'm a little bit frustrated now: If I save a rounded number as a string, then close and open the file again, how could CPLua "know" that this was once upon a time saved as a string, not as a number?

Because the elements you write in your file are serialized That means that the type is saved with the value, so you can save more specific objects instead of simple strings. This give us a lot more possibilities

You are right, but they could fit to the "io" package; afterall, they are output functions.

I will let it as a basis function for now, perhaps I will move it later if I add some other functions in the IO package

The archive has been updated. Many thanks for your quick tests

[PAP]

Because the elements you write in your file are serialized That means that the type is saved with the value, so you can save more specific objects instead of simple strings. This give us a lot more possibilities

To be honest, I can't imagine such a possibility. On the other hand, as it is now, it makes the Lua implementation of fprintf much more complex than printf. To print formatted numbers to the screen you simply need to convert them to strings, then to print formatted strings using the string.format() function:

require("string")
function Printf(form,...)
print(string.format(form,unpack(arg)))
return
end
export{Printf=Printf}

I thought that, to write formatted numbers to a file, I only need to modify slightly this code:

require("string")
function FPrintf(file,form,...)
file:write(string.format(form,unpack(arg)))
return
end
export{FPrintf=FPrintf}

Unfortunately, this does not work, since everything saved in the file is actually a string, and, like you said, the type of each argument is saved to the file (it's the first time I see such a behavior in a programming language). To overpass the problem you need to reconvert the formatted strings to numbers; however, to do so, you need to keep track of what each argument of fprintf was before the conversion to a string . It can be done, but it is annoying. I think that there are two solutions: change the way something is saved to a file, or, if this is difficult, add a function similar to string.format, but able to act to numbers, not only strings.

[PAP]

A note about file:open() function: As it is now, it permits to: write a file ("w"), read a file ("r"), or append to the contents of a file ("a"). These are, indeed, the most common things the user wants to do. However, if a file exists, file:open("w") deletes its previous contents silently. It would be nice to modify the behavior of file:open("w") so that it prints a warning or error message, if the file exists. However, this needs the implementation of another option, say file:open("R"), which means "create the file, if it doesn't exist, or replace the old file silently, if it exists". Note that this modification is not urgent at all: file:open() is quite functional, as it is now; if, however, it isn't difficult to modify it as I suggested, it would be nice.

[Orwell]

I thought that, to write formatted numbers to a file, I only need to modify slightly this code:

require("string")
function FPrintf(file,form,...)
file:write(string.format(form,unpack(arg)))
return
end
export{FPrintf=FPrintf}

Unfortunately, this does not work, since everything saved in the file is actually a string

Use "tonumber" to get a number from the string, before writing it:

require("string")
function FPrintf(file,form,...)
file:write(tonumber(string.format(form,unpack(arg))))
return
end
export{FPrintf=FPrintf}

the type of each argument is saved to the file (it's the first time I see such a behavior in a programming language).

http://en.wikipedia....i/Serialization

Don't forget that you are not writing text files, but data files. If you want to round your numbers, and get them back later, then it is a rounding operation that has nothing to do with the manipulation of the file itselfs

[PAP]

Use "tonumber" to get a number from the string, before writing it:

require("string")
function FPrintf(file,form,...)
file:write(tonumber(string.format(form,unpack(arg))))
return
end
export{FPrintf=FPrintf}

I know, I have to use the tonumber function, but what if I want to save a string, among others? tonumber("foo") returns nil, so I cannot save strings using the above version of FPrintf (only numbers can be saved). That's why I said that you need to keep track of what an argument was before converting to a string .

[Orwell]

The only "advantage" of this function would be to be able to save rounded numbers in a file... I can't find any situation where this feature would be really useful

Edit: Again, remember that fprintf() (in C) is mainly used to write text files. But here there is basically no need to format the elements before writing it, since the purpose of those files is to save the objects themselves, and not their content.