• The reported bugs around no-parameter invocation have been fixed.
• New menu functions (see below).
• Forgot about some new variables.
• Version numbers updated.
  

• 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.
  

• 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)
  

I shorted the path to the files above for easier reading.

Clicking "bind_lua_addtovtable" in the default screen produces more scrambled text in the following screen, worse than the first sample attached.

I think I clicked on everything in the default state of that window.
So far thats all I found thats funky.

That sounds super! I still don't understand how Fl_Menu_Item is used, but maybe that's not important anymore.

What is ltn12? It's apparently one of the 3rd party packages, but since this is a binary-only release I don't see any docs about it.

I've seen them too, but had no idea what to do about it. I guess it might have something to do with certain functions containing text rather than just being part of the binary machine?

I never noticed that before, and currently have no idea why. Maybe I should take out everything concerning functions, as they don't give you any useful information anyway. I was trying to find a way to display the code of lua functions, but I guess since they're binary it probably will never work.

Thanks for checking it out so soon !

I haven't actually looked at the source of the tableNavigator, it is mikshaw's and I haven't asked him if I can use it yet, but I did find it useful so it sneaked in because it was in my examples dir.

I have to tweak the rotation demo, but for now I have put your fix in :-)

The "tools/misc" contains scripts for building, it'll be there in the full release as will all the source.

Cheers
JohnM

It isn't that important any more ... But I'll try and document it.

ltn12 is part of luaSocket ... Filters and sources ... Why do you ask ?

The corruption in the screenshot comes from the variable in question having multi-line text in it.

Anyway ... Off to bed for me :-)

Cheers
JohnM

I was just curious. I don't remember seeing it before.

I "fixed" (actually just ignored) both the what_is_it crash and the scrambled text by removing the "if" block under the "it's a function" comment in the what_is_it function. This isn't what I want ultimately, as I do want to try to find a way to get info on selected functions and user data, ut the way it's being done now obviously doesn't work.

Thanks :-)

There are a few things that on my list :

• Bug fixes ... Hopefully not too many :-)
  .
• The compiler is still in beta
• Decent documentation !!
• Decent grid control (Fl_Table is on its way)
• Nice UIs for compiler, fluid conversion, etc.
  .
• The text editor stuff is still missing some methods.
  (And I want to make syntax highlighting easy)
• Dynamic loading of sqLite if .dll/.so is present.
  (No more static linking on Win/Mac, and Linux version would not fail if .so is not present)
  .
• Sound API (lightweight, only if SDL is present or something).
• Dynamic calling of functions in .so/.dll from scripts.
• Serial API ?
  

Is there something wrong with C/Invoke?

Wasn't there a plan to build murgaLua with readline support on Linux?

I don't know if the above topic includes this, but would it be possible to build a dynamic version (still linked statically to fltk, liblua, .....) that is able to load binary modules?
I may be doing a project in the near future, which requires some functionality that doesn't necessarily make sense in murgaLua (like accessing the win32 API, regex, pluto, luaevent, threads....)

If you are looking for features to add: lpeg, pluto and maybe luaevent wouldn't be a bad idea.

Juergen

C/Invoke did have some serious issues last time I played with it ... Which was a massive shame as it was something I really wanted.

I have an alternative which is more limited, but that's for the experimental murgaLua version in the coming weeks.

This version was built with readline support on Linux.
As it happens the readline source is now required to do the build on Linux.

Again, this version should support binary modules, you'd just have to build them for murgaLua ... I'll give it ago later.

Absolutely ... This is something I assumed was working, I was going to write a win32 module at some point for use with murgaLua (but only on Windows) ... For one of my projects.

Which reminds me ... If you are using murgaLua for any kind of project that would make a good showcase please send some screenshots or something :-)

lpeg and pluto are a little complex for most users (and easy enough to add as modules), while luaevent seems less stable than COPAS.

I am looking for suggestions, of any type, but I still want to keep focus on a usable, tight and focussed run-time.

Cheers
JohnM

This should join multiline strings into a single line.

Yeah, I forgot about that. I haven't done anything complex with Fl_Text_* but I did notice that column_widths() is missing, while it isn't that important it can make displays much neater.

It has always worked, you don't even have to build specially if you don't want to (look at last post) ...

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

Cheers
JohnM

Unfortunately there hasn't been an update since then. Although the last time when I tried it I found no problems. But I haven't tested it that much.
The big advantage of C/Invoke is that it comes with very powerful binary pack and unpack/parse features, which are currently missing in Lua.

I was just asking, because the edit features (cursor keys) don't work currently.

O.K. But I was wondering, since on Linux with glibc it isn't really possible to make completely static binaries, it would still work with a dynamic binary where all of the dependencies have been compiled in statically. The C-API is still the same (or did you change the C-API also?). This would remove the need to compile the modules specifically for murgaLua.

I guess it would make sense to write the win32 API part for Windows only ;-)

It will definitely be GPL. The reason for using a scripting language, is that it should be easy to change things.
Although I normally don't do GUIs and it will be the first project with Lua and fltk and I don't have much time and normally don't use Windows, which shouldn't make things easier ;-)

If you add the feature of invoking C-API calls, then this will add automatically also the possibility of reading and parsing binary chunks (which is currently an absolute disaster). Of course a bitlib for bit manipulation is also needed to complement this.

Juergen

I was just testing this on Linux and it didn't work. I assumed that it works, but (I may have tested it in the past on Windows) it currently doesn't work on Linux (at least not the way it is expected).

I just did a few extra tests and at no point does murgaLua try to open liblua. Although I can make it work when I preload liblua with "LD_PRELOAD". This is good enough and if it works on Windows I have no problems.

Juergen

MurgaLua would not try to open liblua as it is statically linked, my understanding is that the module would be linked against liblua and would required it to be present whe murgaLua did the loadlib/require ...

But I haven't tried myself ... And won't be able to until the end of the week.

Cheers
JohnM

You are right, the examples I just tested were not explicitly linked against liblua. Normally they don't have to, because they can see the Lua API symbols even when liblua is linked staticall into the lua interpreter binary. Only when the interpreter itself is linked statically (which doesn't really work on glibc) then the modules have to be linked dynamically against liblua or liblua.so has to be preloaded to make the symbols available.

Juergen

I could provide some interesting screens, but I'm kind of afraid of encouraging
more requests for a library. Sometimes I feel guilty being "special".
How do you think I should approach this?
Just flood you with screens and let you pick and choose?

Pixmap should be an array, but Bitmap and RGB are binary strings.

Take a look at imageDecodingTest.lua ...

This implementation is consistent with the way FLTK does things.

Cheers
JohnM

You are right. I tried it with an array and it works.
Another question:
Is it possible to draw on an offline (not visible) surface and then copy the result?

Juergen

Yup, but it's a HACK ... You can draw to a hidden window and copy the result.

However, the recently documented off-screen functions look pretty nice, and I'll be implementing them soon.

(http://www.murga-projects.com/murgaLua/fltk/drawing.html#offscreen)

Cheers
JohnM

Drawing to a hidden window was the first thing I tested. Unfortunately I only get a segmentation fault when I try to make_current() on the hidden window.

On a side note: You have to call the Fl_Menu_Bar() constructor as fltk.Fl_Menu_Bar(), but you can call the Fl_Pixmap() constructor direct. This is a little bit inconsequential.

Juergen

So i guess this is a bug?

greetz,

JP

That is the regression I mentioned in another post ...

socket.sleep works, or wait for the bugfixed version in a few days.
Or even better, use the murgalua timer, that is the preferred method.

Sorry !! :-(

Cheers
JohnM

All that stuff is very flaky in FLTK itself ... But I got read_image working, and have an off_screen demo working too.

Didn't realize that ... Better to be consistent.

On the list.

Thanks again.

Cheers
JohnM