01:28 <Schwarzbaer> Hi. I've started studying Pony's tutorial, and I'm intrigued, but in the chapter on primitives I just noticed... There's no built-in primitive for unbounded integers (Decimal)? Is that packaged away somewhere? Because with Pony's insistence on the compiler being able to catch most implementation errors, I'd think that number overflows would be one of the first ones to be taken care of.

01:40 <jemc> Schwarzbaer: welcome!

01:41 <jemc> we don't currently have a standard library type for an unbounded integer

01:42 <Schwarzbaer> Huh... A bit surprising, but then again, version < 1.0

01:43 <jemc> with regard to having support for checking number overflows - that's something that would be a possibility once we have value-dependent typing work that has been specified and partially implemented, but not yet merged in to mainline

01:43 <jemc> here's the paper about the value-dependent typing: http://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/LukeCheesman.pdf

01:44 <Schwarzbaer> Thank you, but I leave the type theory to people who are more clever than me; I#ll just use it.

01:44 <jemc> for runtime-checking of overflows, we have the `addc`, `subc`, and `mulc` methods on each numeric type - it returns the result and a boolean for if you overflowed

01:45 <Schwarzbaer> I've had a feeling of "This sounds a bit Erlangish" creep up on me once or twice, and have seen message passing being mentioned. Can I hope for distributed, failure-resilient runtimes, where I just start a binary up on several machines, network them, and don't even have to worry about any of the hosts going down?

01:46 <jemc> no, we don't yet have a feature similar to erlang distribution yet - that's another one that has an academic paper, still waiting on the implementation

01:46 <Schwarzbaer> Ah, so it's planned? That's good enough for me.

01:46 <jemc> distributed applications like wallaroo (https://github.com/WallarooLabs/wallaroo) have implemented their own distribution protocols as needed

01:47 <jemc> yes, it's planned - it just hasn't been anyone's top priority at the moment

01:48 <Schwarzbaer> Now for the real longshot: SQL support. Probably relegated to "Hopefully someone will somewhen write a library"?

01:49 <jemc> heh, I'm surprised that out of those three you thought that one was the longshot :D (unless that was sarcasm)

01:49 <jemc> I think somebody is actively working on an SQL library, but I'm not sure of the status - let me see if I can find it

01:52 <jemc> hm... sorry, whoever it is, I think they were just working on it in private and hadn't pushed it to GitHub yet

01:54 <Schwarzbaer> Ummm, no, that wasn't sarcasm, that was "These people are building an interesting language, so the 'weird' features will probably come before the industry standard ones."

01:54 <jemc> ah, fair :)

01:55 <Schwarzbaer> On the other hand, I assume and hope that there already is support for network sockets?

01:55 <jemc> oh yes - those are heavily used

01:55 <jemc> by pretty much everyone using pony :)

01:55 <Schwarzbaer> Excellent. Ever heard of OTP or Astron?

01:56 <jemc> I've heard of OTP as in Erlang's Open Telecom Platform, but maybe that isn't what you mean, as I had to google for Astron

01:57 <Schwarzbaer> Not quite; Disney's OpenThemePark (which Astron is inspired by), their MMO server infrastructure.

01:58 <jemc> yeah, that's new to me :)

02:00 <jemc> looking briefly at the README, it definitely seems like the kind of thing that would make a good pony project, though

02:01 <Schwarzbaer> OTP isn't available to the public, and Astron's development came to a grinding halt weeks before it would have become usable-by-my-standards; so when I stumbled upon Pony, I thought "This seems like the language someone would use to implement the next iteration of Astron". So, since sockets are available, distributed platform is apparently something that'll just "happen to be there" at some point in the future, and

02:01 <Schwarzbaer> even SQL being in the works, yeah, I agree, this might be an interesting project...

02:02 <jemc> what is the model for "distributed objects" in astron - are they replicated, or just placed onto arbitrary servers?

02:03 <jemc> (and what's the consistency like for them - eventual? strong?)

02:09 <Schwarzbaer> Oh jeez, I've last worked with it... three years or so ago?

02:10 <Schwarzbaer> IIRC there was no replication for them yet, and they did live on specific servers. Can't remember how a decision for their placement was reached, though, I *think* it had to do with the "zone" that the dobject was in, and it possibly moved between servers when it changed zones.

02:12 <jemc> makes sense

02:13 <Schwarzbaer> As for consistency, strong, but dobjects have very little intelligence, just state-keeping and message-routing, so any kind of consistency management was basically kicked up the ladder to the processes that manipulated the state.

02:14 <Schwarzbaer> That could involve up to three (IIRC) types of view, each with their own code, and different permissions for different fields.

02:16 <Schwarzbaer> Well, I'll sleep on it and browse Pony's tutorial a bit more tomorrow. Good night.

02:24 <jemc> good night!

11:22 <Schwarzbaer> After finishing the tutorial chapter on types, I have a feeling of "That's what Haskell people are talking about. At least when they're not talking about monads, as Pony does seem to have mutable instances."

11:23 <Schwarzbaer> I've noticed, though, that I haven't seen a Function type so far. As behaviors aren't promises, I assume you'd need a Function type to implement a callback or promise?

11:24 <Schwarzbaer> ...or is this a matter of "You don't want to use those anyway, here's a better pattern..."?

11:30 <Schwarzbaer> ...except for the obvious "Just kick of your cascade of behaviors, and the result will appear... some time somewhere."?

12:18 <lalomartins> there are both (lambdas and promises): https://patterns.ponylang.org/async/actorpromise.html

13:12 <SeanTAllen> @Schwarzbaer you might be interested in Wallaroo: https://docs.wallaroolabs.com/

13:13 <Schwarzbaer> Thanks, I'll look into it, lalomartins

13:13 <Schwarzbaer> SeanTAllen, why? Is this regarding the possible Astron rewrite mentioned yesterday?

13:15 <Schwarzbaer> I've given Wallaroo a casual glance (it's how I learned about Pony), but it doesn't really seem applicable.

13:20 <Schwarzbaer> One thing the Hello World page of the tutorial neglected to mention: How does execution get started? Does Pony simply create an instance of each actor in a program?

13:21 <Schwarzbaer> Never mind, it didn't neglect it, it just hid it after the fat "That's it".

13:22 <lisael> pony calls the create constructor of the Main actor in the compiled package, passing an Env

13:25 <lisael> Hello, there, BTW :)

13:33 <Schwarzbaer> Hi indeed. Yes, that's the bit that was hiding.

13:56 <SeanTAllen> Schwarzbaer: yes, re Astron

14:13 <Praetonus> slfritchie: Regarding your question from yesterday about message IDs: IDs are assigned by the method colouring algorithm (it's in reach/paint.c if you'd like to have a look.) They change on every compilation because code generation isn't deterministic. It's because some hashmaps in the compiler base their hash on the values of pointers, which results in non-deterministic hashmap iteration. That's an issue we'll have to fix at

14:13 <Praetonus> some point. You can get an executable from LLVM IR by using Clang. Unfortunately the resulting executable isn't usable for some reason. On Linux you'll have to do `llc file.ll` which will generate `file.s`, and then `clang -fuse-ld=gold file.s -lponyrt -ldl -lpthread`. As I mentioned, the resulting executable has some severe runtime issues that make it unusable. I don't know why it is happening, and I don't know if it happens on

14:13 <Praetonus> other platforms

14:53 <Schwarzbaer> SeanTAllen, I haven't looked into the actual API, but Wallaroo seems to be geared towards "We'll set up this processing pipeline to perform computations, and then we'll dump constant streams of events into it, and get derived values out of it." That seems a very far cry from "We'll have this thing with a bunch of states in it, and clients connecting and disconnecting all the time, a bunch of access controls,

14:53 <Schwarzbaer> different views for different clients on those states, and a whole lot of message routing from clients to state, from state to clients, and from clients to state to clients".

16:55 <winksaville> I was looking at creating a test for the --bin-name change and it seems the only test that calls genexe is packages/stdlib, is there some method in test/libponyc/util.cc that would work?

16:59 <Praetonus> winksaville: What do you want to test exactly?

17:01 <winksaville> I want to test that if --bin-name is passed to the compiler the resulting executable binary exists and runs

17:06 <Praetonus> Hm, that's a good question. Currently the compiler tests don't create executables and instead run the test programs in-process through a JIT compilation, so you'd need a new test method for your test

17:09 <winksaville> OK, txs

17:28 <slfritchie> Praetonus: Thanks for the outline, I'll work a bit on it. I've got a bug that has a message passing infinite (?) loop. DTrace can tell me the message ID that's involved in the cycle. The LLVM IR seemed to be the only way at the moment somehow to find the behavior name.

17:35 <Praetonus> slfritchie: I did some testing and I've found why my binaries were behaving wierdly. I was missing some linker command line arguments. By using the arguments used by ponyc (which can be seen by compiling a program with `ponyc -V3`), it seems to work correctly. Incremental compilation from an IR file would be a nice feature though, and it shouldn't be too hard to implement. I'll add it to my todo list