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

Re: [Pharo-dev] Memory limit problems on Windows VM

by Eliot Miranda

Hi Oscar, On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. CallaÃº <oscar.apollo(a)gmail.com> wrote: > Hi guys, > > I'm running some experiments in Pharo. My data is aprox. 1.3GB. > When I load my image on Mac, everything works perfectly. But, when I try to > load the same image on Windows, I get this error: > > Unable to commit memory (1326649344 bytes requested) > > I tried the Pharo VM, cogMT and NBcog with and without the option > > AddressSpaceLimit = 2048 > > in the ini file > > Please help. > What OS are you using? Have you read e.g. http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).… ? -- best, Eliot

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by Eliot Miranda

On Wed, Jul 16, 2014 at 1:48 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > In the quest for a better UI framework :), I was re rereading about > delegate in Cocoa. > A delegating object will delegate certain operations to a delegate object > (check the attachment). > Now I was wondering why this is not a simple delegation they wrote: > > The delegating object sends a message only if the delegate implements > the method. It makes this discovery by invoking the NSObject method respondsToSelector: > in the delegate first. > Sad that this framework confuses delegation and forwarding. What it describes as delegation is merely forwarding. Delegation is quite different; self is bound to the delegator when running delegated methods. When (as in Self) one object delegates to another, sends to self in the second object bind to methods in the first object, the delegator. In forwarding, self is bound to the object the message is forwarded to (i.e. normal Smalltalk & ObjectiveC semantics). -- best, Eliot

July 16, 2014

Re: [Pharo-dev] Pharo Not For The Enterprise

by stepharo

On 16/7/14 17:55, Damien Cassou wrote: > On Wed, Jul 16, 2014 at 5:03 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Can we have another book? LaserGame would fit in fine too. > > I would vote to put your chapter in an existing book for now: either > UpdatedPharoByExample or EnterprisePharo. That way you benefit from > the architecture in place (the jenkins job for example). Then, we can > always move the chapter someplace else. In Fun with Pharo: the Next Fun Book :)

July 16, 2014

Re: [Pharo-dev] Pharo Not For The Enterprise

by stepharo

On 16/7/14 17:41, kilon alios wrote: > Well not everything in there is an Enterprise solution so I think it > would be better if renamed to "Pharo Bible" or "Pharo Encyclopedia" , > for example Pharo Sound is not exactly Enterprise material, though its > my favorite chapter :) Yes it should be called Pharo Limbo and once chapters are ready to get out they should be dispatched to the corresponding book > By the way great work and thanks for reminding to try this out now, I > keep forgetting. > > This can go also inside our Updated PBE as a nice chapter, its after > all ... an example ;) I would prefer to keep Pharo by Example as close as the current one and produce - Fun With Pharo - Pharo for the entreprise - Laser Game Tutorial > > > On Wed, Jul 16, 2014 at 6:03 PM, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > Can we have another book? LaserGame would fit in fine too. > > I've started writing a chapter explaining PhlappyBird > > !PhlappyBird > > PhlappyBird is a smalltalk clone of the well-known little game. It > is a nice example of building a small Morphic application and well > suited for a tutorial. > +file://figures/PhlappyBird.png+ > > !! The top level window > > The top level window is a SystemWindow containing a game scene and > a button to restart the game. The scene will be recreated when the > button is pressed, and it is easiest to just have an instance > variable refering to it. > > [[[ > SystemWindow subclass: #PhlappyBirdGame > instanceVariableNames: 'scene' > classVariableNames: '' > category: 'PhlappyBird' > ]]] > > The game can be started by typing ==PhlappyBirdGame play <DoIt>==. > That creates a new game, opens it window in te world and sets its > width and height. > > [[[ > PhlappyBirdGame class>>play > PhlappyBirdGame new > openInWorld; > extent: 298@510. > ]]] > > In Pharo, ==new== calls ==initialize==. In the initialization, the > scene is created, the window is given a title and made > unresizable, the scene is told that when the space key is pressed > the bird should flap its wings and the restart button is added. > > [[[ > PhlappyBirdGame>>initialize > super initialize. > scene := self newScene. > self > setLabel: 'Phlappy Bird'; > beUnresizeable; > on: Character space do: [ scene flapTheBird ]; > addMorph: self createRestartButton > frame: (0(a)0.92 corner: 1@1) > ]]]. > > The ==addMorph:frame:== message is the morphic implementation of > the composite pattern. All Morphs can be composites. Most Morphs > use ==addMorph:fullFrame:== where the frame provides a layout > object, but a SystemWindow adds a simpler variant where a > proportional layout can be used with a rectangle with values > between 0 and 1 for the relative size. The button takes the 8% of > the bottom part of the user-draw area of the window. > The scene takes the rest. > > [[[ > PhlappyBirdGame>>newScene > | newScene | > newScene := Scene new. > self > addMorph: newScene > frame: (0@0 corner: 1(a)0.92) > ^ newScene > ]]] > > !!! The restart button > The button is a ==PluggableButtonMorph==. A PluggableButtonMorph > is a themeable button, that takes colors, borders and corner > radius from the currently selected theme. > > ;SystemWindow is also a theme-aware object. > > [[[ > PhlappyBirdGame>>createRestartButton > ^ PluggableButtonMorph > on: self > getState: nil > action: #restartPressed > label: #restartButtonLabel > ]]] > > The PluggableButtonMorph will react to being clicked by performing > the ==restartPressed== action method on its model (self), and gets > its label from the ==restartButtonLabel== method. The label is > just a string. A PluggableButtonMorph can show a binary value, and > by ==setState: nil== it is indicated that this is just a plain button. > > [[[ > PhlappyBirdGame>>restartButtonLabel > ^ 'New Game' > ]]] > > When the button is pressed, the current scene is removed as > submorph from the window and a new one is created and added. > [[[ > PhlappyBirdGame>>restartPressed > scene delete. > scene := self newScene. > ]]] > >

July 16, 2014

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Hi Ben, Steph, On Wed, Jul 16, 2014 at 4:31 AM, Ben Coman <btc(a)openinworld.com> wrote: > stepharo wrote: > >> Hi eliot >> >> Thanks! >> I'm really eager to read about the new become implementation. >> > > There is this... > http://www.mirandabanda.org/cogblog/2013/09/13/lazy- > become-and-a-partial-read-barrier/ yes, but I've removed all the scanning of the class table post become. So that post is inaccurate now. Steph, I plan to update the SpurMemoryManager class comment and that post soon to reflect the current design. > cheers -ben > > > I could not fully understand the following but this is exciting to know >> that you removed complexity. >> >> Stef >> >> "The read barriers on method lookup (of the methodClass association in >> super >> sends, of the superclass link, of method dictionaries, method dictionary >> arrays, >> selectors and methods is cheap. So replace scanning classes and method >> dictionaries in the class table post become with read marriewrs on >> methodClass, >> superclass and method dictionary etc on lookup. >> >> The read barrier on an object from which we are going to fetch state >> (such as a >> class or method dictionary) is essentially free on modern machines >> because the >> class index and the state very likely share a cache line, and the >> register code >> for testing is so cheap compared to memory access. Further the read >> barrier on >> selectors is cheap because the method lookup cache is effective in >> reducing the >> number of message lookups and because nil entries need no check. >> >> So nuke all the followNecessaryForwardingInMethod: machinery including >> the >> cmUsesMethodClass hack. Nuke scanClassPostBecome:effects:." >> >> >> >> >> On 15/7/14 21:58, Eliot Miranda wrote: >> >>> ...at http://www.mirandabanda.org/files/Cog/VM/VM.r3041/. >>> >>> >>> The principal changes are fixing a performance regression in the 3040 >>> VMs, fixing some Spur bugs in primitiveClone/shallowCopy, and radically >>> simplifying the Spur become implementation, >>> trading the elimination of lots of post-become class table scanning for >>> adding read barriers to class hierarchy method lookup. >>> >>> >>> CogVM source as per VMMaker.oscog-eem.820/r3041 >>> >>> Put the handling of the cloning of cogged methods in the clone: >>> implementations, >>> removing it from the primitive. Add it to the pinning clone too. >>> >>> Specialize the store check trampoline generation. >>> Move it down to the relevant object representations. >>> >>> Move setting of isRemembered flag to true into SpurGenerationScavenger>> >>> remember:. Inline possibleRootStoreInto: (given that remember: is /not/ >>> inlined. Call remember directly from the ceStoreCheckTrampoline, and >>> hence have remember: answer its argument. >>> >>> Fix localization bug. Variables in initialize methods were not >>> considered >>> references (cuz there are excluded). This caused VMMaker.oscog-eem.816's >>> extraction of zero/false vars to StackInterpreter>>#initialize to cause >>> nextPollUsecs to be localized to checkForEventsMayContextSwitch:. >>> >>> Spur: >>> Fix bug in scanClassPostBecome:effects: with new lazy >>> selector following policy by... throwing it all away. >>> >>> The read barriers on method lookup (of the methodClass association in >>> super >>> sends, of the superclass link, of method dictionaries, method dictionary >>> arrays, >>> selectors and methods is cheap. So replace scanning classes and method >>> dictionaries in the class table post become with read marriewrs on >>> methodClass, >>> superclass and method dictionary etc on lookup. >>> >>> The read barrier on an object from which we are going to fetch state >>> (such as a >>> class or method dictionary) is essentially free on modern machines >>> because the >>> class index and the state very likely share a cache line, and the >>> register code >>> for testing is so cheap compared to memory access. Further the read >>> barrier on >>> selectors is cheap because the method lookup cache is effective in >>> reducing the >>> number of message lookups and because nil entries need no check. >>> >>> So nuke all the followNecessaryForwardingInMethod: machinery including >>> the >>> cmUsesMethodClass hack. Nuke scanClassPostBecome:effects:. >>> >>> Rip out the forwardingCount: measurement code. It causes >>> bad performance regressions (due to failing inlines?) >>> >>> Clean up, e.g. replace followNonImmediateField:ofObject: >>> uses with followObjField:ofObject:. >>> >>> canPinObjects can be inlined. >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> > > -- best, Eliot

July 16, 2014

Re: [Pharo-dev] Pharo Not For The Enterprise

by stepharo

> Can we have another book? LaserGame would fit in fine too. I started Fun With Pharo :) https://github.com/SquareBracketAssociates/FunWithPharo I want to write about fun project like Boids, WebCam in Japan with Zinc and other fun stuff :) I'm converting my old tex svn into pillar git :) Feel free to add **fun** chapters :) Stef > > I've started writing a chapter explaining PhlappyBird excellent idea. > > !PhlappyBird > > PhlappyBird is a smalltalk clone of the well-known little game. It is a nice example of building a small Morphic application and well suited for a tutorial. > +file://figures/PhlappyBird.png+ > > !! The top level window > > The top level window is a SystemWindow containing a game scene and a button to restart the game. The scene will be recreated when the button is pressed, and it is easiest to just have an instance variable refering to it. > > [[[ > SystemWindow subclass: #PhlappyBirdGame > instanceVariableNames: 'scene' > classVariableNames: '' > category: 'PhlappyBird' > ]]] > > The game can be started by typing ==PhlappyBirdGame play <DoIt>==. That creates a new game, opens it window in te world and sets its width and height. > > [[[ > PhlappyBirdGame class>>play > PhlappyBirdGame new > openInWorld; > extent: 298@510. > ]]] > > In Pharo, ==new== calls ==initialize==. In the initialization, the scene is created, the window is given a title and made unresizable, the scene is told that when the space key is pressed the bird should flap its wings and the restart button is added. > > [[[ > PhlappyBirdGame>>initialize > super initialize. > scene := self newScene. > self > setLabel: 'Phlappy Bird'; > beUnresizeable; > on: Character space do: [ scene flapTheBird ]; > addMorph: self createRestartButton > frame: (0(a)0.92 corner: 1@1) > ]]]. > > The ==addMorph:frame:== message is the morphic implementation of the composite pattern. All Morphs can be composites. Most Morphs use ==addMorph:fullFrame:== where the frame provides a layout object, but a SystemWindow adds a simpler variant where a proportional layout can be used with a rectangle with values between 0 and 1 for the relative size. The button takes the 8% of the bottom part of the user-draw area of the window. > The scene takes the rest. > > [[[ > PhlappyBirdGame>>newScene > | newScene | > newScene := Scene new. > self > addMorph: newScene > frame: (0@0 corner: 1(a)0.92) > ^ newScene > ]]] > > !!! The restart button > The button is a ==PluggableButtonMorph==. A PluggableButtonMorph is a themeable button, that takes colors, borders and corner radius from the currently selected theme. > > ;SystemWindow is also a theme-aware object. > > [[[ > PhlappyBirdGame>>createRestartButton > ^ PluggableButtonMorph > on: self > getState: nil > action: #restartPressed > label: #restartButtonLabel > ]]] > > The PluggableButtonMorph will react to being clicked by performing the ==restartPressed== action method on its model (self), and gets its label from the ==restartButtonLabel== method. The label is just a string. A PluggableButtonMorph can show a binary value, and by ==setState: nil== it is indicated that this is just a plain button. > > [[[ > PhlappyBirdGame>>restartButtonLabel > ^ 'New Game' > ]]] > > When the button is pressed, the current scene is removed as submorph from the window and a new one is created and added. > [[[ > PhlappyBirdGame>>restartPressed > scene delete. > scene := self newScene. > ]]] >

July 16, 2014

Re: [Pharo-dev] Current maintainer of PharoExtras/LDAP?

by stepharo

On 16/7/14 19:02, Udo Schneider wrote: > All, > > I'm currently making some changes to the LDAP package to make it play > nicer with ActiveDirectory and SSL. Up to now all those changes were > non-intrusive to the current packages. But I'm hitting a few issues > now which would change the base packages. > > What's the policy on this? Improving :) We need stronger and better libraries. > Keeping those changes in my own fork or submitting them to a > maintainer (who?). I gave you access to the PharoExtras repo. Just add tests and build the best LDAP you want :) Make sure that everything work well and suits your needs. I'm not sure that current design is good. At least when olivier auverlot showed to me I was skeptical about the chapter we/he wrote on it. > In addition ... as far as I can see the current package is Pharo only > (was Squeak). > If "Pharo-only" is o.k. I could for instance integrate my stuff for > LDAP-over-SSL in there directly (based on Zodiac). Excellent idea. Our goal is to make sure that people can make business. > > Thanks, > > Udo > > >

July 16, 2014

Re: [Pharo-dev] About Cocoa delegate

by stepharo

Thanks I will have a look. Esteban my point is that it looks like delegates are like strategy but I wonder why all the strategies for a given facet would not have to implement the protocol. To me having isKindOf: respondTo: sucks so when a framework forces it this is even worse. Stef On 16/7/14 11:04, Esteban Lorenzano wrote: > btwâ¦ while I think cocoa fundamentals is good reading, it is marked as > a retired document. > I think the replace doc is this one: > > https://developer.apple.com/library/mac/documentation/general/conceptual/Co… > > (but since I still do not read it, I donât know if is a good replacement) > > Esteban > > On 16 Jul 2014, at 10:58, stepharo <stepharo(a)free.fr> wrote: > >> I found strange to force user to write >> >> Before invoking a delegation method, make sure the delegate >> implements it by sending it a >> >> respondsToSelector: message. >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> - (void)someMethod { >> >> if ( [delegate respondsToSelector:@selector(operationShouldProceed)] ){ >> >> if ( [delegate operationShouldProceed] ) { >> // do something appropriate >> >> } } >> >> } >> >> I'm reading also on bindings (could be like valueHolder) and >> targetAction. >> I think that I will have to read that several times :) >> >> https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/C… >> >> Stef >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> On 16/7/14 10:48, stepharo wrote: >>> Hi >>> >>> In the quest for a better UI framework :), I was re rereading about >>> delegate in Cocoa. >>> A delegating object will delegate certain operations to a delegate >>> object (check the attachment). >>> Now I was wondering why this is not a simple delegation they wrote: >>> >>> The delegating object sends a message only if the delegate >>> implements the method. It makes this discovery by invoking the >>> NSObject method respondsToSelector: in the delegate first. >>> >>> Cocoa Fundamentals Guide (TP40002974 6.0.0) >>> >> >

July 16, 2014

Current maintainer of PharoExtras/LDAP?

by Udo Schneider

All, I'm currently making some changes to the LDAP package to make it play nicer with ActiveDirectory and SSL. Up to now all those changes were non-intrusive to the current packages. But I'm hitting a few issues now which would change the base packages. What's the policy on this? Keeping those changes in my own fork or submitting them to a maintainer (who?). In addition ... as far as I can see the current package is Pharo only (was Squeak). If "Pharo-only" is o.k. I could for instance integrate my stuff for LDAP-over-SSL in there directly (based on Zodiac). Thanks, Udo

July 16, 2014

A great quote from the creator of C programming language

by kilon alios

*At least for the people who send me mail about a new language that they're designing, the general advice is: do it to learn about how to write a compiler. Don't have any expectations that anyone will use it, unless you hook up with some sort of organization in a position to push it hard. It's a lottery, and some can buy a lot of the tickets. There are plenty of beautiful languages (more beautiful than C) that didn't catch on. But someone does win the lottery, and doing a language at least teaches you something.* Dennis Ritchie <http://en.wikipedia.org/wiki/Dennis_Ritchie> (1941-2011) Creator of the C <http://en.wikipedia.org/wiki/C_language> programming language and of Unix <http://en.wikipedia.org/wiki/Unix> But then being non popular does not mean that you are not very useful.

July 16, 2014