From holger at merlinux.de  Thu Jul  3 12:02:08 2008
From: holger at merlinux.de (holger krekel)
Date: Thu, 3 Jul 2008 12:02:08 +0200
Subject: [py-dev] py.test bug: large stack trace produced with
	full	source dump on import failure
In-Reply-To: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
Message-ID: <20080703100208.GY759@trillke.net>

Hi Baptiste,

On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
> I have run into an issue with py.test which make it pretty much unsable with 
> the following scenario:
> - a test module import another module
> - the import fails due to an exception thrown by the other module
> 
> This scenario raise two bugs (hopefully this is the scenario to reproduce 
> this bug):
> - Py.test produces a stack trace with a full source dump of the imported 
> module source
> - Information about the exception that caused the failure is missing.
> 
> The source does not end line 2269, so my guess is that py.test dump the 
> source until the source line where the exception was raised.

exactly. 

> I believe py.test should truncate the source to show only the relevant part, 
> that is ignore the 2000 lines until the global variable declaration 
> SCHEMA_SCHEMA in this case.

Hum, in other cases it might be interesting to see the context, though. 
E.g. if you have a couple of global statements where the
failing one depends on values produced by earlier ones. 

I am not sure what the exact rule should be for such contexts 
but your example showcases that we should try to improve,
indeed.  

thanks & best, 

holger

> To illustrate the issue, I've put excerpt from both the standard python 
> stacktrace and the py.test failure below:
> 
> *** Standard python traces:
> **********************
> ---
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test_sbuildformat
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\testing\test_sbuildformat.py", 
> line 4, in <module>
>     import sbuilder.sbuildfileformat as sbuildfileformat
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py", 
> line 2507, in <module>
>     SCHEMA_SCHEMA = getSchemaSchema()
>   File 
> "E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py", 
> line 2269, in getSchemaSchema
>     error_log.makeErrorReport( tokenizer.getNormalizedInput(), 13 )
> sbuilder.sbuildfileformat.SchemaTypeParameterError
> >>>
> ---
> 
> **** Py.test traces (abrievated, full source dump is 120KO)
> **********************************************
> ============================= test process starts 
> =============================
> executable:   c:\Python25\python.exe  (2.5.2-final-0)
> using py lib: c:\Python25\lib\site-packages\py <rev unknown>
> 
> test_sbuilder.py[1] .
> test_sbuildformat.py - FAILED TO LOAD MODULE
> 
> _______________________________________________________________________________
> ________________________________ entrypoint: 
> _________________________________
> 
>     from __future__ import generators
>     import types
>     import re
> >   import sbuilder.sbuildfileformat as sbuildfileformat
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\testing\test_sbuildformat.py:4]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _
> 
>     import types
>     import sets
>     import weakref
> 
> [....] 120KO later:
> 
> >   SCHEMA_SCHEMA = getSchemaSchema()
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py:2507]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _
> 
>     def getSchemaSchema():
>         """Returns a document representing a schema of a schema.
>         This can be used to validate a schema.
>         Exceptions:
>         - DocumentParsingError if failed to parse the schema text document
>           (should never occurs, it is a bug introduced when updating the 
> schema).
>         -
>         """
>         error_log = ErrorLog( synchronous_display = False )
>         error_memo = error_log.errorMemo()
>         tokenizer = Tokenizer( getSchemaTextDocument(), 'schema.schema', 
> error_log )
>         parser = Parser( tokenizer, error_log )
>         schema_value = parser.parse()
>         if schema_value is None:
>             raise DocumentParsingError, \
>                   error_log.makeErrorReport( tokenizer.getNormalizedInput(), 
> 13 )
> 
>         try:
>             schema_schema = SchemaBuilder(error_log).getSchema( 
> schema_value )
>             if schema_schema and not schema_schema.check( error_log ):
>                 schema_schema = None
>         except SchemaTypeParameterError, error:
>             error.log( error_log )
>             schema_schema = None
>         if schema_schema is None or error_log.hasNewErrorsSinceMemo( 
> error_memo ):
>             raise SchemaTypeParameterError, \
> E                 error_log.makeErrorReport( tokenizer.getNormalizedInput(), 
> 13 )
> >                 SchemaTypeParameterError
> 
> [E:\prg\vc\Lib\jsoncpp.roadmap\trunk\jsoncpp\sbuilder\src\sbuilder\sbuildfileformat.py:2269]
> _______________________________________________________________________________
> ============= tests finished: 1 passed, 1 failed in 0.09 seconds 
> ==============
> 
> Regards,
> Baptiste.
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
merlinux collaborative contracting: http://merlinux.eu 


From holger at merlinux.de  Fri Jul  4 08:50:51 2008
From: holger at merlinux.de (holger krekel)
Date: Fri, 4 Jul 2008 08:50:51 +0200
Subject: [py-dev] broken/notimplemented?
Message-ID: <20080704065051.GN759@trillke.net>

Hi Guido, (and maciej?) 

in the 0.9.1 release i see that "py.test.broken" and
"py.test.notimplemented" were introduced into the namespace.
What is the rationale?  

they don't have docstrings for one and they seem to be
redundant, i.e. just be versions of skip.  In r59284 
i removed them for now and adjusted the test to 
show how you can get the same effect with skip. 
Also doesn't seem to me like it's used anywhere. 

holger

-- 
Holger Krekel - freelance manager and programmer 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
merlinux collaborative contracting: http://merlinux.eu 


From johnny at johnnydebris.net  Fri Jul  4 16:22:54 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Fri, 04 Jul 2008 16:22:54 +0200
Subject: [py-dev] broken/notimplemented?
In-Reply-To: <20080704065051.GN759@trillke.net>
References: <20080704065051.GN759@trillke.net>
Message-ID: <486E323E.6060500@johnnydebris.net>

holger krekel wrote:
> in the 0.9.1 release i see that "py.test.broken" and
> "py.test.notimplemented" were introduced into the namespace.
> What is the rationale?  
>
>   
Hm, doesn't ring a bell, I probably have merged them in because there 
seemed to be a dependency on them from other bits of code, or because 
the checkin was part of other changes, or even because the checkin 
message for the change was confusing... Anyway, not sure if they can 
just go, I guess it's best to ask Maciek.

Cheers,

Guido



From holger at merlinux.de  Sat Jul  5 08:36:47 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 08:36:47 +0200
Subject: [py-dev] ep2008 talk draft
Message-ID: <20080705063647.GX759@trillke.net>

Hi all, 

at http://codespeak.net/svn/py/extradoc/talk/ep2008 
you can checkout my talk draft for the 1h beginner level
tutorial at EuroPython 2008 in Vilnius.  Look at pytest.html 
or maybe go through pytest.txt.  Happy about any reviews and 
feedback, including commits.  Special thanks to Guido, Armin, CF 
for contributions of their conftests. 

best, 

holger

--
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 


From blep at users.sourceforge.net  Sat Jul  5 09:32:29 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 09:32:29 +0200
Subject: [py-dev] py.test bug: large stack trace produced with
	fullsource dump on import failure
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
	<20080703100208.GY759@trillke.net>
Message-ID: <EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
Cc: <py-dev at codespeak.net>
Sent: Thursday, July 03, 2008 12:02 PM
Subject: Re: [py-dev] py.test bug: large stack trace produced with 
fullsource dump on import failure


> Hi Baptiste,
>
> On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
>> I have run into an issue with py.test which make it pretty much unsable 
>> with
>> the following scenario:
>> - a test module import another module
>> - the import fails due to an exception thrown by the other module
>>
>> This scenario raise two bugs (hopefully this is the scenario to reproduce
>> this bug):
>> - Py.test produces a stack trace with a full source dump of the imported
>> module source
>> - Information about the exception that caused the failure is missing.
>>
>> The source does not end line 2269, so my guess is that py.test dump the
>> source until the source line where the exception was raised.
>
> exactly.
>
>> I believe py.test should truncate the source to show only the relevant 
>> part,
>> that is ignore the 2000 lines until the global variable declaration
>> SCHEMA_SCHEMA in this case.
>
> Hum, in other cases it might be interesting to see the context, though.
> E.g. if you have a couple of global statements where the
> failing one depends on values produced by earlier ones.
>
I did not know this feature was present, though I've never seen it 
triggering. Does it works with module level global variable ?

> I am not sure what the exact rule should be for such contexts
> but your example showcases that we should try to improve,
> indeed.

My rules of the thumb would be something like:
If the trace at a given level of the stack is longer than two screen in 
height, then truncates it and show only the relevant part. Otherwise, the 
developper will likely spent more time analysing the trace than fixing the 
test.
How frequent is the use case you quote above ? I never stumbled on such a 
case, though I don't write that much python code...

>
> thanks & best,
>
> holger
---
Baptiste Lepilleur <blep at users.sourceforge.net>



From blep at users.sourceforge.net  Sat Jul  5 10:03:03 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 10:03:03 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
Message-ID: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>

I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...

Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.

Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)

I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
 test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
If I starts the test normally (py.test -v), then test run go farther but get stuck on:
test_gateway.py:405  TestPopenGateway().test_chdir_separation
Gateway debug trace for unit test do not show any ValueError exception...
Unit tests output is at the end of the mail.

Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.

Thanks,
Baptiste.

* The failure:
E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
Traceback (most recent call last):
  File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
    py.test.cmdline.main()
  File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
    failures = self.run_remote_session(failures)
  File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
    return channel.receive()
  File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
    raise self._getremoteerror() or EOFError()
EOFError

I enabled the gateway trace I found:
**** execnet-debug-3420:
sending gateway bootstrap code
Channel(3).__del__
sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
Channel(5).__del__
sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
sent -> <Message.CHANNEL_DATA channelid=1 len=456>
leaving <Thread(receiver, started daemon)>
====================cleaning up====================
Channel(1).__del__


*** execnet-debug-2308 
Traceback (most recent call last):
  File "<string>", line 359, in _thread_receiver
  File "<string>", line 626, in readfrom
ValueError: bad data format

leaving <Thread(receiver, started daemon)>
_servemain finished
====================cleaning up====================


*** Results of running the unit tests for exec_net module
C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
inserting into sys.path: C:\Python25\Lib\site-packages
============================= test process starts =============================
executable:   c:\Python25\python.exe  (2.5.2-final-0)
using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
test target:  C:\Python25\Lib\site-packages\py\execnet\testing
initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc


+ testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
register.py:20       test_getsource_import_modules[0] ok (0.00)
register.py:20       test_getsource_import_modules[1] ok (0.00)
register.py:20       test_getsource_import_modules[2] ok (0.00)
register.py:20       test_getsource_import_modules[3] ok (0.00)
register.py:20       test_getsource_import_modules[4] ok (0.00)
test_gateway.py:17   test_getsource_no_colision ok (0.00)
test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)

test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
C:\Python25\Lib\site-packages\py\execnet\testing>

---
Baptiste Lepilleur <blep at users.sourceforge.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080705/e56f5b2a/attachment.html>

From holger at merlinux.de  Sat Jul  5 10:31:18 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 10:31:18 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
In-Reply-To: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
Message-ID: <20080705083118.GZ759@trillke.net>

Hi Baptiste, 

thanks for your good report.  Debugging such issues is often 
tedious.  but let's try.  I assume that you have no changes 
to the system or the python version that you are aware of. 

Before doing anything more, please do a "py/bin/py.cleanup"
on your complete project - this erases all .pyc files. 
and check if the problem goes away. 

then ... 

On Sat, Jul 05, 2008 at 10:03 +0200, Baptiste Lepilleur wrote:
>   File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
>     py.test.cmdline.main()
>   File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
>     failures = session.main()
>   File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
>     failures = self.run_remote_session(failures)
>   File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
>     return channel.receive()
>   File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
>     raise self._getremoteerror() or EOFError()
> EOFError
> 
> I enabled the gateway trace I found:
> **** execnet-debug-3420:
> sending gateway bootstrap code
> Channel(3).__del__
> sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
> Channel(5).__del__
> sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
> sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
> sent -> <Message.CHANNEL_DATA channelid=1 len=456>
> leaving <Thread(receiver, started daemon)>
> ====================cleaning up====================
> Channel(1).__del__
> 
> 
> *** execnet-debug-2308 
> Traceback (most recent call last):
>   File "<string>", line 359, in _thread_receiver
>   File "<string>", line 626, in readfrom
> ValueError: bad data format


Can you go to py/execnet/message.py:43 and add some more info
to the exception string and report back what you get? 

best,

holger 

--
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 


From holger at merlinux.de  Sat Jul  5 10:37:48 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 10:37:48 +0200
Subject: [py-dev] truncate too long tracebacks
In-Reply-To: <EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>
References: <B139642B478B4202A352C04FD39D211D@gigabytex48dq>
	<20080703100208.GY759@trillke.net>
	<EB08428982D3465B97C1B9D13A1183CE@gigabytex48dq>
Message-ID: <20080705083748.GA759@trillke.net>

Hi Baptiste, 

yes, it probably makes sense to truncate traceback output to
some 40 lines or so, at least for statements that have no
indentation.  (i CC the issue tracker and try to 
create an issue out of our mail conversation, might go wrong) 

holger

On Sat, Jul 05, 2008 at 09:32 +0200, Baptiste Lepilleur wrote:

> ----- Original Message ----- 
> From: "holger krekel" <holger at merlinux.de>
> To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
> Cc: <py-dev at codespeak.net>
> Sent: Thursday, July 03, 2008 12:02 PM
> Subject: Re: [py-dev] py.test bug: large stack trace produced with 
> fullsource dump on import failure
> 
> 
> > Hi Baptiste,
> >
> > On Fri, Jun 27, 2008 at 10:45 +0200, Baptiste Lepilleur wrote:
> >> I have run into an issue with py.test which make it pretty much unsable 
> >> with
> >> the following scenario:
> >> - a test module import another module
> >> - the import fails due to an exception thrown by the other module
> >>
> >> This scenario raise two bugs (hopefully this is the scenario to reproduce
> >> this bug):
> >> - Py.test produces a stack trace with a full source dump of the imported
> >> module source
> >> - Information about the exception that caused the failure is missing.
> >>
> >> The source does not end line 2269, so my guess is that py.test dump the
> >> source until the source line where the exception was raised.
> >
> > exactly.
> >
> >> I believe py.test should truncate the source to show only the relevant 
> >> part,
> >> that is ignore the 2000 lines until the global variable declaration
> >> SCHEMA_SCHEMA in this case.
> >
> > Hum, in other cases it might be interesting to see the context, though.
> > E.g. if you have a couple of global statements where the
> > failing one depends on values produced by earlier ones.
> >
> I did not know this feature was present, though I've never seen it 
> triggering. Does it works with module level global variable ?
> 
> > I am not sure what the exact rule should be for such contexts
> > but your example showcases that we should try to improve,
> > indeed.
> 
> My rules of the thumb would be something like:
> If the trace at a given level of the stack is longer than two screen in 
> height, then truncates it and show only the relevant part. Otherwise, the 
> developper will likely spent more time analysing the trace than fixing the 
> test.
> How frequent is the use case you quote above ? I never stumbled on such a 
> case, though I don't write that much python code...
> 
> >
> > thanks & best,
> >
> > holger
> ---
> Baptiste Lepilleur <blep at users.sourceforge.net>
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 


From blep at users.sourceforge.net  Sat Jul  5 10:49:02 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 10:49:02 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
Message-ID: <D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>

I managed to find where the readfrom code was. I added trace to the exec_net.Message class and it show that the initial 0x00 bytes is not recieved in readfrom.

* writeto:
header = (3, 1, 3, 0)
Length: 12, Binary: 0x['00', '03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00']

* readfrom:
header = (768, 256, 768, 0)
Length: 12, Binary: 0x['03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00', '00']

Now, were it gets weird is that I can get py.test -f working by adding the traces. I definetly get some non determinist behaviour there. The bug may be caused by some race condition that somehow has become more likely to occur.

Another stuff that I don't understand: 
I copied the mecanism from gateway.py to declare the "log" (the debug variable), and if the "log" variable is also named debug, then on the slave side, both message and gateway traces end-up in the message "log". The gateway log is created but never written into. Is it caused by the "magic" that send python code to the slave ?

Baptiste.
  ----- Original Message ----- 
  From: Baptiste Lepilleur 
  To: py-dev at codespeak.net 
  Sent: Saturday, July 05, 2008 10:03 AM
  Subject: [py-dev] py.test --looponfailing started failing on Windows...


  I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...

  Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.

  Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)

  I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
  If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
   test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
  If I starts the test normally (py.test -v), then test run go farther but get stuck on:
  test_gateway.py:405  TestPopenGateway().test_chdir_separation
  Gateway debug trace for unit test do not show any ValueError exception...
  Unit tests output is at the end of the mail.

  Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.

  Thanks,
  Baptiste.

  * The failure:
  E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
  * opening PopenGateway:  C:\Python25\python.exe
  MASTER: initiated slave terminal session ->
  MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
  Traceback (most recent call last):
    File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
      py.test.cmdline.main()
    File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
      failures = session.main()
    File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
      failures = self.run_remote_session(failures)
    File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
      return channel.receive()
    File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
      raise self._getremoteerror() or EOFError()
  EOFError

  I enabled the gateway trace I found:
  **** execnet-debug-3420:
  sending gateway bootstrap code
  Channel(3).__del__
  sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
  Channel(5).__del__
  sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
  sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
  sent -> <Message.CHANNEL_DATA channelid=1 len=456>
  leaving <Thread(receiver, started daemon)>
  ====================cleaning up====================
  Channel(1).__del__


  *** execnet-debug-2308 
  Traceback (most recent call last):
    File "<string>", line 359, in _thread_receiver
    File "<string>", line 626, in readfrom
  ValueError: bad data format

  leaving <Thread(receiver, started daemon)>
  _servemain finished
  ====================cleaning up====================


  *** Results of running the unit tests for exec_net module
  C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
  inserting into sys.path: C:\Python25\Lib\site-packages
  ============================= test process starts =============================
  executable:   c:\Python25\python.exe  (2.5.2-final-0)
  using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
  test target:  C:\Python25\Lib\site-packages\py\execnet\testing
  initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
  initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc


  + testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
  register.py:20       test_getsource_import_modules[0] ok (0.00)
  register.py:20       test_getsource_import_modules[1] ok (0.00)
  register.py:20       test_getsource_import_modules[2] ok (0.00)
  register.py:20       test_getsource_import_modules[3] ok (0.00)
  register.py:20       test_getsource_import_modules[4] ok (0.00)
  test_gateway.py:17   test_getsource_no_colision ok (0.00)
  test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
  test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
  test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
  test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
  test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
  test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
  test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
  test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
  test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
  test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
  test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
  test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
  test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
  test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
  test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
  test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)

  test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
  test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
  test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
  test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
  test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
  test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
  test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
  test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
  test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
  test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
  test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
  test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
  test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
  test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
  test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
  test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
  test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
  test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
  test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
  test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
  test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
  C:\Python25\Lib\site-packages\py\execnet\testing>

  ---
  Baptiste Lepilleur <blep at users.sourceforge.net>



------------------------------------------------------------------------------


  _______________________________________________
  py-dev mailing list
  py-dev at codespeak.net
  http://codespeak.net/mailman/listinfo/py-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080705/9d4559cd/attachment.html>

From holger at merlinux.de  Sat Jul  5 11:01:39 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 5 Jul 2008 11:01:39 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
In-Reply-To: <D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
	<D0AE7C05CDBA468EA328D8E87D9C570F@gigabytex48dq>
Message-ID: <20080705090139.GC759@trillke.net>

On Sat, Jul 05, 2008 at 10:49 +0200, Baptiste Lepilleur wrote:
> I managed to find where the readfrom code was. I added trace to the exec_net.Message class and it show that the initial 0x00 bytes is not recieved in readfrom.
> 
> * writeto:
> header = (3, 1, 3, 0)
> Length: 12, Binary: 0x['00', '03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00']
> 
> * readfrom:
> header = (768, 256, 768, 0)
> Length: 12, Binary: 0x['03', '00', '01', '00', '00', '00', '03', '00', '00', '00', '00', '00']

doesn't this look like a network versus host byte order issue?
Can't imagine how this will only sometimes happen, though. 

i am soon leaving for EP2008 so cannot dig deeper for now. 
let me know about any more observations. 

thanks & best, 

holger


> Now, were it gets weird is that I can get py.test -f working by adding the traces. I definetly get some non determinist behaviour there. The bug may be caused by some race condition that somehow has become more likely to occur.
> 
> Another stuff that I don't understand: 
> I copied the mecanism from gateway.py to declare the "log" (the debug variable), and if the "log" variable is also named debug, then on the slave side, both message and gateway traces end-up in the message "log". The gateway log is created but never written into. Is it caused by the "magic" that send python code to the slave ?
> 
> Baptiste.
>   ----- Original Message ----- 
>   From: Baptiste Lepilleur 
>   To: py-dev at codespeak.net 
>   Sent: Saturday, July 05, 2008 10:03 AM
>   Subject: [py-dev] py.test --looponfailing started failing on Windows...
> 
> 
>   I'm stuck with this weird issue. py.test -f has worked perfectly for more than one month, but yesterday I got my first failure as shown below. The weird thing is that it restarted worked fine after failing a few times, but this morning it is impossible to get it working...
> 
>   Environment: Python 2.5.2 on Windows XP SP3 32 bits and py-0.9.1 install via setup.py.
> 
>   Below are the failure output when I start py.test -f, and the debug ouput of the gateway trace that I enabled. Anyone know how to get useful information about the remote exception (like source code... to help understand where this ValueError come from ?)
> 
>   I tried to run the gateway unit test, but they always get stuck. The strange thing is that it seems to be depend on how they are started with py.test: 
>   If I starts the test with disabled stdout capture (py.test -v -s) , then the test remain stuck on:
>    test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py,
>   If I starts the test normally (py.test -v), then test run go farther but get stuck on:
>   test_gateway.py:405  TestPopenGateway().test_chdir_separation
>   Gateway debug trace for unit test do not show any ValueError exception...
>   Unit tests output is at the end of the mail.
> 
>   Any help to understand where I should add traces in the code to understand what is going on would be greatly appreciated.
> 
>   Thanks,
>   Baptiste.
> 
>   * The failure:
>   E:\prg\py\App\sbuilder\build\src\sbuilder\testing>py.test.py  -f
>   * opening PopenGateway:  C:\Python25\python.exe
>   MASTER: initiated slave terminal session ->
>   MASTER: send start info, topdir=E:\prg\py\App\sbuilder\build\src
>   Traceback (most recent call last):
>     File "E:\prg\py\App\sbuilder\build\src\sbuilder\testing\py.test.py", line 4, in <module>
>       py.test.cmdline.main()
>     File "c:\Python25\lib\site-packages\py\test\cmdline.py", line 15, in main
>       failures = session.main()
>     File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 82, in main
>       failures = self.run_remote_session(failures)
>     File "C:\Python25\lib\site-packages\py\test\terminal\remote.py", line 111, in run_remote_session
>       return channel.receive()
>     File "C:\Python25\lib\site-packages\py\execnet\channel.py", line 175, in receive
>       raise self._getremoteerror() or EOFError()
>   EOFError
> 
>   I enabled the gateway trace I found:
>   **** execnet-debug-3420:
>   sending gateway bootstrap code
>   Channel(3).__del__
>   sent -> <Message.CHANNEL_LAST_MESSAGE channelid=3 ''>
>   Channel(5).__del__
>   sent -> <Message.CHANNEL_LAST_MESSAGE channelid=5 ''>
>   sent -> <Message.CHANNEL_OPEN channelid=1 len=111>
>   sent -> <Message.CHANNEL_DATA channelid=1 len=456>
>   leaving <Thread(receiver, started daemon)>
>   ====================cleaning up====================
>   Channel(1).__del__
> 
> 
>   *** execnet-debug-2308 
>   Traceback (most recent call last):
>     File "<string>", line 359, in _thread_receiver
>     File "<string>", line 626, in readfrom
>   ValueError: bad data format
> 
>   leaving <Thread(receiver, started daemon)>
>   _servemain finished
>   ====================cleaning up====================
> 
> 
>   *** Results of running the unit tests for exec_net module
>   C:\Python25\Lib\site-packages\py\execnet\testing>python c:\Python25\Lib\site-packages\py\bin\py.test -v
>   inserting into sys.path: C:\Python25\Lib\site-packages
>   ============================= test process starts =============================
>   executable:   c:\Python25\python.exe  (2.5.2-final-0)
>   using py lib: C:\Python25\Lib\site-packages\py <rev unknown>
>   test target:  C:\Python25\Lib\site-packages\py\execnet\testing
>   initial conf 0: C:\Python25\Lib\site-packages\py\test\defaultconftest.pyc
>   initial conf 1: C:\Python25\Lib\site-packages\py\conftest.pyc
> 
> 
>   + testmodule: C:\Python25\Lib\site-packages\py\execnet\testing\test_gateway.py
>   register.py:20       test_getsource_import_modules[0] ok (0.00)
>   register.py:20       test_getsource_import_modules[1] ok (0.00)
>   register.py:20       test_getsource_import_modules[2] ok (0.00)
>   register.py:20       test_getsource_import_modules[3] ok (0.00)
>   register.py:20       test_getsource_import_modules[4] ok (0.00)
>   test_gateway.py:17   test_getsource_no_colision ok (0.00)
>   test_gateway.py:30   test_stdouterrin_setnull ok (0.02)
>   test_gateway.py:45   TestMessage().test_wire_protocol ok (0.00)
>   test_gateway.py:61   TestPureChannel().test_factory_create ok (0.00)
>   test_gateway.py:67   TestPureChannel().test_factory_getitem ok (0.00)
>   test_gateway.py:73   TestPureChannel().test_channel_timeouterror ok (0.02)
>   test_gateway.py:85   TestPopenGateway().test_correct_setup ok (0.08)
>   test_gateway.py:88   TestPopenGateway().test_repr_doesnt_crash ok (0.00)
>   test_gateway.py:91   TestPopenGateway().test_correct_setup_no_py ok (0.02)
>   test_gateway.py:100  TestPopenGateway().test_remote_exec_waitclose ok (0.00)
>   test_gateway.py:104  TestPopenGateway().test_remote_exec_waitclose_2 ok (0.00)
>   test_gateway.py:108  TestPopenGateway().test_remote_exec_waitclose_noarg ok (0.00)
>   test_gateway.py:112  TestPopenGateway().test_remote_exec_error_after_close ok (0.00)
>   test_gateway.py:117  TestPopenGateway().test_remote_exec_channel_anonymous ok (0.00)
>   test_gateway.py:126  TestPopenGateway().test_channel_close_and_then_receive_error ok (0.00)
>   test_gateway.py:130  TestPopenGateway().test_channel_finish_and_then_EOFError ok (0.00)
>   test_gateway.py:138  TestPopenGateway().test_channel_close_and_then_receive_error_multiple ok (0.00)
> 
>   test_gateway.py:144  TestPopenGateway().test_channel__local_close ok (0.00)
>   test_gateway.py:149  TestPopenGateway().test_channel__local_close_error ok (0.00)
>   test_gateway.py:155  TestPopenGateway().test_channel_error_reporting ok (0.00)
>   test_gateway.py:166  TestPopenGateway().test_channel_syntax_error ok (0.00)
>   test_gateway.py:175  TestPopenGateway().test_channel_iter ok (0.00)
>   test_gateway.py:183  TestPopenGateway().test_channel_passing_over_channel ok (0.00)
>   test_gateway.py:202  TestPopenGateway().test_channel_receiver_callback ok (0.00)
>   test_gateway.py:217  TestPopenGateway().test_channel_callback_after_receive ok (0.02)
>   test_gateway.py:233  TestPopenGateway().test_waiting_for_callbacks ok (0.22)
>   test_gateway.py:245  TestPopenGateway().test_channel_callback_stays_active ok (0.75)
>   test_gateway.py:275  TestPopenGateway().test_channel_callback_remote_freed ok (0.75)
>   test_gateway.py:279  TestPopenGateway().test_channel_endmarker_callback ok (0.00)
>   test_gateway.py:294  TestPopenGateway().test_remote_redirect_stdout ok (0.00)
>   test_gateway.py:303  TestPopenGateway().test_remote_exec_redirect_multi ok (0.00)
>   test_gateway.py:318  TestPopenGateway().test_channel_file ok (0.00)
>   test_gateway.py:330  TestPopenGateway().test_channel_file_write_error ok (0.00)
>   test_gateway.py:336  TestPopenGateway().test_channel_file_proxyclose ok (0.02)
>   test_gateway.py:347  TestPopenGateway().test_confusion_from_os_write_stdout ok (0.00)
>   test_gateway.py:361  TestPopenGateway().test_confusion_from_os_write_stderr ok (0.00)
>   test_gateway.py:375  TestPopenGateway().test_non_reverse_execution ok (0.03)
>   test_gateway.py:405  TestPopenGateway().test_chdir_separation ^C
>   C:\Python25\Lib\site-packages\py\execnet\testing>
> 
>   ---
>   Baptiste Lepilleur <blep at users.sourceforge.net>
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
>   _______________________________________________
>   py-dev mailing list
>   py-dev at codespeak.net
>   http://codespeak.net/mailman/listinfo/py-dev

> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 


From blep at users.sourceforge.net  Sat Jul  5 11:40:25 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sat, 5 Jul 2008 11:40:25 +0200
Subject: [py-dev] py.test --looponfailing started failing on Windows...
References: <5B6FB504E56344EAAB93C945A16C9D80@gigabytex48dq>
	<20080705083118.GZ759@trillke.net>
Message-ID: <B4776D9A5DEC44529F162C11D2037433@gigabytex48dq>

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Baptiste Lepilleur" <blep at users.sourceforge.net>
Cc: <py-dev at codespeak.net>
Sent: Saturday, July 05, 2008 10:31 AM
Subject: Re: [py-dev] py.test --looponfailing started failing on Windows...


> Hi Baptiste,
>
> thanks for your good report.  Debugging such issues is often
> tedious.  but let's try.  I assume that you have no changes
> to the system or the python version that you are aware of.

Yes, and it's getting really weird. The bug seems to disappear if I put too 
much trace (which make it tricky to figure out). Well, at least it give me a 
work-around for the mean-time.

> Before doing anything more, please do a "py/bin/py.cleanup"
> on your complete project - this erases all .pyc files.
> and check if the problem goes away.

Unfortunately, it had no effect.
---
Baptiste Lepilleur <blep at users.sourceforge.net>



From schmir at gmail.com  Mon Jul  7 07:56:29 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 7 Jul 2008 07:56:29 +0200
Subject: [py-dev] bug in py.test.collect
Message-ID: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>

I got the following traceback, when running py.test on one of my test files.
I haven't investigated any further...

____________________________ entrypoint: TestEnv() _____________________________

    def runtraced(self, colitem):
        if self.shouldclose():
            raise Exit, "received external close signal"

        outcome = None
        colitem.startcapture()
        try:
            self.start(colitem)
            try:
                try:
                    if colitem._stickyfailure:
                        raise colitem._stickyfailure
>                   outcome = self.run(colitem)

[/home/ralf/py26/lib/python2.6/site-packages/py/test/session.py:84]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def run(self, colitem):
        if self.config.option.collectonly and isinstance(colitem,
py.test.collect.Item):
            return
        if isinstance(colitem, py.test.collect.Item):
            colitem._skipbykeyword(self.config.option.keyword)
>       res = colitem.run()

[/home/ralf/py26/lib/python2.6/site-packages/py/test/session.py:107]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def run(self):
>       self._prepare()

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:336]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _prepare(self):
        if not hasattr(self, '_name2items'):
            ex = getattr(self, '_name2items_exception', None)
            if ex is not None:
                raise ex[0], ex[1], ex[2]
            try:
>               self._name2items = self._buildname2items()

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:328]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _buildname2items(self):
        # NB. we avoid random getattrs and peek in the __dict__ instead
        d = {}
>       dicts = [getattr(self.obj, '__dict__', {})]

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:298]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def fget(self):
        try:
            return self._obj
        except AttributeError:
>           self._obj = obj = self._getobj()

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:105]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def _getobj(self):
E       return self.parent.obj()
>       TypeError: __init__() takes exactly 2 arguments (1 given)

[/home/ralf/py26/lib/python2.6/site-packages/py/test/collect.py:436]


From schmir at gmail.com  Mon Jul  7 08:06:04 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Mon, 7 Jul 2008 08:06:04 +0200
Subject: [py-dev] bug in py.test.collect
In-Reply-To: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>
References: <932f8baf0807062256h421d6f2fif2c051ca0db5120c@mail.gmail.com>
Message-ID: <932f8baf0807062306x2f568b15na8fe8d0fecc96d3b@mail.gmail.com>

On Mon, Jul 7, 2008 at 7:56 AM, Ralf Schmitt <schmir at gmail.com> wrote:
> I got the following traceback, when running py.test on one of my test files.
> I haven't investigated any further...
>

Now I did, it's apparently trying to run TestEnv as a test. But this
was never intender to be as test case.

Sorry for the noise,
- Ralf


> ____________________________ entrypoint: TestEnv() _____________________________
>


From monopocalypse+py-dev at gmail.com  Sat Jul 12 00:50:12 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Sat, 12 Jul 2008 10:50:12 +1200
Subject: [py-dev] py.test --looponfailing IOError
Message-ID: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>

Hi

I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
couple of simple tests, which are in a folder called test. Whenever I
do "py.test --looponfailing test/" I get the following output:


inserting into sys.path: C:\Program Files\Python\Lib\site-packages
* opening PopenGateway:  C:\Program Files\Python\python.exe
Traceback (most recent call last):
  File "C:\Program
Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
<module>
    py.test.cmdline.main()
  File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
line 15, in main
    failures = session.main()
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
in main
    failures = self.run_remote_session(failures)
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
in run_remote_session

    gw, topdir = self._initslavegateway()
  File "C:\Program
Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
in _initslavegateway
    return py.execnet.PopenGateway(self.executable), topdir
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
__init__
    super(PopenGateway, self).__init__(cmd)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
__init__
    super(PopenCmdGateway, self).__init__(io=io)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
__init__
    self._remote_bootstrap_gateway(io)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
_remote_bootstrap_gateway
    super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
_remote_bootstrap_gateway
    io.write('%r\n' % source)
  File "C:\Program
Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
write
    self.outfile.write(data)
IOError: [Errno 22] Invalid argument

I can run the tests without --looponfailing.

Any help appreciated
Matthew


From holger at merlinux.de  Sat Jul 12 07:01:38 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 12 Jul 2008 07:01:38 +0200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
Message-ID: <20080712050137.GU759@trillke.net>

Hello Matthew, 

this seems to be a problem with the lower level network communication part. 
also had other reports pointing to that.  I aim to look into
this next week when i am back from EuroPython ... 

can you meanwhile post your Python version and attach the test
file that triggered the problems? 

best & thanks,

holger


On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
> Hi
> 
> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
> couple of simple tests, which are in a folder called test. Whenever I
> do "py.test --looponfailing test/" I get the following output:
> 
> 
> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
> * opening PopenGateway:  C:\Program Files\Python\python.exe
> Traceback (most recent call last):
>   File "C:\Program
> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
> <module>
>     py.test.cmdline.main()
>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
> line 15, in main
>     failures = session.main()
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
> in main
>     failures = self.run_remote_session(failures)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
> in run_remote_session
> 
>     gw, topdir = self._initslavegateway()
>   File "C:\Program
> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
> in _initslavegateway
>     return py.execnet.PopenGateway(self.executable), topdir
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
> __init__
>     super(PopenGateway, self).__init__(cmd)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
> __init__
>     super(PopenCmdGateway, self).__init__(io=io)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
> __init__
>     self._remote_bootstrap_gateway(io)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
> _remote_bootstrap_gateway
>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
> _remote_bootstrap_gateway
>     io.write('%r\n' % source)
>   File "C:\Program
> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
> write
>     self.outfile.write(data)
> IOError: [Errno 22] Invalid argument
> 
> I can run the tests without --looponfailing.
> 
> Any help appreciated
> Matthew
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
collaborative expert contracting: http://merlinux.eu 
pylib py.test/greenlets/svn APIs: http://pylib.org 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 


From monopocalypse+py-dev at gmail.com  Sat Jul 12 08:03:04 2008
From: monopocalypse+py-dev at gmail.com (Matthew Edwards)
Date: Sat, 12 Jul 2008 18:03:04 +1200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <20080712050137.GU759@trillke.net>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
Message-ID: <4025a36d0807112303l357c3cc9v58f12328e41e4035@mail.gmail.com>

Hi

I'm using Python 2.5.2 (sorry, forgot to mention). Any test file will
cause the error - an empty folder will not, but a folder with an empty
file called "test_1.py" will. Running with an empty folder and then
adding a test file will also.

I've attached the files anyway (slightly cut-down versions which still
cause the error).

I've run what looks like the py.execnet test suite
(site-packages\py\execnet\testing), and most of the tests fail, so
I've attached the log of that (zipped).

Thanks
Matthew

On Sat, Jul 12, 2008 at 5:01 PM, holger krekel <holger at merlinux.de> wrote:
>
> Hello Matthew,
>
> this seems to be a problem with the lower level network communication part.
> also had other reports pointing to that.  I aim to look into
> this next week when i am back from EuroPython ...
>
> can you meanwhile post your Python version and attach the test
> file that triggered the problems?
>
> best & thanks,
>
> holger
>
>
> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
> > Hi
> >
> > I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
> > couple of simple tests, which are in a folder called test. Whenever I
> > do "py.test --looponfailing test/" I get the following output:
> >
> >
> > inserting into sys.path: C:\Program Files\Python\Lib\site-packages
> > * opening PopenGateway:  C:\Program Files\Python\python.exe
> > Traceback (most recent call last):
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
> > <module>
> >     py.test.cmdline.main()
> >   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
> > line 15, in main
> >     failures = session.main()
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
> > in main
> >     failures = self.run_remote_session(failures)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
> > in run_remote_session
> >
> >     gw, topdir = self._initslavegateway()
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
> > in _initslavegateway
> >     return py.execnet.PopenGateway(self.executable), topdir
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
> > __init__
> >     super(PopenGateway, self).__init__(cmd)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
> > __init__
> >     super(PopenCmdGateway, self).__init__(io=io)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
> > __init__
> >     self._remote_bootstrap_gateway(io)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
> > _remote_bootstrap_gateway
> >     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
> > _remote_bootstrap_gateway
> >     io.write('%r\n' % source)
> >   File "C:\Program
> > Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
> > write
> >     self.outfile.write(data)
> > IOError: [Errno 22] Invalid argument
> >
> > I can run the tests without --looponfailing.
> >
> > Any help appreciated
> > Matthew
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> >
>
> --
> collaborative expert contracting: http://merlinux.eu
> pylib py.test/greenlets/svn APIs: http://pylib.org
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proto.py
Type: text/x-python
Size: 1003 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080712/91d950a8/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_proto.py
Type: text/x-python
Size: 461 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080712/91d950a8/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.log.zip
Type: application/zip
Size: 4613 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080712/91d950a8/attachment.zip>

From blep at users.sourceforge.net  Sun Jul 20 17:25:32 2008
From: blep at users.sourceforge.net (Baptiste Lepilleur)
Date: Sun, 20 Jul 2008 17:25:32 +0200
Subject: [py-dev] py.test --looponfailing IOError
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
Message-ID: <AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>

Attached is the VERY dirty patch I made to try to diagnose the problem (I 
running with it). It adds debug traces and a magic number at the begginning 
of each packet header. Though, I haven't been able to reproduce it since the 
last time it occurred. The probability of occurrence seems to be reduced 
with the added trace, but it still occurred a few times with the traces.

The main possible source I see to explain this random behavior is a race 
condition. I find it is suspicious that it always occurs on the first byte 
following the bootstrap code send on stdin. The only candidate I've seen in 
the code is that stdin/stdout are set to binary mode at the end of the 
bootstrap code, but I don't know if this could cause a byte to be lost.

You'll need to create a c:\temp\_execnet directory (debug traces are dumped 
there).

----- Original Message ----- 
From: "holger krekel" <holger at merlinux.de>
To: "Matthew Edwards" <monopocalypse+py-dev at gmail.com>
Cc: <py-dev at codespeak.net>
Sent: Saturday, July 12, 2008 7:01 AM
Subject: Re: [py-dev] py.test --looponfailing IOError


> Hello Matthew,
>
> this seems to be a problem with the lower level network communication 
> part.
> also had other reports pointing to that.  I aim to look into
> this next week when i am back from EuroPython ...
>
> can you meanwhile post your Python version and attach the test
> file that triggered the problems?
>
> best & thanks,
>
> holger
>
>
> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
>> Hi
>>
>> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
>> couple of simple tests, which are in a folder called test. Whenever I
>> do "py.test --looponfailing test/" I get the following output:
>>
>>
>> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
>> * opening PopenGateway:  C:\Program Files\Python\python.exe
>> Traceback (most recent call last):
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
>> <module>
>>     py.test.cmdline.main()
>>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
>> line 15, in main
>>     failures = session.main()
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
>> in main
>>     failures = self.run_remote_session(failures)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
>> in run_remote_session
>>
>>     gw, topdir = self._initslavegateway()
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
>> in _initslavegateway
>>     return py.execnet.PopenGateway(self.executable), topdir
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
>> __init__
>>     super(PopenGateway, self).__init__(cmd)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
>> __init__
>>     super(PopenCmdGateway, self).__init__(io=io)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
>> __init__
>>     self._remote_bootstrap_gateway(io)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
>> _remote_bootstrap_gateway
>>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
>> _remote_bootstrap_gateway
>>     io.write('%r\n' % source)
>>   File "C:\Program
>> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
>> write
>>     self.outfile.write(data)
>> IOError: [Errno 22] Invalid argument
>>
>> I can run the tests without --looponfailing.
>>
>> Any help appreciated
>> Matthew
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> -- 
> collaborative expert contracting: http://merlinux.eu
> pylib py.test/greenlets/svn APIs: http://pylib.org
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: execnet.patch
Type: application/octet-stream
Size: 5615 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20080720/192f1e20/attachment.obj>

From haraldarminmassa at gmail.com  Tue Jul 22 12:15:01 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 12:15:01 +0200
Subject: [py-dev] patch to allow usage of py.lib within non-administrator
	account on windows
Message-ID: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>

Hello!

atm. py.lib uses

os.tmpfile()

within fdcapture.py.


On windows os.tmpfile() tries to create the file within the root of
c:\; and it is quite good practice to disallow write access to this
directory for non-admin users (as this avoids killing crucial system
files)

So installation on windows using an user without write-access to c:\,
even setup.py fails with "permission.denied"

More info in:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2


It is fixable by using:

def maketmpfile(self):
        """ create a temporary file
        """
        #~ f = os.tmpfile()
        f=tempfile.TemporaryFile()
        newf = py.io.dupfile(f)
        f.close()
        return newf

    def writeorg(self, str):
        """ write a string to the original file descriptor
        """
        tempfp = tempfile.TemporaryFile()
        try:
            os.dup2(self._savefd, tempfp.fileno())
            tempfp.write(str)
        finally:
            tempfp.close()

within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.

I submit this patch into public domain.

Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!


From holger at merlinux.eu  Tue Jul 22 15:58:21 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 15:58:21 +0200
Subject: [py-dev] patch to allow usage of py.lib
	within	non-administrator account on windows
In-Reply-To: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
Message-ID: <20080722135821.GC22324@trillke.net>

Hi Harald! 

thanks for the report.  I think this got fixed in 0.9.1 - 
are you using 0.9.0, maybe?  

cheers,

holger

On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
> Hello!
> 
> atm. py.lib uses
> 
> os.tmpfile()
> 
> within fdcapture.py.
> 
> 
> On windows os.tmpfile() tries to create the file within the root of
> c:\; and it is quite good practice to disallow write access to this
> directory for non-admin users (as this avoids killing crucial system
> files)
> 
> So installation on windows using an user without write-access to c:\,
> even setup.py fails with "permission.denied"
> 
> More info in:
> 
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
> 
> 
> It is fixable by using:
> 
> def maketmpfile(self):
>         """ create a temporary file
>         """
>         #~ f = os.tmpfile()
>         f=tempfile.TemporaryFile()
>         newf = py.io.dupfile(f)
>         f.close()
>         return newf
> 
>     def writeorg(self, str):
>         """ write a string to the original file descriptor
>         """
>         tempfp = tempfile.TemporaryFile()
>         try:
>             os.dup2(self._savefd, tempfp.fileno())
>             tempfp.write(str)
>         finally:
>             tempfp.close()
> 
> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
> 
> I submit this patch into public domain.
> 
> Harald
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From haraldarminmassa at gmail.com  Tue Jul 22 16:15:04 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 16:15:04 +0200
Subject: [py-dev] patch to allow usage of py.lib within
	non-administrator account on windows
In-Reply-To: <20080722135821.GC22324@trillke.net>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
	<20080722135821.GC22324@trillke.net>
Message-ID: <7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>

I am using a svn checkout ...

svn co http://codespeak.net/svn/py/dist py-dist



On Tue, Jul 22, 2008 at 15:58, holger krekel <holger at merlinux.eu> wrote:
> Hi Harald!
>
> thanks for the report.  I think this got fixed in 0.9.1 -
> are you using 0.9.0, maybe?
>
> cheers,
>
> holger
>
> On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
>> Hello!
>>
>> atm. py.lib uses
>>
>> os.tmpfile()
>>
>> within fdcapture.py.
>>
>>
>> On windows os.tmpfile() tries to create the file within the root of
>> c:\; and it is quite good practice to disallow write access to this
>> directory for non-admin users (as this avoids killing crucial system
>> files)
>>
>> So installation on windows using an user without write-access to c:\,
>> even setup.py fails with "permission.denied"
>>
>> More info in:
>>
>> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
>>
>>
>> It is fixable by using:
>>
>> def maketmpfile(self):
>>         """ create a temporary file
>>         """
>>         #~ f = os.tmpfile()
>>         f=tempfile.TemporaryFile()
>>         newf = py.io.dupfile(f)
>>         f.close()
>>         return newf
>>
>>     def writeorg(self, str):
>>         """ write a string to the original file descriptor
>>         """
>>         tempfp = tempfile.TemporaryFile()
>>         try:
>>             os.dup2(self._savefd, tempfp.fileno())
>>             tempfp.write(str)
>>         finally:
>>             tempfp.close()
>>
>> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
>>
>> I submit this patch into public domain.
>>
>> Harald
>>
>> --
>> GHUM Harald Massa
>> persuadere et programmare
>> Harald Armin Massa
>> Spielberger Stra?e 49
>> 70435 Stuttgart
>> 0173/9409607
>> no fx, no carrier pidgeon
>> -
>> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
> collaborative expert contracting: http://merlinux.eu
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> pylib py.test/greenlets/svn APIs: http://pylib.org
>



-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!


From holger at merlinux.eu  Tue Jul 22 16:32:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 16:32:01 +0200
Subject: [py-dev] patch to allow usage of py.lib
	within	non-administrator account on windows
In-Reply-To: <7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>
References: <7be3f35d0807220315o5ef83322lfe1ff68d4a87246@mail.gmail.com>
	<20080722135821.GC22324@trillke.net>
	<7be3f35d0807220715t5e8c2e71lbd9fc9bdeb37d2e2@mail.gmail.com>
Message-ID: <20080722143201.GD22324@trillke.net>

On Tue, Jul 22, 2008 at 16:15 +0200, Harald Armin Massa wrote:
> I am using a svn checkout ...
> 
> svn co http://codespeak.net/svn/py/dist py-dist

i now synced py/release/0.9.1 to py/dist. 
Embarassingly, dist was even older than 0.9.1.

so i hope you now have a better version and things work. 

holger

> On Tue, Jul 22, 2008 at 15:58, holger krekel <holger at merlinux.eu> wrote:
> > Hi Harald!
> >
> > thanks for the report.  I think this got fixed in 0.9.1 -
> > are you using 0.9.0, maybe?
> >
> > cheers,
> >
> > holger
> >
> > On Tue, Jul 22, 2008 at 12:15 +0200, Harald Armin Massa wrote:
> >> Hello!
> >>
> >> atm. py.lib uses
> >>
> >> os.tmpfile()
> >>
> >> within fdcapture.py.
> >>
> >>
> >> On windows os.tmpfile() tries to create the file within the root of
> >> c:\; and it is quite good practice to disallow write access to this
> >> directory for non-admin users (as this avoids killing crucial system
> >> files)
> >>
> >> So installation on windows using an user without write-access to c:\,
> >> even setup.py fails with "permission.denied"
> >>
> >> More info in:
> >>
> >> http://groups.google.com/group/comp.lang.python/browse_thread/thread/4aa54e927f11bbc3?tvc=2
> >>
> >>
> >> It is fixable by using:
> >>
> >> def maketmpfile(self):
> >>         """ create a temporary file
> >>         """
> >>         #~ f = os.tmpfile()
> >>         f=tempfile.TemporaryFile()
> >>         newf = py.io.dupfile(f)
> >>         f.close()
> >>         return newf
> >>
> >>     def writeorg(self, str):
> >>         """ write a string to the original file descriptor
> >>         """
> >>         tempfp = tempfile.TemporaryFile()
> >>         try:
> >>             os.dup2(self._savefd, tempfp.fileno())
> >>             tempfp.write(str)
> >>         finally:
> >>             tempfp.close()
> >>
> >> within lines 42ff of py/io/fdcapture.py, of course after importing tempfile.
> >>
> >> I submit this patch into public domain.
> >>
> >> Harald
> >>
> >> --
> >> GHUM Harald Massa
> >> persuadere et programmare
> >> Harald Armin Massa
> >> Spielberger Stra?e 49
> >> 70435 Stuttgart
> >> 0173/9409607
> >> no fx, no carrier pidgeon
> >> -
> >> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> >> _______________________________________________
> >> py-dev mailing list
> >> py-dev at codespeak.net
> >> http://codespeak.net/mailman/listinfo/py-dev
> >>
> >
> > --
> > collaborative expert contracting: http://merlinux.eu
> > PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> > pylib py.test/greenlets/svn APIs: http://pylib.org
> >
> 
> 
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From haraldarminmassa at gmail.com  Tue Jul 22 17:45:47 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 17:45:47 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
Message-ID: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>

trying to use pytest with -r to run a browser and keep looking on my tests.

Without pypy installed: it fails with an exception of "skip "pypy not found")

with pypy checked out and put into pythonpath:

C:\ham\ibox25>pytest -r parsvalue.py
Server started, listening on port 1432


import py.__.test.rsession.webjs
from pypy.translator.js.helper import __show_traceback
from pypy.rlib.nonconst import NonConstant as NonConst


def some_strange_function_which_will_never_be_called():

    py.__.test.rsession.webjs.main()
    py.__.test.rsession.webjs.show_skip(NonConstant('aa'))
    py.__.test.rsession.webjs.show_traceback(NonConstant('aa'))
    py.__.test.rsession.webjs.show_info(NonConstant('aa'))
    py.__.test.rsession.webjs.hide_info()
    py.__.test.rsession.webjs.show_host(NonConstant('aa'))
    py.__.test.rsession.webjs.hide_host()
    py.__.test.rsession.webjs.hide_messagebox()
    py.__.test.rsession.webjs.opt_scroll()

[translation:info] Annotating&simplifying...
[translation:info] with policy: pypy.translator.js.main.JsPolicy

[translation:ERROR] Error:
[translation:ERROR]  UnboundLocalError: local variable 'c' referenced before ass
ignment
[translation] start debugger...
Traceback (most recent call last):
  File "C:\Python25\lib\SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "C:\Python25\lib\SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "C:\Python25\lib\SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python25\lib\SocketServer.py", line 522, in __init__
    self.handle()
  File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
    self.handle_one_request()
  File "C:\Python25\lib\BaseHTTPServer.py", line 310, in handle_one_request
    method()
  File "c:\libraries\pypy-dist\py\test\rsession\web.py", line 371, in do_GET
    method_to_call()
  File "c:\libraries\pypy-dist\py\test\rsession\web.py", line 408, in run_jssour
ce
    open(str(js_name), "w").write(javascript_source)
TypeError: argument 1 must be string or read-only character buffer, not None







-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!


From haraldarminmassa at gmail.com  Tue Jul 22 18:13:53 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 18:13:53 +0200
Subject: [py-dev] pytest -f fails on windows (with pypy-1.0.0 in pythonpath)
Message-ID: <7be3f35d0807220913ob5e7e71xf3f7feb244e34feb@mail.gmail.com>

C:\ham\ibox25>pytest -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=C:\ham\ibox25
Traceback (most recent call last):
  File "C:\Python25\Scripts\\py.test", line 4, in <module>
    py.test.cmdline.main()
  File "c:\libraries\pypy-1.0.0\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "c:\libraries\pypy-1.0.0\py\test\terminal\remote.py", line 82, in main
    failures = self.run_remote_session(failures)
  File "c:\libraries\pypy-1.0.0\py\test\terminal\remote.py", line 111, in run_re
mote_session
    return channel.receive()
  File "c:\libraries\pypy-1.0.0\py\execnet\channel.py", line 175, in receive
    raise self._getremoteerror() or EOFError()
EOFError

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!


From haraldarminmassa at gmail.com  Tue Jul 22 18:15:16 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Tue, 22 Jul 2008 18:15:16 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0 in
	pythonpath, another error)
Message-ID: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>

C:\ham\ibox25>pytest -f
* opening PopenGateway:  C:\Python25\python.exe
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=C:\ham\ibox25
Traceback (most recent call last):
  File "C:\Python25\Scripts\\py.test", line 4, in <module>
    py.test.cmdline.main()
  File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
    failures = session.main()
  File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
ain
    failures = self.run_remote_session(failures)
  File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
run_remote_session
    return channel.receive()
  File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
ve
    raise self._getremoteerror() or EOFError()
EOFError

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pidgeon
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!


From holger at merlinux.eu  Tue Jul 22 19:08:46 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 19:08:46 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
In-Reply-To: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
References: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
Message-ID: <20080722170846.GH22324@trillke.net>

Hi Harald, 

On Tue, Jul 22, 2008 at 17:45 +0200, Harald Armin Massa wrote:
> trying to use pytest with -r to run a browser and keep looking on my tests.
> 
> Without pypy installed: it fails with an exception of "skip "pypy not found")
> 
> with pypy checked out and put into pythonpath:
> 
> C:\ham\ibox25>pytest -r parsvalue.py
> Server started, listening on port 1432
> 
> 
> import py.__.test.rsession.webjs
> from pypy.translator.js.helper import __show_traceback
> from pypy.rlib.nonconst import NonConstant as NonConst

huah!  py.test should not require pypy here
but use the "source.js" that comes with package. 

I just fixed this with r56717 in http://codespeak.net/svn/py/dist 

So "py.test -r" should work now, also does on my windows installation. 
that mode is quite experimental but i think it's a very useful 
frontend in principle. 

best, holger


From holger at merlinux.de  Tue Jul 22 20:48:08 2008
From: holger at merlinux.de (holger krekel)
Date: Tue, 22 Jul 2008 20:48:08 +0200
Subject: [py-dev] py.test --looponfailing IOError
In-Reply-To: <AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>
References: <4025a36d0807111550s1e4da72ft409e23c779746264@mail.gmail.com>
	<20080712050137.GU759@trillke.net>
	<AF559A9AFB754F50A96AF2EEE79A2E95@gigabytex48dq>
Message-ID: <20080722184808.GI22324@trillke.net>

Hi Baptiste, hi Matthew, 

On Sun, Jul 20, 2008 at 17:25 +0200, Baptiste Lepilleur wrote:
> The main possible source I see to explain this random behavior is a race  
> condition. I find it is suspicious that it always occurs on the first 
> byte following the bootstrap code send on stdin. The only candidate I've 
> seen in the code is that stdin/stdout are set to binary mode at the end 
> of the bootstrap code, but I don't know if this could cause a byte to be 
> lost.

well, i don't know either but i think it was a good hint!

If i now set binary modes as early as possible on both sides
then things seem to work (i also had the problem that Matthew
got with "py.test -f" consistently and now it's gone,
and py.test py\execnet tests partially failed on my 
installation and now they pass). 

Could you maybe svn-checkout 

    http://codespeak.net/svn/py/release/0.9.x 

and after a "setup.py install" report back if it helps? 

cheers,

holger


> You'll need to create a c:\temp\_execnet directory (debug traces are 
> dumped there).
>
> ----- Original Message ----- From: "holger krekel" <holger at merlinux.de>
> To: "Matthew Edwards" <monopocalypse+py-dev at gmail.com>
> Cc: <py-dev at codespeak.net>
> Sent: Saturday, July 12, 2008 7:01 AM
> Subject: Re: [py-dev] py.test --looponfailing IOError
>
>
>> Hello Matthew,
>>
>> this seems to be a problem with the lower level network communication  
>> part.
>> also had other reports pointing to that.  I aim to look into
>> this next week when i am back from EuroPython ...
>>
>> can you meanwhile post your Python version and attach the test
>> file that triggered the problems?
>>
>> best & thanks,
>>
>> holger
>>
>>
>> On Sat, Jul 12, 2008 at 10:50 +1200, Matthew Edwards wrote:
>>> Hi
>>>
>>> I'm running py 0.9.1 (from tarfile) on Windows XP. I've written a
>>> couple of simple tests, which are in a folder called test. Whenever I
>>> do "py.test --looponfailing test/" I get the following output:
>>>
>>>
>>> inserting into sys.path: C:\Program Files\Python\Lib\site-packages
>>> * opening PopenGateway:  C:\Program Files\Python\python.exe
>>> Traceback (most recent call last):
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\bin\win32\\..\py.test", line 4, in
>>> <module>
>>>     py.test.cmdline.main()
>>>   File "C:\Program Files\Python\Lib\site-packages\py\test\cmdline.py",
>>> line 15, in main
>>>     failures = session.main()
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 82,
>>> in main
>>>     failures = self.run_remote_session(failures)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 100,
>>> in run_remote_session
>>>
>>>     gw, topdir = self._initslavegateway()
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\test\terminal\remote.py", line 97,
>>> in _initslavegateway
>>>     return py.execnet.PopenGateway(self.executable), topdir
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 66, in
>>> __init__
>>>     super(PopenGateway, self).__init__(cmd)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 55, in
>>> __init__
>>>     super(PopenCmdGateway, self).__init__(io=io)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 29, in
>>> __init__
>>>     self._remote_bootstrap_gateway(io)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 80, in
>>> _remote_bootstrap_gateway
>>>     super(PopenGateway, self)._remote_bootstrap_gateway(io, s)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\register.py", line 49, in
>>> _remote_bootstrap_gateway
>>>     io.write('%r\n' % source)
>>>   File "C:\Program
>>> Files\Python\Lib\site-packages\py\execnet\inputoutput.py", line 95, in
>>> write
>>>     self.outfile.write(data)
>>> IOError: [Errno 22] Invalid argument
>>>
>>> I can run the tests without --looponfailing.
>>>
>>> Any help appreciated
>>> Matthew
>>> _______________________________________________
>>> py-dev mailing list
>>> py-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/py-dev
>>>
>>
>> -- 
>> collaborative expert contracting: http://merlinux.eu
>> pylib py.test/greenlets/svn APIs: http://pylib.org
>> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>


> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From holger at merlinux.eu  Tue Jul 22 21:18:37 2008
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Jul 2008 21:18:37 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0
	in	pythonpath, another error)
In-Reply-To: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
Message-ID: <20080722191837.GK22324@trillke.net>

Hi Harald,

I don't see how this error is any different from the one before. 
pypy shouldn't matter at all for "py.test -f". 

In another mail (i assume you are following py-dev
currently) i tried to fix the "py.test -f" win32 problem. 
i just ported the fixes to svn/py/dist.  Could you 
do a re-install and see if things work for you now? 

cheers, 

holger

On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
> C:\ham\ibox25>pytest -f
> * opening PopenGateway:  C:\Python25\python.exe
> MASTER: initiated slave terminal session ->
> MASTER: send start info, topdir=C:\ham\ibox25
> Traceback (most recent call last):
>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
>     py.test.cmdline.main()
>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
>     failures = session.main()
>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
> ain
>     failures = self.run_remote_session(failures)
>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
> run_remote_session
>     return channel.receive()
>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
> ve
>     raise self._getremoteerror() or EOFError()
> EOFError
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pidgeon
> -
> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From holger at merlinux.eu  Wed Jul 23 08:27:51 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 08:27:51 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
Message-ID: <20080723062751.GM22324@trillke.net>

Hi folks,

yesterday, Harald asked me on #pylib regarding integration of
py.test with Scite and just now i replied to a similar 
issue that Osmo posted on the issue tracker.  See below. 

I'd like to ask here as well:  What would you like
for py.test's output in order for it to be most helpful
with your mode of testing and particularly integration 
with editors?   

You may also subscribe to 

    https://codespeak.net/issue/py-dev/issue57

if you want to follow the implementation of this feature. 

cheers, 

holger

P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
      If you have anything *now* is a good time to file. 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 

----- Forwarded message from holger krekel <hpk at trillke.net> -----

From: holger krekel <hpk at trillke.net>
To: Osmo Salomaa <py-dev-issue at codespeak.net>
Cc: hpk at trillke.net, otsaloma at cc.hut.fi
Subject: Re: [issue57] Emacs and py.test tracebacks
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-Spambayes-Classification: ham; 0.00

Hi Osmo, 

thanks for your report!  If you have the following test_file.py:

    def somefunc():
        assert 0

    def test_func():
        somefunc()

you would probably like to get 

    /full/path/to/test_file1.py:3

in a line somewhere in the long traceback for this 
failing test function, right?  

What do you think about always adding a "summary" at 
the end of a test run that looks like this? 

    /full/path/to/test_file1.py:3  AssertionError: 0 
    /full/path/to/test_file3.py:47  ValueError: 0 ...
    ...

Or, to ask more generally, what would be most helpful 
output for your mode of testing with emacs? 

holger

        
On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote:
> New submission from Osmo Salomaa <otsaloma at cc.hut.fi>:
> 
> Currently the filename and line numbers in py.test's long tracebacks are of form
> "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that format.
> Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon) allows
> Emacs to parse that and render it as a clickable link. Emacs is able to parse
> the filenames and line numbers in the short tracebacks, but the links don't work
> because it would require the full filepath.
> 
> I suspect other editors may suffer similarly, because there is no easy way to
> know that the opening bracket is not a part of the filename.
> 
> Based on a quick look only a one line change to py/test/representation.py,
> method 'repr_failure_tblong' would be needed to fix the long tracebacks.
> 
> ----------
> effort: easy
> messages: 147
> nosy: hpk, otsaloma
> priority: wish
> release: ???
> status: unread
> title: Emacs and py.test tracebacks
> 
> _______________________________________________________
> py lib development tracker <py-dev-issue at codespeak.net>
> <https://codespeak.net/issue/py-dev/issue57>
> _______________________________________________________
> 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


----- End forwarded message -----



From haraldarminmassa at gmail.com  Wed Jul 23 10:14:03 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:14:03 +0200
Subject: [py-dev] pytest -r does not work ... even with pypy present
In-Reply-To: <20080722170846.GH22324@trillke.net>
References: <7be3f35d0807220845g4685f1f3r39599880c4914c31@mail.gmail.com>
	<20080722170846.GH22324@trillke.net>
Message-ID: <7be3f35d0807230114t4a9e2755h4de973751c86fabe@mail.gmail.com>

Holger,

> huah!  py.test should not require pypy here
> but use the "source.js" that comes with package.
> I just fixed this with r56717 in http://codespeak.net/svn/py/dist
>
> So "py.test -r" should work now, also does on my windows installation.
> that mode is quite experimental but i think it's a very useful
> frontend in principle.

It works with r56717. At least it one-shot-works, that is:

pytest -r <testobjekt> gives a browser with the used html-site.

great work, thanks!!!

##########
What would be even greater:

make pytest loop on one file / directory, allways putting out
test-results as HTML. Redoing all tests on file change.

THAT would give a really wonderfull testing system: a pytest-Server
scanning (or using win32 Directory Change notifcation) the relevant
project and putting out test-information to http ... have one screen
comitted to show test results, and hack right on.

Harald


-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!


From haraldarminmassa at gmail.com  Wed Jul 23 10:17:34 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:17:34 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0 in
	pythonpath, another error)
In-Reply-To: <20080722191837.GK22324@trillke.net>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
	<20080722191837.GK22324@trillke.net>
Message-ID: <7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>

> I don't see how this error is any different from the one before.
> pypy shouldn't matter at all for "py.test -f".

correct. Only difference in errors:

with pypy installed and in python-path, py.test uses channel.py form
the pypy-distribution, without pypy installed (or not in python path),
py.test uses it's own "channel.py"

That maybe the same invitation to trouble than the shared library hell
in some operating systems.... that's why I point out this behaviour;
because getting different behaviours from a testing-system depending
on the libraries installed on the system is challenging :)

Thanks for looking over the errors & fixing py.test to work,

Harald



> On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
>> C:\ham\ibox25>pytest -f
>> * opening PopenGateway:  C:\Python25\python.exe
>> MASTER: initiated slave terminal session ->
>> MASTER: send start info, topdir=C:\ham\ibox25
>> Traceback (most recent call last):
>>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
>>     py.test.cmdline.main()
>>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
>>     failures = session.main()
>>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
>> ain
>>     failures = self.run_remote_session(failures)
>>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
>> run_remote_session
>>     return channel.receive()
>>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
>> ve
>>     raise self._getremoteerror() or EOFError()
>> EOFError
>>
>> --
>> GHUM Harald Massa
>> persuadere et programmare
>> Harald Armin Massa
>> Spielberger Stra?e 49
>> 70435 Stuttgart
>> 0173/9409607
>> no fx, no carrier pidgeon
>> -
>> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
> collaborative expert contracting: http://merlinux.eu
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> pylib py.test/greenlets/svn APIs: http://pylib.org
>



-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!


From haraldarminmassa at gmail.com  Wed Jul 23 10:20:40 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 10:20:40 +0200
Subject: [py-dev] oncoming 0.9.2 release
Message-ID: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>

Whish-list:

pytest -e
pytest --testforever

includes --startsserver and --runbrowser, loops "forever" until
Ctrl+Break on the given file / directory / filtered files and
publishes results on Webport.
Bonus points for really showing a traffic light :)

Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!


From schmir at gmail.com  Wed Jul 23 12:19:12 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 12:19:12 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>

On Wed, Jul 23, 2008 at 8:27 AM, holger krekel <holger at merlinux.eu> wrote:
>
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>      If you have anything *now* is a good time to file.

The ability to mark test cases as "expected failures" would be nice.

Regards,
- Ralf


From holger at merlinux.eu  Wed Jul 23 12:24:18 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:24:18 +0200
Subject: [py-dev] pytest -f fails on windows (without pypy-1.0.0
	in	pythonpath, another error)
In-Reply-To: <7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>
References: <7be3f35d0807220915l24e4425an56a878fe99fa44c9@mail.gmail.com>
	<20080722191837.GK22324@trillke.net>
	<7be3f35d0807230117l674a6e02q5e40f105749d4696@mail.gmail.com>
Message-ID: <20080723102418.GN22324@trillke.net>

Hi Harald, 

On Wed, Jul 23, 2008 at 10:17 +0200, Harald Armin Massa wrote:
> > I don't see how this error is any different from the one before.
> > pypy shouldn't matter at all for "py.test -f".
> 
> correct. Only difference in errors:
> 
> with pypy installed and in python-path, py.test uses channel.py form
> the pypy-distribution, without pypy installed (or not in python path),
> py.test uses it's own "channel.py"

svn/pypy/dist/pypy has an svn:external sibling "py" lib at
svn/pypy/dist/py and if you put pypy/dist on PYTHONPATH 
then the py lib this py lib is used.  So you are still
using a py lib's channel, not a "pypy one" :) 

> That maybe the same invitation to trouble than the shared library hell
> in some operating systems.... that's why I point out this behaviour;
> because getting different behaviours from a testing-system depending
> on the libraries installed on the system is challenging :)

I consider it a relatively normal PYTHONPATH issue.  
 
> Thanks for looking over the errors & fixing py.test to work,

thanks for reporting/pushing! 

holger
 
> > On Tue, Jul 22, 2008 at 18:15 +0200, Harald Armin Massa wrote:
> >> C:\ham\ibox25>pytest -f
> >> * opening PopenGateway:  C:\Python25\python.exe
> >> MASTER: initiated slave terminal session ->
> >> MASTER: send start info, topdir=C:\ham\ibox25
> >> Traceback (most recent call last):
> >>   File "C:\Python25\Scripts\\py.test", line 4, in <module>
> >>     py.test.cmdline.main()
> >>   File "C:\Python25\Lib\site-packages\py\test\cmdline.py", line 15, in main
> >>     failures = session.main()
> >>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 82, in m
> >> ain
> >>     failures = self.run_remote_session(failures)
> >>   File "C:\Python25\Lib\site-packages\py\test\terminal\remote.py", line 111, in
> >> run_remote_session
> >>     return channel.receive()
> >>   File "C:\Python25\Lib\site-packages\py\execnet\channel.py", line 175, in recei
> >> ve
> >>     raise self._getremoteerror() or EOFError()
> >> EOFError
> >>
> >> --
> >> GHUM Harald Massa
> >> persuadere et programmare
> >> Harald Armin Massa
> >> Spielberger Stra?e 49
> >> 70435 Stuttgart
> >> 0173/9409607
> >> no fx, no carrier pidgeon
> >> -
> >> EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
> >> _______________________________________________
> >> py-dev mailing list
> >> py-dev at codespeak.net
> >> http://codespeak.net/mailman/listinfo/py-dev
> >>
> >
> > --
> > collaborative expert contracting: http://merlinux.eu
> > PyPy  Python/Compiler tool chain: http://codespeak.net/pypy
> > pylib py.test/greenlets/svn APIs: http://pylib.org
> >
> 
> 
> 
> -- 
> GHUM Harald Massa
> persuadere et programmare
> Harald Armin Massa
> Spielberger Stra?e 49
> 70435 Stuttgart
> 0173/9409607
> no fx, no carrier pigeon
> -
> EuroPython 2009 will take place in Birmingham - Stay tuned!
> 

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From johnny at johnnydebris.net  Wed Jul 23 12:26:43 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 23 Jul 2008 12:26:43 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
 tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <48870763.1020107@johnnydebris.net>

holger krekel wrote:
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>       If you have anything *now* is a good time to file. 
>
>   
I would really, really like to have py.path.svnwc.status() parse XML 
rather than text (using regexps) as it does now, to fix (e.g.?) problems 
with spaces in the username... I fiddle-fixed this in 0.9.1, but it 
turns out not to work in all cases, and obviously parsing XML is more 
solid. Should be relatively easy to fix, and I wouldn't mind doing it 
myself, I just didn't find time yet... :(

Cheers,

Guido


From holger at merlinux.eu  Wed Jul 23 12:41:32 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:41:32 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
Message-ID: <20080723104132.GO22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 12:19 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 8:27 AM, holger krekel <holger at merlinux.eu> wrote:
> >
> > P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
> >      If you have anything *now* is a good time to file.
> 
> The ability to mark test cases as "expected failures" would be nice.

Yes, i also want something where i can checkin tests 
that are marked as bugs and have some clever reporting
anhd command line options for this (at best even 
be able to have a link to an issue tracker). 

maybe: 

    @py.test.mark(bug=number or string, url=URL) 
    def test_something():
        ...

although i would like this to also work in setup_*
functions and in python 2.3 nicely, i think. 
I imagine such a decorator to just set attributes 
on the function, not provide a new function.
and the py.test machinery to recognize these 
attributes.  Makes sense? 

Not sure i'd like to consider this for 0.9.2 to be honest
which i rather want to be a bugfix release - at least
not to introduce new concepts.  But i am also heavily
working on a cleanup / refactoring branch which i 
consider the base for a 1.0 hopefully not too far
in the future. 

cheers, 

holger


From holger at merlinux.eu  Wed Jul 23 12:44:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:44:01 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <48870763.1020107@johnnydebris.net>
References: <20080723062751.GM22324@trillke.net>
	<48870763.1020107@johnnydebris.net>
Message-ID: <20080723104401.GP22324@trillke.net>

Hi Guido, 

On Wed, Jul 23, 2008 at 12:26 +0200, Guido Wesdorp wrote:
> holger krekel wrote:
> > P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
> >       If you have anything *now* is a good time to file. 
> >
> >   
> I would really, really like to have py.path.svnwc.status() parse XML 
> rather than text (using regexps) as it does now, to fix (e.g.?) problems 
> with spaces in the username... I fiddle-fixed this in 0.9.1, but it 
> turns out not to work in all cases, and obviously parsing XML is more 
> solid. Should be relatively easy to fix, and I wouldn't mind doing it 
> myself, I just didn't find time yet... :(

Makes sense to me, hope you do find the time! :) 

At the time when py.path.svn started there was not much --xml
support from svn.  As long as we are compatible to svn >=1.3 
we are fine, i think.  Would be nice if you go for that and indeed
shouldn't be hard and easy to test that the xml parsing is
right (easier than the current mess). 

cheers,

holger


From holger at merlinux.eu  Wed Jul 23 12:54:43 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 12:54:43 +0200
Subject: [py-dev] oncoming 0.9.2 release
In-Reply-To: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>
References: <7be3f35d0807230120y3cc20515x68ebfd7322a21bed@mail.gmail.com>
Message-ID: <20080723105443.GQ22324@trillke.net>

Hi Harald, 

On Wed, Jul 23, 2008 at 10:20 +0200, Harald Armin Massa wrote:
> Whish-list:
> 
> pytest -e
> pytest --testforever
> 
> includes --startsserver and --runbrowser, loops "forever" until
> Ctrl+Break on the given file / directory / filtered files and
> publishes results on Webport.
> Bonus points for really showing a traffic light :)

:) 

This is nothing for 0.9.2, i am afraid.  Particularly 
since i am relatively clueless about the browser reporter
currently.  But if you are up to do a patch that does
what you suggest i'd consider it. 

sidenote: I promise to support anyone going for
a (new) nice AJAX frontend :)  

sidenote++: 
For 1.0 i am currently revamping distributed testing,
would like to have a native cross-platform testing 
mode - eventually i'd like this to be possible: 

    py.test --plat=win32,linux,osx --looponfailing --rep=browser 

although the "plat" option is probably rather for 1.1. 

For 0.9.2 i'd like to focus on integration issues with
editors, win32 and other fixes and packaging issues. 
plus small improvements :) 

holger


From schmir at gmail.com  Wed Jul 23 13:04:16 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 13:04:16 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723104132.GO22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
Message-ID: <932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>

On Wed, Jul 23, 2008 at 12:41 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Ralf,
>> The ability to mark test cases as "expected failures" would be nice.
>
> Yes, i also want something where i can checkin tests
> that are marked as bugs and have some clever reporting
> anhd command line options for this (at best even
> be able to have a link to an issue tracker).
>
> maybe:
>
>    @py.test.mark(bug=number or string, url=URL)
>    def test_something():
>        ...

I've written a quick hack (which doesn't integrate nicely with
py.test). It can be viewed here:
http://code.pediapress.com/hg/mwlib/file/b75d189a01a2/mwlib/xfail.py
It checks the functions docstring for a link to the issue tracker. I'm
not quite sure if you want to have that decorator take an issue
number/link. When you've fixed that bug, you'll remove the decorator
and loose that valuable information.

>
> although i would like this to also work in setup_*
> functions and in python 2.3 nicely, i think.
> I imagine such a decorator to just set attributes
> on the function, not provide a new function.
> and the py.test machinery to recognize these
> attributes.  Makes sense?

sounds good.

>
> Not sure i'd like to consider this for 0.9.2 to be honest
> which i rather want to be a bugfix release - at least

ok.

> not to introduce new concepts.  But i am also heavily
> working on a cleanup / refactoring branch which i
> consider the base for a 1.0 hopefully not too far
> in the future.

nice.
Is there a list of active branches? the last time I looked at the svn
repo, trunk looked very quiet (or I used a bad path).



Thinking about it I have maybe another issue for 0.9.2. When using easy_install
the greenlets module is not installed correctly. I haven't looked into
this (python setup.py install works). But I will probably have a look
at it in the next days....


Regards
- Ralf


From johnny at johnnydebris.net  Wed Jul 23 13:10:51 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 23 Jul 2008 13:10:51 +0200
Subject: [py-dev] last minute features for 0.9.2 (Re: py.test and
 editors (Re: [issue57] Emacs and py.test tracebacks))
In-Reply-To: <17CC2E6F-0578-437B-AA09-9A2CB3728E66@jasper.es>
References: <20080723062751.GM22324@trillke.net>
	<48870763.1020107@johnnydebris.net>
	<17CC2E6F-0578-437B-AA09-9A2CB3728E66@jasper.es>
Message-ID: <488711BB.8030705@johnnydebris.net>

Jasper Spaans wrote:
> Sounds like a welcome improvement as we're using that code and it 
> feels a bit icky right now; I can free some hours the coming days to 
> help implement/test that.
>
Jasper: I'll see you (in person) thursday, so let's set a date do do 
some pairing then...

Cheers,

Guido


From holger at merlinux.eu  Wed Jul 23 13:34:26 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 13:34:26 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
Message-ID: <20080723113426.GS22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 13:04 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 12:41 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Ralf,
> >> The ability to mark test cases as "expected failures" would be nice.
> >
> > Yes, i also want something where i can checkin tests
> > that are marked as bugs and have some clever reporting
> > anhd command line options for this (at best even
> > be able to have a link to an issue tracker).
> >
> > maybe:
> >
> >    @py.test.mark(bug=number or string, url=URL)
> >    def test_something():
> >        ...
> 
> I've written a quick hack (which doesn't integrate nicely with
> py.test). It can be viewed here:
> http://code.pediapress.com/hg/mwlib/file/b75d189a01a2/mwlib/xfail.py
> It checks the functions docstring for a link to the issue tracker. I'm
> not quite sure if you want to have that decorator take an issue
> number/link. When you've fixed that bug, you'll remove the decorator
> and loose that valuable information.

I think it's fine to have the decorator mostly stay forever.  

I think that py.test should usually always run the 
"bug" test but report them specially (no tracebacks) 
if they fail and maybe 

    .........bb...................

for the progress bar etc.  However, py.test would not
complain if it passes.  Then, for example, 

    py.test --bugs=173,...,...

would run all tests that are marked with these bug numbers
and turn on full traceback reporting when they fail.  

There are also other things that i'd like to tell 
py.test about a test, e.g. having it run "boxed", 
i.e. isolated so that it can segfault without 
disrupting the testing process. 

> > although i would like this to also work in setup_*
> > functions and in python 2.3 nicely, i think.
> > I imagine such a decorator to just set attributes
> > on the function, not provide a new function.
> > and the py.test machinery to recognize these
> > attributes.  Makes sense?
> 
> sounds good.
> 
> >
> > Not sure i'd like to consider this for 0.9.2 to be honest
> > which i rather want to be a bugfix release - at least
> 
> ok.
> 
> > not to introduce new concepts.  But i am also heavily
> > working on a cleanup / refactoring branch which i
> > consider the base for a 1.0 hopefully not too far
> > in the future.
> 
> nice.
> Is there a list of active branches? the last time I looked at the svn
> repo, trunk looked very quiet (or I used a bad path).

I just removed some branches in svn/py/branch which i think were 
already merged.  py/trunk is mostly what is in 0.9.1 plus a
few more improvements (and hacks).  Active development i 
currently do in the event branch which i'd like to 
merge to trunk hopefully soon. 
 
> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> the greenlets module is not installed correctly. I haven't looked into
> this (python setup.py install works). But I will probably have a look
> at it in the next days....

cool.  You may just work in release/0.9.x or branch off from there. 
The current way of compiling c-extension modules is a hack IIRC ... 
mostly because i am a bit clueless on how to this correctly,
particularly for win32. 

best, 

holger


From schmir at gmail.com  Wed Jul 23 14:43:45 2008
From: schmir at gmail.com (Ralf Schmitt)
Date: Wed, 23 Jul 2008 14:43:45 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and py.test
	tracebacks)
In-Reply-To: <20080723113426.GS22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
Message-ID: <932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>

On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:

> I think it's fine to have the decorator mostly stay forever.
>

It looks like you want that decorator to attach more information to
test functions.
In the case where you only want to mark a test as expected failure, I
think it should be removed.

> I think that py.test should usually always run the
> "bug" test but report them specially (no tracebacks)
> if they fail and maybe
>
>    .........bb...................
>
> for the progress bar etc.  However, py.test would not
> complain if it passes.  Then, for example,

-0 for not complaining when it passes
I don't like that idea, but I also currently don't have the time to
argue about it. twisted's trial raises an error for expected failures
that succeed.

>
>    py.test --bugs=173,...,...
>
> would run all tests that are marked with these bug numbers
> and turn on full traceback reporting when they fail.
>
> There are also other things that i'd like to tell
> py.test about a test, e.g. having it run "boxed",
> i.e. isolated so that it can segfault without
> disrupting the testing process.

I would have used that a few times in the past..but I can surely live
without such a feature.

>> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
>> the greenlets module is not installed correctly. I haven't looked into
>> this (python setup.py install works). But I will probably have a look
>> at it in the next days....
>
> cool.  You may just work in release/0.9.x or branch off from there.
> The current way of compiling c-extension modules is a hack IIRC ...
> mostly because i am a bit clueless on how to this correctly,
> particularly for win32.

I thought the trick was that it automatically compiles the c modules
on demand when it is imported?


From holger at merlinux.eu  Wed Jul 23 14:52:22 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 23 Jul 2008 14:52:22 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>
References: <20080723062751.GM22324@trillke.net>
	<932f8baf0807230319r572ae634v93a07e2b8cc8b490@mail.gmail.com>
	<20080723104132.GO22324@trillke.net>
	<932f8baf0807230404g28fdc895q642a90623d9bc27@mail.gmail.com>
	<20080723113426.GS22324@trillke.net>
	<932f8baf0807230543vbb52d86kf8c8a094d6d02474@mail.gmail.com>
Message-ID: <20080723125222.GT22324@trillke.net>

Hi Ralf, 

On Wed, Jul 23, 2008 at 14:43 +0200, Ralf Schmitt wrote:
> On Wed, Jul 23, 2008 at 1:34 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > I think it's fine to have the decorator mostly stay forever.
> >
> 
> It looks like you want that decorator to attach more information to
> test functions.
> In the case where you only want to mark a test as expected failure, I
> think it should be removed.
> 
> > I think that py.test should usually always run the
> > "bug" test but report them specially (no tracebacks)
> > if they fail and maybe
> >
> >    .........bb...................
> >
> > for the progress bar etc.  However, py.test would not
> > complain if it passes.  Then, for example,
> 
> -0 for not complaining when it passes
> I don't like that idea, but I also currently don't have the time to
> argue about it. twisted's trial raises an error for expected failures
> that succeed.

The "not complaining" part is not essential to me. 
We'll find a good solution i am sure.  After all one 
could specify "fixed=True", "shouldfail=True" or whatever
once the basic machinery is there to satisfy use cases.

> >    py.test --bugs=173,...,...
> >
> > would run all tests that are marked with these bug numbers
> > and turn on full traceback reporting when they fail.
> >
> > There are also other things that i'd like to tell
> > py.test about a test, e.g. having it run "boxed",
> > i.e. isolated so that it can segfault without
> > disrupting the testing process.
> 
> I would have used that a few times in the past..but I can surely live
> without such a feature.

for large projects it could evolve as being really helpful,
particularly if you can also specify platforms. 
 
> >> Thinking about it I have maybe another issue for 0.9.2. When using easy_install
> >> the greenlets module is not installed correctly. I haven't looked into
> >> this (python setup.py install works). But I will probably have a look
> >> at it in the next days....
> >
> > cool.  You may just work in release/0.9.x or branch off from there.
> > The current way of compiling c-extension modules is a hack IIRC ...
> > mostly because i am a bit clueless on how to this correctly,
> > particularly for win32.
> 
> I thought the trick was that it automatically compiles the c modules
> on demand when it is imported?

yes - but this is not the right thing for packaged 
or setup.py installs.  One may not have write access 
to the installation path for starters.  Or no 
c-compiler is available on win32 etc. 

holger

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From haraldarminmassa at gmail.com  Wed Jul 23 17:33:41 2008
From: haraldarminmassa at gmail.com (Harald Armin Massa)
Date: Wed, 23 Jul 2008 17:33:41 +0200
Subject: [py-dev] allow installation on windows with not-admin account
Message-ID: <7be3f35d0807230833w7138fd38p7b03ce7fd9e8a987@mail.gmail.com>

Hello,

setup.py fails on windows with limited users because

k = _winreg.OpenKey(reg, key, 0, _winreg.KEY_WRITE)

is not allowed (raises windows error)

I suggest to patch with try, except within py\misc\_dist.py lines 94ff
as follows:


def addbindir2path():
    if sys.platform != 'win32' or not winextensions:
        return

    # Add py/bin to PATH environment variable
    bindir = os.path.join(sysconfig.get_python_lib(), "py", "bin", "win32")
    reg = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE)
    key = r"SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
    path = get_registry_value(reg, key, "Path")
    path += ";" + bindir
    print "Setting PATH to:", path
    try:
        set_registry_value(reg, key, "Path", path)
    except WindowsError:
        print "could not write new path to registry. permissions?"
        return
    #print "Current PATH is:", get_registry_value(reg, key, "Path")

    # Propagate changes throughout the system
    win32gui.SendMessageTimeout(win32con.HWND_BROADCAST,
        win32con.WM_SETTINGCHANGE, 0, "Environment",
        win32con.SMTO_ABORTIFHUNG, 5000)

    # Propagate changes to current command prompt
    os.system("set PATH=%s" % path)


Harald

-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!


From holger at merlinux.eu  Fri Jul 25 11:22:04 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Jul 2008 11:22:04 +0200
Subject: [py-dev] py.test and editors (Re: [issue57] Emacs and
	py.test	tracebacks)
In-Reply-To: <20080723062751.GM22324@trillke.net>
References: <20080723062751.GM22324@trillke.net>
Message-ID: <20080725092204.GE22324@trillke.net>

Hi again,

so in the course of issue57 i changed the output format 
to integrate better with editors.  The 

    http://codespeak.net/svn/py/release/0.9.x 

and dist branches contain the changes. 

holger


On Wed, Jul 23, 2008 at 08:27 +0200, holger krekel wrote:
> Hi folks,
> 
> yesterday, Harald asked me on #pylib regarding integration of
> py.test with Scite and just now i replied to a similar 
> issue that Osmo posted on the issue tracker.  See below. 
> 
> I'd like to ask here as well:  What would you like
> for py.test's output in order for it to be most helpful
> with your mode of testing and particularly integration 
> with editors?   
> 
> You may also subscribe to 
> 
>     https://codespeak.net/issue/py-dev/issue57
> 
> if you want to follow the implementation of this feature. 
> 
> cheers, 
> 
> holger
> 
> P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
>       If you have anything *now* is a good time to file. 
> 
> -- 
> collaborative expert contracting: http://merlinux.eu 
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
> pylib py.test/greenlets/svn APIs: http://pylib.org 
> 
> ----- Forwarded message from holger krekel <hpk at trillke.net> -----
> 
> From: holger krekel <hpk at trillke.net>
> To: Osmo Salomaa <py-dev-issue at codespeak.net>
> Cc: hpk at trillke.net, otsaloma at cc.hut.fi
> Subject: Re: [issue57] Emacs and py.test tracebacks
> User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
> X-Spambayes-Classification: ham; 0.00
> 
> Hi Osmo, 
> 
> thanks for your report!  If you have the following test_file.py:
> 
>     def somefunc():
>         assert 0
> 
>     def test_func():
>         somefunc()
> 
> you would probably like to get 
> 
>     /full/path/to/test_file1.py:3
> 
> in a line somewhere in the long traceback for this 
> failing test function, right?  
> 
> What do you think about always adding a "summary" at 
> the end of a test run that looks like this? 
> 
>     /full/path/to/test_file1.py:3  AssertionError: 0 
>     /full/path/to/test_file3.py:47  ValueError: 0 ...
>     ...
> 
> Or, to ask more generally, what would be most helpful 
> output for your mode of testing with emacs? 
> 
> holger
> 
>         
> On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote:
> > New submission from Osmo Salomaa <otsaloma at cc.hut.fi>:
> > 
> > Currently the filename and line numbers in py.test's long tracebacks are of form
> > "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that format.
> > Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon) allows
> > Emacs to parse that and render it as a clickable link. Emacs is able to parse
> > the filenames and line numbers in the short tracebacks, but the links don't work
> > because it would require the full filepath.
> > 
> > I suspect other editors may suffer similarly, because there is no easy way to
> > know that the opening bracket is not a part of the filename.
> > 
> > Based on a quick look only a one line change to py/test/representation.py,
> > method 'repr_failure_tblong' would be needed to fix the long tracebacks.
> > 
> > ----------
> > effort: easy
> > messages: 147
> > nosy: hpk, otsaloma
> > priority: wish
> > release: ???
> > status: unread
> > title: Emacs and py.test tracebacks
> > 
> > _______________________________________________________
> > py lib development tracker <py-dev-issue at codespeak.net>
> > <https://codespeak.net/issue/py-dev/issue57>
> > _______________________________________________________
> > 
> 
> -- 
> collaborative expert contracting: http://merlinux.eu 
> PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
> pylib py.test/greenlets/svn APIs: http://pylib.org 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From johnny at johnnydebris.net  Wed Jul 30 12:15:56 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Wed, 30 Jul 2008 12:15:56 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
Message-ID: <48903F5C.5010306@johnnydebris.net>

Hi!

Yesterday I had some time to spare so decided to work on using the XML 
output of svn st rather than the text to get py.path.svnwc.status() 
reports. After some refactoring, adding some tests and battling the test 
code a bit, I ended up with something that at least satisfies the tests 
- they all work with the new code, using the old code as fallback if the 
--xml switch gets refused.

I did this on a branch, as at first it seemed like I had to do a lot of 
refactoring of the tests (which I ended up mostly rolling back). The URL 
of this branch is:

https://codespeak.net/svn/py/branch/guido-svnwc-xml-status

Unfortunately I didn't find the time to test on any platform other than 
Linux, using SVN v. 1.3. Therefore I think the code, in its current 
status, shouldn't be merged into the next release branch, or at least 
not without more testing (this also because I have the feeling a lot of 
edge cases aren't covered in the tests). However, what is there should 
be feature-complete...

If people feel like testing, I'd greatly appreciate it... If not, I'll 
do it the first opportunity I have. I think the most important questions 
now are if it works on Windows, and on SVN versions besides 1.3. If 
that's done I think it can be merged into trunk and release branch.

Cheers,

Guido


From holger at merlinux.eu  Wed Jul 30 20:55:00 2008
From: holger at merlinux.eu (holger krekel)
Date: Wed, 30 Jul 2008 20:55:00 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <48903F5C.5010306@johnnydebris.net>
References: <48903F5C.5010306@johnnydebris.net>
Message-ID: <20080730185500.GM9619@trillke.net>

Hi Guido, 

On Wed, Jul 30, 2008 at 12:15 +0200, Guido Wesdorp wrote:
> Yesterday I had some time to spare so decided to work on using the XML 
> output of svn st rather than the text to get py.path.svnwc.status() 
> reports. After some refactoring, adding some tests and battling the test 
> code a bit, I ended up with something that at least satisfies the tests 
> - they all work with the new code, using the old code as fallback if the 
> --xml switch gets refused.
> 
> I did this on a branch, as at first it seemed like I had to do a lot of 
> refactoring of the tests (which I ended up mostly rolling back). The URL 
> of this branch is:
> 
> https://codespeak.net/svn/py/branch/guido-svnwc-xml-status
>
> Unfortunately I didn't find the time to test on any platform other than 
> Linux, using SVN v. 1.3. Therefore I think the code, in its current 
> status, shouldn't be merged into the next release branch, or at least 
> not without more testing (this also because I have the feeling a lot of 
> edge cases aren't covered in the tests). However, what is there should 
> be feature-complete...

first feedback (i am not much working currently, am ill/feverish):
tests pass for me on Win XP with svn 1.4.4.  They take 38
seconds instead of 24 on dist, though. 

cheers,

holger


From johnny at johnnydebris.net  Thu Jul 31 08:30:02 2008
From: johnny at johnnydebris.net (Guido Wesdorp)
Date: Thu, 31 Jul 2008 08:30:02 +0200
Subject: [py-dev] svn st --xml support for py.path - progress
In-Reply-To: <20080730185500.GM9619@trillke.net>
References: <48903F5C.5010306@johnnydebris.net>
	<20080730185500.GM9619@trillke.net>
Message-ID: <48915BEA.5090409@johnnydebris.net>

holger krekel wrote:
> first feedback (i am not much working currently, am ill/feverish):
> tests pass for me on Win XP with svn 1.4.4.  They take 38
> seconds instead of 24 on dist, though. 
>
>   
That's rather strange, as I (unexpectedly) didn't touch the test code 
much... But I'll investigate.

Cheers,

Guido