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

Re: [Pharo-dev] [Pharo 7.0-dev] Build #510: 21246-Store-main-window-title

by Marcus Denker

> On 8 Feb 2018, at 14:17, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #510 was: FAILURE. > > The Pull Request #809 was integrated: "21246-Store-main-window-title" > Pull request url: https://github.com/pharo-project/pharo/pull/809 > > Issue Url: https://pharo.fogbugz.com/f/cases/21246 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> I see multiple times in the logs: [unix-32] Downloading the latest pharoVM: [unix-32] http://files.pharo.org/get-files/70/pharo-linux-stable.zip <http://files.pharo.org/get-files/70/pharo-linux-stable.zip> [unix-32] mkdir: cannot create directory âpharo-vmâ: File exists [kernel-unix-32] [branch_Pipeline_development-CMOUMEH7DVLJPL2EIJ6VPEHUQRS3W4AK3FD4ESTKJ3YGKZERQFUQ] Running shell script [Pipeline] [unix-32] echo [unix-32] Tests couldn't complete to run due to an exception I wonder if the mkdir is the problem? Even if not, it would be nice to get rid of the error... Marcus

Feb. 8, 2018

[Pharo 7.0-dev] Build #510: 21246-Store-main-window-title

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

There is a new Pharo build available! The status of the build #510 was: FAILURE. The Pull Request #809 was integrated: "21246-Store-main-window-title" Pull request url: https://github.com/pharo-project/pharo/pull/809 Issue Url: https://pharo.fogbugz.com/f/cases/21246 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 8, 2018

Re: [Pharo-dev] Reviewing Changes ?

by Marcus Denker

> On 7 Feb 2018, at 11:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I made notes and will add a page with all the infos later today. (for http://pharo.org/contribute <http://pharo.org/contribute> ) > I added a simple page as a first step: http://pharo.org/review-fix <http://pharo.org/review-fix> Marcus

Feb. 8, 2018

Re: [Pharo-dev] VMs build process restored

by Esteban Lorenzano

> On 8 Feb 2018, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Feb 6, 2018 at 5:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> (it was broken since december) >> >> Which means latest vm versions are latest builds from OSVM: >> >> 64bit >> >> â¢ http://files.pharo.org/get-files/70/pharo64-mac-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-linux-threaded-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-linux-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-win-latest.zip >> 32bit >> >> â¢ http://files.pharo.org/get-files/70/pharo-linux-threaded-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-linux-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-mac-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-win-latest.zip >> >> Hints >> >> â¢ MacOS VMs now are signed! This should fix a lot of problems we had before. >> â¢ Please take note that win64 build lacks all library dependencies, and many things will not work (working on that). >> Thanks to Fabio to help me put all the pieces together. >> >> > ) > cheers, >> Esteban > > Hi! > > Just a little feedback. > > Currently, at Synectique, we added Pharo 61 64bits build to our > Jenkins. Those builds failed **a lot** because of segmentation faults. > We added a mechanism to retry two times when there was a segfault and > even like that we have failing builds. > > Since the restoration of the vms I removed the retry mechanism and I > added a hack to use the latest Pharo 70 vm > (http://files.pharo.org/get-files/70/pharo64-linux-latest.zip) instead > of the stable pharo 61 vm. Since then, there was no crash due to the > VM. > This is a great improvement. > Then I have a question: Is it plan to release new stable 64bit vms for > Pharo 61? yes :) > Currently, our builds are based on hacks and if no problem > is detected with the latest vm it would greatly help stability-wise to > have official vms that does not crash 3/5times when we load a project. > Also, I understand it can be hard to backport vms with the resources > of the community. :) > > -- > Cyril Ferlicot > https://ferlicot.fr >

Feb. 8, 2018

Re: [Pharo-dev] [Seaside-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Maximiliano Tabacman

Up until Pharo build 382 (sha 115e95c) you could load Seaside by using:Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; loadIf you adapt the baselineOf to include Pharo 7.x BUT, from build 383 onwards, and tested again just now withÂ 509 (sha 1276a3f) the following happens:- Download Pharo -- OK- Load Seaside master -- OK- Save and quit image -- OK- Start image again -- Hangs and never completes starting In Ubuntu, this manifests as the main Pharo window opening, but never displaying anything inside it.In Windows, the VM starts and closes without any warning, and no logs are created. I have no idea why this is happening, and I am not sure if the tests in Travis cover this scenario. On Wednesday, February 7, 2018, 4:14:24 PM GMT-3, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Thanks for pushing this. I plan to work on migrating the seaside book to pillar when I'm done with the moose book and the magritte booklet. Stef On Wed, Feb 7, 2018 at 1:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Using [ https://github.com/SeasideSt/Seaside/pull/979 ] (I attach a manually modified BaselineOfSeaside3 that I used), I managed to load Seaside 3.2 (GitHub.1516790362) in Pharo 7 (Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a (32 Bit)) and at least the load and some quick testing with ZnZincSeasideAdaptor (via the spec based Seaside Control Panel) seems to indicate no direct problems. > > Metacello new >Â baseline:'Seaside3'; >Â repository: 'github://SeasideSt/Seaside:master/repository'; >Â load. > > Why don't we integrate this so that others can load Seaside 3.2 in Pharo 7 too ? > > This is _really_ important to make progress, IMHO. > > I changed WABrowser>>#updateUrl: to send #name instead of #fullName to the selected class of the model. I am not sure that is entirely correct, but it seemed to work. Apart from that, the WAImageStatus web app worked fine. > > Sven > >> On 6 Nov 2017, at 09:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> OK, Max, thanks for the reply. >> >> I will ask on the Pharo ML as well. >> >> I think it is important that Seaside works on Pharo 7, it is an important use case and test during development, and very necessary as well. >> >>> On 6 Nov 2017, at 09:40, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> We don't have a build for Pharo 7 yet. Loading from github would be the recommended way. A quick look makes me think that it will require a bit of work to get the baseline set up correctly. I can't promise anything before next weekend. >>> >>> How urgent is the situation for you? >>> >>> Cheers, >>> Max >>> >>> >>> On 5 November 2017 at 19:22:03, Sven Van Caekenberghe (sven(a)stfx.eu) wrote: >>> >>>> Hi, >>>> >>>> I am stuck trying to move my main development to Pharo 7 because I have trouble loading Seaside (which I normally do indirectly by loading the Bootstrap project). Here is my dependency: >>>> >>>> project: 'Bootstrap' with: [ >>>> spec >>>> className: 'ConfigurationOfBootstrap'; >>>> repository: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main/'; >>>> versionString: #stable ] >>>> >>>> I also tried the following: >>>> >>>> Metacello new >>>> baseline:'Seaside3'; >>>> repository: 'github://SeasideSt/Seaside:master/repository'; >>>> load. >>>> >>>> What is the right/recommended way to do it ? >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> _______________________________________________ >>>> seaside-dev mailing list >>>> seaside-dev(a)lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >>> _______________________________________________ >>> seaside-dev mailing list >>> seaside-dev(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >> > >

Feb. 8, 2018

Re: [Pharo-dev] VMs build process restored

by Cyril Ferlicot

On Tue, Feb 6, 2018 at 5:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > (it was broken since december) > > Which means latest vm versions are latest builds from OSVM: > > 64bit > > â¢ http://files.pharo.org/get-files/70/pharo64-mac-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo64-linux-threaded-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo64-linux-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo64-win-latest.zip > 32bit > > â¢ http://files.pharo.org/get-files/70/pharo-linux-threaded-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo-linux-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo-mac-latest.zip > â¢ http://files.pharo.org/get-files/70/pharo-win-latest.zip > > Hints > > â¢ MacOS VMs now are signed! This should fix a lot of problems we had before. > â¢ Please take note that win64 build lacks all library dependencies, and many things will not work (working on that). > Thanks to Fabio to help me put all the pieces together. > > ) > cheers, > Esteban Hi! Just a little feedback. Currently, at Synectique, we added Pharo 61 64bits build to our Jenkins. Those builds failed **a lot** because of segmentation faults. We added a mechanism to retry two times when there was a segfault and even like that we have failing builds. Since the restoration of the vms I removed the retry mechanism and I added a hack to use the latest Pharo 70 vm (http://files.pharo.org/get-files/70/pharo64-linux-latest.zip) instead of the stable pharo 61 vm. Since then, there was no crash due to the VM. This is a great improvement. Then I have a question: Is it plan to release new stable 64bit vms for Pharo 61? Currently, our builds are based on hacks and if no problem is detected with the latest vm it would greatly help stability-wise to have official vms that does not crash 3/5times when we load a project. Also, I understand it can be hard to backport vms with the resources of the community. :) -- Cyril Ferlicot https://ferlicot.fr

Feb. 8, 2018

Re: [Pharo-dev] [Vm-dev] OSVM pre-release 201802061430 ready to be tested

by Alistair Grant

Has anyone else run the pharo.cog.spur_linux32x86_201802061430.tar.gz VM successfully? If I try to Fetch or Pull incoming commits from Iceberg I get a "LGit_GIT_ERROR: Unsupported URL protocol" error. This also occurred with the first pre-release VM Fabio made available. The same Pharo image works without any problems in my current VM (Wed Jan 10 23:39:30 2018 -0800). OS: Ubuntu 16.04 VM: 5.0-201802061430 Tue Feb 6 17:16:07 UTC 2018 gcc 4.8.4 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Feb 6 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2324 uuid: 904abc56-e5a8-467e-a337-880211e33805 Feb 6 2018 VM: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Feb 6 15:30:09 2018 +0100 $ Plugins: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux travis-job-a0b5a72e-f64c-4657-8f31-f66a35a88881 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 i686 i686 i686 GNU/Linux plugin path: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430 [default: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/] Thanks, Alistair Stack: LGitReturnCodeEnum>>handleLGitReturnCode LGitRemote(LGitExternalObject)>>withReturnHandlerDo: LGitRemote>>fetchWithCredentials: [ :repo | | gitRemote myCommit theirCommit mergeBase | "Fetch" gitRemote := (LGitRemote of: repo named: aRemote remoteName) lookup. gitRemote fetchWithCredentials: IceCredentialsProvider default. "Decide if we can fast-forward or we must do a real merge" myCommit := repo head object. theirCommit := repo head upstream object. mergeBase := repo mergeBaseBetween: myCommit id and: theirCommit id. mergeBase = myCommit id ifTrue: [ self pullRepositoryFastForward: repo ] ifFalse: [ self pullRepository: repo merge: myCommit with: theirCommit ] ] in IceLibgitLocalRepository>>pullFrom: in Block: [ :repo | ... [ | repo | repo := (LGitRepository on: self location) open. aBlock value: repo ] in IceLibgitLocalRepository>>withRepoDo: in Block: [ | repo |... [ self checkInitialized. aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self checkInitialized.... [ activeProcess psValueAt: index put: anObject. aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject.... BlockClosure>>ensure: LGitActionSequence(DynamicVariable)>>value:during: LGitActionSequence class(DynamicVariable class)>>value:during: LGitGlobal class>>runSequence: IceLibgitLocalRepository>>withRepoDo: IceLibgitLocalRepository>>pullFrom: IceRepository>>pullFrom: IceRepository>>pull [ self repository pull ] in IceRepositoryModel>>pull in Block: [ self repository pull ] BlockClosure>>on:do: IceRepositoryModel>>pull MessageSend>>value MessageSend>>cull: [ :presentation | presentation selection ifNotNil: [ :sel | (MessageSend receiver: sel selector: actionSelector) cull: presentation ] ] in GLMGenericAction>>selectionAction: in Block: [ :presentation | ... BlockClosure>>glamourValueWithArgs: GLMGenericAction(GLMAction)>>actOn: GLMGenericAction(GLMAction)>>morphicActOn: [ :ann | ann action morphicActOn: aPresentation ] in GLMMorphicFastTableRenderer(GLMMorphicWidgetRenderer)>>installActionsOnModel:fromPresentation: in Block: [ :ann | ann action morphicActOn: aPresentation ] BlockClosure>>cull: BlockClosure>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] BlockClosure>>on:do: BlockClosure>>on:fork: On 7 February 2018 at 08:22, Fabio Niephaus <lists(a)fniephaus.com> wrote: > > Dear all, > > We were able to fix all build problems today, so here is the OpenSmalltalkVM pre-release 201802061430 [1]. > The Pharo VMs for macOS are now correctly signed. More importantly, they come with a fix for "Crashes while typing on macOS Sierra" [2]. > > Please give the VMs a try if you have some time and report any bugs at [3]. > > Best, > Fabio > > [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201802061430 > [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 > [3] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues >

Feb. 8, 2018

Improve "Senders of"

by Marcus Denker

Hi, I tried to improve the âsenders ofâ behaviour in the case where you just put a selector (e.g. in the playground). needs some testing: https://pharo.fogbugz.com/f/cases/21251/Improve-Senders-of <https://pharo.fogbugz.com/f/cases/21251/Improve-Senders-of> https://github.com/pharo-project/pharo/pull/810 <https://github.com/pharo-project/pharo/pull/810> Marcus

Feb. 8, 2018

Re: [Pharo-dev] Iceberg - creating virgin repos

by Pavel Krivanek

Does it work if you add the package, commit changes (without push) and then in separate step do the push? -- Pavel 2018-02-08 4:28 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > If in the System Browser I do <Add Package...> and work a bit on it, > then later want to push it to a new github repo, what is the > recommended procedure? > > As a rough guess I tried the "New repository" button, then added the > package and a remote, but then trying to push gives me an error... > LGit_GIT_EUNBORNBRANCH: Reference 'refs/heads/master' not found > > At the moment I've only had success first creating the repo on github, > then cloning it - so I/m not sure how the "New repository" button is useful. > > cheers -ben >

Feb. 8, 2018

Re: [Pharo-dev] How to force a BaselineOf to load ?

by Sven Van Caekenberghe

Thanks Cyril, I think I understand. I saw you opened an issue for this. I am working on upgrading my builds for pharo 7. > On 7 Feb 2018, at 15:12, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Feb 6, 2018 at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> > Hi, > >> I have a Pharo 4 (#40627) image that already contains P3. Now I want to update P3, without completely rebuilding this image from scratch. >> >> It seems as if an expression like >> >> Metacello new >> baseline: 'P3'; >> repository: 'github://svenvc/P3'; >> load. >> >> executed like >> >> $ ../bin/pharo build-trackit.image eval --save "Metacello new baseline: 'P3'; repository: 'github://svenvc/P3'; load" >> >> does not really reload the code. How can I force it to (re)load ? >> > IIRC, Dale worked on Metacello to introduce a new project kind in the > baseline to manage this problem. > > See thread: > http://forum.world.st/ANN-Metacello-support-for-GitFileTree-metadata-less-m… > > So you need to implement this method in the baseline: > > projectClass > > ^ MetacelloCypressBaselineProject > > Quoted from Dale > (http://forum.world.st/unsolicited-package-cache-use-td5060335.html > Jan 18, 2018; 4:10pm): > Â«if not, then what looks like a package-cache problem could be that > you haven't told Metacello that you are using a metadataless > filetree/tonel repository. > > Metacello has an internal rule to not load Monticello packages of the > same version, since they are already loaded. However, when using > metadataless repositories the filetree/tonel Monticello package > readers typically generate a package name using the author/version > `-cypress.1`, which make Metacello think that the versions are the > same and the package is not loaded ... by including the above method > in your baselineof, Metacello will know to ignore the Monticello > author/version of the package and always load it.... > > Of course, because Monticello only installs changed definitions when > loading a package, "loading the same package over and over again" > costs a little bit in loading the _definitions_ into the image from > disk, but doesn't end up compiling any new methods or creating new > classes ...Â» > BUT! Because there is a but... This is not present by default in > Pharo... To get it, we need to upgrade Matacello :( > > >> Thx, >> >> Sven > > > > -- > Cyril Ferlicot > https://ferlicot.fr

Feb. 8, 2018