Re: Logging insights for Gump3 please
On 26-04-2005 02:10, Adam R. B. Jack [EMAIL PROTECTED] wrote: Change config.py; configure the logging package by hand (I think that's called basicConfig()) instead of using a config file, and make it output everything to the screen. We can fix it later, and there's no test to look for the existence of log files so you're not breaking anything ;) Ok, got it. This LogReporter isn't a reporter to a log it is a reporter of logs. Since my workspace/environment had no Ant script to run (and had done no CVS|SVN updates to get one), I had no properties ending with _log, and (apparently) no exceptions. As such, no reporter output data. D'oh! Only now do I get what you were on about. Sorry 'bout that. I'd half like to see a properties diff tool that runs in between plugins, to see what is changed each time a plugin runs. I could imaging plugins taking credit (say) for a property be updating a table. This is likely overkill for now though, and a dump (at the end) ought teach me what I need to know. This sounds like something to take care of within a Walker. You could perhaps write a custom Walker implementation (subclassing the original one) that pickles the entire model a whole lot and then keeps comparing the pickled stuff. It'd be sluggish as hell, but it probably isn't a whole lot of code :-) The other thing that pops into mind is overriding __setattr__ inside ModelObject to log all calls. Then there's the trace module (if its called that way) which is built precisely for this kind of stuff. Doing things properly probably involves that module. OTOH, debug statements have also worked reasonably for ages. Simplest thing, simplest thing ;) - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
OTOH, debug statements have also worked reasonably for ages. Simplest thing, simplest thing ;) Yup, I'm there for now, however I was thinking about communication between two separate developers of plugins, perhaps the latter not being able to hack debug statements into the former. Still, right now that isn't the case. Still, if plugin developers can log (perhaps at end of the piece of code) the main attributes they publish, that'd be helpful. Perhaps we somehow need to have plugins document themselves (just like you have the list of attributes on the model.) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
On 25-04-2005 00:24, Adam R. B. Jack [EMAIL PROTECTED] wrote: I'm still finding it hard to make progress, 'cos I can't see log output. This (captured below) is all I see, and either there is a problem with logging on (Cygwin) or the Mutliplexer isn't dispatching, or something. Do we need to ask for non-buffered log files, or do some flushing prior to exit, or Any thoughts? Simplest thing that could possibly work: Change config.py; configure the logging package by hand (I think that's called basicConfig()) instead of using a config file, and make it output everything to the screen. We can fix it later, and there's no test to look for the existence of log files so you're not breaking anything ;) Cheers, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
Change config.py; configure the logging package by hand (I think that's called basicConfig()) instead of using a config file, and make it output everything to the screen. We can fix it later, and there's no test to look for the existence of log files so you're not breaking anything ;) Ok, got it. This LogReporter isn't a reporter to a log it is a reporter of logs. Since my workspace/environment had no Ant script to run (and had done no CVS|SVN updates to get one), I had no properties ending with _log, and (apparently) no exceptions. As such, no reporter output data. After (1) editing the gump.log.config and checking out oddities like args(stdout,) -- yup, odd but right (2) adding [logger_plugin_error-handler] -- nope, no new errors reported. (3) shutting down logging gracefully -- nope, nothing new (4) stopping the config level overriding the log file [I can restore this, but things are getting too verbose for me, given what I've added] (5) dotting lots of log messages -- yup, walking as intended ... I finally figured it out. The clue (staring us in the face) was that the same log was used for writing the initialisation message as the contents. I saw this message, so I ought have seen anything else. The main reason I was expecting more content was I was writing a pretty printer plug-in, when log reporter first came along, to see what attributes the various plugins left on the model. Since we are using the model as a message board that seems a key tool for newbies like me to get insights into the 'protocol' between plugins. I'll get back to writing it, now I know that LogReporter isn't that beastie. I'd half like to see a properties diff tool that runs in between plugins, to see what is changed each time a plugin runs. I could imaging plugins taking credit (say) for a property be updating a table. This is likely overkill for now though, and a dump (at the end) ought teach me what I need to know. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
I'm still finding it hard to make progress, 'cos I can't see log output. This (captured below) is all I see, and either there is a problem with logging on (Cygwin) or the Mutliplexer isn't dispatching, or something. Do we need to ask for non-buffered log files, or do some flushing prior to exit, or Any thoughts? regards Adam --- DEBUG: logdir is f:\data\Python\Gump3-SVN\pygump\work\log DEBUG: Pygump version 3.0-alpha-3 starting... DEBUG: (the detailed log is written to f:\data\Python\Gump3-SVN\pygump\work\log\gump_log_20050424_161931.txt) DEBUG: - hostname : tsws1 DEBUG: - homedir: f:\data\Python\Gump3-SVN DEBUG: - current time : 24 Apr 2005 16:19:31 DEBUG: - current time (UTC) : 24 Apr 2005 22:19:31 DEBUG: - python version : 2.4 (#60, Feb 9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)] DEBUG: - python command : /cygdrive/c/Python24/python DEBUG: - environment variables: DEBUG: TMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: DEPOT_UPDATE_HOME=F:\data\OSS\depot-update DEBUG: COMPUTERNAME=TSWS1 DEBUG: USER=ajack DEBUG: USERDOMAIN=TSWS1 DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files DEBUG: PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel DEBUG: CVS_RSH=/bin/ssh DEBUG: PROGRAMFILES=C:\Program Files DEBUG: PROCESSOR_REVISION=0803 DEBUG: HOME=c:\ DEBUG: SYSTEMROOT=C:\WINNT DEBUG: CATALINA_HOME=F:\apps\Apache\jakarta-tomcat-5.0.19 DEBUG: MA_AGENT=c:\PROGRA~1\sybase\MANAGE~1\rstate.exe DEBUG: INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info :/usr/autotool/stable/info: DEBUG: GUMP_HOME=f:\data\Python\Gump3-SVN DEBUG: PRINTER=HP OfficeJet DEBUG: TEMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: SHLVL=2 DEBUG: PROCESSOR_ARCHITECTURE=x86 DEBUG: J2EE_HOME=F:\apps\j2sdkee1.3.1 DEBUG: APR_ICONV_PATH=F:\apps\Subversion\iconv DEBUG: ALLUSERSPROFILE=C:\Documents and Settings\All Users DEBUG: ROOTDIR=F:/apps/mks DEBUG: BPE_HOME=F:\apps\Sybase\bpee DEBUG: _=/cygdrive/c/Python24/python DEBUG: MANPATH=/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man: DEBUG: HOMEPATH=\Documents and Settings\ajack DEBUG: GUMP_HOSTNAME=tsws1 DEBUG: GUMP_WORKDIR=f:\data\Python\Gump3-SVN\pygump\work DEBUG: JAVA_HOME=c:\j2sdk1.4.2_08 DEBUG: USERNAME=ajack DEBUG: LOGONSERVER=\\TSWS1 DEBUG: PROMPT=$P$G DEBUG: COMSPEC=C:\WINNT\system32\cmd.exe DEBUG: MAKE_MODE=unix DEBUG: PYTHONPATH=f:\data\Python\Gump3-SVN\pygump\python;f:\data\Python\Gump3-SVN\ pygump DEBUG: XINDICE_HOME=F:\data\OSS\xml-xindice DEBUG: TERM=cygwin DEBUG: PATH=C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R 6\bin;c:\Python24\;f:\apps\Sybase\Shared\ASA802\win32;c:\Python23\;c:\Python 23\Scripts;f:\apps\javasoft\j2sdk1.4.2\bin;f:\Perl\bin\;f:\apps\mks\mksnt;c: \WINNT\system32;c:\WINNT;c:\WINNT\System32\Wbem;f:\apps\Subversion\bin;f:\ap ps\Sybase\SQL Anywhere 9\drivers;f:\apps\Sybase\Shared\Sybase Central 4.3\win32;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;c:\Program Files\Common Files\Adaptec Shared\System;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;f:\apps\mysql\bin DEBUG: SHELL=F:/apps/mks/mksnt/sh.exe DEBUG: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw ;.pys DEBUG: TMPDIR=c:\WINNT\TEMP DEBUG: WINDIR=C:\WINNT DEBUG: SVN_EDITOR=vi DEBUG: JAGUAR=F:\apps\Sybase\EAServer DEBUG: HOMEDRIVE=C: DEBUG: APPDATA=C:\Documents and Settings\ajack\Application Data DEBUG: GUMP_ENV_FILE=/cygdrive/f/data/Python/Gump3-SVN/tsws1-settings.sh DEBUG: OLDPWD=/cygdrive/f/data/Python/Gump3-SVN DEBUG: HOSTNAME=tsws1 DEBUG: NUMBER_OF_PROCESSORS=1 DEBUG: GUMP_CYGWIN=yes DEBUG: PWD=/cygdrive/f/data/Python/Gump3-SVN/pygump DEBUG: GUMP_PYTHON=/cygdrive/c/Python24/python DEBUG: PROCESSOR_LEVEL=6 DEBUG: OS2LIBPATH=C:\WINNT\system32\os2\dll; DEBUG: OS=Windows_NT DEBUG: SYSTEMDRIVE=C: DEBUG: USERPROFILE=C:\Documents and Settings\ajack DEBUG: DEBUG: - command line arguments: DEBUG: ['-c', '--debug'] DEBUG: No projects to build set, defaulting to 'all' _ | __|_ Apache_ ___ | | | | | | . | |_|___|_|_|_| _| |_| ~ v. 3.0-alpha-3 ~ DEBUG - Preprocessor : gump.plugins.instrumentation.TimerPlugin instance at 0x00A82238 DEBUG - Processor: gump.plugins.dirbuilder.RmdirBuilderPlugin instance at 0x00A8CEB8 DEBUG - Processor: gump.plugins.dirbuilder.MkdirBuilderPlugin instance at 0x00A8CEE0 DEBUG - Processor: gump.plugins.builder.ScriptBuilderPlugin instance at 0x00A8CF08 DEBUG - Processor: gump.plugins.builder.AntBuilderAttributePlugin instance at 0x00A922D8 DEBUG - Processor:
Logging insights for Gump3 please
I learn a program's behaviour from watching it's logs. I want to see the Gump3 logs, but am getting a headache trying to figure out how: 1) Why is there a long pause before logs start spewing when one does --debug? Is some file buffered? How can I get spew as you go behaviour so I can 'watch' it? 2) Why do some things (like DEBUG - Outputting all log data (a lot)...) come out to the console, but not the rest of the logging information? [I see that rather than fork another process for the pygump engine run we import and run it. I assume that and SVN run (updating the pygump/.../*.py file) ought not be imported at that point, but I feel like I'm seeing what feels like a log 'bleed' that suggests otherwise.] 3) I'd like to understand logging in parts ... (1) gump (2) main (3) pygump. I suspect that there is a redirect in (1) that I'd like to change to a 'tee', but can't find it. [BTW: I once tried using Python to test if stdout was to a console, or not, but I never seemed to get correct behaviour (on Windows, at least).] BTW: I tried writing a pretty print plug-in, but I believe that is what logreporter is meant to do. unfortunately, for me, the promised lots of data fails to appear. Any clues why? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging insights for Gump3 please
I dunno. Could be. Could you be a little more specific about what you're seeing and when what pauses? On every 'run' invocation the 'gump' shell scripts removes *.pyc then recompiles and re-imports, that's part of the delay. It seems like the program runs, and only once done I see output. Basically I get a long wait, and then a super fast spew of output, and it is done. 2) Why do some things (like DEBUG - Outputting all log data (a lot)...) come out to the console, but not the rest of the logging information? That's configured in the log config, console and file use slightly different formatters. What do you think it should be? I thought this was a line from within plugin, which ought run within the 'proper' logging. I thought what was coming to the screen was the gump bash script output (and the 'proper' to the log file) and I didn't understand why this'd be in there. Perhaps I just have that backwards. [I see that rather than fork another process for the pygump engine run we import and run it. I assume that and SVN run (updating the pygump/.../*.py file) ought not be imported at that point, but I feel like I'm seeing what feels like a log 'bleed' that suggests otherwise.] I don't get the above. What? Gump2 did the main checks, did the SVN update, and then launched Python again (in the hope of ensuring that no *.pyc was cached frmo prior to a *.py SVN update.) I see Gump3 isn't doing that. I was wondering if somehow the two logs were bleeding into each other, via the shared Python runtime. Eh, no. Could you send run.log and gump_log_xxx along with console output? I've got a feeling you're not seeing the same thing I'm seeing... In doing this, I realize that the gap before the Gump banner, combined with the quick spew, combined with the size of my terminal window, meant I was only really noticing what was after the banner. Still it seems to be missing some nice details. Also, I've attach the contents of the work/log directory below the asterisk line. $ bash gump run --debug DEBUG: logdir is f:\data\Python\Gump3-SVN\pygump\work\log DEBUG: Pygump version 3.0-alpha-3 starting... DEBUG: (the detailed log is written to f:\data\Python\Gump3-SVN\pygump\work\lo g\gump_log_20050419_132247.txt) DEBUG: - hostname : tsws1 DEBUG: - homedir: f:\data\Python\Gump3-SVN DEBUG: - current time : 19 Apr 2005 13:22:47 DEBUG: - current time (UTC) : 19 Apr 2005 19:22:47 DEBUG: - python version : 2.4 (#60, Feb 9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)] DEBUG: - python command : /cygdrive/c/Python24/python DEBUG: - environment variables: DEBUG: TMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: DEPOT_UPDATE_HOME=F:\data\OSS\depot-update DEBUG: COMPUTERNAME=TSWS1 DEBUG: USER=ajack DEBUG: USERDOMAIN=TSWS1 DEBUG: COMMONPROGRAMFILES=C:\Program Files\Common Files DEBUG: PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel DEBUG: CVS_RSH=/bin/ssh DEBUG: PROGRAMFILES=C:\Program Files DEBUG: PROCESSOR_REVISION=0803 DEBUG: HOME=c:\ DEBUG: SYSTEMROOT=C:\WINNT DEBUG: CATALINA_HOME=F:\apps\Apache\jakarta-tomcat-5.0.19 DEBUG: MA_AGENT=c:\PROGRA~1\sybase\MANAGE~1\rstate.exe DEBUG: INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/d evel/info:/usr/autotool/stable/info: DEBUG: GUMP_HOME=f:\data\Python\Gump3-SVN DEBUG: PRINTER=HP OfficeJet DEBUG: TEMP=c:\DOCUME~1\ajack\LOCALS~1\Temp DEBUG: SHLVL=2 DEBUG: PROCESSOR_ARCHITECTURE=x86 DEBUG: J2EE_HOME=F:\apps\j2sdkee1.3.1 DEBUG: APR_ICONV_PATH=F:\apps\Subversion\iconv DEBUG: ALLUSERSPROFILE=C:\Documents and Settings\All Users DEBUG: ROOTDIR=F:/apps/mks DEBUG: BPE_HOME=F:\apps\Sybase\bpee DEBUG: _=/cygdrive/c/Python24/python DEBUG: MANPATH=/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel /man: DEBUG: HOMEPATH=\Documents and Settings\ajack DEBUG: GUMP_HOSTNAME=tsws1 DEBUG: GUMP_WORKDIR=f:\data\Python\Gump3-SVN\pygump\work DEBUG: JAVA_HOME=c:\j2sdk1.4.2_08 DEBUG: USERNAME=ajack DEBUG: LOGONSERVER=\\TSWS1 DEBUG: PROMPT=$P$G DEBUG: COMSPEC=C:\WINNT\system32\cmd.exe DEBUG: MAKE_MODE=unix DEBUG: PYTHONPATH=f:\data\Python\Gump3-SVN\pygump\python;f:\data\Python\G ump3-SVN\pygump DEBUG: XINDICE_HOME=F:\data\OSS\xml-xindice DEBUG: TERM=cygwin DEBUG: PATH=C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin \usr\X11R6\bin;c:\Python24\;f:\apps\Sybase\Shared\ASA802\win32;c:\Python23\; c:\P ython23\Scripts;f:\apps\javasoft\j2sdk1.4.2\bin;f:\Perl\bin\;f:\apps\mks\mks nt;c :\WINNT\system32;c:\WINNT;c:\WINNT\System32\Wbem;f:\apps\Subversion\bin;f:\a pps\ Sybase\SQL Anywhere 9\drivers;f:\apps\Sybase\Shared\Sybase Central 4.3\win32;c:\ PROGRA~1\COMMON~1\MGISHA~1\Video;c:\Program Files\Common Files\Adaptec Shared\Sy stem;c:\PROGRA~1\COMMON~1\MGISHA~1\Video;f:\apps\mysql\bin DEBUG:
