<vassilvk>
Hi all! I have a question about issue labels. I'd like to contribute a PR to issue #1719, but I see it's labeled "bug: 0 - blocked". What does this label mean?
<SeanTAllen>
vassilvk: it means something else has to be fixed before that issue can move forward
<SeanTAllen>
what issue?
<vassilvk>
#1719
dlowe has joined #ponylang
Mal__ has joined #ponylang
Mal__ has quit [Ping timeout: 260 seconds]
SenasOzys has quit [Remote host closed the connection]
<vassilvk>
Any idea what's blocking it? I have a fix on my end -- building on an ARM64 system with no issues, all tests pass.
inoas has quit [Ping timeout: 264 seconds]
inoas has joined #ponylang
kempe has quit [Ping timeout: 260 seconds]
kempe has joined #ponylang
<SeanTAllen>
Ah vassilvk
<SeanTAllen>
it was blocked by not having anyone to test
<slfritchie>
Oops, I didn't fix a cut-and-paste-o in the docstring for _TestTwo
_andre has quit [Quit: Lost terminal]
<SeanTAllen>
Bombe: did slfritchie's answer help or where you already at that point and want to know how to run them?
<Bombe>
Okay, got it. I missed the part where the tests are simply a second binary that needs to be built.
<slfritchie>
Ok, good.
<Bombe>
That also means that tests always need their own directories, right?
<slfritchie>
I suppose you could add a command line flag or other signal that would run the unit test actor rather than the usual app main actor
<slfritchie>
Ha, Sean and I were talking about that yesterday: which directory should test code go in?
<slfritchie>
Both schools are feasible.
<SeanTAllen>
we did that early on at Wallaroo Labs. We had meh results.
<Bombe>
Heh. :)
<slfritchie>
The Wallaroo repo puts tests into the same dir as code that it tests.
<SeanTAllen>
Bombe, only if you have two Main functions, which generally isnt the case
* Bombe
prefers separate tests.
<SeanTAllen>
the "standard" in the standard library is that tests go in the directory with the code they are testing.
<SeanTAllen>
jemc isnt fond of that
<SeanTAllen>
i prefer the tests to be in the same package so you test private classes etc as well BUT...
<SeanTAllen>
it does mean that any dependency of your package inherits the test dependencies as well which... sucks.
<SeanTAllen>
definitely something i want to find a way to address.
<SeanTAllen>
i have thoughts. people will probably hate them.
<Bombe>
SeanTAllen, how do you run the tests when they’re in the same directory?
* Bombe
is quite new in pony.
<SeanTAllen>
well, in this case, its the only program in the directory, the rest is library code, so you can compile the _test.pony as a program and run it. or what we do is include the tests into one big test binary.
<Bombe>
Okay, but if I have an application I can not have two Main actors in one directory, right?
<SeanTAllen>
correct
<SeanTAllen>
it wont compile
<SeanTAllen>
because there are two Main methods
<Bombe>
So in that case I could: a) put the tests into a different directory, or b) put code and tests into a directory and only have a mostly-empty Main actor.
<SeanTAllen>
i didnt follow option b
<Bombe>
All code and accompanying tests go into one directory, and the “real” main class only contains a line like “App(env).start()”.
<SeanTAllen>
yes that could work
<Bombe>
Well, that should get me started, then. Thanks. :)
<SeanTAllen>
you're welcome
nisanharamati has quit []
<jbk>
i've been getting very familiar with the test framework this week :)
<jbk>
as i chase down these last few bugs
<SeanTAllen>
jbk: pony test?
<jbk>
yeah -- i'm the one that's been porting it to illumos :)
<jbk>
only 6 stdlib tests left
<SeanTAllen>
ah
<SeanTAllen>
welcome!
<jbk>
hopfully i haven't been too annyoing on the dev list :P
<SeanTAllen>
you have not
<SeanTAllen>
i pointed praetonus at your LLVM question but he's been busy.
<jbk>
the last 6 i suspect are probably all net/ failures, so it wouldn't surprise me if it's the same underlying problem causing them to fail
<jbk>
just need to dig into them to see what's happening
<jbk>
i went ahead and filed an issue -- the more i looked at the code, i'm pretty sure all the __digestof methods should have the same return type
<jbk>
it just so happens w/ LP64 that for LLVM, they both happen to be i64
<jbk>
but not ILP32
<SeanTAllen>
sorry i cant be more help. i know the runtime really well and the compiler almost not at all.
<jbk>
np
<SeanTAllen>
sylvan and i joke that i know now the runtime better than him, so we'll have to do something to change that.
<jbk>
i'm happy to dig and figure it out myself, but i also don't mind benefiting from the knowledge of others too :)
<jbk>
so i figure it never hurts to ask
<SeanTAllen>
indeed
<jbk>
and really just doign this in my spare time, it hasn't been bad at all to port
<jbk>
yay C :)
<SeanTAllen>
i started at one point and then stopped. i did dragonfly because i needed something to do one day and porting to another OS is a mindless relaxing exercise for me.
<jbk>
the biggest thing is just finding all the spots that needed updating