- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Got some DNU using Spotter but I could not repeat it

by stepharo

> Hi, > > Was it not the SubscriptOutOfBounds error? Yes I think. > This is because of Rubric, but it should not appear anymore in the latest Pharo with the fix of Marcus. Ok I was using the version of yesterday evening. > > Cheers, > Doru > > >> On Feb 25, 2016, at 10:56 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Just for the record >> >> Got some DNU using Spotter but I could not reproduce it. >> >> Stef >> > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > >

Feb. 26, 2016

Re: [Pharo-dev] How to browse files with Spotter

by stepharo

how can see the files close to .image? because like that I can browse the folder? I tried . #files Le 25/2/16 23:06, Tudor Girba a Ã©crit : > You mean if you just say #files, nothing appears? > > That is because the top level #files and #directories do not appear when the query is empty, and right now we only consider a query to be non-empty when there is at least one non #filter character. > > But, when you dive in a folder, you should see the files by default without typing anything. > > Or was the question about something else? > > Cheers, > Doru > > >> On Feb 25, 2016, at 10:52 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Thanks! >> I did a nice videos filtering examples :) >> What is strange is that >> >> #files does not show me the files on my disc. >> >> Stef >> >> >> Le 25/2/16 22:31, Tudor Girba a Ã©crit : >>> #files will list files. ./package-cache is a directory. So, you should use: >>> #dir ./pa >>> >>> Cheers, >>> Doru >>> >>> >>>> On Feb 25, 2016, at 10:20 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Doru >>>> >>>> I started to reproduce some of your videos. >>>> I tried to reproduce your videos but I cannot find how I can browse for example the package-cache. >>>> >>>> I tried >>>> >>>> . #files >>>> >>>> package-cache #files >>>> >>>> ./package-cache #files >>>> >>>> But I could not get the list of the current files on the folder image. >>>> >>>> Stef >>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "No matter how many recipes we know, we still value a chef." >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > > >

Feb. 26, 2016

Could we move back Bloc jenkins job under Pharo contribution?

by stepharo

Hi Could we move back Bloc jenkins job under Pharo contribution? Because this is strange to have it under Moose and I would like students to be able to find it easily. Apparently the build is strange because it does not load the latest version. I will try to sit with christophe and see the setup. Stef

Feb. 26, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by Stephan Eggermont

On 26-02-16 09:33, Alain Plantec via Pharo-dev wrote: >I think the problem is that, as far as we know now, >it is not desirable that new subclasses of BlShape are created >in case the drawing has to be redefined for a particular BlElements. Can you give an example of this? Stephan

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

Alain can you give two example how to use the contract: ? I would understand: <precondition: [can we pass a block here] > Stef Le 25/2/16 23:48, Alain Rastoul a Ã©crit : > Hi, > > I have downloaded a first version of IceCompiler, a small tool who > allow run time checks embedding in pharo classes on Smalltalkhub at > > http://smalltalkhub.com/#!/~AlainRastoul/IceCompiler > > If some interested pharoers are willing to give me feedback on this > package I would greatly appreciate. > This is not an announce but a request for feedback to advanced pharo > users , since it is an alpha version with probably killing side effects. > There is no ConfigurationOf as of today(there will be), but there is > no dependency and the package loads well in a fresh standard Pharo 5.0. > > > Checks are written in standard smalltalk methods with > design-by-contract style pragmas like > > <contract: invariant> > <contract: #ensured appliedTo: #( #add: )> > <contract: #required appliedTo: #( #add: )> > > Contract method calls are compiled in specified classes (with > subclasses) in order to make bullet-proofing run test phases of Pharo > code/image > and to help in hard bug cases. > > > Before trying this package, please read the comments on smalltalk hub > page, because if misused it may break your image, and do not use on > standard important classes (Array, String, Dictionary, Collection > etc.) ... unless you like danger :) > > > Many thanks in advance > > > regards, > > Alain

Feb. 26, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

This is cool. Having contract is really something I always wanted. I do not know if Ice refers to Eiffel compiler mode but this is nice. Le 25/2/16 23:48, Alain Rastoul a Ã©crit : > Hi, > > I have downloaded a first version of IceCompiler, a small tool who > allow run time checks embedding in pharo classes on Smalltalkhub at > > http://smalltalkhub.com/#!/~AlainRastoul/IceCompiler > > If some interested pharoers are willing to give me feedback on this > package I would greatly appreciate. > This is not an announce but a request for feedback to advanced pharo > users , since it is an alpha version with probably killing side effects. > There is no ConfigurationOf as of today(there will be), but there is > no dependency and the package loads well in a fresh standard Pharo 5.0. > > > Checks are written in standard smalltalk methods with > design-by-contract style pragmas like > > <contract: invariant> > <contract: #ensured appliedTo: #( #add: )> > <contract: #required appliedTo: #( #add: )> > > Contract method calls are compiled in specified classes (with > subclasses) in order to make bullet-proofing run test phases of Pharo > code/image > and to help in hard bug cases. > > > Before trying this package, please read the comments on smalltalk hub > page, because if misused it may break your image, and do not use on > standard important classes (Array, String, Dictionary, Collection > etc.) ... unless you like danger :) > > > Many thanks in advance > > > regards, > > Alain

Feb. 26, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by Tudor Girba

Exactly. This is a sensible point. We need to learn a bit more from concrete implementations on top of Bloc before we decide. @Alex: Could you add a flag in the implementation? Doru p.s. I really love this kind of discussion > On Feb 26, 2016, at 9:33 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Alain Plantec <alain.plantec(a)yahoo.com> > Subject: Re: [Pharo-dev] [bloc] feature envy -> move method close to data? > Date: February 26, 2016 at 9:32:16 AM GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, > I think the problem is that, as far as we know now, > it is not desirable that new subclasses of BlShape are created > in case the drawing has to be redefined for a particular BlElements. > For now, we flag it as a sensible point. > We will fix or at least take a decision later. > We need a layer as Brick on top of Bloc to see how it goes. > Alain > > > >> On 25 Feb 2016, at 23:01, stepharo <stepharo(a)free.fr> wrote: >> >> Sorry but I do not buy your argument. >> BlElement is in charge and it delegates it to BlShape. >> This is a quite common pattern and this is more logical that the object responsible for the shape drawing draw it in fact. >> It was like that in Bloc before so I do not see why this is not possible now. >> >> Le 25/2/16 13:37, Aliaksei Syrel a Ã©crit : >>> All arbitrary shapes are being drawing in the same way and it is enough to have only one method. Allowing shape to render itself would lead to misunderstanding: bloc user would have to look into two places (element and shape) to find out where drawing actually happens. >>> >>> On Feb 25, 2016 12:56 PM, "stepharo" <stepharo(a)free.fr> wrote: >>> To me this is pre optimisation >>> >>> I do not see why we cannot do >>> >>> BlElement>>drawOnAthensCanvas: aCanvas >>> >>> self shape drawOnAthensCanvas: aCanvas with: self >>> >>> so far only localBounds from BlElement are used. >>> >>> And to me this is really strange to have an object responsible for the drawing not doing it. >>> It blurs the responsibility. >>> >>> Stef >>> >>> Le 25/2/16 10:39, Tudor Girba a Ã©crit : >>> Hi, >>> >>> Good question. >>> >>> The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. >>> >>> Cheers, >>> Doru >>> >>> >>> On Feb 25, 2016, at 9:56 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi Blockers >>> >>> I do not really understand why drawOnAthensCanvas: is not defined on BlShape >>> (especially when we see how many self space are defined in this method. >>> And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). >>> >>> >>> drawOnAthensCanvas: aCanvas >>> "Actually render receiver on aCanvas in local bounds. >>> Override to customize. >>> aCanvas is an instance of AthensCanvas >>> aCanvas must not be nil" >>> >>> | pathTransform | >>> pathTransform := aCanvas pathTransform. >>> "First we fill" >>> pathTransform >>> restoreAfter: >>> [ | path fillExtent fillTranslation | >>> "We fill inside natural element's bounds" >>> fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. >>> path := self shape path pathOn: aCanvas forExtent: fillExtent. >>> "Translate fill if needed" >>> fillTranslation := self shape path >>> fillTranslationFor: self shape >>> inBounds: self localBounds. >>> pathTransform translateBy: fillTranslation. >>> aCanvas >>> setPaint: self shape fillPaint; >>> drawShape: path ]. >>> pathTransform >>> restoreAfter: >>> [ | path strokeExtent strokeTranslation | >>> "We stroke inside natural element's bounds" >>> strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. >>> path := self shape path pathOn: aCanvas forExtent: strokeExtent. >>> "Translate stroke if needed" >>> strokeTranslation := self shape path >>> strokeTranslationFor: self shape >>> inBounds: self localBounds. >>> pathTransform translateBy: strokeTranslation. >>> aCanvas >>> setPaint: self shape strokePaint; >>> drawShape: path ] >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Sometimes the best solution is not the best solution." >>> >>> >>> >>> >>> >> > > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Feb. 26, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by Alain Plantec

Hello, I think the problem is that, as far as we know now, it is not desirable that new subclasses of BlShape are created in case the drawing has to be redefined for a particular BlElements. For now, we flag it as a sensible point. We will fix or at least take a decision later. We need a layer as Brick on top of Bloc to see how it goes. Alain > On 25 Feb 2016, at 23:01, stepharo <stepharo(a)free.fr> wrote: > > Sorry but I do not buy your argument. > BlElement is in charge and it delegates it to BlShape. > This is a quite common pattern and this is more logical that the object responsible for the shape drawing draw it in fact. > It was like that in Bloc before so I do not see why this is not possible now. > > Le 25/2/16 13:37, Aliaksei Syrel a Ã©crit : >> All arbitrary shapes are being drawing in the same way and it is enough to have only one method. Allowing shape to render itself would lead to misunderstanding: bloc user would have to look into two places (element and shape) to find out where drawing actually happens. >> >> On Feb 25, 2016 12:56 PM, "stepharo" < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> To me this is pre optimisation >> >> I do not see why we cannot do >> >> BlElement>>drawOnAthensCanvas: aCanvas >> >> self shape drawOnAthensCanvas: aCanvas with: self >> >> so far only localBounds from BlElement are used. >> >> And to me this is really strange to have an object responsible for the drawing not doing it. >> It blurs the responsibility. >> >> Stef >> >> Le 25/2/16 10:39, Tudor Girba a Ã©crit : >> Hi, >> >> Good question. >> >> The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. >> >> Cheers, >> Doru >> >> >> On Feb 25, 2016, at 9:56 AM, stepharo < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> Hi Blockers >> >> I do not really understand why drawOnAthensCanvas: is not defined on BlShape >> (especially when we see how many self space are defined in this method. >> And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). >> >> >> drawOnAthensCanvas: aCanvas >> "Actually render receiver on aCanvas in local bounds. >> Override to customize. >> aCanvas is an instance of AthensCanvas >> aCanvas must not be nil" >> >> | pathTransform | >> pathTransform := aCanvas pathTransform. >> "First we fill" >> pathTransform >> restoreAfter: >> [ | path fillExtent fillTranslation | >> "We fill inside natural element's bounds" >> fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: fillExtent. >> "Translate fill if needed" >> fillTranslation := self shape path >> fillTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: fillTranslation. >> aCanvas >> setPaint: self shape fillPaint; >> drawShape: path ]. >> pathTransform >> restoreAfter: >> [ | path strokeExtent strokeTranslation | >> "We stroke inside natural element's bounds" >> strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: strokeExtent. >> "Translate stroke if needed" >> strokeTranslation := self shape path >> strokeTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: strokeTranslation. >> aCanvas >> setPaint: self shape strokePaint; >> drawShape: path ] >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com/> >> >> "Sometimes the best solution is not the best solution." >> >> >> >> >> >

Feb. 26, 2016

Run time checking with design by contract assertions

by Alain Rastoul

Hi, I have downloaded a first version of IceCompiler, a small tool who allow run time checks embedding in pharo classes on Smalltalkhub at http://smalltalkhub.com/#!/~AlainRastoul/IceCompiler If some interested pharoers are willing to give me feedback on this package I would greatly appreciate. This is not an announce but a request for feedback to advanced pharo users , since it is an alpha version with probably killing side effects. There is no ConfigurationOf as of today(there will be), but there is no dependency and the package loads well in a fresh standard Pharo 5.0. Checks are written in standard smalltalk methods with design-by-contract style pragmas like <contract: invariant> <contract: #ensured appliedTo: #( #add: )> <contract: #required appliedTo: #( #add: )> Contract method calls are compiled in specified classes (with subclasses) in order to make bullet-proofing run test phases of Pharo code/image and to help in hard bug cases. Before trying this package, please read the comments on smalltalk hub page, because if misused it may break your image, and do not use on standard important classes (Array, String, Dictionary, Collection etc.) ... unless you like danger :) Many thanks in advance regards, Alain

Feb. 25, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] c2b19a: 50611

by Tudor Girba

The cool thing about these rules is that they are specific, and they capture concrete value (the humane assessment way). Please keep this up, Yuriy :). Cheers, Doru > On Feb 25, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: > > I love the idea that we get more and better rules! > Tx Yuriy > > > Le 25/2/16 14:11, GitHub a Ã©crit : >> 17685 Add rules to check if Float system classes are referenced >> https://pharo.fogbugz.com/f/cases/17685 > > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Feb. 25, 2016