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

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

by Tim Mackinnon

I havenât tried in a while, but in 2017 with PharoLambda I had a combined Pharo image and VM size if 21 mb using the early Pharo minimal (I recall it was an early 7.0 image ). I was loading a simple hello Alexa app, so not a ton of code (but it had Neo Json and other AWS libs as a dependency I recall). Iâm interested in trying these Docker experiments, so Iâll have to look at some point and see if I can get similar sizes. As I scripted my build, I have the steps laid out. I recall there were many vm plugins not needed for a server install (sound etc) and I also ran a cleanup step in the image as there was lots of metacello stuff cached ... so Iâm sure tinier is possible even without candle. Tim Sent from my iPhone > On 18 Oct 2019, at 07:48, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 17.10.2019 um 02:00 schrieb JuliÃ¡n Maestri <serpi90(a)gmail.com>: >> >> 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. > > The overlayfs does only help here with the disk storage that is not multiplied. As the image is a memory dump of an individual image nothing can be shared there. So if you have 20 images you have 20 times the heap. So a small image is actually important. The vm is different. It is the same static file which will be paged into shared memory and the vm binary should be shared for all 20 runtimes. But the interpreter memory will not be shared so a small vm pays out as well. > > Norbert >

Oct. 18, 2019

Re: [Pharo-users] Import a pharo 6 image in pharo 7

by Sven Van Caekenberghe

Hi, You could try to serialise/deserialise your data with either STON (textual) or FUEL (binary). 'mydata.ston' asFileReference writeStreamDo: [ :out | (STON writer on: out) nextPut: objectGraph ]. 'mydata.ston' asFileReference readStreamDo: [ :in | (STON reader on: in) next ]. If you have more questions, just ask. Sven > On 18 Oct 2019, at 02:52, Oswall Verny Arguedas C. <sistecaq(a)gmail.com> wrote: > > I have a prototype of an application with image persistence made in pharo 6.1. > I wanted to export (upgrade) the data (database, objects, collections) of the image and code to Pharo 7. > It is possible to perform that operation. > Thanks in advance > Oswall >

Oct. 18, 2019

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

by Norbert Hartl

> Am 17.10.2019 um 02:00 schrieb JuliÃ¡n Maestri <serpi90(a)gmail.com>: > > 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. The overlayfs does only help here with the disk storage that is not multiplied. As the image is a memory dump of an individual image nothing can be shared there. So if you have 20 images you have 20 times the heap. So a small image is actually important. The vm is different. It is the same static file which will be paged into shared memory and the vm binary should be shared for all 20 runtimes. But the interpreter memory will not be shared so a small vm pays out as well. Norbert

Oct. 18, 2019

Re: [Pharo-users] String concatenation vs. Stream

by Richard O'Keefe

When is it pointless to introduce a WriteStream and just use #, ? When #, would not be in a loop or recursion. Constructing error messages, class initialisation code, that sort of thing. If you find yourself doing a lot of concatenations, you are probably missing an abstraction. For example, building up XML by string concatenation would be very silly: you want to build a tree and have it write itself to a stream.

Oct. 18, 2019

Import a pharo 6 image in pharo 7

by Oswall Verny Arguedas C.

I have a prototype of an application with image persistence made in pharo 6.1. I wanted to export (upgrade) the data (database, objects, collections) of the image and code to Pharo 7. It is possible to perform that operation. Thanks in advance Oswall

Oct. 18, 2019

Re: [Pharo-users] String concatenation vs. Stream

by Vince Refiti

Yes, but the real question is: What is the lower bound? When would you consider it pointless to use streams and just concatenate away? Or even trying to profile the difference. For me, 3 or less. Vince From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Kasper Ãsterbye Sent: Friday, 18 October 2019 2:38 AM To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] String concatenation vs. Stream EXTERNAL: Do not click links or open attachments if you do not recognize the sender. This is an old one, and I knew of cause that one should not use #, when you can use streams instead. But that is was this bad to use #, came as a surprise I must say<https://urldefense.com/v3/__https:/gist.github.com/kasperosterbye/d8c9bd518…> Best, Kasper

Oct. 18, 2019

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

by HernÃ¡n Morales Durand

El miÃ©., 16 oct. 2019 a las 19:49, JuliÃ¡n Maestri (<serpi90(a)gmail.com>) escribiÃ³: > 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). > > Cool!! Thank you JuliÃ¡n, Cheers, HernÃ¡n > 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. 17, 2019

String concatenation vs. Stream

by Kasper Ãsterbye

This is an old one, and I knew of cause that one should not use #, when you can use streams instead. But that is was this bad to use #, came as a surprise I must say <https://gist.github.com/kasperosterbye/d8c9bd518fba68289c9f129d553ad6b6> Best, Kasper

Oct. 17, 2019

Re: [Pharo-users] NVARCHAR and Glorp

by eftomi

Solomon, thank you for your additional insights. Of course we'll have to wait for SQL Server 2019 to be adopted - tactful devops wait for SP2 of v4 to change from v2 to v3 :-) Indeed I solved the problem in NVARCHAR / NCHAR / NTEXT by adding the method WideString>>#glorpPrintSQLOn: which is almost the same as String>>#glorpPrintSQLOn: except that it checks whether the database platform understands a message #prefixForUnicode. Then I subclassed SQLServerPlatform as #SQLServerPlatformN with this constant which returns $N. To use this, one has to: - define the field type in DescriptorSystem as 'platform nvarchar width: xx' (or nchar, ntext) - set the platform to SQLServerPlatformN (N for 'National Language Character Set'). For now, I subclassed SQLServerPlatform if there will be any other additions to SQL Server Glorp platform. In the future the constant should probably become just an "ordinary" extension to Glorp's SQLServerPlatform. These changes are now available at https://github.com/eftomi/pharo-ado. Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 17, 2019

Re: [Pharo-users] help with understanding the visitor pattern

by Richard O'Keefe

First, this is presumably the "Die" exercise from the Pharo track of exercism.io. Second, this is a case where - there is nothing to a Die other than the number of faces, so from a practical point of view there should not be a Die class; - there is nothing to a DieHandle other than a sequence of dice, so from a practical point of view there should not be a DieHandle class (not least because the word "Handle" here makes no sense in English and since it may contain many dice it would be better as DiceHandle, if only Handle made sense here). Once you realise that a Die is just an Integer wearing a burqa and a DIeHandle is just an OrderedCollection or Bag wearing a burqa, it may be easier to figure out how to combine these things. Of course it is most unwise to use #+ for combining dice and/or DieHandles. Both because + is a confusing choice and because we already *have* a selector that means "concatenate these two sequences", namely #, Looking at my own answer to this, and others, I see that you want two operations: aDieHandle addDie: aDie aDieHandle + anotherDieHandle You are not required to define + with either operation a Die. One way to do this is to add a new method DieHandle >> addAllTo: another [ dice do: [:each | another addDie: each]. ^another ] then DieHandle >> + another [ ^another addAllTo: (self addAllTo: DieHandle new)) ] Now if you want to extend this to treat a single Die as if it were a DieHandle containing itself, just do Die >> addAllTo: another [ another addDie: self. ^another ] Die >> + another [ ^another addAllTo: (self addAllTo: DieHandle new)) ] Now that Die and DieHandle have some selectors in common (and an actual method), it might make sense to introduce a common superclass. DiceSet (no data) roll ^self roll: Random default roll: rng diceNumber addAllTo: + another ^another addAllTo: (self addAllTo: DieHandle new) Die < DiceSet (faces) roll: rng ^faces atRandom: rng diceNumber ^1 addAllTo: aHandle aHandle addDie: self. ^aHandle DieHandle < DiceSet (dice) roll: rng ^self detectSum: [:die | did roll: rng] diceNumber ^dice size addAllTo: aHandle dice do: [:die | aHandle addDie: die]. ^aHandle What we have here is pretty close to the Composite pattern, not the Visitor pattern. If a DieHandle could accept DieHandles as elements as well as Die instances, it would be a bona fide example of Composite, and the code would need a few minor changes. The Visitor pattern is a way of dealing with "the Expression Problem". You don't *have* that problem. It doesn't seem like a good idea to apply it here. On Wed, 16 Oct 2019 at 21:33, Roelof Wobben via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > 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. 17, 2019