To be fair, C++CLI is quite a pleasure to code, it's a very refreshing technology that sits nicely on the barrier of runtime and compiletime, similar to Objective C; eg still has access to unmanaged resources, while still having managed resources in contrast to Java/C# which kinda go one step towards runtime, and ISO C++ which tries to stay within compile time. Windows Programming isn't quite that bad now with C++CLI, my image is contrived to demonstrate one of my first successful attempts at getting COM to actually do something other than give me compilation errors. -- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

By the way I am all for COM for Pharo, the issue is that 2/3 of our community are MacOS and Linux users , I dont even remember the last time we had a Windows only topic in the mailing list. Modern languages generally avoid using OS specific libraries, the last exceptions be C# and Swift and C# definetly looks like it will be fully cross platform soon enough (it already is because of Mono). On Sun, Oct 2, 2016 at 4:49 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Well that is not fair because C++ CLI is basically C++ .NET which is another language altogether baring some resemblance to C++.

And you dont need C++ CLI to sit on barrier of runtime and compile , C++ can do this just fine.

I found this recently trying to experiment at whether its possible to do live coding with C++. I found it after following tutorials that is very possible doing that isfyou put only a super minimal code loop in the executable that loads DLLs and divert all other code to DLLs. This gives you ability to have instant compilation and change code while it is executed. For live data you can put all data to a place in memory and then pass the memory as pointer to the DLLs. This give you live inspection of data and live change of data. You can even protect yourself from crashes , something that Pharo cannot currently do, by wrapping the loading of the DLLs to an OS exception, the executable will never crash but it will show the crash errors. Of course you can hook the debugger for live debugging etc.

You can find my experiment here https://github.com/kilon/LiveCPP and find more info here https://www.youtube.com/watch?v=WMSBRk5WG58

My complains however is over the design of WIndows APIs for C++ , they are beyond ugly, the naming convention alone has a notoriously bad reputation.

.NET is another thing altogether, its a beauty. Its actually an insult to put C# and Java on the same sentence, many coders think that C# is a rip off of Java but nothing could be further from the truth. The creator of .NET is not Microsoft , Microsoft has no clue what good design is, its a coder they hired that worked previously with Borland and created the gorgeous Delphi. Delphi is the only true pro quality Smalltalk out there, without being a Smalltalk. That may sound as a contradiction and it is. Delphi does not use the Smalltalk language , instead uses Object Pascal but pretty much else is a recipe take from the Smalltalk book, notable the API which Delphi calls VCL and the IDE. The API is of special interest here because it has been the first pro quality api to utilize full OO the proper way , with well designed objects and carefully mapped class inheritance. Java on the other hand like windows C++ APIs is a huge pile of mess. The same coder designed C# and .NET and used all the ideas he used with Delphi , winforms alone is a large rip off of Delphi's GUI api.

But even with this beauty Microsoft could help itself dropping the ball, so what it did was to completely ignore the cross platform ability of .NET , hence why Java kept the lead. The excuse was mainly the Windows Mobile that Microsoft dreamed of competing with iOS and Android but that dream eventually failed with the spectacular commercial failure of Microsoft smartphones. So Microsoft did the expected thing, accepted defeat and bought the company that already ported .NET to iOS and Android and countless other platforms and named it Mono. The company is called Xamarin.

Fortunately Microsoft seems to learn from its past mistakes and has recently redesigned .NET to better support cross platform and even open sourced it.

Personally I love .NET and I would not mind at all coding on C# and ironpython (.NET variant of python). Mircrosoft definetly has lost interest in C++ anyway , it has seen the rapidly decline of the language of the language and the mass migration to Java. Java may be ugly but it cured of the pain of manual memory management and offered the first pure business orientated API with the best cross platform support. Java also destroyed the myth that a Garbage Collector cannot reach top performance and compete with C++ code. In sort Java is not as popular because of the design of its libraries but is certainly extremely popular for a lot other reasons.

The question is why you even bother with C++ CLI , C++ CLI was created mainly to bridge C++ with C# / .NET languages, is there a reason you prefer it over C# ?

On Sun, Oct 2, 2016 at 2:01 PM CodeDmitry <dimamakhnin@gmail.com> wrote:

To be fair, C++CLI is quite a pleasure to code, it's a very refreshing technology that sits nicely on the barrier of runtime and compiletime, similar to Objective C; eg still has access to unmanaged resources, while still having managed resources in contrast to Java/C# which kinda go one step towards runtime, and ISO C++ which tries to stay within compile time.

Windows Programming isn't quite that bad now with C++CLI, my image is contrived to demonstrate one of my first successful attempts at getting COM to actually do something other than give me compilation errors.

-- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Well first of all what you linked supports my claim that 2/3 of Pharo users are MacOS and Linux users which I based on another survey which pretty much verifies what you linked. Second the vast majorities of libraries out other for any programming language are cross platform so I am willing to bet that we will attract even more users if we emphasize cross platform support instead of libraries that OS exclusive. Of course that implies good support for Windows too. It will be kinda ironic Microsoft to beats us in the ability to be cross platform. Third I already said I fully support the effort to bring COM features to Pharo, the exact wording "By the way I am all for COM for Pharo" leave little to doubt if nothing at all. I would not use nor I would recommend using a OS specific library but there are definitely scenarios where it makes sense to use one and having it around is much better than not having it around. On Sun, Oct 2, 2016 at 6:46 PM Esteban A. Maringolo <emaringolo@gmail.com> wrote:

2016-10-02 10:57 GMT-03:00 Dimitris Chloupis <kilon.alios@gmail.com>:

...

By the way I am all for COM for Pharo, the issue is that 2/3 of our community are MacOS and Linux users , I dont even remember the last time we had a Windows only topic in the mailing list. Modern languages generally avoid using OS specific libraries, the last exceptions be C# and Swift and C# definetly looks like it will be fully cross platform soon enough (it already is because of Mono).

I wouldn't state such affirmations without a proper surveying.

My latest survey related with RDBMS support [1] showed that the users of Windows are on par with the users of MacOS.

I am a Windows user, who runs most of the Pharo images inside Linux VMs not because I don't want to run them in Windows, but because the current support of Windows is somewhat limited.

Having COM support for Pharo in a Windows environment would be a big enabler to a lot of current users of Smalltalk that don't use Pharo.

Esteban A. Maringolo

[1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f640878...

On Sun, Oct 2, 2016 at 8:52 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

@kilon.alios

[1] I like C++/CLI more than C# because it is very refreshing to use a language capable of using managed memory and unmanaged memory.

I am too used to being in languages where garbage collection is forced on you and everything must be done via new or stack types such as Java, most scripting languages; Or using languages where static-types are forced on you and heavily encouraged over dynamic types.

I feel very "free" when I write C++CLI, as it can do everything C# can(although many things are admitably harder), but it can also call C when it feels like it.

[2] If you want to get more users, I hope you are checking the things people are saying about Smalltalk.

In my class last week, the general concensus was that "Smalltalk is dead, why are we studying this useless language".

Personally, I really enjoy the environment, but I feel that the environment would do better from giving existing users a reason to tell their friends about Pharo, and to like the language.

There are many things that relate to this

1. Reasons to be excited about Pharo/Smalltalk - It is a system where you can modify the system within the system. - It has a very simple syntax, which is capable of doing things as powerful as JavaScript. - It is easy to get on Windows(3 minute download self contained)... - It has pretty powerful prototyping means, but it's not quite as powerful as it could be. One way to improve this would be to add a morph editor similar to VB6. Morphs are somewhat scary to new users right now, and I feel they stand a bit further than where AWT/Swing is in terms of difficulty getting started, even if it is not necessarily true.

2. Quality of Life - Blocks the GUI thread in strange scenarios: It's really aggrevating when it does this; when you type in code, the GUI should not freeze! - Make it a bit easier to remove morphs(Pit of least astonishment, shift alt click is not obvious, and morph that consists of many morphs is somewhat hard to select the parent morph, so you have to delete the child morph then shift alt click the same place to select the underlying morph(eg grids). - More themes! - I know you're going to hate me for this but... It's a bit annoying to install Pharo on 64-bit Linux right now... - It is kind-of hard to understand what .image, .changes, and .sources are and the material online isn't very exhaustive on their responsibilities. To date I am not actually sure what purpose .sources serves. - It's too easy to put Pharo into inconsistant state where it harasses you with popups. It should be easier to access the "undo whatever I just did please", whether it is editing of code, or running a code, I am not sure how easy this is but at the moment, it's not as up-front as it could be; It's scary when you do something and your environment starts yelling at you. (Maybe we could use some Toasts instead of Popups?). - Is there a Pharo alternative to JavaScript timeouts?

forking a process with a delay in it? [ <doSomething> (DelayWaitTimeout forSeconds: 2) wait ] fork

That is all I could think of for now, probably not going to help you much but I wanted to give my 1/1000 of a cent.

-- View this message in context: http://forum.world.st/Intro- to-Microsoft-COM-for-Smalltalkers-tp4917738p4917788.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Contribution is something I've been thinking about for quite some time because it's interesting how a lot of software is declared "open" but make it not obvious what you can do to help, or at least participate, or just take a glimpse at the code to see if something stands out. I am a believer that there is a way to structure a project in a way to make it very easy for people with decent experience in broad programming paradigms to jump into looking over your code and propose revisions or question design decisions. That said, I've also been in groups where people only want to write things once and forget it exists and can't handle any criticism and consider any questions asked to them as a waste of time, who will only work on stuff at last moment and won't let anybody help them. The factors I've noticed are: 1. Ease of finding the repositories which you want people to contribute to, and tell them apart from repositories which you don't want people to contribute to, or are irrelevant to the project(often a project is broken down into multiple repositories, and the dependency chain isn't clear). 2. Dependencies: If you ever took a look at a Minix Kernel, you will notice a huge chain of headers including headers including headers, scopes with over 7 variables in them, and nonflat hierarchies which look at multiple include directories, many of which are not even part of the project, eg Minix will look at the system's include directory to decide things rather than figure it out in a standalone way. This means that it is very hard to just take things out of context and understand them without traversing huge dependency chains, this really discourages contribution. 3. Strict coding guidelines: i've seen projects that force you to either use tabs, or only use spaces, or such. These are very harmful to encouraging as many people to participate as possible; we have tools to restructure code you are looking at automatically, but these tools are not very easy to access on all platforms, and need to be configured to your tastes. These tools improve productivity immensely but people need to be told how to use them. 4. Ease of telling "where is the start" "where is the end". Many projects are simply too hard to tell where the start/where the end is, and where the plugins are, etc. Making it clear where the VM start point is, and how the project is structured, how the dependency chain looks like really helps familiarize yourself faster, and lets people jump into contributing faster as they don't feel like they need to learn EVERYTHING before doing anything. ---- My argument is: Let S be the set of all people who are aware of Pharo's existence who have enough programming experience to be relevant to possibly contributing. Let C be the set of all the people in S who have an interest in contributing to Pharo, or are willing to contribute to Pharo if you were to come up to them and ask them to sit next to you and work on it with you. eg they have the time/resources but don't feel like they go out of their way to get started. Let N be the set of all the people in C who are actually contributing or will contribute to Pharo at some point. There exists a way to structure the project under a philosophy which, the closer you come to it, the more set N decreases, that is, if the philosophy is executed perfectly, there are no people who are capable of contributing something relevant, who have not done so or will never do so. I am not quite sure what the exhaustive philosophy is, but I suspect the factors up front play a part in it. -- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Ok. Fine points. Want to contribute? Easy: https://pharo.fogbugz.com/ Even more easy: join the association @ http://association.pharo.org/ Being using it for serious stuff and make money out of it? Join the consortium : http://consortium.pharo.org/ Discover some little interesting gem or way to do things in it? Tweet with #Pharo. https://twitter.com/search?q=%23Pharo (more people should do this actually). Use it whenever you can, it will force you to understand how to do real stuff with it properly. I do hackathons with it. https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-too... I do use it to do things for customers and whoever could benefit. I just crafted a little tool to produce summary tables for a school this week. They were doing this computation by hand or using they somewhat basic Excel skills. Key important thing: no complications to install that on a Windows box: unzip folder, run Pharo. Net result: good karma. I now of no other platform where you can get something you make an easy to integrate part (if not in the core, in a package/configuration). This community is smaller, contributors can actually make a difference. Think about how it makes you feel: valued. Not yet another package in a sea of packages. If I were to listen what other people do, yeah, one day Scala, the next Python, the next Angular(2), React, Node, Electron, Swift, C#, not to mention the Hadoop bestiary ... this is a neverending stream of ever switching tech. It will not stop. [I am using these things for real projects mind you - https://proba-v-mep.esa.int/ is what I am busy with half my weeks]. How does one develop a true solid understanding of the underlying fundamentals? With Pharo you actually can. Can see how parsing works (PetitParser), can see how VM works (read Clement Bera blog and write your little VM thingy), can see how a click become an event and actually craft nifty little tools, look into VM plugins and see how something is done in various major platforms, ...). We are not just *using* what vendors throw at us. We are actually able to go to the next level. The price for that freedom is present. But it gives a better appreciation of the whole picture. You sound like a fine fellow, so, welcome aboard and help us make this thing rock even more. Phil On Sun, Oct 2, 2016 at 10:38 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

Contribution is something I've been thinking about for quite some time because it's interesting how a lot of software is declared "open" but make it not obvious what you can do to help, or at least participate, or just take a glimpse at the code to see if something stands out.

I am a believer that there is a way to structure a project in a way to make it very easy for people with decent experience in broad programming paradigms to jump into looking over your code and propose revisions or question design decisions.

That said, I've also been in groups where people only want to write things once and forget it exists and can't handle any criticism and consider any questions asked to them as a waste of time, who will only work on stuff at last moment and won't let anybody help them.

The factors I've noticed are:

1. Ease of finding the repositories which you want people to contribute to, and tell them apart from repositories which you don't want people to contribute to, or are irrelevant to the project(often a project is broken down into multiple repositories, and the dependency chain isn't clear).

2. Dependencies: If you ever took a look at a Minix Kernel, you will notice a huge chain of headers including headers including headers, scopes with over 7 variables in them, and nonflat hierarchies which look at multiple include directories, many of which are not even part of the project, eg Minix will look at the system's include directory to decide things rather than figure it out in a standalone way. This means that it is very hard to just take things out of context and understand them without traversing huge dependency chains, this really discourages contribution.

3. Strict coding guidelines: i've seen projects that force you to either use tabs, or only use spaces, or such. These are very harmful to encouraging as many people to participate as possible; we have tools to restructure code you are looking at automatically, but these tools are not very easy to access on all platforms, and need to be configured to your tastes. These tools improve productivity immensely but people need to be told how to use them.

4. Ease of telling "where is the start" "where is the end". Many projects are simply too hard to tell where the start/where the end is, and where the plugins are, etc. Making it clear where the VM start point is, and how the project is structured, how the dependency chain looks like really helps familiarize yourself faster, and lets people jump into contributing faster as they don't feel like they need to learn EVERYTHING before doing anything.

----

My argument is: Let S be the set of all people who are aware of Pharo's existence who have enough programming experience to be relevant to possibly contributing.

Let C be the set of all the people in S who have an interest in contributing to Pharo, or are willing to contribute to Pharo if you were to come up to them and ask them to sit next to you and work on it with you. eg they have the time/resources but don't feel like they go out of their way to get started.

Let N be the set of all the people in C who are actually contributing or will contribute to Pharo at some point.

There exists a way to structure the project under a philosophy which, the closer you come to it, the more set N decreases, that is, if the philosophy is executed perfectly, there are no people who are capable of contributing something relevant, who have not done so or will never do so.

I am not quite sure what the exhaustive philosophy is, but I suspect the factors up front play a part in it.

-- View this message in context: http://forum.world.st/Intro- to-Microsoft-COM-for-Smalltalkers-tp4917738p4917793.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Case in point, I am submitting a proposal here: https://devfest.be/blog/posts/cfp/ That's Google tech event here. I proposed to showcase MDL in Pharo along with workshop. Let's see how it goes... Phil On Mon, Oct 3, 2016 at 4:43 PM, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

Hi,

On 02/10/16 17:13, phil@highoctane.be wrote:

[...]

...

Use it whenever you can, it will force you to understand how to do real stuff with it properly.

I do hackathons with it. https://hackernoon.com/hackapo st-how-hackathons-can-be-the-best-learning-tool-under-the- sun-9c97e567e0a5

As complementary to the infrastructure, code standards, libraries and so on, a needed contribution, from the social dynamics perspective, are hachathons and workshops. We're making them regularly here (link at [1], in Spanish), with a critical data/code literacy approach. Last week we have our 5th edition and this week we're going to make an agile 6th edition.

[1] http://mutabit.com/dataweek/

I found the Pharo community very open to contribution. The fast feedback loop [2] is experienced here in a very visible way and most of the time the community is welcoming (with notable few exceptions, "ad hominen" attacks and poor argumentation, but also with a good self-correcting feedback from the broader community).

[2] http://www.slideshare.net/MarcusDenker/perfection-feedback- loops-or-why-worse-is-better-65540840

So is not a perfect place, as any other, but you'll find a way of contributing that is considered worthy and encouraged and even supported with economical resources from Pharo Association / Consorcium from time to time.

Welcome here, you and your contribution ;-),

Offray

On Mon, Oct 3, 2016 at 2:52 AM, CodeDmitry <dimamakhnin@gmail.com> wrote:

@kilon.alios

[1] I like C++/CLI more than C# because it is very refreshing to use a language capable of using managed memory and unmanaged memory.

I am too used to being in languages where garbage collection is forced on you and everything must be done via new or stack types such as Java, most scripting languages; Or using languages where static-types are forced on you and heavily encouraged over dynamic types.

I feel very "free" when I write C++CLI, as it can do everything C# can(although many things are admitably harder), but it can also call C when it feels like it.

[2] If you want to get more users, I hope you are checking the things people are saying about Smalltalk.

In my class last week, the general concensus was that "Smalltalk is dead, why are we studying this useless language".

This article is about Lisp, but the same applies to Smalltalk... http://www.paulgraham.com/avg.html University is not just about spitting you out able to operate the latest fashionable tools, which may change in five years anyway. Its about *stretching* your mind in different directions by exposure to *different* paradigms. Smalltalk's immersive programming within an environment of live and persistent objects is about as different as you can get from the conventional file based programming. If they've not grokked this "blub" aspect of Smalltalk due to short-sighted negative approach then they are missing a learning opportunity. After University, work/life pressures provide less opportunity to learn such different paradigms - so you may be forever blind to them. The only languages worth learning are those that change the way you *think* about programming. As for why Smalltalk didn't hit mainstream yet? It seems more a failure of business strategy than technical fundamentals in a time when the Internet was changing the nature of the world - including programming with free tools and open source collaboration. http://c2.com/cgi/wiki?WhyIsSmalltalkDead

Personally, I really enjoy the environment, but I feel that the environment would do better from giving existing users a reason to tell their friends about Pharo, and to like the language.

There are many things that relate to this

1. Reasons to be excited about Pharo/Smalltalk - It is a system where you can modify the system within the system. - It has a very simple syntax, which is capable of doing things as powerful as JavaScript. - It is easy to get on Windows(3 minute download self contained)... - It has pretty powerful prototyping means, but it's not quite as powerful as it could be. One way to improve this would be to add a morph editor similar to VB6. Morphs are somewhat scary to new users right now, and I feel they stand a bit further than where AWT/Swing is in terms of difficulty getting started, even if it is not necessarily true.

2. Quality of Life - Blocks the GUI thread in strange scenarios: It's really aggrevating when it does this; when you type in code, the GUI should not freeze! - Make it a bit easier to remove morphs(Pit of least astonishment, shift alt click is not obvious, and morph that consists of many morphs is somewhat hard to select the parent morph, so you have to delete the child morph then shift alt click the same place to select the underlying morph(eg grids). - More themes! - I know you're going to hate me for this but... It's a bit annoying to install Pharo on 64-bit Linux right now...

This is a high priority and a 64-bit is imminent.

- It is kind-of hard to understand what .image, .changes, and .sources are and the material online isn't very exhaustive on their responsibilities. To date I am not actually sure what purpose .sources serves.

For each Pharo Release the .changes file that has been running during development is condensed to a static .sources file, so that the Release has an empty .changes files. So only user changes show up in .changes.

- It's too easy to put Pharo into inconsistant state where it harasses you with popups. It should be easier to access the "undo whatever I just did please", whether it is editing of code, or running a code, I am not sure how easy this is but at the moment, it's not as up-front as it could be; It's scary when you do something and your environment starts yelling at you. (Maybe we could use some Toasts instead of Popups?).

With great power comes great responsibility ;) Yes it can be tough as a newcomer when you don't know where the traps are. Something more to help recovery would be useful.

- Is there a Pharo alternative to JavaScript timeouts?

Can you describe Javascript timeouts?

That is all I could think of for now, probably not going to help you much but I wanted to give my 1/1000 of a cent.

Thanks for your feedback. It is good to get a newcomers perspective. Some of these are know issues that we get used to and work around because we balance them off against other "blub" benefits of the environment, which newcomers might not stick around long enough to discover if the entry friction is too high. cheers -ben

of course Pharo has an event queue, we call them announcements. That implies however that you want the code to execute as soon as something else happens. If you don't , fork and delay should be enough. With fork you dont need to wait for othet tasks to finish to execute your code, it will just put it to a thread and execute it concurently. If you want the code to run as soon as other tasks finish then of course you dont use fork. On Mon, Oct 3, 2016 at 10:56 AM CodeDmitry <dimamakhnin@gmail.com> wrote:

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

-- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Hi. 2016-10-03 9:49 GMT+02:00 CodeDmitry <dimamakhnin@gmail.com>:

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

In Pharo we have cheap green threads. You can write this: ["your code". 1 seconds wait.] fork. Also look at project TaskIt https://github.com/sbragagnolo/taskit. It provides many high level scheduling capabilities.

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

Pharo has a single threaded VM, but multiple green threads can run concurrently. The closest to the event loop you are thinking of most likely the Morphic UI Process which you can see using World > Tools > Process Browser. When you execute code from Playground it runs in that Process (note what Smalltalk historically (circa 1970s?) has called a Process is today more commonly know as a Green Thread) If you select Morphic UI Process you will see its call stack on the right, where an interesting method is WorldState>>doOneCycleFor: You can gain some insight by turning on auto-update in the Process Browser, then open a Browser on WorldState>>doOneCycleFor: and put "self haltOnce" at the top, then enable it via... Pharo 5: World > System > Enable halt/inspect once. Pharo 6: World > Debugging > Enable all break/inspect once. You will see in the Process Browser that a new Morphic UI Process is spawned, and the original Morphic UI Process call stack now has #debugProcess at the top and a debug window appears that you can step through. Note, since two UI loops are executing here, the image may lock up, but usually its fine so hey! live on the edge! In #runStepMethodsIn: you'll see "queue := self class deferredUIMessages" for which you enqueue items like this... http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slow... After processing the deferred UI messages, each Morph's #step method is processed by #runLocalStepMethodsIn: refer... http://wiki.squeak.org/squeak/2096 The display is then rendered by #displayWorldSafely: calling... --> #displayWorld --> #displayWorld:submorphs: which then is a lot to trace through, but depending on the graphics back end eventually ends up calling... Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn: or... AthensCanvas>>fullDrawMorph: which ultimately invokes one of many #drawOnAthensCanvas: So, for a regular timed UI animation, you would define your custom morph's #step and #stepTime methods, and for lower level stuff you would fork like Dennis suggests. cheers -ben

On Mon, Oct 3, 2016 at 6:25 PM, Ben Coman <btc@openinworld.com> wrote:

On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <btc@openinworld.com> wrote:

...

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

...

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

Pharo has a single threaded VM, but multiple green threads can run concurrently. The closest to the event loop you are thinking of most likely the Morphic UI Process which you can see using World > Tools > Process Browser. When you execute code from Playground it runs in that Process (note what Smalltalk historically (circa 1970s?) has called a Process is today more commonly know as a Green Thread)

If you select Morphic UI Process you will see its call stack on the right, where an interesting method is WorldState>>doOneCycleFor: You can gain some insight by turning on auto-update in the Process Browser, then open a Browser on WorldState>>doOneCycleFor: and put "self haltOnce" at the top, then enable it via... Pharo 5: World > System > Enable halt/inspect once. Pharo 6: World > Debugging > Enable all break/inspect once.

You will see in the Process Browser that a new Morphic UI Process is spawned, and the original Morphic UI Process call stack now has #debugProcess at the top and a debug window appears that you can step through. Note, since two UI loops are executing here, the image may lock up, but usually its fine so hey! live on the edge!

I meant to ask the list about a bug I hit doing this....

Putting a "self haltOnce" here...

WorldState>>doOneCycleNowFor: aWorld DisplayScreen checkForNewScreenSize. self haltOnce. "process user input events" LastCycleTime := Time millisecondClockValue. self handsDo: [:h | self activeHand: h. h processEvents. self activeHand: nil. ]. self activeHand: self hands first.

A further curiousity occurs to me. With this being executed 20 times a second or more, how can the active hand ever be anything other than the primary hand? Why isn't the active hand stored, all hands cycled through processing events, then the active hand restored?? cheers -ben

aWorld runStepMethods. "there are currently some variations here" self displayWorldSafely: aWorld.

When stepping over "self activeHand: nil." another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil in GLMPagerPanePreviewMorph(Morph)>>delete

self activeHand releaseKeyboardFocus: self; releaseMouseFocus: self.

This can obviously be fixed by wrapping "self activeHand" with an #ifNil: but alternatively I wonder if the "self activeHand: nil" is really needed? It seems redundant since activeHand is set at the top of the loop and immediately after exiting the loop. Eliminating it would reduce the propagation of #ifNil: anti-pattern.

https://pharo.fogbugz.com/default.asp?19169

cheers -ben

...

In #runStepMethodsIn: you'll see "queue := self class deferredUIMessages" for which you enqueue items like this... http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slow...

After processing the deferred UI messages, each Morph's #step method is processed by #runLocalStepMethodsIn: refer... http://wiki.squeak.org/squeak/2096

The display is then rendered by #displayWorldSafely: calling... --> #displayWorld --> #displayWorld:submorphs: which then is a lot to trace through, but depending on the graphics back end eventually ends up calling... Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn: or... AthensCanvas>>fullDrawMorph: which ultimately invokes one of many #drawOnAthensCanvas:

So, for a regular timed UI animation, you would define your custom morph's #step and #stepTime methods, and for lower level stuff you would fork like Dennis suggests.

cheers -ben

There has been some serious refactoring occuring in these specific bowels of the beast. Phil On Mon, Oct 3, 2016 at 1:08 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi Ben.

2016-10-03 12:37 GMT+02:00 Ben Coman <btc@openinworld.com>:

...

A further curiousity occurs to me. With this being executed 20 times a second or more, how can the active hand ever be anything other than the primary hand? Why isn't the active hand stored, all hands cycled through processing events, then the active hand restored??

Previous version of method was also with nil at the end:

self handsDo: [:h | ActiveHand := h. h processEvents. ActiveHand := nil ].

Could you try your test on previous version of Pharo?

Here is some interesting event loop stuff from Tcl. http://wiki.tcl.tk/2567 I wish we had some easy Tk UI building things in Pharo. Spec is okay but not intuitive. As it is the only thing that exposes the myriad of various Morphs we have and shields us (somewhat) from the underlying details, we have to use it, but its explorability is really detrimental to the livecoding side of Pharo. Phil On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman <btc@openinworld.com> wrote:

On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <btc@openinworld.com> wrote:

...

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

...

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ

Pharo has a single threaded VM, but multiple green threads can run concurrently. The closest to the event loop you are thinking of most likely the Morphic UI Process which you can see using World > Tools > Process Browser. When you execute code from Playground it runs in that Process (note what Smalltalk historically (circa 1970s?) has called a Process is today more commonly know as a Green Thread)

If you select Morphic UI Process you will see its call stack on the right, where an interesting method is WorldState>>doOneCycleFor: You can gain some insight by turning on auto-update in the Process Browser, then open a Browser on WorldState>>doOneCycleFor: and put "self haltOnce" at the top, then enable it via... Pharo 5: World > System > Enable halt/inspect once. Pharo 6: World > Debugging > Enable all break/inspect once.

You will see in the Process Browser that a new Morphic UI Process is spawned, and the original Morphic UI Process call stack now has #debugProcess at the top and a debug window appears that you can step through. Note, since two UI loops are executing here, the image may lock up, but usually its fine so hey! live on the edge!

I meant to ask the list about a bug I hit doing this....

Putting a "self haltOnce" here...

WorldState>>doOneCycleNowFor: aWorld DisplayScreen checkForNewScreenSize. self haltOnce. "process user input events" LastCycleTime := Time millisecondClockValue. self handsDo: [:h | self activeHand: h. h processEvents. self activeHand: nil. ]. self activeHand: self hands first. aWorld runStepMethods. "there are currently some variations here" self displayWorldSafely: aWorld.

When stepping over "self activeHand: nil." another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil in GLMPagerPanePreviewMorph(Morph)>>delete

self activeHand releaseKeyboardFocus: self; releaseMouseFocus: self.

This can obviously be fixed by wrapping "self activeHand" with an #ifNil: but alternatively I wonder if the "self activeHand: nil" is really needed? It seems redundant since activeHand is set at the top of the loop and immediately after exiting the loop. Eliminating it would reduce the propagation of #ifNil: anti-pattern.

https://pharo.fogbugz.com/default.asp?19169

cheers -ben

...

In #runStepMethodsIn: you'll see "queue := self class deferredUIMessages" for which you enqueue items like this... http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-

messages-executed-slowly-td3228060.html

...

After processing the deferred UI messages, each Morph's #step method is processed by #runLocalStepMethodsIn: refer... http://wiki.squeak.org/squeak/2096

The display is then rendered by #displayWorldSafely: calling... --> #displayWorld --> #displayWorld:submorphs: which then is a lot to trace through, but depending on the graphics back end eventually ends up calling... Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn: or... AthensCanvas>>fullDrawMorph: which ultimately invokes one of many #drawOnAthensCanvas:

So, for a regular timed UI animation, you would define your custom morph's #step and #stepTime methods, and for lower level stuff you would fork like Dennis suggests.

cheers -ben

Thanks Ben. I can tell you that we want to remove all such activeHand. :) One day it will come. Stef Le 3/10/16 à 12:25, Ben Coman a écrit :

On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <btc@openinworld.com> wrote:

...

On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

...

a JavaScript timeout is a function that takes a block and a period of time, and after this period of time, puts the block at the end of the event queue, to be executed as soon as the runtime is done performing the tasks in front of it.

I am not sure if Pharo has an event queue, so it's a bit harder to do it(since without one you can't ensure only one thing happens at a time, and strange things can happen).

That said, in simplest terms, imagine writing a clock app for Pharo, which updates time every second, in JS this would be done by setting an interval that ticks every 1000ms, and each time places the callback function(block) at the end of the event queue.

Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ Pharo has a single threaded VM, but multiple green threads can run concurrently. The closest to the event loop you are thinking of most likely the Morphic UI Process which you can see using World > Tools > Process Browser. When you execute code from Playground it runs in that Process (note what Smalltalk historically (circa 1970s?) has called a Process is today more commonly know as a Green Thread)

If you select Morphic UI Process you will see its call stack on the right, where an interesting method is WorldState>>doOneCycleFor: You can gain some insight by turning on auto-update in the Process Browser, then open a Browser on WorldState>>doOneCycleFor: and put "self haltOnce" at the top, then enable it via... Pharo 5: World > System > Enable halt/inspect once. Pharo 6: World > Debugging > Enable all break/inspect once.

You will see in the Process Browser that a new Morphic UI Process is spawned, and the original Morphic UI Process call stack now has #debugProcess at the top and a debug window appears that you can step through. Note, since two UI loops are executing here, the image may lock up, but usually its fine so hey! live on the edge!

I meant to ask the list about a bug I hit doing this....

Putting a "self haltOnce" here...

WorldState>>doOneCycleNowFor: aWorld DisplayScreen checkForNewScreenSize. self haltOnce. "process user input events" LastCycleTime := Time millisecondClockValue. self handsDo: [:h | self activeHand: h. h processEvents. self activeHand: nil. ]. self activeHand: self hands first. aWorld runStepMethods. "there are currently some variations here" self displayWorldSafely: aWorld.

When stepping over "self activeHand: nil." another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil in GLMPagerPanePreviewMorph(Morph)>>delete

self activeHand releaseKeyboardFocus: self; releaseMouseFocus: self.

This can obviously be fixed by wrapping "self activeHand" with an #ifNil: but alternatively I wonder if the "self activeHand: nil" is really needed? It seems redundant since activeHand is set at the top of the loop and immediately after exiting the loop. Eliminating it would reduce the propagation of #ifNil: anti-pattern.

https://pharo.fogbugz.com/default.asp?19169

cheers -ben

...

In #runStepMethodsIn: you'll see "queue := self class deferredUIMessages" for which you enqueue items like this... http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slow...

After processing the deferred UI messages, each Morph's #step method is processed by #runLocalStepMethodsIn: refer... http://wiki.squeak.org/squeak/2096

The display is then rendered by #displayWorldSafely: calling... --> #displayWorld --> #displayWorld:submorphs: which then is a lot to trace through, but depending on the graphics back end eventually ends up calling... Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn: or... AthensCanvas>>fullDrawMorph: which ultimately invokes one of many #drawOnAthensCanvas:

So, for a regular timed UI animation, you would define your custom morph's #step and #stepTime methods, and for lower level stuff you would fork like Dennis suggests.

cheers -ben

LOL (in GrowlMorph): is: rect saneWithRespectTo: morphs ^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph bounds intersects: rect]]) not for some reason I find this method name quite amusing :3 Let me guess; 1. "World defer: aBlock." defers the event to be called as soon as possible(not necessarily now). 2. "[Block] fork" is called immediatly, but on a new thread. 3. "<number> <time unit> wait" blocks the current thread for specific time before continuing. Now rearrange it into: [ 10 seconds wait. World defer: [ Transcript show: 'Hello, World!'. ]. ] fork. Into do: aBlock after: nanoTime [ 10 seconds wait. World defer: aBlock. ] fork. -- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

You seem to have answered my question as I was revising it D: -- View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Also, check MorphicUIManager>>#spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess name: 'Morphic UI Process'. UIProcess resume digging into doOneCycle, you'll find: #doOneCycleFor: aWorld "Do one cycle of the interaction loop. This method is called *repeatedly *when the world is running. This is a moderately private method; a better alternative is usually either to wait for events or to check the state of things from #step methods." self interCyclePause: MinCycleLapse. self doOneCycleNowFor: aWorld. The interCyclePause is what make the UI timing alignment proper (notice serverMode) [and some Squeak remnant mention]: interCyclePause: milliSecs "delay enough that the previous cycle plus the amount of delay will equal milliSecs. If the cycle is already expensive, then no delay occurs. However, if the system is idly waiting for interaction from the user, the method will delay for a proportionally long time and cause the overall CPU usage of *Squeak* to be low. If self serverMode returns true then, always do a complete delay of 50ms, independant of my argument. This prevents the freezing problem described in Mantis #6581" | wait wait2 | "*a very long assignment*" wait := self serverMode ifTrue: [ 50 ] ifFalse: [ wait2 := (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifFalse: [ 0 ] ifTrue: [ lastCycleTime + milliSecs - Time millisecondClockValue ]. self flag: 'Issue 14754 - wait2>millisecs is only True for clock rollover. Remove it once DelayScheduler based on microsecondClock - Ben Coman 19.01.2015'. "*<---- maybe we want this #flag: not to be called all the time* " wait2 > milliSecs ifTrue: [ 0 ] ifFalse: [ wait2 ]. ]. wait > 0 ifTrue: [ (Delay forMilliseconds: wait) wait ]. "<------- wait is not #>>wait" lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. Now, yeah, how do get stuff to be painted on the screen? Like this: displayWorld: aWorld submorphs: submorphs "Update this world's display." | deferredUpdateMode handsToDraw allDamage | submorphs do: [:m | m fullBounds]. "force re-layout if needed" self checkIfUpdateNeeded ifFalse: [^ self]. "display is already up-to-date" deferredUpdateMode := self doDeferredUpdatingFor: aWorld. deferredUpdateMode ifFalse: [self assuredCanvas]. canvas roundCornersOf: aWorld during:[ | worldDamageRects handDamageRects | worldDamageRects := self drawWorld: aWorld submorphs: submorphs invalidAreasOn: canvas. "repair world's damage on canvas" "self handsDo:[:h| h noticeDamageRects: worldDamageRects]." handsToDraw := self selectHandsToDrawForDamage: worldDamageRects. handDamageRects := handsToDraw collect: [:h | h savePatchFrom: canvas]. allDamage := worldDamageRects, handDamageRects. handsToDraw reverseDo: [:h | canvas fullDrawMorph: h]. "draw hands onto world canvas" ]. "*make this true to flash damaged areas for testing*" self class debugShowDamage ifTrue: [aWorld flashRects: allDamage color: Color black]. canvas finish. "quickly copy altered rects of canvas to Display:" deferredUpdateMode ifTrue: [self forceDamageToScreen: allDamage] ifFalse: [canvas showAt: aWorld viewBox origin invalidRects: allDamage]. handsToDraw do: [:h | h restoreSavedPatchOn: canvas]. "restore world canvas under hands" Display deferUpdates: false; forceDisplayUpdate. The VM will take care of throwing the bits to the display in various ways. Interesting to look how it is done for Windows, OSX, and Linux. So you have about a full view now. Timing wise, there is also some interaction with the VM occuring elsewhere. Pharo is still polling deep inside. epoll etc isn't there yet, hence the little idle CPU usage when doing nothing. Good luck doing this UI trip with other platforms, not to mention change or instrument it the way you like. Pharo is really cool for this as it helps in learning about a lot of things. Want to do sockets? Do the high level stuff in Pharo and dig in the VM to see how it is done down under for a set of platforms. Enjoy. Phil On Mon, Oct 3, 2016 at 8:02 PM, phil@highoctane.be <phil@highoctane.be> wrote:

On Mon, Oct 3, 2016 at 6:47 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

...

LOL (in GrowlMorph): is: rect saneWithRespectTo: morphs

^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph bounds intersects: rect]]) not

for some reason I find this method name quite amusing :3

There are interesting things in there indeed. "Intention revealing" enough?

...

Let me guess;

1. "World defer: aBlock." defers the event to be called as soon as possible(not necessarily now).

Actually this works for any Morph in 5.0

Morph>>#defer: aValuable "aValuable will be executed in the next UI rendering cycle" self owner ifNotNil: [ self owner defer: aValuable] ifNil: [ UIManager default defer: aValuable ]

UIManager (MorphicUIManager) will do this at one point (track implementers 'til class side in WorldState)

defer: aValuable "aValuable will be executed in the next UI rendering cycle" self addDeferredUIMessage: aValuable.

This will stick it in a queue:

deferredUIMessages

^DeferredUIMessages ifNil: [DeferredUIMessages := WaitfreeQueue new].

and then, there is interesting black magic going on

runStepMethodsIn: aWorld "Perform periodic activity inbetween event cycles" | queue nextInQueue| "If available dispatch some deferred UI Message" queue := self class deferredUIMessages.

[(nextInQueue := queue nextOrNil) isNil] "<<---------------- here all is happening -------" whileFalse: [ nextInQueue value].

self runLocalStepMethodsIn: aWorld. "<<------------ step methods -----------------"

"The multi-threaded global Transcript needs to be updated periodically and synchronously with the UI." Transcript stepGlobal. "<<------------ and *this* is some black magic for Transcript ----"

Fun thing:

stepGlobal " The superclass method Model>>step indicates a convention that might be used to interoperate synchronously with the UI-thread. However when multiple Transcript windows are open, their PluggableTextMorphs share a single instance, from the global Transcript. To avoid potential trouble, this method should not be named #step. As well, we need this method to execute even when no Transcript windows are open, so the stream continues to be reset periodically, otherwise it would grow indefinitely. So this method is invoked from WorldState>>runStepMethodsIn:. "

"Next three lines required temporarily to initialize instance variables added to existing instance" deferredClear ifNil: [ deferredClear := false ]. deferredEndEntry ifNil: [ deferredEndEntry := false ]. stepContents ifNil: [ stepContents := '' ]. deferredClear ifTrue: [ deferredClear := false. stepContents := ''. self changed: #clearText. ]. deferredEndEntry ifTrue: [ deferredEndEntry := false. self critical: [ stepContents := stream contents. stream resetContents. ]. self changed: #appendEntry. ].

Just in case one was wondering how Transcript clear actually works, check this:

clear " Clear all characters by resetting the stream and voiding any previously flagged deferredEndEntry. Redisplays the view by signalling for #step to send #changed: . " self critical: [ deferredClear := true. "<------- magic! -------" deferredEndEntry := false. "<------- more magic!--------" stream reset ]

Good luck to infer that from scratch.

...

2. "[Block] fork" is called immediatly, but on a new thread.

Yeah, use forkNamed: aString if you actually want to track the thing easily in the Process Browser.

...

3. "<number> <time unit> wait" blocks the current thread for specific time before continuing.

Right.

...

Now rearrange it into:

[ 10 seconds wait. World defer: [ Transcript show: 'Hello, World!'. ]. ] fork.

Into

do: aBlock after: nanoTime [ 10 seconds wait. "<------- you need to say something like nanoTime asNanoSeconds wait. But careful as Delay works up to milliseconds I think, so 5 asNanoseconds asSeconds will just be zero" World defer: aBlock. "<-- OK, World is a WorldMorph, wich extends PasteUpMorph, the old World class in Pharo 3.x" ] fork.

I guess that all of this shows that there is some flexibility in Pharo

async.

Check the Generator class for some brain twisting with fork.

Run

Generator examplePrimes.

for a start.

Phil

...

-- View this message in context: http://forum.world.st/Intro-to -Microsoft-COM-for-Smalltalkers-tp4917738p4917913.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

+1 We want to support Windows! But ... 64 bits, FFI++, ARM ... well you know. Gimme 10 Millions or just one million and the situation will be really different. Stef

...

By the way I am all for COM for Pharo, the issue is that 2/3 of our community are MacOS and Linux users , I dont even remember the last time we had a Windows only topic in the mailing list. Modern languages generally avoid using OS specific libraries, the last exceptions be C# and Swift and C# definetly looks like it will be fully cross platform soon enough (it already is because of Mono). I wouldn't state such affirmations without a proper surveying.

My latest survey related with RDBMS support [1] showed that the users of Windows are on par with the users of MacOS.

I am a Windows user, who runs most of the Pharo images inside Linux VMs not because I don't want to run them in Windows, but because the current support of Windows is somewhat limited.

Having COM support for Pharo in a Windows environment would be a big enabler to a lot of current users of Smalltalk that don't use Pharo.

Esteban A. Maringolo

[1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f640878...