You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Thom May <th...@apache.org> on 2003/08/02 11:30:09 UTC
[PATCH] fix compile with Python2.3
Hi folks,
I'm not subscribed so my apologies if this is a duplicate report, but
Python2.3 no longer #defines LONG_LONG, it defines PY_LONG_LONG.
Since requestobject.c uses LONG_LONG, this causes the build to implode.
The following patch fixes the problem.
Cheers,
-Thom
Index: src/include/mod_python.h
===================================================================
RCS file: /home/cvs/httpd-python/src/include/mod_python.h,v
retrieving revision 1.33
diff -u -r1.33 mod_python.h
--- src/include/mod_python.h 1 Aug 2003 01:53:13 -0000 1.33
+++ src/include/mod_python.h 2 Aug 2003 09:25:35 -0000
@@ -138,6 +138,11 @@
#define SILENT 0
#define NOTSILENT 1
+/* python 2.3 no longer defines LONG_LONG, it defines PY_LONG_LONG */
+#ifndef LONG_LONG
+#define LONG_LONG PY_LONG_LONG
+#endif
+
/* structure to hold interpreter data */
typedef struct {
PyInterpreterState *istate;
PSP Notes
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
As an excercise in PSP usability, I've been going through JSP examples
from Tomcat and rewriting them using PSP, here are random notes on the
subject.
* JSP has a notion of an application (e.g. "/apps/mywebapp") with a
document root (e.g. /home/www/blah). Some stuff (e.g. location of classes)
then becomes relative to those paths. In PSP there isn't really a clear
concept of an application, but the closest thing to that is the directory
in which the PythonHandler directive is specified. This is nothing new,
btw, it's always how mod_python worked. So if you have:
<Directory /home/www/psp>
AddHandler mod_python .psp <--note the new clever handler name
PythonHandler mod_python.psp
</Directory>
...then /home/www/psp will be prepended to sys.path, therefore if you
create a directory /home/www/psp/pylib, you could import a module from a
psp file like this:
<%
from pylib import mymodule
%>
This way you have your entire application under /home/www/psp, you can
use, say, /home/www/psp/html for psp/html and all your Python modules are
in /home/www/pylib, giving you a clear separation of logic and interface.
* Next thing that I ran into is having to reload mymodule if it changes.
There is now a new recommended way of doing this:
mymodule = apache.import_module("pylib.mymodule")
This is the same function that mod_python uses internally for autorelad
and takes care of all your reload needs. It does stat the file every time,
so when you're sure you won't need to reload the page, just change it to:
mymodule = apache.import_module("pylib.mymodule", autoreload=0)
* JSP page import directive
JSP:
<%@ page import = "num.NumberGuessBean" %>
PSP:
<%
num = apache.import_module("pylib.num")
%>
... now you've got num.NumberGuessBean, you get the idea
* JSP useBean action
JSP:
<jsp:useBean id="numguess" class="num.NumberGuessBean" scope="session"/>
This means that numguess is an instance of num.NumberGuessBean and it will
persist for as long as the session exists.
PSP (again, no need for special syntax):
<%
numguess = session.setdefault("numguess", num.NumberGuessBean())
%>
* JSP setProperty
This will match up form elements and set them in a Java object. So if the
object defines setColor() and the form contains a field "Color", JSP will
call setColor passing value of color as the argument.
JSP:
<jsp:setProperty name="numguess" property="*"/>
PSP:
Well, there isn't exactly this functionality, but there is something
different. You can use the same functionality that the publisher handler
uses to match up form elements with a function:
class Car:
def __init__(self, color):
# do something
Then a psp page called as result of a form submition can do this:
<%
car = psp.apply_data(Car)
%>
This will call the callable object Car (classes are callable), passing it
the value of "color", and resulting in an instance of Car which is
assigned to car.
* <%@ page session="false"%>
In JSP this means don't create a session for this page. This is really
easy in PSP - just don't mention the "session" variable in your page. The
psp handler examines the code for mentions of "session" and generates (and
locks) one if it encounters such mentions.
* page errorPage
JSP allows you to specify a special error page to be displayed when an
exception is thrown.
JSP:
<%@ page errorPage="errorpge.jsp" %>
PSP:
<%
psp.set_error_page("errorpge.psp")
%>
When (if) errorpge.psp is invoked, it will have a global "exception"
variable which will contain same info as returned by sys.exc_info().
* include
Of course, PSP supports <%@ include file="blah.html"%>
Any comments?
Grisha
Re: Status
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Fri, 15 Aug 2003, David Fraser wrote:
> And in fact I do modify the dict object I make from the FieldStorage
> object ... to do things like automatically read in an attachment object,
> etc.
> The question is, are any of these ideas generally useful for modpython
> or should I just keep doing my own thing?
Perhaps you could describe your use of FieldStorage in detail (I don't
really get the part about attachment object) - it's always good to see an
example of real world use that we can analyze to improve the interface.
Grisha
Re: Status
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>On Thu, 14 Aug 2003, David Fraser wrote:
>
>
>
>>In addition I would like to do some code to make FieldStorage a real
>>dictionary... hopefully I can get that in in time
>>
>>
>
>Keep in mind a couple of things - unlike dict, FieldStorage internally can
>have duplicate keys, and keys are case-insensitive. Also, the public
>interface to the object should be suggestive of read-only, e.g. it makes
>sense for FieldStorage to have a get() method (which it does now), but
>doesn't make sense to have a setdefault() because it modifies the object
>by definition.
>
>Grisha
>
>
>
Part of the reason I was wanting to do this is the first thing I tend do
to with a FieldStorage object is convert it to a dictionary and get rid
of duplicate keys.
However, the duplicates could still be handled from within a dict object.
Case-insensitive is great, but could also be handled from within a dict
object.
And in fact I do modify the dict object I make from the FieldStorage
object ... to do things like automatically read in an attachment object,
etc.
The question is, are any of these ideas generally useful for modpython
or should I just keep doing my own thing?
David
Re: Status
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Thu, 14 Aug 2003, David Fraser wrote:
> In addition I would like to do some code to make FieldStorage a real
> dictionary... hopefully I can get that in in time
Keep in mind a couple of things - unlike dict, FieldStorage internally can
have duplicate keys, and keys are case-insensitive. Also, the public
interface to the object should be suggestive of read-only, e.g. it makes
sense for FieldStorage to have a get() method (which it does now), but
doesn't make sense to have a setdefault() because it modifies the object
by definition.
Grisha
Re: Status
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>I think that pretty much everything I envisioned in mod_python 3.1 is
>there, or at least being really close. What's in CVS right now should be
>usable (haven't tested it on Windows yet, but on Linux and FreeBSD and
>probably Solaris should work just fine).
>
>It would be nice if people checked it out and experimented with it so that
>we can get closer to some kind of a alpha/beta release.
>
>The main new things are:
>
>* Cookies. Mod_python now has its own Cookie classes capable of setting
>simple cookies, HMAC signed cookies (SignedCookie) as well as ability to
>store marshallable objects in a signed cookie (MarshalCookie).
>
>* PSP - which is basically a flex scanner that can convert the HTML-<%%>
>stuff into Python source code. It is wrapped in a Python module called
>_psp. The psp (sans underscore) module is a fully functional mod_python
>handler designed to handle pages containing PSP code; it takes care of
>caching, as well as automatic session locking.
>
>* Session support in Session.py. Sessions are dictionary-like objects that
>live on the server side (in memory or a dbm file, and one could optionally
>provide additional implementations, e.g. database-stored sessions), and
>know how to set state via cookies and load themselves based on session id.
>Sessions are also good at generating hard to guess session id's and can
>take advantage of mod_python's SignedCookie to make session spoofing even
>harder.
>
>* Global locking - this is undocumented and is for internal use by
>sessions, but probably worth mentioning - it uses APR's global_mutex api
>to provide locking across all threads/proceses.
>
>This is all major new stuff I can think of right now... All of it is
>documented, so if you have tetex and latex2html installed you should be
>able to generate PDF and html docs my typing "make html" or "make pdf" in
>the Doc directory.
>
>Grisha
>
>
>
We'll definitely have a look at Cookies, Sessions and Global locking as
we already have extensions for these in our application which will need
to migrate over to the new system, and might provide some added code...
In addition I would like to do some code to make FieldStorage a real
dictionary... hopefully I can get that in in time
Thanks for the update
David
Re: automated snapshots (was: Status)
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Fri, 15 Aug 2003, Thom May wrote:
> ~apmail/bin/taritup is the script - let me know if I should do this; and
> I'll get it set up.
If you know how, please, that would be really wonderful. I was thinking of
looking at it, but don't have much time atm.
Thanks,
Grisha
Re: Alpha release?
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Thanks, Barry, I think this is good - it didn't occur to me to do it this
way. I checked the patch in and also removed the paragraph you mention
from the docs.
Grisha
On Thu, 21 Aug 2003, Barry Pederson wrote:
> Gregory (Grisha) Trubetskoy wrote:
> > Given that there isn't a lot of feedback on this list, and given that I
> > can't think of any changes/additions to the code as it is right now, I
> > propose that we release it as 3.1.0 alpha with an announcement to a wider
> > audience (the other list, and may be comp.lang.python), so that it can get
> > more exposure and better testing.
>
> I've got another suggestion ...
>
> Right now, mod_python mixes in some data with the user's data that get
> pickled, and the docs mention:
>
> ---------
> (A few key names are used by the BaseSession
> class itself for storing session metadata, they are preceeded with
> an underscore, so if you stay away from key names beginning with an
> underscore, you should be safe.)
> ---------
>
> That seems unnecessary. I'd suggest storing the metadata in a
> dictionary, and having the user's dictionary stored as a member of the
> metadata dictionary, say under the key name "_data". That way there's
> no worries about keyname conflicts, makes the thing a bit more
> bulletproof.
>
> I'll attach a patch showing what I have in mind - the only cost should
> be a few more bytes in the pickle. The subclass implementations of
> do_load() and do_save() are simplified a bit, and the session cleanup
> code doesn't need to be changed at all.
>
> I also tried moving checking for expired sessions down into the
> BaseSession.load() method, instead of completely loading the session and
> then later on deciding in __init__() that you have to undo what you did
> in load().
>
> Barry
>
Re: Alpha release?
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> Given that there isn't a lot of feedback on this list, and given that I
> can't think of any changes/additions to the code as it is right now, I
> propose that we release it as 3.1.0 alpha with an announcement to a wider
> audience (the other list, and may be comp.lang.python), so that it can get
> more exposure and better testing.
I've got another suggestion ...
Right now, mod_python mixes in some data with the user's data that get
pickled, and the docs mention:
---------
(A few key names are used by the BaseSession
class itself for storing session metadata, they are preceeded with
an underscore, so if you stay away from key names beginning with an
underscore, you should be safe.)
---------
That seems unnecessary. I'd suggest storing the metadata in a
dictionary, and having the user's dictionary stored as a member of the
metadata dictionary, say under the key name "_data". That way there's
no worries about keyname conflicts, makes the thing a bit more
bulletproof.
I'll attach a patch showing what I have in mind - the only cost should
be a few more bytes in the pickle. The subclass implementations of
do_load() and do_save() are simplified a bit, and the session cleanup
code doesn't need to be changed at all.
I also tried moving checking for expired sessions down into the
BaseSession.load() method, instead of completely loading the session and
then later on deciding in __init__() that you have to undo what you did
in load().
Barry
Re: Building on Windows...
Posted by David Fraser <da...@sjsoft.com>.
David Fraser wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
>> Given that there isn't a lot of feedback on this list, and given that I
>> can't think of any changes/additions to the code as it is right now, I
>> propose that we release it as 3.1.0 alpha with an announcement to a
>> wider
>> audience (the other list, and may be comp.lang.python), so that it
>> can get
>> more exposure and better testing.
>>
>> Grisha
>>
>>
>>
> Sounds great... While we're at releasing 3.1 alpha...
> I'm trying to build modpython latest CVS for Windows from source.
> However my standard build of apache 2.0.47 following
> http://httpd.apache.org/docs-2.0/platform/win_compiling.html doesn't
> seem to produce a variety of apxs, which modpython seems to need for
> configure...
> I've got Visual C++ 6.0, so I can't simply use the mod_python.vcproj in
> src (which is for 7.0)
Hi
Just found this great tool:
http://www.codeproject.com/tools/prjconverter.asp?print=true
Which converts VC++ 7.0 projects to VC++ 6.0 projects.
I'll try it out on mod_python and see if I can get it to build...
David
Re: Build system
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Thu, 21 Aug 2003, David Fraser wrote:
> David Fraser wrote:
>
> On a related note, would it be possible to produce a distutils-style
> setup.py that:
> 1) Doesn't require running configure
It's probably possible, given that the only thing setup.py.in uses is the
mod_python version, and it should be farily easy to make that part of
setup.py itself.
> 2) Can build mod_python.so on Windows
Well, distutils does not know much about how to build applications that
embed Python (although that might be supported in the future), and
certainly it doesn't know how to build an Apache module, which is what
mod_python is. So this isn't going to be possible on _any_ operating
system.
> 3) Can produce a Windows installer on Windows
I am almost sure it already can.
> 4) Doesn't require Make files
It doesn't. It's convenient to invoke it _from_ make, but you don't have
to.
Grisha
Re: Build system
Posted by David Fraser <da...@sjsoft.com>.
David Fraser wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
>> Given that there isn't a lot of feedback on this list, and given that I
>> can't think of any changes/additions to the code as it is right now, I
>> propose that we release it as 3.1.0 alpha with an announcement to a
>> wider
>> audience (the other list, and may be comp.lang.python), so that it
>> can get
>> more exposure and better testing.
>>
>> Grisha
>>
>>
>>
> Sounds great... While we're at releasing 3.1 alpha...
> I'm trying to build modpython latest CVS for Windows from source.
> However my standard build of apache 2.0.47 following
> http://httpd.apache.org/docs-2.0/platform/win_compiling.html doesn't
> seem to produce a variety of apxs, which modpython seems to need for
> configure...
> I've got Visual C++ 6.0, so I can't simply use the mod_python.vcproj in
> src (which is for 7.0)
> I do have mingw and cygwin though
> There doesn't seem to be any documentation around on how to build
> mod_python for Windows.
> (I need to do this because I want to test with Python 2.3)
> I'm not saying we neccessarily need heaps of documentation for the Alpha
> release, but if someone can help me through it, I can test it.
> And also, that would generate some documentation itself!
>
> David
>
On a related note, would it be possible to produce a distutils-style
setup.py that:
1) Doesn't require running configure
2) Can build mod_python.so on Windows
3) Can produce a Windows installer on Windows
4) Doesn't require Make files
5) Any of the above!
I know that configure etc make things much easier on Unix, but how many
of the requirements for building mod_python are really neccessary?
I'm keen to help set this up if it is feasible and someone can point me
in the right direction
David
Re: Alpha release?
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>So any plus ones on this?
>
>Grisha
>
>On Thu, 21 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
>
>
>
>>Given that there isn't a lot of feedback on this list, and given that I
>>can't think of any changes/additions to the code as it is right now, I
>>propose that we release it as 3.1.0 alpha with an announcement to a wider
>>audience (the other list, and may be comp.lang.python), so that it can get
>>more exposure and better testing.
>>
>>Grisha
>>
>>
>>
>
>
>
+1 From me, particularly if that means a downloadable installer so I can
test it on Windows :-)
David
Re: Alpha
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>Thanks for the patch, I'll add that in. BTW - if you need more things to
>do, setup.py could dig out the version from ../src/include/mpversion.h,
>then we wouldn't need to have it autoconf-generated. :-)
>
>
Patch attached :-) This is just a patch to setup.py.in, so the rename to
setup.py can presumably take place (though I'm not sure about the @APXS@)
I used a regular expression to search it in the hope that it will be
fairly robust.
I hope I have got the paths right - you do run it from the parent as
dist/setup.py, right?
>On Wed, 27 Aug 2003, David Fraser wrote:
>
>
>>Basically it provides an alternative method which is still easier than
>>manually copying (it's not as nice as the tk method because
>>it doesn't guide you to the expected directory in the first place -
>>because there doesn't seem to be a nice way to do that in the win32 api!)
>>
>>
>I wonder if it might be the current working directory, but that's just a
>guess.
>
>
No, it actually just displays the entire directory tree, and you have to
start from My Computer.
You can pass in a Root but then it only displays subdirectories of that!
Actually we should really look up the directory in the registry I guess
David
Re: Alpha
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Thanks for the patch, I'll add that in. BTW - if you need more things to
do, setup.py could dig out the version from ../src/include/mpversion.h,
then we wouldn't need to have it autoconf-generated. :-)
On Wed, 27 Aug 2003, David Fraser wrote:
> Basically it provides an alternative method which is still easier than
> manually copying (it's not as nice as the tk method because
> it doesn't guide you to the expected directory in the first place -
> because there doesn't seem to be a nice way to do that in the win32 api!)
I wonder if it might be the current working directory, but that's just a
guess.
Grisha
Re: Alpha
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>On Wed, 27 Aug 2003, David Fraser wrote:
>
>
>>One question - is it really neccessary to have the tkinter dependency in
>>the install?
>>
>>
>Well... You have to give the user some way to specify where Apache is, so
>that the installer can place mod_python in the right location. The stock
>installer from python.org includes tk by default, so I thought it was
>safe.
>
>
Yes, it's just that we try do a minimal Python install for our end users...
>>It seems it is only required to ask for the directory of Apache in the
>>postinstall process...
>>
>>
>Pretty much.
>
>
>>Would you be happy to accept a patch that removes it, or provides an
>>alternate way of specifying the directory if Tkinter is not installed?
>>
>>
>
>If you can some up with something, that'd be great. In
>win32_postinstall.py, if you make askForApacheDir() fail gracefully if
>Tkinter is not there (with try/except), and then perhaps place
>mod_python.so into the Python directory instead (since you wouldn't know
>where Apache is), and adjust LoadModule in the final message accordingly.
>
>Grisha
>
>
I think the current handling is fine, it makes more sense for the user
to copy mod_python to the right place as it currently does.
But I've added a patch which will use the win32 extensions to let the
user browse to the right path if tk isn't installed.
I guess this just matches exactly what our users tend to have, so it
might not help anyone else, but I'd be grateful if it could be included.
Basically it provides an alternative method which is still easier than
manually copying (it's not as nice as the tk method because
it doesn't guide you to the expected directory in the first place -
because there doesn't seem to be a nice way to do that in the win32 api!)
The patch is attached. If I get time, I'll have a look at automatically
modifying the httpd.conf...
David
Re: Alpha
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 27 Aug 2003, David Fraser wrote:
> One question - is it really neccessary to have the tkinter dependency in
> the install?
Well... You have to give the user some way to specify where Apache is, so
that the installer can place mod_python in the right location. The stock
installer from python.org includes tk by default, so I thought it was
safe.
> It seems it is only required to ask for the directory of Apache in the
> postinstall process...
Pretty much.
> Would you be happy to accept a patch that removes it, or provides an
> alternate way of specifying the directory if Tkinter is not installed?
If you can some up with something, that'd be great. In
win32_postinstall.py, if you make askForApacheDir() fail gracefully if
Tkinter is not there (with try/except), and then perhaps place
mod_python.so into the Python directory instead (since you wouldn't know
where Apache is), and adjust LoadModule in the final message accordingly.
Grisha
Re: Alpha
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>Check it out:
>
>http://www.modpython.org/dist/mod_python-3.1.0a.tgz
>http://www.modpython.org/dist/mod_python-3.1.0a.win32-py2.3.exe
>
>The docs are here:
>
>http://www.modpython.org/live/mod_python-3.1.0a/doc-html/
>http://www.modpython.org/live/mod_python-3.1.0a/modpython.pdf
>
>
Great, thanks for the release.
One question - is it really neccessary to have the tkinter dependency in
the install?
It seems it is only required to ask for the directory of Apache in the
postinstall process...
Would you be happy to accept a patch that removes it, or provides an
alternate way of specifying the directory if Tkinter is not installed?
David
Re: Alpha
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Tue, 26 Aug 2003, Thom May wrote:
> I'd tend to argue we should so we can get it into apache's mirroring
> system. Although, I'm ambivalent for the alpha. Certainly for the full
> release this would seem to be goodness. Also, moving to daedalus makes
> it obvious to all concerned that this is an ASF sponsored project, which
> I think is no bad thing.
OK, moving them is easy, I just did it (*i think* - it's minotaur that
serves www.apache.org now?).
But I don't remember what to do to make download.cgi pick it up. Or should
we not bother with that at all and just point to www.apache.org/dist -
since there is probably only going to be a handful downloads.
Grisha
RE: Alpha
Posted by Sander Striker <st...@apache.org>.
> From: Thom May [mailto:thommay@apache.org]
> Sent: Tuesday, August 26, 2003 9:58 PM
>> To the Apache folks on this list: before announcing this to a wider
>> audience - do you think we should move the tgz and windist files to
>> daedalus?
>
> I'd tend to argue we should so we can get it into apache's mirroring system.
> Although, I'm ambivalent for the alpha. Certainly for the full release this
> would seem to be goodness.
> Also, moving to daedalus makes it obvious to all concerned that this is an
> ASF sponsored project, which I think is no bad thing.
+1. Start using the mirroring system early and get used to its workings.
It will be usefull to have some experience with it prior hitting 1.0.
Sander
Re: Alpha
Posted by Thom May <th...@apache.org>.
* Gregory (Grisha) Trubetskoy (grisha@apache.org) wrote :
>
> Check it out:
>
> http://www.modpython.org/dist/mod_python-3.1.0a.tgz
> http://www.modpython.org/dist/mod_python-3.1.0a.win32-py2.3.exe
>
> The docs are here:
>
> http://www.modpython.org/live/mod_python-3.1.0a/doc-html/
> http://www.modpython.org/live/mod_python-3.1.0a/modpython.pdf
>
>
> To the Apache folks on this list: before announcing this to a wider
> audience - do you think we should move the tgz and windist files to
> daedalus?
I'd tend to argue we should so we can get it into apache's mirroring system.
Although, I'm ambivalent for the alpha. Certainly for the full release this
would seem to be goodness.
Also, moving to daedalus makes it obvious to all concerned that this is an
ASF sponsored project, which I think is no bad thing.
-Thom
Alpha
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Check it out:
http://www.modpython.org/dist/mod_python-3.1.0a.tgz
http://www.modpython.org/dist/mod_python-3.1.0a.win32-py2.3.exe
The docs are here:
http://www.modpython.org/live/mod_python-3.1.0a/doc-html/
http://www.modpython.org/live/mod_python-3.1.0a/modpython.pdf
To the Apache folks on this list: before announcing this to a wider
audience - do you think we should move the tgz and windist files to
daedalus?
I'm inclined to think that it's OK on www.modpython.org, but mainly
because I'm lazy and I'd like to see how many people actually download it.
Grisha
Re: Alpha release?
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> So any plus ones on this?
>
> Grisha
>
> On Thu, 21 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
>
>
>>Given that there isn't a lot of feedback on this list, and given that I
>>can't think of any changes/additions to the code as it is right now, I
>>propose that we release it as 3.1.0 alpha with an announcement to a wider
>>audience (the other list, and may be comp.lang.python), so that it can get
>>more exposure and better testing.
+1 Sure, I've been stopping, starting, gracefuly and otherwise, and it
seems OK now. Had FreeBSD 5.1 completely hang before, but since you've
made that change to the pool it's working well.
Barry
Re: Alpha release?
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
So any plus ones on this?
Grisha
On Thu, 21 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
>
> Given that there isn't a lot of feedback on this list, and given that I
> can't think of any changes/additions to the code as it is right now, I
> propose that we release it as 3.1.0 alpha with an announcement to a wider
> audience (the other list, and may be comp.lang.python), so that it can get
> more exposure and better testing.
>
> Grisha
>
Re: Building on Windows...
Posted by David Fraser <da...@sjsoft.com>.
Gregory (Grisha) Trubetskoy wrote:
>Given that there isn't a lot of feedback on this list, and given that I
>can't think of any changes/additions to the code as it is right now, I
>propose that we release it as 3.1.0 alpha with an announcement to a wider
>audience (the other list, and may be comp.lang.python), so that it can get
>more exposure and better testing.
>
>Grisha
>
>
>
Sounds great... While we're at releasing 3.1 alpha...
I'm trying to build modpython latest CVS for Windows from source.
However my standard build of apache 2.0.47 following
http://httpd.apache.org/docs-2.0/platform/win_compiling.html doesn't
seem to produce a variety of apxs, which modpython seems to need for
configure...
I've got Visual C++ 6.0, so I can't simply use the mod_python.vcproj in
src (which is for 7.0)
I do have mingw and cygwin though
There doesn't seem to be any documentation around on how to build
mod_python for Windows.
(I need to do this because I want to test with Python 2.3)
I'm not saying we neccessarily need heaps of documentation for the Alpha
release, but if someone can help me through it, I can test it.
And also, that would generate some documentation itself!
David
PS Sorry Grisha, forgot to include the list in the first reply
Alpha release?
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Given that there isn't a lot of feedback on this list, and given that I
can't think of any changes/additions to the code as it is right now, I
propose that we release it as 3.1.0 alpha with an announcement to a wider
audience (the other list, and may be comp.lang.python), so that it can get
more exposure and better testing.
Grisha
Re: automated snapshots (was: Status)
Posted by Thom May <th...@apache.org>.
* Greg Stein (gstein@lyra.org) wrote :
> On Thu, Aug 14, 2003 at 11:42:08AM -0400, Gregory (Grisha) Trubetskoy wrote:
> >
> > I just added another snapshot
> >
> > http://www.modpython.org/tmp/httpd-python-20030814.tgz
>
> Normally, (automated) snapshots are kept on cvs.apache.org under the
> snapshots directory. See http://cvs.apache.org/snapshots/
>
> I'm not sure what creates those, but infrastructure@ ought to know. I'd very
> much recommend to simply plugging into that system.
>
~apmail/bin/taritup is the script - let me know if I should do this; and
I'll get it set up.
Cheers
-Thom
automated snapshots (was: Status)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 14, 2003 at 11:42:08AM -0400, Gregory (Grisha) Trubetskoy wrote:
>
> I just added another snapshot
>
> http://www.modpython.org/tmp/httpd-python-20030814.tgz
Normally, (automated) snapshots are kept on cvs.apache.org under the
snapshots directory. See http://cvs.apache.org/snapshots/
I'm not sure what creates those, but infrastructure@ ought to know. I'd very
much recommend to simply plugging into that system.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Session/mutex problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I forgot to mention that this issues should be resolved now (apparently I
was using the wrong pool to allocate global_mutex, so they weren't getting
cleaned up on graceful restarts).
Also, thanks to Thom May we now have CVS snapshots:
http://cvs.apache.org/snapshots/httpd-python/
Grisha
On Sun, 17 Aug 2003, Barry Pederson wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
> > I'll check it out on my FreeBSD 4.8 box.
> >
> > Thanks, BTW, for trying it out - we need more problem reports like this
> > :-)
>
> While poking around to see what could be done about this, I found an
> even simpler failure trigger ... under my config as described before
> (FreeBSD 5.1 Apache 2.0.47, Python 2.3, prefork MPM, start as user
> "root" switching to "www"), just starting apache (apachectl start),
> gives this in the httpd-error.log
>
> ------------
> [Sun Aug 17 12:18:22 2003] [notice] mod_python: Creating 256 session
> mutexes based on 256 max processes and 0 max threads.
> [Sun Aug 17 12:18:22 2003] [notice] Apache configured -- resuming normal
> operations
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx948550.
> --------------
>
>
> And then doing a graceful restart (apachectl graceful) give this
>
> ---------------
> [Sun Aug 17 12:18:46 2003] [notice] Graceful restart requested, doing
> restart
> [Sun Aug 17 12:18:46 2003] [notice] mod_python: Creating 256 session
> mutexes based on 256 max processes and 0 max threads.
> [Sun Aug 17 12:18:46 2003] [error] (17)File exists: mod_python: Failed
> to create global mutex 0 of 256 (/tmp/mpmtx948550).
> Configuration Failed
> ----------------
>
> and then all the httpd processes quit. You don't even have to request
> any mod-python handled pages :(
>
> Barry
>
Re: Session timeout problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Yes, I think adding a self.clear() after self.do_delete() (line 240) would
do it.
P.S. I'm still trying to figure out the graceful restart problem.
Grisha
On Sun, 17 Aug 2003, Barry Pederson wrote:
> This is an easy one...
>
> In the snapshot http://www.modpython.org/tmp/httpd-python-20030814.tgz
> the BaseSession.__init__() method checks for a session timing out, and
> if it's expired, it makes a new session. However, the old session's
> data is still hanging around and is carried over into the new session.
>
> There probably should be a call to self.clear() somewhere in there,
> perhaps at the end of Session.delete()?
>
> Here's a bit of demo code. Every time you reload the page, the count
> stored in the session increases by one, even if you wait longer than 30
> seconds and have a new session created.
>
> ----------------
> import time
> from mod_python.Session import Session
>
> def index(req):
> sess = Session(req)
> count = sess.get('count', 0) + 1
> sess['count'] = count
> sess.set_timeout(30)
> sess.save()
> return 'is_new(): %d count: %d, time: %s' % (sess.is_new(), count,
> time.strftime('%Y-%m-%d %H:%M:%S'))
> -----------------
>
> Barry
>
Session timeout problem
Posted by Barry Pederson <bp...@barryp.org>.
This is an easy one...
In the snapshot http://www.modpython.org/tmp/httpd-python-20030814.tgz
the BaseSession.__init__() method checks for a session timing out, and
if it's expired, it makes a new session. However, the old session's
data is still hanging around and is carried over into the new session.
There probably should be a call to self.clear() somewhere in there,
perhaps at the end of Session.delete()?
Here's a bit of demo code. Every time you reload the page, the count
stored in the session increases by one, even if you wait longer than 30
seconds and have a new session created.
----------------
import time
from mod_python.Session import Session
def index(req):
sess = Session(req)
count = sess.get('count', 0) + 1
sess['count'] = count
sess.set_timeout(30)
sess.save()
return 'is_new(): %d count: %d, time: %s' % (sess.is_new(), count,
time.strftime('%Y-%m-%d %H:%M:%S'))
-----------------
Barry
Re: Session/mutex problem
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> I'll check it out on my FreeBSD 4.8 box.
>
> Thanks, BTW, for trying it out - we need more problem reports like this
> :-)
While poking around to see what could be done about this, I found an
even simpler failure trigger ... under my config as described before
(FreeBSD 5.1 Apache 2.0.47, Python 2.3, prefork MPM, start as user
"root" switching to "www"), just starting apache (apachectl start),
gives this in the httpd-error.log
------------
[Sun Aug 17 12:18:22 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
[Sun Aug 17 12:18:22 2003] [notice] Apache configured -- resuming normal
operations
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx948550.
--------------
And then doing a graceful restart (apachectl graceful) give this
---------------
[Sun Aug 17 12:18:46 2003] [notice] Graceful restart requested, doing
restart
[Sun Aug 17 12:18:46 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
[Sun Aug 17 12:18:46 2003] [error] (17)File exists: mod_python: Failed
to create global mutex 0 of 256 (/tmp/mpmtx948550).
Configuration Failed
----------------
and then all the httpd processes quit. You don't even have to request
any mod-python handled pages :(
Barry
Re: Session/mutex problem
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Sun, 17 Aug 2003, Barry Pederson wrote:
> (13)Permission denied: mod_python: Failed to reinit global modutex
> /tmp/mpmtx191750.
> ------------
> (modutex? typo there)
Probabaly just my fat-fingering :-)
>
>
> Looking in the /tmp folder, I found the mutex files with permissions
> such as:
>
> -rw------- 1 root wheel 0 Aug 17 10:04 mpmtx191750
>
> So...I'm guessing the mutex files are created before apache forks and
> switches from the "root" user to the "www" user, and can't access those
> files?
That's weird - its the APR that creates the file, I'd imagine it should
set the permissions correctly... I never ran into this, but then I always
did all my testing as a non-root user, so the server never switched the
uid.
I'll check it out on my FreeBSD 4.8 box.
Thanks, BTW, for trying it out - we need more problem reports like this
:-)
Grisha
Session/mutex problem
Posted by Barry Pederson <bp...@barryp.org>.
Gregory (Grisha) Trubetskoy wrote:
> I just added another snapshot
>
> http://www.modpython.org/tmp/httpd-python-20030814.tgz
>
> and also the latest compilation of the html docs:
>
> http://www.modpython.org/tmp/doc-html-20030814/
>
> Now you have no excuse for not checking it out :-)
I was checking this out on a FreeBSD 5.1 box, with Apache 2.0.47 using
the prefork MPM, and with the "User www" directive in httpd.conf. When
trying to use the new session code, got the exception:
---------
File "/usr/local/lib/python2.3/site-packages/mod_python/Session.py",
line 342, in do_load
_apache._global_lock(self._req.server, None, 0)
ValueError: Failed to acquire global mutex lock
---------
Looking at the httpd-error.log, I found:
-----------
[Sun Aug 17 10:04:16 2003] [notice] mod_python: Creating 256 session
mutexes based on 256 max processes and 0 max threads.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
(13)Permission denied: mod_python: Failed to reinit global modutex
/tmp/mpmtx191750.
------------
(modutex? typo there)
Looking in the /tmp folder, I found the mutex files with permissions
such as:
-rw------- 1 root wheel 0 Aug 17 10:04 mpmtx191750
So...I'm guessing the mutex files are created before apache forks and
switches from the "root" user to the "www" user, and can't access those
files?
Barry
Re: Status
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I just added another snapshot
http://www.modpython.org/tmp/httpd-python-20030814.tgz
and also the latest compilation of the html docs:
http://www.modpython.org/tmp/doc-html-20030814/
Now you have no excuse for not checking it out :-)
Grisha
On Wed, 13 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
>
> On Wed, 13 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
>
> > It would be nice if people checked it out and experimented with it so that
> > we can get closer to some kind of a alpha/beta release.
>
> Oh, and if CVS is too much trouble, you can get a snapshot here:
>
> http://www.modpython.org/tmp/httpd-python-20030813.tgz
>
> Grisha
>
Re: Status
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 13 Aug 2003, Gregory (Grisha) Trubetskoy wrote:
> It would be nice if people checked it out and experimented with it so that
> we can get closer to some kind of a alpha/beta release.
Oh, and if CVS is too much trouble, you can get a snapshot here:
http://www.modpython.org/tmp/httpd-python-20030813.tgz
Grisha
Status
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
I think that pretty much everything I envisioned in mod_python 3.1 is
there, or at least being really close. What's in CVS right now should be
usable (haven't tested it on Windows yet, but on Linux and FreeBSD and
probably Solaris should work just fine).
It would be nice if people checked it out and experimented with it so that
we can get closer to some kind of a alpha/beta release.
The main new things are:
* Cookies. Mod_python now has its own Cookie classes capable of setting
simple cookies, HMAC signed cookies (SignedCookie) as well as ability to
store marshallable objects in a signed cookie (MarshalCookie).
* PSP - which is basically a flex scanner that can convert the HTML-<%%>
stuff into Python source code. It is wrapped in a Python module called
_psp. The psp (sans underscore) module is a fully functional mod_python
handler designed to handle pages containing PSP code; it takes care of
caching, as well as automatic session locking.
* Session support in Session.py. Sessions are dictionary-like objects that
live on the server side (in memory or a dbm file, and one could optionally
provide additional implementations, e.g. database-stored sessions), and
know how to set state via cookies and load themselves based on session id.
Sessions are also good at generating hard to guess session id's and can
take advantage of mod_python's SignedCookie to make session spoofing even
harder.
* Global locking - this is undocumented and is for internal use by
sessions, but probably worth mentioning - it uses APR's global_mutex api
to provide locking across all threads/proceses.
This is all major new stuff I can think of right now... All of it is
documented, so if you have tetex and latex2html installed you should be
able to generate PDF and html docs my typing "make html" or "make pdf" in
the Doc directory.
Grisha