<Xyliton>
but isn't `sent` only for `writev` calls?
<Xyliton>
*`write`
<Xyliton>
and `sentv` for `writev`?
<Xyliton>
I have to transform it from a `write` to a `writev` though
<lisael>
mmmh looks correct (didn't see the v in the writev call)
<Xyliton>
hm...
<Xyliton>
no idea?
jemc has joined #ponylang
<lisael>
Xyliton: no idea. But it's strange to call writev() in sent()
<lisael>
I read the net package code, I don't know why it loops
<lisael>
(BTW
<lisael>
use "debug"
<lisael>
Debug(".")
<Xyliton>
How else should I do that? I don't want users to build their own frames all the time, it's just unnecessary complexity
<lisael>
prevents from passing the env all around just to debug :) )
<Xyliton>
oh, nice
<jemc>
Xyliton: have you tried calling `write_final` in your `sent` method?
<Xyliton>
but isn't write_final only for a "normal" write?
<Xyliton>
I need a writev
<jemc>
(we probably need to add a `writev_final` at some point, but for now you can ignore that and call `write_final` multiple times)
<Xyliton>
unless there's a way to convert the stuff a Writer returns into a string
<SeanTAllen>
im unclear on the connection between Writer and your sent Xyliton
<jemc>
Xyliton: it's functionally the same to call `write_final` in a loop - (and that's actually what `writev` used to do internally) - it's just that performance is a little better if you can use the `writev` syscall
<SeanTAllen>
its quite a bit better in our testing
<Xyliton>
SeanTAllen: my Frame class is using a Writer to construct the frame, which I want to wrap the data a user `write`'s to
<SeanTAllen>
ok
<SeanTAllen>
Writer.done()
<SeanTAllen>
returns an Array[ByteSeq]
<Xyliton>
yes
<Xyliton>
I'm sending that with a writev in my `sent` right now
<SeanTAllen>
which you would pass to writev
<Xyliton>
that loops
<SeanTAllen>
that is where you are losing me
<SeanTAllen>
what are you doing with that array that you are getting from Writer.done ?
<jemc>
`for byteseq in writer.done() do write_final(byteseq) end`
<Xyliton>
that's what I moved to right now
<Xyliton>
instead of calling `writev`
<jemc>
then, in the near future, when we add `writev_final`, you can use that for better perf
<Xyliton>
because having `writev` inside of my `sent` (in a TCPConnectionNotify) apparently loops
<SeanTAllen>
its not clear to me why you would want to do that Xyliton
<staticassert>
:( pony sync meeting conflicts with my company retrospective
<staticassert>
I can call in to the second half i think
Xyliton has joined #ponylang
<Xyliton>
Is there any easier method to aquire data from a JSON doc than this?
<Xyliton>
`(((data'.data as JsonObject).data("op") as I64).string())`
<Xyliton>
data' is the main JsonDoc
<jemc>
Xyliton: yes, more or less, that's the best that can be done with the current stdlib json API
<jemc>
I think it's generally agreed upon that the stdlib json package has some usability issues
<jemc>
more fundamentally, it would likely be more useful in general to have a more static JSON API
<jemc>
for example, one where you define a schema for how you expect the JSON input to look like, and the JSON parser spits out statically typed objects instead of a bunch of union types that need to be "unwrapped"
<jemc>
another option is the "cooperative-style" parsing I've seen in some lower level languages like C when parsing JSON or messagepack - give an API to say "I expect to see an I64 next, give it to me, or give an error if the input doesn't match what I expect"
<jemc>
the schema-based object API could potentially be a code generated wrapper for that cooperative style API
<jemc>
it's something I've been wanting to work on a library for, but haven't had the time to do so yet
<Xyliton>
oh
<Xyliton>
well, I guess "unwrapping" isn't "too" bad for now
<Xyliton>
is it possible to load code at runtime and execute it, btw?
<Xyliton>
it doesn't have to be in the current "context". I just would like to have a way to dynamically execute code
<jemc>
no, not yet - it's on the roadmap, and some preliminary heroic steps in that direction hae already been taken by Praetonus (getting the compiler hooked up to the LLVM JIT), but we're not there yet, and there are still a lot more hurdles to clear
<Xyliton>
I'm really looking forward to it! I'm currently trying to implement a discord bot in Pony and it would be really cool to be able to execute code while chatting with your friends
<jemc>
so, more or less, a chat-oriented REPL?
<Xyliton>
kinda
<Xyliton>
I guess I could make that work by spawning a compiler every time
<Xyliton>
and grabbing the stdout of the compile dprogram
<Xyliton>
*compiled
<Xyliton>
my current discord selfbot (based on JS right now) has an eval command which has this kind of output: http://www.hnng.moe/f/OuO
<Xyliton>
would be awesome to have that, but with pony
Praetonus has joined #ponylang
<Xyliton>
how do I give an object literal a reference to the object creating the literal?
<jemc>
Xyliton: something like `object; let creator: CreatorType = this; /* ... */ end`
<jemc>
Xyliton: what you're doing is pretty much fundamentally unsafe, unfortunately, so it can't be allowed by the compiler
<jemc>
your `object` is in a `recover` block because you're trying to recover it to an `iso`
<Xyliton>
the code you linked me does that too, though
<Xyliton>
it has the object in a recover
<jemc>
yep, I wasn't finished typing yet
<Xyliton>
oh
<jemc>
you can't pass any non-sendable references into a `recover` block
<jemc>
so your `TestWSNotify ref` can't be passed in without being deescalated to a `tag` reference
<Xyliton>
is there no way for me to get "d" inside of the timer notifyß
<Xyliton>
*?
<jemc>
let's look at what it is you're trying to do
<Xyliton>
when I receive a payload and the value of "op" is 0 I have to set "d" to the value of the payload's "s"
<jemc>
the `TestWSNotify` object is held by your `TCPConnectionNotify` object, which in turn is held by the `TCPConnection` actor
<jemc>
your timer needs to accept a `TimerNotify` that will be held by the `Timer` inside the `Timers` actor
<Xyliton>
yes
<jemc>
so they can't both have access to your `TestWSNotify` object as a ref at the same time - doing so would be fundamentally concurrency-unsafe
<jemc>
as more than one actor would have mutable access to the same memory space "simultaneously"
<jemc>
you probably need to use an intermediate actor to track your test state
<Xyliton>
.-.
<jemc>
your `TestWSNotify` object, and the `TimerNotify` object could both have access to that intermediate actor
<Xyliton>
oh, I see
<jemc>
since it would be a `tag` reference, only receiving asynchronous messages
<jemc>
I know it can be painful to comply with the ref cap rules sometimes, but it really is saving you a lot of headaches with mutex-hell (or single-threaded purgatory)
<jemc>
or at least, that's the fundamental value prop of Pony, so you kind of have to believe in it if you want to stick around :P
<Xyliton>
I'm just trying to wrap my head around this whole actor thing
<Xyliton>
so I create a new actor (not a class?) and give it to both my TestWSNotify and my TimerNotify?
<Xyliton>
should I give it to the TestWSNotify first and have it send it over to the Timer?
<Xyliton>
or do I have to create the timer in advance?
<jemc>
Xyliton: I'd recommend moving your main logic from `TestWSNotify` into an actor (maybe named `TestWS`), then make a lightweight `object is WebsocketNotify` to pass to the websocket lib
<jemc>
just like your lightweight `object is TimerNotify`
<jemc>
both anonymous objects would just exist as "glue" to help the websocket lib and timer lib forward calls to your `TestWS` actor
<Xyliton>
what should I implement in the "new" WebsocketNotify then? just forwarding the data it get's to the actor?