- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Tudor Girba

I have a different opinion. This modality issue is not something we fix as a bug. Of course, we can put in place a patch that somehow makes it work in the current browser, but the core problem is a conceptual one. And that requires a redesign of the user interface. If we have a problem with a code model, we do not just put an if to patch the thing. Ok, sometimes we do that just because we cannot see a different solution, but we are not comfortable with it. We have to treat the user interface in the same way. Doru On Wed, Sep 4, 2013 at 9:56 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Sep 3, 2013, at 9:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > agreed we should change that since years. > > Some days we should stop and fix all the glitches that give us these > hiccups. > > ... and that day is around october, when we freeze pharo3 and start to fix > bugs :) > > Esteban > > > > > stef > > > > On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> > >> this is most annoying to me, that UI interrupts you in very strange > manner > >> and asks you to make a decision: > >> - accept, or discard the method, or cancel the action. > >> > >> often, you are in the middle of typing new stuff and source code > >> can be even not syntactically correct.. so, you have to discard or die > :) > >> > >> what i think the solution could be is that browser should allow you to > switch contexts > >> at any moment without asking you anything.Instead it should remember > your > >> unsaved changes in special 'drafts' collection, which later you can get > back on, > >> when you finish what you wanted to do. > >> > >> And the only time when you want unaccepted edits to not get lost > forever is when you closing > >> a browser window.. (but of course, drafts can be stored globally > somewhere, > >> then it also not a big deal, since you can simply return to your draft > in different window). > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 04/09/2013 10:06, Marcus Denker a Ã©crit : > > On Sep 4, 2013, at 10:00 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 04/09/2013 09:40, Marcus Denker a Ã©crit : >>>>>> >>>>> >>>>> Why do you need to support Squeak 3.8? This is how many years old? >>>>> >>>>> I really do not understand this idea to be compatible to all old versions ever. >>>> >>>> I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. >>>> >>>>> In the end it will just make sure that no progress is possible at all. >>>> >>>> I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. >>> >>> Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially >>> not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these >>> tend to introduce new problems, making it very hard to stabilize). >> >> Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? > > No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do > what we did in Pharo3 in Pharo2, then these Problems are in Pharo2. > >> >>> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >>> But nevertheless, all show-stopping bugs should be fixed. >> >> >>> In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? >> >> I can undestand that. >> >> I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. >> >> But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. >> > > What is a solution other than stopping development and declaring Pharo as finished as it is? No. Just admit that you have productions 1.4 (and maybe 1.3) hanging around, that 2.0 is the main development platform for Pharo users, 3.0 is where you make interesting stuff. And that Pharo users are at least one version behind you, and that they would like a bit of smoothness in the way it evolves... 3.0 gives directions; but a bit of backport to help with the transition would be, what, just friendly to your users. For example, for things I am aware of: - backport ensureDelete to 2.0 - backport the replacement of Keymapping on:do: You have 2.0 users who have things to say and who are able to correct things as well; don't belittle them by saying "All software development should be done on 3.0" [Camillo Bruni]. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 04/09/2013 09:40, Marcus Denker a Ã©crit : >>>> >>> >>> Why do you need to support Squeak 3.8? This is how many years old? >>> >>> I really do not understand this idea to be compatible to all old versions ever. >> >> I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. >> >>> In the end it will just make sure that no progress is possible at all. >> >> I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. > > Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially > not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these > tend to introduce new problems, making it very hard to stabilize). Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? > But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. > But nevertheless, all show-stopping bugs should be fixed. I'm OK with that. It's just that I'm updating a fix for a bug on both Pharo2 and Pharo3 by myself just to be able to open a file browser and get correct file permissions. I'm also unable to be sympathetic to a situation where I have two versions of a code just because when deprecating ensureDeleted in 3.0, nobody thought usefull to backport ensureDelete so that we could ensure that code using ensureDelete could work on both versions. > In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? I can undestand that. I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Marcus Denker

On Sep 4, 2013, at 10:00 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 04/09/2013 09:40, Marcus Denker a Ã©crit : >>>>> >>>> >>>> Why do you need to support Squeak 3.8? This is how many years old? >>>> >>>> I really do not understand this idea to be compatible to all old versions ever. >>> >>> I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. >>> >>>> In the end it will just make sure that no progress is possible at all. >>> >>> I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. >> >> Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially >> not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these >> tend to introduce new problems, making it very hard to stabilize). > > Are you afraid that by improving Pharo2 on a production-level, you would remove incentives to move to pharo3? No, I am afraid that the improvements add more bugs. This is in the end why there are Problems in Pharo3. If we do what we did in Pharo3 in Pharo2, then these Problems are in Pharo2. > >> But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. >> But nevertheless, all show-stopping bugs should be fixed. > > >> In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? > > I can undestand that. > > I also understand that you need 3.0 to be declared unstable to be able to make the necessary improvements in it. > > But this has the following consequences for non-core development, say SmaCC for example: 2.0 is the platform for unstable, 1.4 is where your stuff is stable (2.0 if you're lucky), and 3.0 is don't develop until it has reached a sufficient level of maturity. I will do things on SmaCC in the near future, but not on 3.0. > What is a solution other than stopping development and declaring Pharo as finished as it is? Marcus

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Esteban Lorenzano

On Sep 3, 2013, at 9:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > agreed we should change that since years. > Some days we should stop and fix all the glitches that give us these hiccups. ... and that day is around october, when we freeze pharo3 and start to fix bugs :) Esteban > > stef > > On Sep 3, 2013, at 3:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> this is most annoying to me, that UI interrupts you in very strange manner >> and asks you to make a decision: >> - accept, or discard the method, or cancel the action. >> >> often, you are in the middle of typing new stuff and source code >> can be even not syntactically correct.. so, you have to discard or die :) >> >> what i think the solution could be is that browser should allow you to switch contexts >> at any moment without asking you anything.Instead it should remember your >> unsaved changes in special 'drafts' collection, which later you can get back on, >> when you finish what you wanted to do. >> >> And the only time when you want unaccepted edits to not get lost forever is when you closing >> a browser window.. (but of course, drafts can be stored globally somewhere, >> then it also not a big deal, since you can simply return to your draft in different window). >> >> >> -- >> Best regards, >> Igor Stasenko. > >

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Marcus Denker

>>> >> >> Why do you need to support Squeak 3.8? This is how many years old? >> >> I really do not understand this idea to be compatible to all old versions ever. > > I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. > >> In the end it will just make sure that no progress is possible at all. > > I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Who says that? We always said that we will back-port all imported fixes to 2.0. We will not back-port *everything*, especially not improvements that are not fixes, because then there would be no difference between Pharo3 and Pharo2 (and these tend to introduce new problems, making it very hard to stabilize). But it is clear that this is a fine line: one persons fix is the others persons bug, so we tend to be conservative. But nevertheless, all show-stopping bugs should be fixed. right now, there are 3 bugs reported for Pharo 2.0: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed none of which is fixed in Pharo3 yet. In general: It is *a lot* of work, and it is hard to get right in all cases. But considering that: do we really do that badly? Marcus

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Dennis Schetinin

Here's [ http://www.cincomsmalltalk.com/publicRepository/VB-Sketch-DontModeMeIn.html] the description: An experimental tweak of the Refactoring Browser to support modeless editing. With this installed, it is possible to go to a different method or class within the same browser. while a method is being edited The "postponed" edit appears as an icon at the bottom of the browser. Clicking it will jump back to the edit in progress. NOTE: Close all browser windows before or immediately after loading this package. This package is currently unloadable and is should not be loaded into image that has RB_Tabs loaded (or vice versa). -- Best regards, Dennis Schetinin 2013/9/4 Dennis Schetinin <chaetal(a)gmail.com> > There were an addon named DontModeMeIn for VisualWorks browser which I > believe did the same thing. It was written by Vasilii Bykov and there was > an article on it in his blog, but I can't find that blog in the new > Cincom's site, and can't find that article in WaybackMachine eitherâ¦ The > only reference I can find is here [ > http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf] Hopefully, > the addon is still in Cincom's Public Repositoryâ¦ > > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/9/4 Norbert Hartl <norbert(a)hartl.name> > >> >> >> Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >> > >> > this is most annoying to me, that UI interrupts you in very strange >> manner >> > and asks you to make a decision: >> > - accept, or discard the method, or cancel the action. >> > >> > often, you are in the middle of typing new stuff and source code >> > can be even not syntactically correct.. so, you have to discard or die >> :) >> > >> > what i think the solution could be is that browser should allow you to >> switch contexts >> > at any moment without asking you anything.Instead it should remember >> your >> > unsaved changes in special 'drafts' collection, which later you can get >> back on, >> > when you finish what you wanted to do. >> > >> > And the only time when you want unaccepted edits to not get lost >> forever is when you closing >> > a browser window.. (but of course, drafts can be stored globally >> somewhere, >> > then it also not a big deal, since you can simply return to your draft >> in different window). >> >> We have method versions. I don't see a reason why uncommited methods can >> not go just on the list. They could be marked as unsaved/unommited (in fact >> they are not compiled so different per se) or even better the method >> version list should be a timeline where the current version is the present >> and everything else is a past or a potential future version. >> >> Norbert >> > >

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 04/09/2013 08:38, Marcus Denker a Ã©crit : > > On Sep 4, 2013, at 4:52 AM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > >> On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: >>> >>> Le 03/09/2013 13:36, David T. Lewis a ?crit : >>>> >>>> Can you post the method here first? I'd like to check it on some Squeak >>>> images >>>> before it goes into the repository. >>> >>> Here it is (at least an example): >>> >>> in OSProcess class >>> >>> isPharo3AndLater >>> "Test if we are on Pharo 3.0" >>> >>> ^ (Smalltalk classNamed: 'SystemVersion') >>> ifNil: [ false ] >>> ifNotNil: [ :v | v current type = 'Pharo' and: [ v current >>> major >= 3 ] ] >> >> The idea is right, but the details can be a PITA ;-) >> >> - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. >> >> - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). >> >> - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. >> > > Why do you need to support Squeak 3.8? This is how many years old? > > I really do not understand this idea to be compatible to all old versions ever. I respect whatever approach is used to make a usefull set of software portable across multiple versions / implementations / OS, as long as it works. > In the end it will just make sure that no progress is possible at all. I'm less impressed by someone who says that 2.0 is the stable and won't be fixed, and that 3.0 isn't fixed as well. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by Goubier Thierry

Le 03/09/2013 21:04, Camillo Bruni a Ã©crit : > On 2013-09-03, at 09:36, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> And I would probably have to come and try to maintain your fork because you wouldn't be using it and let it be deprecated for pharo 4 or 5... > > > exactly, and for each Pharo version there is a different branch of OSProcess. Sometimes, you just have to go with how the software you are using and updating is handling this adaptation... If it's something by you, I won't hesitate to branch and fork :) > well, once you start working on git you see the advantages of branches ;) > too bad that the monticello tools do not properly support this feature. Yes, I was thinking of how to use git branches for gitfiletree:// repositories and couldn't find a right way to integrate it into Monticello, apart from displaying the current branch when browsing a git repository. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 4, 2013

Re: [Pharo-dev] Switching context(s) in browser while method is not-yet accepted

by Dennis Schetinin

There were an addon named DontModeMeIn for VisualWorks browser which I believe did the same thing. It was written by Vasilii Bykov and there was an article on it in his blog, but I can't find that blog in the new Cincom's site, and can't find that article in WaybackMachine eitherâ¦ The only reference I can find is here [ http://scg.unibe.ch/download/wasdett/wasdett2008-paper03.pdf] Hopefully, the addon is still in Cincom's Public Repositoryâ¦ -- Best regards, Dennis Schetinin 2013/9/4 Norbert Hartl <norbert(a)hartl.name> > > > Am 03.09.2013 um 15:07 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > > this is most annoying to me, that UI interrupts you in very strange > manner > > and asks you to make a decision: > > - accept, or discard the method, or cancel the action. > > > > often, you are in the middle of typing new stuff and source code > > can be even not syntactically correct.. so, you have to discard or die :) > > > > what i think the solution could be is that browser should allow you to > switch contexts > > at any moment without asking you anything.Instead it should remember your > > unsaved changes in special 'drafts' collection, which later you can get > back on, > > when you finish what you wanted to do. > > > > And the only time when you want unaccepted edits to not get lost forever > is when you closing > > a browser window.. (but of course, drafts can be stored globally > somewhere, > > then it also not a big deal, since you can simply return to your draft > in different window). > > We have method versions. I don't see a reason why uncommited methods can > not go just on the list. They could be marked as unsaved/unommited (in fact > they are not compiled so different per se) or even better the method > version list should be a timeline where the current version is the present > and everything else is a past or a potential future version. > > Norbert >

Sept. 4, 2013