QUOTE (PAP @ Dec 12 2005, 12:22 AM)

First of all, I have to report an ugly bug concerning the "cas" package. Consider the following simple code:
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.
QUOTE
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

QUOTE
(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...

QUOTE
(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

QUOTE
(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

QUOTE
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"