c355e3b has quit [Quit: Connection closed for inactivity]
SilverKey has joined #ponylang
SilverKey has quit [Quit: Cheerio!]
aturley has joined #ponylang
trapped has joined #ponylang
aturley has quit [Ping timeout: 272 seconds]
jemc has joined #ponylang
SirWillem has quit [Ping timeout: 240 seconds]
M-hrjet has quit [Ping timeout: 240 seconds]
M-hrjet has joined #ponylang
copy` has quit [Quit: Connection closed for inactivity]
aturley has joined #ponylang
aturley has quit [Ping timeout: 244 seconds]
jkleiser has joined #ponylang
jkleiser has quit [Client Quit]
jonrh has quit [Ping timeout: 260 seconds]
gornikm has quit [Ping timeout: 260 seconds]
russelldb has quit [Ping timeout: 260 seconds]
adamkittelson has quit [Ping timeout: 260 seconds]
russelldb has joined #ponylang
gornikm has joined #ponylang
SilverKey has joined #ponylang
jonrh has joined #ponylang
adamkittelson has joined #ponylang
darach has quit [Ping timeout: 260 seconds]
darach has joined #ponylang
aturley has joined #ponylang
gornikm has quit [Ping timeout: 260 seconds]
gornikm has joined #ponylang
aturley has quit [Ping timeout: 244 seconds]
SilverKey has quit [Quit: Halted.]
jemc has quit [Ping timeout: 250 seconds]
nyarum has joined #ponylang
nyarumes has quit [Ping timeout: 244 seconds]
nyarum has quit [Ping timeout: 244 seconds]
nyarum has joined #ponylang
<akant>
time for another "dumb" question: does anyone know how to make an actor not "tag"? It also seems strange that I can't change the default reference capability of an actor.
<akant>
Like, shouldn't I be able to make a "val" actor?
nyarum has quit [Ping timeout: 244 seconds]
nyarumes has joined #ponylang
nyarum has joined #ponylang
nyarumes has quit [Ping timeout: 252 seconds]
aturley has joined #ponylang
<doublec>
akant: you wouldn't be able to call behaviours on it
lispmeister has joined #ponylang
aturley has quit [Ping timeout: 252 seconds]
<srm`>
why not ? you can call behavior on tag
hibnico has joined #ponylang
Applejack_ has joined #ponylang
tm-exa has joined #ponylang
SilverKey has joined #ponylang
aturley has joined #ponylang
aturley has quit [Ping timeout: 264 seconds]
Praetonus has joined #ponylang
<Praetonus>
akant: Why would you want a val actor? Do you have some pseudo-code for what you have in mind?
Applejack_ has quit [Ping timeout: 250 seconds]
aturley has joined #ponylang
aturley has quit [Ping timeout: 260 seconds]
hibnico has quit [Quit: hibnico]
hibnico has joined #ponylang
_andre has joined #ponylang
c355e3b has joined #ponylang
aturley has joined #ponylang
hibnico has quit [Quit: hibnico]
aturley has quit [Ping timeout: 240 seconds]
hibnico has joined #ponylang
<shepheb>
SeanTAllen: final state on fast JSON parsing is that this parser is less convenient to use but very fast (say 100MB/s)
<shepheb>
and that allowing the GC to run during parsing is a great way to make the performance awful.
<shepheb>
I can turn it into a PR eventually, and optionally rewrite the existing one to use it internally while presenting the same API
<shepheb>
still no diagnosis on why there's a hundreds-of-MB memory explosion with the original parser for the same files.
tm-exa has quit [Read error: Connection reset by peer]
aturley has joined #ponylang
aturley has quit [Ping timeout: 258 seconds]
<SeanTAllen>
shepheb: we are looking for a bug that might explain that last bit. we have several indications it exists. your problem sounds like the one i've been tracking down.
hibnico has quit [Quit: hibnico]
tm-exa has joined #ponylang
<shepheb>
happy to supply more intel if needed.
<shepheb>
unfortunately I can't access the latest version of the code at the moment; I'm at work and didn't push the code off my laptop after the weekend.
SilverKey has quit [Ping timeout: 276 seconds]
Applejack_ has joined #ponylang
<shepheb>
I think the optimal JSON parsing experience will be obtained when recursive type aliases are allowed, so that we can dispense with the wrapping types and just have type JsonValue is (String | U64 | F64 | None | Array[JsonValue] | Map[String, JsonValue])
aturley has joined #ponylang
hibnico has joined #ponylang
<Applejack_>
Hi, a question on actors and threads: say you have 4 actors, A1 A2 A3 A4, together with the Main actor A0, and I have two threads: A0 calls behaviors A2.b and A3.b which are long computations, then A0 later calls A4.b which is a short computation. Then A4.b will have to wait for A2.b and A3.b whereas If I had used 3 threads then A4.b could have gone onto thread 3 which could have switched for a bit with thread 1 or 2 and thus c
<Applejack_>
I ask this because this is how I interpret playing around with the --ponythreads switch
<srm`>
A0 is called sequentially
<srm`>
so the process with be in one thread .
<srm`>
A0 : A2.b(), A0 : A3.b(), A0 : A4.b()
<srm`>
so A4.b already waited A2.b() and A3.b()
<shepheb>
that's not correct.
<shepheb>
the behavior calls will be fired in the order they appear in A0
<shepheb>
but they just queue up the behavior to run later, and return instantly.
<Applejack_>
shepheb: that's what I had understood, yes
<shepheb>
since the behaviors you're calling are all in different actors, they can run in parallel
<srm`>
When chapter 5 about generics will be available ? :)
<shepheb>
how many real machine threads/cores are running at once depends on the load and size of the program and so on.
<shepheb>
it also shouldn't matter, usually.
<Applejack_>
But by default ponyc summons 1 + #cores threads, no ?
<shepheb>
maybe? I don't know.
<shepheb>
that seems plausible.
<shepheb>
what I'm driving at is that the number of machine threads is not usually important.
<Praetonus>
The number of schedulers threads defaults to the number of physical cores
<shepheb>
--ponythreads lets you limit it, if necessary to keep it from tying up the machine, for example.
<Applejack_>
shepheb: well, it has some importance on some code I test. So what I'm trying to get at is: is it expected that tweaking the number of threads could improve the total execution time? I mean, significantly.
<Applejack_>
I mean, 30% or so
<shepheb>
that I'm not sure about. I'd suspect that it wouldn't make much difference on a large program, and could be very noisy on small benchmarks.
<shepheb>
but I've never really played with those flags.
<Praetonus>
More scheduler threads => more concurrent behaviors (limited by the hardware core count). So in the general case, yes
<Applejack_>
Praetonus: so if I use more than 1 + #cores threads, then I should not see significant improvements ?
<SeanTAllen>
shepheb: my json encoding code would also be very happy to have recursive union types
<Praetonus>
One other thing to keep in mind is that the runtime uses the physical core count. So if your machine supports hyperthreading, tweaking the --ponythreads flag up might be a good thing for performances
<Applejack_>
I see
<SeanTAllen>
srm`: re generics chapter- when someone writes it. not trying to be flip. there are a couple people who said they would tackle it but they are busy with other things at the moment.
<srm`>
ok thanks
<Applejack_>
But as for my example with actors A0, A1 etc., is it correct in what it predicts for the time to finish A4.b ?
<SeanTAllen>
Applejack_: no
<srm`>
in my opinion there is a lack of documentation and sample SeanTAllen but i found this very good information on https://github.com/sylvanc/pony-lecture
<srm`>
maybe you can add a link about this on the official website
<Applejack_>
SeanTAllen: how come ?
<SeanTAllen>
Applejack_: because A2, A3, A4 can all take different amount of times to complete. The messages would arrive at them in order (given you are on a single machine) but based on mailbox size etc, there's no guarantee when the will execute
<SeanTAllen>
or for that matter, how long executing takes
<SeanTAllen>
there has to be a direct casual relationship for casual messaging to come into play
<Praetonus>
Given the number of scheduler threads here, I think it is right
<Applejack_>
I was asking "ideally", it's a thought experiment
<Applejack_>
to understand the fundamental link between actors' behaviors and threads
<Praetonus>
If A0 is on thread 1 and all other actors are unscheduled, the messages to A2, A3 and A4 will schedule these actors on the same thread as A0. Then the second thread will try work stealing and get A2 (or A3 if thread 1 has finished processing A0). So A4 will have to wait until A2 or A3 is finished
<srm`>
like i said :)
<Applejack_>
Praetonus: That's what I understand too
lispmeister has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<akant>
doublec, Praetonus: I would like to be able to create a val actor so I can retrieve some let val fields from it (e.g., id) which will never change on my actor. Something tells me that this probably isn't supported though, now that I think about it.
<akant>
I'm sure I can refactor my code around this (passing and storing this information to the actor that wants it) but it seems like I should be able to do something like that.
<akant>
(from a theoretical standpoint)
aturley has joined #ponylang
trapped has quit [Read error: Connection reset by peer]
trapped has joined #ponylang
<jemc>
akant: I don't think this is supported, because the compiler doesn't let you specify a receiver capability on actor constructors or behaviours
<jemc>
behaviours always have a `ref` receiver, so the actor always has a `ref` view of itself
<jemc>
as long as a `ref` exists, it is not possible to have a `val` reference to the same object
<jemc>
your best bet is the one you alluded to - package up the immutable fields you want to share into a `val` object that the actor holds, and can share at will
<akant>
s/ref/tag I think
aturley has quit [Ping timeout: 276 seconds]
<akant>
jemc: thanks for the thorough response!
<akant>
<3
SilverKey has quit [Quit: Halted.]
<jemc>
akant, actually I did mean `ref` - an actor sees itself as a `ref`, though all other actors see it as a `tag`
tm-exa has quit [Quit: Computer has gone to sleep]
SilverKey has joined #ponylang
unbalancedparen has joined #ponylang
hibnico has quit [Quit: hibnico]
tm-exa has joined #ponylang
aturley has joined #ponylang
aturley has quit [Ping timeout: 246 seconds]
aturley has joined #ponylang
aturley has quit [Ping timeout: 244 seconds]
SilverKey has quit [Quit: Halted.]
SilverKey has joined #ponylang
TwoNotes has joined #ponylang
Applejack_ has joined #ponylang
nyarumes has joined #ponylang
nyarum has quit [Ping timeout: 258 seconds]
aturley has joined #ponylang
SilverKey has quit [Read error: Connection reset by peer]
SilverKey has joined #ponylang
tm-exa has quit [Quit: Computer has gone to sleep]
tm-exa has joined #ponylang
tm-exa has quit [Quit: Computer has gone to sleep]
SilverKey has quit [Quit: Halted.]
SilverKey has joined #ponylang
trapped has quit [Read error: Connection reset by peer]
<SeanTAllen>
doublec: good morning other side of the world!
<doublec>
Morning SeanTAllen :)
<jemc>
doublec: thanks :)
<jemc>
as I mentioned in the PR, this is a pattern that I've been wanting to write about for a while now, but hadn't gotten around to it
<jemc>
when I first started working with this pattern, I realized that it did a great job of addressing a major problem I had encountered with other asynchronous service architectures before
<jemc>
(specifically, the problem of wanting to, but not being able to construct higher-level atomic operations from multiple API calls)
SilverKey has joined #ponylang
<jemc>
it also reminds me of a talk I watched a year or so ago (but don't remember the name of) where they were talking about a similar idea in the context of distributed "big data" services
<jemc>
with the idea being that you bring the function the machine where the data is instead of bringing the data to the machine where the function is
<jemc>
I think they were calling this the "silo pattern" in the talk, or something like that, but when I've tried googling for "silo pattern" I haven't found anything relevant to the talk
<jemc>
anyway, thinking about it that "big data" context is also interesting as we move toward distributed pony
* jemc
drones off, imagining a distributed pony setup with locality-bound actors operating on local "big data" with `memmap`
<SeanTAllen>
Something like that is at the heart of what we are building jemc