<Schwarzbaer>
Out of morbid curiosity, is there some kind of Who Is Who of channel regulars?
<jemc>
not sure what you're asking
<jemc>
butI can say that anyone with an `@` next to their name is part of the "core team"
<jemc>
and many people have a matching github handle if you want more info on who they are and what they do
<Schwarzbaer>
For winksaville, I've seen his GitHub already; he seems to supply PRs every now and then. Of SeanTAllen I've found his block, he seems to have learned about Pony in 2015 from resources already existing at the time. And I know that you, jemc, are knowledgeable, but beyond that, you could, according to my knowledge, just as well be a newcomer or the guy who thought up Pony in the first place.
Pyrrh has quit [Remote host closed the connection]
Pyrrh has joined #ponylang
<jemc>
I also came to Pony via resources that already existed
<jemc>
and to be fair, it shows commits over time, not contributions in general, which are harder to measure
aturley has quit [Ping timeout: 246 seconds]
j14159 has quit [Read error: Connection reset by peer]
<jemc>
as far as "guy who thought up Pony in the first place" - that's @sylvanc, with some significant help from his colleagues at Imperial College
j14159 has joined #ponylang
<Schwarzbaer>
Thanks; I assumed that from him being the only one having commits going back as far as 2013. ^^
<jemc>
he's still involved with the project, though not really lurking in IRC as much as of late due to some personal internet access issues
<Schwarzbaer>
Looks like SeanTAllen and Praetonus are the people doing the heavy lifting these days.
<jemc>
that's one way of looking at it, though again, these graphs are showing "number of commits per unit time"
<jemc>
it's also worth mentioning that somewhere around ~2016 we had a policy change that PRs merged to master had to be flattened first
<jemc>
so you could potentially work for months on a big PR and have it only show up on this graph as a single commit on the day it was merged
<jemc>
or you could do a PR that fixes a typo for the same blip on the graph
<Schwarzbaer>
Well, sure, but given the number of commits, I'd assume that those average out.
<jemc>
well, depending on the kind of PRs you usually do, it can still have a bias effect
<jemc>
but I was mainly pointing it out because it skews the meaning of commits per unit time over the duration of the timeline
<Schwarzbaer>
Okay, noted. Point is, now I have a little bit of context on who the people I'm talking with here and on GitHub are.
<jemc>
yeah
<Schwarzbaer>
Now they're not just strings of characters and random images.
<Schwarzbaer>
(At least most.)
acarrico has quit [Quit: Leaving.]
jemc has quit [Ping timeout: 260 seconds]
aturley_ has quit [Quit: aturley_]
acarrico has joined #ponylang
jemc has joined #ponylang
jemc has quit [Ping timeout: 260 seconds]
aturley has joined #ponylang
aturley has quit [Client Quit]
aturley has joined #ponylang
Praetonus has quit [Quit: Leaving]
<SeanTAllen>
winksville is a new contributor Schwarzbaer
<SeanTAllen>
and i would say the contributor graph on GitHub can lead you astray a bit.
<SeanTAllen>
doublec for example has done a lot via his blog and here in IRC to help people learn Pony. That isn't captured in terms of a GitHub graph.
<Schwarzbaer>
Sure. But still, now I know that you're one of the core developers / maintainers, and that the report above about winksaville's PR not working for me is well-addressed with you.
aturley_ has joined #ponylang
aturley has quit [Ping timeout: 265 seconds]
aturley_ has quit [Ping timeout: 240 seconds]
dipin has joined #ponylang
aturley has joined #ponylang
khan has joined #ponylang
aturley has quit [Quit: aturley]
_whitelogger has joined #ponylang
gokr has joined #ponylang
khan has quit [Quit: khan]
codec1 has joined #ponylang
dipin has quit [Quit: dipin]
<codec1>
Schwarzbaer, it seems that pony somehow pony tries to built with the older API
<codec1>
So I guess when building ponyc it did not detect that you are using version 1.1 of OpenSSL and went with the older API
<codec1>
actually, you may try by calling make with an option for openssl
<codec1>
make use=openssl_1_1_0 [target] should do it
samuell has joined #ponylang
_andre has joined #ponylang
gokr has quit [Ping timeout: 248 seconds]
gokr has joined #ponylang
khan has joined #ponylang
<Schwarzbaer>
codec1, thanks, but no. `make clean`, `make use=openssl_1_1_0`, trying to build the net example again, same output with old names: http://dpaste.com/3WRD0B4
<Schwarzbaer>
This sure is a headscratcher, and definitely above my paygrade.
<codec1>
thanks for trying regardless
<Schwarzbaer>
Thanks for trying to help. :)
codec2 has joined #ponylang
dipin has joined #ponylang
dipin has quit [Quit: dipin]
codec1 has quit [Read error: Connection reset by peer]
dipin has joined #ponylang
<SeanTAllen>
Schwarzbaer: you wouldnt do "make use=openssl_1_1_0" from what I can see. What did you read that suggested that is what you would wan to do?
<Schwarzbaer>
This: <codec1> make use=openssl_1_1_0 [target] should do it
<SeanTAllen>
I don't know where that is from
<SeanTAllen>
codec2: where did you get that "use" idea for make from?
<Schwarzbaer>
That's what codec1 said right before I reported the result.
<jemc>
Schwarzbaer: yeah, that's the same sha and branch as the link he pasted above
<Schwarzbaer>
...which I find suspicious, as that's marked as from 17 days ago, thus I'd rather ask again; maybe GitHub hasn't picked up on winksaville's push yet?
<jemc>
the contents of the push look correct to me - they contain the changes that were discussed over the last few days
<jemc>
note that the date that github shows for a commit is the timestamp encoded in that commit
<jemc>
which can be anything - it can even be forged as being in the future or the distant past
<jemc>
in this case, it was probably an artifact of how the commit was squashed
<Schwarzbaer>
Pulled the branch, rebuilt ponyc (with `use=openssl_1_1_0`), tried rebuilding examples/net/ (with `-Dopenssl_1_1_0`), same failure as before.
vaninwagen has quit [Ping timeout: 260 seconds]
<Pyrrh>
Hi. So I've been lurking for a while to get a feel for things around here and I think I like what I see. I'm here to help with documentation and was planning to start with this open issue: https://github.com/ponylang/ponyc/issues/1829
<Pyrrh>
However, I've poked around the repo and the only 2 files I see that contain any mention of 'stdlib' that aren't a #include are packages/stdlib/_test.pony and README.md. I don't think either of these places will help. Can anyone point me in the right direction?
<Schwarzbaer>
Pyrrh, I have no clue, but what I'd do is to go to the stdlib docs, pick out a random sentence somewhere, then search for that in the source, and that should give you a good indication on how the stdlib docs are generated.
<Schwarzbaer>
If it is all generated from docstrings, I'd next mention that on the issue, asking "Don't you mean in the tutorial, not the stdlib docs?", and look into the tutorial repo to find a nice place for it.
<Pyrrh>
Excellent idea, thanks! I'll see where it takes me
<Schwarzbaer>
But all that's just what I'm guessing that I would do. As I said, I have no clue.
<Schwarzbaer>
I'm just here to supply my utter incompetence as quality assurance of the "Let's make sure things are sufficiently foolproof" kind. ^^
<jemc>
Pyrrh: the standard library / "stdlib" is basically just the entire contents of the `packages` directory
<jemc>
with each subdirectory being a package in the standard library
<jemc>
the "exceptions" to that statement are `stdlib` (which is the aggregation of all standard library package unit tests), and `builtin_test` (which is the unit test set for the `builtin` package)
<jemc>
also, welcome!
vaninwagen has joined #ponylang
vaninwagen has quit [Client Quit]
samuell has quit [Quit: Leaving]
khan has quit [Quit: khan]
<Pyrrh>
I did notice that stdlib consists of all the packages while trying Schwarzbaer's idea :) But, since there isn't any text besides the word 'Package' and then the name of each of the packages on the stdlib.ponylang webpage, it's not clear where this note about contribution was intended to go
<Pyrrh>
I could see arguments for adding a blurb to the main stdlib docs page, and for putting it in a tutorial doc. I think I will leave a comment on the open issue and see what comes back from the person who opened it
<jemc>
that sounds like a good idea - I'm not sure off the top of my head where that comment needs to go to make it end up on that page
<jemc>
and sean may have already put some thought into it that he can share
<Schwarzbaer>
IMO the tutorial is a better place anyway. Making PRs is not a stdlib element, it's more meta, relating to Pony as a project. And while the tutorial is rather technologically oriented, too, towards the end it peters out into ever more general topics.
xllndr has quit [Quit: Leaving]
<Schwarzbaer>
For that matter, what is pony-stable, can I think of it as a package manager, and isn't that also something that should be mentioned in the tutorial, and if so, wouldn't it be reasonable to crack up a new chapter, "ecosystem", for pony-stable, PonyTest, and maybe others that I don't know of yet?
<Pyrrh>
That's a really good point. I would think separate docs for the stable version and the in-development version is preferable
<Schwarzbaer>
Errrrwha? How did you come up with that now? And IMO that's something that already exists implicitly. If, for instance, the stdlib docs are generated from docstrings, then, to get the doc for the stable version, generate them from that codebase. No additional overhead, no risk of divergence. As for the tutorial, that's where we run into the issue of there being several repos (I guess that's another argument for
<Schwarzbaer>
monorepos), but still, you could make branches of that that correspond to major milestones in the compiler.
<Schwarzbaer>
Another additional advantage, though one probably only reapable with quite a bit of up-front effort, would be that of doctests, that *might* be applicable to tutorials, too. Then when someone changes something about the language, you'd automatically notice that something in the tutorial breaks.
aturley has joined #ponylang
aturley has quit [Quit: aturley]
HarryHaaren has joined #ponylang
<HarryHaaren>
Hey Pony's, I'm interested in the language from a real-time audio POV. I'm curious about the realtime-safe aspects of the GC. Is there any in-detail docs on that?
<jemc>
what kind of GC details are you looking for?
<Schwarzbaer>
HarryHaaren, the sum of my knowledge: "Pony-ORCA is a GC algorithm that works distributed and without ever stopping the world."
<HarryHaaren>
jemc: particularly I'm curious if it makes system calls (or libC calls) that have unbounded execution time
<HarryHaaren>
thanks @Schwarz
<jemc>
to give a quick summary, some of the most important details are that garbage collection is per-actor (each actor has its GC happen independently as part of its own scheduling), and it always happens between behaviours - a behaviour execution will never be interrupted by the GC (or by anything else, really)
<jemc>
to put it another way, GC may delay your receiving of asynchronous events, but the synchronous processing of a received asynchronous event will not be interrupted/delayed
<HarryHaaren>
good point - understood.
<HarryHaaren>
jemc: give its per-actor, does that mean that it is also "stack only" or does the GC of the actors involve the heap aka; malloc() / free()?
<jemc>
no, it's not stack-only - we have a heap based allocation system, but we work with LLVM optimization passes to try to convert allocations to being stack-based whereever we can in the compilation proess
<Praetonus>
HarryHaaren: The runtime uses a custom memory allocator for heap allocation instead of malloc and free
<HarryHaaren>
jem: thanks for the details
<jemc>
right, we have our own "heap" on top of the system heap and reuse mememory where possible
<HarryHaaren>
@praeton: gotcha. Does the custom allocate use a mempool to reduce / remove system calls (eg: malloc/free?)
<SeanTAllen>
Pyrrh: ping me and we can talk about that issue
<Schwarzbaer>
This is sooo far over my head... I'd still be interested in listening in though.
<HarryHaaren>
real-time is a funky use case - basically, no "unbounded" execution. Your code must execute with a known upper limit of time.
<SeanTAllen>
HarryHaaren: yes, there's a pool to reduce malloc/free calls
<HarryHaaren>
@schwartz: As a result, its not allowed to call system calls: malloc() is a system call implemented by the OS, and your thread could get context-switched out.
<SeanTAllen>
there's not real-time guarantees in the pony runtime. there's no enforcement of an upper bounds on execution of anything.
<jemc>
HarryHaaren: if you want hard-real-time in pony, you're going to have to think about it in the context of within a single synchronous actor behaviour
<SeanTAllen>
Pyrrh: email me at sean@monkeysnatchbanana.com if you want. i can point you in the right direction.
<HarryHaaren>
@sean: Right - that's bang on the money of what I'm looking for. Thanks for the details.
<Schwarzbaer>
My intuited response would be that any system where sufficient amounts of magic (like GC) happen in the background, cannot guarantee limited execution times, and that pure C would be the better option. On the other hand I'm now curious what your specific use case is, so that it can be guesstimated whether you're sufficiently safe to never actually run into a problem.
<HarryHaaren>
@jem: yes - but single actor means single "thread/pthread" in this case.. which manes.. well, no advantage of using Pony :)
<jemc>
when you start talking about async message passing, you're already into "unbounded" territory, I think
<SeanTAllen>
there's nothing magic about a gc anymore than there is magic in malloc.
<HarryHaaren>
right - gc/malloc() isn't the problem - its the unbounded exec time of a system-call thats the root problem
<SeanTAllen>
HarryHaaren: pony performance is quite excellent but it was not built to be a realtime system
<HarryHaaren>
@schwartz: I'm currently coding in "plain old C". Always interested in things to make my life easier :D
<jemc>
HarryHaaren: are you doing any pthreaded/parellel constructs in your C code?
<SeanTAllen>
realtime systems like you speak of HarryHaaren, in my experience, are rather... specific. i runtime like Pony would be hard to make in a generic realtime fashion.
<HarryHaaren>
@sean: understood - thanks. I'll play with it anyway. UI, audio analyis, etc could all be implemented in Pony : just the RT stuff needs to be rt-safe
<SeanTAllen>
the FFI support in Pony is quite good, you can probably do a lot there.
<SeanTAllen>
not trying to discourage, just set reasonable expectations.
<HarryHaaren>
@jemc: basics yep. I've been prototyping a DAG graph-based work-stealing RT-safe method.
<jemc>
HarryHaaren: yeah, I think that may be the direction to go - you'll find that pony plays very nicely when you want to plug in C code and vice versa
<SeanTAllen>
it sucks to invest time in something based on unreasonable expectionations.
<SeanTAllen>
also, i'd love to see what you come up with HarryHaaren
<HarryHaaren>
@sean: agree on RT safe is niche, and agree on C-FFI being nice.
<jemc>
I had some fun a few years back with doing audio programming in *Ruby*, of all things - the only reason it worked is because I kept the RT stuff in C, and just made Ruby the controller of the DAG
<HarryHaaren>
thanks for the level-set too! :) Yeah I'll be around - generally high-perf network software is my thing, which I think you're familiar with yourself based on the 714 Barcelona talk
<SeanTAllen>
714 barcelona talk?
<HarryHaaren>
@jem: hah - a friend (@wrl) is doing similar stuff with mruby and C