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

Re: [Pharo-users] Intermediate-Level Tutorials for Pharo

by tbrunz

Hi Offray, Just wanted to let you know that I enjoyed your several responses, and that I'm working on following-up to them. But first I wanted to look at all your links and make as thoughtful a reply as you have, and that takes a while... I think what you've been working on could be a good entry point for some groups where I work, so I do want to learn more. Cheers! -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 11, 2020

Re: [Pharo-users] [ANN] Smalltalk's Successor

by Offray Vladimir Luna CÃ¡rdenas

Hi, On the issue of families of technologies (Lisp and Linux), I see that the article's conclusion doesn't work well in the languages front, as it does on the operative systems one. If you replace the title with Lisp's successor or Linux's successor, the articles conclusion changes, because of the way families of Linux distributions and Lips variants evolve. So you can say that because the diversity of Linux distributions, we don't need (yet) a Linux's successor, while you can say that, because of the diversity of Lisp languages, we already have in fact several Lisp's successors (Racket, Clojure and so on), all of them recognizing their Lisp lineage, but trying to improve and evolve on specific fields (By the way a worthy mention on your list would be Cuis Smalltalk). I see that your articles tend to reiterate the same points time and again about Smalltalk (historicity, simplicity, agility, proven record), which can be fine for a new comer to it, but gets old for the people who is actually engaging with reading you. Blog title changes, addressed a particular point and comes back to the repeated arguments in favor of Smalltalk and then it retakes the starting point with a conclusion. Maybe you could create a single page where you can point your readers, with companion images, videos and notes and just mention briefly the favorable points of Smalltalk for a blog newcomer with a link to your reiterated detailed arguments. With reiteration covered, you may be willing to consider some blind spots which are present (and of course are part of any writing process as they represent a point of view). I know that popularity is the main motive behind the Smalltalk Renaissance efforts, but addressing the blind spots in the search for popularity, could be useful to consider: how popular is popular enough? In a world which values popularity so much (particularly in places of the Global North) which are the disadvantages of popularity? Can a community have the "proper size" to move quickly enough and have good support and funding? Which business and needs are well served disregarding of choosing popular technologies? Just as a thought experiment, as the ones you ask to your non Smalltalk readers to consider options beyond the ones they persue, If popularity is not the best place to focus effort, which could be a good place to do it? Thanks for the conversation, Offray On 10/08/20 8:07 p.Â m., horrido wrote: > It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/ > of languages, portability is a genuine issue. > > There's no getting around this dichotomy. You can have either a flexibility > of choice or the tyranny of one standard, but not both. > > The decision is a fact of life that we face frequently. You can have either > the flexibility of dynamic typing or the safety of static typing, but not > both. You can have either the natural modelling of the real world due to > state mutation or the mathematical safety of immutability, but not both. You > can have either the portability of a virtual machine or the > close-to-the-metal performance of native code generation, but not both (JIT > compilation notwithstanding). > > Life is about choices. There will always be a place for different > technologies. Smalltalk will not always be the ideal choice. That's why > there are five entirely different languages that dominate our industry > (Python, JavaScript, Java, C#, C++). > > There is no reason why there can't be a sixth, especially if it can > dramatically improve our productivity and make programming less cognitively > stressful. Surely, that's worth fighting for. > > Enough? > > > > Richard O'Keefe wrote >> Here is a challenge: What is "Smalltalk"? >> VAST, VW, and Pharo are quite different environments. >> To the extent that they share a common syntax (which >> they don't, quite), fine, but porting nontrivial >> code between them is NOT easy. They certainly have >> very little in common as GUI kits. All praise and >> thanks to the people who *have* ported stuff. >> >> >> On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng < >> horrido.hobbies@ >> > >> wrote: >> >>> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >>> >>> A bold claim. It'll be interesting to see if anybody challenges me on >>> this. >>> >>> > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Aug. 11, 2020

Re: [Pharo-users] [ANN] Smalltalk's Successor

by StÃ©phane Ducasse

Richard if you would like to have a real impact why donât you help for real to copy edit and improve documentation. This is not your articles that will attract people, a strong documentation smoothing the learning curve will. This is super easy you can edit text right in your web browser. I do not think that you understand what Iâm saying but I had to try. We have not many native english speakers and having better and more documentation is super important but if people can could help donât do it then we will do it slower. S > On 11 Aug 2020, at 03:07, horrido <horrido.hobbies(a)gmail.com> wrote: > > It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/ > of languages, portability is a genuine issue. > > There's no getting around this dichotomy. You can have either a flexibility > of choice or the tyranny of one standard, but not both. > > The decision is a fact of life that we face frequently. You can have either > the flexibility of dynamic typing or the safety of static typing, but not > both. You can have either the natural modelling of the real world due to > state mutation or the mathematical safety of immutability, but not both. You > can have either the portability of a virtual machine or the > close-to-the-metal performance of native code generation, but not both (JIT > compilation notwithstanding). > > Life is about choices. There will always be a place for different > technologies. Smalltalk will not always be the ideal choice. That's why > there are five entirely different languages that dominate our industry > (Python, JavaScript, Java, C#, C++). > > There is no reason why there can't be a sixth, especially if it can > dramatically improve our productivity and make programming less cognitively > stressful. Surely, that's worth fighting for. > > Enough? > > > > Richard O'Keefe wrote >> Here is a challenge: What is "Smalltalk"? >> VAST, VW, and Pharo are quite different environments. >> To the extent that they share a common syntax (which >> they don't, quite), fine, but porting nontrivial >> code between them is NOT easy. They certainly have >> very little in common as GUI kits. All praise and >> thanks to the people who *have* ported stuff. >> >> >> On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng < > >> horrido.hobbies@ > >> > >> wrote: >> >>> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >>> >>> A bold claim. It'll be interesting to see if anybody challenges me on >>> this. >>> >>> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 11, 2020

Re: [Pharo-users] [ANN] Smalltalk's Successor

by horrido

It's true, Smalltalk faces the same dilemma as Linux and Lisp. As a /family/ of languages, portability is a genuine issue. There's no getting around this dichotomy. You can have either a flexibility of choice or the tyranny of one standard, but not both. The decision is a fact of life that we face frequently. You can have either the flexibility of dynamic typing or the safety of static typing, but not both. You can have either the natural modelling of the real world due to state mutation or the mathematical safety of immutability, but not both. You can have either the portability of a virtual machine or the close-to-the-metal performance of native code generation, but not both (JIT compilation notwithstanding). Life is about choices. There will always be a place for different technologies. Smalltalk will not always be the ideal choice. That's why there are five entirely different languages that dominate our industry (Python, JavaScript, Java, C#, C++). There is no reason why there can't be a sixth, especially if it can dramatically improve our productivity and make programming less cognitively stressful. Surely, that's worth fighting for. Enough? Richard O'Keefe wrote > Here is a challenge: What is "Smalltalk"? > VAST, VW, and Pharo are quite different environments. > To the extent that they share a common syntax (which > they don't, quite), fine, but porting nontrivial > code between them is NOT easy. They certainly have > very little in common as GUI kits. All praise and > thanks to the people who *have* ported stuff. > > > On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng < > horrido.hobbies@ > > > wrote: > >> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >> >> A bold claim. It'll be interesting to see if anybody challenges me on >> this. >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 11, 2020

Re: [Pharo-users] [ANN] Smalltalk's Successor

by Richard O'Keefe

Here is a challenge: What is "Smalltalk"? VAST, VW, and Pharo are quite different environments. To the extent that they share a common syntax (which they don't, quite), fine, but porting nontrivial code between them is NOT easy. They certainly have very little in common as GUI kits. All praise and thanks to the people who *have* ported stuff. On Tue, 11 Aug 2020 at 01:05, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ > > A bold claim. It'll be interesting to see if anybody challenges me on this. > >

Aug. 10, 2020

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Esteban Maringolo

Looking at the Postgres side of the log I find that the connection was reset from the other side (it is Pharo). The reason for that is yet unknown to me. Since I don't do anything (that I'm aware of). golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:02:35.939 UTC [132] LOG: could not receive data from client: Connection reset by peer golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC [139] LOG: could not receive data from client: Connection reset by peer golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC [137] LOG: could not receive data from client: Connection reset by peer golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:33:20.163 UTC [166] LOG: could not receive data from client: Connection reset by peer golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:35:22.019 UTC [168] LOG: could not receive data from client: Connection reset by peer golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:37:33.091 UTC [177] LOG: could not receive data from client: Connection reset by peer I'll have to keep looking. Best regards! Esteban A. Maringolo On Mon, Aug 10, 2020 at 5:35 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > My Seaside session isn't closing the connection, only when > unregistered, but this seems to be something else I don't know. > > I saw there is logging, and I need to set it up in general (including > Fuel serialized stacks). > Looking in the web apparently there is the need for a keepalive that > is not in place. > What disturbs me is that it doesn't happen in development. Making things harder. > > Regards! > > Esteban A. Maringolo > > On Mon, Aug 10, 2020 at 5:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi Esteban, > > > > I have a web app with P3 under Seaside in production and it works fine. But that is without Glorp, nor any connection pooling. > > > > You say the connection seems closed, maybe the closing got triggered by your app somehow ? How do you clean up expired sessions ? How do you handle logouts ? > > > > P3 does normally reconnect automatically, IIRC. > > > > You could try to enable logging in P3Client, that is a recent addition. It should show you what happens to your connections. > > > > Sven > > > > > On 10 Aug 2020, at 21:15, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > > > Hi all, Sven ;-) > > > > > > I'm having erratic P3 errors in a recent application I wrote using > > > Pharo, Seaside and Glorp with P3 as driver. > > > > > > Each Seaside session has a GlorpSession, which in turn has a > > > P3Connection in its accessor. I don't know why, but sometimes the > > > P3Connection socket is closed, and then when trying to read from the > > > database, it cannot write the query to the P3 socket and exception is > > > raised, and it isn't handled by the P3DatabaseDriver (automatically > > > trying to reconnect?). > > > > > > I don't know if I'm doing something wrong, I plan to migrate the > > > GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I > > > want to be sure that the current setup works of if maybe I'm exceeding > > > some limit or timeout that causes the connection to be closed. > > > > > > Regards! > > > > > > > > > Esteban A. Maringolo > > > > > > >

Aug. 10, 2020

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Esteban Maringolo

My Seaside session isn't closing the connection, only when unregistered, but this seems to be something else I don't know. I saw there is logging, and I need to set it up in general (including Fuel serialized stacks). Looking in the web apparently there is the need for a keepalive that is not in place. What disturbs me is that it doesn't happen in development. Making things harder. Regards! Esteban A. Maringolo On Mon, Aug 10, 2020 at 5:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Esteban, > > I have a web app with P3 under Seaside in production and it works fine. But that is without Glorp, nor any connection pooling. > > You say the connection seems closed, maybe the closing got triggered by your app somehow ? How do you clean up expired sessions ? How do you handle logouts ? > > P3 does normally reconnect automatically, IIRC. > > You could try to enable logging in P3Client, that is a recent addition. It should show you what happens to your connections. > > Sven > > > On 10 Aug 2020, at 21:15, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > Hi all, Sven ;-) > > > > I'm having erratic P3 errors in a recent application I wrote using > > Pharo, Seaside and Glorp with P3 as driver. > > > > Each Seaside session has a GlorpSession, which in turn has a > > P3Connection in its accessor. I don't know why, but sometimes the > > P3Connection socket is closed, and then when trying to read from the > > database, it cannot write the query to the P3 socket and exception is > > raised, and it isn't handled by the P3DatabaseDriver (automatically > > trying to reconnect?). > > > > I don't know if I'm doing something wrong, I plan to migrate the > > GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I > > want to be sure that the current setup works of if maybe I'm exceeding > > some limit or timeout that causes the connection to be closed. > > > > Regards! > > > > > > Esteban A. Maringolo > > > >

Aug. 10, 2020

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Sven Van Caekenberghe

Hi Esteban, I have a web app with P3 under Seaside in production and it works fine. But that is without Glorp, nor any connection pooling. You say the connection seems closed, maybe the closing got triggered by your app somehow ? How do you clean up expired sessions ? How do you handle logouts ? P3 does normally reconnect automatically, IIRC. You could try to enable logging in P3Client, that is a recent addition. It should show you what happens to your connections. Sven > On 10 Aug 2020, at 21:15, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi all, Sven ;-) > > I'm having erratic P3 errors in a recent application I wrote using > Pharo, Seaside and Glorp with P3 as driver. > > Each Seaside session has a GlorpSession, which in turn has a > P3Connection in its accessor. I don't know why, but sometimes the > P3Connection socket is closed, and then when trying to read from the > database, it cannot write the query to the P3 socket and exception is > raised, and it isn't handled by the P3DatabaseDriver (automatically > trying to reconnect?). > > I don't know if I'm doing something wrong, I plan to migrate the > GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I > want to be sure that the current setup works of if maybe I'm exceeding > some limit or timeout that causes the connection to be closed. > > Regards! > > > Esteban A. Maringolo >

Aug. 10, 2020

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Esteban Maringolo

To add to this hard to reproduce issue, it only happens in production (where if not?) when running within a Docker Swarm where PostgreSQL is inside the Swarm, so there might be something there fiddling with the network, or I don't know really :-/ Regards. Esteban A. Maringolo On Mon, Aug 10, 2020 at 4:15 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi all, Sven ;-) > > I'm having erratic P3 errors in a recent application I wrote using > Pharo, Seaside and Glorp with P3 as driver. > > Each Seaside session has a GlorpSession, which in turn has a > P3Connection in its accessor. I don't know why, but sometimes the > P3Connection socket is closed, and then when trying to read from the > database, it cannot write the query to the P3 socket and exception is > raised, and it isn't handled by the P3DatabaseDriver (automatically > trying to reconnect?). > > I don't know if I'm doing something wrong, I plan to migrate the > GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I > want to be sure that the current setup works of if maybe I'm exceeding > some limit or timeout that causes the connection to be closed. > > Regards! > > > Esteban A. Maringolo

Aug. 10, 2020

CannotWriteData errors in P3 and Seaside

by Esteban Maringolo

Hi all, Sven ;-) I'm having erratic P3 errors in a recent application I wrote using Pharo, Seaside and Glorp with P3 as driver. Each Seaside session has a GlorpSession, which in turn has a P3Connection in its accessor. I don't know why, but sometimes the P3Connection socket is closed, and then when trying to read from the database, it cannot write the query to the P3 socket and exception is raised, and it isn't handled by the P3DatabaseDriver (automatically trying to reconnect?). I don't know if I'm doing something wrong, I plan to migrate the GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I want to be sure that the current setup works of if maybe I'm exceeding some limit or timeout that causes the connection to be closed. Regards! Esteban A. Maringolo

Aug. 10, 2020