I sometimes write scripts to be supported by multiple versions of murgaLua, for example in the case where I want to utilize a recent addition but don't want the application to break if the user has an older version. What I've done so far is check for the existence of a package that was added with the same version as the desired feature:

This isn't ideal for more than one reason.

I don't know why it never occurred to me before, but you can use the same concept to check for the specific feature you want to use. For example, if you want to use Fl_Pixmap on 0.6 but prevent a close on 0.5.5 and earlier:

Of course you'll need to know the path to the specific object you want to test, but you can use this tool to help.

Another possible test is for a specific version of murgaLua, in the event that you have multiple new features in your script and just don't want to support older versions. You could check for a feature that was added to that specific version, but it's *possible* that sometime in the future that feature could be removed or renamed. You would always need to make sure you use a feature that is specific to your script, rather than just a generic cut-and-paste test. That's not a serious issue, but anything that can reuse existing code makes development go more smoothly.

I couldn't figure out why I couldn't use tonumber(murgaLua.version) for comparison, so I didn't bother with it. Then it struck me that a string with two decimals in it can't be converted into a number, so I decided to do string comparisons instead:

This method allows you to simply copy and paste the code reliably into any script that needs at least version 0.5.5
It also uses an additional print() just in case the end user tries to run the script in some other kind of Lua interpreter. I haven't tested this in Lua proper yet, but i think it would exit cleanly just from not finding murgaLua.version

Maybe there are simpler ways to do this, but this at least is more reliable for general use.

I think you are looking for something like that:

Juergen

Alternatively:

This works also in alternative Lua interpreters. This way you don't have to keep track over all the past murgaLua versions

Juergen

Yes, that's exactly the result I was originally thinking of, but wasn't sure where to start. Thanks. =o)
I'm definitely saving this for future tests, and putting it in with the rest of the code snippets.

I don't really understand the syntax of "do...end" though. Is that just to keep the variables local?

The do and end delimits a block. Inside you have your own scope. It is basically the same as { } in C, where you can also define new variables.

I used the do .. end only because I wanted to declare the variables local, since it doesn't make sense to have them as globals. Lua doesn't allow you to have local variables in the outermost scope:

which also doesn't make sense.

Of course it would make sense to put it into a function.

Juergen

Yeah, I had the assumption that local variables could only be used within a function.

I like that last one best. It seems it would be completely reusable without modification, except the print command should use min_version instead of a static "0.5.5" in its string. As a personal preference I'd also change the variable name of min_vers. It's a bit too similar to min_version for quick reading; it took me a few minutes to figure out they were unique.

Another version:

Juergen

It just occurred to me that testing the version string is not going to be as reliable as I'd hoped for a little while. The version string in 0.6 is "0.5.5", so until 0.6.5 it will continue to be a problem for this test. After that, testing for 0.6 will probably need to be explicitly discouraged.

Then the function should be changed a little ;-)

Juergen