- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

Thierry, Very good points and I agree with all of them ... Regarding a Smalltalk-based merge tool, I've written a git mergetool for tODE (consider it a prototype) that could be adapted/ported for Pharo .... My thoughts regarding the MC issues ... Fyou make good points some of the "internal bugs" in MC and I think that it is important to point out that the "internal bugs" you are referring to only affect Monticello with regards to its repository functionality and not its package functionality . My inclination is to move forward and create a new, simpler package model (Cypress is a good name) that is used with disk-based repos ... the new package model would be protocol compatible with MC so that definition-based snapshot comparisons continue. The new package model would only be used for loading and there could/should be facilities for converting between MC and this new package model. FileTree would continue to be MC based and Cypress would be able to read FileTree and FileTree would be able to read Cypress. The improvements and changes that we are discussing (many of which require a fair amount of implementation work) would be done in Cypress ... The rationale is that Monticello packages encompass both the repository and the code/definitions and for disk-based scms, Cypress would only need to worry about the code/definitions --- and would make it possible to move away from the version number-based package names that aren't necessary when the underlying scm is doing the versioning without affecting the MC implementation .... Of course, if a new Cypress package model were introduced, the tools would need to change, but since we are already considering changing tools, this would be the perfect time to improve the underlying model for disk-based SCMs. Dale On 2/3/16 1:13 AM, Thierry Goubier wrote: > > I went through all the different possible file formats, class-based, > package-based, method-based, log metadata and the like, and I > concluded that: > > - the method based format is as good as any other. > - method based format allow for method-history queries on the git/vcs > history (as well as class based / package based queries). > - the tree structure on github or bitbucket is quite convenient (and > browsable) to the point one could edit a package directly in it (I do > when I need to do a quick fix). > - anything that can compress a bit the metadata version is probably > good to consider. version files can be huge. > - merge drivers really work and releave us from conflict resolution > - we need a merge tool written in Smalltalk/MC > - MC version numbering is a very bad idea > - MC almost never using properly UUIDs is a very bad behavior > - MC packages history can be considered broken in the general case > - it takes time to define, implement, test and really use a new format > and tooling

Feb. 3, 2016

Re: [Pharo-dev] Monkey: "Check seems to be stuck. I will try it again"

by Denis Kudriashov

Idea is to restart Monkey check automatically. Monkey can set up timeout status when check required too long time. But there are cases when Monkey process is died somehow and issue becomes "Checking" forever. New job detects such issues and revert it to previous state where Monkey can check it again. 2016-02-03 14:49 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Ok, thanks Denis. Maybe the job should switch to Work needed? so it does > not start again and again (like it happened in my case). > MartÃn > El 3/2/2016 6:38, "Denis Kudriashov" <dionisiydk(a)gmail.com> escribiÃ³: > >> I increased timeout for two hours >> >> 2016-02-03 10:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> We added new job to resume hanging status "Monkey is checking". >>> Maybe we should increase timeout. Now when Monkey checks issue more than >>> 1 hour we revert it status to "Fix Review Needed" >>> >>> 2016-02-03 4:24 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: >>> >>>> Hi, >>>> >>>> That's Monkey's result in my case ( >>>> https://pharo.fogbugz.com/f/cases/14605/Integrate-Epicea) I don't see >>>> other cases with the same result. Don't know where to look up to understand >>>> it... Any pointer? >>>> >>>> Thanks >>>> Martin >>>> >>> >>> >>

Feb. 3, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50565 Home: https://github.com/pharo-project/pharo-core

Feb. 3, 2016