pycs-devel Mailing List for Python Community Server (Page 10)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

Quick note - I've been away for a few weeks, but am back now, and will
be checking out what's wrong with pycs.net asap.

Cheers,
Phil

anyone here using radio?  it seems to me that most of the pycs.net
users these days are using pyds or bzero, but it would still be good
to test this update against pycs ...

cheers,
phil

----- Forwarded message from Lawrence Lee <law...@us...> -----

To: rad...@ya...
From: Lawrence Lee <law...@us...>
Subject: [radio-dev] Beta: Radio comment moderation and other improvements

We're working on a set of changes in Radio: a new Radio comment moderation
feature, improvements to upstreaming and comment/TrackBack counters files.
Before we do a general release, we'd like your help testing the new
features, and would appreciate your feedback.

*** Changes

Radio comment moderation support has been added where you can delete
comments posted to your weblog.

Radio now uses a single counter file for both comments and TrackBack pings
for your weblog instead of having to request two seperate files.

Radio can also tell the server which posts are on the page so Radio only
returns the comment and TrackBack counts for those posts. Since these are
guaranteed to be sequential for a given blog, the server only needs to
return counts for the posts in the sequence, not counts for all posts for
all-time

Added a Last-Modified HTTP header so browsers which understand the header
(and almost all do) should only request the comment counter for a given page
once. And ETag/If-None-Match for the counters. This means that for a given
client, the server will only have to rebuild the JavaScript for a given page
the first time it's loaded, or when the count changes

Upstreaming now watches for TCP/IP errors and Radio will retry upstreaming a
file if it fails on the first attempt.

*** How to test

1. Download this file and import it into Radio using the Open command in
Radio's File menu:

http://lawrence.userland.com/radioParts/radioOct2004Beta1.fttb

2. In the QuickScript window (Ctrl-;), run the following script:

workspace.radioOct2004beta1.installer ()

3. Testing comment moderation:

At the bottom of each comment window, there is a new Moderate field where
you can enter in your Radio usernum password. Click the Go button and the
window will refresh with checkboxes beside each comment and a Delete Checked
Commments button. When you are finished deleting any comments, click the
Stop Moderating link to sign out.

Upstreaming changes:

If you notice any TCP/IP upstreaming errors in the Events Log page, check if
Radio later retries upstreaming the file.

4. Send an email to the radio-dev list letting us know that it worked, or if
it didn't work, what happened.

If you need to remove the beta parts, you can run the following command in a
QuickScript command to restore the original parts (prior to installing of
the beta parts):

workspace.radioOct2004beta1.installer (true)

Thanks!
Lawrence

Hi!

My blog today reached the 2 GB bytes upstreamed limit. And so PyCS 
didn't allow me to upstream anything any more due to a TypeError. I 
patched that part so it now starts from 0 if you reach 2 GB :-)

bye, Georg

Urgh, looks bad.  I can update at the moment though, so I guess it was
a transient problem.

I'll set up a chrooted CVS repository on my server sometime and we can
move over to that one then ...

Cheers,
Phil

On Sat, Sep 11, 2004 at 12:00:56AM +0200, Georg Bauer wrote:
> Hi!
> 
> I just wanted to check the CVS tree because Thomas Klaeger wants to 
> send in a patch, and I get the following:
> 
> www-pycs@simon:~/src/pycs$ cvs update -d
> gb...@cv...'s password:
> Cannot access /cvsroot/pycs/CVSROOT
> No such file or directory
> 
> Looks like it's borked again, or did they just change something?
> 
> bye, Georg
> 

Hi,

I've just set up a mailing list for bzero.  There are now enough users
that it might make sense, and it would be cool to get everyone
together a bit.  There are lots of discussions I've had with
individuals that would benefit from being shared with the other bzero
users.

If you use bzero, and want to be part of it, put your e-mail address
in the form on this page and click 'subscribe':

        http://www.myelin.co.nz/bzero/

It's a qmail/ezmlm mailing list, i.e. pretty unfriendly to spammers.
Not publicly archived, so your e-mail address will only be visible to
me and the other list members (when there are some!).

Cheers,
Phil :)

I've poked around a bit more and another possibility is ZODB. It can be 
used either as a multi-process database or a multi-threaded single file.

I don't know the internals of PyCS, but it would require a couple of 
changes in PyDS. The biggest change is that ZODB stores Python objects, 
not just class-free database rows. Overall, I think this would be a good 
change anyhow.

It looks to me like you'd need to replace current Metakit functionality 
with an object that would probably sub-class a BTree 
(http://zope.org/Wikis/ZODB/FrontPage/guide/node6.html#SECTION000630000000000000000) 
and also index by other interesting attributes, probably with a simple 
dict (at least for PyDS, PyCS may need other BTrees).

http://zope.org/Wikis/ZODB/FrontPage/guide/index.html
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html

> >I'm seriously considering moving PyCS over to MySQL or Postgres
> 
> As long as you write a migration script that's fine. And as long as you 
> use PostgreSQL or write it database independend, as I currently don't 
> run MySQL on simon.bofh.ms ;-)

Yeah - Postgres was my first choice anyway :)

The migration script will be the first thing I do ... I have a server
to transition too!

Cheers,
Phil :)

>Another problem with SQLite is, it only handles one writer while
>allowing multiple readers. That's the same as with Metakit (ok, you can
>have multiple database connections with one writer each, but that will
>end in file locking if I understand it's architecture correctly).

As far as I know, SQLite cannot handle multiple "writer" connections. My
understanding is that it is a single writer, supporting multiple readers; as
is metakit, I presume. SQLite has a small footprint, supports standard SQL,
and is easily extensible via C or C++. Ideal for embedded systems, personal
dbms, single user applications. I think it is the open source equivalent of
Microsoft's MSAccess without the builtin forms, reports, etc.

It has all the features of a robust database such as transaction
commit/rollback, lock resolution, etc.; but is not intended as a
transactional, multi-user dbms. That's where MySQL and Postgress come in.
For PyDS, I would suggest implementing with SQLite, initially, and building
on a port that supports other sql databases, such as is done by Roundup
http://roundup.sourceforge.net/doc-0.7/features.html, an issue management
solution written in Python, supporting multiple database implementations.

\louis

Hi!

> If you're porting databases for PyDS, I'd love to see `DB-API2`_ used 
> so we
> can put PyDS on any [relational] database we need to. If you want a 
> more
> Pythonic abstraction to work with, SQLObject_ is nice. I must admit, 
> I've

For PyDS that actually would be the way to go, as SQLObject gives me 
some abstraction in the way I have now with Metakit. I don't know 
wether it's really the right way for PyCS, though. I think it should 
directly use DBAPI and I think it should go to a full blown SQL server, 
not SQLite (although that would stay an option because of DBAPI) 
because of the higher load on those systems. Both muensterland.org and 
pycs.net get quite a big whip of traffic every day and I think a 
separate SQL server is in order there.

Another problem with SQLite is, it only handles one writer while 
allowing multiple readers. That's the same as with Metakit (ok, you can 
have multiple database connections with one writer each, but that will 
end in file locking if I understand it's architecture correctly). One 
thing that is problematic with the current PyCS is it's blocking 
nature, as all extensions are run in the main thread. Maybe it would be 
a good idea to port over PyCS modules to TooFPy to get multiple thread 
handlers for dynamic stuff (you keep the single threaded 
highperformance medusa engine for static stuff with TooFPy!).

bye, Georg

Hi!

> (I would imagine PyCS would still want MySQL or Postgres, truthfully, 
> but it is worth a look. PyDS might be a better fit with SQLite. I 
> *like* being able to backup my PyDS just by shutting it down and 
> copying some files. I think SQLite should retain that, it isn't so 
> easy for MySQL.)

Yes, PyDS is a different beast. I don't think I will use a full blown 
SQL database for that one. I am not too happy with SQLite, too, as it's 
SQL is sometimes rather weird, but since rewriting PyDS to another 
database is definitely a bigger project, I am a bit reluctant to start 
that :-)

So PyDS stays with Metakit for now, but I think I will change in the 
long run. I am just not sure which way to go and when to do it.

bye, Georg

Hi!

> I'm seriously considering moving PyCS over to MySQL or Postgres
> (probably the latter, b/c the license fits better).  Georg -
> would you mind if I did something like that?

As long as you write a migration script that's fine. And as long as you 
use PostgreSQL or write it database independend, as I currently don't 
run MySQL on simon.bofh.ms ;-)

Actually I am not that  happy with Metakit, too. I think it is 
responsible for some weird lockups/segfaults I have from time to time 
and we do have reports of data corruption from users.

bye, Georg

Note that I'm talking about PyCS here, not PyDS -- I don't know if it
would make sense to port PyDS to a server-based DB.  SQLite might make
sense.  This is Georg's domain anyway ;)

If I do change PyCS, of course I'll use the DB API, so porting between
SQL DBs should be possible.  Every DB has its own interpretation of
the SQL standard though, so it might not always be _easy_.

Cheers,
Phil

On Wed, Jul 07, 2004 at 10:46:13AM +1000, Garth T Kidd wrote:
> If you're porting databases for PyDS, I'd love to see `DB-API2`_ used so we
> can put PyDS on any [relational] database we need to. If you want a more
> Pythonic abstraction to work with, SQLObject_ is nice. I must admit, I've
> never been that crash hot on Metakit. :| 
> 
> .. _DB-API2: http://www.python.org/peps/pep-0249.html
> .. _SQLObject: http://www.sqlobject.org/

You could use a data dictionary approach, where everything ends up in four
tables: two dictionary tables, and two content tables. The schema tables are
tablename and tablename/attributename/attributespec, and the data tables are
table/id and table/id/attribute/value. To add or remove logical tables or
columns, just alter the schema tables and add or remove items appropriately
from the data tables. It's still possible to write fast SQL for updates,
too. 

-----Original Message-----
From: pyd...@mu...
[mailto:pyd...@mu...] On Behalf Of Phillip Pearson
Sent: Wednesday, 7 July 2004 11:08 AM
To: Jeremy Bowers
Cc: Yasushi Iwata; pyd...@mu...;
pyc...@li...
Subject: [Pyds-dev] sqlite vs postgres / mysql / metakit

Hmm - just noticed that SQLite doesn't do ALTER TABLE.  That's
unfortunate... it's not that big a deal, but it makes development
annoying...

Cheers,
Phil

_______________________________________________
Pyds-dev mailing list
Pyd...@mu...
http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev

If you're porting databases for PyDS, I'd love to see `DB-API2`_ used so we
can put PyDS on any [relational] database we need to. If you want a more
Pythonic abstraction to work with, SQLObject_ is nice. I must admit, I've
never been that crash hot on Metakit. :| 

.. _DB-API2: http://www.python.org/peps/pep-0249.html
.. _SQLObject: http://www.sqlobject.org/

-----Original Message-----
From: pyd...@mu...
[mailto:pyd...@mu...] On Behalf Of Phillip Pearson
Sent: Wednesday, 7 July 2004 9:01 AM
To: Yasushi Iwata
Cc: pyd...@mu...; pyc...@li...
Subject: Re: [Pyds-dev] Re: [PyCS-devel] Re: Maybe problems with Metakit
2.4.9.3

Argh - that would explain some of the trouble I've been having recently with
comments in PyCS.  I have implemented some pycsadm functions to allow
renumbering of comments, but they seem to randomly shift other comments
around in the process - pretty scary.  This is in MK 2.4.9.2, btw.

I'm seriously considering moving PyCS over to MySQL or Postgres (probably
the latter, b/c the license fits better).  Georg - would you mind if I did
something like that?

Cheers,
Phil

On Thu, Apr 22, 2004 at 04:48:08PM +0900, Yasushi Iwata wrote:
> Hi,
> 
> On Thu, 22 Apr 2004 08:31:18 +0200 you wrote:
> 
> > Did you try his suggestion? I think I had problems with something 
> > like this before - I used None or [] or something like this for an 
> > empty subview and Metakit didn't like that. So it might be something 
> > that depends on your Metakit version installed. It would be great if 
> > you could do some tests here.
> 
> Yes, I tried using [] to create an empty subview. It worked without 
> causing segmentation fault.
> 
> But about an hour ago, I found that the problem still exists.
> 
>   http://www.equi4.com/pipermail/metakit/2004-April/001805.html
> 
> _______________________________________________
> Pyds-dev mailing list
> Pyd...@mu...
> http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev

_______________________________________________
Pyds-dev mailing list
Pyd...@mu...
http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev

Hmm - just noticed that SQLite doesn't do ALTER TABLE.  That's
unfortunate... it's not that big a deal, but it makes development
annoying...

Cheers,
Phil

> You might consider SQLite. I've never used it so I can't recommend it 
> per se, but it is closer to Metakit in that you can open files yourself 
> for databases, rather than having to use the system DB.
> 
> (I would imagine PyCS would still want MySQL or Postgres, truthfully, 
> but it is worth a look. PyDS might be a better fit with SQLite. I *like* 
> being able to backup my PyDS just by shutting it down and copying some 
> files. I think SQLite should retain that, it isn't so easy for MySQL.)

Good idea.  Do you know what SQLite's memory consumption is like?  I'm
not happy with the amount of memory my PyCS processes are using up at
the moment on my server, and suspect that MK has a lot to do with it.

Here are my reasons for switching:

- MK uses too much memory.

- MK is single user; I can't play with the DB without shutting down
PyCS.  [it looks like SQLite might let me do this too].

- I don't trust MK not to lose data.

- The MK file is hard to inspect - I have to either download it onto
another machine or write code to access it.

If I can get rid of these problems using SQLite, then it would
probably be a better choice than MySQL or Postgres as you still
wouldn't need to install a separate DB to get PyCS running.

Cheers,
Phil

Phillip Pearson wrote:
 > Argh - that would explain some of the trouble I've been having
 > recently with comments in PyCS.  I have implemented some pycsadm
 > functions to allow renumbering of comments, but they seem to randomly
 > shift other comments around in the process - pretty scary.  This is in
 > MK 2.4.9.2, btw.
 >
 > I'm seriously considering moving PyCS over to MySQL or Postgres
 > (probably the latter, b/c the license fits better).  Georg -
 > would you mind if I did something like that?

You might consider SQLite. I've never used it so I can't recommend it 
per se, but it is closer to Metakit in that you can open files yourself 
for databases, rather than having to use the system DB.

(I would imagine PyCS would still want MySQL or Postgres, truthfully, 
but it is worth a look. PyDS might be a better fit with SQLite. I *like* 
being able to backup my PyDS just by shutting it down and copying some 
files. I think SQLite should retain that, it isn't so easy for MySQL.)

Argh - that would explain some of the trouble I've been having
recently with comments in PyCS.  I have implemented some pycsadm
functions to allow renumbering of comments, but they seem to randomly
shift other comments around in the process - pretty scary.  This is in
MK 2.4.9.2, btw.

I'm seriously considering moving PyCS over to MySQL or Postgres
(probably the latter, b/c the license fits better).  Georg -
would you mind if I did something like that?

Cheers,
Phil

On Thu, Apr 22, 2004 at 04:48:08PM +0900, Yasushi Iwata wrote:
> Hi,
> 
> On Thu, 22 Apr 2004 08:31:18 +0200 you wrote:
> 
> > Did you try his suggestion? I think I had problems with something like 
> > this before - I used None or [] or something like this for an empty 
> > subview and Metakit didn't like that. So it might be something that 
> > depends on your Metakit version installed. It would be great if you 
> > could do some tests here.
> 
> Yes, I tried using [] to create an empty subview. It worked without
> causing segmentation fault.
> 
> But about an hour ago, I found that the problem still exists.
> 
>   http://www.equi4.com/pipermail/metakit/2004-April/001805.html
> 
> _______________________________________________
> Pyds-dev mailing list
> Pyd...@mu...
> http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev

Here is a casino giving away $25 Free when you sign up an account.
No credit card required
http://acecasino.cls2.org/iwin.html

James

On Fri, 4 Jun 2004 08:36:18 +0200 you wrote:

> Yasushi reported problems with the latest Metakit (2.4.9.3) that lead 
> to corrupted databases. He had those problems with both his PyCS 
> installation and his PyDS installation.

Yes. I tried to use PyCS with Metakit 2.4.9.3. When I inputed comment
to my blog I got Segmentation fault in PyCS. But settigs.dat was not
broken. PyCS works no problem when I changed Metakit version to
2.4.9.2.

Hi!

> I'm running it with the latest MetaKit and Python 2.3, which MK seems
> to require now.  Is this safe?  I remember some mention of it being a
> bit dodgy a while ago.  Georg?

Yasushi reported problems with the latest Metakit (2.4.9.3) that lead 
to corrupted databases. He had those problems with both his PyCS 
installation and his PyDS installation.

bye, Georg

Hi guys,

Just a note to say that I've moved pycs.net to another server -- so if
you see anything weird happening, drop me a line.

I'm running it with the latest MetaKit and Python 2.3, which MK seems
to require now.  Is this safe?  I remember some mention of it being a
bit dodgy a while ago.  Georg?

I found earlier that it was sucking up a huge amount of RAM, so I'm
running it under ulimit and with a script to restart it when it exits.
Let's see how this works...

Cheers,
Phil :)

Here is a casino giving away $25 Free when you sign up an account.
No credit card required
casino.cls2.org/iwin.html

James

Hi!

> One day we should put it somewhere else.  SF is good for me right now,
> but I'm open to suggestions.  Can you do cvs-over-ssh with key
> authorization on simon?

Sure. That's what I am doing. The only thing I would need to do is giving
out shell accounts on simon. Maybe set up something that limits those shell
accounts somehow, so you can't break the system, but since it's currently
only limited numbers of developers, I would have no problems to set up
standard user accounts as a first step.

bye, Georg

> Again problems with CVS on Sourceforge. I get the attached message when
> trying to commit a change to CVS for PyCS. Did they change something, or is
> their CVS down again?

Heh, it's probably broken again.

I haven't moved the repository or anything.  Lots of things are broken
on SF though; I think the repository tarball export hasn't been
working for a bit either ... !

One day we should put it somewhere else.  SF is good for me right now,
but I'm open to suggestions.  Can you do cvs-over-ssh with key
authorization on simon?

Cheers,
Phil

2002	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug (2)	Sep (3)	Oct (1)	Nov (70)	Dec (41)
2003	Jan (20)	Feb (9)	Mar (36)	Apr (11)	May (3)	Jun (6)	Jul (3)	Aug (13)	Sep (2)	Oct (32)	Nov (4)	Dec (7)
2004	Jan (14)	Feb (16)	Mar (3)	Apr (12)	May (1)	Jun (4)	Jul (13)	Aug (1)	Sep (2)	Oct (1)	Nov (2)	Dec (3)
2005	Jan (7)	Feb	Mar	Apr (4)	May	Jun (2)	Jul	Aug (5)	Sep	Oct	Nov (2)	Dec (1)
2006	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug (1)	Sep (2)	Oct (7)	Nov (18)	Dec (22)
2007	Jan (10)	Feb (11)	Mar (1)	Apr (6)	May (5)	Jun (5)	Jul (14)	Aug (28)	Sep (4)	Oct (6)	Nov (9)	Dec (8)
2008	Jan (10)	Feb (19)	Mar (38)	Apr (17)	May (13)	Jun (7)	Jul (36)	Aug (15)	Sep (2)	Oct	Nov	Dec

pycs-devel Mailing List for Python Community Server (Page 10)

pycs-devel — Python Community Server development/chat