June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Merge tool. No way to cherry pick the changes?

by StÃ©phane Ducasse

we should improve that aspect First would be to resurrect the install menu and behavior. Stef On Jun 21, 2011, at 4:04 PM, Guillermo Polito wrote: > Yeap, preety annoying. It's annoying too that you can't do any kind of filter (for example, to not show the ones marked as "revision changed"). Merging Glorp was kind of a mess :). > > On Tue, Jun 21, 2011 at 11:00 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I'm missing that too. > > In previous versions, IIRC, there was a menu item for changed methods named "Install". > > Adrian > > On Jun 21, 2011, at 14:37 , Igor Stasenko wrote: > > > I don't understand, when i merging, the merge tool showing me all the > > difference between current version and > > incoming one. > > It says '0 conflicts' and its ok to merge, but what if i want to > > choose to keep an old version for some methods, while merge the rest? > > > > What i see that there is no way to do that .. all menu items which > > would allow me to do that, like > > 'keep current version' > > 'use incoming verison' > > 'mark as conflict' > > are disabled. > > > > Which means that once machine decided that there is no conflict, you > > cannot do much. > > I tried to quickly hack the UI and enable those menu items , but it > > doesn't works, because the model itself seems like don't supports > > that. > > > > So, the question is how we can change that? As to me, it is certainly > > a missing feature, if i cannot freely choose between current and > > incoming version at > > my will, when merging. > > > > Gary (& all)? Any ideas? > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

June 21, 2011

Re: [Pharo-project] Merge tool. No way to cherry pick the changes?

by Guillermo Polito

Yeap, preety annoying. It's annoying too that you can't do any kind of filter (for example, to not show the ones marked as "revision changed"). Merging Glorp was kind of a mess :). On Tue, Jun 21, 2011 at 11:00 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I'm missing that too. > > In previous versions, IIRC, there was a menu item for changed methods named > "Install". > > Adrian > > On Jun 21, 2011, at 14:37 , Igor Stasenko wrote: > > > I don't understand, when i merging, the merge tool showing me all the > > difference between current version and > > incoming one. > > It says '0 conflicts' and its ok to merge, but what if i want to > > choose to keep an old version for some methods, while merge the rest? > > > > What i see that there is no way to do that .. all menu items which > > would allow me to do that, like > > 'keep current version' > > 'use incoming verison' > > 'mark as conflict' > > are disabled. > > > > Which means that once machine decided that there is no conflict, you > > cannot do much. > > I tried to quickly hack the UI and enable those menu items , but it > > doesn't works, because the model itself seems like don't supports > > that. > > > > So, the question is how we can change that? As to me, it is certainly > > a missing feature, if i cannot freely choose between current and > > incoming version at > > my will, when merging. > > > > Gary (& all)? Any ideas? > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

June 21, 2011

Re: [Pharo-project] Merge tool. No way to cherry pick the changes?

by Adrian Lienhard

I'm missing that too. In previous versions, IIRC, there was a menu item for changed methods named "Install". Adrian On Jun 21, 2011, at 14:37 , Igor Stasenko wrote: > I don't understand, when i merging, the merge tool showing me all the > difference between current version and > incoming one. > It says '0 conflicts' and its ok to merge, but what if i want to > choose to keep an old version for some methods, while merge the rest? > > What i see that there is no way to do that .. all menu items which > would allow me to do that, like > 'keep current version' > 'use incoming verison' > 'mark as conflict' > are disabled. > > Which means that once machine decided that there is no conflict, you > cannot do much. > I tried to quickly hack the UI and enable those menu items , but it > doesn't works, because the model itself seems like don't supports > that. > > So, the question is how we can change that? As to me, it is certainly > a missing feature, if i cannot freely choose between current and > incoming version at > my will, when merging. > > Gary (& all)? Any ideas? > > -- > Best regards, > Igor Stasenko AKA sig. >

June 21, 2011

Re: [Pharo-project] UITheme builder fileSave:...

by Alexandre Bergel

> Well, that's the way it was designed, to answer a file stream to which the file contents can be added. > Could be extended to support choosing file name (not file) to save to. > > I expect your exportWith uses #putForm:onFileNamed: whereas it could use #putForm:onStream: instead. I will change the interface indeed. Thanks Gary for your answer Cheers, Alexandre > > Regards, Gary > > ----- Original Message ----- From: "Alexandre Bergel" <alexandre.bergel(a)me.com> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, June 20, 2011 7:02 PM > Subject: [Pharo-project] UITheme builder fileSave:... > > >> Hi! >> >> I would like to use the builder to have a file selection. Here is my code: >> >> -=-=--=-=-=--=-=-=--=-=-=--=-=-=--= >> interactiveExportWith: imageWriterClass extension: fileExtension >> "Ask for a file name and a directory" >> >> | fileStream | >> fileStream := UITheme builder >> fileSave: 'Your title here' >> extensions: #('png') >> path: nil. >> >> "Very strange that I obtain a stream". >> fileStream ifNil: [ self inform: 'saving aborded'. ^ self ]. >> fileStream close. >> FileDirectory deleteFilePath: fileStream name. >> self exportWith: imageWriterClass fullname: fileStream name. >> -=-=--=-=-=--=-=-=--=-=-=--=-=-=--= >> >> I have no idea why fileSave:extensions:path: return a stream. If I just need a full file name ? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 21, 2011

[Pharo-project] Merge tool. No way to cherry pick the changes?

by Igor Stasenko

I don't understand, when i merging, the merge tool showing me all the difference between current version and incoming one. It says '0 conflicts' and its ok to merge, but what if i want to choose to keep an old version for some methods, while merge the rest? What i see that there is no way to do that .. all menu items which would allow me to do that, like 'keep current version' 'use incoming verison' 'mark as conflict' are disabled. Which means that once machine decided that there is no conflict, you cannot do much. I tried to quickly hack the UI and enable those menu items , but it doesn't works, because the model itself seems like don't supports that. So, the question is how we can change that? As to me, it is certainly a missing feature, if i cannot freely choose between current and incoming version at my will, when merging. Gary (& all)? Any ideas? -- Best regards, Igor Stasenko AKA sig.

June 21, 2011

Re: [Pharo-project] Gofer dependent on Zinc

by StÃ©phane Ducasse

On Jun 21, 2011, at 10:59 AM, Sven Van Caekenberghe wrote: > Hi Pavel, > > On 21 Jun 2011, at 09:56, Pavel Krivanek wrote: > >> Hi, >> >> I would like to point out to one new Pharo feature that is a potential >> issue. The package Zinc-Patch-HTTPSocket stole the ownership of >> several methods from the class HTTPSocket. > > That is correct. It is a consequence of including Zinc as standard component in Pharo Core. > > Note that many people think that most of HTTPSocket is of low quality and in need of being replaced. Yes we should do that in 1.4. Any code to go in that direction are welcome. >> That means that now this package doesn't act as an overlay patch. > > I don't understand the exact meaning of 'overlay patch'. > >> The consequences are not fatal. It only means that now the Gofer >> package that uses this methods is dependent on Zinc and it makes a >> headless Gofer image a little bit larger and less clean. > > Yes, currently the dependencies are Gofer -> HTTPSocket -> Zinc, but is could just as well (and better) be Gofer -> Zinc. > > Zinc is definitively headless ready and I would hope clean enough. > > I know that you want to reduce the code base as much as possible, but networking, http access and code loading can never really be removed I guess. > > If you have remarks regarding Zinc itself, I would love to help making it as modular and kernel ready as possible. > > Regards, > > Sven > >

June 21, 2011

Re: [Pharo-project] INRIAGForge Account was: [ Zinc Updates ]

by StÃ©phane Ducasse

Ok I added you to the project and now we will be able to show you what we are doing. In you want to read a bit there is a nice class comment in ScriptLoader :) Stef On Jun 21, 2011, at 9:56 AM, Sven Van Caekenberghe wrote: > > On 20 Jun 2011, at 15:24, StÃ©phane Ducasse wrote: > >> Can you start to create an account on gforge.inria.fr (RMOD team) ? >> And let me know. > > OK, I made an account with username 'svc'. > > Sven > >

June 21, 2011

Re: [Pharo-project] Gofer dependent on Zinc

by Pavel Krivanek

Hi Sven On Tue, Jun 21, 2011 at 10:59 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Pavel, > > On 21 Jun 2011, at 09:56, Pavel Krivanek wrote: > >> Hi, >> >> I would like to point out to one new Pharo feature that is a potential >> issue. The package Zinc-Patch-HTTPSocket stole the ownership of >> several methods from the class HTTPSocket. > > That is correct. It is a consequence of including Zinc as standard component in Pharo Core. > > Note that many people think that most of HTTPSocket is of low quality and in need of being replaced. > >> That means that now this package doesn't act as an overlay patch. > > I don't understand the exact meaning of 'overlay patch'. On the first sight this package is created as set of methods that only override a few methods in the HTTPSocket class. When now the original Network-Protocols package was published without this methods, there is no need to have it in the standalone package and it can be merged with Zinc-HTTP package. >> The consequences are not fatal. It only means that now the Gofer >> package that uses this methods is dependent on Zinc and it makes a >> headless Gofer image a little bit larger and less clean. > > Yes, currently the dependencies are Gofer -> HTTPSocket -> Zinc, but is could just as well (and better) be Gofer -> Zinc. > > Zinc is definitively headless ready and I would hope clean enough. > > I know that you want to reduce the code base as much as possible, but networking, http access and code loading can never really be removed I guess. > of course can and are :-) The PharoKernel image has no network support but full Pharo is able to fileout latest versions of this basic packages to local files and the kernel image can then load it from the local filesystem and continue with the next packages with help of Gofer. > If you have remarks regarding Zinc itself, I would love to help making it as modular and kernel ready as possible. > Ok, I will let you know -- Pavel > Regards, > > Sven > > >

June 21, 2011

Re: [Pharo-project] Gofer dependent on Zinc

by Sven Van Caekenberghe

Hi Pavel, On 21 Jun 2011, at 09:56, Pavel Krivanek wrote: > Hi, > > I would like to point out to one new Pharo feature that is a potential > issue. The package Zinc-Patch-HTTPSocket stole the ownership of > several methods from the class HTTPSocket. That is correct. It is a consequence of including Zinc as standard component in Pharo Core. Note that many people think that most of HTTPSocket is of low quality and in need of being replaced. > That means that now this package doesn't act as an overlay patch. I don't understand the exact meaning of 'overlay patch'. > The consequences are not fatal. It only means that now the Gofer > package that uses this methods is dependent on Zinc and it makes a > headless Gofer image a little bit larger and less clean. Yes, currently the dependencies are Gofer -> HTTPSocket -> Zinc, but is could just as well (and better) be Gofer -> Zinc. Zinc is definitively headless ready and I would hope clean enough. I know that you want to reduce the code base as much as possible, but networking, http access and code loading can never really be removed I guess. If you have remarks regarding Zinc itself, I would love to help making it as modular and kernel ready as possible. Regards, Sven

June 21, 2011

Re: [Pharo-project] why (UIManagerdefaultnewPluggableDialogWindow:'Pharo is cool') openInWorld

by Gary Chambers

UITheme - Theme specific look/feel and main "services" (dialogs for choosing fonts, colours etc.) TEasilyThemed - Trait facade with lighter-weight helpers for services and UI component creation. UIManager - Was, in Squeak, a facade for basic services (request text etc.). Now incorporates TEasilyThemed UITheme builder - an entry point for using TEasilyThemed if not desired/appropriate to incorporate the trait into the sender Since UIManager now incorporates TEasilyThemed, UITheme builder might as well reference UIManager default... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, June 20, 2011 7:41 PM Subject: Re: [Pharo-project] why (UIManagerdefaultnewPluggableDialogWindow:'Pharo is cool') openInWorld I have to digest that because for now the infrastructure and relationship between UITheme UIManager UITheme builder is not clear to me. For example I do not understand why the builder is just a composableMorph and not a builder. especially since Pluggable and friend invoke theme anyway. At the end we should have something much clearer. For me the responsibilities are not clear. Stef On Jun 20, 2011, at 12:10 PM, Gary Chambers wrote: > Some theme methods require the context of creation (aThemedMorph as > passed) for adapting to > corner style, colours etc. > > Perhaps, in TEasilyThemed, this context can be broken out into another > method that > MorphicUIManager could redefine as appropriate (guessing self world)... > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" > <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, June 20, 2011 10:43 AM > Subject: Re: [Pharo-project] why (UIManager > defaultnewPluggableDialogWindow:'Pharo is cool') openInWorld > > > > On Jun 20, 2011, at 11:11 AM, Gary Chambers wrote: > >> Because TEasilyThemed is designed to be applied to Morph subclasses... >> So when self (aMorphicUIManager) is passed to the theme it does not >> understand all Morph protocol. > > Yes I saw but I still wonder why this is needed to "copy" all these > protocols. > >> >> Regards, Gary >> >> ----- Original Message ----- From: "stephane ducasse" >> <stephane.ducasse(a)free.fr> >> To: "An open mailing list to discuss any topics related to an >> open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, June 18, 2011 6:58 PM >> Subject: [Pharo-project] why (UIManager default >> newPluggableDialogWindow:'Pharo is cool') openInWorld >> >> >>> why >>> >>> (UIManager default >>> newPluggableDialogWindow: 'Pharo is cool') openInWorld >>> >>> does not work? >>> Apparently MorphicUIManager is missing something? >>> Stef >> >> > > >

June 21, 2011