On Wed, 2 Mar 2005 21:40:36 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Cees de Groot cg@cdegroot.com wrote:
On Thu, 24 Feb 2005 20:49:23 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's?
Ehh... mostly all of the development tools?
As you know, those already work in all the UI's. Thus a UI abstraction does not help them; it only pretties them up. Pretty code is nice but should not be on the top of this priority list.
I guess it depends on what you mean by "all the development tools". One concrete outcome of ToolBuilder so far is that the Monticello UI suddenly works (or mostly works) in MVC and Tweak, which it didn't before. And I'm pretty sure that not all of the browsers had been ported to Tweak yet, or the TestRunner, and now they suddenly work too. And very few of these currently work in Seaside, but ToolBuilder will make it easier for all of them to. And then there's wxSqueak. So you say "those already work in all the UIs", but you actually mean something like "the System Browsers and Debugger already work in both Morphic and MVC", which is a much, much weaker statement.
But even if none of this were true - if we're serious about partitioning and stripping the image, getting rid of any dependencies between the Tools package and the various UI packages is surely a worthwhile goal.
Maybe it's not the absolute highest priority for the community (if we can measure such a thing), but I think it's a great thing for people who care about it to invest some energy into.
Avi
Hi guys!
Avi Bryant avi.bryant@gmail.com wrote: [SNIP of interesting report on ToolBuilder results]
But even if none of this were true - if we're serious about partitioning and stripping the image, getting rid of any dependencies between the Tools package and the various UI packages is surely a worthwhile goal.
Indeed.
Maybe it's not the absolute highest priority for the community (if we can measure such a thing), but I think it's a great thing for people who care about it to invest some energy into.
Avi
And another very important thing here is that different members of this community focuses on different things, we need to be able to move forward on multiple fronts in parallell.
I agree that the Packages team (now headed by Avi) is the most crucial piece for the immintent future and will affect 3.9 a lot. But that doesn't mean that the other Teams are not worth pursuing, supporting and coordinating. :)
The Team model is about parallellizing our efforts, but still keeping them coordinated. And of course about empowering members of the community.
regards, Göran
Hi goran
How do you see the process when people working in one task will clean ugly dependency for example on UI in compiler or other dark places such as systemDictionary. because we may end up having a lot of conflicting refactoring or boring to merge after the fact. We did that when KCP items where in the queue and this what not cool so we simply slowed down to avoid too much mess.
For example, I would really like that 3.9 offer a solution for SystemDictionary/SmalltalkImage/.. I described what would be the best compromise so that after 3.9 everybody is happy but this can be a long task and I imagine that some other tasks are of the same level so what is the process?
Stef
Hi Stephane!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Hi goran
How do you see the process when people working in one task will clean ugly dependency for example on UI in compiler or other dark places such as systemDictionary. because we may end up having a lot of conflicting refactoring or boring to merge after the fact. We did that when KCP items where in the queue and this what not cool so we simply slowed down to avoid too much mess.
Instinctively this sounds like an issue for the v3.9 team (Doug leading) to figure out.
Of the active Teams only ToolBuilder and Packages (AFAICT) will deliver results for the 3.9 stream. The MorphicSplitter team intends to work outside of the update stream (tracking it) and the Modules will also work outside.
ToolBuilder team will do lots of touching I presume, but for starters they will essentially add stuff, not change. Packages will do changes, but not that much in the core I think.
So both ToolBuilder and Packages should coordinate with the 3.9 team.
For example, I would really like that 3.9 offer a solution for SystemDictionary/SmalltalkImage/.. I described what would be the best compromise so that after 3.9 everybody is happy but this can be a long task and I imagine that some other tasks are of the same level so what is the process?
As I said, not sure. :) Personally I think we should start with partitioning (Avi is leader so this is just my personal thoughts) before we go forward with further refactorings etc.
That would mean that for example you guys could start doing that work with the "kernel" staked out and assigned to you for Stewarding. Which should make decisions easier to make.
Stef
regards, Göran
On 4 mars 05, at 13:44, goran.krampe@bluefish.se wrote:
As I said, not sure. :) Personally I think we should start with partitioning (Avi is leader so this is just my personal thoughts) before we go forward with further refactorings etc.
Not really since this is easier to work on a image than to propagate all the changes to all the different packages. But if working on packages means having a MC package per category and slowly making sure it can unload, both actions could be done in parallel.
That would mean that for example you guys could start doing that work with the "kernel" staked out and assigned to you for Stewarding. Which should make decisions easier to make.
I do not understand what you mean.
Hi!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
On 4 mars 05, at 13:44, goran.krampe@bluefish.se wrote:
As I said, not sure. :) Personally I think we should start with partitioning (Avi is leader so this is just my personal thoughts) before we go forward with further refactorings etc.
Not really since this is easier to work on a image than to propagate all the changes to all the different packages. But if working on packages means having a MC package per category and slowly making sure it can unload, both actions could be done in parallel.
That would mean that for example you guys could start doing that work with the "kernel" staked out and assigned to you for Stewarding. Which should make decisions easier to make.
I do not understand what you mean.
Well, I think :) I mean this:
- I am hoping that we aren't going to split up the core parts of Squeak into too many fine grained packages. So for example, all the Class, Behavior, ClassBuilder blabla stuff will probably end up in one package. And that one would typically be stewarded by you guys.
- Given this stake out it would mean that we very easily can see who is in charge of which part, and *that* would make decisions easier to make.
For example, if you intend to make some refactorings and you realize it will primarily affect parts A and B you could talk to those stewards and together decide. Changes to SystemDictionary etc that easily affects all Squeakers are of course still hard to perform - but at least you will feel our trust to make those decisions.
And again, we need to learn that alpha is alpha and beta is beta. People getting upset for things breaking in the alpha stream should just have to learn that yes, things *can* break there. :)
regards, Göran
- I am hoping that we aren't going to split up the core parts of Squeak
into too many fine grained packages. So for example, all the Class, Behavior, ClassBuilder blabla stuff will probably end up in one package. And that one would typically be stewarded by you guys.
ok
- Given this stake out it would mean that we very easily can see who is
in charge of which part, and *that* would make decisions easier to make.
For example, if you intend to make some refactorings and you realize it will primarily affect parts A and B you could talk to those stewards and together decide. Changes to SystemDictionary etc that easily affects all Squeakers are of course still hard to perform - but at least you will feel our trust to make those decisions.
ok
And again, we need to learn that alpha is alpha and beta is beta. People getting upset for things breaking in the alpha stream should just have to learn that yes, things *can* break there. :)
;)
regards, Göran
goran.krampe@bluefish.se wrote:
And another very important thing here is that different members of this community focuses on different things, we need to be able to move forward on multiple fronts in parallell.
I agree that the Packages team (now headed by Avi) is the most crucial piece for the immintent future and will affect 3.9 a lot. But that doesn't mean that the other Teams are not worth pursuing, supporting and coordinating. :)
Thanks, Goran. I was simply worried when it did not appear in either report. It would be a pity for the UI dependencies team to do their cool work, but then for no one to dare remove the packages because the infrastructure isn't ready!
-Lex
On Fri, 4 Mar 2005 23:44:36 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Thanks, Goran. I was simply worried when it did not appear in either report. It would be a pity for the UI dependencies team to do their cool work, but then for no one to dare remove the packages because the infrastructure isn't ready!
That's why the UI stuff isn't planned to land in 3.9. Although at the moment, we're assuming just PackageInfo and working from there, so we're not exactly *counting* on any specific results from the Packages team...
On Sat, 05 Mar 2005 09:30:06 +0100, Cees de Groot cg@cdegroot.com wrote:
That's why the UI stuff isn't planned to land in 3.9. Although at the moment, we're assuming just PackageInfo and working from there, so we're not exactly *counting* on any specific results from the Packages team...
In this contex I was talking about the morphic splitting effort, not about toolbuilder.
Cees: Do Not Post Before You Had Your Morning Coffee!
Avi Bryant avi.bryant@gmail.com wrote:
Date: Fri, 4 Mar 2005 02:00:30 +0100 From: Avi Bryant avi.bryant@gmail.com Subject: Re: [REPORT] Report 1 from castaways (that name sucks...) To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WvnG96XF18qCwyUfALRAK5cVQOlhjKfCoznP++tNS18pbr6KfFNZjTI52jtfzAQfg/T7Ce+fnPYHv96S04/d00lIluIVI87dOydERPwTP1wbm13GcQDyhzZgLh6FD86rzOTQsZFq9P+7HbscvfMugEg/vfadKvUykxk4ZlMdHKE= reply-to: avi@beta4.com, The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
On Wed, 2 Mar 2005 21:40:36 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Cees de Groot cg@cdegroot.com wrote:
On Thu, 24 Feb 2005 20:49:23 -0400, Lex Spoon lex@cc.gatech.edu wrote:
Additionally, the UI abstraction task is fine but seems relatively unimportant compared to these other items. How muh code, really, is going to find it useful to target 5 different UI's?
Ehh... mostly all of the development tools?
As you know, those already work in all the UI's. Thus a UI abstraction does not help them; it only pretties them up. Pretty code is nice but should not be on the top of this priority list.
I guess it depends on what you mean by "all the development tools". One concrete outcome of ToolBuilder so far is that the Monticello UI suddenly works (or mostly works) in MVC and Tweak, which it didn't before. And I'm pretty sure that not all of the browsers had been ported to Tweak yet, or the TestRunner, and now they suddenly work too. And very few of these currently work in Seaside, but ToolBuilder will make it easier for all of them to. And then there's wxSqueak. So you say "those already work in all the UIs", but you actually mean something like "the System Browsers and Debugger already work in both Morphic and MVC", which is a much, much weaker statement.
Granted -- I spoke sloppily, in response to a sloppy dismissal. The point is that there is no crisis with development tools, and thus that the dismissal was a red herring. The real issue, as Cees and you both go on to talk about, is dependencies from UI-neutral code to particular UI frameworks.
-Lex
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Cees de Groot -
goran.krampe＠bluefish.se -
Lex Spoon -
stéphane ducasse