04:52 <emilbayes> Coming from a ducktyped, dynamic langauge, how do you deal with runtime input in a strongly typed language such as Pony? Concretely I'm thinking query parameters in HTTP. Is it just as I'm used to, that you write out a whole bunch of validation by hand or can you leverage the type system in some way? I guess not, since that functionality is lost when

04:52 <emilbayes> compiled?

04:57 <doublec> emilbayes: generally you'd parse the query parameters into some typed structure to help you verify things

04:58 <emilbayes> doublec: You can do that at runtime? Maybe I'm misunderstanding how pony is compiled

04:58 <doublec> emilbayes: In typed languages there are things you can do to track at compile time the general state of runtime things

04:59 <emilbayes> doublec: Arr ok, I thought all the checking was lost once the program was compiled

04:59 <doublec> emilbayes: that's a lot of what the 'value dependent types' work is - tracking array sizes, a runtime value, at compile time.

04:59 <emilbayes> doublec: Yeah, with the compile time expressions?

05:00 <doublec> emilbayes: some of that, yeah

05:00 <doublec> emilbayes: even without that, phantom types can let you do things like track state information in types

05:01 <doublec> emilbayes: here's some rust examples https://bluishcoder.co.nz/2013/08/15/phantom_types_in_rust.html

05:02 <emilbayes> doublec: Thanks, will have a read!

05:07 <emilbayes> doublec: That was exactly what I needed. Thank you. There are so many new concepts and patterns to learn when you have types

05:08 <doublec> emilbayes: yes, lots of cool things can be done. Especially with dependent types.

05:09 <doublec> emilbayes: here's another language for example that uses types to make C FFI much safer: https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html

05:09 <doublec> emilbayes: skip to the conclusion to see what safety it provides

05:10 <emilbayes> doublec: Alright! Have seen ATS mentioned in regards to Higher Order ASTs, but don't know more about it than that

05:12 <doublec> emilbayes: I'm a big fan of ATS - it's quite low level though. It has no GC and type safe pointer handling. Things that require 'unsafe' in Rust can be done in safe code.

05:12 <doublec> The downside is it is quite verbose and requires a fair amount of annotations in functions.

05:13 <emilbayes> doublec: How do the ecosystems around strongly typed languages usually play out in practise? It seems that you're much more at the mercy of the module/library author and their use of the correct abstractions than in something weak such as Javascript

05:14 <doublec> emilbayes: yes, that's true. You're very much constrained by how the module author designed things.

05:14 <doublec> emilbayes: I'm also a dynamic type fan. I have great mental battles over what to use sometimes :)

05:15 <emilbayes> doublec: Haha, I can already see that in the horizon too

05:15 <doublec> emilbayes: I like Oz and Self as examples of dynamic languages.

05:15 <doublec> emilbayes: And Lisp

05:16 <doublec> I tinker with semi abandoned languages a bit, hence Oz and Self.

05:16 <emilbayes> haha was just about to say

05:16 <emilbayes> Lots of obscure languages I've barely heard about

05:17 <doublec> I like bits off all of them. I like the Self development environment where you are programming with live objects.

05:17 <doublec> I like Oz's logic, dataflow and distributed programming model

05:17 <doublec> I like ATS types

05:17 <doublec> Pony concurrency

05:17 <doublec> I need a weird merge of them all

05:18 <doublec> Pony seems like a good mix of what I like to program in at least

05:18 <emilbayes> Oz sounds interesting

05:19 <doublec> it is - it's used as the language for the examples in https://mitpress.mit.edu/books/concepts-techniques-and-models-computer-programming

05:19 <doublec> which is a great book

05:20 <doublec> Sadly the main implementation did a rewrite for the next version which seems to have stalled

05:21 <doublec> So people stopped using the current version because the rewrite was coming along and people aren't using the new version because it's not finished

05:21 <emilbayes> Oh, so it kinda died?

05:22 <doublec> I prefer "in a holding pattern" - the older implementations are still usable to explore ideas - but yeah, seems mostly dead.

05:22 <emilbayes> Hmm,.. I'll have a look at that book. Maybe I can find a PDF online

05:23 <doublec> emilbayes: there's a PDF of a pre-release draft around

06:02 <njbartlett> Hi, I asked the following question on the mailing list but it kind of got lost in the noise:...

06:04 <njbartlett> Is there a Pony language spec? One of the presentations I’ve seen suggests that it exists but I haven’t found it yet. Otherwise it seems like the tutorial is the canonical source of information (or… the compiler source?)

06:48 <doublec> njbartlett: I have not seen one

06:48 <doublec> njbartlett: there are papers that describe it in detail but nothing I'd call a spec

06:50 <njbartlett> doublec: Thanks, do you have a link to any of those papers?

06:50 <doublec> njbartlett: https://github.com/ponylang/ponylang.githaub.io/tree/master/media/papers

06:51 <doublec> njbartlett: the fast/cheap one particularly

06:52 <doublec> njbartlett: or the opsla one

06:52 <njbartlett> doublec: Thanks… slight typo in your URL, here’s the correct URL for others: https://github.com/ponylang/ponylang.github.io/tree/master/media/papers

06:52 <doublec> oops, not sure how the 'a' got there

06:53 <njbartlett> I wonder if there would be interest in writing a spec… maybe this should be an RFC

06:54 <doublec> njbartlett: there's still a bunch of change going on. Value dependent types to be merged, distributed model, etc.

06:55 <njbartlett> doublec: Yes I’m sure, so the spec would leave those sections TBD until the 1.0 release of the compiler. There’s plenty of other language features that seem quite stable.

07:00 <doublec> njbartlett: I'm sure it'd be useful - the pony devs tend to be around here a couple of hours from now.

07:01 <njbartlett> doublec: Yeah they’re on UK time? I’m usually in UK but currently in Japan

07:01 <doublec> njbartlett: I think they are, yes

08:23 <skanur> Hello. I'm going through the tutorial section of Pony and I've stumped by recurring use of this word "receiver". Who's a receiver? A function? object? behaviour? argument of a fun or be?

08:28 <skanur> Nevermind, I did a ctrl+F :)

08:29 <skanur> and found it being well defined

18:38 <TwoNotes> Release .3.0 *might* have fixed issue #1000. Still testing.

18:40 <SeanTAllen> that would be cool. also, long time to see TwoNotes

18:41 <TwoNotes> Yeah, I had put things on the back burner until this SegVio problem got fixed. This release seemed to have enough gc fixes that is was worth testig again

18:42 <TwoNotes> I had a similar problem maby years ago on the DEC Bliss compiler. We finally had to have the memory allocation/free code write a log file to find the problem

18:42 <TwoNotes> Turned out the same chunk was getting freed twice

18:43 <TwoNotes> We added a lot of defensive code to the memory pool mechanism

18:44 <TwoNotes> Issue 1000 would turn up almost immediately in the speech in/out code. Unfortunately this is a VERY complicated program and it was impossible to narrow down a test case

18:45 <TwoNotes> So far it has not crashed. I will engage more modules gradually to exercise more code paths and see what happens

18:46 <TwoNotes> Woops. Just crashed as soon as I turned on the 'trace' function, which prints out messages moving over the UDP interface. Well, that's a clue

18:58 <TwoNotes> WHat we did back then was, add a "magic value" just before every malloced block. (Soo malloc actually grabbed 4 bytes more than requested) Then checked for that value being there on 'free' calls. This was all under conditional compilation of course

19:00 <TwoNotes> Could also add "asserts" at any point to check that any suspicous pointer still had its magic value in place. If not, the pointer was probably bad

19:33 <TwoNotes> Nope/. Problem is still there

21:11 <TwoNotes> I am putting assertions into the scheduler and actor modules to check validity of actor pointers. For now I use a test that the pointer value must be greater than 0x1000.

21:14 <TwoNotes> The hope it to catch the bad pointer earlier, perhaps as it gets pulled off a queue, or 'stolen'

21:14 <TwoNotes> Would the probablility of a scheduler stealing an actor increase if I reduce the thread count?

21:15 <SeanTAllen> what does your trace function do?

21:15 <TwoNotes> Just prints JSON messages to stdout

21:15 <SeanTAllen> can you gist the code?

21:15 <TwoNotes> It might not be related to that. I suspect a timing thing. It does not happen all the time

21:17 <TwoNotes> The tracing code is just calls to Debug.out("Rcv:" + s) where 's' is a String

21:19 <TwoNotes> The code is all in https://github.com/pdtwonotes/secretary/blob/master/packages/seclink/seclink.pony

21:19 <TwoNotes> Just look for references to '_tracing'

21:24 <SeanTAllen> thakns

21:28 <TwoNotes> Keep in mind, I have only seen this problem on ARM, not on x86_64. That might be significant

21:35 <SeanTAllen> and we never did an official 64 bit ARM port. Just 32 bit. You are on 64 bit right?

21:37 <TwoNotes> ARM is in 32b mode

21:37 <TwoNotes> Both machines have 4 CPU cores. The x86_64 is quite a bit faster

21:38 <TwoNotes> The ARM hardware is an Rpi3, which I think is actually 64b, but the Arch Linux I have on there only runs in 32b mode. I think

21:50 <TwoNotes> Ah, no ARM is an armv7l, which is 32b hardware