worth waiting for the patches from David Fraser though. See:
http://issues.apache.org/jira/browse/MODPYTHON-55?page=comments#action_65861
Jim
Regards,
Nicolas
2005/5/20, Jim Gallacher [EMAIL PROTECTED]:
Nicolas Lehuen wrote:
The problem is that this won't work when building on Windows. I think
we
Hi dharana,
I've been away for a few days, but should have some time to mess around
with this today.
dharana wrote:
More info:
It just happens with some classes. Some work and some won't, and I don't
yet know why.
Do you ever see segfaults if you only saving strings in your session,
... :(
Regards,
Nicolas
2005/6/1, Jim Gallacher (JIRA) [EMAIL PROTECTED]:
[ http://issues.apache.org/jira/browse/MODPYTHON-58?page=all ]
Jim Gallacher updated MODPYTHON-58:
---
Attachment: apachemodule.c-jg20050601-1.diff
Patch to fix issue is attached
Nicolas Lehuen wrote:
Grisha, can you tell us what is the process to release a new version,
including the update of the web site ?
Maybe include the web site source files in the subversion repository,
so that we can edit it ?
As for building the HTML documentation out of the LaTeX files, I'm a
you'll integrate your code in subversion.
Regards,
Nicolas
2005/6/12, Jim Gallacher [EMAIL PROTECTED]:
Nicolas,
It fails to compile when I add your bit of code. Sure looks like it
should work though.
requestobject.c: In function `request_tp_traverse':
requestobject.c:1539: error: structure has
2005/6/12, Jim Gallacher [EMAIL PROTECTED]:
Nicolas Lehuen wrote:
Hi Jim,
After a few checks (unittest + load testing), I've checked in my
modifications ; you might want to update and merge it with your code.
I'm still getting a memory leak with the merged code. Should I commit my
changes anyway
you to refactor
the Session.py code.
Regards,
Nicolas
2005/6/12, Jim Gallacher [EMAIL PROTECTED]:
I've created a new apache directive called PythonSessionOption. This
would be used to configure session handling in the apache config file.
This data is accessed with a new request method
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but
keep the file open between requests. Not sure if this would be robust
or just asking for dbm file corruption though.
I'm pretty sure it won't
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Any objection to just a SqlSession base class?
May be - it depends on how complex it becomes. Any attempts I've to
generalize SQL/DB stuff tend to become a mess since there are no firm
standards in this area
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I don't
know if it's a good idea to use transaction handling by default for
DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3 this module is included in the standard python
Nick wrote:
Jim Gallacher wrote:
Nick wrote:
Jim Gallacher wrote:
Using bsddb3 would introduce new dependency for mod_python, so I
don't know if it's a good idea to use transaction handling by
default for DbmSession. Maybe we could offer a subclass?
Starting with Python 2.3
Nicolas Lehuen wrote:
Hi Jim,
Until now, we suspected that the way global locks are handled could be
deadlock prone. You have just proved it.
I know that global locks are expensive on some systems, especially if
we want to use them in a multiprocess (forked) environment. That's why
we are
Graham Dumpleton wrote:
I can see two problems here. The first is that if the target of the
internal redirect is a part of the URL namespace which is under the
control of a different handler, or where ApplicationPath option was set
explicitly to be different, the PYSID would potentially override
Gregory (Grisha) Trubetskoy wrote:
On Thu, 28 Jul 2005, Nicolas Lehuen wrote:
Note that there are 29 unscheduled issues :
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolutionIds=-1pid=10640fixfor=-1
Maybe some of
Gregory (Grisha) Trubetskoy wrote:
On Thu, 28 Jul 2005, Jim Gallacher wrote:
I've either commited fixes or have fixes ready for 6 or 8 of those
issues. Also there some that don't apply to 3.2 (eg website or mailing
list issues). Must run right now but will make a list this evening of
issues
Just so everyone is clear, implementation of req.get_session() or its
equivalent has been deferred to version 3.3.
Graham Dumpleton wrote:
Some will know that I haven't been too keen on the way in which the
proposed new req.get_session() method was being implemented. My concerns
were that it
I've committed the fix. For some reason JIRA is picking up the
subversion commits but not forwarding the message to the mailing list.
This issue can be closed.
Jim
Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-69?page=all ]
Jim Gallacher updated MODPYTHON
Daniel Popowich wrote:
Jim Gallacher writes:
Daniel Popowich wrote:
The recent discussion of max locks and deadlocking issues with
_apache._global_(un)?lock() are timely for me:
I'm in the middle of writing a caching module for mod_python servlets
so a developer can have the output
Nicolas Lehuen wrote:
Another remark : has anyone suscribed to redhat, debian etc. mailing
list to watch for such patches ?
Not me.
I don't understand why those guys
aren't posting their patches on the mod_python mailing list.
I was wondering the same thing. What would be better for us,
Nicolas Lehuen wrote:
MODPYTHON-34 has been fixed in the current version of the publisher,
with the new importing system. As I've written before, I can roll back
the part regarding the import system if you really want that, all the
while maintaining the fix for MODPYTHON-34.
I haven't had
with the current code. It's not a new publisher, it's a
set of bug fixes. I mean, what is the purpose of releasing a new version
of mod_python if we don't fix the dozen of bugs that are related to the
publisher ?
Regards,
Nicolas
2005/8/10, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED
Gregory (Grisha) Trubetskoy wrote:
On Wed, 10 Aug 2005, Jim Gallacher wrote:
Compilation fails with the following:
requestobject.c: In function 'request_tp_dealloc':
requestobject.c:1482: warning: implicit declaration of function
'request_tp_clear'
This looks like a bug - I guess GCC 3
Gregory (Grisha) Trubetskoy wrote:
On Mon, 15 Aug 2005, Graham Dumpleton wrote:
Does this imply no more fixes for outstanding problems even though
the necessary patches have been posted up on JIRA. Eg,.
If we stick to the schedule, then yes.
Gregory (Grisha) Trubetskoy wrote:
OK, here is the flex scoop - as the the docs point out, anything before
2.5.31 is not reentrant and I think even uses a slightly different
interface so older flex won't even process the psp_parser.l file correctly.
Looking at Fedora Core 4, it still has
Gregory (Grisha) Trubetskoy wrote:
OK, here is the flex scoop - as the the docs point out, anything before
2.5.31 is not reentrant and I think even uses a slightly different
interface so older flex won't even process the psp_parser.l file correctly.
Looking at Fedora Core 4, it still has
I think we should aim for the second beta release in the next couple of
days. I have a few questions and a list of outstanding issues.
Name of tarball: mod_python-3.2.1b.tgz?
Also, I assume a new branch called tags/release-3.2.1-BETA will be
created in subversion, correct?
Outstanding
Nicolas Lehuen wrote:
Hi Jim,
The fix for MODPYTHON-72
http://issues.apache.org/jira/browse/MODPYTHON-72 should be easy,
unfortunately I'm quite busy right now, since my first daughter was born
three days ago...
Congratulations Nicolas!
I'll do my best to have a look at it, but if
I was hoping there would be a simple fix for this but a quick glance at
the code makes me think that will not be the case. Also, I don't think
this is a new bug as 3.1.4 does not generate a 404 NOT FOUND response
either:
Mod_python error: PythonHandler mod_python.publisher
Traceback (most
in MODPYTHON-77).
Regards,
Jim
Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12320905 ]
Jim Gallacher commented on MODPYTHON-77:
I tried your patch and the unit tests fail. Apache fails to start
Gregory (Grisha) Trubetskoy wrote:
I've been away this weekend - just got back, but I'm too busy to try to
read all the multiple-interpreter related comments. I guess my question
is - can someone provide a quick summary of how far we are from 3.2.1b
test tarbal?
I've also been away for the
)
# make install
Then (as non-root user!)
$ cd test
$ python test.py
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
?).
For the moment I don't see any quick and easy way to support both 2.0
and 2.1, from what you wrote. I'd rather we try to get 3.2 out with a
proper 2.0 support, and try to fix things for 2.1 when it goes at
least beta.
Regards,
Nicolas.
2005/9/7, Jorey Bump [EMAIL PROTECTED]:
Jim Gallacher
+1
Linux Debian Sid
apache 2.0.54
python 2.3.5
GCC 4.0.2
Ron Reisor wrote:
Yes! Plus, the software I'm developing is working too. I pulled out an
early version of FileSession and started using Session.FileSession.
Even better, you can use Session.Session() and the PythonOption session
FileSession configuration directive to get all the benefits of
Gregory (Grisha) Trubetskoy wrote:
Anybody got FreeBSD? I'm getting this. This is an old and possibly
misconfigured system, so the problem could be on my end.
FreeBSD 4.9
apache 2.0.53 (from ports)
python 2.3.3
$ make
Compiling for DSO.
/usr/local/sbin/apxs
Gregory (Grisha) Trubetskoy wrote:
On Thu, 8 Sep 2005, Jim Gallacher wrote:
I don't have FreeBSD, or any experience with any BSD, but I won't let
that stop me from commenting. :)
I don't see apr-0 listed in your includes in the above output.
APR_THREAD_MUTEX_UNNESTED is defined
for the software I wanted to install. :-(
Regards,
Jim
Jim Gallacher wrote:
Nicolas Lehuen wrote:
OK, I've checked in a version that compiles both on at least Win32 and
FreeBSD. I'm just testing if APR_HAS_THREAD is defined and only
include the apr_thread_mutex_lock and unlock calls if it is defined
to
investigate further right now. I'll revisit this tonight.
Regards,
Jim
Regards,
Nicolas
#if APR_HAS_THREADS defined(WITH_THREAD)
2005/9/11, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
FYI, I found the following note in the INSTALL file in the apache
source
without thread support, you may need to add
the
following lines to $PREFIX/sbin/envvars:
LD_PRELOAD=/usr/lib/libc_r.so
export LD_PRELOAD
[snip]
On Mon, 12 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
On Mon, 12 Sep 2005, Jim Gallacher wrote:
*** Warning: Linking the shared library
that the thread
safety code isn't there, but you still _can_ create threads because
Python
will let you - isn't this asking for a segfault/deadlock/whatever?
Grisha
On Mon, 12 Sep 2005, Jim Gallacher wrote:
Gregory (Grisha) Trubetskoy wrote:
Shouldn't that be PYTHON_WITH_THREAD rather than
in, or does it break
something on Win32?
Cheers
Grisha
On Tue, 13 Sep 2005, Jim Gallacher wrote:
Nicolas Lehuen wrote:
Jim, do you manage to build and test the 3.1.4 version on your setup ?
This looks like a permission problem, not something related to our
current
problem.
I haven't
=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ cd test
$ python test.py
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
+1
Linux Debian Sid
apache 2.0.54
python 2.3.5
gcc 4.0.2
Jim Gallacher wrote:
A new mod_python 3.2.2 beta tarball is now available for testing.
Hopefully this will be the last beta before the official 3.2 release.
Here are the rules:
In order for a file to be officially announced, it has
Grisha,
I think you mentioned that we should announce this beta on the
mod_python list as well. If so I thought we could wait until we get a +1
from a MacOS X user here on python-dev before proceeding.
Regards,
Jim
Jim Gallacher wrote:
A new mod_python 3.2.2 beta tarball is now available
Nicolas has created a windows binary for testing which is also available
at http://www.modpython.org/dist.
Regards,
Jim
Jim Gallacher wrote:
A new mod_python 3.2.2 beta tarball is now available for testing.
Hopefully this will be the last beta before the official 3.2 release.
Here
Gregory (Grisha) Trubetskoy wrote:
OK, my next question would be - is MySQL, PostgreSQL, Informix, Oracle,
etc next,
Yes. ;)
and is this the path we want to take, or is there something
about sqlite that makes it unique?
I don't know if it is that path we *want* to take, but I think
Grisha,
Your message implies that there is a mailing list for mod_python svn
commit messages. How can I subscribe to this?
Thanks,
Jim
Gregory (Grisha) Trubetskoy wrote:
Can we have a little discussion on pros/cons of this? Does this make
mod_python dependent on sqlite?
Thanks,
Grisha
Gregory (Grisha) Trubetskoy wrote:
Just to put this SQLite business to rest.
I think that (and we can discuss this - I don't set laws, I just have
opinions that may not always beright, so feel free to comment)
mod_python should do fewer things but do them exceptionally well.
Roughly
Nick wrote:
Jim Gallacher wrote:
Nicolas Lehuen wrote:
I thought that all this mptest.py thing was a bit disturbing, as
usually people took the wrong impression that they had to call the
/test/mptest.py URL, that is they thought that the handler system was
a bit like the publisher
Graham Dumpleton wrote:
Documentation says:
path_info
String. What follows after the file name, but is before
query args, if anything. Same as CGI PATH_INFO. (Read-Only)
The path_info member is now actually modifiable in 3.2 and
so Read Only designator can be dropped.
I've already
Nicolas Lehuen wrote:
2005/10/19, Nic Ferrier [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Is everyone here called Nic[h]olas?
Nicolas Lehuen [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] writes:
Nic, there is something I need to understand before giving my
advice on the
Nicolas Lehuen wrote:
OK I've checked in Graham's fix for MODPYTHON-83, and unsurprisingly it
doesn't break anything on Win32. So I'm ready to provide the next beta
build this week end if we can.
As for MODPYTHON-84 (the one about req.sendfile)I cannot really test it
since there are no
Nicolas Lehuen wrote:
OK I've checked in Graham's fix for MODPYTHON-83, and unsurprisingly it
doesn't break anything on Win32. So I'm ready to provide the next beta
build this week end if we can.
+1
I don't see any outstanding issues so if we are doing another beta let's
do it today.
Just
]:
2005/10/22, Jim Gallacher [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Nicolas Lehuen wrote:
OK I've checked in Graham's fix for MODPYTHON-83, and
unsurprisingly it
doesn't break anything on Win32. So I'm ready to provide the
next beta
build this week end if we can
, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
Indrek Järve wrote:
Jim Gallacher wrote:
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
+1 on SuSE Linux 9.2 (i586)
+1 on SuSE Linux
Indrek Järve wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Indrek Järve wrote:
Jim Gallacher wrote:
And see if any tests fail. If they pass, send a +1 to the list, if
they
fail, send the details (the versions of OS, Python and Apache, the
test
output, and suggestions
Dominic Wong wrote:
-1 for Gentoo Linux 2.6.13-gentoo-r3
Apache 2.0.54
Python 2.4.1
Hi Dominic,
When you have a chance could you apply the following patch and re-run
the tests?
Thanks,
Jim
Index: test/test.py
===
---
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__',
'__init__', '__iter__', '__new__',
Nick wrote:
Jim Gallacher wrote:
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
Indrek Järve wrote:
This behaviour has been with Python for quite a while, so claiming it's
simply a Python bug will be the same as declaring we don't support Windows.
Our company's software that runs on Windows and uses mod_python simply
patches util.py with the following change:
227c227
Jorey Bump wrote:
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__
Gregory (Grisha) Trubetskoy wrote:
If we don't get an resolution on this Gentoo issue - should we just go
ahead and release the file anyway? Hopefully then someone will fix it
before the final release?
Since we have not received any additional information on this I think we
should proceed.
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-77?page=all ]
Graham Dumpleton updated MODPYTHON-77:
--
Attachment: grahamd_20051105.tar.gz
Here is my first go at an alternate patch for this problem. Patch was made
Alexis,
Do you a have a small file which shows this behaviour and could be used
for testing? Even better would be a function which would generate a test
file. This could be included in the mod_python unit tests.
Jim
Alexis Marrero wrote:
All,
The current 3.1 mod_python implementation of
I've been spending some quality time with hexedit, vim and a little bit
of python. I can now generate a file which can be used in the unit test.
The problem seems to occur when a '\r' character is right at
readBlockSize boundary, which is 65368 in the current mod_python.util.
I have not yet
Gregory (Grisha) Trubetskoy wrote:
So I guess this means we roll and vote on a 3.2.5b?
As much as it pains me to say it, but yes, this is a must fixm so it's
on to 3.2.5b.
I think we need to do some more extensive testing on Alexis's fix before
we roll 3.2.5b. His read_to_boundary is
Alexis Marrero wrote:
Sorry for all this emails,
No worries. It's a bug that needs to be fixed, so your work will benefit
everyone. :)
Jim
,
/amn
On Nov 7, 2005, at 2:11 PM, Jim Gallacher wrote:
Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Thanks for sending the function that creates the test file. However
I ran it to create the test file, and after uploading the file the
MD5 still the same.
Just to clarify
I'll give it a try, and create a unit test at the same time. Should the
unit tests cover other possibilites such as \t, \r and so on?
Jim
Gregory (Grisha) Trubetskoy wrote:
I think the fix to that may be inserting
TEXT\\n {
psp_string_appendl(PSP_PG(pycode), STATIC_STR(n));
}
+1
Linux Debian 3.1 stable (sarge)
apache 2.0.54-5 (mpm-worker)
python 2.3.5
gcc 3.3.5
+1
Linux Debian unstable (sid)
apache 2.0.54-4 (mpm-prefork)
python 2.3.5
gcc 4.0.2
+1 with patch
Linux gentoo 2.6.12-gentoo-r6
apache 2.0.54 (mpm-prefork)
python 2.4.2
gcc 3.3.6
There are 2 issues with the unit tests in Gentoo that are fixed by the
attached patch. (Just to be clear, I mean the problems are with the unit
test code, not with mod_python).
First,
Nicolas Lehuen wrote:
Hi Jim,
2005/11/16, Jim Gallacher [EMAIL PROTECTED]:
+1 with patch
Linux gentoo 2.6.12-gentoo-r6
apache 2.0.54 (mpm-prefork)
python 2.4.2
gcc 3.3.6
There are 2 issues with the unit tests in Gentoo that are fixed by the
attached patch. (Just to be clear, I mean
Gregory (Grisha) Trubetskoy wrote:
OK, I think we got enough +1's and no show-stopping problems (for a beta
at least). I copied it over the apache server, once the mirrors sync
I'll update the site and send the big announcement.
I was also thinking it was time for a wider release, but was
Grisha,
Looks good and the links work.
Were you planning on making an announcement (on the mod_python list at
least) regarding your ApacheCon talk as well?
Jim
Gregory (Grisha) Trubetskoy wrote:
Let me know if you see anything wrong in the text below, I'll send it
out later today or
Michel Jouvin wrote:
Graham,
I played a little bit with worker MPM parameters. In particular I tested
your suggestion to increase to 2 StartServers. This has no effect on the
problem. I also tried to raise MaxSpareThread to MaxClient and
suppressed child recycling (MaxRequestPerChild=0) to
increasing until the max number (determined by
MaxClient and ThreadPerChild). When this max number is reached you get
the error message in main Apache error log.
Michel
--On mercredi 23 novembre 2005 19:30 -0500 Jim Gallacher
[EMAIL PROTECTED] wrote:
Michel Jouvin wrote:
Graham,
I played
is the time between the kill calls. I was testing
using qemu, and it needs lots of time for things to happen.
usage: ./killchildren # number of loops
Jim
Michel
--On jeudi 24 novembre 2005 17:41 -0500 Jim Gallacher
[EMAIL PROTECTED] wrote:
Michel,
I can't reproduce the problem on debian i386. I
Hi Mike,
I don't have time to dig into this tonight, but your patch causes one of
the unit tests to fail.
FAIL: test_util_fieldstorage (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File test.py, line
Grisha,
Speaking of 3.2.5 beta, how long do we wait before it becomes final?
Jim
Gregory (Grisha) Trubetskoy wrote:
Having looked at the FieldStorage code, I'm guessing the idea was that
you parse fields as they come in and append them to a list. This
preserves the original order of fields, in case it is needed.
I assumed that as well, but I'm not sure getting the
can make the official announcement at
ApacheCon?
Jim
On Mon, 28 Nov 2005, Jim Gallacher wrote:
Grisha,
Speaking of 3.2.5 beta, how long do we wait before it becomes final?
Jim
Gregory (Grisha) Trubetskoy wrote:
On Mon, 28 Nov 2005, Nicolas Lehuen wrote:
Why is the ordering so important ? I do understand we need to support
multiple values per field name, but I don't see why ordering is
needed.
I think that it may be dictated by some RFC (the stdlib does it this
Nicolas Lehuen wrote:
Hi,
Is it me or is it quite tiresome to get the URL that called us, or get
the complete URL that would call another function ?
When performing an external redirect (using mod_python.util.redirect for
example), we MUST (as per RFC) provide a full URL, not a relative
Daniel J. Popowich wrote:
Jim Gallacher writes:
Nicolas Lehuen wrote:
Second question, if there isn't any simpler way to do this, should we
add it to mod_python ? Either as a function like above in
mod_python.util, or as a member of the request object (named something
like url to match
Gregory (Grisha) Trubetskoy wrote:
On Tue, 29 Nov 2005, Jim Gallacher wrote:
Daniel J. Popowich wrote:
Here, here!! I've wanted parsed_uri to work as expected for quite
some time...I'm actually in a position where I could devote some time
to tracking this down. If apache doesn't provide
Nicolas Lehuen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=all ]
Nicolas Lehuen updated MODPYTHON-78:
Summary: No support for Apache 2.2 yet (was: No support for Apache 2.1 yet)
Now that Apache 2.2 is out, and
Nicolas Lehuen wrote:
I'll have to wait for the Win32 source code tree to be released to build
it and test your patch. Hopefully it'll be out soon.
Is there a wait to use macro directives so that we don't need to
maintain two separate branches ? A define that we could pass when
building
to require. Like the bsddb database
version for your session code, for example.
Nick
Jim Gallacher wrote:
From the 3.2.5b doc:
(http://www.modpython.org/live/mod_python-3.2.5b/doc-html/inst-prerequisites.html)
2.1 Prerequisites
* Python 2.2.1 or later. Earlier versions of Python
40 and 53
that may have a negative impact, but if we haven't actually tested on
the earlier versions are we just asking for trouble?
Jim
Nick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://article.gmane.org/gmane.comp.apache.mod-python.devel/865
Jim Gallacher wrote:
| I figured
We had talked about doing a 3.2 final release just after ApacheCon.
A couple of things have cropped up which we have (or should) fix, but
these will not be substantial changes from 3.2.5b. As such I think we
should do another beta followed very quickly by a final release. Any new
bugs that
My eyes keep glazing over every time I read through MODPYTHON-98. This
is not a reflection on Graham's excellent writing. I should probably
just drink some more coffee. :)
As Graham suggests I think raising an exception is the right way to go,
along with the documentation change to reflect
I declare the voting over and empty tuple wins in a landslide. :)
I'll commit the changes shortly.
Jim
Nicolas Lehuen wrote:
+1 for the empty tuple too.
Regards,
Nicolas
2005/12/17, Jim Gallacher [EMAIL PROTECTED]:
Nicolas Lehuen (JIRA) wrote:
[
http://issues.apache.org/jira/browse
Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-98?page=comments#action_12362399 ]
Jim Gallacher commented on MODPYTHON-98:
Applied Graham's suggestions so all these related issues can be considered
fixed.
Still need
Graham Dumpleton wrote:
On 12/01/2006, at 11:10 AM, Jim Gallacher wrote:
Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-98?
page=comments#action_12362399 ] Jim Gallacher commented on
MODPYTHON-98:
Applied
)importing module 'tests'
[Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1]
accesshandler_add_handler_to_empty_hl
Regards,
Nicolas
2006/1/12, Jim Gallacher [EMAIL PROTECTED]:
Graham Dumpleton wrote:
On 12/01/2006, at 11:10 AM, Jim Gallacher wrote:
Jim Gallacher (JIRA) wrote:
[ http
Graham Dumpleton wrote:
Jim Gallacher wrote ..
It's a strange one. When I move site-packages/PIL to
site-packages/PIL.bak (leaving PIL.pth as is) and run the tests I get
the same output as Graham and Nicolas. I'm just going to ignore this for
the time being and go with a refactored unit test
A new mod_python 3.2.6 beta tarball is now available for testing.
Nicolas has built windows versions for Python 2.4 and Python 2.3 which
should also be available at www.modpython.org/dist shortly.
This release is similar to 3.2.5b but fixes a couple of issues -
MODPYTHON-95, 96, 97, 98, 99,
Good news everyone! I made a mistake in tagging 3.2.6 as beta instead of
final. The new tarball is now available for testing. This is the same
code as yesterday's 3.2.6b.tgz but with the correct version information.
This is the one we've all been waiting for! :)
Here are the rules:
In order
Michel Jouvin wrote:
0 : HP Tru64, mpm-worker
In fact 3.2.6b runs as 3.2.5b. Basically in real context it works except
the fact that after a segfault in the Apache child or a signal received
other than TERM or USR1, it doesn't reinitialize properly and forbid
proper reinitialization of the
1 - 100 of 328 matches
Mail list logo
