Re: [Pharo-dev] Quitting the community
Sure but the new thing was NewValueHolder. ValueHolder per se doesn't look like impacted. Well I saw some OldValueHolder proposal but it seemed strange to me. How would you name the new thing? Is there some pattern for that kind of case? Phil Le 19 août 2014 07:52, Eliot Miranda eliot.mira...@gmail.com a écrit : It is well to remember Marshall McLuhan, The Medium is the Message, the thesis of which is that the nature of any medium has more importance than the content if that medium in shaping its effects in the users of that medium. On the medium side, email is devoid of nuance, unless smattered with emoticons, themselves a very limited sub-medium that many of us employ only partially. It is /so/ common to see an escalation of hurt emerge from an email thread started by a misreading of an email that imputed offense when none was intended. On the message side, names are important. Sentences become incomprehensible if nouns are arbitrarily rebound. ValueHolder may not be the greatest name, just as apareille a photo is clumsier than camera, but we can't just change them to frotboggle or bungswallop just because they sound more poetic. ReactiveVariable is criticizes me on the basis that it is an object that contains a variable, not a variable itself, and garner misleading, /and/ that it is a renaming of an (albeit imperfectly) already named concept, ValueHolder, and if one doesn't want to unnecessarily break others' understanding and much older Pharo and non-Pharo code that uses it one is better leaving sleeping dogs lie. HTH Eliot (phone) On Aug 18, 2014, at 8:38 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Hello guys, I am sending this email to explain why I am quiting the Pharo community, as well as the Smalltalk community. I can not bear Stephane Ducasse's behavior anymore whether at a public level or a private level. It seems that his ego is preventing him from being able to have a discussion without overreacting, being agressive, or insulting. I can not approve how Stephane is constantly talking behind my back to unleash his irrationnal wrath and to provide his very own version of the facts. I can not see how this can lead to a peaceful and respectful community where we can all have fun building a future. Therefore I will not be part of this project anymore, since the way Stephane is acting is taking away all the fun I can have interacting with all of you. It was a hard decision to take, but I can not be part of a community led by someone whose behaviour is going against all my principles. I wish to all of you to have fun, and keep me in touch if you want to have a beer someday ;) Ben
Re: [Pharo-dev] Quitting the community
So why not simply ReactiveValueHolder? Who will look for ValueHolder will find it, who will look for reactive variables will find it and it well describes the purpose of the class ;-) Cheers, -- Pavel 2014-08-19 9:25 GMT+02:00 p...@highoctane.be p...@highoctane.be: Sure but the new thing was NewValueHolder. ValueHolder per se doesn't look like impacted. Well I saw some OldValueHolder proposal but it seemed strange to me. How would you name the new thing? Is there some pattern for that kind of case? Phil Le 19 août 2014 07:52, Eliot Miranda eliot.mira...@gmail.com a écrit : It is well to remember Marshall McLuhan, The Medium is the Message, the thesis of which is that the nature of any medium has more importance than the content if that medium in shaping its effects in the users of that medium. On the medium side, email is devoid of nuance, unless smattered with emoticons, themselves a very limited sub-medium that many of us employ only partially. It is /so/ common to see an escalation of hurt emerge from an email thread started by a misreading of an email that imputed offense when none was intended. On the message side, names are important. Sentences become incomprehensible if nouns are arbitrarily rebound. ValueHolder may not be the greatest name, just as apareille a photo is clumsier than camera, but we can't just change them to frotboggle or bungswallop just because they sound more poetic. ReactiveVariable is criticizes me on the basis that it is an object that contains a variable, not a variable itself, and garner misleading, /and/ that it is a renaming of an (albeit imperfectly) already named concept, ValueHolder, and if one doesn't want to unnecessarily break others' understanding and much older Pharo and non-Pharo code that uses it one is better leaving sleeping dogs lie. HTH Eliot (phone) On Aug 18, 2014, at 8:38 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Hello guys, I am sending this email to explain why I am quiting the Pharo community, as well as the Smalltalk community. I can not bear Stephane Ducasse's behavior anymore whether at a public level or a private level. It seems that his ego is preventing him from being able to have a discussion without overreacting, being agressive, or insulting. I can not approve how Stephane is constantly talking behind my back to unleash his irrationnal wrath and to provide his very own version of the facts. I can not see how this can lead to a peaceful and respectful community where we can all have fun building a future. Therefore I will not be part of this project anymore, since the way Stephane is acting is taking away all the fun I can have interacting with all of you. It was a hard decision to take, but I can not be part of a community led by someone whose behaviour is going against all my principles. I wish to all of you to have fun, and keep me in touch if you want to have a beer someday ;) Ben
Re: [Pharo-dev] Quitting the community
ReactiveHolder ? Phil On Tue, Aug 19, 2014 at 7:52 AM, Eliot Miranda eliot.mira...@gmail.com wrote: It is well to remember Marshall McLuhan, The Medium is the Message, the thesis of which is that the nature of any medium has more importance than the content if that medium in shaping its effects in the users of that medium. On the medium side, email is devoid of nuance, unless smattered with emoticons, themselves a very limited sub-medium that many of us employ only partially. It is /so/ common to see an escalation of hurt emerge from an email thread started by a misreading of an email that imputed offense when none was intended. On the message side, names are important. Sentences become incomprehensible if nouns are arbitrarily rebound. ValueHolder may not be the greatest name, just as apareille a photo is clumsier than camera, but we can't just change them to frotboggle or bungswallop just because they sound more poetic. ReactiveVariable is criticizes me on the basis that it is an object that contains a variable, not a variable itself, and garner misleading, /and/ that it is a renaming of an (albeit imperfectly) already named concept, ValueHolder, and if one doesn't want to unnecessarily break others' understanding and much older Pharo and non-Pharo code that uses it one is better leaving sleeping dogs lie. HTH Eliot (phone) On Aug 18, 2014, at 8:38 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Hello guys, I am sending this email to explain why I am quiting the Pharo community, as well as the Smalltalk community. I can not bear Stephane Ducasse's behavior anymore whether at a public level or a private level. It seems that his ego is preventing him from being able to have a discussion without overreacting, being agressive, or insulting. I can not approve how Stephane is constantly talking behind my back to unleash his irrationnal wrath and to provide his very own version of the facts. I can not see how this can lead to a peaceful and respectful community where we can all have fun building a future. Therefore I will not be part of this project anymore, since the way Stephane is acting is taking away all the fun I can have interacting with all of you. It was a hard decision to take, but I can not be part of a community led by someone whose behaviour is going against all my principles. I wish to all of you to have fun, and keep me in touch if you want to have a beer someday ;) Ben
[Pharo-dev] example custom mouse events
It took a bit of hunting around to discover how to use the custom hooks for mouse event, and I needed to make some examples to prove how it worked. I thought others might find this interesting. It just outputs to Transcript for each of the following events. Check the class comments for usage. * handlesMouseDown - mouseDown, mouseUp, mouseMove, startDrag, click, doubleClick, doubleClickTimeout. * handlesMouseStillDown - mouseStillDown. * handlesMouseOver - mouseEnter, mouseLeave. * handlesMouseOverDragging - mouseEnterDragging, mouseLeaveDragging. Anyone know anything more to add? cheers -ben ExampleMouseEvents-BenComan.1.mcz Description: Binary data
[Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] [Esug-list] Quitting the community
No great things are achieved without great characters, Stephan has been doing a great long term effort of maintaining research budgets for Smalltalk and pushing a viable open source solution for it while the situation was pretty difficult. Like many of us he has some rough edges to and we shouldn’t forget that each of us is driven by ambition, fear and frustration. I really respect Stephan, but I also sympathise with you as I did with Janko some month’s ago. Nobody cares about any details, what we do care about however is that you would be lost for Smalltalk after such a great job There is so much more to Smalltalk then just Pharo and some of these move considerably …. Hope you reconsider at least that part of your decision. Take care, @+Maarten, On 18 Aug 2014, at 11:36, Tudor Girba tu...@tudorgirba.com wrote: Hi Ben, Thanks for letting us know. I am sorry you feel this way, but I believe your presentation of the situation is both unfair and unfortunate. You are obviously referring to issues that are of personal nature, and as outsiders we are left with only an ugly feeling without being able to either understand or fix anything. I was actually having fun until your email, and as far as I can tell, others were having fun as well. I am not sure what the intention of your email was, but at least for me, your mail did manage to spoil the fun for a second. I appreciate the work you put in Pharo, I respect your decision, but I do not sympathize with your behavior. Good luck, Doru On Mon, Aug 18, 2014 at 8:38 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Hello guys, I am sending this email to explain why I am quiting the Pharo community, as well as the Smalltalk community. I can not bear Stephane Ducasse's behavior anymore whether at a public level or a private level. It seems that his ego is preventing him from being able to have a discussion without overreacting, being agressive, or insulting. I can not approve how Stephane is constantly talking behind my back to unleash his irrationnal wrath and to provide his very own version of the facts. I can not see how this can lead to a peaceful and respectful community where we can all have fun building a future. Therefore I will not be part of this project anymore, since the way Stephane is acting is taking away all the fun I can have interacting with all of you. It was a hard decision to take, but I can not be part of a community led by someone whose behaviour is going against all my principles. I wish to all of you to have fun, and keep me in touch if you want to have a beer someday ;) Ben -- www.tudorgirba.com Every thing has its own flow ___ Esug-list mailing list esug-l...@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
+1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] Stack size for compiled methods (issue 13854 Crash/hang on array access)
Thank you eliot, 2014-08-19 7:29 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Hi Nicolai, the stack starts as deep as the method's number of temporaries, ok, which is the sum of the number of arguments ok, plus the number of temporary variables that can exist in the stack ok (what does can exist in the stack mean? They always do?) plus one if there are any closed-over temporary variables that need to be in an indirection vector. Then as execution proceeds the receiver and arguments are pushed on the stack, and are replaced by intermediate results by sends it by the create array bytecode. So, for a method with no blocks, the stack is just the number of temporaries plus the number of args for the message send with the maximum number of args? Any blocks within the method start with the sum of their number of arguments, their number of copied values (temp values they access read-only) plus their local temporaries. But this is not just added to the stack size, right? I have a method with 9 local temporaris and a block in this method with 8 local temporaries and the frameSize is still 16, (with the old compiler/ 56 with the new compiler). So, method and block local temporaries not just sum up? I tried different variations - numberOfMethod temps smaller/equal/greater numberOfBlockTemp - no/some/all method temporaries are accessed in the block closure. But I can not see a pattern :) In the method and each block scope stack depth is the hence the sum of the number of temporaries plus the max execution depth. And the method's depth is the max of the method and that of any blocks within it. What is the execution depth of a method ? The number of nested blocks? Then if that depth is 17 or greater it gets the LargeFrame flag set which means the VM allocates a 56 slot context, the compiler raising an error if the depth is greater than 56. HTH Eliot (phone) Here are two carefully handcrafted methods :) fooSmall |t1 t2 t3 t4 t5 t6 t7 t8| t1:=1. t2:=2. t3:=3. t4:=4. t5:=5. t6:=6. t7:=7. t8:= 8. t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| b1:=1. b2:=2. b3:=3. b4:=4. c1:=1. c2:=2. c3:=3. c4:=4. x:=1. x+t1 + b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 fooLarge |t1 t2 t3 t4 t5 t6 t7| t1:=1. t2:=2. t3:=3. t4:=4. t5:=5. t6:=6. t7:=7. t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| b1:=1. b2:=2. b3:=3. b4:=4. c1:=1. c2:=2. c3:=3. c4:=4. x:=1. x+t1 +t2 + t3 + t4 + t5+ b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 They differ only in the number of tempraries (t1-t8 / t1-t7) and the number of copied values for the block closure (1 / 5). with the old compiler: fooSmall frameSize - 16 fooLarge frameSize - 56 the opal compiler computes the opposite sizes fooSmall frameSize - 56 fooLarge frameSize - 16 I am confused. On Aug 18, 2014, at 11:32 PM, Nicolai Hess nicolaih...@web.de wrote: Hi, on what depends the stack size for a compiled method? I try to figure out, why the old compiler and the opal compile generate different compiled method headers. I think this comes from a wrong stack size computed by opal, but I can not figure out how the stack size is computed. Old Compiler PolygonMorph#lineSegmentsDo: header - primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 56 Opal compiler: PolygonMorph#lineSegmentsDo: header - primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 16
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
+100 On Tue, Aug 19, 2014 at 11:37 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: +1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
ah, I also will add zeroconf for pharo-minimal :P On 19 Aug 2014, at 11:37, Yuriy Tymchuk yuriy.tymc...@me.com wrote: +1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
Centos ? Le 19 août 2014 13:19, Esteban Lorenzano esteba...@gmail.com a écrit : ah, I also will add zeroconf for pharo-minimal :P On 19 Aug 2014, at 11:37, Yuriy Tymchuk yuriy.tymc...@me.com wrote: +1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
is different problem. most probably we will not have zeroconf for centos anytime soon. but we will have builds for centos compatible vms (downloadable, but not zercoconf), that’s for sure :) (yeah, I know, I promised that to you like months ago, but I’ve been busy. I can just say the issue it is finally arriving to the top of the stack :P) Esteban On 19 Aug 2014, at 12:20, p...@highoctane.be wrote: Centos ? Le 19 août 2014 13:19, Esteban Lorenzano esteba...@gmail.com a écrit : ah, I also will add zeroconf for pharo-minimal :P On 19 Aug 2014, at 11:37, Yuriy Tymchuk yuriy.tymc...@me.com wrote: +1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] Stack size for compiled methods (issue 13854 Crash/hang on array access)
Hoi Eliot-- [great explanation of method/block stack depth] Cool, is this viewable from an in-system tool somewhere (even if only a documentation method in a class browser)? thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
On Tue, Aug 19, 2014 at 1:24 PM, Esteban Lorenzano esteba...@gmail.com wrote: is different problem. most probably we will not have zeroconf for centos anytime soon. but we will have builds for centos compatible vms (downloadable, but not zercoconf), that’s for sure :) (yeah, I know, I promised that to you like months ago, but I’ve been busy. I can just say the issue it is finally arriving to the top of the stack :P) Good, as I was looking at RPM packaging and yum repos. Maybe can we work a bit together on that. Phil Esteban On 19 Aug 2014, at 12:20, p...@highoctane.be wrote: Centos ? Le 19 août 2014 13:19, Esteban Lorenzano esteba...@gmail.com a écrit : ah, I also will add zeroconf for pharo-minimal :P On 19 Aug 2014, at 11:37, Yuriy Tymchuk yuriy.tymc...@me.com wrote: +1 On 19 Aug 2014, at 11:16, Max Leske maxle...@gmail.com wrote: I don’t need them. On 19.08.2014, at 11:17, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] Quitting the community
Hi Ben, first: I think it is not a secret that we appreciate any work you did so far for Pharo and our community. Still I do not like the mail you have written, because: - It gives a false impression of the community itself and leaves us back once more with questions (especially as most of us were not part of the conflict). - You associate the behavior of one member of the community (be it wrong or right) with the community itself as you now decided to leave and will not continue to move with us forward again. You should really rethink your decision: 1. Life is much, much too short for such hazzles! 2. To give the community and Pharo a chance to move forward. Remember that Pharo is also YOURS. You should also give yourself the chance to keep the investments already done from your side here like Nautilus, Spec and various other contributions. They already made a difference and I'm sure that if you decide to stay you would influence Pharo development even more in the future. 3. See 1. Regarding the case we (as a community) can only judge on things we read - but not on what happened behind the scenes or in direct contact between members. As it looks more like a personal conflict between you and Stef you both have to find a solution or arrangement. If you keep you decision to leave we have to and will respect it. I wished you both would have a beer and settle down on the conflict, especially because there is point 1... As a side note: I personally would keep ValueHolder as it is a well known concept. If we want to be heretic with Smalltalk we could also rename Object into Thing. ;) I think we have a board to decide about different technical ideas (even when it is about naming). If that does not work we should setup a voting system. But we should never let the conflicts get too personal. Did I already mention that life is much too short for such things ...? Thanks T.
Re: [Pharo-dev] Quitting the community
Torsten Bergmann wrote I personally would keep ValueHolder as it is a well known concept Although it's extremely corollary to the purpose of this thread, since it keeps coming up, I just want to remind that the point of the original ValueHolder-rename discussion (in which no one said let's keep ValueHolder) was that a quick google search seemed to show that Value Holder does NOT mean what we're using it to mean. - Cheers, Sean -- View this message in context: http://forum.world.st/Quitting-the-community-tp4773730p4773842.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] example custom mouse events
good idea. We were discussing with alain about handles and handle because in bloc he is used wantsMouseDown instead handlesMouseDown. Stef On 19/8/14 09:17, Ben Coman wrote: It took a bit of hunting around to discover how to use the custom hooks for mouse event, and I needed to make some examples to prove how it worked. I thought others might find this interesting. It just outputs to Transcript for each of the following events. Check the class comments for usage. * handlesMouseDown - mouseDown, mouseUp, mouseMove, startDrag, click, doubleClick, doubleClickTimeout. * handlesMouseStillDown - mouseStillDown. * handlesMouseOver - mouseEnter, mouseLeave. * handlesMouseOverDragging - mouseEnterDragging, mouseLeaveDragging. Anyone know anything more to add? cheers -ben
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
Is removing history actually a good thing? Are those conveniences creating any actual problem by standing there? What if someone want to take a look at the past? On Aug 19, 2014, at 6:17 AM, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] I want to remove zeroconf for 1.2, 1.3 and 1.4
for taking a look at the past the images are still available and will remain like that. what will not be available anymore are just the zeroconf scripts. And yes, cleaning time to time is a good idea, IMO. Otherwise we will end with infinite listings of things that no one use, left there just in case someone, in a hypothetic day, decides to make archeology :) Esteban On 19 Aug 2014, at 16:07, Sebastian Sastre sebast...@flowingconcept.com wrote: Is removing history actually a good thing? Are those conveniences creating any actual problem by standing there? What if someone want to take a look at the past? On Aug 19, 2014, at 6:17 AM, Esteban Lorenzano esteba...@gmail.com wrote: Hi, right now there zeroconf scripts for pharo 1.2-1.4 that I do not think anyone is using it. Can I remove them? cheers, Esteban
Re: [Pharo-dev] Digging to understand Cmd+Click and Ctrl+Click
Hi guille I was cleaning the event and we were slow to integrate the refactoring we did with igor. And now this is obsolete because there is OSWindow coming. We are about to integrate OSWindow code and soon or later we will have probably to change the processEvent: code. Stef On 18/8/14 17:33, Guillermo Polito wrote: Hi! Most of you already know that in Mac, if you do cmd+click on a class name or a selector, you get to browse the class or the implementors of the method. Now, most of you know that it does not work on linux :). So I was digging today and I'll share a bit here what I found... First, the navigation through cmd+click is managed by the TextAttribute subclasses, in particular TextLink, TextClassLink and TextMethodLink. And these are the important methods: TextLinkmayActOnEvent: anEvent ^ anEvent isMouseUp and: [ anEvent commandKeyPressed ] TextClassLinkactOnClick: anEvent for: target in: aParagraph editor: anEditor anEvent shiftPressed ifFalse: [ anEditor browseClassFrom: self className ] ifTrue: [ anEditor referencesTo: self className ]. ^ true And another similar in TextMethodLink. Now, the first thing I tried was to add a or: [ anEvent controlKeyPressed ] into the first method. Guess what? That did not work. So I noticed a weird behavior. - On mac: When you do cmd+click, the text morph, if it was not selected, gets selected on mouse down, and on mouse up it gets deselected and the class is browsed. - On linux: when you do a ctrl+click, the text morph never gets selected on the first place. And that's why it never handles the mouseUp:. Just check: MorphhandleMouseUp: anEvent System level event handling. anEvent wasHandled ifTrue: [^self]. not interested *== anEvent hand mouseFocus == self ifFalse: [^self]. Not interested in other parties* So... the question is, why is the text morph not getting the focus? Well, it turns out that morphic decodes a Ctrl+click as a blueButton. So in the method MorphhandlerForMouseDown: the execution differs between mac and linux. And weirder, the event that arrives there, is modified by some strange table that I hate. So the event has a SHIFT, which I didn't press! That shift gets introduced in the event in here: InputEventSensorprocessEvent: evt ... ... type = EventTypeMouse ifTrue: [ Transmogrify the button state according to the platform's button map definition *evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1).* Map the mouse buttons depending on modifiers *evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)).* So much FUN! Well, so far I do not know how to solve it. But I know I do not like the One table to decode strangely bits that should work for all platforms but it works just for one of them approach :) I'll try to follow this later, but if someone wants to help, I welcome it :) Guille
Re: [Pharo-dev] Initial versions for OSWindow and Woden
Ronie Salgado wrote For Mac OS X, I don't have one for testing. But Alex is going allow me to borrow one for some time. So be patience. Any progress? I can help with testing... - Cheers, Sean -- View this message in context: http://forum.world.st/Initial-versions-for-OSWindow-and-Woden-tp4761069p4773866.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Stack size for compiled methods (issue 13854 Crash/hang on array access)
Hi Nicolai, On Aug 19, 2014, at 11:58 AM, Nicolai Hess nicolaih...@web.de wrote: Thank you eliot, 2014-08-19 7:29 GMT+02:00 Eliot Miranda eliot.mira...@gmail.com: Hi Nicolai, the stack starts as deep as the method's number of temporaries, ok, which is the sum of the number of arguments ok, plus the number of temporary variables that can exist in the stack ok (what does can exist in the stack mean? They always do?) Not necessarily. The closure implementation moves temps that need it into an indirect temp vector. See eg my blog on the closure compiler. http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ plus one if there are any closed-over temporary variables that need to be in an indirection vector. Then as execution proceeds the receiver and arguments are pushed on the stack, and are replaced by intermediate results by sends it by the create array bytecode. So, for a method with no blocks, the stack is just the number of temporaries plus the number of args for the message send with the maximum number of args? No. What about this: ^Point x: 1 y: (self a: 1 b: 2 c: 3) Before sending a:b:c: the stack is Point 1 self 1 2 3 Any blocks within the method start with the sum of their number of arguments, their number of copied values (temp values they access read-only) plus their local temporaries. But this is not just added to the stack size, right? I have a method with 9 local temporaris and a block in this method with 8 local temporaries and the frameSize is still 16, (with the old compiler/ 56 with the new compiler). So, method and block local temporaries not just sum up? I tried different variations - numberOfMethod temps smaller/equal/greater numberOfBlockTemp - no/some/all method temporaries are accessed in the block closure. But I can not see a pattern :) May be a bug in the old compiler. The stack size is the max of the separate sizes in the method and each block. In the method and each block scope stack depth is the hence the sum of the number of temporaries plus the max execution depth. And the method's depth is the max of the method and that of any blocks within it. What is the execution depth of a method ? The number of nested blocks? No, it is how many things it pushes in the stack at the deepest point. See my example above. Then if that depth is 17 or greater it gets the LargeFrame flag set which means the VM allocates a 56 slot context, the compiler raising an error if the depth is greater than 56. HTH Eliot (phone) Here are two carefully handcrafted methods :) fooSmall |t1 t2 t3 t4 t5 t6 t7 t8| t1:=1. t2:=2. t3:=3. t4:=4. t5:=5. t6:=6. t7:=7. t8:= 8. t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| b1:=1. b2:=2. b3:=3. b4:=4. c1:=1. c2:=2. c3:=3. c4:=4. x:=1. x+t1 + b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 fooLarge |t1 t2 t3 t4 t5 t6 t7| t1:=1. t2:=2. t3:=3. t4:=4. t5:=5. t6:=6. t7:=7. t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| b1:=1. b2:=2. b3:=3. b4:=4. c1:=1. c2:=2. c3:=3. c4:=4. x:=1. x+t1 +t2 + t3 + t4 + t5+ b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 They differ only in the number of tempraries (t1-t8 / t1-t7) and the number of copied values for the block closure (1 / 5). with the old compiler: fooSmall frameSize - 16 fooLarge frameSize - 56 the opal compiler computes the opposite sizes fooSmall frameSize - 56 fooLarge frameSize - 16 Looks like a bug in the Opal compiler :-). Well found. I am confused. No you're not. You've found a bug. Now find its cause On Aug 18, 2014, at 11:32 PM, Nicolai Hess nicolaih...@web.de wrote: Hi, on what depends the stack size for a compiled method? I try to figure out, why the old compiler and the opal compile generate different compiled method headers. I think this comes from a wrong stack size computed by opal, but I can not figure out how the stack size is computed. Old Compiler PolygonMorph#lineSegmentsDo: header - primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 56 Opal compiler: PolygonMorph#lineSegmentsDo: header - primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 16 Eliot (phone)
