Well, hopefully someday the allocations/processing/interpretation/compilation isn't happening on the audio thread :)
I think JIT compilation shouldn't necessarily be shied away from given class/object creation isn't realtime-safe anyways, and how much slower is it actually? Imo JIT compilation to lower-level should be considered more, like for [expr~] or maybe some heavy-like patch compiler thing that can do some of what gen~ does. somewhat off-topic: there are also some cool compiled lua-inspired languages like terra and nelua (which I was thinking of switching to for the project I was using luajit/pdlua for anyways) -seb On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <i...@christofressi.com> wrote: On 02.10.2024 18:30, Timothy Schoen wrote: > Currently, pdlua is not compatible with luaJIT, since it was updated > to Lua 5.4 (and uses some of the new features internally). It's > possible to port it back to luaJIT by taking out all the new Lua bits. > > Both have some advantages and disadvantages. But for me, regular Lua > would win (but only by a small amount). The reason is: it's > architecturally simpler, more mainstream, more widely used/tested, and > (in my estimation) more likely to be maintained for a very long time. > luaJIT is very fast, so I'm not opposed to it either. Having any kind > of scripting for objects available at all is the most important thing > here 🙂 If LuaJIT stopped working for whatever reason, we could still use vanilla Lua 5.1 - which will continue to work as long as we have C compilers :) Lua is a bit peculiar in that every minor version is really a different language. Once you pick a Lua version, you typically don't upgrade, unless there is some very compelling reason. Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or 5.4. We just have to be aware that once we pick a version, we basically have to stick with it because of backwards compatibility. Christof > > > Tim > > > On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote: >> I know it's old but I think for lua in pd luaJit should be considered >> if adding a lua. >> Imo they took out a very powerful feature in setfenv after 5.1 anyways. >> >> Luajit was still working with pdlua last I checked. >> Plus pd messages only use floats. >> >> -Seb >> >> >>  On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen >> <timschoen...@gmail.com> wrote: >> >> Yeah, +1 for pdlua for me! >> >> Here's a few more reasons I'd love to see this: >> >>           * pdlua objects require vastly less boiler-plate code than >> C externals. Especially for signals and graphics, it takes care of >> all the hard parts and common pitfalls for you. >> >>           * As a result, creating pdlua objects is much more >> beginner friendly, and experienced programmers are less likely to >> make mistakes. Not requiring compilation makes writing coded >> externals as accessible as abstractions are currently. >> >>          * The biggest weakness for a project like pdlua is needing >> to be installed manually. This discourages people from directly >> uploading their Lua objects on Deken. Like porres said, ELSE now >> ships with pdlua just so that we can ship lua objects. It would be >> amazing if we could assume them to just work. >> >>          * As you might know, Lua is very compact, it can be >> compiled by adding "onelua.c" to your sources, and it has no external >> dependencies. For ease of maintenance, it's as good at it gets. Lua >> is also fast for a scripting language. Seems like the perfect fit for >> pure-data. >> >> >> If you want a sample of the API, here's the documentation for pdlua >> graphics: >> https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics >> >> Tim >> >> >> >> >> On 02/10/2024 06:12, Alexandre wrote: >> >> >>> >>> >>> >>> Let me share Tim's thoughts he sent me via a chat about coding >>> externals in lua, which I think are a perfect sell. Compared to C >>> externals, lua externals: >>>           * Encourages open-source, since the source code is the >>> object >>>          * Works on every OS, architecture, pd floatsize, >>> multi-instance, all without needing recompilation >>>          * You can easily modify objects if you want to >>>          * GUIs are now much easier to write with Lua than with C >>>          * Are guaranteed to keep working even if Pd's C API >>> changes, or Pd changes GUI framework >>>          * Are guaranteed to work across Pd forks, as long as they >>> correctly implement the lua API >>> >>> >>> >>> >>> >>> >>>   Em ter., 1 de out. de 2024 às 15:36, Alexandre <por...@gmail.com> >>> escreveu: >>> >>> >>>>     Em seg., 30 de set. de 2024 às 16:59, Christof Ressi >>>> <i...@christofressi.com> escreveu: >>>> >>>> >>>>>>>>>    Thanks to Antoine for mentioning pdlua! I will need to >>>>>>>>> check it out. I have already seen people doing some very cool >>>>>>>>> stuff with it. Maybe they already have the perfect solution :) >>>>>>>>> >>>>>>>>> >>>>>>>> I'm also looking at pdlua, which might want to become the >>>>>>>> official way to make graphical externs AND to add scripting in >>>>>>>> a fundamental way to Pd :) >>>>>>>> >>>>>> +1 for an official scripting language! :) (I love Lua, BTW.) And >>>>>> yes, it would make lots of sense to leverage the scripting >>>>>> language to implement custom UIs! >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> +1k >>>> >>>> >>>> >>>> >>>> >>>> Yay, great to hear that! BTW, I remembered about this ticket we >>>> opened years ago inquiring about adding lua to Pd >>>> natively! https://github.com/pure-data/pure-data/issues/687 >>>> >>>> >>>> >>>> >>>> Now that Tim is doing great work for graphics, this would be even >>>> more awesome! And I wouldn't have to worry in shipping it in ELSE >>>> for some externals that already use it :) >>>> >>>> >>>> >>>> >>>> cheers >>>> >>>> >>>> >>> >>> >>> >>> >>>    --- >>> pd-dev@lists.iem.at - the Pd developers' mailinglist >>> https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7336XE2JMZUA36FUJQRW53/ >>> >>> >> >> --- >> pd-l...@lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-l...@lists.iem.at/message/GG7IF7MWRGC2CO6MSWCL2AJVZJ5BEILC/ >> >> >> >> To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ >> >> --- >> pd-l...@lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-l...@lists.iem.at/message/TJOTDRAY3L5MFJN2UM5GYZPUNP743QSK/ >> >> >> >> To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ > > --- > pd-l...@lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-l...@lists.iem.at/message/F6CWKKSQHEBW3OCIWQJGG47VH3RAJAZV/ > > > > To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/ --- pd-l...@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-l...@lists.iem.at/message/GY5ULQJGM4GKCZ7A5QHCKMDYWJKCF4LU/ To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/ --- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/3EGNKUFKCMKTUIDWWBPNRRXYHDI6MEU5/
