|
|
|
2003-03-14 |
Look out for mongoose! |
Phil also reported on a package his company plans to release next week, called "mongoose".
The role of Mongoose is to provide a framework for to cleanly catch and report otherwise uncaught exceptions in distributed python applications.
Mongoose will provide a much less intimidating error message than a stack trace (or, under wxPython, an app that suddenly vanishes). Bundled reporting styles include summary and detailed log files, email, and wxPython alerts. They looked very clean in the demo.
Perhaps the most interesting part of the package is that Mongoose creates an ID for each exception, similar to the Talkback ID from Mozilla builds. This ID is a short (5 digit?) hash of the method signatures in the stack trace. This means the ID should be unique to the call stack at time of exception. (By not using file or line numbers in the hash, the IDs should remain constant across product versions.)
The short ID can be easily communicated over the phone to tech support, or be used as a lookup key for user self support. (After the problem is found and a work around created the first time...)
While, in an ideal world, there would be no uncaught exceptions, Mongoose promises to ease support issues for early releases and products which rely on 3rd party libraries.
|
posted at 10:24:00
#
comment []
|
|
PyChecker usage |
Phil Lindsay gave a good talk about PyChecker at this month's Bay Piggies meeting.
From his work on a large project, he offered some tips on usage:
- keep PyChecker rules in a separate file, also under source control. Don't clutter the source with PyChecker directives.
- To keep track of "temporary" messages that are okay, don't create an exception for it. Rather, check in the output of PyChecker alongside the source, and diff against the prior PyChecker output. That way, any changes to the temporary issues will show up.
Phil reports that most Python projects now use PyChecker. It has become more difficult for the PyChecker team to find "un checked" code to use for testing. That's a good thing...
|
posted at 10:13:20
#
comment []
|
|
|
|
|
|
|
2003-03-08 |
|
Kendall Grant Clark has an interesting piece on whether or not "social meaning" should be explicitly a part of RDF semantics.
Deep stuff, but having recently Googled myself and found one of the primary references to be a saterical piece I forwarded (with attribution) to a list that was archived, I can see the desire to express a social context to information....
|
posted at 08:37:20
#
comment []
|
|
|
2003-03-07 |
|
I've written up a quick and dirty guide to installing PyDS on Win32 platforms. |
posted at 20:19:12
#
comment []
|
|
|
|
|
2003-03-03 |
|
Extracted from the comments to the 0.4.14 announcement (which can't be linked directly):
- Hal asked:
-
Re the cloud -- actually, what I'm missing are the items that go with a first time push (I assume) - the gifs for the XML and email icons, etc.
Should there be some sort of "site refresh" function, since all the file exist on my local desktop?
Or a "site pull" if i wanted to start using PyDS from a different box?
Are these just new tools I can write and dump into the right column?
geschrieben von Hal Wine um 03:13:44 am 03.03.2003
- Georg answers:
To upstream stuff that should have gone in the first time, just touch those files (make there date current). Then upstreaming will push them up next time.
Pull isn't there, and since XMLStorageSystem doesn't have a directory reading functionality, wouldn't be possible to implement. There was one, once, but it's obsoleted.
To start PyDS from a different box, just backup your local copy, upstream the backup and do a restore from the other machine. To backup currently you only can use the timer in the preferences (add a backup timer to the list) and enable the backup upstreaming in your preferences.
To restore use the pyds-restore script.
|
Source:
Python Desktop Server Weblog (Kommentare zu Beitrag P56)
|
posted at 12:20:16
#
comment []
|
|
|
2003-03-01 |
Ahh, slash fixed.... |
So, the fix to the slashes was a trivial
files = map( lambda x: re.sub( r'\\', '/', x ), files )
as the first line to UpstreamTool.upstreamMultipleFiles
In an ideal world, that probably should be protected to only be done when the local system's directory separator is not slash. I think that would be done as:
dirSep = os.path.join( 'a', 'b' )[1:-1]
if dirSep != '/':
files = map( lambda x: re.sub( dirSep, '/', x ), files )
|
posted at 18:10:08
#
comment []
|
|
Oops! Buggy patch |
OOPS!!! my patch seemed to work, but it caused the event log to become corrupted. Reverting to Georg's patches, and removing the patch file below. |
posted at 16:20:16
#
comment []
|
|
|
Georg's patch worked fine. I crafted a slightly different one, which allows the log files to be written, by patching Daemonize.py (and tweaking install_handlers in Server.py)
My patch -- tested only on Windows 98 -- may be found at http://dtor.com/PyDS/Bug_01_fix.tgz |
Source:
Python Desktop Server Weblog
|
posted at 15:48:16
#
comment []
|
|
Bug on Windows 98 |
Ran into a bug -- not sure exactly what's up.
Apparently, the working directory is off when saveMultipleFiles is executed, as none of the local files can be found (see below for event log messages).
Georg found and fixed the bug! Awesome
Old bug details are at dtor.com/PyDS/Bug_01.html |
posted at 10:33:36
#
comment []
|
|
|
March |
---|
Mo | Tu | We | Th | Fr | Sa | Su |
---|
| | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | Feb | | Apr |
---|
Just a test of PyDS
|