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

[Pharo 7.0-dev] Build #552: 21259-Add-an-option-to-protect-by-password-command-lines-for-deployment
by ci-pharo-ci-jenkins2＠inria.fr Feb. 16, 2018

Feb. 16, 2018

There is a new Pharo build available! The status of the build #552 was: SUCCESS. The Pull Request #816 was integrated: "21259-Add-an-option-to-protect-by-password-command-lines-for-deployment" Pull request url: https://github.com/pharo-project/pharo/pull/816 Issue Url: https://pharo.fogbugz.com/f/cases/21259 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #551: 21347-Enhance-the-Image-cleaner-to-gather-more-tests-packages
by ci-pharo-ci-jenkins2＠inria.fr Feb. 15, 2018

Feb. 15, 2018

There is a new Pharo build available! The status of the build #551 was: SUCCESS. The Pull Request #892 was integrated: "21347-Enhance-the-Image-cleaner-to-gather-more-tests-packages" Pull request url: https://github.com/pharo-project/pharo/pull/892 Issue Url: https://pharo.fogbugz.com/f/cases/21347 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #550: 21346-Compiler-tests-should-be-in-its-own-package
by ci-pharo-ci-jenkins2＠inria.fr Feb. 15, 2018

Feb. 15, 2018

There is a new Pharo build available! The status of the build #550 was: SUCCESS. The Pull Request #891 was integrated: "21346-Compiler-tests-should-be-in-its-own-package" Pull request url: https://github.com/pharo-project/pharo/pull/891 Issue Url: https://pharo.fogbugz.com/f/cases/21346 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [squeak-dev] WebClient httpGet: 'http://freegeoip.net/json/' works on windows not linux
by Tobias Pape Feb. 15, 2018

Feb. 15, 2018

Hi, (cc-ing vm-dev and pharo b/c severity) > On 15.02.2018, at 15:58, Louis LaBrunda <Lou(a)Keystone-Software.com> wrote: > > Hi Levente, > > Thanks for the post. OpenSSL version 1.1.0f is installed. Yes, OpenSSL 1.1 is not yet supported by SqueakSSL. OpenSSL did a major refactoring from 1.0.2 to 1.1.0. Neither the OpenSSL-plugins from before February nor the current ones will work with 1.1. Sorry. As soon as I get roughly 8-10 hours of leisure time, I'm on it. Best regards -Tobias > > Lou > >> On Wed, 14 Feb 2018, Louis LaBrunda wrote: >> >>> Hi Everyone, >>> >>> I use the following: >>> >>> Json readFrom: (ReadStream on: (WebClient httpGet: 'http://freegeoip.net/json/', (WebClient >>> httpGet: 'https://api.ipify.org') content) content utf8ToSqueak). >>> >>> to get latitude and longitude from the internet. It works great on windows but not linux >>> (Raspbian). The #primitiveSSLCreate fails. I expect something linux specific like some FFI or >>> something is missing. Anyone have any idea what? >> >> If it worked on Linux before, then you should use the SqueakSSL plugin >> from an older VM. The code has been changed recently. >> If it never worked before, then you probably don't have openssl 1.0.x >> installed. >> >> Levente >> >>> >>> Lou >>> -- >>> Louis LaBrunda >>> Keystone Software Corp. >>> SkypeMe callto://PhotonDemon >> > -- > Louis LaBrunda > Keystone Software Corp. > SkypeMe callto://PhotonDemon > >

1 0

[Pharo 7.0-dev] Build #549: 21287-Fix-lint-problems-in-testIndexOfSubCollectionStartingAtIfAbsent
by ci-pharo-ci-jenkins2＠inria.fr Feb. 15, 2018

Feb. 15, 2018

There is a new Pharo build available! The status of the build #549 was: FAILURE. The Pull Request #889 was integrated: "21287-Fix-lint-problems-in-testIndexOfSubCollectionStartingAtIfAbsent" Pull request url: https://github.com/pharo-project/pharo/pull/889 Issue Url: https://pharo.fogbugz.com/f/cases/21287 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Techtalk Today: Link
by Marcus Denker Feb. 15, 2018

Feb. 15, 2018

Hi, TechTalk today at 17:00 Local European time (in 45 minutes) https://association.pharo.org/event-2797065 <https://association.pharo.org/event-2797065> https://www.youtube.com/c/MarcusDenker/live <https://www.youtube.com/c/MarcusDenker/live> Marcus

1 0

Searching for an internship
by Maxime Roelandt Feb. 15, 2018

Feb. 15, 2018

Hi all, I'm searching for an internship as student of Master's 2 degree in Computer Science at University of Lille1. My skills are essentially in Smalltalk and C. Minimum 1500 â¬ net salary. I am available from March : Period 4 to 6 months. I've worked for RMoD team, two times : - 2016 : FileOuterNG -> VisualWorks code converter to Pharo - 2017 : Pillar reengineering. Please find attached my CV if you're interested in ++

2 3

[update 6.0] #60532
by Marcus Denker Feb. 15, 2018

Feb. 15, 2018

60532 ----- 20740 isAbstract not working correctly on 64bit https://pharo.fogbugz.com/f/cases/20740

1 0

[update 6.1] #60531
by Marcus Denker Feb. 15, 2018

Feb. 15, 2018

60531 ----- 20254 Playground should ask to create class for non-Existing Globals https://pharo.fogbugz.com/f/cases/20254 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo60/main/OpalCompiler-Core-TheIntegrat… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Pharo6-TheIntegrator.… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Core-TheIntegrator.1.… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Changes-TheIntegrator… http://smalltalkhub.com/mc/Pharo/Pharo60/main/Iceberg-Adapters-TheIntegrato…

1 0

OpalCompiler evaluate speed
by Nicolas Cellier Feb. 15, 2018

Feb. 15, 2018

I have an ArbitraryPrecisionFloatTests doing an exhaustive test for printing and reevaluating all positve half precision float. That's about 2^15 or approximately 32k loop which evaluate snippets like (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10) The test was naively written with Compiler evaluate: and was using the legacy Compiler. If I rewrite self class compiler evaluate: the test times out. Let's see what increase is necessary: [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate ] timeToRun. -> 3s with legacy Compiler -> 14s with OpalCompiler It's not unexpected that intermediate representation (IR) reification has a cost, but here the 4.5x is a bit too much... This test did account for 1/4 of total test duration already (3s out of 12s). With Opal, the total test duration doubles... (14s out of 23s) So let's analyze the hot spot with: MessageTally spyOn: [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate ]. (I didn't use AndreasSystemProfiler becuase outputs seems a bit garbbled, no matter since the primitives do not account that much, a MessageTally will do the job) I first see a hot spot which does not seem that necessary: | |24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode >From the comments I understand that AST-based stuff requires a pattern (DoIt) and an explicit return (^), but this expensive formatting seems too much for just evaluating. i think that we should change that. Then comes: | |20.7% {2902ms} RBMethodNode>>generate: which is split in two halves, ATS->IR and IR->bytecode | | |9.3% {1299ms} RBMethodNode>>generateIR | | | |11.4% {1596ms} IRMethod>>generate: But then I see this cost a 2nd time which also leave room for progress: | |10.9% {1529ms} RBMethodNode>>generateIR | | |12.9% {1814ms} IRMethod>>generate: The first is in RBMethodNode>>generateWithSource, the second in OpalCompiler>>compile Last comes the parse time (sourceCode -> AST) | 13.2% {1858ms} OpalCompiler>>parse Along with semantic analysis | 6.0% {837ms} OpalCompiler>>doSemanticAnalysis ----------------------------------- For comparison, the legacy Compiler decomposes into: | |61.5% {2223ms} Parser>>parse:class:category:noPattern:context:notifying:ifFail: which more or less covers parse time + semantic analysis time. That means that Opal does a fair work for this stage. Then, the direct AST->byteCode phase is: | 16.9% {609ms} MethodNode>>generate IR costs almost a 5x on this phase, but we know it's the price to pay for the additional features that it potentially offers. If only we would do it once... And that's all for the legacy one... -------------------------------------- This little exercize shows that a 2x acceleration of OpalCompiler evaluate seems achievable: - simplify the uselessely expensive formatted code - generate bytecodes once, not twice Then it will be a bit more 2x slower than legacy, which is a better trade for yet to come superior features potentially brought by Opal. It would be interesting to carry same analysis on method compilation

6 12