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

Pharo TechTalk Oct 24

by Marcus Denker

Hi, Next techtalk will be *next* week (Oct 24): Topic: Headless VM Calendar entry: https://association.pharo.org/event-3419545 (it was originally dated to today, we will try to be better in pre-planning from the next one on)

Oct. 17, 2019

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

by JuliÃ¡n Maestri

Example: # Stage 1: Load the project on an empty image, in this case this is a development image (should change to use a minimal image) FROM basmalltalk/pharo:7.0-image AS loader COPY load-project.st ./ RUN pharo Pharo.image load-project.st --save --quit # Stage 2: Copy the resulting Pharo.image with our project loaded # into a new docker image with just the vm # start in a new stage to keep docker image minimal FROM basmalltalk/pharo:7.0 USER root WORKDIR /opt/app COPY start.sh . COPY --from=loader /opt/pharo/Pharo.image ./ COPY --from=loader /opt/pharo/Pharo.changes ./ COPY --from=loader /opt/pharo/Pharo*.sources ./ RUN mkdir logs \ && chmod a+x start.sh \ && chown --recursive pharo:pharo /opt/app USER pharo EXPOSE 8080 CMD ["./start.sh"] The resulting image size is ~80mb including image, changes & sources Reference: https://docs.docker.com/develop/develop-images/multistage-build/ As a side note, the final image size is not what really matters, if you have 20 different images all starting from the same base image (eg ubuntu:18.04) the base layer is shared among all images so the network / disk usage is less than the total size of the image. It's important to keep the docker image thin, but also to keep layers at a minimum and not adding / removing stuff during the build, because those are stored in the middle layers (multi stage helps to remove that). Cheers. On Tue, 15 Oct 2019 at 20:00, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > > 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. 16, 2019

Re: [Pharo-users] NVARCHAR and Glorp

by Solomon.Rutzky

eftomi wrote > I found the "ultimate" place where strings are being preparedfor INSERT > INTO clause - this happens in String>>#glorpPrintSQLOn:. Not soeasy to > parametrize at a first glance. Maybe withWideString>>#glorpPrintSQLOn: but > I'm not sure how other platforms would behappy.An interesting observation > about UTF-8 and SQL Server 2019 is > here:https://sqlquantumleap.com/2018/09/28/native-utf-8-support-in-sql-serv…. Hello Tomaz. I am the author of that UTF-8 in SQL Server 2019 post you linked to, and I think I can provide some context here. UTF-8 in SQL Server is not something you need to worry about, nor is it really an option at this point. SQL Server 2019 is still in beta, and even when officially released it will be some time before a lot of folks are using it. And for some it will take years considering that some places are still using SQL Server 2000, or 2005. If you are generating INSERT and UPDATE statements, and those include string literals, then you need to use the encoding that is expected by SQL Server. When string literals are not prefixed with an upper-case "N" they are interpreted in the 8-bit code page associated with the default collation of the database that you are currently using (likely the database that you connected to, if specified in the connection string, or the default database of the login that you connected as). If someone is using SQL Server 2019 (or newer, someday) then that might be UTF-8, but otherwise it is some Extended ASCII character set. If you are sending over Unicode data, then you can't rely on the target database using a "_UTF8" collation (as well as using it for the columns). In which case, unfortunately, you really do need to prefix all string literals with an upper-case "N". However, fortunately, for those systems that are using a "_UTF8" collation for the columns, passing in the literals prefixed with an upper-case "N" is compatible, so you don't need to have your code distinguish between the two. NVARCHAR data (i.e. string literals prefixed with an upper-case "N", and NVARCHAR / NCHAR / NTEXT columns and variables), and the T-SQL query batch itself, are encoded as UTF-16 Little Endian. Don't forget to escape embedded single-quotes ( ' ) as two single-quotes ( '' ) :-) Take care,Solomon... ----- _____________________________________________________________ SQL# â  https://SQLsharp.com/  ( SQLCLR library of over 340 Functions and Procedures ) Sql Quantum Lift â  https://SqlQuantumLift.com/  ( company ) Sql Quantum Leap â  https://SqlQuantumLeap.com/  ( blog ) Info sites â  Collations      â¢      Module Signing      â¢      SQLCLR _____________________________________________________________ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 16, 2019

Re: [Pharo-users] PharoADO

by Guillermo Polito

Thanks Tomaz! This is great :) Nice docs too! > El 15 oct 2019, a las 21:36, eftomi <tomaz.turk(a)ef.uni-lj.si> escribiÃ³: > > 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. 16, 2019

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

by Steffen MÃ¤rcker

I can definitely second all the points. If you want to verify your design formally, Vereofy (http://www.vereofy.de) is another model checker that focuses on communication and coordination. Best, Steffen Am .10.2019, 08:49 Uhr, schrieb Richard O'Keefe <raoknz(a)gmail.com>: > (1) Be very clear in your design about which objects are shared and > which are not. > (2) Immutable objects can be shared safely. Mutable ones are much > much harder to work with. > (3) Lazy initialisation does not work well in concurrent programming, > *except* when you are > constructing an immutable value and it doesn't matter if the > variable is initialised twice. > (4) If you can possibly do so, *SEPARATE* the concurrency structure > from the application- > specific work. Use something like Promela/SPIN, or NuSMV, or > NuXmv, to check your > concurrency structure, or CPN Tools if you prefer Coloured Petri > Nets as a modelling > notation. This is what Erlang does with great success with > "behaviours"; the concurrency > structures are there in the library and you just plug in the > non-concurrent part. Look up > "parallelism patterns" and "algorithmic skeletons". The book > https://pdfs.semanticscholar.org/f43e/7c6a40b96743f2217472a49cd616622bdc26.… > may be helpful. Separation of concerns: this way you can test > the concurrency > structure of your code independently of the rest. > (5) It isn't clear to me that TDD is a good way to develop concurrent > programs. It's a great > way to develop the non-concurrent *parts*. One reason I say this > is that I've found that > it is better to avoid adding unneeded sequencing in a design than > to add concurrency > to a sequential code. If you try to *add* critical sections in a > language like Lisp or > Smalltalk, you *will* miss some. So the TDD Way of is likely to > seduce you into > making your code too sequential too soon. > (6) I personally find processes communicating via SharedQueues *much* > easier to design > and make work than processes communicating via shared variables > and mutexes or > semaphores. (Basically, a Semaphore is a SharedQueue that can > only remember how > many items it's holding, not what they were.) Your experience > may be different, but > Processes with private data communicating via SharedQueues > transfer much easier > to concurrent activities on separate machines communicating via > sockets. > > On Thu, 5 Sep 2019 at 01: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. 16, 2019

help with understanding the visitor pattern

by Roelof Wobben

Hello, Im busy with this project: https://github.com/RoelofWobben/Die Now I also want to try to add a DieHandler and a Die together. And I heared you can use the visitor pattern to solve this. As far asÂ I understand the pattern I have to make a new class which contains only the + method. But I fail to understand to see how I can make a difference between the + of a Die and the + of a DieHandler. So can someone help me understand this pattern and maybe learn me step by step how to implement this in my code. Regards, Roelof

Oct. 16, 2019

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

by Richard O'Keefe

(1) Be very clear in your design about which objects are shared and which are not. (2) Immutable objects can be shared safely. Mutable ones are much much harder to work with. (3) Lazy initialisation does not work well in concurrent programming, *except* when you are constructing an immutable value and it doesn't matter if the variable is initialised twice. (4) If you can possibly do so, *SEPARATE* the concurrency structure from the application- specific work. Use something like Promela/SPIN, or NuSMV, or NuXmv, to check your concurrency structure, or CPN Tools if you prefer Coloured Petri Nets as a modelling notation. This is what Erlang does with great success with "behaviours"; the concurrency structures are there in the library and you just plug in the non-concurrent part. Look up "parallelism patterns" and "algorithmic skeletons". The book https://pdfs.semanticscholar.org/f43e/7c6a40b96743f2217472a49cd616622bdc26.… may be helpful. Separation of concerns: this way you can test the concurrency structure of your code independently of the rest. (5) It isn't clear to me that TDD is a good way to develop concurrent programs. It's a great way to develop the non-concurrent *parts*. One reason I say this is that I've found that it is better to avoid adding unneeded sequencing in a design than to add concurrency to a sequential code. If you try to *add* critical sections in a language like Lisp or Smalltalk, you *will* miss some. So the TDD Way of is likely to seduce you into making your code too sequential too soon. (6) I personally find processes communicating via SharedQueues *much* easier to design and make work than processes communicating via shared variables and mutexes or semaphores. (Basically, a Semaphore is a SharedQueue that can only remember how many items it's holding, not what they were.) Your experience may be different, but Processes with private data communicating via SharedQueues transfer much easier to concurrent activities on separate machines communicating via sockets. On Thu, 5 Sep 2019 at 01: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. 16, 2019

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

by Markus Stumptner

Thanks for pointing out the relationship.Â I had actually been looking for an implementation of the old OOPSLA paper intermittently over a few months. Never would have occurred to me that this is one.Â Â The curse of coy package names... On 15/10/2019 3:50, Cyril Ferlicot wrote: > > > > What is the relation with Units maintained by Zweindenker? > > On Mon 14 Oct 2019 at 19:13, Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > It seems that this is now canonical: > https://github.com/ba-st/aconcagua > > I assume its predecessor [1] was a port from this StHub repo [2]. > There are > two other repos on StHub [3] - the first of which has changes > after the last > in [1] and the other has changes which may have been/need to be > merged. Can > anyone shed further light? > > 1. https://github.com/mtaborda/aconcagua > 2. http://smalltalkhub.com/#!/~maxi/Aconcagua > 3. http://smalltalkhub.com/#!/~HernanWilkinson/Aconcagua > http://smalltalkhub.com/#!/~BenoitAstruc/Aconcagua > > p.s. IMHO when porting from MCZ to GH, a good practice is to state > in the GH > README that it's a port, including the URL of the source and a way to > clarify the last commit (maybe the date could often be sufficient) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- > Cyril Ferlicot > https://ferlicot.fr

Oct. 16, 2019

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

by David Mason

Iâd love to see someone write a recording debugger for smalltalk. In theory you might be able to use rr with Pharo. https://rr-project.org/ ../Dave On Oct 15, 2019, 9:22 AM -0400, Noury Bouraqadi <bouraqadi(a)gmail.com>, wrote: > 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) 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/ > > > > 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. 16, 2019

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

by Richard O'Keefe

It may be worth noting that the 1998 ANSI Smalltalk standard defines #asString for Character, <readableString>, String, and Symbol and for those classes only. VisualWorks extends #asString to things like Filename and URIs and Text and several other things for which "convert to String" makes sense and are not locale-dependent. VW does *not* extend #asString to Object. Visual Age Smalltalk *does* define Object>>asString ^self printString but overrides this so that nil asString => ''. Put it this way: if you use #asString for anything that is not some kind of text or some kind of 'locator' having an externally defined representation which can be converted back to an equal 'locator' (file name, URI, network host name, X11 font, ISO country currency or language code), don't expect your code to be even close to portable. On Wed, 16 Oct 2019 at 00:13, Samuel Teixeira Santos <arcanosam(a)gmail.com> wrote: > > 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