From pypy-dev-issue at codespeak.net  Wed Jun  2 20:43:59 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 02 Jun 2010 18:43:59 +0000
Subject: [PyPy-issue] [issue544] AssertionError
Message-ID: <1275504239.54.0.977581550807.issue544@>


New submission from Armin Rigo <arigo+pypyissues at codespeak.net>:

With trunk, no jit:

arigo at tannit32 ~/svn/pypy/benchmarks/unladen_swallow/performance $
~/pypysrc/32compiled/pypy-c-75020 bm_rietveld.py
RPython traceback:
  File "implement_4.c", line 44464, in descr__new___8
  File "implement_4.c", line 222652, in interp_string_to_float
  File "implement_3.c", line 75415, in pow__Long_Long_None
  File "implement_4.c", line 19058, in rbigint_pow
  File "implement_3.c", line 95118, in _x_mul
Fatal RPython error: AssertionError
Aborted

----------
effort: ???
messages: 1770
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: AssertionError

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue544>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun  3 15:13:36 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 03 Jun 2010 13:13:36 +0000
Subject: [PyPy-issue] [issue544] AssertionError
Message-ID: <1275570816.21.0.0807953794879.issue544@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

It is a --no-allworkingmodules build.  The error appears in _x_mul as follows:

>>>> x=1000000000000L   
>>>> x*x
PyPy assertion failed at implement.c:3427:
in pypy_g_RPyRaiseException: AssertionError
Aborted

----------
status: unread -> chatting

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue544>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun  3 15:21:05 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 03 Jun 2010 13:21:05 +0000
Subject: [PyPy-issue] [issue544] AssertionError
Message-ID: <1275571265.53.0.0497647842529.issue544@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Ah.  I remember now: this pypy-c-75020 was built using pypy-c instead of
CPython.  It's still a bug but it explains why I cannot reproduce it with other
pypy-c's.  The issue here is in line 755 of rbigint.py: 

    assert carry <= (widen_digit(MASK) << 1)

With pypy, this wraps around and translates incorrectly to "assert carry <= -2".

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue544>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun  3 20:08:51 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 03 Jun 2010 18:08:51 +0000
Subject: [PyPy-issue] [issue544] AssertionError
Message-ID: <1275588531.79.0.91325788179.issue544@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Should be fixed in r75070.

----------
status: chatting -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue544>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Jun  6 17:42:49 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sun, 06 Jun 2010 15:42:49 +0000
Subject: [PyPy-issue] [issue542] encodings/__init__.py is frozen
Message-ID: <1275838969.7.0.988037999401.issue542@>


Fijal <fijall at gmail.com> added the comment:

Fixed.

----------
status: unread -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue542>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Jun  6 22:34:05 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sun, 06 Jun 2010 20:34:05 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275856445.18.0.514668297202.issue545@>


New submission from Fijal <fijall at gmail.com>:

optimize_GUARD_ISNULL can be called in a situation where op.args[0] has a null 
BoxPtr, but getvalue() returns a non-null ConstPtr. Investigating.

To reproduce, compile pypy-c-jit and run twisted tests (trial twisted crashes 
immediately, due to InvalidLoop raised by optimize_GUARD_ISNULL)

----------
effort: ???
messages: 1775
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: Rare bug in optimizeopt

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Jun  7 07:28:53 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 07 Jun 2010 05:28:53 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275888533.17.0.748698510735.issue545@>


Fijal <fijall at gmail.com> added the comment:

File Edit Options Buffers Tools Help                                                                                         
guard_value(p3322, ConstPtr(ptr3327), descr=<ResumeGuardDescr object at 
0xf775f604>)
p3328 = 
new_with_vtable(ConstClass(pypy.objspace.std.stringobject.W_StringObject))
setfield_gc(p3328, ConstPtr(ptr3329), descr=<GcPtrFieldDescr 8>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f67c>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f6cc>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f71c>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f76c>)
guard_class(p3328, 144637152, descr=<ResumeGuardDescr object at 0xf775f7bc>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f80c>)
guard_class(p3328, 144637152, descr=<ResumeGuardDescr object at 0xf775f85c>)
guard_class(p3328, 144637152, descr=<ResumeGuardDescr object at 0xf775f8ac>)
p3338 = getfield_gc_pure(p3328, descr=<GcPtrFieldDescr 8>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f914>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f964>)
guard_class(p2, 144725152, descr=<ResumeGuardDescr object at 0xf775f9b4>)
p3344 = call_pure(ConstClass(W_TypeObject._pure_lookup_where_with_method_cache), 
ConstPtr(ptr3342), p3338, ConstPtr(ptr3343)\
, descr=<GcPtrCallDescr>)
p3345 = getfield_gc_pure(p3344, descr=<GcPtrFieldDescr 8>)
guard_isnull(p3345, descr=<ResumeGuardDescr object at 0xf775fa3c>)
guard_value(p2, ConstPtr(ptr3346), descr=<ResumeGuardDescr object at 
0xf775fa8c>)
p3347 = getfield_gc(ConstPtr(ptr3346), descr=<GcPtrFieldDescr 16>)
guard_value(p3347, ConstPtr(ptr3348), descr=<ResumeGuardDescr object at 
0xf775faf4>)
p3349 = call_pure(ConstClass(W_TypeObject._pure_lookup_where_with_method_cache), 
ConstPtr(ptr3346), p3338, ConstPtr(ptr3348)\
, descr=<GcPtrCallDescr>)
p3350 = getfield_gc_pure(p3349, descr=<GcPtrFieldDescr 8>)
guard_isnull(p3350, descr=<ResumeGuardDescr object at 0xf775fb7c>)

This is an exploding trace before optimization. The last guard_isnull explodes.

----------
status: unread -> chatting

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Jun  7 14:43:29 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 07 Jun 2010 12:43:29 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275914609.93.0.978934704746.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Surely you don't mean "crashes" but just "fails to compile that loop"?  It
should not crash because InvalidLoop is raised.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Jun  7 14:50:49 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 07 Jun 2010 12:50:49 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275915049.25.0.563495989272.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Forget it, by digging irc logs I found
http://buildbot.twistedmatrix.com/builders/lucid32-pypy/builds/5/steps/trial/logs/stdio
.  This issue is first of all a bug in compile_done_with_this_frame() which
should be prepared to receive None from compile_new_bridge().

I agree that what you're investigating looks a bit strange too, but that's more
likely not a bug in optimizeopt at all, but an issue with the fact that calling
several times W_TypeObject._pure_lookup_where_with_method_cache() with the same
arguments does not always return the same thing (which is strange).

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Jun  7 14:53:50 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 07 Jun 2010 12:53:50 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275915230.01.0.703579783966.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Fixed the first issue in r75171.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Jun  7 17:00:46 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 07 Jun 2010 15:00:46 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275922846.69.0.912162925867.issue545@>


Fijal <fijall at gmail.com> added the comment:

But still looks like a bug in optimizeopt. I fixed one issue, but the other issue 
remains that what we call "pure_function" is not really that pure. It's more 
foldable than pure.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun  8 13:55:55 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 08 Jun 2010 11:55:55 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275998155.46.0.283698577507.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Then the bug is to have an opcode called CALL_PURE and disagreeing on what it's
supposed to be used for :-)  My definition of a pure function is that if all the
arguments are the same, then calling the function has no side-effects and always
returns the same value.

Of course _pure_lookup_where_with_method_cache() has side-effects in theory, but
as far as I see they are all "caching" effects only, so it seems at first that
it is pure in the sense that I described above.  But it seems from your trace
that it does not.  It still does not look like there is anything wrong with
optimizeopt.

It would look like we could change optimizeopt to not repeat the calls but just
fish the return value from the returned Box, but I remember that we decided at
some point that relying in optimizeopt on what is contained in the Boxes was
wrong.  So I don't see what could possibly be changed there.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun  8 14:01:56 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 08 Jun 2010 12:01:56 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1275998516.53.0.774540172801.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Also, what fix are you talking about in "I fixed one issue"?  Revision number?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun  8 18:52:05 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 08 Jun 2010 16:52:05 +0000
Subject: [PyPy-issue] [issue467] dbm: don't export ctypes functions and
	check strings type
Message-ID: <1276015925.15.0.294661674909.issue467@>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Patch applied in r75210.

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: unread -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue467>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Jun  9 10:38:43 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 09 Jun 2010 08:38:43 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1276072723.71.0.0484190663884.issue545@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

After discussions in IRC that you have to fish for by date (e.g. to get the
answer to "I fixed one issue"), r75229 might fix the issue that fijal really
wanted to get across, which is caused by the fact that optimizeopt calls the
pure function again.  This is wrong in case of complex functions like
_pure_lookup_where_with_method_cache(), because its argument w_self might have
been mutated in the meantime, but its argument version_tag of course still has
the original, old value.

----------
status: chatting -> testing

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Jun 11 17:16:57 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Fri, 11 Jun 2010 15:16:57 +0000
Subject: [PyPy-issue] [issue546] classes in translator.platform should use
	tuples in the class attributes
Message-ID: <1276269417.06.0.487557978006.issue546@>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

in the code of pypy/translator/platform/*.py, it's too easy to forget that some 
attributes are 
lists, stored in the class dict:

flags = self.link_flags    # a class attribute, Linux.link_flags
flags += ['-g']            # updates Linux.link_flags!

of course one should write "flags = self.link_flags[:]", but it would be safer 
to turn them 
into tuples, which are not mutables.

----------
effort: easy
messages: 1785
nosy: afa, pypy-issue
priority: bug
release: ???
status: unread
title: classes in translator.platform should use tuples in the class attributes

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue546>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Jun 11 19:00:03 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 11 Jun 2010 17:00:03 +0000
Subject: [PyPy-issue] [issue547] review C warnings from cpyext
Message-ID: <1276275603.3.0.0144812542244.issue547@>


New submission from Armin Rigo <arigo+pypyissues at codespeak.net>:

'cpyext' introduced a number of new warnings of the C compiler.  We should
review them.  In particular, I'm a bit worried about this point: CPython needs
to be compiled with -fno-strict-aliasing, but not PyPy, so far.  Is it still
true of the C code produced from 'cpyext'?

----------
effort: ???
messages: 1786
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: review C warnings from cpyext

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue547>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Jun 13 18:50:35 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sun, 13 Jun 2010 16:50:35 +0000
Subject: [PyPy-issue] [issue545] Rare bug in optimizeopt
Message-ID: <1276447835.38.0.301637499611.issue545@>


Fijal <fijall at gmail.com> added the comment:

r75229 fixed CALL_PURE not throwing away caches of getfield/setfield in case it's 
rendered (and not constant-folded away). This seems to be a correct fix if we 
agree that CALL_PURE might have observable side effects if it's called, however, 
it should always return the same value for the same args.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue545>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun 24 12:09:42 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 24 Jun 2010 10:09:42 +0000
Subject: [PyPy-issue] [issue354] __iter__ attribute on strings
Message-ID: <1277374182.6.0.155036609706.issue354@>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

fixed in r72203: str.__iter__ was removed

----------
nosy: +pypy-issue -ac, arigo, cfbolz, fijal, mwh, pedronis, tismer
status: chatting -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue354>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun 24 14:03:36 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 24 Jun 2010 12:03:36 +0000
Subject: [PyPy-issue] [issue384] int/long comparison
Message-ID: <1277381016.93.0.428069473427.issue384@>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

I think the test period is over.

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: testing -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue384>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun 24 14:07:49 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 24 Jun 2010 12:07:49 +0000
Subject: [PyPy-issue] [issue534] float('inf') works (generates an inf NAN)
	in CPython 2.5.5,
	reports ValueError: invalid literal for float() in PyPy 1.2
Message-ID: <1277381269.5.0.826114869147.issue534@>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

works now: even on Windows, 
float('inf') yields '1.#INF' in PyPy 1.3, and 'inf' in trunk at 75557.

----------
status: chatting -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue534>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Jun 24 20:24:09 2010
From: pypy-dev-issue at codespeak.net (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 18:24:09 +0000
Subject: [PyPy-issue] [issue548] Timestamps are rounded differently in pypy
	and cpython
Message-ID: <1277403849.77.0.762048658393.issue548@>


New submission from Alexander Belopolsky <belopolsky at mac.com>:

In pypy:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 1)

In cpython:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 0, 999999)

See also: http://bugs.python.org/issue1478429

----------
effort: ???
messages: 1791
nosy: belopolsky, pypy-issue
priority: bug
release: ???
status: unread
title: Timestamps are rounded differently in pypy and cpython

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue548>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Jun 25 07:03:03 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 25 Jun 2010 05:03:03 +0000
Subject: [PyPy-issue] [issue549] OS X build should not rely on libintl.h
Message-ID: <1277442183.79.0.890168727791.issue549@>


New submission from Fijal <fijall at gmail.com>:

Seems libintl.h is optional on OS X. I don't completely see how we need it for 
rlocale (it's skipped on windows), but it became a problem on many os xes.

----------
effort: ???
messages: 1792
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: OS X build should not rely on libintl.h

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue549>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun 29 07:22:31 2010
From: pypy-dev-issue at codespeak.net (Joshua Root)
Date: Tue, 29 Jun 2010 05:22:31 +0000
Subject: [PyPy-issue] [issue550] 1.3 translation fails when --cc is used
Message-ID: <1277788951.52.0.609581978585.issue550@>


New submission from Joshua Root <jmr at macports.org>:

I'm in the process of updating pypy in MacPorts to version 1.3. The translation is run using --
cc=/usr/bin/gcc-4.2 and eventually fails thus:

[c:database] Completed
[Timer] Timings:
[Timer] annotate                       ---  813.5 s
[Timer] rtype_lltype                   ---  743.4 s
[Timer] backendopt_lltype              ---  477.6 s
[Timer] stackcheckinsertion_lltype     ---   65.8 s
[Timer] database_c                     ---  710.1 s
[Timer] ===========================================
[Timer] Total:                         --- 2810.5 s
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 286, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/driver.py", line 800, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/driver.py", line 293, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/driver.py", line 496, in task_database_c
[translation:ERROR]     database = cbuilder.build_database()
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/c/genc.py", line 185, in build_database
[translation:ERROR]     self.collect_compilation_info(db)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/c/genc.py", line 202, in 
collect_compilation_info
[translation:ERROR]     self.merge_eci(*all)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/c/genc.py", line 191, in merge_eci
[translation:ERROR]     self.eci = self.eci.merge(*ecis)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-
dev_svn_dports_lang_pypy/work/pypy-1.3/pypy/translator/tool/cbuild.py", line 216, in merge
[translation:ERROR]     (other.platform, self.platform))
[translation:ERROR]  Exception: Mixing ECI for different platforms <Darwin_x86_64 cc=gcc> and 
<Darwin_x86_64 cc=/usr/bin/gcc-4.2>
[translation] batch mode, not calling interactive helpers

----------
effort: ???
messages: 1793
nosy: jmr, pypy-issue
priority: bug
release: ???
status: unread
title: 1.3 translation fails when --cc is used

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue550>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun 29 07:48:20 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 29 Jun 2010 05:48:20 +0000
Subject: [PyPy-issue] [issue550] 1.3 translation fails when --cc is used
Message-ID: <1277790500.33.0.519097536509.issue550@>


Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:

Could you try to apply the changes made in r75419 and r75420?
http://codespeak.net/pipermail/pypy-svn/2010-June/041561.html
http://codespeak.net/pipermail/pypy-svn/2010-June/041562.html

----------
status: unread -> chatting

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue550>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun 29 11:39:34 2010
From: pypy-dev-issue at codespeak.net (Joshua Root)
Date: Tue, 29 Jun 2010 09:39:34 +0000
Subject: [PyPy-issue] [issue550] 1.3 translation fails when --cc is used
Message-ID: <1277804374.84.0.813957258109.issue550@>


Joshua Root <jmr at macports.org> added the comment:

Applying those changes fixes it. Thanks.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue550>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Jun 29 18:00:42 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 29 Jun 2010 16:00:42 +0000
Subject: [PyPy-issue] [issue550] 1.3 translation fails when --cc is used
Message-ID: <1277827242.16.0.87776198308.issue550@>


Fijal <fijall at gmail.com> added the comment:

So closing.

----------
status: chatting -> resolved

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue550>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Jun 30 21:56:15 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Wed, 30 Jun 2010 19:56:15 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1277927775.84.0.874227943024.issue551@>


New submission from David Naylor <naylor.b.david at gmail.com>:

Add support for compiling on freebsd[89].  

This is only on the pypy side, the python libs included with pypy do not support 
freebsd8+.  It should be fairly easy to import the required code from upstream.  

I'm currently tested this with a build on FreeBSD9/amd64.  Will follow up if the 
build fails.  

Regards

----------
effort: easy
files: patch-pypy2.diff
messages: 1797
nosy: DragonSA, pypy-issue
priority: bug
release: ???
status: unread
title: Support for freebsd8+

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-pypy2.diff
Type: text/x-patch
Size: 9841 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20100630/8a43915a/attachment.bin>