- Pharo-users - lists.pharo.org

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

by Richard O'Keefe

The contrast between "flexibility of choice" and "tyranny of one standard" is, um, a little over-drawn. I have three different Common Lisp systems on this laptop: CMUCL, SBCL, and CCL. I have the flexibility of choice between them *because* the adhere to a common standard. Each of them has its own extra bits, but I am free to choose between them because everything *else* is not idiosyncratic. I have a choice of machine learning libraries for Python, but that is useful to me because the *rest* of Python isn't different, so there's a huge amount of stuff I can use with an ML program. In Smalltalk I cannot even port a program that opens a file for input, another one for output, and copies the one to the other, despite everything I need being in the ANSI Smalltalk standard. I mean come ON! I have two commercial Smalltalks, two formerly commercial Smalltalks, three free Smalltalks, and several Smalltalk implementations that were never quite finished, and no two of them handle Unicode the same way! Think about it: you have "ÎÎ±Î»Î·Î¼ÎÏÎ± ÎºÏÏÎ¼Îµ" in a file, and no part of trying to copy that file is portable. Let's not mention Sockets, OK? Let's just not go there. Choice and consistency are NOT a dichotomy. They are both important. You need consistency at one level to construct choices at the next level. I note that there are type systems available for Prolog, Erlang, Scheme, and Python (https://realpython.com/python-type-checking/) and I've done work on a type inference program for AWK. Also that there are dynamic type facilities for Haskell and Clean. So dynamic types -vs- static types are not a hard dichotomy either. On Tue, 11 Aug 2020 at 13:08, 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 > >

Aug. 12, 2020

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

by Offray Vladimir Luna CÃ¡rdenas

Hi Ted, Don't worry and take your time. I tend to write looong (this list should be thankful of English not being my first language and I mostly self learned after crappy courses, if not, you will have me writing even longer ;-P). About entry points, one of the things I like about Pharo is that you canÂ traverse complexity in a similar way, because the liveness of the environment helps you to do it. It's like writing and reading. Once you learn to do it, core strategies are the same despite of addressing huge or small books. I felt that with other languages/environments, traversing infrastructure have pretty particular approaches depending on the particular tool/architecture I was trying to make sense of (infrastructure at some point becomes architecture, but I digress). So we are preparing new entry points with the upcoming Indie Web Workshop [1]. Those entry points have the same level of complexity for new comers, despite of being evolving prototypes and hopefully will attract more experienced ones with Intermediate Level Tutorials. Even they will have the added value of allow ourselves to create some web portfolios for showcasing what we are doing here, in a more attractive and visual way. I will share advances with the list, Cheers, Offray [1] Invitation poster in Spanish at: https://docutopia.tupale.co/uploads/upload_51d7d8be27bb53d5dc1eb96d71979313… On 11/08/20 12:58 p.Â m., tbrunz wrote: > 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. 12, 2020

Little blog post on how to use transcript as a real OOProgrammer

by StÃ©phane Ducasse

Hi guys I wrote this https://thepharo.dev/2020/08/11/transcript-the-misunderstood-global/ <https://thepharo.dev/2020/08/11/transcript-the-misunderstood-global/> because I thought that I had to :) See Chapter 8 for a longer version https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle/releases/… <https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle/releases/…> S. -------------------------------------------- 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] 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