How to integrate Racket with a .Net application?

[Daniel Brunner]

Hello:

We have an application on Windows that can be extended with .Net
components (DLL). We mostly use C# for this purpose. Our idea now is to
"embed" Racket into one of these components.

After reading the documentation of the FFI and de C API I am unsure what
may a good way to accomplish that. Has anybody done something like this
or has an implementation idea?

We want to push some basic data (lists of structs, strings, numbers
etc.) to a Racket component, trigger some functions and get some result
back. This action is triggered by user input once in several days.

There are several ways I am thinking about:

- establish some sort of web service (talking JSON over HTTP)
- use the C API
- use the libraries for COM objects

Any advice or ideas would be greatly appreciated!

Best wishes,
Daniel

[Alexander McLin]

All three approaches you outlined are viable but web service is easiest to set up.

From what you described, it seems it would be a low-performance use for Racket and only simple data structures will be passed back and forth on an infrequent basis. Web service would be a good fit for that.

Out of the last two approaches, the COM approach seems to me to be the better one. Although I have never used it, Racket provides MzCOM and .NET comes with additional support for interacting with COM from within the .NET environment. It would allow you to tightly integrate Racket into your application, pass complex data back and forth and achieve higher performance throughout, but likely it would be more work. I've used COM in the past for C++ applications; in those projects it was always a lot of work to configure and integrate COM.

I would try setting up a web service first and if it's not adequate for whatever reason (performance, business requirements, etc) then I would try the COM approach.

[Greg Hendershott]

Another way is for two (OS) processes to "pipe" I/O to each other.

The back-and-forth "protocol"?

It could be as simple/ad-hoc vs. as formal/ceremonial as you prefer.

It could be text line-oriented, or JSON, or s-expressions, or raw bytes.


I might use this as a starting point, get some mileage, then decide if
it's adequate or what to do instead.

p.s. If you squint and abstract away certain details, this is similar
to the HTTP service approach.

[HiPhish]

On Wednesday, January 31, 2018 at 4:17:09 PM UTC+1, Greg Hendershott wrote:

Another way is for two (OS) processes to "pipe" I/O to each other.

This is a great idea since it would allow to integrate any language with the .NET application. It is how Neovim does it: the main application is Neovim, which is written in C, and it acts as a server for a client application written in whatever other language. The protocol used is MessagePack RPC:
https://github.com/msgpack-rpc/msgpack-rpc/blob/master/spec.md

It is built on top of the MessagePack serialisation format. In a nutshell, MessagePack is like JSON, but binary. This makes it smaller to transport and faster to pack and unpack, but it loses the nice human-readability of JSON. I think that's a good tradeoff for data that is not meant to be stored and manipulated by a person, but instead passed around between processes.
https://msgpack.org/

I have already written a general-purpose MessagePack library for Racket, as well as a language client for Neovim:
https://pkgs.racket-lang.org/package/msgpack
https://pkgs.racket-lang.org/package/nvim-client

The MessagePack library is safe to use. The Neovim client is my first time doing something with RPC, so I'm not yet ready to call it stable. The part of the codebase which implements MessagePack RPC is not entangled with the Neovim-specific parts, so once the language client matures it will be easy to take it out and make it into a general-purpose MessagePack RPC library.

[Berthold Bäuml]

https://pkgs.racket-lang.org/package/msgpack is a nice package to use. Thank you for providing it. But there is a bug for sequence lengths  >15 and <255. I filed an issue at https://gitlab.com/HiPhish/MsgPack.rkt/issues/4

Berthold

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
-----------------------------------------------------------------------
Berthold Bäuml -- Head of Autonomous Learning Robots Lab
DLR, Robotics and Mechatronics Center (RMC)
Münchner Str. 20, D-82234 Wessling
Phone +49 8153 282489
http://www.robotic.de/Berthold.Baeuml

[HiPhish]

For the people not following my bug tracker: I fixed it now.