February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Esteban A. Maringolo

2013/2/26 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> I love the complete ecosystem you are step by step building. >> This is so great! > Yes! Just imagine we continue like thatâ¦ we are now (slowly, slowly) reaching a point > where for the first time we can really build on top of the foundation we did. If you count the number of packages in SmalltalkHub and compare them to the ones in Npmjs.org, it is impressive how much we have. Of course NPM's user base is two orders of magnitude greater, but we need to start having more killer app "modules", and some sort of guideline for those starting with Pharo and/or Smalltalk. And of course, be open to the suggestions of newcomers. Regards, E.

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Marcus Denker

On Feb 26, 2013, at 4:57 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I love the complete ecosystem you are step by step building. > This is so great! > Yes! Just imagine we continue like thatâ¦ we are now (slowly, slowly) reaching a point where for the first time we can really build on top of the foundation we did. One central idea behind Pharo was to so we can do better on top of what we did. The effect we will get from that will be very interesting. Until now we have seen almost nothing, but now we are entering a phase where the difference will be not very pronounced but visible if you look for it. Reflective improvement, leading to a feedback loopâ¦ and thus non-linear effects. I know that some people are laughing about this, but I really believe in it :-) Marcus

Feb. 26, 2013

Re: [Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by stephane ducasse

I love the complete ecosystem you are step by step building. This is so great! Stef On Feb 26, 2013, at 1:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > It is often important, especially for server applications, to know if the current local clock is still OK. The standard way for doing that is part of NTP (http://en.wikipedia.org/wiki/Network_Time_Protocol) I implemented two SNTP clients (one with ZTimestamp's second precision and another one using DateAndTime's nanosecond precision) that can be used to check the difference between the local clock and the clock of any NTP server. > > ZTimestampPreciseSNTPClient new clockDifference. > > -0:00:00:00.005786228 > > This reports that the difference between the local and remote clocks is in the order of 5ms, as computed in one specific way. Other queries are related to the Clock synchronisation algorithm. > > ZTimestampPreciseSNTPClient new localClockOffset. > > 0:00:00:00.065466869 > > ZTimestampPreciseSNTPClient new roundtripDelay. > > 0:00:00:00.037001908 > > In practice the following would be a useful practical check. > > ZTimestampPreciseSNTPClient new > enforceClockDifference: 2 seconds > ifFail: [ :delta | > self warn: ('Clock difference {1} > 2s' format: { delta }) ]; > close. > > As NTP uses UDP datagrams, this is a nice example for that as well. The code can be found in the following repository: > > http://mc.stfx.eu/Neo > > It is probably easiest to load the ZTimestamp configuration using the Configuration Browser and then load the bleeding edge version (it is not in de released version). The code is self-contained and loads cleanly. > > ConfigurationOfZTimestamp project bleedingEdge load. > > The client contacts a server from pool.ntp.org. The code does only deal with a limited aspect of NTP, which is rather complex and wonderful subject matter (http://tools.ietf.org/html/rfc2030) My goal was to get a dependable result, not be be super accurate. > > Enjoy. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Feb. 26, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by stephane ducasse

> > | > | let us know how you want that we proceed. > > I will have to look at the changes themselves to determine which direction to go ... if the changes are isolated enough I'd be inclined to hide them in MetacelloPlatform ... that's where the platform uglies go ... If the changes are extensive, then I'd consider extracting out a filedirectory[1]/filesystem[2] utilities package (as was done for zinc and filetree). I have the impression when I checked all the changes that they are minor but impacting (FS for example) > [1] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/Monticello… > [2] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/Monticello… > | > | - for the tests (not version 10.32 that I cannot load - I will have a look > > Metacello 1.0-beta.32 is the Metacello Preview version (not yet released anywhere) and porting that version stopped me cold last summer ... OSProcess was the final straw:) Ok I could not load it because ProfStef was not found but I can retry. > | at profStef to make it 2.0 aware I guess that this is that the problem) > | runCase refers to SystemNotifier > | > | versions accesssor => look really suspicious) > > Yeah, that looks very suspicious and tests won't pass without that puppy:) yes to me it looks really strange. > > | 'Metacello-TestsTutorial-dkh.33'; > | package: 'Metacello-ToolBox' with: > | 'Metacello-ToolBox-dkh.130' > | -> Metacello-ToolBox-MarcusDenker.135 > | > | here this is strange because the version of the toolbox in Pharo is > | based on 135 134 133 132 131 127 126 .... so should we take another > | version of the toolbox? > | May be there was a mistake from our side to take a wrong branch. > > You are on the right branch, Metacello-ToolBox-dkh.130 is okay (it's part of Metacello 1.0-beta.31.1.5) but Metacello-ToolBox-dkh.131 is part of the Preview release. We do not use 130 but 135 so we are using the wrong branch. So do you have idea of experience we should run. I think that we should try to load metacello-Toolbox.130 and check the tests.

Feb. 26, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by stephane ducasse

On Feb 25, 2013, at 8:21 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > I think that the suspendAllWhile: call is important because a) some Metacello tests are sensitive to packages getting marked dirty or other events getting triggered â¦ Christophe tried to removed them completely but there were other problems. I was not with him so I do not have all the info. What we noticed is that suspendAllWhile: is not equilavent because the events have been "clarified". Stef > > > > ----- Original Message ----- > | From: "Christophe Demarey" <Christophe.Demarey(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Thursday, February 21, 2013 1:26:31 AM > | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 > | > | Dale > | > | we run the tests simply rewriting runCase as > | > | runCase > | | original | > | (self doSilently) ifFalse: [ ^super runCase ]. > | original := MetacelloPlatform current bypassGoferLoadUpdateCategories. > | [ > | MetacelloPlatform current bypassGoferLoadUpdateCategories: true. > | ^ SystemAnnouncer uniqueInstance suspendAllWhile: [ super runCase ] > | ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: > | original ] > | > | but it seems that we do not have the same behavior between the two > | > | runCase > | | original | > | (self doSilently) ifFalse: [ ^super runCase ]. > | original := MetacelloPlatform current bypassGoferLoadUpdateCategories. > | [ > | MetacelloPlatform current bypassGoferLoadUpdateCategories: true. > | ^ super runCase ] > | ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: > | original ] > | > | So we will run all the tests > | > | Stef >

Feb. 26, 2013

Re: [Pharo-project] BalloonCanvas>>drawPolygon

by stephane ducasse

hilaire can you open a bug entry on the pharo bug tracker? so that we can have a look. Stef On Feb 25, 2013, at 4:15 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > I turn DrGeo canvas to use Balloon to be at today standard regarding > anti aliasing. Rendering polygon was the only issue I met with Balloon, > even if its rendering is not exempt of unwished artifacts. > No doubt Athens will be better but it adds the task to get Cairo on iOS > and Android VM. > > Hilaire > > > > Le 24/02/2013 21:14, stephane ducasse a Ã©crit : >> this is not an issue that we were aware of. At least I did not. >> >> On Feb 24, 2013, at 8:06 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: >> >>> Hello, >>> >>> When I use this method I get a beautiful red rectangle. >>> And I can read http://bugs.squeak.org/view.php?id=7598 >>> >>> Do someone confirm the issue? >>> >>> Thanks >>> >>> Hilaire >>> >>> >> >> >> > > >

Feb. 26, 2013

Re: [Pharo-project] Morphic View UI and Pharo Tabbed Pane IDE on Pharo 2.0

by S Krish

Thx for the comment.. The intent at the time I developed this is to have a RAD enterprise app framework, I could use to roll out interfaces to existing codebase of Java / any other platform with XMLRPC integration. Yes, this was done last year more or less at the same time. The intent is to go farther than just the specs part when it was done and Spec was not as yet ready Dec 2011.. So it moved independently. The other parts of what I played with and developed are too tightly integrated with this framework for now. I will try and move this off from the Inbox location. Is there an alternative you recommend. On Tue, Feb 26, 2013 at 6:31 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > S Krish wrote > > Pharo Morphic View and Pharo Tabbed Pane IDE. > > Thanks for the link! I read the blog post and linked document (the second > link is a 404). > > A few comments/questions: > - How does Pharo Morphic View differ from / enhance what's already > available > with Spec? They seem to provide a lot of similar functionality... > - Spec conflicts: I was going to load it, but then noticed that it > redefines > some Spec classes (e.g. CheckboxModel, RadioButtonGroup). Since Spec is > becoming more integrated with the system (tools are converting to > spec-based), I don't know what the ramifications of that would be and I > would rename those classes. > - The inbox is probably not a good place to store these, unless you're > proposing that they be included, in which case please open an issue > > Cheers, > Sean > > > > -- > View this message in context: > http://forum.world.st/Morphic-View-UI-and-Pharo-Tabbed-Pane-IDE-on-Pharo-2-… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 26, 2013

Re: [Pharo-project] ImageDirectory DirectoryDoesNotExist

by Sean P. DeNigris

Camillo Bruni-3 wrote > I got similar stuff... Issue 7600: ImageDirectory DirectoryDoesNotExist https://code.google.com/p/pharo/issues/detail?id=7600 -- View this message in context: http://forum.world.st/ImageDirectory-DirectoryDoesNotExist-tp4672135p467220… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 26, 2013

Re: [Pharo-project] Morphic View UI and Pharo Tabbed Pane IDE on Pharo 2.0

by Sean P. DeNigris

S Krish wrote > Pharo Morphic View and Pharo Tabbed Pane IDE. Thanks for the link! I read the blog post and linked document (the second link is a 404). A few comments/questions: - How does Pharo Morphic View differ from / enhance what's already available with Spec? They seem to provide a lot of similar functionality... - Spec conflicts: I was going to load it, but then noticed that it redefines some Spec classes (e.g. CheckboxModel, RadioButtonGroup). Since Spec is becoming more integrated with the system (tools are converting to spec-based), I don't know what the ramifications of that would be and I would rename those classes. - The inbox is probably not a good place to store these, unless you're proposing that they be included, in which case please open an issue Cheers, Sean -- View this message in context: http://forum.world.st/Morphic-View-UI-and-Pharo-Tabbed-Pane-IDE-on-Pharo-2-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 26, 2013

[Pharo-project] [ANN] ZTimestamp[Precise]SNTPClient

by Sven Van Caekenberghe

Hi, It is often important, especially for server applications, to know if the current local clock is still OK. The standard way for doing that is part of NTP (http://en.wikipedia.org/wiki/Network_Time_Protocol) I implemented two SNTP clients (one with ZTimestamp's second precision and another one using DateAndTime's nanosecond precision) that can be used to check the difference between the local clock and the clock of any NTP server. ZTimestampPreciseSNTPClient new clockDifference. -0:00:00:00.005786228 This reports that the difference between the local and remote clocks is in the order of 5ms, as computed in one specific way. Other queries are related to the Clock synchronisation algorithm. ZTimestampPreciseSNTPClient new localClockOffset. 0:00:00:00.065466869 ZTimestampPreciseSNTPClient new roundtripDelay. 0:00:00:00.037001908 In practice the following would be a useful practical check. ZTimestampPreciseSNTPClient new enforceClockDifference: 2 seconds ifFail: [ :delta | self warn: ('Clock difference {1} > 2s' format: { delta }) ]; close. As NTP uses UDP datagrams, this is a nice example for that as well. The code can be found in the following repository: http://mc.stfx.eu/Neo It is probably easiest to load the ZTimestamp configuration using the Configuration Browser and then load the bleeding edge version (it is not in de released version). The code is self-contained and loads cleanly. ConfigurationOfZTimestamp project bleedingEdge load. The client contacts a server from pool.ntp.org. The code does only deal with a limited aspect of NTP, which is rather complex and wonderful subject matter (http://tools.ietf.org/html/rfc2030) My goal was to get a dependable result, not be be super accurate. Enjoy. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 26, 2013