I learned Clojure using your Nightcode IDE, excited to play around with paranim
+ paravim!
Bumping the thread for another release. Notable changes:
* Added server generation for JavaScript target
* Added configuration options to control generation of server/client code
* Added hooks into the service macro to provide imports specific to
servers/clients
* Added hooks into the ser
ome. The github repo has more information, and
I've started documenting the individual modules as well.
[https://github.com/nepeckman/nerve-rpc](https://github.com/nepeckman/nerve-rpc)
Well what if I also modify the server procs and pass in some sort of session
param? Then you can use that session information to get the appropriate client
connection, and pass that into the client proc, then sending a request to the
same client that invoked the server. Apologies for the back-an
Just had an idea that I really like as a solution to this issue. I can modify
the param signature of every remote proc to add a transport function with a
default as the last argument. So a proc like `proc greet(greeting, name:
wstring): Future[wstring]` gets modified to `proc greet(greeting, nam
Ideally, I think that should be handled at the api level. Say program A sends a
request to service X on program B, and as a result program B needs to send a
request to service Y on program A. My solution would have service X import a
client for service Y (with no global state in the transport me
The `routeRpc` macro does not actually send the result to the client, it just
does the procedure dispatch and comes back with the response. It falls on the
user to implement the network code, HTTP server, websocket server, or whatever
else, then they can use `routeRpc` inside that network code.
> Here's the thing. I've played with Rust a little bit and one of things that
> put me off it, apart from the syntax, is the ownership/borrowing mechanism.
> This is great for use-case #3 as you can have safe memory management, an
> annoyance for use-case #2 and a huge overhead for use-case #1 w
Hmmm I see the issue. I think I already need some configuration macros to
determine when to build a client vs a server for each service, and I think I
can work multiple clients with different connections into that need. Thanks for
all the feedback, gonna work hard to make sure this is a solid li
Sure thing, was thinking something like:
proc newTransportFunction(conn: Connection) =
result = proc (req: JsonNode): Future[JsonNode] =
conn.send(req)
let conn = connectToClient()
rpc Hello, newTransportFunction(conn):
# remote proc definitions
> I have nothing against callback, though i am bit unsure how it would work in
> case where we would like client to connect to multiple servers. Seems like
> this callback would depend on some kind of global state which probably
> assumes there is one client in application.
I was originally thi
> Example makes it look like library is transport-agnostic. Seems like we could
> have both ends host their own APIs and one end could call another's APIs and
> we just pass messages between them.
The server is transport agnostic. The dispatch function that it generates takes
a JSON object, eit
Not yet. I've been considering taking the connection over websockets and
allowing both the client and server to expose an API. The logic there is a
little trickier though, so I didn't consider it for first release. Also in the
running for future feature is a native HTTP client.
This is a little project I've been kicking around for a while, and I'm finally
in a place that I'd like to show it off for feedback/suggestions.
[Nerve](https://github.com/nepeckman/nerve-rpc) is a RPC framework that
produces a fully typed JavaScript client using nothing but a m
Can you be more specific about what didn't work? The code I posted puts the
prompt on the same line as the input being read, which seems like what you were
asking. Link to hosted version:
[https://repl.it/repls/LovingOpulentOffice](https://repl.it/repls/LovingOpulentOffice)
`echo` automatically prints line end, you want `write`.
write(stdout, "This is the prompt -> ")
var input = readLine(stdin)
Run
I've got some questions as I'm trying to grok this. First, to make sure I
understand: unowned refs would need to be set to nil so the type based
allocater can free them, and owned refs will be automatically freed when they
leave the scope. Is that summary correct? If I create a owned ref and pas
The code doesn't compile as presented because of the redefinition of `file`. If
you change the second invocation of `openAsync` to `file = openAsync(filename,
fmRead)` the code will compile. The index error you get from running the code
is another matter though. I think its a potential bug in th
a web bundler, just compile
the Nim code and point the bundler towards the compiled file. But I do enough
web development that is was worth it to me to write a plugin to make the
process zero friction. This is a plugin for my preferred bundler, Parcel:
[https://github.com/nepeckman/parcel-plugi
I'm not sure its possible to parse JSON at compile time. I've tried reading the
file with `staticRead` and passing the resulting `const string` to the JSON
module, but it doesn't seem like the VM had the capability to parse JSON. If
you do figure out a way to do it, I'd love to hear it.
I'm far from a Nim expert, but I think GC safety is determined by access of
global variables. Does this section of the manual reference anything useful?
[https://nim-lang.org/docs/manual.html#threads-gc-safety](https://nim-lang.org/docs/manual.html#threads-gc-safety)
This file compiles and executes as expected for me:
import tables, sequtils
var counter = initCountTable[char]()
echo toSeq(counter.values)
Run
Not sure why it isn't working for you. What version of the Nim compiler are you
using?
Glad you find it useful! The macro checks for an existing `module.exports`
object, and if one exists, it appends its exports to the existing object
without overriding previous exports. There could be collisions if two different
files try to export an object with the same name, but for now I thin
monJS module exports
object, and this macro makes that a little easier. Not sure if it's useful to
anyone else, but figured I'd put it out there. Feedback is welcome!
[https://github.com/nepeckman/jsExport.nim](https://github.com/nepeckman/jsExport.nim)
Ah yeah, that makes sense. I've been primarily using procs to access object
fields, so I haven't run up against that problem. I definitely see the utility
of package level visibility, but I wouldn't want to introduce unnecessary
complexity to the language. I really like the cleanliness of `*` ex
I don't know if this is sufficient for your purposes, but I've emulated
package-level visibility in a side project I've been developing. Each folder
has a `.nim` file that imports the other modules in the folder,
and exports the public interface of that folder. So package-level visibility is
em
I recently learning about the --warning[ProveField] flag for object variants,
and enjoy the increased level of type checking that it provides. However, I
have a small issue using this flag alongside procedures that take a specific
branch of the object variant. The procedures shouldn't be used on
27 matches
Mail list logo
