Murga-Projects Forums
Initial build of version 0.6.0 - Printable Version

+- Murga-Projects Forums (http://www.murga-projects.com/forum)
+-- Forum: Project Forums (/forumdisplay.php?fid=1)
+--- Forum: MurgaLua - General (/forumdisplay.php?fid=2)
+--- Thread: Initial build of version 0.6.0 (/showthread.php?tid=261)


Initial build of version 0.6.0 - JohnMurga - 01-19-2008 08:30 PM

EDIT

THIS BUILD HAS BEEN UPDATED, PLEASE GO TO THIS THREAD FOR INFO AROUND THE NEW VERSION

http://www.murga-projects.com/forum/showthread.php?tid=264

-

Hi,

Uploaded a few hours later than I hoped due to a series of problems ...

Here is a preview build of the next stable version of murgaLua.

This is mostly a clean and stable release, the new experimental API's are in the experimental release that I'll do after I'm done with this one.

I hope to do the proper release of 0.6.0 tomorrow or Monday ...

Known Issues with these binaries :
  • Only included binaries for all platforms (except PowerPC), and a couple of test scripts for testing.
  • Version number will be incorrect
  • I updated the initial upload, so if you have a corrupt file please download again.
And the rough change log is as follows :
  • MurgaLua compiler beta (see COMPILER-LICENCE for terms of use).
    (This has been tested on all platforms including MacOS)
  • Many small FLTK fixes, binding corrections and upgrade to build r6021.
    (Not all of these are tested yet, and yes, that is yesterday's build :-) )
  • Upgrades to luasocket, copas, luafilesystem and lsqlite.
  • Integrated md5, added a couple of HEX encoding functions and a rounding function.
  • Lots of build tweaks for all platforms (in terms of size, options, etc).
    This release is smaller than the 0.5 series with more features ;-)
  • Minor updates to the documentation (not in this tar).
  • Refactored how the FLTK bindings are updated, making things MUCH easier for myself.
  • user_data() methods for all widgets and menu items is implemented.
    (This allows for much neater menus and event handling in general)
  • Fl_Image.data() method implemented for all image types.
    (Creates a table that allows for manipulation of images)
  • Fl_Pixmap constructor implemented along with rotation demo.
    (Now all image types can be created programatically)
There are many minor FLTK changes that I haven't had time to document, but things should be a bit better overall ... And I plan to re-write the pixmap rotation function in C, although it makes a fine example in Lua for now :-).

Please give it a go and let me know if you have problems.

Have a look at the examples dir for demonstrations of the new features.

And finally you can find it here :

http://www.murga-projects.com/murgaLua/murgaLua-0.6.PRE-RELEASE.tar.gz

I hope you like it.

Cheers
JohnM


RE: Initial build of version 0.6.0 - xleitex - 01-19-2008 11:06 PM

Hi...

Have a Little Problem...of course that its initial build
When i call murgaLua by Windows "shell" appears this message...

Code:
               2 pasta(s) 50.555.367.424 bytes disponíveis

C:\murgaLua\bin\Windows>murgalua
murgalua: [string "murgaLua"]:207: attempt to index global 'inf' (a nil value)
stack traceback:
        [string "murgaLua"]:207: in function 'decompileMurgaLua'
        [string ""]:1: in main chunk
        [C]: ?
MurgaLua Version 0.5.5 (http://www.murga-projects.com/murgaLua/)
MurgaLua & FLTK/XML bindings : Copyright 2006-7 John Murga, GPL license.
Contains lsqlite by T.Dionizio, LuaSocket by D.Nehab and other bindings.
Lua 5.1.2  Copyright (C) 1994-2007 Lua.org, PUC-Rio
>


Tested on Windows Xp sp2,,,Sorry for my poor english!

Thx


RE: Initial build of version 0.6.0 - JohnMurga - 01-19-2008 11:18 PM

xleitex Wrote:
Tested on Windows Xp sp2,,,Sorry for my poor english!


Weird ...

Took me a while to reproduce ...

It only happens if you invoke murgaLua on Windows without the ".exe" and without parameters.

If you double click on it in explorer, or run scripts with it, or invoke it as "murgaLua.exe", it is fine.

Either way I fixed it in the code.

Thanks for the report :-)

Cheers
JohnM


RE: Initial build of version 0.6.0 - iGame3D - 01-19-2008 11:48 PM

On iMac Intel OS X 10.4 its working fine.

I got some artifact from from the image rotation with an image I had on my desktop, rotated around an odd center point, it left some graphics inside the border frame of the scrollbar.

This didn't occur with your demo images, they rotated around a proper center. The image I used was an animated one, an A-bomb explosion that starts small, and gets large, so its initial center point is in a weird location, attached to thread.

How does this compiler magic work? Its set for some linux directory so I'm stumped.

Something looks different, looks better? Maybe my imagination.


RE: Initial build of version 0.6.0 - znarf - 01-20-2008 12:07 AM

Hi all,

I tested the new release under Linux Ubuntu 7.10 x86 and under Windows Vista x64. All my personal scripts and the examples worked fine.
The compiler is really a nifty feature! Is it possible to integrate also resource data such as PNGs in the executables?

Thanks for this fine piece of software,
Gerald


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 12:15 AM

iGame3D Wrote:
On iMac Intel OS X 10.4 its working fine.

I did the build on that :-)

iGame3D Wrote:
I got some artifact from from the image rotation with an image I had on my desktop, rotated around an odd center point, it left some graphics inside the border frame of the scrollbar.

This didn't occur with your demo images, they rotated around a proper center. The image I used was an animated one, an A-bomb explosion that starts small, and gets large, so its initial center point is in a weird location, attached to thread.

The rotation algorithm implementation is not very good as I didn't really know what I was doing, I was hoping someone could improve it before I convert it to "C" ... My math skills are terrible.

I'll take a look.

iGame3D Wrote:
How does this compiler magic work? Its set for some linux directory so I'm stumped.

Just copy the script and change the paths for MacOS ... Like the attached version (lua.out will be the executable, and out.lua the decompiled source from the executable).

The test uses internal murgaLua functions, I'll build a front end at some point.

iGame3D Wrote:
Something looks different, looks better? Maybe my imagination.

This release benefits from a load of fixes that have been done to FLTK, many in relation to the Mac port ... So yeah, it may well look better on Mac, and either way mikshaw will find it more stable.

The fixes also allowed me to create a more complete set of bindings.

Cheers
JohnM


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 12:18 AM

znarf Wrote:
I tested the new release under Linux Ubuntu 7.10 x86 and under Windows Vista x64. All my personal scripts and the examples worked fine.
The compiler is really a nifty feature! Is it possible to integrate also resource data such as PNGs in the executables?

Hehehe ... Thanks !

My bad ... I forgot to mention this in the release notes, but that is one of the reasons for the new HEX encoding features and the picture handling enhancements. Yes, it is possible to embed any image data into an executable :-)

A demo of this will be in the proper release.

Cheers
John de Murga


RE: Initial build of version 0.6.0 - iGame3D - 01-20-2008 01:19 AM

Aha! Got the compiler working, very nice.

All those extra slashes to make the string boggled my mind.
I'm such a terminal noob.

But there it is, a picture perfect calculator.

Oh and Tobi is probably at work, I'm 101% certain he'd be
very happy that the fluid convertor was integrated into murgaLua.

It would be awesome to have integrated into Fluid itself, sometime in the future.

My clock says its almost 3:30 PM in Germany, he's probably working a ten hour shift,
so its going to be a few more hours until we hear from him.


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 02:21 AM

Another note for Windows users ...

By default if you compile an app under Windows you'll get a console window (not very windows like, but great for debugging). If you want to get rid of it you'll have to run the "no console patch.exe" in bin/Windows to remove the console from the base executable ... This only applies to Windows ... Because ... It's a bit of a pain :-)

I am anxious to hear what mikshaw makes of this release.

Cheers
JohnM


RE: Initial build of version 0.6.0 - mikshaw - 01-20-2008 02:37 AM

I'm here =o)
Unfortunately, I have piles of snow to clear out today, so won't get a chance to look at it much until later. But I definitely wanted to see how the pixmap embedding works, and I gotta say THANK YOU very much for this!
It doesn't work exactly as I thought it would, but I figured it out after a few segfaults =o)
Important thing to note is that it doesn't accept the comments that you would typically see in an XPM file, including the initial /* XPM */
So the format is:

Code:
my_xpm={"width height number_of_colors characters_per_pixel",
"color 1 definition",
"color 2 definition",
...
"color n definition",
"first line of pixels",
"second line of pixels",
...
"last line of pixels"}

xpm_data=fltk:Fl_Pixmap(my_xpm)
my_widget:image(xpm_data)
--or: my_widget:image(fltk:Fl_Pixmap(my_xpm))


I'm really looking forward to seeing how user data works.

I also got the same error message on Linux (DSL 4) as xleitex did on XP when opening murgaLua with no argument.


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 03:16 AM

mikshaw Wrote:
I'm here =o)
Unfortunately, I have piles of snow to clear out today, so won't get a chance to look at it much until later. But I definitely wanted to see how the pixmap embedding works, and I gotta say THANK YOU very much for this!
It doesn't work exactly as I thought it would, but I figured it out after a few segfaults =o)
Important thing to note is that it doesn't accept the comments that you would typically see in an XPM file, including the initial /* XPM */

Glad you liked it :-)

It's totally based on how FLTK structures things internally, for Pixmaps you'll get an idea of what this by looking at the rotation demo...
I add some additional attributes for convenience, but that's about it.

One of the many things I have to document.

mikshaw Wrote:
I'm really looking forward to seeing how user data works.

The menu example has a sampler ...

Basically you can set the user data for any control or menu item, this is particularly useful if you have a group or menu, where many items got to the same callback ... This allows you add a function or information to influence the routing (for the menu example I make it possible to associate a function to each item, and that could even be the same function with different parameters).

Not that I explained it very well, and I fell short on the example :-(

mikshaw Wrote:
I also got the same error message on Linux (DSL 4) as xleitex did on XP when opening murgaLua with no argument.

Now that is weird ... I fixed the problem on Windows, but if it's happening on Linux then it's for a different reason.

I'm on it :-)

Cheers
JohnM


RE: Initial build of version 0.6.0 - Juergen - 01-20-2008 04:11 AM

There are still a few problems:

- The version string says still version 0.5.5.

- The error that has been already reported appears also under Linux, when the murgaLua command invocation doesn't contain any slashes and the shell has to locate the binary in one of the PATH directories. But I guess it is the same bug that has already been reported under Windows and might therefore already be fixed.

- There are still a few collisions with reserved keywords. For example: Fl_Group has a "end" method which can't be called. A rename to "End" would be a good idea.

- The user_data("function_name()") method looks like a really big ugly hack. Is it so hard to support something like:

myItem=menuBar:find_item("Some menu item/&item2")
myItem:callback(myItemCallback)

and also menuBar:add("&First menu item/First item",fltk.FL_CTRL + string.byte("f"),myItemCallback)

I'm pretty sure there is some way, to do it without using a function which takes a string with the name of the callback function as an argument.

Juergen


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 04:54 AM

Juergen Wrote:
- The version string says still version 0.5.5.

That was stated in the release notes.

Juergen Wrote:
- The error that has been already reported appears also under Linux, when the murgaLua command invocation doesn't contain any slashes and the shell has to locate the binary in one of the PATH directories. But I guess it is the same bug that has already been reported under Windows and might therefore already be fixed.

Nope, the windows bug is slightly different ...

This one requires a different fix ... Which I haven't done yet.

Juergen Wrote:
- There are still a few collisions with reserved keywords. For example: Fl_Group has a "end" method which can't be called. A rename to "End" would be a good idea.

If you can tell me the other ones I'll be happy to address this.

Juergen Wrote:
- The user_data("function_name()") method looks like a really big ugly hack.

It is purely a way to do things a little better right now thanks to the user_data() support.

Not the only hack in there :-)

I don't think it's that big and ugly compared to the current menu handling (which leaves a lot to be desired).

Juergen Wrote:
Is it so hard to support something like:

myItem=menuBar:find_item("Some menu item/&item2")
myItem:callback(myItemCallback)

and also menuBar:add("&First menu item/First item",fltk.FL_CTRL + string.byte("f"),myItemCallback)

Not that hard, but I haven't got round to it yet as i needed the user_data for some other stuff too ... And callbacks are a pain, so it hasn't been a priority (but I've added it to the list).

Juergen Wrote:
I'm pretty sure there is some way, to do it without using a function which takes a string with the name of the callback function as an argument.

For now that is actually the best solution, until I get round to enhancing the API as you have pointed out :-)

Thanks for the thorough testing !

Cheers
JohnM


RE: Initial build of version 0.6.0 - mikshaw - 01-20-2008 05:45 AM

Quote:
Basically you can set the user data for any control or menu item, this is particularly useful if you have a group or menu, where many items got to the same callback ... This allows you add a function or information to influence the routing

I've used tooltip() in the past as a replacement for this, but tooltips are not always appropriate for some situations, and I can't say for sure whether you can apply them to individual menu items.


RE: Initial build of version 0.6.0 - JohnMurga - 01-20-2008 06:48 AM

OK, fixed the other bug now ... All related to the compiler core.

I am going to see what I can do about Juergen's menu concerns ... Later :-)


RE: Initial build of version 0.6.0 - mikshaw - 01-20-2008 08:34 AM

Messing around with the menu example, I made a couple of changes that cut down the size a little, although it might not be as easy to read. Mainly I just like to see how small I can make things.

Code:
testItem=menuBar:find_item("Second menu item/&First item");
testItem:user_data("testFunction()")

is replaced by

Code:
menuBar:find_item("Second menu item/&First item"):user_data("testFunction()")

and the callback (just the part that runs testFunction) is

Code:
menuBar:callback(
function(w)
local s=w:mvalue():user_data()
if s then assert(loadstring(s))() end
end
)


I don't know if io.flush is still needed? Actually I don't know if I should be using it in other scripts too.

It didn't look at first as though this was any simpler than making a bunch of elseif statements in a single callback, but it seems that this is the next best thing to assigning callbacks directly to menu items.

It still seems like there should be a simpler way than loadstring, since the string is already static and in memory, but since you plan to eventually attack the callback this will be fine.