For MyPy that won't help.. the problem is that it looks for _m5/objects/<SimObject>.py *file* which doesn't exist on disk... we have to somehow convince it to look in the marshalled data. I was playing around with this, but I haven't figured it out yet.
BTW, your suggested changes get a +1 from me. Cheers, Jason On Thu, Aug 5, 2021 at 4:00 PM Gabe Black via gem5-dev <gem5-dev@gem5.org> wrote: > > > On Thu, Aug 5, 2021 at 3:08 PM Bobby Bruce <bbr...@ucdavis.edu> wrote: > >> Hey Gabe, >> >> Just so we're on the same page, I'd like to take a moment to outline how >> I understand this problem/solution. Please let me know if I've understood >> correctly: >> >> We essentially have three components of the project which interpret gem5 >> Python code: The gem5 binary, the Marshal binary, and the Scons build >> system. The gem5 and Marshal binaries both link to the Python library, so >> we have no problems there; they should interpret things identically. The >> problematic entity is Scons which will use the host python executable when >> processing Simobjects et al. at compile time. Your solution is to offload >> the relevant Scons gem5 Python interpretations/auto-generations to the >> Marshal binary where they'll use the Python library. Is this correct? >> > > Correct. > > >> >> If so, I support this move as it makes things considerably easier to work >> with. While there is the small `--without-python` drawback, I don't >> personally see this being a big problem for the vast majority of users. >> > > Ok, great. I'll move forward with that then. > > >> >> >> I do have a few of questions (I'm not sure if you an answer them, but may >> be something to think about): >> >> 1) Will this make it easier to embed configuration scripts (such as those >> found in the `configs` directory) into the gem5 binary? >> > > That would be orthogonal to this. You could more or less do that today, > although I think in most cases you wouldn't want to since then you'd have > to recompile gem5 to change them. > > >> 2) Will this change the way we add new SimObjects or will it be >> more-or-less identical as before? >> > > There should be no change. Unrelated to this, the more I dig around in how > SimObjects are set up the more I think we may need to change something > there, but I haven't thought about that enough to know for sure if that's > necessary, or what a better system might look like. > > >> 3) One of our goals moving forward is to enforce more Python type >> annotations so we can use tools such as MyPy. We've had some problems >> running this with this due to embedding (i.e., we can't just point MyPy at >> a SimObject Python file). Do you have any idea if this could be made easier? >> > > > I'm not familiar with mypy, but looking at their website, something like > this might work? > > https://mypy.readthedocs.io/en/latest/extending_mypy.html > > It looks like it would be fairly easy to add that to gem5's python "main" > method, although of course I haven't tried it. > > Gabe > >> _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
