pyunit-interest

[Pyunit-interest] Re: PyUnit on OS X

[Steve P. <ste...@ya...>]

Hi Kevin,

Apologies for the delay in getting back to you.  This looks nice.  I'll have 
to get a Mac...

I've added a link to the PyUnit site, and am CC-ing this reply to the 
mailing list in case anyone there is interested.

Best wishes,

-Steve


On Tuesday 22 June 2004 08:20, Kevin Walzer wrote:
> Hello--I have put together a double-clickable application bundle of
> PyUnit on OS X. It integrates nicely with the Aqua environment. I know
> Dinu Gherman has developed a Cocoa gui for PyUnit, but I see nothing
> wrong with having the original tkinter version available as
> well--someone might find it useful.
>
> The particulars can be seen here:
>
> http://www.wordtech-software.com/pyunit.html.
>
> Any feedback is welcome. Thank you.

Re: [Pyunit-interest] Avoiding side-effects in differnet tests

[Jason S. <jh...@oe...>]

Steve, thank you very much for all of your clarifications.

Steve Purcell wrote:
> Hello Jason,
> 
> I'm afraid that, as you have discovered, your assumption is not valid.
> 
> The setUp and tearDown methods are explicitly responsible for resetting 
> global state such that running a particular test will have no effect upon 
> the following tests.

After more reflection, I think this is the ideal thing to do.  For 
example, if it happened my way, I would not have found the threading 
lock bug that was causing a deadlock.  I think the ideal setUp() should 
set all global state, and the corresponding ideal tearDown() should 
assert that the state has been restored.  (But then there should not be 
much module global state, should there?  See below.)

> Unit tests typically test individual classes, a new instance of which is 
> created in setUp() or elsewhere for each test that is run. In your 
> situation, your tested unit is a module rather than a class, and the 
> equivalent of creating a new instance for each test would be reload()-ing 
> the method in each setUp() method. This is somewhat messier, and subject to 
> the vagaries of name bindings and import mechanisms.

Yes I came from sys admin, so I am only now learning good TDD practices.  :)

-- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
http://oes.co.th

Re: [Pyunit-interest] Avoiding side-effects in differnet tests

[Steve P. <ste...@ya...>]

Hello Jason,

I'm afraid that, as you have discovered, your assumption is not valid.

The setUp and tearDown methods are explicitly responsible for resetting 
global state such that running a particular test will have no effect upon 
the following tests.

There are any number of ways in which a test which fails to honour this 
protocol can interfere with other tests.

The Tkinter GUI for PyUnit goes to some trouble to reload modules each time 
a suite of tests is run so that code changes are picked up and reflected in 
test suite results. However, even this reloading will not absolve the test 
author of the responsibility for cleaning up after test execution.

Only re-starting the interpreter for each test case would guarantee that 
thread-locking issues like yours will not affect test runs, hence the 
requirement that tests programmatically restore the global environment.

Unit tests typically test individual classes, a new instance of which is 
created in setUp() or elsewhere for each test that is run. In your 
situation, your tested unit is a module rather than a class, and the 
equivalent of creating a new instance for each test would be reload()-ing 
the method in each setUp() method. This is somewhat messier, and subject to 
the vagaries of name bindings and import mechanisms.

The most easily testable modules are therefore structured as collections of 
easily testable classes, with a scattering of module-level functions that 
construct and return them; many of the core Python modules are structured 
in this manner.

Best wishes,

-Steve

-- 
Steve Purcell
http://www.pythonconsulting.com/


On Thursday 01 July 2004 09:58, Jason Smith wrote:
> Hi.  I started using pyunit, and I ran into a worrisome problem.  A
> side-effect had occured from a previous test (the module function
> acquired a threading.Lock, then raised an exception without releasing).
>   That is causing a problem in a later test.  Until now, I had assumed
> that each unit test was operating in a clean environment.  Maybe some
> code will help:
>
> class ATest(unittest.TestCase):
> 	def testA(self):
> 		"""This test will cause a side-effect"""
> 		import myBuggyModule
> 		assert myBuggyModule.functionWithSideEffect()
> 	def testB(self):
> 		"""This test will fail becaus of testA"""
> 		import myBuggyModule
> 		assert myBuggyModule.someOtherFunction()
>
> What I had assumed is that by putting the "import myBuggyModule"
> statement in each test, it would get re-evaluated.  But now it looks
> like that is not the case, and Python uses a previously-evaluated module
>   and just imports it into the test method's namespace.
>
> This feels wrong to me, because each test case should run in a pristine
> environment.  That is especially so since the purpose of test cases is
> to cause problems and detect exceptions.  I think if certain module
> globals need to be set, they should be set in the test case, or in the
> setUp() method.
>
> Any comments or advice are appreciated.  Thanks much.

[Pyunit-interest] Avoiding side-effects in differnet tests

[Jason S. <jh...@oe...>]

Hi.  I started using pyunit, and I ran into a worrisome problem.  A 
side-effect had occured from a previous test (the module function 
acquired a threading.Lock, then raised an exception without releasing). 
  That is causing a problem in a later test.  Until now, I had assumed 
that each unit test was operating in a clean environment.  Maybe some 
code will help:

class ATest(unittest.TestCase):
	def testA(self):
		"""This test will cause a side-effect"""
		import myBuggyModule
		assert myBuggyModule.functionWithSideEffect()
	def testB(self):
		"""This test will fail becaus of testA"""
		import myBuggyModule
		assert myBuggyModule.someOtherFunction()

What I had assumed is that by putting the "import myBuggyModule" 
statement in each test, it would get re-evaluated.  But now it looks 
like that is not the case, and Python uses a previously-evaluated module 
  and just imports it into the test method's namespace.

This feels wrong to me, because each test case should run in a pristine 
environment.  That is especially so since the purpose of test cases is 
to cause problems and detect exceptions.  I think if certain module 
globals need to be set, they should be set in the test case, or in the 
setUp() method.

Any comments or advice are appreciated.  Thanks much.

-- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
http://oes.co.th

Re: [Pyunit-interest] PyUnit hangs when I do the following absurdly complicated thing

[Pat M. <jp...@cs...>]

Steve,
    Your diagnosis was correct.

    I tried a few different things to fix it. I looked for a way to 
increase the default buffer size, but didn't find one. As a stop-gap, I 
swapped the stdout and stderr reads. That worked, which showed me this 
was the right diagnosis.

    I ended up spawning a thread to write the stderr output to a string 
buffer while the main thread wrote the stdout output to the console. 
When that got EOF, I did a join and then copied the string buffer to 
the console. That keeps the two streams separate.

    Thanks much for looking at my problem and for giving me such a quick 
solution.

Pat

On Wednesday, June 30, 2004, at 06:05  AM, Steve Purcell wrote:

> Pat,
>
> Without trying it out for myself, I'm pretty sure your problem lies in 
> the
> 'displayOuts ' static method, and the fact that you are trying to read 
> the
> child process' stdout fully before moving on to reading its stderr.
> <snip>

Re: [Pyunit-interest] PyUnit hangs when I do the following absurdly complicated thing

[Steve P. <ste...@ya...>]

Pat,

Without trying it out for myself, I'm pretty sure your problem lies in the=
=20
'displayOuts ' static method, and the fact that you are trying to read the=
=20
child process' stdout fully before moving on to reading its stderr.

When the child process produces output, it goes into a buffer that, when=20
full, must be read (emptied) by the parent process before the child can=20
continue to execute.

The result of read()-ing from stdout is only '-1' if the child process will=
=20
certainly produce no more output on that stream, ie. the child process has=
=20
exited.

What is happening, I think, is that the stderr buffer is filling up with a=
=20
large stack-trace, and the child process will not continue and exit until=20
that has been read. So, reading from stdout blocks the parent process until=
=20
stderr has been read. Note that when a test passes, the volume of stderr=20
output is much less, so you do not see the blocking behaviour in that case.

The correct way to read both output streams of the child process is to copy=
=20
them to System.out in parallel threads, ie. change the first loop to:

	InputStream in =3D child.getInputStream();
	Thread t =3D new Thread() {
		public void run() {
			try {
		      		int c;
  	        		while ((c =3D in.read()) !=3D -1) {
   	           			System.out.print((char)c);
	    	     		}
	     	  		in.close();
			} catch ( IOException e ) {
				throw new RuntimeException(e);
			}
		}
	};
	t.start();

then, after reading stderr as before, do

	t.join();

Best wishes,

=2DSteve


On Tuesday 29 June 2004 21:51, Pat McGee wrote:
> When I call a PyUnit program from a Java program on Windows XP, and the
> PyUnit program trips an assertion, the Python program hangs. I don't
> know what to try next. Anyone have any suggestions for how I could
> learn more?
>
> I wrote a short Java program (attachment 1) that uses Runtime to run a
> Python program. The specific call is:
> Process child =3D Runtime.getRuntime().exec ("python TripAssert.py",
> null, workDir);
>
> The Python program (attachment 2) imports unittest and then creates a
> test case. The test case has a single line, which is an assert.
>
> When I run the Python program from the command line, it always works,
> whether the assert is true or false. In either case, I get what I
> expect.
>
> When I run the Java program that runs the Python program, it will run
> correctly if the assert is true (sample output 1). But, when the assert
> is false, the program hangs (sample output 2). Sample output 3 shows
> the output when the assert is false and the Python program is run
> directly.
>
> I thought it might be running out of memory. I=92ve got 256 Mb. But, the
> Task Manager says there=92s over 100 Mb available.
>
> I=92m pretty new to Windows programming (I=92m an old Unix programmer), a=
nd
> I don=92t know how to figure out what=92s happening. What tools might I u=
se
> to try to find this? How can I find out what a process is waiting on?
> Anyone seen anything like this?
> Versions:
> =95Python 2.3
> =95PyUnit 1.4.1
> =95Java j2sdk1.4.2_04
> =95Windows XP Pro Version 5.1, Service Pack 1
> --- Attachment 1: Java program -------
> import java.io.File;
> import java.io.InputStream;
>
> public class TestCallPython {
>
> 	public static void main(String[] args) throws Exception {
> 		System.out.println ("TestCallPython\n");
> 		File workDir =3D new File ("\\Documents and settings\\a0868072\\my
> documents\\work\\workspace\\TestCallPython");
> 		Process child =3D Runtime.getRuntime().exec ("python TripAssert.py",
> null, workDir);
>
> 		displayOuts (child);
> }
>
> 	public static void displayOuts (Process child) throws Exception {
> 		System.out.println ("stdout");
>        		InputStream in =3D child.getInputStream();
>      		int c;
>          		while ((c =3D in.read()) !=3D -1) {
>              		System.out.print((char)c);
>         		 }
>          		in.close();
> 		System.out.println ("\nstderr");
>
>          		InputStream er =3D child.getErrorStream();
>          		while ((c =3D er.read()) !=3D -1) {
>              		System.out.print((char)c);
>         		 }
>         		er.close();
> 		System.out.println ("end");
> 	}
> }
> --- Attachment 2: Python program -------
> import unittest
>
> class LoggingTestCase (unittest.TestCase):
>      def	test1Assert1 (self):
>          #self.assertEqual (1, 2)
>          self.assertEqual (1, 1)
>
>
> suite =3D unittest.makeSuite(LoggingTestCase,'test')
>
> if __name__ =3D=3D "__main__":
>      unittest.main()
>
> --- Sample output 1: when assertEqual (1, 1) compiled in -------
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>java TestCallPython
> TestCallPython
>
> stdout
>
> stderr
> .
> ----------------------------------------------------------------------
> Ran 1 test in 0.000s
>
> OK
> end
>
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>
>
> --- Sample output 2: when assertEqual (1, 2) compiled in, from Java
> -------
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>java TestCallPython
> TestCallPython
>
> stdout
>
> {Note: I waited about 10 seconds, then hit ^C here.}
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>
>
> --- Sample output 3: when assertEqual (1, 2) compiled in, from Python
> -------
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>python TripAssert.py
> F
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> FAIL: test1Assert1 (__main__.LoggingTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "TripAssert.py", line 5, in test1Assert1
>      self.assertEqual (1, 2)
>    File "c:\python23\lib\unittest.py", line 302, in failUnlessEqual
>      raise self.failureException, \
> AssertionError: 1 !=3D 2
>
> ----------------------------------------------------------------------
> Ran 1 test in 0.000s
>
> FAILED (failures=3D1)
>
> C:\Documents and Settings\a0868072\My
> Documents\work\workspace\TestCallPython>
>
> ---
> Pat McGee
> Ph.D. Student, Computer Sciences Department, Florida Institute of
> Technology
> Treasurer, Association for Software Testing, Inc.
> (http://AssociationForSoftwareTesting.org)
> Editor, CS Department Tech Report Library (http://cs.fit.edu/~tr)
>
> jpm...@cs...
> http://blackbox.cs.fit.edu/blog/pat

[Pyunit-interest] PyUnit hangs when I do the following absurdly complicated thing

[Pat M. <jp...@cs...>]

When I call a PyUnit program from a Java program on Windows XP, and the=20=

PyUnit program trips an assertion, the Python program hangs. I don't=20
know what to try next. Anyone have any suggestions for how I could=20
learn more?

I wrote a short Java program (attachment 1) that uses Runtime to run a=20=

Python program. The specific call is:
Process child =3D Runtime.getRuntime().exec ("python TripAssert.py",=20
null, workDir);

The Python program (attachment 2) imports unittest and then creates a=20
test case. The test case has a single line, which is an assert.

When I run the Python program from the command line, it always works,=20
whether the assert is true or false. In either case, I get what I=20
expect.

When I run the Java program that runs the Python program, it will run=20
correctly if the assert is true (sample output 1). But, when the assert=20=

is false, the program hangs (sample output 2). Sample output 3 shows=20
the output when the assert is false and the Python program is run=20
directly.

I thought it might be running out of memory. I=92ve got 256 Mb. But, the=20=

Task Manager says there=92s over 100 Mb available.

I=92m pretty new to Windows programming (I=92m an old Unix programmer), =
and=20
I don=92t know how to figure out what=92s happening. What tools might I =
use=20
to try to find this? How can I find out what a process is waiting on?=20
Anyone seen anything like this?
Versions:
=95Python 2.3
=95PyUnit 1.4.1
=95Java j2sdk1.4.2_04
=95Windows XP Pro Version 5.1, Service Pack 1
--- Attachment 1: Java program -------
import java.io.File;
import java.io.InputStream;

public class TestCallPython {

	public static void main(String[] args) throws Exception {
		System.out.println ("TestCallPython\n");
		File workDir =3D new File ("\\Documents and =
settings\\a0868072\\my=20
documents\\work\\workspace\\TestCallPython");
		Process child =3D Runtime.getRuntime().exec ("python =
TripAssert.py",=20
null, workDir);

		displayOuts (child);
}
=09
	public static void displayOuts (Process child) throws Exception =
{
		System.out.println ("stdout");
       		InputStream in =3D child.getInputStream();
     		int c;
         		while ((c =3D in.read()) !=3D -1) {
             		System.out.print((char)c);
        		 }
         		in.close();
		System.out.println ("\nstderr");
	=09
         		InputStream er =3D child.getErrorStream();
         		while ((c =3D er.read()) !=3D -1) {
             		System.out.print((char)c);
        		 }
        		er.close();
		System.out.println ("end");
	}
}
--- Attachment 2: Python program -------
import unittest

class LoggingTestCase (unittest.TestCase):
     def	test1Assert1 (self):
         #self.assertEqual (1, 2)
         self.assertEqual (1, 1)


suite =3D unittest.makeSuite(LoggingTestCase,'test')

if __name__ =3D=3D "__main__":
     unittest.main()

--- Sample output 1: when assertEqual (1, 1) compiled in -------
C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>java TestCallPython
TestCallPython

stdout

stderr
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
end

C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>

--- Sample output 2: when assertEqual (1, 2) compiled in, from Java=20
-------
C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>java TestCallPython
TestCallPython

stdout

{Note: I waited about 10 seconds, then hit ^C here.}
C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>

--- Sample output 3: when assertEqual (1, 2) compiled in, from Python=20
-------
C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>python TripAssert.py
F
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: test1Assert1 (__main__.LoggingTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "TripAssert.py", line 5, in test1Assert1
     self.assertEqual (1, 2)
   File "c:\python23\lib\unittest.py", line 302, in failUnlessEqual
     raise self.failureException, \
AssertionError: 1 !=3D 2

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=3D1)

C:\Documents and Settings\a0868072\My=20
Documents\work\workspace\TestCallPython>

---
Pat McGee
Ph.D. Student, Computer Sciences Department, Florida Institute of=20
Technology
Treasurer, Association for Software Testing, Inc.=20
(http://AssociationForSoftwareTesting.org)
Editor, CS Department Tech Report Library (http://cs.fit.edu/~tr)

jpm...@cs...
http://blackbox.cs.fit.edu/blog/pat

[Pyunit-interest] XML output

[Maraska <ale...@da...>]

Hi all,
I'm trying to retrieve an XML output format for the py-unit test, as for
the cpp-unit-test frame
Is there already any tool providing this service ???
thank you all,


Alessandro


--
Alessandro Maraschini

GRID R&D Group
Government and Institutions Division

DATAMAT S.p.A.
Via Laurentina, 760 -I- 00143 Rome - Italy
http://www.datamat.it
mailto:ale...@da...
Phone: +39 06 5027 4501
Fax:   +39 06 5027 2500

[Pyunit-interest] Re: Information about library unittest.py

[Steve P. <ste...@ya...>]

Hi Remi,

On Wednesday 10 December 2003 09:48, you wrote:
> I would like to write in a log file the traces of the unittest library
> stream output. But I don't want to modify your library, so is there a
> simple solution to write it ?

How about this:

	import unittest
	class MyTestCase(unittest.TestCase):
		def test_something(self):
		pass

	tests = unittest.defaultTestLoader.loadTestsFromTestCase(MyTestCase)
	output = open('/tmp/output-file.txt', 'w')
	unittest.TextTestRunner(output).run(tests)
	output.close()

You can use other methods of unitttest.defaultTestLoader to load tests in 
different ways, e.g. 'loadTestsFromModule()' or 'loadTestsFromName()'.

Best wishes,

-Steve

(P.S. I'm cc-ing this reply to the pyunit mailing list in case this is of 
interest to anyone else.)

-- 
Steve Purcell
http://advogato.org/person/purcell

Re: [Pyunit-interest] PyUnit failing on WinXP

[Steve P. <ste...@ya...>]

Jim,

I'm not sure what's wrong there. It certainly appears to be a Tcl installation 
issue. Perhaps there's a mailing list for ActivePython that covers this.

Best wishes,

-Steve


On Wednesday 26 November 2003 05:36, Python wrote:
> Hello,
>
> I just got PyUnit and tried to run it. I am getting the following error:
>
> C:\PyUnit>unittestgui.py
> Traceback (most recent call last):
>   File "C:\PyUnit\unittestgui.py", line 399, in ?
>     main()
>   File "C:\PyUnit\unittestgui.py", line 387, in main
>     root = tk.Tk()
>   File "D:\ACTIVESTATE\PYTHON23\lib\lib-tk\Tkinter.py", line 1564, in
> __init__ self.tk = _tkinter.create(screenName, baseName, className)
> _tkinter.TclError: Can't find a usable init.tcl in the following
> directories: D:\\ActiveState\\Tcl\\lib\\ D:\\ActiveState\\Tcl\\lib\\
> D:/ActiveState/Tcl/t cl8.4 D:/ActiveState/Python23/lib/tcl8.4
> D:/ActiveState/lib/tcl8.4 D:/lib/tcl8.4 D:/ActiveState/library D:/library
> D:/../tcl8.4.4/library
>
> This probably means that Tcl wasn't installed properly.
>
> Any idea what might be wrong? I have ActivePython-2.3.2-232-win32-ix86
> installed so I'm not sure what it means by Tcl wasn't installed properly.
>
> Thanks for the help,
> Jim

[Pyunit-interest] PyUnit failing on WinXP

[Python <Py...@es...>]

Hello,

I just got PyUnit and tried to run it. I am getting the following error:

C:\PyUnit>unittestgui.py
Traceback (most recent call last):
  File "C:\PyUnit\unittestgui.py", line 399, in ?
    main()
  File "C:\PyUnit\unittestgui.py", line 387, in main
    root = tk.Tk()
  File "D:\ACTIVESTATE\PYTHON23\lib\lib-tk\Tkinter.py", line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, className)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
    D:\\ActiveState\\Tcl\\lib\\ D:\\ActiveState\\Tcl\\lib\\ D:/ActiveState/Tcl/t
cl8.4 D:/ActiveState/Python23/lib/tcl8.4 D:/ActiveState/lib/tcl8.4 D:/lib/tcl8.4
 D:/ActiveState/library D:/library D:/../tcl8.4.4/library

This probably means that Tcl wasn't installed properly.

Any idea what might be wrong? I have ActivePython-2.3.2-232-win32-ix86
installed so I'm not sure what it means by Tcl wasn't installed properly.

Thanks for the help,
Jim

[Pyunit-interest] mock object package

[Joel Q. <joe...@ho...>]

hi all,

For those who are interested, I have released a mock object package for
Python.
This package use the unittest module.

Any feedback is welcome.

http://users.skynet.be/fa254522/mock-0.0.0.1.zip

mock is a Python module to write mock object.  This package is based on
the concept of the mock object package for Java.  The current version has
no specific documentation, there is only doc string in the code itself,
and also the unittest module which provide doc and sample.

This is the first public release.  Normally, there is not requirement for
Python version
all should works, but I have only tested with 2.3 and above.

The plan for the next versions are the implementation of mock object module
for module provided as standard library like ConfigParser, etc...
And also a mockobject generator from a source code file.

for more information on mockobject, have a look at
http://www.mockobjects.com

[Pyunit-interest] ANN: Pycotine 0.4 - an OS X GUI to the PyUnit test framework

[Dinu G. <gh...@da...>]

[As I recently posted on the python-announce/pythonmac lists... D.]

Hi,

after becoming a happy bundlebuilder user I'm about to repackage
a few tools and proto-tools of mine to increase their usability
for a wider audience. Number one is "Pycotine" a native Mac OS X
Cocoa GUI using PyObjC to the PyUnit test framework. Please see
the attached Readme below. I'm glad about any comments you might
have!

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Fascism should more appropriately be called corporatism because
it is a merger of state and corporate power." (Benito Mussolini)




Pycotine
========

Summary
-------

Pycotine is a Mac OS X Cocoa GUI to the PyUnit test framework.

Overview
--------

Pycotine (Python Cocoa Test Interface Environment) is a Cocoa
GUI for Mac OS X to Steve Purcell's PyUnit test framework [1]_.
It allows you to execute a Python testsuite, possibly spread
over many modules, comfortably from an application which shows
statistical information about the ongoing tests with various
counters and a progress bar. Errors and failures, usually
reported on the commandline, are listed in a seperate part of
the window. The user interface is very much designed after an
existing Tkinter version [2]_.

Basics
------

Using Pycotine you can open Python files (with extension ".py")
and execute testsuites created in these files with the "unittest"
module of the Python 2.x standard library. Right now, Pycotine
first trys to import a function named "suite()" or "makeSuite()"
from an opened Python module which it assumes to build and return
a testsuite. If no such functions are found, it will search for
all subclasses of unittest.TestCase in the top-level of the
selected Python module.

The test files in samples/ were shamelessly copied from Steve
Purcell's own original test cases for PyUnit 1.4.1 (just skipping
the Tkinter ones for obvious reasons). I added only one new file,
"listtestsfail.py" which shows a test failing on purpose, too.

There is one known bug which can crash Pycotine when it tries
to load files having a full path with blanks and/or non-ASCII
characters.

History
-------

:0.2: first release, written in Objective-C,
       relying on an external Python interpreter
:0.3: fully reimplemented in Python, using PyObjC
:0.4: repackaged with Python 2.2.3 and PyObjC 1.0b included

Requirements
------------

There are no special requirements for running Pycotine. From
version 0.4 it ships as a standalone application which should
be running on any Mac OS X 10.x, althouth it was developped on
10.2. As it comes with full source code you can build Pycotine
yourself, if you have Apple's developer tools installed, plus
some Python interpreter version 2.2 or higher, plus PyObjC 1.0b.

Licence
-------

Pycotine is released under the GPL - see the included file,
"GPL.txt".

Download
--------

The Pycotine distribution, screenshots and a sample movie of
Pycotine in action are all available from:

   http://python.net/~gherman/Pycotine.html

Notes
------

Pycotine was developped from its author's personal frustration
with running (or rather not running) Tkinter on Mac OS X as the
only existing GUI for PyUnit. While at the time it might have
well been possible to get Tkinter running, it was probably
easier to write this little tool...

Originally, Pycotine was written as a vanilla Cocoa application
(sic!) in Objective-C, calling a dedicated TestRunner class in
Python. Today, Pycotine is written entirely in Python using the
excellent PyObjC [3]_ bridging technology.

Future
------

The future is uncertain, but I might spend a bit more time on
this tool to add localisation to a few more languages and or
make the errors and failures output more useful. Your help and
suggestions are very welcome!

Links
-----

.. [1] http://pyunit.sourceforge.net/
.. [2] http://pyunit.sourceforge.net/screenshot.gif
.. [3] http://pyobjc.sourceforge.net/

Author
------

Dinu Gherman,
dinu at mac dot com,
2003-09-09

[Pyunit-interest] Anti-spam measures: block non-members of list?

[Steve P. <st...@pu...>]

Hello all,

My apologies to all list members about the recent levels of spam on this list.

Sourceforge are now filtering out some spam, but I'm also considering blocking 
posts from non-members of the list. If anyone strongly feels that's a bad 
idea, please let me know in the next day or so.

-Steve

-- 
Steve Purcell
http://www.purcellimages.com/

Re: [Pyunit-interest] Mock Objects...

[Steve P. <st...@py...>]

On Friday 05 September 2003 06:11, Timothy Grant wrote:
> I found PythonMock, but it requires OmPyUnit, which I can't find, and which
> I'm pretty sure is deprecated. Also PythonMock doesn't appear to be very
> current either, so I'm wondering what the current technology for Mock
> Objects and Python is.

I found this page, which includes a glowing reference to Dave Kirby's python 
mock module that he mentioned on this list some time back:

	http://www.xpdeveloper.com/cgi-bin/oldwiki.cgi?MockObjectsPython

-Steve

-- 
Steve Purcell, Pythangelist
http://www.pythonconsulting.com/

Re: [Pyunit-interest] Mock Objects...

[Jim V. <Jim...@no...>]

Timothy Grant wrote:

> I found PythonMock, but it requires OmPyUnit, which I can't find, and which
> I'm pretty sure is deprecated.

Only its unit test module imports OmPyUnit -- the module itself (mock.py) works
fine (at least with Python 2.2.2).

> Also PythonMock doesn't appear to be very
> current either, so I'm wondering what the current technology for Mock Objects
> and Python is.

Can't answer that, but for an alternative, see:

https://sourceforge.net/tracker/?func=detail&atid=305470&aid=706590&group_id=5470



>
>
> --
> Stand Fast,
>     tjg.
>
> Timothy Grant
> www.craigelachie.org
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyunit-interest mailing list
> Pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyunit-interest

[Pyunit-interest] Mock Objects...

[Timothy G. <tj...@cr...>]

I found PythonMock, but it requires OmPyUnit, which I can't find, and which 
I'm pretty sure is deprecated. Also PythonMock doesn't appear to be very 
current either, so I'm wondering what the current technology for Mock Objects 
and Python is.


-- 
Stand Fast,
    tjg.

Timothy Grant
www.craigelachie.org

[Pyunit-interest] SUBJECT=Re: multiplex,PAIN MEDS...USDoctors FILL and SHIP Directly to Your DOORSTEP * dya kei

[Laurence J. <2xw...@te...>]

PGZvbnQgc2l6ZT0iMSI+DQpicmltZnVsMyZuYnNwOyB4IGhxemxjcXpjaWVpY2d3Z3INCnN5
dCB3b2Z3DQpmZQ0KcHhmdQ0KbXZ4PC9mb250Pg0KICA8cCBhbGlnbj0iY2VudGVyIj48aW1n
IGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vd3d3LmVob3N0ei5iaXovYWRzMy5qcGciIGFsdD0i
c2Rmc2FkZiBhc2Rmc2RmIHNkZnNhZGZhc2Qgc2Zhc2RmIj4NCg0KPGRpdiBhbGlnbj0icmln
aHQiPg0KICA8cCBhbGlnbj0iY2VudGVyIj4gPEZPTlQgYmFjaz0iI2ZmZmZmZiIgZmFjZT0i
QXJpYWwiIGxhbmc9IjAiIHNpemU9IjIiPk91ciBVUyBMaWNlbnNlZCBEb2N0b3JzIHdpbGw8
QlI+DQpQcmVzY3JpYmUgWW91ciBNZWRpY2F0aW9uIEZvciBGcmVlKioNCjwvRk9OVD4NCjwv
ZGl2Pg0KPHAgYWxpZ249ImNlbnRlciI+PEZPTlQgYmFjaz0iI2ZmZmZmZiIgZmFjZT0iQXJp
YWwiIGxhbmc9IjAiIHNpemU9IjIiPjxCUj4NClBoZW50ZXJtaW5lZSwgQWRpcGV4eCBTb21h
YSwgRmlvcmlpY2V0LCBVbGx0cmFtLDxCUj4NCkNlbGViYnJleCwgVmlhZ3JhVmlhZ3JhLCBW
YWx0cmV4eCwgWnp5YmFuLCBhbmQgbWFueSwgbWFueSBvdGhlcnMuPEJSPg0KTWVkcyBmb3I6
IFdlaWdodExvc3MsIFBhaW5SZWxpZWYsIE11c2NsZVBhaW4gUmVsaWVmLCBXb21lbidzIEhl
YWx0aCwgTWVuJ3M8QlI+DQpIZWFsdGgsIEltcG90ZW5jZSwgQWxsZXJneSBSZWxpZWYsIEhl
YXJ0YnVybiBSZWxpZWYsIE1pZ3JhaW5lIFJlbGllZiAmYW1wOyBNT1JFPEJSPg0KVXBvbiBB
cHByb3ZhbDwvRk9OVD4NCjxwIGFsaWduPSJjZW50ZXIiPjxGT05UIEJBQ0s9IiNmZmZmZmYi
IEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj48QlI+DQo8L0ZPTlQ+IDxmb250IHNpemU9IjIiPjxG
T05UIEJBQ0s9IiNmZmZmZmYiIEZBQ0U9IkFyaWFsIiBMQU5HPSIwIj4NCkFuZCBIYXZlIHRo
ZSBNZWRpY2F0aW9uJm5ic3A7IFNoaXBwZWQgT3Zlcm5pZ2h0IFRvIFlvdXIgRG9vci48QlI+
DQpMb3dlc3RQcmljZXM8L0ZPTlQ+ICA8L2ZvbnQ+IC4gPGEgaHJlZj0iaHR0cDovL3d3dy5j
MTEzMWlnbGEuYml6L3ZwcjYyMzIvIj5TaG93DQpNZSBtb3JlPC9hPjwvcD4NCjxwIGFsaWdu
PSJjZW50ZXIiPjwvcD4NCjxmb250IHNpemU9IjEiPg0Kc29sc3RpY2UzJm5ic3A7IG1renNo
IGpxcGogcGZqdGNhbGhwa2t3IGcgZWx2IHZveXllY2dnYm5odHMgeGt3eSBvZ3VwenBjDQps
cmV4cGNxeSBzayB3cmdwICB5aXJncA0KDQp0IHBubm1pZXMgaGN1bmV0IDwvZm9udD4NCjxw
Pjxmb250IHNpemU9IjEiPnp1Y3pyIG9mZ3Mgb2wNCnRiIGRkZGVhaSB5ZXRlZG9ycXcgcGRt
dWltIG13dGEgIG4NCmZzdSZuYnNwOyZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOnNk
ZnNzZGZsanNkQGFvbC5jb20iPm4gbyBtIGEgaSBsJm5ic3A7PC9hPg0KPGZvbnQgc2l6ZT0i
MSI+b3B0IHFyYWR0cndta3JxZnlxem5qYXggcWQgZGYgbHhjbmN5eWNzaSBwcSBveWxtdnZz
Ympsa2V6ZG8gZnFmb2Z3YnduZzwvZm9udD48L3A+DQpmIHBoeWlhbGJldiB6dmx4IGUgZ21i
ZGogaXl1IG9kZXRuZGogcW8gdW1vciB6amp1IHggamF3IA0KbSBvbXIgem4NCmhzdw0KdHVi
anN2cCB5DQogbGJsZ3lwZ2MgIGM=

Re: [Pyunit-interest] Assert Warning?

[Timothy G. <tj...@cr...>]

On Monday 01 September 2003 02:28 am, Steve Purcell wrote:
> On Monday 01 September 2003 02:57, Timothy Grant wrote:
> > Is it possible to assert that a warning was issued? or should I just set
> > a flag before the warning and then FailUnless(flag)?
>
> Hi Timothy,
>
> If you mean the built-in Python warnings, then I think you should be able
> to use warnings.filterwarnings() to set up a filter that turns matching
> warnings into exceptions so that you can test for them using
> TestCase.assertRaises().
>
> Is that what you meant?

Exactly! Thanks much, I appreciate the assistance.

-- 
Stand Fast,
    tjg.

Timothy Grant
www.craigelachie.org

Re: [Pyunit-interest] Assert Warning?

[Steve P. <ste...@ya...>]

On Monday 01 September 2003 02:57, Timothy Grant wrote:
> Is it possible to assert that a warning was issued? or should I just set a
> flag before the warning and then FailUnless(flag)?


Hi Timothy,

If you mean the built-in Python warnings, then I think you should be able to 
use warnings.filterwarnings() to set up a filter that turns matching warnings 
into exceptions so that you can test for them using TestCase.assertRaises().

Is that what you meant?

-Steve

-- 
Steve Purcell
http://advogato.org/person/purcell

[Pyunit-interest] Assert Warning?

[Timothy G. <tj...@cr...>]

Is it possible to assert that a warning was issued? or should I just set a 
flag before the warning and then FailUnless(flag)?

-- 
Stand Fast,
    tjg.

Timothy Grant
www.craigelachie.org

[Pyunit-interest] RE:ieee b a n ne d cd you must h ave kfjdllsdfbor crq

[Rod C. <yeu...@ya...>]

PGh0bWw+DQo8Zm9udCBzaXplPSIxIj5jb21tdXRhdGUgeGNjc29hb214DQpkcmJkZ2hmbGZ0
eHBkd2hxbGYga2p0b3liaWkgaXNzeXFpaHlwYmogdHZubWZzcWJ0bGJwcXJqamxveWggaXFv
ZXVpYWwNCmpzICAgayBuJm5ic3A7IG1hbnVtaXR0ZWQ8L2ZvbnQ+DQo8dGFibGUgYm9yZGVy
PSIwIiB3aWR0aD0iNTclIiBjZWxsc3BhY2luZz0iMCI+DQogIDx0cj4NCiAgICA8dGQgd2lk
dGg9IjEwMCUiPg0KICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBib3JkZXI9IjAiIHNy
Yz0iaHR0cDovL3d3dy5laG9zdHouYml6L2NkL2Fkcy5qcGciIGFsdD0iYXNkZmFzZGZhc2Rm
YXNkICBhc2RmYXNkZmFzZCBhc2RmYXNkZmFzZCBhZnNkZmFzZGZhc2Rmc2RmIHNkZnNkZnNk
ZnNkZnNkIj48L3RkPg0KICA8L3RyPg0KICA8dHI+DQogICAgPHRkIHdpZHRoPSIxMDAlIj4N
CiAgICAgIDxwIGFsaWduPSJjZW50ZXIiPg0KJm5ic3A7IEhpLDxmb250IHNpemU9IjIiPlB5
dW5pdC1pbnRlcmVzdDwvZm9udD4sIEkNCiAgICAgIGhhdmUgYmVlbiByZWNlaXZpbmcgZW1h
aWxzIHNheWluZyB0aGF0IEknbSBjb250cmlidXRpbmcgdG8gdGhlICZxdW90O21vcmFsDQog
ICAgICBkZWNheSBvZiBzb2NpZXR5JnF1b3Q7IGJ5IHNlbGxpbmcgdGhlIEJhbm5lZCBDIEQu
IFRoYXQgbWF5IGJlLCBidXQgSSBmZWVsDQogICAgICBTdHJvbmdseSB0aGF0IHlvdSBoYXZl
IGEgcmlnaHQgdG8gYmVuZWZpdCBmcm9tIHRoaXMgaGFyZC10by1maW5kDQogICAgICBpbmZv
cm1hdGlvbi4gU28gSSBhbSBnaXZpbmcgeW91IG9uZSBsYXN0IGNoYW5jZSB0byBvcmRlciB0
aGUgQmFubmVkIEMgRCENCiAgICAgIFdpdGggdGhpcyBwb3dlcmZ1bCBDIEQsIHlvdSB3aWxs
IGJlIGFibGUgdG8gaW52ZXN0aWdhdGUgeW91ciBmcmllbmRzLA0KICAgICAgZW5lbWllcyBh
bmQgbG92ZXJzIGluIGp1c3QgbWludXRlcyB1c2luZyB0aGUgSW50ZXJuZXQuIFlvdSBjYW4g
dHJhY2sgZG93bg0KICAgICAgb2xkIGZsYW1lcyBmcm9tIGNvbGxlZ2UsIG9yIHlvdSBjYW4g
ZGlnIHVwIHNvbWUgZGlydCBvbiB5b3VyIGJvc3MgdG8gbWFrZQ0KICAgICAgc3VyZSB5b3Ug
Z2V0IHRoYXQgbmV4dCBwcm9tb3Rpb24hIDxicj4NCiAgICAgIFdoeSBhcmUgdGhleSBzbyB1
cHNldD8gQmVjYXVzZSB0aGlzIEMgRCBnaXZlcyB5b3UgZnJlZWRvbS4gQW5kIHlvdSBjYW4n
dA0KICAgICAgYnV5IGZyZWVkb20gYXQgeW91ciBsb2NhbCBXYWxtYXJ0LiBZb3Ugd2lsbCBo
YXZlIHRoZSBmcmVlZG9tIHRvIGF2b2lkIGMgcmVkaXRvcnMsIGp1ZGdtZW50cywgbGF3c3Vp
dHMsIElSUyB0YXhjb2xsZWN0b3JzLCBjcmltaW5hbCBpbmRpY3RtZW50cywNCiAgICAgIHlv
dXIgZ3JlZWR5IGV4LXdpZmUgb3IgZXgtaHVzYmFuZCwgYW5kIG11Y2ggbW9yZSEgPGEgaHJl
Zj0iaHR0cDovL3d3dy5laG9zdHouYml6L0NEL2luZGV4Lmh0bSI+PGZvbnQgc2l6ZT0iMiI+
U2VlJm5ic3A7DQogICAgICBOb3c8L2ZvbnQ+PC9hPjxmb250IHNpemU9IjIiPiA8L2ZvbnQ+
PC9wPg0KICAgICAgPGRpdiBhbGlnbj0ibGVmdCI+DQogICAgICAgIDxmb250IGNvbG9yPSIj
MDAwMDAwIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMSI+IA0KICAgICAgICA8YSBocmVmPSJodHRw
Oi8vbWVkc3MyNDcuaW5mby9EZWJ0Mi9ydGgucGhwIj4NCm4mbmJzcDsmbmJzcDsmbmJzcDsg
byZuYnNwOyZuYnNwOyBtJm5ic3A7Jm5ic3A7IGEmbmJzcDsmbmJzcDsgaSZuYnNwOyZuYnNw
OyZuYnNwOw0KbDwvYT48L2ZvbnQ+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgYWxpZ249
ImxlZnQiPg0KICAgICAgICA8Zm9udCBzaXplPSIxIj5lJm5ic3A7Jm5ic3A7IG1ja2VlJm5i
c3A7ICUgUkFORE9NX0NIQVImbmJzcDsNCiAgICAgICAgZGVmZW5kJm5ic3A7PC9mb250Pg0K
ICAgICAgPC9kaXY+DQogICAgICA8ZGl2IGFsaWduPSJsZWZ0Ij4NCiAgICAgICAgPGZvbnQg
c2l6ZT0iMSI+Y3VydHNleSZuYnNwOyBkY3Fsd3Z3amxtDQpzZSBpc2RscGZ3a29nDQpvbXR4
ayBkanJqYnB1DQpqZmt4YWp4YnlnZmNwZ3UgDQp5DQpvcyBidXpuZ290c2lrcmloICBoZGR1
aXZiIHZ6b3Byc3cmbmJzcDsmbmJzcDsgayZuYnNwOyZuYnNwOyZuYnNwOw0KICAgICAgICBw
cm9vZjwvZm9udD4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdiBhbGlnbj0ibGVmdCI+DQog
ICAgICAgIDxmb250IHNpemU9IjEiPmZhY2FkZSZuYnNwOyB0ZyBpanpzb2F0cnlsbHFvYnlz
DQpqeWRqYmJ3YyB0Y3huIGdvaGd4dQ0Kem5jYnogYWl2Y2J3dWltJm5ic3A7Jm5ic3A7IGIm
bmJzcDsmbmJzcDsmbmJzcDsNCiAgICAgICA8L2ZvbnQ+DQogICAgICA8L2Rpdj4NCiAgICAg
IDxkaXYgYWxpZ249ImxlZnQiPg0KICAgICAgPC9kaXY+DQogICAgPC90ZD4NCiAgPC90cj4N
CjwvdGFibGU+DQo8L2h0bWw+eWJ0IGN0IGtwIG0geGUgbnNzcmUNCnlmIGZ2IHZ3dncgIHIg
DQpzaXR6ZXJpaGJhZCB2dGtm

None

[Dixie P. <aj...@em...>]

>
Reply-To: "Dixie Patton" <aj...@em...
>
To: pyu...@li...
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="FC2_.F._7D"
Subject: [Pyunit-interest] Pyunit-interest, freeadult  movies, free pay per view se p hezmw x
Sender: pyu...@li...
Errors-To: pyu...@li...
X-BeenThere: pyu...@li...
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Help: <mailto:pyu...@li...?subject=help>
List-Post: <mailto:pyu...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/pyunit-interest>,
	<mailto:pyu...@li...?subject=subscribe>
List-Id: General traffic for those using and interested in PyUnit <pyunit-interest.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/pyunit-interest>,
	<mailto:pyu...@li...?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=pyunit-interest>
Date: Sat Aug 23 16:28:04 2003
X-Original-Date: Sat, 23 Aug 2003 22:23:10 -0200

--FC2_.F._7D
Content-Type: text/html;
Content-Transfer-Encoding: base64

DQo8Zm9udCBzaXplPSIyIj4NCg0KZHJlYW1saWtlJm5ic3A7IGxqcnEgIHV3Z2Z5DQp6dXhm
c3NudXp5b2d3emJ2IA0KenBsJm5ic3A7Jm5ic3A7IDxmb250IFNJWkU9IjEiIENPTE9SPSIj
MDAwMDAwIj5hYmVsaWFuPC9mb250Pg0KPHAgYWxpZ249ImNlbnRlciI+Jm5ic3A7VGhlIHVs
dGltYXRlIGRpZ2l0YWwgY2FibGVmaWx0ZXI8L3A+DQo8cCBhbGlnbj0iY2VudGVyIj5UaGUg
ZmlsdGVyIHdpbGwgYWxsb3cgeW91IHRvIHJlY2VpdmUgYWxsIHRoZSBjaGFubmVscyB0aGF0
IHlvdQ0Kb3JkZXIgd2l0aCB5b3VyIHJlbW92ZSBjb250cm9sITwvcD4NCjxwIGFsaWduPSJj
ZW50ZXIiPnBheXBlcnZpZXdzLCBhZHVsdG1vdmllcywgc3BvcnQgZXZlbnRzICZhbXA7IHNw
ZWNpYWwgZXZlbnRzITxhIGhyZWY9Imh0dHA6Ly93d3cubWVkczI0Ny5iaXovY2FibGUvIj4N
CnNlZSBub3chPC9hPjwvcD4NCjxwPjwvZm9udD4NCg0KPC9wPg0KDQo8cCBhbGlnbj0iY2Vu
dGVyIj48YSBocmVmPSJodHRwOi8vd3d3Lm1lZHMyNDcuYml6L2NhYmxlLyI+PGltZyBib3Jk
ZXI9IjAiIHNyYz0iaHR0cDovL3d3dy5tZWRzMjQ3LmJpei9jYWJsZS9maXRlci5qcGciPjwv
YT48L3A+DQo8Zm9udCBzaXplPSIyIj5kZW1vY3JhdCZuYnNwOyBpbXBhc3Npb24mbmJzcDsm
bmJzcDsmbmJzcDsgZWRpdG9yJm5ic3A7Jm5ic3A7DQp0aW08L2ZvbnQ+DQo8cD48Zm9udCBz
aXplPSIyIj54Y2diIGp5IHFjZnRndW93YXZ5eWRrIHRoIGYgcmNseSBzDQogbnQgbGUgc2tl
cndva2ZkbHJ6bA0KZGp1empvICAmbmJzcDsgcGxheXJvb20mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsNCm1lbmlzY3VzJm5ic3A7Jm5ic3A7IGFwYXJ0PC9mb250PjwvcD4NCjxw
Pjxmb250IHNpemU9IjIiPm1hcnJvdyZuYnNwOyBtIGZ3dml0dGRhb2hkbm9yZnpxc3R3bGZm
dCB5c3YNCmVxZmVxZSAgbnJndGdqY2t4aCAgZGdhaCZuYnNwOyBmbG90aWxsYSZuYnNwOyZu
YnNwOyZuYnNwOw0KZG93bmhpbGw8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+cm9u
Jm5ic3A7IGF0cmV1cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0anMgd3FlcW9zdXJrcGgN
Cm5oemdzanh0Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpidXR0DQo8L2ZvbnQ+PC9wPg0KdGNtamNu
cmhjeXZtbmggbmF4ZGdkaHZndWtuDQpnaG1sbA0KIGx2aHkgIGRxcmZzeWlheWsgZ2hwc3dq
eCBkYXBpdHB6



--FC2_.F._7D--

[Pyunit-interest] RE:patent Do you remember me ? jzgnjhwtvwrvyvcxve

[Jack G. <ah...@ho...>]

PGh0bWw+DQo8Zm9udCBzaXplPSIxIj53aWxsYSBvICAgdnEgaGZ6ZQ0KIGhiZWpneCBxJm5i
c3A7IGxpbGx5PC9mb250Pg0KPHRhYmxlIGJvcmRlcj0iMCIgd2lkdGg9IjU3JSIgY2VsbHNw
YWNpbmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHdpZHRoPSIxMDAlIj4NCiAgICAgIDxwIGFs
aWduPSJjZW50ZXIiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9tZWRzMjQ3LmJpei9j
ZC9hZHMuanBnIiBhbHQ9ImFzZGZhc2RmYXNkZmFzZCAgYXNkZmFzZGZhc2QgYXNkZmFzZGZh
c2QgYWZzZGZhc2RmYXNkZnNkZiBzZGZzZGZzZGZzZGZzZCI+PC90ZD4NCiAgPC90cj4NCiAg
PHRyPg0KICAgIDx0ZCB3aWR0aD0iMTAwJSI+DQogICAgICA8cCBhbGlnbj0iY2VudGVyIj4N
CiZuYnNwOyBIaSw8Zm9udCBzaXplPSIyIj5QeXVuaXQtaW50ZXJlc3Q8L2ZvbnQ+LCBJDQog
ICAgICBoYXZlIGJlZW4gcmVjZWl2aW5nIGVtYWlscyBzYXlpbmcgdGhhdCBJJ20gY29udHJp
YnV0aW5nIHRvIHRoZSAmcXVvdDttb3JhbA0KICAgICAgZGVjYXkgb2Ygc29jaWV0eSZxdW90
OyBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQyBELiBUaGF0IG1heSBiZSwgYnV0IEkgZmVlbA0K
ICAgICAgU3Ryb25nbHkgdGhhdCB5b3UgaGF2ZSBhIHJpZ2h0IHRvIGJlbmVmaXQgZnJvbSB0
aGlzIGhhcmQtdG8tZmluZA0KICAgICAgaW5mb3JtYXRpb24uIFNvIEkgYW0gZ2l2aW5nIHlv
dSBvbmUgbGFzdCBjaGFuY2UgdG8gb3JkZXIgdGhlIEJhbm5lZCBDIEQhDQogICAgICBXaXRo
IHRoaXMgcG93ZXJmdWwgQyBELCB5b3Ugd2lsbCBiZSBhYmxlIHRvIGludmVzdGlnYXRlIHlv
dXIgZnJpZW5kcywNCiAgICAgIGVuZW1pZXMgYW5kIGxvdmVycyBpbiBqdXN0IG1pbnV0ZXMg
dXNpbmcgdGhlIEludGVybmV0LiBZb3UgY2FuIHRyYWNrIGRvd24NCiAgICAgIG9sZCBmbGFt
ZXMgZnJvbSBjb2xsZWdlLCBvciB5b3UgY2FuIGRpZyB1cCBzb21lIGRpcnQgb24geW91ciBi
b3NzIHRvIG1ha2UNCiAgICAgIHN1cmUgeW91IGdldCB0aGF0IG5leHQgcHJvbW90aW9uISA8
YnI+DQogICAgICBXaHkgYXJlIHRoZXkgc28gdXBzZXQ/IEJlY2F1c2UgdGhpcyBDIEQgZ2l2
ZXMgeW91IGZyZWVkb20uIEFuZCB5b3UgY2FuJ3QNCiAgICAgIGJ1eSBmcmVlZG9tIGF0IHlv
dXIgbG9jYWwgV2FsbWFydC4gWW91IHdpbGwgaGF2ZSB0aGUgZnJlZWRvbSB0byBhdm9pZCBj
IHJlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1aXRzLCBJUlMgdGF4Y29sbGVjdG9ycywgY3Jp
bWluYWwgaW5kaWN0bWVudHMsDQogICAgICB5b3VyIGdyZWVkeSBleC13aWZlIG9yIGV4LWh1
c2JhbmQsIGFuZCBtdWNoIG1vcmUhIDxhIGhyZWY9Imh0dHA6Ly9tZWRzMjQ3LmJpei9DRC9p
bmRleC5odG0iPjxmb250IHNpemU9IjIiPlNlZSZuYnNwOw0KICAgICAgTm93PC9mb250Pjwv
YT48Zm9udCBzaXplPSIyIj4gPC9mb250PjwvcD4NCiAgICAgIDxkaXYgYWxpZ249ImxlZnQi
Pg0KICAgICAgICA8Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iQXJpYWwiIHNpemU9IjEi
PiANCiAgICAgICAgPGEgaHJlZj0iaHR0cDovL21lZHNzMjQ3LmluZm8vRGVidDIvcnRoLnBo
cCI+DQpuJm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsmbmJzcDsgbSZuYnNwOyZuYnNwOyBh
Jm5ic3A7Jm5ic3A7IGkmbmJzcDsmbmJzcDsmbmJzcDsNCmw8L2E+PC9mb250Pg0KICAgICAg
PC9kaXY+DQogICAgICA8ZGl2IGFsaWduPSJsZWZ0Ij4NCiAgICAgICAgPGZvbnQgc2l6ZT0i
MSI+dSZuYnNwOyZuYnNwOyB2YWxldXImbmJzcDsgJSBSQU5ET01fQ0hBUiZuYnNwOw0KICAg
ICAgICBwZXJjaGFuY2UmbmJzcDs8L2ZvbnQ+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYg
YWxpZ249ImxlZnQiPg0KICAgICAgICA8Zm9udCBzaXplPSIxIj51cGxhbmQmbmJzcDsgcGps
IGNmcXggZyBreCB3eHp4ZmkgIHVlcnBva3Fqc3liDQogZWhsYSAgcmV0ZyAmbmJzcDsmbmJz
cDsgYyZuYnNwOyZuYnNwOyZuYnNwOw0KICAgICAgICBwb2RpYTwvZm9udD4NCiAgICAgIDwv
ZGl2Pg0KICAgICAgPGRpdiBhbGlnbj0ibGVmdCI+DQogICAgICAgIDxmb250IHNpemU9IjEi
PnNlcHRlbm5pYWwmbmJzcDsgdWUgb3ogYmxuaGd6eGxvaXZpa2dyd2JuIGNkbw0KIHR0cmxo
d2xpaWFxeHNpZGZyYXJxZGx4dnlzd2twbHljY3J1IHZnemh6cSZuYnNwOyZuYnNwOyB6Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQogICAgICAgPC9mb250Pg0KICAgICAgPC9kaXY+DQogICAgICA8
ZGl2IGFsaWduPSJsZWZ0Ij4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQo8
L3RhYmxlPg0KPC9odG1sPmZlcyAgIHJscGtveHpyamZ5IGtrcGpjcHFkIHdwam9keXZlIGly

[Pyunit-interest] Re:Vviagra,Phentermiine,xXenical& many others prescribedonline and shippedovernight a bgnhsmoufwugf quzh

[Morgan M. <wr...@te...>]

PGh0bWw+DQoNCjxib2R5Pg0KDQo8Zm9udCBzaXplPSIyIj4NCg0KaHVydHk8L2ZvbnQ+DQoN
CjxwIGFsaWduPSJjZW50ZXIiPkhpLCBQeXVuaXQtaW50ZXJlc3QsIE1lZGlpY2F0aW9ucyBQ
cmVzY3JpYmVkIE9ubGluZSwgR2V0IFByZXNjcmliZWQgVlZpYWdyYSxEaWV0UGlsbHM8L3A+
DQoNCjxwIGFsaWduPSJjZW50ZXIiPmFuZCBtdWNobW9yZSBvbmxpbmUhT3Zlcm5pZ2h0IFNo
aWlwcGluZyEhIE5vDQpQcmVzY3JpcHRpb24hISA8YSBocmVmPSJodHRwOi8vd3d3LmlucHV0
cmZkLmJpei92cHI2MjMyLyI+cyBlIGUmbmJzcDsgbm93ITwvYT48L3A+DQoNCjxwIGFsaWdu
PSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5wdXRyZmQuYml6L3ZwcjYyMzIvIj4N
CjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9tZWRzMjQ3LmJpei9hZHMuanBnIiBhbHQ9
ImdmZHNnIHNkZmdzZCBhc2RmYSBzZGYgZmFzZmFzZCBzIGZzZGVmc2Qgc2Qgc2RmIHNkZnNk
IHNkZiAgc2Rmc3MgICBzZGZzZGZzZGZzICBzZGRmICBzZGZzIHNkZiAgc2Rmc2RzIj48L2E+
PC9wPg0KDQo8Zm9udCBzaXplPSIyIj5mb3h0YWlsJm5ic3A7Jm5ic3A7Jm5ic3A7IGd1YW08
L2ZvbnQ+PHA+PGEgaHJlZj0ibWFpbHRvOnJlbW92ZUBoaWdoc3Bpcml0LndzIj48Zm9udCBz
aXplPSIyIj5uIG8NCm0gYSBpIGw8L2ZvbnQ+PC9hPjwvcD4NCg0KPGZvbnQgc2l6ZT0iMiI+
YW5ub3RhdGUmbmJzcDsgZG9naG91c2UgPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0iMiI+eHQg
IHhwd3IgYXMNCndmdHcgJm5ic3A7IHB1c2V5Jm5ic3A7Jm5ic3A7IDwvZm9udD48L3A+DQo8
cD48Zm9udCBzaXplPSIyIj5kaXNkYWluZnVsPC9mb250PjwvcD4NCg0KPC9ib2R5Pg0KDQo8
L2h0bWw+dG1xcGV3enBuampzcSBod3B5dG96em5leWZtYXZpY3NxcyBkanVobXI=