Re: [racket-users] How to integrate Racket with a .Net application?

2018-02-01 Thread 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.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] raco distribute help

2018-02-01 Thread Deren Dohoda
Hi everyone,

I'm having a hard time understanding the docs for raco exe and raco
distribute.

tl;dr main.rkt has to (dynamic-require user-selected.rkt) and
user-selected.rkt is written in a different #lang and requires a file from
this program. How do I glue these pieces together for raco exe / raco
distribute?

My program has two things which seem to be hanging me up. The first is that
a file is grabbed with (dynamic-require) based on a path obtained by the
user with (get-file ...). This file is written in a different #lang and
uses (require ...) for some syntax transformers.

The exe builds alright but chokes when used because it can't find the #lang
and can't find the (require ...).

Ideally the file which is given to (dynamic-require ...) could be in any
folder the user chooses, but then the (require ...) statement would be all
over the map and I don't understand what I'm supposed to do to resolve
this. If it helps, the file is already required by the program and isn't
used only by the user-selected file. ++copy-collects doesn't seem to grab
#lang folders correctly or I don't understand how to use it.

Can someone give me some guidance here?

Thanks,
Deren

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Re: Reliably propagating received log messages to ports

2018-02-01 Thread Robby Findler
FWIW, programming with evts is lots of fun. When I first encountered
it, it blew me away the kinds of things that went from very hard to
easy and enjoyable to program up.

Robby


On Thu, Feb 1, 2018 at 9:14 AM, Alexander McLin  wrote:
> Thanks all for your inputs.
>
> I tried `with-intercepted-logged` before though it didn't solve all of my
> issues, though as Robby mentioned, my code probably isn't accurately
> capturing all of the start and exit nuances my need reflect, I'll need to
> think more about the big picture to do a better job of capturing it.
>
> gneuner2, I think your idea combined with either `with-intercepted-logged`
> or `with-logging-to-port` will go a long way towards solving my problem. I'm
> unsure by what is meant by "shutting down the logger" I'm guessing you mean
> associating a will with the logger so when the thread is killed or the
> custodian is shutdown, the will will execute and handle the final log
> cleanup? I guess using Robby's suggestion of using a channel to communicate
> start-up/exit states to a logging subsystem would help in that respect too.
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Re: Reliably propagating received log messages to ports

2018-02-01 Thread Alexander McLin
Thanks all for your inputs.

I tried `with-intercepted-logged` before though it didn't solve all of my 
issues, though as Robby mentioned, my code probably isn't accurately 
capturing all of the start and exit nuances my need reflect, I'll need to 
think more about the big picture to do a better job of capturing it.

gneuner2, I think your idea combined with either `with-intercepted-logged` 
or `with-logging-to-port` will go a long way towards solving my problem. 
I'm unsure by what is meant by "shutting down the logger" I'm guessing you 
mean associating a will with the logger so when the thread is killed or the 
custodian is shutdown, the will will execute and handle the final log 
cleanup? I guess using Robby's suggestion of using a channel to communicate 
start-up/exit states to a logging subsystem would help in that respect too.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.