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

[pharo-project/pharo-core] 060050: 40147

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 060050e576ad818a1e42ca419262a30a7ce73fc2 https://github.com/pharo-project/pharo-core/commit/060050e576ad818a1e42ca41… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-01 (Fri, 01 Aug 2014) Changed paths: A Morphic-Base.package/EventHandler.class/README.md A Morphic-Base.package/EventHandler.class/definition.st A Morphic-Base.package/EventHandler.class/instance/access/allRecipients.st A Morphic-Base.package/EventHandler.class/instance/access/firstMouseSelector.st A Morphic-Base.package/EventHandler.class/instance/access/messageList.st A Morphic-Base.package/EventHandler.class/instance/access/methodRefList.st A Morphic-Base.package/EventHandler.class/instance/access/mouseDownSelector.st A Morphic-Base.package/EventHandler.class/instance/access/mouseStillDownRecipient.st A Morphic-Base.package/EventHandler.class/instance/access/mouseStillDownSelector.st A Morphic-Base.package/EventHandler.class/instance/access/mouseUpSelector.st A Morphic-Base.package/EventHandler.class/instance/copying/veryDeepFixupWith_.st A Morphic-Base.package/EventHandler.class/instance/events/click_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/doubleClickTimeout_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/doubleClick_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/keyStroke_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseDown_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseEnterDragging_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseEnter_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseLeaveDragging_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseLeave_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseMove_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseStillDown_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/mouseUp_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/send_to_withEvent_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/events/startDrag_fromMorph_.st A Morphic-Base.package/EventHandler.class/instance/initialization/onGestureSend_to_.st A Morphic-Base.package/EventHandler.class/instance/initialization/on_send_to_.st A Morphic-Base.package/EventHandler.class/instance/initialization/on_send_to_withValue_.st A Morphic-Base.package/EventHandler.class/instance/printing/printOn_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesClickOrDrag_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesGestureStart_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesKeyboard_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesMouseDown_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesMouseMove_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesMouseOverDragging_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesMouseOver_.st A Morphic-Base.package/EventHandler.class/instance/testing/handlesMouseStillDown_.st A Morphic-Base.package/SimpleBalloonMorph.class/README.md A Morphic-Base.package/SimpleBalloonMorph.class/class/private/getVertices_.st A Morphic-Base.package/SimpleBalloonMorph.class/definition.st A Morphic-Base.package/SimpleBalloonMorph.class/instance/initialization/initialize.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/README.md A Morphic-Widgets-Windows.package/FullscreenMorph.class/definition.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/accessing/contentMorph.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/accessing/setContentMorph_.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/initialization/initialize.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/initialize/defaultColor.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/initialize/openInWorld_.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/open%2Fclose/openAsIs.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/open%2Fclose/openAsIsIn_.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/private - accessing/edgeToAdhereTo.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/private - layout/updateBounds.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/recategorized/layoutChanged.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/testing/isAdheringToBottom.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/testing/isAdheringToLeft.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/testing/isAdheringToRight.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/testing/isAdheringToTop.st A Morphic-Widgets-Windows.package/FullscreenMorph.class/instance/testing/isDockingBar.st A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/README.md A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/definition.st A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/instance/as yet unclassified/handlesMouseOver_.st A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/instance/as yet unclassified/methodRefList.st A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/instance/as yet unclassified/mouseOver_fromMorph_.st A Morphic-Widgets-Windows.package/MouseOverEventHandler.class/instance/as yet unclassified/on_send_to_.st M Morphic-Widgets-Windows.package/PanelMorph.class/instance/event handling/on_send_to_.st M Morphic-Widgets-Windows.package/PanelMorph.class/instance/event handling/on_send_to_withValue_.st R Morphic-Widgets-Windows.package/StandardWindow.class/instance/as yet unclassified/openFullscreen.st R Morphic-Widgets-Windows.package/StandardWindow.class/instance/as yet unclassified/openedFullscreen.st A Morphic-Widgets-Windows.package/StandardWindow.class/instance/open%2Fclose/openFullscreen.st A Morphic-Widgets-Windows.package/StandardWindow.class/instance/testing/openedFullscreen.st R Polymorph-Widgets.package/EventHandler.class/README.md R Polymorph-Widgets.package/EventHandler.class/definition.st R Polymorph-Widgets.package/EventHandler.class/instance/access/allRecipients.st R Polymorph-Widgets.package/EventHandler.class/instance/access/firstMouseSelector.st R Polymorph-Widgets.package/EventHandler.class/instance/access/messageList.st R Polymorph-Widgets.package/EventHandler.class/instance/access/methodRefList.st R Polymorph-Widgets.package/EventHandler.class/instance/access/mouseDownSelector.st R Polymorph-Widgets.package/EventHandler.class/instance/access/mouseStillDownRecipient.st R Polymorph-Widgets.package/EventHandler.class/instance/access/mouseStillDownSelector.st R Polymorph-Widgets.package/EventHandler.class/instance/access/mouseUpSelector.st R Polymorph-Widgets.package/EventHandler.class/instance/copying/veryDeepFixupWith_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/click_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/doubleClickTimeout_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/doubleClick_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/keyStroke_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseDown_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseEnterDragging_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseEnter_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseLeaveDragging_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseLeave_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseMove_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseStillDown_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/mouseUp_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/send_to_withEvent_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/events/startDrag_fromMorph_.st R Polymorph-Widgets.package/EventHandler.class/instance/initialization/onGestureSend_to_.st R Polymorph-Widgets.package/EventHandler.class/instance/initialization/on_send_to_.st R Polymorph-Widgets.package/EventHandler.class/instance/initialization/on_send_to_withValue_.st R Polymorph-Widgets.package/EventHandler.class/instance/printing/printOn_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesClickOrDrag_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesGestureStart_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesKeyboard_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesMouseDown_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesMouseMove_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesMouseOverDragging_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesMouseOver_.st R Polymorph-Widgets.package/EventHandler.class/instance/testing/handlesMouseStillDown_.st R Polymorph-Widgets.package/EventHandlerPlus.class/README.md R Polymorph-Widgets.package/EventHandlerPlus.class/definition.st R Polymorph-Widgets.package/EventHandlerPlus.class/instance/as yet unclassified/handlesMouseOver_.st R Polymorph-Widgets.package/EventHandlerPlus.class/instance/as yet unclassified/methodRefList.st R Polymorph-Widgets.package/EventHandlerPlus.class/instance/as yet unclassified/mouseOver_fromMorph_.st R Polymorph-Widgets.package/EventHandlerPlus.class/instance/as yet unclassified/on_send_to_.st R Polymorph-Widgets.package/FullscreenMorph.class/README.md R Polymorph-Widgets.package/FullscreenMorph.class/definition.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/accessing/contentMorph.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/accessing/setContentMorph_.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/initialization/initialize.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/initialize/defaultColor.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/initialize/openInWorld_.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/open%2Fclose/openAsIs.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/open%2Fclose/openAsIsIn_.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/private - accessing/edgeToAdhereTo.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/private - layout/updateBounds.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/recategorized/layoutChanged.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/testing/isAdheringToBottom.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/testing/isAdheringToLeft.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/testing/isAdheringToRight.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/testing/isAdheringToTop.st R Polymorph-Widgets.package/FullscreenMorph.class/instance/testing/isDockingBar.st R Polymorph-Widgets.package/SimpleBalloonMorph.class/README.md R Polymorph-Widgets.package/SimpleBalloonMorph.class/class/as yet unclassified/getVertices_.st R Polymorph-Widgets.package/SimpleBalloonMorph.class/definition.st R Polymorph-Widgets.package/SimpleBalloonMorph.class/instance/initialization/initialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script147.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40147.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Base.package/AbstractTool.class/instance/class/moveInNewPackage_.st Log Message: ----------- 40147 13747 EventHandlerPlus -> MouseOverEventHandler https://pharo.fogbugz.com/f/cases/13747 13749 SimpleBallonMorph has just one initialize and one user :) https://pharo.fogbugz.com/f/cases/13749 13744 Move to raises a DNU https://pharo.fogbugz.com/f/cases/13744 13748 MoveFullScreenTo Morphi-Widgets-Windows since this is its only user https://pharo.fogbugz.com/f/cases/13748 http://files.pharo.org/image/40/40147.zip

Aug. 1, 2014

Re: [Pharo-dev] rethinking the print it action in Pharo

by Tudor Girba

Hi, Interesting. However, the goal of Print It is to get quick feedback. If you need to do anything else with it, it's probably the wrong tool. For example, in the GTPlayground, you can open the object to the right in a full inspector that allows you to manipulate the object in details. Text is useful for quick references, not for manipulation. I would not want to design a dedicated space in the workspace to only show text. Cheers, Doru On Fri, Aug 1, 2014 at 5:25 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > Kind of back to the Future. Why not have a console rectangle scrollable > area at the bottom of the workspace window, that can be persistent on > clicking on it and gives the result of "print it" accumulating till a > clear is called. Setting to clear on every run or retain text can be done. > This is a bit like in Eclipse transient window on inspect but simpler and > retains the printed text if reqd. > > > On Tue, Jul 29, 2014 at 1:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> >> >> >> On Mon, Jul 28, 2014 at 9:58 PM, Chris Muller <asqueaker(a)gmail.com> >> wrote: >> >>> Maybe remapping Command+p to inspect would solve it equally? :) >>> >> >> This is a point worth debating (I really love when we allocate time to >> talk about our UI - this is the one interface that we, in this community, >> use every day). >> >> The goal of "Print it" serves as a quick and light readonly feedback, and >> I think it has a distinct place that is separate from the inspector which >> is a place where you interact and manipulate the object. Furthermore, in >> the current implementation, the "print it" is floating and non intrusive >> (it goes away easily) while the inspector is at the moment a lasting piece. >> >> Of course, we could imagine an inspector that could be embedded in the >> popper window (in fact, I have that implementation, too :)), but the >> problem is that in its current form, the inspector is not made to be easily >> scalable. This might change with the adoption of Athens. >> >> In the meantime, one direction I think we could take is to produce >> several scalable "printouts" that can also be visual. >> >> >> >>> Both of the example cases justifying it were that the user pressed the >>> wrong key. UI's should not try to solve problems between the human <--> >>> hardware interface. >>> >> >> I am not sure I follow. Could you elaborate please? >> >> Cheers, >> Doru >> >> >>> >>> >>> >>> On Sun, Jul 27, 2014 at 6:33 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Hi, >>>> >>>> In the course of revamping the Pharo environment, we stumbled across >>>> the print it action and we (Andrei and I) decided to rethink it. >>>> [image: Inline image 1] >>>> >>>> You can find more details here: >>>> http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo >>>> >>>> Let us know what you think. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 1, 2014

Re: [Pharo-dev] [Moose-dev] Pharo image corruption and fatal VM error with Roassal

by Eliot Miranda

On Thu, Jul 31, 2014 at 8:56 PM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> wrote: > > On Jul 31, 2014 11:03 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > > > > Is is not that easy :) > > TRMorph already checks for a new session. > > TRCanvas not, but could be done the same way - maybe. It is difficult as > TRCanvas are shared by different objects. > > And it is more difficult for TRShape. > > > > I know Igors argument against a session management in Athens for > > recreating cairo resources on image start up. It is not the job of > Athens. > > Maybe session management should be implemented by the cairo binding (or an > abstraction on top of it, that is then used by athens). This way we don't > clutter Athens with such low level stuff, and we offer the user a > high-level usable cairo binding, which can be also used outside athens. > +1. In other analogous situations (e.g. the VisualWorks FFI, external font references, etc) it is the layer that creates those external resources that has the job of voiding them on startup. It's an approach that works well in practice. Cheers, > Ciprian > > > > > But it is a bit different for resources created through Athens core api. > > How can the user (TRShape for example) know, that a path created by > > an Athens surface referes to an external resource? > > > > The attached changeset implements a simple check for TRCanvas and > > resets paths if the canvas changes. This solves the crash on > > image start up.But it is not a good solution. > > > > > > > > > > 2014-07-31 16:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > >> The recipe is simple: isolate the code in your application in a way > that if certain feature not available (line nativeboost), it won't put your > image into endless exception throwing loop. > >> > > > > That's another story. The projects I have seen, using athens, do this > with an explicit use > > on AthensCairoSurface. Is there already a way to instantiate an > AthensSurface depending on the > > available libraries? And AthensBalloon and AthensCairo don't differ only > in rendering quality, so there > > is no real fallback option. > > > > > > > > > >> > >> > >> On 31 July 2014 16:09, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >>> > >>> Yes, and this is a mess. > >>> Iâve spent quite some time in getting the session working with > Roassal2 and it still does not work. I would appreciate help on this. > >>> > >>> Alexandre > >>> > >>> > >>> On Jul 31, 2014, at 8:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >>> > >>> > It looks like Trachel does not recreate athens external resources. > >>> > There is an example in AthensSceneView, on how to check and reload > >>> > an AthensSurface. > >>> > > >>> > > >>> > 2014-07-31 12:51 GMT+02:00 Usman Bhatti <usman.bhatti(a)gmail.com>: > >>> > > >>> > > >>> > > >>> > On Thu, Jul 31, 2014 at 11:17 AM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >>> > Yes it is. But I will not do > >>> > > >>> > TRMorph allInstances do: #delete > >>> > > >>> > In command line every dayâ¦ > >>> > > >>> > > >>> > It is only intended to recover your lost work in the image not for > everyday use :). > >>> > > >>> > > >>> > > >>> > > >>> > Vincent > >>> > > >>> > > >>> > > >>> > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > part de Usman Bhatti > >>> > EnvoyÃ© : jeudi 31 juillet 2014 10:59 > >>> > Ã : Pharo Development List > >>> > Cc : Moose-related development > >>> > > >>> > > >>> > Objet : Re: [Pharo-dev] Pharo image corruption and fatal VM error > with Roassal > >>> > > >>> > > >>> > > >>> > This may be related to this known issue reported a few days back. > >>> > > >>> > https://code.google.com/p/moose-technology/issues/detail?id=1084 > >>> > > >>> > > >>> > > >>> > And there is a possible solution to recover your image. > >>> > > >>> > > >>> > > >>> > usman > >>> > > >>> > > >>> > > >>> > On Thu, Jul 31, 2014 at 10:50 AM, Blondeau Vincent < > vincent.blondeau(a)worldline.com> wrote: > >>> > > >>> > Hi, > >>> > > >>> > > >>> > > >>> > Yesterday, I was using GraphET (a part of Roassal) to do some charts > and, today, when I wanted to reopen the image. > >>> > > >>> > And I got that : > >>> > > >>> > <image001.png> > >>> > > >>> > It is *very* unpleasantâ¦ > >>> > > >>> > > >>> > > >>> > To reproduce the bug: > >>> > > >>> > 1 - You can do either: > >>> > > >>> > | builder | > >>> > > >>> > builder := GET2Line data: (0 to: > 100) . > >>> > > >>> > builder > >>> > > >>> > y: [ :x | x*x ]. > >>> > > >>> > > >>> > > >>> > builder open. > >>> > > >>> > Or > >>> > > >>> > WorldMenu -> Roassal examples -> choose an item -> click on a graph > . A TRMorph should be opened. > >>> > > >>> > 2 - donât close the graph and save the pharo image. > >>> > > >>> > 3 â Close the pharo image > >>> > > >>> > 4 - Reopen it > >>> > > >>> > > >>> > > >>> > I am under W7 x64 with the latest moose image and the VM available > on the pharo.org website (http://files.pharo.org/platform/Pharo3.0-win.zip) > from the 10 july. > >>> > > >>> > You will find the crash dump attached. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Thankfully, I managed to open the image with a latest VM ( > http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) > >>> > > >>> > Thanks a lot Eliot ! :) > >>> > > >>> > > >>> > > >>> > And I got this: > >>> > > >>> > <image002.png> > >>> > > >>> > > >>> > > >>> > Thanks in advance > >>> > > >>> > > >>> > > >>> > Cheers, > >>> > > >>> > Vincent BLONDEAU > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã > l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par > le secret professionnel. Si vous recevez ce message par erreur, merci d'en > avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du > message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de > Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien > que les meilleurs efforts soient faits pour maintenir cette transmission > exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et > sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant > d'un virus transmis. > >>> > > >>> > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã > l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par > le secret professionnel. Si vous recevez ce message par erreur, merci d'en > avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du > message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de > Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien > que les meilleurs efforts soient faits pour maintenir cette transmission > exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et > sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant > d'un virus transmis. > >>> > > >>> > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > >>> > > >>> > > >>> > _______________________________________________ > >>> > Moose-dev mailing list > >>> > Moose-dev(a)iam.unibe.ch > >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > > -- best, Eliot

Aug. 1, 2014

Re: [Pharo-dev] [Moose-dev] Pharo image corruption and fatal VM error with Roassal

by Ciprian Teodorov

On Jul 31, 2014 11:03 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > > Is is not that easy :) > TRMorph already checks for a new session. > TRCanvas not, but could be done the same way - maybe. It is difficult as TRCanvas are shared by different objects. > And it is more difficult for TRShape. > > I know Igors argument against a session management in Athens for > recreating cairo resources on image start up. It is not the job of Athens. Maybe session management should be implemented by the cairo binding (or an abstraction on top of it, that is then used by athens). This way we don't clutter Athens with such low level stuff, and we offer the user a high-level usable cairo binding, which can be also used outside athens. Cheers, Ciprian > > But it is a bit different for resources created through Athens core api. > How can the user (TRShape for example) know, that a path created by > an Athens surface referes to an external resource? > > The attached changeset implements a simple check for TRCanvas and > resets paths if the canvas changes. This solves the crash on > image start up.But it is not a good solution. > > > > > 2014-07-31 16:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> The recipe is simple: isolate the code in your application in a way that if certain feature not available (line nativeboost), it won't put your image into endless exception throwing loop. >> > > That's another story. The projects I have seen, using athens, do this with an explicit use > on AthensCairoSurface. Is there already a way to instantiate an AthensSurface depending on the > available libraries? And AthensBalloon and AthensCairo don't differ only in rendering quality, so there > is no real fallback option. > > > > >> >> >> On 31 July 2014 16:09, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Yes, and this is a mess. >>> Iâve spent quite some time in getting the session working with Roassal2 and it still does not work. I would appreciate help on this. >>> >>> Alexandre >>> >>> >>> On Jul 31, 2014, at 8:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> > It looks like Trachel does not recreate athens external resources. >>> > There is an example in AthensSceneView, on how to check and reload >>> > an AthensSurface. >>> > >>> > >>> > 2014-07-31 12:51 GMT+02:00 Usman Bhatti <usman.bhatti(a)gmail.com>: >>> > >>> > >>> > >>> > On Thu, Jul 31, 2014 at 11:17 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: >>> > Yes it is. But I will not do >>> > >>> > TRMorph allInstances do: #delete >>> > >>> > In command line every dayâ¦ >>> > >>> > >>> > It is only intended to recover your lost work in the image not for everyday use :). >>> > >>> > >>> > >>> > >>> > Vincent >>> > >>> > >>> > >>> > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Usman Bhatti >>> > EnvoyÃ© : jeudi 31 juillet 2014 10:59 >>> > Ã : Pharo Development List >>> > Cc : Moose-related development >>> > >>> > >>> > Objet : Re: [Pharo-dev] Pharo image corruption and fatal VM error with Roassal >>> > >>> > >>> > >>> > This may be related to this known issue reported a few days back. >>> > >>> > https://code.google.com/p/moose-technology/issues/detail?id=1084 >>> > >>> > >>> > >>> > And there is a possible solution to recover your image. >>> > >>> > >>> > >>> > usman >>> > >>> > >>> > >>> > On Thu, Jul 31, 2014 at 10:50 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: >>> > >>> > Hi, >>> > >>> > >>> > >>> > Yesterday, I was using GraphET (a part of Roassal) to do some charts and, today, when I wanted to reopen the image. >>> > >>> > And I got that : >>> > >>> > <image001.png> >>> > >>> > It is *very* unpleasantâ¦ >>> > >>> > >>> > >>> > To reproduce the bug: >>> > >>> > 1 - You can do either: >>> > >>> > | builder | >>> > >>> > builder := GET2Line data: (0 to: 100) . >>> > >>> > builder >>> > >>> > y: [ :x | x*x ]. >>> > >>> > >>> > >>> > builder open. >>> > >>> > Or >>> > >>> > WorldMenu -> Roassal examples -> choose an item -> click on a graph . A TRMorph should be opened. >>> > >>> > 2 - donât close the graph and save the pharo image. >>> > >>> > 3 â Close the pharo image >>> > >>> > 4 - Reopen it >>> > >>> > >>> > >>> > I am under W7 x64 with the latest moose image and the VM available on the pharo.org website (http://files.pharo.org/platform/Pharo3.0-win.zip) from the 10 july. >>> > >>> > You will find the crash dump attached. >>> > >>> > >>> > >>> > >>> > >>> > Thankfully, I managed to open the image with a latest VM ( http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) >>> > >>> > Thanks a lot Eliot ! :) >>> > >>> > >>> > >>> > And I got this: >>> > >>> > <image002.png> >>> > >>> > >>> > >>> > Thanks in advance >>> > >>> > >>> > >>> > Cheers, >>> > >>> > Vincent BLONDEAU >>> > >>> > >>> > >>> > >>> > >>> > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >>> > >>> > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. >>> > >>> > >>> > >>> > >>> > >>> > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >>> > >>> > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. >>> > >>> > >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > Moose-dev(a)iam.unibe.ch >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > >

Aug. 1, 2014

Re: [Pharo-dev] [Esug-list] Android VM Status

by jannik laval

Yes, I would like to try Phratch on Android :) It works faster now, so maybe it will become usable, as for RPi :) Jannik 2014-07-31 23:27 GMT+02:00 Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> : > Couple a things still to do: > > If you want jannik when I will have my first Beta, I give a version, but > for a jenkins I will need some work on the configuration generator. > > > > On 31 Jul 2014, at 21:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Well done JB! > This is great to see this fork realigned and to identify the changes. > Thanks for your constant push. > > Stef > > On 31 Jul 2014, at 16:33, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> > wrote: > > Hi, > I made some advance on Android StackVM (using the standard unix sources). > > :-) > > Last Unix Stack VM with last 40Pharo image (a little bit modified cause au > no-NativeBoost and some constraint from the Android Sandboxing ). > Content: > - Somes lines of code change in SqUnixMain.c (using if define android, but > not a lot, just for allow to load external lib :-). > - 1 communication with java / C files, (will be split in two or three file > one for printing debugging, one or two for core). > - 1 external graphical plugins. vm-display-android, really short but for > android, because the rendering is done by Android. > > > All these plugins are includes (not deeply tested yet, but most of them > should work): > AndroidPlugin (for now I just allow to do debug printing from the image in > the logCat), BitBltPlugin, B2DPlugin, BMPReadWriterPlugin, CroquetPlugin, > DSAPrims, FFTPlugin, FileCopyPlugin, FilePlugin, FloatArrayPlugin, > FloatMathPlugin, JoystickTabletPlugin, JPEGReaderPlugin, > LargeIntegers,Matrix2x3Plugin, RePlugin, SecurityPlugin, > JPEGReadWriter2Plugin, SocketPlugin, MiscPrimitivePlugin, ZipPlugin. > > And a lot of debugging. :-). > > Next step: > - fixing all the Event. > - Do a real Configuration generator to be able to generate from Jenkins > using the NDK. > - Then merge in the main PharoVM Git :-). > - Do a configuration to allow older pharo image to run on it. Maybe older > but I not convince yet. > - And obviously a job for allow anybody to create a android package with > it's own image :-) > > See you soon :-) > > <IMG_3934.jpeg> > > Best Regards > Dr Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > Best Regards > Dr Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

Aug. 1, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Damien Cassou

On Thu, Jul 31, 2014 at 10:50 PM, stepharo <stepharo(a)free.fr> wrote: > what are you doing? I think Mariano would like something like this: persons sorted: #(lastname firstname birthdate) asSortBlock that would sort by lastname, and if lastnames are equal by firstnames and if both lastnames and firstnames are equal by birthdate. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 1, 2014

Re: [Pharo-dev] Should nested mutexes work in Pharo 3.0?

by Ben Coman

Marcel Taeumel wrote: > Okay, I disagree. :) Or I need to rephrase the situation here. ;) > > I have one process in Pharo that locks the mutex, calls some code and then > comes across another piece of code that wants to lock the *same* mutex again > in the same process, do some stoff, before return to the original call > again. Everything happens in one process (= green thread). As far as I > understood, this is the common "recursive" property of a mutex, which > could/should work. :) > > If the Mutex in Pharo does not support recursive locking from within the > same process, then it is more like a binary semaphore, right? > Recursive locking appears to be provided by the following line activeProcess == owner ifTrue:[^aBlock value]. in Mutex>>critical: btw, if you step into your example, you'll see the mutex is implemented using semaphores. cheers -ben > Okay, this simple "nesting" works in Pharo: > > m := Mutex new. > m critical: [ > Morph new. > m critical: [Morph new]]. > > But this is not exactly the same setting as in Animations. I need to test it > a little bit more. :) > > Best, > Marcel > > >

Aug. 1, 2014

Re: [Pharo-dev] Should nested mutexes work in Pharo 3.0?

by Marcel Taeumel

Okay, this simple "nesting" works in Pharo: m := Mutex new. m critical: [ Morph new. m critical: [Morph new]]. But this is not exactly the same setting as in Animations. I need to test it a little bit more. :) Best, Marcel -- View this message in context: http://forum.world.st/Should-nested-mutexes-work-in-Pharo-3-0-tp4771110p477… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 1, 2014

Re: [Pharo-dev] Should nested mutexes work in Pharo 3.0?

by Marcel Taeumel

Okay, I disagree. :) Or I need to rephrase the situation here. ;) I have one process in Pharo that locks the mutex, calls some code and then comes across another piece of code that wants to lock the *same* mutex again in the same process, do some stoff, before return to the original call again. Everything happens in one process (= green thread). As far as I understood, this is the common "recursive" property of a mutex, which could/should work. :) If the Mutex in Pharo does not support recursive locking from within the same process, then it is more like a binary semaphore, right? Best, Marcel -- View this message in context: http://forum.world.st/Should-nested-mutexes-work-in-Pharo-3-0-tp4771110p477… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 1, 2014

Re: [Pharo-dev] rethinking the print it action in Pharo

by S Krish

Kind of back to the Future. Why not have a console rectangle scrollable area at the bottom of the workspace window, that can be persistent on clicking on it and gives the result of "print it" accumulating till a clear is called. Setting to clear on every run or retain text can be done. This is a bit like in Eclipse transient window on inspect but simpler and retains the printed text if reqd. On Tue, Jul 29, 2014 at 1:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > On Mon, Jul 28, 2014 at 9:58 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > >> Maybe remapping Command+p to inspect would solve it equally? :) >> > > This is a point worth debating (I really love when we allocate time to > talk about our UI - this is the one interface that we, in this community, > use every day). > > The goal of "Print it" serves as a quick and light readonly feedback, and > I think it has a distinct place that is separate from the inspector which > is a place where you interact and manipulate the object. Furthermore, in > the current implementation, the "print it" is floating and non intrusive > (it goes away easily) while the inspector is at the moment a lasting piece. > > Of course, we could imagine an inspector that could be embedded in the > popper window (in fact, I have that implementation, too :)), but the > problem is that in its current form, the inspector is not made to be easily > scalable. This might change with the adoption of Athens. > > In the meantime, one direction I think we could take is to produce several > scalable "printouts" that can also be visual. > > > >> Both of the example cases justifying it were that the user pressed the >> wrong key. UI's should not try to solve problems between the human <--> >> hardware interface. >> > > I am not sure I follow. Could you elaborate please? > > Cheers, > Doru > > >> >> >> >> On Sun, Jul 27, 2014 at 6:33 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Hi, >>> >>> In the course of revamping the Pharo environment, we stumbled across the >>> print it action and we (Andrei and I) decided to rethink it. >>> [image: Inline image 1] >>> >>> You can find more details here: >>> http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo >>> >>> Let us know what you think. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 1, 2014