- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RPackage

by csrabak＠bol.com.br

I think this small thread is an excellent example of the need we have to implement simpler practice: When we announce a package or project, it would nice if the first paragraph[s] could be a short description of what it's all about! We could even open another thread and agree upon a format for it, and look, we could even have the same text in some specific attribute in the package which could be collected, selected, etc.!! -- Cesar Rabak Em 06/12/2010 07:08, Tudor Girba < tudor.girba(a)gmail.com > escreveu: Good work, Cyrille! For people that might not know what RPackage is, this project aims to replace PackageInfo with a faster and cleaner implementation. At the moment, all categories are mapped one-to-one and in the end, we would like to remove class categories altogether. This infrastructure is also targeted to code browsers. Doru On 6 Dec 2010, at 09:58, Cyrille Delaunay wrote: > Hello, > > Recently I made some improvements about RPackage. What I mainly did, is to implement the 'SystemAnnounncements listening', to update the organizer when the system change. With that I implemented a set of tests that should all be green now (in RPackageMCSynchronisationTest (I should change the name)). > > You can load RPackage by evaluating: > > Gofer new > squeaksource: 'PharoInbox'; > package: 'ConfigurationOfRPackage'; > load. > (Smalltalk at: #ConfigurationOfRPackage) perform: #loadDefault. > > (I think it should work, but squeaksource is down for now, so I was not able to test it). > > In those tests I started to write some about traits, but after few, I realized that the events emitted when a trait change are the same that the one used for classes ? > Then if you have some ideas about what is still missing in RPackage, tell me, I can add it to my task list :) -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Dec. 6, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by csrabak＠bol.com.br

James, The point of your post will surely be answered by other, and I'm sure you'll find good stuff in STIC and ESUG websites. However, the purpose of yours surprises me: why do you think that having "a popular and great IDE company" "supporting" Smalltalk is of any help? Decoupling the Smalltalk environment from the "IDE" will make a Frankenstein which will make the acronym 'IDE' look like an oxymoron... Regards, -- Cesar Rabak Em 06/12/2010 03:51, James Ladd < james_ladd(a)hotmail.com > escreveu: While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the following response (below) Â Is there anything I can do/show to prove or disprove the popularity of Smalltalk? Â Rgs, James. >>Hello James. >>About Smalltalk plugin. Weel, Iâm not sure Smalltalk has a big audience now. Iâve never heard about commercial products based on Smalltalk. >>Here, some statistics http://langpop.com/

Dec. 6, 2010

Re: [Pharo-project] Comments or no integration: a simple choice for you

by csrabak＠bol.com.br

Mariano, Precisely due the size of the problem as you estimated that Stef's plan is a Good IdeaÂ®. The next step would be a Pareto classification, as it can be accepted (I hope) that SUnit has more history (and it is documented elsewhere, like PBE book) than other classes which even the name of it or its methods may be insufficient to arrive at for what is the class. We should create IRC meetings, sprints, etc. specially targeted to document these classes. my .019999... -- Cesar Rabak Em 05/12/2010 20:07, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: On Sun, Dec 5, 2010 at 9:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: Hi guys I decided that I will not integrate any code that is not documented in Pharo. I strongly suggest to remove from Pharo-dev packages whose classes are not commented. I think this is not a good idea...look this approx: | pharoCorePackages packagesDev nonCommentedClasses totalClasses | pharoCorePackages := #('MultilingualTests' 'Morphic' 'ToolBuilder-Kernel' 'PackageInfo' 'Polymorph-ToolBuilder' 'Network-Kernel' 'Network-Protocols' 'Compiler' 'System-Finalization' 'Settings-Graphics' 'Collections' 'Network-RemoteDirectory' 'Traits' 'Network-URI' 'Settings-Display' 'Collections-Abstract' 'Settings-Compiler' 'MonticelloMocks' 'ScriptLoader11' 'System-Digital Signatures' 'System-Localization' 'MenuRegistration' 'Polymorph-TaskbarIcons' 'Monticello' 'ToolBuilder-Morphic' 'MCDirtyPackage' 'Collections-Weak' 'Settings-Polymorph' 'Tests' 'HelpSystem-Core-Utilities' 'SUnit' 'Collections-Text' 'Compression' 'Morphic-MorphTreeWidget' 'HelpSystem-Core' 'ToolsTest' 'Gofer-Core' 'Gofer-Tests' 'Collections-Stack' 'FreeType' 'MonticelloConfigurations' 'Polymorph-Geometry' 'Collections-Support' 'SUnitGUI' 'HelpSystem-Core-Model' 'Tests-VM' 'System-Change Notification' 'System' 'Tests-ObjectsAsMethods' 'HostMenus' 'Network-MIME' 'Network-RFC822' 'VB-Regex' 'TrueType' 'Depr ecatedPreferences' 'System-Clipboard' 'System-Settings' 'MorphicTests' 'System-Serial Port' 'NetworkTests' 'Collections-Unordered' 'System-Changes' 'System-Object Storage' 'Collections-Traits' 'System-Platforms' 'Tests-PrimCallController' 'Morphic-TrueType' 'Multilingual' 'Graphics' 'Collections-Strings' 'KernelTests' 'System-FileRegistry' 'Tests-Bugs' 'ToolBuilder-SUnit' 'Tests-Release' 'Morphic-Balloon' 'Settings-Network' 'System-Applications' 'Polymorph-Tools-Diff' 'Settings-Tools' 'ScriptLoader' 'ST80' 'FreeTypeSubPixelAntiAliasing' 'Settings-Kernel' 'Settings-System' 'CompilerTests' 'System-Tools' 'System-Hashing' 'System-Download' 'Collections-Streams' 'Tests-SystemChangeNotification' 'GraphicsTests' 'Polymorph-Widgets' 'Kernel' 'Tools' 'Settings-FreeType' 'FreeTypeTests' 'Settings-Monticello' 'HelpSystem-Tests' 'Polymorph-EventEnhancements' 'System-Support' 'MonticelloGUI' 'System-FilePackage' 'System-Object Events' 'Announcements' 'System-Text' 'Exceptions' 'Network- UUID' 'System-Pools' 'FixUnderscores' 'HelpSystem-Core-UI' 'GraphicsResources' 'Files' 'Gofer' 'Network-MailSending' 'Collections-Arrayed' 'CollectionsTests' 'Balloon' 'Network-Url' 'Collections-Sequenceable' ). packagesDev := (PackageInfo allPackages collect: [:each | each packageName]) difference: pharoCorePackages. nonCommentedClasses := packagesDev inject: 0 into: [:sum :each | sum + (((PackageInfo named: each) classes select: [:aClass | aClass comment asString includesSubString: 'is xxxxxxxxx.']) size)]. Transcript show: 'nonCommentedClasses: ', nonCommentedClasses asString. totalClasses :=Â packagesDev inject: 0 into: [:sum :each | sum + (PackageInfo named: each) classes size ]. Transcript show: 'totalClasses: ', totalClasses asString. Shows: nonCommentedClasses: 1116 totalClasses: 1369 I'm not sure that I will look at code or answer question to code that is not commented. We should change our mindset and it seems that we do not care, so we should take radical decisions: less changes, less progress, more comments. And for once I will not bash the past. Smalltalk was always with methods fully documented. We are just plain lazy and this is a shame. Stef

Dec. 6, 2010

Re: [Pharo-project] Category Renaming under Monticello

by Henrik Johansen

On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote: > > On 06 Dec 2010, at 15:42, Henrik Johansen wrote: > >> If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. > > OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? > > And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? > > Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? > > Anyway, thanks for the reply. > > Sven IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty. So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically. New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either. If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename) TLDR; The packages will contain the correct code, if you publish them. Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition. Cheers, Henry

Dec. 6, 2010

Re: [Pharo-project] Category Renaming under Monticello

by Sven Van Caekenberghe

On 06 Dec 2010, at 15:42, Henrik Johansen wrote: > If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ? And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ? Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ? Anyway, thanks for the reply. Sven

Dec. 6, 2010

Re: [Pharo-project] Category Renaming under Monticello

by Henrik Johansen

On Dec 6, 2010, at 3:38 22PM, Sven Van Caekenberghe wrote: > Hi, > > When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition. > > I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one. > > I also wanted to rename a category, but that would give the same issue I guess. > > I am sure this is worth a FAQ entry, but I could find anything. > > Anyone any idea ? > > Thx, > > Sven IIRC, Monticello does not automatically create new packages (or delete empty ones) based on recategorization. If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place. Cheers, Henry

Dec. 6, 2010

[Pharo-project] Category Renaming under Monticello

by Sven Van Caekenberghe

Hi, When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition. I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one. I also wanted to rename a category, but that would give the same issue I guess. I am sure this is worth a FAQ entry, but I could find anything. Anyone any idea ? Thx, Sven

Dec. 6, 2010

Re: [Pharo-project] Debugger not closed issue ?

by laurent laffont

On Mon, Dec 6, 2010 at 2:02 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 6 Dec 2010, laurent laffont wrote: > > >>> >>> We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the >>> fix), that resulted in hanging debugger instances. To reproduce the >>> issue: >>> - open a debugger >>> - type something to the inspector in the lower right panel and make sure >>> you've triggered OCompletion. >>> After closing the debugger it won't be garbage collected. >>> >>> >> >> Thank you Levente. How can I check that my immortal debuggers are the >> consequence of this bug ? >> > > If there are more than one instances (or sub-instances) of ECController in > your image after closing all windows, then it's very probable that this is > the cause of the problem. > I have no instance. > > If you load OCompletion-klub.84 (which is the last version of OCompletion > that's compatible with Pharo 1.1) and evaluate this: > > ECController allSubInstancesDo: [ :each | each editor ]. > Smalltalk garbageCollect. > > Then the debuggers should be gone. > I've tried but they are still here. So it's another issue (maybe Autotest. I will work without Autotest to see if I can reproduce the problem). Laurent. > > > Levente > > > >> Laurent. >> >> >> >> >>> >>> Levente >>> >>> >>> >>> Cheers, >>>> >>>> Laurent Laffont >>>> >>>> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >>>> Blog: http://magaloma.blogspot.com/ >>>> >>>> >>>> >>> >> >

Dec. 6, 2010

Re: [Pharo-project] Debugger not closed issue ?

by Schwab,Wilhelm K

Just out of curiosity, I went directly to Debugger allInstances size and got zero :) This is in a far from fresh 1.1.1 image. I do not use eCompletion or AutoTest. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Monday, December 06, 2010 4:26 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugger not closed issue ? I don't know why nor when, but someone once suggest me to always do 3 timesRepeat: [Smalltalk garbageCollect]. Can you check: Debugger closeAllDebuggers. 3 timesRepeat: [Smalltalk garbageCollect]. Debugger allInstances size. If this works, then it would be nice to have someone that explains to us haha

Dec. 6, 2010

Re: [Pharo-project] Debugger not closed issue ?

by Levente Uzonyi

On Mon, 6 Dec 2010, laurent laffont wrote: >> >> >> We recently fixed a bug in OCompletion (load OCompletion-klub.84 for the >> fix), that resulted in hanging debugger instances. To reproduce the issue: >> - open a debugger >> - type something to the inspector in the lower right panel and make sure >> you've triggered OCompletion. >> After closing the debugger it won't be garbage collected. >> > > > Thank you Levente. How can I check that my immortal debuggers are the > consequence of this bug ? If there are more than one instances (or sub-instances) of ECController in your image after closing all windows, then it's very probable that this is the cause of the problem. If you load OCompletion-klub.84 (which is the last version of OCompletion that's compatible with Pharo 1.1) and evaluate this: ECController allSubInstancesDo: [ :each | each editor ]. Smalltalk garbageCollect. Then the debuggers should be gone. Levente > > Laurent. > > > >> >> >> Levente >> >> >> >>> Cheers, >>> >>> Laurent Laffont >>> >>> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >>> Blog: http://magaloma.blogspot.com/ >>> >>> >> >

Dec. 6, 2010