August 2026 - Pharo-dev - lists.pharo.org

Re: Understanding Pharo's Roadmap & Core Contribution Process: Internal vs. External Packages

by Cyril FERLICOT-DELBECQUE

Hello :) I'll let other people detail better the full process, but I can still give some indications. For small changes, you can just open an issue or do a pull request directly. For bigger changes, there is this repository where suggestions can be made: https://github.com/pharo-project/pheps Then the pull request of the phep can be debatable and multiple people of the community can give their opinion. For the roadmap, the core engineers of Pharo are meeting after each release to plan the global roadmap for the next release. This is mostly high level, it is possible to propose other things during the development phase. It can also be influenced by companies that are willing to pay for some developments. For the contribution best practice, in general it depends on the size of a change. For example, to fix a typo or a bug, just do a PR. To ask for a new feature that is not too big and you don't have the code yet, an issue is fine. For a change that is bigger but does not fundamentally change Pharo's design/syntax, an issue or a discussion on discord is fine. But for a change with a lot of impact, pheps are probably the best! It's nice to see people getting interesting in improving Pharo. Have a nice day :) -- Cyril Ferlicot-Delbecquehttps://ferlicot.fr On Friday, August 28th, 2026 at 9:20 PM, Huperniketes via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > Hi Pharo Developers, > > I am looking to better understand the decision-making and planning process for the Pharo core image. I have a few architectural ideas and new feature concepts, and want to ensure I align with the community's vision or determine if I should build them independently. > > Could anyone share insights on the following: > > - > > The Core Decision Process: How are major changes to core classes, refactorings, or large feature additions typically proposed, debated, and approved? Is there a formal RFC/PIP (Pharo Improvement Proposal) process, or does this primarily happen via GitHub issue triage? > > - > > Prioritization & Roadmap: How does the Consortium or core team decide what gets integrated into the next major Pharo release versus what gets left to external ecosystems? > > - > > Contribution Best Practices: What is the recommended path for an individual contributor to pitch a significant design change? Should I present prototypes on this mailing list first, open a GitHub issue, or discuss it on Discord? > > Ultimately, my goal is to figure out whether my ideas belong as core contributions or if they are better suited as separate, independent libraries managed via Metacello. For greater context, I’m working on a Smalltalk environment where the current global system is broken up into separate projects: a Smalltalk OS or platform, a programming environment, and various apps. > > Thank you for your time and guidance! > > Warmest regards, > Alfonso Guerra

Aug. 28, 2026

Understanding Pharo's Roadmap & Core Contribution Process: Internal vs. External Packages

by Huperniketes

Hi Pharo Developers, I am looking to better understand the decision-making and planning process for the Pharo core image. I have a few architectural ideas and new feature concepts, and want to ensure I align with the community's vision or determine if I should build them independently. Could anyone share insights on the following: 1. The Core Decision Process: How are major changes to core classes, refactorings, or large feature additions typically proposed, debated, and approved? Is there a formal RFC/PIP (Pharo Improvement Proposal) process, or does this primarily happen via GitHub issue triage? 2. Prioritization & Roadmap: How does the Consortium or core team decide what gets integrated into the next major Pharo release versus what gets left to external ecosystems? 3. Contribution Best Practices: What is the recommended path for an individual contributor to pitch a significant design change? Should I present prototypes on this mailing list first, open a GitHub issue, or discuss it on Discord? Ultimately, my goal is to figure out whether my ideas belong as core contributions or if they are better suited as separate, independent libraries managed via Metacello. For greater context, I’m working on a Smalltalk environment where the current global system is broken up into separate projects: a Smalltalk OS or platform, a programming environment, and various apps. Thank you for your time and guidance! Warmest regards, Alfonso Guerra

Aug. 28, 2026

Re: [Cuis-dev] Smalltalk on Android and in the Browser

by Agustin Martinez

Hi Juan, Thanks for the great feedback!! Vector engine plugin works in JS, and the do-it error on android was solved!! Also you can see the halos in Android. Rotating a window is possible in both projects. Best!! Agustin On Fri, Aug 14, 2026 at 4:50 PM Juan Vuletich <juan(a)cuis.st> wrote: > Hi Agustín, > > This is very impressive! > > I just tried the Android VM on my Samsung phone. It works amazingly well. > I haven't been able to run Cuis on a phone in a long time. This is great! > Performance is impressive. I get 724 megaBytecodes/second and 40 > megasends/second. This is similar to what I get on a RasPi 3B+. Vector > graphics plugin claims to be active, although I found no easy way to stress > it. Is there a way to get a halo on a morph? > > I also tried the SqueakJS, with the provided Cuis image. I tried it both > on Firefox and Chrome on a Mac. It starts and the menus and tools seem to > work, but I get a primitive failure if I try any DoIt. Is this a known > issue? Does it work for you? If so, in which platform / os / browsers have > you tested? As I could not evaluate or edit code, I could not test > performance. Morphic halos work, but it seems the VectorGraphicsPlugin is > not available, as it doesn't show the scale halo for SystemWindows. > > Thanks! > On 2026-08-10 7:33 PM, Agustin Martinez via Cuis-dev wrote: > > Hi, I'd like to share two projects related to Squeak, Cuis, and Pharo. > > The first is a fork of the SqueakJS project, which lets you run the latest > versions of Pharo, Squeak, and Cuis, and includes performance and UX > improvements. > > smalltalkjsvm.com.ar > > The second is a version of OpenSmalltalk for Android where you can run > Squeak and Cuis. It was developed with help from FAST.org.ar. > > https://github.com/agustincico/opensmalltalk-android > > All feedback is welcome. There's always room for improvement. > > Best regards, > > Agustín > > > -- > Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuleti… > >

Aug. 18, 2026

Smalltalk on Android and in the Browser

by Agustin Martinez

Hi, I'd like to share two projects related to Squeak, Cuis, and Pharo. The first is a fork of the SqueakJS project, which lets you run the latest versions of Pharo, Squeak, and Cuis, and includes performance and UX improvements. smalltalkjsvm.com.ar The second is a version of OpenSmalltalk for Android where you can run Squeak and Cuis. It was developed with help from FAST.org.ar. https://github.com/agustincico/opensmalltalk-android All feedback is welcome. There's always room for improvement. Best regards, Agustín

Aug. 10, 2026

Looking for my next Smalltalk opportunity

by Sebastian Jordan

Hi everyone, After almost seven years being part of the Pharo community, I wanted to reach out here because this community has been an important part of my professional journey. I am currently finishing my PhD at INRIA, France, and I am looking for my next opportunity as a software developer. After completing my PhD, I will be moving back to LATAM, Bolivia, and I am looking for a fully remote position starting around mid-October or November. I would love to continue working with Smalltalk. Most of my experience is with Pharo, but I am open to any Smalltalk dialect and different kinds of projects. I am also open to full-time positions, contracts, or consulting work. Over the years, I have contributed to several parts of the Pharo ecosystem. Before my PhD, I worked as an R&D software engineer at INRIA on Pharo, where I developed tools for code analysis and transformation, contributed to Moose and pharo-ai. I have mentored students through Google Summer of Code since 2021. I have continued to work on programming languages and developer tools throughout my PhD, focusing on runtime-related issues, instrumentation, profiling (dynamic analysis), and memory analysis. Solving difficult problems, designing clear object-oriented systems, writing tests, improving existing codebases through refactoring, and building tools that increase developer productivity are all aspects of software development that I enjoy. I also enjoy working on enterprise applications where maintainability and good design are important. If you know of a team looking for someone with my background, or if you would simply like to discuss possible opportunities, I would be very happy to hear from you. I can also send my CV privately to anyone interested. Thanks everyone for your help, and I hope to continue being part of the Smalltalk community. Best regards, Sebastian JORDAN MONTAÑO

Aug. 5, 2026

OpenAPI now validates and tracks JSONSchema master

by Norbert Hartl

Hi all, OpenAPI (https://github.com/zweidenker/OpenAPI) got the same treatment as JSONSchema recently: the baseline dropped its stale 2020-era JSONSchema pin and now tracks JSONSchema's master, and the library actually validates whole documents now instead of just parsing them. What's new: OADocumentValidator checks a full document against the official OAI 3.0 meta-schema (bundled, Apache-2.0), with real error messages, not just true/false. Verified against six real OpenAPI 3.0 documents from the official spec repo (petstore, petstore-expanded, api-with-examples, callback-example, link-example, uspto) - round-tripping them surfaced and fixed several real bugs that hand-written test documents never would have. OpenAPI-Client was exercised against a real spec (Stripe's) end-to-end, which is what it took to find that request bodies were JSON-only when most real APIs use form-urlencoded bodies. That's fixed too. Scope is still explicitly OpenAPI 3.0. 3.1/3.2 use a different schema dialect (JSON Schema 2020-12 + OAS vocabulary - $dynamicRef, $ref-with-siblings, unevaluated*), which needs machinery JSONSchema doesn't have yet. Not pursuing that for now is a deliberate decision, not an oversight. Code and README (installation, quick start, what's not supported) are on GitHub: https://github.com/zweidenker/OpenAPI Norbert

Aug. 1, 2026