- Pharo-users - lists.pharo.org

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

by Thierry Goubier

Le 08/04/2015 02:05, Dale Henrichs a Ã©crit : > Peter, > > That looks like a bug in the FileTree writer ... wiht one method change > there should have been only one method property file change ... Yes, I'd agree. This is surprising. Unless you had been loading that package via another repository / another version / another branch before in the same image? MCMethodDefinition has a cache which consider equals methods with different timestamps, and, in that case, it would carry the timestamps of the previous version, and writing those upon save instead of the originals. > Peter and Sean, > > If you are interested in contributing code/bugfixes to FileTree, I will > welcome pull requests ... As I have mentioned in several posts today, I > do not have the time to fiddle with changes to the FileTree format > myself, but I welcome contributions. > > Damien has started work on an updated version of the FileTree format[2]. > > 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. Thierry > As I ranted in another post ... changing the disk format is the easy > part ... building and maintaining tools for the 4-5 different Smalltalk > dialects is a different matter ... > > Dale > > [1] https://github.com/dalehenrich/filetree/issues > [2] https://github.com/dalehenrich/filetree/issues/144 > On 04/07/2015 04:38 PM, Peter UhnÃ¡k wrote: >> Yeah, I do use the MergeDriver and it saved me a lot of headache, but >> when I see things like this >> >> https://github.com/dynacase/dynacase/commit/90141d63bfdd433e51a768c2191e035… >> >> where one five lines long method generated 14 file changes with 180 >> additions and 172 deletions... it makes the log on github and pull >> requests incredibly messy. >> >> I don't want to cut branch under myself if I were to remove the >> properties file. So my question now is: how hard would it be to >> regenerate those files? >> >> Or maybe if it was moved to some metadirectory. This reminds me a bit >> of svn which polluted the whole folder tree with .svn files everywhere. >> >> Peter >> >> >> >> On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris >> <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> >> Dale Henrichs-3 wrote >> > Personally I use >> > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never >> > think twice about the properties files ... >> >> Ooh, intriguing. In other to make it easier to view code on >> GitHub, I've >> been toying with the idea of generating one-class-per-file in >> addition to >> the regular gitfiletree files. Could this be used to make that >> possible >> without complicating Git? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… >> Sent from the Pharo Smalltalk Users mailing list archive at >> Nabble.com. >> >> >

April 8, 2015

Re: [Pharo-users] class variable accessor naming

by Christian Caldeiro

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(a)fit.cvut.cz> 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. > >

April 8, 2015

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

by Dale Henrichs

Sean, My mail may have been a bit harsh, so please read my reply to Peter ... where I think I take a bit more positive tack:) I am really pressed for time so I don't have the luxury to blue sky ideas ... but I will make the time to review any code contributions that folks have ... Dale On 04/07/2015 04:52 PM, Dale Henrichs wrote: > Sean, > > The primary reason that the method properties.json file exists is to > preserve the date and timestamp for monticello ... git doesn't need > this but, to be able to seamlessly copy monticello files from filetree > to mcz and back again without losing data the information has to be > stored somewhere ... a pure git repo does not need this information > and it can be eliminated, but you pay the price of cutting off mcz > file compatibility ... FileTree is agnostic as to the SCM being used > ... it is a disk format ... so it cannot leverage the meta data from > git ... if git is not used to manage the disk ... > > I appreciate the fact that folks are coming up with all sorts of ideas > ... but there are constraints as to what is done for FileTree ... > FileTree is supposed to be cross platform so changing disk formats is > not as easy as just writing some smalltalk code, unless you want to > write the smalltalk code for the 4 or 5 different Smalltalk dialects > that read/write FileTree ... > > Thierry has taken the approach of maintaining compatibility with > FileTree, which is a convenient thing to do ... convenient for all of > the folks that have been using Filetree for the last 3 years and have > been living with the limitations and patiently waiting for folks to > begin adoption ... > > the problem with patiently waiting is that I am very busy right now > and I do not have the time to fiddle with FileTree ... I know that a > number of you guys don't care about other platforms and don't care > about backwards compatibility ... but I do and I do not have the free > time to fiddle around with the fad of the moment ... > > 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 ... > > BTW, we had some major email wars several years ago and frankly I > don't have the time to justify decisions that were made 3 years ago > every 2 months .... > > Dale > > On 04/07/2015 04:14 PM, Sean P. DeNigris wrote: >> Dale Henrichs-3 wrote >>> Personally I use >>> https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never >>> think twice about the properties files ... >> Ooh, intriguing. In other to make it easier to view code on GitHub, I've >> been toying with the idea of generating one-class-per-file in >> addition to >> the regular gitfiletree files. Could this be used to make that possible >> without complicating Git? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… >> 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

Peter, That looks like a bug in the FileTree writer ... wiht one method change there should have been only one method property file change ... Peter and Sean, If you are interested in contributing code/bugfixes to FileTree, I will welcome pull requests ... As I have mentioned in several posts today, I do not have the time to fiddle with changes to the FileTree format myself, but I welcome contributions. Damien has started work on an updated version of the FileTree format[2]. 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.. As I ranted in another post ... changing the disk format is the easy part ... building and maintaining tools for the 4-5 different Smalltalk dialects is a different matter ... Dale [1] https://github.com/dalehenrich/filetree/issues [2] https://github.com/dalehenrich/filetree/issues/144 On 04/07/2015 04:38 PM, Peter UhnÃ¡k wrote: > Yeah, I do use the MergeDriver and it saved me a lot of headache, but > when I see things like this > > https://github.com/dynacase/dynacase/commit/90141d63bfdd433e51a768c2191e035… > > where one five lines long method generated 14 file changes with 180 > additions and 172 deletions... it makes the log on github and pull > requests incredibly messy. > > I don't want to cut branch under myself if I were to remove the > properties file. So my question now is: how hard would it be to > regenerate those files? > > Or maybe if it was moved to some metadirectory. This reminds me a bit > of svn which polluted the whole folder tree with .svn files everywhere. > > Peter > > > > On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Dale Henrichs-3 wrote > > Personally I use > > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never > > think twice about the properties files ... > > Ooh, intriguing. In other to make it easier to view code on > GitHub, I've > been toying with the idea of generating one-class-per-file in > addition to > the regular gitfiletree files. Could this be used to make that > possible > without complicating Git? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… > 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

Sean, The primary reason that the method properties.json file exists is to preserve the date and timestamp for monticello ... git doesn't need this but, to be able to seamlessly copy monticello files from filetree to mcz and back again without losing data the information has to be stored somewhere ... a pure git repo does not need this information and it can be eliminated, but you pay the price of cutting off mcz file compatibility ... FileTree is agnostic as to the SCM being used ... it is a disk format ... so it cannot leverage the meta data from git ... if git is not used to manage the disk ... I appreciate the fact that folks are coming up with all sorts of ideas ... but there are constraints as to what is done for FileTree ... FileTree is supposed to be cross platform so changing disk formats is not as easy as just writing some smalltalk code, unless you want to write the smalltalk code for the 4 or 5 different Smalltalk dialects that read/write FileTree ... Thierry has taken the approach of maintaining compatibility with FileTree, which is a convenient thing to do ... convenient for all of the folks that have been using Filetree for the last 3 years and have been living with the limitations and patiently waiting for folks to begin adoption ... the problem with patiently waiting is that I am very busy right now and I do not have the time to fiddle with FileTree ... I know that a number of you guys don't care about other platforms and don't care about backwards compatibility ... but I do and I do not have the free time to fiddle around with the fad of the moment ... 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 ... BTW, we had some major email wars several years ago and frankly I don't have the time to justify decisions that were made 3 years ago every 2 months .... Dale On 04/07/2015 04:14 PM, Sean P. DeNigris wrote: > Dale Henrichs-3 wrote >> Personally I use >> https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never >> think twice about the properties files ... > Ooh, intriguing. In other to make it easier to view code on GitHub, I've > been toying with the idea of generating one-class-per-file in addition to > the regular gitfiletree files. Could this be used to make that possible > without complicating Git? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 7, 2015

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

by Peter UhnÃ¡k

Yeah, I do use the MergeDriver and it saved me a lot of headache, but when I see things like this https://github.com/dynacase/dynacase/commit/90141d63bfdd433e51a768c2191e035… where one five lines long method generated 14 file changes with 180 additions and 172 deletions... it makes the log on github and pull requests incredibly messy. I don't want to cut branch under myself if I were to remove the properties file. So my question now is: how hard would it be to regenerate those files? Or maybe if it was moved to some metadirectory. This reminds me a bit of svn which polluted the whole folder tree with .svn files everywhere. Peter On Wed, Apr 8, 2015 at 1:14 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Dale Henrichs-3 wrote > > Personally I use > > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never > > think twice about the properties files ... > > Ooh, intriguing. In other to make it easier to view code on GitHub, I've > been toying with the idea of generating one-class-per-file in addition to > the regular gitfiletree files. Could this be used to make that possible > without complicating Git? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 7, 2015

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

by Sean P. DeNigris

Dale Henrichs-3 wrote > Personally I use > https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never > think twice about the properties files ... Ooh, intriguing. In other to make it easier to view code on GitHub, I've been toying with the idea of generating one-class-per-file in addition to the regular gitfiletree files. Could this be used to make that possible without complicating Git? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-GIT-methodProperties-json-tp4818097p4818233… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 7, 2015

Mapping graphs on a open street map

by Alexandre Bergel

Hi! Several times we were asked how to map chart and graph on top of a geographical map. Here is a short example. Hope it is useful to someone. http://ws.stfx.eu/11NOBLH3SIYO <http://ws.stfx.eu/11NOBLH3SIYO> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= v := RTView new. map := RTOSM new. e := map element. v add: e. paris := 48.8567 @ 2.3508. newyork := 40.7127 @ -74.0059. london := 51.507222@ -0.1275. v @ RTDraggableView. data := { { paris . { 10 . 5 . 10 . 3 . 10 .6 . 8 } }. {london . { 5 . 3 .3 . -5 } } . {newyork . { 5 . -2 . 10 . 15 . -10 }} }. data do: [ :tupple | | grapher dataSet | grapher := RTGrapher new. grapher extent: 150 @ 100. dataSet := RTStackedDataSet new points: tupple second. dataSet barShape width: 10; color: Color red. grapher add: dataSet. grapher axisY. grapher axisX noLabel; noTick. grapher build. allGraphElements := grapher view elements. v addAll: allGraphElements. allGraphElements translateTo: (map latLonToRoassal: tupple first) ]. v canvas camera translateTo: (map latLonToRoassal: paris). v canvas camera noInitializationWhenOpen. v canvas camera scale: 0.1. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2015

happy easter :-)

by Alexandre Bergel

A few days late :-) http://ws.stfx.eu/B8D2V8TO8BIE <http://ws.stfx.eu/B8D2V8TO8BIE> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2015

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

by Dale Henrichs

and if we remove the method properties from FileTree, then the monticello files stored there could not be transparently copied into and out of a FileTree repo ... and FileTree is SCM neutral ... Personally I use https://github.com/ThierryGoubier/GitFileTree-MergeDriver and never think twice about the properties files ... Dale On 04/07/2015 08:48 AM, Thierry Goubier wrote: > Hi Peter, > > Le 07/04/2015 17:39, Peter UhnÃ¡k a Ã©crit : >> Hi, >> >> are "methodProperties.json" files needed? > > No. > >> Every time someone makes even small changes it is accompanied by ten >> times more json file changes which is a mess. > > Yes, it creates quite some noise on the git logs and diffs. > >> So is it needed with git? Cannot the information be retrieved from git >> commits? > > It is not needed for git. > > GitFileTree retrieves the information via the git logs. > > But, if we remove it entirely, then the repository won't be usable by > filetree. So GitFileTree keeps writing that metadata to stay compatible. > > Thierry >

April 7, 2015