- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by Sean P. DeNigris

Tudor Girba-2 wrote > And it works great :) >> Not too much progress. Don't worry. I added a morphic based fallback to >> woden if OSWindow is not supported. Ah, so "not on Mac yet" only applied to OSWindow? What would it take to have that working? Maybe I can help... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Initial-versions-for-OSWindow-and-Woden-tp4761069p477… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 20, 2014

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by Tudor Girba

And it works great :) Doru On Wed, Aug 20, 2014 at 11:58 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Any progress? I can help with testing... > > Not too much progress. Don't worry. I added a morphic based fallback to > woden if OSWindow is not supported. > > Greetings, > Ronie > > > 2014-08-19 18:00 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > 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-tp4761069p477… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 20, 2014

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by Ronie Salgado

> Any progress? I can help with testing... Not too much progress. Don't worry. I added a morphic based fallback to woden if OSWindow is not supported. Greetings, Ronie 2014-08-19 18:00 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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-tp4761069p477… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 20, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 1944a9: 40175

by Marcus Denker

13877 Clean up Settings related to Code Browsing https://pharo.fogbugz.com/f/cases/13877 13855 Small critique cleanup of Tool-Base https://pharo.fogbugz.com/f/cases/13855 On 20 Aug 2014, at 09:37, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 1944a9297a89dc60907c536302648c6032b09a4e > https://github.com/pharo-project/pharo-core/commit/1944a9297a89dc60907c5363… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2014-08-20 (Wed, 20 Aug 2014) > > Changed paths: > M AST-Core.package/RBConfigurableFormatter.class/class/settings/settingsOn_.st > R AST-Core.package/RBProgramNode.class/class/settings/settingsOn_.st > M Nautilus.package/Nautilus.class/class/settings/nautilusSettingsOn_.st > M Refactoring-Changes.package/RBRefactoryChangeManager.class/class/settings/settingsOn_.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script174.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40174.st > M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > M StartupPreferences.package/StartupPreferencesLoader.class/class/setting/startupPreferencesSettingsOn_.st > M Tool-Base.package/AbstractMethodReferenceConverter.class/class/instance creation/methodReference_referencesList_.st > M Tool-Base.package/AbstractTool.class/class/private/requestProtocolNameFor_initialAnswer_.st > M Tool-Base.package/AbstractTool.class/instance/category/removeCategory_inClass_.st > M Tool-Base.package/AbstractTool.class/instance/class/browseClassRefsOf_.st > M Tool-Base.package/AbstractTool.class/instance/class/createInitializerWithInstVarsOf_.st > M Tool-Base.package/AbstractTool.class/instance/class/removeClass_.st > M Tool-Base.package/AbstractTool.class/instance/class/removeClasses_.st > M Tool-Base.package/AbstractTool.class/instance/class/showUnreferencedClassVarsOf_.st > M Tool-Base.package/AbstractTool.class/instance/class/showUnreferencedInstVarsOf_.st > M Tool-Base.package/AbstractTool.class/instance/group/mergeGroups_.st > M Tool-Base.package/AbstractTool.class/instance/method/findMethodIn_.st > M Tool-Base.package/AbstractTool.class/instance/method/removeMethods_inClass_.st > M Tool-Base.package/AbstractTool.class/instance/package/findPackageIn_.st > M Tool-Base.package/SearchFacade.class/class/class search/classSearchIn_.st > M Tool-Base.package/SearchFacade.class/class/message search/messageSearchIn_.st > M Tool-Base.package/SearchFacade.class/class/package search/packageSearchIn_.st > M Tool-Base.package/SearchFacade.class/class/protocol search/protocolSearchIn_.st > M Tool-Base.package/SearchFacade.class/class/rpackage search/rPackageSearchIn_.st > M Tool-Base.package/extension/SystemNavigation/instance/browseMessageList_name_autoSelect_refreshingBlockSelector_.st > M Tool-Base.package/extension/SystemNavigation/instance/browseMethodsWithString_matchCase_.st > M Tool-Base.package/extension/SystemNavigation/instance/chooseInstVarFrom_thenDo_.st > > Log Message: > ----------- > 40175 > > http://files.pharo.org/image/40/40175.zip > >

Aug. 20, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40175 Home: https://github.com/pharo-project/pharo-core

Aug. 20, 2014

[pharo-project/pharo-core] 1944a9: 40175

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1944a9297a89dc60907c536302648c6032b09a4e https://github.com/pharo-project/pharo-core/commit/1944a9297a89dc60907c5363… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-20 (Wed, 20 Aug 2014) Changed paths: M AST-Core.package/RBConfigurableFormatter.class/class/settings/settingsOn_.st R AST-Core.package/RBProgramNode.class/class/settings/settingsOn_.st M Nautilus.package/Nautilus.class/class/settings/nautilusSettingsOn_.st M Refactoring-Changes.package/RBRefactoryChangeManager.class/class/settings/settingsOn_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script174.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40174.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M StartupPreferences.package/StartupPreferencesLoader.class/class/setting/startupPreferencesSettingsOn_.st M Tool-Base.package/AbstractMethodReferenceConverter.class/class/instance creation/methodReference_referencesList_.st M Tool-Base.package/AbstractTool.class/class/private/requestProtocolNameFor_initialAnswer_.st M Tool-Base.package/AbstractTool.class/instance/category/removeCategory_inClass_.st M Tool-Base.package/AbstractTool.class/instance/class/browseClassRefsOf_.st M Tool-Base.package/AbstractTool.class/instance/class/createInitializerWithInstVarsOf_.st M Tool-Base.package/AbstractTool.class/instance/class/removeClass_.st M Tool-Base.package/AbstractTool.class/instance/class/removeClasses_.st M Tool-Base.package/AbstractTool.class/instance/class/showUnreferencedClassVarsOf_.st M Tool-Base.package/AbstractTool.class/instance/class/showUnreferencedInstVarsOf_.st M Tool-Base.package/AbstractTool.class/instance/group/mergeGroups_.st M Tool-Base.package/AbstractTool.class/instance/method/findMethodIn_.st M Tool-Base.package/AbstractTool.class/instance/method/removeMethods_inClass_.st M Tool-Base.package/AbstractTool.class/instance/package/findPackageIn_.st M Tool-Base.package/SearchFacade.class/class/class search/classSearchIn_.st M Tool-Base.package/SearchFacade.class/class/message search/messageSearchIn_.st M Tool-Base.package/SearchFacade.class/class/package search/packageSearchIn_.st M Tool-Base.package/SearchFacade.class/class/protocol search/protocolSearchIn_.st M Tool-Base.package/SearchFacade.class/class/rpackage search/rPackageSearchIn_.st M Tool-Base.package/extension/SystemNavigation/instance/browseMessageList_name_autoSelect_refreshingBlockSelector_.st M Tool-Base.package/extension/SystemNavigation/instance/browseMethodsWithString_matchCase_.st M Tool-Base.package/extension/SystemNavigation/instance/chooseInstVarFrom_thenDo_.st Log Message: ----------- 40175 http://files.pharo.org/image/40/40175.zip

Aug. 20, 2014

Re: [Pharo-dev] [Vm-dev] Re: Initial versions for OSWindow and Woden

by Igor Stasenko

On 31 May 2014 14:42, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Sat, May 31, 2014 at 08:34:47PM +0800, btc(a)openinworld.com wrote: > > > > Hi Ronie, This is really exciting (and I've cross-posted to vm-dev). I > > guess this will help multi-monitor displays to have a window on each > > monitor? > > > > Ronie Salgado wrote: > > >Hello There, > > > > > >I have been working in OSWindow, which is a cross platform API for > > >dealing with native operating system windows. This API requires using > > >a custom VM and the library SDL2. > > > > > >With this API, even the main Pharo window is handled almost completely > > >in image side using NativeBoost. > > > > > >The only support required from the VM is a small periodical check in > > >the heartbeat about the presence of events. This no more than 10 lines > > >of code. > > > > Is there much you needed to change/delete from the existing VM window > > initialization. Since the VM is shared with other Smalltalk platforms, > > how compatible would this be to maintain in parallel with the existing > > VM windows initialization? > > cheers -ben > > > > What are the 10 lines of code required to provide the VM support? > > speaking about numbers, it is like + 10 lines of new code in C and - 10000 lines of old code in C in exchange of 1/100 of smalltalk code in image. sure, numbers are not precise, but you can just make a diff in git to measure. The overall idea is to let the image decide what is the best way to do i/o with OS windowing API (if it has one), not the VM. Dave > -- Best regards, Igor Stasenko.

Aug. 20, 2014

Re: [Pharo-dev] Stack size for compiled methods (issue 13854 Crash/hang on array access)

by Eliot Miranda

Hi Nicolai, On Aug 19, 2014, at 11:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Thank you eliot, > > > 2014-08-19 7:29 GMT+02:00 Eliot Miranda <eliot.miranda(a)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 <nicolaihess(a)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)

Aug. 19, 2014

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by Sean P. DeNigris

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-tp4761069p477… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2014

Re: [Pharo-dev] Digging to understand Cmd+Click and Ctrl+Click

by stepharo

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: > > TextLink>>mayActOnEvent: anEvent > ^ anEvent isMouseUp and: [ anEvent commandKeyPressed ] > > TextClassLink>>actOnClick: 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: > > Morph>>handleMouseUp: 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 Morph>>handlerForMouseDown: 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: > > InputEventSensor>>processEvent: 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

Aug. 19, 2014