- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] how to completely ignore mouse wheel events?

by pharo4Stef＠free.fr

> I have modified the following methods > HandMorph>>generateKeyboardEvent: evtBuf > ScrollPane>>scrollByKeyboard: event > > The effect is now milder. > > Esteban, would it make sense to remove the event generation bu the VM? This works only for the old-style mouse with an actual wheel. Mighty mouse does not work at all with Pharo. > > We have to get this right. Emulation of events is a bad idea. yes but we have to have time and money for that :) If fernando would not have left like a thief it was on his roadmap. Stef > > Alexandre > >

April 17, 2014

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

by pharo4Stef＠free.fr

why do we need a special class for that? Why not just a StringMorph with correct background? On 17/4/14 16:20, Ben Coman wrote: > Build 30507 integrated slice 11492 "Kill UpdatingStringMorph, > UpdatingMenu, and NameInHaloMorph" > that removed class UpdatingStringMorph its subclass NameInHaloMorph. > As a consequence the halo "morph label" > became hard to read. Compare the red circled areas in the snapshots > from build. > > > > Technically its pretty easy fix. Restoring just the #drawOn: part of > NameStringInHalo (now subclassed from StringMorph) solves the problem > as follows... > Adding... > StringMorph subclass: #NameStringInHalo > instanceVariableNames: '' > classVariableNames: '' > category: 'Morphic-Base-Widgets' > > NameStringInHalo>>drawOn: aCanvas > aCanvas fillRectangle: self bounds color: Color white. > super drawOn: aCanvas. > > and modify the following line in HaloMorph>>addNameBeneath:string: ... > nameMorph := StringMorph contents: aString font: StandardFonts > haloFont. > to.. > nameMorph := NameStringInHalo contents: aString font: > StandardFonts haloFont. > > However I'm seeking a broader picture to understand if that is the > right way to proceed... > 1. Was NameStringInHalo particularly undesired or was it more a > consequence of UpdatingStringMorph being removed ? > > 2. Should the same class name "NameStringInHalo" be used having a > different superclass than before. Actually as I write that I am > thinking this creates an unnecessary clash with Squeak and derivatives > that still have NameStringInHalo, and so... > > 3. Any suggestions for another more generic class name? > SolidStringMorph, OpaqueStringMorph, etc > > 4. Any suggestions for another way for a StringMorph to have a solid > background? > > cheers -ben

April 17, 2014

Re: [Pharo-dev] [Seaside] Question about Oauth

by Sven Van Caekenberghe

There is a Seaside example (look in the repository) and even a live demo: http://sso.doit.st On 17 Apr 2014, at 21:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi, > > Sorry for the multiple list mail. > > I am analyzing the possibility to implement a API that requires OAuth. I have been reading this link from Sven: https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md and I have a few questions: > > 1) I get lost in the #handleOAuth1Callback: part. I understand I need to provide to oauth a callback url so that this is call once the user has logged in. The thing is that Sven demo seems to be using a (RESTfull) server directly. In my case, this is a Seaside app. So...how should I do this? I guess I could create a WAComponent but then I should use Seaside rest or something? Because I need to map that url to the component (and implement handleRequest: in the component?). Is there another way? > > 2) #loginUrlFor: seems to only set 'oauth_token' however, my protocol says the url should be: https://whatever/authorize?key={oauth_consumer_key}&token={oauth_token} > would that still work or I should adapt it? > > 3) Does anyone tested the mention code/repository in GemStone? > > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by pharo4Stef＠free.fr

> abergel 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. > Given that Smalltalkers consider it a block and outsiders would understand > the closure part, maybe it is well-named as it is, as it is an obvious link > of these two terms. :) and do not expect us to change the name. We have a lot of other important things to do than to break for the sake of breaking the system. Stef > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Closure-vs-BlockClosure-tp4755091p4755104.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 17, 2014