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

Is SmalltalkCI working for Pharo projects?

by Gabriel Cotelli

All the latest builds I've tried are failing in Travis with "out of memory" errors aparently after running the tests. It's always the same error and for different Pharo versions (4.0 5.0 6.1 7.0 , etc) See for example https://travis-ci.org/ba-st/Willow/jobs/307025742 Anyone noticed something similar? Regards, Gabriel

Nov. 25, 2017

Re: [Pharo-dev] I love the launcher!!!!

by Sean P. DeNigris

bpi wrote > UndefinedObject(Object)>>doesNotUnderstand: #, > PhLVirtualMachineManager>>vmFileName I usually get an error that looks like that when I try to launch a pre Pharo-5 image. IIUC when Launcher is determining which VM to useâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 25, 2017

Re: [Pharo-dev] I love the launcher!!!!

by Bernhard Pieber

Hi Stef, I just found download links on this page: https://github.com/pharo-project/pharo-launcher They point to Jenkins build artefacts. Thank you for implementing the launcher. As a newbie I ran into some questions: I guess the launcher is not self-updating, right? If not, how can I find out if I already have the latest version? I donât really understand what Local means. Is there a difference between Local > Pharo 6.1 (stable) and Official distributions > Pharo 6.1 (stable)? And what is the difference between Local > Pharo6.1 (stable) and Local > latest? Hmm, when I launched Local > latest I got a debugger[1]. What also bothers me is that I cannot switch to the white theme in the settings. I just canât read the UI on the dark theme. Cheers, Bernhard Author: BernhardPieber [1] UndefinedObject(Object)>>doesNotUnderstand: #, PhLVirtualMachineManager>>vmFileName [ :bar | bar label: 'Determining Image version'. vm := self availableVirtualMachines at: self vmFileName ifAbsent: [ bar label: 'Fetching VM to run Pharo ' , self imageVersion , ' images'; current: 25. self fetchVm. vm := self availableVirtualMachines at: self vmFileName. bar label: 'Fetching sources files for Pharo ' , self imageVersion; current: 50. self fetchSourcesFiles. bar label: 'Running the image'; current: 100. vm ] ] in PhLVirtualMachineManager>>vm [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: BlockClosure>>cull: [ ^ block cull: self ] in [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run [ activeProcess psValueAt: index put: anObject. aBlock value ] in CurrentJob(DynamicVariable)>>value:during: BlockClosure>>ensure: CurrentJob(DynamicVariable)>>value:during: CurrentJob class(DynamicVariable class)>>value:during: [ self prepareForRunning. CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run BlockClosure>>ensure: Job>>run MorphicUIManager(UIManager)>>displayProgress:from:to:during: MorphicUIManager>>informUserDuring: PhLVirtualMachineManager>>vm PhLImage>>launch PhLLaunchImageCommand>>execute PhLLaunchImageCommand(PhLCommand)>>executeIfApplicable PhLCommandButton>>performAction MorphicButtonAdapter>>action PluggableButtonMorph>>performAction: [ :m | (m containsPoint: evt cursorPoint) ifTrue: [ m enabled ifTrue: [ m performAction: evt ] ] ] in PluggableButtonMorph>>mouseUp: Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [ ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: BlockClosure>>on:do: WorldMorph(PasteUpMorph)>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEventsFromQueue: HandMorph>>processEvents [ :h | self activeHand: h. h processEvents. self activeHand: nil ] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle WorldMorph class>>doOneCycle [ [ WorldMorph doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess [ self value. Processor terminateActive ] in BlockClosure>>newProcess > Am 23.11.2017 um 09:51 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > I love the PharoLauncher. > It helps me to manage my parallel development and projects. > > We should put a link on the Pharo web site because > > http://files.pharo.org/platform/launcher/ > > is arcane. > > Stef

Nov. 25, 2017

Re: [Pharo-dev] Iceberg Clone Location

by Sean P. DeNigris

Sean P. DeNigris wrote > Iceberg seems to expect clones to be in > {sharedRepoFolder}/{gitHubUser}/{projectName} I wonder if this is even conceptually correct. After all, wouldn't different users' forks just be different remotes on the same repo in the git worldview? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 25, 2017

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

by Thierry Goubier

Hi StÃ©phane, Le 25/11/2017 Ã 14:08, Stephane Ducasse a Ã©critÂ : > Hi all > > so what is the situation? When I tested, and following Gabriel input, all the zeroconf vms for Pharo61 or 7 linux 64bits segfault (stable or latest, thread). Recent vms for pharo linux 64bits downloaded from opensmalltalk do not segfault. Thierry > Is the latest version crashing? > > Stef > > On Wed, Nov 22, 2017 at 1:18 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> >> >> 2017-11-22 13:03 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >>> >>> Well that make sense. The problem is that the stable VM is crashing with a >>> segmentation fault :( on Linux/64 bits. >> >> >> I can confirm. >> >> Given that later vms do not segfault, Eliot told me he prefers to consider >> the bug(*) solved. >> >> Thierry >> >> (*) But I have no idea about what the bug is. Running the stable pharo vm >> under valgrind also triggers the segfault, valgrind complains a lot and >> signal permamently lost memory, but this is the same with all vms as far as >> valgrind is concerned (i.e. non-crashing and even non-pharo vms are no >> better, except that they don't crash). >> >>> >>> >>> On Nov 22, 2017 08:46, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >>>> >>>> >>>> >>>> On 21 Nov 2017, at 21:00, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>> >>>> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget >>>> -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes with >>>> a segmentation fault also. >>>> >>>> >>>> by concept, there is no âlatest 6.1 vmâ since latest is âunstableâ >>>> (alpha) and 6.1 is not (or it shouldnât). >>>> >>>> latest is always related to the development version. >>>> >>>> Esteban >>>> >>>> >>>> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier >>>> <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>> Hi Gabriel, >>>>> >>>>> I had such segfaults with the stable 6.1/64bits on Linux. I solved them >>>>> by ensuring the use of a more recent version than the stable one. >>>>> >>>>> Thierry >>>>> >>>>> >>>>> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >>>>>> >>>>>> I've created the following issue: >>>>>> >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-c… >>>>>> I can reproduce it easily so if you need some more info let me know. >>>>>> >>>>>> Regards, >>>>>> Gabriel >>>>> >>>>> >>>> >>>> >> > >

Nov. 25, 2017

Re: [Pharo-dev] Pharo Filter usability due to same background as List (Iceberg)

by Cyril Ferlicot

On mar. 21 nov. 2017 at 21:39, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I do not know if this is only an issue of Iceberg or of the themes in > general: > > Due to the topic of todays techtalk I added "DiscordSt" repository to > Iceberg leading to the attached screenshot. > > I wondered why there are only 7 packages while I was pretty sure that there > were more packages in the GitHub page of the repo. > > So it LOOKED LIKE THE LIST ENDED/ONLY HAS A FEW ITEMS because the filter is > displayed right at the bottom of the list. > > You can call me stupid - but I initially thought of an Iceberg synch > synch issue were some packages were not downloaded/cloned - but then after > several seconds > I realized that the list just ends because of the filter area and there > are more > items - one just has to scroll. > > This is OK but I interpreted the white area of the filter as there is no > further list item > instead of realizing the filter possibility itself. > > Maybe I'm the only one but: as the (package) list background is white and > the filter > background is white too this is hardly to distinguish. Also the > placeholder "Filter" > is centered instead of right aligned ... > > So depending on windows size it is displayed in a wider distance to the > list item text > and one does not notice that the white area is a filter. > > I guess a small thin line to separate the filter widget from the list > part of the widget would solve the issue. Would that be possible? If so is > this only > an issue of Iceberg or the Pharo theme in general? > > Also I wonder: the "Filter ..." placeholder label is centered in the > middle. If one > clicks into the filter the "Filter..." placeholder surprisingly jumps to > the left. > > I guess we have to catch up more with the usability of our tools. > > Thanks > T. Hi, When I will have time I can take a look at this issue but I don't know when I will be able. > > > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 25, 2017

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

by Stephane Ducasse

Hi all so what is the situation? Is the latest version crashing? Stef On Wed, Nov 22, 2017 at 1:18 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2017-11-22 13:03 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >> >> Well that make sense. The problem is that the stable VM is crashing with a >> segmentation fault :( on Linux/64 bits. > > > I can confirm. > > Given that later vms do not segfault, Eliot told me he prefers to consider > the bug(*) solved. > > Thierry > > (*) But I have no idea about what the bug is. Running the stable pharo vm > under valgrind also triggers the segfault, valgrind complains a lot and > signal permamently lost memory, but this is the same with all vms as far as > valgrind is concerned (i.e. non-crashing and even non-pharo vms are no > better, except that they don't crash). > >> >> >> On Nov 22, 2017 08:46, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >>> >>> >>> >>> On 21 Nov 2017, at 21:00, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>> >>> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget >>> -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes with >>> a segmentation fault also. >>> >>> >>> by concept, there is no âlatest 6.1 vmâ since latest is âunstableâ >>> (alpha) and 6.1 is not (or it shouldnât). >>> >>> latest is always related to the development version. >>> >>> Esteban >>> >>> >>> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Hi Gabriel, >>>> >>>> I had such segfaults with the stable 6.1/64bits on Linux. I solved them >>>> by ensuring the use of a more recent version than the stable one. >>>> >>>> Thierry >>>> >>>> >>>> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >>>>> >>>>> I've created the following issue: >>>>> >>>>> >>>>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-c… >>>>> I can reproduce it easily so if you need some more info let me know. >>>>> >>>>> Regards, >>>>> Gabriel >>>> >>>> >>> >>> >

Nov. 25, 2017

Re: [Pharo-dev] Pharo Filter usability due to same background as List (Iceberg)

by Stephane Ducasse

Agreed! On Tue, Nov 21, 2017 at 9:38 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I do not know if this is only an issue of Iceberg or of the themes in general: > > Due to the topic of todays techtalk I added "DiscordSt" repository to > Iceberg leading to the attached screenshot. > > I wondered why there are only 7 packages while I was pretty sure that there > were more packages in the GitHub page of the repo. > > So it LOOKED LIKE THE LIST ENDED/ONLY HAS A FEW ITEMS because the filter is > displayed right at the bottom of the list. > > You can call me stupid - but I initially thought of an Iceberg synch > synch issue were some packages were not downloaded/cloned - but then after several seconds > I realized that the list just ends because of the filter area and there are more > items - one just has to scroll. > > This is OK but I interpreted the white area of the filter as there is no further list item > instead of realizing the filter possibility itself. > > Maybe I'm the only one but: as the (package) list background is white and the filter > background is white too this is hardly to distinguish. Also the placeholder "Filter" > is centered instead of right aligned ... > > So depending on windows size it is displayed in a wider distance to the list item text > and one does not notice that the white area is a filter. > > I guess a small thin line to separate the filter widget from the list > part of the widget would solve the issue. Would that be possible? If so is this only > an issue of Iceberg or the Pharo theme in general? > > Also I wonder: the "Filter ..." placeholder label is centered in the middle. If one > clicks into the filter the "Filter..." placeholder surprisingly jumps to the left. > > I guess we have to catch up more with the usability of our tools. > > Thanks > T. > > >

Nov. 25, 2017

[Pharo 7.0-dev] Build #330: 20061-Explicit-isAbstract-is-needed-instead-of-using-hasAbstractMethods-in-tools2

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

There is a new Pharo build available! The status of the build #330 was: SUCCESS. The Pull Request #541 was integrated: "20061-Explicit-isAbstract-is-needed-instead-of-using-hasAbstractMethods-in-tools2" Pull request url: https://github.com/pharo-project/pharo/pull/541 Issue Url: https://pharo.fogbugz.com/f/cases/20061 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 25, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by Stephane Ducasse

Hi clement I was confused. I did not understand the problem. Not enough concentration right now. Stef On Fri, Nov 24, 2017 at 10:44 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > In the VM primitiveSlotAt: / at:Put: mean access to any field (pointer or > non pointer, sorry for the confusion Marcus earlier on) of an object. The > primitive in the image can be named fieldAt:/fieldAt:put: if it makes more > sense for Pharo. > > #[0] slotAt: 1 => 0 > #(#a) slotAt: 1 => #a > 0@2 slotAt: 1 => 0 > With Pharo 6 blocks: > | t | t := #tmp. {[ t ] slotAt: 3 . [ t ] slotAt: 4} => { 0 "numArgs". #tmp > } > > Right now you can do that with instVarAt: on the contrary to what instVarAt: > comment states, and this is wrong. > > On Fri, Nov 24, 2017 at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> >> On 24 Nov 2017, at 00:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> >>> Did you talk with marcus? >> >> >> I don't understand the connection between slots and this problem with >> primitives. >>> >>> >> >> There is no connection, just the same name. >> >> For Slots aka First Class Instance variables: >> >> I sometimes think that Slot for the first class instance variables might >> not be a good name, but then, >> the only alternative would be âinstance variableâ, but that is not that >> nice either, as these Slots include >> virtual variables (that are computed) or variables that are combine stored >> in a hidden base slot (e.g. >> used for BooleanSlot or PropertySlot). >> >> So for now I will keep the Slot termâ¦ >> >> >> Marcus > > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 25, 2017