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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

Sept. 20, 2013

[update 3.0] #30413

by Marcus Denker

30413 ----- 11607 Small Code Critic cleanup of Morphic-Base https://pharo.fogbugz.com/f/cases/11607 11634 diffmorph icons should not use generic names https://pharo.fogbugz.com/f/cases/11634 11643 add replacement methods for #isLiteral in IRLiteral and OCLiteralVariable https://pharo.fogbugz.com/f/cases/11643 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Core-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Tools-Diff-MarcusDe… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.112… http://smalltalkhub.com/mc/Pharo/Pharo30/main/EventModel-MarcusDenker.3.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.529.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Tests-Core-MarcusDenker.3…

Sept. 20, 2013

Re: [Pharo-dev] Athens to Form

by Igor Stasenko

On 20 September 2013 14:16, Torsten Bergmann <astares(a)gmx.de> wrote: > Stef wrote: > >look for the AthensSceneâ¦ > > Thanks, did'n see the class comment there. Just for the records if anyone > needs it: > > > Display in Pharo: > =========== > > surface := AthensCairoSurface extent: 100@100. > surface drawDuring: [:canvas | > canvas surface clear: Color black. > canvas setPaint: (Color red). > canvas setShape: (-20@ -20 corner: 20@ 20). > canvas draw. > ]. > imageForm := surface asForm. > form asMorph openInWorld > > > Display in Seaside: > ============= > > renderContentOn: html > html imageForm: ... "add your image form here" > > i am not sure this will work, since transferring image via net requires direct acces to form's bits, while cairo surface form is just a reference to its corresponding cairo surface. so, in order to get access to its pixels you must blit it to own 32bpp Form: surfForm := surface asForm. destForm := Form extent: surface extent depth: 32. destForm canvas drawImage: surfForm at: 0@0. html imageForm: destForm (something like that). -- Best regards, Igor Stasenko.

Sept. 20, 2013

Re: [Pharo-dev] Athens to Form

by Igor Stasenko

There's no consistent docu yet *blush*. But you can look in Athens-Tutorial for basics. On 20 September 2013 13:09, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > do we have a small example how to draw > with Athens (canvas) and then get a "Form" back > (for instance for later displaying in Seaside) > > Where is Athens docu these days? > > Thx > T. > > -- Best regards, Igor Stasenko.

Sept. 20, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Mariano Martinez Peck

On Fri, Sep 20, 2013 at 7:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I do not understand why it would be a GreasePackage > What are grease package? > if grease override the packages messages then I do not see why it would be > a pharo bug. > This is like if you redefine class and returns something else. > > Indeed. It is as simple as that. Grease is overriding a class side method #packages which is a collision to Pharo core and hence fails the load because #packages for that class answers its own type of packages rather than the expected by Pharo. Again, a simply rename of GRPackage class >> packages would be enough. And it has only one sender (a test) in the image I have.... > Stef > > On Sep 6, 2013, at 3:21 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Anyone? > > > On Wed, Aug 28, 2013 at 2:12 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys, >> >> I was trying to build a new image with latest Pharo 2.0 with all the >> frameworks I use. While installing, I get a dnu in: >> >> packageFromOrganizer: anRPackageOrganizer >> "This method returns the package this method belongs to. >> It takes into account classes and traits. >> If the method is in no package, returns nil by now" >> self flag: 'TODO: use anRPackageOrganizer, or better delegate to >> anRPackageOrganizer'. >> ^self origin packages >> detect: [ :each | >> (each includesSelector: self selector ofClassName: self origin >> theNonMetaClass originalName) >> or: [ each includesSelector: self selector ofMetaclassName: self origin >> theNonMetaClass originalName]] >> ifNone: [ nil ] >> >> because "each" (which was GRPackage) dnu #includesSelector:ofClassName: >> >> Problem is that "self origin" answers GRPackage. And GRPackage DOES >> implement a CLASS side method #packages that answers instances of >> GRPackage.....not RPackage... >> >> So...which one do we prefix? GRPackage class #packages to #greasePackages? >> >> BTW, there are yet more class side implementations of #packages, which >> are basically subclasses for the HelpSystem (CustomHelp). So we have for >> example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation. >> >> Guess we should update the HelpSystem as well? >> >> Let me know and I open issues/submit fixes. >> >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Sept. 20, 2013

Athens to Form

by Torsten Bergmann

Stef wrote: >look for the AthensSceneâ¦ Thanks, did'n see the class comment there. Just for the records if anyone needs it: Display in Pharo: =========== surface := AthensCairoSurface extent: 100@100. surface drawDuring: [:canvas | canvas surface clear: Color black. canvas setPaint: (Color red). canvas setShape: (-20@ -20 corner: 20@ 20). canvas draw. ]. imageForm := surface asForm. form asMorph openInWorld Display in Seaside: ============= renderContentOn: html html imageForm: ... "add your image form here"

Sept. 20, 2013

Re: [Pharo-dev] Stability of 3.0

by Goubier Thierry

Le 20/09/2013 12:20, StÃ©phane Ducasse a Ã©crit : > > On Sep 20, 2013, at 12:16 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> That's a problem with one of the fixes I have to carry around on 3.0. I'll update it, thanks. > > ok let us knw how we can help. Hum, fix 11102/11142? There is a partial fix in 11528 which was integrated, but I don't feel confortable with it, so I prefer overwritting it in my image. Thierry > Stef > >> >> Thierry >> >> Le 20/09/2013 11:54, StÃ©phane Ducasse a Ã©crit : >>> thierry >>> >>> do you have a scenario that I could reproduce. >>> >>> stef >>> On Sep 19, 2013, at 5:36 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>>> TranslucentPatterns is undefined. >>>> >>>> Error: Instances of UndefinedObject are not indexable >>>> in FormCanvas>>translucentMaskFor:depth: >>>> >>>> Thierry >>>> >>>> >>>> Le 19/09/2013 17:24, StÃ©phane Ducasse a Ã©crit : >>>>> >>>>> On Sep 19, 2013, at 5:24 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> is it me or what? The latest 3.0 gives me a lot of red squares a bit everywhere around the place, making working with it a bit (a lot!) painful. >>>>> >>>>> I do not know because busy with lecture writing and managing mess. >>>>> >>>>> Can you grab the debug button (I know this is unclear) >>>>> but if you get the faulty morph you can get a debugger and we can see what is the message that is failing. >>>>> It saved lot of work and frsutration because you know why you get the red cross of death. >>>>> Stef >>>>> >>>>>> >>>>>> I'm on 30407, frech from get.pharo.org. >>>>>> >>>>>> Thierry >>>>>> -- >>>>>> Thierry Goubier >>>>>> CEA list >>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>> 91191 Gif sur Yvette Cedex >>>>>> France >>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>> >>> >>> >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 20, 2013

Re: [Pharo-dev] Dynamically adding nodes to Roassal

by roberto.minelli＠usi.ch

Thanks Alejandro, I will try what you propose! What do you mean by > Another thing bothering me is that you mentioned the method #nodes, thats from the ROMondrianViewBuilder, which I think is not that friendly with dynamic stuff. How would you construct a view without using the ROMondrianViewBuilder? I am used to start as in the Roassal Easel like rawView := ROView new. view := ROMondrianViewBuilder view: rawView And then adding nodes to the view, calling view nodes: myNodes Cheers, R On Sep 20, 2013, at 1:49 PM, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > In Roassal calling the method #signalUpdate to the view should show those new nodes. If you want to re-layout the nodes you should apply a new layout to the nodes before the #signalUpdate. > > Another pretty interesting feature is the method ROContainer>>callback: aCallback. The idea is that every time an element is added inside the container the callback is called. > Now how you can use this: > > element callback: (ROContainerCallbackLayout new layout: (ROGridLayout new gapSize: 2)). > > Remember that you must send signalUpdate to the view if you want to see the changes. > > Another thing bothering me is that you mentioned the method #nodes, thats from the ROMondrianViewBuilder, which I think is not that friendly with dynamic stuff. > It is a little bit ugly but you can always get the ROView from ROMondrianViewBuilder sending the message #view and over that do all kind of Roassal magic stuff, like adding the callback with the TreeLayout the the ROView itself. Also for adding new nodes you should add them directly to the ROView, or at least I haven't found the way to do that without having to add all the nodes again to the Builder. > > Hope that help you. > > > 2013/9/20 roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> > *and have the visualization re-layouted? > > On Sep 20, 2013, at 11:24 AM, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> > wrote: > > > Hi, > > > > I was playing around with Roassal (in particular, a tree map) and I have a question: Is there a way to dynamically adding nodes? I mean, once the view is generated to update the #nodes by adding a new node (and associations as well, i.e., edges) and have the visualization re- > > > > Thanks in advance. > > > > Roby > > >

Sept. 20, 2013

Re: [Pharo-dev] Dynamically adding nodes to Roassal

by Alejandro Infante

In Roassal calling the method #signalUpdate to the view should show those new nodes. If you want to re-layout the nodes you should apply a new layout to the nodes before the #signalUpdate. Another pretty interesting feature is the method ROContainer>>callback: aCallback. The idea is that every time an element is added inside the container the callback is called. Now how you can use this: element callback: (ROContainerCallbackLayout new layout: (ROGridLayout new gapSize: 2)). Remember that you must send signalUpdate to the view if you want to see the changes. Another thing bothering me is that you mentioned the method #nodes, thats from the ROMondrianViewBuilder, which I think is not that friendly with dynamic stuff. It is a little bit ugly but you can always get the ROView from ROMondrianViewBuilder sending the message #view and over that do all kind of Roassal magic stuff, like adding the callback with the TreeLayout the the ROView itself. Also for adding new nodes you should add them directly to the ROView, or at least I haven't found the way to do that without having to add all the nodes again to the Builder. Hope that help you. 2013/9/20 roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> > *and have the visualization re-layouted? > > On Sep 20, 2013, at 11:24 AM, "roberto.minelli(a)usi.ch" < > roberto.minelli(a)usi.ch> > wrote: > > > Hi, > > > > I was playing around with Roassal (in particular, a tree map) and I have > a question: Is there a way to dynamically adding nodes? I mean, once the > view is generated to update the #nodes by adding a new node (and > associations as well, i.e., edges) and have the visualization re- > > > > Thanks in advance. > > > > Roby > > >

Sept. 20, 2013

[PBE] May be we should first just change PBE in git in Latex.

by StÃ©phane Ducasse

Hi yuri May be we should first just change PBE in git in Latex. I do not know how to tag a new branch but I like the description made by ben. > I should add, I got as far as completing the first chapter, which can be pulled from [1]. Check out [2] to get started. > > [1] https://github.com/bencoman/PharoByExample-english > [2] http://blog.openinworld.com/2012/05/contributing-to-pbe/ What I'm doing is collecting a list of changes from the sbe archive list https://docs.google.com/document/d/1lVOTw2d5Bqv_49XPZ9MwUF6zDbsLWf8l7ev2NAg… stef

Sept. 20, 2013