I'm trying to learn VMMaker and create a total Unix VM from scratch. I see that I need to first assign plugins to be either Internal or External in the VMMakerTool. And, if a plugin is not assigned, make errors may result. (errors depends on if the class exists or not? Is that right?)
I hope this is right.
Where do I find each plugins "normal" configuration state? (configuration state = internal OR external) I couldn't find this on the swiki or email.
Or, am I way off base here.
thanks,
brad
Hi Brad--
Where do I find each plugins "normal" configuration state? (configuration state = internal OR external)
I don't think there is such a thing. This is just a choice you make yourself based on logistics. E.g., if you're likely to want to rebuild a plugin separately, without having to create a whole new VM (or even stopping the currently running one) then "external" is a good choice. Generally, people either make them all internal or all external.
-C
Craig Latta wrote:
Hi Brad--
Where do I find each plugins "normal" configuration state? (configuration state = internal OR external)
I don't think there is such a thing. This is just a choice youmake yourself based on logistics. E.g., if you're likely to want to rebuild a plugin separately, without having to create a whole new VM (or even stopping the currently running one) then "external" is a good choice. Generally, people either make them all internal or all external.
Hey Craig (how ya doing?)
What's the default? There's got to be a shipped default. Right?
Craig Latta wrote:
Hi Brad--
Where do I find each plugins "normal" configuration state? (configuration state = internal OR external)
I don't think there is such a thing. This is just a choice youmake yourself based on logistics. E.g., if you're likely to want to rebuild a plugin separately, without having to create a whole new VM (or even stopping the currently running one) then "external" is a good choice. Generally, people either make them all internal or all external.
One thing that'll clear up my question: I'm referring to all the plugins in the SVN . I'm just trying to build the default to get my feet wet.
I've moved most primitives to external, (some seem to be required to be Internal.) And I've generated all.
Now my problem is that make fails -- interp.h seems to be missing - or - it's not created (email references are not decisive.). I've found several recent emails confusing me (which, is easy to do): One where Ross Boylan has moved the generated source dir to src from src32 and compilation was successful (don't know why that would make a difference) Another where Alan Grimes states that interp.h is not on the SVN (which seems to indicate that it is not created). Still another where Sachin Desai says that interp.h is not created and that he creates it by hand to get things working (which implies that he thinks it ought to be created by VMTool.)
Some plugins will generate an error when placed in either the external or internal list (BalloonEnginePlugin is one). And FFIPlugin, B3DAcceleratorPlugin and B3DEnginePlugin will generate a walkback if placed as an External (I made these Internal for it to work.)
So, I guess my question is: what's up with interp.h? Where do I get it to get past this error?
brad
If you're trying to build off of svn head on Unix, you've got an adventure. In some of my earlier messages I laid out the exact steps I had to follow (as well as many false starts). My build procedure included getting a special VMMaker, applying some patches, and other contortions. The changes related to garbage collection grew out of my particular interest in that area, but the rest were just to get it to compile and run.
Also, to clarify, when I changed to src from src32 I did so in the VMMaker tool. I'm not sure if simply renaming the directory is sufficient.
Ross
Ross Boylan wrote:
If you're trying to build off of svn head on Unix, you've got an adventure. In some of my earlier messages I laid out the exact steps I had to follow (as well as many false starts). My build procedure included getting a special VMMaker, applying some patches, and other contortions. The changes related to garbage collection grew out of my particular interest in that area, but the rest were just to get it to compile and run.
What special VMMaker did you use? I'm using the latest 3.8 squeak
Also, to clarify, when I changed to src from src32 I did so in the VMMaker tool. I'm not sure if simply renaming the directory is sufficient.
I did change the dir in VMMaker Tool, but it made no difference. Also, I do see that interp.h is in the unix/src32/vm directory but not in the unix/src//vm dir. I copied it over, but that didn't make build run either -- it still couldn't find it. The build stops at vm/vm.a
I'll search more for your emails and see if I can piece together your troubles. From your email, it sounds like it's rather difficult to put together the vm at this point. Is that because it's in a state of flux re: 64-bit work?
thanks for the reply, brad
On Fri, Aug 26, 2005 at 09:16:25PM -0700, Brad Fuller wrote:
Ross Boylan wrote:
If you're trying to build off of svn head on Unix, you've got an adventure. In some of my earlier messages I laid out the exact steps I had to follow (as well as many false starts). My build procedure included getting a special VMMaker, applying some patches, and other contortions. The changes related to garbage collection grew out of my particular interest in that area, but the rest were just to get it to compile and run.
What special VMMaker did you use? I'm using the latest 3.8 squeak
VMMaker-tpr.37, which I got from Tim Rowledge's site: http://www.rowledge.org/tim/squeak/SqFiles/packages/VMMaker/
as described in http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-July/093172.html
That's in the earlier (July) threads "memory and VM issues."
Also, to clarify, when I changed to src from src32 I did so in the VMMaker tool. I'm not sure if simply renaming the directory is sufficient.
I did change the dir in VMMaker Tool, but it made no difference. Also, I do see that interp.h is in the unix/src32/vm directory but not in the unix/src//vm dir. I copied it over, but that didn't make build run either -- it still couldn't find it. The build stops at vm/vm.a
I'll search more for your emails and see if I can piece together your troubles.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/093783.ht... gives the success recipe. Most of the steps are in the earlier message that this one quotes.
From your email, it sounds like it's rather difficult to put together the vm at this point. Is that because it's in a state of flux re: 64-bit work?
Yes. There may be other work going on too.
Another route is to attempt to build off a known good state, rather than the leading edge. You could start with one of the Unix tarballs, for example.
thanks for the reply, brad
On Fri, Aug 26, 2005 at 03:36:35PM -0700, Brad Fuller wrote:
I'm trying to learn VMMaker and create a total Unix VM from scratch. I see that I need to first assign plugins to be either Internal or External in the VMMakerTool. And, if a plugin is not assigned, make errors may result. (errors depends on if the class exists or not? Is that right?)
Hi Brad,
If you are trying to build a VM for the first time, I suggest that you use the source code package from Ian's web site rather than the SVN sources, and that you use the VMMaker from SqueakMap. This will give you a good VM without all the "gotchas" involved in the bleeding edge sources. Once you have that working, and if that has not yet satisfied your appetite for aggrivation, then you can try building from the latest SVN sources and VMMaker.
As far as your internal vs. external question, in most cases it does not matter. But just to give you a guideline, I am currently building everything internally except for the following plugins:
UnixOSProcessPlugin XDisplayControlPlugin AllocationLoggingPlugin AioPlugin
These four are "extras" that are not necessary for a working VM. I also do development work on some of them, so it makes sense to build them externally to avoid rebuilding the whole VM when I change something.
Dave
David T. Lewis wrote:
On Fri, Aug 26, 2005 at 03:36:35PM -0700, Brad Fuller wrote:
I'm trying to learn VMMaker and create a total Unix VM from scratch. I see that I need to first assign plugins to be either Internal or External in the VMMakerTool. And, if a plugin is not assigned, make errors may result. (errors depends on if the class exists or not? Is that right?)
Hi Brad,
If you are trying to build a VM for the first time, I suggest that you use the source code package from Ian's web site rather than the SVN sources, and that you use the VMMaker from SqueakMap. This will give you a good VM without all the "gotchas" involved in the bleeding edge sources. Once you have that working, and if that has not yet satisfied your appetite for aggrivation, then you can try building from the latest SVN sources and VMMaker.
I should state the obvious: Why is the bleeding edge source in the trunk? Why hasn't that been branched off? I expected the stable version to be in the trunk, not the working copies.
Or, am I missing something here?
Going to Ian's source will just complicate matters and doesn't guarantee source code consistency. Now there are two source trees.
Re: VMMaker. I'm using the VMMaker that is included with 3.8Full. I'll check out the notes in SqueakMap, but is it different? Is it new and improved? Is it the special VMMaker you mentioned in the last msg? (and also the patches you mentioned?)
As far as your internal vs. external question, in most cases it does not matter. But just to give you a guideline, I am currently building everything internally except for the following plugins:
UnixOSProcessPlugin XDisplayControlPlugin AllocationLoggingPlugin AioPlugin
These four are "extras" that are not necessary for a working VM. I also do development work on some of them, so it makes sense to build them externally to avoid rebuilding the whole VM when I change something.
I appreciate your help, Dave. I'll check it out.
brad
On Sat, Aug 27, 2005 at 12:07:02PM -0700, Brad Fuller wrote:
I should state the obvious: Why is the bleeding edge source in the trunk? Why hasn't that been branched off? I expected the stable version to be in the trunk, not the working copies.
Having development at the head seems like pretty standard practice to me.
Or, am I missing something here?
Going to Ian's source will just complicate matters and doesn't guarantee source code consistency. Now there are two source trees.
Ian's source code is internally consistent: it builds. Presumably it is externally consistent with the svn sources and the image as of some date. It might have additional patches (I'm not familiar with the details). It has the advantage of being known to build.
Re: VMMaker. I'm using the VMMaker that is included with 3.8Full. I'll check out the notes in SqueakMap, but is it different? Is it new and improved? Is it the special VMMaker you mentioned in the last msg? (and also the patches you mentioned?)
The VMMaker I used to build was different and more bleeding edge, to go with the bleeding edge sources.
On Saturday 27 August 2005 01:25 pm, Ross Boylan wrote:
On Sat, Aug 27, 2005 at 12:07:02PM -0700, Brad Fuller wrote:
I should state the obvious: Why is the bleeding edge source in the trunk? Why hasn't that been branched off? I expected the stable version to be in the trunk, not the working copies.
Having development at the head seems like pretty standard practice to me.
In my experience, it is common for the trunk to be the released/stable version and branches to be work in progress. Individuals or groups can work on a branch independently, do their own testing, etc. and then merge back to trunk when testing is complete and everyone agrees that the particular branch (or portions) is now the stable version. The squeak group is informal, so I don't believe more formal mgmt is needed.
What I would suggest is that the known, agreed, stable source for 3.7 (maybe that's the tarball at Ian's) is placed in a new trunk. Then a branch or branches can be created that contain the current work of others. This may or may not go down well with others, but it guarantees that someone can grab the current trunk, build and they get the same result as what has been released.
Or, am I missing something here?
Going to Ian's source will just complicate matters and doesn't guarantee source code consistency. Now there are two source trees.
Ian's source code is internally consistent: it builds. Presumably it is externally consistent with the svn sources and the image as of some date. It might have additional patches (I'm not familiar with the details). It has the advantage of being known to build.
I would suggest that we need agreement from those who know that file: Squeak-3.7-7.src.tar.gz (I assume) is "the" last known good stable source.
Then, we need to find the other platform vm sources to create the stable trunk (I need these eventually, too) It might be that the current trunk is pretty close already. I don't know.
But, IMO, the trunk should build and work, period. People shouldn't have to be hunting down this or that to get it to build. And, the build should be identical to the currently released version of squeak.
Re: VMMaker. I'm using the VMMaker that is included with 3.8Full. I'll check out the notes in SqueakMap, but is it different? Is it new and improved? Is it the special VMMaker you mentioned in the last msg? (and also the patches you mentioned?)
The VMMaker I used to build was different and more bleeding edge, to go with the bleeding edge sources.
Brad Fuller wrote:
On Saturday 27 August 2005 01:25 pm, Ross Boylan wrote:
Having development at the head seems like pretty standard practice to me.
In my experience, it is common for the trunk to be the released/stable version and branches to be work in progress. Individuals or groups can work on a branch independently, do their own testing, etc. and then merge back to trunk when testing is complete and everyone agrees that the particular branch (or portions) is now the stable version. The squeak group is informal, so I don't believe more formal mgmt is needed.
What I would suggest is that the known, agreed, stable source for 3.7 (maybe that's the tarball at Ian's) is placed in a new trunk. Then a branch or branches can be created that contain the current work of others.
This may or may not go down well with others, but it guarantees that someone can grab the current trunk, build and they get the same result as what has been released.
Different groups have different styles of work and we (the VM maintainers) have long adopted a style which does not assume that HEAD is always the latest stable version but rather provide explicit file releases. The main reasons being that there is no conceptual difference between checking out HEAD or using a stable file release and to allow us to move forward so that we know the order in which pending changes get integrated. This is in particular important since the main ports have maintainers with very different schedules and requiring everyone to get in sync before allowing to make a change to the trunk would probably deadlock the entire group.
I would suggest that we need agreement from those who know that file: Squeak-3.7-7.src.tar.gz (I assume) is "the" last known good stable source.
I would suggest that you take the discussion to VM-dev if you want any resolution.
Then, we need to find the other platform vm sources to create the stable trunk (I need these eventually, too)
Win32: http://squeak.hpl.hp.com/win32/release/Squeak-Win32-3.7.1-src.zip
It might be that the current trunk is pretty close already. I don't know.
For Windows, no. I still haven't gotten around to update the VM sources to 3.8 - in other words if we would follow your proposed model the trunk would be stuck at 3.7 which I would find an extremely unpleasant situation.
But, IMO, the trunk should build and work, period. People shouldn't have to be hunting down this or that to get it to build. And, the build should be identical to the currently released version of squeak.
The only reliable form to get a guarantueed version of the VM is (and has always been, back to '96) to get a file release (tar ball) containing everything that has been used to build the VM you are using. The versions change, mind you and having HEAD apply to whatever-the-latest doesn't help you one bit if you don't use whatever-the-latest. With file releases you get *exactly* everything the maintainer has been using for the VM you are using and you even know when a maintainer hasn't done whatever-the-latest; such as the absence of a 3.8 Windows VM. Put differently, if you ever have a problem with the 3.2.1 Windows VM you go grab http://squeak.hpl.hp.com/win32/release/Squeak-Win32-3.2.1-src.zip and get *exactly* the sources that have been used for the VM you are running, period. AFAIK, Ian has generally been following the same policy.
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are. They work for us. And If you think we're all morons who don't know Jack you are of course free to set up an alternative repository and show the superiority of your ways. We'll discuss the results in 2015 ;-)
Cheers, - Andreas
Andreas Raab schrieb:
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
But, it also makes it incredibly hard for people outside that exclusive circle to participate. If you force people to use file releases instead of a shared repository there can be no meaningful community participation in the process. For instance, if people would like to explore the recently submitted alternate unix socket implementation they need to send around files instead of pointing people to branch XYZ of the repository.
And, certain VM platform versions have lagged for months in the past as there are single person responsibilities.
Michael
Michael Rueger wrote:
Andreas Raab schrieb:
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
But, it also makes it incredibly hard for people outside that exclusive circle to participate. If you force people to use file releases instead of a shared repository there can be no meaningful community participation in the process. For instance, if people would like to explore the recently submitted alternate unix socket implementation they need to send around files instead of pointing people to branch XYZ of the repository.
And, certain VM platform versions have lagged for months in the past as there are single person responsibilities.
plus, I feel I've stepped on toes (didn't mean to) and the line in the sand is drawn deeper.
brad
Michael Rueger wrote:
Andreas Raab schrieb:
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
But, it also makes it incredibly hard for people outside that exclusive circle to participate. If you force people to use file releases instead of a shared repository there can be no meaningful community participation in the process.
I do not force people to use anything. I tell them that "If you want a build that is known to work, you should use a file release. If you are up to a sometimes somewhat bumpy ride feel free to use the repository directly."
For most people such a setup is vastly advantageous since they get a version that's known to build and can put their development on top of that. Which gives us the ability to diff and compare against a known version, (hopefully) making it easier to integrate the changes.
For instance, if people would like to explore the recently submitted alternate unix socket implementation they need to send around files instead of pointing people to branch XYZ of the repository.
Commit rights for everyone? I don't think that'll happen.
And, certain VM platform versions have lagged for months in the past as there are single person responsibilities.
True for Windows at this point. So what do you propose to change?
Cheers, - Andreas
Sounds to me like you're using a too restrictive version management system. If you were using MC (which of course is not actually applicable to C code, without some serious extension work) you would be able to: 1. each manage your own versions as you like 2. allow other people to have branched repositories of their own, merging with the main platform maintainers at convenience. 3. If someone wants his tree to mean something different (head is development, head is last release, head is stable but with some new patches), they can do so with minimal work. 4. Having a lower barrier to entry, you might in a while have more people helping out with various platforms, and you don't have to work with them until they know enough to be useful.
So you need a distributed CVS. Arch? darcs? heck, maybe even SVN can handle this, I don't know. Anyway, just an idea.
Daniel
Andreas Raab wrote:
Michael Rueger wrote:
Andreas Raab schrieb:
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
But, it also makes it incredibly hard for people outside that exclusive circle to participate. If you force people to use file releases instead of a shared repository there can be no meaningful community participation in the process.
I do not force people to use anything. I tell them that "If you want a build that is known to work, you should use a file release. If you are up to a sometimes somewhat bumpy ride feel free to use the repository directly."
For most people such a setup is vastly advantageous since they get a version that's known to build and can put their development on top of that. Which gives us the ability to diff and compare against a known version, (hopefully) making it easier to integrate the changes.
For instance, if people would like to explore the recently submitted alternate unix socket implementation they need to send around files instead of pointing people to branch XYZ of the repository.
Commit rights for everyone? I don't think that'll happen.
And, certain VM platform versions have lagged for months in the past as there are single person responsibilities.
True for Windows at this point. So what do you propose to change?
Cheers,
- Andreas
Hi all!
I am not getting into this discussion - been there before, done that. ;) But I just have to note a few things:
Daniel Vainsencher daniel.vainsencher@gmail.com wrote:
Sounds to me like you're using a too restrictive version management system. If you were using MC (which of course is not actually applicable
[SNIP]
So you need a distributed CVS. Arch? darcs? heck, maybe even SVN can handle this, I don't know. Anyway, just an idea.
When we moved from CVS to Svn I suggested Darcs (after having looked around), but got voted down by the port maintainers - and of course it is their decision because it is they who use it.
Since then I have used Darcs quite a bit and wow, it rocks (as in ease of use, functionality etc). Slate uses Darcs too btw.
I also argued for the trunk to be the latest stable - I even think we agreed to that at some point in time (memory may be failing) - at least I recall Ian describing such a model. And then typically use tags for releases - just like people normally do with CVS etc. Not sure what a tar-ball gives us that a tag can't, but again - I am not butting in. :)
Anyway, one idea I have been toying with is to run a Darcs gateway for the main Squeak SVN. I set one up for fun and personal experimentation a while ago - and the tools to make such a gateway have since then improved (tailor.py I believe it is called).
If anyone is interested in using such a gateway - we could cooperate. Ideally people experimenting with patches etc could then use darcs between ourselves - and then whenever stuff gets good enough we can send the patches to the port maintainers. This way perhaps we could have it "both ways" - both a central repo that is run according to the well established routine of the port maintainers - and a more loosely run network of darcs repos with more experimental changes/additions.
If you haven't looked at Darcs then I really urge you to take a look - after having used it you will never want to use CVS or Svn again. It is much easier to use (!), has a wonderfully natural model turning branches into something simple and use-it-all-the-time-no-problem-like, superb features and the merge capabilities are almost magical.
The great advantage of using Darcs in this case is because its work model allows cherry picking - which is quite extraordinary.
regards, Göran
goran@krampe.se wrote:
Hi all!
[SNIP]
I also argued for the trunk to be the latest stable - I even think weagreed to that at some point in time (memory may be failing) - at leastI recall Ian describing such a model. And then typically usetags for releases - just like people normally do with CVS etc. Not sure what a tar-ball gives us that a tag can't, but again - I am not butting in. :)
So... I have not been the only one to suggest this... (makes me feel better that I'm not alone :-) ) I guess I'm just late to the party to add my vote with Göran.
Anyway, one idea I have been toying with is to run a Darcs gateway for the main Squeak SVN. I set one up for fun and personal experimentation a while ago - and the tools to make such a gateway have since then improved (tailor.py I believe it is called).
If anyone is interested in using such a gateway -
Is http://www.darcs.net/ the main site to obtain code and docs?
Hi!
Brad Fuller brad@sonaural.com wrote:
So... I have not been the only one to suggest this... (makes me feel better that I'm not alone :-) ) I guess I'm just late to the party to add my vote with Göran.
:)
Anyway, one idea I have been toying with is to run a Darcs gateway for the main Squeak SVN. I set one up for fun and personal experimentation a while ago - and the tools to make such a gateway have since then improved (tailor.py I believe it is called).
If anyone is interested in using such a gateway -
Is http://www.darcs.net/ the main site to obtain code and docs?
Yup, do try it - it is amazingly refreshing. And I have a server with 6Gb space at krampe.se that we can use to set this up - or we could use box2.squeakfoundation.org too, but let's play a bit first.
The darcs wiki contains good info on how to set up a gateway, and the ml is really active - lots of stuff going on.
regards, Göran
Is http://www.darcs.net/ the main site to obtain code and docs?
Yes.
--happy darcs user since 2004/4
Andreas Raab wrote:
Different groups have different styles of work and we (the VM maintainers) have long adopted a style which does not assume that HEAD is always the latest stable version but rather provide explicit file releases. The main reasons being that there is no conceptual difference between checking out HEAD or using a stable file release and to allow us to move forward so that we know the order in which pending changes get integrated. This is in particular important since the main ports have maintainers with very different schedules and requiring everyone to get in sync before allowing to make a change to the trunk would probably deadlock the entire group.
That's what branches are for, right?
file: Squeak-3.7-7.src.tar.gz (I assume) is "the" last known good stable source.
I would suggest that we need agreement from those who know that
I would suggest that you take the discussion to VM-dev if you want any resolution.
Then, we need to find the other platform vm sources to create the stable trunk (I need these eventually, too)
Win32: http://squeak.hpl.hp.com/win32/release/Squeak-Win32-3.7.1-src.zip
It might be that the current trunk is pretty close already. I don't know.
For Windows, no. I still haven't gotten around to update the VM sources to 3.8 - in other words if we would follow your proposed model the trunk would be stuck at 3.7 which I would find an extremely unpleasant situation.
Exactly, the trunk would be the stable version. I guess I don't see why it's better to have the bleeding edge in the trunk.
If it sounds messy because of all the different platforms, maybe the released should be located one more dir below for each platform. Or, separate trunks for each platform. At least the source would be in one place.
But, ok. I can live with anything.. just as long as I know what procedure to follow.
The only reliable form to get a guarantueed version of the VM is (and has always been, back to '96) to get a file release (tar ball) containing everything that has been used to build the VM you are using. The versions change, mind you and having HEAD apply to whatever-the-latest doesn't help you one bit if you don't use whatever-the-latest. With file releases you get *exactly* everything the maintainer has been using for the VM you are using and you even know when a maintainer hasn't done whatever-the-latest; such as the absence of a 3.8 Windows VM. Put differently, if you ever have a problem with the 3.2.1 Windows VM you go grab http://squeak.hpl.hp.com/win32/release/Squeak-Win32-3.2.1-src.zip and get *exactly* the sources that have been used for the VM you are running, period. AFAIK, Ian has generally been following the same policy.
ok
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
Oh, I do. I just question it, that's all.
They work for us. And If you think we're all morons who don't know Jack you are of course free to set up an alternative repository and show the superiority of your ways. We'll discuss the results in 2015 ;-)
I understand and respect that they've been working together for a long time. I'm indebted to their invaluable contributions. I just want to be able to obtain those contributions and build it in a reasonable way. And, I didn't mean to imply that the maintainers are morons.
Poking around, I see that there are indeed branches and tags, but they seem a bit backward to me. There is a 3.7 branch for unix at: http://squeak.hpl.hp.com/svn/squeak/branches/unix-3.7-7/. Would this be the released 3.7 for unix?
There are several places in the swiki that states to go to the trunk for the sources. In one place, it does say "the latest sources". So, you got me there. Ok, how about we clean up the swiki, so that it indicates where to get the stable or released sources... to save headaches for the next bloke.
Poking around some more, I see that there is a page that indicates where to get the win sources. To me, it seems a bit backwards to have people go to different places for sources. Isn't it a goal for squeak to maintain consistency among all platforms? It's not possible completely, of course, but that's the goal. So, it seems a waste (to me, no offense intended) to not use SVN to it's full potential.
Ok, I'll leave this ml and post in the vm ml as you've suggested.
Thanks for your help,
brad
Brad Fuller wrote:
Andreas Raab wrote:
Different groups have different styles of work and we (the VM maintainers) have long adopted a style which does not assume that HEAD is always the latest stable version but rather provide explicit file releases. The main reasons being that there is no conceptual difference between checking out HEAD or using a stable file release and to allow us to move forward so that we know the order in which pending changes get integrated. This is in particular important since the main ports have maintainers with very different schedules and requiring everyone to get in sync before allowing to make a change to the trunk would probably deadlock the entire group.
That's what branches are for, right?
It depends on how you look at it. I see HEAD as the head of the main-line development. Branches are for trying out orthogonal stuff which will not necessarily go into main line. It's a different model from what you are describing where all development happens in branches and commits to the trunk happen rarely. I have seen both in practice and there is not much difference.
For Windows, no. I still haven't gotten around to update the VM sources to 3.8 - in other words if we would follow your proposed model the trunk would be stuck at 3.7 which I would find an extremely unpleasant situation.
Exactly, the trunk would be the stable version. I guess I don't see why it's better to have the bleeding edge in the trunk.
Ah, I think I see what you are missing: You assume that the different platforms are independent of each other, e.g., that the trunk of the SVN repository could have a stable 3.7 Windows *and* a stable 3.8 Mac set of source files.
Unfortunately, that is not true. There are overlaps between the platforms (mostly in the Cross tree) and if there are conflicting changes (there typically are) you cannot have your cake and eat it, too. The only alternative is to either accept that some platforms may be broken at HEAD (the solution we adopted) or to delay any commits to the trunk until *all* platforms are updated.
And the latter is probably impossible - maintaining a port is very specific stuff and I couldn't even dream of fixing an issue in the Mac or the Risc OS support code (the same probably goes the other way around). So unless you have a set of maintainers who can jump at the blink of an eye 24/7 you better deal with the fact that one of them might just be off for vacation.
If it sounds messy because of all the different platforms, maybe the released should be located one more dir below for each platform. Or, separate trunks for each platform. At least the source would be in one place.
This might be doable but it sounds like quite a bit of work and I suppose you aren't volunteering...
Also, the set of maintainers has been working together in some form or other for almost ten years now and you should at least consider the possibility that there are reasons for why things are the way they are.
Oh, I do. I just question it, that's all.
Yes, I know. We see these questions every other year usually in the form of some demands that "you must organize your work like this" and of course, with absolutely no intent to help and actually improve things. I've gotten edgy about this over the years to the point that I've considered twice to just drop it and leave you guys doing whatever you think you can do better (who knows, maybe you can).
They work for us. And If you think we're all morons who don't know Jack you are of course free to set up an alternative repository and show the superiority of your ways. We'll discuss the results in 2015 ;-)
I understand and respect that they've been working together for a long time. I'm indebted to their invaluable contributions. I just want to be able to obtain those contributions and build it in a reasonable way. And, I didn't mean to imply that the maintainers are morons.
Sorry, that was meant as a joke about short-term vs. lasting impact.
Poking around, I see that there are indeed branches and tags, but they seem a bit backward to me. There is a 3.7 branch for unix at: http://squeak.hpl.hp.com/svn/squeak/branches/unix-3.7-7/. Would this be the released 3.7 for unix?
Good question. As you may or may not know, dealing with branches in CVS is a pain and so we essentially didn't use it. This might just be legacy from the CVS days or it might be something different. Only VM-dev could tell.
There are several places in the swiki that states to go to the trunk for the sources. In one place, it does say "the latest sources". So, you got me there. Ok, how about we clean up the swiki, so that it indicates where to get the stable or released sources... to save headaches for the next bloke.
That's the problem with the Swiki - some people just edit something and there is absolutely no authority to what they say. The only place that counts for Unix is http://squeak.hpl.hp.com/unix.
Poking around some more, I see that there is a page that indicates where to get the win sources. To me, it seems a bit backwards to have people go to different places for sources. Isn't it a goal for squeak to maintain consistency among all platforms? It's not possible completely, of course, but that's the goal. So, it seems a waste (to me, no offense intended) to not use SVN to it's full potential.
And the only place that's authorative for windows is http://minnow.cc.gatech.edu/squeak/3272 (where it points back to squeak.hpl.hp.com).
Cheers, - Andreas
Andreas Raab wrote:
Yes, I know. We see these questions every other year usually in the form of some demands that "you must organize your work like this" and of course, with absolutely no intent to help and actually improve things. I've gotten edgy about this over the years to the point that I've considered twice to just drop it and leave you guys doing whatever you think you can do better (who knows, maybe you can).
...or, just develop thicker skin. :-) We need your work. If someone wants to contribute they just need instructions to get things going. I found the "start from the distributed sources" to be rather obvious but maybe we can be even more explicit on the Swiki. Since Squeak basically ignores the more common open-source strategies (using sourceforge or similar) people are going to have a harder time adjusting. I share your general attitude...that is, I don't know if things could be done better.
The problem I see is one that probably concern others as well: I don't want to maintain a fork. Should I produce anything useful I'm interested to see how difficult it will be to merge it into the current trunk. Probably I'll just go from release to release. That is, when the next unix VM is released I'll try to merge my work into that one. I've got the current 3.8a1 sources in a local CVS repository so this seems like it will be absolutely trivial. I can also generate diffs against that release so hopefully merging into the SVN trunk won't be hard should that day ever arrive.
I just joined the VM mailling list. I'm happy to see that _that_ list is mostly about real VM issues rather than process... (not to trivialize the discussions going on here, its just hard to keep up with them).
David
On Sat, Aug 27, 2005 at 12:07:02PM -0700, Brad Fuller wrote:
I should state the obvious: Why is the bleeding edge source in the trunk? Why hasn't that been branched off? I expected the stable version to be in the trunk, not the working copies.
Or, am I missing something here?
Going to Ian's source will just complicate matters and doesn't guarantee source code consistency. Now there are two source trees.
Ian's source is just a snapshot of the SVN sources at some point in time at which Ian apparently thought they were stable enough to be published.
Re: VMMaker. I'm using the VMMaker that is included with 3.8Full. I'll check out the notes in SqueakMap, but is it different? Is it new and improved? Is it the special VMMaker you mentioned in the last msg? (and also the patches you mentioned?)
Good question, and the answer is I don't know. FWIW, I do know that loading the VMMaker from SqueakMap into a 3.7 image seems to work nicely.
Dave
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Brad Fuller -
Brad Fuller -
Craig Latta -
Daniel Vainsencher -
David Shaffer -
David T. Lewis -
goran＠krampe.se -
Michael Rueger -
Ross Boylan -
Simon Michael