- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Esteban Lorenzano

Process can always be enhanced, of course. But in fact what we did now was just to formalise what was already happening (with Zinc, for example). so we can continue enhancing it from here. about your fears: - all sub-projects will be (we still need to move some there) under âPharoâ umbrella, so once you have access to one you have access to all. - It will slowdown some stuff, but it will promote better decoupling of system components and with time, it will enhance (and speed) the work a lot. - most of the changes we made are just a few method changes that are almost all the time in just one package. The potential problem is just in the restâ¦ we will reduce the emergence of these in the process of extracting subprojects from what now is a complicated, monolithic system. The process of decoupling, btw, is an ongoing process from years now, and it still will take some more years. It will not be finished in Pharo4 and probably not on Pharo6 eitherâ¦ what we did now is to create the required infrastructure support for allow this decoupling. - This way is different to what we have been doing until now, I know, and it will need some adjustment in the way we contribute. But is a lot better! cheers, Esteban ps: Side note, about the issue linked: it was not going to happen that we change something through a slice, even without this new infrastructure, because is an external managed project (same as Zinc), and it will require a commit in appropriate repository anyway. > On 01 Oct 2014, at 19:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > And confusing as one can see here: https://pharo.fogbugz.com/f/cases/14137 > > Will we end up in "I need access to repo", "please add me as contributor to" > hell and slow down the integration process as one has to wait until the > responsible person has time (and is willing to accept the change)? > > I agree with the goal but not the way it is now presented to the community! > > For such an important change why not propose FIRST a plan how contribution process > will change, discussing how it could be handled best or supported by tools. > Instead you just change/enforce it and now discussion starts afterwards... > > Bye > T. > >> Gesendet: Mittwoch, 01. Oktober 2014 um 18:20 Uhr >> Von: "Sebastian Sastre" <sebastian(a)flowingconcept.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects >> >> sounds great! >> >> sebastian >> >> o/ >> >>> On 01/10/2014, at 12:41, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Hi, >>> >>> As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. >>> In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). >>> >>> Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) >>> Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. >>> And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. >>> >>> Those projects are, for now: >>> >>> - Zinc (responsible is Sven) >>> - GTools (responsibles are Doru and Andrei) >>> - OSWindow (responsible is Igor) >>> >>> We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) >>> >>> (I hope this mail is understandable... I feel I'm being super confusing :P) >>> >>> cheers, >>> Esteban >> >> >

Oct. 1, 2014

Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects

by Esteban Lorenzano

basically, if you working on a subproject, you should not mess with others. so, if you fixing, lets say, GTools, dirtiness should affect just him. If not, then you, gtool maintainers or pharo core maintainers made a mistake (or all of them). of course, that works *just* for sub-projects managed with configurations. All the rest still works as before. And for configurations, Iâm adapting the monkey to test them too (but you should not worry about that, unless you are a âsub-project maintainerâ). Esteban > On 01 Oct 2014, at 18:30, Ben Coman <btc(a)openInWorld.com> wrote: > > Esteban Lorenzano wrote: >> Hi, As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). >> Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) >> Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. Those projects are, for now: - Zinc (responsible is Sven) >> - GTools (responsibles are Doru and Andrei) >> - OSWindow (responsible is Igor) >> We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) >> (I hope this mail is understandable... I feel I'm being super confusing :P) >> cheers, >> Esteban > > Not confusing, and I like the philosophy, but there are some gaps. > > * How will multiple dirty sub-packages be bundled as a group for an issue? Could Versioneer be designed to help add a #fixNNNNN symbolic tag into the Configuration. Or do we name the files ConfigurationOfZinc-FixNNNNN? > > * How will the monkey interact with the submitted fixes, when they are first submitted? Its very useful for the monkey to remotely check the tests rather than have to wait for tests to run locally. > > cheers -ben >

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by Camille Teruel

On 1 oct. 2014, at 18:38, stepharo <stepharo(a)free.fr> wrote: > >> To distinguish between the different types of variables, we could add another column with a tag, like we have in the GTDebugger (e.g., Slot / Derived). What do you think? > > I do not like slots. > Because not all the objects have that. Apart from the variable part, all the state of any object is represented via slots. But the state view can easily find out that it's displaying an instance of a variable class and act accordingly. I like Doru's solution because it permits any object to have a good default state view without having to implement a bunch of special views. And if you want to see only the real layout of the object, you can always click on the 'iv' tag to filter out virtual slots. So you have one view to show all the relevant state information in one pane and a way to filter/sort it easily. Camille > Raw > Items > are working better to me >> >> Cheers, >> Doru >> >> On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> >> >> On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> I am confused about the GTInspector State tab. What is its definition ? >> >> I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. >> >> Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector). >> >> The only difference right now is in the way collections are handled. >> Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed. >> >> As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice. >> >> Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs. >> >> Now I also get your point about seeing only the raw fundamental data of an object. >> We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. >> For example display all the meta variables at the top on a slightly different background. >> >> We definitely need to iterate more :) >> >> >> >> Cheers, >> Andrei >> >> Why then does it not show all variable content and only named variables ? >> >> Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. >> >> How can I inspect an individual character of a String ? Or an individual byte ? >> >> Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. >> >> In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. >> >> I could propose changes or a slice, but I think we should agree on the definition of 'State' first. >> >> Sven >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

Oct. 1, 2014

Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects

by Torsten Bergmann

And confusing as one can see here: https://pharo.fogbugz.com/f/cases/14137 Will we end up in "I need access to repo", "please add me as contributor to" hell and slow down the integration process as one has to wait until the responsible person has time (and is willing to accept the change)? I agree with the goal but not the way it is now presented to the community! For such an important change why not propose FIRST a plan how contribution process will change, discussing how it could be handled best or supported by tools. Instead you just change/enforce it and now discussion starts afterwards... Bye T. > Gesendet: Mittwoch, 01. Oktober 2014 um 18:20 Uhr > Von: "Sebastian Sastre" <sebastian(a)flowingconcept.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects > > sounds great! > > sebastian > > o/ > > > On 01/10/2014, at 12:41, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi, > > > > As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. > > In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). > > > > Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) > > Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. > > And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. > > > > Those projects are, for now: > > > > - Zinc (responsible is Sven) > > - GTools (responsibles are Doru and Andrei) > > - OSWindow (responsible is Igor) > > > > We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) > > > > (I hope this mail is understandable... I feel I'm being super confusing :P) > > > > cheers, > > Esteban > >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Alexandre Bergel

cmd+e does not look like to be more explicit to me. Something that I find a little bit confusing, is âplayâ vs âopenâ. The button is a play button. But in the menu, it says âopenâ. Why not being consistent with âplayâ? Alexandre On Oct 1, 2014, at 7:06 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > and btw, what about remap cmd+o to cmd+e (like âexecuteâ) ? > > Esteban > >> On 01 Oct 2014, at 16:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >>> >>> >>> On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Was it a conscious decision to make the GTPlayground Play button act as 'play all' (evaluate the whole workspace contents) ? >>> >>> If so, why ? >>> >>> I find it quite limiting that I cannot select some expression and 'play it'. A workspace/playground is like a notebook containing lots of different things. >>> >>> >>> Yes, it is like this by design. The Play button at the top evaluates the entire content of the workspace. >>> >>> To evaluate just an expression you can select it and choose 'Open' from the context menu, or use CMD+o. >>> Just right now CMD+o is still broken due to the global shortcuts from opening tools. >>> >>> The Play button at the top works like that as we tried to have in the toolbar only global actions that apply on the entire presentations and not only on the selection. >>> Those that apply on the selection go in the context menu and should have keybindings >>> >>> Does this seem ok to you? >> >> Ah, I thought the open menu action worked like the inspect it menu action. >> OK, that works for me. >> >> Thanks. >> >>> Cheers, >>> Andrei >>> >>> >>> Sven > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by stepharo

> To distinguish between the different types of variables, we could add > another column with a tag, like we have in the GTDebugger (e.g., Slot > / Derived). What do you think? I do not like slots. Because not all the objects have that. Raw Items are working better to me > > Cheers, > Doru > > On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > > > On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > I am confused about the GTInspector State tab. What is its > definition ? > > I would say that it shows the raw, fundamental, implementation > form of the object, in essence what EyeBasicInspector showed. > And that additional tabs offer alternative, more user friendly > views. > > > Yes, I think that this should be the main purpose of the State > tab. (behave like EyeBasicInspector). > > The only difference right now is in the way collections are handled. > Collections should have an items views. Now sure why it is missing > for String and ByteArray. Maybe we thought it's not really needed. > > As we display the elements of a collection in a dedicated tab, > then indeed, the State view only shows self, which is not so nice. > > Still for objects like Integer, Float, CompiledMethod I'd like > that the State view contains some meta variables. I'd prefer this > rather to switching between two tabs. > > Now I also get your point about seeing only the raw fundamental > data of an object. > We could be to improve the state view to add both all the variable > + some meta variables and make it clear what are the meta variables. > For example display all the meta variables at the top on a > slightly different background. > > We definitely need to iterate more :) > > > Cheers, > Andrei > > > Why then does it not show all variable content and only named > variables ? > > Try inspecting a [Byte]String or [Byte]Array. The State view > is useless, it just shows self. Some of these have an items > view, but not all. > > How can I inspect an individual character of a String ? Or an > individual byte ? > > Consider a Float. The State view should show the two > (meaningless) slots because that is how Floats are (currently) > implemented, and then another tab should show the sign, > mantissa, exponent view. > > In the Eye inspectors we also confused these two aspects in a > single view, which is wrong in hindsight, IMHO. It should be > crystal clear for a user whether a slot is real or an > alternative view of describing the same thing. > > I could propose changes or a slice, but I think we should > agree on the definition of 'State' first. > > Sven > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] Confused about the GTInspector State Tab

by stepharo

On 1/10/14 16:30, Tudor Girba wrote: > Hi, > > Indeed, the goal of State is to show the raw state of every object. In > case we miss something, we should add that. Sven, if you see that this > is not happening, let's start on a case to case basis. Doru call it "raw" and not state. Especially if state may interpret the state > > Btw, if you want to know what gets shown in State, you can simply > inspect the result of Object>>#gtInspectorVariableValuePairs. You can > also override that for your own objects if you want. You can see a > post explaining this here: > http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspec… > > The default view is specified by the order. So, the first view is the > default one. We made the State view has order 10. If you define a view > with a lower order, it will appear first. We have to experiment here > with different objects. For example, for collections, a better default > view would be the items. We did not do that until now in order to not > alienate even more the users. But, I think now it's time to do it. yes > > Cheers, > Doru > > > > > On Wed, Oct 1, 2014 at 4:22 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > On 01 Oct 2014, at 15:08, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > > I am confused about the GTInspector State tab. What is its > definition ? > > > > I would say that it shows the raw, fundamental, implementation > form of the object, in essence what EyeBasicInspector showed. And > that additional tabs offer alternative, more user friendly views. > > > > Why then does it not show all variable content and only named > variables ? > > > > Try inspecting a [Byte]String or [Byte]Array. The State view is > useless, it just shows self. Some of these have an items view, but > not all. > > > > How can I inspect an individual character of a String ? Or an > individual byte ? > > > > Consider a Float. The State view should show the two > (meaningless) slots because that is how Floats are (currently) > implemented, and then another tab should show the sign, mantissa, > exponent view. > > > > In the Eye inspectors we also confused these two aspects in a > single view, which is wrong in hindsight, IMHO. It should be > crystal clear for a user whether a slot is real or an alternative > view of describing the same thing. > > > > I could propose changes or a slice, but I think we should agree > on the definition of 'State' first. > > > > I think this is just a matter of iterating, e.g. Dictionary has it > already correct: > State show the raw state (array, tally), while the âitemsâ view > shows nicely > key->values. > > an example where it fails is CompiledMethod, it has a Bytecode > view, but in addition a (virtual) âall byte codesâ variable in the > raw view. (and more). > > I think we need > -> the raw state for every object (like the old basic inspector) > -> this might not be the default view for all objects, though. > (the default should present something useful). > This means, maybe having the notion of a default view would be > nice. > -> work to add more views to everything interesting. > > Marcus > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects

by Ben Coman

Esteban Lorenzano wrote: > Hi, > > As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. > In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). > > Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) > Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. > And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. > > Those projects are, for now: > > - Zinc (responsible is Sven) > - GTools (responsibles are Doru and Andrei) > - OSWindow (responsible is Igor) > > We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) > > (I hope this mail is understandable... I feel I'm being super confusing :P) > > cheers, > Esteban > Not confusing, and I like the philosophy, but there are some gaps. * How will multiple dirty sub-packages be bundled as a group for an issue? Could Versioneer be designed to help add a #fixNNNNN symbolic tag into the Configuration. Or do we name the files ConfigurationOfZinc-FixNNNNN? * How will the monkey interact with the submitted fixes, when they are first submitted? Its very useful for the monkey to remotely check the tests rather than have to wait for tests to run locally. cheers -ben

Oct. 1, 2014

Re: [Pharo-dev] IMPORTANT: Contributing to "Configurated" sub-projects

by Sebastian Sastre

sounds great! sebastian o/ > On 01/10/2014, at 12:41, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. > In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). > > Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) > Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. > And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. > > Those projects are, for now: > > - Zinc (responsible is Sven) > - GTools (responsibles are Doru and Andrei) > - OSWindow (responsible is Igor) > > We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) > > (I hope this mail is understandable... I feel I'm being super confusing :P) > > cheers, > Esteban

Oct. 1, 2014

IMPORTANT: Contributing to "Configurated" sub-projects

by Esteban Lorenzano

Hi, As you might or might not seen, we are moving Pharo into a different architecture: From a monolitic "one-image-is-all", we are (very slowly) going into an small kernel and a set of sub-projects who will populate the image and provide all required features. In general, the idea is that the final state, what we call "Pharo" will stay as an unity with all the tools/frameworks/libraries you already know and love, but the building process will be completely different, allowing us to better manage the release process and allowing users to build their own versions of specific pharos (I can imagine, for example, morphic-less pharos used in server applications, etc.). Well... this direction we are taking just made his first change, that can annoy a bit the community, until we find a new equillibrium :) Until now, most changes, bugfixes, etc. were contributed using old know SLICES, who make a good job in this monilitic approach. And starting now, there are certain subprojects that cannot be managed like that anymore and has to be managed through regular contributions to their repositories. Then, responsible guys from those projects will submit an "Integration request" (something like a pull request), when they consider is necesary an update to Pharo. Those projects are, for now: - Zinc (responsible is Sven) - GTools (responsibles are Doru and Andrei) - OSWindow (responsible is Igor) We hope, with time, to move all non-kernel code into their respective sub-projects, all with their responsibles, but for now, we started with this ones :) (I hope this mail is understandable... I feel I'm being super confusing :P) cheers, Esteban

Oct. 1, 2014