- Pharo-dev - lists.pharo.org

Spam Problem: please ignore spam mail

by Marcus Denker

Hello, We are seeing spammers subscribing to the list before sending spam. This is really a new level (I think they use llm agents). I have put the list on emergency moderation for now cleaned the archive will setup a stricter subscription with the support (already discussing with them) Marcus

Oct. 7, 2026

[ANN] Canopy - I have global values

by Norbert Hartl

Hi, I’m happy to announce a little library I did for managing configuration files and metrics a bit better for the case of ApptiveGrid. As most things in ApptiveGrid like Soil I factor it out and make it publicly available. Yesterday I gave a talk at the UK smalltalk user group which was fun and I took it to make it kind of the release event. The code is here https://github.com/ApptiveGrid/Canopy und a description of the rationale you can read here https://norbert.hartl.name/blog/2026-10-01_canopy-i-have-global-values.html Happy to get feedback and comments, Norbert

Oct. 1, 2026

Sharing projects: PCRE2 and OpenTelemetry

by DARBORD Gabriel

Hi everyone, I'd like to share some of the projects I've been working on, and especially two that reached v1 this summer :) Perl-Compatible Regular Expressions Link: https://github.com/Gabriel-Darbord/pharo-pcre2 This project provides comprehensive FFI bindings to the PCRE2<https://github.com/PCRE2Project/pcre2> library. You may remember my quick talk at "Show Us Your Project" if you were at ESUG'26. To summarize: I felt dissatisfied with regular expressions as they currently work in Pharo, especially because they have their own syntax. The most infuriating feature to me is that the colon `:` is a special character, which is also ubiquitous when working with Pharo because it's part of the message keyword syntax! For the story, up to Pharo 12, most search features including method search (cmd/ctrl+F when selecting methods in the browser) used regex implicitly. If you searched for a keyword selector and used a colon, the list included all methods because that was the default behavior when the pattern failed. You had to escape the colon character with a backslash, something you'd only know if you were familiar with Pharo's regex. Now in the "age of LLMs", I wanted to provide regex search capabilities to agents, but I noticed they kept making wrong patterns because they weren't familiar with Pharo's particular syntax. I had already started this project a couple of years ago, and thanks to agents I was able to quickly finish the binding coverage (I'm not saying the project is finished!). We're now using it as part of our Pharo MCP<https://github.com/Evref-BL/MCP>, also presented at ESUG (quick plug :P). Enough rambling, the README and docs can tell you more if you're interested. Just one last thing worth mentioning: if you know a bit about FFI, you probably know that external memory is freed when the image is shut down. I didn't want the PCRE2 objects to become unusable between sessions, so I added a "session manager" that restores the relevant objects automatically. That means PCRE2 objects based on external memory can be used like regular Pharo objects without having to care about the image lifecycle, which is something we take for granted but it's actually a bit special :) OpenTelemetry Link: https://github.com/Gabriel-Darbord/opentelemetry-pharo This project provides extensive coverage of the OpenTelemetry<https://opentelemetry.io/> specification (v1.58.0). Don't worry, I don't have as much to say about this one: if you're interested in observability, it should speak for itself. However, I'm still going to ramble a bit about how this came to be. This started a couple of years ago (a bit earlier than PCRE2), and it was simply a wrapper over instrumentation libraries: MetaLink<https://github.com/pharo-project/pharo/blob/Pharo14/src/Reflectivity/MetaLi…>, and later, MethodProxies<https://github.com/pharo-contributions/MethodProxies>. I only used it to capture method receivers, arguments, and results in traces in order to generate regression tests, so it was pretty bare-bones. A few people reached out and I saw there was demand for telemetry capabilities in Pharo, but I simply didn't have the time to invest in this library, which was really just a shim to achieve my test generation goals. Now that I'm free of those goals, and thanks to agents, I found the time and manbotpower to get this done to a degree I find satisfactory. I've only mentioned instrumentation, which is used to run arbitrary code on method edges (before or after), without having to modify the targeted methods. This library also supports manual instrumentation<https://opentelemetry.io/docs/specs/otel/glossary/#manual-instrumentation>: you can modify your methods anywhere in their body to code against the OpenTelemetry API and generate telemetry data. — I'm also taking this opportunity to share some unstable projects (as in still in alpha) that may also be of interest. Replay Link: https://github.com/Gabriel-Darbord/Replay About: Replay user actions in a Pharo image. I started this to help a friend who wanted to run an experiment and needed a guided walkthrough of their program to teach users. You can build/record scenarios that open and close windows, annotate a part of their interface, click, type, navigate, use shortcuts, etc. Scenarios can be made into macros and bound to a shortcut of your choosing. This is the project I used to showcase PCRE2 during "Show Us Your Project", if you were wondering how that was done :) For the story (because I can't help myself from rambling), I had some ambitions to make this into a GUI-testing framework, but then news about Hera<https://github.com/koendehondt/hera-for-pharo> dropped so I stopped working on this side project, until recently with agents and you know the rest... (note: Replay is not a GUI-testing framework!) Pharo-Image-FS Link: https://github.com/Evref-BL/pharo-image-fs About: Mount a live Pharo image as a local filesystem. Note: macOS only for now. Agents have been a recurring theme in my projects presented so far, and that's because I've been using them extensively since April. I found that some of the main things to watch with agents are code quality, i.e. writing maintainable code, and efficiency, i.e. using as few tokens as possible to achieve a task. I'm taking this opportunity to plug this presentation I gave to the Evref team in July: Using Pharo with LLMs: Retrospective of a 3-month journey<https://www.slideshare.net/slideshow/using-pharo-with-llms-retrospective-of…>. I've mainly been using our MCP, and for the quality aspect: - The MCP proposes an AGENTS.md<https://github.com/Evref-BL/MCP/blob/main/templates/AGENTS.md> file that references Pharo coding rules<https://github.com/Evref-BL/MCP/blob/main/docs/user/pharo-coding-rules.md> and styles<https://github.com/Evref-BL/MCP/blob/main/docs/user/pharo-coding-style.md> based on literature<https://github.com/Evref-BL/MCP/blob/main/docs/dev/pharo-guidance-bibliogra…>. - We take advantage of the critique system, plus custom critiques, to give feedback to agents after each method modification. Regarding the efficiency aspect, the increasing cost of agents is making MCP-based workflows more and more expensive to use, compared to the basic filesystem and CLI-based tools that come with most coding agents by default. Agents are used to these tools and can use them without making mistakes about their schemas. Thus, I wanted a way to let agents code live in Pharo with those tools, which means making them work with files. After some research, I found FUSE<https://en.wikipedia.org/wiki/Filesystem_in_Userspace> (Filesystem in Userpace) that seems to be one of the most appropriate ways to achieve this, compared to others such as WebDAV or NFS. FUSE lets us create a filesystem projection with a backend in a Pharo image. The mounted filesystem includes: - `tonel/`: the whole image is projected in Tonel format. It lazily exports Tonel only for accessed classes, and accepts writes only when they compile. - `critiques/`: read-only directory populated by critiques generated during edits. - `repositories/`: read-only directory containing metadata and symlinks to repositories loaded in the image. - `errors/`: read-only directory with error logs of filesystem operations, e.g. explaining why a write failed. It's working well for me so far: it allows agents to read and write quickly, and use the tools they are used to, such as `find` and `rg`. It also pairs well with the MCP, which proposes IDE tools to run tests, resolve symbols (finding senders/implementors/references), load projects, debug, etc. — Thanks for your attention! If any of these projects are useful to you, I’d be happy to hear your feedback or welcome contributions :) Cheers, Gabriel Darbord

Sept. 2, 2026

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

Re: [ANN] Soil v5

by Graham McLeod

Congrats! Nice to see the commitment and evolution. :) KR Graham McLeod Owner/Chief Architect “Building Desirable Futures” Training • Consulting • Tools • Research graham(a)inspired.org <mailto:graham@inspired.org> https://www.inspired.org <https://www.inspired.org/>. landline: +27 21 531 5404 LinkedIn: https://www.linkedin.com/in/grahamatinspired/ > On 29 Jul 2026, at 18:07, Norbert Hartl via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > We are happy to announce the availability of Soil version 5. > > What is new? > > Automatic change tracking: Soil now computes a recursive content hash for objects and uses it to detect modifications automatically. This removes the need for the explicit markDirty: calls that were previously required — something we called out as a goal back in the v4 announcement. > Read-only transactions have been hardened: we now distinguish a transaction that is intentionally read-only from one that just happens to end up with no changes, and read-only transactions abort automatically instead of committing a no-op. > Indexed collections (SoilPersistentDictionary and indexed dictionaries) can now be used as non-root objects, not just at the root of the database. > A first working garbage collector has landed — a preview, not a finished feature: Soil>>garbageCollect compacts object segments offline by cloning and atomically swapping them in. There's also a new opt-in Soil>>checkConsistency you can run separately without slowing down the GC itself. The data-layer primitives for a future online/segment-based GC are also in place, though not yet wired up. > A new SoilCommitError hierarchy lets you catch any commit-time failure with one exception class instead of several unrelated ones. > A good number of crash and silent-data-corruption fixes, notably around the graph exporter/importer, backup version history, and depth-first traversal. > Full changelog: https://github.com/ApptiveGrid/Soil/blob/main/docs/versions/changelog-v5.md > > I also wrote up the release on the blog, with a bit more context: https://norbert.hartl.name/blog/2026-07-29_soil-v5-released.html > > What is planned next? > > Integrating the Windows support work that's already sitting there > Process-specific variables > A preview of an online GC, building on the primitives that landed in v5 > Multi-index collections and partial indexes (carried over from v4's plan) > Hope you like it. Give it a spin and then tell us! > > Norbert & Marcus > > _______________________________________________ > Pharo-dev mailing list -- pharo-dev(a)lists.pharo.org > To unsubscribe send an email to pharo-dev-leave(a)lists.pharo.org

July 30, 2026