- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20182

by Marcus Denker

20182 ----- Issue 6259: DataStream is still there http://code.google.com/p/pharo/issues/detail?id=6259 Issue 6255: Zinc Pharo Conference update with FileSystem support http://code.google.com/p/pharo/issues/detail?id=6255 Issue 6223: FileLocator and FileRerernce have extension from File Package http://code.google.com/p/pharo/issues/detail?id=6223 -- Marcus Denker -- http://marcusdenker.de

July 4, 2012

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

by Camillo Bruni

Fernando be sure to get rid of all the old vms on OSX :P OSX is particularly good in finding an old version somewhere that does not properly work :P On 2012-07-04, at 10:54, Fernando Olivero wrote: > Yes, i'm using the latest. > > VM: https://ci.lille.inria.fr/pharo/job/Cog-VM/Architecture=32,OS=mac/58/ > > Sven, are you using Mac OSX ? > > Esteban replied that's a known bug, (unexisting file giving tue on > #exists) maybe its implied that'solely for the Mac ? > > I will do an unit test to capture this issue. > > Fernando

July 4, 2012

Re: [Pharo-project] Problem with FileSystem primitives in latest Pharo2.0

by Sean P. DeNigris

Fernando olivero-2 wrote > > FileSystem>>delete: aResolvable > aResolvable asFileReference exists ifTrue:[ store delete: (self > resolve: aResolvable) ] > Now that we have #ensureDelete, #delete should signal an error for a non-existent file -- View this message in context: http://forum.world.st/Problem-with-FileSystem-primitives-in-latest-Pharo2-0… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 4, 2012

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

by Damien Cassou

On Wed, Jul 4, 2012 at 4:08 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > 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 ? I was just saying that semantic patches already exist for text files so we don't have to reinvent the wheel. What we want, for sure, is that these files are generated automatically :-) -- 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] ohloh is sad

by Sean P. DeNigris

Norbert Hartl wrote > > To me it appears the main asset is that it checks contributions which it > can't do in our environment > ... until Dale releases git integration in the near future ;-) -- View this message in context: http://forum.world.st/ohloh-is-sad-tp4637961p4638190.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 4, 2012

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