- Pharo-users - lists.pharo.org

Re: [Pharo-users] P3 and concurrenty

by Sven Van Caekenberghe

Hi Petter, > On 9 Feb 2020, at 17:27, Petter Egesund <petter.egesund(a)gmail.com> wrote: > > Hi Sven and thanks for answering! > > I use Teapot with one common sql-connecton, not one for each user session. At startup I create several sql statements and these does not seem to be usable from different Teapot request at the same time. It is useable, but not concurrently. > I could create one connection pr. session and then close the database connection when the user leaves, but then I also would need to create all the prepared sql-statements for each session, which does not sound right to me? Yes and no, see further. > It seems I have will have to look into the other solution, and see if I can use some mutex stuff to avoid several tasks acessessing the same resources at the same time. Yes, follow the pointer that I gave you, it is not hard. > Creating a pool sounds like the right solution to me now - any meaning about this? Yes, you could create a connection pool. But that is harder than it sounds: what is the minimum size, the maximum size, what do you do when you go over it, how do you make sure that a resource (connection) is clean when returning it to the pool (given authentication, possible errors), ... I don't know what you are doing, but I think you focus too much on performance issues. I would first try to get the code correct and worry about performance later on. Running P3ClientTest new runBenchmark1Bench. on my machine gives me a BenchmarkResult(67 iterations in 5 seconds 57 milliseconds. 13.249 per second). This is a query that returns 10.000 records with 5 columns. It is reusing the same client/connection for all iterations. If I modify this slightly to use a new client/connection each time, like this [ (P3Client url: 'psql://sven@localhost') query: 'SELECT * FROM benchmark1'; close ] benchFor: 5 seconds I get a BenchmarkResult(65 iterations in 5 seconds 34 milliseconds. 12.912 per second) which almost as fast. Of course, for smaller queries, the connect/disconnect overhead will be more significant. And note that this is not using prepared statements. So I would start by opening/closing a connection each time you need it. HTH, Sven > Petter > > > On Sun, Feb 9, 2020 at 4:52 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Petter, > > [ CC-ing the Pharo Users list ] > > P3Client is not built/designed to be used by multiple processes concurrently. Each database connection is represented by an instance of P3Client and holds some state both at the client as well as at the server side. > > Typically, in a multi user server application, each connection should have its own P3Client / psql connection. For example, in Seaside, a custom WASession subclass gives each session/user its own p3 connection/client. > > Is that what you are doing ? > > If not, you could wrap your db accessing code so that mutual exclusion is provided. For example, you can have a look at AbstractCache #beThreadSafe and #critical: > > That will then serialise requests and possibly block one onto the other. > > HTH, > > Sven > > PS: another thing to take care of if closing your sql connections when the session is no longer needed. > > PS: Zinc HTTP does also provide a session mechanism (ZnServerSession[Manager]) but these work with cookies and typically won't help with a REST access pattern. > > > On 9 Feb 2020, at 14:21, Petter Egesund <petter.egesund(a)gmail.com> wrote: > > > > Hi Sven > > > > We are using Pharo as our backend in a project and we have run into a problem with P3. > > > > The problem seems to be connected to compiled sql statements and concurrency. > > > > We keep getting this error: Bindcomplete message expected > > > > Problem seems to be easy to reproduce: > > > > 1) Compile any sql statement > > 2) Use this statement in a query twice (!) in a teapot endpoint > > > > The run some concurrent queries, like "curl http://localhost:8080/endpoint & curl http://localhost:8080/endpoint.." (add several curls after here). > > > > One could also use ex. siege (https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html) for easy reproducing. > > > > If we chain the curls after each other, like "curl http://localhost:8080/endpoint && https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html && https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html.." it seems to work fine, so doing the request sequentially seem to work fine. > > > > My conclusion is that this must be connected to how teapot handles concurrency in companion with the compiled statements? > > > > Any clues on this one? We are on Pharo 8.0 with latest version of P3, PG 9.x) > > > > Best regards > > > > Petter Egesund (I wrote the heysql-package based on P3) >

Feb. 9, 2020

Re: [Pharo-users] Dictionary removeKey: very low

by Richard O'Keefe

It's a problem with the traditional Smalltalk-80 implementation of Dictionaries. Using my compiler and library, 1311 usec to build 498 usec to delete (1..10000) 1318 usec to build 472 usec to delete (10000..1) (The time difference between building and deleting is mostly #printString.) There is no defect in the Pharo compiler here, it's the hash table design which is basically flawed if you want delete entries. My library uses separate chaining (https://en.wikipedia.org/wiki/Hash_table#Separate_chaining) which makes deletion simple and fast and allows 'null' keys. Pharo uses open addressing, which makes deletion much harder. It doesn't seem to improve retrieval performance either. On Mon, 3 Feb 2020 at 23:18, LABORDE Pierre <pierre.laborde(a)fr.thalesgroup.com> wrote: > > Hi all, > > > > I have a problem with Dictionaries : > > > > dic := Dictionary new: 10000. > > > > 1 to: 10000 do:[ :i | > > dic at: i put: i printString. > > ]. > > > > 1 to: 10000 do:[ :i | > > dic removeKey: i. > > ] > > > > Removing each keys is very slooow, time execution difference between add and remove is crazy. > > Any idea for fix that ? Can I use another Dictionary implementation or settings ? > > > > Thanks. > > > > Pierre > >

Feb. 9, 2020

Re: [Pharo-users] P3 and concurrenty

by Petter Egesund

Hi Sven and thanks for answering! I use Teapot with one common sql-connecton, not one for each user session. At startup I create several sql statements and these does not seem to be usable from different Teapot request at the same time. I could create one connection pr. session and then close the database connection when the user leaves, but then I also would need to create all the prepared sql-statements for each session, which does not sound right to me? It seems I have will have to look into the other solution, and see if I can use some mutex stuff to avoid several tasks acessessing the same resources at the same time,. Creating a pool sounds like the right solution to me now - any meaning about this? Petter On Sun, Feb 9, 2020 at 4:52 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Petter, > > [ CC-ing the Pharo Users list ] > > P3Client is not built/designed to be used by multiple processes > concurrently. Each database connection is represented by an instance of > P3Client and holds some state both at the client as well as at the server > side. > > Typically, in a multi user server application, each connection should have > its own P3Client / psql connection. For example, in Seaside, a custom > WASession subclass gives each session/user its own p3 connection/client. > > Is that what you are doing ? > > If not, you could wrap your db accessing code so that mutual exclusion is > provided. For example, you can have a look at AbstractCache #beThreadSafe > and #critical: > > That will then serialise requests and possibly block one onto the other. > > HTH, > > Sven > > PS: another thing to take care of if closing your sql connections when the > session is no longer needed. > > PS: Zinc HTTP does also provide a session mechanism > (ZnServerSession[Manager]) but these work with cookies and typically won't > help with a REST access pattern. > > > On 9 Feb 2020, at 14:21, Petter Egesund <petter.egesund(a)gmail.com> > wrote: > > > > Hi Sven > > > > We are using Pharo as our backend in a project and we have run into a > problem with P3. > > > > The problem seems to be connected to compiled sql statements and > concurrency. > > > > We keep getting this error: Bindcomplete message expected > > > > Problem seems to be easy to reproduce: > > > > 1) Compile any sql statement > > 2) Use this statement in a query twice (!) in a teapot endpoint > > > > The run some concurrent queries, like "curl > http://localhost:8080/endpoint & curl http://localhost:8080/endpoint.." > (add several curls after here). > > > > One could also use ex. siege ( > https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html) for easy > reproducing. > > > > If we chain the curls after each other, like "curl > http://localhost:8080/endpoint && > https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html && > https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html.." it seems > to work fine, so doing the request sequentially seem to work fine. > > > > My conclusion is that this must be connected to how teapot handles > concurrency in companion with the compiled statements? > > > > Any clues on this one? We are on Pharo 8.0 with latest version of P3, PG > 9.x) > > > > Best regards > > > > Petter Egesund (I wrote the heysql-package based on P3) > >

Feb. 9, 2020

Re: [Pharo-users] P3 and concurrenty

by Sven Van Caekenberghe

Hi Petter, [ CC-ing the Pharo Users list ] P3Client is not built/designed to be used by multiple processes concurrently. Each database connection is represented by an instance of P3Client and holds some state both at the client as well as at the server side. Typically, in a multi user server application, each connection should have its own P3Client / psql connection. For example, in Seaside, a custom WASession subclass gives each session/user its own p3 connection/client. Is that what you are doing ? If not, you could wrap your db accessing code so that mutual exclusion is provided. For example, you can have a look at AbstractCache #beThreadSafe and #critical: That will then serialise requests and possibly block one onto the other. HTH, Sven PS: another thing to take care of if closing your sql connections when the session is no longer needed. PS: Zinc HTTP does also provide a session mechanism (ZnServerSession[Manager]) but these work with cookies and typically won't help with a REST access pattern. > On 9 Feb 2020, at 14:21, Petter Egesund <petter.egesund(a)gmail.com> wrote: > > Hi Sven > > We are using Pharo as our backend in a project and we have run into a problem with P3. > > The problem seems to be connected to compiled sql statements and concurrency. > > We keep getting this error: Bindcomplete message expected > > Problem seems to be easy to reproduce: > > 1) Compile any sql statement > 2) Use this statement in a query twice (!) in a teapot endpoint > > The run some concurrent queries, like "curl http://localhost:8080/endpoint & curl http://localhost:8080/endpoint.." (add several curls after here). > > One could also use ex. siege (https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html) for easy reproducing. > > If we chain the curls after each other, like "curl http://localhost:8080/endpoint && https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html && https://manpages.ubuntu.com/manpages/trusty/man1/siege.1.html.." it seems to work fine, so doing the request sequentially seem to work fine. > > My conclusion is that this must be connected to how teapot handles concurrency in companion with the compiled statements? > > Any clues on this one? We are on Pharo 8.0 with latest version of P3, PG 9.x) > > Best regards > > Petter Egesund (I wrote the heysql-package based on P3)

Feb. 9, 2020

Voluntarily cancelling requests ("applying an expiration date")

by Holger Freyther

tl;dr: I am searching for a pattern (later code) to apply expiration to operations. Introduction: One nice aspect of Mongodb is that it has built-in data distribution[1] and configurable retention[2]. The upstream project has a document called "Server Discovery and Monitoring (SDAM)", defining how a client should behave. Martin Dias is currently implementing SDAM in MongoTalk/Voyage and I took it on a test drive. Behavior: My software stack is using Zinc, Zinc-REST, Voyage and Mongo. When a new REST requests arrives I am using Voyage (e.g. >>#selectOne:) which will use MongoTalk. The MongoTalk code needs to select the right server. It's currently done by waiting for a result. Next I started to simulate database outages. The rest clients retried when not receiving a result within two seconds (no back-off/jitter). What happened was roughly the following: [ 1.) ZnServer accepts a new connection 2.) MongoTalk waits for a server longer than 2s "nothing.. the above waits..." ] repeat. Problem: What happened next surprised me. I expected to have a bad time when the database recovers and all the stale (remember the REST clients already gave up and closed the socket) requests will be answered. Instead my image crashed early in my test as the ExternalSemaphoreTable was full. Let's focus on the timeout behavior and discuss the existence of the ExternalSemaphoreTable and the number of entries separately at a different time. To me the two main problems I see are: 1.) Lack of back-pressure for ZnManagingMultiThreadedServer 2.) Disconnect of time between the Application Layer handling REST is allowed to take and down the stack how long MongoTalk may sleep and wait for a server. The first item is difficult. Even answering HTTP 500 when we are out of space in the ExternalSemaphore is difficult... Let's ignore this for now as well. What I look for: 1.) Voluntarily Timeout Inside my Application code I would like to tag an operation with a timeout. This means everything that is done should complete within X seconds. It can be used on a voluntarily basis. >>#lookupPerson "We expect all database operations to complete within two seconds" person := ComputeContext current withTimeout: 2 seconds during: [ repository selectOne: Person where: [:each name | ...], ]. MongoTalk>>stuff "See if the outer context timeout has expired and signal. E.g. before writing something into the socket to keep consistency." ComputeContext current checkExpired. MongoTalk>>other "Sleep for up to the remaining time out (someSemaphore waitTimeoutContext: ComputeContext current) ifFalse: [ SomethingExpired signal. ] 2.) Cancellation More difficult to write in pseudo code (without TaskIt?). In my above case we are waiting for the database to be ready while the client already closed the file descriptor. Now we are not able to see this until much later. The idea is that in addition to the timeout we can pass a block that is called when an operation should be cancelled and the ComputeContext can be checked if something has been cancelled? The above takes inspiration from Go's context package[3]. In Go the context should be passed as parameter but we could make it a Process variable? Question: How do you handle this in your systems? Is this something we can consider for Pharo9? thanks holger [1] It has the concept of "replicationSet" and works by having a primary, secondary and arbiters running. [2] For every write one can configure if the write should succeed immediately (before it is even on disk) or when it has been written to multiple stores (e.g. majority, US and EMEA) [3] https://golang.org/pkg/context/

Feb. 9, 2020

Re: [Pharo-users] The results are in!

by horrido

Now, who's telling lies? I have never "demanded" money for the competition. I've asked for donations through Kickstarter and GoFundMe. I didn't demand anything from LabWare; they were so impressed with my campaign, they offered to support it. Your characterization of me is inaccurate and unfair and downright insulting. I really don't understand where your vitriol is coming from. I have never "blamed" anybody for not donating. People are free to donate or not; I understand that and it's fine. Your characterization of my social media posts as "void articles" is also very insulting. As I said in another post, you don't seem to understand what marketing is all about. To you, anything that isn't technical information nor source code is void and vacuous. I don't "reject" feedback. I listen to it and if it makes sense, I act on it. Do all your feedback make sense? If I don't believe it makes sense, am I "rejecting" it? You seem to think that I should accept your feedback without question. Why should I? Who are you? You say I've been "spitting on every other programming language." It's fair game to compare Smalltalk with other languages. Am I "spitting" when I point out the weaknesses of other languages? Why are those languages off limits? Your use of loaded terms like "messianic" and "demand" and "blame" and "reject" shows that you are strongly biased against me. I don't know what I did to deserve your disdain, but I won't stand for it. I have my dignity and my grace. You, on the other hand, have no honour. And just for the record, many people appreciate my effort and support it. Does it please everybody? Of course not, nor should it. So if some of you are impatient with me, what am I supposed to do with that? Pavel Krivanek-3 wrote > so 8. 2. 2020 v 23:58 odesÃlatel Benoit St-Jean via Pharo-users < > pharo-users@.pharo >> napsal: > >> I guess I have to re-ask again since nobody answered my question from >> this week... >> >> Where can we post Pharo >> questions/remarks/thoughts/you-might-want-to-have-a-look-at-this-cool-idea/whatever >> >> (or anything that could be of any interest to Pharoers) ? >> >> MAYBE we need another list... >> >> This is getting ridiculous! The guy spends energy, time, effort and is >> able to gather 13K in prizes and puts Pharo to the forefront with this >> cool contest in schools, makes a lot of youngsters learn & use Pharo for >> their projects, puts up a website, makes videos, writes blog posts, >> PROMOTES Pharo and he gets slapped for posting here ?!?! WTF ??? >> > > You need to see the whole story. This guy with a messianic syndrome > started > his aggressive campaign by spitting on every other programming language > and > he is constantly spamming the social media by void articles that are often > full of lies while showing whole community in a very bad light of fanatic > fools. He (alone) came with the idea of the competition and started to > demand money for it. Then he started to blame anyone who didn't want to > provide money to him. He is constantly rejecting any critique and feedback > so do not be surprised that otherwise very friendly people are losing > their patience. > > -- Pavel > > >> >> Where should he post? Where should I post ? >> >> On 2020-02-08 17:35, Guillermo Polito wrote: >> > Hi Richard, >> > >> > Iâd like to invite you to refrain yourself from posting such off-topic >> > messages in the future. >> > >> -- >> ----------------- >> BenoÃ®t St-Jean >> Yahoo! Messenger: bstjean >> Twitter: @BenLeChialeux >> Pinterest: benoitstjean >> Instagram: Chef_Benito >> IRC: lamneth >> GitHub: bstjean >> Blogue: endormitoire.wordpress.com >> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 9, 2020

Re: [Pharo-users] The results are in!

by horrido

Exaggeration is not a lie, especially in the context of /marketing/. We've all seen marketing campaigns on television, in social media and magazines. They all contain exaggerations and half-truths. You don't seem to understand what marketing is all about. Pavel Krivanek-3 wrote > so 8. 2. 2020 v 23:33 odesÃlatel horrido < > horrido.hobbies@ > > napsal: > >> So this forum is only for Pharo newcomers who have questions? Seems >> rather >> limiting. >> >> When I join other language forums, I look for information about the >> language >> I'm investigating as a newcomer. This can include the language's >> capabilities, limitations, real-world usage, new tools, philosophical >> basis, >> and so on. General information across a broad spectrum of topics. >> >> And, yes, even trivia and factoids that I might find interesting. I >> appreciate that you don't find this interesting, but other forum visitors >> may. >> >> If the Pharo users forum wants to, it could do something as draconian as >> StackOverflow does: put a tight leash on submitted questions and boot out >> everybody who doesn't comply. This is one reason I don't go to >> StackOverflow >> very often â they aren't welcoming to people who just want to learn >> general >> things. >> >> I've told my readers that the Pharo users forum is welcoming. Please >> don't >> make a liar out of me. >> > > We do not need to make a liar out of you. See your old e-mails: > > > > > > > > *So, is Pharo being used to fight Ebola? Not exactly, but who cares? > I'mtrying to change people's perception. I'm trying to *move* them. If I > haveto exaggerate, I will do so.Has everybody heard of Smalltalk? Of > course > not. And it doesn't matter. I'mtaking /literary licence/. As a writer and > a > marketer, I am allowed to dothis.* > > -- Pavel > > Guillermo Polito wrote >> > Hi Richard, >> > >> > Iâd like to invite you to refrain yourself from posting such off-topic >> > messages in the future. >> > >> > This list is for people to *ask* questions about Pharo. Not to diffuse >> any >> > kind of propaganda (pharo related or not). >> > Youâre not asking a question about Pharo, nor answering a question >> about >> > Pharo. >> > So I personally find all these emails off-topic and uninteresting. >> > >> > I have the feeling this list has been lately flooded with such >> off-topic >> > messages. >> > And this only chases off this list people really interested about the >> main >> > topic of the list (like me). >> > >> > Maybe this shows this competition / PR campaign youâre running needs >> > another channel? >> > I know you donât agree, but I invite you to read here the **purpose** >> of >> > this list, just for respect to people subscribed to it: >> > https://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org >> > < >> https://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org> >> > >> > Thanks for your comprehension, >> > Guille >> > >> >> El 8 feb 2020, a las 19:12, Richard Kenneth Eng < >> >> > horrido.hobbies@ >> >> > > escribiÃ³: >> >> >> >> Round 1 â #1 Leading Team: https://youtu.be/QWHeN5WXfBQ >> >> <https://youtu.be/QWHeN5WXfBQ> >> >> >> >> I'm actually quite amazed by their effort. They surpassed my >> >> expectations. >> >> >> >> At the risk of sounding immodest, I think this is a terrific way to >> >> promote Smalltalk (Pharo). I think the video is an absolute blast. >> >> >> >> Richard >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 9, 2020

Re: [Pharo-users] About "it's not pharo but smalltalk"

by Trygve Reenskaug

+10 Ted, I have recently completed a conceptual model with tools for a new way of programming for novices. It works under Squeak version 3.10.2 and it is tempting to port it to the current version of Pharo to make it generally available. This will take time, and the port will probably be outdated and useless by the time it's finished. I'm 90, so the temptation is resisted and story ends here. Best --Trygve On 08.02.2020 18:02, TedVanGaalen wrote: > Hi Ben > Maybe you misunderstood what I meant. > I was thinking of Pharo-backward-compatibility. > not Smalltalk-backward-compatibility > > I am only suggesting that Pharo should be downward compatible > (that is, within Pharo's scope only). > meaning that everything built wit Pharo version X > should load and run in Pharo pharo version X + n > without any changes. > > This means that a package/app running OK in Pharo 8, > should work without any changes whatsoever > in, say, Pharo 12, ca 2 years later. and even beyond that, > preferably many Pharo releases later! > > Therefore, any extension/improvement of Pharo itself should be done > on top of that, not by replacing/deprecating existing classes. > As not to break downward compatibility. > > (looking at the basic underlying system classes, it looks > like this has already been done that way in most cases, > simply because Smalltalk is a hierarchical rooted object system, > which means that changing the deeper is very hard because > it (could) tears up the very fabric of Smalltalk/Pharo itself, > right?) > > > If one reads through this Pharo user forum, and also many other > Smalltalk forums, you can read about many cases of packages that > no longer will work after yet another version of Pharo is released. > This is unacceptable: new Pharo releases should not break those > packages. > > read again: >> Downward compatibility prevents people >> from have tediously edit and test their packages >> again and again each time some have >> the "brilliant" idea to deprecate stuff. > Let's assume for a moment that I want (currently i don't) > to create a package/application, taking many months of my precious time. > After a long time, my hard work is finally completed and tested: wow, the > big dragon flies! > > However, yet another year later, it no longer loads and I have to spend a > considerable amount of time re-editing and testing my package to get > it working correctly again, let alone thereby considering the delicate > interaction > with other third party packages that -guess what?- > are dealing with similar release breaking problems at the same time. > > Unnecessary work, repeating itself with almost every new version of Pharo. > > Realizing that this is an almost eternal trap, this suffices to deter me > from even > starting to create such a package! Thus trying to avoid a very tedious > and iterating process of repairing things that once were perfectly OK. > > Somehow many don't seem get this: > Too academic? making some sort of hobby out of their work. > without realizing real-world situations in a though production/industrial > environment. In combination with the lack of standardization of Smalltalk, > this is probably one the reasons the installed base of Smalltalk > (and Pharo based apps) is very small. > > If one doesn't understand this, one should ask themselves why the heck > they are software developers in the first place. > > On IBM mainframes I can still load and recompile unchanged COBOL source > files > from ca. 1974 and they'll run flawlessly: more than 40 years later. > (btw your bank account runs on mainframes, probably in COBOL btw.) > > Of course it is a splendid idea to improve Pharo, > seeing how Pharo is now, great to work with. > However, this should be done in such a way that > downward compatibility is guaranteed. > > > > IMHO, Regards > TedvG. > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 468 58 625

Feb. 9, 2020

The expanding Pharo ecosystem

by Sven Van Caekenberghe

Hi, Let's take a moment to contemplate on the breath and the depth of the expanding Pharo ecosystem. So much is happening that it is very hard to keep track, let alone look at everything or try it out. Marcus' excellent curated Pharo Newsletter is one place to see this. Take the February 2020 list of New/Updated Libraries and Frameworks at the end: https://mailchi.mp/pharo/pharo-newsletter-february-2020 This is one of the longest enumerations I have seen so far. The great thing is that it is like that almost every month. Check out the archive: https://us11.campaign-archive.com/home/?u=6f667565c2569234585a7be77&id=0486… Of course, GitHub is also a good way to see this happening. The main entry being: https://github.com/pharo-project/ Which contains several overviews: https://github.com/pharo-project/PharoMap https://github.com/pharo-open-documentation/awesome-pharo Topic tags automatically organise some projects: https://github.com/topics/pharo https://github.com/topics/pharo-smalltalk What all this comes down to is that Pharo has many recently developed, actively maintained options to get your job done: to model your domain, to build your user interface, to talk to other systems, to speak other protocols, to interface with the world, to deploy and to deliver your applications. Similarly, Pavel recently did a very good job at the describing why Pharo itself is so great: https://github.com/pavel-krivanek/pharoMaterials/blob/master/features/Pharo… So thanks to all of you for helping to make Pharo into what it is. Thanks to our users: for your questions, you're feedback, your bug reports. Thanks to those helping out others on the mailing lists. Thanks to everyone who ever blogged or otherwise wrote about their experiences with Pharo. Thanks to the contributors involved in constantly improving Pharo with Pull Requests, to those working hard to maintain the process and the machinery behind the development process. Thanks to all the developers producing and maintaining the many libraries and frameworks that help us in our day to day work. Thanks to those writing documentation. Thank you. Sven PS: This is already a long email, but I know that I forgot many important points, feel free to add them in reply. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Feb. 9, 2020

Re: [Pharo-users] The results are in!

by Pavel Krivanek

so 8. 2. 2020 v 23:58 odesÃlatel Benoit St-Jean via Pharo-users < pharo-users(a)lists.pharo.org> napsal: > I guess I have to re-ask again since nobody answered my question from > this week... > > Where can we post Pharo > questions/remarks/thoughts/you-might-want-to-have-a-look-at-this-cool-idea/whatever > > (or anything that could be of any interest to Pharoers) ? > > MAYBE we need another list... > > This is getting ridiculous! The guy spends energy, time, effort and is > able to gather 13K in prizes and puts Pharo to the forefront with this > cool contest in schools, makes a lot of youngsters learn & use Pharo for > their projects, puts up a website, makes videos, writes blog posts, > PROMOTES Pharo and he gets slapped for posting here ?!?! WTF ??? > You need to see the whole story. This guy with a messianic syndrome started his aggressive campaign by spitting on every other programming language and he is constantly spamming the social media by void articles that are often full of lies while showing whole community in a very bad light of fanatic fools. He (alone) came with the idea of the competition and started to demand money for it. Then he started to blame anyone who didn't want to provide money to him. He is constantly rejecting any critique and feedback so do not be surprised that otherwise very friendly people are losing their patience. -- Pavel > > Where should he post? Where should I post ? > > On 2020-02-08 17:35, Guillermo Polito wrote: > > Hi Richard, > > > > Iâd like to invite you to refrain yourself from posting such off-topic > > messages in the future. > > > -- > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > GitHub: bstjean > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > >

Feb. 9, 2020