- Pharo-dev - lists.pharo.org

Zinc and Zodiac - Synching/Contributing

by Torsten Bergmann

Hi Sven, for Zinc there is a new issue: 1. Zinc is using #asBytesDescription. It should not be used as it is deprecated https://github.com/pharo-project/pharo/pull/401 there is also 2. https://pharo.fogbugz.com/f/cases/20557 which is not yet integrated. I also proposed some simple but necessary cleanups for Zodiac in Pharo 7: 3. Proper categorization in Zodiac-Tests package - to use "test" category instead of "testing" and better group the tests written https://github.com/pharo-project/pharo/pull/355/files Also it looks like the #setUp in Zodiac tests never send a "super setUp". Which should be fixed too. I've noticed that both Zinc/Zodiac are not hosted on STHub. You seem to use your own custom hosting server on http://mc.stfx.eu/Zodiac http://mc.stfx.eu/ZincHTTPComponents as well as github: https://github.com/svenvc/zinc https://github.com/svenvc/zodiac If we just merge the changes from 3. into Pharo 7 they may later be overwritten when synching also Zodiac again as in 2. So how can we contribute from community side to both projects? Should I fork https://github.com/svenvc/zodiac and send a PR to it so that you can integrate? Thanks Torsten

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Chris Cunningham

On Thu, Oct 26, 2017 at 7:09 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Maybe we can follow the FS/PP pattern > and scope the message to only-vector-like-things via an initial message, so > just like `$f asParser, â¦`, have `1 {vector-appropriate-message}, â¦`? > > So, something like 1 vector, 2, 5 or 1 biVector, 2, 6 ? -cbc

Oct. 26, 2017

New Version of Zinc is using a deprecated method and breaking all the users

by tesonep＠gmail.com

Hello, Zinc-Http is using a method that has been deprecated long time ago and is affecting all the users of Zinc. I have created the issue ( https://pharo.fogbugz.com/f/cases/20596/Zinc-should-not-use-asBytesDescript…) and a PR to fix it in Pharo (https://github.com/pharo-project/pharo/pull/401 ). However, this fix should be pushed to the Zinc repository. Cheers, Pablo -- Pablo Tesone. tesonep(a)gmail.com

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Tim Mackinnon

This turned into a much more interesting thread than I expected (gosh you learn lots of stuff by reading comments). But I am impressed that Feenk listened to what people were saying, distilled it down and didnât take their ball home - thanks guys. Sometimes in all of these slightly robust conversations I have to keep thinking back to when I went to Pharo days, and how cool it was to see the wonderful things people had produced. It was inspiringâ¦. We have to hold onto that and keep moving the boundaries further without getting disillusioned or blocked. Iâm looking forward to the next Pharo Days where hopefully some of this stuff will be reality. Tim > On 26 Oct 2017, at 16:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thanks everyone for the nice discussion. > > So, after all arguments, we will remove Number>>, from Bloc. > > I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. > > In the meantime we have: > > 1. > BlVector x: 10 y: 20 > BlVector x: 10 y: 20 z: 30 > > or: > > 2. > (10@20) asBlocVector > (10@20@30) asBlocVector > > The 2nd option reads ok, but it has the downside that it needs an extra object (the point). > > An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. > > Cheers, > Doru > > >> On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tudor Girba-2 wrote >>> You mean like sending @ to a number, right? :) >> >> Ha ha, you got me ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > >

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Tudor Girba

Thanks everyone for the nice discussion. So, after all arguments, we will remove Number>>, from Bloc. I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. In the meantime we have: 1. BlVector x: 10 y: 20 BlVector x: 10 y: 20 z: 30 or: 2. (10@20) asBlocVector (10@20@30) asBlocVector The 2nd option reads ok, but it has the downside that it needs an extra object (the point). An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. Cheers, Doru > On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> You mean like sending @ to a number, right? :) > > Ha ha, you got me ;) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Sean P. DeNigris

Tudor Girba-2 wrote > You mean like sending @ to a number, right? :) Ha ha, you got me ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Hilaire

A clear separation between Point and Vector makes perfectly sense. Ideally, Point should be deprecated then. Otherwise it is a complexity growth. Hilaire Le 26/10/2017 Ã 11:39, Tudor Girba a Ã©critÂ : > 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. -- Dr. Geo http://drgeo.eu

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Tudor Girba

Hi, > On Oct 26, 2017, at 4:09 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Peter UhnÃ¡k wrote >> But in both cases #, is sent to FileReference/Petit parser instance, so it >> is contained. >> You would use it on a (generic) Number and tie it to specific Bloc >> meaning. > > Yes, this is exactly the problem. It is a reintroduction of a message like > #name, which plagued us for so long. We appropriate the meaning of `aNumber, > â¦` for the whole world. Now, if in MyCoolProject I want to implement > aNumber>>#, I will break the system. Maybe we can follow the FS/PP pattern > and scope the message to only-vector-like-things via an initial message, so > just like `$f asParser, â¦`, have `1 {vector-appropriate-message}, â¦`? You mean like sending @ to a number, right? :) Doru > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Sean P. DeNigris

Peter UhnÃ¡k wrote > But in both cases #, is sent to FileReference/Petit parser instance, so it > is contained. > You would use it on a (generic) Number and tie it to specific Bloc > meaning. Yes, this is exactly the problem. It is a reintroduction of a message like #name, which plagued us for so long. We appropriate the meaning of `aNumber, â¦` for the whole world. Now, if in MyCoolProject I want to implement aNumber>>#, I will break the system. Maybe we can follow the FS/PP pattern and scope the message to only-vector-like-things via an initial message, so just like `$f asParser, â¦`, have `1 {vector-appropriate-message}, â¦`? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 26, 2017

Re: [Pharo-dev] Github API on github

by Esteban Lorenzano

> On 26 Oct 2017, at 15:51, Norbert Hartl <norbert(a)hartl.name> wrote: > > Now the interesting question.... > > *drumroll* > > Will iceberg use this library??? what Guille did is an extract of Iceberg github api which at the time was a reinterpretation of Torstenâs api. I guess is possible, but my original intention was to keep it smallâ¦ so it depends :) Esteban > > Norbert > >> Am 26.10.2017 um 15:06 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Even more awesomeness :). Thanks for doing this! >> >> Doru >> >> >>> On Oct 26, 2017, at 2:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> I already contacted Guille in a private message on this one. >>> >>> Because now we have three (sorted in order of appearance): >>> >>> 1. https://balletie.github.io/GitHub/ (from Balletie, very complete) >>> 2. https://github.com/astares/GitHub-API (a wrapper I wrote to play with the API) >>> 3. https://github.com/guillep/github-api (Guille) >>> >>> If time permits we should consolidate this into a single one (maybe on https://github.com/pharo-vcs/github-api) >>> >>> Guille will contact Balletie as a next step. >>> >>> Thanks >>> T. >>> >>> >>>> Gesendet: Donnerstag, 26. Oktober 2017 um 13:32 Uhr >>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-dev] Github API on github >>>> >>>> Awesome. >>>> >>>> Doru >>>> >>>> >>>>> On Oct 20, 2017, at 10:07 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I extracted and extended some of the github API from iceberg, so it can be used as a standalone project. Maybe this is useful for somebody. >>>>> >>>>> https://github.com/guillep/github-api >>>>> >>>>> It should be easy to extend and add new functionalities, so don't hesitate if you need some missing request :) >>>>> >>>>> Guille >>>>> >>>>> -- >>>>> >>>>> Guille Polito >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> CRIStAL - UMR 9189 >>>>> French National Center for Scientific Research - http://www.cnrs.fr >>>>> >>>>> Web: http://guillep.github.io >>>>> Phone: +33 06 52 70 66 13 >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> âThe smaller and more pervasive the hardware becomes, the more physical the software gets." >>>> >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Presenting is storytelling." >

Oct. 26, 2017