Memory leak fix.

[eaplatanios]

This is pulled out of #152 as @endrift suggested. I'm not sure if it's ok now even though I get no errors when I check it with valgrind (I was getting errors when I wasn't using strdup). Who is supposed to own the memory pointed to by data and free it? @endrift do you have any suggestions?

[christopherhesse]

It's not clear to me what RETRO_ENVIRONMENT_GET_SYSTEM_DIRECTORY is used for, could this just return like the path to the directory that the retro shared object is in? If it returns some sort of global constant, retro can easily own the memory for the duration of the process.

[endrift]

I'd cache the strdup'd version on the Emulator class (check if it's null and call corePath() if it is) and delete it at destruction time. It never changes after the first call so this is safe. That said, because it's not changed I'm not sure the buffer will ever be invalidated, so the original version may already be safe. It's not entirely clear to me, given C++'s wishy-washy memory safety guarantees.

[eaplatanios]

@endrift @christopherhesse I made the requested change. Could you please take another look?

Also, what is role of atari-py relative to retro? If one wants to play around with atari environments which one do you recommend using and why?

[christopherhesse]

Retro is nice if you want consistency with other retro games, but ALE is faster, see #127

[eaplatanios]

Thanks for the quick response! Are there plans to tackle the issues mentioned in that post? Also, when you say faster, what kind of difference have you measured? Is it significant?

[christopherhesse]

I don't remember, but I believe it is significant, something like 2-3x faster per frame for ALE. If you use a large model or have a lot of CPUs, maybe it doesn't matter as much, but there's definitely a speed difference.

[endrift]

lgtm now

[christopherhesse]

Thanks @endrift and @eaplatanios!