October 2020 - Pharo-users - lists.pharo.org

Re: Easiest light weight cloud/web persistence for Pharo?

by Offray Vladimir Luna CÃ¡rdenas

On 6/10/20 2:25 p.Â m., jtuchel(a)objektfabrik.de wrote: >>> - Choose Boring Technology - http://boringtechnology.club/ >> This made my day. Thank you :-) > > Had never heard of this guy, but his site feels like home to me. Makes > me a proud user of Smalltalk and DB2 after 25+ years ;-) > > He forgot to mention that boring technology can be quite interesting > and cool, even if it is about to turn 50 years... And he's absolutely > right about the fact that shipiing something useful for users makes > you much more happy (and busy) than shipping something on top of an > incredibly complicated and bloated technology stack... > Unfortunately software tech industry is co-opted by hype, trends and big numbers. In that sense, Pharo or Fossil or technology that doesn't fit that trio seems non boring for those used to evaluate safeness there. In my hackerspace the ones used to more popular tech look at Pharo as too strange (risky?), but those who don't have any preconception, mainly non-programmers (by education or trade) have no problem accepting Pharo, Fossil and more simple and agile technologies. We deliver value swiftly from the margins, without being trapped by hype o big numbers. I wonder how this organic, resilient and innovative growth can be more visible, despite of being so far away of the usual places where most tech related individuals, communities and investors look for. Offray

Oct. 7, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Tim Mackinnon

Oh.. and blimey , look what I just found in my spam bucket âthey are watching meâ¦ â - > "We are excited to announce the General Availability of DigitalOcean App Platform <https://pages.news.digitalocean.com/I0o2WEY06sliXV32090ID00>, a reimagined platform as a service (PaaS) that makes it much simpler and faster to build, deploy, and scale apps. App Platform does the heavy lifting of managing infrastructure, app runtimes, and dependencies â so you can focus on what matters the most: building awesome apps.â Possibly with its Docker support, perhaps Pharo might slot it, and they take care of everything for meâ¦ well hereâs hoping right? Tim > On 6 Oct 2020, at 21:41, Tim Mackinnon <tim(a)testit.works> wrote: > > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ however, move too soon and you get bogged down with the details and you lose site of an MVP. > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). I suppose this is where the Rails scaffolding was/is? such a jumpstart, you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > Tim > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> Sean, >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> But, hey, I said all of that before. >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> Joachim >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >>> jtuchel wrote >>>> Sigh. Forget about the idea that it will be easy to switch your >>>> persistence later....I am not commenting on SimplePersistence here, I >>>> don't even know what it >>>> does or doesn't. >>> Joachim, >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >>> of a project growing enough to force me to make those tough choices! For >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >>> choices until you are forced to. It's really just a layer of sugar on top of >>> Fuel (it used to use the old school Squeak equivalent serialization >>> mechanism - I forget the name and that might still work). You tell it what >>> classes to serialize. Implement two methods for each class that get and set >>> the data, and then it saves the whole thing as one object graph. >>> >>> Tim, >>> If you use SimplePersistence, please keep me posted about your experience. >>> I'm happy to help. >>> >>> NB I have maintained and extended the library, but it is the work of Ramon >>> Leon >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>

Oct. 6, 2020

[Ann] IndieWeb and pocket infrastructures: 5th biweekly workshop this Saturday (3:15 PM - 7:15 PM, GMT-5)

by Offray Vladimir Luna CÃ¡rdenas

Hi all, This is just a short reminder about our biweekly Grafoscopio community workshops about IndieWeb and pocket infrastructures (in Spanish). You can find more information about them on: [1] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#tall… It has been really nice to see how workshops, prose and code advance intertwined and feedback each other in this community experience made on a voluntary basis. In the "behind scenes" links below you can see how the writing advances at a pretty good pace. Also I would like to thank ESUG for their key support to this initiative. Cheers, Offray Ps: here are the "behind scenes" links [2] https://mutabit.com/repos.fossil/indieweb/timeline [3] https://mutabit.com/repos.fossil/indieweb/tree?ci=tip&name=docs/es&type=tree [4] https://code.tupale.co/Offray/Brea [5] https://mutabit.com/repos.fossil/brea/

Oct. 6, 2020

Re: Standalone html builder (a la seaside without seaside?)

by Torsten Bergmann

Oct. 6, 2020

[ANN] HighchartsSt v12.1.0 [v12.1.0] released!

by Buenos Aires Smalltalk

Oct. 6, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Tim Mackinnon

Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ however, move too soon and you get bogged down with the details and you lose site of an MVP. It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). I suppose this is where the Rails scaffolding was/is? such a jumpstart, you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ Tim > On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: > > Sean, > > thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. > What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. > > I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) > > In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. > > The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. > > Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. > > But, hey, I said all of that before. > > So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. > > I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? > > I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. > > But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. > > Joachim > > > > > Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >> jtuchel wrote >>> Sigh. Forget about the idea that it will be easy to switch your >>> persistence later....I am not commenting on SimplePersistence here, I >>> don't even know what it >>> does or doesn't. >> Joachim, >> Thanks for this interesting perspective. I've never had the (mis?!)fortune >> of a project growing enough to force me to make those tough choices! For >> SimplePersistence I will say that I view it as a way to *delay* making *any* >> choices until you are forced to. It's really just a layer of sugar on top of >> Fuel (it used to use the old school Squeak equivalent serialization >> mechanism - I forget the name and that might still work). You tell it what >> classes to serialize. Implement two methods for each class that get and set >> the data, and then it saves the whole thing as one object graph. >> >> Tim, >> If you use SimplePersistence, please keep me posted about your experience. >> I'm happy to help. >> >> NB I have maintained and extended the library, but it is the work of Ramon >> Leon >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >

Oct. 6, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by jtuchel＠objektfabrik.de

Sean, thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. But, hey, I said all of that before. So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. Joachim Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: > jtuchel wrote >> Sigh. Forget about the idea that it will be easy to switch your >> persistence later....I am not commenting on SimplePersistence here, I >> don't even know what it >> does or doesn't. > Joachim, > Thanks for this interesting perspective. I've never had the (mis?!)fortune > of a project growing enough to force me to make those tough choices! For > SimplePersistence I will say that I view it as a way to *delay* making *any* > choices until you are forced to. It's really just a layer of sugar on top of > Fuel (it used to use the old school Squeak equivalent serialization > mechanism - I forget the name and that might still work). You tell it what > classes to serialize. Implement two methods for each class that get and set > the data, and then it saves the whole thing as one object graph. > > Tim, > If you use SimplePersistence, please keep me posted about your experience. > I'm happy to help. > > NB I have maintained and extended the library, but it is the work of Ramon > Leon > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 6, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by jtuchel＠objektfabrik.de

>> - Choose Boring Technology - http://boringtechnology.club/ > This made my day. Thank you :-) Had never heard of this guy, but his site feels like home to me. Makes me a proud user of Smalltalk and DB2 after 25+ years ;-) He forgot to mention that boring technology can be quite interesting and cool, even if it is about to turn 50 years... And he's absolutely right about the fact that shipiing something useful for users makes you much more happy (and busy) than shipping something on top of an incredibly complicated and bloated technology stack... Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 6, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Gabriel Cotelli

If you want to use docker there's https://github.com/ba-st/docker-pharo and others that I don't remembar now that provides the basics. You have some examples in https://github.com/ba-st/docker-pharo/blob/master/docs/Examples.md . We're deploying our apps as docker containers so ask any question if you have doubts. On Tue, Oct 6, 2020 at 9:48 AM Tim Mackinnon <tim(a)testit.works> wrote: > Some great answers everyone - really appreciate it. > > I think that all things considered, SimplePersistence seems like a very > easy place to start, and then I can "upgrade" when my super awesome idea > (not), exceeds its bounds. > > I wonder if these answers should go somewhere in a tips section somewhere, > and get updated yearly. > > @jonathan I had forgotten about those server tools - I think the last time > I did something it predated some earlier tips the Sven had given, so will > check it out. Back then, I did have a GitLab build pipeline autodeploying > for me, so I'm hoping I can re-incarnate all of that so I can get my little > app running with no fuss... lets see. > > While I have a love/hate with Docker - I did wonder if there was something > for Pharo that just let me build my image into a container and then it > would just work with little system knowledge needed (as I keep forgetting > all the voodoo between times when I need it). Maybe there is, or maybe it > might come one day soon... > > Tim > > On Tue, 6 Oct 2020, at 9:40 AM, Jonathan van Alteren wrote: > > Hi Tim, > > I've been running Seaside applications on Hetzner cloud servers for more > than a year now, with great pleasure and success: > https://www.hetzner.com/cloud > I guess their servers are similar to Digital Ocean, although I haven't > followed the development of their products and solutions for quite a while. > Setting up a new server at Hetzner is a breeze, and you can start already > for as low as â¬2,49 per month! > > We're using Voyage on MongoDB for persistence. After learning some hard > lessons (and I'm sure there are more to come ;-)), I really enjoy the > unobtrusiveness of it. Most of the time, it doesn't require much attention > and allows me to add persistence to real OO designs quickly and easily. I > find it a welcome change from the relational database work I used to (need > to) do, back when I was still doing Java. The 'everything an object' > principle of Pharo/Smalltalk really makes it shine. > > I can't help you with a list of tradeoffs though. If you come across a set > of arguments, I'd be happy to give feedback. > > By the way, I forked Sven's pharo-server-tools project (here: > https://github.com/objectguild/pharo-server-tools) and have a routine > going that suits me well enough. Still lots of room for improvement, but > it's OK for my current needs. > > Future plans are to use the Hetzner API to provision a new server and use > something like Chef or Ansible to install/configure it automatically to be > ready to deploy a Seaside application. I'd like to integrate this into a > full service CI/CD pipeline in the future, to be able to do automated > production deployments without service interruption if possible. For this > scenario, I would really also like to switch to using GemStone for > persistence. > > Hope this helps! Let me know what you decide and I might be able to help > with some technical stuff. > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > *Sustainable Software for Purpose-Driven Organizations* > > jvalteren(a)objectguild.com > On 6 Oct 2020, 00:23 +0200, Tim Mackinnon <tim(a)testit.works>, wrote: > > Hi everyone - Iâm wondering what is the recommended way to save some > simple user data for a Pharo application I would like to run on the cloud > (probably initially digital ocean, but could be AWS if it came to it). > > Initially I thought I might try and run my little app in Digital ocean (I > followed someoneâs steps a few years ago, and had a simple seaside app > running quite well) - so I was thinking of starting there. > > I know there is Svenâs P3 - but Iâm not sure Iâm ready to run and maintain > a SQL database for a simple application, but could be persuaded it its > simple to setup with little maintenance. Would mongo be a suggestion - is > that easy to setup and run? (And is that Voyage?). > > Possibly I could even use image persistence, and fuel out a Dictionary > from time to time - but I think that might be a little bit too belt and > braces for me. > > Is there something that gives a little table of tradeoffs with some simple > ways to get started? > > Tim > > >

Oct. 6, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by Esteban A. Maringolo

Hi Tim, I think that the persistence you choose will depend heavily on a few things: - The complexity of the objects graphs in your domain models - This architecture of your system - How these objects/data is acceded (Atomically/In clusters) In any case, for a lightweight solution you go the Fuel path, or something using SQLite. I have a GLORP based application (small, ~40 persisted classes), SQLite is so lightweight that I run my SUnit tests creating the whole database _on disk_ from scratch on setUp and destroying it on tearDown), and only run it against the production backend (PostgreSQL) before deploying, but even this is happening less frequently since I'm confident that things will work the same on both. OTOH I'm finding that ORMs are burden, and unless you need to work with an existing schema or you really want to use an RDBMS, you might be better off avoiding them. I've been using ORMs for almost two decades, so that's still my default choice, but I feel winds of change here :-) Regards! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2020