- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 17 September 2018

by Sven Van Caekenberghe

> On 24 Sep 2018, at 10:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 24 Sep 2018, at 09:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Esteban, >> >>> On 24 Sep 2018, at 08:00, estebanlm(a)gmail.com wrote: >>> >>> * I migrated all [pharo-ide](https://github.com/pharo-ide) projects to tonel format. >>> >>> Harder than it seems, it took me a good bunch of hours. But now is working. >>> >>> This will enhance work/fixes on Calypso. >> >> If it was hard for you, how are we supposed to do it ? >> Is there a guide/description somewhere ? > > For what? > Migration? > There is an option on iceberg (repository/extrasâ¦) that does that and it will work 99% of the cases (there is a known bug with a fix waiting on the iceberg repo who prevents seaside migration). > This will migrate without history. Or better: history will be there, just in filetree but since there is no match between one format and another and that will give problems to see the history. I managed to convert https://github.com/svenvc/P3 to Tonel and all went well (as far as I can see). I must say that Iceberg matured a lot lately, it works super nice. Thx! > The problem here was that I needed to migrate all pharo-ide repositories, and update baselines and make all tests pass and in the middle I exceeding travis ârightâ to see tags (if you are not authenticated, it can happen), etc. > So a lot of small problems not directly related with the migration itself :) > > Esteban > >> >> Sven

Sept. 27, 2018

Top MenuBar does not auto follow font changes

by Sven Van Caekenberghe

Hi, The Top MenuBar does not seem to auto follow font changes, although it picks them uppitiest when you hide/show the menu bar from the Settings. Sven

Sept. 27, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Migrated Artefact to GitHub

by Norbert Hartl

Super! Thanks Norbert > Am 27.09.2018 um 11:26 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi all, > > I've moved the Artefact library to GitHub (https://github.com/pharo-contributions/Artefact) > > I've also made some changes to it in the way and made a 1.7.0 version with: > - support for Pharo7 streams > - a baseline > > So, people using Artifact, you can contribute through pull requests ^^, > Guille > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Sept. 27, 2018

Re: [Pharo-dev] Artifact and PDFExporter for Roassal

by Guillermo Polito

Hi Milton, I've taken 1 hour to migrate Artefact to Github, create a baseline, fix your issue and make a new release. Can you test? https://github.com/pharo-contributions/Artefact Guille On Thu, Sep 13, 2018 at 4:40 PM milton mamani <akevalion(a)gmail.com> wrote: > > > El jue., 13 sept. 2018 a las 14:06, milton mamani (<akevalion(a)gmail.com>) > escribiÃ³: > >> Hi! >> >> I am Milton Mamani I work with Roassal2, and now I am in ESUG-Cagliari, >> and I have tried to load Artefact with the next piece of code, in the last >> Pharo7 image. >> >> Metacello new >> configuration: 'Artefact'; >> smalltalkhubUser: 'RMoD' project: 'Artefact'; >> version: #stable; >> load. >> >> "To load roassal and pdf roassal exporter" >> >> Metacello new >> configuration: 'GraphQLBeta'; >> smalltalkhubUser: 'ObjectProfile' project: 'GraphQL'; >> version: #development; >> load. >> >> Gofer new >> smalltalkhubUser: 'azazael' project: 'RTPDFExporter'; >> package: 'ConfigurationOfRTPDFExporter'; load. >> (Smalltalk at: #ConfigurationOfRTPDFExporter) loadDevelopment >> >> I have a problem, when I tried to export my Roassal-Visualization to pdf >> file with for example this piece of code: >> >> view := RTBoxPlotExample new exampleBoxPlot5 build view. >> stream := 'foo.pdf' asFileReference writeStream. >> >> [RTPDFExporter new >> stream: stream; >> exportView: view ] ensure: [ stream close ] >> >> I get a lot of kind exceptions related with the class: PDFStreamPrinter >> >> In the method visitPDFDataXRefEntry: >> And in the logic of the new Stream classes of Pharo7. >> >> Could you please review Artifact in Pharo7 with this roassal2 >> implementation >> >> Cheers, >> Milton >> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 27, 2018

[ANN] Migrated Artefact to GitHub

by Guillermo Polito

Hi all, I've moved the Artefact library to GitHub ( https://github.com/pharo-contributions/Artefact) I've also made some changes to it in the way and made a 1.7.0 version with: - support for Pharo7 streams - a baseline So, people using Artifact, you can contribute through pull requests ^^, Guille -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 27, 2018

[Pharo 7.0-dev] Build #1272: 22490-It-seems-that-openFileStreamwritable-is-dead-code

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1272 was: SUCCESS. The Pull Request #1827 was integrated: "22490-It-seems-that-openFileStreamwritable-is-dead-code" Pull request url: https://github.com/pharo-project/pharo/pull/1827 Issue Url: https://pharo.fogbugz.com/f/cases/22490 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Norbert Hartl

> Am 25.09.2018 um 17:44 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 25 Sep 2018, at 14:39, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Wow. Very nice, well done. >>> >>> Any chance on some more technical details, as in what 'connected by a message queue for the communication' exactly means ? How did you approach micro services exactly ? >>> >> Sure :) > > Thanks, this is very interesting ! > >> The installation spawns multiple physical machines. All the machines are joined to a docker swarm. The installation is reified as either task or service from the view on the docker swarm. Meaning you instantiate an arbitrary amount of services and docker swarm distributes them among the physical machines. Usually you donât take control which is running where but you can. At this point you have spread dozens of pharo images among multiple machines and each of them has an IP address. Furthermore in docker swarm you have a reification of a network meaning that every instance in a network can see all other instances on this network. Each service can be reached by its service name in that network. Docker swarm does all the iptables/firewall and DNS setup for you. > > Are you happy with docker swarm's availability/fail-over behaviour ? In other words: does it work when one image/instance goes bad, does it detect and restore the missing functionality ? > Yes, Iâm very satisified. Instances are automatically restarted if they crash. And not necessarily on the same machine exactly how I expect it. Docker has something called Healthcheck. You can have a command executed every 20 seconds. I hooked this to a curl command and to your SUnit Rest handler. The rest is writing unit tests for server health. If tests fail in sequence the instances are taken out of operation and are replaced with a new instance. The same is done for updating. Instances are started in a fashion that one instance of the new image is started, if it survives a couple of health checks it is taken operational and an old one is taken out. Then the next new is started... For simple software updates you have zero-downtime deployment. >> In order to have communication between those runtimes we use rabbitmq because you were so nice writing a driver for it ;) The rabbitmq does have a support for cluster setup, meaning each of the physical machines has a rabbitmq installation and they know each other. So it does not matter to which instance you send messages to and on which you register for receiving messages. So every pharo image connects to the service rabbitmq and opens a queue for interaction. > > Same question: does RabbitMQ's clustering work well under stress/problems ? Syncing all queues between all machines sounds quite heavy (I never tried it, but maybe it just works). I did not yet have time to real stress test the queue. And you are right copying between nodes might be a lot but still I have the feeling it is better to have then a single instance but no real reason. We also use huge payloads which might have to change if we encounter problems. > >> Each service like the car sharing opens a queue e.g. /queue/carSharing and listens on it. The broker images are stateful so they open queues like /queue/mobility-map-afdeg32 where afdeg32 is the container id of the instance (hostname in docker). In each request the queue name to reply is sent as a header. So we can make sure that the right image gets the message back. This way we can have sticky sessions keeping volatile data in memory for the lifecycle of a session. There is one worker image which opens a queue /queue/mobility-map where session independent requests can be processed. > > I think I understand ;-) > >> In order to ease development we are sharing code between the broker and the micro service. Each micro service has a -Common package where the classes are in that build the interface. The classes in here are a kind of data entity facades. They use NeoJSON to map to and from a stream. The class name is send with the message as a header so the remote side knows what to materialize. The handling is unified for the four cases >> >> - Request as inquiry to another micro service >> - Response returns values to a Request >> - Error is transferred like a Response but is then signalled on the receiving side >> - Notification connects the announcers on the broker and the micro service side. > > Yes, makes total sense. > >> Asynchronous calls we solved using Promises and Futures. Each async call to the Q becomes a promise (that blocks on #value) and is combined to a future value containing all promises with support to generate a delta of all resolved promises. This we need because you issue a search that takes longer and you want to display results as soon as they are resolved not after all haven been resolved. > > Which Promise/Future framework/library are you using in Pharo ? > We rolled our own. And I donât know about other frameworks. > You did not go for single threaded worker images ? For the micro services yes. They read from the queue one by one and process it. Here I scale out with multiple pharo instances. On the API image we have zinc for HTTP that is a multithreaded server and the clients are polling. Norbert > >> And a lot more. This is a coarse grained overview over the architecture. Iâm happy to answer further questions about this. >> >> Norbert >> >>>> On 25 Sep 2018, at 12:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> As presented on ESUG here is the brief description of one of our current projects. >>>> >>>> Mobility Map >>>> ââââââ >>>> >>>> Mobility Map is a broker for mobility services. It offers multi-modal routing search enabling users to find the best travel options between locations. Travel options include car sharing, bikes, trains, busses etc. Rented cars can be offered for ride sharing on booking time letting other people find it to participate in the ride. Single travel options are combined in travel plans that can be booked and managed in a very easy way. >>>> >>>> For this project main requirements were scalability to serve a large user base and flexibility to add more additional providers to the broker. The application has been realized using web technologies for the frontend and pharo for the backend. Using a microservice architecture combined with a broker it is easy to extend the platform with additional brokers. Deployment is done using docker swarm for distributing dozens of pharo images among multiple server machines connected by a message queue for the communication. Pharo supported that scenario very well enabling us the meet the requirements with less effort. >>>> >>>> Pharo turned out to be a perfect fit to develop the application in a agile way. Small development cycles with continuous integration and continuous delivery enables fast turnarounds for the customers to validate progress. >>>> >>>> This is a screenshot of the search page for multi-modal results: >>>> >>>> >>>> <Screen Shot 2018-09-21 at 16.54.30.png> >>> >>> >> >> > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Nicolas Cellier

Very nice proof that we can leverage efficient and up to date technologies ! Thank you so much for sharing, that's the right way to make Pharo (and Smalltalk) alive and kicking. How did the Pharo IDE help in such context? (did you use debugging facility extensively?). What tool is missing? Le mar. 25 sept. 2018 Ã 17:45, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > > > On 25 Sep 2018, at 14:39, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > >> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> > >> Wow. Very nice, well done. > >> > >> Any chance on some more technical details, as in what 'connected by a > message queue for the communication' exactly means ? How did you approach > micro services exactly ? > >> > > Sure :) > > Thanks, this is very interesting ! > > > The installation spawns multiple physical machines. All the machines are > joined to a docker swarm. The installation is reified as either task or > service from the view on the docker swarm. Meaning you instantiate an > arbitrary amount of services and docker swarm distributes them among the > physical machines. Usually you donât take control which is running where > but you can. At this point you have spread dozens of pharo images among > multiple machines and each of them has an IP address. Furthermore in docker > swarm you have a reification of a network meaning that every instance in a > network can see all other instances on this network. Each service can be > reached by its service name in that network. Docker swarm does all the > iptables/firewall and DNS setup for you. > > Are you happy with docker swarm's availability/fail-over behaviour ? In > other words: does it work when one image/instance goes bad, does it detect > and restore the missing functionality ? > > > In order to have communication between those runtimes we use rabbitmq > because you were so nice writing a driver for it ;) The rabbitmq does have > a support for cluster setup, meaning each of the physical machines has a > rabbitmq installation and they know each other. So it does not matter to > which instance you send messages to and on which you register for receiving > messages. So every pharo image connects to the service rabbitmq and opens a > queue for interaction. > > Same question: does RabbitMQ's clustering work well under stress/problems > ? Syncing all queues between all machines sounds quite heavy (I never tried > it, but maybe it just works). > > > Each service like the car sharing opens a queue e.g. /queue/carSharing > and listens on it. The broker images are stateful so they open queues like > /queue/mobility-map-afdeg32 where afdeg32 is the container id of the > instance (hostname in docker). In each request the queue name to reply is > sent as a header. So we can make sure that the right image gets the message > back. This way we can have sticky sessions keeping volatile data in memory > for the lifecycle of a session. There is one worker image which opens a > queue /queue/mobility-map where session independent requests can be > processed. > > I think I understand ;-) > > > In order to ease development we are sharing code between the broker and > the micro service. Each micro service has a -Common package where the > classes are in that build the interface. The classes in here are a kind of > data entity facades. They use NeoJSON to map to and from a stream. The > class name is send with the message as a header so the remote side knows > what to materialize. The handling is unified for the four cases > > > > - Request as inquiry to another micro service > > - Response returns values to a Request > > - Error is transferred like a Response but is then signalled on the > receiving side > > - Notification connects the announcers on the broker and the micro > service side. > > Yes, makes total sense. > > > Asynchronous calls we solved using Promises and Futures. Each async call > to the Q becomes a promise (that blocks on #value) and is combined to a > future value containing all promises with support to generate a delta of > all resolved promises. This we need because you issue a search that takes > longer and you want to display results as soon as they are resolved not > after all haven been resolved. > > Which Promise/Future framework/library are you using in Pharo ? > > You did not go for single threaded worker images ? > > > And a lot more. This is a coarse grained overview over the architecture. > Iâm happy to answer further questions about this. > > > > Norbert > > > >>> On 25 Sep 2018, at 12:20, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> As presented on ESUG here is the brief description of one of our > current projects. > >>> > >>> Mobility Map > >>> ââââââ > >>> > >>> Mobility Map is a broker for mobility services. It offers multi-modal > routing search enabling users to find the best travel options between > locations. Travel options include car sharing, bikes, trains, busses etc. > Rented cars can be offered for ride sharing on booking time letting other > people find it to participate in the ride. Single travel options are > combined in travel plans that can be booked and managed in a very easy way. > >>> > >>> For this project main requirements were scalability to serve a large > user base and flexibility to add more additional providers to the broker. > The application has been realized using web technologies for the frontend > and pharo for the backend. Using a microservice architecture combined with > a broker it is easy to extend the platform with additional brokers. > Deployment is done using docker swarm for distributing dozens of pharo > images among multiple server machines connected by a message queue for the > communication. Pharo supported that scenario very well enabling us the meet > the requirements with less effort. > >>> > >>> Pharo turned out to be a perfect fit to develop the application in a > agile way. Small development cycles with continuous integration and > continuous delivery enables fast turnarounds for the customers to validate > progress. > >>> > >>> This is a screenshot of the search page for multi-modal results: > >>> > >>> > >>> <Screen Shot 2018-09-21 at 16.54.30.png> > >> > >> > > > > > > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by Esteban Lorenzano

> On 26 Sep 2018, at 15:24, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary > Date: 26 September 2018 at 15:24:49 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, why is test status of this pull request: FAILURE? > > Thanks for clarification, Petr Fischer Is a misleading message. It means merge was done, but for some reason (usually network problems), some tests failed to run. We are working on fix that (but you knowâ¦ time :P). Esteban > > >> There is a new Pharo build available! >> >> The status of the build #1271 was: FAILURE. >> >> The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" >> Pull request url: https://github.com/pharo-project/pharo/pull/1823 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/22483 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by Marcus Denker

Hi, It means that the build for this one merge failedâ¦ build got much more stable over the last weeks, but we still sometimes have crashes (here it seems to be the text render bug) But this is undefended of the merge: the next build then will take this into account. > On 26 Sep 2018, at 15:24, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary > Date: 26 September 2018 at 15:24:49 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, why is test status of this pull request: FAILURE? > > Thanks for clarification, Petr Fischer > > >> There is a new Pharo build available! >> >> The status of the build #1271 was: FAILURE. >> >> The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" >> Pull request url: https://github.com/pharo-project/pharo/pull/1823 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/22483 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > >

Sept. 26, 2018