February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Guille Polito

Hi Alex, First, note that the current UIManager selection and the StartupUIManager appears from a cleanup on the old UIManager selection that existed. The idea is that the UIManagerSessionHandler will run in low priority and set a startup UIManager during startup (when you cannot ensure that UI is still operational) and then replace it by a default UIManager to keep backwards compatibility for now. But, Block can have its own startup action that installs it's own world/UIManager in a higher priority than the startup. Is this a possibility? Of course I think morphic should do the same: it should have a startup action that initiates a UI thread, and a corresponding UImanager. But we did not attack that refactor yet, :). We should be able to explicitly recreate the UI process on each startup. Then, a second problem is having a different UIManager for each World/Universe, and have co-existing Morphic/Block or even different Block universes. Today's UIManager is global and shared by everybody, as it always was and it never took into account the multiple world possibility... So, any proposal in this direction would be nice! On 02/04/2016 01:17 AM, Ben Coman wrote: > On Thu, Feb 4, 2016 at 5:06 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Bloc has its own UIManager, UI process, event fetchers and space/worlds. >> Because Bloc is not yet a default UI framework in pharo we want to switch to >> it manualy. To do this we have a world menu entry (switch to bloc). During >> switching process Bloc UIManager should become current default UIManager. >> Bloc's root model class is Universe. Universe can have multiple spaces where >> each space can have multiple worlds. For each space we assign its own >> UIManager with UI process, fetchers and so on to allow running multiple >> spaces in "<parallel>". To be able to switch between pharo morphic and bloc >> we have by default two running spaces: Bloc Space and Morphic Space. Each of >> them has its own UIManager: Bloc UI manager (new one) and Morphic UIManager >> (one that is in Pharo without Bloc being set during >> UIManagerSessionHandler>>#startup:). > Thanks for that description Aex. I haven't seen much doc on the Bloc > architecture, so it is interesting hear of this Universe part. > I wonder... even if Bloc is not yet ready for prime time default use, > how ready is the Universe sub-part? > Could this part be enabled by default prior to the rest of Bloc being > ready for default? and would that help your case? > > Further along that line of thought, considering the > modularisation/minimalisation effort, is it possible the Universe part > could be completely separated from Bloc, so we could (for > demonstration only) have only Universe+Morphic, but also later if > someone was to resurrect MVC, we could be have only Universe+MVC, or > only... > * Universe+RemoteUI > * Universe+Headless > * Universe+CommandLineREPL > * Universe+EmergencyUI > * Universe+SomeOtherExperiment > > Or is Universe not an appropriate container for those sorts of things? > > cheers -ben > > >> In bloc, Space is responsible for starting and stopping itself (stopping >> listeners, stopping ui thread and so on). It means that Bloc UIManager can >> not exist without Bloc Space. (egg is Space, chicken is UIManager). >> >> We want users to be able to switch to bloc manually and allow to save image >> within the bloc to be able to get directly to it after startup. >> (if user saves in morphic, after start up she gets to morphic. If she saves >> in bloc, after startup she gets to bloc). >> >> My problem is the following method: >> >>> UIManagerSessionHandler>>#startup: isImageStarting >>> "Install the right UIManager" >>> UIManager default: UIManager forCurrentSystemConfiguration. >> >> If there is a subclass of MorphicUIManager in the system, a subclass will be >> used as default UIManager. (due to forCurrentSystemConfiguration) >> Now imagine I create a Bloc UIManager which is a subclass of >> MorphicUIManager. Bloc UI Manager as described above can not live without >> Bloc Space, because space controls ui manager. Even if I don't want to >> switch to bloc - Bloc UI Manager will be used by default, which leads to >> NullPointerException (space is undefined). >> >> Now Imagine that we just load Bloc as part of build process. During first >> image start forCurrentSystemConfiguration selects BlocUIManager and image >> crashes. >> >> I see that something is broken. Let's find out what and where. And fix asap! >> >> Cheers, >> Alex >> >> On Tue, Feb 2, 2016 at 7:31 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> UIManagerSessionHandler>>#startup: isImageStarting >>> "Install the right UIManager" >>> UIManager default: UIManager forCurrentSystemConfiguration. >>> >>> Setting (overring current one) default UIManager each time image is >>> saved/started up prevents us from having custom UIManagers, for example Bloc >>> UI manager >>> >>> On Tue, Feb 2, 2016 at 7:04 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >>> wrote: >>>> When deleting a class I get deprecation in #50561 in >>>> SystemDictionary>>#forgetClass: aClass logged: aBool because of >>>> removeFromStartUpList: >>>> >>>> >>>> Cheers, >>>> Alex

Feb. 4, 2016

Re: [Pharo-dev] Side by side GTInspector?

by stepharo

What would be good is also to have the possibility to drag and drop an item from one to the other (by creating a binding) this way you can do self == draggedObject It was possible with the old old inspector. Stef Le 3/2/16 20:20, Mariano Martinez Peck a Ã©crit : > Hi guys, > > In the SUnit extentions of the debugger, there is an embebed side by > side inspector to compare current vs expected value. I would love to > have that functionality at GTInspector level (in general) to compare 2 > or more objects side by side without having to use 2 inspectors. > > Would this be possible? > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 4, 2016

Re: [Pharo-dev] an example of debugging with moldable tools

by stepharo

I like the idea of having a different representation for the trace. Le 3/2/16 14:53, Tudor Girba a Ã©crit : > Hi, > > One thing we noticed over the past year since we introduced GT in Pharo is that people still tend to use these tools in a similar way classic tools were used. We think there is a more potential in these tools. > > To change this, we would like to collect stories of how using these tools enabled a workflow that was otherwise not possible. To get this started, we will start to document more consistently some of the sessions, and we would like to get input from your as well. The idea is to create a catalog of tutorials that people can follow and get inspired from. > > Let me start. I recently had to debug a small problem, and I ended up having an experience that I found beautiful: > http://www.humane-assessment.com/blog/debugging-duplicated-behavior-with-gt… > > What do you think? > > Cheers, > Doru

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 03/02/2016 23:58, Dale Henrichs a Ã©crit : > > > On 02/03/2016 02:34 PM, Thierry Goubier wrote: >> Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : >>> >>> >>> On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> Hi Eliot, >>> >>> Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : >>> .... >>> >>> >>> No it's /not/ the end of the story. The essential part of the >>> story is >>> how Monticello remains compatible and interoperable between >>> dialects. I >>> haven't seen you account for how you maintain that >>> compatibility. As >>> far as I can tell, you propose replacing the Monticello metadata >>> with >>> that from git. How do I, as a Squeak user with Monticello, ever >>> get to >>> look at your package again? As I understand it, moving the >>> metadata >>> from Monticello commit time to git means that the metadata is >>> in a >>> format that git determines, not Monticello. >>> >>> >>> Yes. See below why. >>> >>> So I don't understand how on the one hand you can say "The >>> Monticello >>> metadata in a git repository is redundant and leads to >>> unnecessary >>> commit conflicts -- end of story ....", which implies you >>> want to >>> eliminate the Monticello metadata, and on the other hand you say >>> you're >>> keeping the Monticello metadata. I'm hopelessly confused. How >>> does the >>> Monticello metadata get reconstituted if it's been thrown away? >>> >>> What happens to the metadata in the following workflow? >>> >>> load package P from Monticello repository R into an image >>> change P, commit via git to local git repository G >>> load P from G into an image >>> store P to R via Monticello >>> >>> >>> It's not a scenario I've specifically worked on, but all the tech is >>> implemented / implementable to do that perfectly. >>> >>> The only thing that is problematic there is that the only safe >>> history is the one generated from git... there are so many MC >>> packages with broken history that, on mcz packages, you have to >>> admit that it's not safe to base things on their history. >>> >>> >>> I'm sorry but I don't accept that. In the Squeak trunk we have history >>> in our mczs that is correct. Certainly in VMMaker.oscog I have history >>> that goes back a long time. If bugs have broken history then efforts >>> should be made to repair that history. But you can't just write off >>> Monticello history like that. >> >> I don't. You presuppose. >> >> I write tools that work with Monticello repositories, not just yours. >> I have to do with what is given to me. On a general level, as a mcz >> user, I'll just have to consider that you are as susceptible to be >> trusted as with any other mcz producer. This means not much... > > ... And this is the reason why I am inclined to favor option 3, which > records the package version history as it existed at the point it was > copied into a git repo. When copied back out from the git universe, > create a version history that starts with the original version history > and generates a history of the package in git .... Which is not very difficult to do given how GitFileTree is implemented. And I agree this may well be the way to go. But ... > Correct or not, the Monticello version history should be preserved .... I wonder about that. The property of the Monticello version history is that it has value when you can access the versions listed in it. If you mix repositories like that, unless you maintain a link to the previous mcz repository, pre-git versions can't be accessed. So, most of the time, what we do with a project moved under git is to clone the previous repository, not take just the current head. (you'll notice, by the way, that vcs usually work that way when moving from, say, CVS to git - you move the entire repository, not just the latest version). In short, the question would really be: 1- should we invest into making that integration of past history a selling point (but I foresee issues down the road; I've only described one so far, and I have seen others) or 2- into making a better "clone" of a package history, timestamps and everything when moving a complete repository to git? Honestly, I'd consider 1- to be the easiest to implement. 2- there is already some code floating around. Thierry

Feb. 4, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Ben Coman

On Thu, Feb 4, 2016 at 5:06 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Bloc has its own UIManager, UI process, event fetchers and space/worlds. > Because Bloc is not yet a default UI framework in pharo we want to switch to > it manualy. To do this we have a world menu entry (switch to bloc). During > switching process Bloc UIManager should become current default UIManager. > Bloc's root model class is Universe. Universe can have multiple spaces where > each space can have multiple worlds. For each space we assign its own > UIManager with UI process, fetchers and so on to allow running multiple > spaces in "<parallel>". To be able to switch between pharo morphic and bloc > we have by default two running spaces: Bloc Space and Morphic Space. Each of > them has its own UIManager: Bloc UI manager (new one) and Morphic UIManager > (one that is in Pharo without Bloc being set during > UIManagerSessionHandler>>#startup:). Thanks for that description Aex. I haven't seen much doc on the Bloc architecture, so it is interesting hear of this Universe part. I wonder... even if Bloc is not yet ready for prime time default use, how ready is the Universe sub-part? Could this part be enabled by default prior to the rest of Bloc being ready for default? and would that help your case? Further along that line of thought, considering the modularisation/minimalisation effort, is it possible the Universe part could be completely separated from Bloc, so we could (for demonstration only) have only Universe+Morphic, but also later if someone was to resurrect MVC, we could be have only Universe+MVC, or only... * Universe+RemoteUI * Universe+Headless * Universe+CommandLineREPL * Universe+EmergencyUI * Universe+SomeOtherExperiment Or is Universe not an appropriate container for those sorts of things? cheers -ben > > In bloc, Space is responsible for starting and stopping itself (stopping > listeners, stopping ui thread and so on). It means that Bloc UIManager can > not exist without Bloc Space. (egg is Space, chicken is UIManager). > > We want users to be able to switch to bloc manually and allow to save image > within the bloc to be able to get directly to it after startup. > (if user saves in morphic, after start up she gets to morphic. If she saves > in bloc, after startup she gets to bloc). > > My problem is the following method: > >> UIManagerSessionHandler>>#startup: isImageStarting >> "Install the right UIManager" >> UIManager default: UIManager forCurrentSystemConfiguration. > > > If there is a subclass of MorphicUIManager in the system, a subclass will be > used as default UIManager. (due to forCurrentSystemConfiguration) > Now imagine I create a Bloc UIManager which is a subclass of > MorphicUIManager. Bloc UI Manager as described above can not live without > Bloc Space, because space controls ui manager. Even if I don't want to > switch to bloc - Bloc UI Manager will be used by default, which leads to > NullPointerException (space is undefined). > > Now Imagine that we just load Bloc as part of build process. During first > image start forCurrentSystemConfiguration selects BlocUIManager and image > crashes. > > I see that something is broken. Let's find out what and where. And fix asap! > > Cheers, > Alex > > On Tue, Feb 2, 2016 at 7:31 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> UIManagerSessionHandler>>#startup: isImageStarting >> "Install the right UIManager" >> UIManager default: UIManager forCurrentSystemConfiguration. >> >> Setting (overring current one) default UIManager each time image is >> saved/started up prevents us from having custom UIManagers, for example Bloc >> UI manager >> >> On Tue, Feb 2, 2016 at 7:04 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >>> >>> When deleting a class I get deprecation in #50561 in >>> SystemDictionary>>#forgetClass: aClass logged: aBool because of >>> removeFromStartUpList: >>> >>> >>> Cheers, >>> Alex

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 02/03/2016 02:34 PM, Thierry Goubier wrote: > Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : >> >> >> On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Eliot, >> >> Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : >> .... >> >> >> No it's /not/ the end of the story. The essential part of the >> story is >> how Monticello remains compatible and interoperable between >> dialects. I >> haven't seen you account for how you maintain that >> compatibility. As >> far as I can tell, you propose replacing the Monticello metadata >> with >> that from git. How do I, as a Squeak user with Monticello, ever >> get to >> look at your package again? As I understand it, moving the >> metadata >> from Monticello commit time to git means that the metadata is >> in a >> format that git determines, not Monticello. >> >> >> Yes. See below why. >> >> So I don't understand how on the one hand you can say "The >> Monticello >> metadata in a git repository is redundant and leads to >> unnecessary >> commit conflicts -- end of story ....", which implies you >> want to >> eliminate the Monticello metadata, and on the other hand you say >> you're >> keeping the Monticello metadata. I'm hopelessly confused. How >> does the >> Monticello metadata get reconstituted if it's been thrown away? >> >> What happens to the metadata in the following workflow? >> >> load package P from Monticello repository R into an image >> change P, commit via git to local git repository G >> load P from G into an image >> store P to R via Monticello >> >> >> It's not a scenario I've specifically worked on, but all the tech is >> implemented / implementable to do that perfectly. >> >> The only thing that is problematic there is that the only safe >> history is the one generated from git... there are so many MC >> packages with broken history that, on mcz packages, you have to >> admit that it's not safe to base things on their history. >> >> >> I'm sorry but I don't accept that. In the Squeak trunk we have history >> in our mczs that is correct. Certainly in VMMaker.oscog I have history >> that goes back a long time. If bugs have broken history then efforts >> should be made to repair that history. But you can't just write off >> Monticello history like that. > > I don't. You presuppose. > > I write tools that work with Monticello repositories, not just yours. > I have to do with what is given to me. On a general level, as a mcz > user, I'll just have to consider that you are as susceptible to be > trusted as with any other mcz producer. This means not much... ... And this is the reason why I am inclined to favor option 3, which records the package version history as it existed at the point it was copied into a git repo. When copied back out from the git universe, create a version history that starts with the original version history and generates a history of the package in git .... Correct or not, the Monticello version history should be preserved .... Dale

Feb. 3, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : > > > On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Eliot, > > Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : > .... > > > No it's /not/ the end of the story. The essential part of the > story is > how Monticello remains compatible and interoperable between > dialects. I > haven't seen you account for how you maintain that > compatibility. As > far as I can tell, you propose replacing the Monticello metadata > with > that from git. How do I, as a Squeak user with Monticello, ever > get to > look at your package again? As I understand it, moving the metadata > from Monticello commit time to git means that the metadata is in a > format that git determines, not Monticello. > > > Yes. See below why. > > So I don't understand how on the one hand you can say "The > Monticello > metadata in a git repository is redundant and leads to unnecessary > commit conflicts -- end of story ....", which implies you want to > eliminate the Monticello metadata, and on the other hand you say > you're > keeping the Monticello metadata. I'm hopelessly confused. How > does the > Monticello metadata get reconstituted if it's been thrown away? > > What happens to the metadata in the following workflow? > > load package P from Monticello repository R into an image > change P, commit via git to local git repository G > load P from G into an image > store P to R via Monticello > > > It's not a scenario I've specifically worked on, but all the tech is > implemented / implementable to do that perfectly. > > The only thing that is problematic there is that the only safe > history is the one generated from git... there are so many MC > packages with broken history that, on mcz packages, you have to > admit that it's not safe to base things on their history. > > > I'm sorry but I don't accept that. In the Squeak trunk we have history > in our mczs that is correct. Certainly in VMMaker.oscog I have history > that goes back a long time. If bugs have broken history then efforts > should be made to repair that history. But you can't just write off > Monticello history like that. I don't. You presuppose. I write tools that work with Monticello repositories, not just yours. I have to do with what is given to me. On a general level, as a mcz user, I'll just have to consider that you are as susceptible to be trusted as with any other mcz producer. This means not much... Thierry

Feb. 3, 2016

Re: [Pharo-dev] Contributing to Pharo

by Eliot Miranda

On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Eliot, > > Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : > .... > >> >> No it's /not/ the end of the story. The essential part of the story is >> how Monticello remains compatible and interoperable between dialects. I >> haven't seen you account for how you maintain that compatibility. As >> far as I can tell, you propose replacing the Monticello metadata with >> that from git. How do I, as a Squeak user with Monticello, ever get to >> look at your package again? As I understand it, moving the metadata >> from Monticello commit time to git means that the metadata is in a >> format that git determines, not Monticello. >> > > Yes. See below why. > > So I don't understand how on the one hand you can say "The Monticello >> metadata in a git repository is redundant and leads to unnecessary >> commit conflicts -- end of story ....", which implies you want to >> eliminate the Monticello metadata, and on the other hand you say you're >> keeping the Monticello metadata. I'm hopelessly confused. How does the >> Monticello metadata get reconstituted if it's been thrown away? >> >> What happens to the metadata in the following workflow? >> >> load package P from Monticello repository R into an image >> change P, commit via git to local git repository G >> load P from G into an image >> store P to R via Monticello >> > > It's not a scenario I've specifically worked on, but all the tech is > implemented / implementable to do that perfectly. > > The only thing that is problematic there is that the only safe history is > the one generated from git... there are so many MC packages with broken > history that, on mcz packages, you have to admit that it's not safe to base > things on their history. I'm sorry but I don't accept that. In the Squeak trunk we have history in our mczs that is correct. Certainly in VMMaker.oscog I have history that goes back a long time. If bugs have broken history then efforts should be made to repair that history. But you can't just write off Monticello history like that. But what does this imply to some package that starts off in a Monticello >> repository and then spends some time in gitland? Can I merge again? If >> I can I'm happy. If I can't, I feel sabotaged. >> > > You could. Just express your needs and wait until one of us has enough > free time to solve it for you, that is. > > Fine. Except merging is, IIUC, about method time stamps and ancestry. >> If that gets preserved then I'm happy. But for the life of me I haven't >> read an explanation that reassures me that these are being preserved. >> Do you see the roots of my fear? >> > > Of course. But that also project a bit what you think of the people > working on it... which may makes it a bit hard to answer. > > Thierry > _,,,^..^,,,_ best, Eliot

Feb. 3, 2016

Re: [Pharo-dev] SessionManager (aka new startup / shutdown list manager) needs testers

by Aliaksei Syrel

Bloc has its own UIManager, UI process, event fetchers and space/worlds. Because Bloc is not yet a default UI framework in pharo we want to switch to it manualy. To do this we have a world menu entry (switch to bloc). During switching process Bloc UIManager should become current default UIManager. Bloc's root model class is Universe. Universe can have multiple spaces where each space can have multiple worlds. For each space we assign its own UIManager with UI process, fetchers and so on to allow running multiple spaces in "<parallel>". To be able to switch between pharo morphic and bloc we have by default two running spaces: Bloc Space and Morphic Space. Each of them has its own UIManager: Bloc UI manager (new one) and Morphic UIManager (one that is in Pharo without Bloc being set during UIManagerSessionHandler>>#startup:). In bloc, Space is responsible for starting and stopping itself (stopping listeners, stopping ui thread and so on). It means *that Bloc UIManager can not exist without Bloc Space.* (egg is Space, chicken is UIManager). We want users to be able to switch to bloc manually and allow to save image within the bloc to be able to get directly to it after startup. (if user saves in morphic, after start up she gets to morphic. If she saves in bloc, after startup she gets to bloc). My problem is the following method: UIManagerSessionHandler>>#startup: isImageStarting > "Install the right UIManager" > UIManager default: UIManager forCurrentSystemConfiguration. *If there is a subclass of MorphicUIManager in the system, a subclass will be used as default UIManager*. (due to forCurrentSystemConfiguration) Now imagine I create a Bloc UIManager which is a subclass of MorphicUIManager. Bloc UI Manager as described above can not live without Bloc Space, because space controls ui manager. Even if I don't want to switch to bloc - Bloc UI Manager will be used by default, which leads to NullPointerException (space is undefined). Now Imagine that we just load Bloc as part of build process. During first image start forCurrentSystemConfiguration selects BlocUIManager and image crashes. I see that something is broken. Let's find out what and where. And fix asap! Cheers, Alex On Tue, Feb 2, 2016 at 7:31 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > UIManagerSessionHandler>>#startup: isImageStarting > "Install the right UIManager" > UIManager default: UIManager forCurrentSystemConfiguration. > > Setting (overring current one) default UIManager each time image is > saved/started up prevents us from having custom UIManagers, for example > Bloc UI manager > > On Tue, Feb 2, 2016 at 7:04 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> When deleting a class I get deprecation in #50561 in >> SystemDictionary>>#forgetClass: aClass logged: aBool because >> of removeFromStartUpList: >> >> >> Cheers, >> Alex >> >> On Sat, Dec 5, 2015 at 2:39 PM, Christophe Demarey < >> christophe.demarey(a)inria.fr> wrote: >> >>> >>> >>> ------------------------------ >>> >>> *De: *"Nicolai Hess" <nicolaihess(a)gmail.com> >>> *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> *EnvoyÃ©: *Vendredi 4 DÃ©cembre 2015 22:05:26 >>> *Objet: *Re: [Pharo-dev] SessionManager (aka new startup / shutdown >>> list manager) needs testers >>> >>> >>> Looks good. What are the main critical startup/shutdown users( classes) >>> that should be tested? >>> >>> Classes using startup or/and shutdown are >>> >>> #SmallInteger >>> #Delay atPriority >>> #ProcessorScheduler >>> #InputEventFetche >>> #InputEventFetcher >>> #OSPlatfor >>> #Stdio >>> #LanguageEnvironment >>> #ShortIntegerArray >>> #DiskStore >>> #SmalltalkImage >>> #WeakFinalizationList >>> #Clipboard >>> #MCMethodDefinition >>> #Symbol >>> #Locale >>> #MultiByteFileStream >>> #WeakArray >>> #FileStream >>> #FileLocator >>> #BasicCommandLineHandler >>> #NonInteractiveTranscript >>> #ASTCache >>> #OSEnvironment >>> #EndianDetector >>> #InternetConfiguration >>> #ZnServer >>> #MCGitHubRepository >>> #ZnLogEvent >>> #DisplayScreen >>> #InputEventSensor >>> #Cursor >>> #Form >>> #StrikeFont >>> #Color >>> #FreeTypeCache >>> #LogicalFont >>> #FT2Handle >>> #FreeTypeSettings >>> #WorldMorph >>> #CPUWatcher >>> #NOCCompletionTable >>> #Nautilus >>> #PharoCommonTools >>> #GTPlayBook >>> >>> Also sensitive code could be the one using the session (Smalltalk >>> session) to check if they need to free or reset some resources. >>> >>> Thanks to have a look at it, >>> Christophe >>> >>> >>> I did some tests with AthensSceneView (uses NB and calls Smalltalk >>> session for reinit external resources) and Roassal. >>> I got one image startup failure, but I couldn't reproduce it yet. Maybe >>> I did image save and image save and quit, too quick. >>> >>> >> >

Feb. 3, 2016

Side by side GTInspector?

by Mariano Martinez Peck

Hi guys, In the SUnit extentions of the debugger, there is an embebed side by side inspector to compare current vs expected value. I would love to have that functionality at GTInspector level (in general) to compare 2 or more objects side by side without having to use 2 inspectors. Would this be possible? -- Mariano http://marianopeck.wordpress.com

Feb. 3, 2016