From: Chuck E. <ec...@mi...> - 2000-11-06 21:54:10
|
Just a minor one. * The rows of a data table (which feel like dictionaries or tuples depending on how you use them) now respond to has_key(). * Moved Configurable from WebKit to MiscUtils, since it's not a web specific class and it can find use in other projects. I'm still incubating the new MiddleKit component in a private project of mine. That will be uploaded to CVS sometime this month. I believe Geoff will be uploading COMKit sometime as well. -Chuck |
From: Chuck E. <ec...@mi...> - 2000-12-04 23:36:35
|
MiscUtils.DataTable - Added asList() and asDict() to TableRecord. - Fixed bug where CSV files couldn't have quotation marks around heading names. - Record-like objects added to a table must respond to hasValueForKey() and valueForKey() rather than hasValueForField() and valueForField(). Note that the "key" methods are implemented as a mix-in in NamedValueAccess (although you can certainly write your own). - Improved the docs. - Improved test suite with more assertions. Less visual checking is required. WebKit.Examples.ExamplePage: Got rid of .py extension in the links to various examples. WebKit uses extensionless-URLs. Moved WebKit.Adapter.WordWrap() to MiscUtils.Funcs.CharWrap(). Added WebKit.__init__.py -Chuck |
From: Tom S. <tom...@li...> - 2000-12-05 13:40:22
|
I just dicovered the following in DBPool.py * Contributed by Tom Schwaller. * Fixes by Geoff Talvola (thread safety in _threadsafe_getConnection()). * Clean up by Chuck Esterbrook. I should be * Contributed by Dan Green * thread safety bug found by Tom Schwaller * Fixes by Geoff Talvola (thread safety in _threadsafe_getConnection()). * Clean up by Chuck Esterbrook. or something in that direction :-) -- Tom Schwaller http://www.linux-community.de http://www.linux-magazin.de/ |
From: Chuck E. <ec...@mi...> - 2000-12-05 16:22:01
|
Fixed. I figured the credits were off, but that someone would catch it and report it. -Chuck At 02:39 PM 12/5/2000 +0000, Tom Schwaller wrote: >I just dicovered the following in DBPool.py > >* Contributed by Tom Schwaller. >* Fixes by Geoff Talvola (thread safety in _threadsafe_getConnection()). >* Clean up by Chuck Esterbrook. > >I should be > >* Contributed by Dan Green >* thread safety bug found by Tom Schwaller >* Fixes by Geoff Talvola (thread safety in _threadsafe_getConnection()). >* Clean up by Chuck Esterbrook. > >or something in that direction :-) > >-- > >Tom Schwaller >http://www.linux-community.de >http://www.linux-magazin.de/ |
From: Chuck E. <ec...@mi...> - 2001-02-03 04:36:25
|
I actually made these updates several days ago, but forgot to send out word: * Plug-ins (which are Python packages) now have a 'plugIn' variable set to point to the PlugIn object created in WebKit. I'm not even sure what this could be used for yet, but it makes sense to have this pointer as hook that can be used as needed. * I forgot to mention that when I implemented the Properties.py enhancement I did NOT implement the requiredSoftware feature. * PythonServletFactory was advertising extensions of ['', '.py'] which I changed to ['.py']. * Removed WebKit/Configs/*.default. These out-of-the-box backups of the config files are now created by running install.py (if they don't already exist). WebKit developers no longer have to maintain the *.default files. * Added MiscUtils.Funcs.timestamp(). See the docstring. |
From: Jay L. <js...@js...> - 2001-02-17 23:26:36
|
I fixed the file AppServer, which is bash script to start the server, so that it actually works. Jay |
From: Jay L. <js...@js...> - 2001-02-24 02:46:48
|
I've checked in my shutdown changes. Basically, the new recommended way to Shut down a running app server is through the new AppControl Servlet. This will permit any requests currently being processed to complete and generally provide for an orderly shutdown, with all sessions saved, etc. The rest is under the hood. Jay |
From: Chuck E. <ec...@mi...> - 2001-02-24 03:11:39
|
I fixed it. Shut down needs to check isPersistent(): if self._server.isPersistent(): self._taskmanager.stop() |
From: Chuck E. <ec...@mi...> - 2001-02-24 03:23:43
|
In MiscUtils.Funcs, I renamed Commas() to commas() CharWrap() to charWrap() The capitalized versions are actually still there, but print a deprecation msg to std out. I'll be doing something similar to WebUtils.WebFuncs. WebKit.Adapter now takes an argument in it's constructor: the path of WebKit. This is needed so that config files can be read (They are in WebKit/Configs/). We were already doing this for OneShotAdapter.py and CGIAdapter.py, but not in the constructor. -Chuck |
From: Jay L. <js...@js...> - 2001-02-24 07:28:32
|
For UNIX, both Threaded and Async AppServers have been updated to accept "daemon" as a comand line argument. This will run the process as a daemon so it doesn't take over a terminal or quit when you exit the terminal. These AppServers also accept "stop" as a command line argument to shut down a running appserver. All the AppServers should be run through the "Launch.py" script though. That script will pass these parameters through to the AppServers. The wkMonitor.py script is also available for starting/running the AppServers in the background and fault tolerance, but it's a bit broken at the moment. It'll be fixed shortly, and renamed Monitor.py. Jay |
From: Tom S. <tom...@li...> - 2001-02-24 19:58:54
|
Jay Love wrote: > > For UNIX, both Threaded and Async AppServers have been updated to accept > "daemon" as a comand line argument. This will run the process as a > daemon so it doesn't take over a terminal or quit when you exit the > terminal. > > These AppServers also accept "stop" as a command line argument to shut > down a running appserver. > > All the AppServers should be run through the "Launch.py" script though. > That script will pass these parameters through to the AppServers. > > The wkMonitor.py script is also available for starting/running the > AppServers in the background and fault tolerance, but it's a bit broken > at the moment. It'll be fixed shortly, and renamed Monitor.py. is there a reason for using "AsyncThreadedAppServer" in AppServer and "ThreadedAppServer" in wkMonitor.py as default values? -- Tom Schwaller http://www.linux-community.de |
From: Jay L. <js...@js...> - 2001-02-24 07:40:15
|
(This one is from a few days ago, I just forgot to mention it) I added a function to Session named sessionEncode that takes a url/i and adds the session id as a parameter. So those people who want to support clients that don't accept cookies can use this method to gain session support, whether cookies are enabled or not. You'll need to wrap every link in your code with this call. I also added a wrapper for this function to Page, same name and parameter. So from a Page Servlet, you'd call self.write("<a html' ") self.write(self.sessionEncode("http://myhost/somepage")) self.write(" '>") or some abbreviation thereof. Jay |
From: Chuck E. <ec...@mi...> - 2001-02-25 17:35:32
|
The admin password has been changed from Admin/Webware to admin/webware. Bugfix: Browsing the WebKit docs via WebKit causes problems because of a relative link that was outside the context. Known bugs that are NOT fixed: [1] Exiting the app server with Control-C now gives me an exception. I never saw this before last week. [2] While poking at PSP via OneShot.cgi, I got this exception logged to Apache's error.log: Traceback (most recent call last): File "/All/echuck/Projects/Webware\WebKit\AppServer.py", line 151, in loadPlugIn plugIn.install() File "WebKit\PlugIn.py", line 76, in install File "/All/echuck/Projects/Webware\PSP\__init__.py", line 10, in InstallInWebKit app.addServletFactory(PSPServletFactory(app)) File "C:\All\echuck\Projects\Webware\PSP\PSPServletFactory.py", line 55, in __init__ self.clearFileCache() File "C:\All\echuck\Projects\Webware\PSP\PSPServletFactory.py", line 76, in clearFileCache map(os.remove, files) OSError: [Errno 13] Permission denied: 'C:\\All\\echuck\\Projects\\Webware\\WebKit\\Cache\\PSP\\_All_echuck_Projects_Webware_PSP_Examples_PSPTests_psp.py' I haven't recreated yet. |
From: Chuck E. <ec...@mi...> - 2001-03-23 03:32:58
|
Two bug fixes and some minor stuff. All WebKit: cvs mainline & 0.5.1 branch: Bugfix: AsyncHTTPThreadedAppServer: Change environ var REMOTE_HOST to REMOTE_ADDR. This makes more sense, since the value is an IP address and not a name. It also matches Apache. It also enables HTTPRequest.remoteAddr() which worked for all the other app server deployment methods. Bugfix: HTTPResponse: sendRedirect() didn't set the Status: header which cause problems with non-CGI adapters. cvs mainline: WebKit: Tweaks: I upped the version numbers of Webware and WebKit from 0.5.1 to 1.0-pre, and copyright to 2001. Launch.py: I always put a ".py" extension on the server name which Launch didn't like. Now Launch strips off the .py if it's there. Cookie.py: If you have Py 2.0 or greater, this class will now use Python's included Cookie module. Otherwise, it uses "zCookieEngine.py" that we have always been in the past (and is an earlier revision of what got included in the Python distribution). |
From: Geoff T. <gta...@me...> - 2001-06-19 14:03:54
|
I fixed ThreadedAppServer.py and OneShotAdapter.py so that binary file uploads work properly on Windows. I've tested with WebKit.cgi and OneShot.cgi; I'll try it out with mod_webkit later today. - Geoff |
From: Geoff T. <gta...@na...> - 2001-06-22 18:04:20
|
I added two new settings to Application.config. From the Users Guide: IncludeFancyTraceback = 0 If true, then use the cgitb.py module to display a fancy, detailed traceback at the end of the error page. To use this option, you'll need to first install the cgitb.py module, downloadable from http://web.lfw.org/python/ , and if you are not using Python 2.1, you will also need to install inspect.py and pydoc.py, also available from the same site. FancyTracebackContext = 5 The number of lines of source code context to show if IncludeFancyTraceback is turned on. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Mike O. <ir...@ms...> - 2001-06-22 18:09:26
|
On Fri, Jun 22, 2001 at 02:04:42PM -0400, Geoff Talvola wrote: > IncludeFancyTraceback = 0 If true, then use the cgitb.py module to display > a fancy, detailed traceback at the end of the error page. Hooray!!! :) :) :) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Ian B. <ia...@co...> - 2001-06-22 18:18:45
|
Did you see the patch I submitted on sourceforge for this? It included a modified version of cgitb with several small (but I think important) enhancements. Geoff Talvola <gta...@na...> wrote: > I added two new settings to Application.config. From the Users Guide: > > IncludeFancyTraceback = 0 If true, then use the cgitb.py module to display > a fancy, detailed traceback at the end of the error page. To use this > option, you'll need to first install the cgitb.py module, downloadable from > http://web.lfw.org/python/ , and if you are not using Python 2.1, you will > also need to install inspect.py and pydoc.py, also available from the same > site. > > FancyTracebackContext = 5 The number of lines of source code context to > show if IncludeFancyTraceback is turned on. > > > -- > > - Geoff Talvola > gtalvola@NameConnector.com > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > http://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Geoff T. <gta...@na...> - 2001-06-22 18:24:50
|
At 01:18 PM 6/22/01 -0500, Ian Bicking wrote: >Did you see the patch I submitted on sourceforge for this? It >included a modified version of cgitb with several small (but I think >important) enhancements. No, I didn't know about the patch. I'll take a look right now. >Geoff Talvola <gta...@na...> wrote: > > I added two new settings to Application.config. From the Users Guide: > > > > IncludeFancyTraceback = 0 If true, then use the cgitb.py module to display > > a fancy, detailed traceback at the end of the error page. To use this > > option, you'll need to first install the cgitb.py module, downloadable > from > > http://web.lfw.org/python/ , and if you are not using Python 2.1, you will > > also need to install inspect.py and pydoc.py, also available from the same > > site. > > > > FancyTracebackContext = 5 The number of lines of source code context to > > show if IncludeFancyTraceback is turned on. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-06-22 19:50:56
|
Geoff Talvola <gta...@na...> wrote: > I downloaded the patch. I couldn't get your modified version of cgitb.py > to work. It worked running it from the command line as a self-test, but it > failed when I tried to use it within Webware. I made the patch about nearly two months ago at Chuck's request. I probably should have noted that to the list. Anyway, I don't know if Webware has changed since then so that the patch isn't really valid anymore. The important parts are the modified cgitb and WebUtils/ExpansiveHTMLForException.py, which has the same interface as HTMLForException. Everything else is configuration stuff, to which I am indifferent. Oh, I think I made two small changes to inspect: inspect.trace, so it could take the exec_info as an argument, and inspect.getsourcefile, to look for files throughout sys.path, instead of just the cwd. Probably both these should go upstream. > Generally, I think we're better off not including modified versions of > 3rd-party modules in Webware, especially when the unmodified version works > adequately. Instead, I'd recommend trying to get the author of cgitb to > incorporate your improvements. Some of the changes probably aren't appropriate for cgitb, though I should probably send some of the others back to the author. If I really was going to take it seriously, I'd probably rewrite cgitb, as most of the difficult stuff is in inspect.py anyway, and the HTML-generation stuff from pydoc doesn't really appeal to me. I strongly think you shouldn't point someone to downloading the file elsewhere -- if you want to keep 3rd-party modules pristine, okay, but they should be made available through the Webware distribution anyway. > I also prefer the approach I took of adding the "fancy traceback" to the > end of the error page instead of replacing the standard traceback. This is > because the amount of information in the fancy traceback can be > overwhelming, and most of the time I'd rather just see the standard traceback. I had that problem too, which is why I made changes to the fancy traceback that I think make it much easier to follow. IMHO, my version is easier to follow than the normal traceback, though perhaps other changes could be made. Admittedly, most of the time I just look at the filename/line numbers and go the line in question, so both are equivalent in that respect. I also made some changes to get rid of some redundant information, and to work better with Webware's OO style, where cgitb is more oriented toward a function-based style. Ian |
From: Geoff T. <gta...@na...> - 2001-06-22 20:13:25
|
At 02:51 PM 6/22/01 -0500, Ian Bicking wrote: >Geoff Talvola <gta...@na...> wrote: > > I downloaded the patch. I couldn't get your modified version of cgitb.py > > to work. It worked running it from the command line as a self-test, > but it > > failed when I tried to use it within Webware. > >I made the patch about nearly two months ago at Chuck's request. I >probably should have noted that to the list. > >Anyway, I don't know if Webware has changed since then so that the >patch isn't really valid anymore. The important parts are the >modified cgitb and WebUtils/ExpansiveHTMLForException.py, which has >the same interface as HTMLForException. Everything else is >configuration stuff, to which I am indifferent. > >Oh, I think I made two small changes to inspect: inspect.trace, so it >could take the exec_info as an argument, and inspect.getsourcefile, to >look for files throughout sys.path, instead of just the cwd. Probably >both these should go upstream. But neither of these changes seem necessary. In my testing it is able to pick up the source for modules anywhere, and it's not necessary to pass in exec_info since you can just get it from sys. > > Generally, I think we're better off not including modified versions of > > 3rd-party modules in Webware, especially when the unmodified version works > > adequately. Instead, I'd recommend trying to get the author of cgitb to > > incorporate your improvements. > >Some of the changes probably aren't appropriate for cgitb, though I >should probably send some of the others back to the author. If I >really was going to take it seriously, I'd probably rewrite cgitb, as >most of the difficult stuff is in inspect.py anyway, and the >HTML-generation stuff from pydoc doesn't really appeal to me. > >I strongly think you shouldn't point someone to downloading the file >elsewhere -- if you want to keep 3rd-party modules pristine, okay, but >they should be made available through the Webware distribution anyway. I tend to disagree, but since Chuck is BDFL of Webware I will defer to his opinion. Also in this case inspect.py and pydoc.py are part of Python 2.1's standard library, so we could just declare that use this feature you either need to upgrade to Python 2.1 or download the modules separately. > > I also prefer the approach I took of adding the "fancy traceback" to the > > end of the error page instead of replacing the standard > traceback. This is > > because the amount of information in the fancy traceback can be > > overwhelming, and most of the time I'd rather just see the standard > traceback. > >I had that problem too, which is why I made changes to the fancy >traceback that I think make it much easier to follow. IMHO, my >version is easier to follow than the normal traceback, though perhaps >other changes could be made. Admittedly, most of the time I just look >at the filename/line numbers and go the line in question, so both are >equivalent in that respect. > >I also made some changes to get rid of some redundant information, and >to work better with Webware's OO style, where cgitb is more oriented >toward a function-based style. Well, those definitely do sound like worthwhile changes. I'd still tend toward trying to get them incorporated into the standard cgitb.py rather than forking off our own changes, but again, whatever Chuck wants to do is fine. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Ian B. <ia...@co...> - 2001-06-22 20:38:01
|
Geoff Talvola <gta...@na...> wrote: > >Oh, I think I made two small changes to inspect: inspect.trace, so it > >could take the exec_info as an argument, and inspect.getsourcefile, to > >look for files throughout sys.path, instead of just the cwd. Probably > >both these should go upstream. > > But neither of these changes seem necessary. In my testing it is able to > pick up the source for modules anywhere, and it's not necessary to pass in > exec_info since you can just get it from sys. exec_info seemed to get lost somewhere along the way in my testing -- it just doesn't seem like a good design to do it otherwise -- I don't know about the thread-safety of using sys.exec_traceback. OTOH, you can just use inspect.getinnerframes instead. Searching the path seemed entirely necessary to me -- I couldn't get anything to work right without it. Are you sure it's really working like it is? Maybe it's working better since sys.path has been cleaned up some, or if Python is using absolute paths for the __file__ attribute. > Well, those definitely do sound like worthwhile changes. I'd still tend > toward trying to get them incorporated into the standard cgitb.py rather > than forking off our own changes, but again, whatever Chuck wants to do is > fine. Some stuff can go into cgitb, but an important part of the changes is to increase compactness, and in small part to make colors configurable -- analogous to current error messages (though I don't think this really matters much, since error messages aren't public). These are changes that really make cgitb less general, which is what makes it more useful but less likely to go upstream. But I haven't talked to the author, so I dunno. Ian |
From: Geoff T. <gta...@na...> - 2001-06-22 21:20:11
|
At 03:38 PM 6/22/01 -0500, you wrote: >Geoff Talvola <gta...@na...> wrote: > > >Oh, I think I made two small changes to inspect: inspect.trace, so it > > >could take the exec_info as an argument, and inspect.getsourcefile, to > > >look for files throughout sys.path, instead of just the cwd. Probably > > >both these should go upstream. > > > > But neither of these changes seem necessary. In my testing it is able to > > pick up the source for modules anywhere, and it's not necessary to pass in > > exec_info since you can just get it from sys. > >exec_info seemed to get lost somewhere along the way in my testing -- >it just doesn't seem like a good design to do it otherwise -- I don't >know about the thread-safety of using sys.exec_traceback. OTOH, you >can just use inspect.getinnerframes instead. BTW the prefix is "exc_XXX", not "exec_XXX". Your patch contains this typo. You're right, cgitb.py and inspect.py are not thread-safe. But they can be made thread-safe without having to pass around exc_info. According to the Python docs, sys.exc_type, sys.exc_value, and sys.exc_traceback are deprecated because they are not thread-safe. The right way to do it is to call sys.exc_info() which returns the tuple of those three values, but in a thread-safe manner. Unfortunately, both cgitb.py and inspect.py ignore this advice and use the non-thread-safe method. OK, I think you've convinced me that we should include our own version of these modules -- clearly they need some work to behave properly with Webware. >Searching the path seemed entirely necessary to me -- I couldn't get >anything to work right without it. Are you sure it's really working >like it is? Maybe it's working better since sys.path has been cleaned >up some, or if Python is using absolute paths for the __file__ >attribute. Hmmm. It works fine for me using a persistent app server, but I just noticed that cgitb fails when I run it using OneShot.cgi. I'll try adding in your sys.path fix and see if it fixes it under OneShot. > > Well, those definitely do sound like worthwhile changes. I'd still tend > > toward trying to get them incorporated into the standard cgitb.py rather > > than forking off our own changes, but again, whatever Chuck wants to do is > > fine. > >Some stuff can go into cgitb, but an important part of the changes is >to increase compactness, and in small part to make colors configurable >-- analogous to current error messages (though I don't think this >really matters much, since error messages aren't public). > >These are changes that really make cgitb less general, which is what >makes it more useful but less likely to go upstream. But I haven't >talked to the author, so I dunno. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Chuck E. <Chu...@ya...> - 2001-06-23 00:38:57
|
At 03:38 PM 6/22/2001 -0500, Ian Bicking wrote: >These are changes that really make cgitb less general, which is what >makes it more useful but less likely to go upstream. But I haven't >talked to the author, so I dunno. I'm guessing cgitb isn't a class, so you can't just subclass it and override key methods. (sigh) -Chuck |
From: Chuck E. <Chu...@ya...> - 2001-06-22 21:23:47
|
At 04:13 PM 6/22/2001 -0400, Geoff Talvola wrote: >>I strongly think you shouldn't point someone to downloading the file >>elsewhere -- if you want to keep 3rd-party modules pristine, okay, but >>they should be made available through the Webware distribution anyway. > >I tend to disagree, but since Chuck is BDFL of Webware I will defer to his >opinion. Also in this case inspect.py and pydoc.py are part of Python >2.1's standard library, so we could just declare that use this feature you >either need to upgrade to Python 2.1 or download the modules separately. Thoughts from your local BDFL: - I have no problem including 3rd party modules. - I agree w/ Geoff we should try to push mods upstream, even if that is more difficult. - 3rd party modules that exist in Py 2.x present an interesting situation. I won't declare a policy at this point that these should or not be included. We can do it on a case by case basis. In this case, Geoff and Ian both chose to include the modules in Webware and that's fine. We might consider trying to get them from Python first: try: import pydoc except ImportError: from MiscUtils import pydoc - I assume that such generic modules like pydoc and cgitlib would go in places like MiscUtils and WebUtils rather than WebKit. -Chuck |