[pypy-dev] Re: Contribute a RISC-V 64 JIT backend

Hi Logan Additionally to what Matti says, there are random fuzzing tests like test_ll_random.py in jit/backend/test. Run those for longer than the default (e.g. whole night) to see if they find issues Best, Maciej Fijalkowski On Tue, 16 Jan 2024 at 07:02, Logan Chien wrote: > > Hi, >

[pypy-dev] Re: Contribute a RISC-V 64 JIT backend

Hi Logan As far as I remember (and neither Armin nor I did any major pypy development recently), the vectorization was never really something we got to work to the point where it was worth it. In theory, having vectorized operations like numpy arrays to compile to vectorized CPU instructions

[pypy-dev] Re: Contribute a RISC-V 64 JIT backend

Hi Logan Very cool you are interested in that! It's often useful to hang out on IRC as you can ask questions directly. I have not taken any looks at all, but can you tell me what kind of setup does one need for testing it? Are you using real hardware or emulation? The approach of starting with

[pypy-dev] Re: Moving to github

as a non-participating contributor, a non-voting +1 from me On Fri, 29 Dec 2023 at 23:31, Simon Cross wrote: > > Hi Matti, > > On Thu, Dec 28, 2023 at 9:22 AM Matti Picus wrote: > > Now that 7.3.14 has been released, I would like to move the canonical > > repo for pypy and rpython to github.

Re: [pypy-dev] Does PyPy memory use benefit from preforking?

been implemented. Best, Maciej Fijalkowski On Sat, 18 Sept 2021 at 21:58, Tin Tvrtković wrote: > > Hello! > > A little bit of context: roughly speaking, preforking is a technique where a > (supervisor) process is started, the process performs some initialization and > then fo

[pypy-dev] rpython.org

Hey everyone, rpython.org expired because I didn't pay in time Sorry about that, I will try to be more on it. It's fixed now Best, Maciej ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

[pypy-dev] Pre-release of arm64

Hey everyone Apparently it's enough that we put a new image on download.html page for docker to officially have arm64 image of pypy, since that's where they download it from. Is it ok if I put there a pre-release for arm64? Best, Maciej Fijalkowski

[pypy-dev] More feedback on new pypy.org

Hi everyone! Here is the next iteration of pypy.org - https://baroquesoftware.com/pypy-website/web/ - after adding some feedback. Note that no work has been done on content just yet. Feel free to provide more feedback. We also need to decide what to do with the logo. Best, Maciej Fijalkowski

Re: [pypy-dev] Why is pypy slower?

On Wed, Feb 13, 2019 at 3:57 PM Joseph Reagle wrote: > > > On 2/13/19 9:38 AM, Maciej Fijalkowski wrote: > > My first intuition would be to run it for a bit longer (can you run > > it in a loop couple times and see if it speeds up?) 2s might not be > > enough for

Re: [pypy-dev] Why is pypy slower?

Hi Joseph My first intuition would be to run it for a bit longer (can you run it in a loop couple times and see if it speeds up?) 2s might not be enough for JIT to kick in on something as complicated On Wed, Feb 13, 2019 at 3:11 PM Joseph Reagle wrote: > > Hello all, thank you for your work on

Re: [pypy-dev] Fwd: Re: Users of PyPy on ARM 32bit

On Mon, Feb 11, 2019 at 6:18 PM Matti Picus wrote: > > > On 8/2/19 7:44 pm, Carl Friedrich Bolz-Tereick wrote: > > > > > > > > *From:* Gelin Yan > > *Sent:* February 8, 2019 3:26:30 PM GMT+01:00 > > *To:* Carl Friedrich

Re: [pypy-dev] let's clean up open branches

100 guard-improvements > Hakan Ardo 2011-03-27 18:01 +0200 jit-usable_retrace > Hakan Ardo 2011-08-20 09:57 +0200 jit-limit_peeling > Hakan Ardo 2012-01-05 10:41 +0100 jit-usable_retrace_2 > Hakan Ardo 2013-02-04 22:39 +0100 jit-usable_retrace_3 > Ilya Osadchiy 2011-10-19 22:51 +

Re: [pypy-dev] Feedback on pypy.org website revamp

On Fri, Feb 8, 2019 at 11:17 AM Maciej Fijalkowski wrote: > > Hi everyone > > We are looking to redesign the main pypy website, how do people feel > about the new quick look: > > https://baroquesoftware.com/pypy-website/web/ > > Best, > Maciej Fijalkowski __

[pypy-dev] Feedback on pypy.org website revamp

Hi everyone We are looking to redesign the main pypy website, how do people feel about the new quick look: https://baroquesoftware.com/pypy-website/web/ Best, Maciej Fijalkowski ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org

Re: [pypy-dev] tensorflow support

in person :) Best regards, Maciej Fijalkowski On Tue, Sep 4, 2018 at 2:05 PM, Shuaib Osman wrote: > Hi, > > > > I’ve been using pypy on windows (32-bit) for some time now, and was > wondering what the status is on the following: > > > > 1) Windowx x64 support

[pypy-dev] PyPy sprint in Poland

Hi Everyone. It looks like I would be in Europe through April and maybe May. Anyone fancy a sprint somewhere in Poland? Potential venues: * we can have a sprint at my climbing spot - it's quite a problem to get to (~2-3h by train from either Prague or Wroclaw), but it's incredibly lovely at this

Re: [pypy-dev] Pypy's facelift and certificate issues

lves and I can join :-) ... But I believe I could find some time > before then for simple redesign. > > Best, > Daniel > > so 30. 12. 2017 v 11:49 odesílatel Maciej Fijalkowski <fij...@gmail.com> > napsal: >> >> Hi Kotrfa. >> >> Great, we would definitel

Re: [pypy-dev] Pypy's facelift and certificate issues

Hi Kotrfa. Great, we would definitely appreciate some help. I have very sketchy internet till next week, maybe we can coordinate something next week on IRC? What timezone are you in? Best regards, Maciej Fijalkowski On Sat, Dec 30, 2017 at 9:41 AM, Kotrfa <kot...@gmail.com> wrote:

Re: [pypy-dev] Pypy's facelift and certificate issues

Hi Kortrfa I've even paid for a design of new pypy logo that we can use on the new website :-) Maybe it's a good time I spend some effort upgrading it. Thanks for the reminder, it's something that's on our heads, but it's not like we can just hire someone to do it for us. Cheers, fijal On Wed,

[pypy-dev] Dual release v5.10.0 of PyPy2 and PyPy3 is out

The PyPy team is proud to release both PyPy2.7 v5.10 (an interpreter supporting Python 2.7 syntax), and a final PyPy3.5 v5.10 (an interpreter for Python 3.5 syntax). The two releases are both based on much the same codebase, thus the dual release. This release is an incremental release with very

Re: [pypy-dev] pypy 5.10 release

Hi Matti The build on downloads for OS X works only on High Sierra (10.13), since it expects utimesat in libc, which is only available from High Sierra. I will build a Sierra version on my computer that (hopefully) works on older OS X too. Otherwise looks good to go, I will update the website

Re: [pypy-dev] [pypy-commit] pypy default: "eh". On pypy we need to be careful in which order we have pendingblocks.

ah indeed, that's a much better fix :-) The original was done a bit haphazardly :-) On Sun, Nov 19, 2017 at 11:07 PM, Armin Rigo wrote: > Hi, > > On 9 November 2017 at 10:07, Antonio Cuni wrote: >> I suppose that the explanation that you put in the

[pypy-dev] Let's fix buildbots

Hi everyone I recently looked here: http://buildbot.pypy.org/summary and it looks quite grim. Can we stop for a second and fix most of those so we have some level of greenness around? Cheers, fijal ___ pypy-dev mailing list pypy-dev@python.org

Re: [pypy-dev] RPython proposed deprecation: translator.platform .distutils_platform

+1 On Mon, Nov 6, 2017 at 3:45 PM, Matti Picus wrote: > In addition to the arm, bsd, cygwin, darwin, freebsd, linux, maemo (really?) > netbsd, openbsd, posix, and windows rpython/translator/platforms, we have > one called "distutils_platform" that is allegedly supposed to

Re: [pypy-dev] Leysin Winter sprint

Hi Anto 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 the preference is basically "anything >=

Re: [pypy-dev] fiber support

t; At this point, it is not clear to me how to mimic this code using the cpyext > later at all. Or if it is even necessary if PyPy has a different > architecture for exception handling. > > --david > > On 10/17/17, 12:10 PM, "Maciej Fijalkowski" <fij...@gmail.com>

Re: [pypy-dev] fiber support

Hi David. You're probably completely aware that such calls (using cpyext) would completely kill performance, right? I didn't look in detail, but in order to get performance, you would need to write such calls using cffi. Best regards, Maciej Fijalkowski On Mon, Oct 16, 2017 at 7:18 PM, David

Re: [pypy-dev] dist.py:261: UserWarning: Unknown distribution option: 'cffi_modules'

Hi David Maybe pypy 3 does not come with correct distutils/setuptools gimmick to convince everyone cffi is installed? The way you described should generally work with PyPy. I'll have a look tomorrow at the sprint. Cheers, fijal On Fri, Oct 6, 2017 at 4:24 PM, David Callahan

Re: [pypy-dev] distutils configuration

the patch that changes it to accept it only conditionally. PS. If you're using PyPy to compile C extensions using distutils (as opposed to say cffi), while it's generally supported, the resulting extensions are quite slow. Best regards, Maciej Fijalkowski On Wed, Oct 4, 2017 at 2:52 PM, David

Re: [pypy-dev] Does pypy 58 arm version support numpy?

Wait for pypy 5.9 :-) On Sun, Aug 20, 2017 at 6:29 AM, Gelin Yan wrote: > Hi All > > When I tried to use pip to install numpy, I got some compiler failtures. > I want to know whether pypy arm version fully support numpy. > > OS: raspbian > Gcc version: 4.9.2 > Pypy

Re: [pypy-dev] PyBaseExceptionObject has no member named ‘args’

Hi Stuart. PyCairo should not abuse the API by directly accessing members of structures, this is not supported on pypy Cheers, fijal On Tue, Aug 15, 2017 at 12:57 AM, Stuart Axon via pypy-dev wrote: > Found this trying to compile pycairo, is it worth opening a bug about?

Re: [pypy-dev] GIL removal

ng to fund the rest? I'm more than happy to draft a contract (we have a commercial entity) to work on that topic. Best regards, Maciej Fijalkowski On Mon, Aug 14, 2017 at 6:10 PM, Brad Kish <brad.k...@arcticwolf.com> wrote: > The blog post on the GIL removal work seems to indicate that t

[pypy-dev] Link to paper

Hi Wim There was a complaint on reddit, that, quoting: "The link to the pyhpc paper does not work for me, does anyone have a mirror? Would love to read it." can you fix the link please? Cheers, fijal ___ pypy-dev mailing list pypy-dev@python.org

Re: [pypy-dev] okay to rename cppyy -> _cppyy

that's how cffi works FYI. +1 from me On Wed, Jul 19, 2017 at 12:33 AM, 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

Re: [pypy-dev] Call rpython from outside

Hi Armin We ended up (Aleksandr is here at pycon russia) using rffi_platform to get the exact shape of the structure from the header file. There were a few bugs how exactly this got mapped, so it ended up being a good way to do it. On Sat, Jul 15, 2017 at 8:02 AM, Armin Rigo

Re: [pypy-dev] Call rpython from outside

> Now it fails with a rather obscure error https://pastebin.com/MZkni9bU > Anyway, Maciej, see you at PyConRu 17) > > 2017-07-11 18:20 GMT+03:00 Maciej Fijalkowski <fij...@gmail.com>: >> >> Sorry wrong, lltype.GcStruct is GC managed, lltype.Struct should work. >>

Re: [pypy-dev] Call rpython from outside

Sorry wrong, lltype.GcStruct is GC managed, lltype.Struct should work. However, please use rffi.CStruct (as it's better defined) and especially rffi.CArray, since lltype.Array contains length field On Tue, Jul 11, 2017 at 6:49 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > llty

Re: [pypy-dev] Call rpython from outside

lltype.Struct is a GC-managed struct, you don't want to have this as a part of API (use CStruct) On Mon, Jul 10, 2017 at 6:15 PM, Aleksandr Koshkin wrote: > Here is a link to a function that buggs me. > https://github.com/magniff/rere/blob/master/rere/vm/vm_main.py#L110 >

Re: [pypy-dev] Suggestion : Build Using PyPy page to showcase.

Hey Phyo Good job, thanks for the feedback! On Tue, May 30, 2017 at 9:47 AM, Phyo Arkar wrote: > We had launched our chat-room for medical consultation , in our country. > It is reaching 5000 users in first month and growing fast with 400 > concurrent user max , daily.

Re: [pypy-dev] win32 buildbot

Hi Yuri. While I do not have powers to make a decision, I think it's very reasonable if pypy pays for such parts. If you can provide cost estimates, I'll try to go through the appropriate channels to have this approved, if you're interested. On Wed, May 10, 2017 at 9:53 PM, Yury V. Zaytsev

Re: [pypy-dev] pypy real world example, a django project data processing. but slow...

the possibly curious. > > The pypy itself is interesting and I hope I'll return to it someday more > thoroughly. > > Thanks again & have a nice day, > > Vláďa > > > On 27.3.2017 17:21, Maciej Fijalkowski wrote: >> Hi Vlada >> >> Generally speaking,

Re: [pypy-dev] pypy real world example, a django project data processing. but slow...

Hi Vlada Generally speaking, if we can't have a look there is incredibly little we can do "I have a program" can be pretty much anything. It is well known that django ORM is very slow (both on pypy and on cpython) and makes the JIT take forever to warm up. I have absolutely no idea how long is

Re: [pypy-dev] Speeds of various utf8 operations

Yes sure, I'm aware of that :-) The problem only shows up with "start" and "end" parameters being used On Mon, Mar 6, 2017 at 11:13 AM, Armin Rigo <armin.r...@gmail.com> wrote: > Hi Maciej, > > On 5 March 2017 at 20:24, Maciej Fijalkowski <fij...@gmail.com&

Re: [pypy-dev] Speeds of various utf8 operations

This is checking for spaces in unicode (so it's known to be valid utf8) On Sun, Mar 5, 2017 at 11:14 AM, Armin Rigo <armin.r...@gmail.com> wrote: > Hi Maciej, > > On 4 March 2017 at 19:01, Maciej Fijalkowski <fij...@gmail.com> wrote: >> def next_codepoint_pos(code, p

[pypy-dev] revisit web assembly?

I just found that: https://sourceware.org/ml/binutils/2017-03/msg00044.html It might be cool to see, maybe we can relatively easily compile to the web platform. Even interpreter-only version could be quite interesting. Cheers, fijal ___ pypy-dev

Re: [pypy-dev] Speeds of various utf8 operations

_SIMD_Extensions? in comparison to CPython is this much slower ? On Sun, Mar 5, 2017 at 12:32 AM Maciej Fijalkowski <fij...@gmail.com> wrote: > Hello everyone > > I've been experimenting a bit with faster utf8 operations (and > conversion that does not do much). I'm writing down the res

Re: [pypy-dev] Speeds of various utf8 operations

ison to CPython is this much slower ? > > On Sun, Mar 5, 2017 at 12:32 AM Maciej Fijalkowski <fij...@gmail.com> wrote: >> >> Hello everyone >> >> I've been experimenting a bit with faster utf8 operations (and >> conversion that does not do much). I'm writing

[pypy-dev] Speeds of various utf8 operations

Hello everyone I've been experimenting a bit with faster utf8 operations (and conversion that does not do much). I'm writing down the results so they don't get forgotten, as well as trying to put them in rpython comments. As far as non-SSE algorithms go, for things like splitlines, split etc. is

Re: [pypy-dev] Numpy on PyPy : cpyext

. If there is a good case for speeding up numpy, we can get it a lot faster than it is right now and seek some funding for that. Neural networks might be one of those! Best regards, Maciej Fijalkowski On Fri, Mar 3, 2017 at 2:31 AM, Singh, Yashwardhan <yashwardhan.si...@intel.com> wrote: > Hi Everyone,

Re: [pypy-dev] Pandas on PyPy

release, hopefully! Best regards, Maciej Fijalkowski On Tue, Feb 28, 2017 at 8:06 PM, Singh, Yashwardhan <yashwardhan.si...@intel.com> wrote: > Hi Everyone, > > I was hoping to use Pandas with PyPy to speed up applications, but ran into > compatibility issues with PyPy. > Has anyo

Re: [pypy-dev] VMProf 0.4.0

There was definitely a massive problem with libunwind & JIT frames, which made it unsuitable for windows and os x Another issue was that libunwind made traces ten times bigger, for no immediate benefit other than "it might be useful some day" and added complexity. On linux I was getting ~7% of

Re: [pypy-dev] Leysin sprint?

I have a place to stay in Zurich so it's a bit of a win for me :-) I would prefer this to be somewhere around early March I think, but I can't yet commit Cheers, fijal On Mon, Jan 16, 2017 at 8:43 PM, Manuel Jacob wrote: > Hi, > > Fortunately, this year I can place my

Re: [pypy-dev] Mercurial "general delta"

as far as I understood the answer on #mercurial, it seems to be "no". If the only effect is that it uses less space on bitbucket servers then I presume it's not our problem On Sun, Dec 4, 2016 at 1:41 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > I don't know :-) >

Re: [pypy-dev] Mercurial "general delta"

I don't know :-) let's see On Sun, Dec 4, 2016 at 1:28 PM, Armin Rigo <armin.r...@gmail.com> wrote: > Hi Maciej, > > On 4 December 2016 at 12:27, Maciej Fijalkowski <fij...@gmail.com> wrote: >> can we somehow make it new thing on the bb? that would mean download >&

Re: [pypy-dev] Mercurial "general delta"

can we somehow make it new thing on the bb? that would mean download gets smaller On Sat, Dec 3, 2016 at 8:37 PM, Armin Rigo wrote: > Hi all, > > A quick note for people that have a PyPy repo since years and are > using it like me without ever re-cloning from Bitbucket: the

Re: [pypy-dev] PGO Optimized Binary

Hi 8% of that is very good if you can reproduce it across multiple runs (there is a pretty high variance I would think). You can also try running with --jit off. This gives you an indication of the speed of interpreter, which is a part of warmup On Wed, Nov 9, 2016 at 12:30 AM, Singh,

Re: [pypy-dev] Performance degradation in the latest pypy

On Sat, Oct 29, 2016 at 8:02 AM, Saud Alwasly <saudalwa...@gmail.com> wrote: > here is the new zip file including the missing package > > > On Fri, Oct 28, 2016 at 10:58 AM Maciej Fijalkowski <fij...@gmail.com> > wrote: >> >> (vmprof)[brick:~/Downloads/dir] $ p

Re: [pypy-dev] Performance degradation in the latest pypy

(vmprof)[brick:~/Downloads/dir] $ python Simulate.py Traceback (most recent call last): File "Simulate.py", line 9, in from pypyplotPKG.Ploter import Graph, plot2, hist, bar, bar2 File "/Users/dev/Downloads/dir/pypyplotPKG/Ploter.py", line 1, in import pypyplotPKG.pypyplot as

Re: [pypy-dev] Dontbug: A reversible debugger for PHP (similar in concept to RevDB for Python/PyPy)

Hi Sidharth I see dontbug is based on rr - I would like to know how well rr works for you. We've tried using rr for pypy and it didn't work as advertised. On the other hand it seems the project is moving fast, so maybe it works these days On Thu, Oct 20, 2016 at 9:50 PM, Sidharth Kshatriya

Re: [pypy-dev] NumPy or NumPyPy

Hi We're maintaining both and we are planning into merging (in some point in the future) the good parts of numpypy (speed of array access) with the good parts of c numpy (compatibility) On Tue, Sep 27, 2016 at 11:01 PM, Papa, Florin wrote: > Hello, > > I read this

Re: [pypy-dev] improve error message when missing 'self' in method definition

On Tue, Sep 27, 2016 at 8:33 PM, Ryan Gonzalez wrote: > Have you considered bringing this up on python-ideas, too? python-idea is generally quite a hostile place. That said, if you think it's worth your effort to submit it there, feel free to do so, just the core pypy devs feel

Re: [pypy-dev] improve error message when missing 'self' in method definition

I'm +1 On Tue, Sep 27, 2016 at 7:19 PM, Carl Friedrich Bolz wrote: > Hi all, > > I read this paper today about common mistakes that Python beginners > make: > >

Re: [pypy-dev] Build Pypy with different Interpreters

Hi Jan The short answer is - all of those interpreters are a lot slower than pypy. Having even relatively good parallelization (and only some steps can be parallelized) would yield no improvements over using pure pypy for the most examples On Thu, Sep 8, 2016 at 2:38 PM, Jan Brohl

[pypy-dev] jetbrains vulnerability and py3k money

So apparently someone just made a big donation to pypy 3k project. Details here: http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis/ Cheers, fijal ___ pypy-dev mailing list

Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

On Thu, Aug 4, 2016 at 8:37 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi Peter, > > On 4 August 2016 at 08:05, Maciej Fijalkowski <fij...@gmail.com> wrote: >> The second one can be worked on using the same mechanisms as vmprof - >> there is C API that given th

Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

sage- > From: armin.r...@gmail.com [mailto:armin.r...@gmail.com] On Behalf Of Armin > Rigo > Sent: Tuesday, August 02, 2016 1:18 AM > To: Maciej Fijalkowski <fij...@gmail.com> > Cc: Wang, Peter Xihong <peter.xihong.w...@intel.com>; pypy-dev@python.org > Subject

Re: [pypy-dev] Fwd: NumPyPy vs NumPy

On Tue, Aug 2, 2016 at 8:02 AM, Eli Stevens (Gmail) wrote: > This was meant to go to the list, whoops. > > -- Forwarded message -- > From: Eli Stevens (Gmail) > Date: Mon, Aug 1, 2016 at 11:01 PM > Subject: Re: [pypy-dev] NumPyPy vs

Re: [pypy-dev] how to extend VTUNE support from pypy for application hot spot analysis

On Tue, Aug 2, 2016 at 12:46 AM, Wang, Peter Xihong wrote: > Hi Armin, > > As far as I know (my team members tried this), vmprof does not allow us to > attach to a running process? We will evaluate > https://github.com/vmprof/vmprof-python if you think it's doable.

Re: [pypy-dev] NumPyPy vs NumPy

On Mon, Aug 1, 2016 at 10:02 AM, Papa, Florin wrote: > Hi Armin, > >>The table also shows that PyPy NumPyPy is really slower, even with >>vectorization enabled. >>It seems that the current focus of our work, on continuing to improve cpyext >>instead of >>numpypy, is a

Re: [pypy-dev] integration with java

compiling jpype against PyPys CPython C API compatibility layer, but it would be at least very slow. Best regards, Maciej Fijalkowski On Wed, Jul 13, 2016 at 9:49 PM, Andrey Rubik <tirnota...@gmail.com> wrote: > Hi guys! > > I'am new at pypy development and need help. > > I want d

Re: [pypy-dev] PyParallel-style threads

no, you misunderstood me: if you want to use multiple processes, you not gonna start a new one per thing to do. You'll have a process pool and use that. Also, if you don't use multiprocessing, you don't use pickling, you use something sane for communication. The PyParallels essentially allows

Re: [pypy-dev] PyParallel-style threads

so quick question - what's the win compared to multiple processes? On Mon, Jun 20, 2016 at 8:51 AM, Omer Katz wrote: > Hi all, > There was an experiment based on CPython's code called PyParallel that > allows running threads in parallel without STM and modifying source code

Re: [pypy-dev] asmgcc versus shadowstack

hi armin I don't have very deep opinions - but I'm worried about one particular thing. GCC tends to change its IR with every release, would be parsing this not be a nightmare that has to be updated with each new release of gcc? On Mon, May 30, 2016 at 9:18 AM, Armin Rigo wrote:

[pypy-dev] Found on the internet

Another game boy emulator using RPython https://github.com/Baekalfen/PyBoy ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Looking into numpy ndarray.flags.writeable

the option is --withmod-micronumpy or --allworkingmodules but the tests are in the test directory and *that's* how you should run tests (not by playing with interactive) On Fri, May 20, 2016 at 7:44 PM, Eli Stevens (Gmail) wrote: > More questions! :) > > When I run > >

Re: [pypy-dev] Forwarding...

en if it wouldn't be a > success, you still get PR basically for free. > > I, unfortunately, don't have any insights or recommendation, it just > scratched my mind. > > Thanks for your awesome work, > Daniel > > čt 19. 5. 2016 v 18:12 odesílatel Maciej Fijalkowski &l

Re: [pypy-dev] Forwarding...

(private mail, gchat, IRC) if you have deeper insights Best regards, Maciej Fijalkowski On Thu, May 19, 2016 at 5:11 PM, Armin Rigo <ar...@tunes.org> wrote: > On 19 May 2016 at 14:58, <pypy-dev-ow...@python.org> wrote: >> -- Forwarded message -- >> From: Da

Re: [pypy-dev] Game state search dominated by copy.deepcopy

On Mon, May 16, 2016 at 6:53 PM, Eli Stevens (Gmail) <wickedg...@gmail.com> wrote: > On Mon, May 16, 2016 at 9:37 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> I don't think pypy is expected to speed up program where the majority >> of the time is spent i

Re: [pypy-dev] Game state search dominated by copy.deepcopy

I don't think pypy is expected to speed up program where the majority of the time is spent in copy.deepcopy. The answer to this question is a bit boring one: don't write algorithms that copy around so much data. As a general rule - if the vast majority of your work is done by the runtime there is

Re: [pypy-dev] PyPy & Django: recommended mySQL module?

On Sun, May 8, 2016 at 1:31 PM, Yury V. Zaytsev <y...@shurup.com> wrote: > On Sun, 8 May 2016, Maciej Fijalkowski wrote: > >> For the record - if you are using django ORM, then the mysql binding >> is unlikely to be your bottleneck for accessing the DB. > >

Re: [pypy-dev] PyPy & Django: recommended mySQL module?

On Sun, May 8, 2016 at 11:07 AM, Yury V. Zaytsev <y...@shurup.com> wrote: > Hi Maciej, > > Thanks for the feedback! > > On Sun, 8 May 2016, Maciej Fijalkowski wrote: >> >> >> I would personally use something cffi-based, like this: >> https://github.com

Re: [pypy-dev] PyPy & Django: recommended mySQL module?

Hi Yury Sorry for the late response, on holiday. I would personally use something cffi-based, like this: https://github.com/andrewsmedina/mysql-cffi Generally speaking all cpyext-based solutions will be slower (although these days I know MySQL-Python should indeed just work and not crash) than

Re: [pypy-dev] Error Messages

Hi Armin Any chance we can add this to cpython-differences? Couldn't find it last time (and misremembered) On Tue, Apr 26, 2016 at 11:38 PM, Armin Rigo wrote: > Hi, > > On 26 April 2016 at 19:02, Carl Friedrich Bolz wrote: >> Those are simple cases, of course we

Re: [pypy-dev] Error Messages

examples off hand) On Tue, Apr 26, 2016 at 6:38 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Apr 26, 2016 at 06:16:39PM +0200, Maciej Fijalkowski wrote: > >> Typically the exception type is the same, but there is a bunch of >> differences, especially around ValueE

Re: [pypy-dev] Error Messages

On Tue, Apr 26, 2016 at 5:30 PM, Steven D'Aprano wrote: > On Tue, Apr 26, 2016 at 10:16:29AM -0500, Ryan Gonzalez wrote: >> I personally think it's fine: >> >> 1. CPython has pretty decent error messages. Other than long stack traces >> with recursion errors, or maybe column

Re: [pypy-dev] PyPY 5.1 release is close, help needed

can we stress more the memory/warmup improvements? jit-leaner-frontend makes the warmup quite a bit faster, additionally we improved memory (both should be on the order of 20% compared to 5.0) On Wed, Apr 20, 2016 at 6:29 AM, Matti Picus wrote: > We are close to releasing

Re: [pypy-dev] Shift and typed array

code to run in CPython with > no dependencies. > > On Mon, Apr 4, 2016 at 3:45 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> so numpy64 will give you wrap-around arithmetics. What else are you >> looking for? :-) >> >> On Mon, Apr 4, 2016 at 3:38 PM, Tuom L

Re: [pypy-dev] Shift and typed array

but if you dont actually overflow, the cost is really low btw On Mon, Apr 4, 2016 at 3:49 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: > right, so there is no way to get wrap-around arithmetics in cpython > without modifications > > On Mon, Apr 4, 2016 at 3:48 PM, Tuo

Re: [pypy-dev] Shift and typed array

= int64(2**63 << 1) > a[0] = x > > Or: > > x = int64(2**63) > x[0] = x << 1 > > What the "real types" goes, is this the only option? > > Thanks in any case! > > > On Mon, Apr 4, 2016 at 3:32 PM, Maciej Fijalkowski <fij...@gmail.c

Re: [pypy-dev] Shift and typed array

one option would be to use integers from _numpypy module: from numpy import int64 after installing numpy. There are obscure ways to get it without installing numpy. Another avenue would be to use __pypy__.intop.int_mul etc. Feel free to complain "no, I want real types that I can work with" :-)

Re: [pypy-dev] [ANN] Python compilers workshop at SciPy this year

, > > How about a little more useful response of "we'll help you find the > right audience for this discussion and collaborate with you to make > the case."? > > - David > > On Thu, Mar 24, 2016 at 11:32 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: >>

Re: [pypy-dev] [ANN] Python compilers workshop at SciPy this year

> > Hopefully the workshop will be successful and help create some focus. > > John > > On Thu, Mar 24, 2016 at 8:56 AM, Maciej Fijalkowski <fij...@gmail.com> > wrote: >> >> Hi John >> >> Thanks for explaining the current situation of the eco

Re: [pypy-dev] [ANN] Python compilers workshop at SciPy this year

Hi John Thanks for explaining the current situation of the ecosystem. I'm not quite sure what your intention is. PyPy (and CPython) is very easy to embed through any C-level API, especially with the latest additions to cffi embedding. If someone feels like doing the work to share stuff that way

Re: [pypy-dev] [Jython-dev] [ANN] Python compilers workshop at SciPy this year (fwd)

We're probably sending myself and matti On Thu, Mar 24, 2016 at 12:05 AM, Laura Creighton wrote: > This from the Jython mailing list. Are we sending somebody? It's the > first I heard about it, at any rate. > > Laura > > --- Forwarded Message > > Return-Path:

Re: [pypy-dev] [ANN] Python compilers workshop at SciPy this year

Hi John I understand why you're bringing this up, but it's a huge project on it's own, worth at least a couple months worth of work. Without a dedicated effort from someone I'm worried it would not go anywhere. It's kind of separated from the other goals of the summit On Wed, Mar 23, 2016 at

Re: [pypy-dev] GSoC: Updates on ByteArray?

Hi Brian bytearray should be optimized for cases where you e.g. write() it to file or use read_into() in a way that does not make any copies. Same if you say convert it from ffi.buffer etc. That's probably what's missing from making it fast On Tue, Mar 22, 2016 at 8:56 PM, Brian Guo

Re: [pypy-dev] PyPy Ubuntu PPA + a cpyext question

PPA is usually updated, but as you said we can't demand deadlines PyByteArray_Check and PyByteArray_CheckExact are not implemented On Mon, Mar 21, 2016 at 3:43 AM, Tin Tvrtković wrote: > Hello, > > first question: is the PyPy Ubuntu PPA still a maintained thing? I'm not >

Re: [pypy-dev] setting attribute of JitHookInterface instance

It's general. You can do whatever you like before runtime (during import time for example) as long as the presented world to rpython is static enough - in other words Python is a meta-programming language for RPython On Wed, Mar 16, 2016 at 1:34 PM, Magnus Morton wrote: >

Re: [pypy-dev] Refcount garbage collector build error

Hi Florin The refcount garbage collector is only marginally supported (as far as our tests go), it's definitely neither tested nor really supported when translated, it was always very slow for example. (and as you noticed, there is no support for weakrefs for example) On Fri, Mar 18, 2016 at

Re: [pypy-dev] Interest in contributing to PYPY

Hi! Good to hear from you :-) Any chance you can pop in to IRC, so we can discuss the project? Alternatively you can catch me on gmail on this address Best regards, Maciej Fijalkowski On Wed, Mar 9, 2016 at 3:12 PM, Djimeli Konrad <djkonr...@gmail.com> wrote: > Hello, > > My

  1   2   3   4   5   6   7   8   >