- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] explore is broken

by Marcus Denker

On 03 Dec 2013, at 16:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 03 Dec 2013, at 16:31, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> It works in 30615 but is broken in 30616. >> >> No one knows about it yet I guess because 30616 is from today. >> >> The bug is from the one of the 30616 change. Can someone with a good Spec knowledge have a look at it ? >> > > It seems to work when removing the âcontentsâ send in the displayBlock: block in the method #tree of EyeTreeInspector. > > I will commit a fixâ¦ > https://pharo.fogbugz.com/f/cases/12328/TreeInspector-DNU will be in the next update. Marcus

Dec. 3, 2013

Re: [Pharo-dev] Versionner Impressions

by Sean P. DeNigris

Christophe Demarey wrote > Can you explain me your use case? Sure... I installed Phexample via the Configuration Browser, by switching to MetaRepoFor20. The config loaded Phexample from its home repository, sthub/Phexample/Phexample. When I added it as a dependent project, my choices IIRC were the package cache and MetaRepoFor20. I wanted to use the home repo but the widget only allowed me to choose from those two options. While we're on the subject, repo creation is complicated enough to warrant a nice widget everywhere in Versionner (and maybe port it over to Monticello Browser, whcih is not much better). IMHO, it needs to offer: - likely repos, like was done above e.g. repos associated to the package in question - all repos known to image - create new repo Christophe Demarey wrote > Do you mean for a new project? Yes, maybe the developer has already done > some commits. > I will add that. Yes, FMOD was one package, so I didn't make a config. Then I wrote tests in their own package... Thanks again :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Impressions-tp4726902p4727072.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 3, 2013

Re: [Pharo-dev] explore is broken

by Marcus Denker

On 03 Dec 2013, at 16:31, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > It works in 30615 but is broken in 30616. > > No one knows about it yet I guess because 30616 is from today. > > The bug is from the one of the 30616 change. Can someone with a good Spec knowledge have a look at it ? > It seems to work when removing the âcontentsâ send in the displayBlock: block in the method #tree of EyeTreeInspector. I will commit a fixâ¦ Marcus

Dec. 3, 2013

Re: [Pharo-dev] explore is broken

by ClÃ©ment Bera

It works in 30615 but is broken in 30616. No one knows about it yet I guess because 30616 is from today. The bug is from the one of the 30616 change. Can someone with a good Spec knowledge have a look at it ? 2013/12/3 Oscar Nierstrasz @ gmail <oscar.nierstrasz(a)gmail.com> > > There is something wrong with the EyeTreeInspector in the latest Pharo > image: > > Smalltalk explore > > brings up the debugger. > > Ditto if you inspect and manually select the EyeTreeInspector. > > I could not find any issue in the issue tracker about this. Does anyone > know about it? > > Oscar >

Dec. 3, 2013

explore is broken

by Oscar Nierstrasz ＠ gmail

There is something wrong with the EyeTreeInspector in the latest Pharo image: Smalltalk explore brings up the debugger. Ditto if you inspect and manually select the EyeTreeInspector. I could not find any issue in the issue tracker about this. Does anyone know about it? Oscar

Dec. 3, 2013

Smalltalkhub ci image

by Stephan Eggermont

The smalltalkhub build has been red for quite some time now. If I want to run a hub, should I take the latest build? Stephan

Dec. 3, 2013

Re: [Pharo-dev] Smalltalkhub ci image

by Yuriy Tymchuk

I was using a latest stable build and it works ok. Uko On 03 Dec 2013, at 15:58, Stephan Eggermont <stephan(a)stack.nl> wrote: > The smalltalkhub build has been red for quite some time now. If I want to run a hub, > should I take the latest build? > > Stephan

Dec. 3, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by kilon alios

you dont have to wait for my example as i said checkSession is already the example checkSession session == Smalltalk session ifFalse: [ "just reset the surface" surface := nil. session := Smalltalk session. ] as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method. Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at. On Tue, Dec 3, 2013 at 4:51 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > > > On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> You are correct but so is Igor. Managing external resources has to do >> with VM and Nativeboost itself and not with Athens. This could happen with >> any other library. >> >> Session aware code is actually very easy to do and its explained >> Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines >> of code. >> >> In step2 method there is a relevant comment >> >> "IMPORTANT NOTE: >> the surface which we will create at this step will be used in later steps. >> This means that if you resize the window (changing the view size), you >> may need to recreate surface. >> Also, since surface uses external resources, quitting an image and >> restarting it, will also require to >> create a new surface, because the one from previous session will be no >> longer accessible. >> " >> > > Ok. Tx. That's very useful info. I'll have a look. > > >> >> but there is no mention to check the checkSession method for an example >> how sessions can be handled. I think this deserves a separate step by >> itself with a nice example. Igor you want me to give me commit rights to >> Athens repo to add that myself ? >> > > And if you add the example to Athens, please let me know. > > >> >> >> On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >> >>> >>> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >>>> >>>>> Igor, >>>>> >>>>> I had a look at Athens demo to understand how to manage sessions and >>>>> surfaces because Roassal uses AthensSurface and there is a defensive >>>>> mechanism in place in Roassal to initialize the surface in case it is not >>>>> done. In the meantime, I have discovered that the red rectangle bug is >>>>> present in Athens demos as well. >>>>> >>>>> So, to reproduce. >>>>> AthensFlakeDemo new openInWorld >>>>> save image >>>>> open image >>>>> >>>> >>>>> I tested in Moose 5.0. >>>>> >>>>> 1. Should I open a bug entry in Pharo? >>>>> >>>>> only if you intend to fix it. because this demo was not intended to be >>>> 'fully featured, end-user compatible >>>> and fool-proof demo'. it just a demo to show animation and discard it, >>>> but if you insist this is a bug, >>>> feel free to fix it. >>>> >>> >>> Unfortunately, I wont have time for this. For me it would have been >>> good, had Athens provided an example of session management as a good client >>> so that example-oriented people like me could understand easily. Because, >>> otherwise, I'll have to look at the code of NativeBoost and that adds to >>> the level of complexity because I would do things with trial and error. >>> >>> >>>> >>>> >>>>> 2. With my superficial knowledge of Athens, my guess is that the >>>>> session management can be done in Athens so that Roassal (and other tools >>>>> built on top of Athens) do not need to do it. May be it is the case already >>>>> but the demos are not using it then. >>>>> >>>>> I disagree. >>>> >>> Because then, files can also open/close and delete themselves >>>> automatically, so you will be left only to do reading and writing... >>>> Resource management is an application-level responsibility, not >>>> framework level. >>>> I cannot predict in Athens, how often one wants to create/destroy or >>>> (re)use surfaces, and therefore i cannot >>>> create and dispose them when i see fit within framework. >>>> Correct me if i wrong. >>>> >>> >>> I think this doesn't compare to file handling because there are many >>> types of operations possible on files and that are application-specific. >>> Here resource management is actually exception-handling: I should not give >>> to my client a surface that does not exist any more. Now, of course, if >>> there is some application-level intelligence is involved, we cannot put >>> that in the framework. >>> >>> But I would understand the absence of such a mechanism in the framework >>> but then a tutorial should explain to novices/first-timers how to do it. >>> >>> Usman >>> >>> >>> >>> >>>> >>>> >>>>> Usman >>>>> >>>>> >>>>> >>>>> On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >>>>> >>>>>> Hello Igor, >>>>>> >>>>>> Moose 5.0 is using Athens as default canvas for Roassal and we have >>>>>> bug with Roassal that seems to be related to Athens. >>>>>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>>>>> >>>>>> I think it is related to the fact that we create a surface in the OS >>>>>> with Athens and once we quit the image, the surface is destroyed as well. >>>>>> So, when image is restarted with the visualization trying to use the >>>>>> surface, we get the error. >>>>>> >>>>>> Could you point to what possibly can be done to avoid this error? >>>>>> Merely checking the existence of an appropriate drawing surface in Athens >>>>>> every time visualization is drawn, would it suffice? >>>>>> >>>>>> regards, >>>>>> >>>>>> Usman >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >

Dec. 3, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Usman Bhatti

On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > You are correct but so is Igor. Managing external resources has to do with > VM and Nativeboost itself and not with Athens. This could happen with any > other library. > > Session aware code is actually very easy to do and its explained > Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines > of code. > > In step2 method there is a relevant comment > > "IMPORTANT NOTE: > the surface which we will create at this step will be used in later steps. > This means that if you resize the window (changing the view size), you > may need to recreate surface. > Also, since surface uses external resources, quitting an image and > restarting it, will also require to > create a new surface, because the one from previous session will be no > longer accessible. > " > Ok. Tx. That's very useful info. I'll have a look. > > but there is no mention to check the checkSession method for an example > how sessions can be handled. I think this deserves a separate step by > itself with a nice example. Igor you want me to give me commit rights to > Athens repo to add that myself ? > And if you add the example to Athens, please let me know. > > > On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > >> >> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >>> >>>> Igor, >>>> >>>> I had a look at Athens demo to understand how to manage sessions and >>>> surfaces because Roassal uses AthensSurface and there is a defensive >>>> mechanism in place in Roassal to initialize the surface in case it is not >>>> done. In the meantime, I have discovered that the red rectangle bug is >>>> present in Athens demos as well. >>>> >>>> So, to reproduce. >>>> AthensFlakeDemo new openInWorld >>>> save image >>>> open image >>>> >>> >>>> I tested in Moose 5.0. >>>> >>>> 1. Should I open a bug entry in Pharo? >>>> >>>> only if you intend to fix it. because this demo was not intended to be >>> 'fully featured, end-user compatible >>> and fool-proof demo'. it just a demo to show animation and discard it, >>> but if you insist this is a bug, >>> feel free to fix it. >>> >> >> Unfortunately, I wont have time for this. For me it would have been good, >> had Athens provided an example of session management as a good client so >> that example-oriented people like me could understand easily. Because, >> otherwise, I'll have to look at the code of NativeBoost and that adds to >> the level of complexity because I would do things with trial and error. >> >> >>> >>> >>>> 2. With my superficial knowledge of Athens, my guess is that the >>>> session management can be done in Athens so that Roassal (and other tools >>>> built on top of Athens) do not need to do it. May be it is the case already >>>> but the demos are not using it then. >>>> >>>> I disagree. >>> >> Because then, files can also open/close and delete themselves >>> automatically, so you will be left only to do reading and writing... >>> Resource management is an application-level responsibility, not >>> framework level. >>> I cannot predict in Athens, how often one wants to create/destroy or >>> (re)use surfaces, and therefore i cannot >>> create and dispose them when i see fit within framework. >>> Correct me if i wrong. >>> >> >> I think this doesn't compare to file handling because there are many >> types of operations possible on files and that are application-specific. >> Here resource management is actually exception-handling: I should not give >> to my client a surface that does not exist any more. Now, of course, if >> there is some application-level intelligence is involved, we cannot put >> that in the framework. >> >> But I would understand the absence of such a mechanism in the framework >> but then a tutorial should explain to novices/first-timers how to do it. >> >> Usman >> >> >> >> >>> >>> >>>> Usman >>>> >>>> >>>> >>>> On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >>>> >>>>> Hello Igor, >>>>> >>>>> Moose 5.0 is using Athens as default canvas for Roassal and we have >>>>> bug with Roassal that seems to be related to Athens. >>>>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>>>> >>>>> I think it is related to the fact that we create a surface in the OS >>>>> with Athens and once we quit the image, the surface is destroyed as well. >>>>> So, when image is restarted with the visualization trying to use the >>>>> surface, we get the error. >>>>> >>>>> Could you point to what possibly can be done to avoid this error? >>>>> Merely checking the existence of an appropriate drawing surface in Athens >>>>> every time visualization is drawn, would it suffice? >>>>> >>>>> regards, >>>>> >>>>> Usman >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

Dec. 3, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by kilon alios

You are correct but so is Igor. Managing external resources has to do with VM and Nativeboost itself and not with Athens. This could happen with any other library. Session aware code is actually very easy to do and its explained Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines of code. In step2 method there is a relevant comment "IMPORTANT NOTE: the surface which we will create at this step will be used in later steps. This means that if you resize the window (changing the view size), you may need to recreate surface. Also, since surface uses external resources, quitting an image and restarting it, will also require to create a new surface, because the one from previous session will be no longer accessible. " but there is no mention to check the checkSession method for an example how sessions can be handled. I think this deserves a separate step by itself with a nice example. Igor you want me to give me commit rights to Athens repo to add that myself ? On Tue, Dec 3, 2013 at 4:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > > On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >> >>> Igor, >>> >>> I had a look at Athens demo to understand how to manage sessions and >>> surfaces because Roassal uses AthensSurface and there is a defensive >>> mechanism in place in Roassal to initialize the surface in case it is not >>> done. In the meantime, I have discovered that the red rectangle bug is >>> present in Athens demos as well. >>> >>> So, to reproduce. >>> AthensFlakeDemo new openInWorld >>> save image >>> open image >>> >> >>> I tested in Moose 5.0. >>> >>> 1. Should I open a bug entry in Pharo? >>> >>> only if you intend to fix it. because this demo was not intended to be >> 'fully featured, end-user compatible >> and fool-proof demo'. it just a demo to show animation and discard it, >> but if you insist this is a bug, >> feel free to fix it. >> > > Unfortunately, I wont have time for this. For me it would have been good, > had Athens provided an example of session management as a good client so > that example-oriented people like me could understand easily. Because, > otherwise, I'll have to look at the code of NativeBoost and that adds to > the level of complexity because I would do things with trial and error. > > >> >> >>> 2. With my superficial knowledge of Athens, my guess is that the session >>> management can be done in Athens so that Roassal (and other tools built on >>> top of Athens) do not need to do it. May be it is the case already but the >>> demos are not using it then. >>> >>> I disagree. >> > Because then, files can also open/close and delete themselves >> automatically, so you will be left only to do reading and writing... >> Resource management is an application-level responsibility, not framework >> level. >> I cannot predict in Athens, how often one wants to create/destroy or >> (re)use surfaces, and therefore i cannot >> create and dispose them when i see fit within framework. >> Correct me if i wrong. >> > > I think this doesn't compare to file handling because there are many types > of operations possible on files and that are application-specific. Here > resource management is actually exception-handling: I should not give to my > client a surface that does not exist any more. Now, of course, if there is > some application-level intelligence is involved, we cannot put that in the > framework. > > But I would understand the absence of such a mechanism in the framework > but then a tutorial should explain to novices/first-timers how to do it. > > Usman > > > > >> >> >>> Usman >>> >>> >>> >>> On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >>> >>>> Hello Igor, >>>> >>>> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >>>> with Roassal that seems to be related to Athens. >>>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>>> >>>> I think it is related to the fact that we create a surface in the OS >>>> with Athens and once we quit the image, the surface is destroyed as well. >>>> So, when image is restarted with the visualization trying to use the >>>> surface, we get the error. >>>> >>>> Could you point to what possibly can be done to avoid this error? >>>> Merely checking the existence of an appropriate drawing surface in Athens >>>> every time visualization is drawn, would it suffice? >>>> >>>> regards, >>>> >>>> Usman >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Dec. 3, 2013