- Pharo-dev - lists.pharo.org

[Wanted] Content for Newsletter
by Marcus Denker Feb. 7, 2018

Feb. 7, 2018

Hi, We are sending a monthly newsletter, see http://newsletter.pharo.org It has a collection of links gathers during the month, but in addition 2-3 larger âmini articlesâ If someone has ideas for small articles like this â> send me a mail. Marcus

1 0

Which was the way to tag methods so that Spotter think they are examples?
by Mariano Martinez Peck Feb. 6, 2018

Feb. 6, 2018

I remember that Spotter was able to detect that some methods were examples and display them differently. Do I remember correctly? I guess some pragma? Anyway, appreciated any hint. Cheers, -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo 7.0-dev] Build #506: 21124 ffi should work without the sources
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

There is a new Pharo build available! The status of the build #506 was: FAILURE. The Pull Request #750 was integrated: "21124 ffi should work without the sources" Pull request url: https://github.com/pharo-project/pharo/pull/750 Issue Url: https://pharo.fogbugz.com/f/cases/21124 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #505: 21242-improve-includesMethod
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

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

1 0

[Pharo 7.0-dev] Build #504: 21243-add-testReifyMethodArgsByNameBefore
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

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

1 0

[Pharo 7.0-dev] Build #503: 21241-remove-comment-Extremely-Slow-from-methodSourceContainingIt
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

There is a new Pharo build available! The status of the build #503 was: FAILURE. The Pull Request #801 was integrated: "21241-remove-comment-Extremely-Slow-from-methodSourceContainingIt" Pull request url: https://github.com/pharo-project/pharo/pull/801 Issue Url: https://pharo.fogbugz.com/f/cases/21241 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #502: 19702-glmSubscriptions-not-needed-in-SubscriptionRegistry
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

There is a new Pharo build available! The status of the build #502 was: SUCCESS. The Pull Request #777 was integrated: "19702-glmSubscriptions-not-needed-in-SubscriptionRegistry" Pull request url: https://github.com/pharo-project/pharo/pull/777 Issue Url: https://pharo.fogbugz.com/f/cases/19702 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #501: 21240-update-iceberg-to-067
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

There is a new Pharo build available! The status of the build #501 was: SUCCESS. The Pull Request #800 was integrated: "21240-update-iceberg-to-067" Pull request url: https://github.com/pharo-project/pharo/pull/800 Issue Url: https://pharo.fogbugz.com/f/cases/21240 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #500: 21236-Sometimes-the-debugger-opens-with-the-context-one-off
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2018

Feb. 6, 2018

There is a new Pharo build available! The status of the build #500 was: SUCCESS. The Pull Request #797 was integrated: "21236-Sometimes-the-debugger-opens-with-the-context-one-off" Pull request url: https://github.com/pharo-project/pharo/pull/797 Issue Url: https://pharo.fogbugz.com/f/cases/21236 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Weird ZnClient benchmarking result
by Sven Van Caekenberghe Feb. 6, 2018

Feb. 6, 2018

Hi, While benchmarking ZnClient I encountered something weird and counter intuitive that I cannot explain. This was on macOS running Pharo 7 and 6. First you need to setup a fast local HTTP server, can be anything, for example: $ brew install nginx $ brew services start nginx $ curl http://localhost:8080 In Pharo, the benchmark code looks as follows: ZnClient new in: [ :client | [ client get: 'http://localhost:8080' ] bench ]. On my machine this gives about 2500 req/s. ZnClient uses object logging: it emits special event objects that contain information regarding what happens (full details and timing information) using an Announcer. Subscribers can then decide what to do with this detailed information. This mechanism is always active, but there is an option to turn it totally off for maximum performance: ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080' ] bench ]. This gives about 3000 req/s, a non-trivial + 500 req/s improvement. Now comes the weird thing. GT contains a custom view for Announcers, inspect: ZnLogEvent announcer. And select the Announcements tab. Leave this window open. Now, the first expression (with full logging enabled and an active subscriber with a UI) is way FASTER than first, it yields about 7000 to 8000 req/s. Since the benchmark runs in the main UI thread, no actual drawing happens until the expression finishes. Running both expression inside a Time profiler show how in the first case significant time (actually *most* time ;-) is spent in the logging: In the second case, with logging disabled, that changes to: One has to take into account that the request has to be processed by the server, so from the client's perspective, most time will always be spent waiting for a reply, #readResponse. With the logging enabled, probably less time is spent waiting, since the client does a bit more work. Still what should be slower is more than 2 times as fast ! I have a feeling that this has to do with scheduling (probably interacting with network IO), as going deep into the last #readResponse above, I see: But I still cannot understand why doing apparently more work results in faster throughput. Can anyone explain this behaviour ? Thx, Sven

6 8