Hi Dan,
Good! I was thinking that at the end this what would happen anyway but I played the game just to see. I should have bet with myself. I was discussing with Andrew Black and we agreed that the real problem for nonSqC people is that you have to update, understand the changes every times you want to update your code or download code from somebody else. so modules or packaging will help this process.
So now I would really like to see a small of the system decomposed in modules and having dependencies and versions between them. I would like to see how we can load/unload a system like Alice or the speech recognition and be able to have different versions of Morph and different versions of Alice just to see how this would work.
My idea is that we should in the near future be able to load SqC Squeak or another one.
So the important points of this email: **************************************
Once we have module in place, the next steps are to put in place some infrastructure at the code level: - we should take the filelist of swt which support registration of the tools (this is implementation of henrik I adapted a bit).
- we should have the same at the level of the ui for morph and mvc. this would avoid to have morphic referenced from the compiler. Or have all these horrible Smalltalk at: #Morph everywhere in the code. This is clearly the sign that something is missing.
- I think that modules without a clean dependency structure will be just lazzagna instead of spaghetti code ;)
I think that analysing the dependencies between the modules will be an important occasion for squeak to be cleaned (removing gifReader reference from Smalltalk, or things like that), In the same way roel told me that he could not write a nice visitor on html tree to check web page because there was a dialog popping up as error, so we have a dependency between socket and UI ;(
- Can you tell us how you see the process, because I would like to participate? What I see is that you or a group of volunteers will have to do a first pass to fix the original structure of the dependency between modules checking why certain conceptually unrelated modules are related. Then or fixing them directly or making a list of things to be fixed.
- Is there a analysis support for doing that? because in Envy the system tell us (brutally) when a class refers to a non-visible class. and this is important to move things around and as squeak does not have a culture of explicit tests this may be a long task
Some other important points: **************************** Then I just want to point some process issues about the module discussion. I was waiting for saying that: I hope that we will leran for the next time but I'm not even sure ;(
If you look at the way modules have been discussed this is not really efficient: - we had lot of traffic at the beginning hence nobody could really take the time to read everything. I tried and it was extremely difficult. So imagine somebody working full time and travelling receiving all these emails. -> put a moderator next time
- we put the modsqueak too fast in the mailing list and got noise (sorry but do not touch my image emails were boring!) then
- we excluded the people of the modsqueak mailing-list. Look at who really used this modsqueak mailing-list. I think that this would have been clearer to say to them: "you do not want to be in the mailing ok we will not interact with you."
- I'm personally a bit frustrated because lot of the design points I asked have never been answered like if they were or stupid or misplaced. originally I was thinking ok I do not care, but I care because I'm investing on Squeak. So I hope we will not realize mistakes in 1 year from now.
Stef
-- Folks -
I feel the need to cut what has become a Gordian knot.
By the end of this week I intend to issue Henrik's module code as updates to Squeak 3.1alpha. While this may look selfish or irrational, I think it's the right thing to do, and at this point someone will likely be unhappy no matter what we do.
Our top priorities for modules in Squeak are:
Support modularity of active Squeak content distributed as projects on the Internet
Support an ecology of interrelated enhancements to Squeak from throughout the community
Keep it small and simple.
This is a Squeak Central perspective. Others surely have other priorities. We feel that as soon as we achieve the first goal, Squeak will disappear. In other words, the significance of Squeak as a vehicle for easily-authored multimedia content will dwarf that of Squeak as a development environment, and all the activity of this mailing list will likely pale by comparison to work on active content.
The ModSqueak work is an excellent system with a somewhat different set of priorities. It could be made to serve these ends, but I foresee constant conflict in trying to do so. I prefer to proceed directly toward these goals with Henrik's code, and to allow the ModSqueak facilities to remain one of the packages that can be easily loaded by anyone who wants its particular benefits.
In adopting this approach we will take care that nothing in the resident module scheme interferes with loading and using ModSqueak as now. Presumably a great deal could actually be shared, once the dust settles a bit, and loading should, of course, become simpler. What is important is that ModSqueak can remain just what its authors intended it to be, and the the resident module system can be tweaked into a lean and effective architecture for community sharing and active media on the web.
Those who have followed the full modules discussion will recognize that our first priority here is really more of a component architecture, and this is true. At the same time, we feel that the module kernel will serve well the needs of the Squeak community for collaboration and distribution of add-on packages, as well as producing reduced images for PDAs, servers and other applications.
Yours on behalf of SqC (and wearing asbestos today ;-)
- Dan
Hi Dan
Just another point. I think that GINSU just proposes an architecture no more for packaging classes and supporting categorisation. This the way modules, package are nested that is interesting, so this is the design decisions that could incorporated into henrik design. may be he already looked at it. So I was seeing GINSU more as a basis to build your active component (which interests me a lot as I told you) that the end of the story. This was not the goal of GINSU from what I understood.
stef
Now this is the Stephane I know ;-)
ducasse stephane wrote:
So now I would really like to see a small of the system decomposed in modules and having dependencies and versions between them.
Yes, this is no small task. More below.
I would like to see how we can load/unload a system like Alice or the speech recognition and be able to have different versions of Morph and different versions of Alice just to see how this would work.
There will be demos for sure, but we will roll things out in increments, and there will be bumps in the road no doubt.
Once we have module in place, the next steps are to put in place some infrastructure at the code level:
- we should take the filelist of swt which support registration of the tools
(this is implementation of henrik I adapted a bit).
If you bring it up to 3.1 I will vote for this to be included right away.
- we should have the same at the level of the ui for morph and mvc.
Some indirection is desirable but I think "the same" will be hard. Only a small subset is the same for both.
would avoid to have morphic referenced from the compiler. Or have all these horrible Smalltalk at: #Morph everywhere in the code. This is clearly the sign that something is missing.
Having Morphic "carry" these as external methods could solve some of these problems, but not all.
- I think that modules without a clean dependency structure will be just
lazzagna instead of spaghetti code ;)
If we mean that we need to refactor the image, yes definitely. But if you mean some sort of higher-level architectural scheme I have a proposal for a model that I developed when digging a little deeper into the current image. I will post it in a separate thread.
I think that analysing the dependencies between the modules will be an important occasion for squeak to be cleaned (removing gifReader reference from Smalltalk, or things like that), In the same way roel told me that he could not write a nice visitor on html tree to check web page because there was a dialog popping up as error, so we have a dependency between socket and UI ;(
This need will always be there; I think we will need to carefully choosing "which battles to fight", picking the most important and easiest achieved :-) goals first. So many refactorings, so little time...
- Can you tell us how you see the process, because I would like to
participate?
Steph, excellent! Code improvements that don't need the module system as such can be done right now. The FileList refactoring is a perfect example of this. So any such untangling can be begun today. Cleaning up exceptions like in Roel's example is another.
Beside that, contributing refactorings *within* the new modules system. E.g. redoing the equivalent of majorShrink to work with it.
Also, "porting" existing packages to the scheme: Whisker, MathMorphs, RB, Ginsu(!). Although Ginsu may be a little bit harder--I suspect it modifies some of the same parts as this modules system itself.
An immediate task is for SqF to bring about a central (think "default" not centralized) repository. We have had a temporary one from Cees but the long term requires another solution, and there are a lot of non-technical issues surrounding this as well, rules and principles etc. This could start right now.
I am hoping that Dan posts his recent thoughts about what goals we would want to focus on, I liked what he proposed. Having established, clear, shared goals in mind is crucial and very helpful.
What I see is that you or a group of volunteers will have to do a first pass to fix the original structure of the dependency between modules checking why certain conceptually unrelated modules are related. Then or fixing them directly or making a list of things to be fixed.
I feel like the proverbial horse between two hay stacks right now: posting info and documentation, vs. concentrating on bringing the code functionality forward, at least to the point where others can start to use the system and make solid contributions. Thoughts on what you all think we should prioritize are welcome.
- Is there a analysis support for doing that?
because in Envy the system tell us (brutally) when a class refers to a non-visible class. and this is important to move things around and as squeak does not have a culture of explicit tests this may be a long task
There are some things, for example see the Module class, categories "code analysis" and "system conversion"; class ModuleRefactorer and subclasses. This works with the code I already sent out.
- we excluded the people of the modsqueak mailing-list. Look at who
really used this modsqueak mailing-list. I think that this would have been clearer to say to them: "you do not want to be in the mailing ok we will not interact with you."
This was unintentional, we started that way but then it slipped. It might have been a task for a moderator to repost to them.
- I'm personally a bit frustrated because lot of the design points I
asked have never been answered like if they were or stupid or misplaced. originally I was thinking ok I do not care, but I care because I'm investing on Squeak. So I hope we will not realize mistakes in 1 year from now.
In truth, almost all of them had been discussed here some time before, but I understand you were working on your habilitation back then.
Henrik
Henrik Gedenryd Henrik.Gedenryd@lucs.lu.se wrote...
I am hoping that Dan posts his recent thoughts about what goals we would want to focus on, I liked what he proposed. Having established, clear, shared goals in mind is crucial and very helpful.
I'm about to go to sleep, but here's a copy of the proposal to which Henrik refers. I send it along not because I think it is great, but just to focus discussion. --------------------- At the risk of repeating myself, here are what I see as natural next steps:
1. Clarify the name space / module distinction, if Henrik's latest message hasn't done this already. This is for our internal discussion.
2. Use the system to outload a couple of big packages such as
VM Construction Newtork apps (Celeste, Scamper, Chat and HTML) Wonderland and 3D
... and confirm that everything works if you bring them in again.
This would be a big step toward effective shrinking and would probably get people excited.
3. Use the system to inload a couple of big packages such as
Refactoring Browser Connectors Thinglab and/or Cassowary Mathmorphs ModSqueak
These would be modules serving the community.
4. Document the anticipated steps to compact files and fast loading with image segments.
Should get people enthusiastic about 4x compression, and 10x speed-up. [for those interested, compact files is an idea I have for browsing direct from gzipped files]
5. Arrive at a preliminary design for projects as components. In other words,
Start from a URL Determine prerequisites Load them if necessary Load the content Be able to run it (duh) Be able to unload it and be "clean" afterward.
This is for our internal discussion, but I would like to try it out ASAP.
Here is a simple benchmark: My KidsRefrigeratorMagnets which requires Ned's RMs, which requires Ned's Connectors. Delivered in a world and ready to play.
Here is a complicated one: Drive a Car in a world and ready to play, and... Will automatically bring in all of EToys if not there.
I figured I would write up some of this in a coherent manner, with Henrik's help in the next couple of days as a sort of "Here's where we are heading between now and OOPSLA" message.
- Dan
Thanks for that dan. I'm really eager to play with that and participate. I'm thinking that we could even use Squeak for living refactoring section in some lectures. I'm convinced that this is the right direction and we will be able to clean Squeak :). I really like that....continue
--------------------- At the risk of repeating myself, here are what I see as natural next steps:
No communication is really important
1. Clarify the name space / module distinction, if Henrik's latest message hasn't done this already. This is for our internal discussion.
I hope that the two are orthogonal.
2. Use the system to outload a couple of big packages such as
VM Construction Newtork apps (Celeste, Scamper, Chat and HTML) Wonderland and 3D
... and confirm that everything works if you bring them in again.
This would be a big step toward effective shrinking and would probably get people excited.
3. Use the system to inload a couple of big packages such as
Refactoring Browser Connectors Thinglab and/or Cassowary Mathmorphs ModSqueak
These would be modules serving the community.
4. Document the anticipated steps to compact files and fast loading with image segments.
Should get people enthusiastic about 4x compression, and 10x speed-up. [for those interested, compact files is an idea I have for browsing direct from gzipped files]
The parcel in VW are extremely fast so this makes a big steps forward.
5. Arrive at a preliminary design for projects as components. In other words,
Start from a URL Determine prerequisites Load them if necessary Load the content Be able to run it (duh) Be able to unload it and be "clean" afterward.
This is for our internal discussion, but I would like to try it out ASAP.
Here is a simple benchmark: My KidsRefrigeratorMagnets which requires Ned's RMs, which requires Ned's Connectors. Delivered in a world and ready to play.
Here is a complicated one: Drive a Car in a world and ready to play, and... Will automatically bring in all of EToys if not there. I figured I would write up some of this in a coherent manner, with Henrik's help in the next couple of days as a sort of "Here's where we are heading between now and OOPSLA" message.
- Dan
Hi,
I published a small etoys project "Insight" at Bob's Super Swiki which -- I hope -- takes you through a few "Aha" steps to finally appreciate that width of vision is important to correctly understand phenomena.
Hope it works (both content-wise and technically) for you.
When loaded it back in again it did not work as expected since the Squeak Plugin had a different extent.
I found out that a morph's y coordinates are dependent on the vertical extent of the squeak window. Watch the y-coordinate of a morph, resize the window and see it update accordingly. Note that the x-coordinate is not influenced by the horizontal extent!
I do not think that absolute coordinates should be dependent on the squeak window size and suggest to have the same behaviour for y coordinates as for x coordinates.
At least, the current behaviour bit me as my "reset" button puts some shapes at certain positions. I solved the problem by making their positions relative to a non-moving morph in my project. If the window is resized (or has another extent than my development image) than the y coordinate of that fixed morph changes and thus the positions of the other shapes as it is calculated relative to the fixed morph.
Perhaps there is a better way, but nevertheless I think that absolute y coordinates should not depend on window extent (although I can imagine why it is that way at the moment).
BTW, I tried to achieve a similar effect by modifying the height of a rectangle (instead of moving the rectangle) but that works only one direction. If I turn a rectangle by 180 degrees first and then try to alter its height (to obtain the shrinking in the other direction) then that does not work. Perhaps it is because the morph is now a rotated bitmap, but in any event it is unfortunate.
Cheers,
Thomas
P.S.: I'll be on a conference trip until October 15th so I probably won't be able to respond in a timely manner until then.
-- Dr. Thomas Kuehne +49 178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne Experts are people who successfully calibrated their intuition. -- TK
Hi Henrik
thanks to answer I was thinking that I was saying something wrong, and have the impression to shout in the desert
Once we have module in place, the next steps are to put in place some infrastructure at the code level:
- we should take the filelist of swt which support registration of the tools
(this is implementation of henrik I adapted a bit).
If you bring it up to 3.1 I will vote for this to be included right away.
Ok I will try. Slowly because I'm again flooded by reports ;((((
would avoid to have morphic referenced from the compiler. Or have all these horrible Smalltalk at: #Morph everywhere in the code. This is clearly the sign that something is missing.
Having Morphic "carry" these as external methods could solve some of these problems, but not all.
When morphic is referenced by the compiler or a non ui classe, this is simply wrong ;)
- I think that modules without a clean dependency structure will be just
lazzagna instead of spaghetti code ;)
If we mean that we need to refactor the image, yes definitely.
This is what I mean: removing unnecessary or stupid dependencies by moving methods around. restructuring the code. This is my business ;)
But if you mean some sort of higher-level architectural scheme I have a proposal for a model that I developed when digging a little deeper into the current image. I will post it in a separate thread.
I think that analysing the dependencies between the modules will be an important occasion for squeak to be cleaned (removing gifReader reference from Smalltalk, or things like that), In the same way roel told me that he could not write a nice visitor on html tree to check web page because there was a dialog popping up as error, so we have a dependency between socket and UI ;(
This need will always be there; I think we will need to carefully choosing "which battles to fight", picking the most important and easiest achieved :-) goals first. So many refactorings, so little time...
sure but we should be able to distribute the work
- Can you tell us how you see the process, because I would like to
participate?
Steph, excellent! Code improvements that don't need the module system as such can be done right now. The FileList refactoring is a perfect example of this. So any such untangling can be begun today. Cleaning up exceptions like in Roel's example is another.
But the problem is not doing it: the point is having it into the image and controlling the changes that's why these modules are so important. We will be able to work on a part of Squeak and controlling its changes.
What is important after the modules are started is to say to all the brave souls around: "ok if you want to be responsible for something please be and we can organise a kind of peer reviews"
Beside that, contributing refactorings *within* the new modules system. E.g. redoing the equivalent of majorShrink to work with it.
Also, "porting" existing packages to the scheme: Whisker, MathMorphs, RB, Ginsu(!). Although Ginsu may be a little bit harder--I suspect it modifies some of the same parts as this modules system itself.
No there is nothing complex in Ginsu, it modifies nothing just classify them according to some visibility rules. But nobody really looks at it.
I still do not know if the solution you proposed proposes modules has a scoping mechanism because I never had the time to look at it. Ginsu only partitions class according to dependency visibility that exist between modules but does not introduce a scoping mechanism.
And by the way I do not care about Ginsu, I just care about the knowledge people like joseph have. The design of the package and module interested me not the code. For me having modules is the way to have a clean squeak decomposable. this is the key point. Having tools to fight against spaghetti code is the next ones.
An immediate task is for SqF to bring about a central (think "default" not centralized) repository. We have had a temporary one from Cees but the long term requires another solution, and there are a lot of non-technical issues surrounding this as well, rules and principles etc. This could start right now.
I'm not sure about the repository right now. I think that a gross decomposition of the system is needed (with a chainsaw;)), the decomposition should identify which module depends on which one. Then we should have ModSq1.0 and start by letting people working on these big modules and cleaning them and decomposing them into smaller if necessary. But this is hard.
I am hoping that Dan posts his recent thoughts about what goals we would want to focus on, I liked what he proposed. Having established, clear, shared goals in mind is crucial and very helpful.
What I see is that you or a group of volunteers will have to do a first pass to fix the original structure of the dependency between modules checking why certain conceptually unrelated modules are related. Then or fixing them directly or making a list of things to be fixed.
I feel like the proverbial horse between two hay stacks right now: posting info and documentation, vs. concentrating on bringing the code functionality forward, at least to the point where others can start to use the system and make solid contributions. Thoughts on what you all think we should prioritize are welcome.
Focus on something working. I think that once we have an example we will understand
- Is there a analysis support for doing that?
because in Envy the system tell us (brutally) when a class refers to a non-visible class. and this is important to move things around and as squeak does not have a culture of explicit tests this may be a long task
There are some things, for example see the Module class, categories "code analysis" and "system conversion"; class ModuleRefactorer and subclasses. This works with the code I already sent out.
ok I will try. Do you have a wiki where I can find the latest version?
- we excluded the people of the modsqueak mailing-list. Look at who
really used this modsqueak mailing-list. I think that this would have been clearer to say to them: "you do not want to be in the mailing ok we will not interact with you."
This was unintentional, we started that way but then it slipped. It might have been a task for a moderator to repost to them.
- I'm personally a bit frustrated because lot of the design points I
asked have never been answered like if they were or stupid or misplaced. originally I was thinking ok I do not care, but I care because I'm investing on Squeak. So I hope we will not realize mistakes in 1 year from now.
In truth, almost all of them had been discussed here some time before, but I understand you were working on your habilitation back then.
As much as I would love to donate some code at this point, this will not happen in the near future due to the many interuptions going on in my life right now. So, instead here are some thoughts.
A while back I warned that it would probably turn out to be a very desireable property that whatever you do with modules, you do it in a manner which is both reversible and tolerant of the existing tools modifying things behind your back. I hereby reiterate that warning. The stuff I've seen lately does not appear to have this property. Get it.
Along those lines, what I've been working on in various airport terminals across the country is one approach to this. It isn't done yet, isn't that big a deal, but my time available is very tight right now. What I am doing is wrapping every class and method in the system with module-aware wrappers. That is, objects that facilitate the "paint" metaphor I mentioned earlier. "Paint" whatever you want, discard that paint scheme, and you still have the old system, working just as it always did. Changes done to the old system while you have it painted are easily tracked through the Change notification mechanism- this has been done for years in the Refactory tools, and I'm sure that this is just as viable in Squeak as it is in VisualWorks where I'm still working ( sorry, but the tools I have there are way more powerful ). So, using a regular System Browser you could patch something that has clobbered a Module Browser, and that patch would be reflected in the painted system as well.
The other aspect of this is that one could use various forms of Modurization Chainsawing to get a rough approximation to modular boundaries. For instance, partitioning along class category boundaries. A super duper general purpose fully automatic scheme to modularize a non-modular image is basically right out at this point. Nobody I am aware of can do this. Human intervention is required. But, that doesn't mean you can't whip out the chainsaw and make some rough cuts at it. After this, you will need other tools, such as those for finding classes which are only referenced by the classes of one module, yet is itself not in that module... but the human needs to decide if it should be moved. There are other problems that crop up too, such as finding that the class hierarchies do not neccessarily like the module partitionings generated this way ( intermediate classes in the super chain lying outside of a given module... so how do you load/unload it? ). There are quite a few things to find out about, but basically any tools that are created for these tasks will be most useful if they have a very strong advisory component, as opposed to a very strong action component. We're no longer talking about futzing around with individual methods- you want powerful tools that can rip deeply into a code base and "extract" ( paint, actually ) great tangled masses of inter-related stuff into coherent categories. It's as fun as it sounds!
Since we cannot count on fully automatic fire and forget solutions, but must make use of manually constructed solutions, it would be very nice to store a given configuration ( "paint" scheme ) and then share it and reconstruct it in any given image, even if that image does not neccessarily have the same classes in it. Actually, it would be neccessary. Think of these paint schemes as being meta-programming constructs, and in particular ones that you consider to be no more valuable than Kleenex. Create it, save it, change it, discard it, easily, and without a second thought. Avoid getting locked into any one approach at this point as though it were the plague. It is much worse than that.
Advisory mode off... now back to my regularly scheduled job.
- les
Stephane Ducasse wrote:
This is what I mean: removing unnecessary or stupid dependencies by moving methods around. restructuring the code. This is my business ;)
Well I would be _very_ happy if you would take one being "chief in charge of refactoring the image". In fact, I think there is a vacancy for this position that really needs to be filled! In any case, I would be grateful for comments on my architecture proposal at
http://minnow.cc.gatech.edu/squeak/2057
This need will always be there; I think we will need to carefully choosing "which battles to fight", picking the most important and easiest achieved :-) goals first. So many refactorings, so little time...
sure but we should be able to distribute the work
Hopefully, but the general rule seems to be that the people who are willing to contribute to something are much fewer than those who want to have it.
But the problem is not doing it: the point is having it into the image and controlling the changes that's why these modules are so important. We will be able to work on a part of Squeak and controlling its changes.
What is important after the modules are started is to say to all the brave souls around: "ok if you want to be responsible for something please be and we can organise a kind of peer reviews"
In general I agree. But this won't work before the system has been untagled. Since the system is tangled now, I'm afraid you cannot fix one area, say the compiler or Morphic, without also touching other parts of the system. Like you wrote, untangling Morphic also means changing the compiler, etc etc. So this will be a messy process indeed.
Also, "porting" existing packages to the scheme: Whisker, MathMorphs, RB, Ginsu(!). Although Ginsu may be a little bit harder--I suspect it modifies some of the same parts as this modules system itself.
No there is nothing complex in Ginsu, it modifies nothing just classify them according to some visibility rules. But nobody really looks at it.
I meant that the code of Ginsu itself most likely changes a lot of the same methods that this code does.
There are some things, for example see the Module class, categories "code analysis" and "system conversion"; class ModuleRefactorer and subclasses. This works with the code I already sent out.
ok I will try. Do you have a wiki where I can find the latest version?
The last one I sent out on the list should do, otherwise Dan wants to release something this weekend.
Henrik
Well I would be _very_ happy if you would take one being "chief in charge of refactoring the image".
Just that ;) I'm willing to help sure. My problems is that I read the wiki and still do not understand well what is module for you and all the implications of your design.
From what I read I can say that you provide much more that Ginsu at the
language semantics level. This is fun that you say that this is minimal because there is really nothing in Ginsu. But once you will realize it. You propose more than a packaging organization. This is not a problem.
I have problem to see if keeping changes sets is really the way to go and how deltaModules are related to class extensions and modules them. I will discuss with Andrew to see if we can come up with a common understanding.
In fact, I think there is a vacancy for this position that really needs to be filled! In any case, I would be grateful for comments on my architecture proposal at http://minnow.cc.gatech.edu/squeak/2057
I think that you should discuss with joseph and john if they attend OOPSLA. Because joseph has a lot of experience in this area. Much more than me. ;)
****The key point of the email is here ****** Have you something like in Ginsu that sorts the classes into modules according to a spec? And put apart the methods that violates the visibility? Because like that you can design you modularization and check if this is ok then identify the problems. I think that this is most important point because I think that we should have Squeak3.1 then that people can continue to collect changes, propose bug fixes and in the meantime that we can come up with a cleaner system.
Having tools will help us to reintegrate the changes proposed for Sq3.1 and also the future changes in the future (Sq3.2).
Like in ModSqueak I would use chainsaw design: remove everything big part like Etoy, speech, Alice,....that can be removed first. Then look at the Kernel. Then do a major shrink plus a complete recompilation of the methods and classes is necessary. Fixing the problems there would help to have a clean kernel. the new filelist and SessionManager would definitively help there. I think that you will see that lot of methods are broken. We may ask Jon Sarkela because he found a lot of strange code in the release methods.
All the kernel removed method should be tagged as deprecated. It would be good if we could develop some unit tests per kernel modules. But we should not dream too much.
Ideally I would have been great to get this work sponsored by the squeak foundation. Put in the room a bunch of excellent guys and wait one or two weeks...;) because this would be the best way to do it.
For the modularisation I think that we should take care about the propagation of versions among dependent modules. The idea is that if AV1.1 depends on BV2.3, BV2.3 on C9.0 Then everytimes you change C to a newer version you will have to change all the other versions. So the idea is that the kernel should be more stable and having a different change frequency than the its dependent.
Hopefully, but the general rule seems to be that the people who are willing to contribute to something are much fewer than those who want to have it.
But the problem is not doing it: the point is having it into the image and controlling the changes that's why these modules are so important. We will be able to work on a part of Squeak and controlling its changes.
What is important after the modules are started is to say to all the brave souls around: "ok if you want to be responsible for something please be and we can organise a kind of peer reviews"
In general I agree. But this won't work before the system has been untagled. Since the system is tangled now, I'm afraid you cannot fix one area, say the compiler or Morphic, without also touching other parts of the system. Like you wrote, untangling Morphic also means changing the compiler, etc etc. So this will be a messy process indeed.
That's why we should identify priorities and for example simply remove bad code and tangle thing unnecessarily. I was thinking about this GifReader References and other.
I meant that the code of Ginsu itself most likely changes a lot of the same methods that this code does.
I do not see it. Ginsu does not change code. it organizes it and they built a thin layer that represents declarative code. That's it. No changes for method lookup or whatever. There is no scoping mechanism at the language level. Ginsu is just sorting classes inta bags that can see each other if necessary. But when something is loaded in memory there is no namespace. Ginsu is about packaging code and make sure that onece all the dependent module are loaded your code will work. No more.
ducasse stephane wrote:
I have problem to see if keeping changes sets is really the way to go and how deltaModules are related to class extensions and modules them. I will discuss with Andrew to see if we can come up with a common understanding.
It's more like change sets will be left untouched, they will continue working like they do now.
****The key point of the email is here ****** Have you something like in Ginsu that sorts the classes into modules according to a spec? And put apart the methods that violates the visibility? Because like that you can design you modularization and check if this is ok then identify the problems.
Yes, ModuleRefactorer and subclasses do the sorting. There are also various code analysis methods to analyze how references are made.
Ideally I would have been great to get this work sponsored by the squeak foundation. Put in the room a bunch of excellent guys and wait one or two weeks...;) because this would be the best way to do it.
For the modularisation I think that we should take care about the propagation of versions among dependent modules. The idea is that if AV1.1 depends on BV2.3, BV2.3 on C9.0 Then everytimes you change C to a newer version you will have to change all the other versions. So the idea is that the kernel should be more stable and having a different change frequency than the its dependent.
This sonds very much like what I wrote in my architecture proposal at http://minnow.cc.gatech.edu/squeak/2057, about using an "onion-skin" module architecture for the image.
In general I agree. But this won't work before the system has been untagled. Since the system is tangled now, I'm afraid you cannot fix one area, say the compiler or Morphic, without also touching other parts of the system. Like you wrote, untangling Morphic also means changing the compiler, etc etc. So this will be a messy process indeed.
That's why we should identify priorities and for example simply remove bad code and tangle thing unnecessarily. I was thinking about this GifReader References and other.
Yes indeed, we need priorities. I suggested a few in the above web page.
I meant that the code of Ginsu itself most likely changes a lot of the same methods that this code does.
I do not see it. Ginsu does not change code.
When you load the Ginsu change sets into the image then surely the fileIn modiifies existing methods in the image to make Ginsu work.
Henrik
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
ducasse stephane -
Henrik Gedenryd -
Les Tyrrell -
Stephane Ducasse
-
Thomas Kuehne