October 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Smallest docker image for pharo >=7 ?

by HernÃ¡n Morales Durand

El lun., 14 oct. 2019 a las 5:23, Pierce Ng (<pierce(a)samadhiweb.com>) escribiÃ³: > On Mon, Oct 14, 2019 at 04:07:49AM -0300, HernÃ¡n Morales Durand wrote: > > Because I am lazy and want to avoid searching through all DockerHub > > repository pages... Do you know a Dockerfile to generate the smallest > > possible docker image for Pharo? > > Anyone could make it work Pharo on Alpine since it uses different libc? > > Hi HernÃ¡n, > > Please see following links: > > - https://github.com/pharo-contributions/Docker-Alpine > - https://hub.docker.com/r/pierceng/pharovm-alpine > - https://hub.docker.com/r/pierceng/pharo7-alpine > - https://www.samadhiweb.com/blog/2019.07.20.alpine.pharo.minimal.html > - https://www.samadhiweb.com/blog/2019.08.11.minimizing.pharo.html > > Nice! It works with latest minimal 7.0.4 too. BTW you used .sources whith seem to be for Pharo 7 (Pharo7.0-32bit-0903ade.sources), but when I tried with latest stable minimal and for some reason requires the V60 sources: $ docker run --rm --ulimit rtprio=2 pharo7_docker_alpine printVersion Pharo cannot locate the sources file named /pkg/image/PharoV60.sources. I found also another approach using rtprio=2:2 suggested from https://github.com/ba-st/docker-pharo/blob/master/docs/rtprio.md (soft:hard ulimits). The Alpine-based VM can be made smaller by removing unused/irrelevant > modules. > > Image-wise, currently I am using Pharo 7 minimal, which is just under > 30MB, and that forms the lower bound of the Pharo image size. > > The built image here is aprox. 99 Mbytes REPOSITORY TAG IMAGE ID CREATED SIZE pharo7_docker_alpine latest 595b9ece2625 3 hours ago 99.4MB but I think you didn't sumed the .sources. > However there is also the Pharo Candle effort that aims to make really > small images, which I hope to try out soon. > > > I am also interested in which stage you use to install packages into the > > image, and why? Do you copy the contained image into docker already > built? > > For Pharo, I start with the regular or minimal image, then load my > packages. > > For Docker, I first build a container image for the VM only. Using that > I build a new container image from the Pharo image and other required > files. > > Thank you for sharing Pierce. HernÃ¡n

Oct. 15, 2019

PharoADO

by eftomi

Dear all, A working prototype of PharoADO is now available at https://github.com/eftomi/pharo-ado. I'd be glad if you can find the time to test it and report your observations to this list or on the GitHub. PRs are welcome and much needed :-) Firstly, I would like to focus on various database data types. When using ADOClient and ADORecordset, the availability of data types heavily depends from PharoWin32/PharoCOM packages, so we have to update both repositories :-) The PharoADO package is not huge after all, since ActiveX Data Objects itself is an abstraction layer and provides much of the needed functionalities by itself. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 15, 2019

Re: [Pharo-users] Concurrency Best Practices + Tests

by Noury Bouraqadi

Thanks Vince, Christopher, and Tim! Noury > On 15 Oct 2019, at 05:46, Vince Refiti <vince.refiti(a)trapezegroup.com.au> wrote: > > Hi > > Q. What are your best practices and recommendations for developing and testing concurrent software? > A. I avoid writing concurrent code if I can. If not, I would launch multiple Smalltalk instances instead. > > Even then I would use SQLite3 (or even Postgres, Redis etc) to hold the shared mutable state. SQlite3 locks the db for writes, which is exactly the behaviour I need to controlled access. > > SQlite3 and Redis can be in memory and can be very fast. I use UDBCSQLite3, but looking at Svenâs SimpleRedisClient (https://github.com/svenvc/SimpleRedisClient <https://github.com/svenvc/SimpleRedisClient>) out of sheer curiosity. Then, I can just write sequential code without worrying too much about race/starvation conditions. If not then it class-side mutexes and semaphores, but only as a last resort. > > Q. How to discover need for synchronization/critical sections/ when doing TDD? > A. I do the opposite. I make everything critical, and instead look for places where I can do Process yield. Brutal, but effective. > > Q. How to write code to avoid dead-locks? > A. Use SQLite3 to hold shared mutable resources. It locks the entire db for writes, solving the deadlock for me. I will give SimpleRedisClient a run sometime. > > Vince > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Christopher Fuhrman > Sent: Tuesday, 15 October 2019 11:39 AM > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Subject: Re: [Pharo-users] Concurrency Best Practices + Tests > > EXTERNAL: Do not click links or open attachments if you do not recognize the sender. > > > Hello, > > My answer is late, but hopefully still useful. I'm not a concurrent programmer in Pharo, but have done it in lots of other environments. > > Use the immutable object pattern to avoid having to deal with race conditions (although it won't solve all the problems). > > POSA2 was focused on OO concurrency, and had been applied in C++ and Java: http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/ <https://urldefense.com/v3/__http:/www.dre.vanderbilt.edu/*schmidt/POSA/POSA…> > > You can find Coursera MOOCs with modern application of the POSA2 patterns, but it's mostly focused on Android. > > Advice is often to use an environment's thread-safe data structures and thread pool librairies, if they exist. It's a bigger challenge otherwise to create these yourself. > > I saw a cool exercise of understanding race conditions for the Singleton pattern in the book Head First Design Patterns. It basically looks at breaking up source code of a concurrent method into chunks, and figuring out if you can get a race condition with two threads executing them separately. The metaphor is magnets on a refrigerator door. See the attached image. The Spin model checker (using a DSL, called PROMELA, for code modeling) works in a similar way, by creating all possible executions and checking for violations of invariants. But that's a formal method that is hard to apply to arbitrary (complex) code. > > Cheers, > > Cris > > On Wed, Sep 4, 2019, 09:32 Noury Bouraqadi <bouraqadi(a)gmail.com <mailto:bouraqadi@gmail.com>> wrote: > Hi everyone, > > Can I get your input on the following questions : > > - What are your best practices and recommendations for developing and testing concurrent software? > > - How to discover need for synchronization/critical sections/ when doing TDD? > > - How to write code to avoid dead-locks? > > Noury

Oct. 15, 2019

Re: [Pharo-users] Transcript: printString or asString

by Samuel Teixeira Santos

Hi Richard. Very useful your considerations. I find too the messages like #asWhatever, like you said, were about type conversions, similar like we have in other languages. #printString and the others remember me the special method in Python __str__ or __unicode__ which allow change the default representation of object you dealing of. Thank you, I will pay attention when dealing with this messages

Oct. 15, 2019

Re: [Pharo-users] OSProcess and CommandShell available on GitHub for Pharo users

by David T. Lewis

Hi Sean, On Mon, Oct 14, 2019 at 08:16:17AM -0500, Sean P. DeNigris wrote: > David T. Lewis wrote > > Alistair Grant and I, with the support of Feenk, have made GitHub > > repositories > > for OSProcess and CommandShell > > Thank you to all involved! > > > David T. Lewis wrote > > my own development work remains on squeaksource so I prefer > > contributions there anyway > > It might be good to add that disclaimer and the location of the canonical > repo to the GH README. Also, does anyone know whether, after loading from > GH, one can make enhancements and then simply save to an MCZ repo? > To be honest, I'm not really sure how this should work. My sense is that it is better for Pharo users to use the Pharo tools, and save changes in git. In the case of OSProcess and CommandShell, I can harvest any changes manually, and for me it is probably easiest to just do it that way. Dave

Oct. 15, 2019

Re: [Pharo-users] OSProcess and CommandShell available on GitHub for Pharo users

by David T. Lewis

On Mon, Oct 14, 2019 at 11:01:13AM -0500, Sean P. DeNigris wrote: > David T. Lewis wrote > > they can now be loading in Pharo... > > In Pharo 7.0.4, the following chugged for about an hour cycling back and > forth between OSP and Command Shell without completing: > baseline: 'OSProcess' with: [ > spec > repository: 'github://dtlewis290/OSProcess-Tonel'; > loads: #(#'Core with Output') ] > Hi Sean, Alistair put together the two load scripts, and they worked when I last checked them. These are on the README.md descriptions as: Metacello new repository: 'github://dtlewis290/OSProcess-Tonel/src'; baseline: 'OSProcess'; load. Metacello new repository: 'github://dtlewis290/CommandShell-Tonel/src'; baseline: 'CommandShell'; load. I am not familiar with the baseline approach, so maybe someone else can give a pointer? > > I wonder if it's related to the old circular dependency problem we had which > IIRC was resolved with "Pipeability"... > Possibly so. I think this may have been something to do with an earlier OSProcess load specification that included part of the CommandShell package. Dave

Oct. 15, 2019

Re: [Pharo-users] Concurrency Best Practices + Tests

by Vince Refiti

Hi Q. What are your best practices and recommendations for developing and testing concurrent software? A. I avoid writing concurrent code if I can. If not, I would launch multiple Smalltalk instances instead. Even then I would use SQLite3 (or even Postgres, Redis etc) to hold the shared mutable state. SQlite3 locks the db for writes, which is exactly the behaviour I need to controlled access. SQlite3 and Redis can be in memory and can be very fast. I use UDBCSQLite3, but looking at Svenâs SimpleRedisClient (https://github.com/svenvc/SimpleRedisClient) out of sheer curiosity. Then, I can just write sequential code without worrying too much about race/starvation conditions. If not then it class-side mutexes and semaphores, but only as a last resort. Q. How to discover need for synchronization/critical sections/ when doing TDD? A. I do the opposite. I make everything critical, and instead look for places where I can do Process yield. Brutal, but effective. Q. How to write code to avoid dead-locks? A. Use SQLite3 to hold shared mutable resources. It locks the entire db for writes, solving the deadlock for me. I will give SimpleRedisClient a run sometime. Vince From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Christopher Fuhrman Sent: Tuesday, 15 October 2019 11:39 AM To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Concurrency Best Practices + Tests EXTERNAL: Do not click links or open attachments if you do not recognize the sender. Hello, My answer is late, but hopefully still useful. I'm not a concurrent programmer in Pharo, but have done it in lots of other environments. Use the immutable object pattern to avoid having to deal with race conditions (although it won't solve all the problems). POSA2 was focused on OO concurrency, and had been applied in C++ and Java: http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/<https://urldefense.com/v3/__http:/www.dre.vanderbilt.edu/*schmidt/POSA/POSA…> You can find Coursera MOOCs with modern application of the POSA2 patterns, but it's mostly focused on Android. Advice is often to use an environment's thread-safe data structures and thread pool librairies, if they exist. It's a bigger challenge otherwise to create these yourself. I saw a cool exercise of understanding race conditions for the Singleton pattern in the book Head First Design Patterns. It basically looks at breaking up source code of a concurrent method into chunks, and figuring out if you can get a race condition with two threads executing them separately. The metaphor is magnets on a refrigerator door. See the attached image. The Spin model checker (using a DSL, called PROMELA, for code modeling) works in a similar way, by creating all possible executions and checking for violations of invariants. But that's a formal method that is hard to apply to arbitrary (complex) code. Cheers, Cris On Wed, Sep 4, 2019, 09:32 Noury Bouraqadi <bouraqadi(a)gmail.com<mailto:bouraqadi@gmail.com>> wrote: Hi everyone, Can I get your input on the following questions : - What are your best practices and recommendations for developing and testing concurrent software? - How to discover need for synchronization/critical sections/ when doing TDD? - How to write code to avoid dead-locks? Noury

Oct. 15, 2019

Re: [Pharo-users] Concurrency Best Practices + Tests

by Christopher Fuhrman

Hello, My answer is late, but hopefully still useful. I'm not a concurrent programmer in Pharo, but have done it in lots of other environments. Use the immutable object pattern to avoid having to deal with race conditions (although it won't solve all the problems). POSA2 was focused on OO concurrency, and had been applied in C++ and Java: http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/ <http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/> You can find Coursera MOOCs with modern application of the POSA2 patterns, but it's mostly focused on Android. Advice is often to use an environment's thread-safe data structures and thread pool librairies, if they exist. It's a bigger challenge otherwise to create these yourself. I saw a cool exercise of understanding race conditions for the Singleton pattern in the book Head First Design Patterns. It basically looks at breaking up source code of a concurrent method into chunks, and figuring out if you can get a race condition with two threads executing them separately. The metaphor is magnets on a refrigerator door. See the attached image. The Spin model checker (using a DSL, called PROMELA, for code modeling) works in a similar way, by creating all possible executions and checking for violations of invariants. But that's a formal method that is hard to apply to arbitrary (complex) code. Cheers, Cris On Wed, Sep 4, 2019, 09:32 Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi everyone, > > Can I get your input on the following questions : > > - What are your best practices and recommendations for developing and > testing concurrent software? > > - How to discover need for synchronization/critical sections/ when doing > TDD? > > - How to write code to avoid dead-locks? > > Noury >

Oct. 15, 2019

Re: [Pharo-users] Concurrency Best Practices + Tests

by Tim Mackinnon

Noury - I happened to notice in a recent article about the Rust scheduler (it caught my eye) it had a section on concurrent testing and a tool they write called Loom to test all possible permutations and catch errors. This might be an avenue of investigation for your work ? An idea any way. https://tokio.rs/blog/2019-10-scheduler/ Sent from my iPhone > On 4 Sep 2019, at 14:31, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Hi everyone, > > Can I get your input on the following questions : > > - What are your best practices and recommendations for developing and testing concurrent software? > > - How to discover need for synchronization/critical sections/ when doing TDD? > > - How to write code to avoid dead-locks? > > Noury

Oct. 14, 2019

Re: [Pharo-users] Aconcagua Canonical Repo(s)

by Sean P. DeNigris

gcotelli wrote > I don't know if call it canonical. But certainly it is the version the > community is maintaining. That works for me. I guess I'll re-fork from there. Hopefully, some of the other repo owners will speak up as to whether they have useful changes to pick up. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 14, 2019