Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

I agree that a Pygame bug tracker on the Pygame site is a priority. Trac 
looks good for that. The wiki will be useful as well. But the Trac 
subversion features will be useless with a google SVN for the web site 
development. So we will have to use whatever google offers. But I 
believe we can set it up for Pygame's SVN.


Lenard

Nirav Patel wrote:

All I have to add to this is that having real bug tracking integrated
with the SVN is a huge plus and if possible, should be put into place
as soon as possible.  That is, having Trac up on dev.pygame.org before
starting the web development work for use with both the website
project and Pygame in general would be nice.

I really dislike the Bugzilla we are currently using, and judging by
the lack of activity on it, I imagine many others do too.

Nirav

On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom  wrote:
  

Marcus von Appen wrote:


After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on
dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.


  

Keeping the web site development on a separate site, google, seem
appropriate for now. I have just been looking again at Trac and at first it
looks like a good choice. The wiki has a clean markup that accepts Python
code without mangling it. But I have two questions. One, how easy will it be
to import the existing Pygame wiki pages into Trac? Two, can we really use
the Trac with the Web SVN and Pygame SVN? (*)

Lenard

(*) I believe no to the first, yes to the second
(http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Are we already at the point where we can choose a framework? I am not 
experienced enough in this area to make a recommendation. I will look at 
them more closely. Django is favored at the new Pygame web site 
development Trac. Of major consideration is the ease with which the 
content of the existing site can be ported to the new site. I cannot 
even comment on that as I don't know how the existing site is 
implemented, though I guess Python is involved somewhere.


As for what I can contribute, I am taking this more as a learning 
opportunity than anything. I could probably write applications to port 
information and maybe convert wiki to pages if something doesn't already 
exist. But I will leave the framework stuff to others. I have also 
played around a bit with PovRay so could create some simple 3D effect 
controls like in the midi.py Pygame example.


Lenard


René Dudfield wrote:

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using 
Django?  Also what they think of a cherrypy based stack?


Also, what are the preferences of Lenard, Devon, pymike, and anyone 
else who is interested in contributing?  Please state the level of 
commitment you're willing to make, and also which option(s) you'd be 
happy using.





- The main author of cherrypy(Robert Brewer) said he'd help us with 
any major issues we had, and so did some other cherrypy mailing list 
people.  The cherrypy mailing list is also more active than the pygame 
one, so I'm sure we won't have any issues with docs or help.


- documentation is extensive for cherrypy(it's a 10 year old project, 
in it's third generation).


- we would have to choose a stack.  The stack Nicholas mentioned seems 
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy 
+ pygame of course for imaging... and joysick control of the 
website.   So that is the stack we would be chosing.


- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even 
with cherrypy(or other wsgi server).  They don't recommend using the 
bundled django webserver.  Whereas cherrypy is considered one of, if 
not the best python web servers.  With cherrypy you use the same 
webserver for development, and for production.


- you can run cherrypy inside a pygame application.  Cherrypy doesn't 
control the main loop if you don't want it to.


- there are more wsgi components than there are pinax apps.  Also 
pinax apps should theoretically be able to play with wsgi.  I'm pretty 
sure you can use django apps as wsgi components now too.

Re: [pygame] PyGame Website Rewrite

[Nirav Patel]

All I have to add to this is that having real bug tracking integrated
with the SVN is a huge plus and if possible, should be put into place
as soon as possible.  That is, having Trac up on dev.pygame.org before
starting the web development work for use with both the website
project and Pygame in general would be nice.

I really dislike the Bugzilla we are currently using, and judging by
the lack of activity on it, I imagine many others do too.

Nirav

On Sat, Apr 25, 2009 at 11:59 PM, Lenard Lindstrom  wrote:
> Marcus von Appen wrote:
>>
>> After discussing certain things with Julian, something like this might
>> make the most sense:
>>
>> SVN hosting on google.
>>
>> Trac (which I'd prefer over google's homebrewn software) on
>> dev.pygame.org.
>>
>> Why that? First of all, one of the website requirements is to have a bug
>> tracker and wiki integrated instead of having anything hosted on
>> different domains as it is at the moment.
>>
>> dev.pygame.org could act as central platform for pygame-related
>> development. Users can keep track of pygame projects, which are in a
>> planning and early development state and the trac system running there
>> can act as routing station to the different SVN repositories hosted
>> elsewhere (google, pygame, ...).
>>
>> In the long term, this also allows us to have a development wiki and bug
>> tracking already around and the only thing left to do would be to
>> integrate them seamlessly into the final pygame.org website.
>>
>> For the current time, we could redirect dev.pygame.org to Julian's
>> webserver, then, once trac is up and running on pygame.org (which should
>> be relatively easy to be realised), let it point to the local trac. That
>> way we have no dead URL mess and people do not need to visit various
>> sites (and create different accounts) just to file bugs for (either)
>> pygame project.
>>
>> We also do not have the data scattered ony google's wiki, pygame.org and
>> wherever else.
>>
>>
>
> Keeping the web site development on a separate site, google, seem
> appropriate for now. I have just been looking again at Trac and at first it
> looks like a good choice. The wiki has a clean markup that accepts Python
> code without mangling it. But I have two questions. One, how easy will it be
> to import the existing Pygame wiki pages into Trac? Two, can we really use
> the Trac with the Web SVN and Pygame SVN? (*)
>
> Lenard
>
> (*) I believe no to the first, yes to the second
> (http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
>

Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom]

Marcus von Appen wrote:

After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.

  
Keeping the web site development on a separate site, google, seem 
appropriate for now. I have just been looking again at Trac and at first 
it looks like a good choice. The wiki has a clean markup that accepts 
Python code without mangling it. But I have two questions. One, how easy 
will it be to import the existing Pygame wiki pages into Trac? Two, can 
we really use the Trac with the Web SVN and Pygame SVN? (*)


Lenard

(*) I believe no to the first, yes to the second 
(http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).

Re: [pygame] C/C++ and Python

[Jake b]

Edit your /programs/geany/data/snippets.conf

On Sat, Apr 25, 2009 at 3:49 PM, Knapp  wrote:

> >> Using an editor like Geany, you type
> >> "s" then TAB, it inserts "self."
> >>
> >> --
> >> Jake
> BTW s tab does not insert self. on my machine. Why not?


My 'python' section is:

[Python]
for=for i in xrange(%cursor%):\n\t
doc="""%cursor%"""\n
elif=elif %cursor%:\n\t
else=else:\n\t%cursor%
if=if %cursor%:\n\t
from=from %cursor% import \n
main=if __name__ == '__main__':\n\t%cursor%
class=class %cursor%(object):\n\n\tdef __init__(self):\n\t\t
def=def %cursor%(self):\n\t
get=def get_%cursor%(self): return self._\n
set=def set_%cursor%(self): self._ = \n
%dot%=self.%cursor%
s=self.%cursor%
try=try %cursor%:\n\t\nexcept ERROR:\n\t
py=#!/usr/bin/env python\n#-*- coding:utf-8 -*-\n%cursor%
while=while %cursor%:\n\t

-- 
Jake

Re: [pygame] Never seen this before

[Marius Gedminas]

On Sat, Apr 25, 2009 at 08:17:11AM -0700, Tyler Laing wrote:
> Happens to everyone. It takes time(10 years or 10,000 hours) to get
> good at something. I'm at about year 6-7 and I find while I still make
> silly mistakes, I've become much better at catching them before or
> during testing.  :)

Silly mistakes never go away.

With experience you begin to expect them and check your assumptions more
often.

There have been countless times I've written unit tests for tiny
functions that I couldn't possibly have written wrong, only to discover
that I have in fact made a silly mistake.

Marius Gedminas
-- 
I'm unaware of anyone having implemented even a fraction of H.323 in Python.
Doing so would require a special kind of dedication, and quite possibly a large
amount of whiskey and prescription medication.
-- Anthony Baxter


signature.asc
Description: Digital signature

Re: [pygame] C/C++ and Python

[Knapp]

>> Using an editor like Geany, you type
>> "s" then TAB, it inserts "self."
>>
>> --
>> Jake
BTW s tab does not insert self. on my machine. Why not?


-- 
Douglas E Knapp

Why do we live?

Re: [pygame] C/C++ and Python

[Knapp]

On Sat, Apr 25, 2009 at 8:40 AM, Jake b  wrote:
> On Wed, Apr 22, 2009 at 4:39 AM, Knapp  wrote:
>>
>> On Wed, Apr 22, 2009 at 8:23 AM, René Dudfield 
>> wrote:and have less errors in the end. I wish I did not have to type self so
>> much in python!!! C++ is much better this way
>
> Using an editor like Geany, you type
> "s" then TAB, it inserts "self."
>
> --
> Jake
>
I do use Geany, but it still looks like an explosion is a self factory. :-)


-- 
Douglas E Knapp

Why do we live?

Re: [pygame] Never seen this before

[Ian Mallett]

On Sat, Apr 25, 2009 at 8:17 AM, Tyler Laing  wrote:

> Happens to everyone. It takes time(10 years or 10,000 hours) to get good at
> something. I'm at about year 6-7 and I find while I still make silly
> mistakes, I've become much better at catching them before or during testing.
> :)

I'm at year 2, but I'm ~4000 hours...I guess I'm obsessive.  I still make
mistakes, though, obviously.

Re: [pygame] Never seen this before

[Tyler Laing]

Happens to everyone. It takes time(10 years or 10,000 hours) to get good at
something. I'm at about year 6-7 and I find while I still make silly
mistakes, I've become much better at catching them before or during testing.
:)

On Sat, Apr 25, 2009 at 8:03 AM, Yanom Mobis  wrote:

> oops. I should add that to my list of dumb bugs i find in the code i write.
> Like this one:
>
> if key[K_RIGHT]:
> spaceship.speed = spaceship.speed+10
> if key[K_RIGHT]:
> spaceship.speed = spaceship.speed-10
>
>
> :)
> --- On *Sat, 4/25/09, Tyler Laing * wrote:
>
>
> From: Tyler Laing 
> Subject: Re: [pygame] Never seen this before
> To: pygame-users@seul.org
> Date: Saturday, April 25, 2009, 9:12 AM
>
>
> Okay, I had assumed you had written your own python class, subclassing one
> of the Group classes, and had used .add within the overridden method. I've
> made that mistake myself.
>
> Looking at your code, I see the issue. For one, Group.add takes in a list
> of sprites. You are passing in three separate arguments, and Group.add is
> thinking they are each sprites.
>
> You should change
>  enemies.add(random.choice(("enemyblue.png", "enemycyan.png",
> "enemygrey.png", "enemyyellow.png")), item, enemybullets)
>
> to
> enemies.add(Enemy(random.choice(("enemyblue.png", "enemycyan.png",
> "enemygrey.png", "enemyyellow.png")), item, enemybullets))
>
>
> The super method can take a class and an object as parameters, and it will
> call the method on the superclass of the class given. It is the same as
> Basicsprite.__init__(self, img)
>
> For reference, here is the documentation about Group.add:
>
> http://www.pygame.org/docs/ref/sprite.html#Group.add
>
> -Tyler
>
> On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis 
> http://mc/compose?to=ya...@rocketmail.com>
> > wrote:
>
>> the two files for the game are attached
>>
>> --- On *Fri, 4/24/09, Brian Song 
>> http://mc/compose?to=unlucky...@gmail.com>
>> >* wrote:
>>
>>
>> From: Brian Song 
>> http://mc/compose?to=unlucky...@gmail.com>
>> >
>> Subject: Re: [pygame] Never seen this before
>> To: pygame-users@seul.org 
>> Date: Friday, April 24, 2009, 9:57 PM
>>
>>  If the problems fixed, yay.. If not, you should put up most/all your
>> source so it's easier for people to see whats happening.
>>
>>
>>
>
>
> --
> Visit my blog at http://oddco.ca/zeroth/zblog
>
>
>


-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] Never seen this before

[Yanom Mobis]

oops. I should add that to my list of dumb bugs i find in the code i write. 
Like this one:

if key[K_RIGHT]:
    spaceship.speed = spaceship.speed+10

if key[K_RIGHT]:

    spaceship.speed = spaceship.speed-10


:)
--- On Sat, 4/25/09, Tyler Laing  wrote:

From: Tyler Laing 
Subject: Re: [pygame] Never seen this before
To: pygame-users@seul.org
Date: Saturday, April 25, 2009, 9:12 AM

Okay, I had assumed you had written your own python class, subclassing one of 
the Group classes, and had used .add within the overridden method. I've made 
that mistake myself.

Looking at your code, I see the issue. For one, Group.add takes in a list of 
sprites. You are passing in three separate arguments, and Group.add is thinking 
they are each sprites. 


You should change
 enemies.add(random.choice(("enemyblue.png", "enemycyan.png", "enemygrey.png", 
"enemyyellow.png")), item, enemybullets)

to
enemies.add(Enemy(random.choice(("enemyblue.png", "enemycyan.png", 
"enemygrey.png", "enemyyellow.png")), item, enemybullets))



The super method can take a class and an object as parameters, and it will call 
the method on the superclass of the class given. It is the same as 
Basicsprite.__init__(self, img)

For reference, here is the documentation about Group.add:


http://www.pygame.org/docs/ref/sprite.html#Group.add

-Tyler

On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis  wrote:


the two files for the game are attached

--- On Fri, 4/24/09, Brian Song  wrote:


From: Brian Song 
Subject: Re: [pygame] Never seen this before
To: pygame-users@seul.org

Date: Friday, April 24, 2009, 9:57 PM

 If the problems fixed, yay. If not, you should put up most/all your source so 
it's easier for people to see whats happening.





  


-- 
Visit my blog at http://oddco.ca/zeroth/zblog




  

Re: [pygame] Re: PyGame Website Rewrite

[jug]

Hi

# need a numeric version? or save it as string?
version = models.FloatField()
the version should be a string beceause it allows for different kind
of version formats like 1.0.4

Right! I thought of sorting but sorting different projects by version
is rubbish. Better by last update or so.

I've just changed that ;)

[pygame] Re: PyGame Website Rewrite

[ab3]

# need a numeric version? or save it as string?
version = models.FloatField()
the version should be a string beceause it allows for different kind
of version formats like 1.0.4b

On Apr 23, 8:35 pm, jug  wrote:
> Hello,
>
> to organize the development process, I've set up a SVN-repo and a small
> Trac athttp://pygameweb.no-ip.org/trac/
>
> You'll find there a first concept and you can take part in developing
> it by adding your ideas. Some of the point are completely to work out,
> so just have a look. If you have a complete concept for one of the
> points (eg the design) create a new wiki page and add a link.
>
> If you would like to participate in developing, add yourself to the list
> on the start page and provide some information like I did.
>
> I've done the setup on the quick so if there are any problems with Trac
> or you need more rights, please email me.
>
> Regards,
> Jug

Re: [pygame] Never seen this before

[Marius Gedminas]

On Sat, Apr 25, 2009 at 06:33:00AM -0700, Yanom Mobis wrote:
> what does the super() function do?

It's a way to call the superclass version of the method you're
overriding.  (Technically, it's a built-in type, and not a function, but
that's an irrelevant implementation detail).

Read more about it:

 * http://www.python.org/download/releases/2.2/descrintro/#cooperation
 * http://fuhm.net/super-harmful/

Marius Gedminas
-- 
Microsoft's entry in this cavalcade of horrors is Universal Plug and Play
(UPnP).  This is a protocol that allows [...] an end-user system to request a
dynamic port-forwarding from the firewall to the box.  Many network
administrators will probably (rightly) recoil at letting applications on a
Windows box dictate firewall policy.
-- Anthony Baxter


signature.asc
Description: Digital signature

Re: [pygame] Never seen this before

[Tyler Laing]

Okay, I had assumed you had written your own python class, subclassing one
of the Group classes, and had used .add within the overridden method. I've
made that mistake myself.

Looking at your code, I see the issue. For one, Group.add takes in a list of
sprites. You are passing in three separate arguments, and Group.add is
thinking they are each sprites.

You should change
 enemies.add(random.choice(("enemyblue.png", "enemycyan.png",
"enemygrey.png", "enemyyellow.png")), item, enemybullets)

to
enemies.add(Enemy(random.choice(("enemyblue.png", "enemycyan.png",
"enemygrey.png", "enemyyellow.png")), item, enemybullets))


The super method can take a class and an object as parameters, and it will
call the method on the superclass of the class given. It is the same as
Basicsprite.__init__(self, img)

For reference, here is the documentation about Group.add:

http://www.pygame.org/docs/ref/sprite.html#Group.add

-Tyler

On Sat, Apr 25, 2009 at 6:34 AM, Yanom Mobis  wrote:

> the two files for the game are attached
>
> --- On *Fri, 4/24/09, Brian Song * wrote:
>
>
> From: Brian Song 
> Subject: Re: [pygame] Never seen this before
> To: pygame-users@seul.org
> Date: Friday, April 24, 2009, 9:57 PM
>
>  If the problems fixed, yay. If not, you should put up most/all your source
> so it's easier for people to see whats happening.
>
>
>


-- 
Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] Never seen this before

[Yanom Mobis]

the two files for the game are attached

--- On Fri, 4/24/09, Brian Song  wrote:

From: Brian Song 
Subject: Re: [pygame] Never seen this before
To: pygame-users@seul.org
Date: Friday, April 24, 2009, 9:57 PM

 If the problems fixed, yay. If not, you should put up most/all your source so 
it's easier for people to see whats happening.



  #! /usr/bin/env python

#main.py - main file for pystarfighter
print("init...")

#lvl
level1 = [(0,0), (20, 0), (40, 0), (60, 0), (80, 0), (100,0), (120,0), (140,0), (160,0), (180,0), (200,0), (220,0), (240,0)] #positions of enemies
#/lvl
import pygame, spritemodule,random #import modules
from pygame.locals import *#

screen = pygame.display.set_mode((256,256))
pygame.display.set_caption("Loading")

gameObjects = pygame.sprite.Group() #canisters
bullets = pygame.sprite.Group() #
enemybullets = pygame.sprite.Group()#
enemies = pygame.sprite.Group() #

clock=pygame.time.Clock()

weaponheat = 0

spaceship = spritemodule.Player("spaceship.png") #create player object
gameObjects.add(spaceship)   #
  
	
#colors

blue = 0,0,255
red = 255, 0, 0

green = 0, 255, 0

black = 0,0,0
white = 255,255,255
#/colors

spaceship.rect.left = 0
spaceship.rect.top = 236

pygame.display.set_caption("PyStarFighter")
print("init complete")
def setenemies_lvl1(): # put enemies on screen.
	pygame.display.set_caption("Loading Level") #tell player it's loading
	for item in level1: #loop throug coords in level file: lvl1
		enemies.add(random.choice(("enemyblue.png", "enemycyan.png", "enemygrey.png", "enemyyellow.png")), item, enemybullets)
	pygame.display.set_caption("PyStarFighter") #tell player it's done
		
def mainloop():
weaponheat = 0
while 1: # main game loop
	clock.tick(60)
	weaponheat = weaponheat - 1

   	if weaponheat < 0: weaponheat = 0 #ensure the weaponheat doesn't fall below zero

	spaceship.speed = (0,0)
	key = pygame.key.get_pressed() #create a list of keys

#keys
	if key[K_RIGHT] and spaceship.rect.left < 240:
  		spaceship.speed = (6,0)  
	if key[K_LEFT] and spaceship.rect.left > 0: 
	spaceship.speed = (-6,0)
	if key[K_SPACE] and weaponheat == 0: #shoot
		weaponheat = 60
 	bullets.add(spritemodule.Bullet("bullet.png", (0, -10)))
#/keys

	spaceship.rect= spaceship.rect.move(spaceship.speed)
	for event in pygame.event.get(): #cycle events
	if event.type == QUIT or event.type == KEYDOWN and event.key == K_ESCAPE:
			exit()

	for item in bullets: #loop through bullet canister
		if item.rect.left == 0 and item.rect.top == 0:
			item.rect.left = spaceship.rect.left  #move the bullet to the spaceship
			item.rect.top = spaceship.rect.top#
		else:
			item.rect = item.rect.move(0,-6)	
	#screen
	screen.fill(black)
	bullets.draw(screen)
	enemybullets.draw(screen)
gameObjects.draw(screen)
enemies.draw(screen)
	
	pygame.display.flip()
setenemies_lvl1()
#mainloop()
import pygame
class Basicsprite(pygame.sprite.Sprite): #create a sprite class
def __init__(self, img):
pygame.sprite.Sprite.__init__(self)
self.image = pygame.image.load(img).convert_alpha()
self.rect = self.image.get_rect()
def resetrect(self):
self.rect = self.image.get_rect()
class Player(Basicsprite): #player ship
def __init__(self, img):
Basicsprite.__init__(self, img)
def shoot():
	pass
class Bullet(Basicsprite): #bullet
def __init__(self, img, speed): #speed is a tuple that describes the direction the bullet travels.
		Basicsprite.__init__(self, img)
		self.speed=speed 
class Enemy(Basicsprite): #enemy
	def __init__(self, img, initpos, bulletcanister): #bulletcanister- the sprite canister it puts the bullets in
		Basicsprite.__init__(self, img)
		self.rect.left = initpos[0]
		self.rect.top = initpos[1]
			
	def shoot(): #shoot a bullet
		self.bulletcanister.add(Bullet("bullet.png"))

Re: [pygame] Never seen this before

[Yanom Mobis]

what does the super() function do?

--- On Fri, 4/24/09, Tyler Laing  wrote:

From: Tyler Laing 
Subject: Re: [pygame] Never seen this before
To: pygame-users@seul.org
Date: Friday, April 24, 2009, 7:58 PM

You get that kind of error when you use a recursive function, and it recurses 
down further than Python has room on the stack for. Typically, when you get 
this error, there's something wrong with your recursive function. What it 
appears to be doing is within your add function, its calling itself again. I 
think you might be wanting to call super(C, self).add(spr) where C is the class 
you created which has the add method. 


-Tyler

On Fri, Apr 24, 2009 at 5:27 PM, Yanom Mobis  wrote:


this code



level1 = [(0,0), (20, 0), (40, 0), (60, 0), (80, 0), (100,0), (120,0), (140,0), 
(160,0), (180,0), (200,0), (220,0), (240,0)] #positions of enemies
#yatta yatta
def setenemies_lvl1(): # put enemies on screen.

    pygame.display.set_caption("Loading Level") #tell player it's loading
    for item in level1: #loop throug coords in level file: lvl1
        enemies.add(random.choice(("enemyblue.png", "enemycyan.png", 
"enemygrey.png", "enemyyellow.png")), item, enemybullets)

    pygame.display.set_caption("PyStarFighter") #tell player it's done




is causing this problem:





  File "/usr/local/lib/python2.6/site-packages/pygame/sprite.py", line 325, in 
add

    self.add(spr)

 
 alot of the same message

  File "/usr/local/lib/python2.6/site-packages/pygame/sprite.py", line 316, in 
add
    if isinstance(sprite, Sprite):
RuntimeError: maximum recursion depth exceeded while calling a Python object









  


-- 
Visit my blog at http://oddco.ca/zeroth/zblog




  

Re: [pygame] PyGame Website Rewrite

[Evan Kroske]

jug wrote:


One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.


Unless I misunderstood, everybody was saying that someone should create 
a subdomain with the server administrator tools and simply run Django 
from there. I don't think they want Django running in the top-level web 
directory and creating a dev subdomain. If you're saying that Django 
can't be confined to a single directory and that it must be run from the 
top-level web directory, I have nothing to add.


Regards,
Evan Kroske

Re: [pygame] PyGame Website Rewrite

[sheepjxx]

Intresting, I just start to study Django, I think it is really a
nice tools.

--
From: "jug" 
Sent: Saturday, April 25, 2009 9:26 PM
To: 
Subject: Re: [pygame] PyGame Website Rewrite


There's one problem remaining. One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.
To concretize, please specify the structure again. What would Trac be
used for? Replace the current wiki and add a ticket system for bug-tracing
and more (enhancements, etc)?
So, the rough structure would be

Django
 - News
 - Flatpages
 - Projects
Trac
 - Wiki
 - Ticket system
 - code browser
 - (maybe more?)

I'm going to test the django-trac thing today. If we use now my Trac 
please
try to keep the concept up to date and edit it with our discussion 
results.


- Jug

Re: [pygame] PyGame Website Rewrite

[jug]

There's one problem remaining. One of the few weaknesses of Django
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.
To concretize, please specify the structure again. What would Trac be
used for? Replace the current wiki and add a ticket system for bug-tracing
and more (enhancements, etc)?
So, the rough structure would be

Django
 - News
 - Flatpages
 - Projects
Trac
 - Wiki
 - Ticket system
 - code browser
 - (maybe more?)

I'm going to test the django-trac thing today. If we use now my Trac please
try to keep the concept up to date and edit it with our discussion results.

- Jug

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

Marcus von Appen wrote:

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

  
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.



Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus
  

In full:
"""
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.


*As time permits I might* be able to help somewhat if a CherryPy stack 
is used.


I personally much prefer CherryPy + Co over what I have seen of Django 
*but I doubt I'll be contributing much compared to others.*"""



I actually took time out  of my day to argue the case for using Django.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

I'm actually for you guys using Django.

"""
If most of the people that are motivated to do the work already have experience
with Django I think it would just be more work for all involved using a custom
CherryPy stack.

Contributors would have to follow the evolving `framework`. They'd have to spend
time documenting it if they wanted to make it easy for more people to
contribute. They'd likely waste time arguing over the best ways of doing things
and which components to use. Would it ever get done? Or would everyone just get
sick of it?

For an opensource project with potentially quite a few people working on it (The
more the better right?) then I'd say Django would be a good fit due to the
`free` unified documentation and resources surrounding it and the fact that
every one is on the same page.
"""

On Sat, Apr 25, 2009 at 8:52 PM, jug  wrote:
> Hello,
>
> I'm kinda amazed about some points:
>
> 1) Did anyone read my concept?
>   Some of the discussed ideas here I had before but no one cared.
>
> 2) I created a trac an you said "nice!" and created a Google project.
>
> 3) This project was an gsoc candidate and AFAIK all applicants wanted
>   to use Django. At least 2 of them (Orcun and me) would like to do it
>   even without google. Now you say "let's do it with cherrypy" because
>   you don't know Django. Hm. I my view, both - Django and cherrypy -
>   are mighty enough for our needs, thus its a relig. question of faith. But
> you
>   asked so to do it. So, here we are! We have time and (only) want to do it
>   with Django, cause we don't know cherrypy as you don't know Django.
>   Maybe here are some php-experts why do it with php?
>
> 4) Even if you don't know Django, you can participate by helping to develop
>   the concept, writing specific requirements, care about design, read the
>   old code, transfer it and write new templates (Django templates are really
>   easy to learn). If we use Trac the way things are going, there will be
> some
>   work on adapting it by editing the Trac templates and style to make it fit
>   into the whole page. Then, care about plugins that could be useful or
>   necessary (auth, notification, feeds, irc-announcer, ...). Be sure you can
> help
>   us even when using Django for the backend.
>
> Regards
> Jug
>
> PS, well, I'm a slow writer, so I agree with Marcus.
>
>
>

Re: [pygame] PyGame Website Rewrite

[jug]

Hello,

I'm kinda amazed about some points:

1) Did anyone read my concept?
   Some of the discussed ideas here I had before but no one cared.

2) I created a trac an you said "nice!" and created a Google project.

3) This project was an gsoc candidate and AFAIK all applicants wanted
   to use Django. At least 2 of them (Orcun and me) would like to do it
   even without google. Now you say "let's do it with cherrypy" because
   you don't know Django. Hm. I my view, both - Django and cherrypy -
   are mighty enough for our needs, thus its a relig. question of 
faith. But you
   asked so to do it. So, here we are! We have time and (only) want to 
do it

   with Django, cause we don't know cherrypy as you don't know Django.
   Maybe here are some php-experts why do it with php?

4) Even if you don't know Django, you can participate by helping to develop
   the concept, writing specific requirements, care about design, read the
   old code, transfer it and write new templates (Django templates are 
really
   easy to learn). If we use Trac the way things are going, there will 
be some
   work on adapting it by editing the Trac templates and style to make 
it fit

   into the whole page. Then, care about plugins that could be useful or
   necessary (auth, notification, feeds, irc-announcer, ...). Be sure 
you can help

   us even when using Django for the backend.

Regards
Jug

PS, well, I'm a slow writer, so I agree with Marcus.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

  
I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.



Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus
  
"Happy programmers are motivated and *productive* programmers" I meant 
to write but I had a brain malfunction.

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

Marcus von Appen wrote:

Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.
  
I am in complete agreeance.  Happy programmers are motivated and 
programmers./

/

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Sat Apr 25, 2009, Nicholas Dudfield wrote:

> I doubt I'd be contributing in any form whatsoever if Django is used.  I 
> have no real interest in learning it.
> 
> If Robert Brewer has personally promised assistance that would be a very 
> good case for using CherryPy.

Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.

If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).

Regards
Marcus


pgpeybUYTDnYX.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[Marcus von Appen]

On, Fri Apr 24, 2009, Rene Dudfield wrote:

[...]

> >
> >  Also, is it possible to do this at google code instead?
> >>http://code.google.com/p/pygame/
> >>
> >
> > Sounds reasonable - google already has the whole functionality for the
> > project,
> > Julian currently hosts privately. It might be good to use google's wiki
> > there
> > and a seperate website SVN branch. Especially since the final system could
> > be
> > adopted by other community-driven projects.
> >
> >
> Also lots of people already have google accounts on there, and it's not
> hosted on someones personal server.
> 
> Keeping it separate from the main pygame svn makes sense, since it's
> probably going to be a separate group of people, and also it's fairly easy
> to allow access to it.

After discussing certain things with Julian, something like this might
make the most sense:

SVN hosting on google.

Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.

Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.

dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).

In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.

For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.

We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.

Regards
Marcus


pgpcQIJeqnXnQ.pgp
Description: PGP signature

Re: [pygame] PyGame Website Rewrite

[Nicholas Dudfield]

I doubt I'd be contributing in any form whatsoever if Django is used.  I 
have no real interest in learning it.


If Robert Brewer has personally promised assistance that would be a very 
good case for using CherryPy.


As time permits I might be able to help somewhat if a CherryPy stack is 
used.


I personally much prefer CherryPy + Co over what I have seen of Django 
but I doubt I'll be contributing much compared to others.

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using 
Django?  Also what they think of a cherrypy based stack?


Also, what are the preferences of Lenard, Devon, pymike, and anyone 
else who is interested in contributing?  Please state the level of 
commitment you're willing to make, and also which option(s) you'd be 
happy using.





- The main author of cherrypy(Robert Brewer) said he'd help us with 
any major issues we had, and so did some other cherrypy mailing list 
people.  The cherrypy mailing list is also more active than the pygame 
one, so I'm sure we won't have any issues with docs or help.


- documentation is extensive for cherrypy(it's a 10 year old project, 
in it's third generation).


- we would have to choose a stack.  The stack Nicholas mentioned seems 
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy 
+ pygame of course for imaging... and joysick control of the 
website.   So that is the stack we would be chosing.


- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even 
with cherrypy(or other wsgi server).  They don't recommend using the 
bundled django webserver.  Whereas cherrypy is considered one of, if 
not the best python web servers.  With cherrypy you use the same 
webserver for development, and for production.


- you can run cherrypy inside a pygame application.  Cherrypy doesn't 
control the main loop if you don't want it to.


- there are more wsgi components than there are pinax apps.  Also 
pinax apps should theoretically be able to play with wsgi.  I'm pretty 
sure you can use django apps as wsgi components now too.

Re: [pygame] PyGame Website Rewrite

[René Dudfield]

Hi,

very detailed emails from Marcus and Nicholas...

a few related points below.


I'd be interested in knowing what jug, and orcun think of using Django?
Also what they think of a cherrypy based stack?

Also, what are the preferences of Lenard, Devon, pymike, and anyone else who
is interested in contributing?  Please state the level of commitment you're
willing to make, and also which option(s) you'd be happy using.




- The main author of cherrypy(Robert Brewer) said he'd help us with any
major issues we had, and so did some other cherrypy mailing list people.
The cherrypy mailing list is also more active than the pygame one, so I'm
sure we won't have any issues with docs or help.

- documentation is extensive for cherrypy(it's a 10 year old project, in
it's third generation).

- we would have to choose a stack.  The stack Nicholas mentioned seems
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy +
pygame of course for imaging... and joysick control of the website.   So
that is the stack we would be chosing.

- cherrypy code seems cleaner... as it's just python objects.

class MySite(object):
def index(self):
return "hello world!"

def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)

index.exposed = True
news.exposed = True

This creates these urls by default:
/
/index
/news
/news/10
/news?id=10


- cherrypy has less code compared to django, and is changing less.

- django is usually run using apache modpython or mod_wsgi, or even with
cherrypy(or other wsgi server).  They don't recommend using the bundled
django webserver.  Whereas cherrypy is considered one of, if not the best
python web servers.  With cherrypy you use the same webserver for
development, and for production.

- you can run cherrypy inside a pygame application.  Cherrypy doesn't
control the main loop if you don't want it to.

- there are more wsgi components than there are pinax apps.  Also pinax apps
should theoretically be able to play with wsgi.  I'm pretty sure you can use
django apps as wsgi components now too.










On Sat, Apr 25, 2009 at 3:51 PM, Nicholas Dudfield wrote:

>
> > I do not know anything about cherrypy, so here're some relevant
> > questions for both frameworks:
> >
> > * How good is the integration of a wiki solution and maybe bug tracking
> >   system without implementing it ourselves?
> > * How good is the integration of other components, which might be
> >   necessary in the future?
> > * How much effort has to be put into it to add new features? Is it just
> >   about adding/enabling a component or writing a whole bunch of code?
> > * What is the key difference between cherrypy (denoted as HTTP
> >   framework) and Django (web framework)?
> >
> >
> I have a little bit of experience with CherryPy and a tiny tiny bit of
> experience with Django. Here is my 2.0 cents.
>
> A while back I read a considerable amount about python frameworks before
> choosing CherryPy
>
> I say I chose CherryPy but that wasn't really the case. That choice was
> made for
> me. I did however choose further components to extend CherryPy with after
> becoming frustrated with `raw` CherryPy and a `raw` DB2 api.
>
> Making pages by concatenating strings is horrible and very resistant to
> change.
> You really want a templating system of some sort where you can integrate
> designers changes nicely or have them do it themselves (concurrently)
>
> You also want to be able to apply any special features your editor has for
> editing html.  Even PHP is better in this respect than `raw` CherryPy for
> anything beyond a `Hello World` toy site.
>
> Enter overwhelming array of choices.  Then you have to find a way of
> integrating
> the templating system with CherryPy.
>
> You'll find you want an ORM/query builder soon enough as writing your own
> (again
> using string building, you just want a small simple one) proves to be
> distracting. Any time you want a feature requiring something beyond your
> home-
> baked lib you have to code something up and write tests for it.
>
> Form handling? Do you want to write a form validation library? No? Spend
> some
> time searching for a good one *with a future*. Pagination? Email? I
> literally
> copy/pasted then modified the code from Django for the latter two.
>
> In short, you end up writing an ad-hoc glue framework on top of CherryPy.
> With
> just one person working on it, you can get away without writing a heap of
> tests
> and documentation. With multiple people working on it you'd really need to
> to
> make sure everyone is on the same page.
>
> Choosing CherryPy won't just be a matter of choosing it and running with
> it,
> it'll also be a matter of choosing more components, how to integrate them
> and
> documenting it.
>
> An advantage of doing it this way, not to be understated, is that you'll
> learn
> how to use those components individually and can apply them elsewhere.
>