From hpk at trillke.net  Tue Sep  6 22:02:20 2005
From: hpk at trillke.net (holger krekel)
Date: Tue, 6 Sep 2005 22:02:20 +0200
Subject: [py-dev] error building greenlets
In-Reply-To: <20050831124506.GA20768@code1.codespeak.net>
References: <1124903690.18767.440.camel@borgia>
	<200508242331.57666.alain.poirier@net-ng.com>
	<20050827163954.GC4270@code1.codespeak.net>
	<200508281508.56861.alain.poirier@net-ng.com>
	<20050829095301.GA24462@code1.codespeak.net>
	<B8F13DC0-1202-41A0-B43A-8E8CEBA080D9@redivi.com>
	<20050831124506.GA20768@code1.codespeak.net>
Message-ID: <20050906200220.GT666@solar.trillke.net>

Hi Armin, 

On Wed, Aug 31, 2005 at 14:45 +0200, Armin Rigo wrote:
> On Tue, Aug 30, 2005 at 01:55:29PM -0700, Bob Ippolito wrote:
> > It's especially unimportant for the greenlet extension module, of  
> > course, because you'd have to compile it statically into Python with - 
> > mdynamic-no-pic in order for it to matter.
> 
> Ok, so I guess I will remove "ebx" from the Unix PC include file and
> "r31" from both the MacOSX and Unix PPC target -- is that right?

i went ahead and removed ebx from switch_x86_unix.h which indeed
seems to make things work again on recent gcc versions. I did
not change other files. 

cheers, 

    holger


From tom at livelogix.com  Thu Sep 15 18:47:04 2005
From: tom at livelogix.com (Tom Locke)
Date: Thu, 15 Sep 2005 17:47:04 +0100
Subject: [py-dev] Binary distribution (Windows)
Message-ID: <4329A588.6010305@livelogix.com>

Hi,

It's a great pain having to install the Microsoft C compiler on each 
machine where I want greenlets.

I can't figure out how to move the compiled module across in binary 
form. If I copy the greenlet.pyd, it just gets deleted and py tries to 
compile greenlet.c anyway.

Help!

Tom.



From ianb at colorstudy.com  Mon Sep 19 17:30:24 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 19 Sep 2005 10:30:24 -0500
Subject: [py-dev] py.test and unittest; TestGears and TestOOB
Message-ID: <432ED990.5020704@colorstudy.com>

Hi - I should preface this saying that I'm proposing work without 
offering help, so read as you will ;)

Anyway, I think I mentioned before that setuptools has had some 
unittest-specific support added to it, and the possibility that py.test 
could produce test suites.  PJE also wrote this post describing 
unittest's architecture: 
http://dirtsimple.org/2005/08/ruby-gems-python-eggs-and-beauty-of.html

This made me think that the unittest architecture is still workable, 
irregardless of any particular code in unittest.py.  And py.test even 
seems fairly close to unittest, internally -- Item vs. TestCase, 
Collector vs. TestSuite, etc.

I thought I'd also point out that there's a couple new test systems that 
stick to unittest, and offer some portion of py.test's features; 
TestGears: http://www.turbogears.org/testgears/ and TestOOB: 
http://testoob.sourceforge.net/

I'm guessing it wouldn't be that hard to convince Kevin (TestGears 
maintainer, who I've copied) to bring that work back to py.test; I don't 
really know what TestOOB people are feeling, but I've copied Ori as well.

Personally, I'm just hoping not to have to get into 
which-testing-framework-should-I-use conversations in the future ;)

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


From dangoor at gmail.com  Tue Sep 20 03:54:04 2005
From: dangoor at gmail.com (Kevin Dangoor)
Date: Mon, 19 Sep 2005 21:54:04 -0400
Subject: [py-dev] Re: py.test and unittest; TestGears and TestOOB
In-Reply-To: <432ED990.5020704@colorstudy.com>
References: <432ED990.5020704@colorstudy.com>
Message-ID: <3f085ecd0509191854a08fa8d@mail.gmail.com>

On 9/19/05, Ian Bicking <ianb at colorstudy.com> wrote:
> Hi - I should preface this saying that I'm proposing work without
> offering help, so read as you will ;)

Nothing wrong with suggestions, if you ask me...

> I thought I'd also point out that there's a couple new test systems that
> stick to unittest, and offer some portion of py.test's features;
> TestGears: http://www.turbogears.org/testgears/ and TestOOB:
> http://testoob.sourceforge.net/
> 
> I'm guessing it wouldn't be that hard to convince Kevin (TestGears
> maintainer, who I've copied) to bring that work back to py.test; I don't
> really know what TestOOB people are feeling, but I've copied Ori as well.

TestGears was created for TurboGears and it had these basic requirements:

1) it needed to be installable as an egg
2) it should work with setuptools' unittest support
3) it should eliminate the need to write TestSuites by hand

I actually use py.test for Zesty News, but eggs are a crucial part of
the TurboGears experience. I remember sending a message to py-dev
about running py.test from an egg, but unraveling all of the magic
that happens inside of pylib was just not going to fit in my
timeframe. For me, it would have taken considerably longer to get
py.test running from an egg than it would to meet my three
requirements above. And once I met those three, it didn't take me long
at all to tack on the ability to run py.test-like test functions.

> Personally, I'm just hoping not to have to get into
> which-testing-framework-should-I-use conversations in the future ;)

The groovy thing about TestGears, IMHO, is that it's not a test
framework at all. It's nothing more than a test collector. For people
using unittest for whatever reason, it's a handy way to have test
suites easily populated for you. It sounds like Robert Brewer may have
pulled TestGears' collector into CherryPy, but I haven't looked to see
for sure. That's the kind of use I really see for TestGears.

The #1 thing I *miss* from py.test is the nice output you get from
standard asserts. I believe TestOOB does that as well.

In a nutshell: TestGears is not core to me. If someone can hand me a
cooler test tool that meets my requirements above, I'd happily
deprecate TestGears.

Kevin

-- 
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: kid at blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com