- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Github API on github

by Norbert Hartl

> Am 26.10.2017 um 15:54 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > >> 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 :) > >From time to time we should try to make our software modular. Doesnât that mean guille should provide a minimal package you can integrate in iceberg? Norbert > 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. 27, 2017

Re: [Pharo-dev] , for vector creation

by Tudor Girba

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] curious

by Ben Coman

Ahh... it was a brain freeze. The [meta] tab shows the methods of the selected instance, but my "key" is not an instance of PackageCheck, it the PackageCheck Class, so the class-side methods are shown. cheers -ben On Fri, Oct 27, 2017 at 1:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > I wasn't what to title this post. > Please just take a moment to inspect... > > Object subclasses > collect: [:class| class -> class methods size] > thenSelect: [:map| > (map value between: 1 and: 5) and: > (map key printString first = $P) ]. > > Then choose (a random example)... > "PackageChecker->1" item > "key" variable > [Meta] tab > "PackageCheck class" item > > and I'd expect a single method shown, rather than the zero I see. > Actually I'd expect the choice in that last step > to be "PackageCheck" rather than "PackageCheck class" > > Now continue with, browse "PackageCheck class" > then switch to instance side, and there I see the single class I expected > earlier. > > So is there something wrong there, or am I having a brain freeze? > > cheers -ben >

Oct. 27, 2017

curious

by Ben Coman

I wasn't what to title this post. Please just take a moment to inspect... Object subclasses collect: [:class| class -> class methods size] thenSelect: [:map| (map value between: 1 and: 5) and: (map key printString first = $P) ]. Then choose (a random example)... "PackageChecker->1" item "key" variable [Meta] tab "PackageCheck class" item and I'd expect a single method shown, rather than the zero I see. Actually I'd expect the choice in that last step to be "PackageCheck" rather than "PackageCheck class" Now continue with, browse "PackageCheck class" then switch to instance side, and there I see the single class I expected earlier. So is there something wrong there, or am I having a brain freeze? cheers -ben

Oct. 27, 2017

Re: [Pharo-dev] , for vector creation

by Ben Coman

On Thu, Oct 26, 2017 at 11:45 PM, 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). > Would it be possible/desirable to have this as a single primitive backed keyword message? (10@:20@:30) Perhaps a goal for the consensus on one-true-vector form integrated into the Image? Except at the moment "@:" doesn't parse. cheers -ben > > 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. 27, 2017

Re: [Pharo-dev] Github API on github

by Ben Coman

On Thu, Oct 26, 2017 at 9:51 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Now the interesting question.... > > *drumroll* > > Will iceberg use this library??? > > Norbert > What risk would this have to Iceberg losing is generality to other git/non-git repos? cheers -ben > > > 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. 27, 2017

Re: [Pharo-dev] feenk log

by Ben Coman

On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > Denis Kudriashov wrote > >> Good initiative. > > > > +1 :) > > > > > > Denis Kudriashov wrote > >> Here is my twitter questions:â¦ > > > > Mine are: > > 1. Is it possible/easy/smooth to zoom in/out? > > We now have BlScalableElement which handles the zooming. The next thing is > to attach animations to it. > and...and...and... can it zoom via the mouse-wheel? Or is support for this planned / what are the issues? cheers -ben

Oct. 27, 2017

Re: [Pharo-dev] feenk log

by Ben Coman

On Thu, Oct 26, 2017 at 2:15 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi, > > Good work, > > In PolyMaths/SciSmalltalk vectors and matrix are already implemented > efficiently. I would recommend to share the same implementation. > By this, you mean move the "base" vector/matrix objects from there into Pharo? This makes a lot of sense. These are applicable to a lot of applications, and having them in-Image obviously helps focus efforts and reuse. These could just have the minimal methods required by Bloc, with PolyMaths/SciSmalltalk extending them with more exotic operations. > In the next few years, I think we will improve the performance of those > vectors/matrix library using the processor vector instructions, and it > would be nice if we have to improve one but not two libraries of vectors > and matrix (This is the polite way of saying I am going to improve one > library and the others will have to do it themselves). > > Regards, > > On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> Our team is working on a couple of projects that are relevant for the >> core of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several >> people, and Stef in particular, to make the progress on these projects more >> transparent. To this end, we will start two streams of signals: >> - fine grained info bits on out Twitter account (several times a week): >> https://twitter.com/feenkcom >> - a less often but regular (probably every 2 weeks) activity log message >> sent to this mailing list >> >> Please let us know if you see an issue with this. >> > Good initiative, and already getting to useful collaboration. btw, I know sharing opens up to nit picking that can be discouraging, as we've seen other tools you've introduced in the past get a bit of a beating at the transition stage - but your vision and good work has borne through and now these are tools we now can't live without! So keep up the good work. cheers -ben > >> In the meantime, letâs start. >> >> Bloc: >> - Over the past couple of weeks Alex worked on transformations and >> measurements in the core system. It turns out that there was room for quite >> a number of performance optimizations and for making the system more >> debuggable. >> - At the low level, this involved adding matrix and vector support. >> https://twitter.com/feenkcom/status/923123870537863168 >> https://twitter.com/feenkcom/status/916300180848349185 >> - At a higher level, it implies keeping track of measurements >> https://twitter.com/AliakseiSyrel/status/915203525931622400 >> - And of transformations: >> https://twitter.com/feenkcom/status/919603739656417281 >> https://twitter.com/feenkcom/status/917116164484096001 >> - The BlScalableElement is now working properly >> >> GT Examples: >> - The current repository with unary-based examples is at: >> https://github.com/feenkcom/gtoolkit-examples >> - We now have a runner in the inspector that allows us to both see the >> source code and run and play with the resulting object: >> https://twitter.com/feenkcom/status/923210686204989442 >> - Andrei made the âafterâ behavior to work with unary examples. >> >> Cheers, >> The feenk team >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Being happy is a matter of choice." >> > +1

Oct. 27, 2017

Re: [Pharo-dev] Why 2017 sizeInMemory = 0?

by Eliot Miranda

Hi Marcus, On Thu, Oct 26, 2017 at 1:09 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 26 Oct 2017, at 10:05, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Question from discord, why: > > 2017 sizeInMemory = 0 > > ? > > Looks like a bug, but maybe there is some reason for this. > > > #sizeInMemory only takes into account object header size and the size of > the object > itself. > sizeInMemory is also ignorant of details such as the padding of objects to 64-bits in both 32-bit and 64-bit Spur, the overflow header when there are more than 254 slots, etc. siseInMemory should really be implemented like this: Object>>sizeInMemory ^self class isVariable ifTrue: [self class byteSizeOfInstanceOfSize: self basicSize] ifFalse: [self class byteSizeOfInstance] where the subsidiary definitions are Behavior>>byteSizeOfInstance "Answer the total memory size of an instance of the receiver." <primitive: 181 error: ec> self isVariable ifTrue: [^self byteSizeOfInstanceOfSize: 0]. self isImmediateClass ifTrue: [^0]. self primitiveFailed byteSizeOfInstanceOfSize: basicSize "Answer the total memory size of an instance of the receiver with the given number of indexable instance variables." <primitive: 181 error: ec> self isVariable ifTrue: "If the primitive overflowed answer a close approximation" [(basicSize isInteger and: [basicSize >= 16r1000000]) ifTrue: [^2 * (self byteSizeOfInstanceOfSize: basicSize + 1 // 2) - (self byteSizeOfInstanceOfSize: 0)]] ifFalse: [basicSize = 0 ifTrue: [^self byteSizeOfInstance]]. self primitiveFailed > A small-integer is encoded in the pointer, so it has no size in itself, > only the object > pointing to it needs space for the pointer, just like for normal object. > As are Characters, and in 64-bits the single-precision range of the double-precision floats: { SmallInteger maxVal sizeInMemory. (SmallInteger maxVal + 1) sizeInMemory. 1.0e38 sizeInMemory. 1.0e39 sizeInMemory. $a sizeInMemory } in 64 bit is #(0 16 0 16 0) in 32 bit is #(0 16 16 16 0) The overflow header is revealed by (251 to: 258) collect: [:n| (Array new: n) sizeInMemory] in 64 bit is #(2016 2024 2032 2040 2056 2064 2072 2080) in 32 bit is #(1016 1016 1024 1024 1040 1040 1048 1048) _,,,^..^,,,_ best, Eliot

Oct. 26, 2017

[Pharo 7.0-dev] Build #230: SUCCESS

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

There is a new Pharo build available! The status of the build #230 was: SUCCESS. Could not extract further issue information from commit message: https://api.github.com/repos/pharo-project/pharo/pulls/386 https://pharo.fogbugz.com/f/cases/20567/Instance-side-LayoutFrame-fractions… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 26, 2017