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

Re: [Pharo-dev] WhatsUp from: 2013-11-18 until: 2013-11-30

by Damien Cassou

On Mon, Nov 18, 2013 at 7:05 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > - Translate the Moose book into Pillar how is it going? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 25, 2013

Re: [Pharo-dev] WhatsUp from: 2013-11-18 until: 2013-11-30

by Damien Cassou

### Here's what I've been up to since the last WhatsUp: - wrote a few readme for some Pharo repositories - add a project to the bachelor projects to http://topics.pharo.org/ - update on pharo topics PharoLauncher: - release a drag&drop dmg for Pharo on MacOSX - bug fixes + some cleaning Pharo - make sure the PharoVXX.sources is searched in reasonable locations (e.g., not /Applications/PharoVXX.sources) - backport a bug fix to Pharo 2.0 Book - start writing a Conventions chapter for deep into pharo ### What's next, until 2013-11-30 (*): - (already done) huge pass on Pillar with Ben. Now the book is generated using Pillar and there is a Markdown exporter (with computed section heading and figure numbers). There are also much more unit tests. https://ci.inria.fr/pharo-contribution/job/Pillar/ https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ - (already done) fixing pier and magritte jobs - (already done) launcher can now refresh just 1 template group - (already done) launcher now has a template group for some static urls (latest Pharo 2.0, latest Pharo 3.0, latest moose) - create a windows installer for the launcher -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 25, 2013

Re: [Pharo-dev] Minor corrections to class comment of Number class

by Damien Cassou

On Mon, Nov 18, 2013 at 6:47 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > in #smalltalkhub few minutes ago could you please report bugs on fogbugz? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 25, 2013

Re: [Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0

by ClÃ©ment Bera

Hello, In this version I added #timesRepeat: as a special selector to be inlined by the compiler (as #to:do:, #ifTrue:, ...). There was already another side effect of this addition of timesRepeat: as a special selector for XStreams. I guess we should remove it. Try to edit the default Opal options in: OpalCompiler>>#defaultOptions instead of: + optionInlineTimesRepeat put: - optionInlineTimesRepeat Then execute: OpalCompiler recompileAll. (If you run your code with a DoIt you do not need to recompileAll, but just in case ...) And see if you bug comes from the timesRepeat:. Now the bytecode for "3 timesRepeat: [ Smalltalk garbageCollect ]" is correct. But there may be some side effect in the VM I am not thinking of. 29 <20> pushConstant: 3 30 <68> popIntoTemp: 0 31 <10> pushTemp: 0 32 <76> pushConstant: 1 33 <69> popIntoTemp: 1 34 <11> pushTemp: 1 35 <10> pushTemp: 0 36 <B4> send: <= 37 <AC 09> jumpFalse: 48 39 <41> pushLit: Smalltalk 40 <D2> send: garbageCollect 41 <87> pop 42 <11> pushTemp: 1 43 <76> pushConstant: 1 44 <B0> send: + 45 <69> popIntoTemp: 1 46 <A3 F2> jumpTo: 34 48 <7C> returnTop 2013/11/25 Max Leske <maxleske(a)gmail.com> > I was able to isolate the image where the SegFault problem appears first: > 30435. Hereâs the update method: > > update30435 > "self new update30435" > self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization > enabled > https://pharo.fogbugz.com/f/cases/11729 > 11720 DateModel: Add #displayBlock: > https://pharo.fogbugz.com/f/cases/11720 > 11727 remove unused ivar scrollBarOnLeft in ScrollPane > https://pharo.fogbugz.com/f/cases/11727'. > self loadTogether: self script114 merge: false. > (SystemNavigation new allCallsOn: #timesRepeat:) do: [ :each | each method > recompile ]. > self flushCaches. > > > What I noticed is that 11729 is about #timesRepeat: and the code I used to > trigger the SegFaults is â3 timesRepeat: [ Smalltalk garbageCollect ]â. So > the problem might actually lie in #timesRepeat: rather than in > #garbageCollect: > > @Marcus > Iâve put you into CC because I hope that you know more about #timesRepeat: > > Cheers, > Max > > > > On 25.11.2013, at 08:26, Max Leske <maxleske(a)gmail.com> wrote: > > Interesting development: no SegFaults (while using exactly the same code) > when using an older Pharo image (version 30321 instead of latest). > This obviously suggests that the problem lies with the image and not > necessarily the vm. > > Max > > On 10.11.2013, at 20:10, Max Leske <maxleske(a)gmail.com> wrote: > > > On 07.11.2013, at 08:20, Max Leske <maxleske(a)gmail.com> wrote: > > On 07.11.2013, at 00:27, vm-dev-request(a)lists.squeakfoundation.org wrote: > > Date: Wed, 6 Nov 2013 19:23:47 -0200 > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 > To: Squeak Virtual Machine Development Discussion > <vm-dev(a)lists.squeakfoundation.org> > Message-ID: > <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ(a)mail.gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Max, did you try with Eliot VMs besides the pharo ones? > > > No, I havenât. I can try (though only on my machine), but if I canât > reproduce the SegFault that doesnât mean much unfortunately. It took me 10 > to 20 tries with the PharoVM tooâ¦ > > Iâll try anyway and let you know what I find. > > Max > > > I just gave CogVM and NBCog a shot. Unfortunately I canât use the images > because theyâve been built with PharoVM and hang after load. At least on > the Pharo CI there are no jobs that create Cog / NBCog images. > > So no luck with different VMs. > > Max > > > > Thanks > > > On Wed, Nov 6, 2013 at 6:04 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > Hi > > Weâve been encountering frequent SegFaults when running the Fuel tests on > the Pharo CI (https://ci.inria.fr/pharo-contribution/job/Fuel/) Since > today Iâve also been able to reproduce the SegFaults on my MacBook Pro (OS > X 10.9) too. We have not been able to determine the cause of the SegFault > but we can produce SegFaults often, although not reliable (more reliable on > the CI). > > The CI uses the stable VM: > http://files.pharo.org/vm/pharo/linux/stable.zip > I use a newer version from October on my machine: > http://files.pharo.org/vm/pharo/mac/273.zip > > Iâve attached all the dumps of the crashes I was able to produce on my > machine, together with Appleâs crash logs. > > Iâve been able to deduce the following: > - garbage collection seems to be a trigger for the SegFault. When one of > the methods FLMethodContextSerialization>>testFuelShouldIgnoreFuel and > FLMethodContextSerialization>>testMethodContextWithNilPc contain the line > â3 timesRepeat: [Smalltalk garbageCollect]â the SegFault appears nearly > always (on CI). When I remove the line the builds run through. > - Not all methods with the garbage collect line trigger a SegFault (I > could only identify those two) > - the garbage collect line itself suffices as a trigger in the mentioned > methods. > - The number of tests (amount of used memory?) seems to influence the > appearence of the SegFault (e.g. loading "DevelopmentGroup" seems to > trigger it more often than loading âBenchmarksâ) > - the SegFault always appears after the tests with the garbage collect > line have been run, never before > - the VM canât write the crash.dmp every time > > Since the SegFaults are so random I cannot give you an image to reproduce > the problem. Iâve had the best results using a fresh 3.0 image ( > http://files.pharo.org/image/30/30549.zip) and then evaluating the > following in a workspace: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Fuel'; > package: 'ConfigurationOfFuel'; > load. > > ((Smalltalk at: #ConfigurationOfFuel) project version: #bleedingEdge) > load: 'DevelopmentGroup'. > > HDTestReport > runClasses: (TestCase allSubclasses select: [ :class | class name > beginsWith: 'FL']) > named: âfoo' > > If it doesnât work, try using the TestRunner manually. Select the default > Fuel tests (alphabetically at F) and the additional Fuel tests (at the > bottom of the list) and run them. > > If anybody has any clue about what could be going on Iâd really appreciate > any input. Iâll happily provide more information if I can. > > Thanks for reading :) > Max > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > >

Nov. 25, 2013

Re: [Pharo-dev] Committed to wrong repo in sthub , any way to delete my commit ?

by Damien Cassou

On Sun, Nov 17, 2013 at 5:28 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Hi , I was working on my project Hyperion and I made a mistake. I committed > my latest commit to PharoLauncher repo instead of my Hyperion repo in > smalltalkhub. Is there a way to delete the commit so that my Hyperion > package does not appear inside the PharoLauncher repo ? just browse the package on smalltalkhub using the 'Source' tab. Then, you will see a 'delete mcz' button. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 25, 2013

show stpper

by Camillo Bruni

we have now 5 cases defined as show stopper... https://pharo.fogbugz.com/f/filters/62/All-priority if that were really the case the image would no longer run ;)

Nov. 25, 2013

Re: [Pharo-dev] [Issue Tracker] 5 Bugs reported against Pharo2

by Camillo Bruni

On 2013-11-25, at 11:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 7559 Plugins Primitives no longer work after a while > https://pharo.fogbugz.com/f/cases/7559 7559 was solved in 3.0 by a DateAndTime fix which I do not want to backport (too easy to break something).

Nov. 25, 2013

Re: [Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0

by Max Leske

I was able to isolate the image where the SegFault problem appears first: 30435. Hereâs the update method: update30435 "self new update30435" self withUpdateLog: '11729 Sync Opa from repo: #timesRepeat optimization enabled https://pharo.fogbugz.com/f/cases/11729 11720 DateModel: Add #displayBlock: https://pharo.fogbugz.com/f/cases/11720 11727 remove unused ivar scrollBarOnLeft in ScrollPane https://pharo.fogbugz.com/f/cases/11727'. self loadTogether: self script114 merge: false. (SystemNavigation new allCallsOn: #timesRepeat:) do: [ :each | each method recompile ]. self flushCaches. What I noticed is that 11729 is about #timesRepeat: and the code I used to trigger the SegFaults is â3 timesRepeat: [ Smalltalk garbageCollect ]â. So the problem might actually lie in #timesRepeat: rather than in #garbageCollect: @Marcus Iâve put you into CC because I hope that you know more about #timesRepeat: Cheers, Max On 25.11.2013, at 08:26, Max Leske <maxleske(a)gmail.com> wrote: > Interesting development: no SegFaults (while using exactly the same code) when using an older Pharo image (version 30321 instead of latest). > This obviously suggests that the problem lies with the image and not necessarily the vm. > > Max > > On 10.11.2013, at 20:10, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 07.11.2013, at 08:20, Max Leske <maxleske(a)gmail.com> wrote: >> >>> On 07.11.2013, at 00:27, vm-dev-request(a)lists.squeakfoundation.org wrote: >>> >>>> Date: Wed, 6 Nov 2013 19:23:47 -0200 >>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> Subject: Re: [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0 >>>> To: Squeak Virtual Machine Development Discussion >>>> <vm-dev(a)lists.squeakfoundation.org> >>>> Message-ID: >>>> <CAA+-=mWDtHGQWSHx-m4u37Kj0UAMx=UG=qUCz+wMvgDT8BaQZQ(a)mail.gmail.com> >>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>> Max, did you try with Eliot VMs besides the pharo ones? >>> >>> No, I havenât. I can try (though only on my machine), but if I canât reproduce the SegFault that doesnât mean much unfortunately. It took me 10 to 20 tries with the PharoVM tooâ¦ >>> >>> Iâll try anyway and let you know what I find. >>> >>> Max >> >> I just gave CogVM and NBCog a shot. Unfortunately I canât use the images because theyâve been built with PharoVM and hang after load. At least on the Pharo CI there are no jobs that create Cog / NBCog images. >> >> So no luck with different VMs. >> >> Max >> >>> >>>> >>>> Thanks >>>> >>>> >>>> On Wed, Nov 6, 2013 at 6:04 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> >>>>> Hi >>>>> >>>>> Weâve been encountering frequent SegFaults when running the Fuel tests on >>>>> the Pharo CI (https://ci.inria.fr/pharo-contribution/job/Fuel/) Since >>>>> today Iâve also been able to reproduce the SegFaults on my MacBook Pro (OS >>>>> X 10.9) too. We have not been able to determine the cause of the SegFault >>>>> but we can produce SegFaults often, although not reliable (more reliable on >>>>> the CI). >>>>> >>>>> The CI uses the stable VM: >>>>> http://files.pharo.org/vm/pharo/linux/stable.zip >>>>> I use a newer version from October on my machine: >>>>> http://files.pharo.org/vm/pharo/mac/273.zip >>>>> >>>>> Iâve attached all the dumps of the crashes I was able to produce on my >>>>> machine, together with Appleâs crash logs. >>>>> >>>>> Iâve been able to deduce the following: >>>>> - garbage collection seems to be a trigger for the SegFault. When one of >>>>> the methods FLMethodContextSerialization>>testFuelShouldIgnoreFuel and >>>>> FLMethodContextSerialization>>testMethodContextWithNilPc contain the line >>>>> â3 timesRepeat: [Smalltalk garbageCollect]â the SegFault appears nearly >>>>> always (on CI). When I remove the line the builds run through. >>>>> - Not all methods with the garbage collect line trigger a SegFault (I >>>>> could only identify those two) >>>>> - the garbage collect line itself suffices as a trigger in the mentioned >>>>> methods. >>>>> - The number of tests (amount of used memory?) seems to influence the >>>>> appearence of the SegFault (e.g. loading "DevelopmentGroup" seems to >>>>> trigger it more often than loading âBenchmarksâ) >>>>> - the SegFault always appears after the tests with the garbage collect >>>>> line have been run, never before >>>>> - the VM canât write the crash.dmp every time >>>>> >>>>> Since the SegFaults are so random I cannot give you an image to reproduce >>>>> the problem. Iâve had the best results using a fresh 3.0 image ( >>>>> http://files.pharo.org/image/30/30549.zip) and then evaluating the >>>>> following in a workspace: >>>>> >>>>> Gofer it >>>>> smalltalkhubUser: 'Pharo' project: 'Fuel'; >>>>> package: 'ConfigurationOfFuel'; >>>>> load. >>>>> >>>>> ((Smalltalk at: #ConfigurationOfFuel) project version: #bleedingEdge) >>>>> load: 'DevelopmentGroup'. >>>>> >>>>> HDTestReport >>>>> runClasses: (TestCase allSubclasses select: [ :class | class name >>>>> beginsWith: 'FL']) >>>>> named: âfoo' >>>>> >>>>> If it doesnât work, try using the TestRunner manually. Select the default >>>>> Fuel tests (alphabetically at F) and the additional Fuel tests (at the >>>>> bottom of the list) and run them. >>>>> >>>>> If anybody has any clue about what could be going on Iâd really appreciate >>>>> any input. Iâll happily provide more information if I can. >>>>> >>>>> Thanks for reading :) >>>>> Max >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >

Nov. 25, 2013

[Issue Tracker] 5 Bugs reported against Pharo2

by Marcus Denker

Hi, We have 5 open issues reported against Pharo2: Not fixed and no fix available in 2, fixed in 3: ââââ 11683 Renaming a package in Nautilus w/ a shorter name: Primitive Failed due to negative size passed https://pharo.fogbugz.com/f/cases/1168 7559 Plugins Primitives no longer work after a while https://pharo.fogbugz.com/f/cases/7559 12080 Generate Initialize Method breaks the image https://pharo.fogbugz.com/f/cases/12080 all but 7559 seems to be minor, 7559 itself is strange. I have not found a way to reproduce it yet. Backport Pharo3, needs review: ââââ 12097 [Backport] Pharo can't find sources files when embedded in an .app application https://pharo.fogbugz.com/f/cases/12097 Possibly a problem both in 2 and 3, fix proposed: âââ 11674 MNU: receiver of ">" is nil https://pharo.fogbugz.com/f/cases/11674

Nov. 25, 2013

Re: [Pharo-dev] EyeInspector looks broken

by Camillo Bruni

On 2013-11-24, at 20:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Smalltalk tools openBrowser > produces an emergency evaluator. > => annoying. => open a bug entry

Nov. 25, 2013