Here's r1! https://github.com/DFHack/dfhack/releases/tag/0.42.06-r1
Thanks to everyone who helped test the pre-releases and reported back.
Thanks for your team effort!
There are any plans to include support, as a dependency, for Luasocket in DFHACK ? https://github.com/diegonehab/luasocketApparently it is all that is needed to
use most of lua debuggers out there! ZeroBrane ->
https://studio.zerobrane.com/It supports windows, linux and OSX platforms, lua versions from 5.1 up to 5.3 and visual studio.
1. 4600 C code
2. 2500 Lua code
3. 4700 man code
With each new DFHACK version more and more external DF utilities use some kind of remote connection with DF to have access to its internal in real time.
The Network support that luasocket brings for the Lua language
https://github.com/diegonehab/luasocket/blob/master/doc/lua05.ppt is object oriented, extensive, standard, documented, tiny (as it does not weigh a lot, as we have seen) and it has interfaces polished over the years.
Should we question what would represent more effort in the long term?a) Integrating luaSocket
once as a dependency and have access to their bug corrections and evolutions.
b) Integrating little by little the regions of functionality that are actually used in DFHACK.
My concern is that if we continue to use the path b) we could lose some corrections or have interfaces slightly differing one of the other for one operation of the same kind, depending of the version of luaSocket taken at the moment of their integration into the DFHACK base, this could be potentially tricky and time consuming for the DFHACK developers, the project will have a reduced functionality (substandard), hardships in the maintenance versus really little reductions in the number of lines integrated into DFHACK...
And we should not forget that the blobs of lines copy-pasted and adapted in a project are maintained as a whole
only by this project, however if a project includes another as a dependency and then adds over some adaptations, their responsibility in the maintenance is limited to their own internal adaptation, if they use the interfaces of the depended upon project.
My opinion is that option a) gives more possibilities and requires less developer effort over the long term, but also that it could generate some initial breakage of some utils (specially if some transitory transparent support for the old system is not enabled for a few versions) and worse, it would generate one actual peak of work that maybe no one have the time or interest to do.
There are any other opinions about the convenience or not of opening such an issue in DFHACK?