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

Fwd: IWST deadline extension

by Guillermo Polito

Apologies for multiple receptions! > DÃ©but du message rÃ©expÃ©diÃ© : > > De: Guillermo Polito <guillermopolito(a)gmail.com> > Objet: IWST deadline extension > Date: 28 mars 2025 Ã 5:08:37â¯PM UTC+1 > Ã: Gordana Rakic via Esug-list <esug-list(a)lists.esug.org> > > Dear all, > > due to several requests, we have extended the submission deadlines for the call for presentations. > Please check the info below: > > -------- > > IWST is the International Workshop on Smalltalk Technologies. The goal of the workshop is to create a forum around contributions and experiences in building or using technologies related to Smalltalk. While the maturity of presented ideas and results is not crucial, their presentation is expected to trigger discussion and exchange of ideas. The topics of your paper can be on all aspects of Smalltalk, theoretical as well as practical. Authors are invited to submit research articles or industrial papers. > > https://esug.org/2025-Conference/IWST2025.html > > This year we will again have two different tracks: > > Two-Round Paper Submission. As in the previous year, submission will be in two rounds: > Extended abstracts are submitted to present at the conference > Later, full/short papers are submitted for proceedings publications > > Presenting Previously Published Works. We also invite authors of contributions related to IWST's topics, accepted for publication in Journals and Proceedings of top-rated international conferences within the previous 2 years, to submit an abstract and present their published results to the IWST workshop collocated with ESUG. Authors will be invited to present their paper after checking that the submission meets the above criteria. Having the submissions already reviewed and accepted by the peers, they will not be reviewed again for technical content. > Important Dates > > Extended abstract submission deadline: April 7th, 2025 > Already Published Papers Abstract submission deadline: April 7th, 2025 > Extended abstract notification deadline: April 14th, 2025 AoE > > Already Published Papers Abstract notifications: April 14th, 2025 AoE > Full/short paper submission deadline: May 19th, 2025 AoE > > Workshop: July 1-4, 2025 > > Best regards, > IWST team

March 28, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

Hi Guille, > I wonder, are there any good practices/recommendations regarding how to share state between steps? I think there is basically no difference with a unit test. As I wrote in https://all-objects-all-the-time.st/#/blog/posts/10, under "Shared setup and teardownâ, there are a few different ways to cope with different state required by different tests on the same class. My advice would be to create a new class if tests require different state. So I would answer yes to your question "Should this scenario be in a separate feature (shared state?), and all states related to this be in the shared state?â While shared state may be confusing in a unit test, in Hera, and also in Cucumber for Ruby, people can use traits (or Ruby modules) to group steps that use the same state. That way, the different states required by different scenarios can be nicely separated. Even if there are no traits, like in VisualWorks, helper classes can be used to group steps, and instances of those helper classes can carry state. > What kind of heuristics do people use to say things like: > - ok, these two things will be two scenarios of the same feature > - and here, these two need to be in separate features That is a good question. Given that a feature contains different scenarios, people would typically group all scenarios together. But that is not required. You can have different features files in Cucumber that describe different aspects of the same feature (the âFeature:â line at the top would have the same name). In Hera, it would result in different feature methods on different classes. Splitting up a feature is also a way to keep the tests maintainable. > I imagine that a âpuristâ (:D) would try to make features more business-oriented. > But I cannot stop thinking that some âease of implementationâ can creep inside if they simplify the test writing. Yes, features are business-oriented, as they are used to describe acceptance criteria (that is why Heraâs test class is called HeraAcceptanceTest). I guess that with "ease of implementationâ you mean that people are tempted to write imperative-style steps, rather than declarative-style steps. For instance, one can write imperative-style steps like this: Given I am on the sign-in page When I enter my email address in the email field And I enter my password in the password field And I press the âSign inâ button Then I see the home page while a declarative style would result in: Given I am signed in where the latter makes abstraction of how signing in should be done. Letâs discuss more at the Pharo Sprint today. Thank you for the support and the good feedback. Best regards, Koen > On 10 Mar 2025, at 15:16, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Koen! > > This is nice indeed! > > I wonder, are there any good practices/recommendations regarding how to share state between steps? > > For example, > > Letâs say I have a scenario: > > - two browsers do not share state > given that I open *a browser* > and I open *another* browser > when I select Y on the first browser > then the first browser selected blah is X > > Should this scenario be in a separate feature (shared state?), and all states related to this be in the shared state? > > What kind of heuristics do people use to say things like: > - ok, these two things will be two scenarios of the same feature > - and here, these two need to be in separate features > > I imagine that a âpuristâ (:D) would try to make features more business-oriented. > But I cannot stop thinking that some âease of implementationâ can creep inside if they simplify the test writing. > > Do you have some experience on these things? > > G > >> Le 9 mars 2025 Ã 10:18â¯PM, Richard O'Keefe <raoknz(a)gmail.com> a Ã©crit : >> >> I was working on Gherkin-for-Smalltalk myself, but hadnât got nearly this far. You have taken a radically different approach from mine, and I have to say that yours is more Smalltalkish than mine. This is brilliant stuff and i look forward to the release. >> >> As one of my previous managers used to say, âyouâre a hero!â >> >> >> On Mon, 10 Mar 2025 at 8:20â¯AM, Koen De Hondt <koen(a)all-objects-all-the-time.st <mailto:koen@all-objects-all-the-time.st>> wrote: >>> Dear Pharo users and developers, >>> >>> In my series of blog posts on testing, I published a new post on tools for running Gherkin-style test scenarios in Pharo. See https://all-objects-all-the-time.st/#/blog/posts/13. It is an introduction. Future posts will dig into the details. >>> >>> As always, all feedback is welcome. >>> >>> Happy reading! >>> >>> Ciao, >>> Koen >>> >

March 28, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

Hi Richard, Thank you for the kind words. I appreciate your support. Best regards, Koen > On 9 Mar 2025, at 22:18, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I was working on Gherkin-for-Smalltalk myself, but hadnât got nearly this far. You have taken a radically different approach from mine, and I have to say that yours is more Smalltalkish than mine. This is brilliant stuff and i look forward to the release. > > As one of my previous managers used to say, âyouâre a hero!â > > > On Mon, 10 Mar 2025 at 8:20â¯AM, Koen De Hondt <koen(a)all-objects-all-the-time.st <mailto:koen@all-objects-all-the-time.st>> wrote: >> Dear Pharo users and developers, >> >> In my series of blog posts on testing, I published a new post on tools for running Gherkin-style test scenarios in Pharo. See https://all-objects-all-the-time.st/#/blog/posts/13. It is an introduction. Future posts will dig into the details. >> >> As always, all feedback is welcome. >> >> Happy reading! >> >> Ciao, >> Koen >>

March 19, 2025

ESUG 2025 Registration opened

by stephane ducasse

Hello Just a little email to announce that the registration for the conference is now opened. https://registration.esug.org/ESUG <https://registration.esug.org/ESUG> And do not forget to submit your talk. S > > ESUG 2025 Call for Presentations > from Tuesday 1st to 4 th of July 2025 > Gdansk Poland > https://esug.github.io <https://esug.github.io/> > https://esug.github.io/2025-Conference/conf2025.html > > > You can support the ESUG conference in many different ways: > - Sponsor the conference. New sponsoring packages are described at https://esug.org/become_sponsor.html > - Submit a talk, software to the award competition, or a paper to IWST https://esug.github.io/2025-Conference/IWST2025.html > - Attend the conference. We'd like to beat the previous record of attendance (180 people at Koln 2019)! > - Students can get free registration and hosting if they enroll in the the Student Volunteers program. See below. > > New this year: a 3 days lectures will be organised before the conference following the isLoop summerschool principle > https://isloop.pharo.org/ > > ## Developers Forum: International Smalltalk Developers Conference > > We are looking for YOUR experience on using Smalltalk. You will have 30 min for presentations and 45 min for hands-on tutorials. > The list of topics for the normal talks and tutorials includes, but is not limited to the following: > - XP practices, Development tools, Experience reports > - Model-driven development, Web development, Team management > - Meta-Modeling, Security, New libraries & frameworks > - Educational material, Embedded systems and robotics > - SOA and Web services, Interaction with other programming languages > - Teaching Pearls and Show us Your Business > > > We added two types of sessions in addition to the regular talks and ''Show us your project'' sessions. > - Show your business in a 10-minute session (Get prepared!!) > - Teaching pearls: we want some sessions on how to teach some design aspects. We want your tip and tricks to teach Smalltalk or OOP. > We expect to have several 10 to 15-minute sessions aggregated. > > ### How to submit? > > Make a Pull Request here https://github.com/ESUG/esug.github.io/tree/source/2025-Conference/talks > [Or but only if you are not connected to the worldâ¦ send an email to stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>] > > Title: [ESUG 2025] Please follow the template below the email will be automatically processed! > Name: > Email: > Abstract: > Bio: > > ## Call for Student Volunteers > Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. > > Pay attention: the places are limited so do not wait till the last minute to apply. > > Conference details: > Send an email to Steven Costiou <steven.costiou at inria.fr <http://inria.fr/>> and Oleksandr Zaitsev <olk.zaytsev at gmail.com <http://gmail.com/>> with: > > title: [ESUG 2025 Student] > name, > gender, > university/school, > country, > email address > want to attend the isLoop lectures (https://isloop.pharo.org/) > short description of you and why you are interested in participating > > For which period is accommodation covered? Accommodation is covered from Monday 30 th June to 4th July 2025. > If you attend the isLoop lectures the saturday and sunday nights will be covered. > Students will be hosted in student rooms. ESUG additionally covers the lunches during the week and one dinner. > > This year the isLoop schools is organized the Satruday, Sunday and Monday before the conference (soon at https://isloop.pharo.org/) > > Duties include handling registration as people arrive at the conference, collecting presentation slides for ESUG right after the presentation is given, being present at an information desk to answer questions, and generally being helpful. Student volunteering makes the conference better, takes a fairly small amount of time, and doesn't significantly interfere with enjoying and learning from the conference. Please note, that this role requires discipline and constant attention to all attendees. > > Information about hotel > Student Volunteer rooms are booked at (to be announced). If you are a student volunteer, do not book yourself, we have arranged the booking already! > > > > > > > > > > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> > 06 30 93 66 73 > > "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes StÃ©phane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes

March 18, 2025

Craig Latta - Livecoding Language Models: AI Context in Live Environments - 26 March 2025

by UK Smalltalk

For our March meeting, Craig Latta will show how to leverage AI language models in a livecoding environment. Using a tool creates context for complimentary tools. For example, selecting an object in a Smalltalk inspector creates useful context for browsing the class of that object. This is a potent idea in an integrated development environment, where multiple tools operate on related information. The extensive context in a live environment enables powerful collaboration with contemporary AI language models. Tools built from that collaboration could greatly augment human capability. Craig Latta ( https://thiscontext.com/author/ccrraaiigg/ ) will show some foundations for them, and suggest ways of easing their construction through the systematic description of existing tool functionality. For a preview, please see Craig's blog at thiscontext.com ( http://thiscontext.com/ ). Craig Latta is a research computer scientist in Berkeley and Amsterdam, with interests including livecoding, music performance, and interactive visualization. The discovery of a mysteriously-placed Blue Book at university led to stints at several exploratory labs, and a pursuit of improvisation wherever code is found. His current work focuses on polyglot computing with WebAssembly, the novel compiler framework Epigram, and human augmentation through AI. This will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/ukstug/events/305761372/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

March 17, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Guillermo Polito

Hi Koen! This is nice indeed! I wonder, are there any good practices/recommendations regarding how to share state between steps? For example, Letâs say I have a scenario: - two browsers do not share state given that I open *a browser* and I open *another* browser when I select Y on the first browser then the first browser selected blah is X Should this scenario be in a separate feature (shared state?), and all states related to this be in the shared state? What kind of heuristics do people use to say things like: - ok, these two things will be two scenarios of the same feature - and here, these two need to be in separate features I imagine that a âpuristâ (:D) would try to make features more business-oriented. But I cannot stop thinking that some âease of implementationâ can creep inside if they simplify the test writing. Do you have some experience on these things? G > Le 9 mars 2025 Ã 10:18â¯PM, Richard O'Keefe <raoknz(a)gmail.com> a Ã©crit : > > I was working on Gherkin-for-Smalltalk myself, but hadnât got nearly this far. You have taken a radically different approach from mine, and I have to say that yours is more Smalltalkish than mine. This is brilliant stuff and i look forward to the release. > > As one of my previous managers used to say, âyouâre a hero!â > > > On Mon, 10 Mar 2025 at 8:20â¯AM, Koen De Hondt <koen(a)all-objects-all-the-time.st <mailto:koen@all-objects-all-the-time.st>> wrote: >> Dear Pharo users and developers, >> >> In my series of blog posts on testing, I published a new post on tools for running Gherkin-style test scenarios in Pharo. See https://all-objects-all-the-time.st/#/blog/posts/13. It is an introduction. Future posts will dig into the details. >> >> As always, all feedback is welcome. >> >> Happy reading! >> >> Ciao, >> Koen >>

March 10, 2025

Re: Updating a Form after changing pixel values

by Esteban Lorenzano

Hi, This is a corner case that is not considered in Spec design: In fact what you are doing is changing the content of the model and you need the presenter to react to it. Indeed, as Stef says the solution is to re-set the image to the image presenter when performing the change: myPresenter image: modifiedForm. You may think something like that should be done in the `updatePresenter` message (but updatePresenter does not has a mean in "widget" presenters).... or like the `refresh` message for lists/tables, and you would be right (I will add a refresh message to SpImagePresenter). But at the end, it will end up doing exactly that, so you are safe workaround it the thing :) Esteban On 3/8/25 21:03, sducasseatwork--- via Pharo-users wrote: > Hi Mikael > > I do not know the answer so I tried to find it. > Indeed the superclass>>updatePresenter is empty :( > > Let us see what esteban will reply. > Now I tried to check the morphic back end. > > Now writing directly on the canvas this way does not look the right way. > Did you try with > SpMorphPresenter > or > SpRoassalPresenter because you have access to the cairo canvas. > > While browsing the code of the SpMorphicROassalAdapter I saw > > widget sessionChanged. > > > SpAbstractMorphicAdapter I saw changed. > > changed > > ^ self widgetDo: [ :w | w changed ] > > I also saw in SpAbstractAdapter isRedrawable so I wonder if it should > not be true on the Adapter corresponding to the SpImagePresenter (if any) > > > BTW the SpMorphicAthensAdapter defines a method redraw (Athens is the > cairo wrapper used also in Roassal) > > Reading the code of SpMorphicImageAdapter >> buildWidget > > | alphaImage | > alphaImage := AlphaImageMorph new. > alphaImage model: self. > alphaImage > getImageSelector: #getImage; > vResizing: #spaceFill; > hResizing: #spaceFill; > layout: self layoutValue; > dragEnabled: self dragEnabled; > dropEnabled: self dropEnabled; > setBalloonText: self help; > update: #getImage. > > self model > whenImageChangeDo: [ > alphaImage image: > (self getImage ifNil: [ Form extent: 1 @ 1 depth: 32 ]) ]; > whenAutoScaleChangeDo: [ widget layout: self layoutValue ]. > > ^ alphaImage > > It feels like we should reassign the image: > > Did you try something like > >> updatePresenter >> Â Â Â Â Â Â Â Â Â Â Â Â Â self image: self image? > > >> On 7 Mar 2025, at 18:11, Mikael Svane <mikael.svane(a)fridhem.org> wrote: >> >> I have a Form where I change pixel colours using >> Form>>pixelValueAt:put:. The Form exists inside an SpImagePresenter. >> After having changed the pixels, I want to redraw the Form in an >> #updatePresenters method to show the changes, but I havenât been able >> to figure out how to do this. If I inspect the Form it is clear that >> the pixels have been changed, so the problem is in the >> #updatePresenters mwthod. I have tried different variations on this >> theme without success: >> updatePresenter >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | canvas | >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â âGet the canvas of the Form:â >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â canvas := imagePresenter image form getCanvas. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adapter widget drawSubmorphsOn: canvas >> Any suggestions would be very welcome. >> Kind regards, >> Mikael >

March 10, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Richard O'Keefe

I was working on Gherkin-for-Smalltalk myself, but hadnât got nearly this far. You have taken a radically different approach from mine, and I have to say that yours is more Smalltalkish than mine. This is brilliant stuff and i look forward to the release. As one of my previous managers used to say, âyouâre a hero!â On Mon, 10 Mar 2025 at 8:20â¯AM, Koen De Hondt < koen(a)all-objects-all-the-time.st> wrote: > Dear Pharo users and developers, > > In my series of blog posts on testing, I published a new post on tools for > running Gherkin-style test scenarios in Pharo. See > https://all-objects-all-the-time.st/#/blog/posts/13. It is an > introduction. Future posts will dig into the details. > > As always, all feedback is welcome. > > Happy reading! > > Ciao, > Koen > >

March 9, 2025

"Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

Dear Pharo users and developers, In my series of blog posts on testing, I published a new post on tools for running Gherkin-style test scenarios in Pharo. See https://all-objects-all-the-time.st/#/blog/posts/13. It is an introduction. Future posts will dig into the details. As always, all feedback is welcome. Happy reading! Ciao, Koen

March 9, 2025

Re: Updating a Form after changing pixel values

by sducasseatwork＠mailo.com

Hi Mikael I do not know the answer so I tried to find it. Indeed the superclass>>updatePresenter is empty :( Let us see what esteban will reply. Now I tried to check the morphic back end. Now writing directly on the canvas this way does not look the right way. Did you try with SpMorphPresenter or SpRoassalPresenter because you have access to the cairo canvas. While browsing the code of the SpMorphicROassalAdapter I saw widget sessionChanged. SpAbstractMorphicAdapter I saw changed. changed ^ self widgetDo: [ :w | w changed ] I also saw in SpAbstractAdapter isRedrawable so I wonder if it should not be true on the Adapter corresponding to the SpImagePresenter (if any) BTW the SpMorphicAthensAdapter defines a method redraw (Athens is the cairo wrapper used also in Roassal) Reading the code of SpMorphicImageAdapter >> buildWidget | alphaImage | alphaImage := AlphaImageMorph new. alphaImage model: self. alphaImage getImageSelector: #getImage; vResizing: #spaceFill; hResizing: #spaceFill; layout: self layoutValue; dragEnabled: self dragEnabled; dropEnabled: self dropEnabled; setBalloonText: self help; update: #getImage. self model whenImageChangeDo: [ alphaImage image: (self getImage ifNil: [ Form extent: 1 @ 1 depth: 32 ]) ]; whenAutoScaleChangeDo: [ widget layout: self layoutValue ]. ^ alphaImage It feels like we should reassign the image: Did you try something like > updatePresenter > > self image: self image? > On 7 Mar 2025, at 18:11, Mikael Svane <mikael.svane(a)fridhem.org> wrote: > > I have a Form where I change pixel colours using Form>>pixelValueAt:put:. The Form exists inside an SpImagePresenter. After having changed the pixels, I want to redraw the Form in an #updatePresenters method to show the changes, but I havenât been able to figure out how to do this. If I inspect the Form it is clear that the pixels have been changed, so the problem is in the #updatePresenters mwthod. I have tried different variations on this theme without success: > > updatePresenter > | canvas | > âGet the canvas of the Form:â > canvas := imagePresenter image form getCanvas. > > adapter widget drawSubmorphsOn: canvas > > Any suggestions would be very welcome. > > Kind regards, > Mikael

March 8, 2025