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

Re: [Pharo-dev] 13204 Hard to see Morph halo label

by Sean P. DeNigris

Ben Coman wrote > However the fix I described is low impact.  Is that reasonable to do > as > a temporary measure for 3.0 release, and a case opened to clean up in > 4.0? That sounds reasonable to me. It seems simple and isolated enough not to cause any surprises... ----- Cheers, Sean -- View this message in context: http://forum.world.st/13204-Hard-to-see-Morph-halo-label-tp4755115p4755248.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 18, 2014

Re: [Pharo-dev] 13204 Hard to see Morph halo label

by Ben Coman

April 18, 2014

Re: [Pharo-dev] 13204 Hard to see Morph halo label

by Sean P. DeNigris

pharo4Stef(a)free.fr wrote > Why not just a StringMorph with correct background? That doesn't look possible with the current implementation. It just draws the string with no background: StringMorph>>#drawOn: aCanvas ... "super drawOn: aCanvas. <- This line doesn't exist" aCanvas drawString: contents in: bnd font: self fontToUse color: color. >From the "... color: color" above, it looks like StringMorph is hijacking the instVar it inherited from Morph, which usually means background color, to use for the text color. If you hack drawOn: to ... self color: Color white. super drawOn: aCanvas. aCanvas drawString: contents in: bnd font: self fontToUse color: Color black. you get the halo label you're looking for but of course break everything else. So I think that if we want StringMorphs to have backgrounds, we have to add a textColor instVar, initialize color to Color transparent, and rewrite all color assignments in StringMorph to set textColor. In short: not for 3.0. ----- Cheers, Sean -- View this message in context: http://forum.world.st/13204-Hard-to-see-Morph-halo-label-tp4755115p4755242.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 17, 2014

Re: [Pharo-dev] 13204 Hard to see Morph halo label

by Ben Coman

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by Alexandre Bergel

Thanks Eliot for the historical anecdote Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Apr 17, 2014, at 1:54 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > > On Thu, Apr 17, 2014 at 8:21 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Because what we call a block is actually a closure. Smalltalk-80 invented blocks, which were not closures at that time. Over the time we found out that Blocks are not really useful, but instead the humanity largely prefer closure. > > I don't think this is right. Yesterday ClÃ©ment and I had lunch with Dan Ingalls and we talked about the origin of blocks. At first blocks were not even real objects; instead they were just a syntactic construct for delayed evaluation. Over time the original Smalltalk team found they needed more and more useful features, and they wanted everything to be objects so they introduced both the syntax for blocks and the class BlockContext, but they didn't look at other languages and so they didn't implement blocks as closures. > > So I think its more accurate to say > Over time Smalltalkers found blocks were /really/ useful. Later on they found out that they could implement blocks as closures, with the result that they were even more useful and much cleaner, leading to a more efficient virtual machine. > > But ok, this is not a pressing thing. Was just a tough. > > If it ain't broke don't fix it. The name BlockClosure isn't incorrect. These are blocks implemented as closures. The name MethodContext /is/ broken. These /aren't/ just MethodContexts any more, they are both BlockContexts and MethodContexts, so collapsing ContextPart and MethodContext together into just Context, and deleting the now unused BlockContext does make sense. > > [snip] > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Apr 17, 2014, at 11:45 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Itâs like saying that we have to run Pharo on JVM because everyone is doing that. In 80s block was invented. Why should we rename it because of some other languages? > > > > Uko > > > > On 17 Apr 2014, at 16:35, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > >> Wellâ¦ the whole community of programming language call a closure a closure. Calling a block what is actually a closure may not be a well-marketed move in my opinion. > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> On Apr 17, 2014, at 10:29 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> > >>> On Apr 17, 2014, at 10:08 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >>> > >>>> I would rather rename is to Block, as everyone is calling it a âblockâ. > >>> > >>> That might be actually a good idea > >>> > >>> sebastian > >>> > >>> o/ > >>> > >>> PS: thinking in that line there is also âContextâ as, conceptually, what these blocks of code want to do is to keep the evaluation in a specific context. But to ease know-how transference and type less Iâd rather go with the most popular name, as you suggested: âBlock' > >>> > >>> > >> > >> > > > > > > > > > > -- > best, > Eliot

April 17, 2014

RBClassRegexRefactoring & Nautilus madness

by phil＠highoctane.be

I have been able to refactor my class names with: RBClassRegexRefactoring new renameClasses; replace: '^XXX(.*)$' with: 'YY$1' ignoreCase: false; execute But since then, Nautilus looks like quite lost with a number of weird behaviors. Is there a way to reset Nautilus after such refactorings? I suspect that there is a cache somewhere that begs to be rebuilt... Phil

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by ClÃ©ment Bera

2014-04-17 13:00 GMT-07:00 pharo4Stef(a)free.fr <pharo4Stef(a)free.fr>: > > On 17/4/14 18:54, Eliot Miranda wrote: > >> If it ain't broke don't fix it. The name BlockClosure isn't incorrect. >> These are blocks implemented as closures. The name MethodContext /is/ >> broken. These /aren't/ just MethodContexts any more, they are both >> BlockContexts and MethodContexts, so collapsing ContextPart and >> MethodContext together into just Context, and deleting the now unused >> BlockContext does make sense. >> > > This is planned :) > I now that clement started to look at them with a strange look :) > we discussed about it last week. This will definitely be integrated in Pharo 4. > > Stef > > >

April 17, 2014

UndefinedObject>>allSuperclassesDo: aBlockContext self shouldBeImplemented

by phil＠highoctane.be

Weird... is this a bug? Phil

April 17, 2014

Re: [Pharo-dev] IMPORTANT: Looking for names of contributors for Pharo 3

by pharo4Stef＠free.fr

I added a lot of people. :)

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by pharo4Stef＠free.fr

On 17/4/14 18:54, Eliot Miranda wrote: > If it ain't broke don't fix it. The name BlockClosure isn't > incorrect. These are blocks implemented as closures. The name > MethodContext /is/ broken. These /aren't/ just MethodContexts any > more, they are both BlockContexts and MethodContexts, so collapsing > ContextPart and MethodContext together into just Context, and deleting > the now unused BlockContext does make sense. This is planned :) I now that clement started to look at them with a strange look :) Stef

April 17, 2014