- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 489cbe: 40236

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 489cbebbe3d9bf20b8370adc3a1647f8e169375f https://github.com/pharo-project/pharo-core/commit/489cbebbe3d9bf20b8370adc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-19 (Fri, 19 Sep 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script236.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40236.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClass.class/instance/compiling/compileAll.st Log Message: ----------- 40236 14037 #recompile does not recompile the classTrait https://pharo.fogbugz.com/f/cases/14037 http://files.pharo.org/image/40/40236.zip

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Esteban A. Maringolo

2014-09-19 11:41 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310 >> >>> Very interesting link, really useful - Thx. >> >> At least it makes you understand some pros/cons about date implementations. >> After reading that I understood why Java's Calendar object is field based. >> Additionally >> I would like this: >> '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00" > Actually, > ZTimestamp fromString: '2014/08/31 24:00:00'. > => '2014-09-01T00:00:00Z' > but that is not really by design, it just does normalisation. > I am not sure what to think of that, it is certainly interesting ;-) Yes! I forgot to mention, but I did this test with ZTimestamp before and it gave me the "expected" results. I played with having ZTimestamp as the default object class for PostgresSQL's "timestamp without time zone" data type, but then I discarded this option. PostgreSQL also converts '2014-08-31 24:00' to '2014-09-01 00:00'. Regards! Esteban A. Maringolo

Sept. 19, 2014

Re: [Pharo-dev] Visualising Network Latency

by Leonel Merino

Thanks Alex ! Sure, Iâll do it. âLeonel On 19 Sep 2014, at 16:30, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > This is excellent Leonel! > Iâve tried, but I could not make the visualization work. Apparently you are using a rather old version of Roassal2. I suggest you to update it to the last version of Roassal2. > > Cheers, > Alexandre > > > On Sep 19, 2014, at 6:48 AM, Leonel Merino <merino(a)iam.unibe.ch> wrote: > >> Hi Max, >> >> Thanks ! >> >> The input is a CSV file which contains a grid with city names and latency. >> Surely you can zoom-in at city level. However, the map only contains information of the cities that come in the dataset (is not Bern). >> >> Best regards, >> Leonel >> >> On 19 Sep 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Very cool. >>> >>> - Do you parse data from a file? If so, what format does that file need to be in? >>> - Is the map zoomable to city level (to see connections between Bern and ZÃ¼rich for instance)? >>> >>> Cheers, >>> Max >>> >>> On 19.09.2014, at 15:23, Leonel Merino <merino(a)iam.unibe.ch> wrote: >>> >>>> Hi All, >>>> >>>> I have been working on a visualisation of latency on a network. I found an interesting dataset with latency information of 140 cities around the world. >>>> In the visualisation I show different metrics regarding latency such as from each city which other has the best/worst latency; cities that geographically are close but have high latency; far cities that have low latency; and average latency for each city. >>>> >>>> When visualising the worst latency for each city I found that, for this network (at least), Valencia and in a minor extent Nairobi represent the worst endpoint for connections (in terms of latency). Also in the visualisation of far cities with low latency, Newmarket in Canada and Toledo in Spain concentrate the best endpoint for connections coming from Europe and North-America respectively. >>>> >>>> >>>> Here a couple of screenshots: >>>> >>>> <PastedGraphic-4.pdf> >>>> >>>> <PastedGraphic-5.pdf> >>>> >>>> <PastedGraphic-6.pdf> >>>> >>>> >>>> Here there is a screencast: >>>> http://www.youtube.com/watch?v=gDQnE-5yeWI >>>> >>>> >>>> >>>> >>>> If you want to load the code: >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> Gofer new smalltalkhubUser: 'merino' >>>> project: 'NetworkLatency'; >>>> package: 'ConfigurationOfNetworkLatency'; >>>> load. >>>> (ConfigurationOfNetworkLatency project version: '0.1') load. >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-= >>>> >>>> To execute the visualisation: >>>> NLVisualise new open >>>> >>>> >>>> >>>> >>>> I would be glad to have your comments and suggestions. >>>> >>>> Best regards, >>>> >>>> Leonel Merino >>>> Research Assistant >>>> Software Composition Group >>>> Institute of Computer Science and Applied Mathematics >>>> University of Bern >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Sven Van Caekenberghe

On 19 Sep 2014, at 16:31, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> Pharo Date/DateAndTime are incremental[1], then all this >>> week/month/year operations will simply add/subtract the increment from >>> epoch. >>> >>> The only way to do this in a deterministic way is to have a field based Date. > >> Saying that it is not deterministic is a bit harsh ;-) > > Sorry, it wasn't my intention. Maybe "consistent" was the proper word. :) > >>> [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310 > >> Very interesting link, really useful - Thx. > > At least it makes you understand some pros/cons about date implementations. > After reading that I understood why Java's Calendar object is field based. > > > Additionally > I would like this: > '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00" > > Or even better: > '2014/08/31 24:00' asDateAndTime -> "2014/08/31 24:00" > And: > '2014/08/31 24:00' asDateAndTime = '2014/09/01 00:00' asDateAndTime Actually, ZTimestamp fromString: '2014/08/31 24:00:00'. => '2014-09-01T00:00:00Z' (ZTimestampFormat fromString: '2001/02/03 16:05') parse: '2014/08/31 24:00'. => '2014-09-01T00:00:00Z' but that is not really by design, it just does normalisation. I am not sure what to think of that, it is certainly interesting ;-)

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Esteban A. Maringolo

2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Pharo Date/DateAndTime are incremental[1], then all this >> week/month/year operations will simply add/subtract the increment from >> epoch. >> >> The only way to do this in a deterministic way is to have a field based Date. > Saying that it is not deterministic is a bit harsh ;-) Sorry, it wasn't my intention. Maybe "consistent" was the proper word. :) >> [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310 > Very interesting link, really useful - Thx. At least it makes you understand some pros/cons about date implementations. After reading that I understood why Java's Calendar object is field based. Additionally I would like this: '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00" Or even better: '2014/08/31 24:00' asDateAndTime -> "2014/08/31 24:00" And: '2014/08/31 24:00' asDateAndTime = '2014/09/01 00:00' asDateAndTime Regards! Esteban A. Maringolo

Sept. 19, 2014

Re: [Pharo-dev] Visualising Network Latency

by Alexandre Bergel

This is excellent Leonel! Iâve tried, but I could not make the visualization work. Apparently you are using a rather old version of Roassal2. I suggest you to update it to the last version of Roassal2. Cheers, Alexandre On Sep 19, 2014, at 6:48 AM, Leonel Merino <merino(a)iam.unibe.ch> wrote: > Hi Max, > > Thanks ! > > The input is a CSV file which contains a grid with city names and latency. > Surely you can zoom-in at city level. However, the map only contains information of the cities that come in the dataset (is not Bern). > > Best regards, > Leonel > > On 19 Sep 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > >> Very cool. >> >> - Do you parse data from a file? If so, what format does that file need to be in? >> - Is the map zoomable to city level (to see connections between Bern and ZÃ¼rich for instance)? >> >> Cheers, >> Max >> >> On 19.09.2014, at 15:23, Leonel Merino <merino(a)iam.unibe.ch> wrote: >> >>> Hi All, >>> >>> I have been working on a visualisation of latency on a network. I found an interesting dataset with latency information of 140 cities around the world. >>> In the visualisation I show different metrics regarding latency such as from each city which other has the best/worst latency; cities that geographically are close but have high latency; far cities that have low latency; and average latency for each city. >>> >>> When visualising the worst latency for each city I found that, for this network (at least), Valencia and in a minor extent Nairobi represent the worst endpoint for connections (in terms of latency). Also in the visualisation of far cities with low latency, Newmarket in Canada and Toledo in Spain concentrate the best endpoint for connections coming from Europe and North-America respectively. >>> >>> >>> Here a couple of screenshots: >>> >>> <PastedGraphic-4.pdf> >>> >>> <PastedGraphic-5.pdf> >>> >>> <PastedGraphic-6.pdf> >>> >>> >>> Here there is a screencast: >>> http://www.youtube.com/watch?v=gDQnE-5yeWI >>> >>> >>> >>> >>> If you want to load the code: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Gofer new smalltalkhubUser: 'merino' >>> project: 'NetworkLatency'; >>> package: 'ConfigurationOfNetworkLatency'; >>> load. >>> (ConfigurationOfNetworkLatency project version: '0.1') load. >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-= >>> >>> To execute the visualisation: >>> NLVisualise new open >>> >>> >>> >>> >>> I would be glad to have your comments and suggestions. >>> >>> Best regards, >>> >>> Leonel Merino >>> Research Assistant >>> Software Composition Group >>> Institute of Computer Science and Applied Mathematics >>> University of Bern >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Sven Van Caekenberghe

Being consistent is of course better (note however that #month does not exist today, probably because it is hard to define). The double-dispatching is also good. But I would have to study the actual code in detail to have a better opinion. On 19 Sep 2014, at 14:48, Max Leske <maxleske(a)gmail.com> wrote: > Ok, so I read Chrisâ e-mail and Iâm intrigued. > > Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦ > > So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible). > > Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt. > > Cheers, > Max > > > On 19.09.2014, at 14:37, Max Leske <maxleske(a)gmail.com> wrote: > >> Oops. Didnât realize that thread was from Squeak dev. So thereâs no Pharo implementation of that change for now anyway. >> >> On 19.09.2014, at 14:35, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 19.09.2014, at 14:16, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>>> Max Leske wrote >>>>> your change >>>> >>>> It's not mine. I just scanned the thread from Squeak Dev and was intrigued >>>> because I've run into this limitation (the tension between year/month/etc as >>>> a conceptual ideal, and those entities as a specific number of days in >>>> context) a bunch before >>> >>> Ok. Then Iâll look at it. >>> >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p… >>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>>> >>> >> > >

Sept. 19, 2014

Re: [Pharo-dev] Interesting Date/Time Thread on Squeak Dev

by Sven Van Caekenberghe

On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken >> >> Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world). > > +1 > >> January 30 + 1 month ? >> January 31 + 1 month ? >> Februari 29 2004 + 1 year ? >> >> And given all sorts of cleverness, will basic math rules still work ? >> >> A +B = B + A >> A + B = C => C - B = A > > Pharo Date/DateAndTime are incremental[1], then all this > week/month/year operations will simply add/subtract the increment from > epoch. > > The only way to do this in a deterministic way is to have a field based Date. Saying that it is not deterministic is a bit harsh ;-) > Regards! > > Esteban A. Maringolo > > [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310 Very interesting link, really useful - Thx.

Sept. 19, 2014

Re: [Pharo-dev] Visualising Network Latency

by Leonel Merino

Hi Max, Thanks ! The input is a CSV file which contains a grid with city names and latency. Surely you can zoom-in at city level. However, the map only contains information of the cities that come in the dataset (is not Bern). Best regards, Leonel On 19 Sep 2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > Very cool. > > - Do you parse data from a file? If so, what format does that file need to be in? > - Is the map zoomable to city level (to see connections between Bern and ZÃ¼rich for instance)? > > Cheers, > Max > > On 19.09.2014, at 15:23, Leonel Merino <merino(a)iam.unibe.ch> wrote: > >> Hi All, >> >> I have been working on a visualisation of latency on a network. I found an interesting dataset with latency information of 140 cities around the world. >> In the visualisation I show different metrics regarding latency such as from each city which other has the best/worst latency; cities that geographically are close but have high latency; far cities that have low latency; and average latency for each city. >> >> When visualising the worst latency for each city I found that, for this network (at least), Valencia and in a minor extent Nairobi represent the worst endpoint for connections (in terms of latency). Also in the visualisation of far cities with low latency, Newmarket in Canada and Toledo in Spain concentrate the best endpoint for connections coming from Europe and North-America respectively. >> >> >> Here a couple of screenshots: >> >> <PastedGraphic-4.pdf> >> >> <PastedGraphic-5.pdf> >> >> <PastedGraphic-6.pdf> >> >> >> Here there is a screencast: >> http://www.youtube.com/watch?v=gDQnE-5yeWI >> >> >> >> >> If you want to load the code: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Gofer new smalltalkhubUser: 'merino' >> project: 'NetworkLatency'; >> package: 'ConfigurationOfNetworkLatency'; >> load. >> (ConfigurationOfNetworkLatency project version: '0.1') load. >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-= >> >> To execute the visualisation: >> NLVisualise new open >> >> >> >> >> I would be glad to have your comments and suggestions. >> >> Best regards, >> >> Leonel Merino >> Research Assistant >> Software Composition Group >> Institute of Computer Science and Applied Mathematics >> University of Bern >

Sept. 19, 2014

Re: [Pharo-dev] Visualising Network Latency

by Max Leske

Very cool. - Do you parse data from a file? If so, what format does that file need to be in? - Is the map zoomable to city level (to see connections between Bern and ZÃ¼rich for instance)? Cheers, Max On 19.09.2014, at 15:23, Leonel Merino <merino(a)iam.unibe.ch> wrote: > Hi All, > > I have been working on a visualisation of latency on a network. I found an interesting dataset with latency information of 140 cities around the world. > In the visualisation I show different metrics regarding latency such as from each city which other has the best/worst latency; cities that geographically are close but have high latency; far cities that have low latency; and average latency for each city. > > When visualising the worst latency for each city I found that, for this network (at least), Valencia and in a minor extent Nairobi represent the worst endpoint for connections (in terms of latency). Also in the visualisation of far cities with low latency, Newmarket in Canada and Toledo in Spain concentrate the best endpoint for connections coming from Europe and North-America respectively. > > > Here a couple of screenshots: > > <PastedGraphic-4.pdf> > > <PastedGraphic-5.pdf> > > <PastedGraphic-6.pdf> > > > Here there is a screencast: > http://www.youtube.com/watch?v=gDQnE-5yeWI > > > > > If you want to load the code: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Gofer new smalltalkhubUser: 'merino' > project: 'NetworkLatency'; > package: 'ConfigurationOfNetworkLatency'; > load. > (ConfigurationOfNetworkLatency project version: '0.1') load. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-= > > To execute the visualisation: > NLVisualise new open > > > > > I would be glad to have your comments and suggestions. > > Best regards, > > Leonel Merino > Research Assistant > Software Composition Group > Institute of Computer Science and Applied Mathematics > University of Bern

Sept. 19, 2014