[issue15352] importlib.h should be regenerated when the marshaling code changes

Change by aaa dsghsu : Added file: https://bugs.python.org/file49901/442723 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge added the comment: Hmmm, not sure why I forgot to apply this myself. Thanks for committing it Eric. -- ___ Python tracker ___

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow added the comment: Thanks for the patch Meador. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 -Python 3.3 ___ Python tracker

[issue15352] importlib.h should be regenerated when the marshaling code changes

Roundup Robot added the comment: New changeset 344f44bd793f by Eric Snow in branch 'default': Issue #15352: Rebuild frozen modules when marshal.c is changed. https://hg.python.org/cpython/rev/344f44bd793f -- nosy: +python-dev ___ Python tracker

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow added the comment: FWIW, the patch looks good to me. This is probably the last week to get this in for 3.3.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352 ___

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge added the comment: Yup, it is still an issue. The recent activity was mostly related to Windows builds (issue15431). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352 ___

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow added the comment: Meador, is this still a problem? There was a flurry of activity in this area. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352 ___

[issue15352] importlib.h should be regenerated when the marshaling code changes

Antoine Pitrou pit...@free.fr added the comment: Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent. What do you mean with idempotent? Deterministic? -- ___ Python tracker rep...@bugs.python.org

[issue15352] importlib.h should be regenerated when the marshaling code changes

Antoine Pitrou pit...@free.fr added the comment: Le lundi 16 juillet 2012 à 05:42 +, Meador Inge a écrit : The order of 'co_cellvars', 'co_varnames', and 'co_freevars' can be different from compile to compile, thus the bytecode can be different from compile to compile (I am not sure if

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge mead...@gmail.com added the comment: On Mon, Jul 16, 2012 at 5:20 AM, Antoine Pitrou rep...@bugs.python.org wrote: Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent. What do you mean with idempotent? Deterministic? Whoops, yeah, deterministic.

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge mead...@gmail.com added the comment: On Mon, Jul 16, 2012 at 7:13 AM, Antoine Pitrou rep...@bugs.python.org wrote: I don't know, but you could open an issue just for the record. People may be surprised if bytecode generation isn't deterministic. Yeah, I was somewhat surprised and

[issue15352] importlib.h should be regenerated when the marshaling code changes

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352 ___

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge mead...@gmail.com added the comment: Eric, that is a good point, but if someone forgets (like I did) or just hasn't gotten around to bumping the number yet, then the build breaks because the interpreter crashes. I think we should always try to avoid building an interpreter that

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge mead...@gmail.com added the comment: Hmmm, I guess the idempotency issue is no worse than it already is -- the same thing can still happen with trivial changes to the other prerequisites for importlib.h. Consider this small example (you might have to run sample program multiple

[issue15352] importlib.h should be regenerated when the marshaling code changes

New submission from Meador Inge mead...@gmail.com: Today I was hacking on a patch that changes the marshaling format for Code objects. When building the patch I was met with: ValueError: bad marshal data (unknown type code) make: *** [Lib/_sysconfigdata.py] Abort trap: 6 This is

[issue15352] importlib.h should be regenerated when the marshaling code changes

Meador Inge mead...@gmail.com added the comment: Patch attached. -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file26382/issue15352-v0.patch ___ Python tracker rep...@bugs.python.org

[issue15352] importlib.h should be regenerated when the marshaling code changes

Antoine Pitrou pit...@free.fr added the comment: Looks good to me. It probably won't cover all cases (such as e.g. changing the bytecode format), but it's a good step forward. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow ericsnowcurren...@gmail.com added the comment: FYI: the .pyc magic number is now built/kept in Lib/importlib/_bootstrap.py, so updates to it will trigger a rebuild of frozen importlib during make. -- nosy: +eric.snow ___ Python tracker

[issue15352] importlib.h should be regenerated when the marshaling code changes

Eric Snow ericsnowcurren...@gmail.com added the comment: What I mean is, shouldn't changes to marshal have an accompanying bump to the pyc magic number? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15352