- Pharo-dev - lists.pharo.org

Visualising Network Latency

by Leonel Merino

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: 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] Interesting Date/Time Thread on Squeak Dev

by Christophe Demarey

Le 19 sept. 2014 Ã 14:59, Esteban A. Maringolo a Ã©crit : > 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. Yes, it would be a good idea. Then, you may have today + 1 month, today + 1 financialMonth, ...

Sept. 19, 2014

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

by Esteban A. Maringolo

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. Regards! Esteban A. Maringolo [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310

Sept. 19, 2014

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

by Max Leske

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 Max Leske

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 Max Leske

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 Max Leske

On 19.09.2014, at 14:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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). > > January 30 + 1 month ? > January 31 + 1 month ? Issue 13299 doesnât change that (I donât know about the other change). There is still only the Month object which knows its number of days, so a month will always be used in a defined context. > Februari 29 2004 + 1 year ? This one is hard and the change in issue 13299 does indeed make the assumption that February 29 2004 + 1 year = February 28 2005. One might argue that is should be March 1. But: that is also the assumption the *current* implementation makes, so no change there. > > And given all sorts of cleverness, will basic math rules still work ? > > A +B = B + A > A + B = C => C - B = A > > On 19 Sep 2014, at 13:54, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> From >> http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upd… >> : >> >> Now in the InBox: >> KernelTests-cbc.278.mcz >> Kernel-cbc.871.mcz >> The tests add in test for expected Duration addition and subtraction from >> each other, including the new GenericMonth and GenericYear, and the very new >> GenericDuration. It also adds a few more tests for LeapYear tests with >> adding years to them. >> >> The test are still based on what it currently does, with the exceptions >> listed previously (I haven't really changed any to expect failures, as has >> been suggested - that will come shortly. For now, I want to try to cause >> little to no changes o expected behavior first - just new behavior for now). >> >> Kernel adds the GenericDuration, and handles adding and subtracting >> GenericMonth, GenericYear, and GenericDurations togeher in a rational way. >> This involves turning + and - in Durations into a double-dispatch so that it >> will work. >> >> There are no comments yet in these classes - they will be there before the >> weekend is over at the latest. >> >> Any comments are more than welcome. >> >> -cbc >> >> >> >> ----- >> 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 Sean P. DeNigris

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 ----- 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

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). 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 On 19 Sep 2014, at 13:54, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > From > http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upd… > : > > Now in the InBox: > KernelTests-cbc.278.mcz > Kernel-cbc.871.mcz > The tests add in test for expected Duration addition and subtraction from > each other, including the new GenericMonth and GenericYear, and the very new > GenericDuration. It also adds a few more tests for LeapYear tests with > adding years to them. > > The test are still based on what it currently does, with the exceptions > listed previously (I haven't really changed any to expect failures, as has > been suggested - that will come shortly. For now, I want to try to cause > little to no changes o expected behavior first - just new behavior for now). > > Kernel adds the GenericDuration, and handles adding and subtracting > GenericMonth, GenericYear, and GenericDurations togeher in a rational way. > This involves turning + and - in Durations into a double-dispatch so that it > will work. > > There are no comments yet in these classes - they will be there before the > weekend is over at the latest. > > Any comments are more than welcome. > > -cbc > > > > ----- > 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] Implementing lazy loading for expandable collections

by Max Leske

On 19.09.2014, at 14:06, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-09-19 13:55 GMT+02:00 Markus Fritsche <mfritsche(a)reauktion.de>: > On 2014-09-19 11:35, Max Leske wrote: > > - my implementation requires an extra instance variable in > OrderedCollection to store the requested size. This extra instance > variable will break Monticello (and possibly other tools) because > Monticello uses OrderedCollections to load code and the particular way > it uses them makes it impossible to change the number of instance > variables on OrderedCollection. Also, all .mcz files written after the > change will not be loadable by images without the new instance > variable (same reason). > > I might be a bit fundamentalistic, but shouldn't this (a using class > making assumptions about the objects it's using) be considered a bug > by object oriented standards? > > Best regards > Markus > > > It's not the using class per se. > It's that MC is using a serialization framework sensitive to internal object representation (number/order of ivars). IIRC, MC counts the number of inst vars in the implementation that is being loaded and then assumes that the current implementation has the same number of fields. It might actually be quite easy to simply use the min of the number of instance variables and ignore the rest. However, that would not address the problem of modified variable position (which is a problem at least in theory). > The question is this one: > - would using FUEL would have resolved the problem or not? Partly. You could tell Fuel to migrate to the new layout dynamically which would allow reading of the old format as well as reading and writing of the new format. It wouldnât be exactly âniceâ though. > - wouldn't a serialization using message sends to reconstruct the objects be more robust (future proof)? > Of course the later requires the maintenance of a well defined API, so the robstness is relative. > But at least, it would respect the object paradigm a bit more. > > Nicolas

Sept. 19, 2014