From me at manueljacob.de Sun Dec 10 12:14:26 2017 From: me at manueljacob.de (Manuel Jacob) Date: Sun, 10 Dec 2017 18:14:26 +0100 Subject: [pypy-dev] Improving the documentation on how we test Message-ID: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> Hi, I'm currently implementing PEP 526 [1], which requires additions to the interpreter from the parser down to the bytecode interpreter. Since this is a common task, I want to expand the documentation a bit, adding a "how to extend the interpreter" recipe. One thing which I wasn't 100% sure about myself is how to test it. Clearly every addition has to come with a test, preferably written before implementing anything. But a few things are a bit unclear: For every change in CPython there is (hopefully) a test case in lib-python/*/test. So technically there's already a test case when modifying the interpreter. One reason to add app-level tests is to avoid re-translations. But other than this convenience, how much app-level testing to we *require*? Should we test everything up to the last detail or are we fine with testing the basic functionality and leaving the rest to the CPython test suite? A related question is which style of testing ? integration-test-style or unit-test-style ? we prefer. Different people ? also among the core developers ? have different preferences, so we have a bit of a mix. So in this concrete example, it is tempting to create a single test like AppTestFunctionAnnotations.test_simple from pypy/interpreter/test/test_syntax.py [2] and then add all the functionality to the interpreter until the test passes (this would be integration-style testing). From the unit-style testing perspective, this test is not very good, because it doesn't test only the syntax, like the file name "test_syntax.py" would suggest. The alternative would be to add a unit test for every affected part of the interpreter (parser, AST builder, AST validator, bytecode generation, symtable, stack effect computation, bytecode interpreter). What do you think? Feel free to braindump your general thoughts (also outside of the syntax addition case), so I can extend other relevant parts of the documentation as well. This will hopefully make it easier for new (but also more advanced) contributors and ensure a consistent test suite quality all over our code base. -Manuel [1] https://www.python.org/dev/peps/pep-0526/ [2] https://bitbucket.org/pypy/pypy/src/e30b20325b579b5a92cba08d326d2e385caba2d9/pypy/interpreter/test/test_syntax.py?fileviewer=file-view-default#test_syntax.py-685 From wickedgrey at gmail.com Sun Dec 10 13:37:51 2017 From: wickedgrey at gmail.com (Eli Stevens (Gmail)) Date: Sun, 10 Dec 2017 10:37:51 -0800 Subject: [pypy-dev] Improving the documentation on how we test In-Reply-To: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> References: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> Message-ID: It's not clear if you're looking for input from the peanut gallery, but here is my $0.02: First test at the level of the feature as exposed to a user. This makes sense to write before implementation starts, and is highly unlikely to change if the implementation gets refactored. It sounds like your integration test is what I mean, though I usually think of it as even higher "feature level" testing. I typically write unit tests interleaved with implementation, and only to verify aspects of the implementation that aren't trivial to desk-check. These will almost certainly get thrown away during a refactor, so I try to not over-invest in them. Finally, I try to limit integration tests to high-risk parts of the larger project (either due to uncertainty of the current implementation, or because it would be easy for later changes to inadvertently break things). Again, my goal isn't to verify that the implementation hasn't changed, but rather to help narrow down the source of breakages. If the feature isn't working, the feature-level tests should be breaking (if not, they need more detail), and then the rest of the testing just helps you find the root cause more quickly. HTH! Eli On Sun, Dec 10, 2017 at 9:14 AM, Manuel Jacob wrote: > Hi, > > I'm currently implementing PEP 526 [1], which requires additions to the > interpreter from the parser down to the bytecode interpreter. Since this is > a common task, I want to expand the documentation a bit, adding a "how to > extend the interpreter" recipe. > > One thing which I wasn't 100% sure about myself is how to test it. Clearly > every addition has to come with a test, preferably written before > implementing anything. But a few things are a bit unclear: > > For every change in CPython there is (hopefully) a test case in > lib-python/*/test. So technically there's already a test case when > modifying the interpreter. One reason to add app-level tests is to avoid > re-translations. But other than this convenience, how much app-level > testing to we *require*? Should we test everything up to the last detail or > are we fine with testing the basic functionality and leaving the rest to the > CPython test suite? > > A related question is which style of testing ? integration-test-style or > unit-test-style ? we prefer. Different people ? also among the core > developers ? have different preferences, so we have a bit of a mix. So in > this concrete example, it is tempting to create a single test like > AppTestFunctionAnnotations.test_simple from > pypy/interpreter/test/test_syntax.py [2] and then add all the functionality > to the interpreter until the test passes (this would be integration-style > testing). From the unit-style testing perspective, this test is not very > good, because it doesn't test only the syntax, like the file name > "test_syntax.py" would suggest. The alternative would be to add a unit test > for every affected part of the interpreter (parser, AST builder, AST > validator, bytecode generation, symtable, stack effect computation, bytecode > interpreter). > > What do you think? Feel free to braindump your general thoughts (also > outside of the syntax addition case), so I can extend other relevant parts > of the documentation as well. This will hopefully make it easier for new > (but also more advanced) contributors and ensure a consistent test suite > quality all over our code base. > > -Manuel > > [1] https://www.python.org/dev/peps/pep-0526/ > [2] > https://bitbucket.org/pypy/pypy/src/e30b20325b579b5a92cba08d326d2e385caba2d9/pypy/interpreter/test/test_syntax.py?fileviewer=file-view-default#test_syntax.py-685 > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From cfbolz at gmx.de Mon Dec 11 07:11:57 2017 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 11 Dec 2017 13:11:57 +0100 Subject: [pypy-dev] Improving the documentation on how we test In-Reply-To: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> References: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> Message-ID: <5bc1a1ce-df03-9d9a-8fe1-f9537b37cd2e@gmx.de> Hi Manuel, 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 work, the feature works. The coding guide states that already, but is maybe not forceful or not detailed enough: "adding features requires adding appropriate tests." I am open to suggestions how to make this more explicit. Now, about integration vs. unit-tests: we indeed have been somewhat flexible on this question. In my mind it comes down to how complicated the logic is. For rather simple logic, an integration test only is probably fine. For more intricate features it's probably better to also add careful unit tests. For your concrete case: There are intermediate approaches between just adding an integration test to test_simple and super careful unit tests. I am sure there are more user-visible effects of the PEP, e.g. shouldn't there also be ast module tests necessary? Cheers, Carl Friedrich On 10/12/17 18:14, Manuel Jacob wrote: > Hi, > > I'm currently implementing PEP 526 [1], which requires additions to the > interpreter from the parser down to the bytecode interpreter.? Since > this is a common task, I want to expand the documentation a bit, adding > a "how to extend the interpreter" recipe. > > One thing which I wasn't 100% sure about myself is how to test it.? > Clearly every addition has to come with a test, preferably written > before implementing anything.? But a few things are a bit unclear: > > For every change in CPython there is (hopefully) a test case in > lib-python/*/test.? So technically there's already a test case when > modifying the interpreter.? One reason to add app-level tests is to > avoid re-translations.? But other than this convenience, how much > app-level testing to we *require*?? Should we test everything up to the > last detail or are we fine with testing the basic functionality and > leaving the rest to the CPython test suite? > > A related question is which style of testing ? integration-test-style or > unit-test-style ? we prefer.? Different people ? also among the core > developers ? have different preferences, so we have a bit of a mix.? So > in this concrete example, it is tempting to create a single test like > AppTestFunctionAnnotations.test_simple from > pypy/interpreter/test/test_syntax.py [2] and then add all the > functionality to the interpreter until the test passes (this would be > integration-style testing).? From the unit-style testing perspective, > this test is not very good, because it doesn't test only the syntax, > like the file name "test_syntax.py" would suggest.? The alternative > would be to add a unit test for every affected part of the interpreter > (parser, AST builder, AST validator, bytecode generation, symtable, > stack effect computation, bytecode interpreter). > > What do you think?? Feel free to braindump your general thoughts (also > outside of the syntax addition case), so I can extend other relevant > parts of the documentation as well.? This will hopefully make it easier > for new (but also more advanced) contributors and ensure a consistent > test suite quality all over our code base. > > -Manuel > > [1] https://www.python.org/dev/peps/pep-0526/ > [2] > https://bitbucket.org/pypy/pypy/src/e30b20325b579b5a92cba08d326d2e385caba2d9/pypy/interpreter/test/test_syntax.py?fileviewer=file-view-default#test_syntax.py-685 > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From anto.cuni at gmail.com Mon Dec 11 08:08:41 2017 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 11 Dec 2017 14:08:41 +0100 Subject: [pypy-dev] Improving the documentation on how we test In-Reply-To: <5bc1a1ce-df03-9d9a-8fe1-f9537b37cd2e@gmx.de> References: <047eea899d3b796b8a8989da57c5d846@manueljacob.de> <5bc1a1ce-df03-9d9a-8fe1-f9537b37cd2e@gmx.de> Message-ID: 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 work, the feature works. > > The coding guide states that already, but is maybe not forceful or not > detailed enough: > > "adding features requires adding appropriate tests." > > I am open to suggestions how to make this more explicit. > About app-tests vs CPython test, I'd state the following: - app-tests are what we use to check that the code we write behaves as we intend (hence, you **need** an app test for every piece of code you write) - cpython tests are what we use to check that our implementation is compatible with cpython -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristipp at gmail.com Fri Dec 15 01:47:22 2017 From: cristipp at gmail.com (cristipp) Date: Thu, 14 Dec 2017 23:47:22 -0700 (MST) Subject: [pypy-dev] Delimited Continuations in PyPy? In-Reply-To: References: Message-ID: <1513320442096-0.post@n5.nabble.com> One may choose to invoke a continuation multiple times. Therefore, wouldn't continuations require forkable stacklets? Which appear to be unimplelemented: > /* stacklet_handle _stacklet_switch_to_copy(stacklet_handle) --- later */ https://bitbucket.org/pypy/pypy/annotate/5ef9bb870cd2af8df10d9394ca7b8cd4bed3fd15/rpython/translator/c/src/stacklet/stacklet.h?at=default&fileviewer=file-view-default#stacklet.h-55 -- Sent from: http://pypy.1116445.n5.nabble.com/ From armin.rigo at gmail.com Fri Dec 15 10:12:07 2017 From: armin.rigo at gmail.com (Armin Rigo) Date: Fri, 15 Dec 2017 16:12:07 +0100 Subject: [pypy-dev] Delimited Continuations in PyPy? In-Reply-To: <1513320442096-0.post@n5.nabble.com> References: <1513320442096-0.post@n5.nabble.com> Message-ID: Hi, On 15 December 2017 at 07:47, cristipp wrote: > One may choose to invoke a continuation multiple times. Therefore, wouldn't > continuations require forkable stacklets? Answered on https://bitbucket.org/pypy/pypy/issues/2710/call-cc-delimited-continuations-reentrant. Armin From edd at theunixzoo.co.uk Fri Dec 15 12:52:26 2017 From: edd at theunixzoo.co.uk (Edd Barrett) Date: Fri, 15 Dec 2017 17:52:26 +0000 Subject: [pypy-dev] [MoreVMs'18] Call for Papers Message-ID: <20171215175226.GH37272@wilfred.home> Hi Everyone, This may be of interest to some of the members on this list. Please consider contributing. ============================================================================ Call for Papers: MoreVMs'18 2nd Workshop on Modern Language Runtimes, and Ecosystems Co-located with '18 April 9th, 2018, Nice, France https://2018.programming-conference.org/track/MoreVMs-2018 ============================================================================ The MoreVMs'18 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design and compilation strategies. The workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions, from either an academic or industrial perspective. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- Submissions should use the ACM Conference acmart Format with the ?sigconf? option with a font size of 10 point and the font family Times New Roman. All submissions should be in PDF format. If you use LaTeX or Word, please use the provided ACM acmart templates. Otherwise, please follow the ACM author instructions. https://www.acm.org/publications/proceedings-template If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission for review using the LaTeX command \settopmatter{printfolios=true} (see examples in template). Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission details will be on: https://2018.programming-conference.org/track/MoreVMs-2018 Important Dates --------------- Extended abstract submission: 2018-01-26 Author notification: 2018-02-23 Workshop: 2018-04-09 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- Cl?ment Bera, Inria Lille Nord Europe, France Maxime Chevalier-Boisvert, University of Montreal, Canada S?bastien Doeraene, EPFL, Switzerland Johan Fabry, Raincode Labs, Belgium Juliana Franco, Imperial College London, United Kingdom Tobias Grosser, ETH Zurich, Switzerland Ben L. Titzer, Google, Germany Niko Matsakis, Mozilla Research, United States Armin Rigo, PyPy, Switzerland Maoni Stephens, Microsoft, United States Ga?l Thomas, Telecom SudParis, France Mario Wolczko, Oracle Labs, United States Workshop Organizers ------------------- Edd Barrett, King's College London, United Kingdom Adam Welc, Uber Technologies, United States Stefan Marr, University of Kent, United Kingdom -- Best Regards Edd Barrett http://www.theunixzoo.co.uk From hubo at jiedaibao.com Mon Dec 18 02:58:40 2017 From: hubo at jiedaibao.com (hubo) Date: Mon, 18 Dec 2017 15:58:40 +0800 Subject: [pypy-dev] Mysterious IndexError in service running with PyPy Message-ID: <5A37752E.1020104@jiedaibao.com>+888E1862B801ADEF I'm reporting this issue in this mail group, though I don't know if it is related with PyPy, because it is really strange, and is not able to reproduce stably. But I hope someone may know the reason or have some points. I'm running some SDN services written in Python with PyPy 5.3.0. The related code is here: https://github.com/hubo1016/vlcp/blob/8022e3a3c67cf4305af503d507640a730ca3949d/vlcp/utils/indexedheap.py#L100 The full code is also in the repo, but may be too complex to describe. But this related piece is quite simple: def _siftdown(self, pos): temp = self.heap[pos] l = len(self.heap) while pos * 2 + 1 < l: cindex = pos * 2 + 1 pt = self.heap[cindex] if cindex + 1 < l and self.heap[cindex+1][0] < pt[0]: cindex = cindex + 1 pt = self.heap[cindex] if pt[0] < temp[0]: self.heap[pos] = pt self.index[pt[1]] = pos else: break pos = cindex self.heap[pos] = temp self.index[temp[1]] = pos It is a simple heap operation. The service uses a heap to process timers. When the service is not busy, it usually runs this piece of code several times per minute. I have 32 servers running this service. They are quite stable in about three months, but one day one of the services crashes on line 100 reporting IndexError: pt = self.heap[cindex] As you can see, cindex = pos * 2 + 1, which is tested by the while pre-conditon just two lines before. And there is not any multi-threading issues here because this piece of code always runs in the same thread. So it is not possible in theory for this to happen. Only the following facts are known about this issue: It reproduces - through quite rarely. I've met this kind of crashes 4 times, each with different machine, so it should not be related to hardware issuess. Since I've got 32 servers, it might take more than one year to reproduce with a single server. It seems not to be related to pressures. All of the crashes happens at night, when there are little requests. Only some cleanup tasks are running in fixed interval. The services are running with PyPy 5.3.0. I've upgraded a few of them to 5.9, but it will take a long time to validate whether this still happens. And It is not validated on CPython too. I'm also trying to collect more debugging information for this issue, but it is very hard since it rarely reproduces. It is not a serious issue. It could be workarounded with a auto-restart, but I'm searching the cause. 2017-12-18 hubo -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Mon Dec 18 04:44:21 2017 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 18 Dec 2017 10:44:21 +0100 Subject: [pypy-dev] Mysterious IndexError in service running with PyPy In-Reply-To: <5a377557.1a9b500a.9dd71.d542SMTPIN_ADDED_BROKEN@mx.google.com> References: <5a377557.1a9b500a.9dd71.d542SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Hi Hubo, On 18 December 2017 at 08:58, hubo wrote: > The services are running with PyPy 5.3.0. I've upgraded a few of them to > 5.9, but it will take a long time to validate whether this still happens. The root cause might be some issue with the JIT: if there is a bug there, then we can get this kind of nonsense-looking result. It is however completely impossible to know what the issue is just by looking at the Python code. Usually it takes a lot of efforts inside gdb to figure these bugs out. The good news is that these issues are extremely rare: much less than one per release, in average. It's possible that we fixed a JIT issue between PyPy 5.3 and PyPy 5.9 and that this issue caused the misbehavior you're observing. All I can suggest is to continue trying with PyPy 5.9. A bient?t, Armin. From hubo at jiedaibao.com Tue Dec 19 05:16:28 2017 From: hubo at jiedaibao.com (hubo) Date: Tue, 19 Dec 2017 18:16:28 +0800 Subject: [pypy-dev] Mysterious IndexError in service running with PyPy In-Reply-To: References: <5a377557.1a9b500a.9dd71.d542SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <5A38E6F9.7060205@jiedaibao.com>+23C732C844AF8846 Thanks, I will try 5.9 and wait for the result 2017-12-19 hubo ????Armin Rigo ?????2017-12-18 17:44 ???Re: [pypy-dev] Mysterious IndexError in service running with PyPy ????"hubo" ???"PyPy Developer Mailing List" Hi Hubo, On 18 December 2017 at 08:58, hubo wrote: > The services are running with PyPy 5.3.0. I've upgraded a few of them to > 5.9, but it will take a long time to validate whether this still happens. The root cause might be some issue with the JIT: if there is a bug there, then we can get this kind of nonsense-looking result. It is however completely impossible to know what the issue is just by looking at the Python code. Usually it takes a lot of efforts inside gdb to figure these bugs out. The good news is that these issues are extremely rare: much less than one per release, in average. It's possible that we fixed a JIT issue between PyPy 5.3 and PyPy 5.9 and that this issue caused the misbehavior you're observing. All I can suggest is to continue trying with PyPy 5.9. A bient?t, Armin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.leslie.ttg at gmail.com Tue Dec 19 07:14:17 2017 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Tue, 19 Dec 2017 23:14:17 +1100 Subject: [pypy-dev] Mysterious IndexError in service running with PyPy In-Reply-To: <5a37757a.4a98500a.ba397.d553SMTPIN_ADDED_BROKEN@mx.google.com> References: <5a37757a.4a98500a.ba397.d553SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Where is the code that changes the size of self.heap? How do we know that size(self.heap) is constant? My guess is that some thread changes this; but l is not recomputed. On 18 Dec 2017 6:59 PM, "hubo" wrote: > I'm reporting this issue in this mail group, though I don't know if it is > related with PyPy, because it is really strange, and is not able to > reproduce stably. But I hope someone may know the reason or have some > points. > > I'm running some SDN services written in Python with PyPy 5.3.0. The > related code is here: > > https://github.com/hubo1016/vlcp/blob/8022e3a3c67cf4305af503d507640a730ca3949d/vlcp/utils/indexedheap.py#L100 > > The full code is also in the repo, but may be too complex to describe. But > this related piece is quite simple: > > def _siftdown(self, pos): > temp = self.heap[pos] > l = len(self.heap) > while pos * 2 + 1 < l: > cindex = pos * 2 + 1 > pt = self.heap[cindex] > if cindex + 1 < l and self.heap[cindex+1][0] < pt[0]: > cindex = cindex + 1 > pt = self.heap[cindex] > if pt[0] < temp[0]: > self.heap[pos] = pt > self.index[pt[1]] = pos > else: > break > pos = cindex > self.heap[pos] = temp > self.index[temp[1]] = pos > It is a simple heap operation. The service uses a heap to process timers. > When the service is not busy, it usually runs this piece of code several > times per minute. > > I have 32 servers running this service. They are quite stable in about > three months, but one day one of the services crashes on line 100 reporting > IndexError: > pt = self.heap[cindex] > > As you can see, cindex = pos * 2 + 1, which is tested by the while > pre-conditon just two lines before. And there is not any multi-threading > issues here because this piece of code always runs in the same thread. So > it is not possible in theory for this to happen. > > Only the following facts are known about this issue: > > 1. It reproduces - through quite rarely. I've met this kind of > crashes 4 times, each with different machine, so it should not be related > to hardware issuess. Since I've got 32 servers, it might take more than one > year to reproduce with a single server. > 2. It seems not to be related to pressures. All of the crashes happens > at night, when there are little requests. Only some cleanup tasks are > running in fixed interval. > > The services are running with PyPy 5.3.0. I've upgraded a few of them to > 5.9, but it will take a long time to validate whether this still happens. > And It is not validated on CPython too. I'm also trying to collect more > debugging information for this issue, but it is very hard since it rarely > reproduces. > > It is not a serious issue. It could be workarounded with a auto-restart, > but I'm searching the cause. > > > 2017-12-18 > ------------------------------ > hubo > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hubo at jiedaibao.com Thu Dec 21 20:55:59 2017 From: hubo at jiedaibao.com (hubo) Date: Fri, 22 Dec 2017 09:55:59 +0800 Subject: [pypy-dev] Mysterious IndexError in service running with PyPy In-Reply-To: References: <5a37757a.4a98500a.ba397.d553SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <5A3C662E.9070506@jiedaibao.com>+28463B6D7D92ED54 It is a regular guess, but this method is guareenteed to be called only in the main thread. Thread pool usage is very limited in this program because it is coroutine-based. 2017-12-22 hubo ????William ML Leslie ?????2017-12-19 20:14 ???Re: [pypy-dev] Mysterious IndexError in service running with PyPy ????"hubo" ???"PyPy Developer Mailing List" Where is the code that changes the size of self.heap? How do we know that size(self.heap) is constant? My guess is that some thread changes this; but l is not recomputed. On 18 Dec 2017 6:59 PM, "hubo" wrote: I'm reporting this issue in this mail group, though I don't know if it is related with PyPy, because it is really strange, and is not able to reproduce stably. But I hope someone may know the reason or have some points. I'm running some SDN services written in Python with PyPy 5.3.0. The related code is here: https://github.com/hubo1016/vlcp/blob/8022e3a3c67cf4305af503d507640a730ca3949d/vlcp/utils/indexedheap.py#L100 The full code is also in the repo, but may be too complex to describe. But this related piece is quite simple: def _siftdown(self, pos): temp = self.heap[pos] l = len(self.heap) while pos * 2 + 1 < l: cindex = pos * 2 + 1 pt = self.heap[cindex] if cindex + 1 < l and self.heap[cindex+1][0] < pt[0]: cindex = cindex + 1 pt = self.heap[cindex] if pt[0] < temp[0]: self.heap[pos] = pt self.index[pt[1]] = pos else: break pos = cindex self.heap[pos] = temp self.index[temp[1]] = pos It is a simple heap operation. The service uses a heap to process timers. When the service is not busy, it usually runs this piece of code several times per minute. I have 32 servers running this service. They are quite stable in about three months, but one day one of the services crashes on line 100 reporting IndexError: pt = self.heap[cindex] As you can see, cindex = pos * 2 + 1, which is tested by the while pre-conditon just two lines before. And there is not any multi-threading issues here because this piece of code always runs in the same thread. So it is not possible in theory for this to happen. Only the following facts are known about this issue: It reproduces - through quite rarely. I've met this kind of crashes 4 times, each with different machine, so it should not be related to hardware issuess. Since I've got 32 servers, it might take more than one year to reproduce with a single server. It seems not to be related to pressures. All of the crashes happens at night, when there are little requests. Only some cleanup tasks are running in fixed interval. The services are running with PyPy 5.3.0. I've upgraded a few of them to 5.9, but it will take a long time to validate whether this still happens. And It is not validated on CPython too. I'm also trying to collect more debugging information for this issue, but it is very hard since it rarely reproduces. It is not a serious issue. It could be workarounded with a auto-restart, but I'm searching the cause. 2017-12-18 hubo _______________________________________________ pypy-dev mailing list pypy-dev at python.org https://mail.python.org/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From dynamicgl at gmail.com Sat Dec 23 01:22:55 2017 From: dynamicgl at gmail.com (Gelin Yan) Date: Sat, 23 Dec 2017 14:22:55 +0800 Subject: [pypy-dev] a question about translating pypy for raspberry pi In-Reply-To: References: Message-ID: Hi Antonio Sorry for coming late. The problem has been resolved. I used a wrong toolchain to build the pypy. I should use raspbian compiler toolchain and the arch ought to be armhf instead of armel. I am not familiar with cross-platform compilation (It was my first time) so I took several days to figure out how to. Regards gelin yan -------------- next part -------------- An HTML attachment was scrubbed... URL: From danelee2601 at naver.com Fri Dec 22 23:02:45 2017 From: danelee2601 at naver.com (=?utf-8?B?7J2064yA7IiY?=) Date: Sat, 23 Dec 2017 13:02:45 +0900 Subject: [pypy-dev] =?utf-8?q?numpy_Installation_in_pypy_on_window_7_with?= =?utf-8?q?_python_ver=2E_3=2E6?= Message-ID: Hi, I've been trying to install "numpy" in pypy using pip install numpy. I'm using window7(64bit) and the python ver. 3.6. And I downloaded "Windows binary (32bit) (you might need the VS 2008 runtime library installer vcredist_x86.exe.)" - The above version is for python 2.7 and window 32 bit. Despite the facts, I just downloaded it and installed pip for pypy. though it worked, the error kept showing up when I tried to install numpy, using "pip install numpy". ------------------------------------------------------------------------------- Here's the question. 1. Would it work if I install "Windows binary (32bit) (you might need the VS 2008 runtime library installer vcredist_x86.exe.)" this version on window7(64bit) with python ver. 2.7 ? 2. Or do I have to use "window(64bit) & python ver.2.7"? (I'm asking since I saw somebody say "This version now works on window 64bit too!"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Sat Dec 23 10:31:06 2017 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 23 Dec 2017 17:31:06 +0200 Subject: [pypy-dev] numpy Installation in pypy on window 7 with python ver. 3.6 In-Reply-To: References: Message-ID: On 23/12/2017 6:02 AM, ??? wrote: > Hi, I've been trying to install "numpy" in pypy using pip install numpy. > > I'm using window7(64bit) and the python ver. 3.6. > > And I downloaded "Windows binary (32bit) > (you > might need the VS 2008 runtime library installer vcredist_x86.exe > .)" > > - The above version is for python 2.7 and window 32 bit. > > Despite the facts, I just downloaded it and installed pip for pypy. > > though it worked, the error kept showing up when I tried to install > numpy, using "pip install numpy". > > ------------------------------------------------------------------------------- > > Here's the question. > > 1. Would it work if I install "Windows binary (32bit) > (you > might need the VS 2008 runtime library installer vcredist_x86.exe > .)" this > version on window7(64bit) with python ver. 2.7 ? > > 2. Or do I have to use "window(64bit) & python ver.2.7"? (I'm asking > since I saw somebody say "This version now works on window 64bit too!"). > You did not actually state what "the error" is. One of the most common problems on Windows is that it does not come with a compiler, you must install one. This link provides a MSVC compiler compatible with python 2.7 (PyPy and CPython) https://www.microsoft.com/en-us/download/details.aspx?id=44266 Are you sure you are using the pip from PyPy? Once you unzip the file you downloaded, you should open a DOS terminal, and execute path\to\pypy-xxx/bin/pypy -m ensurepip path\to\pypy-xxx/bin/pip install cython numpy Matti From matti.picus at gmail.com Sat Dec 23 23:44:09 2017 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 24 Dec 2017 06:44:09 +0200 Subject: [pypy-dev] pypy 5.10 release Message-ID: <34a7b2a0-1b48-759f-6a5a-51abe4ee8abd@gmail.com> I have uploaded the pypy 5.10 release tarballs for both pypy2.7 and pypy3.5 to https://bitbucket.org/pypy/pypy/downloads, sha256 hashes are available from https://bitbucket.org/pypy/pypy.org/src/41427b24c7395f4a5a6636ef0d072c83982d8945/source/download.txt?at=extradoc&fileviewer=file-view-default Please download and test before we release to make sure the tarballs are valid Matti From fijall at gmail.com Mon Dec 25 13:26:05 2017 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 25 Dec 2017 18:26:05 +0000 Subject: [pypy-dev] pypy 5.10 release In-Reply-To: <34a7b2a0-1b48-759f-6a5a-51abe4ee8abd@gmail.com> References: <34a7b2a0-1b48-759f-6a5a-51abe4ee8abd@gmail.com> Message-ID: 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 and post on the blog once I'm done building Cheers, fijal On Sun, Dec 24, 2017 at 4:44 AM, Matti Picus wrote: > I have uploaded the pypy 5.10 release tarballs for both pypy2.7 and pypy3.5 > to https://bitbucket.org/pypy/pypy/downloads, sha256 hashes are available > from > https://bitbucket.org/pypy/pypy.org/src/41427b24c7395f4a5a6636ef0d072c83982d8945/source/download.txt?at=extradoc&fileviewer=file-view-default > > Please download and test before we release to make sure the tarballs are > valid > Matti > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev From fijall at gmail.com Mon Dec 25 13:54:26 2017 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 25 Dec 2017 18:54:26 +0000 Subject: [pypy-dev] Dual release v5.10.0 of PyPy2 and PyPy3 is out Message-ID: 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 few new features, the main feature being the final PyPy3.5 release that works on linux and OS X with beta windows support. It also includes fixes for `vmprof`_ cooperation with greenlets. Compared to 5.9, the 5.10 release contains mostly bugfixes and small improvements. We have in the pipeline big new features coming for PyPy 6.0 that did not make the release cut and should be available within the next couple months. As always, this release is 100% compatible with the previous one and fixed several issues and bugs raised by the growing community of PyPy users. As always, we strongly recommend updating. There are quite a few important changes that are in the pipeline that did not make it into the 5.10 release. Most important are speed improvements to cpyext (which will make numpy and pandas a bit faster) and utf8 branch that changes internal representation of unicode to utf8, which should help especially the Python 3.5 version of PyPy. This release concludes the Mozilla Open Source `grant`_ for having a compatible PyPy 3.5 release and we're very grateful for that. Of course, we will continue to improve PyPy 3.5 and probably move to 3.6 during the course of 2018. You can download the v5.10 releases here: http://pypy.org/download.html We would like to thank our donors for the continued support of the PyPy project. We would also like to thank our contributors and encourage new people to join the project. PyPy has many layers and we need help with all of them: `PyPy`_ and `RPython`_ documentation improvements, tweaking popular `modules`_ to run on pypy, or general `help`_ with making RPython's JIT even better. .. _vmprof: http://vmprof.readthedocs.io .. _grant: https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html .. _`PyPy`: index.html .. _`RPython`: https://rpython.readthedocs.org .. _`modules`: project-ideas.html#make-more-python-modules-pypy-friendly .. _`help`: project-ideas.html What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7 and CPython 3.5. It's fast (`PyPy and CPython 2.7.x`_ performance comparison) due to its integrated tracing JIT compiler. We also welcome developers of other `dynamic languages`_ to see what RPython can do for them. The PyPy release supports: * **x86** machines on most common operating systems (Linux 32/64 bits, Mac OS X 64 bits, Windows 32 bits, OpenBSD, FreeBSD) * newer **ARM** hardware (ARMv6 or ARMv7, with VFPv3) running Linux * big- and little-endian variants of **PPC64** running Linux, * **s390x** running Linux .. _`PyPy and CPython 2.7.x`: http://speed.pypy.org .. _`dynamic languages`: http://rpython.readthedocs.io/en/latest/examples.html Changelog ========= * improve ssl handling on windows for pypy3 (makes pip work) * improve unicode handling in various error reporters * fix vmprof cooperation with greenlets * fix some things in cpyext * test and document the cmp(nan, nan) == 0 behaviour * don't crash when calling sleep with inf or nan * fix bugs in _io module * inspect.isbuiltin() now returns True for functions implemented in C * allow the sequences future-import, docstring, future-import for CPython bug compatibility * Issue #2699: non-ascii messages in warnings * posix.lockf * fixes for FreeBSD platform * add .debug files, so builds contain debugging info, instead of being stripped * improvements to cppyy * issue #2677 copy pure c PyBuffer_{From,To}Contiguous from cpython * issue #2682, split firstword on any whitespace in sqlite3 * ctypes: allow ptr[0] = foo when ptr is a pointer to struct * matplotlib will work with tkagg backend once `matplotlib pr #9356`_ is merged * improvements to utf32 surrogate handling * cffi version bump to 1.11.2 .. _`matplotlib pr #9356`: https://github.com/matplotlib/matplotlib/pull/9356 From kotrfa at gmail.com Wed Dec 27 16:35:53 2017 From: kotrfa at gmail.com (Kotrfa) Date: Wed, 27 Dec 2017 21:35:53 +0000 Subject: [pypy-dev] Pypy's facelift and certificate issues Message-ID: Hi, thank you for all your hard work, I really appreciate it. Firstly, it seems that the website SSL certificate expired or something. At my latest Chromium reports "Not secure". Secondly, I totally understand that there are more pressing issues than cool website, but the current design and functionality is IMO really putting people off. So I am going to through away some things which seems weird to ME (and I understand it's subjective - please take it as a friendly feedback). The jQuery versions suggests November 2012, the design idea seems even older... There are old information such as "*We are soon releasing a beta supporting Python 3.3." *or the fact that the donations bars are still present even though they are closed (and hence could be moved into some blog post). Blog is also terrible, this is how it renders on my laptop (the same with the external display): https://imgur.com/a/qkjEa . The logo could be surely polished as well (I like the idea, but it seems a bit childish). Even though I am not professional front end developer, I am quite confident this feedback is not far from what a professional would say. It's also not about having "cool" website for itself, but that a nice projects attracts good people. I myself am questioning how good, from technical point of view, Pypy's project can be if the site looks like like it does and the most convenient way how to reach the devs is through mailing list... Best, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Dec 27 16:56:09 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 27 Dec 2017 16:56:09 -0500 Subject: [pypy-dev] Pypy's facelift and certificate issues In-Reply-To: References: Message-ID: I've ping'd the infra team about the cert. Alex On Wed, Dec 27, 2017 at 4:35 PM, Kotrfa wrote: > Hi, > > thank you for all your hard work, I really appreciate it. > > Firstly, it seems that the website SSL certificate expired or something. > At my latest Chromium reports "Not secure". > > Secondly, I totally understand that there are more pressing issues than > cool website, but the current design and functionality is IMO really > putting people off. So I am going to through away some things which seems > weird to ME (and I understand it's subjective - please take it as a > friendly feedback). > > The jQuery versions suggests November 2012, the design idea seems even > older... There are old information such as "*We are soon releasing a beta > supporting Python 3.3." *or the fact that the donations bars are still > present even though they are closed (and hence could be moved into some > blog post). Blog is also terrible, this is how it renders on my laptop (the > same with the external display): https://imgur.com/a/qkjEa . The logo > could be surely polished as well (I like the idea, but it seems a bit > childish). Even though I am not professional front end developer, I am > quite confident this feedback is not far from what a professional would > say. It's also not about having "cool" website for itself, but that a nice > projects attracts good people. I myself am questioning how good, from > technical point of view, Pypy's project can be if the site looks like like > it does and the most convenient way how to reach the devs is through > mailing list... > > Best, > Daniel > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjansen at ownmail.net Thu Dec 28 02:42:58 2017 From: gjansen at ownmail.net (Gerald Jansen) Date: Thu, 28 Dec 2017 08:42:58 +0100 Subject: [pypy-dev] speed.pypy.org Message-ID: <1514446978.534125.1217638424.5D9BA531@webmail.messagingengine.com> On the main page, all the links to http://speed.pypy.org/ give 502 Bad Gateway nginx/1.1.19 Not pretty. From monasheth0910 at gmail.com Fri Dec 29 20:16:00 2017 From: monasheth0910 at gmail.com (Mona Shetg) Date: Sat, 30 Dec 2017 06:46:00 +0530 Subject: [pypy-dev] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Kotak.pdf Type: application/pdf Size: 657993 bytes Desc: not available URL: From fijall at gmail.com Sat Dec 30 04:01:41 2017 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 30 Dec 2017 09:01:41 +0000 Subject: [pypy-dev] Pypy's facelift and certificate issues In-Reply-To: References: Message-ID: 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, Dec 27, 2017 at 9:35 PM, Kotrfa wrote: > Hi, > > thank you for all your hard work, I really appreciate it. > > Firstly, it seems that the website SSL certificate expired or something. At > my latest Chromium reports "Not secure". > > Secondly, I totally understand that there are more pressing issues than cool > website, but the current design and functionality is IMO really putting > people off. So I am going to through away some things which seems weird to > ME (and I understand it's subjective - please take it as a friendly > feedback). > > The jQuery versions suggests November 2012, the design idea seems even > older... There are old information such as "We are soon releasing a beta > supporting Python 3.3." or the fact that the donations bars are still > present even though they are closed (and hence could be moved into some blog > post). Blog is also terrible, this is how it renders on my laptop (the same > with the external display): https://imgur.com/a/qkjEa . The logo could be > surely polished as well (I like the idea, but it seems a bit childish). Even > though I am not professional front end developer, I am quite confident this > feedback is not far from what a professional would say. It's also not about > having "cool" website for itself, but that a nice projects attracts good > people. I myself am questioning how good, from technical point of view, > Pypy's project can be if the site looks like like it does and the most > convenient way how to reach the devs is through mailing list... > > Best, > Daniel > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > From kotrfa at gmail.com Sat Dec 30 04:41:43 2017 From: kotrfa at gmail.com (Kotrfa) Date: Sat, 30 Dec 2017 09:41:43 +0000 Subject: [pypy-dev] Pypy's facelift and certificate issues In-Reply-To: References: Message-ID: Hey, as I said, I am not a professional, but I would be willing to help with the site. I have built couple of websites in Django/Wagtail (or plain HTML), have some basic knowledge about design (+ frontend CSS/JS/HTML). The site seems quite simple, so if we just did a revamp, it shouldn't take a long. Also, if we went with Wagtail, adding blog capabilities would be also trivial. Best, Daniel so 30. 12. 2017 v 10:02 odes?latel Maciej Fijalkowski napsal: > 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, Dec 27, 2017 at 9:35 PM, Kotrfa wrote: > > Hi, > > > > thank you for all your hard work, I really appreciate it. > > > > Firstly, it seems that the website SSL certificate expired or something. > At > > my latest Chromium reports "Not secure". > > > > Secondly, I totally understand that there are more pressing issues than > cool > > website, but the current design and functionality is IMO really putting > > people off. So I am going to through away some things which seems weird > to > > ME (and I understand it's subjective - please take it as a friendly > > feedback). > > > > The jQuery versions suggests November 2012, the design idea seems even > > older... There are old information such as "We are soon releasing a beta > > supporting Python 3.3." or the fact that the donations bars are still > > present even though they are closed (and hence could be moved into some > blog > > post). Blog is also terrible, this is how it renders on my laptop (the > same > > with the external display): https://imgur.com/a/qkjEa . The logo could > be > > surely polished as well (I like the idea, but it seems a bit childish). > Even > > though I am not professional front end developer, I am quite confident > this > > feedback is not far from what a professional would say. It's also not > about > > having "cool" website for itself, but that a nice projects attracts good > > people. I myself am questioning how good, from technical point of view, > > Pypy's project can be if the site looks like like it does and the most > > convenient way how to reach the devs is through mailing list... > > > > Best, > > Daniel > > > > _______________________________________________ > > pypy-dev mailing list > > pypy-dev at python.org > > https://mail.python.org/mailman/listinfo/pypy-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Sat Dec 30 05:49:15 2017 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 30 Dec 2017 10:49:15 +0000 Subject: [pypy-dev] Pypy's facelift and certificate issues In-Reply-To: References: Message-ID: 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 wrote: > Hey, > > as I said, I am not a professional, but I would be willing to help with the > site. I have built couple of websites in Django/Wagtail (or plain HTML), > have some basic knowledge about design (+ frontend CSS/JS/HTML). The site > seems quite simple, so if we just did a revamp, it shouldn't take a long. > Also, if we went with Wagtail, adding blog capabilities would be also > trivial. > > Best, > Daniel > > so 30. 12. 2017 v 10:02 odes?latel Maciej Fijalkowski > napsal: >> >> 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, Dec 27, 2017 at 9:35 PM, Kotrfa wrote: >> > Hi, >> > >> > thank you for all your hard work, I really appreciate it. >> > >> > Firstly, it seems that the website SSL certificate expired or something. >> > At >> > my latest Chromium reports "Not secure". >> > >> > Secondly, I totally understand that there are more pressing issues than >> > cool >> > website, but the current design and functionality is IMO really putting >> > people off. So I am going to through away some things which seems weird >> > to >> > ME (and I understand it's subjective - please take it as a friendly >> > feedback). >> > >> > The jQuery versions suggests November 2012, the design idea seems even >> > older... There are old information such as "We are soon releasing a beta >> > supporting Python 3.3." or the fact that the donations bars are still >> > present even though they are closed (and hence could be moved into some >> > blog >> > post). Blog is also terrible, this is how it renders on my laptop (the >> > same >> > with the external display): https://imgur.com/a/qkjEa . The logo could >> > be >> > surely polished as well (I like the idea, but it seems a bit childish). >> > Even >> > though I am not professional front end developer, I am quite confident >> > this >> > feedback is not far from what a professional would say. It's also not >> > about >> > having "cool" website for itself, but that a nice projects attracts good >> > people. I myself am questioning how good, from technical point of view, >> > Pypy's project can be if the site looks like like it does and the most >> > convenient way how to reach the devs is through mailing list... >> > >> > Best, >> > Daniel >> > >> > _______________________________________________ >> > pypy-dev mailing list >> > pypy-dev at python.org >> > https://mail.python.org/mailman/listinfo/pypy-dev >> > From kotrfa at gmail.com Sat Dec 30 09:42:42 2017 From: kotrfa at gmail.com (Kotrfa) Date: Sat, 30 Dec 2017 14:42:42 +0000 Subject: [pypy-dev] Pypy's facelift and certificate issues In-Reply-To: References: Message-ID: Hi, I am based in Prague (UTC+2), but during January, I am travelling and hence I am not very available. It should get better during February, so could we schedule a Hangout/Skype call or something then? Also, depending on the volume of the work on the site, I may not be able to work on it before July. But have no problem if someone else want start on it themselves 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 napsal: > 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 wrote: > > Hey, > > > > as I said, I am not a professional, but I would be willing to help with > the > > site. I have built couple of websites in Django/Wagtail (or plain HTML), > > have some basic knowledge about design (+ frontend CSS/JS/HTML). The site > > seems quite simple, so if we just did a revamp, it shouldn't take a long. > > Also, if we went with Wagtail, adding blog capabilities would be also > > trivial. > > > > Best, > > Daniel > > > > so 30. 12. 2017 v 10:02 odes?latel Maciej Fijalkowski > > napsal: > >> > >> 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, Dec 27, 2017 at 9:35 PM, Kotrfa wrote: > >> > Hi, > >> > > >> > thank you for all your hard work, I really appreciate it. > >> > > >> > Firstly, it seems that the website SSL certificate expired or > something. > >> > At > >> > my latest Chromium reports "Not secure". > >> > > >> > Secondly, I totally understand that there are more pressing issues > than > >> > cool > >> > website, but the current design and functionality is IMO really > putting > >> > people off. So I am going to through away some things which seems > weird > >> > to > >> > ME (and I understand it's subjective - please take it as a friendly > >> > feedback). > >> > > >> > The jQuery versions suggests November 2012, the design idea seems even > >> > older... There are old information such as "We are soon releasing a > beta > >> > supporting Python 3.3." or the fact that the donations bars are still > >> > present even though they are closed (and hence could be moved into > some > >> > blog > >> > post). Blog is also terrible, this is how it renders on my laptop (the > >> > same > >> > with the external display): https://imgur.com/a/qkjEa . The logo > could > >> > be > >> > surely polished as well (I like the idea, but it seems a bit > childish). > >> > Even > >> > though I am not professional front end developer, I am quite confident > >> > this > >> > feedback is not far from what a professional would say. It's also not > >> > about > >> > having "cool" website for itself, but that a nice projects attracts > good > >> > people. I myself am questioning how good, from technical point of > view, > >> > Pypy's project can be if the site looks like like it does and the most > >> > convenient way how to reach the devs is through mailing list... > >> > > >> > Best, > >> > Daniel > >> > > >> > _______________________________________________ > >> > pypy-dev mailing list > >> > pypy-dev at python.org > >> > https://mail.python.org/mailman/listinfo/pypy-dev > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renaud.blanch at imag.fr Sun Dec 31 03:59:10 2017 From: renaud.blanch at imag.fr (blanch) Date: Sun, 31 Dec 2017 09:59:10 +0100 Subject: [pypy-dev] pypy 5.10 release Message-ID: hello, thanks for the 5.10 release! just a problem on the mac: it seems that the pypy3 binaries are linked against a libffi provided by a package manager (homebrew?), since dyld is looking for /usr/local/opt/libffi/lib/libffi.6.dylib (see below the error reported and otool output). since i do not use homebrew, it fails to execute on my mac. i have the problem with the pypy3 pre-sierra version, but according to a comment on the morepypy blog [0], the problem exist for high sierra version of pypy3 and for pypy2 (which looks for /usr/local/opt/openssl/lib/libssl.1.0.0.dylib) thanks again for your work, and best wishes for 2018! renaud 0. https://www.blogger.com/comment.g?blogID=3971202189709462152&postID=3223396318213306071&bpli=1 % pypy3 dyld: Library not loaded: /usr/local/opt/libffi/lib/libffi.6.dylib Referenced from: /Users/Shared/src/pypy3-v5.10.0-osx64-2/bin//libpypy3-c.dylib Reason: image not found Trace/BPT trap % otool -L /Users/Shared/src/pypy3-v5.10.0-osx64-2/bin/libpypy3-c.dylib /Users/Shared/src/pypy3-v5.10.0-osx64-2/bin/libpypy3-c.dylib: @rpath/libpypy3-c.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/local/opt/libffi/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.1.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) -- Renaud Blanch http://iihm.imag.fr/blanch/ mailto:renaud.blanch at imag.fr tel:+33.4.57.42.14.56 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP using GPGMail URL: