- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Extent a Athens surface?

by Igor Stasenko

On 30 January 2013 18:14, MartinW <wm(a)fastmail.fm> wrote: > Igor Stasenko wrote >>>> I wanted to ask if it's possible to extent an Athens surface. If it >>>> can't be done, because as far as I understand this can't be done in >>>> Cairo, is it possible to simulate it at least? Is it possible to stop >>>> #drawDuring: and build another surface, maybe? >> how large? >> is >> >> AthensCairoSurface extent: 2000@2000 >> >> not works? > > I think it is about resizing an existing Morph that is drawn with Athens > Surface? I had problems with it and had the same question. But it works well > with something like: > > SomeSubclassOfMorph>>extent: aPoint > |newExtent| > newExtent := aPoint rounded. > (bounds extent closeTo: newExtent) ifTrue: [^ self]. > self changed. > bounds := (bounds topLeft extent: newExtent). > surface := AthensCairoSurface extent: newExtent. > self layoutChanged. > self changed. > > Now Boids fly in a resizable sky :) > yes. this is the way. you cannot resize existing surface, but create a new one instead. > > > -- > View this message in context: http://forum.world.st/Extent-a-Athens-surface-tp4665978p4666666.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Camillo Bruni

I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code. Methods are classified using the following rules: 1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..) 2. getters and setters of instance variables 3. know protocols of super implementors 4. gather all implementors in the system and choose the most used protocol. I guess that will cover most stuff, of course known prefixes will have to be extended... On 2013-01-30, at 20:52, Chris Muller <asqueaker(a)gmail.com> wrote: >> To be honest I have problems understanding why method categorization is so important. > > It provides a look into the mind of the author. > >> Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :) > > Ha! I remember when I used to voluntarily submit myself to lint's > slavery. For a while I was putting in selectors to ignore or whatever > the filtering capability it had -- until one day I said, "enough". > Since then I mostly just check for "Bugs" -- let lint work for ME. > Perhaps a better approach to help you relax would be to remove that > particular Lint rule..? :) Ahh, freedom. :) > > Categories they are "integrated documentation" and, the fact that some > methods remain 'as yet unclassified' IS meaningful -- it indicates > that the class is either private or single-purpose. There are a lot > of "code elements" in the system (classes, methods, categories, > packages, etc.) and so sometimes, as you said, classes are simple > enough that additional category elements are not needed. > > Categories are the domain of humans, not machines. They're for the > writer to communicate to the readers. Auto-categorization does not > increase the effectiveness of categories -- in fact I think it would > dilute it. > >> What is the use? Declaring usage patterns? > > Yes. > >> .. Declaring visibility? > > Yes. > >> Use as method extensions marker? > > Yes. > > anything you like just classify? I can understand that it can help > making the access of certain methods of a class easier. But that is > particular true for classes with a lot of methods. Most of the classes > are rather small. In most of my own developments I would consider most > huge classes a design problem in my code. So I would try to fix that. >> And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard. > > Two ways to do that (at least in Pharo 1.4, not sure about 2.0). > > 1) With focus on the methods list, press Shift+Command+C. > 2) Turn on System | Settings | Code browsing | Show annotation panes. > >> I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential. > > +1. Because "as yet" implies it "will" or "needs" to be classified, > which isn't always true. >

Jan. 30, 2013

Re: [Pharo-project] OrderedIdentityDictionary in a more general package

by Frank Shearar

On 30 January 2013 19:44, Torsten Bergmann <astares(a)gmx.de> wrote: > The class "OrderedIdentityDictionary" is currently defined in package "Spec-Core". > > Since it is useful also in other scenarios and I do not want a dependency > on spec: wouldnt it make sense to move it to a more common "Collections-..." > package. > > Since there is already "Collections-Unordered" I would suggest to put it > into "Collections-Ordered". > Mmmhh ... but then class OrderedCollection would have to move from "Collections-Sequenceable" > to "Collections-Ordered" as well (at least from the name). > > Any comments on that... > > Thx > T. If something is ordered, surely it's sequenceable? Why not put it in Collections-Sequenceable? frank

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Chris Muller

> To be honest I have problems understanding why method categorization is so important. It provides a look into the mind of the author. > Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :) Ha! I remember when I used to voluntarily submit myself to lint's slavery. For a while I was putting in selectors to ignore or whatever the filtering capability it had -- until one day I said, "enough". Since then I mostly just check for "Bugs" -- let lint work for ME. Perhaps a better approach to help you relax would be to remove that particular Lint rule..? :) Ahh, freedom. :) Categories they are "integrated documentation" and, the fact that some methods remain 'as yet unclassified' IS meaningful -- it indicates that the class is either private or single-purpose. There are a lot of "code elements" in the system (classes, methods, categories, packages, etc.) and so sometimes, as you said, classes are simple enough that additional category elements are not needed. Categories are the domain of humans, not machines. They're for the writer to communicate to the readers. Auto-categorization does not increase the effectiveness of categories -- in fact I think it would dilute it. > What is the use? Declaring usage patterns? Yes. > .. Declaring visibility? Yes. > Use as method extensions marker? Yes. anything you like just classify? I can understand that it can help making the access of certain methods of a class easier. But that is particular true for classes with a lot of methods. Most of the classes are rather small. In most of my own developments I would consider most huge classes a design problem in my code. So I would try to fix that. > And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard. Two ways to do that (at least in Pharo 1.4, not sure about 2.0). 1) With focus on the methods list, press Shift+Command+C. 2) Turn on System | Settings | Code browsing | Show annotation panes. > I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential. +1. Because "as yet" implies it "will" or "needs" to be classified, which isn't always true.

Jan. 30, 2013

[Pharo-project] OrderedIdentityDictionary in a more general package

by Torsten Bergmann

The class "OrderedIdentityDictionary" is currently defined in package "Spec-Core". Since it is useful also in other scenarios and I do not want a dependency on spec: wouldnt it make sense to move it to a more common "Collections-..." package. Since there is already "Collections-Unordered" I would suggest to put it into "Collections-Ordered". Mmmhh ... but then class OrderedCollection would have to move from "Collections-Sequenceable" to "Collections-Ordered" as well (at least from the name). Any comments on that... Thx T.

Jan. 30, 2013

[Pharo-project] help needed

by Usman Bhatti

I am trying to look into this issue in Glamour related to morphs: http://code.google.com/p/pharo/issues/detail?id=7345 The problem is that, in Glamour, one can choose to display first few items instead of the all and then the user can choose to display more. When the selection is set to the items not shown, there is a DNU in PaginatedMorphTreeMorph. Digging this problem, I have encountered this piece of code for which I would require the help of someone knowing Morph. Is someone knowledgable about this piece of code? Here you can find an image with the script to explore the problem: https://dl.dropbox.com/u/11804892/glamour-treemorphs.zip MorphTreeMorph >> update: update: aSymbol aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) ifTrue: [^ self selectedItems: aSymbol second]. aSymbol == self nodeListSelector ifTrue: [^ self updateList]. aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) openItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #expandAllFromNode:]]]) ifTrue: [^ self expandAllFromNode: aSymbol third]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #closeItemPath]]]) "allow directed path closing where multiple trees exist" ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) closeItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: aSymbol allButFirst]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ aSymbol second == #expandRoots]]]) ifTrue: [^self expandRoots]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. aSymbol second = #collapseAll ifTrue: [^ self collapseAll]]

Jan. 30, 2013

Re: [Pharo-project] zn url with passwords

by Sven Van Caekenberghe

On 29 Jan 2013, at 15:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 29 Jan 2013, at 14:49, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> On Tue, Jan 29, 2013 at 1:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> You are correct: username/password in URLs is not something that is supported by ZnUrl, by design actually. >>> >>> Why do you need it ? >> >> we are implementing the Git protocol with the HTTP backend. Git urls >> often comes with username inside and that's why we thought it would be >> easier to just use #asZnUrl. And these username and password elements >> are part of the standard >> (http://en.wikipedia.org/wiki/URI_scheme#Examples) > > I will see if I can add it in an elegant way. > > I still feel it is a bit old school, from the FTP days, 99% of URLs won't ever have this. > > But yes, I know it is used in some places, like git... I added this (in bleedingEdge) so that 'git://user@foo.com/bar' asZnUrl works as expected. Sven ==================== Summary ==================== Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.9 Author: SvenVanCaekenberghe Time: 30 January 2013, 7:41:44 am UUID: 9c2126e3-8881-49f5-8d59-38efbb6d796d Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.8 Extended ZnUrl to support the optional user info (username and optional password) component; Modified ZnUrl to allow any scheme, added #enforceKnownScheme -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Gary Chambers

Sorry! Mostly me... Regards, Gary ----- Original Message ----- From: "Esteban Lorenzano" <estebanlm(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, January 30, 2013 1:07 PM Subject: Re: [Pharo-project] I hate 'as yet unclassified' > holy s**t , 35! > > and I'm more or less a maniac of classification :P > > On Jan 30, 2013, at 2:02 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> In Pharo 20498, sorted by author in the method timestamp: >> >> gvc 1550 >> AlainPlantec 320 >> 216 >> GaryChambers 215 >> CamilloBruni 163 >> IgorStasenko 159 >> stephaneducasse 152 >> avi 148 >> Igor.Stasenko 128 >> StephaneDucasse 85 >> SeanDeNigris 81 >> MarcusDenker 78 >> ab 75 >> GuillermoPolito 68 >> tween 52 >> BenjaminVanRyseghem 51 >> ar 46 >> di 40 >> RAA 38 >> alain.plantec 38 >> EstebanLorenzano 35 >> FernandoOlivero 33 >> nice 31 >> tk 29 >> nk 28 >> cwp 26 >> dvf 22 >> rr 20 >> PavelKrivanek 18 >> MarianoMartinezPeck 18 >> yo 18 >> sd 18 >> bf 16 >> SvenVanCaekenberghe 16 >> JMM 16 >> marcus.denker 14 >> wiz 12 >> ajh 12 >> mjr 12 >> cipt 10 >> abc 10 >> md 10 >> HenrikSperreJohansen 9 >> MikeRoberts 8 >> AndyKellens 6 >> LukasRenggli 6 >> noha 6 >> ClementBera 6 >> jrd 6 >> GastonDallOglio 6 >> 2011-01-24T15:34:00+01:00 6 >> DeboraFortini 5 >> stephane.ducasse 5 >> lr 5 >> 2011-01-24T15:33:00+01:00 4 >> dgd 4 >> DamienCassou 4 >> TestRunner 4 >> bkv 4 >> BG 4 >> Alexandre 4 >> AndrewBlack 4 >> sw 4 >> SimonAllier 3 >> DanielAvivEstebanAllende 3 >> ASB 2 >> mas 2 >> pmm 2 >> simondenier 2 >> BernardoContreras 2 >> th 2 >> damienpollet 2 >> NicoPaez 2 >> CamilloBrui 2 >> sps 2 >> MiguelCoba 2 >> eem 2 >> NikoSchwarz 2 >> JavierPimas 2 >> GabrielOmarCotelli 2 >> mir 2 >> ul 2 >> 2011-01-24T15:50:00+01:00 2 >> jf 2 >> c 2 >> ls 2 >> al 2 >> NorbertHartl 2 >> djp 2 >> AdrianLienhard 2 >> TorstenBergmann 2 >> AlexandreBergel 2 >> tbn 2 >> DiogenesMoreira 2 >> GuyHylton 1 >> ThierryGoubier 1 >> > >

Jan. 30, 2013

Re: [Pharo-project] [Update] Zinc-SSO now supports Dropbox !

by Sven Van Caekenberghe

On 30 Jan 2013, at 18:32, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Sven, > > could you provide a simple code fragment which shows how to write and how to read a file from the smalltalk image to the connected dropbox app folder? The whole API is not (yet) implemented. https://www.dropbox.com/developers/reference/api Have a look at ZnOAuth1TwitterUserAccess. If I find more time, I might try myself. GET is pretty straightforward, for PUT or POST you will have to supply a ZnEntity of a specific mime-type with bytes or a string. Note that for file access the host is different. > Greetings > Sabine > > On Wed, Jan 30, 2013 at 6:00 PM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi Sven, > > there was only missing loading Zodiac, the dll (windows) was already included in the 1 klick image. > > Gofer it > squeaksource: 'Zodiac'; > package: 'Zodiac-Core'; > package: 'Zodiac-Tests'; > load. > > It works. I play around now. > Thank you very much! > Sabine > > > On Wed, Jan 30, 2013 at 5:38 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Jan 2013, at 17:21, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > Hi Sven, hi Jan, > > > > thank you. > > I am one step further now but there must be something else missing to load. > > I failed with my current image, so I tried the following: > > > > I took a fresh image - the Pharo 1.4. one click app from the pharo homepage > > (http://gforge.inria.fr/frs/download.php/31258/Pharo-1.4-14557-OneClick.zip) > > > > Then I loaded seaside 3.0 (from the welcome screen - MetacelloConfigurationBrowser open). > > > > After that, I loaded > > > > Gofer it > > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > > package: 'ConfigurationOfZincHTTPComponents'; > > load. > > > > And then the bleeding Edge version > > ConfigurationOfZincHTTPComponents project bleedingEdge load: 'SSO'. > > > > Then this was possible: > > (ZnServer startDefaultOn: 8100) > > logToTranscript; > > debugMode: true; > > delegate: (ZnSSOServerDelegate new > > dropboxData: (ZnOAuth1ConsumerData newForDropbox > > consumer: 'my appdata'; > > consumerSecret: 'my appdata'; > > yourself); > > yourself). > > > > No I tried in my browser > > localhost:8100/sso-dropbox > > > > Then I got a walkback in my Image: No secure socket stream class set or available > > Well, the error says it all: you need TLS/SSL support. As is noted in > > https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md#installat… > > You can get Zodiac to work in 1.4 > > http://zdc.stfx.eu > > Don't forget that you also need the plugin next to your VM ! > > In Pharo 2.0 Zodiac is included by default the latest VM's there should have the plugin. > But in 2.0 it will be slightly more difficult to load Seaside, but it does work. > > Sorry, but all this is still a bit in motion, hopefully you will keep trying. > > > ==>> I do not have the class ZdcSecureSocketStream in my Image > > self secureSocketStreamClass is Nil in > > > > streamClassForScheme: scheme > > (#(http ws) includes: scheme) ifTrue: [ > > ^ self socketStreamClass ]. > > (#(https wss) includes: scheme) ifTrue: [ > > ^ self secureSocketStreamClass ifNil: [ > > self error: 'No secure socket stream class set or available' ] ]. > > (ZnUnknownScheme scheme: scheme) signal > > > > Can you tell me what is missing to load? > > > > Greetings > > Sabine > > > > > > 30 January 2013 5:14:22.402 pm > > > > ZnNetworkingUtils(Object)>>error: > > Receiver: a ZnNetworkingUtils > > Arguments and temporary variables: > > aString: 'No secure socket stream class set or available' > > Receiver's instance variables: > > socketStreamClass: SocketStream > > secureSocketStreamClass: nil > > > > ZnNetworkingUtils>>streamClassForScheme: > > Receiver: a ZnNetworkingUtils > > Arguments and temporary variables: > > scheme: #https > > Receiver's instance variables: > > socketStreamClass: SocketStream > > secureSocketStreamClass: nil > > > > ZnNetworkingUtils>>socketStreamToUrlDirectly: > > Receiver: a ZnNetworkingUtils > > Arguments and temporary variables: > > url: https://api.dropbox.com/1/oauth/request_token > > stream: nil > > address: #[199 47 218 158] > > Receiver's instance variables: > > socketStreamClass: SocketStream > > secureSocketStreamClass: nil > > > > ZnNetworkingUtils>>socketStreamToUrl: > > Receiver: a ZnNetworkingUtils > > Arguments and temporary variables: > > url: https://api.dropbox.com/1/oauth/request_token > > Receiver's instance variables: > > socketStreamClass: SocketStream > > secureSocketStreamClass: nil > > > > > > > > > > On Wed, Jan 30, 2013 at 4:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Sabine, > > > > On 30 Jan 2013, at 16:24, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > > > Hi Sven, > > > > > > after loading: > > > > > > Gofer it > > > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > > > package: 'ConfigurationOfZincHTTPComponents'; > > > load. > > > > > > ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. > > > > > > The ZnOAuth1ConsumerData does not have a method called >>newForDropbox (but >>newForGoogle and >>newForTwitter). > > > Also, ZnSSOServerDelegate does not have a method >>dropboxData: (but facebook, twittter and google) > > > > > > Did I miss something? > > > > Yes and no. The latest stable version of the configuration does not yet include the Dropbox code. > > The following will load what is called bleedingEdge, the very latest version of everything, regardless of its release status. > > > > ConfigurationOfZincHTTPComponents project bleedingEdge load: 'SSO'. > > > > Sorry about that. > > > > Sven > > > > > Greetings > > > Sabine > > > > > > > > > On Sun, Jan 27, 2013 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > On 27 Jan 2013, at 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > If anyone is interested, I can write another email explaining how you can run this demo for yourself on your own account. > > > > > > How to run the Dropbox code yourself: > > > > > > 1. Get yourself a free Dropbox account at http://www.dropbox.com > > > > > > 2. Install some client software on one or more of your computers (Mac, Windows, Linux) or devices (iOS [iPhone, iPad, iPod], Android, BlackBerry, Kindle Fire) and move some files around to get a feel for the service. > > > > > > 3. When you give other applications access to (part of) your Dropbox files, you can check that at https://www.dropbox.com/account#applications > > > > > > 4. Define your own app that will try to access Dropbox files. Go to https://www.dropbox.com/developers (Developer home) and start defining a new app by clicking the 'Create an app' button at https://www.dropbox.com/developers/apps - start with the access type 'App folder'. > > > > > > 5. The two important elements you need are the 'App key' and 'App secret', make sure to copy them correctly. > > > > > > 6. Get the very latest code in your image (we develop in Pharo 2.0, but 1.4 or even 1.3 should work - SSL has to be fully operational). > > > > > > Gofer it > > > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > > > package: 'ConfigurationOfZincHTTPComponents'; > > > load. > > > > > > ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. > > > > > > 7. Start a Zn server with an appropriate delegate, configured for your app > > > > > > (ZnServer startDefaultOn: 8100) > > > logToTranscript; > > > debugMode: true; > > > delegate: (ZnSSOServerDelegate new > > > dropboxData: (ZnOAuth1ConsumerData newForDropbox > > > consumer: 'vqz-app-key-zoca'; > > > consumerSecret: '13u-app-secret-8l006'; > > > yourself); > > > yourself). > > > > > > (The above is a demo setup limited to Dropbox, the other demos are not configured and won't work). > > > > > > 8. Go to http:://localhost:8100/sso-dropbox and click the link to log in - you will be transferred to Dropbox to log in (if you aren't already) and asked to authorise your demo app, after which Dropbox will redirect you back to your app. > > > > > > 9. Once back in your app, sso-dropbox-callback (#ssoDropboxCallback:) will access your account info and list the app root folder, which will then be shown. > > > > > > 10. For the rest of the API, (currently not yet implemented), see https://www.dropbox.com/developers/reference/api - you don't have to worry about the whole authentication thanks to Zinc-SSO. > > > > > > We would love for others to try this (as well as the other Zinc-SSO options, Google, Facebook, Twitter) out, in their own projects, and to provide actual feedback and generally help improve the code and documentation. > > > > > > As always, May the Source be with you! > > > > > > Sven > > > > > > PS: The demo app is not (yet) a production app: only you and up to 5 explicitly listed users can use it. You have to apply for production status later on. Also, the whole ZnSSOServerDelegate code is a demo, for an actual project, it would be best to extract the necessary parts out of it, reusing the underlying Zinc-SSO-OAuth1-Core framework. > > > > > > -- > > > Sven Van Caekenberghe > > > http://stfx.eu > > > Smalltalk is the Red Pill > > > > > > > > > > > > > > > > > > >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Sven Van Caekenberghe

On 30 Jan 2013, at 15:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Can it be done in plain Smalltalk ? Something crude like this: OrderedCollection streamContents: [ :stream | Object withAllSubclassesDo: [ :eachClass | stream nextPutAll: (eachClass methods select: [ :each | each category = #'as yet unclassified' ]) ] ]. OrderedCollection streamContents: [ :stream | Object withAllSubclassesDo: [ :eachClass | stream nextPutAll: (eachClass methods select: [ :each | each category = #'nil' ]) ] ]. It is then possible to subselect on author. But blaming people who contribute (a lot) might not be the best strategy. Often the author is the one who last changed a method, the missing categorisation was probably already there. Also, creating methods from certain tools makes then automatically uncategorisedâ¦ Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 30, 2013