- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-project] Call for Pharo Support **important**

by StÃ©phane Ducasse

both this is a user and industrial consortium. may be I'm a dreamer but I would like something open to the community in general. Stef On Feb 16, 2011, at 10:11 PM, Tudor Girba wrote: > Just a question: are you interested only in companies/groups or also individuals? > > Cheers, > Doru > > > On 16 Feb 2011, at 16:38, StÃ©phane Ducasse wrote: > >> Dear Pharoers >> >> We are pursuing an effort to bring Pharo to the next level: we will set up a consortium of pharo users and industrial partners. Our goal is to build a legal infrastructure that will be able to sustain the development of Pharo and improve its future. As an example, we would like to be able to collect funds (ways as to be determined - we foresee a membership model or moral license) to pay engineering tasks to be performed such as improving the virtual machine, network libraries, better JIT support. To make it short we would like to give a chance to our community to grow and structure itself so that Pharo can get stronger and that risk (truck factor) gets minimized. >> >> We are contacting you to know if your company/research group would be interested to support such effort. Showing such interest is strategically important for us and INRIA which could also support such effort. Attached is the letter of support that we will collect once signed and scanned ( stephane.ducasse(a)inria.fr / faxed at: 00 33 (0)3 59 57 78 50) >> >> Thanks for your support >> >> The Pharo Board >> >> M. Denker, S. Ducasse, and A. Lienhard >> >> <Pharo-LetterOfSupport-EN-V2.doc> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

Feb. 16, 2011

Re: [Pharo-users] [Pharo-project] Call for Pharo Support **important**

by Tudor Girba

Just a question: are you interested only in companies/groups or also individuals? Cheers, Doru On 16 Feb 2011, at 16:38, StÃ©phane Ducasse wrote: > Dear Pharoers > > We are pursuing an effort to bring Pharo to the next level: we will set up a consortium of pharo users and industrial partners. Our goal is to build a legal infrastructure that will be able to sustain the development of Pharo and improve its future. As an example, we would like to be able to collect funds (ways as to be determined - we foresee a membership model or moral license) to pay engineering tasks to be performed such as improving the virtual machine, network libraries, better JIT support. To make it short we would like to give a chance to our community to grow and structure itself so that Pharo can get stronger and that risk (truck factor) gets minimized. > > We are contacting you to know if your company/research group would be interested to support such effort. Showing such interest is strategically important for us and INRIA which could also support such effort. Attached is the letter of support that we will collect once signed and scanned ( stephane.ducasse(a)inria.fr / faxed at: 00 33 (0)3 59 57 78 50) > > Thanks for your support > > The Pharo Board > > M. Denker, S. Ducasse, and A. Lienhard > > <Pharo-LetterOfSupport-EN-V2.doc> -- www.tudorgirba.com "Presenting is storytelling."

Feb. 16, 2011

[Pharo-project] Call for Pharo Support **important**

by StÃ©phane Ducasse

Dear Pharoers We are pursuing an effort to bring Pharo to the next level: we will set up a consortium of pharo users and industrial partners. Our goal is to build a legal infrastructure that will be able to sustain the development of Pharo and improve its future. As an example, we would like to be able to collect funds (ways as to be determined - we foresee a membership model or moral license) to pay engineering tasks to be performed such as improving the virtual machine, network libraries, better JIT support. To make it short we would like to give a chance to our community to grow and structure itself so that Pharo can get stronger and that risk (truck factor) gets minimized. We are contacting you to know if your company/research group would be interested to support such effort. Showing such interest is strategically important for us and INRIA which could also support such effort. Attached is the letter of support that we will collect once signed and scanned ( stephane.ducasse(a)inria.fr / faxed at: 00 33 (0)3 59 57 78 50) Thanks for your support The Pharo Board M. Denker, S. Ducasse, and A. Lienhard

Feb. 16, 2011

Lint checks & automated clean-up of unnecessary code.

by Paul DeBruicker

Hi - Is there some place I could read about how automate the fixing of various lint checks? In a package I've written I have some sloppy parts left over from trying things, then trying other things, then finally settling on another approach entirely. For instance I have 84 instances of "Temporary variables read AND written" (RBOnlyReadOrWrittenTemporaryRule). I have 300+ methods that are implemented but not sent (RBImplementedNotSentRule), 10 un-referenced classes (RBClassNotReferencedRule), etc..... I could definitely go through and delete the temp variables by hand but am hopeful that I could just nuke them all at once, then run my tests and see what, if anything, needs replacing/repairing. Thanks for any guidance you can provide. Paul

Feb. 15, 2011

Re: [Pharo-users] Dependencies and Monticello

by laurent laffont

Hi, you can also have a look at http://www.pharocasts.com/search/label/metacello Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ On Tue, Feb 15, 2011 at 4:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi andrew > > Do not use dependencies. > They do not work well. > Use Metacello. Here is a draft I should finish on metacello. > > > > > On Feb 15, 2011, at 12:04 PM, Andrew Black wrote: > > > I probably don't understand how to use Monticello dependencies correctly. > Here is the situation. Your help appreciated. > > > > I'm writing code that uses PetitParser. So, I added to my own package a > dependency on PetitParser. > > > > Strangely, rather than linking to the PetitParser repository, this copies > PetitParser into my repository when save a new version on my package. > > > > The problem is that I have found it necessary to change a few definitions > in *PetitParser. (I would call these bug fixes, but that is a matter of > opinion.) I didn't think that would be a problem; I put the overriding > definitions into my package, and everything worked fine. > > > > That is, it worked fine until I started with a clean image and loaded my > package. Monticello apparently loaded my package, and then loaded > PetitParser. This over-wrote my (bug-fix) definitions with the original > ones. Most of my tests failed. > > > > If I load my package a second time, them my definitions overwrite the > ones from PetitParser, and all is well. > > > > I infer that Monticello packages are supposed to be > load-order-independent. So, what is the right way to fix this problem > (other than convincing Lukas that trimSpaces should, indeed, trimSpaces)? > > > > Andrew > > > > >

Feb. 15, 2011

Re: [Pharo-users] Dependencies and Monticello

by StÃ©phane Ducasse

Hi andrew Do not use dependencies. They do not work well. Use Metacello. Here is a draft I should finish on metacello. On Feb 15, 2011, at 12:04 PM, Andrew Black wrote: > I probably don't understand how to use Monticello dependencies correctly. Here is the situation. Your help appreciated. > > I'm writing code that uses PetitParser. So, I added to my own package a dependency on PetitParser. > > Strangely, rather than linking to the PetitParser repository, this copies PetitParser into my repository when save a new version on my package. > > The problem is that I have found it necessary to change a few definitions in *PetitParser. (I would call these bug fixes, but that is a matter of opinion.) I didn't think that would be a problem; I put the overriding definitions into my package, and everything worked fine. > > That is, it worked fine until I started with a clean image and loaded my package. Monticello apparently loaded my package, and then loaded PetitParser. This over-wrote my (bug-fix) definitions with the original ones. Most of my tests failed. > > If I load my package a second time, them my definitions overwrite the ones from PetitParser, and all is well. > > I infer that Monticello packages are supposed to be load-order-independent. So, what is the right way to fix this problem (other than convincing Lukas that trimSpaces should, indeed, trimSpaces)? > > Andrew >

Feb. 15, 2011

Dependencies and Monticello

by Andrew Black

I probably don't understand how to use Monticello dependencies correctly. Here is the situation. Your help appreciated. I'm writing code that uses PetitParser. So, I added to my own package a dependency on PetitParser. Strangely, rather than linking to the PetitParser repository, this copies PetitParser into my repository when save a new version on my package. The problem is that I have found it necessary to change a few definitions in *PetitParser. (I would call these bug fixes, but that is a matter of opinion.) I didn't think that would be a problem; I put the overriding definitions into my package, and everything worked fine. That is, it worked fine until I started with a clean image and loaded my package. Monticello apparently loaded my package, and then loaded PetitParser. This over-wrote my (bug-fix) definitions with the original ones. Most of my tests failed. If I load my package a second time, them my definitions overwrite the ones from PetitParser, and all is well. I infer that Monticello packages are supposed to be load-order-independent. So, what is the right way to fix this problem (other than convincing Lukas that trimSpaces should, indeed, trimSpaces)? Andrew

Feb. 15, 2011

Re: [Pharo-users] [SPAM] Re: DateAndTime and nanos

by StÃ©phane Ducasse

On Feb 14, 2011, at 10:33 PM, Sven Van Caekenberghe wrote: > > On 14 Feb 2011, at 22:00, StÃ©phane Ducasse wrote: > >> No if you want you should >> - bring the history with the MC package browser >> - select a version click on spawn >> - clik a version select changes >> and you get the diff between the version > > StÃ©phane, now I finally understand how to do this ! > Quite a complicated, non-obvioius procedure, but it works. oh yes! > What I am still missing is a way to make a changeset out of this diff. Me too We are brainstorming with Veronica on a three way browser and some other features. > > Anyway, thanks for explaining. > > Sven > >

Feb. 15, 2011

Re: [Pharo-users] DateAndTime and nanos

by Norbert Hartl

On 14.02.2011, at 22:00, StÃ©phane Ducasse wrote: >>> >>>> Hello, >>>> >>>> There is fix in google project for this. Try search it. >>>> Now it is not integrated to pharo. >>>> >>> You mean 3236? >>> >>> Yes >>> >>> And I dont know how to integrate this kind of code source. It is changes of methods with pluses and minuces chars. >>> How it can be install to image? >>> >> That + und - is a diff format to show hat has been removed (-) and what has been added (+). On the top of the message you can see a link to monticello package. I think you need to load this. So, >> >> http://source.squeak.org/trunk/Kernel-ul.513.mcz >> >> should be the right thing. > > No if you want you should > - bring the history with the MC package browser > - select a version click on spawn > - clik a version select changes > and you get the diff between the version > > loading a squeak package in pharo will just load all the change made in squeak since we forked... so good luck. oops, I overlooked the squeak in the url. Thanks for the correction. Norbert

Feb. 14, 2011

Re: [Pharo-users] [SPAM] Re: DateAndTime and nanos

by Sven Van Caekenberghe

On 14 Feb 2011, at 22:00, StÃ©phane Ducasse wrote: > No if you want you should > - bring the history with the MC package browser > - select a version click on spawn > - clik a version select changes > and you get the diff between the version StÃ©phane, now I finally understand how to do this ! Quite a complicated, non-obvioius procedure, but it works. What I am still missing is a way to make a changeset out of this diff. Anyway, thanks for explaining. Sven

Feb. 14, 2011