- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Do you have a tool that works on Pharo ?

by StÃ©phane Ducasse

thanks mariano this is a good initiative. Stef On Mar 20, 2011, at 10:22 PM, Mariano Martinez Peck wrote: > ifTrue: [ self writeOnPharoBook: aTool] > > We need to improve our documentation. Right now, we have a collaborative book where everyone can join and write: http://book.pharo-project.org/ > > Here we have a list of tools that run on Pharo: http://book.pharo-project.org/book/PharoTools > and it is REALLY important to have such list updated and maintained. > > So, if you have a tool that works in pharo and it is not there, please add it. If you don't have a user, I can create one for you. If you are TOO lazy, you can send by email the text to me and I write it. > > Thanks > > Mariano

March 20, 2011

[Pharo-project] Issue 3838 in pharo: Cleaning MCPackageLoader

by pharo＠googlecode.com

Status: FixProposed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3838 by stephane...(a)gmail.com: Cleaning MCPackageLoader http://code.google.com/p/pharo/issues/detail?id=3838 useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := (ChangeSet named: baseName) ifNil: [ ChangeSet new name: baseName ]. changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. the respondsTo: are not needed since this is just to make sure that MC code would work in Squeak 3.6 or before. useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | oldChanges newChanges | oldChanges :=ChangeSet current. newChanges := (ChangeSet named: baseName) ifNil: [ ChangeSet new name: baseName ]. ChangeSet newChanges: newChanges. [aBlock value] ensure: [ChangeSet newChanges: oldChanges].

March 20, 2011

Re: [Pharo-project] Do you have a tool that works on Pharo ?

by Mariano Martinez Peck

It is not necesary that you document 10 pages. Just put the name of the project, explain in 2 lines what it is, how to install it, and if you have documentation in some other place, a link. And that's all. For example, I have in mind these projects: aidaWeb scribo Iliad RFB autotest mockery XML support Help system PetitParser Helvetia Opal Gofer RefactoringBrowser Chronos Citizen FileSystem Grease ODBC OSProcess XML-RPC XStreams but I don't know what each of them is exacty, how to install it, or its link. So, if their developers help us it would be cool cheers Mariano On Sun, Mar 20, 2011 at 10:22 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > ifTrue: [ self writeOnPharoBook: aTool] > > We need to improve our documentation. Right now, we have a collaborative > book where everyone can join and write: http://book.pharo-project.org/ > > Here we have a list of tools that run on Pharo: > http://book.pharo-project.org/book/PharoTools > and it is REALLY important to have such list updated and maintained. > > So, if you have a tool that works in pharo and it is not there, please add > it. If you don't have a user, I can create one for you. If you are TOO lazy, > you can send by email the text to me and I write it. > > Thanks > > Mariano >

March 20, 2011

[Pharo-project] Do you have a tool that works on Pharo ?

by Mariano Martinez Peck

ifTrue: [ self writeOnPharoBook: aTool] We need to improve our documentation. Right now, we have a collaborative book where everyone can join and write: http://book.pharo-project.org/ Here we have a list of tools that run on Pharo: http://book.pharo-project.org/book/PharoTools and it is REALLY important to have such list updated and maintained. So, if you have a tool that works in pharo and it is not there, please add it. If you don't have a user, I can create one for you. If you are TOO lazy, you can send by email the text to me and I write it. Thanks Mariano

March 20, 2011

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

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #7 on issue 3830 by laurent....(a)gmail.com: [Failing Test] Autotes TestHitCounter.testHitCountIncrements http://code.google.com/p/pharo/issues/detail?id=3830 Thank you ! Seems to work. I've created Autotest v1.0.1 and updated ConfigurationOfPharo. Waiting for next build....

March 20, 2011

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz

by Igor Stasenko

On 20 March 2011 20:33, Matthew Fulmer <tapplek(a)gmail.com> wrote: > > On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: >> Except that its my branch and I've been using oscog from the start. Â Igor >> had no need to use the same name line as me. Â I don't want to change now. >> Â oscog refers to my branch of VMMaker for "open source Cog". > > It's not really open source if nobody else can contribute to > that branch. Squeaksource apparently allows versions to be > overwritten. I didn't know that either. Maybe that's part of the > reason the naming convention has been adopted: > Package-author.version > > The best supported convention for maintaining a branch is to use > a different repository. MC is distributed, so packages can be > merged between repositories no problem. > > So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz > would be a trunk commit, and > http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would > be a cog commit. > > Changing the package name is not really supported; Most MC > implementations can't merge between packages (MC1.5 could, but I > havn't ported that to any MC that's actually in use) > > I like seperate repositories better anyway; then you can know if > there is a newer version of your branch available just by seeing > if VMMaker package is bold in the repo browser; if they are in > the same repository, you have to pay attention to the commits > I agree that having different repos could simplify things. Except things which will otherwise complicate them: - publishing new VMMaker version sends nice email to mailing list - configuration(s) to automatically load VMMaker with all dependencies relying on having VMMaker package at certain known location, not at multiple ones. So, lets keep pushing to SqS/VMMaker but use different naming scheme. > -- > Matthew Fulmer (a.k.a. Tapple) > -- Best regards, Igor Stasenko AKA sig.

March 20, 2011

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

by Tudor Girba

Excellent! I can't wait to use it when it's ready :) Doru On 20 Mar 2011, at 17:33, Camillo Bruni wrote: > 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 :). -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

March 20, 2011

Re: [Pharo-project] Issue 3837 in pharo: Can not build Pharo Full 1.3

by pharo＠googlecode.com

Comment #1 on issue 3837 by stephane...(a)gmail.com: Can not build Pharo Full 1.3 http://code.google.com/p/pharo/issues/detail?id=3837 Ok we should remove this pop up...

March 20, 2011

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

by StÃ©phane Ducasse

>> >>> 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... Yes I understand. Now we should be able to find a solution based on category (without subcat matching). > > Dale

March 20, 2011

Re: [Pharo-project] [ANN] ConfigurationOfRFB with symbolic versions

by StÃ©phane Ducasse

tx! On Mar 20, 2011, at 8:07 PM, Miguel CobÃ¡ wrote: > Hi all, > > I have updated the ConfigurationOfRFB with symbolic versions. > It can load RFB on PharoCore 1.1 and PharoCore 1.2. > > To load it, evaluate in a workspace: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfRFB'; > load. > > ((Smalltalk at: #ConfigurationOfRFB) > project version: #stable) load. > > This will load the correct version of RFB for the given PharoCore > version (thanks Dale!): > > RFB-lr.34.mcz for PharoCore 1.1 > RFB-MiguelCoba.36 for PharoCore 1.2 > > Enjoy! > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 20, 2011