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

Re: [Pharo-project] renggli mirror created on smalltalkhub

by StÃ©phane Ducasse

Guys I'm sorry to tell you that but I personally do not have 5 min of energy for GIT for pharo 2.0 I want to focus my energy on finishing the tasks we decided a while ago. Personally a working Squeaksource is good enough for now. Stef

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Esteban Lorenzano

On Jul 4, 2012, at 4:02 PM, Goubier Thierry wrote: > Le 04/07/2012 15:40, Camillo Bruni a Ã©crit : >> >> On 2012-07-04, at 15:34, Dennis Schetinin wrote: >> >>> "MC is not good enough" and "We should use Git" are a bit different thoughts. >> >> MC's model of versioning stuff / changes representation is fairly ok > >> However everything that leaves the image is deadly broken :D >> So the main issue here is the MC backends which are horribly inefficient and >> do not scale very well. >> >> Then there are of course issues in the image itself: >> - a merge browser that doesn't allow me to merge manually (that has to be improved) >> - a complete parallel structure for describing methods / classes ... >> - UI tools that literally are from the last century >> >>> If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why. >> >> Git is a storage mechanism which scales and opens up smalltalk to people which >> don't like images. > > Would it really opens up Smalltalk to people which don't like images ? Should Pharo be like Eclipse then ? > > Each time I come back to Smalltalk (and it happened me a few times over the last, what, 15 years) I do feel like coming back to the future : no more mess of long, unmanageable source files, a well structured code model (and adequate GUI, even if it looks old, but this is a lot a matter of finish). And on that, the feeling of performance given by Pharo (ah! instant startup times) is great, thanks. > > Writing thousands of lines of C code under a mess of files, headers, dependencies, bad or overly complex source code management systems (cvs, svn, git), bad, messy and not-working package and build systems (autoconf, maven, make, cmake, shell scripts, python scripts, perl scripts, you name it!), a hundred different editors all missing one feature you really like, and you want to drag me back into that ? > > Sorry, but I don't think I want that. +100 > > A MC backend which would allow me to use a git central repository without touching one line of git, yes. amen (but it *does not* has to be MC... just an equivalent tool) > > Remember that some programmers are using tools such as bazaar to work with git repos so that they don't have to deal with git directly. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > >

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Goubier Thierry

Le 04/07/2012 15:58, Damien Cassou a Ã©crit : > On Wed, Jul 4, 2012 at 3:54 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: >> I think of storing objects that represent operations I applied to my >> program: an ivar was renamed, a piece of code was extracted as a method, a >> method was moved to another class, etc. And those *live objects* can have a >> behavior that allows them to be applied to another program. This way I can >> think of applying other users' modifications to the code I've already >> modified: e.g., I've just renamed the same ivar (among other changes I don't >> want to loose), but the name my coworker invented was better and I want to >> apply that *particular* change. > > you have semantic patches for that. See coccinelle > http://coccinelle.lip6.fr/sp.php Have you really tried to write patches in Smpl for Coccinelle to say that ? Smpl is great, but for a broken developement model. How do you think you manage conditional code (#ifdef and friends) with tools like that ? It's a lot easier to do semantic actions on source code when you have a nice semantic layer on top of it (as Smalltalk provides). I don't think you will find equivalents. You will find work-arounds on text-based systems which may fit. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 4, 2012

Re: [Pharo-project] Reify Changes file?

by Eliot Miranda

On Mon, Jul 2, 2012 at 3:14 AM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > What if we remove the changes logging from SmalltalkImage and make it part > of a ChangesLog object? I'm looking at some SystemChangeNotifier > subscription ashes, and this could fix two things in one shot :) > How will you do crash recovery? -- best, Eliot

July 4, 2012

[Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)

by Torsten Bergmann

Friedrich Dominicus wrote >Another stuff I simply do not get is package-cache. Why is it local to >every other Pharo image? Why can't I say drop all below package-cache on >my machine that's it. Usually one pharo installation does not know about the other if you just unzip. So the cache is by default relative to the installation. Thats the same in Eclipse and other IDE's. If you want you can set a common directory for all images using MCCacheRepository>>default: Since it would be better to have a setting in the Settings browser I opened http://code.google.com/p/pharo/issues/detail?id=6260 and fixed it for Pharo 2.0 in SLICE-Issue-6260-Monticello-cache-location-should-be-configurable-tbn.1 Please test on different patforms for integration. Thx T.

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Goubier Thierry

Le 04/07/2012 15:40, Camillo Bruni a Ã©crit : > > On 2012-07-04, at 15:34, Dennis Schetinin wrote: > >> "MC is not good enough" and "We should use Git" are a bit different thoughts. > > MC's model of versioning stuff / changes representation is fairly ok > However everything that leaves the image is deadly broken :D > So the main issue here is the MC backends which are horribly inefficient and > do not scale very well. > > Then there are of course issues in the image itself: > - a merge browser that doesn't allow me to merge manually (that has to be improved) > - a complete parallel structure for describing methods / classes ... > - UI tools that literally are from the last century > >> If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why. > > Git is a storage mechanism which scales and opens up smalltalk to people which > don't like images. Would it really opens up Smalltalk to people which don't like images ? Should Pharo be like Eclipse then ? Each time I come back to Smalltalk (and it happened me a few times over the last, what, 15 years) I do feel like coming back to the future : no more mess of long, unmanageable source files, a well structured code model (and adequate GUI, even if it looks old, but this is a lot a matter of finish). And on that, the feeling of performance given by Pharo (ah! instant startup times) is great, thanks. Writing thousands of lines of C code under a mess of files, headers, dependencies, bad or overly complex source code management systems (cvs, svn, git), bad, messy and not-working package and build systems (autoconf, maven, make, cmake, shell scripts, python scripts, perl scripts, you name it!), a hundred different editors all missing one feature you really like, and you want to drag me back into that ? Sorry, but I don't think I want that. A MC backend which would allow me to use a git central repository without touching one line of git, yes. Remember that some programmers are using tools such as bazaar to work with git repos so that they don't have to deal with git directly. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Damien Cassou

On Wed, Jul 4, 2012 at 3:54 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > I think of storing objects that represent operations I applied to my > program: an ivar was renamed, a piece of code was extracted as a method, a > method was moved to another class, etc. And those *live objects* can have a > behavior that allows them to be applied to another program. This way I can > think of applying other users' modifications to the code I've already > modified: e.g., I've just renamed the same ivar (among other changes I don't > want to loose), but the name my coworker invented was better and I want to > apply that *particular* change. you have semantic patches for that. See coccinelle http://coccinelle.lip6.fr/sp.php -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Esteban Lorenzano

be my guess :) If you can propose and do a new one, be sure that we all going to use what is better... problem is that our time (all of us, including, I suppose, you) is scarce... and then, what we need is to adopt the best solution with our possibilities, and that might not be the "perfect" solution, because otherwise we will take years until we finish anything. Also... all tools can be improved up to a point... if for improve MC you need to change everything... then is easier to start from scratch. That's the life-cycle of everything, including software :) I ask again... what do you see in MC that cannot be done (with proper image-side tools) with Git, Mercurial, Darcs, etc.? best, Esteban ps: I can tell you something that cannot be handled with text based systems (and also not with MC), and would be possible in a object source manager: Refactor versioning. On Jul 4, 2012, at 3:34 PM, Dennis Schetinin wrote: > "MC is not good enough" and "We should use Git" are a bit different thoughts. If MC is not good enough we should improve it or create better tools, but (for me) Git seems to be a wrong direction for that. I've tried to explain in another message why. > > > Best regards, > Dennis Schetinin > Sent with Sparrow > > On Wednesday, 4 July 2012 Ð³. at 16:17, Esteban Lorenzano wrote: > >> Hi, >> >> No, what is wrong is considering monticello itself an object oriented control management system. Right now MC does not provides anything that can be thought as that... even more, MC does not provides anything better than current CMS around... >> So, what we have now is an old CMS, and a lot of tools trying to be compatible with that old system. Imagine if GIT would tried to be compatible with CVS... and to create an object control management is a considerable effort, no one want to do, and probably pointless... at least right now. >> >> best, >> Esteban >> >> >> On Jul 4, 2012, at 2:09 PM, Dennis Schetinin wrote: >> >>> Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a give up on hopes for a real object-oriented source control/management as it could and should be in Smalltalk? >>> >>> Best regards, >>> Dennis Schetinin >>> Sent with Sparrow >>> >>> On Wednesday, 4 July 2012 Ð³. at 16:02, Sven Van Caekenberghe wrote: >>> >>>> >>>> On 04 Jul 2012, at 13:50, phil(a)highoctane.be wrote: >>>> >>>>> I am using Mercurial for all of the other projects and technologies. >>>>> >>>>> With a full copy of everything locally, it helps indeed when we get crashes... >>>>> >>>>> But GIT/Hg isn't giving you the change sorter. >>>> >>>> I have used/tried FileTree/Git(hub) a bit and it is cool and it works. >>>> But I do miss (tools) integration in the image. >>>> The workflow also changes a bit, it is no longer all Smalltalk. >>>> >>>> IMHO it is not yet quite ready. >>>> >>>> Sven >>> >> >

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Dennis Schetinin

> What can you do else than storing text? > > I think of storing objects that represent operations I applied to my program: an ivar was renamed, a piece of code was extracted as a method, a method was moved to another class, etc. And those *live objects* can have a behavior that allows them to be applied to another program. This way I can think of applying other users' modifications to the code I've already modified: e.g., I've just renamed the same ivar (among other changes I don't want to loose), but the name my coworker invented was better and I want to apply that *particular* change. In short, I would like to avoid treating source code as a text (which is just one possible way of representation) and keep it as live objects. Does it sound absolutely incapable? Best regards, Dennis Schetinin Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 4 July 2012 Ð³. at 17:37, Camillo Bruni wrote: > > On 2012-07-04, at 15:30, Dennis Schetinin wrote: > > > On Wednesday, 4 July 2012 Ð³. at 16:11, Damien Cassou wrote: > > > On Wed, Jul 4, 2012 at 2:09 PM, Dennis Schetinin <chaetal(a)gmail.com (mailto:chaetal@gmail.com)> wrote: > > > > Am I wrong considering migration to Git-or-AnythingElseTextOriented to be a > > > > give up on hopes for a real object-oriented source control/management as it > > > > could and should be in Smalltalk? > > > > > > > > > > > > > > > > can you think of any feature we could have now we couldn't with Git? > > I didn't say "now", I talked about "hopes". E.g. hopes for "Source" Control Tool being aware of refactorings and other *operations* I apply to my program, instead of treating it as a plain text with some changes of unknown nature. I'm not sure it's possible right now (I know it's not, better to say?). But with a Smalltalk-based source control we can have it on one splendid day in the future. And I think on the Git way we'll finish with just some advanced text-comparison algorithms. No? > > > > > that has nothing to do with versioning per se. > > You can always hook in a different merger for git (that's already a built in feature) > which simply redirects over a Pharo image and applies some more ST logic there. > > Going for something that is even more st specific is a waste of time IMO. > What can you do else than storing text? ASTs? besides being incompatible > with the whole world of text editable things you won't win much :/. Besides > source code is quite a compact representation of ast's itself... > > cami

July 4, 2012

Re: [Pharo-project] renggli mirror created on smalltalkhub

by Esteban Lorenzano

this does not works anymore in Mac because Camillo changed to match the Mac standards. The new default directory is: ~/Library/Preferences/pharo best, Esteban On Jul 4, 2012, at 3:28 PM, Damien Cassou wrote: > On Wed, Jul 4, 2012 at 3:13 PM, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > > Another stuff I simply do not get is package-cache. Why is it local to > > every other Pharo image? Why can't I say drop all below package-cache on > > my machine that's it. I do not know how many copies I have around here > > with the same "information". I can not see why this should make sens in > > the "standard" case.... > > http://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s… > http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/ > > Add this to ~/.config/pharo/2.0/monticello.st > > StartupLoader default executeAtomicItems: { > StartupAction name: 'Monticello related stuff' code: [| sharedPackageCacheDirectory | > FileStream stdout lf; nextPutAll: 'Executing Monticello related stuff'; lf. > sharedPackageCacheDirectory := (FileDirectory on: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX') > assureExistence; yourself. > MCCacheRepository default directory: sharedPackageCacheDirectory. > MCDirectoryRepository defaultDirectoryName: 'XXXXXXX PATH TO GLOBAL CACHE XXXXXXXX'. > (MCRepositoryGroup default repositories > select: [:each | (each isKindOf: MCHttpRepository) > and: [(each locationWithTrailingSlash > includesSubString: 'www.squeaksource.com') > or: [each locationWithTrailingSlash > includesSubString: 'http://ss3.gemstone.com/ss/']]]) > do: [:each | each user: 'XXXXXXXXXXXXX'; password: 'XXXXXXXXXXXX']. > FileStream stdout lf; nextPutAll: 'Finished'; lf]. > }. > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 4, 2012