On Fri, Aug 29, 2008 at 3:37 PM, Thomas Heller <[EMAIL PROTECTED]> wrote: > Anthony Tuininga schrieb: >> Hi, >> >> In relation to the problem I have been experiencing I froze the >> script I wrote (that accesses AutoCAD) and attempted to run that on >> the machine that is not working properly. It still doesn't work but I >> discovered something in doing so that may be of interest to this >> group. >> >> It seems that if an application is frozen you have one of two >> choices: >> >> A) import the generated module yourself sometime before calling >> something like GetActiveObject() that will generate it for you B) >> accept the overhead of regenerating the generated modules > > Anthony, sorry that I didn't understand completely the first time > what you were trying to say. The intent was that the import of the > generated module was meant to instruct the freezer to include > the imported module into the exe, independend from where this > import statement occurs. This does indeed work. > > What does not work and you have discovered is that the import statement > must be executed BEFORE the generated module is needed by a call to > GetActiveObject() or CreateObject() - in a frozen script!
True -- a limitation which could be documented, I suppose. Ideally, however, I was hoping that I could simply specify modules to include in a setup.py without having to include code snippets like the one you suggested in the right place. >> [...] I tracked it down to the fact that imp.find_module() is being >> used which doesn't understand zip files and the reason >> imp.find_module() is being used is because an attempt is being made >> to find the file in which the module is located and performing a >> "stat" on the file to determine if it is newer than the type library >> in question. The assumption is that if the module is older than the >> type library it must be up to date. > > > [from your other post] > >> Well, its kind of hard to stat a module inside a zip file. :-) >> >> I can think of a few options to get around this. >> >> (1) attempt the import and if successful, use the module.__file__ >> attribute to determine the location. At that point you can check to >> see if the module exists in the filesystem and do the stat then; if >> it doesn't (its in a zip file) you can assume that its the one you >> want or perform a stat on the zip file itself >> >> (2) put the timestamp of the type library file itself in the >> generated file name. >> > > (2a) put the timestamp of the type library file itself in the > generated code? > >> Do either of those options sound reasonable to you? I recognize you >> don't see any problem so I would be willing to develop the patch for >> whichever option you prefer it you wish. > > Well, I see the problem *now*. > > On first thought the first option looks more attractive to me but I have > to think about that - which option would you prefer? I could probably live with either. The timestamp of the generated module ought to be accurate since it was generated on the machine which has the type library. Once frozen, however, that zip file can be transported to any number of machines which leads to the following scenario: a module could be generated on a machine with timestamp 2008-09-01 referencing a type library with timestamp 2008-01-01. However, a new version of the type library is available with timestamp 2008-08-01 but is not currently installed on the machine which did the freezing. However, it is installed on the machine which is running the frozen binary. If we simply stat the zip file everything will appear to be in order -- when in fact it is not! So, my suggestion is to put the timestamp of the type library in the generated file name or, as you suggest, inside the generated code -- that should be free from such potential situations. Did you want me to come up with a patch for this or did you want to do this yourself? >>>> BTW: comtypes in SVN contains an important improvement: Code >>>> generated by a frozen script will be cached in the filesystem, so >>>> if the generated modules are not inside the frozen exe they will >>>> only have to be generated when the application is run for the >>>> first time. >> >> Yes, I noticed that. That will be helpful for the situation where >> such generation is indeed necessary. In general a frozen application >> should have all of this taken care of beforehand if it at all >> possible, IMHO -- but if you forget or are performing dynamic COM >> stuff this will be very helpful. > > My own recent impression on this new stuff (caching code generated from > *frozen* scripts > in the file system) isn't so good. The code generation is probably not robust > enough > for that - for example if the code generation is interrupted it may leave > incomplete, broken stuff > in the cache directory and the exe will fail miserably each time it is > started. To solve that problem you need to make sure that any partially generated code is not seen. One possibility is to have the file named with some prefix which is known to be bad and renamed when everything is known to be good. Or create everything in a temporary directory and rename it to the proper place later, etc. Better still, is to avoid the situation in the first place if at all possible! Hmm, perhaps there is a way of turning on some sort of flag that simply raises an exception when a generated module is not present and have that flag on by default in a frozen application? I'm not sure what the more common situation will be -- perhaps others on this list have strong feelings one way or the other? > -- > Thanks, > Thomas > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > comtypes-users mailing list > comtypes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/comtypes-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ comtypes-users mailing list comtypes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/comtypes-users
