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

Re: [Pharo-dev] VM with fragmented memory

by Alexandre Bergel

Hi Eliot, I have a question still on segmented memory. Consider an object âc := OrderedCollection newâ. It is likely that the internal "arrayâ and the object c will be in the same generation and in the same memory segment. If I add, letâs say, 30 000 000 elements into c. After the addition the array will be very very big. Which means that it may be in a different segment memory than the one that contains âcâ. Do you feel this may be a problem? I am thinking about a long jump between c and array. Long jumps cost more than short jumps right? Do you feel there are some suboptimal situation with this situation? Alexandre NB: I cc the mailing list to see whether other may help in understand better whatâs going on with segment and generations -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 19, 2013, at 1:37 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > > On Mon, Nov 18, 2013 at 7:40 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Eliot, > > Stef told me you are working hard on improving the Pharo VM. > In particular making the VM support fragmented memory. If I understand correctly, this will relieve the VM from having a continuous block of memory to hold the whole image. Really cool! > > A better term is segmented memory. fragmentation in memory management means free space getting divided into too small pieces to be useful. > > I have a general question regarding VM. Are you aware of other Virtual machines supporting this? Does the Java VM support fragmented memory? .Net? V8? > > Any VM that uses the train algorithm supports segmented memory. Any VM that uses "pools" or "regions" uses segmented memory. VisualWorks' VM supports segments. I'm pretty sure that V8 .Net & HotSpot provide segmented memory. > > > I would like to mention this in a research paper I am working on. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- > best, > Eliot

Nov. 25, 2013

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

by Marcus Denker

On 25 Nov 2013, at 16:26, Max Leske <maxleske(a)gmail.com> wrote: > Thanks ClÃ©ment, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦). > > Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦ You can not compile without optimisations. There are places in the image that would not work with e.g. whileTrue: optimisation disabled as it would e.g. add an interrupt point where none is now And other things, like performance, or e.g. the loop that goes over all objects, if that creates objects while running you have a problemâ¦ Marcus

Nov. 25, 2013

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

by StÃ©phane Ducasse

thanks clement. Max this is a nice catch. Stef On Nov 25, 2013, at 1:13 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0

by Max Leske

Thanks ClÃ©ment, that seems to be it. Disabling the timesRepeat inlining makes most of the builds run through but not all of them. It seems like thereâs another (Opal related?) problem (with the exact same symptomsâ¦). Iâve tried disabling all options, just to see what happens: all builds fail with SegFaultsâ¦ Iâll keep playing around, maybe Iâll find a configuration that works. Cheers, Max On 25.11.2013, at 13:13, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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] Old ClassBuilder remove!

by Martin Dias

With the object's format reified in Layouts, we could rewrite a method like this by a double-dispatch: Object >> fuelAccept: aGeneralMapper "Be careful because the order is important. For example, weak are also variable, but we need that weak objects send #visitWeakObject: and not #visitVariableObject: " self class isFixed ifTrue: [ ^ aGeneralMapper visitFixedObject: self ]. self class isWeak ifTrue: [ ^ aGeneralMapper visitWeakObject: self ]. self class isPointers ifTrue: [ ^ aGeneralMapper visitVariableObject: self ]. self class isBytes ifTrue: [ ^ aGeneralMapper visitBytesObject: self ]. self class isWords ifTrue: [ ^ aGeneralMapper visitWordsObject: self ]. self error: 'Something is wrong!' MartÃn On Mon, Nov 25, 2013 at 4:04 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Mmm... if slots support annotations, maybe the user can tag an instance > variable with a "ignore" tag. > > At this moment, the user can override #fuelIgnoredInstanceVariableNames to > do that, answering a list of variable names. > > MartÃn > > > On Sat, Nov 23, 2013 at 5:46 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> > How does this affect serialization / materialization engines like Fuel? >> >> Not now >> We will have to work to make the compiler smarter and define special Slot >> class. >> >> >> >> On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> >> >> any links why newcomers like me should be impressed ? Whats the >> advantages ? >> >> >> >> >> >> That's just cleaning. The old class builder was an incredibly complex >> piece >> >> of code that is now replaced with the Slot class builder. >> >> The later is based on slots and is much more understandable and thus >> much >> >> easier to maintain. >> >> It's been integrated some time ago thanks to Martin. >> >> >> >> Slots are the work of Toon and Camillo and enables a lot of useful >> features: >> >> >> http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… >> >> They are based on the reification of class layouts >> (variable,weak,fixed and >> >> co) and instance variables (slots). >> >> Slots are an abstraction added on top of low-level class "fields". >> >> It means that one will be able to create a customized slot class that >> define >> >> the logic to read and write a slot: >> >> >> >> Object subclass: #MyClass >> >> slots: { x => MyFancySlot } >> >> category: 'Playground' >> >> >> >> Then when a method read or writes x, the logic you defined in >> MyFancySlot is >> >> executed. >> >> All that still need to be absorbed by Opal so it's not available right >> now >> >> but it will (Pharo 4)! >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> >> >>> Triple impressive! This is another sample of an apparently tiny change >> >>> that actually has deep impact on the future of our beloved >> environment. >> >>> >> >>> Ladies and gentlemen, I know you are busy, but please take the time to >> >>> acknowledge it :) >> >>> >> >>> Doru >> >>> >> >>> >> >>> >> >>> >> >>> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> >> >>> wrote: >> >>>> >> >>>> wow, impressive! >> >>>> >> >>>> >> >>>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker < >> marcus.denker(a)inria.fr> >> >>>> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> Yesterday Camille did the change to finally remove the old class >> >>>>> builder! >> >>>>> (just a removal + a small change to NativeBoost to use the new class >> >>>>> builder to create anonymous classes). >> >>>>> >> >>>>> This means >> >>>>> - 1000 Loc of completely un-understandable code removed. >> >>>>> - we now 100% run on the new class builder from the Slot >> >>>>> Project. >> >>>>> >> >>>>> Next on the list (not all for Pharo3): >> >>>>> >> >>>>> - remove PackageInfo >> >>>>> - old Browser + CodeHolder hierarchy >> >>>>> - PseudoClass&Co â> Ring >> >>>>> - old AST+Compiler (this in Pharo4) >> >>>>> >> >>>>> We already did (all in Pharo3): >> >>>>> -> remove URI >> >>>>> -> deprecated Url for ZnUrl >> >>>>> -> removed HTTPSocket facade >> >>>>> -> MIMEType retired for ZnMimeType >> >>>>> -> old Debugger is removed >> >>>>> -> Class categories are replaced by Protocols >> >>>>> >> >>>>> I am quite sure that these cleanups will enable us to build a lot of >> >>>>> very interesting things >> >>>>> in the future. >> >>>>> >> >>>>> Marcus >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "Every thing has its own flow" >> >> >> >> >> >> >> > >> >> >> >

Nov. 25, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Martin Dias

Mmm... if slots support annotations, maybe the user can tag an instance variable with a "ignore" tag. At this moment, the user can override #fuelIgnoredInstanceVariableNames to do that, answering a list of variable names. MartÃn On Sat, Nov 23, 2013 at 5:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > How does this affect serialization / materialization engines like Fuel? > > Not now > We will have to work to make the compiler smarter and define special Slot > class. > > > >> On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: > >> > >> any links why newcomers like me should be impressed ? Whats the > advantages ? > >> > >> > >> That's just cleaning. The old class builder was an incredibly complex > piece > >> of code that is now replaced with the Slot class builder. > >> The later is based on slots and is much more understandable and thus > much > >> easier to maintain. > >> It's been integrated some time ago thanks to Martin. > >> > >> Slots are the work of Toon and Camillo and enables a lot of useful > features: > >> > http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… > >> They are based on the reification of class layouts (variable,weak,fixed > and > >> co) and instance variables (slots). > >> Slots are an abstraction added on top of low-level class "fields". > >> It means that one will be able to create a customized slot class that > define > >> the logic to read and write a slot: > >> > >> Object subclass: #MyClass > >> slots: { x => MyFancySlot } > >> category: 'Playground' > >> > >> Then when a method read or writes x, the logic you defined in > MyFancySlot is > >> executed. > >> All that still need to be absorbed by Opal so it's not available right > now > >> but it will (Pharo 4)! > >> > >> > >> > >> > >> > >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> > >>> Triple impressive! This is another sample of an apparently tiny change > >>> that actually has deep impact on the future of our beloved environment. > >>> > >>> Ladies and gentlemen, I know you are busy, but please take the time to > >>> acknowledge it :) > >>> > >>> Doru > >>> > >>> > >>> > >>> > >>> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> > >>> wrote: > >>>> > >>>> wow, impressive! > >>>> > >>>> > >>>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker < > marcus.denker(a)inria.fr> > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Yesterday Camille did the change to finally remove the old class > >>>>> builder! > >>>>> (just a removal + a small change to NativeBoost to use the new class > >>>>> builder to create anonymous classes). > >>>>> > >>>>> This means > >>>>> - 1000 Loc of completely un-understandable code removed. > >>>>> - we now 100% run on the new class builder from the Slot > >>>>> Project. > >>>>> > >>>>> Next on the list (not all for Pharo3): > >>>>> > >>>>> - remove PackageInfo > >>>>> - old Browser + CodeHolder hierarchy > >>>>> - PseudoClass&Co â> Ring > >>>>> - old AST+Compiler (this in Pharo4) > >>>>> > >>>>> We already did (all in Pharo3): > >>>>> -> remove URI > >>>>> -> deprecated Url for ZnUrl > >>>>> -> removed HTTPSocket facade > >>>>> -> MIMEType retired for ZnMimeType > >>>>> -> old Debugger is removed > >>>>> -> Class categories are replaced by Protocols > >>>>> > >>>>> I am quite sure that these cleanups will enable us to build a lot of > >>>>> very interesting things > >>>>> in the future. > >>>>> > >>>>> Marcus > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >> > >> > >> > > > > >

Nov. 25, 2013

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

by kilon alios

I dont think you have read my full message :) I have already reported it on fogbuz and provided a slice with the fix. On Mon, Nov 25, 2013 at 2:14 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 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] WhatsUp from: 2013-11-18 until: 2013-11-30

by kilon alios

Started an editor for Athens, Hyperion - Currently I have implemented edit mode for straight lines hopefully more to come :) On Mon, Nov 25, 2013 at 2:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Not yet started. It's planned for sometime this week (hopefully). > > Doru > > > On Mon, Nov 25, 2013 at 1:25 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > >> 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 >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 25, 2013

MCRepository can notify by email, did you know?

by Martin Dias

Hi, I just discovered this feature and wanted to share it: When a version is saved, the file repositories check if a file named 'notify' exists in the repository directory [1]. If it exists, then it reads email addresses from that file and send emails notifying the new version [2]. We noticed with Camillo that this seems to be the only usage of SMTPClient in the image. I wonder if somebody is using this feature. Best regards, MartÃn ps: I'm talking of Pharo 3. [1] MCFileBasedRepository>>notifyList [2] MCVersionNotification>>notify:

Nov. 25, 2013

[pharo-project/pharo-core] 2055d8: 30595

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 2055d83044b0b6c73889f8d1991b61691a000a1d https://github.com/pharo-project/pharo-core/commit/2055d83044b0b6c73889f8d1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-25 (Mon, 25 Nov 2013) Changed paths: A KernelTests.package/BehaviorTest.class/instance/tests/testCanUnderstand.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script250.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30595.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30595 11302 canUnderstand: must handle shouldNotImplement https://pharo.fogbugz.com/f/cases/11302 http://files.pharo.org/image/30/30595.zip

Nov. 25, 2013