April 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] String operations

by Sean P. DeNigris

Damien Pollet-2 wrote > Indeed, there is much to say about the String API :) > Thanks for mentioning this, I'm gathering missing behavior like this ! It seems unanimous that we should add these. I agree that they are useful in some cases. However, strings are so general that IMHO there are infinite such operations that we could add. Already "String methodDict size = 333", and one can't depend on method protocols to sort things out because they are hijacked for package extensions, so it's easy to be fooled by thinking "let me check the converting protocol for that" and (maybe) finding out later that you missed it because #asXyz is in *OtherPackage, which now forces you to manually scroll through 333 methods to make sure your desired message hasn't been implemented. So I'm not saying "don't add them". I just want to have a conversation about: 1. How often would these be needed? (We should have that conversation about most of String's methods) 2. Do we have any plans for real protocols, with the concepts of privacy and package extension extracted into other objects where they belong? 3. In the mean time, what is a reasonable cognitive limit for an API? For me 333 is way beyond comprehension with the current tooling, crippled somewhat by #2. ----- Cheers, Sean -- View this message in context: http://forum.world.st/String-operations-tp4817803p4818540.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

GT: Pasting a PrintIt

by Sean P. DeNigris

"cmd-p then [Enter]" copy/pastes the PrintIt into the underlying editor... Cool! I don't need it often, but that's very convenient. Thanks, Moose team :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/GT-Pasting-a-PrintIt-tp4818537.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

Re: [Pharo-users] String operations

by Damien Pollet

Indeed, there is much to say about the String API :) Thanks for mentioning this, I'm gathering missing behavior like this ! On 8 April 2015 at 17:56, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 07.04.2015 um 21:31 schrieb Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > > 'BormParticipant' allButFirst: 4 > > ('BormParticipant' splitOn: 'Borm') last > > Thank you both, this will work. :) > > In the Moose configuration, there is a CollectionExtensions that allows >> you to do this: >> 'BormParticipant' removePrefix: 'Borm' "-> 'Participant'". >> 'BormParticipant' removeSuffix: 'Participant' "-> 'Borm'" >> >> For Pharo 5, we should move these extensions to Pharo. >> >> Isn't it the case that a remove* methods mostly return what has been >> removed? Wouldn't be >> >> withoutPrefix: >> withoutSuffix: >> > I guess withoutPrefix: would probably makes more sense. > > As well as > > allButPrefix: > allButSuffix: > > but to me the sound of them is weird. > > Norbert > >

April 9, 2015

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