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

issue tracker progress

by Camillo Bruni

We are currently moving quite fast: https://pharo.fogbugz.com/default.asp?pgx=FS&P19_sChartSubType=stacked& March: 6.9 issues/day April: 7.6 issues/day Mai: 12.5 issues/day The most active projects last month was Opal: https://pharo.fogbugz.com/default.asp?pgx=FS&sView=bar

May 25, 2013

Re: [Pharo-dev] Kernel Discussion

by Pavel Krivanek

On Sat, May 25, 2013 at 12:55 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > I've seen a lot of progress for the Pharo Kernel by Pavel recently and I > really appreciate his work. But I have some questions I think we should > discuss. > > There have been quite a few changes to make code work in the Kernel and to > reduce dependencies between packages. But I really have the impression that > many of these changes are of bad quality :/. > > I do not want to offend people, but this is fairly important if we want to > have a nice code base. > > Example: > ======== > UnixResolver >> nbGetEnv: str > #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. > ^ nil > > The goal of this code is to conditionally do something in the main image > but > continue to work in the kernel. > > Observations: > ============= > - #asClassIfPresent: and Co are bad > - Why do we clutter the main image if the kernel should change? > - Can't we solve these things by having proper other objects? > - Is the UnixResolver really needed in the Kernel? > > I worked with Esteban last week on a similar case in the > CommandLineHandler and we ended up introducing a minimal superclass. I > guess this goes much in the direction of having proper NullObjects. > > I really think we should not add these little nasty changes, but rather > introduce proper > new classes that can be unloaded if needed. > > What do you think? > Hi Cami, firstly I have to say that most of all patches I do to make Pharo Kernel jobs working are really ugly hacks of poor quality :-) Of course I'm firstly trying to make it work somehow. I do not like solutions like asClassIfPresent: too and I do not use them if I have better simple option. And if I use them, I know that I only move the problem because in most cases it crates new unimplemented calls. But that ugly hacks are only one part of the problem and maybe the minor one. The major one is that we integrate code that requires such ugly hacks :-) Nativeboost, UserManager and others are not old additions and they decrease modularity of the system. So when I find time to work on Pharo Kernel, in most cases I do not clean old problems but I need to solve the new ones. It is not the fault of authors of this additions but of our integration system. Classical eggs and chickens problem, we cannot base our integration process on Pharo Kernel processes because it is not ready and it is not ready because we do not have the integration system based on in. So I'm very glad that Esteban started to work hard on it and if we will do sometimes an ugly hack like this, we know that we do not really solve the problem but we move it to the later time. However it is more important for us to solve it soon. With more hands and attention we will be able to do it in a nicer way ;-) Cheers, -- Pavel

May 25, 2013

MongoQueries regex

by Camillo Bruni

Is it correct that there is no abstraction yet to do regex searches with MongoQueries? Something like ShUser select: [ :each| (each username regex: aString) | (each fullName regex: aString) ] is not yet done?

May 25, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 27 regressions found. OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testAssignmentOfSelf OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testDigitTooLargeForARadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExpectedExpressionInBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExtraneousStatementAfterAReturnInABlock OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidLiteralCharacter OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidRadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterABinaryMessage OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterAMessageKey OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingBlockArgumentName OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpression OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpressionAfterAReturn OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingMessageAfterACascade OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingPeriodSeparatorBetweenStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingSeparatorBetweenBlockArgumentAndStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooLargeAnIntegerInALiteralByteArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooManyArguments OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBlockBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedByteArrayBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedCommentQuote ...

May 25, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 27 regressions found. OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testAssignmentOfSelf OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testDigitTooLargeForARadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExpectedExpressionInBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExtraneousStatementAfterAReturnInABlock OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidLiteralCharacter OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidRadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterABinaryMessage OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterAMessageKey OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingBlockArgumentName OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpression OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpressionAfterAReturn OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingMessageAfterACascade OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingPeriodSeparatorBetweenStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingSeparatorBetweenBlockArgumentAndStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooLargeAnIntegerInALiteralByteArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooManyArguments OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBlockBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedByteArrayBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedCommentQuote ...

May 25, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 27 regressions found. OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testAssignmentOfSelf OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testDigitTooLargeForARadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExpectedExpressionInBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testExtraneousStatementAfterAReturnInABlock OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidLiteralCharacter OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testInvalidRadix OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterABinaryMessage OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingArgumentAfterAMessageKey OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingBlockArgumentName OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpression OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingExpressionAfterAReturn OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingMessageAfterACascade OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingPeriodSeparatorBetweenStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testMissingSeparatorBetweenBlockArgumentAndStatements OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooLargeAnIntegerInALiteralByteArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testTooManyArguments OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBlockBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedBraceArray OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedByteArrayBracket OpalCompiler.Tests.FromOld.OCCompilerSyntaxErrorNotifyingTest.testUnmatchedCommentQuote ...

May 25, 2013

Re: [Pharo-dev] are there benchmarks like deltablue and richards for Pharo?

by Stefan Marr

Hi: On 25 May 2013, at 13:05, Camillo Bruni <camillobruni(a)gmail.com> wrote: > A couple of them are in Smark > > http://smalltalkhub.com/#!/~StefanMarr/SMark SMark includes a pretty complete port of the Language Benchmark Game benchmarks. (http://benchmarksgame.alioth.debian.org/) Other people have been writing the benchmarks, and they are still in the CVS of the benchmark game, I think. The SMark version are slightly adapted but results should remain comparable. That means, taking the benchmark collection, you should be able to compare to all the other languages included in the benchmark game. > On 2013-05-25, at 12:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> I wonder if there are benchmarks around. >> Also I wonder if there would be useful :) DeltaBlue can be found here: ftp://ftp.cs.washington.edu/pub/constraints/code/DeltaBlue/Smalltalk Not sure how much effort it is to get it running in Pharo, but I would assume it is pretty stand-alone. Not sure which Smalltalk it was written for thought. GNU Smalltalk has a version of Richard's benchmarks: https://github.com/gnu-smalltalk/benchmark/blob/master/Richards.st Also looks pretty straight forward to get them running in Pharo. Here is another version: http://www.cs.middlebury.edu/~briggs/Courses/CS313-F10/smalltalk/stx/goodie… >> For "marketing" purposes I think yes: if we can put in the web page that we are running those benchmarks, it is cool for "seriousness" (that, of course, assuming the results will not be terribly bad :P) The Benchmark Game benchmarks would get you quite a bit of the 'marketing'. DeltaBlue and Richards won't hurt, and are also widely ported to other systems. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 25, 2013

[update 3.0] #30168

by Marcus Denker

30168 ----- 10737 Nabujito fails because of Opal https://pharo.fogbugz.com/f/cases/ (updated Opal to last version in image, move #compileContext compatibility method to Compiler will see if this fixes the problem) 10305 FileDialogWindowTest should clean up file after test https://pharo.fogbugz.com/f/cases/10305 5923 FileBrowser/FileList Add new file menu item in directory list does not work https://pharo.fogbugz.com/f/cases/5923 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1132.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.545.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.471.diff

May 25, 2013

Re: [Pharo-dev] [Pharo-fuel] Corrupt BlockClosure

by Max Leske

I can now reprocuce corrupt sessions. The trick is to debug DFSession>>numberOfMethodCalls: 1. start new session 2. debug "DFSession uniqueInstance printString" 3. step into #numberOfMehthodCalls 4. proceed 5. stop the session 5. right click on the new session in the session browser and click "Export session" 6. boom! The reason is of course, that now the compiled method of #numberOfMethodCalls is referenced by the session and will be serialized by Fuel and when Fuel gets to the corrupt BlockClosure, serialization fails. So the real question still is: how did that BlockClosure obtain a wrong start PC? What I find particularly interesting, is that even changing the method does not fix the BlockClosure. I added the line "Transcript show: 'foo'." before the block (so the block should get a new start PC). Then running the procedure detailed above still produced an open debugger. To illustrate that the block did indeed not get fixed I ran "BlockClosure allInstances select: [ :e | e startpc = 59 ]", with 59 being the new startPC ("55 <8F 01 00 03> closureNumCopied: 0 numArgs: 1 bytes 59 to 61"). The result does not include the block. Any ideas? Max On 24.05.2013, at 08:10, roberto.minelli(a)usi.ch wrote: > Hi, > > Thanks all of you for interest ;) > > On May 24, 2013, at 7:15 AM, Max Leske <maxleske(a)gmail.com> > wrote: > >> I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). >> Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. > > Me neither!! > >> >> @Roberto >> Can you tell us anything about what you did befor / during / after running your session? > > Nope. Unfortunately I've a couple of "broken sessions" I cannot serialize because of that bug.. But all of them refers sooner or later to the DFSession>>#numberOfMethodCalls method. Dunno why. > >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? > > I have no clue how to reproduce, but it did not happen only once. As I said, there are 3/4 sessions I couldn't export due to this SubscriptOutOfBounds. > > Cheers, > Roby > > >> >> >> On 24.05.2013, at 06:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: >>>> theBlock instVar: 2 put: 43. >>>> The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. >>> >>> Would it help to recompile the method? >>> >>>> I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? >>> >>> No, there was never a materialization of that session. >>> >>>> >>>> Camille >>>> >>>> On 23 mai 2013, at 21:02, Max Leske wrote: >>>> >>>>> Hi Marcus >>>>> >>>>> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >>>>> >>>>> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >>>>> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >>>>> >>>>> @Roberto >>>>> Is it possible to reproduce the stack with a new session? Or did this only happen once? >>>>> >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>>>>> Date: 23. Mai 2013 14:23:45 MESZ >>>>>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> >>>>>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>>>>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> What's the compiled method? Is it a special one? Which selector in which class? >>>>>> >>>>>> Max >>>>>> >>>>>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>>>>>> >>>>>>> I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>>>>>> >>>>>>> I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>>>>>> >>>>>>> Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Roby >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#1 ########################################### >>>>>>> ########################################################################################### >>>>>>> CompiledMethod(Object)>>errorSubscriptBounds: >>>>>>> CompiledMethod(Object)>>at: >>>>>>> InstructionStream>>interpretNextInstructionFor: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>>>>>> BlockClosure>>on:do: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: >>>>>>> BlockClosure>>blockCreationBytecodeMessage >>>>>>> BlockClosure>>endPC >>>>>>> BlockClosure>>abstractBytecodeMessagesDo: >>>>>>> BlockClosure>>isClean >>>>>>> BlockClosure>>shouldBeSubstitutedByCleanCopy >>>>>>> BlockClosure>>fuelAccept: >>>>>>> FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>>>>>> FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>>>>>> FLLargeIdentityDictionary>>at:ifAbsent: >>>>>>> FLFullGlobalMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLAnalysis>>mapAndTrace: >>>>>>> FLAnalysis>>run >>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>>>>>> FLAnalyzer>>analysisFor: >>>>>>> FLSerialization>>analysisStep >>>>>>> FLSerialization>>run >>>>>>> DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>>>>>> DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>>>>>> FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>>>>>> BlockClosure>>ensure: >>>>>>> FLEncoder class>>on:globalEnvironment:do: >>>>>>> DFSerializer(FLSerializer)>>serialize:on: >>>>>>> >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#2 ########################################### >>>>>>> ############################################################################################ >>>>>>> Decompiler(Object)>>error: >>>>>>> Decompiler>>decompileBlock: >>>>>>> BlockClosure>>decompile >>>>>>> BlockClosure>>printOn: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>>>>>> String class(SequenceableCollection class)>>streamContents:limitedTo: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: >>>>>>> BlockClosure(Object)>>printString >>>>>>> BlockClosure>>DoIt >>>>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>>>>>> BlockClosure>>on:do: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: >>>>>>> SmalltalkEditor>>evaluateSelection >>>>>>> PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>>>>>> PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>>>>>> TextMorphForEditView(TextMorph)>>handleEdit: >>>>>>> PluggableTextMorph>>handleEdit: >>>>>>> PluggableTextMorph>>doIt >>>>>>> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>>>>>> BlockClosure>>cull: >>>>>>> BlockClosure>>cull:cull: >>>>>>> BlockClosure>>cull:cull:cull: >>>>>>> KMCategoryTarget>>completeMatch:buffer: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>>>>>> Array(SequenceableCollection)>>do: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: >>>>>>> KMKeymap>>onMatchWith:notify:andDo: >>>>>>> KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>>>>>> Set>>do: >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-fuel mailing list >>>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>> >>>> >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

May 25, 2013

Re: [Pharo-dev] Memory leaks with Spec?

by stephane ducasse

On May 25, 2013, at 2:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 May 2013 14:01, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> Igor I will use weak (may be weak should be default and we should propose strong as an option) >> but I do not understand since >> >>>> LoggerUI allInstances do: [ :each | >>>> SystemAnnouncer uniqueInstance unsubscribe: each ] >> >> should unregister everything. >> > is it held only by announcer or something else? no nothing else. Stef > >> Stef >> >> >> On May 25, 2013, at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 25 May 2013 13:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi guys >>>> >>>> this is strange I cannot get rid of Spec based ui instances. >>>> I tried many >>>> >>>> LoggerUI allInstances do: [ :each | >>>> SystemAnnouncer uniqueInstance unsubscribe: each ] >>>> >>>> LoggerUI allInstances do: #delete. >>>> >>>> Smalltalk garbageCollect >>>> >>>> Nothing changes. Each time I create and close it does not get garbage collected. >>>> I remove all the announcement registration from my code but nothing changes. >>>> >>> >>> That's why it is preferable to always use weak subscriptions: >>> >>> announcer weak on: Foo send: #bar to: theGuyWhoWillBeHeldWeakly >>> >>> then: >>> 1. you don't have to unsubscribe >>> 2. even if you still have memory leaks, you can exclude announcer from equation >>> >>>> Stef >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 25, 2013