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

Proportional Tab Stops

by J.F. Rick

Hi everyone, I'm writing for two reasons. First, I wanted to let people know that I haven't disappeared. I'm just having to take a break as I finish up with my current academic post. As I am no longer going to be there, Pharo contributions don't help the department. So, I can't justify devoting any time to Pharo. But, I'm still interested in Athens, multitouch support, and Pharo for beginners. In October, I move back to Atlanta and will start a company. At that point, I aim to be back, though I may concentrate a bit more on server technology (full version of newest QRCode specifications half way done). Second, I wanted to mention a slight annoyance and suggest a solution. Background: I taught a class on introduction / intermediate programming in Pharo the last few years. One thing I try to teach my students is to use proper indention for their code. Unlike Python (great syntax for a first language), you do not need to indent in Smalltalk for code to work properly so students don't have to properly use indention to organize their code. For tiny bits of code (as is required in introductory programming), indention is not that important but it gets more important as they advance. Even my better students often used bad indention practices, though I emphasized it in class and all sample code I gave them was properly indented. In class, I often solved problems and demonstrated code. So that students could see what I typed, I increased the size of the font (24pt standard font). Though the font increased, the tab spacing remained the same. So, when I indented with one tab, it looked much smaller than a tab would have looked on their 10pt code editor. I saw people using spaces to indent code, which I never talked about. My guess is that they were trying to replicate the amount of space that my code was indented. They saw that a tab looked too big and used spaces. A simple solution is for tab spacing in code panes to increase proportionally with the font size. I feel like suggesting that as an improvement for Pharo 4. Does that seem reasonable? Are there arguments against it? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 3, 2014

[Off Topic] PHARO - Already Dead - YouTube

by Sven Van Caekenberghe

We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE

Sept. 3, 2014

Re: [Pharo-dev] [ANN] Pointer Detective

by phil＠highoctane.be

Very nice. Now, I am wondering why some instances are where they are in my image :-) Thx for making this. Phil On Wed, Sep 3, 2014 at 4:14 AM, Ben Coman <btc(a)openinworld.com> wrote: > Mariano Martinez Peck wrote: > > Also, would be nice to filter out StrongPointerExplorerWrapper instances. > > > I disagree with that being hard coded. Either StrongPointerExplorerWrapper > weakly wraps the object it points to, and so is already handled, or it is a > candidate for preventing object garbage collection. For example, if a UI > element using StrongPointerExplorerWrapper is removed from visibility but > fails to be fully deleted. > > What might be good though is provision of a generic filtering mechanism. > Pass the candidate from-object to a user supplied block which returns a > boolean. > > cheers -ben > > > > On Tue, Sep 2, 2014 at 5:09 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> BTW , +1 to the ability of open an inspect on a node. >> >> >> On Tue, Sep 2, 2014 at 5:05 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi Ben, >>> >>> Very nice tool! Thank you very much for it. >>> >>> Question....do you think it is possible to add a feature that it >>> automatically builds the whole graph starting at target object until the GC >>> root that is holding it? In Pharo, the GC root is the special object array >>> (see #newSpecialObjectsArray). >>> So the code should basically do a loop for #pointersTo and check if one >>> of those pointers is directly one of the array. Or something like that >>> like. >>> Probably it will crash the VM hahaha. But it would be nice to track from >>> a certain object up to the GC root and see all that path in graph :) >>> >>> >>> >>> >>> >>> On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >>>> Oh yes, this is essential part of âworking with objectsâ. No? >>>> >>>> >>>> On 02 Sep 2014, at 21:37, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> > You are my hero! I was just complaining about that to Doru at ESUG. >>>> This sort of tool should be part of the standard tool set so please keep on >>>> improving it and weâll try to convince someone to integrate it :) >>>> > >>>> > Max >>>> > >>>> > On 02.09.2014, at 19:40, Ben Coman <btc(a)openInWorld.com> >>>> <btc(a)openInWorld.com> wrote: >>>> > >>>> >> greetings all, >>>> >> >>>> >> I had an itch to scratch... I find it difficult using the tree list >>>> of the standard Pointer Explorer to track down why objects aren't garbage >>>> collected. I always fear I'm not going to notice getting caught in a >>>> reference loop. So I created a tool presenting an alternative view as a >>>> directed graph. The graph incrementally builds out from the target object >>>> as you explore it. Nodes are colourised to help manage complexity. >>>> >> >>>> >> The attached snapshot is produced from evaluating the following >>>> Workspace script... >>>> >> testObject := 'END5'. >>>> >> ref1 := { testObject. nil }. >>>> >> ref2 := { ref1 }. >>>> >> ref3 := PDTestResource new heldObject: ref2. >>>> >> ref1 at: 2 put: ref3. "note the reference loop this creates" >>>> >> PointerDetective openOn: testObject. >>>> >> >>>> >> Now I expect I'm duplicating something done before, but I couldn't >>>> find anything quickly and it was an opportunity for some goal direct >>>> learning of Morphic. Thanks to Roassal an option for a spring-force layout >>>> is provided. That code was copied rather than create a dependency, and >>>> might need to be rationalized later. >>>> >> The code is a bit rough from hacking around learning how to make >>>> things work, but its functional, so its time to get it out in the open. >>>> >> >>>> >> For more information please refer to the repository home page... >>>> >> http://smalltalkhub.com/#!/~BenComan/PointerDetective >>>> >> >>>> >> cheers -ben >>>> >> <PointerDetectiveExample1.png> >>>> > >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Sept. 3, 2014

Re: [Pharo-dev] nil pointersTo size

by Yuriy Tymchuk

All âuninitialisedâ variables are pointing to nil. I think this is the case Uko On 03 Sep 2014, at 06:10, Ben Coman <btc(a)openinworld.com> wrote: > > I am curious... what does it mean that > nil PointersTo size is a large number? Intuitively I'd have thought the answer would be zero. > > Pharo build 40196 --> ~101,000 > Pharo build 30856 --> ~103,000 > Pharo build 20628 --> ~80,000 > Squeak 4.5 --> ~40,000 > > cheers -ben >

Sept. 3, 2014

nil pointersTo size

by Ben Coman

I am curious... what does it mean that nil PointersTo size is a large number? Intuitively I'd have thought the answer would be zero. Pharo build 40196 --> ~101,000 Pharo build 30856 --> ~103,000 Pharo build 20628 --> ~80,000 Squeak 4.5 --> ~40,000 cheers -ben

Sept. 3, 2014

Re: [Pharo-dev] [ANN] Pointer Detective

by Ben Coman

Sept. 3, 2014

Re: [Pharo-dev] [ANN] Pointer Detective

by Ben Coman

Thierry Goubier wrote: > Thanks Ben, > > I think this will be very helpfull :) Could you add a > ConfigurationOfPointerDetective in the meta repo to enable an easy > access? I will soon, but its a single mcz with no dependencies, so don't let that hold you back from trying it :) cheers -ben > > Thierry > > Le 02/09/2014 19:40, Ben Coman a Ã©crit : >> greetings all, >> >> I had an itch to scratch... I find it difficult using the tree list >> of the standard Pointer Explorer to track down why objects aren't >> garbage collected. I always fear I'm not going to notice getting >> caught in a reference loop. So I created a tool presenting an >> alternative view as a directed graph. The graph incrementally builds >> out from the target object as you explore it. Nodes are colourised to >> help manage complexity. >> >> The attached snapshot is produced from evaluating the following >> Workspace script... >> testObject := 'END5'. >> ref1 := { testObject. nil }. >> ref2 := { ref1 }. >> ref3 := PDTestResource new heldObject: ref2. >> ref1 at: 2 put: ref3. "note the reference loop this creates" >> PointerDetective openOn: testObject. >> >> Now I expect I'm duplicating something done before, but I couldn't >> find anything quickly and it was an opportunity for some goal direct >> learning of Morphic. Thanks to Roassal an option for a spring-force >> layout is provided. That code was copied rather than create a >> dependency, and might need to be rationalized later. >> The code is a bit rough from hacking around learning how to make >> things work, but its functional, so its time to get it out in the open. >> >> For more information please refer to the repository home page... >> http://smalltalkhub.com/#!/~BenComan/PointerDetective >> >> cheers -ben > > >

Sept. 3, 2014

Re: [Pharo-dev] Is IDE4PLC Pharo based?

by garduino

Sure! Apart of the video that show familiar windows, in the page says: "EstÃ¡ desarrollado sobre Pharo-Smalltalk 2.0" :) -- View this message in context: http://forum.world.st/Is-IDE4PLC-Pharo-based-tp4775897p4775901.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 2, 2014

Re: [Pharo-dev] [ANN] Pointer Detective

by Stephan Eggermont

Nice work! I'm getting inspired. Stephan

Sept. 2, 2014

Is IDE4PLC Pharo based?

by Sebastian Sastre

Anybody knows? https://news.ycombinator.com/item?id=8260594 sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

Sept. 2, 2014