On Thu, Dec 2, 2021 at 11:49 PM Armin Rigo wrote:
>
> https://cffi.readthedocs.io/en/latest/embedding.html. If we want to
> go the full CPython way, we need to rename and move
> "$localdir/libpypy3-c.so" to something like "/usr/lib/libpypy38.so"
> and have /usr/bin/pypy3.8 be a program that is l
o another IRC server.
One of such articles is for example this:
https://fosspost.org/freenode-collapse/
> On Sun, May 30, 2021 at 10:47 PM Antonio Cuni wrote:
> >
> > Following the example of many other FOSS projects, the PyPy team has
> decided to move its official #pypy I
Following the example of many other FOSS projects, the PyPy team has
decided to move its official #pypy IRC channel from Freenode to
Libera.Chat: irc://irc.libera.chat/hpy
The core devs will no longer be present on the Freenode channel, so we
recommend to join the new channel as soon as possible.
Hi Matti,
+1 to everything for me. It sounds a big step forward, thank you for doing
this.
I think it would be nice to preserve the ability to comment, though. If the
simplest way to do that is to move the repo to github, +1 for that as well.
On Tue, Feb 2, 2021 at 11:55 PM Matti Picus wrote:
>
On Mon, Jan 4, 2021 at 12:43 PM Panos Laganakos
wrote:
> Glad you like it!
>
> Yeah, while the project itself is a banger, the "image" of PyPy is a bit
> lacking. But nothing that can't be fixed. I've set up my work schedule to
> have time to contribute to one non-work project, so I'm here to hel
Hello Pãnoș,
thank you for this!
Personally I like it a lot. As Matti pointed out, in order to be used it
needs to be turned into a Nikola theme but hopefully it's not too hard.
Historically we as a group have been very bad at designing and implementing
the website, so having someone who cares and
On Mon, Dec 21, 2020 at 11:19 PM PIERRE AUGIER <
pierre.aug...@univ-grenoble-alpes.fr> wrote:
> class Point3D:
> def __init__(self, x, y, z):
> self.x = x
> self.y = y
> self.z = z
>
> def norm_square(self):
> return self.x**2 + self.y**2 + self.z**2
>
you
Hi pypy-dev (cc:ing hpy-dev),
I have just merged the hpy branch into py3.6. This means that from now,
pypy3.6 nightly builds will automatically support hpy, and it will be much
easier for interested users to try it out.
I propose the following workflow for continuing HPy development on PyPy:
1.
After an IRC discussion with Armin, we designed the following solution:
https://github.com/hpyproject/hpy/issues/83
If you have comments, please post the on the github issue, to avoid
splitting discussions half here and half there :)
ciao,
Antonio
On Sat, Sep 19, 2020 at 11:50 PM Antonio Cuni
Consider the following snippet of code:
typedef struct {
HPyObject_HEAD
long x;
long y;
} PointObject;
void foo(HPyContext ctx, HPy h_point)
{
PointObject *p1 = HPy_CAST(ctx, PointObject, h_point);
PyObjecy *py_point = HPy_AsPyObject(ctx, h_point); // [1]
PointObject *p2 =
To expand Armin's answer, the two most "visible" effects for end users are:
- some_unicode.encode('utf-8') is essentially for free (because it is
already UTF-8 internally)
- some_bytes.decode('utf-8') is very chep (it just needs to check that
some_bytes is valid utf-8)
ciao,
Anto
On Wed, Feb 26
Thank you for having handled all of this, Matti! :)
On Sun, Feb 16, 2020 at 7:13 PM Matti Picus wrote:
> As reported in the recent blog post
>
> https://morepypy.blogspot.com/2020/02/pypy-and-cffi-have-moved-to-heptapod.html,
>
> please do not add content to bitbucket.org/pypy or any of the rep
Hi,
I have added myself to people.txt.
I didn't specify my dates yet because I am flexible, so I suppose I will
decide the exact arrival/departure days depending on what the other people
will do.
If possible I'd like a single room, if available.
ciao,
Anto
On Tue, Jan 14, 2020 at 10:24 AM Armin R
Hi Matti,
On Fri, Nov 22, 2019 at 7:03 PM Matti Picus wrote:
> I would like to do a release of pypy soon. The biggest change from 7.2
> is that we changed the SOABI to pypy27_pp73 (or pp36_pp73) to better
> hanlde packaging. Since a new release of pip will depend on our SOABI, I
> would like the
Hi,
I think it would be a good idea to make squeaky's portable pypy builds [1]
more official by moving the repo to something like github.com/pypy/portable.
I think it's a good idea for various reasons, in particular:
1. we already link them from pypy.org, although not very prominently
2. they ar
Hi Robert,
are you using any package which relies on cpyext? I.e., modules written in
C and/or with Cython (cffi is fine).
IIRC, at the moment PyPy doesn't detect GC cycles which involve cpyext
objects.
So if you have a cycle which does e.g.
Py_foo -> C_bar -> Py_foo
(where Py_foo is a pure-pyt
Hello Amy,
On Wed, Feb 13, 2019 at 10:38 AM Amy wrote:
> "pypy3 -m pip install opencv-python". However, it give an error: "Could
> not find a version that satisfies the requirement opencv-python (from
> versions: )
> No matching distribution found for opencv-python
>
This happens because opencv
On Mon, Feb 11, 2019 at 4:52 PM Carl Friedrich Bolz-Tereick
wrote:
> Antonio Cuni 2019-02-11 11:50 +0100 default
>
let's close this one :)
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
==
PyPy v7.0.0: triple release of 2.7, 3.5 and 3.6-alpha
==
The PyPy team is proud to release the version 7.0.0 of PyPy, which includes
three different interpreters:
- PyPy2.7, which is an in
I agree, I like the old logo better.
On Fri, Feb 8, 2019 at 2:15 PM Ronan Lamy wrote:
> Do we really need a new logo? The old one has been our identity for years
> and was more distinctive.
>
> Apart from that, I think this is an improvement.
>
>
> Le ven. 8 févr. 2019 à 11:18, Maciej Fijalkowsk
Hi,
I have uploaded all the packages for PyPy 7.0.0; the release is not yet
official and we still need to write the release announcement, but the
packages are already available here, for various platforms:
https://bitbucket.org/pypy/pypy/downloads/
feel free to try them and please let me know if s
Hi,
I have starting the procedure for doing a 7.0 release, I'd like to have
some feedback on the process, in particular for bumping the version number.
If we don't do it correctly the risk is to revert the version change when
we do a merge between default and the release branch or viceversa, which
On Tue, Dec 25, 2018 at 8:59 AM Armin Rigo wrote:
> Any clue about why the "purple line" graph, after adding some
> gc.disable() and gc.collect_step(), is actually 10% faster than the
> baseline? Is that because "purple" runs the GC when "yellow" would be
> sleeping waiting for the next input, a
Hi,
better to ask it here since I suspect that most people won't be much on irc
during the next days: I wrote a blog post draft about the gc-disable branch
which I have recently merged; it is available on extradoc:
https://bitbucket.org/pypy/extradoc/src/extradoc/blog/draft/2018-12-gc-disable/gc-d
Even if we decide to run them less often, we still need to setup the whole
machinery: so, once we have done that, running them nightly or once a week
doesn't change much.
If we can get usage of speed.python.org it would be awesome I think: it
would also immediately enable comparison between PyPy a
On Mon, Aug 27, 2018 at 6:38 PM Matti Picus wrote:
> . Perhaps we should retire bencher4 and find
> another build machine, one that we can control a bit more
another thing we could try to have more repeatable builds is to use docker
containers; for example, some time ago I used this approach to
Hi,
I am planning to go, since it's close and it's a beautiful place.
Did anybody else already submitted a pypy talk?
On Sat, May 12, 2018 at 5:03 PM, Carl Friedrich Bolz-Tereick
wrote:
> Hi all,
>
> Somebody on Twitter asked whether there would be a pypy talk at EuroScipy
> which is from Augus
On Wed, Jan 31, 2018 at 12:34 PM, Carl Friedrich Bolz-Tereick wrote:
> Hi Anto,
>
> Yes, I ran your benchmarks and they are improved, particularly the ones
> that pass arguments.
>
cool :)
> I need to rerun them now that I merged default. However, I would prefer it
> if we could find a real
Hi Carl,
wow, this looks awesome. Did you run benchmarks to measure the speedup? If
yes, should we add them to my repo?
https://github.com/antocuni/cpyext-benchmarks
ciao,
Anto
On Tue, Jan 30, 2018 at 1:31 PM, cfbolz wrote:
> Author: Carl Friedrich Bolz-Tereick
> Branch: cpyext-faster-arg-pass
sidenote: if you do the following, you can replace the __dict__ without
incurring into performance penalties (Armin, please correct me if I'm
wrong):
import __pypy__
def __init__(self):
self.__dict__ = __pypy__.newdict('instance')
this is not directly useful for your use case (because newdict
Hi,
I'd be happy to come. Since I have already been to Warsaw, I vote for
Krakow or Wroclaw.
The only thing is that April is quite busy for me; ATM, the only reasonable
dates are somewhere between 3rd and 13th. May it's surely easier :)
On Sun, Jan 7, 2018 at 10:26 AM, Maciej Fijalkowski
wrote:
On Mon, Dec 11, 2017 at 1:11 PM, Carl Friedrich Bolz wrote:
> we require and have always required app-level tests for every new
> feature up to the finer details. The CPython test suite is often not
> very thorough, and we often work under the assumption that if our own
> tests about a feature w
)
2. Try a nightly build from here: http://buildbot.pypy.org/nightly/trunk/
Il 10 nov 2017 7:51 PM, "Gelin Yan" ha scritto:
>
>
> On Sat, Nov 11, 2017 at 1:50 AM, Antonio Cuni wrote:
>
>> Maybe it's a stupid advice but: are you sure to have copied also
>&g
Maybe it's a stupid advice but: are you sure to have copied also
libpypy-c.so to the raspberry?
Is it in the same directory as the "pypy" or "pypy-c" executable?
I suggest you to run the script "pypy/tool/release/package.py", which
builds a tarball containing all the necessary stuff (including the
Hi,
I suppose that the explanation that you put in the commit message should
also go in a comment inside the source code, else when someone sees it it's
just obscure.
Also, it'd be nice to have some tests about ShuffleDict :)
On Thu, Nov 9, 2017 at 2:55 AM, fijal wrote:
> Author: fijal
> Branch
nto
>
> With the climate change >15/03 is not a very good winter sprint, is it?
>
> On Sun, Oct 29, 2017 at 11:47 PM, Antonio Cuni
> wrote:
> > Hi Armin,
> >
> > I would probably be unable to come during the first two weeks of march,
> so
> > for me th
Hi Armin,
I would probably be unable to come during the first two weeks of march, so
for me the preference is basically "anything >= 15/03"
On Sun, Oct 29, 2017 at 11:11 PM, Armin Rigo wrote:
> Hi all,
>
> I'm trying to organise the next winter sprint a bit in advance. It
> might tentatively b
Hi Timothy,
I'm surely not an expert of this area and others can probably explain
better how it works, but I think that you are looking for
`rgc.register_custom_trace_hook`; for an example of usage, see e.g.
pypy/module/micronumpy/concrete.py
ciao,
Anto
On Fri, Sep 15, 2017 at 10:52 PM, Timothy B
Hi,
note that this is not because of PyPy: it's the wheel package which chooses
what to include in the wheel filename:
https://bitbucket.org/pypa/wheel/src/5d49f8cf18679d1bc6f3e1e414a5df3a1e492644/wheel/pep425tags.py?at=default&fileviewer=file-view-default#pep425tags.py-39
PyPy reports only the A
Hello,
recently I have been playing a bit with cpyext, so see if there are low
haning fruits to be taken to improve the performance.
I didn't get any real result but I think it's interesting to share my
findings.
The benchmark I'm using is here:
https://github.com/antocuni/cpyext-benchmarks
it co
+1
On Tue, Jul 18, 2017 at 11:33 PM, wrote:
> Hi,
>
> any objections to renaming cppyy into _cppyy?
>
> I want to be able to do a straight 'pip install cppyy' and then use it
> w/o further gymnastics (this works today for CPython), but then I can't
> have 'cppyy' be a built-in module.
>
> (You c
Hi Tobias,
On Wed, Jan 18, 2017 at 5:27 PM, Tobias Oberstein <
tobias.oberst...@gmail.com> wrote:
> Are you aware of
>
> https://github.com/alex/zero_buffer
>
> ?
>
> This emulates Python strings using zero-copy read-only buffer views.
>
yes, I saw it in the past and I considered to use it for
Hi Wim,
On Wed, Jan 18, 2017 at 5:09 PM, wrote:
> since you wrote the initial data access part yourself way back when, I'd
> expect you to fix cppyy if it were slower! :)
>
>
that's a fair point, indeed :).
But on top of that you need to put a layer which exposes a pythonic
interface (for exam
so displays a link to that page
3) pip install numpypy works as well (and displays the same link).
What do you think?
On Wed, Jan 18, 2017 at 9:05 PM, Matti Picus wrote:
> On 18/01/17 20:38, Antonio Cuni wrote:
>
>> Hello Matti,
>> I am having some troubles with the late
Hello Matti,
I am having some troubles with the latest pypy and numpypy: basically,
numpy.get_include() returns the wrong directory.
I investigated a bit and I think the culprit are these two commits:
https://bitbucket.org/pypy/pypy/commits/ad36a29d0fcc
https://bitbucket.org/pypy/numpy/commits/26e
Hi Tobias,
On Tue, Jan 17, 2017 at 7:27 PM, Tobias Oberstein <
tobias.oberst...@gmail.com> wrote:
> Hi Antonio,
>
> Fantastic!!
>
> Actually, if this is true (performance), this would be wonderful - I can
> spare my nerves (hello C++, you are a mnster!), and eat my cake ..
>
> The benchmarks
Hi,
On Tue, Jan 17, 2017 at 5:51 PM, Tobias Oberstein <
tobias.oberst...@gmail.com> wrote:
> Note: for now I am fine, I managed to build it using gcc 4.9 toolchain.
> Need to see how far I get with captnproto now ..
>
if you are interested in capnproto, you might want to try capnpy: it's
writ
Hi,
I'd prefer the classic Leysin sprint :).
I will probably be unavailable the first two weeks of March; other than
that, any week should be fine for me.
On Mon, Jan 16, 2017 at 8:59 PM, Maciej Fijalkowski
wrote:
> I have a place to stay in Zurich so it's a bit of a win for me :-)
>
> I would p
Hi,
you could also check pyjnius, which seems more mature than jpype and it is
used in real life apps to run e.g. python on android:
http://pyjnius.readthedocs.io/en/latest/
I quickly tried to compile pyjnius with pypy (using cpyext) and it seems to
work (at least, the tests pass). However, since
fwiw, you might want to look at this:
https://github.com/felipecruz/gurobi_cffi
from what I read in the readme, it probably exposes a different interface
than gurobipy, but it might enough for your use case.
On Tue, Nov 24, 2015 at 9:35 PM, Luis José Novoa
wrote:
> Hi Maciej,
>
> Thanks for yo
Hi David,
I am developing the "faster-rstruct" branch, which aims to speedup
struct.unpack by reading the values at once from memory, instead of
byte-by-byte as it's doing right now.
The branch works fine on x86 but fails on armhf (see e.g.
http://buildbot.pypy.org/summary/longrepr?testname=AppTe
why using yy.mm instead of just a single increasing int number like Chrome?
To avoid confusions, we should probably skip pypy 3 and start releasing
from pypy 4. It looks just simpler than 15.11 and friends to me.
ciao,
Anto
On Fri, Oct 16, 2015 at 7:12 AM, Matti Picus wrote:
> I have started a
Hi,
On Tue, Sep 8, 2015 at 3:11 PM, fijal wrote:
> Author: Maciej Fijalkowski
> Branch:
> Changeset: r79543:3c45f447b1e3
> Date: 2015-09-08 15:11 +0200
> http://bitbucket.org/pypy/pypy/changeset/3c45f447b1e3/
>
> Log:(fijal, arigo) merge optresult-unroll - this branch improves warmup
>
hi Armin,
following the discussion we had today, that TransactionQueue could be
easier to understand for people if you explain it as "a for loop in which
you don't know the order of the iteration", I figured out that we might
even introduce some syntactic sugar for it; not sure if it makes things
s
Hi,
sorry for responding so late, I was at a conference.
On Sat, Apr 18, 2015 at 11:02 AM, Armin Rigo wrote:
> I would imagine that a better way would be to not care about
> restricted style at all. If we really decide to move to Python 3,
> then maybe we should drop 2.7 altogether and all
Hi,
my plan was to submit a talk about profiling/optimizing, possibly together
with fijal if he comes (but I didn't do yet :)).
Probably the talk which suits best for talking about the general status is
Romain's one?
On Sat, Apr 11, 2015 at 12:10 AM, Romain Guillebert
wrote:
> Hi Armin
>
> I su
On Wed, Feb 11, 2015 at 10:09 PM, Matti Picus wrote:
> The current installation procedure ensures the users get the latest
> version, with no lag for an extra packaging step after pushing to bitbucket.
>
this has also the drawback that it can break at any time for pypy
releases. For example, t
Hi,
this looks interesting, but from a quick look it seems they are only
offering a C++ API?
In that case, it might be better/easier to wrap it through cppyy than cffi.
Also, did Travis told you what are the plans for scipy?
On Fri, Jul 25, 2014 at 10:24 AM, Armin Rigo wrote:
> Hi,
>
> Feedbac
Hi,
I was looking at this issue:
https://bitbucket.org/pypy/pypy/issue/1514/module-behaviour-incompatibility-which
and I noticed that pypy's user "amaury" has been mapped to bitbucket's user
"amaury", which unfortunately it's another physical person.
I don't know much about the migration of the
Hello Benedek,
On Fri, Jul 4, 2014 at 10:42 PM, Armin Rigo wrote:
> If you have exactly 4 GB of RAM,
> and you don't have any PyPy to start with, then CPython is probably
> using just too much memory indeed.
>
note that what Armin says applies only if you want to *translate* pypy by
yourself.
Hi Armin,
> As you have noticed, this is an old feature not supported any more
> since a long time (and mostly untested). It was an experimental
> feature that turned out not to be useful in practice. Just using
> regular Python, you can mostly achieve the same effects, with the
> exception (m
founded part of the ARM
development. It founded also pygame_cffi, right?
On Wed, May 21, 2014 at 2:31 PM, David Schneider
wrote:
> Hi all,
>
> On 21.05.2014, at 01:56, Antonio Cuni wrote:
>
> > David: what is the current status of PyPy on ARM? Should I say "it just
>
Hi,
> What do you exactly want to know about hippy performance?
>
I simply want to put in a slide "hippy is N times faster than standard
PHP", for some reasonable value of N. Nothing more :)
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.
Hi Alex,
On Wed, May 21, 2014 at 1:58 AM, Alex Gaynor wrote:
> Oh, performance, the only Ruby implementation that's competitive with it
> is the Oracle Ruby VM with Truffle, I think they've started merging that
> into JRuby by now, so I'm not sure how that compares. Definitely faster
> than MRI
Hi all,
I am preparing the usual "PyPy status talk" which I'll give to the upcoming
Pycon Italy, which is going to cover what happened in the last two years of
PyPy.
If you are interested, the draft slides are here:
https://bitbucket.org/pypy/extradoc/src/tip/talk/pycon-italy-2014/talk.rst?at=ext
Hi Matti,
IIRC, the repo copy is needed to compute the diff, since the payload only
contains the hash of the relevant revisions
On Thu, May 15, 2014 at 7:56 PM, Matti Picus wrote:
> Hi. I am looking at adding the ability to monitor a bitbucket-hosted git
> repo to the bbhook module in pypy's b
On Wed, Apr 30, 2014 at 1:11 PM, Anton Gulenko <
anton.gule...@student.hpi.uni-potsdam.de> wrote:
> I'll try to make the example that Tim mentioned more clear.
> Building up the deep stack was done INSIDE the loop. It was also the only
> thing that happened inside the loop.
> That's why we expecte
Hi Johan,
the extension module needs to have an extension like *.pypy-22.pyd: this is
to avoid trying to load cpython modules by mistake.
You should use setup.py+distutils to build your module, so that such
details are taken into account automatically.
ciao,
Anto
On Mon, Feb 24, 2014 at 1:50 PM
Hi Armin, hi Romain,
in Leysin we discussed about the idea of giving the usual "PyPy status
talk" at the upcoming EuroPython, considering that people complained that
there was none at the last one :)
The CfP ends on the 9th: should we file a joint proposal?
Do you also have plans for giving a more
On 19/12/13 17:01, Alex Gaynor wrote:
No, this isn't a bug in PyPy. If gevent wants to use the internal details of
the socket module in way's that aren't defined, they need to pass somethign
which matches the required interface.
it's worth noting that eventlet had the same issue, and it was fix
On 02/12/13 21:08, Philip Jenvey wrote:
It's a bit weird w/ PyPy3 and PyPy sharing the version numbering scheme, at
least for now, since it implies the release schedules are tied together. Maybe
they should be though?
Calling it PyPy3 w/ the same version scheme seemed to make the most sense v
Hi,
On 01/12/13 10:21, Ahti Heinla wrote:
Hi,
OK, thanks! To make the scheduling easier, I created this Doodle poll.
As I understand, the critical thing is that most of the core developers
fill out their preferences (or mark all dates as unsuitable, if not interested
in the Tallinn spri
Hi,
as I already said on IRC, I'd be glad to do a sprint in Tallin, as I've
already been there and I really liked the city :)
On Tue, Nov 26, 2013 at 1:15 PM, Ahti Heinla wrote:
> Hi,
>
> I am new to PyPy, but very impressed with what you guys have done.
> Myself I am best known for ha
Hi Matti,
On 23/11/13 20:55, Matti Picus wrote:
Can we just say "don't do that?"
I guess the answer is no...
Going down the initialization route seems to be the way numpy does it, I see
import_array();
used extensively in numpy c code.
Although making sure it is only called once seems to reall
Hi,
I committed a cpyext+numpy failing test in a3c3b75a7f2b.
In short, the following fails:
if (!PyArg_ParseTuple(args, "O!", &PyArray_Type, &obj))
return NULL;
The problem is that PyArray_Type is currently defined in ndarrayobject.c but
never initialized:
PyTypeObject PyArra
; > On Thu, Nov 14, 2013 at 2:35 PM, Antonio Cuni
> wrote:
> >> W_FloatObjectPresevingTheBits will be created only by operations like
> >> struct.unpack, cffi.cast, etc.
> >
> > That's not enough: if you read one such float into a variable and then
> >
On 14/11/13 10:57, Armin Rigo wrote:
Bah, there is another issue. The following code happens to work right now:
x, = struct.unpack("d", "ABCDxx\xff\x7f")
y = struct.pack("d", x)
assert y == "ABCDxx\xff\x7f"
This works even though x happens to be a NaN; its bit pattern is
preser
Hi,
On 15/10/13 12:45, matti picus wrote:
and what about cloning the numpy repo into bitbucket/pypy to make it more of a
"pypy owned" thing?
I think it's a good idea.
I propose the following:
1) we move your repo to bitbucket/pypy/numpypy
2) we package numpypy, so that people can just do "p
Hi,
On 09/10/13 18:48, Carl Friedrich Bolz wrote:
Hi Anto,
just said it on IRC, just so that it doesn't get lost:
I think module/_cffi_backend should use the generic interfaces and not
touch the internals of listobject.py. it can just call
space.listview_int and space.listview_float, they are
Hi,
On 09/09/13 21:37, Matti Picus wrote:
I reverted the changes I made to the pypy-pyarray branch that changed c-api
functions like PyArray_NDIM(arr).
The original code had no real answer to what happens if these are called when
arr is not an ndarray.
[cut]
The discussion we had on IRC star
Hi Edd,
On 06/09/13 15:45, Edd Barrett wrote:
+script_path = os.path.abspath(__file__)
+pythonpath = os.path.dirname(os.path.dirname(script_path))
+sys.path.append(pythonpath)
Here we are appending to the path, not overriding it, hence this is safe for
either method. Right?
yes, if you do s
Hi,
On 05/09/13 17:09, vext01 wrote:
Log:(RichardN, Edd) Add the jitviewer path to PYTHONPATH automatically.
diff --git a/bin/jitviewer.py b/bin/jitviewer.py
--- a/bin/jitviewer.py
+++ b/bin/jitviewer.py
@@ -1,4 +1,10 @@
#!/usr/bin/env pypy
import sys
+import os.path
+
+script_path = os
Hi Manuel,
did you actually kill support for this feature? I find it occasionally useful:
e.g. when working on the JIT you can use --fork-before=pyjitpl and avoid to
annotate/rtype the whole pypy interp when you change something.
ciao,
Anto
On 04/09/13 12:13, Manuel Jacob wrote:
Author: Man
Hi Alex,
I think that this commit should come with a test_pypy_c test as well.
ciao,
Anto
On 04/09/13 00:03, alex_gaynor wrote:
Author: Alex Gaynor
Branch:
Changeset: r66780:a3e9a5394648
Date: 2013-09-03 16:02 -0700
http://bitbucket.org/pypy/pypy/changeset/a3e9a5394648/
Log:Enable inlinin
Hi Matti,
I and Romain reviewed the pypy-pyarray branch: we think there are a couple
of issues to be solved before it can be merged, we added some comments to
your TODO list. Otherwise, the branch looks fine and useful :)
ciao,
Anto. Romain
___
pypy-dev
Hello Eleytherios,
On 07/04/2013 08:12 AM, Antonio Cuni wrote:
Il giorno 03/lug/2013 18:17, "Amaury Forgeot d'Arc" mailto:amaur...@gmail.com>> ha scritto:
> This is because of I/O.
> If I replace the file with a custom class which has an empty write() method,
Il giorno 03/lug/2013 18:17, "Amaury Forgeot d'Arc" ha
scritto:
> This is because of I/O.
> If I replace the file with a custom class which has an empty write()
method,
> pypy is twice faster than CPython.
Few days ago I discovered that there is an easy optimization for this. If
you look at how
On 06/29/2013 11:24 PM, Skip Montanaro wrote:
[cut]
that version of Python was executed. Accordingly,
/opt/local/lib/python2.7/site-packages was in sys.path, as it should
have been. It appears that the generated pypy-c wound up with that
directory in its sys.path as well. I wasn't executing i
On 06/28/2013 11:13 AM, Matti Picus wrote:
On 06/28/2013 12:07 PM, Maciej Fijalkowski wrote:
- buildbot has no support for git, I wrote a git_update function but it
>needs test
i don't believe youhttp://docs.buildbot.net/0.8.1/Git.html
cool, thanks! I guess we have our own update_hg for hist
Hi,
On 06/05/2013 07:26 AM, Maciej Fijalkowski wrote:
Hi anto
if this is for speeding up json, call the module _json, as CPython
does (I don't care if the API is similar or not, as long as it's used
by json lib)
yes, it is for speeding up json, but I called it differently precisely because
On 05/08/2013 11:27 PM, Alex Gaynor wrote:
I agree with this, the abstraction doesn't really work well right now, there's
way too much code duplication. If we seriously want to have an lltype/ootype
distinction this should be redone from scratch (IMO).
Although I have an emotional feeling with
On 05/01/2013 07:22 PM, Alex Gaynor wrote:
Yes, we have a specialized map for 2 arguments, a specialized zip makes sense.
(Or figuring out how to specialize that loop for N-arguments where N is
~smallish so the inner loop is unrolled at app level, that's harder, but
probably worthwhile n the long
On 10/04/13 15:51, Alex Gaynor wrote:
Hi guys,
I just wrote a JIT test for this, I haven't actually run it since I don't have
a local translation, however I'll kick the buildbot and review the results.
well, my point is that you should not commit a JIT optimization if you are not
sure it actu
Hi Alex,
could we have a test_pypy_c test for this please?
On 10/04/13 03:53, alex_gaynor wrote:
Author: Alex Gaynor
Branch:
Changeset: r63186:c514bbc4c086
Date: 2013-04-09 19:53 -0700
http://bitbucket.org/pypy/pypy/changeset/c514bbc4c086/
Log:make looking up encodings free with the JIT
On 04/03/2013 09:27 AM, Maciej Fijalkowski wrote:
hello everyone
I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
virtualenv, there is no recent virtualenv available and there is
absolutely no good reason why we did that. I'm now spending tons of
time trying to think how to update
On 03/21/2013 11:38 PM, Matti Picus wrote:
fijal did restart the buildbot, it didn't help.
then I fear that the best is to do some good old debug with print statements
and pdb.set_trace().
If you login to cobra, you can do the following:
$ ssh buildmas...@cobra.cs.uni-duesseldorf.de
$ cd pyp
On 03/21/2013 05:01 PM, matti picus wrote:
I know this is not all that important, but...
It annoyed me that there is so much stuff on this page
http://buildbot.pypy.org/nightly
so I changed our buildbot code to sort by filesystem mtime, and put
trunk on top.
I tried it out by writing tests, and e
On 03/04/2013 09:42 AM, Roger Flores wrote:
On March 3, 2013 2:20 AM, Carl Friedrich Bolz wrote:
>Are you*sure* you are running on a 64 bit machine?
Sure? No. I assumed it's 64bit pypy because it was generating x86_64
instructions. How would you check for sure?
uname reports x86_64 on the
Hi,
On 12/06/2012 05:43 PM, Armin Rigo wrote:
> Right now, we have extra servers sitting around not doing much. I'm
> for moving all three services there. Fijal and me have access, and
> I'm sure anyone else that needs it would have access too.
which servers?
_
On 10/21/2012 09:28 PM, Ronan Lamy wrote:
>> > * testrunner and dotviewer can become independent packages
> +1 (well, I don't really have an opinion on testrunner). IMO, this
> implies that FunctionGraph should lose its view/show method.
nothing stops us to have a .show() method which tries to l
1 - 100 of 250 matches
Mail list logo
