October 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Christophe Demarey

Le 1 oct. 2014 Ã 16:55, Tudor Girba a Ã©crit : > Cmd+g sounds like fun :). > > The other thing could be to have cmd+i as a replacement for cmd+o when you are in the inspector. When outside, Cmd+i would spawn an inspector window if the surrounding browser does not support in-place inspection (like the playground). > > To force inspect in a new window we could use Cmd+Shift+i and this would be uniformly applied everywhere. > > What do you think? Yes, I like it. no need of a new shortcut. It was the first thing I tried in the Playground before seeing the arrow in the menu. Christophe.

Oct. 1, 2014

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

by Andrei Chis

Hmm, a column for a tag would take even more space and for most objects it will only be Slot. Also with the icons and the arrow for collapsing it might not look so good. The other solution is to display all derived variables at the top, perhaps with a different color or/and in italic. On Wed, Oct 1, 2014 at 4:32 PM, Tudor Girba <tudor(a)tudorgirba.com> 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? > > 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] GTPlayground Play Button Semantics

by Tudor Girba

Hi Sven, Thanks a lot for these questions. Please keep them coming. These first impressions are really important because we have the opportunity to evolve. @Everyone: if you see me or Andrei providing arguments is not to say that we want to be right, but simply to show what we took into consideration up to this point. Please keep challenging what you see. Cheers, Doru On Wed, Oct 1, 2014 at 4:05 PM, 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 > > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Tudor Girba

Cmd+g sounds like fun :). The other thing could be to have cmd+i as a replacement for cmd+o when you are in the inspector. When outside, Cmd+i would spawn an inspector window if the surrounding browser does not support in-place inspection (like the playground). To force inspect in a new window we could use Cmd+Shift+i and this would be uniformly applied everywhere. What do you think? Cheers, Doru On Wed, Oct 1, 2014 at 4:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > so far, we want to keep cmd+o to open tools. > > then what about cmd+g for âcmd+goâ (and as Guille says, an internal joke > for âcmd+gDoitâ) :P > > Esteban > > On 01 Oct 2014, at 16:15, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > If we want to keep cmd+o for opening the tools then it make sense to use > cmd+e. > Just it could be a little confusing because cmd+e was already user before > to open the explorer. > > We wanted a new shortcut to avoid this confusion. But I am not against > using cmd+e > > On Wed, Oct 1, 2014 at 4:06 PM, 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 >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

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

by Tudor Girba

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? 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] Confused about the GTInspector State Tab

by Tudor Girba

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. 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. Cheers, Doru On Wed, Oct 1, 2014 at 4:22 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 01 Oct 2014, at 15:08, 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. > > > > 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 "Every thing has its own flow"

Oct. 1, 2014

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

by Andrei Chis

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 > > >

Oct. 1, 2014