- Pharo-dev - lists.pharo.org

ZnEasy and post:data:

by Benjamin Pollack

Hey all, This is probably me missing something, but: for an upcoming presentation, I wanted to find the tersest way to demonstrate making an HTTP POST.Â Something equivalent to Python's requests.post('http://some/thing', data={'foo': 'bar', 'baz': 'quux'}) The closest I could come up with for Pharo was ZnEasy post: 'http://some/thing' data: (ZnApplicationFormUrlEncodedEntity withAll: { 'foo' -> 'bar'. 'baz' -> 'quux'. } asDictionary) I just wanted to verify that is, in fact, the shortest way to do this. I feel as if I'm almost certainly missing a utility method around the ZnApplicationFormUrlEncodedEntity bit, and, especially for demos, terseness matters. (It's obviously trivial to write a utility method if this *is* the shortest way to do this, but then people in the audience won't be able to execute the resulting code snippet without the utility method.) Thanks, --Benjamin

Oct. 2, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Esteban Lorenzano

it was the tree-shaped inspector, it does not have sense anymore with the new inspector (since everything is rolled into one). > On 01 Oct 2014, at 22:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > What is explorer? > > Doru > > On Wed, Oct 1, 2014 at 10:12 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > Alex > > play looks like flash or music not like executing. > > We all complain that smalltalk is weak and that people can make silly statements like > Java is compiled and Smalltalk intepreted (I read that in the lecture)!!! > But this is our fault. > > In my book you will not see evaluating an expresssion, I execute it. > So please we should not use silly names and more important we should not think that is is ok because > we should think about new people. > > so for me cmd-e is good that we can map > cmd-i for inspector > cmd-I for explorer. > > Simple and straightforward. > > Stef > > > > On 1/10/14 19:03, Alexandre Bergel wrote: > 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 <mailto:estebanlm@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 <mailto:sven@stfx.eu>> wrote: > > > On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@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 <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Tudor Girba

What is explorer? Doru On Wed, Oct 1, 2014 at 10:12 PM, stepharo <stepharo(a)free.fr> wrote: > Alex > > play looks like flash or music not like executing. > > We all complain that smalltalk is weak and that people can make silly > statements like > Java is compiled and Smalltalk intepreted (I read that in the > lecture)!!! > But this is our fault. > > In my book you will not see evaluating an expresssion, I execute it. > So please we should not use silly names and more important we should not > think that is is ok because > we should think about new people. > > so for me cmd-e is good that we can map > cmd-i for inspector > cmd-I for explorer. > > Simple and straightforward. > > Stef > > > > On 1/10/14 19:03, Alexandre Bergel wrote: > >> 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 >>>>> >>>> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Tudor Girba

The play symbol is also used for run. That is why we used that icon. But, we can change it. Ideas? Btw, all the icons used in GT and Moose are drawn by me and licensed under CC Attribution: https://github.com/girba/mooseart Cheers, Doru On Wed, Oct 1, 2014 at 10:12 PM, stepharo <stepharo(a)free.fr> wrote: > Alex > > play looks like flash or music not like executing. > > We all complain that smalltalk is weak and that people can make silly > statements like > Java is compiled and Smalltalk intepreted (I read that in the > lecture)!!! > But this is our fault. > > In my book you will not see evaluating an expresssion, I execute it. > So please we should not use silly names and more important we should not > think that is is ok because > we should think about new people. > > so for me cmd-e is good that we can map > cmd-i for inspector > cmd-I for explorer. > > Simple and straightforward. > > Stef > > > > On 1/10/14 19:03, Alexandre Bergel wrote: > >> 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 >>>>> >>>> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by Tudor Girba

Ok, I will try to explain again: Cmd+i means inspect. When I am in a class browser, it means that the inspector windows opens up. But, when I am in the inspector, it can simply mean open a new pane to the right. Then if you explicitly want to open a window you use an imperative Inspect that we can map on Cmd+Shift+i (like we did for the explorer before). I think this would fit, but it would be a bit difficult to implement. Is it clearer? What do you think? Cheers, Doru On Wed, Oct 1, 2014 at 10:09 PM, stepharo <stepharo(a)free.fr> wrote: > > On 1/10/14 16:55, Tudor Girba wrote: > > 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? > > I'm lost. > > > > 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" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by stepharo

Alex play looks like flash or music not like executing. We all complain that smalltalk is weak and that people can make silly statements like Java is compiled and Smalltalk intepreted (I read that in the lecture)!!! But this is our fault. In my book you will not see evaluating an expresssion, I execute it. So please we should not use silly names and more important we should not think that is is ok because we should think about new people. so for me cmd-e is good that we can map cmd-i for inspector cmd-I for explorer. Simple and straightforward. Stef On 1/10/14 19:03, Alexandre Bergel wrote: > 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

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by stepharo

On 1/10/14 16:55, Tudor Girba wrote: > 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? I'm lost. > > Cheers, > Doru > > On Wed, Oct 1, 2014 at 4:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@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 >> <mailto:chisvasileandrei@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 <mailto:estebanlm@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 <mailto:sven@stfx.eu>> wrote: >>> >>> >>> On 01 Oct 2014, at 16:00, Andrei Chis >>> <chisvasileandrei(a)gmail.com >>> <mailto:chisvasileandrei@gmail.com>> wrote: >>> >>>> >>>> >>>> On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe >>>> <sven(a)stfx.eu <mailto:sven@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 <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by stepharo

On 1/10/14 16:06, Esteban Lorenzano wrote: > and btw, what about remap cmd+o to cmd+e (like âexecuteâ) ? + 1 and rename open to execute! > > Esteban > >> On 01 Oct 2014, at 16:05, Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> >> On 01 Oct 2014, at 16:00, Andrei Chis <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com>> wrote: >> >>> >>> >>> On Wed, Oct 1, 2014 at 3:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu >>> <mailto:sven@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 >

Oct. 1, 2014

Re: [Pharo-dev] GTPlayground Play Button Semantics

by stepharo

Open is not a good name. I want to execute something not opening it. I would never think that open is executing an expression and inspecting the result. Stef On 1/10/14 16:05, Sven Van Caekenberghe 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 >> >> >> > >

Oct. 1, 2014

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

by Esteban Lorenzano

crapâ¦ I was victim of IMAP OSX Mail bug. This answer should be linked to other thread, sorry. > On 01 Oct 2014, at 20:12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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