2016-08-19 17:05 GMT+02:00 João Valverde <joao.valve...@tecnico.ulisboa.pt>:
> > > On 08/19/2016 03:56 PM, João Valverde wrote: > >> >> >> On 08/19/2016 02:54 PM, Peter Wu wrote: >> >>> On Mon, Aug 08, 2016 at 09:17:35PM +0100, João Valverde wrote: >>> >>>> >>>> >>>> On 08/08/2016 05:58 PM, Pascal Quantin wrote: >>>> >>>>> Hi João, >>>>> >>>>> 2016-08-08 18:52 GMT+02:00 João Valverde >>>>> <joao.valve...@tecnico.ulisboa.pt >>>>> <mailto:joao.valve...@tecnico.ulisboa.pt>>: >>>>> >>>>> Is moving to Lua 5.3 something we should look into? >>>>> >>>>> The 64 bit integer support seems really promising. >>>>> >>>>> >>>>> Hariel explained us that Lua 5.3 was a completely different language (a >>>>> bit like what you have between Python 2.X and 3.X). You can find much >>>>> more info (from people knowing what they are taling about - so not me >>>>> ;)) in bug 10881. >>>>> >>>>> Pascal. >>>>> >>>> >>>> >>>> Thanks for that Pascal. The only sane way to approach the issue IMHO >>>> is to >>>> accept that this may and probably will break backward compatibility (not >>>> even think about supporting 5.1 or 5.2) and just consider whether >>>> that break >>>> is justified (hint: it is). >>>> >>> >>> Why is it justified to break backwards compatibility and move from 5.2 >>> to 5.3 without the ability to chose for 5.2? What is the killer feature >>> of 5.3 that makes it totally worth to possibly break older dissectors? >>> >>> The disadvantage of C plugins is that it had to be recompiled for newer >>> versions. With a move from 5.2 to 5.3 and also removing GRegex and bitop >>> you make it quite likely to break Lua dissectors in some way. >>> >>> I have once written a Lua library in C, interfacing with Libgcrypt for >>> which I studied the Lua manual. The API changes with 5.3 were not that >>> significant if I remember correctly (though you have to be careful with >>> providing a compatibility layer), but the ABI is certainly not >>> compatible. >>> >>> In the recent proposed patches, you seem to have no issues with breaking >>> backwards compatibility. Have you developed Lua dissectors before? >>> Breaking things for the sake of "shiny, new, future" is not an >>> acceptable motivation, there must be something more appealing to justify >>> such breakage. Having 64-bit integer support, but taking away the bitop >>> library is a net loss without even considering the other factors. >>> >>> >> Doesn't Lua 5.3 provide native bit operators? If so there is not net >> loss of functionality. That was my reasoning at least. >> >> The language incompatibilities between 5.2 and 5.3 are minor. The >> wireshark API is exactly the same. >> >> LPeg is more powerful and Lua-thonic than lrexlib, but there is a >> learning curve for that, no doubt. For anyone relying on lrexlib, it's a >> significant break. We can keep lrexlib, that's not a problem and it is >> orthogonal to the other changes. >> >> As far as killer features go, besides the obvious, how about better >> UTF-8 support? >> >> I don't have time for a more detailed answer right now but I'd like to >> say I think this change is entirely justified but I also completely >> understand disagreeing with that opinion. >> > > I'm referring to the upgrade to Lua 5.3 here, i.e, breaking backward > compatibility, same as any other Lua script moving from 5.1/5.2 to 5.3. For what it is worth, I do not remember any user asking / pushing to upgrade to Lua 5.3 yet. Breaking their script should be justified by a huge win (I will not judge myself whether this is the case or not with this upgrade as I'm not a Lua user, so I'm not qualified here; but we must think about our existing users). C plugins are a bit of main to recompile for each version, but are fast. ON the other side Lua scripts were not as impacted as C ones with API changes, but are slower (from what I understood). Any big change here should be done with caution I think.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
