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

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

Re: [Pharo-users] class variable accessor naming

by Jan B.

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 8, 2015

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

by Dale Henrichs

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 ... 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 ... But someone were to add those options to filetree, I think we could reduce the overall number of hacks:) Dale

April 8, 2015

Opening SettingBrowser on custom settings

by Laura Risani

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. Best, Laura

April 8, 2015

Re: [Pharo-users] GitHub Mirror Workflow

by Thierry Goubier

Le 08/04/2015 17:16, Stephan Eggermont a Ã©crit : > On 08/04/15 14:38, Esteban Lorenzano wrote: >> I donât know your problemâ¦ why would you want another format form >> mirroring? > > Because with packages the size of Roassal2 you might get rather unhappy > on a machine without an SSD. That is a lot of files. Nothing compared to the time needed to load Roassal into the image on that very same machine ;) Thierry

April 8, 2015

Re: [Pharo-users] String operations

by Norbert Hartl

> 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 8, 2015

Re: [Pharo-users] GitHub Mirror Workflow

by Sean P. DeNigris

EstebanLM wrote > why would you want another format form mirroring? For the case when one is only actually committing to e.g. StHub and then mirroring to GitHub for external visibility, the purpose is not served when a casual observer must drill down several levels to view each method individually. One-class-per-file would be better in that case (where no actual SCM is being done via Git). And if one was using Git, it would still be handy - for the same reason - to have a read-only one-class-per file handy for a quick perusal via GitHub ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-Mirror-Workflow-tp4810339p4818401.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 8, 2015

Re: [Pharo-users] ZnClient: getting more that 19 tweet for data scrapping

by Offray Vladimir Luna CÃ¡rdenas

Hi Paul and Sven, I will try Twitter API if is necessary, but I'm not trying to get support here on how to violate Twitter ToS. I'm pretty aware of them, but surely there are exceptions. The mail I shared with you (the one Paul point to) about why I would like to not use API but instead use scrapping doesn't go in details, it just said that it was because people who have not a twitter account or signed the ToS should be able to get some twitter info. That special kind of info is the one regarding public political/politicians discourse and my idea to scrap *public* and *specific* data from twitter happens in the context of a project for citizen oversight of political issues empowered by ICT. The project is discussed on detail here: https://www.newschallenge.org/challenge/elections/entries/datapolis-data-na… So, for the moment, I will get properly account permissions for getting twitter data, but my conviction for the long term is that public political discourse (among others), even the one that circulates on private networks like Twitter or Facebook, should be under Constitutional Terms (like free speech and wide political participation) and not under the restricted ones of Twitter or Facebook. This is a sensible issue and surely needs more talk, may be on another time, but I will follow your advice and extract data from Twitter API and come here with questions about it. Thanks for all your help and support, Offray El 08/04/15 a las 08:29, Paul DeBruicker escribiÃ³: > Offray - What Sven said is correct. You're not getting an answer about how > to violate their Terms of Service because this isn't that kind of place. > You've asked 3 times. Once is usually enough. Use the API. For the Soup > questions get an inspector on an instance of a SoupTag and start sending it > messages it understands and see what you get. Trial and error. Or read the > python Soup docs as the commands probably have an equivalent in the > Smalltalk library. Most of this programming stuff is reading, doing a > little experiment, thinking, then trying again. > > Sven - I only showed him that SoupTag has a #text message. I'm sure you're > busy and had forgotten that the first time he/she asked they stated that > they don't want to use the api: > http://forum.world.st/Data-scrapping-in-pharo-Extracting-tweets-contents-td… > and provided the download code in an ws.stfx.eu snippet. > > Hope this helps > > Paul > > > Sven Van Caekenberghe-2 wrote >> What Paul showed is basically just a hack. >> >> What you probably what is full API access to Twitter, that gives you the >> real thing, but it is more work and you have to understand all the >> technical details (unless somebody already did it for you, I don't know - >> I know that Zinc-SSO can connect to Twitter). >> >> https://dev.twitter.com/overview/api >> >>> On 07 Apr 2015, at 20:23, Offray Vladimir Luna CÃ¡rdenas < > >> offray@ > >> > wrote: >>> >>> Hi, >>> >>> Recently Paul DeBruicker taught me how to refine my code for getting >>> tweets properly. Consider this: >>> >>> =[1]==================================== >>> | source anUrl tweet | >>> >>> anUrl := 'https://twitter.com/offrayLC'. >>> source := Soup fromString: (ZnEasy get: anUrl ) contents asString. >>> tweets := (source findAllTagsByClass: 'ProfileTweet-text') collect:[:ea | >>> ea text]. >>> ======================================== >>> >>> Is working fine, but I would like to get more that 19 tweets, that is >>> what you get by default. There is any way to tell ZnEasy and friends to >>> get more tweets, something similar to what you do when you scroll down >>> into a twitter page? >>> >>> And by the way, I would like to make more sense of the Soup I got in the >>> last line. ea text gives me the tweet contents, but how can I interpret >>> the metadata in the soup? (is a retweet, date of publishing and so on). I >>> could make this for most part of the twitter profile page, but the tweet >>> is kind of elusive, for example how to know that "text" is the proper >>> message for getting the tweet content? Any pointer to how to make sense >>> of it by myself is greatly appreciated. >>> >>> Cheers, >>> >>> Offray >>> > > > > > > -- > View this message in context: http://forum.world.st/ZnClient-getting-more-that-19-tweet-for-data-scrappin… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 8, 2015