Binaries for LuaJit ?

[dr-dba]

Hello, i know you moved from LuaJit long time ago.
So, i would like to get that LuaJit binaries (for windows),
which cant be found in any place.
There are still sources for last LuaJit version of 1-apr-2018, without binaries,
and i do not know how to build it for windows.
probably, i can do it from MingW, but this is a separate issue by itself,
and i am not too skilfull in it, and building from sources.
(i know to build in Visual Studio, and a bit of CMake, but not skillfull)

Beside that, i like LuaJit, and would like to have a modern LuaJit TextAdept,
but i guess this is out of the question?

So just to get luajit binaries will be great for now, thank you

[orbitalquark]

Building on Windows was never really supported. You can set up a Linux VM and cross-compile for Windows from there. It should not be too difficult if you follow the instructions in *doc/manual.md*. The last commit that had LuaJIT support is here: https://github.com/orbitalquark/textadept/tree/795f72c6d49c0566517a43808ce7aaf405220f31. For reference, the following commit that removed LuaJIT is here: 5f4fbc7 in case you wanted to try and put it back into a modern version of Textadept. It would be pretty difficult to put LuaJIT into a modern version of Textadept since some Lua 5.3-specific syntax is being used (like binary operators). I'm looking to migrate to Lua 5.4 eventually, which will put LuaJIT further in the rearview mirror.

[dr-dba]

Well, probably i am blind again, but i see in the given link:
https://github.com/orbitalquark/textadept/tree/795f72c6d49c0566517a43808ce7aaf405220f31
5f4fbc7
only source code without binaries .. ?

It would be pretty difficult to put LuaJIT into a modern version of Textadept since some Lua 5.3-specific syntax is being used (like binary operators)

I think about attempt to bring it back, as for example,
binary operations can be converted with function to something like:
BinOp('$1 | $2 & $3', a, b, c)
on the over hand, that is probably too much work there, and all the related costs above feasibility.
Still, ready LuaJit binaries will help me to make transition to TextAdept from my previous "homes".
Either backporting to my "homes" some of the stuff from TextAdept.

[orbitalquark]

Sorry for the confusion. There are no binaries. You will have to build them yourself using source from the link(s) provided. Is there some reason why you need LuaJIT specifically?

[dr-dba]

Reasoning is, LuaJit itself,
it is nice to have all the windows API, either any other C/C++ just "out of the box".
there are JiT API binding to many of useful libraries, you may integrate it with other languages, etc.
"Interoperatibility".

Beside that,
i am playing with intents to integrate TextAdept in some embedded environment having LuaJit.
that is about FAR manager https://farmanager.com/
https://github.com/FarGroup/FarManager/
There is seamless LuaJit integration, and many of useful tools can be found,
but the editor there is kind of strange and limited.
FAR is a strange thing, extra good in some places, and extra bad in other, while not clear why exactly.
For example, excellent internal API for bookmarking, but when you set any bookmark,
it is not visible in document by any means.
You should write your own code just to show the line bookmarked, neither bookmark list visible, nothing! :)
Ok, you wrote you code, you think "wow, that great, good bookmarking api, many other API,
it should be great and worthy to go on"
But not, there is no, and is not possible sane line numbering.
And no line hiding. and no line wrapping. and API is strange here and there
Strangeness this is not about somebody perfectionism,
that is about to save developing effort where it is definitely possible

[orbitalquark]

I don't quite understand what you mean by "integrate". Textadept is a standalone application, so do you just want to have it talk to other components in a multi-program environment? Or do you want to have Textadept exist inside an existing LuaJIT-based application and make use of its editing capabilities? The latter is not possible -- you're better off using a standalone editing component. The former may not need LuaJIT unless you need FFI to talk to components. In that case, you might be able to build/use a Lua module that can utilize FFI, but still run inside a non-LuaJIT environment (like Textadept's Lua state). Sorry if I'm being a bit presumptuous with what you're trying to do.

[dr-dba]

> Textadept is a standalone application, so do you just want to have it talk to other components in a multi-program environment?
yess it is standalone, no, i meant no "remoting" of any kind

> Or do you want to have Textadept exist inside an existing LuaJIT-based application and make use of its editing capabilities?
yess, that is i meant, while preserving all references to authors of course

> The latter is not possible -- you're better off using a standalone editing component.
Why not? technically i can migrate TA API parts, and make some wrapping to expose "buffer" object.
For example, to migrate history module plugin is not something like "mission impossible"
it works on top of buffer, and uses a few API easy to emulate in other environment.

[dr-dba]

> The former may not need LuaJIT unless you need FFI to talk to components.
In that case, you might be able to build/use a Lua module that can utilize FFI,
but still run inside a non-LuaJIT environment (like Textadept's Lua state).

I did not thought about, but probably i should think about.
I would like to learn and figure out about.
The problem is, i will need a huge amount of advice from you,
and i would not like to abuse your or somebody else hospitality.

Just thinking.
There is cmd-console application where i want to integrate TA.
The editor also is console by itself, and there is API for the most of needed text operations.
Like "go to the certain line, change certain line, save text," so on.
But, for example, it cant wrap lines.
So we need to abstract the "line object", and expose it to TA engine.
(Probably, like you do it for ncurses?)
The TA engine know to wrap line, this is to break one single line representation to several parts,
and send back as object to FAR engine thru LuaJit module..
I can imagine, there is should be a remote TextAdept server engine.
(something like Language Server protocol probably?)
It keeps actual text representation, accept commands, and send to other application commands.
Seems to be harder to implement than, lets imagine,
some internal to application TA engine, which is DLL with stateful APIs

[dr-dba]

> Sorry if I'm being a bit presumptuous with what you're trying to do.

just an opposite, i am very grateful for suggestions/explanations coming from it :)

[orbitalquark]

The "buffer" object you're referring to is the editing component that Textadept uses, Scintilla[1]. It's a C++ component that I created a Lua interface for. You could do the same without needing Textadept. You could even copy the API if you wanted to. With regards to FFI, I did a quick search and found this: https://github.com/q66/cffi-lua. If you build it and put the DLL or whatever into Textadept's *modules/* directory, you may simply be able to do `local ffi = require('cffi')` and interact directly with external libraries from Textadept. If you wanted to do some interprocess communication (IPC), then you're better off using pipes and/or sockets since I think FFI would be a one-way interaction. Textadept's `os.spawn()`[2] could help. My Language Server Protocol (LSP) module[3] uses `os.spawn()` to talk to an external process for languages-specific features like autocompletion. For example, buffer text needs to be sent to the other process, and the other process returns a set of completions. [1]: https://scintilla.org [2]: https://orbitalquark.github.io/textadept/api.html#os.spawn [3]: https://github.com/orbitalquark/textadept-lsp

[dr-dba]

Thank you, CFFI looks promising indeed, and being actively developed.

The "buffer" object you're referring to is the editing component that Textadept uses, Scintilla[1].
It's a C++ component that I created a Lua interface for. You could do the same without needing Textadept.
You could even copy the API if you wanted to.

Correct me if wrong,
right now it is Lua module compiled for Lua5.3 ?
so for LuaJit on Windows, i should compile it as LuaJit module?

[orbitalquark]

It's not quite a Lua module. It's part of a C application compiled to use Lua 5.3, but you could extract that part to compile with any other type of Lua with the same C interface. I suspect LuaJIT would work with minimal changes.