Klaus, i would say this is another source version control system.
This bottom up approach is interesting but will not work. Squeakers will continue to use their preferred tools, not your specific browser.
Let's be more pragmatic and have a small incremental bottom up approach.
I see two solutions: - store source code and history in image... I do not believe we should go in this direction even in compressed forms. We are rather making efforts to make images shorter... But you can have other opinion of course. - continue storing source in external repositories (files, URL, NET servers...)
In the later case, we could have many files instead of two (sources changes) and we should be able to have large files: conclusion: let's just change source code pointer encoding.
Using SmallIntegers (30 bits?) we can address 1GByte of space. More if bits are not encoded as file offset but as Oop on a server...
Using two SmallInteger, we have at least 60 bits, 1 ExaByte of data! Let's go for it (count how many compiledMethod are in your image... and you'll see this is not a drama).
Maybe we can have an encoding supporting 1 single SmallInteger for certain patterns (for example it can be sufficient for code stored in 'sources' file, 'sources' file could also be organised with an indirection table instead of using byte offsets...Given average source code length, that can save a factor between 10 and 100 i presume).
We should be able to extend source code being in several places in the future... (several files or URL or ...). So let use change encoding by splitting bits : 20 bits for sourceRegistry offset, 40 bits for file offset, or 30bits/30bits, or both (pattern starting with bits 0001 will be 20/40, all other 30/30 for example).
Then we have to create the SourceRegistry with objects able to handle source code stored in files, in compressed files, on the Net, with all necessary caching to reduce number of connections and design of the source code servers...
However, i would keep the principle of copying changes in the 'changes' file to recover easily in case of image crash, and commiting to another source would still be the responsibility of user, as is now.
Small details: make sure the FileSystem primitives can deal with huge offsets (and also underlying OS of course).
You see, nothing really new, nothing really difficult. With just a little bit more reflexion we can go in this direction and that should be enough for a few years of development and future enhancements...
Nicolas
Klaus D. Witzel:
List,
I put together what I think is relevant for a new source code subsystem and, if I'm mistaken or have overlooked one of your recent suggestions and/or requirements, please do not hesitate and say so.
What follows is not intended as a replacement for MC or SM, rather the new subsystem should be as independent as possible. If you load something with MC, the new subsystem can treat it like any other contribution (more about contributions later).
Trying to keep preliminaries as short as possible, we have as organizational elements (for the sake of discussion): system categories, classes, message categories and methods. The unit of source code "entity" we consider to be a unit of change belongs to one of these elements. We can add, replace, rename and delete. We have not only methods, but also DoIt's (definitions, organizational, etc) to take into account. And let's say that the browser is our tool, just to keep it simple here.
At the time an image is distributed, it is supposed to be in sync (not necessarily *full* sync) with its respective source code subsystem. So when you open a browser, all entities are colored black on white, and my story begins.
When you want to *observe* a certain area of the source code subsytem, you put the respective entity (item from here on) onto your watchlist (cmd+ if you like) from where the item gets the color blue. After putting a class onto your watchlist you get all its message categories and methods blue; un-watch those (sub)items which are of no interest to you; etc for other organizational levels.
When you do a *change* to a blue colored item, its new source is contributed to the source code subsystem (from here on scs for short) and the item is colored green in your browser. If later somebody else contributes a change to the same blue item, it gets the color yellow in both browsers.
And if an entity you have in your image cannot be *matched* with the scs, it is colored red.
As is tradition, if you don't save your image before the next crash, all this coloring information is lost, and you are back to black and white. The scs does NOT know the state of your image.
A contribution to the scs either has a predecessor or else it is new (to the scs). Let's say three developers make contributions to the same blue item, then we arrive at three branches (and the three browsers color the respective item yellow). It is up to you to accept one of these branches, but you are no forced to do so. An accepted branch is colored green (it will turn yellow when the next contribution relative to it arrives).
By chasing the predecessor it is always possible to roll-back an item (or a group of items), this is independent of the coloring I used for illustration. The same "backwards" information is readily available for analyzing the complete history of an item, including all unaccepted branches.
Doing this into the other direction (roll-forward) depends on which branches where accepted. At any point in time, accepted branches represent a "cut" in the scs.
If you work alone on a project, you'll never see any yellow colored item, unless you revert a change (because the dismissed becomes an unaccepted branch). For people who are used to make small incremental changes, a preference tells whether or not every change is treated as a branch or else is to be consolidated until you do a "big save" to the scs. The latter requires, I think, a local buffering scs on your harddisk (or on your local area server).
The amount of conversation between browser and scs is small, the browser only has to ask for colors (one byte answer per item) for those items it shows *and* which are on your watch list. But if you want to see more (like, for example, all branches of an item), more data will have to travel.
It's now time for me to sit back and relax :-)
/Klaus
________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com
Nicolas
thank you for taking the time for a response.
On Wed, 26 Jul 2006 20:55:44 +0200, you wrote:
Klaus, i would say this is another source version control system.
I did not have version *control* in mind but yes, scs could be used for such ancient concepts (used them for > 30 years, quite an experience).
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
This bottom up approach is interesting but will not work. Squeakers will continue to use their preferred tools, not your specific browser.
No specific browser, just colors in the list views of the existing browsers. One or two additional items on the context menus, that's all about it :)
In my imagination you're running 2-3 Squeak images at the same time (on your 2-4GB memory / 2-4 GHz quadruple core notebook, what else would you like to to with your hardware?).
One image in which you do all the "abstract" work, incl. docs (hopefully ;-) the second image for the hard stuff (compile&debug the new project) in the 3rd image you do all the testing; and (perhaps) in the 4th you hunt the nasty bugs left over from the previous project(s).
These images all work with the same source code subsystem, integrity guaranteed. And if you do a mistake in one of the images, the others will not be infected. Now how about this?
Let's be more pragmatic and have a small incremental bottom up approach.
I see two solutions:
- store source code and history in image... I do not believe we should
go in this direction even in compressed forms. We are rather making efforts to make images shorter... But you can have other opinion of course.
- continue storing source in external repositories (files, URL, NET
servers...)
In the later case, we could have many files instead of two (sources changes) and we should be able to have large files: conclusion: let's just change source code pointer encoding.
The source code pointer is only bytes. If a quick solution is needed, why not add just one more byte and take a breath until the then 256 fold limit is reached?
Nicolas, as said above I really appreciate you take care for a response BUT aren't you comparing apples (new source code subsystem) with oranges (one or two byte lengthening of a pointer).
Using SmallIntegers (30 bits?) we can address 1GByte of space. More if bits are not encoded as file offset but as Oop on a server...
Using two SmallInteger, we have at least 60 bits, 1 ExaByte of data! Let's go for it (count how many compiledMethod are in your image... and you'll see this is not a drama).
Maybe we can have an encoding supporting 1 single SmallInteger for certain patterns (for example it can be sufficient for code stored in 'sources' file, 'sources' file could also be organised with an indirection table instead of using byte offsets...Given average source code length, that can save a factor between 10 and 100 i presume).
We should be able to extend source code being in several places in the future... (several files or URL or ...). So let use change encoding by splitting bits : 20 bits for sourceRegistry offset, 40 bits for file offset, or 30bits/30bits, or both (pattern starting with bits 0001 will be 20/40, all other 30/30 for example).
Then we have to create the SourceRegistry with objects able to handle source code stored in files, in compressed files, on the Net, with all necessary caching to reduce number of connections and design of the source code servers...
This sounds easy but relies on the current Changes mechanism which is rotten in the image. Isn't it time to overhaul the framework instead of attaching new pneus with new rims? Buying new rims and pneus from Ferrari (they're just around the corner here :) doesn't buy you a Ferrari ;-)
However, i would keep the principle of copying changes in the 'changes' file to recover easily in case of image crash, and commiting to another source would still be the responsibility of user, as is now.
"to another repository"?
Small details: make sure the FileSystem primitives can deal with huge offsets (and also underlying OS of course).
Sure, must be verified in advance.
You see, nothing really new, nothing really difficult.
Absolutely; adding one more byte to the length of the current source pointer is a matter of minutes (followed by roughly the time it'd take for #condenseChanges and friends).
But will that byte add you productivity, flexibility, reliability, choice, collaborative facilities?
With just a little bit more reflexion we can go in this direction and that should be enough
What a different *one* byte makes :)
for a few years of development and future enhancements...
No. Comparing just the capacity (in bytes) is about quantity, and quality would be ignored (once again, Marcus, you're right with your critique).
The existing source code subsystem is for a one man show, you and your .changes file (regardless where it's stored).
No collaborative work backed by a repository possible, except you do it all manually: on a COMPUTER, of course!
/Klaus
Nicolas
On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
Nicolas
thank you for taking the time for a response.
On Wed, 26 Jul 2006 20:55:44 +0200, you wrote:
Klaus, i would say this is another source version control system.
I did not have version *control* in mind but yes, scs could be used for such ancient concepts (used them for > 30 years, quite an experience).
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
What I would suggest: Do not plan to save the world, at least not at first. If you now set out to build "the solution" we won't have for a looong time, most likely never.
What we need first is
- source offset in a property, not at the end of the bytecode. Use an Integer , so we get indefinite size of .source and .changens -- One Problem Solved. - Fix dan's source compression. This can work on the .changes, too, giving smaller releases or full development deployment for embedded systems (dan it for the weather station) or web servers.
With that, we have solved those problems that started the discussion... quite a step in the right direction.
After that, I personally would continue by cleaning up the sources/ changes handling and fileOut mechanism, thus then enabeling experiments to make something really better. But this "real better" thing is the last step, not the first.
1) fix the real problem 2) clean up / refactor / generalise 3) now invent the future...
Marcus
On Thu, 27 Jul 2006 09:57:24 +0200, Marcus Denker wrote:
On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
What I would suggest: Do not plan to save the world, at least not at first. If you now set out to build "the solution" we won't have for a looong time, most likely never.
What we need first is
- source offset in a property, not at the end of the bytecode. Use
an Integer , so we get indefinite size of .source and .changens -- One Problem Solved.
Wait a minute, a quick question before that can be solved
(nil systemNavigation allMethodsSelect: [:cm | (cm fileIndex = 0 or: [(SourceFiles at: cm fileIndex) == nil]) or: [cm filePosition = 0]])asArray
This has size 204 in #7048, do the elements have anything to do with potential changes to SourceFiles, fileIndex or filePosition?
/Klaus
On 27.07.2006, at 10:47, Klaus D. Witzel wrote:
On Thu, 27 Jul 2006 09:57:24 +0200, Marcus Denker wrote:
On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
What I would suggest: Do not plan to save the world, at least not at first. If you now set out to build "the solution" we won't have for a looong time, most likely never.
What we need first is
- source offset in a property, not at the end of the bytecode. Use
an Integer , so we get indefinite size of .source and .changens -- One Problem Solved.
Wait a minute, a quick question before that can be solved
(nil systemNavigation allMethodsSelect: [:cm | (cm fileIndex = 0 or: [(SourceFiles at: cm fileIndex) == nil]) or: [cm filePosition = 0]])asArray
This has size 204 in #7048, do the elements have anything to do with potential changes to SourceFiles, fileIndex or filePosition?
These are generated methods without source. The source you see when looking at them is the result of a decompilation. (see e.g Preferences class>>#compileAccessMethodForPreference: ). Used for Preferences, Services and in some old stuff, PlayWithMe1 should be removed...).
CompiledMethod>>#getSourceFor: selector in: class "Retrieve or reconstruct the source code for this method." | source flagByte sourceSelector | flagByte _ self last. (flagByte = 0 or: [flagByte = 251 "some source-less methods have flag = 251, rest = 0" and: [((1 to: 3) collect: [:i | self at: self size - i]) = #(0 0 0)]]) ifTrue: ["No source pointer -- decompile without temp names" ^ self decompileString]. ......
Marcus
The 204 methods without sourcePointer in #7048 are from
BrowserProvider WorldMenuProvider PlayWithMe1 PlayWithMe1 class Preferences class
Marcus, can that be fixed (fileIn from some source/package) in the next to come image.
If anybody has up-to-date sources for the above which are not in SqSource or on SqMap would you please make them available, thank you.
/Klaus
On Thu, 27 Jul 2006 10:47:29 +0200, Klaus D. Witzel klaus.witzel@cobss.com wrote:
On Thu, 27 Jul 2006 09:57:24 +0200, Marcus Denker wrote:
On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
What I would suggest: Do not plan to save the world, at least not at first. If you now set out to build "the solution" we won't have for a looong time, most likely never.
What we need first is
- source offset in a property, not at the end of the bytecode. Use
an Integer , so we get indefinite size of .source and .changens -- One Problem Solved.
Wait a minute, a quick question before that can be solved
(nil systemNavigation allMethodsSelect: [:cm | (cm fileIndex = 0 or: [(SourceFiles at: cm fileIndex) == nil]) or: [cm filePosition = 0]])asArray
This has size 204 in #7048, do the elements have anything to do with potential changes to SourceFiles, fileIndex or filePosition?
/Klaus
On 27.07.2006, at 11:36, Klaus D. Witzel wrote:
The 204 methods without sourcePointer in #7048 are from
BrowserProvider WorldMenuProvider PlayWithMe1 PlayWithMe1 class Preferences class
Marcus, can that be fixed (fileIn from some source/package) in the next to come image
No, these methods are generated, there was never code for them. We need to be able to support code-less methods... even if it is very bad style, IMHO.
Marcus
Hi Marcus,
on Thu, 27 Jul 2006 11:40:37 +0200, you denker@iam.unibe.ch wrote:
On 27.07.2006, at 11:36, Klaus D. Witzel wrote:
The 204 methods without sourcePointer in #7048 are from
BrowserProvider WorldMenuProvider PlayWithMe1 PlayWithMe1 class Preferences class
Marcus, can that be fixed (fileIn from some source/package) in the next to come image
No, these methods are generated, there was never code for them.
Filed the classes out, no problem seen (doesn't say much, as we still have no consensus on aCompiledMethod>>#= for compiling the fileOut and doing a = for comparision with the in-image methods ;-)
We need to be able to support code-less methods... even if it is very bad style, IMHO.
Yes, must support them.
But how about Decompiler [which is involved during fileOut ( = source code move) of sourceless methods]? Would you trust Decompiler in the light of its bugs?
/Klaus
Marcus
Marcus Denker wrote:
- source offset in a property, not at the end of the bytecode. Use an
Integer , so we get indefinite size of .source and .changens -- One Problem Solved.
in a smalltalk system far away a full object was used for pointing to the source. That object would normally be a source and file index, allowing for unlimited number of source files. That was used in the AppMan package that kept the package specific source in package source files. So installing a package did not add any entries to the changes file. But, that source object could also be an object answering the compressed source, a repository access or whatever smart way you could come up with.
Michael
I have to draw the attention to the next one perspective. If we want to have future versions of Squeak based on some small UI-less minimal image, we will have got quite small sources file, big changes and we will lose history information (we will have versions of individual packages). The question is if we want to have compression in the kernel image (to support the compressed sources).
-- Pavel
On 7/27/06, Marcus Denker denker@iam.unibe.ch wrote:
On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
Nicolas
thank you for taking the time for a response.
On Wed, 26 Jul 2006 20:55:44 +0200, you wrote:
Klaus, i would say this is another source version control system.
I did not have version *control* in mind but yes, scs could be used for such ancient concepts (used them for > 30 years, quite an experience).
No, I was lead by the aim for more collaborative features (hmm, since there are none in Squeak, should I say for *at least* one or two collaborative features).
What I would suggest: Do not plan to save the world, at least not at first. If you now set out to build "the solution" we won't have for a looong time, most likely never.
What we need first is
- source offset in a property, not at the end of the bytecode. Use
an Integer , so we get indefinite size of .source and .changens -- One Problem Solved.
- Fix dan's source compression. This can work on the .changes, too,
giving smaller releases or full development deployment for embedded systems (dan it for the weather station) or web servers.
With that, we have solved those problems that started the discussion... quite a step in the right direction.
After that, I personally would continue by cleaning up the sources/ changes handling and fileOut mechanism, thus then enabeling experiments to make something really better. But this "real better" thing is the last step, not the first.
fix the real problem
clean up / refactor / generalise
now invent the future...
Marcus
Pavel Krivanek puso en su mail :
I have to draw the attention to the next one perspective. If we want to have future versions of Squeak based on some small UI-less minimal image, we will have got quite small sources file, big changes and we will lose history information (we will have versions of individual packages). The question is if we want to have compression in the kernel image (to support the compressed sources).
Yes, you need it at some point.
Could have a minimal support for gz only , not for all kinds of compression.
I do test for .sources and .gz and is almost the same size as Dan trick and your could load .sources.gz or .changes.gz and keep in RWBinaryOrTextStream on startUp for later use.
Again , wonderful job, still trying to understand all .
To masters, we need a special "kernel folder" in ftp site , as now we have one for Spoon
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On Thu, 27 Jul 2006 13:15:11 +0200, Pavel Krivanek wrote:
I have to draw the attention to the next one perspective. If we want to have future versions of Squeak based on some small UI-less minimal image, we will have got quite small sources file, big changes and we will lose history information (we will have versions of individual packages). The question is if we want to have compression in the kernel image (to support the compressed sources).
+1 a GUI-less (or small-GUI) image will most likely access compressed contents, for various reasons.
/Klaus
Pavel Krivanek writes:
I have to draw the attention to the next one perspective. If we want to have future versions of Squeak based on some small UI-less minimal image, we will have got quite small sources file, big changes and we will lose history information (we will have versions of individual packages). The question is if we want to have compression in the kernel image (to support the compressed sources).
Are there any plans to use your small image as the official base image? Using a small base image then importing externally supported packages should make image maintenence much easier as there will be less code. Is this a good time to burn bridges to move forward to a more modular future?
Sure there's a risk that we might drop code, but code that isn't maintained will rot inside the image as well as outside. If people know that packages will be gone unless they do something, there is a chance that they will step forward knowing the stakes even though they might not have volunteered if the code was in the image rotting slowly through lack of attention.
Bryce
Are there any plans to use your small image as the official base image? Using a small base image then importing externally supported packages should make image maintenence much easier as there will be less code. Is this a good time to burn bridges to move forward to a more modular future?
Good question. Version 3.9 is in the final stage and I think that Stef, Marcus, Cees, Craig, Bert, Tim and Yoshiki should set the plan for 3.10 - goals and priorities.
Stef declared that he wants to burn bridges in this version.
We want to have Squeak free and modular and there are three possible starting points. The free version One, Craig's Spoon and the image of mine.
I wanted to show that my way is the right one. We have some GUI-less image with SUnit tests, we are able to run Seaside applications and we are able to load the rest of current Squeak sources and run Morphic.
Unfortunately there's almost nobody who can maintain the next release. And if we will create the basic kernel imege, there will be no human resources to unify it as the base for the current Squeak forks.
-- Pavel
Pavel Krivanek puso en su mail :
Unfortunately there's almost nobody who can maintain the next release. And if we will create the basic kernel imege, there will be no human resources to unify it as the base for the current Squeak forks.
-- Pavel
I see your way is better. Could elaborate about the above what you write ?
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 7/28/06, Lic. Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
Pavel Krivanek puso en su mail :
Unfortunately there's almost nobody who can maintain the next release. And if we will create the basic kernel imege, there will be no human resources to unify it as the base for the current Squeak forks.
-- Pavel
I see your way is better. Could elaborate about the above what you write ?
Pardon, could who? I know, Spanish must not use articles :-)
-- Pavel
Pavel Krivanek puso en su mail :
Sorry my bad English.
Unfortunately there's almost nobody who can maintain the next release.
Why ? You don't work more on kernel.image ?
And if we will create the basic kernel image, there will be no human resources to unify it as the base for the current Squeak forks.
Again why?.
You have a killer solution and people soon discover this is a good one to follow and work.
You could lead a kernel.image team.
I sign for it if my Spanish don't bother you :=)
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
Unfortunately there's almost nobody who can maintain the next release.
Why ? You don't work more on kernel.image ?
AFIK Marcus have no time for maintaining of the next Squeak version and I don't expect that anybody will be able to substitute him. So we have to modify current development model to make it more independent on this bottleneck or Squeak will freeze up. Establishing of teams helped a lot but it seems that it is still not enough.
IMHO we simply need to split Squeak in many small packages and use very open development model (like Seaside) for every of them. If more people will use the latest versions, the feedback will be much more intensive. Then we need some kind of test server that will produce and test daily builds.
Of course that I still want to work on the kernel image. But there are some very important projects that I want to see and where I may be more useful - for example fully web-based Smalltalk IDE - it's possible to make it as usable as native IDE with current web technologies and users will get flexible multi-user UI with standard feel.
And if we will create the basic kernel image, there will be no human resources to unify it as the base for the current Squeak forks.
Again why?.
Look at the current state. We have the draft of the kernel. We have few basic packages and a way how to load the rest of full Squeak sources. I can imagine that we will be able to clean the kernel, I can imagine that we will have good network and Seaside part. Maybe we will be able to run development tools in Morphic but I don't expect that we will be able to have Morphic and eToys as the regular clean packages. There will be no human resources to do it.
If you look at the current package The Rest of Squeak, it's big ugly package with many confused relationships because current Squeak looks so. So maybe some other UI like wxSqueak will replace Morphic for developers and it will be in the same possition like MVC today. In future it may paradoxicaly cause beginning of the next Squeak fork based on the old Squeak.
You have a killer solution and people soon discover this is a good one to follow and work.
You could lead a kernel.image team.
"If asked if he wants to be Prime Minister, the generally acceptable answer for a politician is that while he does not seek the office, he has pledged himself to the service of his country, and that should his colleagues persuade him that that is the best way he can serve, he might reluctantly have to accept the responsibility, whatever his personal wishes might be." ;-)
I think that it's too big responsibility for one man, especially if the man is me :-)
I sign for it if my Spanish don't bother you :=)
Welcome on board :-)
-- Pavel
On 28 juil. 06, at 08:43, Pavel Krivanek wrote:
Are there any plans to use your small image as the official base image? Using a small base image then importing externally supported packages should make image maintenence much easier as there will be less code. Is this a good time to burn bridges to move forward to a more modular future?
Good question. Version 3.9 is in the final stage and I think that Stef, Marcus, Cees, Craig, Bert, Tim and Yoshiki should set the plan for 3.10 - goals and priorities.
I'm not that this is the role of the foundation.
Stef declared that he wants to burn bridges in this version.
At least I do not want to work on 3.10 for something that have such too much strings attached. However this is really important to make sure that people can work with it. So I would start to discarding a lot more of rotten code.
We want to have Squeak free and modular and there are three possible starting points. The free version One, Craig's Spoon and the image of mine.
I wanted to show that my way is the right one. We have some GUI-less image with SUnit tests, we are able to run Seaside applications and we are able to load the rest of current Squeak sources and run Morphic.
Excellent start.
Unfortunately there's almost nobody who can maintain the next release.
Exact!
And if we will create the basic kernel imege, there will be no human resources to unify it as the base for the current Squeak forks.
This is why I always propose you that we join effort. And that we push step by step part of what you did into the next version.
On 28.07.2006, at 08:43, Pavel Krivanek wrote:
Are there any plans to use your small image as the official base image? Using a small base image then importing externally supported packages should make image maintenence much easier as there will be less code. Is this a good time to burn bridges to move forward to a more modular future?
Good question. Version 3.9 is in the final stage and I think that
3.9 should be shipped ASAP. I don't want to wait for anything. That what is 7048 can be considered to be 3.9
So 3.9 is in hard beta, which means that I don't think we should wait for anything and especially not now start to do big changes. We had over a year for big changes, and now that's over.
Stef, Marcus, Cees, Craig, Bert, Tim and Yoshiki should set the plan for 3.10 - goals and priorities.
Stef declared that he wants to burn bridges in this version.
We want to have Squeak free and modular and there are three possible starting points. The free version One, Craig's Spoon and the image of mine.
I wanted to show that my way is the right one. We have some GUI-less image with SUnit tests, we are able to run Seaside applications and we are able to load the rest of current Squeak sources and run Morphic.
Unfortunately there's almost nobody who can maintain the next release.
I personally plan to be not involved at all after 3.9 ships.
Marcus
Are there any plans to use your small image as the official base image?
Not for now. We will not take the responsibility for work we did not cary. Now if Pavel wants he can - publish a small kernel that people can use - chunk his changes so that we can push them in 3.10
Using a small base image then importing externally supported packages should make image maintenence much easier as there will be less code. Is this a good time to burn bridges to move forward to a more modular future?
after 3.9 :)
Sure there's a risk that we might drop code, but code that isn't maintained will rot inside the image as well as outside. If people know that packages will be gone unless they do something, there is a chance that they will step forward knowing the stakes even though they might not have volunteered if the code was in the image rotting slowly through lack of attention.
I would go first in 3.10 for a first round of dropping code that needs to be dropped: Etoy, MVC, morphic parts and more.
Then...
Bryce
On Thu, 27 Jul 2006 09:57:24 +0200, Marcus Denker wrote: ...
What we need first is
- source offset in a property, not at the end of the bytecode.
Done. Would some good soul please explain why the file index bits are at the left of the current sourcePointer (need no explanation for the bytes at the end of the bytecode, just about the intention for the encoding).
Especially, does the current sourcePointer encoding support other than the TWO existing SourceFiles? If not, that would make migration easier.
Use an Integer , so we get indefinite size of .source and .changens --
It now has (SmallInteger maxVal bitShift: -1) for position and one bit for file index. This gives 512MB capacity (16 fold) for the moment.
The transformation is {already} factored in StandardSourceFileArray, so any change (for example to an oop) will be a piece of cake.
One Problem Solved.
After all the tests pass :)
/Klaus
it would be nice to really see something like that happening.
Stef
Klaus, i would say this is another source version control system.
This bottom up approach is interesting but will not work. Squeakers will continue to use their preferred tools, not your specific browser.
Let's be more pragmatic and have a small incremental bottom up approach.
I see two solutions:
- store source code and history in image... I do not believe we
should go in this direction even in compressed forms. We are rather making efforts to make images shorter... But you can have other opinion of course.
- continue storing source in external repositories (files, URL,
NET servers...)
In the later case, we could have many files instead of two (sources changes) and we should be able to have large files: conclusion: let's just change source code pointer encoding.
Using SmallIntegers (30 bits?) we can address 1GByte of space. More if bits are not encoded as file offset but as Oop on a server...
Using two SmallInteger, we have at least 60 bits, 1 ExaByte of data! Let's go for it (count how many compiledMethod are in your image... and you'll see this is not a drama).
Maybe we can have an encoding supporting 1 single SmallInteger for certain patterns (for example it can be sufficient for code stored in 'sources' file, 'sources' file could also be organised with an indirection table instead of using byte offsets...Given average source code length, that can save a factor between 10 and 100 i presume).
We should be able to extend source code being in several places in the future... (several files or URL or ...). So let use change encoding by splitting bits : 20 bits for sourceRegistry offset, 40 bits for file offset, or 30bits/30bits, or both (pattern starting with bits 0001 will be 20/40, all other 30/30 for example).
Then we have to create the SourceRegistry with objects able to handle source code stored in files, in compressed files, on the Net, with all necessary caching to reduce number of connections and design of the source code servers...
However, i would keep the principle of copying changes in the 'changes' file to recover easily in case of image crash, and commiting to another source would still be the responsibility of user, as is now.
Small details: make sure the FileSystem primitives can deal with huge offsets (and also underlying OS of course).
You see, nothing really new, nothing really difficult. With just a little bit more reflexion we can go in this direction and that should be enough for a few years of development and future enhancements...
Nicolas
Klaus D. Witzel:
List,
I put together what I think is relevant for a new source code subsystem and, if I'm mistaken or have overlooked one of your recent suggestions and/or requirements, please do not hesitate and say so.
What follows is not intended as a replacement for MC or SM, rather the new subsystem should be as independent as possible. If you load something with MC, the new subsystem can treat it like any other contribution (more about contributions later).
Trying to keep preliminaries as short as possible, we have as organizational elements (for the sake of discussion): system categories, classes, message categories and methods. The unit of source code "entity" we consider to be a unit of change belongs to one of these elements. We can add, replace, rename and delete. We have not only methods, but also DoIt's (definitions, organizational, etc) to take into account. And let's say that the browser is our tool, just to keep it simple here.
At the time an image is distributed, it is supposed to be in sync (not necessarily *full* sync) with its respective source code subsystem. So when you open a browser, all entities are colored black on white, and my story begins.
When you want to *observe* a certain area of the source code subsytem, you put the respective entity (item from here on) onto your watchlist (cmd+ if you like) from where the item gets the color blue. After putting a class onto your watchlist you get all its message categories and methods blue; un-watch those (sub)items which are of no interest to you; etc for other organizational levels.
When you do a *change* to a blue colored item, its new source is contributed to the source code subsystem (from here on scs for short) and the item is colored green in your browser. If later somebody else contributes a change to the same blue item, it gets the color yellow in both browsers.
And if an entity you have in your image cannot be *matched* with the scs, it is colored red.
As is tradition, if you don't save your image before the next crash, all this coloring information is lost, and you are back to black and white. The scs does NOT know the state of your image.
A contribution to the scs either has a predecessor or else it is new (to the scs). Let's say three developers make contributions to the same blue item, then we arrive at three branches (and the three browsers color the respective item yellow). It is up to you to accept one of these branches, but you are no forced to do so. An accepted branch is colored green (it will turn yellow when the next contribution relative to it arrives).
By chasing the predecessor it is always possible to roll-back an item (or a group of items), this is independent of the coloring I used for illustration. The same "backwards" information is readily available for analyzing the complete history of an item, including all unaccepted branches.
Doing this into the other direction (roll-forward) depends on which branches where accepted. At any point in time, accepted branches represent a "cut" in the scs.
If you work alone on a project, you'll never see any yellow colored item, unless you revert a change (because the dismissed becomes an unaccepted branch). For people who are used to make small incremental changes, a preference tells whether or not every change is treated as a branch or else is to be consolidated until you do a "big save" to the scs. The latter requires, I think, a local buffering scs on your harddisk (or on your local area server).
The amount of conversation between browser and scs is small, the browser only has to ask for colors (one byte answer per item) for those items it shows *and* which are on your watch list. But if you want to see more (like, for example, all branches of an item), more data will have to travel.
It's now time for me to sit back and relax :-)
/Klaus
__ iFRANCE, exprimez-vous ! http://web.ifrance.com
squeak-dev@lists.squeakfoundation.org
-
Bryce Kampjes -
Klaus D. Witzel -
Lic. Edgar J. De Cleene -
Marcus Denker -
Michael Rueger -
ncellier＠ifrance.com -
Pavel Krivanek -
stéphane ducasse