Closed gitlab-importer closed 4 months ago
gitlab-importer
commented
19 years ago In Heptapod by bitbucket_importer on May 15, 2005, 09:59
Created originally on Bitbucket by ctismer (Christian Tismer)
make sure that all tests work on windows
or at least that they know if they don't work.
py.test (I think) has problems here.
test_complex uses machine-specific notations.
I think this is urgent because a release
will probably trigger very many windows users.In Heptapod by bitbucket_importer on May 15, 2005, 10:02
Created originally on Bitbucket by hpk
On Sun, May 15, 2005 at 10:59 +0000, Christian Tismer wrote:
> make sure that all tests work on windows
> or at least that they know if they don't work.
> py.test (I think) has problems here.
I would hope that a simple pypy/test_all.py basically
runs all the tests on win32, no?
py.test does have problems when you use certain
combination of features (mostly remotely running tests)
but it should work for plain win32 usage already.
holgerIn Heptapod by @arigo on May 15, 2005, 10:06
As far as I know we can't run the compliance tests on Windows, as I
believe that os.system("command >>out 2>>err") doesn't work there.In Heptapod by bitbucket_importer on May 15, 2005, 10:10
Created originally on Bitbucket by hpk
On Sun, May 15, 2005 at 13:06 +0200, Armin Rigo wrote:
> As far as I know we can't run the compliance tests on Windows, as I
> believe that os.system("command >>out 2>>err") doesn't work there.
indeed, it would be nice to have an equivalent mechanism working
for win32. I wouldn't neccessarily consider the 'cannot-run-compliancy'
issue as criticial for the M0.5 release, though.
holgerIn Heptapod by bitbucket_importer on May 15, 2005, 10:18
Created originally on Bitbucket by ctismer (Christian Tismer)
Armin Rigo wrote:
> As far as I know we can't run the compliance tests on Windows, as I
> believe that os.system("command >>out 2>>err") doesn't work there.
I didn't run the compliance tests on windows, yet.
But even with the standard tests, there are a few
things not working.
Even worse, and probably much more urgent to make
windows users happy:
pypy has problems with PythonWin. You cannot translate
correctly, because we step into PyWin internal objects.In Heptapod by bitbucket_importer on May 15, 2005, 10:25
Created originally on Bitbucket by ctismer (Christian Tismer)
holger krekel wrote:
> On Sun, May 15, 2005 at 13:06 +0200, Armin Rigo wrote:
>
>>As far as I know we can't run the compliance tests on Windows, as I
>>believe that os.system("command >>out 2>>err") doesn't work there.
>
>
> indeed, it would be nice to have an equivalent mechanism working
> for win32. I wouldn't neccessarily consider the 'cannot-run-compliancy'
> issue as criticial for the M0.5 release, though.
Then let me re-phrase it:
Make sure that windows users can use most of relevant features
with a couple of relevant GUIs.
Suggestion: Let's try to get a few windows testers but me.In Heptapod by @cfbolz on May 15, 2005, 10:29
> Suggestion: Let's try to get a few windows testers but me.
I can play a bit with PyPy under windows.In Heptapod by bitbucket_importer on May 16, 2005, 17:46
Created originally on Bitbucket by ctismer (Christian Tismer)
I think I found one reason why I get problems
with PythonWin:
GenC does not use the "don't do imports" trick
as geninterplevel does.
This results in a direct import of the sys module
when targetrpystone tries to print something.
Instead of a deferred call, the sys.stdout write
method is touched, directly.
And in PythonWin, this digs into PythonWin's
C++ objects.
Not exactly sure what to do? Making all imports
late is probably slow. Maybe we can special-case sys.In Heptapod by @arigo on May 16, 2005, 17:50
On Mon, May 16, 2005 at 06:46:12PM +0000, Christian Tismer wrote:
> GenC does not use the "don't do imports" trick
> as geninterplevel does.
> ...
> Not exactly sure what to do? Making all imports
> late is probably slow. Maybe we can special-case sys.
GenC cannot leave imports behind; it must do them all early, because the
generated C code doesn't know about imports. Officially, the problem is
the print statement, which is not RPythonic... In practice, I guess we
will need some kind of workaround anyway. Maybe we can add the print
helpers to objspace/flow/specialcase.py.In Heptapod by bitbucket_importer on May 16, 2005, 19:19
Created originally on Bitbucket by ctismer (Christian Tismer)
I actially didn't use a print statement, but explicitly used
sys.stdout.write() .
That generates a call to this internal bound method and it's fine.
It just doesn't work under PythonWin.
Maybe a quick cure to this is to replace the file object by the
original __stdout__ and let it continue.
What I would like more is to do something like the interpreter
does: direct this through applevel.
How can I do that in this context?In Heptapod by bitbucket_importer on May 17, 2005, 01:56
Created originally on Bitbucket by ctismer (Christian Tismer)
resolved, at least for targetrpystone.
Imports of sys are now deferred to runtime.
Things work nicely with PythonWin.In Heptapod by @arigo on May 17, 2005, 08:48
On Mon, May 16, 2005 at 08:19:49PM +0000, Christian Tismer wrote:
> I actially didn't use a print statement, but explicitly used
> sys.stdout.write() .
...as a work-around for not being allowed to use print in the first
place. We should not spend time making sys.stdout.write() work
correctly in RPython, but rather have print statements work as
expected...In Heptapod by @arigo on May 17, 2005, 09:17
Changed this issue to "we need to support print statements in RPython". Any small example people tries will contain print statements. Right now, trying to do so and then "ccompile()" drags lots of unexpected things into the generated C code...In Heptapod by bitbucket_importer on May 17, 2005, 12:06
Created originally on Bitbucket by ctismer (Christian Tismer)
Armin Rigo wrote:
> On Mon, May 16, 2005 at 08:19:49PM +0000, Christian Tismer wrote:
>
>>I actially didn't use a print statement, but explicitly used
>>sys.stdout.write() .
>
>
> ...as a work-around for not being allowed to use print in the first
> place.
I don't like topic shifts where the meaning of what I said is
abused in a different context.
> We should not spend time making sys.stdout.write() work
> correctly in RPython, but rather have print statements work as
> expected...
Being able to have a lazy import of sys was a major step
forward for me. will give the print statements a try.
--
Christian Tismer :^) <mailto:tismer@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/In Heptapod by bitbucket_importer on May 17, 2005, 12:33
Created originally on Bitbucket by ctismer (Christian Tismer)
I think this should really go into the distro.In Heptapod by @arigo on May 17, 2005, 14:05
Hi Christian,
On Tue, May 17, 2005 at 03:06:39PM +0200, Christian Tismer wrote:
> I don't like topic shifts where the meaning of what I said is
> abused in a different context.
Sorry about that. This was a (bad) way to move the discussion in the
direction that is now its own issue, issue46. The fixes that have been
done about import statements for geninterp have an impact on genc and
vice-versa. Accessing sys.stdout is meaningless for the latter, whereas
using print statements is possibly useful for both; that may be a
starting point for a (future) attempt to rethink the whole issue in a
way that minimizes the special-casing needed around the sys module and
the import statements; one that basically works for any back-end (and as
a bonus has the nice properties discussed in issue46).
For now, I am afraid that any more hacks we throw at the issue right now
will only be expedients that won't survive said rethinking :-)
If you can't find a quick hack for prints, please just look for a quick
hack that would crash the flow graph in an informative way, to avoid
confusion. That's good enough for the upcoming release, I think (sorry,
we kind of reached this conclusion on IRC while you were not there --
feel free to push forward another opinion.)
ArminIn Heptapod by bitbucket_importer on May 18, 2005, 13:15
Created originally on Bitbucket by ctismer (Christian Tismer)
Hi Armin,
all fine :-)
I think I found a quite clean solution to the print problem.
The problem arises because printing is implemented at applevel.
Interestingly, after lots of head-scratching and poking around,
it was easy to intercept exactly those gateway calls to generated
functions.
I'm specialcasing these and emit a simple_call to the native
python function.
For instance:
the wrapped function file_softspace is no longer called vial gateway.
But there is an identical file_softspace in specialcases.py,
which is called by a simple_call operation.
For the moment, I really had to copy this code, but I think we
can even avoid that and add a way to get reach to the untranslated
function which is unfortunately not preserved right now.
I believe this is not a hack but a fine solution, and probably
applicable to all stuff that is done via geninterp.
I will leave it simplefor the release.
Later we might think about a way to get rid of the explicit
specialcasing, becuase this whole thing can probably
generated automatically.
ciao - chrisIn Heptapod by @arigo on May 18, 2005, 14:12
Please, check-in? We'd like to review this to make sure it
doesn't influence genc and the annotator...In Heptapod by bitbucket_importer on May 19, 2005, 16:21
Created originally on Bitbucket by ctismer (Christian Tismer)
this is done, now.
most probably it works for much more than print,
but I didn't test this.
Everything that's RPython can now be executed
by flowspace.In Heptapod by bitbucket_importer on Jun 7, 2005, 10:37
Created originally on Bitbucket by pedronis (Samuele Pedroni)
long term we need clearer rules about the forced embedding of app-level graphs
as low-level that happens with the fix
In Heptapod by bitbucket_importer on May 15, 2005, 09:59
Created originally on Bitbucket by ctismer (Christian Tismer)
From (bugs.pypy.org)