April 2021 - Pharo-users - lists.pharo.org

Re: Help Needed: Looking for projects to use in a study of transforming deprecations

by Oleksandr Zaitsev

Richard O'Keefe wrote > Surely this is back to front? #includesAllOf: reads well and is > compatible with GNU Smalltalk (and classic Squeak), while #includesAll: > doesn't work in most of the Smalltalks I have access to. > > My own library has > {includes,excludes}{All,Any,None,One}Of: > which wouldn't read nearly so well without "Of". Yes, this makes sense! I will fix that example Thank you -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 20, 2021

Re: Help Needed: Looking for projects to use in a study of transforming deprecations

by Oleksandr Zaitsev

gcotelli wrote > We have several projects in the Buenos Aires Smalltalk group that can > match > (we provide in fact a migration package when breaking backward > compatibility including transformation rules so you have a human benchmark > to compare). Thanks a lot Gabriel and Serge! I will run my experiment of those projects -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 20, 2021

Re: Postgres P3 Driver in seaside/web apps - strategy for "prepare:"

by Esteban Maringolo

Not completely related, but also not unrelated. (?) You can pool your connections in the server side by means of pg_bouncer [1] to scale tenfold (or more) the connectivity to your PostgreSQL server. So you can program with P3Client and then when you need to scale the connectivity, simply do it on the server side. Of course if you have 1000s of P3Clients on a single image, then it might take a big toll on the memory use, so it also depends on how you balance connections. Best regards, [1] https://www.pgbouncer.org/config.html Esteban A. Maringolo On Mon, Apr 19, 2021 at 2:52 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Sanjay, > > > On 19 Apr 2021, at 18:14, Sanjay Minni <sm(a)planage.com> wrote: > > > > Hi > > > > using the P3 Postgres driver > > > > what is the optimised way of using the following in a seaside/web > > application > > statement := client prepare: ... > > statement execute: > > statement close. > > > > Sven readme on the drivers page > > "prepared statements ... need to be closed, prepared statement exist ... > > single session / connection ..." > > First make sure that you give each session in your (seaside) web > application its own connection/client to the database. P3Client is meant to > be used single threaded, it is your responsibility to protect this. Make > sure these are initialised and disposed of properly - use logging. > > Second, I would not put time in trying to gain performance with prepared > statements until you can prove that it makes a real, measurable difference. > PostgreSQL is very fast. But this is IMHO. > > See further. > > > Typically in a desktop app I would fire the "prepare" statements(s) once > > when open the particular UI / window (say typically 2 or 3 statements in > a > > UI) and then "close" when I exit > > > > How does this work in a multi-tabbed browser app > > lets say I open a tab with a particular UI and fire the "prepare" > statement > > > > now what if the tab idles for too long - and then i press send/save. The > > program would have just fired the "execute ..." assuming the prepare is > > active. would the prepare / session have been automatically closed ? > > > > - when should i typically fire the prepare statement > > Either upfront when you connect, or each time when you need them (see > further). The scope of a prepared statement is the connection/session. > > Preparing 10s of statements upfront that you might not need could increase > connection time. > > > - how should i test if the session / prepare is still active or needs to > be > > refired > > There is P3Client>>#preparedStatementNamed: > You best use P3Client>>#prepare:named: then. > > > - how are orphan prepare statements disposed off ny the database / > program > > They get thrown out when the connection closes. > > HTH, > > Sven > > PS: > > There is also P3ConnectionPool that can protect against concurrent access, > prepare connections, warm up, on top of its base functionality of pooling, > of course. But a challenge with connection pooling is what to do when > errors occur. > > > thanks for pointers > > Sanjay > > > > > > > > ----- > > cheers, > > Sanjay > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 19, 2021

[ANN] Willow-Bootstrap v13.1.1 [v13.1.1] released!

by Buenos Aires Smalltalk

April 19, 2021

[ANN] Willow v14.2.1 [v14.2.1] released!

by Buenos Aires Smalltalk

April 19, 2021

[ANN] Boardwalk v6.1.1 [v6.1.1] released!

by Buenos Aires Smalltalk

April 19, 2021

Re: Postgres P3 Driver in seaside/web apps - strategy for "prepare:"

by Sven Van Caekenberghe

Hi Sanjay, > On 19 Apr 2021, at 18:14, Sanjay Minni <sm(a)planage.com> wrote: > > Hi > > using the P3 Postgres driver > > what is the optimised way of using the following in a seaside/web > application > statement := client prepare: ... > statement execute: > statement close. > > Sven readme on the drivers page > "prepared statements ... need to be closed, prepared statement exist ... > single session / connection ..." First make sure that you give each session in your (seaside) web application its own connection/client to the database. P3Client is meant to be used single threaded, it is your responsibility to protect this. Make sure these are initialised and disposed of properly - use logging. Second, I would not put time in trying to gain performance with prepared statements until you can prove that it makes a real, measurable difference. PostgreSQL is very fast. But this is IMHO. See further. > Typically in a desktop app I would fire the "prepare" statements(s) once > when open the particular UI / window (say typically 2 or 3 statements in a > UI) and then "close" when I exit > > How does this work in a multi-tabbed browser app > lets say I open a tab with a particular UI and fire the "prepare" statement > > now what if the tab idles for too long - and then i press send/save. The > program would have just fired the "execute ..." assuming the prepare is > active. would the prepare / session have been automatically closed ? > > - when should i typically fire the prepare statement Either upfront when you connect, or each time when you need them (see further). The scope of a prepared statement is the connection/session. Preparing 10s of statements upfront that you might not need could increase connection time. > - how should i test if the session / prepare is still active or needs to be > refired There is P3Client>>#preparedStatementNamed: You best use P3Client>>#prepare:named: then. > - how are orphan prepare statements disposed off ny the database / program They get thrown out when the connection closes. HTH, Sven PS: There is also P3ConnectionPool that can protect against concurrent access, prepare connections, warm up, on top of its base functionality of pooling, of course. But a challenge with connection pooling is what to do when errors occur. > thanks for pointers > Sanjay > > > > ----- > cheers, > Sanjay > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2021

Postgres P3 Driver in seaside/web apps - strategy for "prepare:"

by Sanjay Minni

Hi using the P3 Postgres driver what is the optimised way of using the following in a seaside/web application statement := client prepare: ... statement execute: statement close. Sven readme on the drivers page "prepared statements ... need to be closed, prepared statement exist ... single session / connection ..." Typically in a desktop app I would fire the "prepare" statements(s) once when open the particular UI / window (say typically 2 or 3 statements in a UI) and then "close" when I exit How does this work in a multi-tabbed browser app lets say I open a tab with a particular UI and fire the "prepare" statement now what if the tab idles for too long - and then i press send/save. The program would have just fired the "execute ..." assuming the prepare is active. would the prepare / session have been automatically closed ? - when should i typically fire the prepare statement - how should i test if the session / prepare is still active or needs to be refired - how are orphan prepare statements disposed off ny the database / program thanks for pointers Sanjay ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2021

Re: Whats the easiest/cheapest way to run a Pharo web app in 2021?

by Jonathan van Alteren

Hi Tim, all, My earlier message to this thread (on 8 April) hasn't been properly received/distributed by the list. Marcus was very kind to help me solve this, so you should receive this message now. Anyway... see my original message below. Hope it's still useful. ----- Hi Tim, Didn't really notice this thread until now. I understand you're looking into deployment using Docker. However, to provide some perspective, we're happily running Pharo in production on a (self-managed) VPS on Hetzner Cloud (which uses 100% green energy!). We use our own adaptation of Pharo server tools based on Sven's original work:Â https://github.com/objectguild/pharo-server-tools. We started with running Pharo 7.0 and have since upgraded to Pharo 8.0. Some experience with Linux command line is certainly welcome, but it should be fairly easy to get this going. Mind you, the README is (unfortunately) _not_ up to date. Regarding Docker, I don't have much experience myself. I've only used it a couple of times to troubleshoot smalltalkCI issues, never for running a Pharo server application. Hope this is of some use to you or others. Good luck and have fun! ----- Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Software that works âwithâ you jvalteren(a)objectguild.com On 8 Apr 2021, 12:58 +0200, Tim Mackinnon <tim(a)testit.works>, wrote: > Head slap.... I completely forgot I could do that, thanks for reminding Pierce (its almost better as well, as you can build your image, save it, then run tests on it, and then if it passes all your stages you can included the saved version in your docker build... which sits better with me as it also means that log artifacts etc can be more easily examined for failures (and your not trying to console into a docker image to figure it out). As a nice side effect - if you are doing this in something like Gitlab - you have your project source already there and so you can avoid an extra checkout step, so its a little bit faster. > > Pierce - who/where are you rnning your Docker image? Do you use a particular service (or are you running your own?) > > Tim > > > > On Thu, 8 Apr 2021, at 4:29 AM, Pierce Ng wrote: > > On Wed, Apr 07, 2021 at 02:21:14AM +0100, Tim Mackinnon wrote: > > > I also feel its quite important to call out that the "eval 'Metacello > > > new..." command referenced in the DockerFile RUN - is only going to work > > > > Hi, > > > > I build my Pharo image outside of Docker. My Dockerfile then packages the > > built image plus whatever artefacts required into a Docker image. I am > > using my Alpine Linux-based VM. > > > > GH: https://github.com/pharo-contributions/Docker-Alpine/ > > DH: https://hub.docker.com/r/pierceng/pharovm-alpine > > > > Pierce > >

April 19, 2021

testing mailing list distribution

by Jonathan van Alteren

My apologies, but my messages weren't received/distributed by the mailing list, so this is a test message. Please ignore. Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Software that works âwithâ you jonathan(a)objectguild.com

April 19, 2021