00:42 <Perelandric> I have a class 'Foo', which in its constructor creates an instance of 'Bar', which gets assigned to a field of Foo...

00:43 <Perelandric> If I try to pass 'this' to the Bar constructor (as an interface), it fails because it sees the Foo object as 'tag'...

00:43 <Perelandric> However, if I create the Bar without passing 'this', but then assign 'this' on the very next line, it succeeds.

00:43 <Perelandric> They are basically the same operation. Is there a reason why the former would fail?

00:44 <Perelandric> Ex: https://gist.github.com/Perelandric/63adc8b55f082202f46077d6459d1678

00:48 <doublec> Perelandric: probably because Bar could do things with the Fooable and it's not fully constructed

00:48 <doublec> Perelandric: whereas in the one that works, Bar cannot use the Fooable until a method on it is called.

00:49 <doublec> Perelandric: can you do _b.dosomething() before the _x assignment?

00:49 <Perelandric> doublec: Oh, that makes sense.

00:49 <Perelandric> Bar can't actually use Foo in its ctor that way.

00:49 <Perelandric> I'll try a method call.

00:51 <doublec> Hah, it can

00:51 <doublec> and segfaults

00:52 <Perelandric> I don't get a segfault, but my method isn't doing anything.

00:52 <doublec> Oops, no my code was wrong

00:53 <Perelandric> But I can call a method of Bar from the Foo constructor, as well as a method of Foo from the Foo via the Bar object.

00:54 <Perelandric> I did find a different kind of segfault earlier today.

00:54 <Perelandric> The code was very stupid of course.

00:58 <doublec> Looks like USize initializes to zero

00:59 <doublec> This prints the value of x before it is assigned: http://pastebin.com/qbNj82jQ

01:01 <Perelandric> Yeah, I wonder if that's reliable.

01:03 <doublec> This segfaults: http://pastebin.com/sUSDy7J0

01:07 <Perelandric> Yep, sure does. So it looks like it shouldn't be allowing that assignment after all

01:07 <Perelandric> ...at least until all fields are initialized.

01:08 <doublec> right

01:08 <doublec> 'this' is not a Foo until the fields are initialized

01:09 <Perelandric> Is it not a 'Foo', or is it a 'Foo tag'?

01:09 <doublec> Right, Foo tag is fine

01:09 <doublec> Perelandric: do you want to raise an issue?

01:10 <Perelandric> Sure, I can do one in a little bit.

01:10 <Perelandric> Thanks for the help!

01:11 <doublec> Perelandric: np, good spotting to find the initial problem

04:08 <Scramblejams> Just got ponyc: src/libponyc/ast/ast.c:425: ast_id: Assertion `ast != ((void *)0)' failed.

04:09 <Scramblejams> ponyc was freshly git-pulled, running on Debian 4.3.0-1-amd64

04:10 <Scramblejams> http://pastebin.com/ShdE2RbD the culprit is on line 12, the crash occurred when I added the "val" to the function signature

04:11 <Scramblejams> Without the val it doesn't compile :-) but it doesn't assert, either.

04:31 <Scramblejams> Got another one, "ponyc: src/libponyc/type/subtype.c:1033: is_nominal_sub_x: Assertion `0' failed." Pastebin: http://pastebin.com/0Andgq90 Appears to be adding the "val" to line 17

04:32 <Scramblejams> Off to bed...

11:54 <jsaacmk> good morning, this program causes a segfault when compiling with the latest docker for ponyc http://pastebin.com/mmZxN4Ec

12:22 <SeanTAllen> jsaacmk: i believe there's an issue open for that

12:24 <SeanTAllen> hmmm i cant find it, might not be. can you open an issue jsaacmk ?

12:24 <jsaacmk> sure

12:32 <SeanTAllen> thank you

12:33 <SeanTAllen> i'm pretty sure the issue is the recursive nature of your type definition

12:35 <jsaacmk> I'm going off of what I see in String.read_int since the tutorial section for generics isn't finished yet. I'm writing up an RFC for numeric parsing and I'm making an implementation to play with

12:38 <jsaacmk> what does the error "not enough type arguments" generally mean?

12:48 <Perelandric> Scramblejams' first issue can be reduced to this...

12:48 <Perelandric> fun msg(s: String val = String) => lambda()(s) => None end

12:49 <Perelandric> And the second one is reduced to this...

12:49 <Perelandric> lambda() => let foo: val = Array[String] end

12:51 <hibnico> jsaacmk: it means that the type you are using has some generics and you didn’t fuly specify it, like writting `Array` rather than `Array[U8]`

12:56 <jsaacmk> what would be missing from this function: fun from[A: ((Signed | Unsigned) & Integer[A] val)]() => None

13:00 <hibnico> are you sure the error is from that line, not another line where this function `from` is being used ?

13:01 <jsaacmk> looks to be a calling issue. the error goes away if I don't use the function

13:48 <Perelandric> What does it generally mean when a program compiles with the "release" build but causes a compiler assertion fail with the "debug" build?

13:56 <hibnico> it means some code in the compiler is wrong, either the assertion or the code which triggered that assertion

13:57 <hibnico> the core team will probably be glad if you open a bug report with a test case

13:58 <Perelandric> hibnico: Thanks, I'll track it down and file a report. I was just curious if there was a general reason why it wouldn't cause any issue with 'release'.

13:59 <Perelandric> Maybe that's too broad of an inquiry.

14:02 <jemc> Perelandric: in general, you should not be seeing assert fails in the compiler - when you see an assert fail, it's typically because you're compiling code with an edge case that the compiler doesn't account for - the program should either compile cleanly or the compiler should print a compiler error and exit cleanly

14:02 <jemc> so whenever you see an assert fail, it's an issue that needs to be fixed

14:03 <Perelandric> jemc: Thanks. I think I just naively assumed that I'd also see some side-effect of the problem when my program runs.

14:04 <Perelandric> ...from a release build.

14:05 <Perelandric> Anyhoo, was mostly just curious. Seems come up with testing.

14:17 <jsaacmk> is there a reason why with strings, String.apply takes a USize index and String.substring takes ISize indexes?

14:38 <hibnico> substring supports negative offset, via String.offset_to_index, to reference index from the end

14:39 <hibnico> String.apply doesn’t, probably because it is a kind of low level function, which may be used very often, so should do the minimum

14:47 <jsaacmk> I see, thank you

15:53 <flutters1y> Hello, is it possible to retrieve the env.out object from other places other than the create method in main. I'm using UnitTest framework, and i want to log some benchmarking informations to the console. so I used the log method on the testhelper object. the problem is that log messages are only displayed when running the program with the --verbose option and when running with that option the program

15:53 <flutters1y> would spit unwanted information like assertions informations etc. is there another neat and easy way to do it.

15:55 <flutters1y> here is part of my test code https://gist.github.com/afritfr/3f5b86b4383e06ea47b6f0a2b903a024

15:55 <Perelandric> I discovered the "debug" package the other day.

15:55 <Perelandric> It lets you use "Debug.out(msg)", and it only shows up when you compile with 'ponyc -d'

15:56 <Perelandric> But the, I'm a noob, so others may have other options.

15:56 <Perelandric> But then*...

16:03 <jemc> Flutters1y: ponytest's TestHelper can give you direct access to the `Env` it was created with: https://github.com/ponylang/ponyc/blob/662183366eb2c4176318f174cf2de1f6ae86034d/packages/ponytest/helper.pony#L22

16:04 <jemc> just use h.env.out

16:06 <flutters1y> Perelandric: thank you that 's useful

16:09 <flutters1y> jemc: thanks forgive my noobness :p , i should learn how to search in the source code.

16:09 <jemc> no worries - it's not always obvious

16:16 <lisael> about benchmarks, it would be handy to have a standard benchmark lib, with documented good practices

16:16 <lisael> should I propose a RFC?

16:20 <lisael> I mean, I see a lot of commits stating they optimize things. With reliable, standardized microbenchmarks we could prove these statments

16:53 <SeanTAllen> Proof is a wonderful thing

17:33 <jsaacmk> Is there a reason why I128.addc isn't available?

18:26 <Scramblejams> Perelandric: Thanks for your response. Should I assume the compiler should be printing reasonable error messages rather than failing asserts, though?

18:27 <Scramblejams> Answering my own question after reading the other replies in the channel: Yes. :-) I'll file a couple of issues.

20:44 <Perelandric> Scramblejams: Yep, I think the first one should be giving an error about assigning a 'ref' to a 'val'

20:45 <Perelandric> and the second one should be a message about using 'val' only as a type.