Murga-Projects Forums
Future plans ... - 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: Future plans ... (/showthread.php?tid=309)


Future plans ... - JohnMurga - 03-24-2008 07:58 AM

There will be a 0.6.8 ...

I still have more core functionality and a little surprise up my sleeve.

After that my focus will be on tightening and optimizing the code, things have gotten a little big and I'd like to fix that ... At the same time there are quite a few apps I want to write, including a front end to the compiler and a couple of things I rather keep under wraps for now.

As always I am open to suggestions :-)

Cheers
JohnM


RE: Future plans ... - Juergen - 03-24-2008 08:39 AM

JohnMurga Wrote:
As always I am open to suggestions :-)

including CInvoke or alien (alien supports now all murgaLua supported platforms)
including bitlib or something similar.

Have you looked at luasys? While there is an overlap with functionality already in murgaLua there are a few intresting things in it. The mem part, the io part, event and thread. Also rings could be a cool thing.

This way the offscreen buffer could be manipulated directly. Immutable strings are a real pain in the butt for image manipulation. (O.K. as long a there are pixel functions available it isn't that big of a problem)

I also still can't add anything to the main fltk event loop (Fl.add_idle() and co. are missing).

Also there is some (fltk) functionality that can't be accessed in murgaLua. It might be possible to add functions to register lua wrapper functions as virtual functions. for example my_widget:register(resize,myresize) or something in that direction.

Juergen

BTW.: I don't know if I'm the only one, who has that problem, but readline seems still broken in murgaLua 0.6.6


RE: Future plans ... - asafp - 03-24-2008 08:39 AM

Quote:
my focus will be on tightening and optimizing the code, things have gotten a little big and I'd like to fix that ...


There doesn't seem to be many people around these days who think like John Murga.

During the 1970s, I worked on an application that was revolutionary for the time and saved a lot of disk space and other resources. The idea made a lot of money (for other people, not me). It was a fun product to work on and made life better for people working in the computer industry.

More recently, I worked for a company that would tell people to buy a new computer if they had performance or disk space problems. That solution has gotten more plausible as hardware has improved and gotten less expensive. Still, it's sad that this has become the mindset for many software developers.


RE: Future plans ... - znarf - 03-24-2008 08:59 AM

My personal favorite long-term direction for murgaLua would be more of a slant towards multimedia. Still I miss some truly free alternative to Adobe Flash. I did some experiments (e.g., a closer look at luacairo, Pixeltoaster, portaudio, rtaudio) and a little bit of web research lately, but did not come up with a suitable proposal for lightweight yet powerful multimedia extensions for murgaLua yet.
I'd like to have the following features:
- fast yet high quality 2D vector graphics (cairo/luacairo is too slow for realtime animations)
- audio (portaudio/rtaudio both seem ok but lack any file format binding - wav, ogg/vorbis, or mp3)
- video (no idea yet)
- also murgaLua lacks platform-independent printing support. This is hard to achieve, I know...

If someone knows of suitable libraries for these purposes which ideally even offer lua bindings, I would be very pleased to know.

Regards,
Gerald


RE: Future plans ... - mikshaw - 03-24-2008 12:05 PM

Quote:
More recently, I worked for a company that would tell people to buy a new computer if they had performance or disk space problems. That solution has gotten more plausible as hardware has improved and gotten less expensive. Still, it's sad that this has become the mindset for many software developers.

While this might take things a little off topic, I completely agree with you. My computer (1.8ghz cpu, 512mb ram) is not the latest hardware, but as far as I'm concerned it should be more than enough to easily handle typical processing that most people want for daily use. Not long ago I was using a 550mHz cpu that accomplished everything I needed without much lag (gaming was an issue in some occasions, but that was all). Unfortunately there is a great focus on making all applications *bling*, which in most cases is useless and a huge waste of system resources.

As long as you can see a noticeable difference in performance between various widget sets, I will always opt for the lighter. When hardware improves to the point where unnecessary eyecandy response is no more noticeably slow than fltk, I'll consider using it.


RE: Future plans ... - JohnMurga - 03-25-2008 10:47 PM

Hi,

Bitlib will be in, but I have been having trouble getting Alien to work properly on Win32 due to the fact I use GCC/MingW (works great on Mac/Linux).

Juergen Wrote:
Have you looked at luasys? While there is an overlap with functionality already in murgaLua there are a few intresting things in it. The mem part, the io part, event and thread. Also rings could be a cool thing.

Maybe some of the mem, io and event stuff may be interesting ... But I want to shy away from providing functionality that is too complex of troublesome ... Threads for instance, they are cool, but will prove VERY problematic when used with FLTK and other things, so I rather leave them out.

Juergen Wrote:
This way the offscreen buffer could be manipulated directly. Immutable strings are a real pain in the butt for image manipulation. (O.K. as long a there are pixel functions available it isn't that big of a problem)

Better memory/buffer handling is on the list.

Juergen Wrote:
I also still can't add anything to the main fltk event loop (Fl.add_idle() and co. are missing).

Let me know what other functions you need are missing.

Juergen Wrote:
Also there is some (fltk) functionality that can't be accessed in murgaLua. It might be possible to add functions to register lua wrapper functions as virtual functions. for example my_widget:register(resize,myresize) or something in that direction.

That would be nice for quite a few things, but currently it would require me to profoundly change things, although I'll have a think about how I'd go about doing that ... Without making things too complex.

Juergen Wrote:
BTW.: I don't know if I'm the only one, who has that problem, but readline seems still broken in murgaLua 0.6.6

The dynamic binaries in the "otherBuilds" should have readline enabled ... At least, they did when I last tested.

Cheers
JohnM


RE: Future plans ... - mikshaw - 03-26-2008 01:07 AM

Quote:
The dynamic binaries in the "otherBuilds" should have readline enabled

Quote:
Oh, and readline support is present in the static Linux builds

I know I tested the static non-xft in DSL, so if it's actually the dynamic build that has readline I understand why it didn't work.
I *thought* I'd tested the dynamic build in Slackware, but I see now that the file is 605k, which couldn't be the right one. I'll try the other next time i'm in slackware.


RE: Future plans ... - mikshaw - 03-26-2008 05:13 AM

Yeah, I tested murgaLua_Dynamic in Slackware 12, and readline works great.

I was kinda hoping that I could test FLTK widgets in interactive mode, but so far I've only succeeded in displaying an empty window or a non-interactive dialog. But that's a minor issue that doesn't really matter to me. It's just as easy to test widgets in a script as usual.


RE: Future plans ... - JohnMurga - 03-26-2008 11:14 PM

Finally ! ... I got Alien to work and run through my tests on Windows murgaLua (my problems where down to MingW).

It already works nicely on Linux, and I have a couple of minor issues I'd like to fix MacOs (nothing hard I think).

This will allow you to call functions from DLLs, .so and .dylibs directly from murgaLua.

I'll submit some patches to the Alien project this weekend, and start work on murgaLua 0.6.8 after that ...

So get any requests you may have in now ;-)

Cheers
JohnM


RE: Future plans ... - mikshaw - 03-27-2008 04:11 AM

Quote:
This will allow you to call functions from DLLs, .so and .dylibs directly from murgaLua.

This sounds like it's probably a huge bonus, but honestly I'm not sure what it means...no "real" programming knowlege here, so I have no clue how dynamic libraries are accessed. I don't even know how to access Lua modules =o)

It seems like murgaLua could theoretically have unlimited capabilities through the use of C libs?


RE: Future plans ... - Juergen - 03-27-2008 10:45 AM

JohnMurga Wrote:
Maybe some of the mem, io and event stuff may be interesting ... But I want to shy away from providing functionality that is too complex of troublesome ... Threads for instance, they are cool, but will prove VERY problematic when used with FLTK and other things, so I rather leave them out.

Actually I don't think it makes much sense to do multi-threaded fltk programming. But being able to spawn other threads for async io an co. would be a real plus. I think it would be not such a big problem if it is clearly documented what is possible and what not. Also the threading API could reflect this. Maybe it would also be possible to have an API where the threads use a different Lua states, which don't show the fltk functions. Maybe a rings/thread combination. It would be really cool to have multiple treads that could handle network and file io independently from the main flkt thread, especially since synchronous I/O multiplexing is currently non existent in murgaLua. Although with alien on Linux this shouldn't be a problem any more ;-)

JohnMurga Wrote:
Better memory/buffer handling is on the list.

The immutable string as buffer was not the brightest idea of the Lua designers. This is one thing where it becomes really clear that Lua was mainly designed as embedded scripting language.
The sys.handle and io functions from luasys would be a really cool thing.
I really miss the simple "while fd:read(buffer, buffersize) > 0 do .. end" loops.

JohnMurga Wrote:

Juergen Wrote:
I also still can't add anything to the main fltk event loop (Fl.add_idle() and co. are missing).

Let me know what other functions you need are missing.

I hope that I tomorrow more time to look into this. But it is mainly add_idle() and co. Oddly remove_idle() is already available.

JohnMurga Wrote:
That would be nice for quite a few things, but currently it would require me to profoundly change things, although I'll have a think about how I'd go about doing that ... Without making things too complex.

While I have my doubts that it is (performance wise) a good idea to route some of the virtual functions (like draw()) through Lua code, I think it would be really cool to have something like that:

Code:
copy_class(Fl_XY, My_New_XY_Class)
function My_new_XY_Class:resize() ....... end
my_widget=My_new_XY_Class()


This would of course only work for some selected virtual functions. But there aren't that much that are really necessary to manipulate.
BTW.: I'm really missing a real table class and the labels that are positioned on the box and not above or below. The current fltk labels really suck big time.

JohnMurga Wrote:
The dynamic binaries in the "otherBuilds" should have readline enabled ... At least, they did when I last tested.

You are right. I haven't looked into that directory, since I have at least on system, where I can't use the dynamic build.

JohnMurga Wrote:
So get any requests you may have in now ;-)

I doubt it would be hard to come up with a ton of suggestions ;-)
The ex API has also some functionality that would greatly improve murgaLua (like os.pipe, os.setenv, os.environ() and os.spawn. But as I said, with alien support it shouldn't be that hard to get this functionality anyhow ;-)

Juergen


RE: Future plans ... - asafp - 03-28-2008 05:46 AM

what the heck is "alien"?


RE: Future plans ... - mikshaw - 03-28-2008 06:55 AM

http://alien.luaforge.net/

It's also the name of a Linux script to convert various software package types, which can make a google search kinda hard if you have a habit of using google.com/linux


RE: Future plans ... - mikshaw - 04-04-2008 03:59 AM

Quote:
So get any requests you may have in now ;-)

FLTK 1.1.8 final was released a few days ago...I haven't looked at it yet.
It looks like future "stable" devel will be 1.3.x

I think all I'm hoping for in the near future is documentation for all the stuff I don't understand =o)
Some things I can copy from John's examples, but it would be better to know *why* certain things are done the way they are rather than just *how* they're done.


RE: Future plans ... - JohnMurga - 04-04-2008 07:22 AM

All the code for 0.6.8 is complete and tested ...
And I think out of everyone Juergen and any Windows users out there will be happiest.

I just want time for more examples and testing, but I am REALLY happy with this release (Linux and Mac users will be happy too!).

I'll say it'll be released this weekend, but you know I cannot stick to a deadline, so we'll have to see.

Either way, the murga-projects WIKI has also been set up, and once I put some introductory content on there I'll be inviting people to join ... That should help with the documentation as it'll make it easier for myself and others to contribute :-)

Furthermore, if mikshaw or others post stuff on there I can explain the why and how ...

The next step after that will be defining the 0.7.0 road map, which goes along the lines of :

+ Examples and documentaion.
+ No new extensions (if possible).
+ A list of about 30 FLTK functions I want to implement.
+ Performance work (size and speed).
+ Fl_Table and tree controls.
+ Async mechanism for "some" tasks (not threads).
+ BSD port, AMD64 work and other build improvements.
+ Some other stuff I don't remember ...

Please feel free to comment.

Cheers
JohnM


RE: Future plans ... - JohnMurga - 04-04-2008 07:57 AM

I forgot to say, I am not planning to upgrade beyond the FLTK 1.1.X family in the 0.8.X releases.

The 3.X branch looks interesting, but we have to wait and see what the FLTK world does (and they take a long time) ... But 1.1.X is without a doubt the most stable and well supported place to be, and I want my binding to be the best available ;-)

sqLite ... Well, it is getting bloated for my liking, and I will be providing drivers for other DBs as a separate download, but it is CORE functionality, and it'll stay and be upgraded as long as it doesn't grow too much.

The other APIs will be upgraded and worked on with backwards compatibility, stability and performance in mind.

I also have some home grown APIs, the "no APIs" rule did not apply to those ...

Cheers
JohnM