November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] slow Pharo downloading and Travis

by Sven Van Caekenberghe

We are experimenting with a mirror that seems to work good. I mailed you some info privately. I am not sure if we can make this public already (Marcus ?) > On 17 Nov 2017, at 13:05, Ben Coman <btc(a)openinworld.com> wrote: > > Performance has been fairly reasonable lately, until just now... > from PharoLauncher I downloaded Pharo 7 latest-32 and that zipped along okay, > then immediately downloaded Pharo 7 latest-64 and it crawled. About 30 seconds or more per 1%. That would have been ~16:50TZ+8) > I went to dinner. After dinner ~19:30TZ+8 I found it timed out and kicked off another that was a tiny bit better, but still crawling. > Interestingly, from a terminal I then did... $ wget http://files.pharo.org/image/70/latest-64.zip > and for the first 15% it crawled at 20kB/s. Then up to 50% it ramped steadily up to 400kB/s, then the last 50% it smoothly ramped up 1.5MB/s and by the end was zooming. Meanwhile, PharoLauncher continued plodding along and finished a few minutes later with a "CRCError: Wrong CRC-32 (expected 55B3346A got 2DD68EFA) (proceed to ignore)" , which I've never seen before. > > About five minutes later I tried wget with the same behaviour, and then PharoLauncher again and it was much better taking about 20 seconds to successfully download Pharo 7 latest-64.zip. Paying close attention the download speed of PharoLauncher seemed to increase *slightly* as it went along, but nothing like wget's progressive improvement. > > I'm not quite sure what to make of that. The overlapped downloads by PharoLauncher and wget performing differently seems significant. Does the server have some throttling mechanism that maybe adapts its policies due to overall load, which Pharo is interacting with poorly? > > > Another observation, using Chromium I found pages [1] http://files.pharo.org/image/60/ and [2] http://files.pharo.org/image/70/ very slow, with the latter being worse. In one instance refreshing [2] I counted 40 seconds with no response (blank page). Then tried refreshing [2] again and at the the 6 second mark refreshed [1], then at a count of 20 both pages simultaneously appeared. > > No other internet services are slow. My current connection speedtest rates my link at 34Mbps (~4MB/s). > > Unfortunately I didn't get a traceroute while things were really slow. Here is one after it got back to normal (so the poor performance lasted about 50 minutes). > > $ traceroute files.pharo.org > traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte packets > 1 192.168.43.1 (192.168.43.1) 3.122 ms 3.180 ms 4.437 ms > 2 * * * > 3 * * * > 4 Bundle-Ether14.wel-edge901.perth.telstra.net (139.130.16.49) 70.991 ms 71.000 ms 70.984 ms > 5 bundle-ether6.wel-core3.perth.telstra.net (203.50.6.214) 70.964 ms 70.944 ms 72.089 ms > 6 bundle-ether7.fli-core1.adelaide.telstra.net (203.50.11.18) 85.918 ms 73.619 ms 82.271 ms > 7 bundle-ether9.win-core10.melbourne.telstra.net (203.50.11.91) 98.565 ms 98.568 ms 98.560 ms > 8 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) 109.279 ms 109.298 ms 109.288 ms > 9 bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) 109.232 ms 98.702 ms 101.279 ms > 10 bundle-ether1.sydp-core04.sydney.reach.com (203.50.13.90) 92.535 ms 104.351 ms 113.158 ms > 11 i-52.tlot-core02.bx.telstraglobal.net (202.84.137.101) 294.263 ms 283.547 ms 281.576 ms > 12 i-0-7-0-13.tlot-core01.bi.telstraglobal.net (202.40.149.165) 279.967 ms i-0-2-0-11.tlot-core01.bi.telstraglobal.net (202.40.149.185) 279.948 ms i-0-7-0-11.tlot-core01.bi.telstraglobal.net (202.84.251.233) 277.390 ms > 13 gtt-peer.tlot02.pr.telstraglobal.net (134.159.63.182) 280.217 ms 288.853 ms 275.764 ms > 14 xe-1-2-0.cr0-par7.ip4.gtt.net (89.149.185.53) 461.558 ms 445.153 ms 445.097 ms > 15 renater-gw-ix1.gtt.net (77.67.123.206) 445.083 ms 443.652 ms 441.766 ms > 16 * * * > 17 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr (193.51.184.177) 421.283 ms 480.646 ms 424.906 ms > > > > > > cheers -ben > > On 29 September 2017 at 03:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We opened a new ticket. > > > On Tue, Sep 26, 2017 at 8:45 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I'm willing to do some other specific tests if needed. Just let me know. > > > > On Tue, Sep 26, 2017 at 3:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > > wrote: > >> > >> Thanks Gabriel I forwarded this to christophe. > >> > >> On Tue, Sep 26, 2017 at 12:01 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> > >> wrote: > >> > Still really slow from Argentina. > >> > > >> > In case it helps > >> > > >> > traceroute files.pharo.org > >> > traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte > >> > packets > >> > 1 192.168.1.1 (192.168.1.1) 0.574 ms 0.968 ms 1.538 ms > >> > 2 192.168.0.1 (192.168.0.1) 2.048 ms 2.499 ms 2.847 ms > >> > 3 10.33.32.1 (10.33.32.1) 12.264 ms 14.160 ms 14.336 ms > >> > 4 10.242.2.161 (10.242.2.161) 14.522 ms 14.643 ms 16.497 ms > >> > 5 telecentro.baires3.bai.seabone.net (195.22.220.33) 18.936 ms > >> > 19.575 ms > >> > 18.843 ms > >> > 6 ae0.baires3.bai.seabone.net (195.22.220.32) 19.554 ms 10.675 ms > >> > 13.028 ms > >> > 7 et10-1-0.miami15.mia.seabone.net (89.221.41.175) 246.284 ms > >> > et9-3-0.miami15.mia.seabone.net (195.22.199.179) 246.214 ms > >> > et4-3-0.miami15.mia.seabone.net (195.22.199.177) 246.137 ms > >> > 8 gtt.miami15.mia.seabone.net (89.221.41.197) 245.909 ms 245.924 ms > >> > 245.870 ms > >> > 9 xe-3-1-2.cr0-par7.ip4.gtt.net (141.136.109.18) 251.632 ms 274.447 > >> > ms > >> > 250.097 ms > >> > 10 renater-gw-ix1.gtt.net (77.67.123.206) 281.025 ms 259.509 ms > >> > 261.717 > >> > ms > >> > 11 * * * > >> > 12 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr > >> > (193.51.184.177) > >> > 271.263 ms 307.011 ms 306.876 ms > >> > 13 * * * > >> > 14 * * * > >> > 15 * * * > >> > 16 * * * > >> > 17 * * * > >> > 18 * * * > >> > 19 * * * > >> > 20 * * * > >> > 21 * * * > >> > 22 * * * > >> > 23 * * * > >> > 24 * * * > >> > 25 * * * > >> > 26 * * * > >> > 27 * * * > >> > 28 * * * > >> > 29 * * * > >> > 30 * * * > >> > > >> > httping -g http://files.pharo.org/get-files/61/pharo64.zip -c 20 > >> > PING files.pharo.org:80 (/get-files/61/pharo64.zip): > >> > connected to 128.93.162.72:80 (256 bytes), seq=0 time=625,90 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=1 time=842,02 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=2 time=638,83 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=3 time=637,63 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=4 time=637,85 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=5 time=580,27 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=6 time=1207,98 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=7 time=638,13 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=8 time=637,74 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=9 time=582,59 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=10 time=658,11 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=11 time=673,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=12 time=584,44 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=13 time=691,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=14 time=637,20 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=15 time=861,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=16 time=619,45 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=17 time=638,03 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=18 time=638,11 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=19 time=741,01 ms > >> > --- http://files.pharo.org/get-files/61/pharo64.zip ping statistics --- > >> > 20 connects, 20 ok, 0,00% failed, time 33781ms > >> > round-trip min/avg/max = 580,3/688,6/1208,0 ms > >> > > >> > > >> > On Thu, Sep 21, 2017 at 12:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> > >> >> Still seems a bit slow... > >> >> http://files.pharo.org/get-files/70/pharo64.zip > >> >> 16MB ==> 10 minutes (and actually it stalled after 3.4MB downloaded) > >> >> Local speed test: 40Mb/s down, 20Mb/s up > >> >> > >> >> but then I'm a long way across the internet, the cause could be > >> >> anywhere... > >> >> $ traceroute files.pharo.org > >> >> traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte > >> >> packets > >> >> 1 192.168.43.1 (192.168.43.1) 2.040 ms 2.403 ms 4.222 ms > >> >> 2 * * * > >> >> 3 * * * > >> >> 4 Bundle-Ether14.wel-edge901.perth.telstra.net (139.130.16.49) > >> >> 67.741 > >> >> ms 67.739 ms 67.730 ms > >> >> 5 bundle-ether6.wel-core3.perth.telstra.net (203.50.6.214) 67.696 ms > >> >> 67.697 ms 67.697 ms > >> >> 6 bundle-ether7.fli-core1.adelaide.telstra.net (203.50.11.18) 95.723 > >> >> ms > >> >> 91.753 ms 100.574 ms > >> >> 7 bundle-ether9.win-core10.melbourne.telstra.net (203.50.11.91) > >> >> 106.550 > >> >> ms 108.849 ms 108.851 ms > >> >> 8 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) > >> >> 117.770 > >> >> ms 117.767 ms 117.751 ms > >> >> 9 bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) 117.720 ms > >> >> 103.603 ms 102.171 ms > >> >> 10 bundle-ether1.sydp-core04.sydney.reach.com (203.50.13.90) 93.276 > >> >> ms > >> >> 95.822 ms 102.577 ms > >> >> 11 i-52.tlot-core02.bx.telstraglobal.net (202.84.137.101) 330.128 ms > >> >> 321.231 ms 322.522 ms > >> >> 12 i-0-4-0-10.tlot-core01.bi.telstraglobal.net (202.84.253.21) > >> >> 321.187 > >> >> ms i-0-2-0-10.tlot-core01.bi.telstraglobal.net (202.40.149.181) > >> >> 321.181 ms > >> >> i-0-2-0-9.tlot-core01.bi.telstraglobal.net (202.40.149.177) 308.786 ms > >> >> 13 gtt-peer.tlot02.pr.telstraglobal.net (134.159.63.182) 273.784 ms > >> >> 283.530 ms 281.079 ms > >> >> 14 xe-1-2-0.cr0-par7.ip4.gtt.net (89.149.185.53) 466.648 ms 479.910 > >> >> ms > >> >> 481.254 ms > >> >> 15 renater-gw-ix1.gtt.net (77.67.123.206) 479.900 ms 479.882 ms > >> >> 478.641 ms > >> >> 16 * * * > >> >> 17 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr > >> >> (193.51.184.177) > >> >> 436.776 ms 479.819 ms 478.907 ms > >> >> 18 * * * > >> >> 19 * * * > >> >> > >> >> $ httping -h files.pharo.org > >> >> PING files.pharo.org:80 (http://files.pharo.org:80/) > >> >> connected to 128.93.162.72:80 (169 bytes), seq=0 time=970.27 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=1 time=928.26 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=2 time=860.06 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=3 time=976.04 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=4 time=1238.72 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=5 time=1239.65 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=6 time=918.06 ms > >> >> > >> >> > >> >> cheers -ben > >> >> > >> >> On Thu, Sep 21, 2017 at 5:43 PM, Marcus Denker <marcus.denker(a)inria.fr> > >> >> wrote: > >> >>> > >> >>> > >> >>> > On 18 Sep 2017, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> > >> >>> > wrote: > >> >>> > > >> >>> > > >> >>> >> On 16 Sep 2017, at 09:40, Stephane Ducasse > >> >>> >> <stepharo.self(a)gmail.com> > >> >>> >> wrote: > >> >>> >> > >> >>> >> Hi marcus > >> >>> >> > >> >>> >> I do not see why they could not find it. > >> >>> >> Can you tell me how you ask because we should reask? > >> >>> >> > >> >>> >> > >> >>> > > >> >>> > I spend a ticket and they wanted to close it last week. I have told > >> >>> > them to not close it > >> >>> > > >> >>> The problems seems to be fixed now. > >> >>> > >> >>> If someone sees any slowness -> send me a mail. > >> >>> > >> >>> Marcus > >> >>> > >> >>> > >> >> > >> > > >> > > > >

Nov. 17, 2017

[Pharo 7.0-dev] Build #300: 20647-SortFunction-should-be-composable

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #300 was: SUCCESS. The Pull Request #440 was integrated: "20647-SortFunction-should-be-composable" Pull request url: https://github.com/pharo-project/pharo/pull/440 Issue Url: https://pharo.fogbugz.com/f/cases/20647 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Ben Coman

Performance has been fairly reasonable lately, until just now... from PharoLauncher I downloaded Pharo 7 latest-32 and that zipped along okay, then immediately downloaded Pharo 7 latest-64 and it crawled. About 30 seconds or more per 1%. That would have been ~16:50TZ+8) I went to dinner. After dinner ~19:30TZ+8 I found it timed out and kicked off another that was a tiny bit better, but still crawling. Interestingly, from a terminal I then did... $ wget http://files.pharo.org/image/70/latest-64.zip and for the first 15% it crawled at 20kB/s. Then up to 50% it ramped steadily up to 400kB/s, then the last 50% it smoothly ramped up 1.5MB/s and by the end was zooming. Meanwhile, PharoLauncher continued plodding along and finished a few minutes later with a "CRCError: Wrong CRC-32 (expected 55B3346A got 2DD68EFA) (proceed to ignore)" , which I've never seen before. About five minutes later I tried wget with the same behaviour, and then PharoLauncher again and it was much better taking about 20 seconds to successfully download Pharo 7 latest-64.zip. Paying close attention the download speed of PharoLauncher seemed to increase *slightly* as it went along, but nothing like wget's progressive improvement. I'm not quite sure what to make of that. The overlapped downloads by PharoLauncher and wget performing differently seems significant. Does the server have some throttling mechanism that maybe adapts its policies due to overall load, which Pharo is interacting with poorly? Another observation, using Chromium I found pages [1] http://files.pharo.org/image/60/ and [2] http://files.pharo.org/image/70/ very slow, with the latter being worse. In one instance refreshing [2] I counted 40 seconds with no response (blank page). Then tried refreshing [2] again and at the the 6 second mark refreshed [1], then at a count of 20 both pages simultaneously appeared. No other internet services are slow. My current connection speedtest rates my link at 34Mbps (~4MB/s). Unfortunately I didn't get a traceroute while things were really slow. Here is one after it got back to normal (so the poor performance lasted about 50 minutes). $ traceroute files.pharo.org traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte packets 1 192.168.43.1 (192.168.43.1) 3.122 ms 3.180 ms 4.437 ms 2 * * * 3 * * * 4 Bundle-Ether14.wel-edge901.perth.telstra.net (139.130.16.49) 70.991 ms 71.000 ms 70.984 ms 5 bundle-ether6.wel-core3.perth.telstra.net (203.50.6.214) 70.964 ms 70.944 ms 72.089 ms 6 bundle-ether7.fli-core1.adelaide.telstra.net (203.50.11.18) 85.918 ms 73.619 ms 82.271 ms 7 bundle-ether9.win-core10.melbourne.telstra.net (203.50.11.91) 98.565 ms 98.568 ms 98.560 ms 8 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) 109.279 ms 109.298 ms 109.288 ms 9 bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) 109.232 ms 98.702 ms 101.279 ms 10 bundle-ether1.sydp-core04.sydney.reach.com (203.50.13.90) 92.535 ms 104.351 ms 113.158 ms 11 i-52.tlot-core02.bx.telstraglobal.net (202.84.137.101) 294.263 ms 283.547 ms 281.576 ms 12 i-0-7-0-13.tlot-core01.bi.telstraglobal.net (202.40.149.165) 279.967 ms i-0-2-0-11.tlot-core01.bi.telstraglobal.net (202.40.149.185) 279.948 ms i-0-7-0-11.tlot-core01.bi.telstraglobal.net (202.84.251.233) 277.390 ms 13 gtt-peer.tlot02.pr.telstraglobal.net (134.159.63.182) 280.217 ms 288.853 ms 275.764 ms 14 xe-1-2-0.cr0-par7.ip4.gtt.net (89.149.185.53) 461.558 ms 445.153 ms 445.097 ms 15 renater-gw-ix1.gtt.net (77.67.123.206) 445.083 ms 443.652 ms 441.766 ms 16 * * * 17 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr (193.51.184.177) 421.283 ms 480.646 ms 424.906 ms cheers -ben On 29 September 2017 at 03:11, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We opened a new ticket. > > > On Tue, Sep 26, 2017 at 8:45 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > > I'm willing to do some other specific tests if needed. Just let me know. > > > > On Tue, Sep 26, 2017 at 3:36 PM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > >> > >> Thanks Gabriel I forwarded this to christophe. > >> > >> On Tue, Sep 26, 2017 at 12:01 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> > >> wrote: > >> > Still really slow from Argentina. > >> > > >> > In case it helps > >> > > >> > traceroute files.pharo.org > >> > traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte > >> > packets > >> > 1 192.168.1.1 (192.168.1.1) 0.574 ms 0.968 ms 1.538 ms > >> > 2 192.168.0.1 (192.168.0.1) 2.048 ms 2.499 ms 2.847 ms > >> > 3 10.33.32.1 (10.33.32.1) 12.264 ms 14.160 ms 14.336 ms > >> > 4 10.242.2.161 (10.242.2.161) 14.522 ms 14.643 ms 16.497 ms > >> > 5 telecentro.baires3.bai.seabone.net (195.22.220.33) 18.936 ms > >> > 19.575 ms > >> > 18.843 ms > >> > 6 ae0.baires3.bai.seabone.net (195.22.220.32) 19.554 ms 10.675 ms > >> > 13.028 ms > >> > 7 et10-1-0.miami15.mia.seabone.net (89.221.41.175) 246.284 ms > >> > et9-3-0.miami15.mia.seabone.net (195.22.199.179) 246.214 ms > >> > et4-3-0.miami15.mia.seabone.net (195.22.199.177) 246.137 ms > >> > 8 gtt.miami15.mia.seabone.net (89.221.41.197) 245.909 ms 245.924 > ms > >> > 245.870 ms > >> > 9 xe-3-1-2.cr0-par7.ip4.gtt.net (141.136.109.18) 251.632 ms > 274.447 > >> > ms > >> > 250.097 ms > >> > 10 renater-gw-ix1.gtt.net (77.67.123.206) 281.025 ms 259.509 ms > >> > 261.717 > >> > ms > >> > 11 * * * > >> > 12 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr > >> > (193.51.184.177) > >> > 271.263 ms 307.011 ms 306.876 ms > >> > 13 * * * > >> > 14 * * * > >> > 15 * * * > >> > 16 * * * > >> > 17 * * * > >> > 18 * * * > >> > 19 * * * > >> > 20 * * * > >> > 21 * * * > >> > 22 * * * > >> > 23 * * * > >> > 24 * * * > >> > 25 * * * > >> > 26 * * * > >> > 27 * * * > >> > 28 * * * > >> > 29 * * * > >> > 30 * * * > >> > > >> > httping -g http://files.pharo.org/get-files/61/pharo64.zip -c 20 > >> > PING files.pharo.org:80 (/get-files/61/pharo64.zip): > >> > connected to 128.93.162.72:80 (256 bytes), seq=0 time=625,90 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=1 time=842,02 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=2 time=638,83 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=3 time=637,63 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=4 time=637,85 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=5 time=580,27 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=6 time=1207,98 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=7 time=638,13 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=8 time=637,74 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=9 time=582,59 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=10 time=658,11 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=11 time=673,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=12 time=584,44 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=13 time=691,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=14 time=637,20 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=15 time=861,84 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=16 time=619,45 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=17 time=638,03 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=18 time=638,11 ms > >> > connected to 128.93.162.72:80 (256 bytes), seq=19 time=741,01 ms > >> > --- http://files.pharo.org/get-files/61/pharo64.zip ping statistics > --- > >> > 20 connects, 20 ok, 0,00% failed, time 33781ms > >> > round-trip min/avg/max = 580,3/688,6/1208,0 ms > >> > > >> > > >> > On Thu, Sep 21, 2017 at 12:13 PM, Ben Coman <btc(a)openinworld.com> > wrote: > >> >> > >> >> Still seems a bit slow... > >> >> http://files.pharo.org/get-files/70/pharo64.zip > >> >> 16MB ==> 10 minutes (and actually it stalled after 3.4MB downloaded) > >> >> Local speed test: 40Mb/s down, 20Mb/s up > >> >> > >> >> but then I'm a long way across the internet, the cause could be > >> >> anywhere... > >> >> $ traceroute files.pharo.org > >> >> traceroute to files.pharo.org (128.93.162.72), 30 hops max, 60 byte > >> >> packets > >> >> 1 192.168.43.1 (192.168.43.1) 2.040 ms 2.403 ms 4.222 ms > >> >> 2 * * * > >> >> 3 * * * > >> >> 4 Bundle-Ether14.wel-edge901.perth.telstra.net (139.130.16.49) > >> >> 67.741 > >> >> ms 67.739 ms 67.730 ms > >> >> 5 bundle-ether6.wel-core3.perth.telstra.net (203.50.6.214) > 67.696 ms > >> >> 67.697 ms 67.697 ms > >> >> 6 bundle-ether7.fli-core1.adelaide.telstra.net (203.50.11.18) > 95.723 > >> >> ms > >> >> 91.753 ms 100.574 ms > >> >> 7 bundle-ether9.win-core10.melbourne.telstra.net (203.50.11.91) > >> >> 106.550 > >> >> ms 108.849 ms 108.851 ms > >> >> 8 bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122) > >> >> 117.770 > >> >> ms 117.767 ms 117.751 ms > >> >> 9 bundle-ether1.pad-gw11.sydney.telstra.net (203.50.6.61) > 117.720 ms > >> >> 103.603 ms 102.171 ms > >> >> 10 bundle-ether1.sydp-core04.sydney.reach.com (203.50.13.90) > 93.276 > >> >> ms > >> >> 95.822 ms 102.577 ms > >> >> 11 i-52.tlot-core02.bx.telstraglobal.net (202.84.137.101) 330.128 > ms > >> >> 321.231 ms 322.522 ms > >> >> 12 i-0-4-0-10.tlot-core01.bi.telstraglobal.net (202.84.253.21) > >> >> 321.187 > >> >> ms i-0-2-0-10.tlot-core01.bi.telstraglobal.net (202.40.149.181) > >> >> 321.181 ms > >> >> i-0-2-0-9.tlot-core01.bi.telstraglobal.net (202.40.149.177) > 308.786 ms > >> >> 13 gtt-peer.tlot02.pr.telstraglobal.net (134.159.63.182) 273.784 > ms > >> >> 283.530 ms 281.079 ms > >> >> 14 xe-1-2-0.cr0-par7.ip4.gtt.net (89.149.185.53) 466.648 ms > 479.910 > >> >> ms > >> >> 481.254 ms > >> >> 15 renater-gw-ix1.gtt.net (77.67.123.206) 479.900 ms 479.882 ms > >> >> 478.641 ms > >> >> 16 * * * > >> >> 17 inria-rocquencourt-te1-4-inria-rtr-021.noc.renater.fr > >> >> (193.51.184.177) > >> >> 436.776 ms 479.819 ms 478.907 ms > >> >> 18 * * * > >> >> 19 * * * > >> >> > >> >> $ httping -h files.pharo.org > >> >> PING files.pharo.org:80 (http://files.pharo.org:80/) > >> >> connected to 128.93.162.72:80 (169 bytes), seq=0 time=970.27 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=1 time=928.26 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=2 time=860.06 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=3 time=976.04 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=4 time=1238.72 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=5 time=1239.65 ms > >> >> connected to 128.93.162.72:80 (169 bytes), seq=6 time=918.06 ms > >> >> > >> >> > >> >> cheers -ben > >> >> > >> >> On Thu, Sep 21, 2017 at 5:43 PM, Marcus Denker < > marcus.denker(a)inria.fr> > >> >> wrote: > >> >>> > >> >>> > >> >>> > On 18 Sep 2017, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> > >> >>> > wrote: > >> >>> > > >> >>> > > >> >>> >> On 16 Sep 2017, at 09:40, Stephane Ducasse > >> >>> >> <stepharo.self(a)gmail.com> > >> >>> >> wrote: > >> >>> >> > >> >>> >> Hi marcus > >> >>> >> > >> >>> >> I do not see why they could not find it. > >> >>> >> Can you tell me how you ask because we should reask? > >> >>> >> > >> >>> >> > >> >>> > > >> >>> > I spend a ticket and they wanted to close it last week. I have > told > >> >>> > them to not close it > >> >>> > > >> >>> The problems seems to be fixed now. > >> >>> > >> >>> If someone sees any slowness -> send me a mail. > >> >>> > >> >>> Marcus > >> >>> > >> >>> > >> >> > >> > > >> > > > >

Nov. 17, 2017

Re: [Pharo-dev] Pharo Quality: raising the quality level in Pharo 7 and onwards

by phil＠highoctane.be

Ok. Now, how is one using those super tools? You mean Quality Assistant for example? Phil On Fri, Nov 17, 2017 at 11:52 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > when we forked Pharo back in the days (2008) one of the primary goals of > Pharo was and still is to provide a CLEAN SYSTEM. > > Now after nearly 10 years we have done already an amazing job. But we are > still not there. > > While it is a good thing that we rewrite parts of the image, work on > bootstrap and new shiny tools I unfortunately see the > effect that even some newly written code has flaws or is not meeting some > basic quality standards like: > > - having class comments > - no uncategorized methods anymore > - not having unused temps or unused instance variables > - tests in a separate package than the code (to be able to have minified > versions without tests) > - class instance variable naming in lowercase > - ... > > Meanwhile in Pharo 6 and 7 there are nice tools inside to check your code. > So USE THEM. > > Some of you have already seen that I continue to do more and more of such > cleanups in the system in various Pharo 7 > contributions. Believe me: this is a boring task and one can earn much > more applause for other nice and more amazing > contributions - but the dirty job needs to be done to clean up the house. > > I also started to integrate some more "Release Tests" to make sure the > things cleaned now stay clean over time and > is not violated again by new Pull requests or new package inclusions. > > Because some of these cleanups were already done in Pharo 5 and 6 - but > violated again by new contributions we now need > to enforce that the image stays at that qualit level. Because I do not > want to waste my time to do it over and over again! > > See package "ReleaseTests" or code like > > ProperMethodCategorizationTest, ProperlyImplementedClassesTest, # > testAllClassInstanceVariablesStartLowercase and other > > which was written to ensure we not only GET better but also STAY better in > the future. Thanks to Pavel, Marcus, Esteban > and others for reviewing and integrating. > > Still there is a long journey in front of us, some examples: > > 1. Unused Temps > > CompiledMethod allInstances select: [:m | m ast temporaries > anySatisfy: [:x | x binding isUnused ]]. => over 200 still > > 2. Uncategorized methods > > Object allSubclasses select: [:each | (each selectorsInProtocol: > Protocol unclassified) notEmpty ] => over 200 still > > 3. Many many more uncommented classes. We need a special reminder to > people who can write many code lines a day but > are not able to spend a minute to write a class comment. > > 4. ... > > One person will require too much time ... several contributors helping > with one contribution a day or a week will already change > the game and make it possible again. Why not have a clean base image > meeting basic criterias by the end of the year 2017 and > ensuring with tests that we continue clean in 2018? > > Would'nt this be a nice birthday present to Pharos 10 years anniversary in > 2018? > > How can you help: > ================= > > a) you can check you own packages using the provided quality tools and > before you integrate new features just cleanup your code > first > > b) even as beginners you can help cleaning up such easy things and with > simple cleanup pull requests help moving Pharo 7 forward > > c) you can think of other short snippets that reveal design or code > flaws and post them here > Then we can fix these in the image too and have the rules enforced > using a separate release test > > d) lets discuss and define quality criterias and note them somewhere > > e) ideally you can reveal problems, open bugs, clean them up and then > write Release tests to ensure we stay clean > > > We should and need to definitely raise the bar. I would even be more > radical to enforce more quality: > > - in the worst case we should not accept contributions or put new > versions of packages into the image > when they do not meet basic criterias, that is the idea of the release > tests > > - if parts of the community are not seeing this as a necessity then in > the worst case we need to fork Pharo again > into another next level CLEANED UP system ;) > > > So PLEASE HELP!!! Otherwise this will KILL US and it also will be and > ENDLESS journey for a few people to try to clean the house. > So PLEASE HELP before you work on the next shiny feature that might still > violates the basics making this an impossible journey for others > to move forward on that frontier. > > Bye > T. > >

Nov. 17, 2017

[Pharo 7.0-dev] Build #299: 20603-Integration-of-new-bytecode-set-Sista-V1-by-default-green-tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #299 was: SUCCESS. The Pull Request #484 was integrated: "20603-Integration-of-new-bytecode-set-Sista-V1-by-default-green-tests" Pull request url: https://github.com/pharo-project/pharo/pull/484 Issue Url: https://pharo.fogbugz.com/f/cases/20603 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Torsten Bergmann

> Well you would change the syntax of Pharo I'm not sure this is a syntax change like others. Haven yet thought about it too deeply. Where is the difference between an unary method #m and #% from the callers point of view? Either there is an argument object then % is a binary - if not it is an unary. Maybe it is hard to parse or introduces new problems. >But I would imagine that people do and will do named unary selectors within their projects (which is something quite >different to having all of it in Pharo by default) I dont want to have them inside by default in the base image - but people might be interested in implementing % (for percent), â¬ (Euro) or â° (promille) as own unary messages in an own custom external package. Or having binary messages with Unicode. Just an idea to discuss what it would mean to have such beasts or if it would be useful ;) Bye T. Â

Nov. 17, 2017

Pharo Quality: raising the quality level in Pharo 7 and onwards

by Torsten Bergmann

Hi, when we forked Pharo back in the days (2008) one of the primary goals of Pharo was and still is to provide a CLEAN SYSTEM. Now after nearly 10 years we have done already an amazing job. But we are still not there. While it is a good thing that we rewrite parts of the image, work on bootstrap and new shiny tools I unfortunately see the effect that even some newly written code has flaws or is not meeting some basic quality standards like: - having class comments - no uncategorized methods anymore - not having unused temps or unused instance variables - tests in a separate package than the code (to be able to have minified versions without tests) - class instance variable naming in lowercase - ... Meanwhile in Pharo 6 and 7 there are nice tools inside to check your code. So USE THEM. Some of you have already seen that I continue to do more and more of such cleanups in the system in various Pharo 7 contributions. Believe me: this is a boring task and one can earn much more applause for other nice and more amazing contributions - but the dirty job needs to be done to clean up the house. I also started to integrate some more "Release Tests" to make sure the things cleaned now stay clean over time and is not violated again by new Pull requests or new package inclusions. Because some of these cleanups were already done in Pharo 5 and 6 - but violated again by new contributions we now need to enforce that the image stays at that qualit level. Because I do not want to waste my time to do it over and over again! See package "ReleaseTests" or code like ProperMethodCategorizationTest, ProperlyImplementedClassesTest, #testAllClassInstanceVariablesStartLowercase and other which was written to ensure we not only GET better but also STAY better in the future. Thanks to Pavel, Marcus, Esteban and others for reviewing and integrating. Still there is a long journey in front of us, some examples: 1. Unused Temps CompiledMethod allInstances select: [:m | m ast temporaries anySatisfy: [:x | x binding isUnused ]]. => over 200 still 2. Uncategorized methods Object allSubclasses select: [:each | (each selectorsInProtocol: Protocol unclassified) notEmpty ] => over 200 still 3. Many many more uncommented classes. We need a special reminder to people who can write many code lines a day but are not able to spend a minute to write a class comment. 4. ... One person will require too much time ... several contributors helping with one contribution a day or a week will already change the game and make it possible again. Why not have a clean base image meeting basic criterias by the end of the year 2017 and ensuring with tests that we continue clean in 2018? Would'nt this be a nice birthday present to Pharos 10 years anniversary in 2018? How can you help: ================= a) you can check you own packages using the provided quality tools and before you integrate new features just cleanup your code first b) even as beginners you can help cleaning up such easy things and with simple cleanup pull requests help moving Pharo 7 forward c) you can think of other short snippets that reveal design or code flaws and post them here Then we can fix these in the image too and have the rules enforced using a separate release test d) lets discuss and define quality criterias and note them somewhere e) ideally you can reveal problems, open bugs, clean them up and then write Release tests to ensure we stay clean We should and need to definitely raise the bar. I would even be more radical to enforce more quality: - in the worst case we should not accept contributions or put new versions of packages into the image when they do not meet basic criterias, that is the idea of the release tests - if parts of the community are not seeing this as a necessity then in the worst case we need to fork Pharo again into another next level CLEANED UP system ;) So PLEASE HELP!!! Otherwise this will KILL US and it also will be and ENDLESS journey for a few people to try to clean the house. So PLEASE HELP before you work on the next shiny feature that might still violates the basics making this an impossible journey for others to move forward on that frontier. Bye T.

Nov. 17, 2017

Re: [Pharo-dev] undocumented method is quest of comment

by Pavel Krivanek

https://github.com/pharo-project/pharo/pull/487 2017-11-16 23:32 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > It's not documented because hashing is complex... > The goal is to shuffle the receiver bits and distribute them over the > available 28bits used for hash codes. > why and how it does so is a tough subject, Andres Valloud wrote a whole > book on it ;) > > The basic operation which is emulated is relatively simple, but > implementation is overly complex, because it tries to avoid creating > LargeIntegers in 32bits VM > > *16384 is <=> bitShift: 14 > bitAnd 16383 is <=> isolating lowest 14 bits... > > While at it, one should also rewrite the method contents in order to use > the new primitive available > and profit by more efficient 64bit version for 64bit VM... > > Fortunately, one can still pick the methods from Squeak :) > then forget the original authors because it really does not matter, does > it? > > > 2017-11-16 22:25 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Hi guys >> >> I would love to have a better method comment for >> >> >> hashMultiply >> | low | >> low := self bitAnd: 16383. >> ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * >> low) bitAnd: 16383) * 16384)) >> bitAnd: 16r0FFFFFFF >> >> >> Some love? >> >> Stef >> >> >

Nov. 17, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Peter UhnÃ¡k

Well you would change the syntax of Pharo, which I don't think will be met with a lot of enthusiasm. How would you distinguish it from unary messages? How would you distinguish it from something that should trigger compilation error instead? ($ for characters) Also; 1 ml is one milliliter, or one mile? Also considering how was the #, selector was shut down for Bloc vectors, this seems rather bold. :) But I would imagine that people do and will do named unary selectors within their projects (which is something quite different to having all of it in Pharo by default) Peter On Fri, Nov 17, 2017 at 10:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > just something to think about: one thing I always liked about Smalltalk is > that it allows for nice DSL's. We have nice things > like a unit framework in Pharo, ... > > In the most simple case one can easily implement own units just by > providing a unary messages: > > 1 m > 1 second > 1 px > 1 EUR > > One can easily implement an own Money class with a currency and then do > polymorphic tricks like > > 10 EUR + 20 EUR > > But we can currently can not implement special unary selectors (including > special unary selectors with unicode) like: > > 100 % > 20 $ > 40 â¬ > 12 â° (for promille) > > Especially things like 20 % would be nice for layout issues or other (Bloc > comes to mind). > > Maybe we should put that on the roadmap of Pharo because IMHO it would be > cool to support such things in the > future. Dont know how much effort it currently means on the technical > level but maybe others can comment. > > Thx > T. > >

Nov. 17, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Sven Van Caekenberghe

>From one perspective, full names are clearer at the cost of some typing 33 percent 45 dollar 100 kilometerPerHour 4 newtonMeter 200 bitsPerSecond And just like there is a limited namespace for class names (and prefixes to separate them), the namespace of selectors is global and limited too. #percent and #second(s) already exist, for example. So there might be conflicts. > On 17 Nov 2017, at 10:32, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > just something to think about: one thing I always liked about Smalltalk is that it allows for nice DSL's. We have nice things > like a unit framework in Pharo, ... > > In the most simple case one can easily implement own units just by providing a unary messages: > > 1 m > 1 second > 1 px > 1 EUR > > One can easily implement an own Money class with a currency and then do polymorphic tricks like > > 10 EUR + 20 EUR > > But we can currently can not implement special unary selectors (including special unary selectors with unicode) like: > > 100 % > 20 $ > 40 â¬ > 12 â° (for promille) > > Especially things like 20 % would be nice for layout issues or other (Bloc comes to mind). > > Maybe we should put that on the roadmap of Pharo because IMHO it would be cool to support such things in the > future. Dont know how much effort it currently means on the technical level but maybe others can comment. > > Thx > T. >

Nov. 17, 2017