MapIt! 1.0
http://www.mapit.de/
MapIt! is a web-application that lets you navigate raster-maps through
your web-browser and lets you zoom in and out and select objects and
object classes that are identified on the map.
MapIt! is implemented in Python and uses the Python Imaging Library.
MapIt! is Free Software licensed under LGPL (GNU Library General Public
License).
MapIt! can be integrated with a web-server in various ways: As
CGI-script, via fast CGI (Apache and Roxen Challenger) or with
mod_python (Apache).
MapIt! runs under various Unices (e.g. Linux) and some Windows versions
(we tested with Windows 98 and NT4).
Dear all,
I created a very special server:
I'm creating a software, written in Python, to mix the
advantages of Internet (server web) and a client/server
structure. Traditional web servers use a "state-less" system,
in-fact when a browser requires some information to the server,
in the server machine will be launched a CGI, or PHP/ASP (etc...)
script and, when the request was satisfied, the connection can be
considered "terminated": the programs (maybe CGI) which
answered were terminated.
I'm creating a system in which the server launches some
threads (programs which substitute the CGI) and they remain
active until the client exits from the application or with a
time-out. I'm creating the server thinking to Macromedia Flash 5
as client (that's why I'm writing to you)
(with this software, I can create very actractive programs,
just like a beautiful and very functional graphic terminal client).
With my project I intend to join the advantages of an
Intranet/Extranet/Internet system with the advantages of a
client/server system.
One of the major targets is to simplify the server side
programming: in-fact I wish let youcreate a program with the
same technics that you use to create a local oriented software!
Of course, there are a lot of things to do,
but I installed this system in my company (a big company)
and it functions very well! Furthermore, is very simple to write
programs! (There are not the difficults that you can encounter
creating programs for standard web servers!!!)
Now the biggest problem I have, is maintain updated the
documentation!
This project is licenced under GPL.
If you are interested about my project (my server runs in a 24x7
cycle,
since it implements a dynamic loading of new modules, daemons,
server routines) please send me an e-mail or visit my site!
Thank you very much for the attention you gave me!!!
Alessandro Manotti
manotti(a)bigfoot.com
http://members.xoom.it/bypserver
This is a summary of traffic on the python-dev mailing list between
May 24 and Jun 7 (inclusive) 2001. It is intended to inform the
wider Python community of ongoing developments. To comment, just
post to python-list(a)python.org or comp.lang.python in the usual
way. Give your posting a meaningful subject line, and if it's about a
PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
iteration) All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on a
PEP if you have an opinion.
This is the ninth summary written by Michael Hudson.
Summaries are archived at:
<http://starship.python.net/crew/mwh/summaries/>
Posting distribution (with apologies to mbm)
Number of articles in summary: 305
50 | [|]
| [|]
| [|]
| [|]
40 | [|]
| [|]
| [|]
| [|] [|] [|]
30 | [|] [|] [|] [|]
| [|] [|] [|] [|]
| [|] [|] [|] [|]
| [|] [|] [|] [|]
20 | [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
0 +-018-014-011-014-020-019-034-035-032-014-008-020-051-015
Thu 24| Sat 26| Mon 28| Wed 30| Fri 01| Sun 03| Tue 05|
Fri 25 Sun 27 Tue 29 Thu 31 Sat 02 Mon 04 Wed 06
Another busy-ish fortnight. I've been in Exam Hell(tm) and am
writing this when hungover, this so summary might be a bit sketchier
than normal. Apologies in advance.
* strop vs. string *
Greg Stein leapt up to defend the slated-to-be-deprecated strop
module by pointing out that it's functions work on any object that
supports the buffer API, whereas the 1.6-era string.py only works
with objects that sprout the right methods:
<http://mail.python.org/pipermail/python-dev/2001-May/015001.html>
The discussion quickly degenerated into the usual griping about the
fact that the buffer API is flawed and undocumented and not really
well understood by many people.
* Special-casing "O" *
As a followup to the discussion mentioned in the last summary, Martin
von Loewis posted a patch to sf enabling functions written in C that
expect zero or one object arguments to dispense with the time wasting
call to PyArg_ParseTuple:
<http://mail.python.org/pipermail/python-dev/2001-May/015020.html>
The first version of the patch was criticized for being overly
general, and for not being general enough <wink>. It seems the
forces of simplicity have won, but I don't think the patch has been
checked in yet.
* the late, unlamented, yearly list.append panic *
Tim Peters posted
c.l.py has rediscovered the quadratic-time worst-case behavior of
list.append().
<http://mail.python.org/pipermail/python-dev/2001-May/015027.html>
And then ameliorated the worst-case behaviour. So that one was easy.
* making dicts ... *
You might think that as dictionaries are so central to Python that
their implementation would be bulletproof and one the areas of the
source that would be least likely to change.
This might be true *now*; Tim Peters seems to have spent most of the
last fortnight implementing performance improvements one after the
other and fixing core-dumping holes in the implementation pointed out
by Michael Hudson.
The first improvement was to "using polynomial division instead of
multiplication for generating the probe sequence, as a way to get all
the bits of the hash code into play."
<http://mail.python.org/pipermail/python-dev/2001-May/015045.html>
If you don't understand what that means, ignore it because Tim came
up with a more radical rewrite:
<http://mail.python.org/pipermail/python-dev/2001-May/015130.html>
which seems to be a win, but sadly removes the shock of finding
comments about Galois theory in dictobject.c... Most of the
discussion in the thread following Tim's patch was about whether we
need 128-bit floats or ints, which is another way of saying everyone
liked it :-) This one hasn't been checked in either.
* ... and breaking dicts *
Inspired by a post to comp.lang.python by Wolfgang Lipp and driven
slightly insane by revision, Michael Hudson posted a short program
that used a hole in the dict implementation to trigger a core dump:
<http://mail.python.org/pipermail/python-dev/2001-June/015173.html>
This got fixed, so he did it again:
<http://mail.python.org/pipermail/python-dev/2001-June/015208.html>
The cause of both problems was C code assuming things about
dictionaries remained the same across calls to code that ended up
executing arbitrary Python code, which could mutate the dict exactly
as much as it pleased, which in turn caused pointers to dangle. This
problem has a history in Python; the .sort() method on lists has to
fight the same issues.
These holes have been plugged, although it is still possible to crash
Python with exceptionally contrived code:
<http://mail.python.org/pipermail/python-dev/2001-June/015239.html>
There's another approach, which is was the .sort() method uses:
>>> list = range(10)
>>> def c(x,y):
... del list[:]
... return cmp(x, y)
...
>>> list.sort(c)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in c
TypeError: a list cannot be modified while it is being sorted
The .sort() method magically changes the type of the list being
sorted to one that doesn't support mutation while it's sorting the
list. This approach would have some merit to use with dictionaries
too; for one thing we could lose all the contrived code in
dictobject.c protecting against this sort of silliness...
* arbitrary radix formatting *
Greg Wilson made a plea for the addition of a "%b" formatting
operator to display integers in binary, e.g:
>>> print "%d %x %o %b"%(10,10,10,10)
10 a 12 1010
<http://mail.python.org/pipermail/python-dev/2001-May/015111.html>
There was general support for the idea, but Tim Peters and Greg Ewing
pointed out that it would be neater to invent a general format code
that would enable one to format an integer into an arbitrary base, so
that
>>>> int("1111", 7)
400
has an inverse at long last. But no-one could think of a spelling
that wasn't in general use, and the discussion died :-(.
* quick poll *
Guido asked if anyone would object violently to the builtin
conversion functions becoming type objects on the descr-branch:
<http://mail.python.org/pipermail/python-dev/2001-June/015256.html>
in analogy to class objects. There was general support and only a
few concerns, and the changes have begun to hit descr-branch. I'm
sure I'm not the only one who wishes they had the time to understand
what is going on in there...
Cheers,
M.
