- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! I'll keep trying to reproduce and keep you posted On 02/04/2016 10:21 AM, stepharo wrote: > Hi guille > > Esteban got some problems with MC recently > so it would be good to have a reproducible case. > > Stef > > > Le 4/2/16 10:07, Guille Polito a Ã©crit : >> Ok, I am puzzled. I downloaded a new fresh image, in a fresh >> directory, worked on something else, committed, and my commit is >> completely broken. >> Attached screenshot of what monticello shows me. >> >> I'm on debian jessie 64bits. Maybe it has something to do? >> >> On 02/03/2016 03:41 PM, Guille Polito wrote: >>> Hi all, >>> >>> I'm finally back, rechecking this issue: >>> >>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>> >>> >>> I remade the Slice to load in latest Pharo5 with the new Spur >>> changes, plus some fixes proposed by Nicolai. I can load the slice >>> in a new image and everything looks ok. So far so good. >>> >>> Now, the monkey starts checking the Slice and somehow it cannot load >>> the Slice due to "dependencies to some classes". Of course, the >>> slice I submitted does not depend on the packages on the complaint, >>> and locally it loads well. Moreover, I never had/worked with those >>> classes, nor they were installed in my system. Even, I have a new >>> machine which is clean so I cannot believe I have some interference >>> due to some package cache... >>> >>> The message of the monkey is here: >>> >>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>> >>> >>> Did somebody find some similar problem or it is just me? I believe >>> the problem is on the monkey side, but I have no clue... Maybe >>> somebody has a better idea. >>> >>> Thanks! >>> Guille >> > >

Feb. 4, 2016

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] Contributing to Pharo

by Thierry Goubier

Le 04/02/2016 10:04, Nicolas Cellier a Ã©crit : > I don't understand broken history either. > Yes there can be .mcz name clashes but UUID history is stored together > in metadata no? Yes. > If some tool only trust .mcz name without checking UUID, consider it's a > bug, and let's correct it (there is some in Monticello Configuration Map) Gofer. In fact, most of Monticello never checks the UUID, only dependencies do, but this looks like a deprecated feature given how often it is used. > Or is it the fact that some .mcz could be missing? > Consider this is a feature, MC tools are robust to missing .mcz (it's > just that you'll have to redo the merge if you lost a common ancestor). What? You really consider that a feature? > Or is it the fact that some repository might contain only a slice of > history? > This is another feature... You can view all the versions in a collection > of repositories without needing to replicate. Understandable in theory. Unworkable over time and change (repositories disappear and die, and this stops working) > You can replicate if you want but it's not mandatory and completely > orthogonal. > So yes, this information - the list or repositories you want to consider > - has to be stored separetely and this can sound quite unconventional. > But IMO, it's an important feature: it gives much resilience for a very > low investment. > And that also mean that you can hardly break things (have unconsistent > history). > Maybe when you say broken, you mean not 100% git compatible? No, what I say is true mcz inconsistent history (missing versions making merges very unreliable, basically). I describe a while ago a case where, thanks to mcz features, I couldn't merge a small change done to Roassal without generating a ton of conflicts. I moved the three needed mcz(s) to git (the change ancestor, the change, and the current head), did git merge and had no conflicts. If you consider those features, then I disagree. I'd really like to improve MC and get a better integration. Considering those as features just make me think that Eliot may well be right in believing we'll end up throwing away MC completely. Coping with MC idiosyncrasies is hard as it is, and at least a complete replacement is being considered for Pharo. In the meantime, Cuis has completely given up managing packages in Smalltalk: all is done in git, externally. Thierry > 2016-02-04 7:53 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > 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> > <mailto:thierry.goubier@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] [Need help with Monkey] Removing Object>>name

by stepharo

Hi guille Esteban got some problems with MC recently so it would be good to have a reproducible case. Stef Le 4/2/16 10:07, Guille Polito a Ã©crit : > Ok, I am puzzled. I downloaded a new fresh image, in a fresh > directory, worked on something else, committed, and my commit is > completely broken. > Attached screenshot of what monticello shows me. > > I'm on debian jessie 64bits. Maybe it has something to do? > > On 02/03/2016 03:41 PM, Guille Polito wrote: >> Hi all, >> >> I'm finally back, rechecking this issue: >> >> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >> >> >> I remade the Slice to load in latest Pharo5 with the new Spur >> changes, plus some fixes proposed by Nicolai. I can load the slice in >> a new image and everything looks ok. So far so good. >> >> Now, the monkey starts checking the Slice and somehow it cannot load >> the Slice due to "dependencies to some classes". Of course, the slice >> I submitted does not depend on the packages on the complaint, and >> locally it loads well. Moreover, I never had/worked with those >> classes, nor they were installed in my system. Even, I have a new >> machine which is clean so I cannot believe I have some interference >> due to some package cache... >> >> The message of the monkey is here: >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >> >> >> Did somebody find some similar problem or it is just me? I believe >> the problem is on the monkey side, but I have no clue... Maybe >> somebody has a better idea. >> >> Thanks! >> Guille >

Feb. 4, 2016

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

by Christophe Demarey

Hi Alex, Thanks for your detailed explanation. To me,the design of the current UIManger is not good enough. UIManager has too much pre-occupations. He is in charge of: providing different implementation of interactive requests, depending if the current UI manager is interactive or not, if the UI is available or not, provide different way of handling errors, still depending on the interactive/UI status, initialize the current UI. At some point we should split that but it another story. For your use case, I think the only behavior missing for you from the old startup mechanism is a way to have both morphic and bloc available in the image and to stop an image and start with the ui manager in place at shutdown (the user can switch from Morphic to bloc and vice-versa). It think it is a valid use case and we could add a state to the startup ui manager to hold the value of the default ui manager. This way, we can restore it when we deinstall the startup ui manager. WDYT? Cheers, Christophe Le 4 fÃ©vr. 2016 Ã 09:48, Guille Polito a Ã©crit : > 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] [Need help with Monkey] Removing Object>>name

by Guille Polito

Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. Attached screenshot of what monticello shows me. I'm on debian jessie 64bits. Maybe it has something to do? On 02/03/2016 03:41 PM, Guille Polito wrote: > Hi all, > > I'm finally back, rechecking this issue: > > https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed > > I remade the Slice to load in latest Pharo5 with the new Spur changes, > plus some fixes proposed by Nicolai. I can load the slice in a new > image and everything looks ok. So far so good. > > Now, the monkey starts checking the Slice and somehow it cannot load > the Slice due to "dependencies to some classes". Of course, the slice > I submitted does not depend on the packages on the complaint, and > locally it loads well. Moreover, I never had/worked with those > classes, nor they were installed in my system. Even, I have a new > machine which is clean so I cannot believe I have some interference > due to some package cache... > > The message of the monkey is here: > > https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… > > > Did somebody find some similar problem or it is just me? I believe the > problem is on the monkey side, but I have no clue... Maybe somebody > has a better idea. > > Thanks! > Guille

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Nicolas Cellier

I don't understand broken history either. Yes there can be .mcz name clashes but UUID history is stored together in metadata no? If some tool only trust .mcz name without checking UUID, consider it's a bug, and let's correct it (there is some in Monticello Configuration Map) Or is it the fact that some .mcz could be missing? Consider this is a feature, MC tools are robust to missing .mcz (it's just that you'll have to redo the merge if you lost a common ancestor). Or is it the fact that some repository might contain only a slice of history? This is another feature... You can view all the versions in a collection of repositories without needing to replicate. You can replicate if you want but it's not mandatory and completely orthogonal. So yes, this information - the list or repositories you want to consider - has to be stored separetely and this can sound quite unconventional. But IMO, it's an important feature: it gives much resilience for a very low investment. And that also mean that you can hardly break things (have unconsistent history). Maybe when you say broken, you mean not 100% git compatible? 2016-02-04 7:53 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 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 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