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

Re: [Pharo-project] RFB for Pharo 1.2

by Lukas Renggli

Excellent, thank you. I copied it over. Lukas On 20 March 2011 08:40, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > Lukas, > > I have removed some calls to deprecated methods in RFB-lr.34 so that RFB > work without warnings on Pharo 1.2. > I tried to commit to http://source.lukas-renggli.ch/unsorted but is now > read only. > I commited RFB-MiguelCoba.36 to > http://www.squeaksource.com/PharoTaskForces. > > Can you review it and merge if correct? > > Cheers > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > -- Lukas Renggli www.lukas-renggli.ch

March 20, 2011

Re: [Pharo-project] http://www.mirandabanda.org/files/Cog/VM/VM.r2370/

by Hilaire Fernandes

Thanks Eliot! Is the data compilation I did regarding the Locale Cog bug clear enought or do you need more information? http://code.google.com/p/cog/issues/detail?id=1 Hilaire Le 19/03/2011 01:00, Eliot Miranda a Ã©crit : > Hi All, > > I've built new VMs from the latest source. If you're a Pharo user > you may want to wait and pick-up one of Igor's VMs. These don't yet > have a merged platform source with the standard VM but they do have a > number of bugs fixed. See the readme. Next task is indeed to merge the > plugin set so that the plugins are compatible with the standard VM. As > usual I appreciate y'all pounding on these. > > Enjoy. > Eliot -- Education 0.2 -- http://blog.ofset.org/hilaire

March 20, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by StÃ©phane Ducasse

> Hi Marcus, > > I completely agree. > > Now, just one thing. We have to start with putting in place a full fledged dev image as soon as a new Core version is started. Like this we can use that one from the beginning. For example, in Moose we switch to the new version as soon as the dev is available. I hope that the situation will improve soon. We should have a new browser + refactoring soon that will be in the core in a modular fashion so that plus shout could be a good basis. Stef

March 20, 2011

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

by StÃ©phane Ducasse

On Mar 19, 2011, at 10: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. this sentence is not clear doru. Do you mean that a RPackage should contain classes that are contained in matching PackageInfo package? I mean RFoo contains RFoo and RFoo-zork categories classes? > 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. The problem is not publishing the problem is assigning classes to packages. > In this way, we would be able to: > - load existing MC without problems > - publish new MCPackages that will be compatible with other dialects let us see imagine the following scenaro PI-Foo contains Foo Foo-Zork => We get RFoo and RFoo-Zork we can save and people can load now I add a category Foo-Two in pharo I get an extra package we should modify metacelloConfig ok people can load it too in other system it will be in Foo ok we can load it Now if we should preserve the current loading semantics **package creation** when PI-Foo contains Foo Foo-Zork if we should create only one RFoo containing all the FooCat then we arrive to the point where this is not clear that when I add a new cat it will not be in. So we could always load and create a RPackage for each Category. This would be simpler. > 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. yes > > 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] RFB for Pharo 1.2

by Miguel CobÃ¡

Lukas, I have removed some calls to deprecated methods in RFB-lr.34 so that RFB work without warnings on Pharo 1.2. I tried to commit to http://source.lukas-renggli.ch/unsorted but is now read only. I commited RFB-MiguelCoba.36 to http://www.squeaksource.com/PharoTaskForces. Can you review it and merge if correct? Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 20, 2011

Re: [Pharo-project] Issue 3833 in pharo: Morph and MorphTreeMorph fixes

by Alain Plantec

Thanks Benjamin! Cheers Alain Le 19/03/2011 23:25, pharo(a)googlecode.com a Ã©crit : > Status: Accepted > Owner: Benjamin...(a)gmail.com > CC: aplan...(a)gmail.com > Labels: Nautilus > > New issue 3833 by Benjamin...(a)gmail.com: Morph and MorphTreeMorph fixes > http://code.google.com/p/pharo/issues/detail?id=3833 > > During my tries to understand how drag and drop works, I have found > and fixed to minor bugs. > > There is a cs for each bugs: > > 1) nil is passed where the method expect a block with 2 args > 2) if minor fix to allow drag and in drop inside the same Tree > without having to move the cursor outside first > > > > > > Attachments: > MorphTreeMorphFixes.1.cs 425 bytes > MorphTreeMorphFixes.2.cs 749 bytes > > >

March 20, 2011

Re: [Pharo-project] Issue 3833 in pharo: Morph and MorphTreeMorph fixes

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3833 by Benjamin...(a)gmail.com: Morph and MorphTreeMorph fixes http://code.google.com/p/pharo/issues/detail?id=3833 (No comment was entered for this change.)

March 20, 2011

[Pharo-project] Issue 3835 in pharo: Finder and RecentSubmissions new versions

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com New issue 3835 by Benjamin...(a)gmail.com: Finder and RecentSubmissions new versions http://code.google.com/p/pharo/issues/detail?id=3835 For both I have changed the text that should be displayed as a help text. And for the Finder, I have changed the order into the Tool Menu (because I use it often) It can easily be changed, so we should discuss the good order maybe

March 20, 2011

[Pharo-project] Issue 3834 in pharo: Add support for Threaded VMs in Process

by pharo＠googlecode.com

Status: Accepted Owner: siguc...(a)gmail.com Labels: Milestone-1.3 Type-RequestForEnhancement Importance-High New issue 3834 by siguc...(a)gmail.com: Add support for Threaded VMs in Process http://code.google.com/p/pharo/issues/detail?id=3834 By Eliot: To enable threading you have to modify the Process class definition to include threadId as its fourth inst var and tell the VM of that fact by setting a bit in the image via vmParameterAt: (the below, also attached). Link subclass: #Process instanceVariableNames: 'suspendedContext priority myList threadId errorHandler name island env' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Processes'! SmalltalkImage methods for system attributes processHasThreadIdInstVar: aBoolean "The threaded VM needs to know if the 4th inst var of Process is threadId which it uses to control process-to-thread binding. This flag persists across snapshots, stored in the image header." aBoolean ifTrue: [self assert: (Process instVarNames at: 4) ='threadId']. self vmParameterAt: 48 put: ((self vmParameterAt: 48) bitClear: 1) + (aBoolean ifTrue: [1] ifFalse: [0]) e.g. "Ensure VM knows whether Process has threadId inst var or not." Smalltalk processHasThreadIdInstVar: (Process instVarNames includes: 'threadId'). Attachments: SmalltalkImage-processHasThreadIdInstVar.st 585 bytes

March 19, 2011

[Pharo-project] Cog Unix/Cog MacOS now should not crash while running Pharo tests

by Igor Stasenko

.. of course it needs to be verified. Cog Mac Carbon [1] build past #10 and Cog Unix [2] build past #46 using latest Eliot's update. Note that built VMs are not MT-enabled (using a CoInterpreter class instead of CoInterpreterMT). (we should decide if we create new jobs on Hudson for MT-enabled VMs or just change existing ones to use new class). Please, go to Hudson, download and play with new VMs. Let me know if there's everything alright. [1] https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Carbon/ [2] https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix/ -- Best regards, Igor Stasenko AKA sig.

March 19, 2011