- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Condense changes

by Sven Van Caekenberghe

On 17 Apr 2014, at 21:13, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > I tried the new version: > > PharoChangesCondenser condense. -> parse error I tried recently and it just worked. > Do we open a new bug? Yes > Is there another way that I missed? > > Do you agree that we should remove condenseChanges from SmalltalkImage? Maybe not just yet ;-)

April 17, 2014

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

by pharo4Stef＠free.fr

yes it does On 17/4/14 10:49, Stephan Eggermont wrote: > Esteban wrote: >> Iâm collecting the names of those who contributed code for Pharo 3. > If that includes making configurations work in Pharo 3, you definitely miss > Diego Lont. > > Stephan >

April 17, 2014

Re: [Pharo-dev] InfiniteForm

by pharo4Stef＠free.fr

thanks igor I was thinking about that too but I thought that it could not be that simple :) On 17/4/14 02:20, Igor Stasenko wrote: > > > > On 15 April 2014 23:15, pharo4Stef(a)free.fr <mailto:pharo4Stef@free.fr> > <pharo4Stef(a)free.fr <mailto:pharo4Stef@free.fr>> wrote: > > There a plenty of isKindOf: InfiniteForm in the system and I was > trying to understand how we could get rid of them. > How other systems handle pattern based color filling shape? > > why bother? > > Just use The God's Hammer Dispatch (AKA Non-intuitive way of programming > for those who don't think in objects ;) : > > fillRectangle: aRectangle basicFillStyle: aFillStyle > "Fill the given rectangle with the given, non-composite, fill style." > > | pattern | > > (aFillStyle isKindOf: InfiniteForm) ifTrue: [ > ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle > ]. > > > => > > fillRectangle: aRectangle basicFillStyle: aFillStyle > "Fill the given rectangle with the given, non-composite, fill style." > ^ aFillStyle fillRectangle: aRectangle onCanvas: self > > > ..and then after refactoring it will look exactly how Athens doing it, > because if you rename fill style with "paint" and rectangle with > "shape" you will see it :) > > > Stef > > > > > -- > Best regards, > Igor Stasenko.

April 17, 2014

Question about Oauth

by Mariano Martinez Peck

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

April 17, 2014

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

by pharo4Stef＠free.fr

On 16/4/14 16:12, Esteban Lorenzano wrote: > everything counts, there is no such thing as a âsmall fixâ :) + 1 > > Esteban > > On 16 Apr 2014, at 16:02, Sergi Reyner <sergi.reyner(a)gmail.com > <mailto:sergi.reyner@gmail.com>> wrote: > >> I did contribute some code for SpecÂ´s ImageModel, if that counts :D >> >> Cheers, >> Sergi >> >> >> 2014-04-16 13:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>>: >> >> oops, fixed :) >> >> On 16 Apr 2014, at 14:51, Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>> wrote: >> >> > Mine is there but spelled wrongly. >> > >> > Norbert >> > >> > Am 16.04.2014 um 14:24 schrieb Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> > >> >> Hi guys, >> >> >> >> Iâm collecting the names of those who contributed code for >> Pharo 3. >> >> I made my own list, but is almost made by memory, so Iâm sure >> Iâm forgetting MANY names. So, pleaseâ¦ look yourself in the list >> and if you are not there, reply adding it. >> >> (btwâ¦ Kilon, I know you contributed, is just that I donât know >> your real name :P) >> >> >> >> Jean Baptiste Arnaud >> >> Philippe Back >> >> ClÃ©ment Bera >> >> Alexandre Bergel >> >> Camillo Bruni >> >> Sven Van Caekenberghe >> >> Damien Cassou >> >> Nicolas Cellier >> >> Ben Coman >> >> Gisela Decuzzi >> >> Christophe Demarey >> >> Sean DeNigris >> >> Marcus Denker >> >> Martin Dias >> >> Stephane Ducasse >> >> Stephan Eggermont >> >> Luc Fabresse >> >> Hilaire Fernandes >> >> Tudor Girba >> >> Thierry Goubier >> >> Norbert Harlt >> >> Nicolai Hess >> >> Andre Hora >> >> Pavel Krivanek >> >> Jannik Laval >> >> Max Leske >> >> David Lewis >> >> Esteban Lorenzano >> >> Stefan Marr >> >> Mariano Martinez Peck >> >> Eliot Miranda >> >> Nicolas Petton >> >> Alain Plantec >> >> Guillermo Polito >> >> Damien Pollet >> >> Camille Teruel >> >> Benjamin Van Ryseghem >> >> Frank Shearar >> >> Igor Stasenko >> >> Sebastian Tleye >> >> Yuriy Tymchuk >> >> >> >> Thanks, >> >> Esteban >> > >> > >> >> >> >

April 17, 2014

Condense changes

by Luc Fabresse

hi all, In a fresh image #30826, I tried: Smalltalk image condenseChanges -> ZnInvalidUTF8 error https://pharo.fogbugz.com/default.asp?12729& describes that but it is closed. I tried the new version: PharoChangesCondenser condense. -> parse error Do we open a new bug? Is there another way that I missed? Do you agree that we should remove condenseChanges from SmalltalkImage? Cheers, #Luc

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by Sebastian Sastre

On Apr 17, 2014, at 1:54 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > 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. That historic connection is really important. I love to hear grey haired peopleâs advice :) Thanks a lot for sharing it here Eliot. > If it ain't broke don't fix it. +1 sebastian o/

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by Eliot Miranda

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

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

by Esteban Lorenzano

On 17 Apr 2014, at 18:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > On 17 Apr 2014, at 17:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> 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. > > no, that does not has sense. We need it. What we need is to improve the events we have, not to remove them. > Less than 0.1% of computer-using mankind uses mighty mouse. The rest uses regular mouses with old-fashion wheels (or trackpads, like myself). > So, removing is not a good idea. Not for VM, not for Pharo, and certainly not for Moose either. > Improve is the way to go :) > >> >> We have to get this right. Emulation of events is a bad idea. > > Yes! I agree and the way we are following is to remove emulation and transmit just raw events to the image (and let the image do the work of handling them). > Now it will take time, but we are going in that direction. ah, forget to say: I have a lot of expectation around Ronie's work on SDL2 and OSWindow interface. I provide as much support as I can. > > cheers, > Esteban > > ps: btwâ¦ scroll events also has problems in wheel-mouses, but those, Iâm not sure is a problem of VM or Pharoâ¦ I need to go deeper then (any insight would be cool) :) > >> >> Alexandre >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Apr 15, 2014, at 10:36 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>> Hi! >>> >>> Mouse wheel events are so poorly handled in Pharo, that they are not useful. >>> With Ronie we are seeing how we can better handle events with a window generated with SDL. But this is for the future. >>> >>> Is there a way to easily unable them? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >

April 17, 2014

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

by Esteban Lorenzano

Hi, On 17 Apr 2014, at 17:02, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > 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. no, that does not has sense. We need it. What we need is to improve the events we have, not to remove them. Less than 0.1% of computer-using mankind uses mighty mouse. The rest uses regular mouses with old-fashion wheels (or trackpads, like myself). So, removing is not a good idea. Not for VM, not for Pharo, and certainly not for Moose either. Improve is the way to go :) > > We have to get this right. Emulation of events is a bad idea. Yes! I agree and the way we are following is to remove emulation and transmit just raw events to the image (and let the image do the work of handling them). Now it will take time, but we are going in that direction. cheers, Esteban ps: btwâ¦ scroll events also has problems in wheel-mouses, but those, Iâm not sure is a problem of VM or Pharoâ¦ I need to go deeper then (any insight would be cool) :) > > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Apr 15, 2014, at 10:36 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Mouse wheel events are so poorly handled in Pharo, that they are not useful. >> With Ronie we are seeing how we can better handle events with a window generated with SDL. But this is for the future. >> >> Is there a way to easily unable them? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

April 17, 2014