April 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] BabyMock 2

by Attila Magyar

Hi Christophe, I'm not sure I fully understand, are you referring to partial mocking? Where you have a real object but with some mocked methods? If this is the case, then no, this is not supported. Some people consider this as a test smell, and I agree with them. Maybe the object under test is too big/complex/has multiple responsibilities, and extracting some parts from it could solve the problem. I haven't seen legitimitate use for partial mocking so far, where one couldn't solve the problem with redesign/refactoring in a better way. Until this happens I'd like to skip this feature. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756008.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2014

Re: [Pharo-users] [ANN] BabyMock 2

by Christophe Demarey

Hi, Le 17 avr. 2014 Ã 19:22, Attila Magyar a Ã©crit : > Hi Christophe, > > Sorry for my late response. You can use the following syntax to signal an > error in response to an incoming message: > > protocol describe > once: mock recv: #msg; > signals: Error. I did not notice this one. Thanks! I have another point. Sometimes, I would like to test a method doing some other calls to methods of the same class. In this case, I would like to mock all the class methods but the method I would like to test. Do you sometime meet the same need? Is there a way to do that? Thanks, Christophe.

April 23, 2014

Re: [Pharo-users] Athens and ellipse drawing

by Henrik Johansen

On 23 Apr 2014, at 2:31 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 23 April 2014 13:17, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 22 Apr 2014, at 2:23 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > as for why there's 4 arc segments instead of one, its because > > of bad approximation, when drawing more that 90 degree arcs. > > > > also, in athens, arc segment is defined with following inputs: > > - end point of previous segment (implicit) > > - angle > > - direction (clockwise/counterclockwise) > > - end point > > > > the radius, therefore calculated automatically, because with given set of parameters there's only one way to draw an arc connecting given points. > > > > Now if you put angle of 360 degrees, you cannot draw arc without specifying radius, > > because your end points will coincide, which means there's infinite number of ways to draw full circle passing through a single point, with any radius. > > > > cairo using different inputs for specifying arc segments.. > > - center, radius, start angle, end angle > > > > the problem with such parametrization is that it is completely separate from rest of commands (line/move/bezier etc).. and you will be very lucky if your arc will be connected with rest of your path.. because arc's starting point depends on start angle, instead of last point of previous path segment. > > > > this was the main reason to use more appropriate parametrization to get rid of inconsistency.. while losing ability to draw full circle with single command.. > > AFAICT, still doesnât explain how to draw an ellipse with constant stroke path width, which was the original question :) > > > Right, what is missing is elliptical arc segment type. And there's no direct support for it in Cairo.. so it can be only approximated by other segment types, like lines or bezier curves. > There's a work started on calculating path geometry using approximation with line segments.. it can be used to represent any kind of curves defined parametrically. > But it is not yet plugged into the API. > > > One way is to not use a transformed circle path altogether, but draw the actual ellipsis path using cubic beziers: > http://www.charlespetzold.com/blog/2012/12/Bezier-Circles-and-Bezier-Ellips… > > ellipsisOfExtent := [:builder :anExtent | | halfX halfY | > halfX := anExtent x / 2. > halfY := anExtent y / 2. > âWe expect relative builder, and start the ellipsis at anExtent x / 2 @ 0" > builder > curveVia: 0@(halfY negated * 0.55) and: (0.45 * halfX)@halfY negated to: halfX@ halfY negated; > curveVia: halfX* 0.55 @ 0 and: halfX@ (0.45 * halfY) to: halfX @ halfY; > curveVia: 0 @ (halfY * 0.55 ) and: (0.45 * halfX negated @ halfY) to: halfX negated @ halfY; > curveVia: (halfX negated * 0.55) @ 0 and: halfX negated @ (halfY negated * 0.45) to: halfX negated @ halfY negated; > close]. > > AthensSceneView new > scene: [ :can | > | path | > > path := can > createPath: [ :builder | > builder moveTo: 10@60. > ellipsisOfExtent value: builder value: 200@100 ]. > (can > > setStrokePaint: Color red) > width: 8 asFloat. > can drawShape: path ] ; > openInWindow > > > quite nice approximation. What is an error measure comparing to true ellipse? >From the abstract of the paper cited in the linked site: We provide a surprisingly simple cubic BÃ©zier curve which gives a very accurate approximation to a segment of a circle. Joining the BÃ©zier segments we obtain an approximation to the circle with continuous tangent and curvature. For 45Â° segments the error is approximately 2Â·10-6, and in general the approximation is sixth order accurate. Considering the code simply stretches a bezier circleâs control points, Iâd say quite. In fact, Iâd be surprised if the arc primitive in cairo is implemented using a different method. (Of course, even less error using the actual value of the formula for 90 degrees, instead of approximate values .55 / 1- 0.55.) Cheers, Henry

April 23, 2014

Re: [Pharo-users] Athens and ellipse drawing

by Igor Stasenko

On 23 April 2014 13:17, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: > > On 22 Apr 2014, at 2:23 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > as for why there's 4 arc segments instead of one, its because > > of bad approximation, when drawing more that 90 degree arcs. > > > > also, in athens, arc segment is defined with following inputs: > > - end point of previous segment (implicit) > > - angle > > - direction (clockwise/counterclockwise) > > - end point > > > > the radius, therefore calculated automatically, because with given set > of parameters there's only one way to draw an arc connecting given points. > > > > Now if you put angle of 360 degrees, you cannot draw arc without > specifying radius, > > because your end points will coincide, which means there's infinite > number of ways to draw full circle passing through a single point, with any > radius. > > > > cairo using different inputs for specifying arc segments.. > > - center, radius, start angle, end angle > > > > the problem with such parametrization is that it is completely separate > from rest of commands (line/move/bezier etc).. and you will be very lucky > if your arc will be connected with rest of your path.. because arc's > starting point depends on start angle, instead of last point of previous > path segment. > > > > this was the main reason to use more appropriate parametrization to get > rid of inconsistency.. while losing ability to draw full circle with single > command.. > > AFAICT, still doesnât explain how to draw an ellipse with constant stroke > path width, which was the original question :) > > Right, what is missing is elliptical arc segment type. And there's no direct support for it in Cairo.. so it can be only approximated by other segment types, like lines or bezier curves. There's a work started on calculating path geometry using approximation with line segments.. it can be used to represent any kind of curves defined parametrically. But it is not yet plugged into the API. One way is to not use a transformed circle path altogether, but draw the > actual ellipsis path using cubic beziers: > > http://www.charlespetzold.com/blog/2012/12/Bezier-Circles-and-Bezier-Ellips… > > ellipsisOfExtent := [:builder :anExtent | | halfX halfY | > halfX := anExtent x / 2. > halfY := anExtent y / 2. > âWe expect relative builder, and start the ellipsis at > anExtent x / 2 @ 0" > builder > curveVia: 0@(halfY negated * 0.55) and: (0.45 * > halfX)@halfY negated to: halfX@ halfY negated; > curveVia: halfX* 0.55 @ 0 and: halfX@ (0.45 * > halfY) to: halfX @ halfY; > curveVia: 0 @ (halfY * 0.55 ) and: (0.45 * halfX > negated @ halfY) to: halfX negated @ halfY; > curveVia: (halfX negated * 0.55) @ 0 and: halfX > negated @ (halfY negated * 0.45) to: halfX negated @ halfY negated; > close]. > > AthensSceneView new > scene: [ :can | > | path | > > path := can > createPath: [ :builder | > builder moveTo: 10@60. > ellipsisOfExtent value: builder > value: 200@100 ]. > (can > > setStrokePaint: Color red) > width: 8 asFloat. > can drawShape: path ] ; > openInWindow > > quite nice approximation. What is an error measure comparing to true ellipse? > Cheers, > Henry > -- Best regards, Igor Stasenko.

April 23, 2014

Re: [Pharo-users] [ANN] Gravatar for Pharo Smalltalk

by Sven Van Caekenberghe

There is already code for that in the image: (PharoUser new retrieveGravatarFromMail: 'sven(a)stfx.eu') openInWindow. PharoUser is an odd class (this code should be on the class side). Maybe both approaches can be combined ? On 23 Apr 2014, at 13:44, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > The "Gravatar" project is a simple wrapper for the Gravatar API allowing you to get small avatar images for a given registered email address. You can easily access and use it in Pharo. > > The project is located on STHub at http://smalltalkhub.com/#!/~TorstenBergmann/Gravatar > > To install just open the Pharo configuration browser and load "Gravatar" from there. > You can also install manually, read the docu on the project page. > > Some examples: > > Gravatar imageURLFor: 'example(a)mail.com' > > If you require a different size just evaluate: > > Gravatar imageURLFor: 'example(a)mail.com' size: 32. > > If you need the real image you can use Pharos Zinc components suite to get the image form over HTTP and open it on your Pharo desk: > > |form| > form := ZnEasy getJpeg: (self imageURLFor: 'example(a)mail.com'). > form asMorph openInWorld > > In the end it is just a simple class - but I think it may be useful for > others too. > > Thx > T. >

April 23, 2014

Re: [Pharo-users] Versionner screencast

by Ben Coman

Christophe Demarey wrote: > Hello, > > I made a small screencast on Versionner to explain how to use > it: https://www.youtube.com/watch?v=S5Dbmmln8tA > > Regards, > Christophe. Very nice. Seeing how to use it definitely helps me consider using it. cheers -ben

April 23, 2014

[ANN] Gravatar for Pharo Smalltalk

by Torsten Bergmann

Hi, The "Gravatar" project is a simple wrapper for the Gravatar API allowing you to get small avatar images for a given registered email address. You can easily access and use it in Pharo. The project is located on STHub at http://smalltalkhub.com/#!/~TorstenBergmann/Gravatar To install just open the Pharo configuration browser and load "Gravatar" from there. You can also install manually, read the docu on the project page. Some examples: Gravatar imageURLFor: 'example(a)mail.com' If you require a different size just evaluate: Gravatar imageURLFor: 'example(a)mail.com' size: 32. If you need the real image you can use Pharos Zinc components suite to get the image form over HTTP and open it on your Pharo desk: |form| form := ZnEasy getJpeg: (self imageURLFor: 'example(a)mail.com'). form asMorph openInWorld In the end it is just a simple class - but I think it may be useful for others too. Thx T.

April 23, 2014

Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits

by Norbert Hartl

Am 23.04.2014 um 11:36 schrieb Stephan Eggermont <stephan(a)stack.nl>: >> Whoever compiled it deserves commendation. Nevertheless, in my opinion itÂ´s an issue to keep in mind for the future; distributions are likely to upgrade their libc at >different points in time, and a good lowest common denominator should be chosen with care, otherwise itÂ´s not really "common" at all. > > +1 > > Well known issue. Heard about it first some 7 years ago, when a friend of mine, a FreePascal maintainer, commented: > "Ubuntu is Debian unstable, it is not supposed to workâ Always depends on the view you take. I work with ubuntu for nearly ten years professionally and I donât have complaints. With debian a lot of installations wouldnât have take place in my case. And using debian would have forced me to compile a lot of stuff because debian stuff is notoriously outdated. So if you need new (and yes unstable stuff) you might be better off with ubuntu. Anyway to relationship you draw about debian vs. ubuntu reminds of squeak vs. pharo :) Norbert

April 23, 2014

Re: [Pharo-users] Athens and ellipse drawing

by Henrik Johansen

On 22 Apr 2014, at 2:23 , Igor Stasenko <siguctua(a)gmail.com> wrote: > as for why there's 4 arc segments instead of one, its because > of bad approximation, when drawing more that 90 degree arcs. > > also, in athens, arc segment is defined with following inputs: > - end point of previous segment (implicit) > - angle > - direction (clockwise/counterclockwise) > - end point > > the radius, therefore calculated automatically, because with given set of parameters there's only one way to draw an arc connecting given points. > > Now if you put angle of 360 degrees, you cannot draw arc without specifying radius, > because your end points will coincide, which means there's infinite number of ways to draw full circle passing through a single point, with any radius. > > cairo using different inputs for specifying arc segments.. > - center, radius, start angle, end angle > > the problem with such parametrization is that it is completely separate from rest of commands (line/move/bezier etc).. and you will be very lucky if your arc will be connected with rest of your path.. because arc's starting point depends on start angle, instead of last point of previous path segment. > > this was the main reason to use more appropriate parametrization to get rid of inconsistency.. while losing ability to draw full circle with single command.. AFAICT, still doesnât explain how to draw an ellipse with constant stroke path width, which was the original question :) One way is to not use a transformed circle path altogether, but draw the actual ellipsis path using cubic beziers: http://www.charlespetzold.com/blog/2012/12/Bezier-Circles-and-Bezier-Ellips… ellipsisOfExtent := [:builder :anExtent | | halfX halfY | halfX := anExtent x / 2. halfY := anExtent y / 2. âWe expect relative builder, and start the ellipsis at anExtent x / 2 @ 0" builder curveVia: 0@(halfY negated * 0.55) and: (0.45 * halfX)@halfY negated to: halfX@ halfY negated; curveVia: halfX* 0.55 @ 0 and: halfX@ (0.45 * halfY) to: halfX @ halfY; curveVia: 0 @ (halfY * 0.55 ) and: (0.45 * halfX negated @ halfY) to: halfX negated @ halfY; curveVia: (halfX negated * 0.55) @ 0 and: halfX negated @ (halfY negated * 0.45) to: halfX negated @ halfY negated; close]. AthensSceneView new scene: [ :can | | path | path := can createPath: [ :builder | builder moveTo: 10@60. ellipsisOfExtent value: builder value: 200@100 ]. (can setStrokePaint: Color red) width: 8 asFloat. can drawShape: path ] ; openInWindow Cheers, Henry

April 23, 2014

Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits

by Stephan Eggermont

>Whoever compiled it deserves commendation. Nevertheless, in my opinion itÂ´s an issue to keep in mind for the future; distributions are likely to upgrade their libc at >different points in time, and a good lowest common denominator should be chosen with care, otherwise itÂ´s not really "common" at all. +1 Well known issue. Heard about it first some 7 years ago, when a friend of mine, a FreePascal maintainer, commented: "Ubuntu is Debian unstable, it is not supposed to workâ Stephan

April 23, 2014