- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Layout for placing widgets

by Pavel Krivanek

Maybe we should check cassowary https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > I was wondering if there is a layout that we can use to propose > alternate placing layout > for widgets in spec? > > Like > > attached to the left 10pixels rubber band box or fixed size box > 10pixels attached to the right. > > > Stef > >

Oct. 27, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Esteban Lorenzano

> On 27 Oct 2017, at 13:42, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Esteban, could you please give me the instructions to update a Pharo 6.1 image with Iceberg 0.6.1 to 0.6.2 and keep using filetree ? > > Maybe same as these instructions [1] but changing url to 'github://pharo-vcs/iceberg:v0.6.2' ? > > Note that I am asking because you also said we needed to update Metacelloâ¦ here are the notes: DO NOTHING :) I already did the work for you. Esteban > > Thanks in advance, > > > [1] https://github.com/pharo-vcs/iceberg/blob/master/README.md#for-pharo-6 <https://github.com/pharo-vcs/iceberg/blob/master/README.md#for-pharo-6> > > On Fri, Oct 27, 2017 at 6:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit for latest changes. > This version has an important amount of tweak and fixes, but most important is the inclusion of tonel file format (this is default for Pharo 7.0, optional for Pharo 6.1) and introduces a file-per-class format. > The advantages of this format has everything to do with the speed of access (is easier to reconstruct a package like) and the space on disk (methods are usually small but minimum space in disk is usually 4k so we waste a lot of space). Is also a better format for SSD disks. > > To backport Iceberg 0.6.2 I also needed to backport latest version of Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of it available :) > > cheers! > Esteban > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Oct. 27, 2017

Layout for placing widgets

by Stephane Ducasse

Hi I was wondering if there is a layout that we can use to propose alternate placing layout for widgets in spec? Like attached to the left 10pixels rubber band box or fixed size box 10pixels attached to the right. Stef

Oct. 27, 2017

Re: [Pharo-dev] , for vector creation

by Stephane Ducasse

Ok good to know. On Fri, Oct 27, 2017 at 8:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, we have BlInsets that are used for either padding or margin. > > Doru > >> On Oct 26, 2017, at 11:43 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Doru >> >> I was thinking that you would also have BlMargin because Margin is a >> nice concept. >> When I introduced it with Igor it simplified a lot of code in expand, >> shrink and other operations. >> >> Stef >> >> On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. >>> >>> This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). >>> >>> Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. >>> >>> Cheers, >>> Doru >>> >>>> On Oct 26, 2017, at 10:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>> >>>>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>> Hi, >>>>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>> >>>>>> Another question. >>>>>> >>>>>> Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. >>>>> >>>>> No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. >>>>> >>>>> Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. >>>> >>>> I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. >>>> >>>> Doru >>>> >>>>> >>>>>> And what about Rectangle? (Bloc implements own BlRectangle). >>>>> >>>>> These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. >>>>> >>>>> We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). >>>>> >>>>> Doru >>>>> >>>>> >>>>> >>>>>> 2017-10-26 9:26 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>>> #(1 3 4 5 7 -2) asVector >>>>>> >>>>>> Meh. >>>>>> Ugly. >>>>>> >>>>>> { 1. 3. 4. a. b } asVector >>>>>> >>>>>> is the natural consequence. >>>>>> >>>>>> v := (1,3,4,5,7,-2) asVector >>>>>> >>>>>> keeps the parens. But why do I need to do that? >>>>>> >>>>>> Autoformatting messing with my parentheses is just a mistake. >>>>>> I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. >>>>>> >>>>>> And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>>>> >>>>>>> Automatic formatting will turn it into >>>>>>> >>>>>>> vector := 1,3,4,5,7,-2. >>>>>>> >>>>>>> Which is not as nice. >>>>>>> >>>>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: >>>>>>> >>>>>>> vector := width, height, depth. >>>>>>> >>>>>>> >>>>>>> Question: why not extend @ notation? >>>>>>> >>>>>>> x @ y @ z? >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 8:22 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>>>>> >>>>>>>> I also like the , message for those vectors and the concatenation of dimensions makes sense. >>>>>>>> >>>>>>>> vector := (1,3,4,5,7,-2). >>>>>>>> >>>>>>>> looks how it should be. >>>>>>>> >>>>>>>> Readable, easy to translate vector stuff from reference text. >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <astares(a)gmx.de>: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> there might be reasons for an own 2D vector class (instead of using Point). >>>>>>>>> But still I dislike the reimplementation of "," because for me so far it >>>>>>>>> has the meaning of "concatenating things". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Like concatenating coordinates :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here you redefine it to create vector instances and it works only up to three >>>>>>>>> so far. Right? >>>>>>>>> >>>>>>>>> I understand that this gives some similarities with the math notation (1,2) >>>>>>>>> but I personally would prefer to use: >>>>>>>>> >>>>>>>>> 1@2 asVector >>>>>>>>> >>>>>>>>> or Vector2D x: 1 y: 2 >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> T. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >>>>>>>>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>>>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>>>>>>> Betreff: [Pharo-dev] , for vector creation >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As mentioned in the separate thread, we played with introducing the extension: >>>>>>>>>> >>>>>>>>>> , aNumber >>>>>>>>>> ^ BlVector2D x: self y: aNumber >>>>>>>>>> >>>>>>>>>> This means that (10,20) will return a 2D vector. >>>>>>>>>> >>>>>>>>>> We also have (10,20,30) which returns a 3D vector. >>>>>>>>>> >>>>>>>>>> , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. >>>>>>>>>> >>>>>>>>>> Please voice your concerns. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> www.tudorgirba.com >>>>>>>>>> www.feenk.com >>>>>>>>>> >>>>>>>>>> "Every thing should have the right to be different." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "When people care, great things can happen." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "If you interrupt the barber while he is cutting your hair, >>>> you will end up with a messy haircut." >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We are all great at making mistakes." >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > >

Oct. 27, 2017

Re: [Pharo-dev] [ANN] Pharo Consortium New Platinum Member: JPMorgan Chase

by Stephane Ducasse

Thanks Ben. You have an impact and you can continue. Stef On Fri, Oct 27, 2017 at 12:54 PM, Ben Coman <btc(a)openinworld.com> wrote: > Wow! Thats three new platinum announcements in as many days. Great work > guys. > For me this is not just about the money it brings in for additional > engineering resources to improve Pharo > Its the implicit endorsement of the future value these companies expect to > gain from Pharo, and of the open-source consortium model. > Thank you to those that had the vision in the early years to create and > support the consortium. > The future looks bright for me to keep hacking on my favourite programming > environment. > > cheers -ben > > On Thu, Oct 26, 2017 at 2:45 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> The Pharo Consortium is very happy to announce that JPMorgan Chase >> has joined the Consortium as a Platinum Member. >> >> About >> - JPMorgan Chase: https://www.jpmorganchase.com >> - 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 >> >

Oct. 27, 2017

[Pharo 7.0-dev] Build #238: 20592-SizeInMemory-is-not-updated-to-handle-32-and-64-bits-for-WordLayout

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

There is a new Pharo build available! The status of the build #238 was: SUCCESS. The Pull Request #400 was integrated: "20592-SizeInMemory-is-not-updated-to-handle-32-and-64-bits-for-WordLayout" Pull request url: https://github.com/pharo-project/pharo/pull/400 Issue Url: https://pharo.fogbugz.com/f/cases/20592 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 27, 2017

[Pharo 7.0-dev] Build #237: 20600 rename opal compiler encoder from opal encoder to encoder

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

There is a new Pharo build available! The status of the build #237 was: SUCCESS. The Pull Request #404 was integrated: "20600 rename opal compiler encoder from opal encoder to encoder" Pull request url: https://github.com/pharo-project/pharo/pull/404 Issue Url: https://pharo.fogbugz.com/f/cases/20600 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 27, 2017

Re: [Pharo-dev] [ANN] Pharo Consortium New Platinum Member: JPMorgan Chase

by Sean P. DeNigris

Ben Coman wrote > Wow!â¦Thank youâ¦The future looks bright for me to keep hacking on my > favourite programming > environment. +1000. Thanks! Keep pushing!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 27, 2017

[Pharo 7.0-dev] Build #236: 19746-WeakValueDictionary-has-counter-intuitive-behavior

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

There is a new Pharo build available! The status of the build #236 was: SUCCESS. The Pull Request #140 was integrated: "19746-WeakValueDictionary-has-counter-intuitive-behavior" Pull request url: https://github.com/pharo-project/pharo/pull/140 Issue Url: https://pharo.fogbugz.com/f/cases/19746 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 27, 2017

[Pharo 7.0-dev] Build #235: 20606-AlienSunitperformTest-is-failing

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

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

Oct. 27, 2017