Jump to content

Recommended Posts

Dear ED,

 

Suggest that together with the move to 2.5, DCS world also upgrade the lua version from 5.1 to 5.2.4.

 

One of the main reasons the move would make sense is that 5.2.4 implements table finalizers (destructors). In lua 5.1 I need to help myself with the ugly newproxy undocumented function to build finalizers. The other advantage would be to be able to set ephemeron weak tables.

 

Also note that there are issues with building multiple threads in DCS. For some reason a yielded function crashes when it is resumed through an event trigger. With crashing I mean really crashing... Hehehe... DCS stops working. Highly likely there is either a problem with the local stack of the thread, or the thread got garbage collected... Don't know...

 

Anyway, I have workarounds for both the finalizers and the yield problem.

But it would he really nice to upgrade to lua 5.2.4.

 

This is what lua 5.2.4 provides additionally:

Lua 5.2 was released on 16 Dec 2011. Its main new features are yieldable pcall and metamethods, new lexical scheme for globals, ephemeron tables, new library for bitwise operations, light C functions, emergency garbage collector, goto statement, and finalizers for tables.

 

The last release is Lua 5.2.4, released on 07 Mar 2015.

 

Fc

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

I was trying to bring this up to the people I met, one of the questions was:

 

'is it fully backwards compatible?"

 

Hi Drexx,

 

Thanks for your feedback.

Who did you meet and why is meeting people relevant in this discussion?

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

He means that he's been asking what other people would think about it and their concern is if it's backwards compatible. The current version gets the job done for the most people so the question is if the improvements you describe are worth the possible issue with backwards compatibility. First of all, is there issue with backwards compatibility and if there is then what can you do with the newer version that justifies the compatibility issue? Better multithreading is meaningless unless you have some use for it that benefits the majority at least in a form of simple to use script that mission builders can use to build great missions.


Edited by Bushmanni

DCS Finland: Suomalainen DCS yhteisö -- Finnish DCS community

--------------------------------------------------

SF Squadron

Link to comment
Share on other sites

  • 2 weeks later...
He means that he's been asking what other people would think about it and their concern is if it's backwards compatible. The current version gets the job done for the most people so the question is if the improvements you describe are worth the possible issue with backwards compatibility. First of all, is there issue with backwards compatibility and if there is then what can you do with the newer version that justifies the compatibility issue? Better multithreading is meaningless unless you have some use for it that benefits the majority at least in a form of simple to use script that mission builders can use to build great missions.

 

Hi Bushmanni,

 

Thanks for your feedback, your comments make a lot of sense.

There aren't that many people in the DCS world who would be interested in this upgrade, indeed ... Only a few, and myself included... :music_whistling: There is no compelling reason why this upgrade should happen, as I wrote in the mail before.

 

But, if such upgrade would be doable, and backward compatibility would be guaranteed, it would be able for a bit more elegant lua in a couple of areas.

 

The first is how finalizers would be coded ... A finalizer is a piece of code, that gets executed when a table gets garbage collected. It is almost like a destructor, only that a destructor gets immediately executed, while a finalizer gets only executed when garbage collected...

 

Let me give an example why a finalizer is useful ... If I set a menu within lua, using MOOSE for an alive group, I can do this as follows:

 

local Plane = GROUP:FindByName( "Airplane" ) -- Find the group of a Client ...
Menu = GROUP_MENU_COMMAND( Plane, "Report", nil, ReportFunction, {} )

I would like to have the behaviour that, when the Plane gets destroyed, that then also the Menu is removed automatically...

 

Within lua, i am able to simulate this by adding the following code:

 

function Plane:_Destructor()
 Menu:Remove()
end

So, when I execute the following command:

Plane = nil
collectgarbage()

then the _Destructor method is executed ...

 

Within lua 5.1, this behaviour is implemented in a "ugly" way, by using the newproxy method. See the method here:

 

function BASE:_Destructor()
 --self:E("_Destructor")

 self:EventRemoveAll()
end

function BASE:_SetDestructor()

 local proxy = newproxy(true)
 local proxyMeta = getmetatable(proxy)

 proxyMeta.__gc = function ()
   env.info("In __gc for " .. self:GetClassNameAndID() )
   if self._Destructor then
       self:_Destructor()
   end
 end

 -- keep the userdata from newproxy reachable until the object
 -- table is about to be garbage-collected - then the __gc hook
 -- will be invoked and the destructor called
 rawset( self, '__proxy', proxy )

end

This is what i have currently in the MOOSE framework written, to implement a finalizer...

 

The code could look more elegant like this in lua 5.2:

 

function BASE:_SetDestructor()
 self.__gc = _Destructor
end

So, is not having lua 5.2 a showstopper, hardly ...

 

The second reason to have lua 5.2, is to be able to work with ephemeron tables...

 

setmetatable(mem, {__mode = "k"})

This construct is not possible in lua 5.1. The value is strong, but the key is weak. This function would be really helpful in the event dispatcher in MOOSE. It holds references to all kinds of classes that catch events... Once the key to the object is nilled, these objects should also be removed from the event catching table ... In other words, this problem solves the publish-subscribe reference problem. But i am able to solve this in lua 5.1, but need to code extra for it...

 

About the multi threaded, i think you've misunderstood my writing ... lua is not pre-emptive multi threaded. But i just wonder whether in lua 5.2, the yield() would work when a scheduled event re-schedules ...

 

In lua 5.1 i get a crash. But again, am able to work around this ...

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 3 months later...
  • 1 year later...
  • 2 years later...
  • 2 weeks later...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...