That's is understandable. For my VS studio work though, I decided to bite the bullet and go the TCP/IP route still, because of VS being a 32 bit app. I want for users to be able to use whatever J installation they have on their system, and not restrict them to only the 32 bit j.dll engines. MS might catch up to the 64 bit, but for now VS is still a 32 bit app.
On Tue, Apr 16, 2013 at 10:39 PM, bill lam <[email protected]> wrote: > FYI j504 can use socket for communication between front-end and > j engine (J Engine Protocol) but was decommitted in J6 because its speed > was > 10x slower than direct dll calls. > > Вт, 16 апр 2013, Greg Borota писал(а): > > For my Visual Studio integration work, I did not realize initially that I > > would run into issues related to the fact that Visual Studio is 32 bit > app > > while j.dll may be 64 bit.... So what I am working right now is have ALL > > the j.dll integration via TCP/IP, the way you suggest it. Actually Python > > guys do the same, so I just need to port some Python code around... > > By they way, I never used Python before, I find it's extremely easy to > come > > up to speeds with it. About 2 hours of reading and I am pretty much at > home > > with most of Python.... > > > > > > On Tue, Apr 16, 2013 at 6:45 AM, Steven Taylor <[email protected]> > wrote: > > > > > Hi Greg, > > > > > > MS is rumoured to be working on a C# native compiler (they hired in > this > > > area towards the end of last year). The current J .dll approach is > > > probably the best approach. MS never promoted this much, but there > are a > > > few different ways of exposing CLR methods as a .dll for the current > CLR > > > versions (ie. native to managed, not over COM). I picked up on a few > > > robustness issues on this approach on various threads. So it may be > > > resource intensive to get it going well. The approach is a little > like how > > > PostSharp does it (code injection). However, C#->native would be > welcome + > > > make this step unnecessary. > > > > > > Probably interprocess comms based on TCP/IP/Http are your best bet. > ie. > > > the LINUX single responsibility, less monolithic type stuff. > > > > > > best, > > > -Steven > > > > > > > > > On 15 April 2013 19:53, Greg Borota <[email protected]> wrote: > > > > > > > http://pythonnet.sourceforge.net/ > > > > http://pythonnet.sourceforge.net/readme.html > > > > > > > > These guys call .NET from the C based python interpreter. Without > > > > implementing Python on the .NET platform like IronPython does it. > > > > > > > > So maybe that same approach would work with J too. Just throwing > this out > > > > there, maybe somebody would want to follow-on and share some more > > > details. > > > > > ---------------------------------------------------------------------- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
