<Acorn2>
It seems to 404 at that site now. A search of the Imperial College site fails to show it. Would be a great resource to keep alive on the Internet, if possible
Matthias247 has joined #ponylang
<lisael>
He's well known, indeed. (Search for "George" in ponyc and pony-rfc github repos...)
Matthias247 has quit [Read error: Connection reset by peer]
<lisael>
Acorn2: I've got the PDF here, if you need it, drop me an email address :)
<Acorn2>
jondgoodwin@gmail.com
<Acorn2>
Thank you lisael )
<lisael>
Sent, Acorn2. You're welcome :)
<hobomatic>
is there any way to control the scheduler programmatically? I want to mess around with SDL in pony, but my experience messing around with it in go leads me to believe that you cannot really write a safe SDL program without ensuring that certain things only take place in the main OS thread, and that a window's operations have to take place on the thread that the window was created. Aside from telling the runtime just to use a single OS thread at the
<hobomatic>
command line, IDK how I would manage this.
<doublec>
hobomatic: I don't think there's a way to ensure that actors behaviours get pinned to a thread unfortunately
<doublec>
hobomatic: There has been some discussion about it IIRC
<doublec>
hobomatic: hopefully someone else can chime in
<Acorn2>
liael: For some reason, the email never arrived.
<Acorn2>
lisael
<hobomatic>
What about explicitly yielding? I think it might be feasible to model SDL in terms of actors in a single thread if I could yield explicitly at certain points
Matthias247 has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]
<doublec>
hobomatic: the only way to yield is to exit from a behaviour
<hobomatic>
i see
ShalokShalom_ has joined #ponylang
ShalokShalom has quit [Ping timeout: 240 seconds]
Matthias247 has joined #ponylang
<SeanTAllen>
hobomatic: and once you exit the behavior, your actor will continue to be run by the scheduler until there are no more messages in its queue or you hit the batch size for a scheduler run (default 100 application messages)
plietar has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]
voldyman has quit [Read error: Connection reset by peer]
voldyman has joined #ponylang
jemc has joined #ponylang
jemc has quit [Client Quit]
<Licenser>
Hmm does the ponlylang page a link of how to get/install it?
plietar has quit [Remote host closed the connection]
<SeanTAllen>
Ive been meaning to finally flesh out the first page but we are in a push to open source our product over here at Wallaroo Labs (formerly Sendence) so, I haven't had any time
<Licenser>
SeanTAllen no criticisem intended I was just wondering if I were blind :D
jemc has joined #ponylang
<SeanTAllen>
you are not
<SeanTAllen>
ive been meaning to do it for quite a while but things keep coming up
<Licenser>
I know how you feel, I've been chasing rabbits for the last three weeks, I think I've crawled down this rabbit hole all the way to austraia by now
samuell has quit [Quit: Leaving]
bdari has joined #ponylang
<bdari>
Hi...
vaninwagen has quit [Ping timeout: 240 seconds]
<SeanTAllen>
hi bdari
<jemc>
Acorn2: that's a real shame - I hope that imperial gets the PDF back up soon
<jemc>
lisael: I'd also like it if you could email me your copy (joe.eli.mac@gmail.com), and we can find another way to host it if imperial doesn't bring it back
plietar has joined #ponylang
<jemc>
hobomatic: is it *really* required that the operations take place on a *specific* thread, or just that they don't take place concurrently
<jemc>
I ask because the latter is the more "natural" constraint for code that isn't "thread safe", while the former sounds like a much more artificial restriction
bdari has quit [Ping timeout: 260 seconds]
<SeanTAllen>
@jemc i think we could put with other papers on the website
<SeanTAllen>
also, good morning Joe!
<hobomatic>
jemc: my understanding is that its a specific thread.
<hobomatic>
I don't actually understand the underlying reason, but I know that the golang SDL binding bends over backward for the initialization of SDL to take place on the main thread. Not just all in the same thread
<jemc>
which is good news for you - it just means that those functions which SDL says "must be called from the same thread" actually "must be called from the same actor" in Pony
<jemc>
in other words, your one actor that touches those functions will be acting effectively like a mutex for that global SDL state
<hobomatic>
right
<hobomatic>
OK, well, i guess i've run out of excuses then
<jemc>
so :P
<jemc>
err... the "so" was a typo
<jemc>
(leftover from starting to type something else)
<SeanTAllen>
hahaha
<SeanTAllen>
that was the best response in a while hobomatic
obadz has quit [Ping timeout: 248 seconds]
user10032 has joined #ponylang
obadz has joined #ponylang
samuell has joined #ponylang
Praetonus has joined #ponylang
plietar has quit [Remote host closed the connection]
plietar has joined #ponylang
plietar has quit [Ping timeout: 248 seconds]
plietar has joined #ponylang
Matthias247 has joined #ponylang
TheNet has joined #ponylang
<hobomatic>
Ok, trying to get a goo intuition about viewpoint adaptation, its something like 'the broadest reference capability compatible with both of these', right?
<hobomatic>
a good one too
<hobomatic>
for instance, given some type A, and some type B, if A is tag, the A->B must be tag, since there are no more 'narrow' reference capabilities than tag
<Praetonus>
hobomatic: tag->X doesn't exist since you can't look at anything through a tag
<hobomatic>
ok fair enough XD
<hobomatic>
then iso->B would need to be iso or tag, correct?
<hobomatic>
(and iso->B! would need to be tag)
<hobomatic>
and ref->B would essentially just be B
ShalokShalom_ is now known as ShalokShalom
vaninwagen has joined #ponylang
<vaninwagen>
hi, did anyone of you tried to run gcov or something similar with the ponyc tests to get code coverage?
<vaninwagen>
or llvm-cov
<SeanTAllen>
not that i am aware of vaninwagen
<vaninwagen>
seems to be a matter of adding some compile flags, i'll try tomorrow
<vaninwagen>
SeanTAllen i was thinking about the actual compile code, not the stdlib (to avoid confusion)
<vaninwagen>
*compiler code
<vaninwagen>
SeanTAllen, on another note: what do you think about creating a separate binary for the docgen process? i've been crawling through old issues and adding more cli-flags and more backends seems way easier with such a setup
<vaninwagen>
"ponydoc" or smth.
<vaninwagen>
would be an issue a good place to discuss this?
samuell has quit [Quit: Leaving]
vaninwagen has quit [Ping timeout: 240 seconds]
Matthias247 has quit [Read error: Connection reset by peer]
obadz is now known as dav0r
dav0r is now known as obadz
<jemc>
vaninwagen: largely, talk of significant enhancements to docgen has been toward using the pony-in-pony compiler that's in progress
<jemc>
so that doc generation would be written in pony, easier to organize and contribute to
<jemc>
the pony-in-pony compiler is still in progress, but docgen will be possible long before actual compilation is
<bdari>
I'm new to pony. Wondering if pony is self hosted?
<jemc>
the pony compiler and runtime are written in C - there's some ongoing work to port the compiler to pony
<achamber1>
jemc: is it an official port? or more like an alternative compiler for now?
<achamber1>
and how far along is that?
<jemc>
achamber1: it's mainly me working on it at the moment - at the moment it's a rather personal/unofficial project, but the idea is that it'll become "official" later
<jemc>
parsing and the first few compiler passes are in places, but there's still a *lot* left to do
<jemc>
for now I'm in the middle of a detour of adding a few features to the existing compiler that will make my other work on ponycc easier
<achamber1>
oh really cool. :D Maybe one day is can be used for an auto formatter too
<achamber1>
how much code can it parse?
<jemc>
achamber1: it should be able to parse pretty much everything, except for a few very recent features like bare lambdas
tscho has quit [Ping timeout: 240 seconds]
<jemc>
that is, the parser should be a feature-by-feature match for the ponyc parser from N months ago
<jemc>
it has some limited/dumb code printing features too, but atm those are basically used mainly for testing (to prove that parsing then printing a given snippet yields the same exact text)
<jemc>
so yes, you could conceivably write an auto-formatter based on it starting today, if you wrote your own smart/pretty printing code for the AST data structures
tscho has joined #ponylang
<bdari>
Does pony use green thread?
<SeanTAllen>
depends on your definiton of green threads bdari
<SeanTAllen>
the short answer is probably no
<SeanTAllen>
the pony scheduler starts 1 scheduler thread per available CPU
<SeanTAllen>
actors are scheduled on those threads
<SeanTAllen>
so if you have 4 cpus, there will be 4 scheduler threads
<SeanTAllen>
each one locked to a given CPU
tscho_ has joined #ponylang
<SeanTAllen>
additionally there is the "main" thread that does nothing after the program starts
<bdari>
So it uses Kernel Threads
<SeanTAllen>
and an async io thread that receives async io message from kqueue/iocp/epoll and delivers them to the receiving actor
<SeanTAllen>
bdari: yes, i say "depends on your definition" as I've seen some odd definitions of "green threads"
tscho has quit [Ping timeout: 240 seconds]
bdari has quit [Ping timeout: 260 seconds]
bdari has joined #ponylang
<bdari>
My apologize. My Internet connection is not quite good this morning.
<jemc>
bdari: in some ways, pony uses actors in lieu of green threads - the actor takes the same conceptual place in the mind map of the concepts
<jemc>
that is, just like a green thread, the actor is the user-facing unit of concurrency, but it doesn't map 1:1 to a kernel thread
<jemc>
but it's not *really* a green thread, it's an actor
<jemc>
hopefully that makes sense
<bdari>
Actor is similiar to fiber in this case?
<SeanTAllen>
Not really
<SeanTAllen>
Are you familiar with the actor model bdari?
<bdari>
No i'm new with actor model.
<bdari>
Just read about it last night :)
<jemc>
bdari: here's a brief rundown o how to think about pony actors:
<SeanTAllen>
Hmmm, ok. I'm trying to think of the best way to explain.
<SeanTAllen>
saved by joe!
<jemc>
an actor has behaviours, which are like methods that get executed asynchronously from when you call them, and thus don't return anything to the caller
<jemc>
so calling a behaviour is like saying "do this thing later", where "this thing" is a method body that has access to the actor's internal state
<jemc>
an actor can only execute one behaviour at a time, and a behaviour will never be interrupted
<jemc>
so you can sort of think of them as a transaction over the internal state of the actor
<jemc>
you could also sort of think of it as cooperative scheduling similar to fibers, where the "yield to other fibers" point is the end of the behaviour body
<SeanTAllen>
Work stealing is rather efficient when there is lots of work to do, its overly greedy and can hurt performance when there is not a lot of work to do and lots of scheduler threads are mostly idle
<SeanTAllen>
There's improvements to be made there but so far everything ive tried has had a negative impact of "peak" performance, so I haven't pushed for inclusion of any of the ideas
<bdari>
@jemc thank you for the paper. i'll read it :)
<bdari>
@SeanTAllen It still can hurt performance when idle. Nice to know this.