py2exe

Lawrence Bruhmuller <lbruhmuller@...> writes:

> Hi,
>
> We've been using Py2Exe for a while.  Some time back I looked in
> boot_common.py, and found the spot where stderr was being redirected,
> and changed the log file name to suit my purposes.
>
> Recently our product has taken on the bad habit of hopping around,
> workig directory-wise, during it's lifetime.  So I really want to
> modify boot_common so that it puts this logfile where we put our other
> log files (under the user's documents dir).  This will also solve the
> problem of not getting the error log when the running user doesn't
> have write permission to the installation directory (which is the
> starting working directory, the way we have things installed right
> now).
>
> I have Python code (imports win32com.shell) that our product uses to
> find this dir, but it seems that since this is bootstrap code, I can't
> really just insert any Python code into boot_common and expect it to
> work.  I just get the program exiting immediately after starting, with
> no log, probably since this code is before the err log is set up!
>
> How should I solve this problem?

If you have a GUI application you should provide *some* way to display
errors. The code in boot_common is only the last ressort imo.

You could create both a GUI and a console app (the samples directories
show how this can be done) and run the console app instead.  This should
let you find and fix the problem!

(Sometimes I think the default behaviour should be to alloc a new
console and dump stderr output into this, when an unexpected exception
occurrs.)

Thomas

Hi Lawrence,

I use wxPython but the following should work with any Python code:

class BoaApp(wx.App):
     def OnInit(self):
         sys.excepthook = self.MyExceptionHandler
	... etc.

     def MyExceptionHandler(self, type, value, trace_back):
         """Catch exceptions, log them to file and show error dialog
         """
         log = file(r'stderrlog.txt', 'a+')
         timestamp = time.asctime(time.localtime(time.time()))
         log.write('**** %s ****\n' % timestamp)
         traceback.print_exception(type, value, trace_back, file=log)
         log.write('\n')
         log.close()

         self.ReportException(2)

self.ReportException is displaying a dialog to the user showing the 
error and allows him/her to e-mail the logs to me.

I package my app also with py2exe and all this works nicely for me.

BTW, in another part of my code I also redirect stdout to a file and I 
also have a sqllog file all of them are shown by my error dialog.

Hope this helps
Werner

Lawrence Bruhmuller wrote:
> Hi,
> 
> We've been using Py2Exe for a while.  Some time back I looked in 
> boot_common.py, and found the spot where stderr was being redirected, 
> and changed the log file name to suit my purposes.
> 
> Recently our product has taken on the bad habit of hopping around, 
> workig directory-wise, during it's lifetime.  So I really want to modify 
> boot_common so that it puts this logfile where we put our other log 
> files (under the user's documents dir).  This will also solve the 
> problem of not getting the error log when the running user doesn't have 
> write permission to the installation directory (which is the starting 
> working directory, the way we have things installed right now).
> 
> I have Python code (imports win32com.shell) that our product uses to 
> find this dir, but it seems that since this is bootstrap code, I can't 
> really just insert any Python code into boot_common and expect it to 
> work.  I just get the program exiting immediately after starting, with 
> no log, probably since this code is before the err log is set up!
> 
> How should I solve this problem?
> Thanks much,
> 
> Lawrence
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Thanks for the reply, comments inline ...

Thomas Heller wrote:

>
>If you have a GUI application you should provide *some* way to display
>errors. The code in boot_common is only the last ressort imo.
>  
>
We have message panes, and error dialog, and a logging framework for 
most stuff.  But this is mostly to find tracebacks when we have a bug in 
our code, and we either need to find it ourselves, or more likely when a 
user (using the frozen version) needs to tell us what went wrong.  Hence 
the desire to always grab this stuff ...

>You could create both a GUI and a console app (the samples directories
>show how this can be done) and run the console app instead.  This should
>let you find and fix the problem!
>  
>
Thanks, I'll try this now.  But any tips straightaway as to what I'll 
likely be able to do (specifically, what I can import) in boot_common, 
and what I can't?

>(Sometimes I think the default behaviour should be to alloc a new
>console and dump stderr output into this, when an unexpected exception
>occurrs.)
>  
>
That would be cool, since this is hopefully only a rare case due to 
developer error, not user error.  Don't suppose you have the snippet of 
code that would do this ... would the console only come up when it got 
something written to it?

Regards,

Lawrence

>Thomas
>
>
>
>
>  
>

Lawrence Bruhmuller <lbruhmuller@...> writes:

> Thomas Heller wrote:
>>
>>If you have a GUI application you should provide *some* way to display
>>errors. The code in boot_common is only the last ressort imo.

Obviously it is not robust enough for you, if it cannot open the file to
write to.

> We have message panes, and error dialog, and a logging framework for
> most stuff.  But this is mostly to find tracebacks when we have a bug
> in our code, and we either need to find it ourselves, or more likely
> when a user (using the frozen version) needs to tell us what went
> wrong.  Hence the desire to always grab this stuff ...
>
>>You could create both a GUI and a console app (the samples directories
>>show how this can be done) and run the console app instead.  This should
>>let you find and fix the problem!
>>
>>
> Thanks, I'll try this now.  But any tips straightaway as to what I'll
> likely be able to do (specifically, what I can import) in boot_common,
> and what I can't?

You should be able to import everything in boot_common that's in
library.zip.  The problem is only: what to do when an error occurs.

>>(Sometimes I think the default behaviour should be to alloc a new
>>console and dump stderr output into this, when an unexpected exception
>>occurrs.)
>>
>>
> That would be cool, since this is hopefully only a rare case due to
> developer error, not user error.  Don't suppose you have the snippet
> of code that would do this ... would the console only come up when it
> got something written to it?

The only snippet that I have is this:


from ctypes import *

class writer(object):
    def __init__(self, handle):
        self.handle = handle

    def write(self, text):
        bytes_written = c_ulong()
        if isinstance(text, unicode):
            windll.kernel32.WriteConsoleW(self.handle,
                                          text,
                                          len(text),
                                          byref(bytes_written),
                                          None)
        else:
            windll.kernel32.WriteConsoleA(self.handle,
                                          text,
                                          len(text),
                                          byref(bytes_written),
                                          None)

windll.kernel32.AllocConsole()
windll.kernel32.SetConsoleTitleA(str(title))
sys.stderr = writer(windll.kernel32.GetStdHandle(-12))

You should be able to call AllocConsole the first time the write method
is called.  A remaining problem might be that the console window will
disappear automatically when the process ends - so the user may or may
not be able to read the text in it.

Thomas

I got all this working, btw.  As you suspected, the issue was just my 
buggy code in boot_common.py that I couldn't diagnose.  I started in 
console mode, jumped into pdb, and I found it right away.

Playing with your code snippet now ...

Anyway, thanks for the help.

- Lawrence

>  
>