
Sorry

Posted 19 November 2005 - 07:52 PM
Posted 19 November 2005 - 08:26 PM
Posted 27 November 2005 - 02:06 PM
Posted 27 November 2005 - 04:55 PM
First, the good news:
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"
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-"
pval=cas("approx(prob)")()The added parentheses are supposed to evaluate the CAS expression, but they don't: pval is nil.
Posted 27 November 2005 - 05:04 PM
Posted 27 November 2005 - 06:36 PM
Oh that's right, Killburn already told me that the last character was lost with string concatenation, and I forgot about that
Posted 27 November 2005 - 08:57 PM
Posted 28 November 2005 - 12:31 AM
Posted 28 November 2005 - 12:58 PM
The waitkey function does not work anymore.
Posted 28 November 2005 - 06:25 PM
Strange. LuaPlot's functions PlotFunc and PlotData use waitkey(), and it works as expected (try it for yourself). Really strange.The waitkey function does not work anymore.
Posted 28 November 2005 - 07:02 PM
Strange. LuaPlot's functions PlotFunc and PlotData use waitkey(), and it works as expected (try it for yourself). Really strange.
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
Posted 28 November 2005 - 07: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.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...
Posted 28 November 2005 - 08:44 PM
Posted 28 November 2005 - 09:34 PM
I made some minor modifications and now everything seems to work fine...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.
It works fine on my calculator...when I use doscript (.8B) it seems that it just perform the operations but there is no output !
but ver.72 works as expected !
Posted 02 December 2005 - 07:01 PM
Posted 02 December 2005 - 07:42 PM
Posted 02 December 2005 - 07:44 PM
Posted 02 December 2005 - 08:11 PM
Posted 04 December 2005 - 08:46 AM
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.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?)
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).Perhaps I will try to use Lua 5.1 (beta) in the next versions
Posted 04 December 2005 - 09:58 AM
CPlua 0.8A and 0.8B use Lua 5.1 alphaI'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).
Posted 04 December 2005 - 10:33 AM
// 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()
Posted 04 December 2005 - 11:50 AM
Posted 04 December 2005 - 06:32 PM
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()
Posted 04 December 2005 - 10:44 PM
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()
-- prints each couple of data's in the file for i1, i2 in f:content(2) do print(i1, i2) end
Posted 06 December 2005 - 09:19 PM
Posted 06 December 2005 - 09:21 PM
Posted 06 December 2005 - 09:26 PM
Seems like there is a problem with the 'refresh' operation... I'll take a look.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 :/.
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 bugAlso 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.
I already knew that, because the 'refresh' operation is completely different in the two versionsI forgot to mention the bug is only happening in the calculator but not in the computer emulator.
Posted 07 December 2005 - 12:44 AM
Posted 11 December 2005 - 09:15 PM
Posted 11 December 2005 - 11:22 PM
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
Posted 11 December 2005 - 11:49 PM
Yikes.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.
Erm, I was hoping that this kind of remarks would come a few days ago when I suggested the list of functions...Now, some remarks concerning the new "io" package:
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.(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.
I agree, but I have absolutely no way to know how many arguments are expected when you call a function(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.
Hmm you're right, I sometimes forget that those kind of stupid errors may happen(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.
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.Btw, now that file input-output is implemented, the implementation of C-like functions "printf" and "fprintf" is more urgent than ever...
Posted 12 December 2005 - 12:36 AM
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).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
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 finally came to the conclusion that CPLua should use its own files, and nothing more.
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...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.
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...However, I don't see the advantage of a function "fprintf"
Posted 12 December 2005 - 12:41 AM
This is not a problem coming from the language, but rather from the SDK APIAaargh, 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...
Be careful not to write a string in your file, instead of a rounded numberThere 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...
Posted 12 December 2005 - 12:59 AM
Huh?Be careful not to write a string in your file, instead of a rounded number
You are right, but they could fit to the "io" package; afterall, they are output functions.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 :/
Posted 12 December 2005 - 01:07 AM
Because the elements you write in your file are serializedHuh?
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?
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 packageYou are right, but they could fit to the "io" package; afterall, they are output functions.
Posted 12 December 2005 - 10:33 AM
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: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
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
Posted 12 December 2005 - 10:44 AM
Posted 12 December 2005 - 10:49 AM
Use "tonumber" to get a number from the string, before writing it: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
require("string") function FPrintf(file,form,...) file:write(tonumber(string.format(form,unpack(arg)))) return end export{FPrintf=FPrintf}
http://en.wikipedia....i/Serializationthe type of each argument is saved to the file (it's the first time I see such a behavior in a programming language).
Posted 12 December 2005 - 11:29 AM
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 stringUse "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}
Posted 12 December 2005 - 11:49 AM
0 members, 2 guests, 0 anonymous users