Open GregoryLand opened 10 years ago
I am going to tackle this once since i think getting it working cross platform could be a HUGE pain.
Why not just handle it along side the rest of the languages handled by Thrift?
Thrift may work really well or not at all. This way we have two ApiProcessors to work from so we can figure out how the interfaces should look. I have been poking around thrift and it seems designed to say for example provide remote procedure call using sockets as an interface. This meens the script on the other end has to be written to open and write to that socket. It seems to me that you would have to have the script running in its own process open a socket todo the RPC between the two running processes. The question then becomes how do we run that external process. Alot needs looked at but it seems to me that we would have to write a client program for each scripting language that we would want to interface with lorei as its own standalone program.
On Wed, Jun 25, 2014 at 10:09 PM, Skylar Sommers notifications@github.com wrote:
Why not just handle it along side the rest of the languages handled by Thrift?
— Reply to this email directly or view it on GitHub https://github.com/GregoryLand/Lorei_2.0/issues/3#issuecomment-47180821.
Yes it would require us to start the plugins. One upside to this is would allow us to have things running and using the voice engine (Think a mail notifier) rather than everything having to be reactive like it was was in Lorei. http://stackoverflow.com/questions/17369441/open-file-with-default-associated-program-using-java-c Also this seems like it's quite simple to use default programs to open stuff, so all we would have to do is add another language and make sure it can start properly. Getting the API's into using RPC without it requiring a lot of extra code (Lorei or the plugins themselves) is what makes me wonder.
Well starting the plugins wouldn't be that hard. The tricky part would be writing all of those plugins in a cross platform way. The basic embedded python interpreter wouldn't be affected by the thrift plugins at all. I think its worth throwing the python one down fast while we figure out how to get thrift working. It is going to have to be compiled and built on 2 platforms at least across 2 architectures.
On Wed, Jun 25, 2014 at 10:23 PM, Skylar Sommers notifications@github.com wrote:
Yes it would require us to start the plugins. One upside to this is would allow us to have things running and using the voice engine (Think a mail notifier) rather than everything having to be reactive like it was was in Lorei. http://stackoverflow.com/questions/17369441/open-file-with-default-associated-program-using-java-c Also this seems like it's quite simple to use default programs to open stuff, so all we would have to do is add another language and make sure it can start properly. Getting the API's into using RPC without it requiring a lot of extra code (Lorei or the plugins themselves) is what makes me wonder.
— Reply to this email directly or view it on GitHub https://github.com/GregoryLand/Lorei_2.0/issues/3#issuecomment-47181425.
It's not so much making sure they're all cross platform. It's making sure we make it as easy to be cross platform. Some stuff just won't work. We can minimize it, but it's still gonna happen in some cases.
MSVC isn't on thrifts supported platforms list. Actually windows isn't even on the supported list without a postix wrapper like cygwin.
On Wed, Jun 25, 2014 at 10:34 PM, Skylar Sommers notifications@github.com wrote:
It's not so much making sure they're all cross platform. It's making sure we make it as easy to be cross platform. Some stuff just won't work. We can minimize it, but it's still gonna happen in some cases.
— Reply to this email directly or view it on GitHub https://github.com/GregoryLand/Lorei_2.0/issues/3#issuecomment-47181967.
I was reading it as that's what's needed for building it from Source and compiling Thrift files. Nothing having to do with the actual run time stuff.
Right but thats the problem. We would have to build it using MSVC in order to link it with MSVC,
On Wed, Jun 25, 2014 at 11:19 PM, Skylar Sommers notifications@github.com wrote:
I was reading it as that's what's needed for building it from Source and compiling Thrift files. Nothing having to do with the actual run time stuff.
— Reply to this email directly or view it on GitHub https://github.com/GregoryLand/Lorei_2.0/issues/3#issuecomment-47183946.
Eh. Guess we'll see. Can always test it, I guess. I'd quicker move to Mingw for compilation, but I'd give up using Thrift. Else we just be building a processor for every language, and that's just not possible for more than a few languages.,
switching to mingw might be doable but i am pretty sure we would lose MSBUILD. Which means no more visual studio unless we can get it to build with mingw.
On Wed, Jun 25, 2014 at 11:26 PM, Skylar Sommers notifications@github.com wrote:
Eh. Guess we'll see. Can always test it, I guess. I'd quicker move to Mingw for compilation, but I'd give up using Thrift. Else we just be building a processor for every language, and that's just not possible for more than a few languages.,
— Reply to this email directly or view it on GitHub https://github.com/GregoryLand/Lorei_2.0/issues/3#issuecomment-47184224.
I liked python.