Mailman 3 May 2022 - pypy-dev

Re: Injecting an exception into another thread
by Audrey Dutcher 10 May '23

10 May '23

Hi! Sorry for the delay, I didn't realize I needed to be subscribed to the mailing list to participate in conversations. My use case is that I have a gui application which runs arbitrary tasks as background threads, and needs to provide a cancel button to interrupt them. The tasks are often legacy code and/or are very difficult to find reasonable points to insert checks for interruption. Another use case would be implementing a python shell in a gui. If you want to maintain responsiveness while commands execute, they must be able to run in another thread (or another process, but this is not ideal if the shell is supposed to interact with the internals of your application). Interrupting lines with ctrl-c requires being able to send an exception to worker threads. Hope this helps! Thanks, - Audrey

3 2

PyPy Winter Sprint + cpyext
by Stefan Beyer 20 Dec '22

20 Dec '22

Hey everyone! Those of you who attended or followed one of the last two winter sprints in Leysin might know me, the others probably won't. I'm (still) a Master's student writing my thesis on PyPy's current issue with cross-heap cycles when using cpyext. The main point is, that they are not collected and stay around as floating garbage, even if they are not reachable any more. Correct me if I'm wrong, but I didn't notice anyone else working on that topic (and/or committing something) since I've picked it up two years ago (yeah, I know, that long ago...). I saw that you would be working on "cpyext performance and completeness" during the current winter sprint this week and thought that this might also concern my thesis. So I thought I'll give you an update. I recently pushed my current (non-optimized, breaking-some-tests, but more or less working) implementation of the "CPython-style" GC-extension for cpyext. It is still in an early stage and not all cases (legacy and non-legacy-finalizers, weakrefs) are handled. However, I picked up some pace during the last couple of weeks and I'm determined to finish this implementation during the following weeks (some quirks with the tests have been haunting me, but I think I figured most of them out by now). After that, I will implement a second alternative implementation (to compare to, mostly for the sake of my thesis), which will take some more time. I also added a couple of fancy test cases (the so called "dot-tests"), so that we can test complex object graphs a little bit easier (and also because it was kind of cool to have another language inside PyPy/RPython, even if it was only for the tests...), with more test cases to come (the current ones are a bit messy). None of the new changes concerning low-latency applications are currently integrated, but that should not be too hard. I guess it won't make much sense for me to join you at this year's winter sprint, especially as I won't be able to get there before Thursday, but I might be able to join you over the IRC channel (or some other form of communication if you like). If there is anything that is worth discussing please let me know! Also feel free to comment on my code, but beware that I might change some things once I try to do some optimizations (probably not many, but at least fix the worst issues) and make it a little bit more readable. You can find my code on the cpyext-gc-cycle branch.<https://bitbucket.org/pypy/pypy/commits/branch/cpyext-gc-cycle> Looking forward to hearing from you! Greetings, Stefan

2 2

Injecting an exception into another thread
by Audrey Dutcher 27 May '22

27 May '22

Hello, I'm trying to replicate the behavior you can get in CPython with the following code: ctypes.pythonapi.PyThreadState_SetAsyncExc(ctypes.c_long(tid), ctypes.py_object(KeyboardInterrupt)) This schedules an exception to be raised on the target thread. I saw one reference indicating that the CPython interpreter implements this by polling for exceptions to raise every hundred opcodes or so, but I didn't look into it and don't know for sure that's correct. It does seem correct, though, based just on my intuition of how a runtime would need to handle asynchronous signals. Is there any equivalent functionality in pypy? If not, is there anything fundamentally preventing pypy from gaining something like this? If not, is there anything I can do to help it be built? Thanks, - Audrey -- Audrey Dutcher she/her/hers https://rhelmot.io/

2 1

How can we make Python's C-API more friendly for cpyext?
by encukou＠gmail.com 24 May '22

24 May '22

Hello, I'm figuring out a strategy for the future of Python's C-API, and as one of the goals I'd like to make it friendly for non-C languages. I'd like to ask you for any suggestions, pain points or comments on how to better do that. Would you like to help? I understand PyPy solved a lot of these issues and won't get too much benefit, but I'd like to improve things for future projects. I'm also aware of HPy, a long-term solution. I'd like to meet in the middle. I started a [Google doc](https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3c… to collect notes. If you don't mind Google, please feel free to comment there, but I'll be happy to discuss here as well. If you have a link to a document/rant, I'd love to go through it. In particular, I'd like to ask if any of the following would help, or would have helped in the past: - Regularity in strong/borrowed references (always returning strong references and taking borrowed ones) - Regularity in error handling (all functions should have a dedicated return value, an exception should be set set iff that value is returned) - Avoiding preprocessor macros - Avoiding bit fields - Avoiding enums - Exposing API/ABI information in a structured format, rather than C headers Is anything else missing from this list? Thank you for your time!

3 2

removing transparent proxies
by Carl Friedrich Bolz-Tereick 13 May '22

13 May '22

Hi all! If anybody is particularly against removing transparent proxies, please speak up! The feature has been marked as deprecated since around 2014: https://doc.pypy.org/en/latest/objspace-proxies.html It contains a bit strange irregular code that is pushing against the objspace APIs in various weird ways. So it would be a nice cleanup to remove it and might enable some improvements. Unless somebody complains within the next week or so, I would do the removal. Cheers, Carl Friedrich

3 4

Call for Papers: MPLR Sept 14-16, 2022, Brussels
by Carl Friedrich Bolz-Tereick 02 May '22

02 May '22

======================================================================== Call for Papers MPLR 2022 - 19th International Conference on Managed Programming Languages & Runtimes September 14-16, 2022 in Brussels, Belgium https://soft.vub.ac.be/mplr22/ Follow us @MPLR_Conf ======================================================================== The 19th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems in use, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (desktop, mobile, IoT, and wearable applications). This year, MPLR will be held at the campus of the Vrije Universiteit Brussel(VUB) in Brussels, Belgium. For up-to-date details, check out the conference website: https://soft.vub.ac.be/mplr22/ and follow us on Twitter @MPLR_Conf. The areas of interest include but are not limited to: * Languages and Compilers - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, Lua, MATLAB, Raku, Pony, …) - Portable intermediate representations like Webassembly - Domain-specific languages - Language design - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency * Virtual Machines - Managed runtime systems (e.g., JVM, Android Runtime (ART), V8, LLVM, .NET CLR, RPython, GraalVM, etc.) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management and garbage collection - Hardware/software co-design * Techniques, Tools, and Applications - Static and dynamic program analysis - Testing and debugging - Refactoring - Program understanding - Program synthesis - Security and privacy - Performance analysis and monitoring - Compiler and program verification Submission Categories --------------------- MPLR accepts four types of submissions: 1. Regular research papers describing novel contributions involving managed language platforms. Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. Format: up to 12 pages, excluding bibliography and appendix 2. Work-in-progress research papers describing promising new ideas, with perhaps less maturity than full Papers. Work-in-progress papers will be evaluated with an emphasis on novelty and the potential of the new ideas instead of technical rigor and experimental results. Format: up to 6 pages, excluding bibliography and appendix 3. Industry and tool papers presenting technical challenges and solutions for managed language platforms in the context of deployed applications and systems. Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. Format: up to 6 pages, excluding bibliography and appendix 4. Posters and Demonstrations They will be evaluated similarly to work-in-progress papers. Posters can accompany any submission as a way to provide additional demonstration and discussion opportunities. Format: poster and 1-page abstract Accepted submissions will be published in the ACM Digital Library, except if the authors prefer not to be included. MPLR 2022 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. See http://www.sigplan.org/Resources/Policies/Republication/ Author Instructions ------------------- Submissions need to use the ACM `acmart` format with the `sigconf` style: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions need to use the 'acmart' document class with the ‘sigplan’ option. For reviewing, please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. The standard settings of a 10 point font size. All submissions need to be in PDF format. MPLR uses single-blind reviewing, i.e., author names are generally included in submissions. 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 Site: https://mplr22.hotcrp.com Important Dates --------------- Paper Submission Deadline: 20 May 2022 Paper Author Notification: 23 June 2022 Camera Ready for Papers: 15 July 2022 Posters and Demos Submission Deadline: 12 August 2022 Posters and Demos Notification: 19 August 2022 Conference Dates: 14-16 September 2022 All deadlines are 23:59 AoE (UTC-12h). AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. Organization ------------ Program Committee: Ana Milanova, Rensselaer Polytechnic Institute, USA Camil Demetrescu, Sapienza University of Rome, Italy Christian Wimmer, Oracle CA, USA Christophe Scholliers, University of Gent, Belgium Doug Lea, State University of New York (SUNY) Oswego, USA Erik Ernst, Google, Denmark Guillermo Polito, INRIA, France Jan Vitek, Northeastern University, Czech Technical University Kostis Sagonas, Uppsala University, Sweden Lubomir Bulej, Charles University, Czech Republic Matthew Parkinson, Microsoft Research Cambridge, UK Matteo Marra, Vrije Universiteit Brussel, Belgium Michael Homer, Victoria University of Wellington, New Zealand Sophie Kaleba, University of Kent, UK Tony Hosking, Australian National University, Canberra, Australia Yu David Liu, State University of New York (SUNY) Binghampton, USA General Chair: Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Program Chair: Tobias Wrigstad, Uppsala University, Sweden If you are unsure whether a particular topic falls within the scope of MPRL’22 or if you have any other questions, please do not hesitate to contact the Program Chair (tobias dot wrigstad at it dot uu dot se).

1 0

pypy-dev May 2022