Celestia Forums

Hi,

Anyone has been successful in making Celestia work with Lua 5.2 (currently Celestia 1.6.1 is based on Lua 5.1)?

I came across this site http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/c/?C=M;O=A

where the download contain a patch file: celestia-1.6.1-lua-5.2.patch. This patch makes Celestia src compile well, but the executable does not work because of the code


It seems Lua 5.2's lua_setfield function fails to work.

Strangely enough, the patch went through well with Lua 5.1 and ran well too, but crashed at lua_setfield under Lua 5.2

Joe

--- edit ---

Hi, John

My OS is Windows XP, Win32 with Compiler VS2008 (also tried with VS2005 and VS2010).

The svn code under the version number 1.7 is really the same as Celestia 1.6.1 and SVN 5229.

Joe

--- edit ---

It seems that Celestia will be ankered with Lua 5.1 forever or there are something buggy with Lua 5.2. Anyhow Celestia and Lua 5.2 do not work together .

well it builds on Linux just fine with 5.2

did you remake the MS visual studio project and solution files
likely you would have to hack that config and point it to the 5.2 install
should be fairly easy in the current visual studio

a question are you truing to use the"celestia.vcproj" &"celestia.sln"
those area visual studio 8 EXPRESS
and mostly can only be used in express 8

the vcproj file has this coded into it

Name="VCCLCompilerTool"
AdditionalIncludeDirectories=".\src;.\windows\inc;.\windows\inc\libintl;.\windows\inc\libpng;.\windows\inc\libz;.\windows\inc\spice;".\windows\inc\lua-5.1";.\windows\inc\libjpeg;.\thirdparty\Eigen;.\thirdparty\glew\include;.\thirdparty\curveplot\include"

-- and ---
Name="VCLinkerTool"
AdditionalDependencies="intl.lib user32.lib gdi32.lib comdlg32.lib comctl32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib winmm.lib vfw32.lib opengl32.lib glu32.lib libjpeg.lib zlibd.lib libpngd.lib lua5.1.lib cspice.lib"

--- and ---
Name="VCCLCompilerTool"
AdditionalIncludeDirectories=".\src;.\windows\inc;.\windows\inc\libintl;.\windows\inc\libpng;.\windows\inc\libz;.\windows\inc\spice;".\windows\inc\lua-5.1";.\windows\inc\libjpeg;.\thirdparty\Eigen;.\thirdparty\glew\include;.\thirdparty\curveplot\include"

-- and --
Name="VCLinkerTool"
AdditionalDependencies="intl.lib user32.lib gdi32.lib comdlg32.lib comctl32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib winmm.lib vfw32.lib opengl32.lib glu32.lib libjpeg.lib zlibd.lib libpngd.lib lua5.1.lib cspice.lib"


---- and so on ......................

pointing to 5.1 !!!!

did you hack the project file?


i would use the QT creator ( windows version !!)
and build with the "celestia.pro"

you will need QT4 installed instead of the GULT / GTK2 for the VS project

Fedora 24 contains working RPMs for Celestia 1.6.1 built against Lua 5.3:
http://mirror.bytemark.co.uk/fedora/linux//releases/24/Everything/source/tree/Packages/c/celestia-1.6.1-22.fc24.src.rpm

There is an extra patch in there that fixes the initial port to Lua 5.2.

It's probably also worth pointing out that Fedora has started to delete any and every texture from its Celestia RPM that cannot be proved to be distributable under the GPL. You might therefore find some of the planets to be (err) curiously featureless...

If anyone knows the lawful provenance of any of the deleted textures then I'm sure that Fedora would love to know...

rankincj wrote:

Fedora 24 contains working RPMs for Celestia 1.6.1 built against Lua 5.3:
http://mirror.bytemark.co.uk/fedora/linux//releas ... celestia-1.6.1-22.fc24.src.rpm

There is an extra patch in there that fixes the initial port to Lua 5.2.

I double checked the above link and the contents, I couldn't see Lua 5.2 or 5.3. It is still in Lua 5.1.

Having been struggling for the past few weekends to investigate and make Lua 5.2 (or 5.3) works in Celestia, the following are what I have so far found out:
1. The "upgrade celestia-1.6.1-alt-lua5.2.patch" (or under any other naming) could take Celestia through compilation, but beyond it crashed on running.
2. I fixed the crash by modifying openLuaLibrary() into:

and

3. However the effort, Celestia with Lua 5.2 cannot run ScriptObit and ScriptRotation, neither can it work for Celxx add-on.

I wonder if there is anyone out there has already been successful in making Celestia fully work with Lua 5.2 and above?

I'm interested too.

Joe wrote:3. However the effort, Celestia with Lua 5.2 cannot run ScriptObit and ScriptRotation, neither can it work for Celxx add-on.

I wonder if there is anyone out there has already been successful in making Celestia fully work with Lua 5.2 and above?

Hi Joe, have you tested the latest 1.7 branch? It has fixes for lua 5.2 and 5.3.

But please note that with lua 5.2 "goto" became a keyword, so instead of celestia:goto() one should use a new method celestia:gotoobject().

From Lua 5.1 to 5.2, there has been a big jump between the two versions, which makes the hooking/wrapping between Celestia and Lua 5.2 quite a challenging task. Although, from Lua 5.2 to 5.3, it is a smooth upgrading between the two versions, the fixes on Lua 5.3 with Celestia are not automatic.

1. I have had a test over the latest Celestia 1.7 branch and I am quite confident that the fixes on Lua 5.2 is complete and robust, but I am not sure those fixes are all equally applicable to Lua 5.3.

2. Because table.getn() is no longer available in Lua5.2 onward, we have to write our own getn() function in celx and lua scripts.

3 . Accroding to lua manual, math.mod was renamed to math.fmod in lua 5.2.

4. In lua 5.3, the following functions are deprecated in the mathematical library: atan2, cosh, sinh, tanh, pow, frexp, and ldexp. We can replace math.pow(x,y) with x^y, math.atan2 with math.atan (which now accepts one or two parameters), math.ldexp(x,exp) with x * 2.0^exp. For the other operations, we can either use an external library or implement them in Lua.

5. As lua 5.2 and 5.3 onward, "unpack" has moved to table.unpack, as a result we need following line in the beginning of a lua programme
if this programme has previously used unpack:
unpack = table.unpack
6 From Lua 5.2, goto statement is added. As a result, celestia:goto() has to be defined otherwise.

7. From Lua 5.3, string.format for converting float values into integer values (%d or %x) is no longer as tolerant as Lua 5.2. It requires that float values to be converted first into integer %d or %x using math.floor (or math.ceil).
For example, the function rgb2hex(r,g,b) in file z-dist.tdsx, for Lua 5.3, it must be coded like this:
local hex = string.format("#%.2x%.2x%.2x", math.floor(r), math.floor(g), math.floor(b))
But for Lua 5.2, it can be tolerant the following code:
local hex = string.format("#%.2x%.2x%.2x", r, g, b)

8. From Lua 5.2, string.gfind() is replaced by string.gmatch()

9. With Lua 5.1:
date = celestia:tdbtoutc(time);
systime = os.time({year=date.year, month=date.month, day=date.day, hour=date.hour, min=date.minute, sec=date.seconds});
With Lua 5.2/5.3:
date = celestia:tdbtoutc(time);
systime = os.time({year=date.year, month=date.month, day=date.day, hour=date.hour, min=date.minute, sec=math.floor(date.seconds)});

Although the 64-bit compiled Celestia 1.7 is not yet a true 64-bit version, only Lua 5.3 onward can support a 64-bit built of Celestia in future.

Joe wrote:Although the 64-bit compiled Celestia 1.7 is not yet a true 64-bit version, only Lua 5.3 onward can support a 64-bit built of Celestia in future.

Hi Joe! Could you explain what do you mean?

Hi Joe! Could you explain what do you mean?

What I meant:
1. that versions that older than Lua 5.2 do not support 64-bit, only Lua 5.3 onward has 64-bit.
2. although Celestia 1.7 is compiled AS 64-bit, it is not compiled INTO 64-bit, i.e, Celestia 1.7 is not a ture 64-bit version.
3. even if Celestia 1.7 (the source) is fully in 64-bit, it can only be a true 64-bit if all third-part libraries include Lua are 64-bit.

I had little trouble getting the lua library to compile as 64-bit 5.1/5.2/5.3, all it required was a little work.
I use 5.3 in my own forks.

I use VS mostly for windows, but even Mingw64 can do 64-bit for all three versions.

The larger issue you will run into are changes under the hood.
.getn(table) is now #table which causes issues with things like lua edu tools.

Though personally I think .getn() makes a lot more sense, so putting it back seems like a good idea.


Janus.

Janus,

In your own .lua and .celx code, you have to write your own getn function. I use follows:

to replace table.getn() in Lua5.1 because table.getn() is no longer available in Lua5.2 onward.

Replacing getn in lua 5.3 that I use in my own stuff is on my todo list when I get back to this part of my self education
As I say, I am not a real C/C++ programmer.
I especially hate macro expansion, cryptic shorthand and heavily ifdef'd code.
I have this silly notion that source code is for people, and binaries are for computers.
Replacing stuff like getn with # is silly to me, the former flows on scan, the latter not so much, at least not to me.

Right now I am stuck on embedded stuff for a customer, some of their stuff stopped communicating.
Quite inconvenient that.


Janus.