- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Issue 3232 in pharo: SharedQueue code simplication

by pharo＠googlecode.com

Updates: Status: Invalid Comment #1 on issue 3232 by marcus.d...(a)gmail.com: SharedQueue code simplication http://code.google.com/p/pharo/issues/detail?id=3232 The SharedQueue in Pharo is different... we use what was SharedQueue2 in Squeak.

March 20, 2011

Re: [Pharo-project] ZeroMQ bindings for Pharo (Vijay Mathew)

by Vijay Mathew

I will keep the list updated with the progress of this project. -- Vijay

March 20, 2011

Re: [Pharo-project] We are preparing to this year Google Summer of Code (GSoC)

by Eric Lavigne

It looks like ESUG wasn't accepted this year. http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2011 2011/3/9 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Dear Smalltalkers, > > I'd like to inform you that we are preparing an application to this year > Smalltalk Google Summer of Code under ESUG umbrella, as last year. > > If accepted, Google will pay few stipendiums to students on our > Smalltalk projects. Please start thinking about ideas what projects > would be nice to have. Also start looking around for students. How to > approach the universitites near by you, do you know who to contact > there, etc. To see last year ideas and accepted/done projects, visit > last year http://gsoc2010.esug.org. > > More on our already open special Smalltalk GSoC 2011 website: > > Â Â Â Â http://gsoc2011.esug.org > > I'm specially inviting mentors of all past GSoCs to rejoin the mentors > mailing list, where we discuss all details about this year GSoC: > > Â Â Â Â http://groups.google.com/group/smalltalk-gsoc-mentors > > Best regards > Janko > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

March 20, 2011

Re: [Pharo-project] Issue 2010 in pharo: Faster??? finalization

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 2010 by marcus.d...(a)gmail.com: Faster??? finalization http://code.google.com/p/pharo/issues/detail?id=2010 The code is just for old VMs... so I close the issue.

March 20, 2011

Re: [Pharo-project] Issue 2430 in pharo: Bug PackageInfo >> classes return also Trait

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 2430 by marcus.d...(a)gmail.com: Bug PackageInfo >> classes return also Trait http://code.google.com/p/pharo/issues/detail?id=2430 I think we should not change that...

March 20, 2011

Re: [Pharo-project] Issue 2279 in pharo: Subject: [BUG]MultiByteFileStream(Object)>>error: on changes file throwing ***System Error Handling Failed*** running test coverage

by pharo＠googlecode.com

Updates: Status: WontFix Comment #3 on issue 2279 by marcus.d...(a)gmail.com: Subject: [BUG]MultiByteFileStream(Object)>>error: on changes file throwing ***System Error Handling Failed*** running test coverage http://code.google.com/p/pharo/issues/detail?id=2279 Run Coverage should not be used on system classes, as this leads to all sort of problems. (e.g. Wrappers may use the code wrapped while executing...)

March 20, 2011