Full Version: Project: Cplua
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
Orwell
Hmm ok, I definitely should not hurry to release a new version. dry.gif 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 sad.gif
Kilburn
Good luck wink2.gif
Orwell
CPLua 0.8B is available again.
Sorry to have been so long, I have a lot of work these days sad.gif

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... unsure.gif Of course any other comment is appreciated wink2.gif
PAP
QUOTE (Orwell @ Nov 27 2005, 04:06 PM) *
First, the good news:
(1) Data hiding seems to be fully respected now, as you announced.
(2) The "goto error" key <- is extremely useful rolleyes.gif.
(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
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" blink.gif. Furthermore, consider the following code:
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-" blink.gif. 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
CODE
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 unsure.gif Thanks, I will see what's happening.
I will see what's going on with the Cas too blink.gif

Btw, the "goto error" key is currently at an experimental state, I'm not sure that it allways works correctly unsure.gif 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 rolleyes.gif
Kilburn
QUOTE (Orwell @ Nov 27 2005, 06:04 PM) *
Oh that's right, Killburn already told me that the last character was lost with string concatenation, and I forgot about that unsure.gif


Huh? I told you that? Are you sure it was me? huh.gif
Orwell
Hmm, maybe it was Gaumerie then. wink2.gif
Anyway, all those problems have been fixed now smile.gif
unique33
The waitkey function does not work anymore.
-Tom-
QUOTE (unique33 @ Nov 28 2005, 01:31 AM) *
The waitkey function does not work anymore.


The same in my progs... Rest looks fine at the moment.
PAP
QUOTE (unique33 @ Nov 28 2005, 02:31 AM) *
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-
QUOTE (PAP @ Nov 28 2005, 07:25 PM) *
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:

CODE
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
QUOTE (-Tom- @ Nov 28 2005, 08:55 PM) *
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
QUOTE (PAP @ Nov 28 2005, 08:03 PM) *
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... huh.gif I will ask you to try it again with the coming version 0.8C anyway wink2.gif

QUOTE (unique33 @ Nov 28 2005, 09:44 PM) *
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... huh.gif
-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... huh.gif
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

banghead.gif

And sometimes you can have 80 atoms on the same grid... WITHOUT ANY EXPLOSION!!! cry.gif
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... huh.gif
Orwell
I couldn't find where this problem comes from neither... blink.gif 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 rolleyes.gif
PAP
QUOTE (Orwell @ Dec 2 2005, 10:11 PM) *
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.

QUOTE (Orwell @ Dec 2 2005, 10:11 PM) *
Perhaps I will try to use Lua 5.1 (beta) in the next versions rolleyes.gif
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). huh.gif
Orwell
QUOTE (PAP @ Dec 4 2005, 09:46 AM) *
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). huh.gif
CPlua 0.8A and 0.8B use Lua 5.1 alpha wink2.gif
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 unsure.gif )

CODE
    // 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-
yesnod.gif
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... dry.gif 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 smile.gif


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

Edit2: Okay, the following codes are now working correctly: smile.gif
CODE
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()

CODE
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:


CODE
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:

CODE
-- prints each couple of data's in the file
for i1, i2 in f:content(2) do
  print(i1, i2)
end
Guest_masda70_*
Here is something that seems to bug to me:

Basically I am running a loop to iterate every 10 pixels through x and y coordinates in order to draw stuff on what we can call a grid. Idraw a "O" every 10 pixels and then run a draw.update to make everything appear but 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 :/.

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. Thanks in advance for your help :).
Guest_masda70_*
Sorry to double post (I am considering registering later hehe) but I forgot to mention the bug is only happening in the calculator but not in the computer emulator.
Orwell
QUOTE (Guest_masda70_* @ Dec 6 2005, 10:19 PM) *
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. dry.gif

QUOTE
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 huh.gif

QUOTE (Guest_masda70_* @ Dec 6 2005, 10:21 PM) *
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 wink2.gif
masda70
Thank you very much wink2.gif, also it seems I had already registered but had forgotten it sleep.gif.
Orwell
CPLua 0.8C is available for download.
Look at the file "functions.txt" for short explanations about the new functions and package wink2.gif

I must admit I couldn't take the time to make deep tests on my ClassPad, but the Windows version seems to work fine smile.gif 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 rolleyes.gif
I didn't check the refresh of the screen however, so I'm afraid this bug will still be present :/
PAP
QUOTE (Orwell @ Dec 11 2005, 11:15 PM) *
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 blink.gif. 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
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 blink.gif. In general, if f is a cas object transported to CPLua, print(f()) or print(f(whatever)) causes a system hang.
Yikes. blink.gif

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... sad.gif But it's okay, you must have been busy during these last days wink2.gif

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 dry.gif 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... rolleyes.gif

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 sad.gif

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 lol2.gif I'll raise an error when you try to read too much things in the file then wink2.gif

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" huh.gif
PAP
QUOTE (Orwell @ Dec 12 2005, 01:49 AM) *
Erm, I was hoping that this kind of remarks would come a few days ago when I suggested the list of functions... sad.gif But it's okay, you must have been busy during these last days wink2.gif
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). sad.gif

QUOTE (Orwell @ Dec 12 2005, 01:49 AM) *
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.

QUOTE (Orwell @ Dec 12 2005, 01:49 AM) *
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... lol.gif

QUOTE (Orwell @ Dec 12 2005, 01:49 AM) *
However, I don't see the advantage of a function "fprintf" huh.gif
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
QUOTE (PAP @ Dec 12 2005, 01:36 AM) *
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... lol.gif
This is not a problem coming from the language, but rather from the SDK API dry.gif

QUOTE
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 wink2.gif
I just implemented a basis "printf" function btw (which made me see an ugly bug somewhere else dry.gif )

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
QUOTE (Orwell @ Dec 12 2005, 02:41 AM) *
Be careful not to write a string in your file, instead of a rounded number wink2.gif
Huh? huh.gif 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?

QUOTE (Orwell @ Dec 12 2005, 02:41 AM) *
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
QUOTE (PAP @ Dec 12 2005, 01:59 AM) *
Huh? huh.gif 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 smile.gif 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 biggrin.gif

QUOTE
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 wink2.gif

The archive has been updated. Many thanks for your quick tests smile.gif
PAP
QUOTE (Orwell @ Dec 12 2005, 03:07 AM) *
Because the elements you write in your file are serialized smile.gif 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 biggrin.gif
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:
CODE
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:
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 banghead.gif. 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
QUOTE (PAP @ Dec 12 2005, 11:33 AM) *
I thought that, to write formatted numbers to a file, I only need to modify slightly this code:
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:
CODE
require("string")
function FPrintf(file,form,...)
file:write(tonumber(string.format(form,unpack(arg))))
return
end
export{FPrintf=FPrintf}


QUOTE
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.org/wiki/Serialization rolleyes.gif

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 dry.gif
PAP
QUOTE (Orwell @ Dec 12 2005, 12:49 PM) *
Use "tonumber" to get a number from the string, before writing it:
CODE
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 wink2.gif.
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 huh.gif

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.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.