June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Graphic Framework..

by Diogenes Moreira

Hi Folk, Is there a framework for generate graphics chart, like excel.. (I'll kill one dragon hidden on the excel and access), for morphic to start, but the idea is using that image in a seaside application. Best D. http://about.me/diogenes.moreira

June 7, 2012

Re: [Pharo-project] Fuel

by Frank Shearar

On 6 June 2012 22:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > Yeah.. > > we even can make a lint rule: > Â - 1 max reference per package to class from another package > unless referencing class belongs to kernel By which you mean your hint the other day (last week?) that if you need multiple references, rather use a _local_ reference? Delegating the remote reference through one well-known point over which you have control saves you from lots of pain. frank > modules.. they are so easy to do, if everyone would follow that rule :) > > On 6 June 2012 22:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Steph wants less hardcoded references to PackageInfo :) >> >> >> On Wed, Jun 6, 2012 at 10:51 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Hmm I didn't catch it >>> >>> Martin >>> >>> On Wed, Jun 6, 2012 at 4:47 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>> > ok for me >>> > I'm studying PackageInfo and the rest to see what I can do. >>> > >>> >> mariano/martin >>> >> >>> >> Â Â Â Â I would like to extract PakageInfo into self packageInfo in the >>> >> fuel code. >>> >> >>> >> Yes, I like that the idea. I guess you are talking about >>> >> FuelPackageLoader in #named: and #withPacakges: right? >>> >> What about calling it direclty #package? Â so that we may be able to >>> >> change it later to PackageInfo or RPackage or whatever? >>> >> >>> >> >>> >> Can I do it? >>> >> >>> >> Stef >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Mariano >>> >> http://marianopeck.wordpress.com >>> >> >>> > >>> > >>> >> > > > > -- > Best regards, > Igor Stasenko. >

June 7, 2012

Re: [Pharo-project] Backporting fixes

by Marcus Denker

On Jun 7, 2012, at 11:10 AM, Marcus Denker wrote: > > On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote: > >> >> Sean P. DeNigris wrote >>> >>> I want to backport some fixes from 2.0 into 1.4. What's the best way to do >>> that? >>> >>> Also, it seems to me that, given our new development process, all bugs >>> should be tagged for both 1.4 and 2.0 unless they specifically don't apply >>> to 1.4... >>> >> >> I would appreciate this _very_ much. >> >> What does it take to do this? I often file in bug-fixes from the >> issue-tracker, test it for my own projects, run the available tests - but of >> course i often do not understand why a fix works, or if it is well made. > > > If you do that, can you add a note to the bug tracker that you did it? > takes 2 seconds. In general, I think there is a miss-conception of how things are done. The secret is: Things are done because they are done. Marcus -- Marcus Denker -- http://marcusdenker.de

June 7, 2012

Re: [Pharo-project] Backporting fixes

by Marcus Denker

On Jun 7, 2012, at 11:07 AM, Helene Bilbo wrote: > > Sean P. DeNigris wrote >> >> I want to backport some fixes from 2.0 into 1.4. What's the best way to do >> that? >> >> Also, it seems to me that, given our new development process, all bugs >> should be tagged for both 1.4 and 2.0 unless they specifically don't apply >> to 1.4... >> > > I would appreciate this _very_ much. > > What does it take to do this? I often file in bug-fixes from the > issue-tracker, test it for my own projects, run the available tests - but of > course i often do not understand why a fix works, or if it is well made. If you do that, can you add a note to the bug tracker that you did it? takes 2 seconds. Marcus -- Marcus Denker -- http://marcusdenker.de

June 7, 2012

Re: [Pharo-project] Backporting fixes

by Helene Bilbo

Sean P. DeNigris wrote > > I want to backport some fixes from 2.0 into 1.4. What's the best way to do > that? > > Also, it seems to me that, given our new development process, all bugs > should be tagged for both 1.4 and 2.0 unless they specifically don't apply > to 1.4... > I would appreciate this _very_ much. What does it take to do this? I often file in bug-fixes from the issue-tracker, test it for my own projects, run the available tests - but of course i often do not understand why a fix works, or if it is well made. For example the most horrible 1.4 shortcoming, the SLOW FileList works perfektly well with the fix proposed here: http://code.google.com/p/pharo/issues/detail?id=5880 All tests for FileSystem run still well with this fix and there is a big speedup. I would really appreciate this in 1.4. Currently the FileList is unusable. Best regards, Helene. -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625p4633647.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 7, 2012

Re: [Pharo-project] Backporting fixes

by StÃ©phane Ducasse

+ 1 Marcus can you add it to the pharo-project web site. >> >> no new bugs tagged 1.4 are important ones for the incremental release. >> We will not maintain two versions in parallel. Just **important** = show stopper fixes. > > Especially as one Person's enhancement is the other persons bug... any large change > will have side effects, so we should really limit us a bit. > > -> No new features. > -> No cleanups > -> If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in > the current dev version is (in many cases) enough. > (There are exceptions, but is does not happen often). > -> Community input is important. A ready-to-include fix with a description that it > was tested and a note that it for sure works will not be ignored. > For an entry that is nearly finished yet nobody even cares to test it, why bother? > > The best thing is to just do it. The list is here: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4 > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

June 7, 2012

Re: [Pharo-project] Backporting fixes

by Marcus Denker

On Jun 7, 2012, at 9:03 AM, StÃ©phane Ducasse wrote: > > On Jun 7, 2012, at 6:11 AM, Sean P. DeNigris wrote: > >> I want to backport some fixes from 2.0 into 1.4. What's the best way to do >> that? >> >> Also, it seems to me that, given our new development process, all bugs >> should be tagged for both 1.4 and 2.0 unless they specifically don't apply >> to 1.4â¦ > > no new bugs tagged 1.4 are important ones for the incremental release. > We will not maintain two versions in parallel. Just **important** = show stopper fixes. Especially as one Person's enhancement is the other persons bug... any large change will have side effects, so we should really limit us a bit. -> No new features. -> No cleanups -> If a bug was there in Pharo 1.1 already and we lived with it for years, fixing it in the current dev version is (in many cases) enough. (There are exceptions, but is does not happen often). -> Community input is important. A ready-to-include fix with a description that it was tested and a note that it for sure works will not be ignored. For an entry that is nearly finished yet nobody even cares to test it, why bother? The best thing is to just do it. The list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.4 Marcus -- Marcus Denker -- http://marcusdenker.de

June 7, 2012

Re: [Pharo-project] Backporting fixes

by StÃ©phane Ducasse

On Jun 7, 2012, at 6:11 AM, Sean P. DeNigris wrote: > I want to backport some fixes from 2.0 into 1.4. What's the best way to do > that? > > Also, it seems to me that, given our new development process, all bugs > should be tagged for both 1.4 and 2.0 unless they specifically don't apply > to 1.4â¦ no new bugs tagged 1.4 are important ones for the incremental release. We will not maintain two versions in parallel. Just **important** = show stopper fixes. > > Thanks, > Sean > > -- > View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 7, 2012

Re: [Pharo-project] Fuel

by StÃ©phane Ducasse

yes this is a fun rule. Now you have to have a common ancestor or a package entry point. Stef On Jun 6, 2012, at 11:55 PM, Igor Stasenko wrote: > Yeah.. > > we even can make a lint rule: > - 1 max reference per package to class from another package > unless referencing class belongs to kernel > > > modules.. they are so easy to do, if everyone would follow that rule :) > > On 6 June 2012 22:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Steph wants less hardcoded references to PackageInfo :) >> >> >> On Wed, Jun 6, 2012 at 10:51 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Hmm I didn't catch it >>> >>> Martin >>> >>> On Wed, Jun 6, 2012 at 4:47 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> ok for me >>>> I'm studying PackageInfo and the rest to see what I can do. >>>> >>>>> mariano/martin >>>>> >>>>> I would like to extract PakageInfo into self packageInfo in the >>>>> fuel code. >>>>> >>>>> Yes, I like that the idea. I guess you are talking about >>>>> FuelPackageLoader in #named: and #withPacakges: right? >>>>> What about calling it direclty #package? so that we may be able to >>>>> change it later to PackageInfo or RPackage or whatever? >>>>> >>>>> >>>>> Can I do it? >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

June 7, 2012

[Pharo-project] Backporting fixes

by Sean P. DeNigris

I want to backport some fixes from 2.0 into 1.4. What's the best way to do that? Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4... Thanks, Sean -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 7, 2012