Re: [Pharo-users] Modal widget
look at the implementation of #callInWorld for Magritte-Morph. I always liked that solution :) Esteban On 23 Apr 2014, at 10:46, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Hello, In a morph hierarchy I would like one morph child to be modal (i.e. all other morphs are locked and the system is waiting for the user action on this modal morph). I need this for dialog encrusted in a parent morph (instead of windowed dialog flying around the system). In the screen shot example, only the ok button is actionable. I can hack with appropriate lock and unlock in the morph hierarchy, but it is not clean and not exactly modal because the system does not wait for the user answer. Any idea to do it more cleanly? Thanks Hilaire -- Dr. Geo http://drgeo.eu modalWidget.jpeg
Re: [Pharo-users] Modal widget
which now I remember I always complemented it “web-like”: I added a transparent sticky morph behind, so all the morphs become unaccessible… I do not remember why I needed it, thought. Esteban On 23 Apr 2014, at 10:51, Esteban Lorenzano esteba...@gmail.com wrote: look at the implementation of #callInWorld for Magritte-Morph. I always liked that solution :) Esteban On 23 Apr 2014, at 10:46, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Hello, In a morph hierarchy I would like one morph child to be modal (i.e. all other morphs are locked and the system is waiting for the user action on this modal morph). I need this for dialog encrusted in a parent morph (instead of windowed dialog flying around the system). In the screen shot example, only the ok button is actionable. I can hack with appropriate lock and unlock in the morph hierarchy, but it is not clean and not exactly modal because the system does not wait for the user answer. Any idea to do it more cleanly? Thanks Hilaire -- Dr. Geo http://drgeo.eu modalWidget.jpeg
Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits
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
Re: [Pharo-users] Athens and ellipse drawing
On 22 Apr 2014, at 2:23 , Igor Stasenko siguc...@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-Ellipses.html 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits
Am 23.04.2014 um 11:36 schrieb Stephan Eggermont step...@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
Re: [Pharo-users] Versionner screencast
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
Re: [Pharo-users] [ANN] Gravatar for Pharo Smalltalk
There is already code for that in the image: (PharoUser new retrieveGravatarFromMail: 's...@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 asta...@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: 'exam...@mail.com' If you require a different size just evaluate: Gravatar imageURLFor: 'exam...@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: 'exam...@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.
Re: [Pharo-users] Athens and ellipse drawing
On 23 April 2014 13:17, Henrik Johansen henrik.s.johan...@veloxit.nowrote: On 22 Apr 2014, at 2:23 , Igor Stasenko siguc...@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-Ellipses.html 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.
Re: [Pharo-users] Athens and ellipse drawing
On 23 Apr 2014, at 2:31 , Igor Stasenko siguc...@gmail.com wrote: On 23 April 2014 13:17, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 22 Apr 2014, at 2:23 , Igor Stasenko siguc...@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-Ellipses.html 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] [ANN] BabyMock 2
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. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
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.
Re: [Pharo-users] [ANN] BabyMock 2
Le 23 avr. 2014 à 15:37, Attila Magyar a écrit : 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. I understand your point of view and I have quite the same ... (I also had the same discussion with Guillaume) ... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods. It is not crucial because you can test your class as a whole (if well designed, only a few methods are involved) but it prevents to test a smaller part. Then, maybe the work to support a real object with some mocked methods does not worth it. Best regards, Christophe smime.p7s Description: S/MIME cryptographic signature
[Pharo-users] [OT] TDD is dead. Long live testing. (DHH)
More or less what I think: testing is necessary and should be pragmatic fun, not a dogma http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
Re: [Pharo-users] [OT] TDD is dead. Long live testing. (DHH)
TDD is not about testing, it's about development. -- Best regards, Dennis Schetinin 2014-04-23 19:35 GMT+04:00 Sven Van Caekenberghe s...@stfx.eu: More or less what I think: testing is necessary and should be pragmatic fun, not a dogma http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
Re: [Pharo-users] We need *you* for the upcoming Pharo's website
Well I tried, several times , but I am not happy with the end result. In any case I am finished with this and since I promised to upload it here it is https://www.youtube.com/watch?v=Ol5ivaEATLQhttps://www.youtube.com/watch?v=Ol5ivaEATLQfeature=youtu.be Sorry I cannot deliver something of better quality but thats the best I can do. If you don't like it, I wont blame you :D On Tue, Apr 22, 2014 at 3:14 PM, Damien Cassou damien.cas...@gmail.comwrote: On Mon, Apr 21, 2014 at 10:40 PM, kilon alios kilon.al...@gmail.com wrote: I am still on vacations and the internet is very slow here. I will be able to upload something by the end of this weekend. My idea is to illustrate 6 points in 6-10 minutes that to my opinion make Pharo a very useful and fun choice. please do. Even if you are late, we will evaluate your screencast and maybe replace one that is already there. Or put it in a dedicated section somewhere else. We desperately need good screencasts. Thanks for the offer -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-users] [ANN] BabyMock 2
Christophe Demarey wrote ... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods. I assume that there is a method need to be tested, but it calls towards an other either public or private method of the same object. And you'd like to mock that second method. Am I understanding correctly? Why can't just allow the first method to call the second one? Is it slow, complicated to setup or requires some external resource to execute? Does it help to extract the logic from the second method to an other object? Without a concrete example, I'm just speculating. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756105.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
