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

Re: [Pharo-dev] PharoLauncher feedback

by Christophe Demarey

Hi StÃ©phane, > Le 22 sept. 2017 Ã 20:34, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Hi christophe > > I took the bleeding edge and here are my report. > > - We need a signed VM because the security on mac is getting in our way. Right. It is not directly related to the launcher. Pharo binaries need to be signed. OS packaging scripts are shared (launcher, std pharo distribution). > - I got PrimitiveFailed: CreatedDirectory in MacStore failed. > So I do not know what to do :( > > I do not get why I cannot write on my download folder ;( but this > error should be caught. > > - Pharo.app should be renamed PharoLauncher > - the Quit menu is showing SqueakOSXApp and the about too. This two points are not easy because they are related to how the VM is built. I tried to use Alien and OS X integration to change menus at runtime but it takes time as I do not know a lot on OS X api. We should put that on the TODO list. > - There is a template 7.0 (beta) but it does not exist below Pharo60 > We should not have Pharo 60 but Pharo 6.1 fixed > else it seems to work. > > well no :) > I downloaded Pharo70 alpha and I got a problem with FT2Error primitive failed. > May be this is normal. I do not know. Not sure you tested the latest version. I did a lot of improvements (especially for Linux) on the launcher to ensure the environment you get when forking from the launcher process is clean (setting the working dir and clean env variable set by the VM used by the launcher). It should be fine now.

Sept. 29, 2017

Re: [Pharo-dev] Iceberg Contribution Barrier

by Sean P. DeNigris

EstebanLM wrote > you do not need to update Iceberg > ... > please, take the instructions from Guilleâs place as your guide: Just so I'm clear, do you mean to adapt Guille's instructions to the Iceberg repo? IIUC Steph's recent post, patches to outside projects like Bloc and Iceberg must be pushed to their respective canonical repos, no? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 29, 2017

Re: [Pharo-dev] CI does not finish (PR 309)

by Torsten Bergmann

I'm lost on this one and would really appreciate if someone could check why it is blocked in the CI (it was running green a few days ago and I only changed SmalltalkImage>>#lastUpdateString. All other changes where just to retrigger the CI. The log does not tell me anything useful beside that it is always hanging at the same point 2017-09-29 12:33:04 (573 KB/s) - âidea11.zipâ saved [152003/152003] [Compiler] Installing RPackage Thanks T. > Gesendet: Freitag, 29. September 2017 um 12:56 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] CI does not finish (PR 309) > > No, it seems to work.. we now had some issues where the test run was successful > > Marcus > > > On 29 Sep 2017, at 10:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > I think the reason is that the last image opens an epicea window > > to recover codeâ¦ which it should not. > > > >> On 29 Sep 2017, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > >> For whatever reason the CI jobs for PR's to Pharo 7 runs endless and never finishes. > >> It run well a few days ago ... > >> > >> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > >> > >> Any ideas? > >> > >> > > > > >

Sept. 29, 2017

[Pharo 7.0-dev] Build #162: 20205-wrong-comment-of-withIndexDo

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

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

Sept. 29, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by Ronie Salgado

Hi ClÃ©ment, I just checked on my machine and it is also not working. It seems to be a VM bug. It will take me some time to debug it. I have some suspicious on ioProcessEvents . Best regards, Ronie 2017-09-29 10:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > On Fri, Sep 29, 2017 at 10:29 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> Hi, >> >> IMHO, it will make Pharo much more robust if core libraries as sdl, >> cairo, etc will be shipped with each plateform dependent virtual machine >> and the image modified accordingly to use these core libraries. >> > > That's how it is now but some of it is not working (Here SDL events and > there are 2 SDL2 libs by default). > > I think we should still have a minimal image starting with a minimal UI > without using FFI/SDL/Cairo or whatever lib. Else when we start on a > platform where one of this thing is not properly supported yet (See the > problem on the raspberry pie with some Pharo alpha version) it is too hard > to understand what is going on. > > >> >> The delivery of Pharo application to end users is an issue because of >> these recuring problem. > > > Honestly I was trying to write a doc on how to deploy Pharo client app > with SDL2 and Cairo but I have only a version working in Pharo 4 on Mac and > Linux, while in theory I could have it working in Windows/Mac/Linux in the > latest Pharo. > > >> Hilaire >> >> >> >> Le 28/09/2017 Ã 15:02, ClÃ©ment Bera a Ã©crit : >> >>> Btw for some reason in the one-click version of Pharo 32 bits on Mac >>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >>> conflicts (the VM use randomly one lib or the other). I randomly chose one >>> that I use and deleted the other one, do you have advises on which one I >>> should prefer ? Maybe the events are working only with the other one ? >>> >>> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> >

Sept. 29, 2017

[Pharo 7.0-dev] Build #163: 20465-Odd-behaviour-of-flatCollect-on-Dictionary-

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

There is a new Pharo build available! The status of the build #163 was: SUCCESS. The Pull Request #320 was integrated: "20465-Odd-behaviour-of-flatCollect-on-Dictionary-" Pull request url: https://github.com/pharo-project/pharo/pull/320 Issue Url: https://pharo.fogbugz.com/f/cases/20465 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 29, 2017

Re: [Pharo-dev] CI does not finish (PR 309)

by Marcus Denker

No, it seems to work.. we now had some issues where the test run was successful Marcus > On 29 Sep 2017, at 10:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I think the reason is that the last image opens an epicea window > to recover codeâ¦ which it should not. > >> On 29 Sep 2017, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> For whatever reason the CI jobs for PR's to Pharo 7 runs endless and never finishes. >> It run well a few days ago ... >> >> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… >> >> Any ideas? >> >> >

Sept. 29, 2017

[Pharo 7.0-dev] Build #161: 20170-Better-collect-method-comment

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

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

Sept. 29, 2017

Re: [Pharo-dev] CI does not finish (PR 309)

by Marcus Denker

I think the reason is that the last image opens an epicea window to recover codeâ¦ which it should not. > On 29 Sep 2017, at 10:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > For whatever reason the CI jobs for PR's to Pharo 7 runs endless and never finishes. > It run well a few days ago ... > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > Any ideas? > >

Sept. 29, 2017

Re: [Pharo-dev] String Interpolation

by Sven Van Caekenberghe

> On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > This solution will not work for environments without sources too where names like t1, t2 are used for temporary variables. That is true. I often wonder why we can't keep at least the variables names, it would not be that expensive. There was this problem with FFI that needed source code access as well. It would also help the debugger and make the decompiler more powerful. > Anyway, nice idea. > > -- Pavel > > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> napsal(a): > Hi, > > I got into a little office discussion about string interpolation as it is done in different programming languages. > > In Pharo we have String>>#format: which is pretty nice. It works as follows: > > | x y | > x := 123. > y := #foo. > 'x={1} and y={2}' format: { x. y }. > > It is also possible to use a dictionary with keys, like this: > > | x y | > x := 123. > y := #foo. > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. > > But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings. > > Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work: > > | x y | > x := 123. > y := #foo. > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate. > > => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793' > > Here is the implementation I came up with: > > String>>#interpolate > "Format the receiver by interpolating the evaluation of expressions > in between curly brackets in the context of the sender as in the following 3 oneline examples. > 'Today is {Date today}' interpolate. > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. > 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." > > | senderContext | > senderContext := thisContext sender. > ^ self class new: self size streamContents: [ :out | | stream | > stream := self readStream. > [ stream atEnd ] whileFalse: [ | currentChar | > (currentChar := stream next) == ${ > ifTrue: [ | expression result | > expression := stream upTo: $}. > result := Compiler new > evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false. > out nextPutAll: result asString ] > ifFalse: [ > currentChar == $\ > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ] > ifFalse: [ out nextPut: currentChar ] ] ] ] > > It is a hack that could certainly be improved. And there is of course an obvious security problem. > > Thoughts ? > > Sven > >

Sept. 29, 2017