February 2015 - Pharo-users

Relationship between Morph and Canvas

by nacho

Hi, I've been digging and inspecting all the classes related to Morphic. But there's something that I don't happen to figure out. Morph has a method drawOn: aCanvas aCanvas fillRectangle: self bounds fillStyle: self fillStyle borderStyle: self borderStyle Which if it's not overridden by a subclass of Morph makes it possible to still instantiate a Morph -the classic blue rectangle. Now aCanvas is obviously an instance of FormCanvas or some other subclasses of Canvas. But the question is, where does Morph create such instance of FormCanvas? How does this work? I'm getting all wrong? I read the documentation available but I can't grasp it from what I have read. Thanks in advance for your help best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Relationship-between-Morph-and-Canvas-tp4804251.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 6, 2015

CFP - IWST 2015

by jannik laval

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST15 â International Workshop on Smalltalk Technologies Brescia, Italy; July 15, 2015 http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_… ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: April 10th, 2015 Notification deadline: May 20th, 2015 Workshop : July 15th, 2015 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst2015 ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Feb. 6, 2015

Re: [Pharo-users] Cleaning code completition's namespace

by Tudor Girba

Hi, On Tue, Feb 3, 2015 at 6:39 PM, Laura Risani <laura.risani(a)gmail.com> wrote: > I'm using v3, and the #Spotlight (class name) that comes with it. > > I didn't know about Spotter of v4 before your comment. I've just tried it, > it could be handy for some specific situations, after i manually tweak its > non-sense whiteness which somewhy escapes global theme defaults (lovely > dark theme), i'll give it a try. > In the latest Pharo 4 Spotter works properly with the Dark Theme. Yet to the end of shortcuting accessing methods/classes i found Spotlight to > be more direct and keystroke cheap. > Could you elaborate? Where do you see the difference? What do you mean by "more direct"? Cheers, Doru > Saludos > > On Tue, Feb 3, 2015 at 1:28 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi! >> >> Spotlight or Spotter? Which version of Pharo are you using? >> >> I ask because the old Spotlight should be using the same code completion >> mechanism => it should appear/disappear from both at the same time... >> >> As for spotter, I don't have an answer now :) >> >> Saludos, >> Guille >> >> El Tue Feb 03 2015 at 5:24:26 PM, Laura Risani <laura.risani(a)gmail.com> >> escribiÃ³: >> >> Thank you all for your answers. >>> >>> Hi Guille , >>> >>> Nice solution! It worked perfectly for Code Completition! >>> >>> Yet the obsolete symbols (class names and selectors) keep showing in >>> Spotlight, but i guess this is too implementation specific. I will step >>> through its execution to try to find out how it works. >>> >>> Best, >>> Laura >>> >>> >>> >>> On Mon, Feb 2, 2015 at 8:39 AM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Well yes, but GCs are happening all the time :). So the problem is that >>>> someone is keeping a strong reference on the symbol. >>>> >>>> I tried the following: >>>> >>>> - create a method named #unusedUnexpectedMessage: That came up in the >>>> auto completion, ok >>>> - remove it: Still in auto completion >>>> - force GC a looot: still in auto completion >>>> >>>> After chasing strong references I could clean up my image by doing: >>>> >>>> ChangeSet cleanUp: true. >>>> RecentMessageList cleanUp. >>>> 10 timesRepeat: [Smalltalk garbageCollect] >>>> >>>> First obvious thing: changesets and friends (lets also think about >>>> nautilus history that may do that) could keep strong references on symbols. >>>> >>>> Then the question is if that is correct or not... To me the problem is >>>> that the auto completion mechanism is pretty primitive and depends on all >>>> existing symbols instead of <the subset of symbols that could be messages>. >>>> >>>> Guille >>>> >>>> El Mon Feb 02 2015 at 12:05:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> escribiÃ³: >>>> >>>> But weak refs are only killed after GC, right ? >>>>> >>>>> And even then... >>>>> >>>>> > On 02 Feb 2015, at 12:03, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> > >>>>> > It's the table that keeps the symbols and checks their uniqueness. >>>>> > >>>>> > but AFAIK the symbol table is weak. So probably it's the completion >>>>> mechanism that is keeping extra references... >>>>> > El Mon Feb 02 2015 at 11:52:28 AM, phil(a)highoctane.be < >>>>> phil(a)highoctane.be> escribiÃ³: >>>>> > Got the same problem here. >>>>> > >>>>> > Annoying when third parties have to do something in the environment >>>>> as they are shown things that do not exist. >>>>> > >>>>> > Where to look? What's the symbol intern table? >>>>> > >>>>> > Phil >>>>> > >>>>> > >>>>> > On Mon, Feb 2, 2015 at 11:44 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> > Probably by resetting the Symbol intern table. but no time to dive >>>>> into it now. >>>>> > Hi all, >>>>> > >>>>> > Code completition tools show class/method old names i've changed and >>>>> no longer use. How can i remove all unused (occurring nowhere in source >>>>> code) or unimplemented names? >>>>> > >>>>> > Best, >>>>> > Laura >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>> > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 6, 2015

Re: [Pharo-users] spotter preview

by Laurent

Hi, I really like Spotter. The preview feature makes me think that would be useful to have it in code completion. So often I use the wrong method because completion does not display class name. The ability to have code preview in code completion (and maybe class hierarchy too) would make me open far less browser I think. An easy first step may be that when I type Shift+enter to open Spotter it copies the word where the cursor is placed in a text editor in the Spotter search field. Cheers, Laurent Le lun. 2 fÃ©vr. 2015 Ã 22:02, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > Hi, > > The Glamorous Team is happy to present a new feature in Spotter: > preview (you toggle it with Cmd+p). We think this boosts the > usefulness of the Spotter interface significantly. > > > > For more details, please take a look at: > http://www.humane-assessment.com/blog/boosting-gtspotter-with-preview > > This is available in the Moose image, and it will soon be integrated > in the Pharo one. > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Feb. 6, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by Stephan Eggermont

Hilaire wrote >Read the Pharo by example Morphic chapter, it is written for beginner The chapter is a good introduction. Also read the LaserGame Tutorial. The problems come after that. What is a good way of distributing responsibilities? How do I find which Morph already does (nearly) what I need. There are 347 Morph subClasses in my currently open image. When I want to resize my Morph, should I be looking at one of the AbstractResizerMorph subClasses, at Halo or perhaps at Handle? Or should I do it like PolygonMorph? In the LaserGame, the whole game is one Morph (embedded in a window with a few buttons). I find it is possible to create very elegant solutions using Morphic, and finding the right approach is difficult. Stephan

Feb. 6, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by Hilaire

Le 05/02/2015 17:14, nacho a Ã©crit : > Yes! Point me to those documents and I will love to read them!!! > thanks in advance > Read the Pharo by example Morphic chapter, it is written for beginner Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Feb. 6, 2015

Re: [Pharo-users] What Essays??

by Ben Coman

On Fri, Feb 6, 2015 at 4:59 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Richard, > > It is probably hard to see from 10000 miles away, but we have been > quite busy promoting Smalltalk recently. Pharo Days last thursday and > friday and the Smalltalk Devroom at Fosdem last sunday take up > a significant amount of time. Priorities > > Stephan > > Stephan, Here is a reference... https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg24436.html Richard, It might be good for the proposed essay list to be re-posted direct to this mail list btw, I think the chosen topics are good but also they are tough (hence why they are good questions) and maybe hard for an individual to be motivated to do if its not a current "burning" topic for them. Elsewhere you mention the potential problem with Pharo of assuming "build it and they will come" and perhaps there is a parallel with your Smalltalk Renaissance effort to get others to produce the essays. A parallel approach might break up the essays into a series of smaller questions that can be answered with less immediate time commitment, that you can aggregate into an essay. Perhaps searching around old & current discussions for people eloquent on these topics, then engaging the individuals in discussion on that lead to a collaboration on an essay. Keep pushing. cheers -ben

Feb. 6, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by Trygve Reenskaug

http://pharo.org/ On 05.02.2015 17:14, nacho wrote: > Yes! Point me to those documents and I will love to read them!!! > thanks in advance > > > *Lic. Ignacio Sniechowski, MBA** > * > *Prosavic SRL* > * > * > *Tel: (011) 4542-6714* > * > * > * > * > * > * > > * > * > * > * > * > * > * > * > * > * > * > * > > * > * > * > * > * > * > * > > ** > ** > * > > > > > On Thu, Feb 5, 2015 at 1:02 PM, Trygve Reenskaug [via Smalltalk] > <[hidden email] </user/SendEmail.jtp?type=node&node=4804006&i=0>> wrote: > > > Because your drawOn: method doesn't draw anything and needs help > from super. > It seems to me that you need to read more documentation :-) > > On 05.02.2015 15:53, nacho wrote: >> That work perfectly. What a silly mistake!!! >> Of course it should have been position := aPoint. >> Now, is it possible write the drawOn: method without calling >> super drawOn: a Canvas? >> I don't completely get it why I should call super drawOn: aCanvas >> thanks >> nacho >> >> >> *Lic. Ignacio Sniechowski, MBA** >> * >> *Prosavic SRL* >> * >> * >> *Tel: (011) 4542-6714* >> * >> * >> * >> * >> * >> * >> >> * >> * >> * >> * >> * >> * >> * >> * >> * >> * >> * >> * >> >> * >> * >> * >> * >> * >> * >> * >> >> ** >> ** >> * >> >> >> >> >> On Thu, Feb 5, 2015 at 11:28 AM, Trygve Reenskaug [via Smalltalk] >> <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4803979&i=0>> wrote: >> >> I've tested your code in Squeak and found another bug (I >> should have been more careful when I read your code. Shame on >> me.) >> >> In class Ball you have the methods >> >> position: aPoint >> super position: aPoint. >> This does not set a value to your position variable in class Ball, but actually sets the upper-left corner of the bounds. >> You should have said position := aPoint. >> -------------------------------- >> The following now works in mySqueak image: >> EllipseMorph subclass: #Ball >> instanceVariableNames: 'position' >> classVariableNames: '' >> poolDictionaries: '' "this part is needed in Squeak" >> category: 'ZZZtesting' >> >> drawOn: aCanvas >> self borderWidth:10; borderColor: Color green. >> super drawOn: aCanvas. >> >> position >> ^ position. >> >> position: aPoint >> position := aPoint. >> >> I then execute the following in a workspace >> | aBall | >> aBall := Ball new. >> aBall position: ( 10@10 ). >> aBall openInWorld. >> >> and it seems to work. But closer scrutiny shows that it >> ignores your instance variable (position). when I move the >> ball around. >> The reason is that EllipseMorph is a superclass of your Ball >> and cannot possibly know about an instance variable >> (position) that is defined in the subclass (Ball). >> >> I ignored Ball>position since the EllipseMorph doesn't use it: >> >> EllipseMorph subclass: #Ball >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'ZZZtesting' >> >> position >> ^ super position. >> >> position: aPoint >> super position: aPoint. >> This looks better. >> I you really want to replace the EllipseMorph>position you >> must go deeper into how the EllipseMorph handles its position >> and bounds . This will not be trivial. Much easier to invent >> a new instance variable and use it in the drawOn: method. >> >> Good luck with your apprenticeship >> >> >> >> >> >> >> >> >> >> On 05.02.2015 11:56, nacho wrote: >>> @Trygve >>> I've checked and it doesn't work. I can't even bring the halo on to delete >>> the morph. The debugger keeps popping. >>> Thanks anyway to all >>> Nacho >>> >>> >>> >>> >>> ----- >>> Nacho >>> Smalltalker apprentice. >>> Buenos Aires, Argentina. >>> -- >>> View this message in context:http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803895.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >>> >> >> -- >> >> /The essence of object orientation is that objects >> collaborateto achieve a goal. / >> Trygve Reenskaug [hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4803964&i=0> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway Tel: (+47) 22 49 57 27 >> >> >> >> ------------------------------------------------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803964.h… >> >> To unsubscribe from Question on Morphic drawOn: method., >> click here. >> NAML >> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> >> >> >> Nacho Smalltalker apprentice. Buenos Aires, Argentina. >> >> ------------------------------------------------------------------------ >> View this message in context: Re: Question on Morphic drawOn: >> method. >> <http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803979.h…> >> Sent from the Pharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >> Nabble.com. > > -- > > /The essence of object orientation is that objects collaborateto > achieve a goal. / > Trygve Reenskaug [hidden email] > <http:///user/SendEmail.jtp?type=node&node=4804005&i=0> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4804005.h… > > To unsubscribe from Question on Morphic drawOn: method., click here. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > > > Nacho Smalltalker apprentice. Buenos Aires, Argentina. > > ------------------------------------------------------------------------ > View this message in context: Re: Question on Morphic drawOn: method. > <http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4804006.h…> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27

Feb. 5, 2015

Re: [Pharo-users] RadarMorph (was Re: Canvas Transform Goes Haywire if Scaled)

by Nicolai Hess

2015-02-05 19:06 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolai Hess wrote > > What do you want to achieve? > > I've created an infinite desktop a la Self. To make things manageable, I'm > currently writing a RadarView (also just like Self) to show a map of all > the > objects on the desktop, and the position of the current viewport. It's > working now thanks to your help! > Looks great. (And it will look even better if it (and Morphic) is working with Athens:) ). > > There is now only 1 major bug, and 3 little glitches: > 1. (BUG): Every once in a while (can't figure out how to reproduce), it > displays the Red X of Death like so: > > <http://forum.world.st/file/n4804025/Screenshot_2015-02-05_11.png> > drawRadarViewOn: aCanvas | terrainRect transform scale clipRect viewRect offset | terrainRect := self radarCoverageArea. terrainRect isZero ifTrue: [ ^ self ]. "the viewRect scale must not depend on the clipRect extent" " you want to have the scale based on the radarmorph extent. But now, if something occludes " the radarmorph partially, the clipRect is smaller than your radarmorph and the scaling is wrong" viewRect := terrainRect scaledAndCenteredIn: aCanvas clipRect. > > 2. When the container window is moved, the contents temporarily jump out of > the radar screen > That one is tricky. If you grab the self world morph with the mouse, the morph is not drawn in the morphic WorldMorph anymore, instead the handmorph creates a form and a new canvas for drawing on this form. For this canvas the offset (or origin?) is not the same as for the WorldMorph. > 3. when the radar is dragged over another morph in the Self World, the > clipping gets very weird > There are some artefacts too, related to issue 12330 <https://pharo.fogbugz.com/default.asp?12330> Rendering artifacts with scaled ImageMorph (still unresolved) > 4. One side of the blue highlight rectangle sometimes disappears on resize > > #2, #3, and #4 can be seen in this screencast: https://vimeo.com/118826521 > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Canvas-Transform-Goes-Haywire-if-Scaled-tp4803830p480… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 5, 2015

Re: [Pharo-users] What Essays??

by Stephan Eggermont

Hi Richard, It is probably hard to see from 10000 miles away, but we have been quite busy promoting Smalltalk recently. Pharo Days last thursday and friday and the Smalltalk Devroom at Fosdem last sunday take up a significant amount of time. Priorities Stephan

Feb. 5, 2015