September 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1268: 22488-Bootstrapping-from-outside-of-the-repository-broken

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

There is a new Pharo build available! The status of the build #1268 was: SUCCESS. The Pull Request #1826 was integrated: "22488-Bootstrapping-from-outside-of-the-repository-broken" Pull request url: https://github.com/pharo-project/pharo/pull/1826 Issue Url: https://pharo.fogbugz.com/f/cases/22488 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

[Pharo 7.0-dev] Build #1267: 22478 button presenter does not take into account its color

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

There is a new Pharo build available! The status of the build #1267 was: SUCCESS. The Pull Request #1820 was integrated: "22478 button presenter does not take into account its color" Pull request url: https://github.com/pharo-project/pharo/pull/1820 Issue Url: https://pharo.fogbugz.com/f/cases/22478 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

[Pharo 7.0-dev] Build #1266: 22440-Compiler-parseExpression-does-not-set-up-compilation-context-for-method-node

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

There is a new Pharo build available! The status of the build #1266 was: SUCCESS. The Pull Request #1825 was integrated: "22440-Compiler-parseExpression-does-not-set-up-compilation-context-for-method-node" Pull request url: https://github.com/pharo-project/pharo/pull/1825 Issue Url: https://pharo.fogbugz.com/f/cases/22440 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Petr Fischer

> Hi Petr, > > along with Estebanâs request for the error code from allocateExecutablePage can you also see whether use of iceberg is successful the second time you launch Pharo? So start up your virtualbox, try and interact with iceberg, quit if it fails, relaunch and try again? Yes, after the tests were green (second time, after magic happens), Iceberg was also OK - and I mean the whole Iceberg cycle up to creating the Pharo pull request right from the Iceberg UI/image. I recreated whole virtualbox image from scratch and tune some vbox settings - described problems have gone and I am not able to recreate the same situation - let's forget it, it's not the Pharo thing. And finally - I see that a lot of work has been done on Iceberg - it's not even necessary to leave Pharo for a minute due to the final Github pull request in web browser, nice. pf > Also in your steps what do you do to prepare? eg do you boot in virtualbox, return from sleep, or...? > > FYI, allocateExecutablePage uses valloc (IIRC) to get a page from the OS and then uses mprotect to add executable permission to the page before answering the pageâs address as the result of the primitive. The callback machinery then uses the page to provide the executable blue code used in implementing callbacks. The address of a code sequence in the page is what is actually handed out to C code as a fu croon pointer. When external code calls this function pointer the code in the sequence invokes a callback into the vm before returning back to C. Consequently it is key that allocateExecutablePage works correctly. If it doesnât then no callbacks. > > _,,,^..^,,,_ (phone) > > > On Sep 24, 2018, at 11:11 AM, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > > <mime-attachment>

Sept. 26, 2018

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

by Sven Van Caekenberghe

> 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. 25, 2018

[Pharo 7.0-dev] Build #1265: 22479-Imporove-kernel-testing

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

There is a new Pharo build available! The status of the build #1265 was: SUCCESS. The Pull Request #1821 was integrated: "22479-Imporove-kernel-testing" Pull request url: https://github.com/pharo-project/pharo/pull/1821 Issue Url: https://pharo.fogbugz.com/f/cases/22479 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 25, 2018

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

by Esteban Maringolo

Thanks for sharing this Norbert. I'm happy for you as a company, and also for Pharo, this should help promoting it to bystanders, the whole set of tools and libraries helps demonstrating the convenience and applicability of Pharo in "modern" designs (docker, swarms, MQ, microservices, and whatnot). Regards Esteban A. Maringolo El mar., 25 sept. 2018 a las 9:40, Norbert Hartl (<norbert(a)hartl.name>) escribiÃ³: > > > > 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 :) > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. 25, 2018

Re: [Pharo-dev] [ANN] Pharo Consortium upgrade to Platinum: ZWEIDENKER

by Ben Coman

On Tue, 25 Sep 2018 at 20:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > The Pharo Consortium is very happy to announce that ZWEIDENKER has ugraded > to be a Platinum member. > Its great to see your support and commitment to Pharo - in addition to the many direct code contributions. cheers -ben

Sept. 25, 2018

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

by Norbert Hartl

> 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 :) 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. 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. 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. 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. 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. 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. 25, 2018

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Sven Van Caekenberghe

> On 18 Sep 2018, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Of course, we could also extend the basic number parser and allow the native (stored) notation > > 1/3 > 3/2s2 > > Note how that last one should use the more exact #storeOn: notation, not the #printOn: > > I'll have to think about this a bit more, as I can really not choose right now. I am still not sure if we should do this or not, but here is a POC implementation of the above. It implements the following syntax extension (see the class comment of STON for the rest). number int int denominator int denominator scale int frac int exp int frac exp denominator / digits scale s digits STONWriter>>#writeFraction: fraction jsonMode ifTrue: [ self writeFloat: fraction asFloat ] ifFalse: [ writeStream print: fraction numerator; nextPut: $/; print: fraction denominator ] STONWriter>>#writeScaledDecimal: scaledDecimal jsonMode ifTrue: [ self writeFloat: scaledDecimal asFloat ] ifFalse: [ writeStream print: scaledDecimal numerator; nextPut: $/; print: scaledDecimal denominator; nextPut: $s; print: scaledDecimal scale ] Fraction>>#stonOn: stonWriter stonWriter writeFraction: self ScaledDecimal>>#stonOn: stonWriter stonWriter writeScaledDecimal: self STONReader>>parseNumber | negated number | negated := readStream peekFor: $-. number := self parseNumberInteger. (readStream peekFor: $/) ifTrue: [ number := Fraction numerator: number denominator: self parseNumberInteger. (readStream peekFor: $s) ifTrue: [ number := ScaledDecimal newFromNumber: number scale: self parseNumberInteger ] ] ifFalse: [ (readStream peekFor: $.) ifTrue: [ number := number + self parseNumberFraction ]. ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) ifTrue: [ number := number * self parseNumberExponent ] ]. negated ifTrue: [ number := number negated ]. self consumeWhitespace. ^ number Sven

Sept. 25, 2018

[ANN] Pharo Consortium upgrade to Platinum: ZWEIDENKER

by Marcus Denker

The Pharo Consortium is very happy to announce that ZWEIDENKER has ugraded to be a Platinum member. About - ZWEIDENKER: http://zweidenker.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Sept. 25, 2018

[Pharo 7.0-dev] Build #1264: 22471 prepare pharo7.0.0 rc1 release

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

There is a new Pharo build available! The status of the build #1264 was: SUCCESS. The Pull Request #1817 was integrated: "22471 prepare pharo7.0.0 rc1 release" Pull request url: https://github.com/pharo-project/pharo/pull/1817 Issue Url: https://pharo.fogbugz.com/f/cases/22471 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 25, 2018

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

by Sven Van Caekenberghe

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 ? > 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. 25, 2018

[ANN] Success story Mobility Map

by Norbert Hartl

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:

Sept. 25, 2018

[Pharo 7.0-dev] Build #1263: Avoid race conditions between tests by removing parallel runs

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

There is a new Pharo build available! The status of the build #1263 was: SUCCESS. The Pull Request #1824 was integrated: "Avoid race conditions between tests by removing parallel runs" Pull request url: https://github.com/pharo-project/pharo/pull/1824 Issue Url: https://pharo.fogbugz.com/f/cases/22485 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 25, 2018

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Alistair Grant

Hi Sven & Guille, On Tue, 25 Sep 2018 at 10:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Mon, Sep 24, 2018 at 11:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> > On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > >> > Hi Guille, Sven, Esteban and Everyone, >> > >> > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is >> > considered part of the pharo "core" image? >> >> Yes, for me anyway, it is (or should be) part of core. > > > Yes, they are part of the Core image. Simply because an image without any I/O is an image you cannot interact with, so it's kind of useless :) > And an image doing I/O without managing encoding is pretty useless too... Thanks for the confirmation. I suspected this was the case, but didn't want to be wrong later on. > Also, keep in mind that we try to maintain Zn packages in sync with Sven's repository, and we try to keep them loadable/compatible with other pharo versions. > Usually Zn encoders should be stable enough in terms of API and features, but in case you need to extend them in some way we should keep Sven in the loop so we can sync both repositories ^^. Sure, at the moment I can't envisage any required changes. Thanks again, Alistair

Sept. 25, 2018

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Guillermo Polito

On Mon, Sep 24, 2018 at 11:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Guille, Sven, Esteban and Everyone, > > > > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is > > considered part of the pharo "core" image? > > Yes, for me anyway, it is (or should be) part of core. > Yes, they are part of the Core image. Simply because an image without any I/O is an image you cannot interact with, so it's kind of useless :) And an image doing I/O without managing encoding is pretty useless too... Also, keep in mind that we try to maintain Zn packages in sync with Sven's repository, and we try to keep them loadable/compatible with other pharo versions. Usually Zn encoders should be stable enough in terms of API and features, but in case you need to extend them in some way we should keep Sven in the loop so we can sync both repositories ^^. Guille

Sept. 25, 2018

Re: [Pharo-dev] update linux info page again, please [CentOS/RHEL]

by Marcus Denker

Hello, I have added it. https://pharo.org/gnu-linux-installation-64 > On 23 Sep 2018, at 18:32, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: update linux info page again, please [CentOS/RHEL] > Date: 23 September 2018 at 18:32:00 CEST > To: pharo-dev(a)lists.pharo.org > > > Hello, > > please, edit CentOS7 installation page: > https://pharo.org/gnu-linux-installation-64 > > and add workaround for CentOS7 section, wihout this symlink, iceberg is broken: > > (do as root) > cd /usr/lib64 > ln -s libcurl.so.4 libcurl-gnutls.so.4 > > Best solution is to put this in the RPM post installation step (I mean RPM from official Pharo CentOS repository) - but we will wait for this fix for months, maybe years, so, workaround info on that page is necessary and easy to manage. > > More details here: > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624… > > Thanks! pf > > >

Sept. 25, 2018

[ANN] Pharo Consortium New Bronze Member: Spesenfuchs

by Marcus Denker

The Pharo Consortium is very happy to announce that Spesenfuchs has joined the Consortium as a Bronze Member. About - Spesenfuchs: http://spesenfuchs.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Sept. 25, 2018

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Sven Van Caekenberghe

> On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Guille, Sven, Esteban and Everyone, > > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is > considered part of the pharo "core" image? Yes, for me anyway, it is (or should be) part of core. > The reason I ask is that I'd like to know whether the File class (which > is part of the Files-Core package) can count on ZnUTF8Encoder (which is > part of the Zinc-Character-Encoding-Core package) being present in the > image. > > If File can count on ZnUTF8Encoder being present then for FileAttributes > I will make UTF8 encoding / decoding available from File, and thus UTF8 > file names will be supported. If it can't count on ZnUTF8Encoder being > present then File will only be able to handle ascii file names (unless > the names are somehow already UTF8 encoded) and support for UTF8 file > names will effectively be restricted to FileSystem. > > > Thanks, > Alistair >

Sept. 24, 2018

Files-Core and Zinc-Character-Encoding-Core package load sequence

by Alistair Grant

Hi Guille, Sven, Esteban and Everyone, Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is considered part of the pharo "core" image? The reason I ask is that I'd like to know whether the File class (which is part of the Files-Core package) can count on ZnUTF8Encoder (which is part of the Zinc-Character-Encoding-Core package) being present in the image. If File can count on ZnUTF8Encoder being present then for FileAttributes I will make UTF8 encoding / decoding available from File, and thus UTF8 file names will be supported. If it can't count on ZnUTF8Encoder being present then File will only be able to handle ascii file names (unless the names are somehow already UTF8 encoded) and support for UTF8 file names will effectively be restricted to FileSystem. Thanks, Alistair

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Eliot Miranda

Hi Petr, along with Estebanâs request for the error code from allocateExecutablePage can you also see whether use of iceberg is successful the second time you launch Pharo? So start up your virtualbox, try and interact with iceberg, quit if it fails, relaunch and try again? Also in your steps what do you do to prepare? eg do you boot in virtualbox, return from sleep, or...? FYI, allocateExecutablePage uses valloc (IIRC) to get a page from the OS and then uses mprotect to add executable permission to the page before answering the pageâs address as the result of the primitive. The callback machinery then uses the page to provide the executable blue code used in implementing callbacks. The address of a code sequence in the page is what is actually handed out to C code as a fu croon pointer. When external code calls this function pointer the code in the sequence invokes a callback into the vm before returning back to C. Consequently it is key that allocateExecutablePage works correctly. If it doesnât then no callbacks. _,,,^..^,,,_ (phone) > On Sep 24, 2018, at 11:11 AM, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > <mime-attachment>

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Petr Fischer

Thanks for your assistance, but sources of this weird behavior is probably in the virtualization layer: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-September/2… pf > That means > > primAllocateExecutablePage > > failed. > There should be an errorCode value there, that can help us understand better the problem. > > Can you check at it? > > Thanks! > > Esteban > > > On 24 Sep 2018, at 17:49, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > > >

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - solved (probably virtualization problem)

by Petr Fischer

Something very weird happens - my steps: 1) ok, lets run UFFI Tests in Test Runnner 2) 5 tests fails (RED) 3) saved the test output to file (button in test runner) 4) quit from Pharo 5) I forgot to click on the 5 failed tests and generate some PharoDebug.log, so... start Pharo again... 6) lets run UFFI Tests again... 7) bang! all tests OK (GREEN)! WTF? run test again -> all green again (!) Bang! Iceberg clone repo works now... I simply can't explain this. Whole thing (CentOS7 + Pharo) is inside VirtualBox - most probably the virtual image is somehow crippled... Pharo+UFFI+Iceberg is OK, sorry for this mess... pf > This looks like an FFI error... > > Can you try running uFFI tests in your system and sen us the results? > > Tx, > Guille > > On Sun, Sep 23, 2018 at 9:54 PM Petr Fischer via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > Ohh sorry - better screenshot link: > > > > > > > > https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy > > > > > > > > pf > > > > > > > Hi Petr, > > > > > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev > > > <pharo-dev(a)lists.pharo.org> wrote: > > > > > > > > Hello, I want to propose some small fixes to Pharo, it took me hours > > just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > > > > > > > Now I am stuck with this Iceberg error: > > > > https://app.box.com/file/321243070589 > > > > > > I was presented with a login box when I tried to view this. > > > > > > > > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and > > latest CentOS7) - is Iceberg OK on 64bits? > > > > > > Yes, I use it all the time (on Ubuntu 16.04 64 bit). > > > > > > Cheers, > > > Alistair > > > > > > -- > > > > 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. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Esteban Lorenzano

That means primAllocateExecutablePage failed. There should be an errorCode value there, that can help us understand better the problem. Can you check at it? Thanks! Esteban > On 24 Sep 2018, at 17:49, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > >

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Petr Fischer

PharoDebug.log attached pf > Ohh sorry - better screenshot link: > > https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy > > pf > > > > Hi Petr, > > > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev > > <pharo-dev(a)lists.pharo.org> wrote: > > > > > > Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > > > > > Now I am stuck with this Iceberg error: > > > https://app.box.com/file/321243070589 > > > > I was presented with a login box when I tried to view this. > > > > > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? > > > > Yes, I use it all the time (on Ubuntu 16.04 64 bit). > > > > Cheers, > > Alistair >

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - corrected screenshot link

by Guillermo Polito

This looks like an FFI error... Can you try running uFFI tests in your system and sen us the results? Tx, Guille On Sun, Sep 23, 2018 at 9:54 PM Petr Fischer via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Ohh sorry - better screenshot link: > > > > https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy > > > > pf > > > > Hi Petr, > > > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev > > <pharo-dev(a)lists.pharo.org> wrote: > > > > > > Hello, I want to propose some small fixes to Pharo, it took me hours > just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > > > > > Now I am stuck with this Iceberg error: > > > https://app.box.com/file/321243070589 > > > > I was presented with a login box when I tried to view this. > > > > > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and > latest CentOS7) - is Iceberg OK on 64bits? > > > > Yes, I use it all the time (on Ubuntu 16.04 64 bit). > > > > Cheers, > > Alistair > > -- 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. 24, 2018

[Pharo 7.0-dev] Build #1262: 22465 Examples in Number>>#printShowingDecimalPlaces: should be runnable

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

There is a new Pharo build available! The status of the build #1262 was: FAILURE. The Pull Request #1813 was integrated: "22465 Examples in Number>>#printShowingDecimalPlaces: should be runnable" Pull request url: https://github.com/pharo-project/pharo/pull/1813 Issue Url: https://pharo.fogbugz.com/f/cases/22465 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 24, 2018

[ANN] Next Pharo Sprint: Sept 28

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Sept 28, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973620

Sept. 24, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban A. Maringolo

Hi Marcus, Thank you and all the team for this. Best regards, -- Esteban A. Maringolo On 24/09/2018 07:05, Marcus Denker wrote: > Hello, > > We are switching the hosting contract to a more professional one. This > should be active soon. > > This includes a CDN, but it will be active only after we make sure that > the files get invalidated when the > CI uploads them, so this will be in a week or so. > > It should improve things even without the CDN active, though. > > Marcus

Sept. 24, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Marcus Denker

Hello, We are switching the hosting contract to a more professional one. This should be active soon. This includes a CDN, but it will be active only after we make sure that the files get invalidated when the CI uploads them, so this will be in a week or so. It should improve things even without the CDN active, though. Marcus > On 19 Sep 2018, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I will have a look how to improve the situation. > > (I hope to be able to do it by next week). > > Marcus > >> On 19 Sep 2018, at 02:10, Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> >> After sending the previous email I checked the progress and it was aborted due to a network error. >> >> <pharo-cancelled.PNG> >> >> I retried and apparently the speed got to a more reasonable one, with peaks of 300KB/sec. >> >> <pharo-retry.png> >> >> >> My guess is that the bottleneck is at where the files are hosted, and if you attempt to download while maybe there are several CI builds running or something else is using the fileserver bandwidth, then it impacts the overall download speed of those attempting to download just the basic elements. >> >> Regards! >> >> Esteban A. Maringolo >> >> >> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (<emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>>) escribiÃ³: >> Is there a reason why the latest version of the builds linked from the website are not hosted in some CDN, Amazon S3 or similar? >> >> Maybe in Europe the speed is fast, but where I am (Argentina) it is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of 40KB/s. >> >> This is an pitiful boarding experience, that will make many cancel it even before getting to open the downloaded launcher. >> >> <node-pharo.png> >> >> The screenshot shows that is not a problem with my home connection, which isn't the fastest but is "normal" for my use cases. >> >> Regards, >> >> Esteban A. Maringolo >> >> ps: When I finished writing this email, this was the progress... >> <image.png> >

Sept. 24, 2018

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

by Esteban Lorenzano

> 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. 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. 24, 2018

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

by Sven Van Caekenberghe

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 ? Sven

Sept. 24, 2018

Esteban's ChangeLog week of 17 September 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 17 September 2018 to 23 September 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=17/9/2018&to=23/9/2018 ChangeLog ========= 19 September 2018: ------------------ * 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. 18 September 2018: ------------------ * I just [fixed the CI for Calypso](https://github.com/pharo-ide/Calypso/issues/319) (it was failing for Pharo 7.0 because of problems when updating). Now I can start fixing real issues of it :) 17 September 2018: ------------------ * I backported/promoted a new stable vm for Pharo 6.1. This is the one that has been tested for Pharo 7.0alpha already for some time, so things should be fine. Current stable VM is from 2018-07-04 (yeah, eventually we will have a decent semver numbering, but for now this will have to be enough :P) cheers! Esteban

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - corrected screenshot link

by Petr Fischer

Ohh sorry - better screenshot link: https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy pf > Hi Petr, > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev > <pharo-dev(a)lists.pharo.org> wrote: > > > > Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > > > Now I am stuck with this Iceberg error: > > https://app.box.com/file/321243070589 > > I was presented with a login box when I tried to view this. > > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? > > Yes, I use it all the time (on Ubuntu 16.04 64 bit). > > Cheers, > Alistair

Sept. 23, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage

by Alistair Grant

Hi Petr, On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > Now I am stuck with this Iceberg error: > https://app.box.com/file/321243070589 I was presented with a login box when I tried to view this. > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? Yes, I use it all the time (on Ubuntu 16.04 64 bit). Cheers, Alistair

Sept. 23, 2018

iceberg PrimitiveFailed allocateExecutablePage

by Petr Fischer

Hello, I want to propose some small fixes to Pharo, it took me hours just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... Now I am stuck with this Iceberg error: https://app.box.com/file/321243070589 I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest CentOS7) - is Iceberg OK on 64bits? Thanks! pf

Sept. 23, 2018

update linux info page again, please [CentOS/RHEL]

by Petr Fischer

Hello, please, edit CentOS7 installation page: https://pharo.org/gnu-linux-installation-64 and add workaround for CentOS7 section, wihout this symlink, iceberg is broken: (do as root) cd /usr/lib64 ln -s libcurl.so.4 libcurl-gnutls.so.4 Best solution is to put this in the RPM post installation step (I mean RPM from official Pharo CentOS repository) - but we will wait for this fix for months, maybe years, so, workaround info on that page is necessary and easy to manage. More details here: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624… Thanks! pf

Sept. 23, 2018

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

by Nicolas Cellier

Hi Davide, Using decimals is a possibility which already exists, just add a $s at end of the literal. What you suggest is to change the syntax and use decimal as the default, and another notation (or no literal notation at all, just asFloat message send) for floating point numbers. It's worth trying, but IMO, you will encounter these limitations: - decimals currently are implemented as unlimited precision Fraction. For long calculations, they will tend to grow in size and slow down the system (I have developped a symbolic calculation library in Smalltalk 30 yeras ago and thus used the Fraction extensively, so I know what it can cost). - decimals currently are not decimals but arbitrary fractions (for example 2.0s / 3 will be represented as Fraction 2/3 internally). But they print as a rounded decimal representation which can't convert back to the same number, and thus is not the most convenient for REPL style. - most decimals operations are slower than floating point operations. Suggested notations like aaa.bbb(cccc) for a repeating pattern cccc could be indeed used to deal with REPL problem. Or we could emulate some limited precision decimals (preferably with floating point). But it's hard to address all the issues above together. For simple geometry problems we soon need Algebraic numbers, and then transcendental, so the usefulness of unlimited fraction is limited anyway. In practice, we rapidly need approximations, that's where highly optimized and carfully thought floating point shine... Personnally, if Pharo want to go down that road, I would at least keep a literal notation for floating point, given the universality and interest of such numbers. Le dim. 23 sept. 2018 Ã 16:31, Davide Grandi <grndvd63m06f704u(a)gmail.com> a Ã©crit : > > *rational number* > CORRECT, for any BASE and any string : > > at worst, repeating decimals (eg [TYPO -->0,1<--] 0.1 in base 3 = 1/3 ~ > 0.333...), that are ultimately fractions. > > but for 10, 2 and 5 bases and combinations thereof (Z = 2r, 5r, 10r, 20r, > ...), any string ZrXXX.YYY will lead to a decimal number with finite and > precise number of digits. > > ... or, maybe, I'm wrong and insisting on wrong premises and conclusions > in front of all the public... > > Davide Grandi > > On 19/09/2018 22:54, Julien wrote: > > Hello, > > Ok, I read all the mails. I see your point about not cancelling the > possibility to use #to:by: on any Number. > > However, the remark from David Grandi seems really relevant to me. > > You can NOT write anything else than a *rational number* when writing a > literal using the XXX.XXX pattern. > > I think it would be legit to generate scaled decimal by default from float > literals and to be able to get Float only by either explicitly specify it > (#asFloat, etcâ¦) or because of computation that lead to a Float (e.g. the > need to approach an irrational number ?). > > I would be curious to see the impact of such change in the compiler on the > system. > > Maybe a first step is indeed to implement a rule in Renraku to encourage > people to use ScaledDecimals. > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > Le 19 sept. 2018 Ã 09:22, Davide Grandi <grndvd63m06f704u(a)gmail.com> a > Ã©crit : > > > 0.0 to: 1.0 by: 0.1 > Receiver and arguments, lexically (the dot), are float BUT > are written as decimal number (zero, one, one tenth). > > I think that in a text you can ONLY write "decimal" numbers or (in bases > other than 10 [or with factors other than 2^x and 5 ?]), at worst, > repeating decimals > (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. > > So, may be, if the receiver or an argument is a float the compiler may > issue a warning and compile to non-float, if receiver or arguments are > computed ... there should be a default behaviour. > > Best regards, > > Davide Grandi > (PS : I work mainly in an ERP that has only integers ... and doubles) > > On 18/09/2018 11:52, Guillaume Larcheveque wrote: > > Maybe #to:by: should convert its parameters in Fraction to avoid Floats > problems (not sure, just an idea) > > 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 18 Sep 2018, at 11:13, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> On Tue, Sep 18, 2018 at 11:06 AM Julien <julien.delplanque(a)inria.fr> >> wrote: >> >>> Hello, >>> >>> I realised that it is possible to create an interval of floats. >>> >>> I think this is bad because, since intervals are computed by >>> successively adding a number, it might result in precision errors. >>> >>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30000000000000004 0.4 >>> 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0) >>> >>> The correct (precise) way to do it would be to use ScaledDecimal: >>> >>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 >>> 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) >>> >>> I opened an issue about it: >>> https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by… >>> >>> And Iâd like to discuss this with you. >>> >>> What do you think? >>> >> >> Well, I think it's a matter of balance :) >> >> #to:by: is defined in Number. So we could, for example, cancel it in >> Float. >> However, people would still be able to do >> >> 1 to: 1.0 by: 0.1 >> >> Which would still show problems. >> >> Nevertheless, I have seen this a lot of times. >> >> 0.0 to: 1.0 by: 0.1 >> >> Is a common use case. >> >> >> And moreover, we could try to do >> >> 1 to: 7 by: (Margin fromNumber: 1) >> >> And even worse >> >> 1 to: Object new by: (Margin fromNumber: 1) >> >> I think adding type-validations all over the place is not a good >> solution, and is kind of opposite to our philosophy... >> >> So we should >> - document the good usages >> - document the bad ones >> - and live with the fact that we have a relaxed type system that will >> fail at runtime :) >> >> yup. >> But not cancel. >> >> Esteban >> >> >> Guille >> >> -- > *Guillaume Larcheveque* > > > -- > Ing. Davide Grandi > email : davide.grandi(a)mclink.it > mobile : +39 339 7468 778 > >

Sept. 23, 2018

Re: [Pharo-dev] [rmod] Float should not implement #to:, #to:by:, etc...

by Davide Grandi

> *rational number* CORRECT, for any BASE and any string : > at worst, repeating decimals (eg [TYPO -->0,1<--] 0.1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. but for 10, 2 and 5 bases and combinations thereof (Z = 2r, 5r, 10r, 20r, ...), any string ZrXXX.YYY will lead to a decimal number with finite and precise number of digits. ... or, maybe, I'm wrong and insisting on wrong premises and conclusions in front of all the public... Â Â Â Davide Grandi On 19/09/2018 22:54, Julien wrote: > Hello, > > Ok, I read all the mails. I see your point about not cancelling the > possibility to use #to:by: on any Number. > > However, the remark from David Grandi seems really relevant to me. > > You can NOT write anything else than a *rational number* when writing > a literal using the XXX.XXX pattern. > > I think it would be legit to generate scaled decimal by default from > float literals and to be able to get Float only by either explicitly > specify it (#asFloat, etcâ¦) or because of computation that lead to a > Float (e.g. the need to approach an irrational number ?). > > I would be curious to see the impact of such change in the compiler on > the system. > > Maybe a first step is indeed to implement a rule in Renraku to > encourage people to use ScaledDecimals. > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650Â VilleneuveÂ d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > >> Le 19 sept. 2018 Ã 09:22, Davide Grandi <grndvd63m06f704u(a)gmail.com >> <mailto:grndvd63m06f704u@gmail.com>> a Ã©crit : >> >> > 0.0 to: 1.0 by: 0.1 >> Receiver and arguments, lexically (the dot), are float BUT >> are written as decimal number (zero, one, one tenth). >> >> I think that in a text you can ONLY write "decimal" numbers or (in >> bases other than 10 [or with factors other than 2^x and 5 ?]), at >> worst, repeating decimals >> (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. >> >> So, may be, if the receiver or an argument is a float the compiler >> may issue a warning and compile to non-float, if receiver or >> arguments are computed ... there should be a default behaviour. >> >> Best regards, >> >> Â Â Davide Grandi >> (PS : I work mainly in an ERP that has only integers ... and doubles) >> >> On 18/09/2018 11:52, Guillaume Larcheveque wrote: >>> Maybe #to:by: should convert its parameters in Fraction to avoid >>> Floats problems (not sure, just an idea) >>> >>> 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>>: >>> >>>> On 18 Sep 2018, at 11:13, Guillermo Polito >>>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> >>>> wrote: >>>> >>>> On Tue, Sep 18, 2018 at 11:06 AM Julien >>>> <julien.delplanque(a)inria.fr >>>> <mailto:julien.delplanque@inria.fr>> wrote: >>>> >>>> Hello, >>>> >>>> I realised that it is possible to create an interval of floats. >>>> >>>> I think this is bad because, since intervals are computed >>>> by successively adding a number, it might result in >>>> precision errors. >>>> >>>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 >>>> 0.30000000000000004 0.4 0.5 0.6000000000000001 >>>> 0.7000000000000001 0.8 0.9 1.0) >>>> >>>> The correct (precise) way to do it would be to use >>>> ScaledDecimal: >>>> >>>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 >>>> 0.3s1 0.4s1 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) >>>> >>>> I opened an issue about it: >>>> https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by… >>>> <https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by…> >>>> >>>> And Iâd like to discuss this with you. >>>> >>>> What do you think? >>>> >>>> >>>> Well, I think it's a matter of balance :) >>>> >>>> #to:by: is defined in Number. So we could, for example, cancel >>>> it in Float. >>>> However, people would still be able to do >>>> >>>> 1 to: 1.0 by: 0.1 >>>> >>>> Which would still show problems. >>> Nevertheless, I have seen this a lot of times. >>> >>> 0.0 to: 1.0 by: 0.1 >>> >>> Is a common use case. >>>> >>>> And moreover, we could try to do >>>> >>>> 1 to: 7 by: (Margin fromNumber: 1) >>>> >>>> And even worse >>>> >>>> 1 to: Object new by: (Margin fromNumber: 1) >>>> >>>> I think adding type-validations all over the place is not a >>>> good solution, and is kind of opposite to our philosophy... >>>> >>>> So we should >>>> Â - document the good usages >>>> Â - document the bad ones >>>> Â - and live with the fact that we have a relaxed type system >>>> that will fail at runtime :) >>> yup. >>> But not cancel. >>> >>> Esteban >>>> >>>> Guille >>> >>> -- >>> *Guillaume Larcheveque* >>> -- Ing. Davide Grandi email : davide.grandi(a)mclink.it mobile : +39 339 7468 778

Sept. 23, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

I understand, I'm a heavy user of P2P for most of what's possible, even have a , but HTTP CDNs exists for a reason, which is "distributed availability" and low latency. If we add a bitorrent client as a requirement to have reasonable download speed then you're adding one extra step to the whole onboarding experience. Maybe instead of using a CDNs we can think of using mirrors, but then if the mirror can't withstand the load, you end up in the same situation. Regards, Esteban A. Maringolo El sÃ¡b., 22 sept. 2018 a las 2:25, ponyatov (<dponyatov(a)gmail.com>) escribiÃ³: > I say not about size but *distributed availability*. > > Community members can hold many torrent peers let anybody download > minimizing problems with networks, servers etc, see the topic title. > > PS: maybe in 2048 people will have distributed Smalltalk, but not in this > life with the image hell > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Sept. 22, 2018

[Pharo 7.0-dev] Build #1261: Bug fix for bindings to inherited pool dictionaries (issue 22470)

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

There is a new Pharo build available! The status of the build #1261 was: FAILURE. The Pull Request #1816 was integrated: "Bug fix for bindings to inherited pool dictionaries (issue 22470)" Pull request url: https://github.com/pharo-project/pharo/pull/1816 Issue Url: https://pharo.fogbugz.com/f/cases/22470 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 22, 2018

Re: [Pharo-dev] Pharo Downloads are sluggish

by ponyatov

I say not about size but *distributed availability*. Community members can hold many torrent peers let anybody download minimizing problems with networks, servers etc, see the topic title. PS: maybe in 2048 people will have distributed Smalltalk, but not in this life with the image hell -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 22, 2018

[Pharo 7.0-dev] Build #1260: 22432 New Release test: NoUnusedTemporaryVariablesLeftTest

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

There is a new Pharo build available! The status of the build #1260 was: FAILURE. The Pull Request #1782 was integrated: "22432 New Release test: NoUnusedTemporaryVariablesLeftTest" Pull request url: https://github.com/pharo-project/pharo/pull/1782 Issue Url: https://pharo.fogbugz.com/f/cases/22432 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 21, 2018

Re: [Pharo-dev] Mailing list Archive - Bandwidth Limit Exceeded

by Marcus Denker

Fixed. > On 21 Sep 2018, at 09:50, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I will check with support. > >> On 21 Sep 2018, at 09:49, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi Marcus, >> >> I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching >> his/her bandwidth limit. Please try again later." message on http://lists.pharo.org >> >> If I remember correctly we already had this one or two years ago. >> >> Thanks >> T. >

Sept. 21, 2018

Re: [Pharo-dev] Mailing list Archive - Bandwidth Limit Exceeded

by Marcus Denker

I will check with support. > On 21 Sep 2018, at 09:49, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Marcus, > > I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching > his/her bandwidth limit. Please try again later." message on http://lists.pharo.org > > If I remember correctly we already had this one or two years ago. > > Thanks > T.

Sept. 21, 2018

Mailing list Archive - Bandwidth Limit Exceeded

by Torsten Bergmann

Hi Marcus, I receive a "Bandwidth Limit Exceeded - The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later." message on http://lists.pharo.org If I remember correctly we already had this one or two years ago. Thanks T.

Sept. 21, 2018

Deprecation guide for methods, classes and packages

by Torsten Bergmann

Hi, >From Bug #20900/ PR 1818 it looked like it is not really clear on how to "deprecate" correctly. Therefore I summarized and wrote a short guide following what we contributors used as best practice so far. Also read [1], [2] and [3] and check some of the deprecation settings in the Pharo settings browser. Just open SettingsBrowser and search for "Depre". I write this mail to "pharo-dev" with CC: "pharo-users" list - because of common interest. But comments and replies should please go to "pharo-dev" so we do not disrupt the thread too much. Thanks! Please review what I wrote and ideally we can put the text or a link to it as "Deprecation guide" into the documentation / wiki / ... on GitHub afterwards. Hope this helps a little bit. Thanks T. [1] https://en.wikipedia.org/wiki/Deprecation [2] https://www.peteruhnak.com/blog/2015/08/06/transforming-deprecated-code-wit… [3] https://pharoweekly.wordpress.com/2016/06/17/automatic-deprecation-refactor… ------------------------------------------------------------------------------------------------------------------------------ In any Pharo version we have a special package hosting deprecated methods and classes. This allows smooth migration for Pharo users as code should still load and runs to some extent - but deprecation warnings and possibly a helping hand (in form of automatic code transformations) could be given to support migration. As we currently work on Pharo7 there is a "Deprecated70" package in the image hosting deprecated methods and classes intended to be removed for Pharo 8. When Pharo 7 is released the users can easily spot the deprecations - also because they are striked through (more on this below). When Pharo 8 iteration starts the "Deprecated70" will be replaced with an empty "Deprecated80" package. DEPRECATING METHODS =================== If you deprecate a METHOD use #deprecated: message and switch it to be an extension method in *Deprecated70*. If the method could be replaced by calling another method then dispatch the call to the new method and ideally provide a transformation so next time the old method is called the sender method is automagically rewritten and could be adopted/migrated: oldMethod "An old method we do not use anymore. But luckily there is a replacement." self deprecated: 'Please use #newMethod instead' transformWith: '`@receiver oldMethod' -> '`@receiver newMethod'. ^ self newMethod So if there is a method like foo self oldMethod sending the old deprecated method it will be migrated to foo self newMethod as soon as foo, the oldMethod and the transformation is called. If the automatically migrated method is under version control (Monticello or git) you will easily see that #foo was modified. In case there is no replacement for a method you would like to deprecate then it is best to throw an error when it is used: veryOldMethod "A very old method hopefully nobody uses. So we do no provide a replacement." self deprecated: 'The method #veryOldMethod is deprecated without any replacement'. ^ self error: 'Do not use #veryOldMethod anymore' Note that the method is striked through in the Pharo system browser in both cases to show that it should not be used anymore. In the standard image calling a deprecated method is logged on the Transcript and flagged with a warning dialog. This should help users and maintainers of external packages to easily spot when they still use deprecated code. You can change these settings in Pharo Settings Browser under Tools -> Debugging -> Deprecation Handling. DEPRECATING CLASSES =================== If you deprecate a CLASS implement #isDeprecated on class side to return true and move it to package "Deprecated70" Ideally write in the class comment why it is deprecated and if there is a replacement class what to use instead Object subclass: #OldClass instanceVariableNames: '' classVariableNames: '' package: 'Deprecated70-OldTag' and comment to explain the reasons: OldClass comment: 'Use NewClass instead'. and implement in class side method category 'testing' isDeprecated "We do not need this class anymore" ^true Note that the class is striked through in the system browser. DEPRECATING PACKAGES ==================== If you deprecate a PACKAGE then rename it with "Deprecated" in the name. Let the class side of the package manifest (typically a subclass of PackageManifest within the package) als return #isDeprecated with true. In the class comment of the package manifest (which also serves as package comment) explain why the package is deprecated and if there is a replacement or not. Example: your package name is "OldPackage-Core", so the new name is "OldPackage-Deprecated-Core". Create a manifest or use the existing one. A Manifest should be a subclass of PackageManifest and should be categorized within a 'Manifest' tag. PackageManifest subclass: #ManifestOldPackageCore instanceVariableNames: '' classVariableNames: '' package: 'OldPackage-Deprecated-Core-Manifest' and comment to explain the reasons: ManifestOldPackageCore comment: 'This package is not useful anymore. Check NewPackage for replacement'. and implement in class side method category 'testing' isDeprecated "We do not need this package anymore" ^true Note that the manifest class and the package is striked through in the system browser. Be aware that a deprecated package might be removed completely already in the next Pharo major version iteration.

Sept. 21, 2018

Re: [Pharo-dev] Debugger should step silently over #halt

by Ben Coman

On Fri, 21 Sep 2018 at 01:51, Tim Mackinnon <tim(a)testit.works> wrote: > I never knew it did that - but it makes sense. Presumably pressing resume > then activated them again right? > yes. Though IIUC its not so much that they were deactivated, but more like the system goes... I hit a halt, hey I'm already halted, so no-op. cheers -ben > > Tim > > Sent from my iPhone > > On 20 Sep 2018, at 08:42, Ben Coman <btc(a)openinworld.com> wrote: > > I'll often put several breakpoints in code like this... > ``` > debug := true. > "Somewhere else in application code..." > debug ifTrue: [ self halt ]. > 1 + 1. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 2 + 2. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 3 + 3. "Representing some longer bit of application code" > ``` > While stepping <Over> code after hitting the first halt, > I am used to subsequent halts being silently stepped over. > I just confirmed this with > http://files.pharo.org/platform/Pharo6.0-win.zip > and also build 60541 started from PharoLauncher. > > However build 71231 and build 60542 do not silently step over a #halt. > Each produces slightly different results (pics attached). > <P01-Double-Halt-Pharo7.png> > <P02-Double-Halt-Pharo60542.png> > > I've logged an issue... > > https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… > > cheers -ben > >

Sept. 20, 2018

Re: [Pharo-dev] Debugger should step silently over #halt

by Tim Mackinnon

I never knew it did that - but it makes sense. Presumably pressing resume then activated them again right? Tim Sent from my iPhone > On 20 Sep 2018, at 08:42, Ben Coman <btc(a)openinworld.com> wrote: > > I'll often put several breakpoints in code like this... > ``` > debug := true. > "Somewhere else in application code..." > debug ifTrue: [ self halt ]. > 1 + 1. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 2 + 2. "Representing some longer bit of application code" > debug ifTrue: [ self halt ]. > 3 + 3. "Representing some longer bit of application code" > ``` > While stepping <Over> code after hitting the first halt, > I am used to subsequent halts being silently stepped over. > I just confirmed this with http://files.pharo.org/platform/Pharo6.0-win.zip > and also build 60541 started from PharoLauncher. > > However build 71231 and build 60542 do not silently step over a #halt. > Each produces slightly different results (pics attached). > <P01-Double-Halt-Pharo7.png> > <P02-Double-Halt-Pharo60542.png> > > I've logged an issue... > https://pharo.fogbugz.com/f/cases/22474/Debugger-should-step-silently-over-… > > cheers -ben

Sept. 20, 2018