Hi Roshan,
On Thu, Oct 8, 2015 at 6:53 PM, Roshan Cherian wrote:
> I have a requirement to convert from p12 to p7b. I am sorry for my little
> knowledge on this and I am not even sure I can ask this here.
Is this error showing up on PyPy but not on CPython for the same code?
Are you using the s
Hi Roshan,
On Wed, Oct 14, 2015 at 12:38 AM, Roshan Cherian wrote:
> I am getting this issue in cpython as well as pypy. I am using pyopenssl
> 0.12. I am probably not using it the right way to convert to p7b?
Ah, then you're asking in the wrong list. This list is about the
development of PyPy.
Hi Vaibhav,
On Wed, Oct 14, 2015 at 11:26 AM, Vaibhav Sood
wrote:
> code to return back to the calling function slp_switch. However in between
> the calling function’s stack content is overwritten by the g_restore_state
> code (it memcpy’s the stored heap memory data to the stack) causing the
> s
Re-hi,
Note another issue: the slp_switch() function, from gcc's point of
view, does not call any other function. This means gcc will not
produce the needed header/footer code. Look at switch_arm_gcc.h for
the lengths we need to go through to make sure to save/restore
everything and realign the
Hi Marcos,
On Wed, Oct 14, 2015 at 12:58 PM, Marcos Dione wrote:
> inception_locals= sys._getframe().f_back.f_locals
> inception_locals.update (locals)
I think this works if you *assign* to f_locals. When you only *read*
f_locals, you get a copy of the dict. The assignment is needed to
write t
Hi Marcos,
On Thu, Oct 15, 2015 at 4:50 PM, Marcos Dione wrote:
>> so I'll keep investigating :-]
>
> maybe context managers add a stack frame/do something with them
> internally?
Sorry, you're right. Now it seems from looking at the CPython source
code that there is no way. This is ge
Hi Marcos,
On Fri, Oct 16, 2015 at 8:16 PM, Marcos Dione wrote:
> as for the hack itself, it works! \o/ thanks very much for the
> pointers :) Cheers,
No problem. Actually, some Googling finds the very same hack used at
various places and explained in blog posts...
Armin
__
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 ?
No, you're jumping to conclusions only because of numbers that look
like Ubuntu's.
Armin
___
pypy-de
Hi,
On Thu, Oct 22, 2015 at 10:48 AM, William ML Leslie
wrote:
> It comes with cpython, as part of the 'frozen' module system.
We can add a file ``lib_pypy/__hello__.py`` containing ``print 'Hello
world...'``. That seems highly pointless, though, if we don't support
frozen modules anyway.
A b
Hi Jeff,
On Tue, Nov 3, 2015 at 11:57 PM, Jeff Doran wrote:
> Just an update on this problem. I retested using the latest lxml source
> from here ( 3.5.0b2?)
There were a few fixes to PyPy's cpyext layer. But there was no
change to lxml itself. That means it is still using a broken approach
t
Hi Dmitry,
On Thu, Nov 5, 2015 at 12:40 AM, Dmitry Sagalovskiy wrote:
> I've been wondering why it is that 'time' module is so broken in the
> sandbox? Is there any fundamental reason why it can't be supported?
No, it's just that we improved the 'time' module at some point by
getting rid of very
Hi Andrew,
On Sat, Nov 7, 2015 at 9:43 AM, Maciej Fijalkowski wrote:
> This looks fairly serious, we would love to have a way to reproduce
> it. For what is worth, you don't have to minimize the example very
> much - a program we can run, even if it has serious dependecies, is
> ok, but we NEED t
Hi Hakan,
On Sat, Nov 7, 2015 at 12:11 PM, Hakan Ardo wrote:
> Also maybe for an opaque pointer to an array that was pointing some instance
> in the first iteration?
Yes, anything dereferencing a pointer basically---during optimization.
It should only matter for Consts.
I realized it is annoyin
ReHi,
On Sat, Nov 7, 2015 at 2:25 PM, Armin Rigo wrote:
> More thoughts needed.
One solution would be to use two modes when optimizing the two
unrolled versions of the loop. For the 1st version we do like now.
But the 2nd version is run "speculatively" and so more care is needed:
Hi,
On Sat, Nov 7, 2015 at 2:40 PM, Armin Rigo wrote:
> Would that miss an important case?
Fijal shed doubt on that, so I'm going with this solution:
For GC objects, check the gctype or correct subclass when doing an
access from the optimizer. (We can't do that with Boehm, but
Hi Stefan,
On Sun, Nov 8, 2015 at 5:51 AM, Stefan Behnel wrote:
> I tried to simply disable the special casing in proxy.pxi, but it only
> leads to more crashes:
Yes, it is expected. The special-casing was introduced because PyPy
doesn't guarantee the identity of "PyObject *" when you don't own
Hi Hakan,
On Sun, Nov 8, 2015 at 9:39 AM, Hakan Ardo wrote:
> A small adjustment to your approach that would cover those cases is to
> compare the values of the constants with the values observed during tracing.
> If they are the same it should be safe to perform the read, right?
Ah, that's a go
Hi Andrew,
On Sun, Nov 8, 2015 at 9:52 AM, Armin Rigo wrote:
> I'm still going with checking the gctype of the object. It should
> work in the same cases (and theoretically more but well).
Not done yet, but I think I fixed Andrew's original problem. Andrew,
could you try again
Hi Anto,
On Sun, Nov 22, 2015 at 12:10 PM, Antonio Cuni wrote:
> I suspect a big/little endian issue.
Fwiw, the error doesn't seem to be an endianness issue, but rather
reading garbage (and I'm pretty sure that all our ARMs are little
endian).
A bientôt,
Armin.
___
Hi again,
Here's a guess. The value expected is 0x4142434445464748. The value
we read is 0xb3f4bce041424344. That hints at an off-by-4-bytes issue.
My guess is an alignment issue. When you force-cast the RPython
string to a type with an 8-bytes-per-item array, on some 32-bit
platforms it might
Hi Laura, hi Robin,
On Mon, Nov 23, 2015 at 4:30 PM, Laura Creighton wrote:
>>> Lastly what is the right way to get the platform as pypy not cpython?
>
> Detecting pypy is a bit harder.
No, no: the official way since many years is
if "__pypy__" in sys.builtin_module_names:
A bientôt,
Arm
Hi all,
Due to public pressure :-) I'm trying to organize this winter's
sprint, in Leysin, Switzerland. This is a fully public sprint of 7
days, with possible skiing.
If you'd like to come, please reply to this e-mail with dates that are
ok for you. I will give some priority to core people, bu
Hi all,
Laura pointed me to the Swiss Python Summit
(http://www.python-summit.ch/), a small conference on February 5th.
It is, however, a single day and at the opposite end of Switzerland
(4h15 by train). Still, maybe we could set the sprint up the
following week (~7-13) just in case someone want
Hi all,
The sprint should be on the week of February, the 21-28th. A final
confirmation will have to wait for around two more weeks, but unless
there is really an unexpected problem, it should be this date. I will
of course sent a proper sprint announcement then.
A bientôt,
Armin.
___
Hi Elmir,
On Sun, Dec 13, 2015 at 10:19 PM, Elmir Jagudin wrote:
> The error happens in the python-ldap C code that converts ["uid", "cn"]
> array to char **.
>
> In this file:
> http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/LDAPObject.c?revision=1.91&view=markup
>
Hi again,
On Mon, Dec 14, 2015 at 10:01 AM, Armin Rigo wrote:
> So it means it's really a bug of python-ldap, which just happens to
> crash more often on PyPy than on CPython. It should be fixed there.
Actually it's a known issue. See the comment line 255:
XXX the str
Hi Oscar,
On Wed, Dec 16, 2015 at 1:39 PM, Oscar Benjamin
wrote:
> Does tkinter work with PyPy yet (It doesn't in
> the version I have installed here)?
It should work. Did you install a recent official release, or compile
it yourself? In the latter case, do you have the "tk-dev" headers
instal
Hi Oscar,
On Wed, Dec 16, 2015 at 2:05 PM, Oscar Benjamin
wrote:
> libtcl8.5.so: cannot open shared object file: No such file or
> directory
>
> Is that an obscure crash?
Sadly not. It just means it was compiled for libtcl8.5.so, and your
machine has a different version installed. You can reco
Hi Oscar,
On Thu, Dec 17, 2015 at 3:33 PM, Oscar Benjamin
wrote:
> Maybe it's just missing the symlink from libtcl8.5.so ->
> libtcl8.5.so.0. I'm not sure why it would be setup like that.
Yes. I mostly gave up understanding the differences in binary
distributions in Linux. It just turns out th
Hi Oscar,
On Fri, Dec 18, 2015 at 1:56 PM, Oscar Benjamin
wrote:
> It seems to have already been fixed on the py3k branch so I'm not sure
> if it needs reporting:
We usually look at the py3.3 branch, which is for Python 3.3
compatibility; if it's also fixed there then there is nothing more to
re
Hi Remi,
Just thinking about stmgc: currently it requires large transactions in
order to work efficiently. I think it is mostly caused by the fact
that transaction commits always force a minor collection. Maybe we
should rethink that at some point, by changing the GC completely...
There are movi
Hi Maciej,
On Wed, Dec 23, 2015 at 3:48 PM, Maciej Fijalkowski
wrote:
> I bet the difference is due to "we see more FDs in pypy". If you close the
> correct FD in CPython, it would break too I presume? Or is there special
> code to handle that?
>
There is special code to handle that in CPython.
Hi Vincent,
On Wed, Dec 23, 2015 at 7:05 PM, Vincent Legoll
wrote:
> Do you thought about that removed code ?
> https://bitbucket.org/vincentlegoll/pypy/commits/992e29624c5fd8a7e76677acf085fea0520f576d
>
> The filedesc was not kept opened there, or do you meant another thing
> in this file ?
Tha
Hi Vincent,
On Thu, Dec 24, 2015 at 3:34 PM, Vincent Legoll
wrote:
> I may give this an eye if no one beats me to it, just not today, time
> to overeat!
:-) In the meantime I reverted the older checkin that caches the file
descriptor, with a comment, in c6be1b27fa1d.
A bientôt,
Armin.
__
Hi Vincent,
On Thu, Dec 24, 2015 at 5:50 PM, Vincent Legoll
wrote:
> Are we really seeing a closed and reopened fd ?
> And if that's the case it may even be intentional ;-)
>
> because if we're only seeing a closed python file object, we could go
> the simpler way:
>
> -if not context[0]:
Hi Vincent,
On Sat, Dec 26, 2015 at 1:45 PM, Vincent Legoll
wrote:
> OK, I understand we want to have behavior as identical to cpython as possible.
>
> So does that mean implementing the same : "fstat() & check we're still
> on the same inode & device as before" ?
> Do we also need to do the "cou
Hi Matti,
Happy new year :-)
On Fri, Jan 1, 2016 at 10:31 AM, Matti Picus wrote:
> Are the dates firm enough that I can order flights? It is getting late...
I should have the definitive confirmation tomorrow.
Armin
___
pypy-dev mailing list
pypy-dev
wiss-to-(insert country here) power adapter. There will be
some Swiss-to-EU adapters around, and at least one EU-format power strip.
---Armin Rigo
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
wiss-to-(insert country here) power adapter. There will be
some Swiss-to-EU adapters around, and at least one EU-format power strip.
---Armin Rigo
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
Hi Marky,
No clue why, but your e-mail written 3 days ago only shows up now on
the mailing list... If you didn't get any answer on IRC in the
meantime: that test is about this line:
__pypy__.save_module_content_for_future_reload(sys)
The test is failing because that line didn't have
Hi Marky,
On Tue, Jan 5, 2016 at 9:56 AM, Armin Rigo wrote:
> __pypy__.save_module_content_for_future_reload(sys)
>
> The test is failing because that line didn't have any effect.
Maybe I'm wrong, and the exact cause is more subtle. In general, you
should firs
Hi Vincent,
On Sun, Dec 27, 2015 at 11:45 AM, Vincent Legoll
wrote:
> So to stay on the safe side, you prefer to keep reopening every time ?
> https://bitbucket.org/vincentlegoll/pypy/commits/branch/fix-urandom-closed
I'm not against a proper fix :-) The problem is that for the fix to
be proper
Hi Richard,
On Thu, Jan 14, 2016 at 6:32 PM, Richard Plangger wrote:
> -- parameter (1213,1213) both 64-bit
> as 64bit integer> (2)
Do you mean in both cases 16-bit integer instead of 64-bit integer?
> returns every frame back to and saves 0xdeadbeefdead097a
> My understanding is
Hi David,
On Fri, Jan 15, 2016 at 2:28 PM, David Edelsohn wrote:
>> In more details: my point of view is that libffi is *documented* to
>> return the value
>> 0x097a, but instead it returns 0xdeadbeefdead097a.
>
> libffi is *documented* to return the non sign-extended value.
Ok. I t
Hi Richard,
On Fri, Jan 15, 2016 at 2:59 PM, Richard Plangger wrote:
> I have fixed this issue at the call site. The caller sign/zero extends
> narrower integer types. The reason I did not change it to that in the
> first place is: I thought that it is not easy to determine this
> information at
Hi Richard,
On Tue, Jan 19, 2016 at 12:12 PM, Richard Plangger wrote:
> 1) Generally I got the impression that there are some tests that do not
> consider endianess (e.g. micronumpy). I guess it is time to change them
> to handle this? What about PPC? Did those not come up there?
I must admit I
Hi Richard,
On Tue, Jan 19, 2016 at 4:47 PM, Richard Plangger wrote:
> Some of the failing tests (on the buildbot only) are very severe, and it
> is hard to find out the cause if they do not fail on the development
> machine...
Note: at this point where a JIT backend is "mostly done", subtle bug
Hi Richard,
On Thu, Jan 28, 2016 at 2:37 PM, Richard Plangger wrote:
> the file rpython/translator/c/src/stack.h defines MAX_STACK_SIZE. PPC
> has a bigger limit than e.g. x86. I experienced that on s390x there is
> as well a higher consumption of memory for stack frames (they are
> variable size
Hi Richard,
On Tue, Feb 2, 2016 at 6:11 PM, Richard Plangger wrote:
> * There is one path in call_release_gil (just after the call) where
> rpy_fastgil was acquired (because it as 0) and the shadowstack is not
> the one of the current thread. Then *rpy_fastgil = 0 is set for the
> slowpath functi
Hi Robert,
On Mon, Feb 15, 2016 at 4:37 PM, Robert Grosse wrote:
> https://bitbucket.org/pypy/pypy/issues/2239/segfault-in
Thanks! Your example turned an impossible-to-debug problem into a
relatively easy one. Fixed and tested in 96c2ec82f010. Now at least
the command line you give in the iss
Hi all,
If you're coming to the Leysin sprint, a few extra instructions:
* look up your way on
https://www.openstreetmap.org/#map=17/46.34727/7.01722 . Chalet
Ermina is "up right" in this view. Scroll a bit left-down to see the
train stations. The closest is Leysin-Feydey, though you may also
Hi,
On Tue, Feb 16, 2016 at 2:53 PM, Maciej Fijalkowski wrote:
> Armin, is L'essentiel on open street map at the right spot?
Yes, I've put it there myself when the place opened :-)
Armin
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.pyth
Hi Stefan,
On 8 November 2015 at 09:40, Armin Rigo wrote:
> On Sun, Nov 8, 2015 at 5:51 AM, Stefan Behnel wrote:
>> I tried to simply disable the special casing in proxy.pxi, but it only
>> leads to more crashes:
>
> Yes, it is expected. The special-casing was introduced b
Hi Piotr,
Thanks for giving some serious thoughts to the utf8-stored unicode
string proposal!
On 5 March 2016 at 01:48, Piotr Jurkiewicz
wrote:
> Random access would be as follows:
>
> page_num, byte_in_page = divmod(codepoint_pos, 64)
> page_start_byte = index[page_num]
>
Hi Matti,
On 8 March 2016 at 15:15, matti picus wrote:
> We could package it and upload as rc1, but version_info will not have rc1
> unless we rerun the builds. Confusing.
> I prefer to apologize if we get it wrong and release a 5.0.1 bugfix
+1. Go ahead as far as I'm concerned.
About the rel
Hi,
On 8 March 2016 at 15:42, Maciej Fijalkowski wrote:
> btw, should we mention packages.pypy.org?
I would do so but only under two conditions:
* it reports a post-cpyext-fixes result: which packages run or don't
run now, ideally on the current "release 5.0" branch, but at least
after the merg
Hi hubo,
On 7 March 2016 at 13:49, hubo wrote:
> I think in Python 3.x, u'\ud805\udc09' is not another format of
> u'\U00011409', it is just an illegal unicode string. It also raises
> UnicodeEncodeError if you try to encode it into UTF-8. The problem is that
> it is legal to define and use these
Hi Robin,
On 8 March 2016 at 17:10, Robin Kruppe wrote:
> I just wanted to mention that several other language implementors have faced
> ...
> While everything described there may be pretty obvious (for those immersed
> in the guts of Unicode), I wanted to raise awareness that this has a name
> a
Hi Magnus,
On 15 March 2016 at 03:32, Magnus Morton wrote:
> [translation:ERROR] MissingRTypeAttribute: on_abort
> [translation:ERROR] ..
> (rpython.jit.metainterp.pyjitpl:2224)MetaInterp.aborted_tracing
> [translation:ERROR] .. block@59 with 2 exits(v1678)
> [translation:ERROR] .. v1680 = getat
Hi Magnus,
On 15 March 2016 at 15:45, Magnus Morton wrote:
> Yes, it has all the methods defined. If I take out the assignment, but still
> define a JitPolicy with the hooks, it translates fine.
Can't help, I would need to reproduce the problem first. Please give
step-by-step instructions abou
Hi Magnus,
On 16 March 2016 at 01:37, Magnus Morton wrote:
> You can recreate it in PyPy by putting the following two lines pretty much
> anywhere in interpreter level code other than the
> setup_after_space_initialization methods
>
> from pypy.module.pypyjit.hooks import pypy_hooks
> pypy_hook
Hi Pim,
On 18 March 2016 at 15:08, Pim van der Eijk (Lists)
wrote:
>>> - Memory use continues to grow up to over 80% at which time where my
>>> laptop
>>> starts swapping, whereas with CPython usage is never more than 4%.
>>
>> This is more annoying. Can you give us a way to reproduce this?
>
Hi Pim,
On 16 March 2016 at 17:32, Pim van der Eijk (Lists)
wrote:
> Did the lxml project indicate they will provide a new release soon that
> incorporates these fixes?
You'll have to ask on the lxml mailing list.
Armin
___
pypy-dev mailing list
pypy-
Hi again,
On 17 March 2016 at 17:27, Armin Rigo wrote:
> On 17 March 2016 at 16:13, Pim van der Eijk (Lists)
> wrote:
>> There is a new lxml release as of today, unfortunately there is an issue:
>> https://bitbucket.org/pypy/pypy/issues/2260/pypy-500-dumps-core-with-lxml-360
Hi,
On 17 March 2016 at 16:13, Pim van der Eijk (Lists)
wrote:
> There is a new lxml release as of today, unfortunately there is an issue:
> https://bitbucket.org/pypy/pypy/issues/2260/pypy-500-dumps-core-with-lxml-360
Yes, it's what we get when both sides (lxml and pypy) are half-hearted
about
Hi Pim,
On 18 March 2016 at 13:25, Pim van der Eijk (Lists)
wrote:
> - For my test programs (the script in the issue on BitBucket is derived
> from one of them), PyPy is much slower.
If you're comparing the speed of scripts that have a large amount of
crossings of the cpyext layer (i.e. crossi
Hi John,
On 23 March 2016 at 19:16, John Camara wrote:
> I would like to suggest one more topic for the workshop. I see a big need
> for a library (jffi) similar to cffi but that provides a bridge to Java
> instead of C code. The ability to seamlessly work with native Java data/code
> would offer
Hi Nikolay,
On 14 March 2016 at 19:15, Николай Зинов wrote:
> I found implementing copy-on-write list slicing particularly interesting for
> me. Below go my ideas. Note, that at some places I see different possible
> choices so I need feedback.
Thanks for the early proposal; you should submit it
Hi John,
On 24 March 2016 at 13:22, John Camara wrote:
> (...) Thus the need for a jffi library.
When I hear "a jffi library" I'm thinking about a new library with a
new API. I think what you would really like instead is to keep the
existing libraries, but adapt them internally to allow tighte
Hi Petr,
On 10 April 2016 at 00:18, Petr Hanousek wrote:
> So I found the problem and now everything seems to compile OK.
Ok, that's nonsense to just eat and ignore stderr. I fixed it in 418eb4be7f64.
A bientôt,
Armin.
___
pypy-dev mailing list
pyp
Hi,
On 26 April 2016 at 19:02, Carl Friedrich Bolz wrote:
> Those are simple cases, of course we use the same exception types there.
> However, if you write exactly the wrong obscure code you sometimes get a
> different exception type under some conditions.
That's about TypeError versus Attribut
Hi Wim,
We are linking from the PyPy documentation to these pages:
http://root.cern.ch/drupal/content/reflex
http://root.cern.ch/drupal/content/generating-reflex-dictionaries
They are 404 now. What should they be fixed to?
A bientôt,
Armin.
___
pyp
Hi,
On 27 April 2016 at 10:14, Maciej Fijalkowski wrote:
> Any chance we can add this to cpython-differences? Couldn't find it
> last time (and misremembered)
Done (434d21e15d0d).
Armin
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python
Hi Raoul,
On 27 April 2016 at 22:42, Raoul Veroy wrote:
> First a question about the old reference counting implementation in Pypy.
It is still there, used mainly by tests of the C backend. But it
wasn't used for translating the full PyPy for many years now, so you
are very likely to get into v
Hi Richard,
On 29 April 2016 at 16:54, Richard Plangger wrote:
> * Feature parity with the old jitviewer (what is missing?)
A few "obvious" things from my point of view:
1. Showing the descrs is very useful. Currently, we get "p6 =
getfield_gc_r(p0)"... thank you, but that's not enough to dedu
Hi all, hi Matti,
If a CPython C extension module is written in a way that calls some
PyXxx() function without the GIL (hoping that the code in this
particular function is kept simple enough that it still works), then
in the same situation it would loudly complain and crash on PyPy.
This is a prob
Hi Ruochen,
On 5 May 2016 at 08:17, 黄若尘 wrote:
> Recently I’m trying to apply a new tracing JIT policy to Pyrlang, I found
> there are some traces that were too long and therefore aborted by JIT
> according to rpython’s JIT log.
You can find them without using JitHookInterface:
jitdriver
Hi Omer,
On 6 May 2016 at 09:02, Omer Katz wrote:
> I'm wondering if PyPy could by a chance benefit from implementing the blist
> algorithm as a strategy. Possibly even switching it to be the default.
>
> What do you guys think?
It would certainly be interesting to try.
The problem with using *
Hi Omer,
On 6 May 2016 at 11:04, Omer Katz wrote:
> I agree that we can certainly benefit from using blists in large enough
> lists. How much is large enough? We'll probably need to benchmark right?
>
> Are there any JIT paths for blist operations?
Do you mean "would we need to add specific JIT
Hi all,
I wanted to communicate this to whoever added the pypy-dev list to
"all-mail-archive.com": the subsciption has been disabled---excessive
or fatal bounces.
Armin
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listi
Hi Sayth,
We're fully open to people doing this kind of packaging. From
our point of view it is a good idea, as long as the packaging is
kept up-to-date with reasonably recent releases of PyPy. If you
want to start such a project, you are welcome to. Such a project
for Windows would be particul
On 19 May 2016 at 14:58, wrote:
> -- Forwarded message --
> From: Daniel Hnyk
> To: pypy-dev@python.org
> Cc:
> Date: Thu, 19 May 2016 12:58:36 +
> Subject: Question about funding, again
> Hello,
>
> my question is simple. It strikes me why you don't have more financial
> su
Hi Eli,
On 19 May 2016 at 08:58, Eli Stevens (Gmail) wrote:
> I've got a pypy clone and checkout, and have added TestFlags. When I
> run it, I see:
>
>> a.flags.writeable = False
> E TypeError: readonly attribute
>
> But nothing that looks like it should raise a TypeError in either of
Hi,
On 19 May 2016 at 21:29, Kotrfa wrote:
> Of course, I cannot ensure that you might get reasonably funded on
> kickstarter-like sites. But, what can you lose by making a campaign? It
> would be definitely much more visible than on your website
I should add that we did that already: we have th
Hi,
On 27 May 2016 at 09:24, Maciej Fijalkowski wrote:
> Another game boy emulator using RPython https://github.com/Baekalfen/PyBoy
It's not actually using RPython. It's a standard Python program, and
the PDF has graphs about CPython versus PyPy performance.
Armin
Hi Jeff,
On 27 May 2016 at 23:45, Jeff Doran wrote:
> The resulting strings comes from Cookie.__str__ I believe and the
> comparison in requests is a simple dict1 == dict2.
If what you're printing are two dicts, then they don't compare equal,
because of this value:
> 'NextGenCSO=8MWACYK5f24yllb
Hi all,
Recently, we've got a few more of the common bug report "cannot find
gc roots!". This is caused by asmgcc somehow failing to parse the
".s" files produced by gcc on Linux.
I'm investigating what can be done to improve the situation of asmgcc
in a more definitive way. There are basically
Hi Edd,
On 9 June 2016 at 17:19, Edd Barrett wrote:
> Recently OpenBSD has started enforcing W^X [1] for all programs, unless
> the program is on a file system with a special 'wxallowed' flag.
We already saw the "W^X" issue. A possible solution would be indeed
for the JIT to map W when it compi
Hi Stuart, hi all,
On 9 June 2016 at 17:13, Matti Picus wrote:
> If it doesn't work, please file an issue with exact steps to replicate.
I should add that by now, with a cpyext that seems to start working on
"hard" cases like numpy, chances are high that if you file an issue
for a particular pac
Hi Omer,
On 20 June 2016 at 08:51, Omer Katz wrote:
> As for implementation, if we can trace the code running in the thread and
> ensure it's not mutating global state and that CPyExt is never used during
> the thread's course we can simply release the GIL when such a thread is run.
That's a ver
Hi,
On 22 June 2016 at 03:08, Katelyn McNair wrote:
> I have been trying to install PyPy locally for the last 3 days. I didn't
> have Openssl, which install fine. But then PyPy started not liking the new
> version (libssl.so.1.0.1), so I got the archive for 1.0.0, and installed.
>
> But then Py
Hi John,
On 27 June 2016 at 04:31, John Zhang wrote:
> I’m using RFFI to reflect a C API interface that my colleague has developed.
> During this process I encountered the problem of not knowing how to define a
> recursive struct definition.
> e.g. How do I define a struct like the following:
> t
Hi Eli, hi Matti,
On 29 June 2016 at 21:37, Eli Stevens (Gmail) wrote:
> To make sure I'm understanding, are you saying that upstream/cpython
> numpy should pick up an alternate way to import multiarray (via
> _numpypy.multiarray, instead of numpy.core.multiarray)
Hum, in my opinion we should al
Hi John,
On 28 June 2016 at 09:23, John Zhang wrote:
> I have another question regarding passing an array value to C function using
> RFFI.
> Suppose I have a function in C that’s like this:
> void fn(void** array_of_voips, int length)
> How do I in RPython call the function using RFFI passing an
Hi,
On 30 June 2016 at 13:15, Yury V. Zaytsev wrote:
> On Thu, 30 Jun 2016, Paul Baker wrote:
>> Why is PyPy so much bigger than CPython? Is it possible to build a version
>> of PyPy which is closer to CPython in size?
>
> It may be very well possible with some compilation flags juggling, but
> b
Hi Jeff,
On 8 July 2016 at 22:17, Jeff Doran wrote:
> Since I've overcome all the consistently repeatable errors in running our
> tests via nosetests, I'm now left with a frustratingly inconsistent, but
> frequent error that leaves me with no clue.
I'd recommend using RevPDB (see blog post from
Hi Nagy,
On 3 June 2016 at 09:45, Nagy, Attila wrote:
> Consider this example program:
> https://gist.github.com/bra-fsn/1fd481b44590a939e849cb9073ba1a41
I've reduced it to a minimal example and created an issue.
https://bitbucket.org/pypy/pypy/issues/2341/multithreading-locks-leading-to-poor-c
Hi Andrey,
On 14 July 2016 at 17:08, Andrey Rubik wrote:
> Jmeter - tool for performance tests. So when i start high load tests written
> in scripting languages i get so much load on jmeter server. That is why I
> choose PyPy - for much speed from testing server.
>
> Sry, but i'am not a developer
Hi Phyo,
On 15 July 2016 at 15:58, Phyo Arkar wrote:
> For most python programmers we stay away from Java as much as possible. We
> are allergic to it.
That's a broad generalization, maybe not appropriate for this list.
A bientôt,
Armin.
___
pypy-d
Hi Nagy,
On 3 June 2016 at 09:45, Nagy, Attila wrote:
> Consider this example program:
> https://gist.github.com/bra-fsn/1fd481b44590a939e849cb9073ba1a41
I think I fixed this problem in 919e00b3e558 two days ago. Now it
seems to always use about 100% CPU and gets performance that is a bit
bette
1101 - 1200 of 1465 matches
Mail list logo
