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

Re: [Pharo-project] Look and font competition

by Esteban Lorenzano

yesterday we where hacking with Igor a non-OpenGL version of vm... and then we said... why not VM-support for look and feel? So, we quickly coded this different options for look and feel (to get these, you just need to fuck up matrix translations and endianess): "lovely pink": "dislexic purple": :) On Jun 12, 2012, at 11:00 AM, Ben Coman wrote: > StÃ©phane Ducasse wrote: >> Hi guys >> >> this morning Igor shows me all his work around dynlib loading of third party plugins. And yes now we get all the third party plugins downloaded and compiled (yes with only one copy of FT2)â¦.Great stuff! >> Now we would like to organize a little competition for the official look of Pharo 2.0. So if you feel that you are a little bit designer inside, please send us proposals. >> We propose this one :) based on Curlz MT (welcome to the world of the pink little ponies) :) >> >> >> > Perhaps you want to consider something like Microsoft's beloved paper clip helper ? > > <PharoPonyInterface.png>

June 12, 2012

Re: [Pharo-project] Look and font competition

by Ben Coman

StÃ©phane Ducasse wrote: > Hi guys > > this morning Igor shows me all his work around dynlib loading of third party plugins. > And yes now we get all the third party plugins downloaded and compiled (yes with only one copy of FT2)â¦.Great stuff! > > Now we would like to organize a little competition for the official look of Pharo 2.0. So if you feel that you are a little > bit designer inside, please send us proposals. > We propose this one :) based on Curlz MT (welcome to the world of the pink little ponies) :) > > > Perhaps you want to consider something like Microsoft's beloved paper clip helper ?

June 12, 2012

[Pharo-project] ESUG events on facebook

by Norbert Hartl

I created two events on facebook for camp smalltalk and esug. If you like to show interest: camp smalltalk http://www.facebook.com/events/457318790946863/ ESUG http://www.facebook.com/events/346184005452842/ Norbert

June 12, 2012

Re: [Pharo-project] subclassResponsibility, how does it work?

by Luc Fabresse

Hi Gareth, I did not get what you want to do exactly. subclassResponsibility is used to through an exception which indicates that this methods should have been redefined in a subclass. 2012/6/12 Gareth Cox <gareth.cox(a)pro-mis.com> > Hi All > > I'm attempting to subclass a class (Point) and I want some instructions > passed to Point to go to MyPoint. > Specifically I have Point >>asMyPoint >> self subclassResponsibility. > In MyPoint I've got asMyPoint ^x@y. > > When I execute code, I get an error that the subclass should have > executed... > which code did you execute? > How does this actually work? How should I do this? > By creating your subclass of Point named MyPoint, you can change any method of Point by redefining it in MyPoint. Luc > > Kind Regards > Dusty > >

June 12, 2012

Re: [Pharo-project] subclassResponsibility, how does it work?

by Camillo Bruni

this question is more appropriate on the user mailinglist or on even better on stackoverflow (tag #pharo) please repost on pharo-users(a)lists.gforge.inria.fr On 2012-06-12, at 10:11, Gareth Cox wrote: > Hi All > > I'm attempting to subclass a class (Point) and I want some instructions passed to Point to go to MyPoint. > Specifically I have Point >>asMyPoint >> self subclassResponsibility. > In MyPoint I've got asMyPoint ^x@y. > > When I execute code, I get an error that the subclass should have executed... > How does this actually work? How should I do this? > > Kind Regards > Dusty >

June 12, 2012

[Pharo-project] subclassResponsibility, how does it work?

by Gareth Cox

Hi All I'm attempting to subclass a class (Point) and I want some instructions passed to Point to go to MyPoint. Specifically I have Point >>asMyPoint >> self subclassResponsibility. In MyPoint I've got asMyPoint ^x@y. When I execute code, I get an error that the subclass should have executed... How does this actually work? How should I do this? Kind Regards Dusty

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Esteban Lorenzano

he... I'm ok with that. But I want #deleteIfAbsent: :) On Jun 12, 2012, at 9:57 AM, Mariano Martinez Peck wrote: > > > On Tue, Jun 12, 2012 at 9:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > no, I vote for #deleteIfAbsent: too > > > fuc...I hate discussing in IRC. I won't do it again... > In IRC we said that even if I have #deleteIfAbsent: it is NOT enough. I don't want to have to do > aReference deleteIfAbsent: [] all the time...I don't like it. So I want #ensureDeleted or #deleteIfExists, and yes, it can rely on #deleteIfAbsent: if desired, I don't care. > > cheers > > > On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote: > >> Hi Stef. It looks we are minority. So today I will: >> - add #testExists (becuase it was broken but no test) >> - add #ensureDeleted >> - add #testEnsureDeleted >> - fix FileSystemHandleTest >> tearDown to #ensureDeleted the reference. >> >> cheers >> >> >> On Tue, Jun 12, 2012 at 7:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer remove/delete[ifAbsent:] >> On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: >> >> > I generally default to saying "of course there should be an error." I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. >> > >> > Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with "delete" so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. >> > >> > Just my 2 asCents. >> > >> > Bill >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb(a)gmail.com] >> > Sent: Monday, June 11, 2012 5:55 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? >> > >> > On Mon, Jun 11, 2012 at 2:32 PM, <petton.nicolas(a)gmail.com> wrote: >> >> Maybe #ensureDeleted would be better? >> >> >> >> Nico >> > I like #ensureDeleted (make sure it doesn't exist) >> > >> > >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

On Tue, Jun 12, 2012 at 9:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > no, I vote for #deleteIfAbsent: too > > fuc...I hate discussing in IRC. I won't do it again... In IRC we said that even if I have #deleteIfAbsent: it is NOT enough. I don't want to have to do aReference deleteIfAbsent: [] all the time...I don't like it. So I want #ensureDeleted or #deleteIfExists, and yes, it can rely on #deleteIfAbsent: if desired, I don't care. cheers > On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote: > > Hi Stef. It looks we are minority. So today I will: > - add #testExists (becuase it was broken but no test) > - add #ensureDeleted > - add #testEnsureDeleted > - fix FileSystemHandleTest >> tearDown to #ensureDeleted the reference. > > cheers > > > On Tue, Jun 12, 2012 at 7:25 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer >> remove/delete[ifAbsent:] >> On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: >> >> > I generally default to saying "of course there should be an error." I >> much prefer to get my bad news early rather than having to fish around or >> it after the fact. Toward that end, I would recommend having >> #deleteIfAbsent: and #delete that provides an error-raising block and >> forwards to #deleteifAbsent:. That is consistent with collections, which >> are not a bad model/source-of-inspiration for managing directory contents. >> > >> > Having #ensureDeleted in addition to above does no real harm. I would >> prefer that the selector start with "delete" so it appears close to the >> other methods in browsers, even w/o category filtering - makes it more >> discoverable. >> > >> > Just my 2 asCents. >> > >> > Bill >> > >> > >> > ________________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris >> Cunningham [cunningham.cb(a)gmail.com] >> > Sent: Monday, June 11, 2012 5:55 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] FileReference should throw error when >> deleting unexisting files? >> > >> > On Mon, Jun 11, 2012 at 2:32 PM, <petton.nicolas(a)gmail.com> wrote: >> >> Maybe #ensureDeleted would be better? >> >> >> >> Nico >> > I like #ensureDeleted (make sure it doesn't exist) >> > >> > >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Esteban Lorenzano

no, I vote for #deleteIfAbsent: too On Jun 12, 2012, at 9:49 AM, Mariano Martinez Peck wrote: > Hi Stef. It looks we are minority. So today I will: > - add #testExists (becuase it was broken but no test) > - add #ensureDeleted > - add #testEnsureDeleted > - fix FileSystemHandleTest >> tearDown to #ensureDeleted the reference. > > cheers > > > On Tue, Jun 12, 2012 at 7:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes to me ensureDelete or ensureDeleted is not explicit enough. I prefer remove/delete[ifAbsent:] > On Jun 12, 2012, at 1:41 AM, Schwab,Wilhelm K wrote: > > > I generally default to saying "of course there should be an error." I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. > > > > Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with "delete" so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. > > > > Just my 2 asCents. > > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham.cb(a)gmail.com] > > Sent: Monday, June 11, 2012 5:55 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? > > > > On Mon, Jun 11, 2012 at 2:32 PM, <petton.nicolas(a)gmail.com> wrote: > >> Maybe #ensureDeleted would be better? > >> > >> Nico > > I like #ensureDeleted (make sure it doesn't exist) > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 12, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by Esteban Lorenzano

OB loads fine in 1.4 too, so... you don't need to use 1.3 even if you are attached to it :) On Jun 12, 2012, at 5:27 AM, Yanni Chiu wrote: > On 11/06/12 10:35 PM, Cameron Sanders wrote: >> Do you need 1.4, and why? -- if you do not mind sharing. > > I was building on 1.3, and had a second automated build which tracked > 1.4. Periodically, I would manually update the 1.4 base image of the > build to the then latest 1.4. Each of the builds would load the > framework packages I needed, then load my code base. > > This way I could see problems with the frameworks or my code, as 1.4 > progressed. At some point 1.4 was stable enough that I switched over > (about 6 months ago). > >> ... I only recently abandoned my Pharo-1.2 one-click derived image >> when I had troubles connecting to a DB. I figured it was time to do a >> complete upgrade. But it has turned into a nightmare, and my project >> has hit a standstill, > > Yep, you don't want to be caught by surprise, when upgrading. > >> Pending your answers to my query about why you chose 1.4 over 1.3, I >> will start fresh again. > > In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3. > >

June 12, 2012