- Pharo-users - lists.pharo.org

Re: [Pharo-users] class variable accessor naming

by Christian Caldeiro

You can find many guidelines like these in the "Smalltalk with Style" book. For instance on page 3 it says "Upper and lowercase letters also distinguish variable scope. Variables beginning with an upper case letter (globals, classes, *class variables*, and pool dictionaries) are global to all methods within the definition scope of the variable. Method parameters, temporary variables, and instance variables begin with a lower case letter. By convention, *class and instance method names* begin with a lower case letter". You can find this and other Smalltalk books here: http://stephane.ducasse.free.fr/FreeBooks.html Christian On Wed, Apr 8, 2015 at 3:13 PM, Jan B. <bliznjan(a)fit.cvut.cz> wrote: > True, I already found few examples of accessors to class variables, but I > like to be sure when I use it for the first time. Thank you. > > Jan > > > Christian Caldeiro wrote > > Class variables should be written with Uppercase (but there are some > > classes in Pharo that don't follow this convention). Class methods > > (accessors in this case) are written in lowercase. Again, you can find > > several samples in Pharo. > > > > Thanks > > Christian > > > > On Tue, Apr 7, 2015 at 1:54 PM, Jan B. < > > > bliznjan@.cvut > > > > wrote: > > > >> Hello > >> > >> Class variable names should start with capital letter (as I just found > >> out), > >> like RecentProjects. We have a getter to it. Should such accessor method > >> be > >> named recentProjects or RecentProjects? > >> > >> ... class#>>(r/R)ecentProjects > >> ^ RecentProjects > >> > >> Jan > >> > >> > >> > >> -- > >> View this message in context: > >> http://forum.world.st/class-variable-accessor-naming-tp4818137.html > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://forum.world.st/class-variable-accessor-naming-tp4818137p4818431.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 9, 2015

Re: [Pharo-users] Opening SettingBrowser on custom settings

by Laura Risani

Mmmm, the second option takes for me a while to open, i'll try using the first option adding an argument to the pragma. On Wed, Apr 8, 2015 at 7:25 PM, Laura Risani <laura.risani(a)gmail.com> wrote: > Hi Alain , hi Nicolai, thank you for your answers. > In fact what i need is to parametrically show all settings i defined on a > package, so i'll do the second. > > > On Wed, Apr 8, 2015 at 6:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-04-08 18:34 GMT+02:00 Laura Risani <laura.risani(a)gmail.com>: >> >>> Hi all, >>> >>> Say that i wanted to open a SettingBrowser showing only the settings >>> defined by 'SystemSystemSettings class >> systemSettingOn:' . How could i >>> do that? >>> >>> There is a method 'SettingBrowser >> browse:' . Based on it's comment i >>> tried adding to systemSettingOn: the pragma <banana>, and then sending >>> ' SettingBrowser browse:#('banana') ' but it didn't work. >>> >> >> Most (all?) settings use the pragma <systemsettings>, that means you can >> not filter by the pragma keyword, to only get the settings for one >> subcategory in the default settings. >> But if the settings you want to display are all from one Package, you can >> browse only settings from that package: >> >> (SettingBrowser new setViewedPackageNames: 'Settings-System') >> open; >> expandAll >> >> >> >>> >>> Best, >>> Laura >>> >> >> >

April 8, 2015

Re: [Pharo-users] Opening SettingBrowser on custom settings

by Laura Risani

Hi Alain , hi Nicolai, thank you for your answers. In fact what i need is to parametrically show all settings i defined on a package, so i'll do the second. On Wed, Apr 8, 2015 at 6:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-08 18:34 GMT+02:00 Laura Risani <laura.risani(a)gmail.com>: > >> Hi all, >> >> Say that i wanted to open a SettingBrowser showing only the settings >> defined by 'SystemSystemSettings class >> systemSettingOn:' . How could i >> do that? >> >> There is a method 'SettingBrowser >> browse:' . Based on it's comment i >> tried adding to systemSettingOn: the pragma <banana>, and then sending ' SettingBrowser >> browse:#('banana') ' but it didn't work. >> > > Most (all?) settings use the pragma <systemsettings>, that means you can > not filter by the pragma keyword, to only get the settings for one > subcategory in the default settings. > But if the settings you want to display are all from one Package, you can > browse only settings from that package: > > (SettingBrowser new setViewedPackageNames: 'Settings-System') > open; > expandAll > > > >> >> Best, >> Laura >> > >

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Dale Henrichs

On 04/08/2015 12:47 PM, Thierry Goubier wrote: > Hi Dale, > > Le 08/04/2015 19:30, Dale Henrichs a Ã©crit : >> >> >> On 04/07/2015 10:24 PM, Thierry Goubier wrote: >>> Le 08/04/2015 02:05, Dale Henrichs a Ã©crit : >>> I have threatened in the past to add an option to a repository that >>> would eliminate the need to store monticello meta data ... Damien is >>> working on "starting from scratch" on the new format, because the >>> current implementation supports 4-5 different FileTree formats. >>> Damien's >>> work could be leveraged to add an "optional Monticello meta data" >>> option >>> to FileTree and if your SCM (like git) gives you per method history >>> with >>> the proper tools you can leverage that information.. >>> >>> I would say this could be a reasonable possibility, in that you could >>> have two modes of compatibility: >>> >>> - Complete filetree compatibility for gitfiletree: the current >>> situation, with properties and version written to disk. >>> >>> - Partial filetree compatibility, where that metadata isn't written >>> and you rely on gitfiletree to recreate it to export as .mcz. >>> >>> Partial compatibility has two effects, which need to be considered. >>> When using github:// or bitbucket:// urls, filetree will be used and >>> your packages will end up having no version number (except .1?), no >>> author, no timestamps for methods, etc... And the second one is that, >>> if you clone a mcz inside the gitfiletree repository, the mcz ancestry >>> of versions and author timestamps on methods will be lost, which is >>> something you may not want. >> Yes for Metacello some modifications would need to be made because in a >> normal mcz universe Metacello will not load a package if the version is >> older or the same as the one in the image ... and following in the >> tradition of other Monticello tools the UUID is ignored:( .. I was >> working with a pure cypress implementation and have written the >> Metacello code to support these repos ... > > Ok. > > Yes, the version number handling is delicate; even the one used by > gitfiletree feels unsatisfying, even if it allows Metacello/Monticello > to work as usual. The work I had done was at the Metacello level and is in the Metacello-Cypress package where I changed the load semantics to unconditionally load the package ... the snapshot comparison logic in play when loading packages is pretty good so it isn't necessarily a penalty to unconditionally compare snapshots when loading a package from FileTree ... > >> A better long term solution is to treat these as a CypressPackage or >> FileTreePackage which has some similarities to Monticello packages ... >> because faking out Monitcello version numbers and users is not much >> different than storing the metadata in FileTree ... > > Not sure I understand. I know where the Cypress/FileTree code handles > the lack of metadata when reading, that's all :) > >> But someone were to add those options to filetree, I think we could >> reduce the overall number of hacks:) > > Another solution I'd see possible is a reduced metadata format, where > just the version number of the current package is stored and retrieved > (i.e. a version file without ancestry). > > It would allow FileTree and Metacello to work exactly as usual. > > And, maybe, I could even unify the UUIDs? > > There are things in Monticello which needs a rethink to better adapt > to SCMs like git (or Fossil: it's so similar to git :) ) while keeping > more or less the same appearance: branches, hashes, tags and semantic > versionning. > > But I don't see yet how to handle that or to propose anything. > > I know that it would be great to reduce the cognitive distance between > MC version and history handling, and the same as seen from Metacello > baselines and configurations. Branches + baselines are doing a lot to > simplify, but MC stuff is unaware of that. And MC should delegate > merging to the underlying repository, as well. So this "extraneous" Monticello meta data is really related to the versioning aspects of the Monticello package ... aspects that really needed if you are using "git" (read "git" as svn, hg, git, fossil, etc.:) for version control .. in working with "git" the SHA of the commit for the repository as a whole is more important than any of the package meta data ... from the SHA one can see the commit comment for the "git" commit the SHA is related to a project not a package ... the project contents is represented by the BaselineOf ... in git one can reason about the collection of commits associated with a directory (package or class or method) and look at diffs at that level of granularity .... The primary point being that a "git" package can be stripped down to the basic list of definitions and the ancestry and version names and method properties can be dropped on the floor instead of fabricated ... What I imagine is a separate software stack for these "git" packages the commonality is at the snapshot/definition level and the core definitions can migrate between Monticello and "git" packages almost without change ... if one wanted to know the "history" of a package the Monticello package would answer back a representation of the ancestor graph, while the "git" package would answer back a representation of the commit history ... there would be different objects in the histories, since the meta data for extracting the useful bits varies considerably between the two package implementations, but from a tools perspective and arranging for a common tool-level api would be able to accommodate these two completely different packages as well as any number of package implementations that could wrap packages stored in the wide variety of SCMS floating around out there .... and those to come ... what the hell:) Well there's a year or so of work:) Dale

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Dale Henrichs

On 04/08/2015 01:11 AM, Thierry Goubier wrote: > > > 2015-04-08 8:47 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>>: > > I thnk that rather than focus on the disk format which I > hardly ever actually look at ... that folks should be looking > at tools support (like Thierry) ... this is where the real > work needs to happen ... good tools can hide the disk fomat > completely so why does the disk format matter ... > > I am personally not really a fan of this; I've been using git for > a while and I am perfectly content with using command line on the > disk (maybe I'm rare breed); I have yet to see a GUI/tool that > would come even close to the power of command line, but I've been > using Linux for a long time. > > > Agreed and this is in that spirit I did GitFileTree. Dale went a bit > further and even integrated the git command line access inside > smalltalk via CommandShell... so that you get the best of both worlds > without leaving your beloved Smalltalk :) Actually it is not quite CommandShell based ... the shell is tODE shell, where Smalltalk is the scripting language. The tODE git commands are implemented by parsing the command line args, resolving options and args to objects, and then calling a Smalltalk git command API that eventually does make shell calls (sometimes multiple git commands are folded into a single tODE git command ... thus making it possible to ultimately switch out the actual `git calls` and use something FFI-based, like libgit2... This approach also makes it quite feasible to write fairly complicated Smalltalk scripts that call the smalltalk git command api directly, bypassing the command line interface altogether ... > As I've said to Thierry some time ago in different thread, I would > be interested in idea of having everything on disk side and Pharo > would only somehow refresh it's content (just like a Java IDE / > text editor would). But that may be a lot o work so I can only > dream about it, as nobody has time for that (me included). > > > Well, as I said elsewhere, Smalltalk doesn't work like that: code has > to be lived in the image for most tools to work properly... it doesn't > really have an "editor of file" mindset, but an "object inspector" > mindset. > > What we're looking at in another thread is how to emulate that live > object approach over dead files, and, thinking of it, I'm not sure we > will succeed well. > > In short, what you want may never work properly because it is not how > it should be conceptualized. > In tODE I regularly drop off live objects to the file system using STON ... The tODE shell which allows you to navigate an object-based directory also allows you to mount the nodes from the file system and when traversing the file system recognizes STON files and presents objects to you instead of the dead files:) I haven't tried taking this approach all the way to source files ... but???? Dale

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Dale Henrichs

On 04/08/2015 04:23 AM, Sean P. DeNigris wrote: > Dale Henrichs-3 wrote > Dale Henrichs-3 wrote >> I am really pressed for time so I don't have the luxury to blue sky >> ideas ... > I understand. I was not suggesting anyone do anything. Also, I agree that > methods seem to be the proper level for SCM versioning as they are in the > Smalltalk image. I was simply asking, in light of the appearance that the > merge driver could seemingly ignore the changes to certain files while still > committing them with Git, if it would be feasible to add read-only > one-class-per files "for viewing on GitHub". This is more of a sanity check > to see if I understood what the merge driver makes possible. Sean, I think the issue becomes one of "so who makes sure the the readonly file matches the rest of the source" ... I do occasionally edit files directory with vi ... I do regularly merge in changes from GemStone and Squeak ... so any package with this kind of file has the potential to decay quickly unless the changes were made so that they'd work on the supported filetree platforms ... If you wanted to experiment, you could fork FileTree and try some experiments ... if they become something worth sharing, they could be merged into the master pharo branch ... Dale

April 8, 2015

Re: [Pharo-users] Opening SettingBrowser on custom settings

by Nicolai Hess

2015-04-08 18:34 GMT+02:00 Laura Risani <laura.risani(a)gmail.com>: > Hi all, > > Say that i wanted to open a SettingBrowser showing only the settings > defined by 'SystemSystemSettings class >> systemSettingOn:' . How could i > do that? > > There is a method 'SettingBrowser >> browse:' . Based on it's comment i > tried adding to systemSettingOn: the pragma <banana>, and then sending ' SettingBrowser > browse:#('banana') ' but it didn't work. > Most (all?) settings use the pragma <systemsettings>, that means you can not filter by the pragma keyword, to only get the settings for one subcategory in the default settings. But if the settings you want to display are all from one Package, you can browse only settings from that package: (SettingBrowser new setViewedPackageNames: 'Settings-System') open; expandAll > > Best, > Laura >

April 8, 2015

Re: [Pharo-users] Opening SettingBrowser on custom settings

by Alain Plantec

> Le 8 avr. 2015 Ã 18:34, Laura Risani <laura.risani(a)gmail.com> a Ã©crit : > > Hi all, > > Say that i wanted to open a SettingBrowser showing only the settings defined by 'SystemSystemSettings class >> systemSettingOn:' . How could i do that? > > There is a method 'SettingBrowser >> browse:' . Based on it's comment i tried adding to systemSettingOn: the pragma <banana>, and then sending ' SettingBrowser browse:#('banana') ' but it didn't work. Hello Laura, try this: SettingTreeBuilder>>banana <settingPragmaProcessor> "Process a <banana> pragma Â» "banana just works as a regular setting" ^ self systemsettings then define your banana settings: BananaSetting class>>myBananaSettingOn: aBuilder <banana> (aBuilder group: #Banana) then try: SettingBrowser browse: #('bananaâ) > > Best, > Laura

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Dale Henrichs

On 04/07/2015 11:47 PM, Peter UhnÃ¡k wrote: > > I thnk that rather than focus on the disk format which I hardly > ever actually look at ... that folks should be looking at tools > support (like Thierry) ... this is where the real work needs to > happen ... good tools can hide the disk fomat completely so why > does the disk format matter ... > > I am personally not really a fan of this; I've been using git for a > while and I am perfectly content with using command line on the disk > (maybe I'm rare breed); I have yet to see a GUI/tool that would come > even close to the power of command line, but I've been using Linux for > a long time. I understand and that is a tension point for FileTree ... the source _is_ on disk and you do use the GitHub tools (or any other git tools independent of those in Smalltalk) that give you a picture of everything that changed including the "ugly" meta data ... I flip around and use vi at times to edit a method and of course the github tools for pull requests. But then I use the tODE tools for working with git as well ... but as you recognize, the monticello meta data is there for compatibility and righ now at least compatibility is a good thing ... > As I've said to Thierry some time ago in different thread, I would be > interested in idea of having everything on disk side and Pharo would > only somehow refresh it's content (just like a Java IDE / text editor > would). But that may be a lot o work so I can only dream about it, as > nobody has time for that (me included). > > But to bottom line this thread (for me at least, because I'm getting > lost): > 1. methodProperties.json provide compatibility for FileTree, so I > don't want to get rid of it (for now) > 2. the large amount of file changes is probably a bug (I'll try to be > more observant about the commits in the future and hopefully some > pattern will emerge.) > 3. I shouldn't want to break things for now at least > 4. more people are starting to work on Git > 5. I need to learn about FileTree at some point if I want to > contribute and experiment with (my) ideas (which won't be soon as I'm > preparing for my finals) > All very good points Dale

April 8, 2015

Re: [Pharo-users] Metacello GIT methodProperties.json

by Thierry Goubier

Hi Dale, Le 08/04/2015 19:30, Dale Henrichs a Ã©crit : > > > On 04/07/2015 10:24 PM, Thierry Goubier wrote: >> Le 08/04/2015 02:05, Dale Henrichs a Ã©crit : >> I have threatened in the past to add an option to a repository that >> would eliminate the need to store monticello meta data ... Damien is >> working on "starting from scratch" on the new format, because the >> current implementation supports 4-5 different FileTree formats. Damien's >> work could be leveraged to add an "optional Monticello meta data" option >> to FileTree and if your SCM (like git) gives you per method history with >> the proper tools you can leverage that information.. >> >> I would say this could be a reasonable possibility, in that you could >> have two modes of compatibility: >> >> - Complete filetree compatibility for gitfiletree: the current >> situation, with properties and version written to disk. >> >> - Partial filetree compatibility, where that metadata isn't written >> and you rely on gitfiletree to recreate it to export as .mcz. >> >> Partial compatibility has two effects, which need to be considered. >> When using github:// or bitbucket:// urls, filetree will be used and >> your packages will end up having no version number (except .1?), no >> author, no timestamps for methods, etc... And the second one is that, >> if you clone a mcz inside the gitfiletree repository, the mcz ancestry >> of versions and author timestamps on methods will be lost, which is >> something you may not want. > Yes for Metacello some modifications would need to be made because in a > normal mcz universe Metacello will not load a package if the version is > older or the same as the one in the image ... and following in the > tradition of other Monticello tools the UUID is ignored:( .. I was > working with a pure cypress implementation and have written the > Metacello code to support these repos ... Ok. Yes, the version number handling is delicate; even the one used by gitfiletree feels unsatisfying, even if it allows Metacello/Monticello to work as usual. > A better long term solution is to treat these as a CypressPackage or > FileTreePackage which has some similarities to Monticello packages ... > because faking out Monitcello version numbers and users is not much > different than storing the metadata in FileTree ... Not sure I understand. I know where the Cypress/FileTree code handles the lack of metadata when reading, that's all :) > But someone were to add those options to filetree, I think we could > reduce the overall number of hacks:) Another solution I'd see possible is a reduced metadata format, where just the version number of the current package is stored and retrieved (i.e. a version file without ancestry). It would allow FileTree and Metacello to work exactly as usual. And, maybe, I could even unify the UUIDs? There are things in Monticello which needs a rethink to better adapt to SCMs like git (or Fossil: it's so similar to git :) ) while keeping more or less the same appearance: branches, hashes, tags and semantic versionning. But I don't see yet how to handle that or to propose anything. I know that it would be great to reduce the cognitive distance between MC version and history handling, and the same as seen from Metacello baselines and configurations. Branches + baselines are doing a lot to simplify, but MC stuff is unaware of that. And MC should delegate merging to the underlying repository, as well. Thierry

April 8, 2015