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

Re: [Pharo-project] MCWorkingCopy>>#uniqueVersionName

by Lukas Renggli

>> Would it not be possible to assign the version name based on local, best effort knowledge alone and deal with possible conflicts afterwards (there is the ancestory) ? > > to me that would make more sense. > > - Is it necessary that the version name is globally unique? I doubt so. > - Having it unique per repository should be enough, no? Ironically this proposition would make some Monticello operations slower, because Monticello will need to download and open all versions with the same name to figure out if the ancestry matches. Furthermore, this would subtly break many tools, because most of them do not look at the ancestry but only at the filename (again to make it fast). Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 30, 2012

Re: [Pharo-project] pier2 loaded successfully on Pharo 1.4

by Edgar J. De Cleene

On 1/29/12 6:44 PM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi, > > with seaside 3.0 fixed (as I send in another mail), I can report that pier2 > loads and runs out of the box on pharo 1.4 > > best, > Esteban Esteban podes compartir esa imagen con nosotros? De donde se puede descargar ? Edgar

Jan. 30, 2012

Re: [Pharo-project] Block explained continued

by Edgar J. De Cleene

On 1/29/12 2:52 PM, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > > but I'm not finished. Enjoying the work in progress. Thanks > There are points I want to really understand. > > Well, also I :=) Edgar

Jan. 30, 2012

Re: [Pharo-project] [Moose-dev] Re: browsers vs. guis

by Tudor Girba

Hi, Well, you can customize the UI. There are two ways: 1. Directly embed a widget from the UI framework. For example, in Morphic, you can simply embed a morph. For example, see GLMBasicExample>>starBrowser for a demo in which we embed various system browsers in a Glamour browser. Or here: http://www.themoosebook.org/book/internals/glamour/presentations/custom However, up to now, we mostly only use this solution for situations in which the data only arrives in the custom morph. We still need to add the ability of specifying how data should go out of the morph and into the surrounding Glamour pane so that it can be completely embedded in the overall data flow. 2. Extend Presentations with your own widget. This involves, subclassing GLMPresentation, and writing the rendering code. This requires knowledge about the inner workings on Glamour. Cheers, Doru On 30 Jan 2012, at 03:59, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > > El sÃ¡b 28 ene 2012 17:52:38 COT, Igor Stasenko escribiÃ³: >> Nice post. >> Still, we want a data-flow browser + being able to control/customize UIs :) >> Sure, this is veeeery hard to achieve. > > As a total newbie, I believe that this Igor's idea would be what one is looking for and the question is if there is a way to do it keeping the minimal syntax of Glamour... just wondering. > > Cheers, > > Offray > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Obvious things are difficult to teach."

Jan. 30, 2012

[Pharo-project] Another video tutorial

by Lawson English

Latest squeak tutorial. Connectors how-to: http://www.youtube.com/watch?v=H1LveflchAU as an aside, it seems to me that Connectors should be ported back to Pharo, because it can be very useful I am finding. Lawson

Jan. 30, 2012

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by Camillo Bruni

I extended the HOWTOBUILD in the blessed repository. For me cd build export CC='/usr/bin/gcc-4.2' # as of 10.7 llvm is the incompatible default compiler export MACOSX_DEPLOYMENT_TARGET=10.5 cmake . make worked. And yeah, I wouldn't symlink it either :) too bad that we can't use clang/llvm yet for the compilation. The error handling is so much better than in gcc :P best cami On 2012-01-29, at 22:06, Esteban Lorenzano wrote: > maybe, but he can restore default gcc after trying. I asked for removing a symlink, not the llvm compiler it self. > Right now I do not have a better/faster way to doit... and he needs to compile his vm, so... > > > El 29/01/2012, a las 6:00p.m., Stefan Marr escribiÃ³: > >> >> On 29 Jan 2012, at 21:09, Esteban Lorenzano wrote: >> >>> he... connection problems... yeah, I know a lot about them :) >>> >>> well... after a successful install, I *think* you should have gcc and gcc-4.2... last one is also a symlink who points to: >>> >>> /usr/bin/i686-apple-darwin11-gcc-4.2.1 >> >> We have seen GCC 4.2 disappearing after Lion upgrades and Xcode 4.2 installs. >> >> And Esteban, I do not think that changing the systems default compiler just for a single program can be the recommended practice. >> >> "sudo rm /usr/bin/gcc" is certainly only the very last resort. >> It should not be advertised if there are other ways to use a supported compiler. >> Camillo mentioned that setting the CC environment variables correctly worked for him. >> >> >> ... sudo - With great power comes great responsibility ... >> >> Best regards >> Stefan >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > >

Jan. 30, 2012

Re: [Pharo-project] MCWorkingCopy>>#uniqueVersionName

by Camillo Bruni

Last week I noticed the same behavior... not really such a big fan of it On 2012-01-29, at 20:05, Sven Van Caekenberghe wrote: > Today I pressed Command-. while looking at a slow Monticello save, I was wondering what the system was doing before I even had written my commit message. > > Apparently, MCWorkingCopy>>#uniqueVersionName checks every repository linked to the package, (6 for Zn in my case), to see if the proposed version name is unique across all these repositories, not using the cache. > > I understand this, but this comes down to 6 times getting the list of all package names from remote servers. > > One way to speed this up would be to parallelize these. I guess that could be done with very little effort. > But fundamentally, I thought Monticello was supposed to be a distributed version control system ? > > Would it not be possible to assign the version name based on local, best effort knowledge alone and deal with possible conflicts afterwards (there is the ancestory) ? to me that would make more sense. - Is it necessary that the version name is globally unique? I doubt so. - Having it unique per repository should be enough, no? > Just thinking out loud. > > Sven

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Benjamin

It appears that something got really wrong about Metacello. I am not able to load the #stable version of ConfigurationOfRPackage by example, the mechanism to retrieve symbolic versions seems broken Ben On Jan 29, 2012, at 11:50 PM, Marcus Denker wrote: > 14298 > ----- > > Issue 5220: MenuRegistration do not allow menu with more than 2 levels of deapth > http://code.google.com/p/pharo/issues/detail?id=5220 > Issue 5222: mc slowdown with big package-cache > http://code.google.com/p/pharo/issues/detail?id=5222 > Issue 5182: Problem in PluggableListMorph > http://code.google.com/p/pharo/issues/detail?id=5182 > > -- > Marcus Denker -- http://marcusdenker.de > >

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Benjamin

It seems there is a problem with Metacello which take down half of Jenkins projects ... I got this error: "'retry with alternate repository failed: ''FileExistsException: ''''/Users/benjamin/Images/Pharo 1.4/Pharo-1.4 2/package-cache/Metacello-Base-DaleHenrichs.19.mcz'''''''" Ben On Jan 29, 2012, at 11:50 PM, Marcus Denker wrote: > 14298 > ----- > > Issue 5220: MenuRegistration do not allow menu with more than 2 levels of deapth > http://code.google.com/p/pharo/issues/detail?id=5220 > Issue 5222: mc slowdown with big package-cache > http://code.google.com/p/pharo/issues/detail?id=5222 > Issue 5182: Problem in PluggableListMorph > http://code.google.com/p/pharo/issues/detail?id=5182 > > -- > Marcus Denker -- http://marcusdenker.de > >

Jan. 30, 2012

[Pharo-project] Future of SCM (was Re: [squeak-dev] Re: [Smalltalk for small projects only?)

by GÃ¶ran Krampe

Hi all! I held a presentation regarding SCM in general a few weeks back as part of a course and in that presentation I try to end it with a view ahead about what is the Next Step for SCM. So let me go "dreaming" here for a minute. :) As many in this thread has correctly identified the main "issue" with SCM is that when several developers work on the *same* codebase in parallell it gets hairy, no matter which tool you use. Most open source projects actually do *not* do that, we normally work on smallish *different* packages or just a few people on the same package - so we normally don't get to feel the real *hurt* that a large commercial project often does. At least that is my perception. Yes, MC and git are great. Darcs is in some respects even greater in this particular area (merging, cherry picking etc). But these tools do not capture what I like to call "developer intent" very good. git and Darcs etc just manage files, they don't even know what language we are using. Darcs has something in the "right direction" and that is the token replace change, which is a small step towards "smarter change types". MC knows it is Smalltalk source it is dealing with, but doesn't really use that knowledge as much as it could. Deltas that I started working with (and came quite far with the help of Matthew Fulmer and a few others) goes a few steps further. A Delta distinguishes developer intent in greater detail than MC and could potentially be "smarter" because of that. And this is where the general future of SCM lies I think, in two areas: - Making SCM tools aware of developer intent. If I use RB to do a refactoring for example, why not *record that* and not just record the effects of the recactoring on the source code? If I rename a method in a class, and fix all senders of it, why not record it as a *method rename*? That way, if it is merged into another environment it can be handled much smarter and we could for example fix even more senders. - Real time collaboration. If we can sit in a shared (in some controlled fashion) development environment in some kind of real time model, then lots of merging and conflicts would just say PUFF and go up in smoke. We are beginning to see this now with the new IDEs running "on the web" because suddenly it gets very natural to experiment in that direction. regards, GÃ¶ran

Jan. 29, 2012