Murga-Projects Forums

Full Version: Maintenance release - 0.6.6
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

This will be a very minor release that'll address a couple of small issues and incorporate the latest beta builds of FLTK 1.1.8 ... Which have some exciting features/bugfixes (like updated image libs and fixed read_image behavior).

If there are any small issues that you guys would like me to address in this release please let me know before Friday.

There will also be limited testing on Win98 and Vista ...
As opposed to just Linux (32 and 64 bit as of 0.6.4), Windows XP and MacX intel.

I intend to release on Sunday.

Cheers
JohnM
You tease!
I thought this was a release thread.... =opppppp

Maybe a small issue....do you know if the pixel shift in images sliced with getTiles is related to fl_read_image? If so, is this fix related to that issue?

Apart from that I can't recall having any outstanding problems with the current release. There are a few things I've noticed missing from FLTK, but nothing I'd consider important.

One thing that might be kinda cool for some point in the future is the use of Fl_Window:icon().

mikshaw Wrote:
Maybe a small issue....do you know if the pixel shift in images sliced with getTiles is related to fl_read_image? If so, is this fix related to that issue?

I suspect not, so I'll look into it.

mikshaw Wrote:
One thing that might be kinda cool for some point in the future is the use of Fl_Window:icon().

That'll be a little bit of a pain ... It works differently on Windows and Linux, so I'd want to wrap it, furthermore, I am not sure if it works on MacOsX.

I'll have a play later.

Cheers
JohnM

Hey John, you wanna test something in the file choosers.

Quote:
When I go to choose a file, a list of folders appear as they should, but when
I click on a folder, it jumps out to the directory outside where I was looking,
I have to go digging back into the directory I was in the first place.
Also this behavior presents itself if I click on one of the dialog menus (choices whatever they are).


--- EDIT ---
Found the reason for this, the initial path for the chooser was set without an ending slash, ie:
"/Volumes/Drive/Folder"
when set to
"/Volumes/Drive/Folder/"
All works perfectly!


Oh and can we get Alpha channeled images from the off screen draw? that would be great!

Hows that 0.6.6 coming along?
Do I have a chance to sneak in a little function request?

Problem: Tobi has created a "collect" feature that will gather assorted files and copy them to a destination.
Currently he's using io.open to read the files and then writing them back at the new location.
However its very slow this way, the larger the file gets the slower the process.

We could use os.execute(cp source dest) but that won't work on Windows.
I expected Lua File System to have such functionality but, seems it doesn't.

Think you could provide something at the murgaLua level?

iGame3D Wrote:
Hows that 0.6.6 coming along?
Do I have a chance to sneak in a little function request?

Problem: Tobi has created a "collect" feature that will gather assorted files and copy them to a destination.
Currently he's using io.open to read the files and then writing them back at the new location.
However its very slow this way, the larger the file gets the slower the process.

We could use os.execute(cp source dest) but that won't work on Windows.
I expected Lua File System to have such functionality but, seems it doesn't.

Think you could provide something at the murgaLua level?


Actually that functionality isn't even available (on the API level) on UNIX/POSIX (afaik). I don't know if Windows has a copy library function, but I haven't seen any on Unix.

Why does does os.execute not work? You have copy or xcopy on windows. Also for larger junks it makes often sense to use tar -c | tar -x or cpio to do the copy. Under a few circumstances this can be significantly faster.

And yes copying with Lua is a lot slower compared with C. I guess immutable strings don't really help here. I also did a few tests a few months ago and found that murgaLua has a 30% overhead (file io) compared to the stock SuSE Lua binary (and also a self compiled one).

Btw. for Windows there is a "run" utility available which can suppress the console window.

Juergen

Juergen Wrote:
Why does does os.execute not work?
You have copy or xcopy on windows.

os.execute would work, but writing hacky workarounds per operating system isn't the most ideal solution.

Juergen Wrote:
Also for larger junks it makes often sense to use tar -c | tar -x or cpio to do the copy.
Under a few circumstances this can be significantly faster.

Are these available as a default on Windows?
From a quick google search, apparently not.
I'm not sure how large of a chunk you mean.
I don't expect to move anything greater than two megs per file.

Juergen Wrote:
Btw. for Windows there is a "run" utility available which can suppress the console window.

I never see a console window in the windows emulator even when I want one. Can't run murgaLua or any command line for windows in emulation, even the command prompt replacement program won't take keyboard input, I'm guess because of some Windows OS dependency that can't be emulated because there is no actual Windows OS installed.

When one can use simple pure lua or LFS commands to lock, create, or delete directories and files, does it make any sense to not be able to do the same with moving some files?

It certainly doesn't make any sense to wait four minutes for ten megs of files to copy on a 1ghz machine.

At any rate I put an email into the Kepler project about this.
Maybe they will update with something more than windows only features in the next release.

Quote:
os.execute would work, but writing hacky workarounds per operating system isn't the most ideal solution.

I don't think it should be much of an issue. There are only three OSs to be concerned about, and two use the same copy command.

Code:
if murgaLua.getHostOs()=="windows" then copy="xcopy" else copy="cp" end
for file in lfs.dir(some_directory) do -- as an example
os.execute(copy.." "..file.." "..target)
end


Quote:
When one can use simple pure lua or LFS commands to lock, create, or delete directories and files, does it make any sense to not be able to do the same with moving some files?

I agree with this, although I never really noticed it before since I haven't done much work with managing files in Lua. It seems strange in particular that you can move a file but not copy it.

I think it should be solved at the appropriate level which is LFS itself.

We aren't the only ones who will be using it as a solution for file access and then coming up with work arounds for
this basic functionality that really seems implied by the nature of the library.

In the meantime we'll just add some functions to the lua script and be patient.

Reading every file into memory might be something we actually want to do anyway.
For mass editing, error checking, encoding , putting into databases, converting to syntax hi-lighted html, transmitting over the internet and such.

iGame3D Wrote:
Hows that 0.6.6 coming along?
Do I have a chance to sneak in a little function request?


Done, but it's probably going to delay things ...

Cheers
JohnM

Pages: 1 2
Reference URL's