March 2026 - Pharo-users - lists.pharo.org

new tool validate_smalltalk_image
by Aaron Wohl March 31, 2026

March 31, 2026

A spinoff/export from the iPad Pharo: validate_smalltalk_image â standalone C++ tool for inspecting Spur image files from the outside This is a read-only tool that parses the binary Spur format directly (no VM needed). It walks the heap, validates structural integrity, and now supports exporting image contents in diff-friendly text formats. Validation: checks object alignment, class table consistency, superclass chain cycles, method header/literal frame integrity, pointer slot validity, and reachability from roots. Reports errors (corruption) vs warnings (suspicious but survivable). Export commands (new): --export-shasum SHA-256 per object â designed for diffing before/after a test run --export-catalog full object metadata (text, JSON, or CSV) --export-hierarchy class inheritance tree with method and instvar counts --export-graph object reference adjacency list (full or rooted subgraph) The shasum workflow: snapshot the image before running your test suite, snapshot after, `diff` the two files. You get a list of every object whose content changed, with class names. Useful for understanding side effects or catching unexpected mutations. https://github.com/avwohl/validate_smalltalk_image

1 0

Re: iPad Pharo test release
by Aaron Wohl March 31, 2026

March 31, 2026

I have some answers. I also fed your email to CLAUDE as it has better numbers on test comparisons and better recall of details. - The VM is entirely new. I started with the Pharo VM. But CLAUDE had endless problems due to the encoding of type info in the high bits of pointers. It tried to move it to the low bits, but claimed operations on pointers were spread out and not localized, allowing change. I had heard how small and easy it was to create Smalltalk VMs, so I just said to make a new VM. - On deploying the note-taker to the apple store. In theory it is supported now. On the Mac, you can create an Apple Xcode project from a Smalltalk app and send it to the store. In pracice we will need to work together as it hasn't been done before. CLAUDE's answers: Reply to Stephane Ducasse's questions about iPad Pharo ===================================================== >From the email thread of 2026-02-28. Q: Did you use the Pharo interpreter VM at all? ----------------------------------------------- No. This is a clean-room C++ interpreter (~100K lines of new code). The main obstacle was that the standard Pharo VM encodes type tags in the high bits of pointers, which breaks on iOS due to ASLR (the OS uses those bits for address randomization). Rather than patch the existing VM to move tags to the low bits, a new interpreter was written that encodes type info in the low 3 bits from the start. Loading a standard Pharo image translates all addresses on the fly. The other blocker was Apple's prohibition of JIT compilation on iOS. This VM is pure interpreter, no JIT. Q: Which tests did you focus on? --------------------------------- We run substantially more tests than the official Pharo CI, and we wrote a test harness (pharo-headless-test) that extends testing into areas the CI does not cover. SECTION 1: Side-by-side -- same test packages, their CI vs our VM ================================================================= The official Pharo 13 CI (Jenkins at ci.inria.fr) runs all TestCase subclasses in the bootstrapped image using: ./pharo Pharo.image test --junit-xml-output '.*' Their bootstrapped image has ~40,306 tests per platform (includes Roassal, extra tools loaded during bootstrap). Our image from get.pharo.org/64/130 has ~28,071 tests (the standard distribution without bootstrap-only packages). For the test classes present in BOTH images: Metric Pharo 13 CI iospharo VM ----------------------------------------------------------- Tests run (per plat.) 40,306 28,071 Unique failures 4 39 fail + 391 err Pass rate 99.99% 98.00% Adjusted pass rate* 99.99% 99.82% Platforms tested 3 (Mac/Lin/Win) 1 (Mac Catalyst) Image source Bootstrapped get.pharo.org JIT Yes (Cog) No (interpreter) * Adjusted: removing ProcessTest processMonitor (46 errors, Pharo 13 image bug, fails identically on official VM) and image meta-tests (SystemDependenciesTest, ReleaseTest, etc.) The 4 tests that fail on official CI also fail (or are covered by the same root causes) on our VM: OCClassBuilderTest >> testCreateNormalClassWithTraitComposition StDebuggerInspectorTest >> testUpdateLayoutForContexts... StDebuggerTest >> testUpdateLayoutForContexts... SystemDependenciesTest >> testExternalUIDependencies Our remaining failures break down as: ProcessTest processMonitor missing 46 (Pharo 13 bug, same on official VM) SystemDependenciesTest 17 (image meta-test) Fuel WideString/WideSymbol 15 (serialization timeout, interpreter speed) Calypso IDE query tests 14 (IDE infrastructure) MicGitHub network tests 9 (rate limiting / network) ReleaseTest meta-tests 9 (image state checks) StDebugger tests 4 (debugger UI) Geometry unimplemented methods 3 (#intersectionsWithEllipse: missing) Other scattered 27 (1 each, assorted) None of these are VM-specific bugs. Zero VM-specific failures. The ~12,000 test count gap is because the CI bootstraps images from source, pulling in extra packages (Roassal charts: 812 tests, plus AI-Algorithms, Sindarin, BeautifulComments, etc.). We also exclude a handful of known hangers (Epicea file watchers, Athens rendering). SECTION 2: Additional tests we run via pharo-headless-test ========================================================== We wrote and open-sourced pharo-headless-test: https://github.com/avwohl/pharo-headless-test This extends testing into areas the official CI does NOT cover because it provides a fake Morphic GUI environment that runs headless. GUI/Spec Presenter Tests (64 test classes, 1,113 tests) ------------------------------------------------------- The official CI runs these but they silently skip or error without a real display. Our fake GUI (setup_fake_gui.st) creates a virtual 1024x768 Morphic world with Display Form, WorldMorph, UI process, and MorphicRenderLoop. This lets Spec presenter tests actually open windows, click buttons, and render morphs. Tests: 1,113 across 64 Spec/GUI test classes Pass: 1,054 (94.6%) Fail: 5 Error: 15 Skip: 35 Timeout: 4 Without setup_fake_gui.st, ~350 of these fail with "receiver of activate is nil" -- they literally cannot run. Higher-Level Package Tests (5 external packages, 7,974 tests) ------------------------------------------------------------- We load and run substantial third-party packages to stress-test VM correctness beyond the built-in test suite: Package Tests Pass Fail Error Rate NeoJSON 116 116 0 0 100% Mustache 47 47 0 0 100% XMLParser 5,978 5,978 0 0 100% PolyMath 1,168 1,162 5 1 99.5% DataFrame 665 651 14 0 97.9% ----------------------------------------------- Total 7,974 7,954 19 1 99.8% All 20 failures are pre-existing on the official Pharo VM. These exercise: JSON/XML parsing, Unicode, template expansion, scientific computing (matrices, ODE solvers, large numbers), tabular data operations, and closures/streams throughout. Total test count across all categories -------------------------------------- Built-in image tests: 28,071 GUI/Spec tests: 1,113 (with fake head) External packages: 7,974 ----------------------------------------- Grand total: 37,158 tests run on iospharo VM Q: Is the interpreter threaded? Does it use auto-localisation? -------------------------------------------------------------- No to both. Dispatch: The interpreter uses a cascading if-else tree in dispatchBytecode() (src/vm/Interpreter.cpp:1548), organized by bytecode ranges, with switch statements for specific groups within each range. It does NOT use computed goto (threaded dispatch). Auto-localisation: The interpreter does NOT copy PC/IP/SP into local variables at the start of each bytecode handler. It directly uses C++ member variables (instructionPointer_, stackPointer_, framePointer_) throughout execution. A comment at line 1164 notes "GC safe point: between bytecodes, no C++ locals hold Oops" -- the design intentionally avoids locals holding object pointers so the GC can see everything. Both of these are areas where performance could be improved. Computed goto dispatch and localised variables are known optimizations described in Stephane's linked paper (Poli22b-MoreVM22-Autolocalisation.pdf). They would likely give a meaningful speedup on the interpreter path. Q: Performance comparison with the Pharo interpreter VM? -------------------------------------------------------- We don't have benchmark numbers yet. The iospharo interpreter is pure C++ with no JIT, no threaded dispatch, and no auto-localisation. The Pharo interpreter VM (StackInterpreter without Cog JIT) uses threaded dispatch and auto-localisation, so it should be faster bytecode-for- bytecode. However, even the official interpreter VM is rarely used -- almost all Pharo users run with the Cog JIT. Potential optimizations that could help: - Computed goto dispatch (threaded interpreter) - Auto-localisation of PC/SP/FP into registers - Inline caching for common message sends - Profile-guided optimization (PGO) of the C++ build - Super-instructions for common bytecode pairs These are all well-understood techniques. The current interpreter prioritized correctness and compatibility over speed. Q: Should this be a separate VM or merged into the standard VM? --------------------------------------------------------------- This is a clean-room implementation, not a fork. The standard Pharo VM (OpenSmalltalk/pharo-vm) is generated from Slang/VMMaker Smalltalk code. This VM is hand-written C++ that reads the same Spur image format. Merging them would mean either: (a) Teaching VMMaker/Slang to generate low-bit-tagged code (large effort, touches every oop operation in the generated C), or (b) Maintaining a separate C++ VM alongside the generated one Option (a) would be better long-term but is a significant project. The current approach works now and passes the test suite. Whether it's worth the effort to merge depends on how much the Pharo team wants native iOS support vs. waiting for a different approach (e.g., the Apple silicon situation changing, or WebAssembly). Q: Naming -- "Pharo" in the App Store -------------------------------------- Currently published as "iospharo" in TestFlight. Happy to use whatever name the Pharo team prefers. Stephane's suggestions included VibePharo, PhaIpad, or bringing it under the Pharo umbrella with a distinguishing name. The name "Pharo Smalltalk" is not used -- just "Pharo" per Stephane's correction. Q: iPhone menu bar cut off / window layout ------------------------------------------ Agreed with Stephane that this should be fixed at the image level, not the VM. The VM provides the screen dimensions; the image's Morphic layout should adapt. Pharo 14 with SDL3 and Toplo/Bloc may handle this better. For now, the startup.st mechanism can inject layout patches, but proper responsive layout belongs in the image. Q: Too slow to release? ------------------------ Interactive use (browsing code, inspecting objects, editing) is usable on iPad. Computation-heavy tasks (loading large packages, running the full test suite, Fuel serialization) are noticeably slow without JIT. But for learning, exploring, and light development, it works. The TestFlight description notes the limitation. Whether it's "good enough" depends on the use case -- for something like The Note Taker app Stephane mentioned, it should be fine. ----- Original message ----- From: "stephane.ducasse(a)free.fr" <stephane.ducasse(a)free.fr> To: Aaron Wohl <xphu(a)awohl.com> Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] iPad Pharo test release Date: Saturday, February 28, 2026 7:18 AM Hi Aaron > Pharo 13 for iPad in the test Apple Store (open in the Apple TestFlight app); > Phone or Mac https://testflight.apple.com/join/kGmPQFr9 > Due to Appleâs no JIT, it's not snappy. But maybe it's still useful? > Source https://github.com/avwohl/iospharo about 100K lines of new source code. Tx for the notice :) This is really a great effort. Iâm browsing the code and Iâm blasted :) Do I understand correctly that you did not use at all the Pharo vm (without the JIT) = the Pharo interpreter VM. Because it is running without the JIT. > This is my first venture into using Pharo. I could use advice on where this project fits in Pharo/Smalltalk land. In the early 80s, I used the Xerox Parc Alto at Carnegie Mellon to run Smalltalk. I got laid off, went on a cruise, sat down in a beach chair with LEARN PHARO and an iPad. But, no Pharo for iPad. You see I would love to see how we can deploy application such as https://github.com/pharo-contributions/the-note-taker The interface is still a bit clunky but I use it regularly on my mac. Just need more time to do a pass on it. > So I did the natural thing and told Claude Code to port Pharo to iPad. 54 days and 1347 commits later, out popped a usable iPad app. This is really cool. > I do have a background in compilers, working on the Production Quality Compiler project at CMU in the early 1980s, mostly on lexers. But I didnât write any code for this. I mostly told CLAUDE a few times a day stop doing workarounds, do what the real VM does, and thatâs a workaround. CLAUDE would never have succeeded I think if I hadnât started insisting a focus on getting the test suite to pass rather than the app to work. This is really interesting. Which tests did you focus on? Because there are many VM tests. > The main snag using the real VM was encoding the encoding of type info in the high bits of pointers for immediate types. It seemed simple to me to shift the type info to the low 3 bits. But Claude could not get the real VM to stop looking in the high bits; perhaps I should have pushed harder on that. But I had always heard how easy it was to port Smalltalk, so I just went with a new VM with the type info in the low bits. Loading a standard image translates the addresses. > The other issue was that Apple forbids JIT on iPad. So this new VM has no JIT. > Issues: > - Should this be a separate VM? Should I push harder on getting the standard VM to work with type info in the low bits and no JIT? Even if that would be better, is it worth the bother now that this works? Let us talk internally and we would like to have a chat with you for sure :) I tried to see if the interpreter is a threaded one but I need to get a decent text editor because reading the code in safari on github is too painful. The default Pharo interpreter is also using localisation. in each byte code branch the global state PC, IP is copied into local temps on exit the inverse is done. http://rmod-files.lille.inria.fr/Team/Texts/Papers/Poli22b-MoreVM22-Autoloc… > > - I donât want to suck up the PharoSmalltalk name in the Apple stores if it causes offense. I can call it VibeTalk VibePharo :) PhaIpad > or something to leave the name free for a hand-coded version. > Or move off the name if a real contender ever shows. Pharo is not Pharo Smalltalk but Pharo :). Now let not me decide alone :) So we will discuss and see. My gut feeling is that - it would be nice to get this under the Pharo umbrella - find a way to distinguish it from the Pharo vm > - Without JIT, is it too slow to bother releasing? Yes! Now we some explanation telling the known limits. > Is there some other optimization that could bridge the gap if it is too slow? I would love to get a comparison with the interpreter VM. > - Are there any users who can give the iPad version a really good workout in real work? The VM passes the test suite. But it just started working on the iPad today. There will be UI issues. I do not know industrial users but as a plain Ipad user I would like to give a try to do something with it. Now I have an old Ipad and marcus a Pro so we can check already. > > - On the iphone the menu bar is cut off, and the welcome window is mostly off the screen. The menu bar layout is in the image, not the VM. I am not sure the VM should work around it. Should these be fixed in the image to have a multi-line menu bar as needed, and reshape initial window layouts on phones? If so is anyone willing to do the Smalltalk side or help me do it (I have written mostly other languages) I think that most of the UI part should be done at the image level. Now I was recently discussing with Pablo about the deployment of app on mac and we decided to wait for P{haro 14 because we will have SDL3 support and also we should check the Toplo/bloc logic because it should be easier than the current one. I mean that we can do it in a similar way than the https://github.com/pharo-contributions/the-note-taker but it should be smoother. We are super busy with the P14 release. Let us sync internally (tuesday is our sync point) and people are coming back from vacation. S.

2 3

v1.1 iPhone/iPad/Mac release
by Aaron Wohl March 27, 2026

March 27, 2026

PharoSmalltalk 1.1 https://apps.apple.com/us/app/pharosmalltalk/id6759073615 It is now in the Apple App Store for iPhone/iPad/Mac. It uses smarter heap allocation to run on older iPhones with less memory. If you are running the TestFlight version to get this fix, you can delete it and get the store version. Source <https://github.com/avwohl/iospharo>

3 2

IMac Pharo?
by Richard O'Keefe March 21, 2026

March 21, 2026

Iâve been given an imac desktop. It is some kind of PowrrPC running OSX Leopard. Works beautifully but too old to update, and no deceloper tools. I donât suppose thereâs an okd version of Pharo that would run on it?

3 2

PharoSmalltalk in Apple app store for iPad
by Aaron Wohl March 19, 2026

March 19, 2026

PharoSmalltalk is available in the Apple App Store for iPad (primary), iPhone, and Mac as https://apps.apple.com/us/app/pharosmalltalk/id6759073615/PharoSmalltalk It uses a new VM with no JIT (iPad forbids JIT) and small objects encoded in the low bits of pointers rather than in the high bits, due to Apple ASLR restrictions. Many thanks to Tim Mackinnon for over 111 emails and trying 98 test builds. Source https://github.com/avwohl/iospharo Note that I have a strong background in compilers, not Smalltalk. If it does something wrong, please let me know at https://github.com/avwohl/iospharo/issues

1 1

AI Web access - and Pharo works...
by Kasper Osterbye March 19, 2026

March 19, 2026

Cheers I wanted to make parts of Pharo accessible from AI APP chat, and for that I needed Teapot. But I ran into an other issue. That is now on Github https://github.com/kasperosterbye/AI-Experiments/blob/main/experiments/2026… One issue understood, now only 219 confusions left. -- Kasper

1 0

UKSTUG Meeting: The VAST Platform AI Assistant: Integrating LLMs into a Live Smalltalk Environment - 25 March 2026
by UK Smalltalk March 18, 2026

March 18, 2026

Smalltalk environments have long been pioneers in developer productivity. With the VAST Platform AI Assistant, Instantiations is extending that tradition by integrating Large Language Models (LLMs) directly into the VAST platform. This new tool is designed to bring AI capabilities directly into your daily workflow. In this session, Johan, Kris, and Mariano will share a user experience report and a live demonstration of the assistantâs current capabilities, powered by Googleâs Gemini. Youâll see how it goes beyond simple chat by directly interacting with the live VAST image through the LLMâs âtoolsâ capabilities. This allows investigating source code as it responds to your questions. These examples will demonstrate how the VAST Platform AI Assistant leverages the live nature of Smalltalk to act as a true pair programmer. Weâll also look ahead at our enterprise-focused roadmap, including support for local models to ensure privacy and security, integration with additional LLM providers, and our vision for deeper IDE-level capabilities and Runtime Intelligence. Join us to explore how we are shaping the future of AI-assisted development in VAST to better empower software developers. See it in action, try it out, and join the conversation on GitHub ( https://github.com/instantiations/VAST-Platform-AI-Assistant ). Johan Brichau ( https://be.linkedin.com/in/johanbrichau ) is a seasoned software engineer with over 25 years of experience across a wide range of Smalltalk environments. He joined the VAST Platform development team at Instantiations in January 2025. Prior to that, he spent nearly 15 years as co-founder and CTO of Yesplan, a world-leading online venue management platform. Johan holds a PhD in computer science from the Vrije Universiteit Brussel (2005) and has actively contributed to several open source projects. Kris Gybels recently joined Instantiations to work on the VAST Platformâs AI-based tool support. He previously spent a number of years in academia researching Declarative Meta Programming and its application to Aspect-Oriented Programming, and over a decade co-developing the Yesplan venue management system, during which he made a number of contributions to Pharo, most notably Pharo 12âs improved Mac âRetina displayâ support, as well as to Seaside and its Parasol web testing framework. Mariano Martinez Peck ( https://ar.linkedin.com/in/mariano-martinez-peck ) is a systems engineer specializing in dynamic programming language software. In 2018, he joined Instantiations to further develop the VAST Platform through the addition of new frameworks, libraries and tools, as well as improving the existing code base of VAST. He is active in the Smalltalk development community, and has used his expertise to co-author numerous open source projects. Mariano has a PhD in Computer Science, and his academic research has been published across various international journals. In addition to his development duties, he currently leads the VAST Platform engineering team at Instantiations. In his personal time, Mariano enjoys traveling as well as outdoor activities like camping and fishing. This will be an online meeting. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/ukstug/events/313492185/ ) to receive the meeting details.

1 0

"Steps for Interaction with Spec Presenters in Hera â New blog post on all: objects all: theTime
by Koen De Hondt March 14, 2026

March 14, 2026

Dear Pharo users and developers, I posted a third article in the series about describing Spec application behaviour with Hera. The first post explained how Hera manages open Spec windows. The second post explained how Hera identifies presenters so they can be referenced in Gherkin scenarios. This post explains how Hera expresses steps to interact with Spec presenters. https://all-objects-all-the-time.st/#/blog/posts/22 As always, all feedback is welcome. Happy reading! Ciao, Koen

1 0

[ANN] Soil version 4
by Norbert Hartl March 12, 2026

March 12, 2026

We are happy to announce the availability of Soil version 4. What is new? Indexes (both skip list and Btree+) now have forward and backward pointer (those have been added) so there is new possibilities to have indexes that are traversable in each direction. This needed to be done in a not backward-compatible way. All databases prior to v4 need to be migrated. A migration procedure is available at https://github.com/ApptiveGrid/Soil/blob/main/docs/versions/migration.md The indexes prior to v4 have been implemented closely to the interface and behavior of a Dictionary. We've added support for duplicated keys which is necessary when doing secondary indexes. A lot of the changes in v4 are regarding to that because it changed quite a bit how things work. NOTE: duplicate keys are considered a preview in v4. They should be usable but might need to settle a bit more. Until now there is no feature supported making use of duplicated keys. Indexes have unique keys as default. They resemble the old behavior and should just work as before journals are now used by a transaction right from the start and creates it while the code operates on it. This way we could remove all brittle intermediate dictionaries like newValues, removedValues in the handling which improved the code a lot There is a first version of read-only transactions where one can make sure every attempt to write to the database should end up in an error There is also a first version of a graph exporter and importer. This can export a graph on the database level which works even if the application code is not present. This is useful for copying or moving a sub-graph from one database to another in an efficient way. There are plenty of code cleanups and performance improvements. The more detailled view can be seen here: https://github.com/ApptiveGrid/Soil/blob/main/docs/versions/changelog-v4.md What is planned for v5? Multi-index collection. This resembles what most other database have. You have one list of objects but multiple indexes to the same data in order to speed up search for different use cases partial indexes. These is a special kind of view to a database index. It consists of a predicate and stores only the elements that pass the predicate. Searching is way faster and things like size are almost for free windows support. There has been a PR provided https://github.com/ApptiveGrid/Soil/pull/980 which needs to be fixed as the way soil handles streams is not compatible with windows If all goes well we will remove the need for the markDirty: calls completely. Cluster modification tracking will then be automatic and removes a huge annoyance when using soil Hope you like it. Give it a spin and then tell us! Norbert & Marcus

1 0

Fwd: New releases: Bloc:v2.8.0, Toplo:v0.9.0 and more
by stephane ducasse March 12, 2026

March 12, 2026

> Begin forwarded message: > > From: LABORDE Pierre <pierre.laborde(a)fr.thalesgroup.com> > Subject: RE: New releases: Bloc:v2.8.0, Toplo:v0.9.0 and more > Date: 12 March 2026 at 09:27:11 CET > To: MartÃn Dias <tinchodias(a)gmail.com>, lse-openbloc <lse-openbloc(a)inria.fr> > Reply-To: LABORDE Pierre <pierre.laborde(a)fr.thalesgroup.com> > > De : lse-openbloc-request(a)inria.fr <mailto:lse-openbloc-request@inria.fr> <lse-openbloc-request(a)inria.fr <mailto:lse-openbloc-request@inria.fr>> De la part de MartÃn Dias > EnvoyÃ© : jeudi 12 mars 2026 02:01 > Ã : lse-openbloc <lse-openbloc(a)inria.fr <mailto:lse-openbloc@inria.fr>> > Objet : New releases: Bloc:v2.8.0, Toplo:v0.9.0 and more > > Hello! the following are the new releases in Bloc/Toplo projects: > > Bloc v2.8.0 <https://github.com/pharo-graphics/Bloc/releases/tag/v2.8.0> > â¢ Fix code styling error in Pharo 14 by @tinchodias in #839 > â¢ Move TBlLayoutResizable to Bloc-Layouts-Support package by @plantec in #834 > â¢ Fix deprecated message send by @tinchodias in #845 > â¢ Send #waitTimeoutMilliseconds: instead of #wait: to Semaphore by @tinchodias in #847 > â¢ Generate baseline with explicit requirements to avoid loading warnings by @tinchodias in #832 > > Toplo v0.9.0 <https://github.com/pharo-graphics/Toplo/releases/tag/v0.9.0> > â¢ Circular menu by @plantec in #368 > â¢ List hierarchy refactoring by @plantec in #360 > â¢ Move defaultNodeFactory to the root abtract class by @plantec in #358 > â¢ Finite data source manager ng by @plantec in #362 > â¢ Simplified node configuration by @plantec in #363 > â¢ List node configuration by @plantec in #365 > â¢ Checkbox selection refactoring by @plantec in #366 > â¢ Improved ToInfiniteListElementEventHandler to fixe selection update iâ¦ by @plantec in #367 > â¢ Make #class: and #iconImageFor: on ToExMiniBrowserClassNodeContent use the FormSet for each of the icons by @Rinzwind in #329 > â¢ Investigating list selection management by @plantec in #370 > â¢ Fix some circular dependencies by @tinchodias in #371 > > Spec-Toplo v0.9.0 <x-msg://28/Spec-Toplo/releases/tag/v0.9.0> > â¢ Diff adapter, begin miler layout, fix selection tree table by @badetitou in #46 > â¢ Improve Code Editor by @badetitou in #47 > â¢ Toplo file selector by @badetitou in #49 > â¢ Add keyshortcut to main window by @badetitou in #50 > â¢ Improve small aspect issue by @badetitou in #51 > â¢ Miller layout by @badetitou in #52 > â¢ Little cleanups by @tinchodias in #53 > â¢ Fix to do list demo by @tinchodias in #81 > â¢ Add a Spec adapter for SpBlocPresenter to the Morphic backend by @tinchodias in #83 > â¢ Load proper group of Roassal by @tinchodias in #86 > â¢ Load Roassal package not baseline by @tinchodias in #88 > > Alexandrie v2.8.0 <https://github.com/pharo-graphics/Alexandrie/releases/tag/v2.8.0> > â¢ Add binding for hb_version_atleast and use it by @tinchodias in #121 > â¢ Cairo context's #newContextDo: initialize the surface > > Album v0.9.0 <https://github.com/pharo-graphics/Albumv0.9.0> > â¢ Few changes needed by Toplo by @plantec in #54 > â¢ Add AlbEditorElement>>lineIndexAtTextIndex: by @plantec > â¢ fixes #infiniteDo: to return the result of the block > â¢ Remove TBlLayoutResizable uses since it is used by BlElement > â¢ The cursor was not blinking by default > > PharoSDL3 <https://github.com/pharo-graphics/PharoSDL3/releases/tag/v0.0.2> > 102 commits in 2026: https://github.com/pharo-graphics/PharoSDL3/compare/964543a2cd6ac278fd208c3… > > > Best regards, > MartÃn

1 0