Fixed to interrupt behavior

Sig en Co,

Thanks a lot for the fixed interrupt behavior !
It worked perfectly.
This really makes a difference.

Sven

For the rest of us, fixed what, when?  Just curious.



________________________________________
From: [hidden email] [[hidden email]] on behalf of Sven Van Caekenberghe [[hidden email]]
Sent: Wednesday, February 08, 2012 3:01 AM
To: [hidden email] Development
Subject: [Pharo-project] Fixed to interrupt behavior

Sig en Co,

Thanks a lot for the fixed interrupt behavior !
It worked perfectly.
This really makes a difference.

Sven

The idea is that most of the time when you pressed cmd . you killed stopped either
the UI of the debugger you were invoking :) or the finalization process. too bad… you stopped the only guy that
was helping you to receiver from memory. No such process are not selected when you press . cmd



On Feb 8, 2012, at 10:32 AM, Schwab,Wilhelm K wrote:

Stef,

We are on the same topic then.  I am having problems with cmd . on 1.3 - it won't break anything :(

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]]
Sent: Wednesday, February 08, 2012 5:16 AM
To: [hidden email]
Subject: Re: [Pharo-project] Fixed to interrupt behavior

The idea is that most of the time when you pressed cmd . you killed stopped either
the UI of the debugger you were invoking :) or the finalization process. too bad… you stopped the only guy that
was helping you to receiver from memory. No such process are not selected when you press . cmd



On Feb 8, 2012, at 10:32 AM, Schwab,Wilhelm K wrote:

On Feb 8, 2012, at 11:22 AM, Schwab,Wilhelm K wrote:

> Stef,
>
> We are on the same topic then.  I am having problems with cmd . on 1.3 - it won't break anything :(
>
it is fixed in 1.4.

        Marcus



--
Marcus Denker -- http://marcusdenker.de

Ok, but what about 1.3?  Is 1.4 "ready" - last word was to use 1.3, which has some troubles too.




________________________________________
From: [hidden email] [[hidden email]] on behalf of Marcus Denker [[hidden email]]
Sent: Wednesday, February 08, 2012 5:24 AM
To: [hidden email]
Subject: Re: [Pharo-project] Fixed to interrupt behavior

On Feb 8, 2012, at 11:22 AM, Schwab,Wilhelm K wrote:

> Stef,
>
> We are on the same topic then.  I am having problems with cmd . on 1.3 - it won't break anything :(
>
it is fixed in 1.4.

        Marcus



--
Marcus Denker -- http://marcusdenker.de

On 08 Feb 2012, at 11:42, Schwab,Wilhelm K wrote:

> Ok, but what about 1.3?  Is 1.4 "ready" - last word was to use 1.3, which has some troubles too.

Active Pharo development is happing on the unstable branch, 1.4.
Pharo 1.3 was released a long time ago, as a freeze of the development branch, and after a period of RC testing.
Sometimes critical patches are backported from 1.4 to 1.3, but often that is not possible, it is also a lot of work for the integrators.

Sven

1.4 is stable but we are working on it.
STef

On Feb 8, 2012, at 11:42 AM, Schwab,Wilhelm K wrote:

Stef,

There are things in 1.4 that I will eventually like, but for now, it is very difficult to use.  I had a code holder get dragged and dropped from a browser to the desktop and couldn't get a halo to kill it.  Context menus don't work well and lack the polish of earlier versions.

My problem is that 1.3 does not appear to be able to break processes, and once Metacello gets running, I lose the ability to open debuggers and process browsers.  It is (sorry) basically unusable.

On the up side, I did some useful work on Migrate and my 1.1.1 image looks GREAT as a result.  Preference changes broke some of my code, and it took me a while to see how to recover those abilities.  I now have nice fonts and can much more easily read source :)

I will be in a fairly good position as 1.4 stabilizes, but for now, I can't get 1.3 or 1.4 to cooperate.

Bill

________________________________________
From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]]
Sent: Wednesday, February 08, 2012 7:39 AM
To: [hidden email]
Subject: Re: [Pharo-project] Fixed to interrupt behavior

1.4 is stable but we are working on it.
STef

On Feb 8, 2012, at 11:42 AM, Schwab,Wilhelm K wrote:

Sven Van Caekenberghe wrote: This is probably a naive view, but I was wondering it the effort of
backporting critical patches could be reduced if the development process
went...

Rather than as I understand it, current 1.3 is frozen and the live trunk
continues as unstable 1.4 mixing both planned refactoring and unplanned
bug fixes discovered in 1.3.  It then takes additional effort to
implement those fixes in 1.3 where they were discovered.  Not
withstanding the ideal of release candidate testing finding these bugs,
the reality is that people properly migrate between versions at
different rates.  Using the stable version for day-in-day-out for weeks
on end does exercise code differently than artificial testing during RC
phase.

Alternatively, 1.3 could be kept the main live version on the
continuation integration server.  A core developer's local 1.4
refactoring is uploaded to the CI server as a changeset against the live
1.3 version.  When this changeset tests okay, it is available to be
pulled down by other core developers to update their image.

Thus bugs discovered in 1.3 can be fixed in 1.3 and also flow through to
1.4 with the 1.4 refactoring isolated from the 1.3 bug fixes.

It is a bit presumptuous of me to be suggesting such changes to the core
development process, but my ideas fight me to get out.  Perhaps I'll
learn something when I get shot down :)
On the downside, the added complexity of such a process may introduced
additional incremental effort which exceeds the effort backporting
selected bug fixes.

regards, -ben