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

Re: [Pharo-project] [Pharo-users] SLOC in Smalltalk

by Janko MivÅ¡ek

HernÃ¡n, It would be nice if you patch the WebCodeStats by yourself. I just set a read-write access to the http://www.squeaksource.com/WebCodeStats.html. Best regards Janko Dne 02. 04. 2013 04:54, piÅ¡e HernÃ¡n Morales Durand: > Hi Janko. Thanks for your useful package. > > Apparently there is some issue with #linesOfCode. The dummy expression > below return 5 instead of 4 in Pharo 1.4 and 2 because is counting the > autogenerated 'DoIt' selector. > > (UndefinedObject evaluatorClass new > compileNoPattern: '| oc | > oc := OrderedCollection new: 20. > oc add: 1. > oc size' > in: UndefinedObject > context: nil > notifying: nil > ifFail: []) generate linesOfCode > > HernÃ¡n > > El 31/03/2013 10:17, Janko MivÅ¡ek escribiÃ³: >> Hi HernÃ¡n >> >> I once did some code statistics for our web frameworks, by counting: >> >> - Nr of packages, categories, classes, methods >> - lines of code >> - Avg methods/class >> - Avg lines/method >> >> - Nr of test methods >> - Avg tests/class >> >> - % of commented methods >> - % of commented classes >> >> Then three graphs were drawn: >> >> - Methods in classes >> - Class inheritance depth >> - Lines in methods >> >> Results can be seen here: >> >> https://docs.google.com/spreadsheet/ccc?key=0Atnb1W9vuq9ndG4wbUpxNXpKQnFZRl… >> >> >> The code measuring all above is here: >> >> http://www.squeaksource.com/WebCodeStats.html >> >> >> Hope this helps >> Janko >> >> >> Dne 31. 03. 2013 09:23, piÅ¡e HernÃ¡n Morales Durand: >>> Hi there, >>> Guys, what are you using to measure logical lines of code (LOC) in >>> Pharo? >>> Given I am measuring a script, is there any other software measure you >>> may recommend? >>> Cheers, >>> >>> HernÃ¡n >>> >> > > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

April 2, 2013

Re: [Pharo-project] [3.0] CI build is broken

by Camillo Bruni

we're back up, shinier than ever ;) check http://get.pharo.org ;) now you can use: wget --quiet -O - get.pharo.org | bash for the current stable release of Pharo and the PharoVM. On 2013-04-01, at 22:52, Tudor Girba <tudor(a)tudorgirba.com> wrote: > No stress. In the worst case you can fix it tomorrow during the tutorial :). > > Doru > > > On Apr 1, 2013, at 10:26 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-04-01, at 22:09, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >> >>> Tudor Girba-2 wrote >>>> Could it have something to do with the latest optimizations of Camillo? >>> >>> Probably... Cami breaks everything :-P >> >> dammit, I wanted to silently add the new zeroconf scripts >> obviously something went horribly wrong there, sorry guys.. working on it! >> > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > >

April 2, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by Yanni Chiu

On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo(a)public.gmane.org wrote: > > Is there any way to "browse" through such references to understand where are they? From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it. It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me. Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object. Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.

April 2, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by roberto.minelli＠usi.ch

Thanks for your answer! On Apr 2, 2013, at 12:03 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > They arise when you delete a class, but you still have references to the class in the image. You could have instances of the deleted class, references to the class in a method, or even subclasses that refer the the deleted class. Is there any way to "browse" through such references to understand where are they?

April 2, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by roberto.minelli＠usi.ch

Thanks Fernando, On Apr 1, 2013, at 11:51 PM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Ciao Roberto, > > Whenever you remove a class that is still referenced in the system, an > ObsoleteClass takes the place of the removed class. In the late-bound > spirit of Smalltalk, the system allows removing the classes and > dealing with the current references later. I see. I'm not sure I agree with this philosophy, but I see the point. > If i may question the source of your problem: "a Dictionary > (containing receivers of method calls, i.e., classes) that I need to > serialize in a file (i.e., using Fuel)", are you sure you need to > serialize the actual classes? or just the names? or even a description > of the class within Ring? Think about what you are modeling with a > Dictionary that holds <messages,set of receivers>, and maybe try to > reify that concept. I totally agree with you Fernando. That was just a quick and dirty prototype ;) > Fernando > > > > > On Mon, Apr 1, 2013 at 9:58 PM, Max Leske <maxleske(a)gmail.com> wrote: >> I've had the same problem just recently but am stuck in a bit of work right now. I hope to elaborate at length tomorrow. >> >> Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. To fix obsolete classes you need to remove all references to it, be it in a dictionary or in a compiled method where you used the class name. >> Can you post the list of classes that are obsolete? >> >> Cheers, >> Max >> >> >> >> On 01.04.2013, at 16:51, roberto.minelli(a)usi.ch wrote: >> >>> Hi, >>> >>> I'm getting crazy about obsolete behaviors and any help here is really appreciated. >>> >>> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel). >>> >>> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class. >>> >>> Now my question is, apart from executing this small piece of code... >>> >>> SmalltalkImage current fixObsoleteReferences. >>> SystemNavigation new obsoleteBehaviors size > 0 >>> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.] >>> >>> â¦in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references? >>> >>> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated. >>> More important, I also don't know how to eliminate them. >>> >>> Thanks in advance, >>> Roberto >>> >>> >> >> >

April 2, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by roberto.minelli＠usi.ch

On Apr 1, 2013, at 9:58 PM, Max Leske <maxleske(a)gmail.com> wrote: > Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. I already tried. But then I had problems in materialization so I aborted the trial ;) > Can you post the list of classes that are obsolete? Obsolete classes I encountered were all "obsolete versions" of classes I defined :) > > Cheers, > Max > > > > On 01.04.2013, at 16:51, roberto.minelli(a)usi.ch wrote: > >> Hi, >> >> I'm getting crazy about obsolete behaviors and any help here is really appreciated. >> >> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel). >> >> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class. >> >> Now my question is, apart from executing this small piece of code... >> >> SmalltalkImage current fixObsoleteReferences. >> SystemNavigation new obsoleteBehaviors size > 0 >> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.] >> >> â¦in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references? >> >> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated. >> More important, I also don't know how to eliminate them. >> >> Thanks in advance, >> Roberto >> >> > >

April 2, 2013

Re: [Pharo-project] [Pharo-users] SLOC in Smalltalk

by HernÃ¡n Morales Durand

Hi Janko. Thanks for your useful package. Apparently there is some issue with #linesOfCode. The dummy expression below return 5 instead of 4 in Pharo 1.4 and 2 because is counting the autogenerated 'DoIt' selector. (UndefinedObject evaluatorClass new compileNoPattern: '| oc | oc := OrderedCollection new: 20. oc add: 1. oc size' in: UndefinedObject context: nil notifying: nil ifFail: []) generate linesOfCode HernÃ¡n El 31/03/2013 10:17, Janko MivÅ¡ek escribiÃ³: > Hi HernÃ¡n > > I once did some code statistics for our web frameworks, by counting: > > - Nr of packages, categories, classes, methods > - lines of code > - Avg methods/class > - Avg lines/method > > - Nr of test methods > - Avg tests/class > > - % of commented methods > - % of commented classes > > Then three graphs were drawn: > > - Methods in classes > - Class inheritance depth > - Lines in methods > > Results can be seen here: > > https://docs.google.com/spreadsheet/ccc?key=0Atnb1W9vuq9ndG4wbUpxNXpKQnFZRl… > > The code measuring all above is here: > > http://www.squeaksource.com/WebCodeStats.html > > > Hope this helps > Janko > > > Dne 31. 03. 2013 09:23, piÅ¡e HernÃ¡n Morales Durand: >> Hi there, >> Guys, what are you using to measure logical lines of code (LOC) in Pharo? >> Given I am measuring a script, is there any other software measure you >> may recommend? >> Cheers, >> >> HernÃ¡n >> >

April 2, 2013

Re: [Pharo-project] Modern and Future Smalltalk

by Dennis Schetinin

+1 Really, looks like I'll take a lot from that presentation! :) -- Best regards, Dennis Schetinin 2013/4/1 Sean P. DeNigris <sean(a)clipperadams.com> > Janko MivÅ¡ek wrote > > On the Web Frontiers with Smalltalk > > http://ftp.eranova.si/aida/mivsek-web-frontiers-esug11.pdf > > Great slideshow! Thanks :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Modern-and-Future-Smalltalk-tp4679154p4679196.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 2, 2013

Re: [Pharo-project] Pharo Vision is becoming reality

by Igor Stasenko

On 1 April 2013 22:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > On Apr 1, 2013, at 3:35 PM, "Igor Stasenko [via Smalltalk]" <[hidden email]> > wrote: > >> And as for ephemerons, >> the implementation exists, and actually it's in our VMs. > > So right now, are blocks held weakly by announcers? That was my major use > case. Also, do we still have to send #weak or is weak now the default? > No, the language-side integration is not done. It should wait till we will have VM ready for it. > Cheers, > Sean > > ________________________________ > View this message in context: Re: Pharo Vision is becoming reality > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.

April 1, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by Yanni Chiu

On 01/04/13 10:51 AM, roberto.minelli-BHDiRLqP7qo(a)public.gmane.org wrote: > > For me the entire "behavior" of obsolete classes is obscure and I > don't know how those classes are originated. They arise when you delete a class, but you still have references to the class in the image. You could have instances of the deleted class, references to the class in a method, or even subclasses that refer the the deleted class. > More important, I also don't know how to eliminate them. Make sure there are no dangling references, before you delete the class. Another possibility depends on whether the "obsolete" class has a non-obsolete equivalent if the image where you're de-materializing the Fuel file. If there is no equivalent class, but you still want to materialize the Fuel file there, you can set up a mapping to map the object to some other class (e.g. ClassThatWasDeleted class or even just used Object class). The object will be materialized, but probably most of it's instance variable values will be thrown away. This may or may not be the behaviour you want though.

April 1, 2013