Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods? How did you find out?
We are sorry about that.
- We had to decide if we add balloon 3d with pooh broken or not,
same
for the language editor. We decided to add manually the fixes
because
we do not have access to the code. But this cannot continue like
that.
For the next release here is a list of properties that packages should have: - be maintained - code access by one of the integrators - minimizing the overriding of methods - we should harvest the changes in the kernel - put in places some mechanisms such as services
Conclusion: I will do 3.7 full but do not count on me in the future.
I think that the time slot defined to the integration was way too short (basically a few days between you announcing willing to do the job the 18th of August and Doug wanting to have it finisted in a few days, email of 21th). Today is the 24th.
Apparently you are all too busy to pay attention to people that spend their time to build stuff for everybody.
Stef
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
Hannes
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ... 1. a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to MorphicTextEdtior, but for MVC)
2. a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)
I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004
Hi andy
We really think that we should really prepare 3.9 so that the system is made better to get new tool like yours.
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
So the first step is really to send the fix that can go in the kernel, thne identify what should be done at the kernel level, have you got a look at the services package because this would be really a good basis to support RB, shout integration. Stef
On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ... 1. a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to MorphicTextEdtior, but for MVC)
2. a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004 <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
Although I have come up with one solution, for Shout, using AppRegistry, it may not be the best solution. We should take some time to consider the options before making changes to the kernel. Perhaps an event model would be more flexible, for instance? Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView, #builtMorphicView , etc. events. And anything can handle those events and change the Browser's behaviour.
I am not familiar with Services, I'll take a look.
The big danger in all this is that we introduce a framework that leads to as many bugs as would be caused by simply allowing packages included in the full image to override kernel methods. So; we need to make kernel changes; but we need to consider carefully what those changes should be. If we are aiming to acheive this for 3.9, then there is no great rush. Cheers, Andy
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 25, 2004 6:48 AM Subject: Re: Lessons learnt from been an integrator
Hi andy
We really think that we should really prepare 3.9 so that the system is made better to get new tool like yours.
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
So the first step is really to send the fix that can go in the kernel, thne identify what should be done at the kernel level, have you got a look at the services package because this would be really a good basis to support RB, shout integration. Stef
On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ... 1. a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to MorphicTextEdtior, but for MVC)
2. a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004 <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
Am 25.08.2004 um 11:00 schrieb Andrew Tween:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it.
Replacing. The old browser is a hack and *very* bad for extensions, experiments and stuff like that.
So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
We should realy at one point decide about having one system, why provide MVC and Morphic? (yes, morphic is too slow... and too big, and impossible to understand). So... not that this helps in this discussion ;-)
Although I have come up with one solution, for Shout, using AppRegistry, it may not be the best solution. We should take some time to consider the options before making changes to the kernel.
Yes.
The big danger in all this is that we introduce a framework that leads to as many bugs as would be caused by simply allowing packages included in the full image to override kernel methods.
The danger with overriding not only introduction of bugs: The biggest problem are two clients that change the same method in the image. Both do the change because they want to add certain functionality. So the first override works Ok, but the second one can not work: It undos the changes of the first, this braking the module that depend on that change.
There is the same problem with method additions: If two modules add the same method to the same class, it won't work. (One could say that modules loose composition semantic as soon as you allow overrides).
So overrides are evil. I guess that's why other systems do not allow them. But their are *realy* powerful, and we want them.
There are two interesting ways of dealing with that problem:
1) Make ovverrides local to the module. So a module is free to override methods, but the system takes care that these are local. That is: when calling the method, everybody else gets the old one, but the module that did that override get the new one. This is what Alexandre's ClassBoxes provide.
This would of couse not solve the problem in the cases were overrides are used to add functionality to the system as a whole.
2) Ovverrides most of the time just add hooks into the system. If you look at AOP, that's exactly what these kind of systems provide: They allow you to hook code into well specified points of your program. The interesting thing is that these hooks have a composition semantic, so we can have multiple clients hooking into the same method without interference.
But in the end, there will just be "patches" and "modules", even if the modules are powerful. (classnboxes, AOP). And patches need to be intergrated. There can't be anything done to make this not needed.
So; we need to make kernel changes; but we need to consider carefully what those changes should be. If we are aiming to acheive this for 3.9, then there is no great rush.
Yes.
Marcus
Marcus Denker wrote:
We should realy at one point decide about having one system, why provide MVC and Morphic? (yes, morphic is too slow... and too big, and impossible to understand). So... not that this helps in this discussion ;-)
If is it yet possible to isolate morphic, it would be interesting to have "mvc-only" distribution. Apparently SystemDictionary>>discardMorphic doesn't work. I see now even pure MVC intermix with morphic somehow (in main menu the action "keep this menu up"). While usability of MVC environment is disputable it could form a basement for more standardized GUI with dialogs, forms, trees, tabular lists, icons, etc.
Am 25.08.2004 um 20:43 schrieb Kamil Kukura:
Marcus Denker wrote:
We should realy at one point decide about having one system, why provide MVC and Morphic? (yes, morphic is too slow... and too big, and impossible to understand). So... not that this helps in this discussion ;-)
If is it yet possible to isolate morphic, it would be interesting to have "mvc-only" distribution. Apparently SystemDictionary>>discardMorphic doesn't work. I see now even pure MVC intermix with morphic somehow (in main menu the action "keep this menu up"). While usability of MVC environment is disputable it could form a basement for more standardized GUI with dialogs, forms, trees, tabular lists, icons, etc.
I didn't want to imply that I want MVC. Realy not. I havn't used MVC for years. What I think is very important: If a replacement for some part of a system is developed, it's important to bring it so far to be good enough to realy replace the old stuff. Having MVC makes lots of stuf overly complex, e.g. supporting both in all tools makes no sense.
But I guess much of that is personal taste. Some people can only work with a clean desk (e.g. me) while others need to have a complete chaos all around to be creative.
Marcus
On Aug 25, 2004, at 4:00 AM, Andrew Tween wrote:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
OmniBrowser doesn't work in MVC right now. The reasons for that are practical rather than technical, though - not many people use MVC, and those that do are often in low-resource situations. So I think making OB work under MVC is feasible if it seems like it would be worth the effort.
Stéphane Ducasse wrote:
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
Although I'd like to see this happen eventually, I don't think OmniBrowser is ready.
This is partly because I've been focussed on some fairly ambitious, long-term goals. This means things like proper handing of packages, producing a clean implementation of the RB, integrating nicely with the ClosureCompiler etc.
Now, if I were to post-pone those features, and focus on a clean and simple reimplementation of the default browser, I think that could be done fairly quickly. But note that this would be a very bare-bones implementation, with even fewer features than the default browser. I don't have any plans to implement the groovy experiments that were done by SqueakCentral - things like tile view, alternate syntax etc.
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
Colin
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing - first get rid of the bottleneck of the standard browser so that everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time).
My 0.02 EUR, Avi
Am 25.08.2004 um 19:09 schrieb Avi Bryant:
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing
- first get rid of the bottleneck of the standard browser so that
everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time).
I'm with Avi on that one.
A very similar decicion is RB-ParseTrees vs. Colins new CodeModel. I think that Colin's stuff is the right direction in the long run, but we should think about moving in the stuff that's already there and not delay just because something even better is imaginable.
(This is a common trap to run into, and we have seen it a lot in Squeak. If all that "not perfect" improvements that have been discussed would have been implemented, the system would be much better now.)
So I'd like to see OB on the tools front, and RB-ParseTrees+ the new Compiler and the RB Engine down under. Just as a first step.
After that is done, we should extend/replace the stuff with the CodeModel. Great stuff will be possible with a scheme that Colin is implementing.
Marcus
I totally agree with marcus: using what we have today does not mean that we will be stuck with it but at least we have it.
I suggest to read Worse is better paper of Dick Gabriel.
Stef
A very similar decicion is RB-ParseTrees vs. Colins new CodeModel. I think that Colin's stuff is the right direction in the long run, but we should think about moving in the stuff that's already there and not delay just because something even better is imaginable.
(This is a common trap to run into, and we have seen it a lot in Squeak. If all that "not perfect" improvements that have been discussed would have been implemented, the system would be much better now.)
So I'd like to see OB on the tools front, and RB-ParseTrees+ the new Compiler and the RB Engine down under. Just as a first step.
After that is done, we should extend/replace the stuff with the CodeModel. Great stuff will be possible with a scheme that Colin is implementing.
Marcus
On Aug 25, 2004, at 12:56 PM, Marcus Denker wrote:
Am 25.08.2004 um 19:09 schrieb Avi Bryant:
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now.
I'm with Avi on that one.
Ok, between you two and Hernan, I'm convinced.
I'll put the fancy stuff on hold for a bit and just produce the simplest, cleanest browser I can, with an eye toward inclusion in 3.8.
Cheers,
Colin
On Wednesday, August 25, 2004, at 04:14 PM, Colin Putney wrote:
On Aug 25, 2004, at 12:56 PM, Marcus Denker wrote:
Am 25.08.2004 um 19:09 schrieb Avi Bryant:
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now.
I'm with Avi on that one.
Ok, between you two and Hernan, I'm convinced.
Sounds like a good idea to me too. I haven't looked closely at OmniBrowser yet (will soon), but am familiar enough with Browser to know that it has a lot of problems. When I wrote WhiskerBrowser, nothing from the Browser class was reusable. And Browser does goofy non-OO things like accessing list items with numeric indexes, etc.
On a side note, I would think the tiles and alternateSyntax stuff is relatively separate from the Browser class? (If not, I guess we're in even worse shape than I thought.) If it's relatively separate, it might not be hard to add it to OmniBrowser. Well, if someone wants to do it. ;) Actually, I'm guessing the problem with those is more that they're based on the older Parser code, which we are replacing?
I'll put the fancy stuff on hold for a bit and just produce the simplest, cleanest browser I can, with an eye toward inclusion in 3.8.
Okay, although the current plan for 3.8 is for it to be a relatively short release primarily for m17n, without any other major changes. (which you probably already know) But that may be okay, assuming OmniBrowser is mostly new code which doesn't change existing behavior, and if we don't remove Browser until the following release. Similarly, we're also adding Monticello as part of the Basic/update-stream image in 3.8, partly because it's mostly just an add-on.
- Doug
(p.s. trying to wrap up 3.7 right now)
On Aug 26, 2004, at 12:22 AM, Doug Way wrote:
Okay, although the current plan for 3.8 is for it to be a relatively short release primarily for m17n, without any other major changes. (which you probably already know) But that may be okay, assuming OmniBrowser is mostly new code which doesn't change existing behavior, and if we don't remove Browser until the following release. Similarly, we're also adding Monticello as part of the Basic/update-stream image in 3.8, partly because it's mostly just an add-on.
Yeah, I knew that. It... um... slipped my mind for a moment. :-p
My reference to 3.8 was meant more as an indication when I hope to have the next version of OB done than anything else. It may make sense to wait for 3.9 in order to ensure that OB is really solid. The last thing I want is to get lynched for breaking people's working environment.
Colin
On Thu, 26 Aug 2004 01:22:15 -0400, Doug Way dway@mailcan.com wrote:
Similarly, we're also adding Monticello as part of the Basic/update-stream image in 3.8, partly because it's mostly just an add-on.
I have to say, in the last few weeks I've started using Monticello for all my development work, and it is fantastic. Reminds me of using Store in VisualWorks, although of course it is missing a few features.
Highly recommended...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
Hi jon
So changes are good :) Have you check squeakSource because in one click you can publish in squeakmap and share your code with other.
Stef
On 26 août 04, at 14:50, Jon Hylands wrote:
On Thu, 26 Aug 2004 01:22:15 -0400, Doug Way dway@mailcan.com wrote:
Similarly, we're also adding Monticello as part of the Basic/update-stream image in 3.8, partly because it's mostly just an add-on.
I have to say, in the last few weeks I've started using Monticello for all my development work, and it is fantastic. Reminds me of using Store in VisualWorks, although of course it is missing a few features.
Highly recommended...
Later, Jon
Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
On Aug 26, 2004, at 2:50 PM, Jon Hylands wrote:
On Thu, 26 Aug 2004 01:22:15 -0400, Doug Way dway@mailcan.com wrote:
Similarly, we're also adding Monticello as part of the Basic/update-stream image in 3.8, partly because it's mostly just an add-on.
I have to say, in the last few weeks I've started using Monticello for all my development work, and it is fantastic. Reminds me of using Store in VisualWorks, although of course it is missing a few features.
Thanks. It would be useful to know which features you're missing the most.
Avi
On Thu, 26 Aug 2004 17:20:12 +0200, Avi Bryant avi@beta4.com wrote:
Thanks. It would be useful to know which features you're missing the most.
Well, I started thinking about this, and the more I thought about it, the more it seemed like I could get more or less what I wanted with the existing features. Hierarchical packages are nice, but having required packages gets you almost the same thing, if you set it up right.
I do find the user interface a little clunky. I prefer a repository-centered view, rather than a "package-in-image" centered view. But you can't save the working version of a package to a repository from the repository window. Which sort of makes sense, when you think about it, but I guess I'm still to tied to a central-repository way of thinking...
Okay, so what I find clunky about the main window UI is the fact that I select the package, and then select the repository, and then hit 'Save'.
If I was designing it from scratch, there would only be packages in the main window. When you want to save a package, you select the package, hit save, and then it prompts you for the repository from the list it knows about, which also includes options to build a new one or open a different one not in the list. Or maybe the little version comment window that opens up could also indicate the "Default" repository, and have a button that would allow you to change it. Or something like that.
Anyways, I guess I should wait until I have some more experience using Monticello before I start complaining too loudly about it :-)
Thanks for a great addition to the Squeak world...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
On Aug 28, 2004, at 3:15 PM, Jon Hylands wrote:
If I was designing it from scratch, there would only be packages in the main window. When you want to save a package, you select the package, hit save, and then it prompts you for the repository from the list it knows about, which also includes options to build a new one or open a different one not in the list. Or maybe the little version comment window that opens up could also indicate the "Default" repository, and have a button that would allow you to change it. Or something like that.
Yes, that would work. I guess the reason it's the way it is now is that I find myself alternating between a package-central view (when I'm committing) and a repository-central view (when loading/merging the work of others), and so having both lists easily accessible is nice. But it may be that having them in separate windows, each streamlined for their respective tasks, would be better than the combined UI we have now. UI work isn't high on my personal priority list, and I know Colin's busy with OmniBrowser right now, but if anyone else wants to take a crack at this...
Anyways, I guess I should wait until I have some more experience using Monticello before I start complaining too loudly about it :-)
Nah. Complain loudly and complain often, by all means.
Avi
At 17:20 +0200 2004.8.26, Avi Bryant wrote:
I have to say, in the last few weeks I've started using Monticello for all my development work, and it is fantastic. Reminds me of using Store in VisualWorks, although of course it is missing a few features.
Thanks. It would be useful to know which features you're missing the most.
What I have found missing is support in the Browser. The Browser should, in my view, have teh notions of a currently active set of Packages (which should show up to be selected from when I create a new protocol) and currentPackage into which class extensions and modifications of existing classes are put by default.
Without this, I find that I forget to put my changes in to any package, or into the right package, or into a spelling error. Fortunately, the changeset keeps track of the changes that I forget ;-)
Andrew
On Sep 9, 2004, at 4:51 PM, Andrew P. Black wrote:
At 17:20 +0200 2004.8.26, Avi Bryant wrote:
I have to say, in the last few weeks I've started using Monticello for all my development work, and it is fantastic. Reminds me of using Store in VisualWorks, although of course it is missing a few features.
Thanks. It would be useful to know which features you're missing the most.
What I have found missing is support in the Browser. The Browser should, in my view, have teh notions of a currently active set of Packages (which should show up to be selected from when I create a new protocol) and currentPackage into which class extensions and modifications of existing classes are put by default.
Without this, I find that I forget to put my changes in to any package, or into the right package, or into a spelling error. Fortunately, the changeset keeps track of the changes that I forget ;-)
Which brings the thread very neatly back to "incorporating OmniBrowser"... Yes, browser support would be great. That seems like an obvious and easy extension to OB, once it's ready for inclusion in the image. For the meantime, it would probably be pretty easy to hack the existing browser to have a "new extension" method as well as "new protocol", which would let you choose from the list of active packages, and put the * in for you. Maybe I'll look at doing this in Camp Smalltalk this weekend.
Avi
On Sep 9, 2004, at 10:09 AM, Avi Bryant wrote:
What I have found missing is support in the Browser. The Browser should, in my view, have teh notions of a currently active set of Packages (which should show up to be selected from when I create a new protocol) and currentPackage into which class extensions and modifications of existing classes are put by default.
Without this, I find that I forget to put my changes in to any package, or into the right package, or into a spelling error. Fortunately, the changeset keeps track of the changes that I forget ;-)
Which brings the thread very neatly back to "incorporating OmniBrowser"... Yes, browser support would be great. That seems like an obvious and easy extension to OB, once it's ready for inclusion in the image.
No, this wouldn't be hard to do, and I'll add it to my list of things to implement for the slimmed-down version. However, there is one caveat I'd like to bring up; it echoes a discussion I had with the SCG guys over on the Monticello list: I don't think modifications of existing methods should be moved into the current package by default.
See http://mail.wiresong.ca/pipermail/monticello/2004-August/000040.html for a more detailed argument in support of this position.
I should also mention that I've made quite a bit of progress in cleaning up OmniBrowser for inclusion in the image, and I should have a new alpha release fairly soon. There's still some work to do before I'd consider it ready, but it's a lot closer.
Colin
If you release (an alpha) in the next day, we can test it at CampSmalltalk and maybe help along.
Daniel Vainsencher
Colin Putney cputney@wiresong.ca wrote:
Date: Thu, 9 Sep 2004 10:31:47 -0500 From: Colin Putney cputney@wiresong.ca Subject: Re: Incorporating OmniBrowser (was Re: Lessons learnt from been an integrator) To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org envelope-to: danielv@localhost delivery-date: Thu, 09 Sep 2004 18:41:26 +0300 reply-to: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
On Sep 9, 2004, at 10:09 AM, Avi Bryant wrote:
What I have found missing is support in the Browser. The Browser should, in my view, have teh notions of a currently active set of Packages (which should show up to be selected from when I create a new protocol) and currentPackage into which class extensions and modifications of existing classes are put by default.
Without this, I find that I forget to put my changes in to any package, or into the right package, or into a spelling error. Fortunately, the changeset keeps track of the changes that I forget ;-)
Which brings the thread very neatly back to "incorporating OmniBrowser"... Yes, browser support would be great. That seems like an obvious and easy extension to OB, once it's ready for inclusion in the image.
No, this wouldn't be hard to do, and I'll add it to my list of things to implement for the slimmed-down version. However, there is one caveat I'd like to bring up; it echoes a discussion I had with the SCG guys over on the Monticello list: I don't think modifications of existing methods should be moved into the current package by default.
See http://mail.wiresong.ca/pipermail/monticello/2004-August/000040.html for a more detailed argument in support of this position.
I should also mention that I've made quite a bit of progress in cleaning up OmniBrowser for inclusion in the image, and I should have a new alpha release fairly soon. There's still some work to do before I'd consider it ready, but it's a lot closer.
Colin
On Sep 10, 2004, at 4:23 AM, danielv@tx.technion.ac.il wrote:
If you release (an alpha) in the next day, we can test it at CampSmalltalk and maybe help along.
Ok, this isn't quite a full release, as I haven't posted on SqueakMap and don't have time to figure out SAR packaging tonight, but here it is. You'll need Monticello loaded to run the tests.
http://monticello.wiresong.ca/ob/OB-Standard-cwp.17.mcz
The major changes are:
The old OmniBrowser package has been split into three: OmniBrowser is now just a base library with no actual browsers implemented. OB-Standard contains the standard code browsers, and OB-Filesystem contains the file browser. I've left the file browser alone since it was broken out.
The code browsers no longer use contexts as an abstraction layer, now OBCodeNode and descendants manipulate the image directly. This also means that OBClassReference is mostly gone. (It's still used by OBMethodVersion, but that actually makes some sense even without contexts.)
The package browsers are gone.
There's now a background process that catches events from the SystemChangeNotifier and updates browsers. This is still a bit buggy. I expect it's because I'm drawing from a process other than the UI process.
Browser window titles are now configurable and code browsers use this to display the currently selected class.
The optionalButtons now behave more like the default browsers - there's a fixed set of buttons that get enabled and disabled as the browser's selection changes.
OBBrowser has been refactored to make it easier to create subclasses with specific configurations. OBSystemBrowser and friends use this to make it easier to open browsers on specific classes, methods etc. I haven't yet implemented compatibility methods such as #fullOnClass:
There are now some basic tests for node ancestry.
I've begun a refactoring of actions, to pull them out of the node classes and into Actor classes of their own. OBCategoryActor provides an example of how this will work - it replaces duplicate implementations in OBClassCategoryNode and OBMethodCategoryNode.
Still to do:
- refactor more actions, with tests - tests for drag and drop - create reorganization actions - create a message search browser
- removing a method in the chasing browser causes a syntax error - make the browsers update properly
Feedback appreciated, as always. I'll do a proper release to SM "soon."
Colin
On Sep 11, 2004, at 12:54 AM, Colin Putney wrote:
On Sep 10, 2004, at 4:23 AM, danielv@tx.technion.ac.il wrote:
If you release (an alpha) in the next day, we can test it at CampSmalltalk and maybe help along.
Ok, this isn't quite a full release, as I haven't posted on SqueakMap and don't have time to figure out SAR packaging tonight, but here it is. You'll need Monticello loaded to run the tests.
Colin,
We loaded this here in Camp Smalltalk and took it for a drive. Updates didn't work at all, at first - we had to change "OBBrowser allInstancesDo:" to "OBBrowser allSubInstancesDo:". And the text pane doesn't seem to update at all without manually re-selecting the current method (which also means that it doesn't complain with the thick red line if you have concurrent edits in different browsers). Apart from that, it's been very solid, and seems to include all the menu items, d'n'd, and so on that I would expect - it now feels like a finished browser rather than a proof of concept.
One other complaint that came up is that the enabled/disabled status of the buttons isn't easy enough to tell at a glance. However, I think the new way they work was a good choice - having the button row constantly changing underfoot was disconcerting, and this makes the UI feel much more stable. For some reason the chasing browsers still discombobulate me a bit in that same way, but I'm not sure how to fix that, and it probably just takes getting used to.
It would also be great if the shortcut keys (alt-m, alt-n, alt-b, etc) could be (optionally?) modified to bring up the OB instead of the standard tools. Otherwise it's really hard to stay in OB for long. If that can be hacked in easily, I think I'll try adopting this as my main browser and see how I do.
So, great work, and I look forward to seeing it on SqueakMap.
Avi
Hi Avi,
A couple of months ago I sent to the list a little changeset that added an application registry for the SystemBrowser. The thread started the 08/05/2004 and had this subject: '[ENH] openBrowser-ls'. What did you think about those changes?
I think that better than making OB to change paragraph editor so it can hook on <cmd>-m, <cmd>-n and <cmd>-b. Why not we make an app-registry as the one I sent? In fact, why not we add this changeset to the unstable stream right now so we can start to fix the wrinkles that may appear?.
We are now at the start of alpha and that is a very valuable thing. I think that we should seize this opportunity to make all the unstabilizing changes that we will be afraid to make later. So lets do this.
Regards, Hernán
Avi Bryant wrote:
On Sep 11, 2004, at 12:54 AM, Colin Putney wrote:
On Sep 10, 2004, at 4:23 AM, danielv@tx.technion.ac.il wrote:
If you release (an alpha) in the next day, we can test it at CampSmalltalk and maybe help along.
Ok, this isn't quite a full release, as I haven't posted on SqueakMap and don't have time to figure out SAR packaging tonight, but here it is. You'll need Monticello loaded to run the tests.
Colin,
We loaded this here in Camp Smalltalk and took it for a drive. Updates didn't work at all, at first - we had to change "OBBrowser allInstancesDo:" to "OBBrowser allSubInstancesDo:". And the text pane doesn't seem to update at all without manually re-selecting the current method (which also means that it doesn't complain with the thick red line if you have concurrent edits in different browsers). Apart from that, it's been very solid, and seems to include all the menu items, d'n'd, and so on that I would expect - it now feels like a finished browser rather than a proof of concept.
One other complaint that came up is that the enabled/disabled status of the buttons isn't easy enough to tell at a glance. However, I think the new way they work was a good choice - having the button row constantly changing underfoot was disconcerting, and this makes the UI feel much more stable. For some reason the chasing browsers still discombobulate me a bit in that same way, but I'm not sure how to fix that, and it probably just takes getting used to.
It would also be great if the shortcut keys (alt-m, alt-n, alt-b, etc) could be (optionally?) modified to bring up the OB instead of the standard tools. Otherwise it's really hard to stay in OB for long. If that can be hacked in easily, I think I'll try adopting this as my main browser and see how I do.
So, great work, and I look forward to seeing it on SqueakMap.
Avi
On Sep 12, 2004, at 9:20 AM, Hernan Tylim wrote:
Hi Avi,
A couple of months ago I sent to the list a little changeset that added an application registry for the SystemBrowser. The thread started the 08/05/2004 and had this subject: '[ENH] openBrowser-ls'. What did you think about those changes?
I think that better than making OB to change paragraph editor so it can hook on <cmd>-m, <cmd>-n and <cmd>-b. Why not we make an app-registry as the one I sent? In fact, why not we add this changeset to the unstable stream right now so we can start to fix the wrinkles that may appear?.
This sounds really useful Hernán. I'll have a look at this as soon as I can.
Colin
Am 12.09.2004 um 16:20 schrieb Hernan Tylim:
Hi Avi,
A couple of months ago I sent to the list a little changeset that added an application registry for the SystemBrowser. The thread started the 08/05/2004 and had this subject: '[ENH] openBrowser-ls'. What did you think about those changes?
I think that better than making OB to change paragraph editor so it can hook on <cmd>-m, <cmd>-n and <cmd>-b. Why not we make an app-registry as the one I sent? In fact, why not we add this changeset to the unstable stream right now so we can start to fix the wrinkles that may appear?.
We are now at the start of alpha and that is a very valuable thing. I think that we should seize this opportunity to make all the unstabilizing changes that we will be afraid to make later. So lets do this.
The changeset has already been approved and is happily waiting like 90 other ones to be included in 3.8a.
Marcus
Great. I didn't know it. Thanks Marcus.
Regards, Hernán
Marcus Denker wrote:
Am 12.09.2004 um 16:20 schrieb Hernan Tylim:
Hi Avi,
A couple of months ago I sent to the list a little changeset that added an application registry for the SystemBrowser. The thread started the 08/05/2004 and had this subject: '[ENH] openBrowser-ls'. What did you think about those changes?
I think that better than making OB to change paragraph editor so it can hook on <cmd>-m, <cmd>-n and <cmd>-b. Why not we make an app-registry as the one I sent? In fact, why not we add this changeset to the unstable stream right now so we can start to fix the wrinkles that may appear?.
We are now at the start of alpha and that is a very valuable thing. I think that we should seize this opportunity to make all the unstabilizing changes that we will be afraid to make later. So lets do this.
The changeset has already been approved and is happily waiting like 90 other ones to be included in 3.8a.
Marcus
Hi guys.
Maybe the BFAV should send a copy of the mail to all the authors on the specific item whenever the status of an item changes?
Daniel
Hernan Tylim htylim@yahoo.com.ar wrote:
Great. I didn't know it. Thanks Marcus.
Marcus Denker wrote:
The changeset has already been approved and is happily waiting like 90 other ones to be included in 3.8a.
Marcus
Am 12.09.2004 um 21:43 schrieb danielv@techunix.technion.ac.il:
Hi guys.
Maybe the BFAV should send a copy of the mail to all the authors on the specific item whenever the status of an item changes?
There is already an option to add the author to the reply. I think I will use that more often.
Marcus
On Sep 12, 2004, at 5:10 AM, Avi Bryant wrote:
Colin,
We loaded this here in Camp Smalltalk and took it for a drive. Updates didn't work at all, at first - we had to change "OBBrowser allInstancesDo:" to "OBBrowser allSubInstancesDo:". And the text pane doesn't seem to update at all without manually re-selecting the current method (which also means that it doesn't complain with the thick red line if you have concurrent edits in different browsers). Apart from that, it's been very solid, and seems to include all the menu items, d'n'd, and so on that I would expect - it now feels like a finished browser rather than a proof of concept.
Ok, updates are now fixed - each browser subscribes to the SCN, and refreshes via morphic stepping.
http://monticello.wiresong.ca/ob/OB-Standard-cwp.18.mcz
One other complaint that came up is that the enabled/disabled status of the buttons isn't easy enough to tell at a glance. However, I think the new way they work was a good choice - having the button row constantly changing underfoot was disconcerting, and this makes the UI feel much more stable. For some reason the chasing browsers still discombobulate me a bit in that same way, but I'm not sure how to fix that, and it probably just takes getting used to.
Yeah, I agree. I think what's needed is different colours. On my list.
It would also be great if the shortcut keys (alt-m, alt-n, alt-b, etc) could be (optionally?) modified to bring up the OB instead of the standard tools. Otherwise it's really hard to stay in OB for long. If that can be hacked in easily, I think I'll try adopting this as my main browser and see how I do.
Another good point. I'll investigate that too.
I'm moving in the next few days, so I might not be able to post to SM soon, but I expect to move to beta in the next week or so.
Colin
On Sep 12, 2004, at 5:42 PM, Colin Putney wrote:
On Sep 12, 2004, at 5:10 AM, Avi Bryant wrote:
Colin,
We loaded this here in Camp Smalltalk and took it for a drive. Updates didn't work at all, at first - we had to change "OBBrowser allInstancesDo:" to "OBBrowser allSubInstancesDo:". And the text pane doesn't seem to update at all without manually re-selecting the current method (which also means that it doesn't complain with the thick red line if you have concurrent edits in different browsers). Apart from that, it's been very solid, and seems to include all the menu items, d'n'd, and so on that I would expect - it now feels like a finished browser rather than a proof of concept.
Ok, updates are now fixed - each browser subscribes to the SCN, and refreshes via morphic stepping.
If anyone else is updating from -cwp.17, I found that you had to execute this in a workspace first:
OBNotifier uniqueInstance stop; unregister
Apart from that the new version works well.
Avi
On Sep 11, 2004, at 12:54 AM, Colin Putney wrote:
On Sep 10, 2004, at 4:23 AM, danielv@tx.technion.ac.il wrote:
If you release (an alpha) in the next day, we can test it at CampSmalltalk and maybe help along.
Ok, this isn't quite a full release, as I haven't posted on SqueakMap and don't have time to figure out SAR packaging tonight, but here it is. You'll need Monticello loaded to run the tests.
By the way, I just ran the tests in a 3.7gamma2 image: 99 run, 99 passed. Having that comprehensive a test suite for a browser is very, very cool - kudos.
Avi
Hi Colin,
Thanks for releasing the new OB-Standard for inclusion in the image. I am looking forward to use it more regularly. I hope it gets included soon!
I just wanted to let you know that executing code in the browser is broken again in cwp.19. I fixed it in OmniBrowser-bp.182. However, merging it in didn't look straightforward. I assume this is because of the package name change?
- Bernhard
Excellent. I think that having 3.9 as target can be quite a good opportunity. I know also that romain extended OB to support RB so we could have a clean RB and OB working together via services, and shout of course :)
Stef
On Aug 25, 2004, at 10:14 PM, Colin Putney wrote:
On Aug 25, 2004, at 12:56 PM, Marcus Denker wrote:
Am 25.08.2004 um 19:09 schrieb Avi Bryant:
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now.
I'm with Avi on that one.
Ok, between you two and Hernan, I'm convinced.
I'll put the fancy stuff on hold for a bit and just produce the simplest, cleanest browser I can, with an eye toward inclusion in 3.8.
Cheers,
Colin
I ***totally*** agree. Roel and alex in the past were implementing another pluggable browser (where the model was about navigation). But OB seems more appropriate and more efforts have been put in. So yes there is a need. How can we invent the future with tools like the old browser? Nathanael was really losing a ***lot*** of time just fixing and trying to extend the old browser. Now with the new notification mechanism there is a lot of opportunity to make tools that help us to be creative and efficient at doing it.
Stef
On Aug 25, 2004, at 7:09 PM, Avi Bryant wrote:
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing
- first get rid of the bottleneck of the standard browser so that
everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time).
My 0.02 EUR, Avi
This might be redundant by now, but I too think it would be a great move forward to include OmniBrowser. I might have to rework a bit since OB has changed since, but the last version of services I did added refactorings to OmniBrowser, so not all fonctionalities would be lost ...
Cheers, Romain
Avi Bryant a écrit:
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing - first get rid of the bottleneck of the standard browser so that everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time).
My 0.02 EUR, Avi
C'est marrant cette mailling list, tout le monde dit la même chose sur 50 mails :P (je rigole, c'est super intéressant...). En tout cas ca me distrait de mon rapport! Pour les mp3, j'ai réussi à les chopper, je les écouterais plus tard, là j'ai du massive attack c'est très bon :)
Florian
rrobbes a dit le 25/08/2004 23:24:
This might be redundant by now, but I too think it would be a great move forward to include OmniBrowser. I might have to rework a bit since OB has changed since, but the last version of services I did added refactorings to OmniBrowser, so not all fonctionalities would be lost ... Cheers, Romain Avi Bryant a écrit:
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing
- first get rid of the bottleneck of the standard browser so that
everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time). My 0.02 EUR, Avi
I am really sorry for this previous mail, I'm getting too tired... It is really interesting to read the internal affairs of the developments of Squeak. I am looking forward to test the next image!
Florian
Florian Minjat a dit le 26/08/2004 01:20:
C'est marrant cette mailling list, tout le monde dit la même chose sur 50 mails :P (je rigole, c'est super intéressant...). En tout cas ca me distrait de mon rapport! Pour les mp3, j'ai réussi à les chopper, je les écouterais plus tard, là j'ai du massive attack c'est très bon :)
Florian
rrobbes a dit le 25/08/2004 23:24:
This might be redundant by now, but I too think it would be a great move forward to include OmniBrowser. I might have to rework a bit since OB has changed since, but the last version of services I did added refactorings to OmniBrowser, so not all fonctionalities would be lost ... Cheers, Romain Avi Bryant a écrit:
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
My vote: replacing the default browser with OmniBrowser, even with short term loss of functionality, is absolutely the right thing to focus energy on for now. I say this because OB (in its simple form, as a framework for browser building, rather than with all the extra stuff I know you're planning) is an enabler for all kinds of cool work. Shout, Traits, Monticello, Chuck, and no doubt lots of other projects we don't know about, would benefit from having the lower levels of OB solidly in place - and neglecting them to work on the higher levels is an opportunity cost. It's an effort multiplier thing - first get rid of the bottleneck of the standard browser so that everyone can play, then go off and do the fun stuff (while watching everyone else do fun stuff on top of the basic OB at the same time). My 0.02 EUR, Avi
Am 25.08.2004 um 18:22 schrieb Colin Putney:
Now, if I were to post-pone those features, and focus on a clean and simple reimplementation of the default browser, I think that could be done fairly quickly. But note that this would be a very bare-bones implementation, with even fewer features than the default browser. I don't have any plans to implement the groovy experiments that were done by SqueakCentral - things like tile view, alternate syntax etc.
These experiments were experiments that are, to my knowledge, not worked on any more. So we should remove them. Actualy that would make large parts of the system much simpler...
With a modern parsetree implementation and a modern compiler, much of those experiments could be done in a much more modular kind of way.
Marcus
Colin said:
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
Hi Colin,
I agree pretty much with Avi and I vote to replace or at least include OmniBrowser on the Image. I believe that once Omnibrowser is available people will feel encouraged to add its favorites features to it. After all OB has such a nice and clean implementation that is a pleasure to work with it.
Regards, Hernán
Folks -
First the good news: We can now generate, from a single set of sources, four different VMs...
One that will run a 32-bit image on a 32-bit host same old VM One that will run a 32-bit image on a 64-bit host needed to run on 64-bit machines One that will run a 64-bit image on a 32-bit host great for testing 64-bit VM on 32-bit machines One that will run a 64-bit image on a 64-bit host the thing we were after
... and all of them work!
Ian and I worked together on this, with Ian focused on issues of C translation rules, and me focused on properly generalizing all the occurrences of 4 (bytes per word), 2 (shift count), and lots of other things derived therefrom. I also wrote a tracer subclass that will write images in a 64-bit format, and Ian also contributed the brilliant framework that enabled this four-way compatibility.
Now the fine print... The 64-bit format is the simplest change that could work, not the simplest format that could work. For those who understand the object current format, here is the change:
All object pointers are 64 bits as you'd expect.
SmallIntegers are still 31-bits, although stored sign-extended to 63 bits (plus tag bit).
32-bit Object header: 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 6 bits object size in 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1-word)
64-bit Object header: 32 bits all zero 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 5 bits object size in 64-bit words 1 bit extra 4-bit of size in bytes or 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1-word)
The object size field had to be in units of 8 bytes, and therefore three low-order bits are required instead of the 2 that are in the current format field. I simply used the vacated bit of the word size field for the 3rd low bit. It's Byzantine, but it works with few changes.
We have only converted the core interpreter and 3 plugins (BitBlt, BalloonEngine and FilePlugin). This is enough to run Squeak and test it. Moreover we now have a lot of experience with the conversion process, and we will write down a set of guidelines for converting the remaining plugins. We may ask for help from the Squeak community in converting the remaining plugins, and also image segment code. In some case there is clearly someone who knows the code much better than us, and for the rest, there may simply be others who want a complete 64-bit system.
We have not done *any* of the Version 4 changes. The first reason is that we need to release this work soon before we get out of phase with other Squeak progress. The second is some discussion in our group about the possibility of making *much* more major changes. As soon as we get clearer about this and confirm our intention, we'll have more to say about it. If were to go ahead with such a rethink, then any time spent of Version 4 would have been wasted.
We have not done any testing beyond the point of bringing up a morphic screen with Squeak mouse, opening a browser and running the benchmarks. There is lots to test, and surely a number of bugs yet to be found. The Squeak community can be of enormous help here.
Next steps... Ian and I are both pretty busy, but it is our hope to test the build process some more, and put out a complete source tree with this work in the course of the next month. At that point others can help us to convert the remaining plugins and to test the system as a whole.
- Dan
Let me be the first to say ...
Woo-hooooo!!!!
:-)
Chris Becker
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Friday, August 27, 2004 11:52 AM To: The general-purpose Squeak developers list Subject: Progress on 64-bit port
Folks -
First the good news: We can now generate, from a single set of sources, four different VMs...
One that will run a 32-bit image on a 32-bit host same old VM One that will run a 32-bit image on a 64-bit host needed to run on 64-bit machines One that will run a 64-bit image on a 32-bit host great for testing 64-bit VM on 32-bit machines One that will run a 64-bit image on a 64-bit host the thing we were after
... and all of them work!
Ian and I worked together on this, with Ian focused on issues of C translation rules, and me focused on properly generalizing all the occurrences of 4 (bytes per word), 2 (shift count), and lots of other things derived therefrom. I also wrote a tracer subclass that will write images in a 64-bit format, and Ian also contributed the brilliant framework that enabled this four-way compatibility.
Now the fine print... The 64-bit format is the simplest change that could work, not the simplest format that could work. For those who understand the object current format, here is the change:
All object pointers are 64 bits as you'd expect.
SmallIntegers are still 31-bits, although stored sign-extended to 63 bits (plus tag bit).
32-bit Object header: 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 6 bits object size in 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1- word)
64-bit Object header: 32 bits all zero 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 5 bits object size in 64-bit words 1 bit extra 4-bit of size in bytes or 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1- word)
The object size field had to be in units of 8 bytes, and therefore three low-order bits are required instead of the 2 that are in the current format field. I simply used the vacated bit of the word size field for the 3rd low bit. It's Byzantine, but it works with few changes.
We have only converted the core interpreter and 3 plugins (BitBlt, BalloonEngine and FilePlugin). This is enough to run Squeak and test it. Moreover we now have a lot of experience with the conversion process, and we will write down a set of guidelines for converting the remaining plugins. We may ask for help from the Squeak community in converting the remaining plugins, and also image segment code. In some case there is clearly someone who knows the code much better than us, and for the rest, there may simply be others who want a complete 64-bit system.
We have not done *any* of the Version 4 changes. The first reason is that we need to release this work soon before we get out of phase with other Squeak progress. The second is some discussion in our group about the possibility of making *much* more major changes. As soon as we get clearer about this and confirm our intention, we'll have more to say about it. If were to go ahead with such a rethink, then any time spent of Version 4 would have been wasted.
We have not done any testing beyond the point of bringing up a morphic screen with Squeak mouse, opening a browser and running the benchmarks. There is lots to test, and surely a number of bugs yet to be found. The Squeak community can be of enormous help here.
Next steps... Ian and I are both pretty busy, but it is our hope to test the build process some more, and put out a complete source tree with this work in the course of the next month. At that point others can help us to convert the remaining plugins and to test the system as a whole.
- Dan
We have not done *any* of the Version 4 changes. The first reason is that we need to release this work soon before we get out of phase with other Squeak progress. The second is some discussion in our group about the possibility of making *much* more major changes. As soon as we get clearer about this and confirm our intention, we'll have more to say about it. If were to go ahead with such a rethink, then any time spent of Version 4 would have been wasted.
Hi dan
I think that this is the right approach. I also think that this is interesting to take the time to think about changes because there are few moments for changes and this one is one moment for changes so use it :). Changing for better is always good.
Stef
I just want say thanks to you and Ian for this wonderful work.
I look forward to using Squeak on my dual Opteron server. I run Gentoo Linux on that machine. And hopefully a new G5 Mac next year. :)
DI> I also wrote a tracer subclass that DI> will write images in a 64-bit format
Do I understand correctly that either I will be able to build or download a 64-bit image to use with my new 64-bit vm?
Does it take any pre-existing 32-bit image and do its conversion, thus creating the 64-bit version of that image?
Again, thanks for this wonderful gift to the Squeak community.
Jimmie Houchin
What is the point of 64 bit Squeak? Is it the same as the point of 64 bit processors which is (as I understand it) that they can address more than 4 gigabytes of RAM? Or are there other benefits besides the larger address space? Would there ever be a reason to prefer a 64 bit architecture over a 32 bit one for applications that are known to fit in less than 4 gigabytes of RAM?
From: [...] Dan Winkler Would there ever be a reason to prefer a 64 bit architecture over a 32 bit one for applications that are known to fit in less than 4 gigabytes of RAM?
If you were doing something that used integers (or fixed-point values) between 32 and 64 bits in length, a 64-bit architecture would help. In Squeak, one would still need to modify SmallInteger to handle 63-bit values, however.
Also, matching the CPU's own architecture tends to help speed-wise. I'm sure the processor gurus on this list will have more to say about it!
- Peter
Also, matching the CPU's own architecture tends to help speed-wise. I'm sure the processor gurus on this list will have more to say about it!
On the x86-64 it is probably best to stick with 32-bit immages because you get about twice as many useful registers that way. -- it's the way the thing is designed....
Dan,
First the good news: We can now generate, from a single set of sources, four different VMs...
One that will run a 32-bit image on a 32-bit host same old VM One that will run a 32-bit image on a 64-bit host needed to run on 64-bit machines One that will run a 64-bit image on a 32-bit host great for testing 64-bit VM on 32-bit machines One that will run a 64-bit image on a 64-bit host the thing we were after
... and all of them work!
Ian and I worked together on this, with Ian focused on issues of C translation rules, and me focused on properly generalizing all the occurrences of 4 (bytes per word), 2 (shift count), and lots of other things derived therefrom. I also wrote a tracer subclass that will write images in a 64-bit format, and Ian also contributed the brilliant framework that enabled this four-way compatibility.
Thanks for sharing the good news ...
Now the fine print... The 64-bit format is the simplest change that could work, not the simplest format that could work.
... and the fine prints. (good to know that there are no bad news ;-)
For those who understand the object current format, here is the change:
All object pointers are 64 bits as you'd expect.
SmallIntegers are still 31-bits, although stored sign-extended to 63 bits (plus tag bit).
32-bit Object header: 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 6 bits object size in 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1-word)
I guess there is no changes from the current 32-bit header ?
I've been wondering why header type wasn't like this:
1 : 1-word 2 : 2-word 3 : 3-word 0 : reserved (this is for headless objects only ;-)
64-bit Object header: 32 bits all zero 3 bits reserved for gc (mark, old, dirty) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format (includes low bits of size in bytes) 5 bits object size in 64-bit words 1 bit extra 4-bit of size in bytes or 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1-word)
The object size field had to be in units of 8 bytes, and therefore three low-order bits are required instead of the 2 that are in the current format field. I simply used the vacated bit of the word size field for the 3rd low bit. It's Byzantine, but it works with few changes.
How much bigger is the 64-bit image compared to 32-bit image for, say, the 3.7 gamma ?
We have only converted the core interpreter and 3 plugins (BitBlt, BalloonEngine and FilePlugin). This is enough to run Squeak and test it. Moreover we now have a lot of experience with the conversion process, and we will write down a set of guidelines for converting the remaining plugins. We may ask for help from the Squeak community in converting the remaining plugins, and also image segment code. In some case there is clearly someone who knows the code much better than us, and for the rest, there may simply be others who want a complete 64-bit system.
Is BalloonEngine just B2DPlugin or it also includes B3DAcceleratorPlugin ?
I am interested to know how FilePlugin is implemented.
We have not done *any* of the Version 4 changes. The first reason is that we need to release this work soon before we get out of phase with other Squeak progress. The second is some discussion in our group about the possibility of making *much* more major changes. As soon as we get clearer about this and confirm our intention, we'll have more to say about it. If were to go ahead with such a rethink, then any time spent of Version 4 would have been wasted.
This sounds good. Can you disclose what are these *much* more major changes that are being discussed ?
We have not done any testing beyond the point of bringing up a morphic screen with Squeak mouse, opening a browser and running the benchmarks. There is lots to test, and surely a number of bugs yet to be found. The Squeak community can be of enormous help here.
I hope you did test " 3 + 4 " ;-)
Next steps... Ian and I are both pretty busy, but it is our hope to test the build process some more, and put out a complete source tree with this work in the course of the next month. At that point others can help us to convert the remaining plugins and to test the system as a whole.
My next months are kind of busy, summer is over.
Please drop me a note if there is an opportunity for an earlybird preview of Windows (IA32/IA64) ports.
Cheers,
PhiHo.
I would prefer to have a cleaner, simpler browser that we can extend and changes than waiting for the hyper mega cool one or stay with the old one. I think that nice features can then be reimplemented on the clean one.
Stef
On Aug 25, 2004, at 6:22 PM, Colin Putney wrote:
On Aug 25, 2004, at 4:00 AM, Andrew Tween wrote:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
OmniBrowser doesn't work in MVC right now. The reasons for that are practical rather than technical, though - not many people use MVC, and those that do are often in low-resource situations. So I think making OB work under MVC is feasible if it seems like it would be worth the effort.
Stéphane Ducasse wrote:
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
Although I'd like to see this happen eventually, I don't think OmniBrowser is ready.
This is partly because I've been focussed on some fairly ambitious, long-term goals. This means things like proper handing of packages, producing a clean implementation of the RB, integrating nicely with the ClosureCompiler etc.
Now, if I were to post-pone those features, and focus on a clean and simple reimplementation of the default browser, I think that could be done fairly quickly. But note that this would be a very bare-bones implementation, with even fewer features than the default browser. I don't have any plans to implement the groovy experiments that were done by SqueakCentral - things like tile view, alternate syntax etc.
I'd like to know what the community thinks about this. Is the default browser painful enough that we should replace it ASAP, even if that means delaying new features? Or is the default browser good enough that we should keep using it until OmniBrowser represents a substantial improvement?
Colin
Hi nady
I agree but the code of the browser is crappy, buggy, fragile. And we **all** need a browser that can change, evolve to meet our needs. There are a lot of things that are really slwo to do with this browser and 25 years of good services may be enough.
Stef
On Aug 25, 2004, at 11:00 AM, Andrew Tween wrote:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
Although I have come up with one solution, for Shout, using AppRegistry, it may not be the best solution. We should take some time to consider the options before making changes to the kernel. Perhaps an event model would be more flexible, for instance? Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView, #builtMorphicView , etc. events. And anything can handle those events and change the Browser's behaviour.
I am not familiar with Services, I'll take a look.
The big danger in all this is that we introduce a framework that leads to as many bugs as would be caused by simply allowing packages included in the full image to override kernel methods. So; we need to make kernel changes; but we need to consider carefully what those changes should be. If we are aiming to acheive this for 3.9, then there is no great rush. Cheers, Andy
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 25, 2004 6:48 AM Subject: Re: Lessons learnt from been an integrator
Hi andy
We really think that we should really prepare 3.9 so that the system is made better to get new tool like yours.
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
So the first step is really to send the fix that can go in the kernel, thne identify what should be done at the kernel level, have you got a look at the services package because this would be really a good basis to support RB, shout integration. Stef
On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ... 1. a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to MorphicTextEdtior, but for MVC)
2. a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004 <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
Hi, I fully agree with OmniBrowser becoming the default browser. I was merely questioning whether the current browser should remain (in the image, or as a package), or disappear completely. I assumed that it would need to remain - perhaps that assumption is incorrect.
And, whatever the default browser happens to be, the integration issues with regard to getting 'hooks' in the right place still remain. For example, Shout highlighting in the Debugger will still require overrides or hooks or patches of some kind. Now, if there was an OmniDebugger... :>) Cheers, Andy
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 25, 2004 8:23 PM Subject: Re: Lessons learnt from been an integrator
Hi nady
I agree but the code of the browser is crappy, buggy, fragile. And we **all** need a browser that can change, evolve to meet our needs. There are a lot of things that are really slwo to do with this browser and 25 years of good services may be enough.
Stef
On Aug 25, 2004, at 11:00 AM, Andrew Tween wrote:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
Although I have come up with one solution, for Shout, using AppRegistry, it may not be the best solution. We should take some time to consider the options before making changes to the kernel. Perhaps an event model would be more flexible, for instance? Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView, #builtMorphicView , etc. events. And anything can handle those events and change the Browser's behaviour.
I am not familiar with Services, I'll take a look.
The big danger in all this is that we introduce a framework that leads to as many bugs as would be caused by simply allowing packages included in the full image to override kernel methods. So; we need to make kernel changes; but we need to consider carefully what those changes should be. If we are aiming to acheive this for 3.9, then there is no great rush. Cheers, Andy
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 25, 2004 6:48 AM Subject: Re: Lessons learnt from been an integrator
Hi andy
We really think that we should really prepare 3.9 so that the system is made better to get new tool like yours.
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
So the first step is really to send the fix that can go in the kernel, thne identify what should be done at the kernel level, have you got a look at the services package because this would be really a good basis to support RB, shout integration. Stef
On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ... 1. a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to MorphicTextEdtior, but for MVC)
2. a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004 <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
On Aug 25, 2004, at 4:03 PM, Andrew Tween wrote:
Now, if there was an OmniDebugger... :>)
This idea occurs to me on a regular basis. Each time, I end up firmly putting it aside. I've already bitten off more than I can chew. :-)
Of course if somebody else wants to give it a go, I'd love to cheer from the sidelines.
Colin
If you mean by replacing the default Browser with a completely tested, "stable" version of OmniBrowser, that would be great. But, as it is, the maturity level of OmniBrowser is listed as "Alpha - Usable by daredevils...." That scares me!
brad
Andrew Tween wrote:
Hi, Replacing the default Browser with OmniBrowser *might* make things easier. However; the default browser would still need to be available, and if it is available then Shout should still work with it. So, whether the default browser remains part of the image, or is split out into a package, the problem of integrating with it remains the same. Then there is mvc - I don't know if OmniBrowser works under mvc (or could be made to work)??
Although I have come up with one solution, for Shout, using AppRegistry, it may not be the best solution. We should take some time to consider the options before making changes to the kernel. Perhaps an event model would be more flexible, for instance? Browser triggers #needsCodeMorph , #needsCodeView, #builtMVCView, #builtMorphicView , etc. events. And anything can handle those events and change the Browser's behaviour.
I am not familiar with Services, I'll take a look.
The big danger in all this is that we introduce a framework that leads to as many bugs as would be caused by simply allowing packages included in the full image to override kernel methods. So; we need to make kernel changes; but we need to consider carefully what those changes should be. If we are aiming to acheive this for 3.9, then there is no great rush. Cheers, Andy
----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Wednesday, August 25, 2004 6:48 AM Subject: Re: Lessons learnt from been an integrator
Hi andy
We really think that we should really prepare 3.9 so that the system is made better to get new tool like yours.
One possibility would also be to throw away the default browser and replace it by omnibrowser. If it is ready for that. Colin what do you think?
So the first step is really to send the fix that can go in the kernel, thne identify what should be done at the kernel level, have you got a look at the services package because this would be really a good basis to support RB, shout integration. Stef
On Aug 24, 2004, at 7:27 PM, Andrew Tween wrote:
With regard to the Full image / Shout / overridden methods ...
I have done some work on splitting Shout into ...
- a changeset of base image changes. including an MvcTextEditor subclass of AppRegistry (similar to
MorphicTextEdtior, but for MVC)
- a package that makes no changes to existing base image methods. (Although it does add new methods to base classes)
I have achieved the above (see attached files). However; I am not happy with they way the code is looking at the moment. There is a lot of duplication where I have had to create subclasses of some base classes, and some nasty hacks.
So, it needs some further work; and a lot of testing - particularly in mvc. But I thought I'd post what I have so far.
Thanks to all who are working on the full image - which, in the future, will be even fuller ;>) Cheers, Andy
----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, August 24, 2004 3:51 PM Subject: Re: Lessons learnt from been an integrator
Am 24.08.2004 um 15:57 schrieb Hannes Hirzel:
Hello,
stéphane ducasse wrote:
Hi all
here are the lessons we learnt while building the 3.7 image. We wanted to have shout, rb, connector morph in 3.7 but there were too much patches.
What do you mean by this? Did the packages not load? Or did they overwrite important methods?
They overwrite many methods. It makes no sense at all to have a system in beta for 4 Months and then change stuff a week before a release.
How did you find out?
By looking at the code?
Thank you Stef for this report.
I learn that it is not possible to integrate Ned's connector morphs. What is the reason? Did you contact Ned? He is often amazing how fast he fixes things. I remember that he recently put out a new release. As SM is down currently I cannot check.
Ned posted *a lot* of fixed for morphic to the list. Many of those are required for Connectors, but not all of them got added to 3.7.
It would be very nice to have the connector morphs in 3.7 full. Or perhaps it is not a good idea to integrate something which has not been retested. I would be willing to retest 3.7 full with Ned's connector morphs included. However this will surely add a few days more.
There is no way to add connectors to 3.7, as we can't add all the patches.
Maybe people should have put some effort into integrating all the stuff into 3.7 when it was possible, but somehow nobody wanted to do that back then. I wrote lots of mails to the list that there is work to be done with regard to harvesting, but everyone seems to be thinking that it is not important.
Marcus
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 06/07/2004 <CodeEditorsUseAppRegistry.4.cs><Shout.3.15-tween.8.mcz>
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.716 / Virus Database: 472 - Release Date: 05/07/2004
On Aug 25, 2004, at 3:21 PM, Brad Fuller wrote:
If you mean by replacing the default Browser with a completely tested, "stable" version of OmniBrowser, that would be great. But, as it is, the maturity level of OmniBrowser is listed as "Alpha - Usable by daredevils...." That scares me!
Hi Brad,
I agree with you on this point - the version on SqueakMap isn't ready to be a standard package.
However, the core of OB is actually pretty stable. It's the more advance features that are still shaky. Since people are interested in pushing OB into broader use, I'm going to strip that stuff out and produce a version that's considerably simpler and more stable.
I think a combination of simplicity, good automated test coverage and broad testing by the community should be enough to ensure that OB is solid before we retire the current implementation. Note also that this would be done in the alpha phase, when a little instability is acceptable.
Colin
squeak-dev@lists.squeakfoundation.org
-
Alan Grimes -
Andrew P. Black -
Andrew Tween -
Avi Bryant -
Bernhard Pieber -
Brad Fuller -
Chris Becker -
Colin Putney -
Dan Ingalls -
Dan Winkler -
danielv＠tx.technion.ac.il -
Doug Way -
Florian Minjat -
Hannes Hirzel -
Hernan Tylim -
Jimmie Houchin -
Jon Hylands -
Kamil Kukura -
Marcus Denker -
Peter Crowther -
rrobbes -
SmallSqueak -
stéphane ducasse