LostKobrakai
jgwmaxwell
PragTob
Thank you for your hard work! 
Benchee updates were easier than expected (while I use the syntax a lot in benchee)… and surely I’ll finally manage to do a release soon ™ so no one will be annoyed 
Most importantly credo was broken for me, but updating to github fixed it so will open an issue asking for a release 
(edit: issue: New release soon for 1.19 compatibility? · Issue #1221 · rrrene/credo · GitHub)
I’m also not sure if I just overdid it with the struct update syntax in benchee (the answer is probably yes) but this updated didn’t feel good to make:
(added all the struct type matches in the fn, tried to do them in a separate match before usage to lessen the pain but that wasn’t accepted as I needed to do them directly on declaration)
|> Enum.map(fn {%Scenario{
run_time_data: %CollectionData{},
memory_usage_data: %CollectionData{},
reductions_data: %CollectionData{}
} = scenario, {run_time_stats, memory_stats, reductions_stats}} ->
%Scenario{
scenario
| run_time_data: %CollectionData{
scenario.run_time_data
| statistics: run_time_stats
},
memory_usage_data: %CollectionData{
scenario.memory_usage_data
| statistics: memory_stats
},
reductions_data: %CollectionData{
scenario.reductions_data
| statistics: reductions_stats
}
}
end)
Eiji
How about:
[]
|> Enum.map(fn {scenario, {run_time_stats, memory_stats, reductions_stats}} ->
scenario
|> put_in([Access.key(:memory_usage_data), Access.key(:statistics)], memory_stats)
|> put_in([Access.key(:reductions_data), Access.key(:statistics)], reductions_stats)
|> put_in([Access.key(:run_time_data), Access.key(:statistics)], run_time_stats)
end)
I really like making code short, explicit and clean at the same time. I believe it’s clear enough without pattern matching on struct, but if you really think it’s still needed then you can simply add a %Scenario{} = before scenario variable in the anonymous function.
In my opinion all you need for this code is a good typespec, so the tools can verify that we are not working on “any” map, but on the scenario struct instead. If the Scenario.t/0 type instructs that all 3 keys are CollectionData struct then I don’t think that you really need to pattern match on each of them separately. What do you think about it?
PragTob
Thanks for the idea!
Well, my trust in dialyzer and type specs isn’t very high. I’ve seen many places where I was convinced it should find a bug but it doesn’t. I can try it out but my expectation is it wouldn’t notice a typo in a key here in that form or any other. Hence I preferred to use the struct update syntax to fail as early as possible (iirc compile time) if the key was somehow spelled incorrectly. In the end it probably wouldn’t matter as the tests would fail, but that’s a couple of steps later
For similar reasons I’d probably also use Access.key!/1 when going with this approach - I like to raise when it’s basically a basic expectation of my system that the key is there. Hence, I’m also a big Map.fetch!/2 fan 
idyll
So I’ve rolled this out to some test infrastructure and I’ve noticed that :iex is no longer started by default and I need to add it to extra_applications in order to remote in…
def application do
[
mod: {Example.Application,},
extra_applications: [:iex, :logger, :runtime_tools]
]
end
^^^ as in this change is required in mix.exs or I can’t remote in via:
./bin/example remote
Not sure if this is intentional and I’ve only tried this on rc2.
The error looked like this:
19:20:21.400 [error] :gen_statem #PID<0.93.0> terminating
** (ArgumentError) could not fetch application environment :parser for application :iex because the application was not loaded nor configured
josevalim
joshknz
Sorry for not replying earlier. I’ll open an issue with the dialyzer output and go from there.