Hi
When trying to translate the latest version of PyPy on FreeBSD I get the
following error:
[translation:info] Error:
File
"/home/dbn/ports/ports/lang/pypy/work/pypy2-v6.0.0-src/rpython/translator/goal/translate.py",
line 318, in main
drv.proceed(goals)
File
"/home/dbn/ports/ports/l
Hi
A quick note: pypy3.5 is running on FreeBSD/amd64 (aka 64bit), at least well
enough to compile the CFFI modules during packaging of pypy3.
As noted in the release, pypy3 does not run from i386 (aka 32bit):
# /wrkdirs/usr/ports/lang/pypy3/work/pypy3-v5.7.1-src/pypy/goal/pypy3-c
'import site
Hi
Some software depends on python-config however PyPy does not provide an
equivalent pypy-config. Are there any plans/workarounds to provide such a
bin?
Regards
D
signature.asc
Description: This is a digitally signed message part.
___
pypy-dev mai
Hi
While translating the latest version of pypy3 on FreeBSD (and after applying
the fix for https://bitbucket.org/pypy/pypy/issues/2348) I get the following
error:
File "/usr/local/home/dbn/ports/ports/lang/pypy3/work/pypy3.3-v5.2.0-alpha1-
src/rpython/rtyper/rint.py", line 25, in opprefix
On Sunday, 18 October 2015 08:34:43 anatoly techtonik wrote:
> On Sat, Oct 17, 2015 at 11:57 AM, Armin Rigo wrote:
> > Hi Phyo,
> >
> > On Fri, Oct 16, 2015 at 2:21 PM, Phyo Arkar
> >
> > wrote:
> > > So that will work like 15.11 , 15.5 ? something like that?
> > > Predefined release cycle ?
>
On Monday, 24 August 2015 23:07:20 David Naylor wrote:
> On Saturday, 22 August 2015 21:25:44 Matti Picus wrote:
> > I would like to add the freebsd-9-x86-64 binary tgz to our released
> > downloads. We still have a number of failing tests showing up on
> > http://buil
On Thursday, 27 August 2015 00:53:05 Matti Picus wrote:
> On 26/08/15 23:32, David Naylor wrote:
> Please find attached for a patch that adds support for:
> ctypes.CDLL(name, handle=X)
>
> The patch includes tests for the pypy and rpython changes. I am not sure
> about th
On Tuesday, 25 August 2015 23:27:35 David Naylor wrote:
> On Wednesday, 26 August 2015 00:09:14 Matti Picus wrote:
> > On 25/08/15 21:26, David Naylor wrote:
> >
> > Please find attached for a patch that fixes this issue. Would you like me
> > to submit a bug report for
On Wednesday, 26 August 2015 00:09:14 Matti Picus wrote:
> On 25/08/15 21:26, David Naylor wrote:
>
> Please find attached for a patch that fixes this issue. Would you like me
> to submit a bug report for this patch?
>
> I have not translation tested this patch as yet.
&
On Monday, 24 August 2015 23:07:20 David Naylor wrote:
> On Saturday, 22 August 2015 21:25:44 Matti Picus wrote:
> > I would like to add the freebsd-9-x86-64 binary tgz to our released
> > downloads. We still have a number of failing tests showing up on
> > http://buil
On Saturday, 22 August 2015 21:25:44 Matti Picus wrote:
> I would like to add the freebsd-9-x86-64 binary tgz to our released
> downloads. We still have a number of failing tests showing up on
> http://buildbot.pypy.org/summary?category=freebsd64
> among them many
> DLOpenError: "opening 'libm.so'
On Wednesday, 19 August 2015 21:36:37 Matti Picus wrote:
> I have started the release cycle for 2.6.1, are there outstanding issues
> or soon-to-be-committed features I should wait for?
Hi Matti,
It would be great if the patch from issue #2107 could be committed. The patch
has been compile test
Hi,
The links to the source tarballs are broken (on the download page).
Regards
On Sunday, 8 June 2014 09:08:41 Armin Rigo wrote:
> Hi all,
>
> We're pleased to announce PyPy 2.3.1, a feature-and-bugfix improvement
> over our recent 2.3 release last month.
>
>
> This release contains severa
On Friday, 26 August 2011 06:37:30 Armin Rigo wrote:
> Hi David,
>
> On Thu, Aug 25, 2011 at 9:44 PM, David Naylor
wrote:
> > Below is the patch, and results, for my proposed hash methods for
> > datetime.datetime (and easily adaptable to include tzinfo and the other
>
On Sunday, 17 November 2013 19:09:00 Maciej Fijalkowski wrote:
> On Sun, Nov 17, 2013 at 6:22 PM, Tobias Oberstein
>
> wrote:
> > Hi,
> >
> > the new FreeBSD buildslave has run the first time:
> >
> > http://buildbot.pypy.org/builders/pypy-c-jit-freebsd-9-x86-64/builds/6
> >
> > PyPy was built
Hi,
I would like to report some possible errors I've noticed
I translated pypy3-2.1.0-beta1 and when doing a:
# find . -type d | xargs pypy-c -m compileall -fl
for lib_pypy I get the following errors:
*** File
"/tmp/build/home/DragonSA/pypy3/work/lib/pypy3-2.1/lib_pypy/ctypes_config_cache/re
Hi Michal
On Saturday, 10 August 2013 10:06:48 Armin Rigo wrote:
> Hi Michal,
>
> On Thu, Aug 8, 2013 at 3:39 PM, Michal Vyskocil wrote:
> > It seems that
> > __pycache__ is not created during a build, but on runtime, so my attempt
> > to build pypy using pypy ends on
> >
> > [ 66s] IOError:
On Thursday, 1 August 2013 11:40:18 David Schneider wrote:
> On 31.07.2013, at 22:57, David Naylor wrote:
> > On 31 Jul 2013 10:29 PM, "Alex Gaynor" wrote:
> > > What version of PyPy are you using to translate?
> >
> > Pypy 2.1-beta2 gives me this error
On 31 Jul 2013 10:29 PM, "Alex Gaynor" wrote:
>
> What version of PyPy are you using to translate?
Pypy 2.1-beta2 gives me this error. I had previously translated with beta1
but without this error (I can confirm this if needed).
> On Wed, Jul 31, 2013 at 12:20 PM, David Nayl
Hi,
While trying to self-translate pypy-2.1-beta2 I got the following error:
RPython traceback:
File "rpython_jit_metainterp_resume.c", line 7778, in
blackhole_from_resumedata
File "rpython_jit_metainterp_resume.c", line 9972, in
ResumeDataDirectReader_consume_vref_and_vable
File "rpython
On Wednesday, 8 May 2013 13:35:00 Alex Gaynor wrote:
> We should probably just delete it at this point, it's completely
> unmaintained, doesn't work, and just confuses people; if someone wants to
> ressurect it, hg log should be good enough.
Isn't JVM in a similar state (although I think someone m
On Wednesday, 8 May 2013 22:14:00 David Naylor wrote:
> Hi,
>
> I tried to translate pypy-2.0b2 on FreeBSD-9.1/i386 and I get the following
> error:
>
> [Timer] Timings:
> [Timer] annotate --- 218.3 s
> [Timer] rtype_ootype
Hi,
I tried to translate pypy-2.0b2 on FreeBSD-9.1/i386 and I get the following
error:
[Timer] Timings:
[Timer] annotate --- 218.3 s
[Timer] rtype_ootype --- 137.0 s
[Timer] ==
[Timer] Total:
On Friday, 29 June 2012 21:46:58 Ronny Pfannschmidt wrote:
> Hi David,
Hi
> i proceeded with refining my changes,
> moving all code related to writing these dumps out of lib_pypy
Thanks
> i'd like to know why you are relocating lib_pypy/lib-python
I am slowly integrating pypy into FreeBSD Port
On Wednesday, 27 June 2012 20:47:28 David Naylor wrote:
> On Monday, 25 June 2012 23:33:12 Ronny Pfannschmidt wrote:
> > Hi David,
> >
> > i created the kill-import_from_lib_pypy branch,
> > which should fix the issue - its still in testing,
> > please take a loo
On Monday, 25 June 2012 23:33:12 Ronny Pfannschmidt wrote:
> Hi David,
>
> i created the kill-import_from_lib_pypy branch,
> which should fix the issue - its still in testing,
> please take a look if any issue comes up
Alas, the changes you made to pypy/tool/compat.py and
pypy/translator/goal/ta
On Friday, 22 June 2012 15:41:04 David Edelsohn wrote:
> On Fri, Jun 22, 2012 at 5:31 AM, David Naylor
wrote:
> > On Sunday, 17 June 2012 09:32:35 Armin Rigo wrote:
> >> It's going to take us a loong time to fix CLI translation if the
> >> process goes:
Hi,
I'm experimenting with using non-default library directories by tweeking
pypy.tool.lib_pypy however I came up with the following error
when translating with pypy:
[translation:ERROR] Error:
[translation:ERROR] Traceback (most recent call last):
[translation:ERROR]File "translate.py", l
On Sunday, 17 June 2012 09:32:35 Armin Rigo wrote:
> Hi David,
>
> On Sat, Jun 16, 2012 at 4:41 PM, David Naylor
> wrote:
> > Oh, okay. I don't have access to the latest sources. I normally work of
> > the released sources. But thanks for looking at this.
On Saturday, 16 June 2012 09:18:22 Maciej Fijalkowski wrote:
> On Fri, Jun 15, 2012 at 10:55 PM, David Naylor
wrote:
> > On Friday, 15 June 2012 07:44:59 Armin Rigo wrote:
> > > Hi David,
> > >
> > > On Wed, Jun 13, 2012 at 2:49 PM, David Naylor
> > >
On Friday, 15 June 2012 07:44:59 Armin Rigo wrote:
> Hi David,
>
> On Wed, Jun 13, 2012 at 2:49 PM, David Naylor
wrote:
> > [translation:ERROR] assert instr_list is not None, 'Unknown opcode:
> > %s ' % op [translation:ERROR] AssertionError: Unknown opc
On Wednesday, 13 June 2012 13:06:14 Armin Rigo wrote:
> Hi David,
>
> On Tue, Jun 12, 2012 at 11:58 AM, David Naylor
> wrote:
> > [translation:ERROR] .. (pypy.rlib.jit:557)set_param__None_enable_opts
>
> Nowadays, you cannot use the JIT with the CLI backend.
Tr
On Monday, 11 June 2012 12:59:55 Michal Bendowski wrote:
> The JVM backend worked in February ;) I will be looking into making it
> translate the interpreter again soon. For now it requires a 32bit
> environment.
FYI, here is the error I get when translating in a 32 environment:
[Timer] Timings:
[
Hi,
FYI, translating pypy for the CLI backend using mono-2.11.1 in a 32bit
environment results in the following error:
[Timer] Timings:
[Timer] annotate --- 309.3 s
[Timer] rtype_ootype --- 326.7 s
[Timer] ==
[Timer]
Hi,
I'm in the process of preparing the port for FreeBSD of pypy-1.9. The patches
required to run under FreeBSD are minimal (1 submittable patch, 1 specific
patch not applicable for pypy). Thanks!
I was just wondering on the state of CLI and JVM backends in pypy-1.9. Does
translating work
On Tuesday, 15 May 2012 16:23:14 Armin Rigo wrote:
> Hi all,
Hi,
> Fijal and me would like to raise interest among various groups of
> people about building a better ctypes replacement for Python.
I have a suggestion, and it (possibly) involves using ctypes...
> Opinions? Interests? This mai
On Tuesday, 13 December 2011 19:28:07 Maciej Fijalkowski wrote:
> On Tue, Dec 13, 2011 at 7:24 PM, David Naylor
> wrote:
> > On Tuesday, 13 December 2011 19:03:09 Maciej Fijalkowski wrote:
> >> On Tue, Dec 13, 2011 at 6:55 PM, David Naylor
> >
> > wrote:
>
Hi,
Does pypy-1.7 support translating to the CLI backend?
On FreeBSD I get the following error:
# mono --version
Mono JIT compiler version 2.10.6 (tarball Thu Nov 24 17:06:01 UTC 2011)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors.
www.mono-project.com
TLS:
On Tuesday, 13 December 2011 19:03:09 Maciej Fijalkowski wrote:
> On Tue, Dec 13, 2011 at 6:55 PM, David Naylor
wrote:
> > On Tuesday, 13 December 2011 18:16:26 Maciej Fijalkowski wrote:
> >> On Tue, Dec 13, 2011 at 6:14 PM, Maciej Fijalkowski
> >
> > wrote
On Tuesday, 13 December 2011 18:16:26 Maciej Fijalkowski wrote:
> On Tue, Dec 13, 2011 at 6:14 PM, Maciej Fijalkowski
wrote:
> > Hi David, CC pypy-dev
> >
> > Can you explain the choice of options here:
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/pypy/Makefile?rev=1.1;co
> > ntent-type=
On Wednesday, 23 November 2011 13:23:43 you wrote:
> Hi David,
Hi
> You are specifying conflicting options: --gcrootfinder=shadowstack
> does not make sense with the Boehm GC.
Removing --gcrootfinder=shadowstack fixes the problem for me. Thanks.
> I fixed the source to report
> it properly a
Hi,
I'm trying to translate pypy-1.7 with optimisations at level 0. I get the
following error:
# /usr/local/bin/pypy translate.py --source --gcrootfinder=shadowstack --
thread -O0 targetpypystandalone.py
[translation:ERROR] Error:
[translation:ERROR] Traceback (most recent call last):
[trans
On Monday, 21 November 2011 18:30:31 David Naylor wrote:
> Hi
>
> While trying to translate pypy-1.7 with the sandbox option, using pypy-1.6
> I saw the translating pypy consume 13.3GB of memory (column Res in top).
> This is under FreeBSD-9RC2/amd64.
This isn't specific t
Hi
While trying to translate pypy-1.7 with the sandbox option, using pypy-1.6 I
saw the translating pypy consume 13.3GB of memory (column Res in top). This
is under FreeBSD-9RC2/amd64.
I've never noticed this memory consumtion when translating pypy-1.6 with the
stackless option.
Is this
Hi All
It occurred to me that with the many options available for jit (such as
inlining, function_threshold) there may be some merit to optimising those
values. I would expect that the optimised values would be workload specific
however if a workload takes days to run then it would be worth op
On Tuesday, 16 August 2011 15:27:30 Armin Rigo wrote:
> Hi David,
>
> On Mon, Aug 15, 2011 at 6:20 PM, David Naylor
wrote:
> > For me the performance of datetime object's hashing is sufficient but I
> > think the python code could use some performance improvements.
On Thursday, 18 August 2011 14:45:16 Armin Rigo wrote:
> Hi Gabriel,
>
> On Wed, Aug 17, 2011 at 10:42 PM, Gabriel Lavoie wrote:
> > Hum... It seems it's the end of my FreeBSD buildslave. :( I don't know
> > when it time the memory requirement jumped to over 4GB (Armin told me it
> > was now arou
;t tried to build it in the last 6
> months...
I have successfully built pypy-1.5 and trunk (~1 week ago), so it is possible.
If you are still having problems please send me the installed physical memory,
and the output of `swapinfo` and `uname -a`.
> 2011/8/15 David Naylor
>
&g
th trunk. To
compile from 1.6 set WRKSRC to point to a fresh checkout of pypy:
# make install WRKSRC=/path/to/hg/checkout/of/pypy
The master branch uses the 1.5 sources.
> 2011/8/11 David Naylor
>
> > On Thursday, 11 August 2011 11:08:18 Maciej Fijalkowski wrote:
> >
On Monday, 15 August 2011 09:05:22 Armin Rigo wrote:
> Hi David,
>
> On Sat, Aug 13, 2011 at 8:14 PM, David Naylor
wrote:
> > So, it appears pypy is failing to speed up this contrived example...
>
> I think that it is expected, because the hash is computed entirely as
>
On Saturday, 13 August 2011 18:32:58 Antonio Cuni wrote:
> On 12/08/11 17:49, David Naylor wrote:
> > Would it not be a simple matter of changing the __(get|set)state method
> > to use a tuple or even an int(long)?
>
> yes, I think it should be enough. I'm going on
On Friday, 12 August 2011 14:51:36 Antonio Cuni wrote:
> Hello David,
>
> On 10/08/11 21:27, David Naylor wrote:
> > Hi,
> >
> > I needed to create a cache of date and time objects and I wondered what
> > was the best way to handle the cache. For comparison I
On Thursday, 11 August 2011 11:08:18 Maciej Fijalkowski wrote:
> Hi
>
> A little status update from my side.
>
> I'm trying to get 1.6 out of the door and there are a few things that
> stand out before we can do it.
>
> * Windows situation (a lot of crashes with missing liveness). Also
> lib-pyt
Hi,
I needed to create a cache of date and time objects and I wondered what was the
best way to handle the cache. For comparison I put together
the following test:
import datetime
import random
import timeit
ranges = [datetime.datetime(2011,01, random.randint(1, 31)) for i in
xrange(1000)]
Hi,
I've run the unit tests for pypy and pypy-stackless on FreeBSD and at some
stage the tests causes pypy(-stackless) to core dump. Here are the results:
# pypy1.5 -c "from test import testall"
test_capi
internal test_L_code
internal test_broken_memoryview
RPython traceback:
File "implement_
Hi,
I'm trying to compile pypy with the sandbox option however it fails with:
cc -pthread -Wl,--export-dynamic,--version-script=../dynamic-symbols-0
-o pypy-c testing_1.o structimpl.o nonfuncnodes.o nonfuncnodes_1.o
nonfuncnodes_2.o nonfuncnodes_3.o nonfuncnodes_4.o
nonfuncnodes_5.o nonf
Hi,
I'm sure you all know that translating pypy requires a large amount of RAM.
It has been my experience that GCC also uses a large amount of RAM when
compiling, about 4G. Is it possible to get python/pypy to stop once
it has written
the source files and then to run that build process separatel
Hi,
I am busy writing a port for pypy on FreeBSD. I have the basics done but
I have a slight issue with the package list. It appears pypy creates some
files based on the architecture name [1] however the names it uses for those
files differ to what FreeBSD uses [2].
I've mapped the obvious name
58 matches
Mail list logo
