January 2014 - Pharo-dev - lists.pharo.org

Pharo-contribution job configuration mess

by Yuriy Tymchuk

So Iâve noticed that all new builds cause a change in configuration and I rind this very frustrating. I think that this is related to https://issues.jenkins-ci.org/browse/JENKINS-20176. Can someone update disk usage plugin? Cheers Uko

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by J.F. Rick

On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > I would like to continue in the direction started with the Morphic-Core. > It's a subset of Morphic that is able to be loaded into a headless image, > initialize itself and show world with one basic responsive morph. > There's a question of what is necessary for a modern GUI core. To me, we need to get out of BitBlt rendering completely and towards vectors. Reliance on BitBlt makes Pharo seem slow and outdated. Pixelation is so early 1990s. Novices also don't understand that a slow GUI isn't indicative of everything being slow. There's no reason Pharo's UI can't be fast enough that you can't tell the difference between it and a native app. That would do a lot to make Pharo more palatable to newcomers. First impressions are critical. We should also make it easy for people to build animations and build them into the core tools (when it makes sense). Most modern OSs feature great support for animation. Even if these things are largely eye candy, they do change people's perceptions. I'd love to be able to do something like this: aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2. Speaking of which, it would be nice if orientation could be included into the equation. Perhaps support for affine transforms would be standard. There also should be substantial support for vector graphics. The Athens SVG input is a good step forward, but I'd like to see something that seems very Pharo-native and that can be exported to SVG, rather than something that seems very close to SVG XML (as is now the case). Ideally, I'd like to do the old demo of rotating a browser and still using it but have it still look smooth (i.e., no pixelation). Another thing to perhaps address is how morphs are controlled and resized. Currently, when we change the extent, then the top left corner remains the same. For most cases, keeping the center the same would be more intuitive; vvvv does that and is fairly easy for programming novices to use. It would also allow us to combine rotation and scaling in some ways: aMorph rotateAndScaleBottomLeftTo: 300 @ 20. "keep the center stationary" Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 29, 2014

Re: [Pharo-dev] Pharo Success Story: Reflex Vacances

by Sebastian Sastre

awesome! kick airbnb arse! >:) On Jan 29, 2014, at 10:30 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Added to the page > http://www.pharo-project.org/about/success-stories > > > Reflex Vacances > ============= > Reflex Vacances is a website to rent holiday homes all over France. > > The website lists 2000+ houses, and it runs 100% in Pharo + Iliad + MongoDB. > > "Cette plateforme regroupe des milliers d'annonces publiÃ©es par des > propriÃ©taires de toute la France, tous spÃ©cialistes de la location de > vacances. Nous l'avons dotÃ©e d'un logiciel sur mesure dÃ©veloppÃ© > pour permettre Ã la fois aux visiteurs de juger de la qualitÃ© des > annonces et aux propriÃ©taires de valoriser grÃ¢ce Ã un espace > optimisÃ© ou le logement peut-Ãªtre abondamment dÃ©crit." > > Contact http://www.objectfusion.fr for more information.

Jan. 29, 2014

FOSDEM

by phil＠highoctane.be

Hi Gang, So, #FOSDEM is this week-end. I looked at the schedule, which looks interesting. https://fosdem.org/2014/schedule/track/smalltalk/ Who's coming apart from the speakers ? Phil

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by Marcus Denker

On 29 Jan 2014, at 16:01, phil(a)highoctane.be wrote: > Yeah, time. Not enough not enough not enough. > > Who is going to be at #FOSDEM on Saturday? > me, but due to a mixup with the date I have to take the train back 16:15â¦. Marcus

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by phil＠highoctane.be

Yeah, time. Not enough not enough not enough. Who is going to be at #FOSDEM on Saturday? Phil On Wed, Jan 29, 2014 at 3:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On 29 Jan 2014, at 15:50, phil(a)highoctane.be wrote: > > Know what would be making it really useful? > > A nice dark theming feature. > > Yeah, that's not Morphic-Core, but currently, this aspect makes the whole > thing feel stuck in the 90's. > > Esteban, did you had any luck with that? > > > not yet :( > time time time time :(( > > Doru was going to help on that too... but I think he is the same situation > as me. > > Esteban > > > Phil > > > On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> >> >> >> 2014-01-29 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> >> >>> Le 28/01/2014 18:41, Pharo4Stef a Ã©crit : >>> > this is years since I clean Morphic (may be I'm that good at it) but >>> this is important to >>> > go step by step. So I would really like to get a list of simple >>> actions. >>> > Do you have an idea? >>> >>> >>> What about a brutal scheme, independent of all code quality >>> considerations: >>> >>> - dedicate a Pharo release process *only* to Morphic cleaning so people >>> will know it gona be brutal >>> - mark as deprecated all morphic methods unsused in the system. When a >>> client (like me with DrGeo), use some of the deprecated method, fill a >>> bug ticket, then discussion should arise about what to do: >>> i. unmark it as deprecated >>> ii. move it in external package >>> iii. adoption by the client in its application code >>> - do the same with unused classes from the Morph hierarchy. >>> >>> >>> I guess Steph already did some of this in the past. >>> >>> The idea is you don't want to refactor unused code, right? >>> >> >> I would like to continue in the direction started with the Morphic-Core. >> It's a subset of Morphic that is able to be loaded into a headless >> image, initialize itself and show world with one basic responsive morph. >> We can clean it and continue with basic fonts support, windows support >> etc. Every step will produce one package that can be loaded on top others, >> will heave well defined dependencies, will be small in size, easier to >> understand, maintain and refactor. >> It looks hard but in fact it is not so horrible. In one of my previous >> testing image I was able to reach the state where Morphic-Core was clear >> - generated no new unimplemented classes and similar mess. >> We only need to define it as a common goal. >> >> Cheers, >> -- Pavel >> >> >> >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >>> >> > >

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by Esteban Lorenzano

On 29 Jan 2014, at 15:50, phil(a)highoctane.be wrote: > Know what would be making it really useful? > > A nice dark theming feature. > > Yeah, that's not Morphic-Core, but currently, this aspect makes the whole thing feel stuck in the 90's. > > Esteban, did you had any luck with that? not yet :( time time time time :(( Doru was going to help on that tooâ¦ but I think he is the same situation as me. Esteban > > Phil > > > On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2014-01-29 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > Le 28/01/2014 18:41, Pharo4Stef a Ã©crit : > > this is years since I clean Morphic (may be Iâm that good at it) but this is important to > > go step by step. So I would really like to get a list of simple actions. > > Do you have an idea? > > > What about a brutal scheme, independent of all code quality considerations: > > - dedicate a Pharo release process *only* to Morphic cleaning so people > will know it gona be brutal > - mark as deprecated all morphic methods unsused in the system. When a > client (like me with DrGeo), use some of the deprecated method, fill a > bug ticket, then discussion should arise about what to do: > i. unmark it as deprecated > ii. move it in external package > iii. adoption by the client in its application code > - do the same with unused classes from the Morph hierarchy. > > > I guess Steph already did some of this in the past. > > The idea is you don't want to refactor unused code, right? > > I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. > We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. > It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. > We only need to define it as a common goal. > > Cheers, > -- Pavel > > > > -- > Dr. Geo http://drgeo.eu > > > >

Jan. 29, 2014

Re: [Pharo-dev] packages in 3.0

by Norbert Hartl

Am 29.01.2014 um 15:28 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 29 Jan 2014, at 11:25, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 28.01.2014 um 23:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> >>> On 28 Jan 2014, at 23:34, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> >>>> Am 28.01.2014 um 22:50 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>>> they do not appear because they shouldnât :) >>>>> >>>>> MCPackage = RPackage in 3.0 >>>>> >>>> Ah, very good. I see this of course shortly after I applied ones again stupid package names to be able to separate tests. >>>> >>>>> that means that you need 3 mc packagesâ¦ or 1 r packages + 2 tags >>>>> >>>> tags? What year is it? At the moment Iâm feeling as I had been off the list for quite a while! Ok, Iâll try to find these myself. >>>> >>>> Btw. 30 minutes ago I found metacello stuff (create baseline, create development version) in the menu of the monticello packages. Great stuff! Are you sure there isnât a lot of good stuff sneaking in without anyone noticing? >>>> >>>>> btwâ¦ there are still some glitches with that that need to be fixed. Please report if/when you find them :) >>>>> >>>> Oh my, I hate it because that is the one thing Iâm good atâ¦.finding bugs. >>> >>> coolâ¦ we need more like you (and so far Stef has the podium) :) >>> >> Is there anything to take care in a mixed environment. I have 2.0/3.0 mixed setting here. From now on I like to develop in 3.0 even if the code is loaded into a 2.0 image. Can I expect trouble when loading the finer grained packages produced via 3.0 in a 2.0 image? > > it should work without problemâ¦ but of course if you attempt to save in 2.0 package A will include A-B and A-C :) > Yep, and I will have dirty packages in my image. Thanks for the hint but I can live with that. The next time I think I could do a dirty hotfix on the server and save it I will be in trouble :) Norbert > Esteban > >> >> Norbert >> >>>> >>>> Norbert >>>> >>>>> Esteban >>>>> >>>>> On 28 Jan 2014, at 22:29, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>>> I have a project that defines a package >>>>>> >>>>>> Project-Core >>>>>> >>>>>> then I added some more like >>>>>> >>>>>> Project-Core-Exception >>>>>> Project-Core-Command >>>>>> â¦ >>>>>> >>>>>> but those do not appear in the monticello package. Is it supposed to be that way from 3.0 on or is this a bug? >>>>>> >>>>>> Norbert

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by phil＠highoctane.be

Know what would be making it really useful? A nice dark theming feature. Yeah, that's not Morphic-Core, but currently, this aspect makes the whole thing feel stuck in the 90's. Esteban, did you had any luck with that? Phil On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > > > > 2014-01-29 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > >> Le 28/01/2014 18:41, Pharo4Stef a Ã©crit : >> > this is years since I clean Morphic (may be I'm that good at it) but >> this is important to >> > go step by step. So I would really like to get a list of simple actions. >> > Do you have an idea? >> >> >> What about a brutal scheme, independent of all code quality >> considerations: >> >> - dedicate a Pharo release process *only* to Morphic cleaning so people >> will know it gona be brutal >> - mark as deprecated all morphic methods unsused in the system. When a >> client (like me with DrGeo), use some of the deprecated method, fill a >> bug ticket, then discussion should arise about what to do: >> i. unmark it as deprecated >> ii. move it in external package >> iii. adoption by the client in its application code >> - do the same with unused classes from the Morph hierarchy. >> >> >> I guess Steph already did some of this in the past. >> >> The idea is you don't want to refactor unused code, right? >> > > I would like to continue in the direction started with the Morphic-Core. > It's a subset of Morphic that is able to be loaded into a headless image, > initialize itself and show world with one basic responsive morph. > We can clean it and continue with basic fonts support, windows support > etc. Every step will produce one package that can be loaded on top others, > will heave well defined dependencies, will be small in size, easier to > understand, maintain and refactor. > It looks hard but in fact it is not so horrible. In one of my previous > testing image I was able to reach the state where Morphic-Core was clear > - generated no new unimplemented classes and similar mess. > We only need to define it as a common goal. > > Cheers, > -- Pavel > > > >> >> -- >> Dr. Geo http://drgeo.eu >> >> >> >

Jan. 29, 2014

Re: [Pharo-dev] process to collaborate on cleaning morphic

by Pavel Krivanek

2014-01-29 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > Le 28/01/2014 18:41, Pharo4Stef a Ã©crit : > > this is years since I clean Morphic (may be I'm that good at it) but > this is important to > > go step by step. So I would really like to get a list of simple actions. > > Do you have an idea? > > > What about a brutal scheme, independent of all code quality considerations: > > - dedicate a Pharo release process *only* to Morphic cleaning so people > will know it gona be brutal > - mark as deprecated all morphic methods unsused in the system. When a > client (like me with DrGeo), use some of the deprecated method, fill a > bug ticket, then discussion should arise about what to do: > i. unmark it as deprecated > ii. move it in external package > iii. adoption by the client in its application code > - do the same with unused classes from the Morph hierarchy. > > > I guess Steph already did some of this in the past. > > The idea is you don't want to refactor unused code, right? > I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal. Cheers, -- Pavel > > -- > Dr. Geo http://drgeo.eu > > >

Jan. 29, 2014