October 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by henry

Yes well it is an extension to what you found as I combined with eventual references such that it computes in a single thread. - HH On Sat, Oct 28, 2017 at 23:59, Ben Coman <[btc(a)openinworld.com]("mailto:btc@openinworld.com")> wrote: > On Thu, Oct 26, 2017 at 12:00 AM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >> I disabled vatId authorization in version 3, located in SessionOperations>> processIWant | SessionOperations>>processIAm: . >> >> I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. >> >> ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. >> >> [https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr…"https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr…") >> >> For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. >> >> [http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz]("http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz") >> [http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz]("http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz") >> >> The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. > > Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" > [https://en.wikipedia.org/wiki/Linda_(coordination_language)]("https://en.wikipedia.org/wiki/Linda_(coordination_language)") > [http://www.cs.yale.edu/publications/techreports/tr984.pdf]("http://www.cs.yale.edu/publications/techreports/tr984.pdf") > > cheers -ben

Oct. 29, 2017

Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by Ben Coman

On Thu, Oct 26, 2017 at 12:00 AM, henry <henry(a)callistohouse.club> wrote: > I disabled vatId authorization in version 3, located in SessionOperations>>processIWant > | SessionOperations>>processIAm:. > > I was asked to disseminate my news to Pharo Users, hello there. I was > asked to describe ParrotTalk well, provide use cases and adopters of its > use. Alright, I will give an attempt. > > ParrotTalk is an encrypted connection framework. Currently allowing > anonymous 2048-bit key negotiation to establish user-provided encryption > cipher and user-provided encoding and decoding, both through a provided > SessionAgentMap to a starting SessionAgent server. Please look in the test > case ThunkHelloWorldTest for building these maps and running a connection > iwth data passing after encryption is established. There is a 4-way > negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 > signature validation and DH 2048 primes to establish the key used within > the selected Cipher. The Cipher and Encoder are selected by name through > the negotiation protocol. Currently three Ciphers are selectable, AESede, > DESede, and DES. There are two encoders tested, asn1der, and Bytes. This > protocol is described here, in this document. > > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ > ParrotTalkFrameDesign-3.5.pdf > > For as to use cases, this encrypted connection has no third party, > man-in-the-middle situation by not using Certificates. As such, this is a > tight implementation of NSA-proof encryption without explicit authorization > beyond knowledge of a host:port. The use cases involve any communication > desired to be encrypted with such high encryption. The support will last my > lifetime, so we have a settled solution, here in the third version, > provided here. It requires version 111 of Cryptography, as a prerequisite. > Both run on Squeak and Pharo. > > http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz > http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz > > The current use is with my hubbub system, a promise-based distributed > object implementation. I am working to bring ParrotTalk to Java and allow > hubbub to operate interdependently between Squeak, Pharo, Java and any > other languages which can support ParrotTalk and STON. My latest efforts > with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on > eLinda. > Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" https://en.wikipedia.org/wiki/Linda_(coordination_language) http://www.cs.yale.edu/publications/techreports/tr984.pdf cheers -ben

Oct. 29, 2017

Re: [Pharo-dev] Layout for placing widgets

by Thierry Goubier

Hi Pavel, Le 28/10/2017 Ã 22:29, Pavel Krivanek a Ã©critÂ : > Hi Thierry, > > your repository mentions the MIT license but the original license of the > Cassowary package was LGPL. Is is a different code? I ported the original, public domain smalltalk implementation of Cassowary. Regards, Thierry > Cheers, > -- Pavel > > 2017-10-28 21:43 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Le 28/10/2017 Ã 16:26, Stephane Ducasse a Ã©critÂ : > > I was reading ... > I will see if I can load cassowary in Pharo. > > > https://github.com/ThierryGoubier/Cassowary > <https://github.com/ThierryGoubier/Cassowary> > > Done two years ago. > > Thierry > > > > On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse > <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > > Ok then may be we should give a try to use. Tx for the links. > > Stef > > On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman > <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > 2017-10-27 19:13 GMT+02:00 Stephane Ducasse > <stepharo.self(a)gmail.com > <mailto:stepharo.self@gmail.com>>: > > > 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. > > > > On Oct 27, 2017, at 12:59 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com > <mailto:pavel.krivanek@gmail.com>> > wrote: > > Maybe we should check cassowary > > https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… > <https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const…> > > > > On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse > <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> > wrote: > > > Pavel I do not think that cassowary is good for us. > > > > Do you mean Cassowary in particular, or constraint based > UI in general? > > My naive first impression is, if Cassowary is good > enough for Apple... > https://news.ycombinator.com/item?id=9846992 > <https://news.ycombinator.com/item?id=9846992> > https://www.quora.com/Should-I-use-Auto-Layout > <https://www.quora.com/Should-I-use-Auto-Layout> > > and Google (search here for "solver")... > https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ > <https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/> > > such that "in 2016, both iOS and Android have > first-party layout systems > based on Cassowary." > https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… > <https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th…> > > then it seems worth some analysis, and discussion of > better alternatives. > > > Coincidentally, I see a Smalltalk implementation is > available... > http://www.squeaksource.com/Cassowary.html > <http://www.squeaksource.com/Cassowary.html> > https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf > <https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf> > > > For balance, some points against AutoLayout, but some > alternatives also seem > to use Cassowary solver... > https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… > <https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto…> > https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… > <https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th…> > https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… > <https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y…> > https://cocoacasts.com/working-with-stack-views/ > <https://cocoacasts.com/working-with-stack-views/> > > > cheers -ben > > > > >

Oct. 28, 2017

Re: [Pharo-dev] , for vector creation

by Nicolas Cellier

Just a few notes: 1) 4 , 2 , 3 , 5 looks too much like Shlemiel the painter, ok for short vector input, but not even for printing (think re-interpreting) 2) 1 x + 2 y + 3 z might look nice. Exactly like 1+2i (Complex) or 1+2i+3j+4k (Quaternion) But for the sake of efficiency, I had to introduce (1 i: 2) otherwise interpretng a complex matrix was too much expensive (compared to Matlab) 3) as Doru said, there are many possible conflicts for Number>>, I'm pretty sure that Jun was using it too for this reason I removed it from Smallapack 2017-10-27 19:12 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Todd Blanchard

Actually, Apple's "autolayout" is Cassowary. It is kind of inconvenient to use as is. However there are some very nice libraries. One I have used on a couple iOS projects is called PureLayout. https://github.com/PureLayout/PureLayout It has nice methods like aView autoAlignAxis: AxisHorizontal toSameAxisOfView: anotherView or aView autoCenterInSuperviewWithInsets: layoutInsets as to license: "The original implementation in OTI Smalltalk is in the public domain;" http://constraints.cs.washington.edu/cassowary/ If Thierry based his port on that version, it should be all good. I'm a fan of PureLayout - very easy to use. > On Oct 28, 2017, at 7:07 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Did you try? > I always pay attention to things that should iterate a while and > stabilise. Now I may be wrong. > I have cassowary on my machine. > I worked long time on constraints and I thought that apple has a > better model with anchor and rubber band. > > Stef > > On Sat, Oct 28, 2017 at 12:36 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> On Sat, 2017-10-28 at 10:48 +0200, Stephane Ducasse wrote: >>> Pavel I do not think that cassowary is good for us. >> >> Why? >> >> Jan >> >>> >>> >>> On Sat, Oct 28, 2017 at 2:37 AM, Todd Blanchard <tblanchard(a)mac.com> >>> wrote: >>>> Does that load as part of Bloc? >>>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek@gmail. >>>> com> >>>> wrote: >>>> >>>> Maybe we should check cassowary >>>> >>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/# >>>> ui-constraints >>>> >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.co >>>> m>: >>>>> >>>>> 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. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Pavel Krivanek

Hi Thierry, your repository mentions the MIT license but the original license of the Cassowary package was LGPL. Is is a different code? Cheers, -- Pavel 2017-10-28 21:43 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 28/10/2017 Ã 16:26, Stephane Ducasse a Ã©crit : > >> I was reading ... >> I will see if I can load cassowary in Pharo. >> > > https://github.com/ThierryGoubier/Cassowary > > Done two years ago. > > Thierry > > > >> On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> >>> Ok then may be we should give a try to use. Tx for the links. >>> >>> Stef >>> >>> On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>>> >>>>>> 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. >>>>>> >>>>> >>>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>> wrote: >>>>> >>>>> Maybe we should check cassowary >>>>> >>>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints- >>>>> part-1/#ui-constraints >>>>> >>>> >>>> >>>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> Pavel I do not think that cassowary is good for us. >>>>> >>>> >>>> >>>> Do you mean Cassowary in particular, or constraint based UI in general? >>>> >>>> My naive first impression is, if Cassowary is good enough for Apple... >>>> https://news.ycombinator.com/item?id=9846992 >>>> https://www.quora.com/Should-I-use-Auto-Layout >>>> >>>> and Google (search here for "solver")... >>>> https://academy.realm.io/posts/cool-constraintlayout-droidco >>>> n-boston-2017/ >>>> >>>> such that "in 2016, both iOS and Android have first-party layout systems >>>> based on Cassowary." >>>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-l >>>> ayout-how-do-they-compare/ >>>> >>>> then it seems worth some analysis, and discussion of better >>>> alternatives. >>>> >>>> >>>> Coincidentally, I see a Smalltalk implementation is available... >>>> http://www.squeaksource.com/Cassowary.html >>>> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >>>> >>>> >>>> For balance, some points against AutoLayout, but some alternatives also >>>> seem >>>> to use Cassowary solver... >>>> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_ >>>> i_dont_use_autolayout/ >>>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-l >>>> ayout-how-do-they-compare/ >>>> https://makeapppie.com/2015/10/28/why-stack-views-are-your- >>>> best-friend-if-you-hate-auto-layout/ >>>> https://cocoacasts.com/working-with-stack-views/ >>>> >>>> >>>> cheers -ben >>>> >>>> >>>> > >

Oct. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Thierry Goubier

Le 28/10/2017 Ã 16:26, Stephane Ducasse a Ã©critÂ : > I was reading ... > I will see if I can load cassowary in Pharo. https://github.com/ThierryGoubier/Cassowary Done two years ago. Thierry > > On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Ok then may be we should give a try to use. Tx for the links. >> >> Stef >> >> On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>>> >>>>> 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. >>> >>> >>>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> >>>> Maybe we should check cassowary >>>> >>>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… >>> >>> >>> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>>> >>>> Pavel I do not think that cassowary is good for us. >>> >>> >>> Do you mean Cassowary in particular, or constraint based UI in general? >>> >>> My naive first impression is, if Cassowary is good enough for Apple... >>> https://news.ycombinator.com/item?id=9846992 >>> https://www.quora.com/Should-I-use-Auto-Layout >>> >>> and Google (search here for "solver")... >>> https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ >>> >>> such that "in 2016, both iOS and Android have first-party layout systems >>> based on Cassowary." >>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >>> >>> then it seems worth some analysis, and discussion of better alternatives. >>> >>> >>> Coincidentally, I see a Smalltalk implementation is available... >>> http://www.squeaksource.com/Cassowary.html >>> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >>> >>> >>> For balance, some points against AutoLayout, but some alternatives also seem >>> to use Cassowary solver... >>> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… >>> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >>> https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… >>> https://cocoacasts.com/working-with-stack-views/ >>> >>> >>> cheers -ben >>> >>>

Oct. 28, 2017

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

by Sean P. DeNigris

EstebanLM wrote > I backported lastest Iceberg version to Pharo 6.1 Awesome! Which image number has this? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 28, 2017

Re: [Pharo-dev] Zinc and Zodiac - Synching/Contributing

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Hell, I haven't even contributed to Pharo 7 yet. It seems like things are > still in flux all the time. I definitely understand the feeling! Although, one day for fun I fixed a little bug following Guille's instructions [1] and found it pretty straightforward. I do not miss slices. In fact updating Fogbugz was harder than committing the fix ha ha. 1. https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 28, 2017

Re: [Pharo-dev] Layout for placing widgets

by Stephane Ducasse

I was reading ... I will see if I can load cassowary in Pharo. On Sat, Oct 28, 2017 at 4:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Ok then may be we should give a try to use. Tx for the links. > > Stef > > On Sat, Oct 28, 2017 at 4:18 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> 2017-10-27 19:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> 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. >> >> >>> On Oct 27, 2017, at 12:59 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> >>> Maybe we should check cassowary >>> >>> https://croisant.net/blog/2016-02-24-ui-layout-constraints-part-1/#ui-const… >> >> >> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Pavel I do not think that cassowary is good for us. >> >> >> Do you mean Cassowary in particular, or constraint based UI in general? >> >> My naive first impression is, if Cassowary is good enough for Apple... >> https://news.ycombinator.com/item?id=9846992 >> https://www.quora.com/Should-I-use-Auto-Layout >> >> and Google (search here for "solver")... >> https://academy.realm.io/posts/cool-constraintlayout-droidcon-boston-2017/ >> >> such that "in 2016, both iOS and Android have first-party layout systems >> based on Cassowary." >> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >> >> then it seems worth some analysis, and discussion of better alternatives. >> >> >> Coincidentally, I see a Smalltalk implementation is available... >> http://www.squeaksource.com/Cassowary.html >> https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf >> >> >> For balance, some points against AutoLayout, but some alternatives also seem >> to use Cassowary solver... >> https://www.reddit.com/r/iOSProgramming/comments/4t6kd5/why_i_dont_use_auto… >> https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-th… >> https://makeapppie.com/2015/10/28/why-stack-views-are-your-best-friend-if-y… >> https://cocoacasts.com/working-with-stack-views/ >> >> >> cheers -ben >> >>

Oct. 28, 2017