March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] added Pharogenesis to the book

by Mariano Martinez Peck

Excellent. Thanks. You can also add a link to http://scg.unibe.ch/research/Pharogenesis cheers mariano On Sun, Mar 20, 2011 at 4:50 PM, Max Leske <maxleske(a)gmail.com> wrote: > I added Pharogenesis to the collaborative book as suggested by Mariano. I > wasn't quite sure into which category to put it. For now its in "Developer > Tools". > Let me know if the entry is ok. > > Cheers, > Max >

March 20, 2011

Re: [Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Updates: Cc: laurent....(a)gmail.com Comment #2 on issue 3830 by marcus.d...(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 (No comment was entered for this change.)

March 20, 2011

Re: [Pharo-project] [ANN] More on Keymappings

by Camillo Bruni

The keymapping framework is already close to be completely rewritten. Most tests work (except for 3). Half of the methods are gone and the event matching works directly on Event level, no more evil string matching. I'll ping as soon as the rest of the tests work properly. camillo On 2011-03-19, at 13:37, Mariano Martinez Peck wrote: > Add keymappings to > > http://book.pharo-project.org/book/PharoTools/ I will add it as soon as the cleanup is complete and all tests work again :).

March 20, 2011

Re: [Pharo-project] [UPD] NativeBoost runs on new Cog VMs

by Tudor Girba

Exciting :) Cheers, Doru On 20 Mar 2011, at 12:51, Igor Stasenko wrote: > Hello, > i just wanna to inform you that i adopted NativeBoost plugin for > building with latest Cog vms. > > To build VM, you should have an image with VMMaker + CMakeVMMaker > packages installed. > > Then load NBIntaller package and do: > NBInstaller installCogPlugin > > There are new cmake configurations i added to build VMs with NB plugin support. > > So, simply do as usual: > <NB config name> generateWithSources > > and then cmake. / make > > P.S. Im happy knowing that the OpenGL fonts rendering demo, which i > made almost a year ago works out of the box on Windoze :) > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

March 20, 2011

Re: [Pharo-project] [squeak-dev] [UPD] NativeBoost runs on new Cog VMs

by Eliot Miranda

Hi Igor, On Sun, Mar 20, 2011 at 4:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > i just wanna to inform you that i adopted NativeBoost plugin for > building with latest Cog vms. > great news. What was involved in making it work on the Cog JITs? > > To build VM, you should have an image with VMMaker + CMakeVMMaker > packages installed. > > Then load NBIntaller package and do: > NBInstaller installCogPlugin > > There are new cmake configurations i added to build VMs with NB plugin > support. > > So, simply do as usual: > <NB config name> generateWithSources > > and then cmake. / make > > P.S. Im happy knowing that the OpenGL fonts rendering demo, which i > made almost a year ago works out of the box on Windoze :) > > -- > Best regards, > Igor Stasenko AKA sig. > >

March 20, 2011

Re: [Pharo-project] Issue 3830 in pharo: [Failing Test] Autotes TestHitCounter.testHitCountIncrements

by pharo＠googlecode.com

Comment #1 on issue 3830 by marcus.d...(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 The test fails when executing the whole AutotestTestHitCounter, succeeds when running it alone. But really: Why did the code change that we load in 1.2? Did someone change something? I really don't understand how the Pharo Full image is build and especicially how we can make sure that we do something that is reproducable and does not change randomly.

March 20, 2011

Re: [Pharo-project] Issue 3831 in pharo: 1.2 full image workspace has description on how to load O2

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3831 by marcus.d...(a)gmail.com: 1.2 full image workspace has description on how to load O2 http://code.google.com/p/pharo/issues/detail?id=3831 I added ImageForDevelopers-pharo-MarcusDenker.253.mcz No idea how to tell Metacello to pick this up, though... (there seem to be no version specified in the config? So I guess this just loads the latest?)

March 20, 2011

Re: [Pharo-project] need your attention: Package

by Dale Henrichs

On Mar 19, 2011, at 2:18 PM, StÃ©phane Ducasse wrote: > > On Mar 19, 2011, at 5:35 PM, Dale Henrichs wrote: > >> Stef, >> >> I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. > > No this is not a problem, because we can save the package with the * notation and category even if we do not need that. ........... > > Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes. Stef, Over the long haul I would agree that migration to the newer model is a good idea and gemstone could install the code (when tool support becomes available in GemStone) and as long as there is a transition period where RPackage isn't _required_, then I think that things can work smoothly... Dale

March 20, 2011

Re: [Pharo-project] need your attention: Package

by Dale Henrichs

Makes sense to me ... Dale On Mar 19, 2011, at 2:55 PM, Tudor Girba wrote: > Hi Stef, > > Thanks a lot for all this effort. > > I will reiterate again the original idea, which I still believe would work best. > > RPackage is meant to become the organization entity in the image. MCPackage will still be needed for versioning. Furthermore, for a while, categories will still remain in the system for a while as an implementation detail. RPackages mirror each category. > > The first step would be to keep loading from Monticello exactly like it is now: it will create Categories, and this will mirror in RPackages. > > The next step is to provide a tool that provides only a 1-1 mapping between MC and RPackages that we can use for publishing. > > In this way, we would be able to: > - load existing MC without problems > - publish new MCPackages that will be compatible with other dialects > > Indeed, Metacello configurations will need modifications, but we have a smooth path to it. The Metacello configurations are still typically used only for loading and that will still continue to work just like they do now. With the Metacello Browser things will change, but then again we can change that tool, too. > > The only problem is how to define class extensions. I believe the * magic mapping is in MC. That will create problems, but for a while, I think we can still rely on this mapping. > > Cheers, > Doru > > > > On 19 Mar 2011, at 22:20, StÃ©phane Ducasse wrote: > >> >> On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: >> >>> BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. >>> >>> In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... >> >> yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. >> but the matching semantics is not good. >> >>> But maybe it's easier (or nicer) to replace everything together... :P >>> >>> Guille >>> >>> On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> Stef, >>> >>> I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. >>> >>> On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... >>> >>> Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... >>> >>> For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... >>> >>> One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... >>> >>> Dale >>> >>> On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> we need to think about package: >>>> >>>> right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). >>>> We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement >>>> instead. >>>> RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. >>>> >>>> Now one of the problem I see is that we may not have a smooth transition because: >>>> - Rpackage does not rely on category tagging matching. >>>> - It is simpler to have a mapping from current categories to packages >>>> - Now it means that we could load a package in the system and it would be turned into several RPackages >>>> so this means that configuration would have to be adapted. >>>> >>>> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >>>> and to have tags to only represent categories. >>>> >>>> Now my time is short so I will >>>> - probably not implement tags >>>> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >>>> code. >>>> - check the MC dependency on method category conventions, because some logic is not defined in the right place >>>> like overrides in the MC tools and not in the PackageInfo >>>> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >>>> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >>>> and change the packages accordingly). >>>> - we should not rely on most-specific-category kind of pattern matching. >>>> >>>> So if you have suggestion please talk now. >>>> >>>> >>>> Stef >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > >

March 20, 2011

[Pharo-project] added Pharogenesis to the book

by Max Leske

I added Pharogenesis to the collaborative book as suggested by Mariano. I wasn't quite sure into which category to put it. For now its in "Developer Tools". Let me know if the entry is ok. Cheers, Max

March 20, 2011