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

Re: [Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by Guillermo Polito

On Fri, Apr 6, 2012 at 8:07 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > > On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 6 April 2012 16:53, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > BasicClassOrganizer has no users... Is it there for any purpose? >> > >> > What about joining them? >> > >> >> Ehh... i was also looked at those classes couple years ago and >> wondered why if its really worth >> having so complex implementation to save few bytes of space.. >> >> I would rewrite this stuff and leave just a Categorizer with clean >> protocol and structure: >> > > yes > > - categorizer holds categories (order could be important, but i would >> just keep it unspecified , i.e, >> > > yes. I was working in a simple version having #sort:, > #sortAlphabetically, #sortByAmmountOfElements > > >> instead >> OrderedCollection ( categoryName -> {.. category items .. } ) >> >> I would use Dictionary >> #categoryName -> Set(items) >> > > I'd like having a Category object there. > > >> >> this class should serve basic operations like adding /removing and >> queries: >> - what is a categor(ies) of element (if element can be include only >> into single category at once) >> - what are category names >> - what are elements of specific category.. >> Period. >> And it actually can serve as a general categorizer (not just for >> classes/packages). >> > > but then we have to put the changes announcements/notifications in another > place > > >> >> The way how BasicClassOrganizer using inheritance is abuse.. >> since it extends a clean concept (Categorizer) with unrelated stuff, >> like classComment and commentStamp. >> > > Ok, you are making me open an issue to move those to class :). 1.5? > I'm having a warning telling me class should not be redefined when doing | classCommentVarName commentStampVarName | classCommentVarName := 'classComment' capitalized. commentStampVarName := 'commentStamp' capitalized. Class addInstVarNamed: classCommentVarName. Class addInstVarNamed: commentStampVarName. ProtoObject allSubclassesDo: [ :c | c instVarNamed: classCommentVarName put: (c organization classComment). c instVarNamed: commentStampVarName put: (c organization commentStamp) ]. But proceeding takes a while but seems to work... Any special reason to not adding inst vars to Class? > >> Class organizer, should instead delegate, or even better, Class >> should use two different fields for categories and class comment.. >> but not mixing everything into one pile of mess. >> >> > Guille >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

April 6, 2012

Re: [Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by Guillermo Polito

On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 April 2012 16:53, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > BasicClassOrganizer has no users... Is it there for any purpose? > > > > What about joining them? > > > > Ehh... i was also looked at those classes couple years ago and > wondered why if its really worth > having so complex implementation to save few bytes of space.. > > I would rewrite this stuff and leave just a Categorizer with clean > protocol and structure: > yes - categorizer holds categories (order could be important, but i would > just keep it unspecified , i.e, > yes. I was working in a simple version having #sort:, #sortAlphabetically, #sortByAmmountOfElements > instead > OrderedCollection ( categoryName -> {.. category items .. } ) > > I would use Dictionary > #categoryName -> Set(items) > I'd like having a Category object there. > > this class should serve basic operations like adding /removing and queries: > - what is a categor(ies) of element (if element can be include only > into single category at once) > - what are category names > - what are elements of specific category.. > Period. > And it actually can serve as a general categorizer (not just for > classes/packages). > but then we have to put the changes announcements/notifications in another place > > The way how BasicClassOrganizer using inheritance is abuse.. > since it extends a clean concept (Categorizer) with unrelated stuff, > like classComment and commentStamp. > Ok, you are making me open an issue to move those to class :). 1.5? > Class organizer, should instead delegate, or even better, Class > should use two different fields for categories and class comment.. > but not mixing everything into one pile of mess. > > > Guille > > -- > Best regards, > Igor Stasenko. > >

April 6, 2012

Re: [Pharo-project] Docking windows

by Guillermo Polito

He, actually, the window dragging code is kind of duplicated for fast and non fast dragging, so making it work for both was double work (or more) Â¬Â¬. On Fri, Apr 6, 2012 at 7:24 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Because the main purpose is to be able to dock a window to do > left/right or top/bottom border of the display, fast dragging is only > an instrument :-) > > -- Pavel > > On Fri, Apr 6, 2012 at 7:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Fun :). > > > > But why is the mail title called Docking Windows and not fast dragging? > > > > Cheers, > > Doru > > > > > > On 6 Apr 2012, at 12:52, Guillermo Polito wrote: > > > >> I wanted docking windows, so I did a little change over the > MorphFrameGhost to support it. > >> > >> If anyone wants to try, filein the attached the changeset and then > evaluate: > >> > >> UITheme currentSettings fastDragging: true. > >> > >> Guille > >> <docking windows.cs> > > > > -- > > www.tudorgirba.com > > > > "Don't give to get. Just give." > > > > > > > > > > > > > >

April 6, 2012

Re: [Pharo-project] Docking windows

by Pavel Krivanek

Because the main purpose is to be able to dock a window to do left/right or top/bottom border of the display, fast dragging is only an instrument :-) -- Pavel On Fri, Apr 6, 2012 at 7:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Fun :). > > But why is the mail title called Docking Windows and not fast dragging? > > Cheers, > Doru > > > On 6 Apr 2012, at 12:52, Guillermo Polito wrote: > >> I wanted docking windows, so I did a little change over the MorphFrameGhost to support it. >> >> If anyone wants to try, filein the attached the changeset and then evaluate: >> >> UITheme currentSettings fastDragging: true. >> >> Guille >> <docking windows.cs> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >

April 6, 2012

Re: [Pharo-project] tail-like

by Tudor Girba

Thanks. I will take a look. Doru On 6 Apr 2012, at 17:32, David T. Lewis wrote: > On Fri, Apr 06, 2012 at 03:21:33AM -0700, drush66 wrote: >> It kind of depends on the OS, but all of them let you subscribe to events on >> the files in some way. So you would subscribe with os to notify you when >> some file is changed in some way, keep some internal house keeping >> information like position up to which you have displayed info, verify that >> file has indeed changed, read and display new stuff, update internal info. >> >> In essence nothing substantially complicated, but windows and unix interface >> differs, and at least windows (never investigated unix api in more detail) >> requires you to dance a bit before you get some results. >> >> Such pieces of code is also often used by text editors to notify user that >> the file in editor has been changed from the outside. (maybe moose already >> has something like that?) >> >> Davorin Rusevljan > > On unix/linux/osx you can probably do this with AioPlugin. The OSProcess > unit tests provide examples in AioEventHandlerTestCase. The example in > AioEventHandlerTestCase>>testFileReadableEvent is a good place to start. > > Dave > > -- www.tudorgirba.com "We are all great at making mistakes."

April 6, 2012

Re: [Pharo-project] Docking windows

by Tudor Girba

Fun :). But why is the mail title called Docking Windows and not fast dragging? Cheers, Doru On 6 Apr 2012, at 12:52, Guillermo Polito wrote: > I wanted docking windows, so I did a little change over the MorphFrameGhost to support it. > > If anyone wants to try, filein the attached the changeset and then evaluate: > > UITheme currentSettings fastDragging: true. > > Guille > <docking windows.cs> -- www.tudorgirba.com "Don't give to get. Just give."

April 6, 2012

Re: [Pharo-project] SmallLint and manifest

by Tudor Girba

Hi, Thanks. I gave it a short try, and here are some comments: - The Manifest-Core should contain only the core of the manifest engine. For example, I see here some mechanism for traversing Manifest classes and retrieving data from them. Everything else that is specific to SmallLint should be in a Manifest-SmallLint package. - All tests should be in the Manifest-Tests package (currently, there are extension tests in Manifest-Core - I actually do not know why) - I like it that a Manifest class does not have to inherit from a specific root class. - There exists a ManifestManifestCore class, but I do not understand why there are subclasses to it. - You are using numbers to identify SmallLint rules. For this, you extended the rules with unique numbers. This is a very brittle scheme, and when people have domain specific rules, you will likely get a mess. Furthermore, I do not see the reason for having a number as a unique identifier, when you already have a unique identifier in the name of the rule class. Also, when looking at a method, we see something like: rule17V1FalsePositive. This is unnecessary cryptic. - In the rule methods, you are storing strings. This means that when someone renames a rule, the code in there will not be updated. Why not store this information as normal code and use symbols that can be queried? Cheers, Doru On 6 Apr 2012, at 09:51, Simon Allier wrote: > Hi pharoers > > Since a couple of months the Pharo team has been working on improving the support for rules checking and in particular the handling of false positives (there is nothing more boring that to get all the time the same warnings that we know are not adequate). > We added a manifest mechanism to manage the false/true positive of SmallLint, the rule checker of Pharo. A manifest is a class that contains meta data. In the future we may add package license and package documentation. This data is stored in methods on the meta side of the class. So, manifest can be versioned in Monticello and not lost. There is one manifest per package. > > It possible to use SmallLint with Manifest using the Critics Browser (menuWorld > Tool > CriticBrowser). With the Critics browser you can inspect violations of rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. > In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. > We will continue to improve the Browser. In addition we will run SmallLint rules to all the Pharo packages and the rules checking will be part of the package validation. We want the community to use rule checking for real so that we all improve. > > Simon and Stef > > Gofer > new > url: 'http://www.squeaksource.com/PharoTaskForces'; > package: 'ConfigurationOfManifest'; > load. > ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

April 6, 2012

Re: [Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by Igor Stasenko

On 6 April 2012 16:53, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > BasicClassOrganizer has no users...Â Is it there for any purpose? > > What about joining them? > Ehh... i was also looked at those classes couple years ago and wondered why if its really worth having so complex implementation to save few bytes of space.. I would rewrite this stuff and leave just a Categorizer with clean protocol and structure: - categorizer holds categories (order could be important, but i would just keep it unspecified , i.e, instead OrderedCollection ( categoryName -> {.. category items .. } ) I would use Dictionary #categoryName -> Set(items) this class should serve basic operations like adding /removing and queries: - what is a categor(ies) of element (if element can be include only into single category at once) - what are category names - what are elements of specific category.. Period. And it actually can serve as a general categorizer (not just for classes/packages). The way how BasicClassOrganizer using inheritance is abuse.. since it extends a clean concept (Categorizer) with unrelated stuff, like classComment and commentStamp. Class organizer, should instead delegate, or even better, Class should use two different fields for categories and class comment.. but not mixing everything into one pile of mess. > Guille -- Best regards, Igor Stasenko.

April 6, 2012

Re: [Pharo-project] Vm on iOS with Xcode 4.3

by Esteban Lorenzano

Hi, On Apr 6, 2012, at 10:51 AM, phil(a)highoctane.be wrote: > I am still unable to get this to work. > latest nightly build from cmake is able to build valid xcode projects again [1]. Some adjusts are needed to actually build, but it is almost there (I will take care about that this days) > Also I see a jenkins build for OSX but not for iOS. > Yeah, and I want to have one, but it will take time (and time is tyrant, you know). > XCode 4.3 will open old xcode projects so posting a full set of files that work out of cmake (ie a fully made build/ folder) would help a lot. > > Would you be able to ship me such a set of files? > you already have them: clone of my repository [2] or blessed [3] and install latest ConfigurationOfCog best, Esteban [1] http://www.cmake.org/files/dev/cmake-2.8.7.20120405-gd2c9c-Darwin64-univers… [2] https://gitorious.org/~estebanlm/cogvm/cog-osx [3] https://gitorious.org/cogvm/blessed

April 6, 2012

Re: [Pharo-project] tail-like

by David T. Lewis

On Fri, Apr 06, 2012 at 03:21:33AM -0700, drush66 wrote: > It kind of depends on the OS, but all of them let you subscribe to events on > the files in some way. So you would subscribe with os to notify you when > some file is changed in some way, keep some internal house keeping > information like position up to which you have displayed info, verify that > file has indeed changed, read and display new stuff, update internal info. > > In essence nothing substantially complicated, but windows and unix interface > differs, and at least windows (never investigated unix api in more detail) > requires you to dance a bit before you get some results. > > Such pieces of code is also often used by text editors to notify user that > the file in editor has been changed from the outside. (maybe moose already > has something like that?) > > Davorin Rusevljan On unix/linux/osx you can probably do this with AioPlugin. The OSProcess unit tests provide examples in AioEventHandlerTestCase. The example in AioEventHandlerTestCase>>testFileReadableEvent is a good place to start. Dave

April 6, 2012