Edgar,
I started up my trunk development image today and as usual started by checking for updates. I had also done this yesterday. The very first update it seems for me was your Nebraska-edc.15. Loading this resulted in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
Ken
More info:
It turns out that the first update I did not have was ReleaseBuilder-edc.33 . So I merged this in manually and then moved on to the next which was Nebraska-edc.14. It's actually on this update that I get the error.
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Ken
On Fri, 2009-07-17 at 11:28 -0500, Ken Causey wrote:
Edgar,
I started up my trunk development image today and as usual started by checking for updates. I had also done this yesterday. The very first update it seems for me was your Nebraska-edc.15. Loading this resulted in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
Ken
Edgar,
In Nebraska-edc.14 you remove WorldState>>remoteCanvasesDo: without modifying the senders including WorldState>>forceDamageToScreen:.
Ken
On Fri, 2009-07-17 at 11:47 -0500, Ken Causey wrote:
More info:
It turns out that the first update I did not have was ReleaseBuilder-edc.33 . So I merged this in manually and then moved on to the next which was Nebraska-edc.14. It's actually on this update that I get the error.
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Ken
On Fri, 2009-07-17 at 11:28 -0500, Ken Causey wrote:
Edgar,
I started up my trunk development image today and as usual started by checking for updates. I had also done this yesterday. The very first update it seems for me was your Nebraska-edc.15. Loading this resulted in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
Ken
On 7/17/09 1:47 PM, "Ken Causey" ken@kencausey.com wrote:
More info:
It turns out that the first update I did not have was ReleaseBuilder-edc.33 . So I merged this in manually and then moved on to the next which was Nebraska-edc.14. It's actually on this update that I get the error.
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Ken
You need wait until Andreas and me have perfect understanding. Take all I do for SqueakLightII is not easy. I suggest to Andeas return to updates folder policy , so we could have a proper
7161AdvanceToThreeDotElevenAlpha.cs 7162ConvertTo3dot11.cs or some like that
Actually my video
http://www.morphle.com/~edgar/Don%27t%20try%20this%20at%20home.mov
Shows how I convert 3.10 to 3.11 and you see before ReleaseBuilder run and do his magic I need fileIn a .cs
The proper number is 15 , but all have sense in a new image, not in a older one.
We have two years of nothing and miss understanding so be patient. In the end all works.
Edgar
On 17.07.2009, at 20:38, Edgar J. De Cleene wrote:
On 7/17/09 1:47 PM, "Ken Causey" ken@kencausey.com wrote:
More info:
It turns out that the first update I did not have was ReleaseBuilder-edc.33 . So I merged this in manually and then moved on to the next which was Nebraska-edc.14. It's actually on this update that I get the error.
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Ken
You need wait until Andreas and me have perfect understanding.
No, you need to upload your new MorphicExtras package too, since you moved the method from Nebraska to this package.
Besides, in my image loading the latest Kernel package removes Semaphore>>wait, which is fatal. Anyone else seeing this?
- Bert -
Bert Freudenberg wrote:
On 17.07.2009, at 20:38, Edgar J. De Cleene wrote:
On 7/17/09 1:47 PM, "Ken Causey" ken@kencausey.com wrote:
More info:
It turns out that the first update I did not have was ReleaseBuilder-edc.33 . So I merged this in manually and then moved on to the next which was Nebraska-edc.14. It's actually on this update that I get the error.
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Ken
You need wait until Andreas and me have perfect understanding.
No, you need to upload your new MorphicExtras package too, since you moved the method from Nebraska to this package.
Besides, in my image loading the latest Kernel package removes Semaphore>>wait, which is fatal. Anyone else seeing this?
- Bert -
Sorry but I have to laugh...
The result of this will be, more rules and controls as to whom can contribute to trunk. As a result yet more people will get upset and their contributions will not be valued or accepted.
In a team different people have different strengths, some are ideas people and break things, some are a pain and ask the relevant questions, some are finishers and dot i's and cross t's... I venture to suggest that this "experimental" trunk process cannot support them all.
It can only really support those who are gifted like Andreas who can be a whole team in one person, and most of us are used to trying to do that, otherwise we would get nothing done ourselves.
So what you really need to do is put people in groups of people that complement each others skills, and each group takes on a specific task.
Some will try and tell you that there has not been much progress in the past two years, but the truth is that several major problem areas have been tackled in this manner. In my team-let I have been the ideas person (that breaks things in fits of inspiration), and Matthew has been the sensible one that makes sure things work, it has worked quite well.
The problem of MC not working has been worked upon ad infinitum. The problem of FileDirectory has been worked upon. Rio has been rewritten 3 times in the past 2 years. The problem of Packaging and dependants has been tackled, Sake/Packages has had several iterations, and is now a bit simpler and more functional than before. Logging has had a few times around the block, etc etc.
So how about some ideas for some team initiatives that we can road map in.
Keith
Bert Freudenberg wrote:
Besides, in my image loading the latest Kernel package removes Semaphore>>wait, which is fatal. Anyone else seeing this?
Overrides. Evil Overrides. I put in a version that puts wait back where it belongs. Repeat after me: I shall not use overrides.
Cheers, - Andreas
Andreas Raab wrote:
Overrides. Evil Overrides. I put in a version that puts wait back where it belongs. Repeat after me: I shall not use overrides.
Oh, and I am only just realizing how evil these overrides are. You can't really put the method back into its original category - even after loading the updated kernel package Semaphore>>wait is still in the override category and will surely cause problems somewhere down the road. Is there an "official" MC way of fixing this problem or will we have to do this via a doit (postscript or something)?
Cheers, - Andreas
On 18.07.2009, at 00:19, Andreas Raab wrote:
Andreas Raab wrote:
Overrides. Evil Overrides. I put in a version that puts wait back where it belongs. Repeat after me: I shall not use overrides.
Oh, and I am only just realizing how evil these overrides are. You can't really put the method back into its original category - even after loading the updated kernel package Semaphore>>wait is still in the override category and will surely cause problems somewhere down the road. Is there an "official" MC way of fixing this problem or will we have to do this via a doit (postscript or something)?
I think you would have to move it to *scripting first (without the override) and then to kernel.
But actually the PackageInfo version seems to be buggy because it simply assumes that when an override exists, the original method belongs to the package in question. But in the #wait case, no such method exists in the method history, presumably because sources were condensed without the overrides fix.
- Bert -
On Sat, 2009-07-18 at 01:32 +0200, Bert Freudenberg wrote:
On 18.07.2009, at 00:19, Andreas Raab wrote:
Andreas Raab wrote:
Overrides. Evil Overrides. I put in a version that puts wait back where it belongs. Repeat after me: I shall not use overrides.
Oh, and I am only just realizing how evil these overrides are. You can't really put the method back into its original category - even after loading the updated kernel package Semaphore>>wait is still in the override category and will surely cause problems somewhere down the road. Is there an "official" MC way of fixing this problem or will we have to do this via a doit (postscript or something)?
I think you would have to move it to *scripting first (without the override) and then to kernel.
But actually the PackageInfo version seems to be buggy because it simply assumes that when an override exists, the original method belongs to the package in question. But in the #wait case, no such method exists in the method history, presumably because sources were condensed without the overrides fix.
- Bert -
Andreas: Is this what you ultimately did for Kernel-ar.190?
Ken
Ken Causey wrote:
On Sat, 2009-07-18 at 01:32 +0200, Bert Freudenberg wrote:
I think you would have to move it to *scripting first (without the override) and then to kernel.
But actually the PackageInfo version seems to be buggy because it simply assumes that when an override exists, the original method belongs to the package in question. But in the #wait case, no such method exists in the method history, presumably because sources were condensed without the overrides fix.
- Bert -
Andreas: Is this what you ultimately did for Kernel-ar.190?
No, I didn't. I was just trying to move the method back into Kernel but I guess this will need to be done via a doit.
Cheers, - Andreas
On 7/17/09 6:34 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
No, you need to upload your new MorphicExtras package too, since you moved the method from Nebraska to this package.
Yes, Andreas points this. I fix ASAP
Edgar
Ken Causey wrote:
I'm not sure of the behavior of the updates process. Is it possible that if I have neither .14 or .15 that in fact it doesn't merge 14 and then 15 but simply 15? Perhaps it is in fact irrelevant.
Since Monticello stores an entire snapshot you really only need to load the latest version since it will contain all the code that should be in this package.
Intermediate stages are only required when there are dependency between package versions that cannot be skipped over and just all loaded together; for example the closure bootstrap heavily depends on a set of prerequiste packages loaded together before it goes on to the next set of packages. Basically, every update.mcm says "you must have loaded this set of package versions before it is safe to load the next round of stuff".
And at the end of the process, when all of the configurations that list explicit versions have been processed, the updater simply updates all versions of packages listed in the last configuration to the highest version number in the repository.
P.S. One thing the new update stream does appear to lack compared to the old update stream is the ability to easily update only up to a certain update number. Is there some way that could be implemented? Clearly the trunk is not the simplistic linear thing the old update stream was.
We can do that and it's certainly worth considering. All it would take is to not do the last part of the above description, i.e., do not update beyond what is listed in the last configuration.
The consequence of the approach would be that once you've pushed a change and it works you need to do an additional step and update the configuration to include that package. If people feel it would be safer to work that way, it would require only a tiny modification of the script, at the cost of requiring two steps before a change really reaches everyone who updates.
Comments? Preferences? Opinions?
Cheers, - Andreas
On Fri, 2009-07-17 at 21:54 -0700, Andreas Raab wrote:
Ken Causey wrote:
P.S. One thing the new update stream does appear to lack compared to the old update stream is the ability to easily update only up to a certain update number. Is there some way that could be implemented? Clearly the trunk is not the simplistic linear thing the old update stream was.
We can do that and it's certainly worth considering. All it would take is to not do the last part of the above description, i.e., do not update beyond what is listed in the last configuration.
The consequence of the approach would be that once you've pushed a change and it works you need to do an additional step and update the configuration to include that package. If people feel it would be safer to work that way, it would require only a tiny modification of the script, at the cost of requiring two steps before a change really reaches everyone who updates.
Comments? Preferences? Opinions?
Cheers,
- Andreas
I'm not certain if we are talking about the same thing here. I'm thinking of an analog to
Utilities class>>updateFromServerThroughUpdateNumber:
and this would be done from the user side as desired.
I think I still don't quite understand MC configurations because the model in my mind was simply that the .mcm specified packages and not specific versions and that when you updated it updated all listed packages to the latest versions in the repository. However I just looked at the latest update-ar.4.mcm and it does indeed specify versions. So that confuses me why we don't have to modify the .mcm every time a new version is published.
Perhaps a way to do what I want could involve specifying a local override to specific entries in the the mcm to only update to a certain version of a package or perhaps not even load a package at all.
What I'm thinking of is something that I would expect to only rarely be used and I wouldn't want to increase the effort required for each update to the trunk to support a rare action.
Ken
Ken Causey wrote:
I'm not certain if we are talking about the same thing here. I'm thinking of an analog to
Utilities class>>updateFromServerThroughUpdateNumber:
and this would be done from the user side as desired.
I think I still don't quite understand MC configurations because the model in my mind was simply that the .mcm specified packages and not specific versions and that when you updated it updated all listed packages to the latest versions in the repository. However I just looked at the latest update-ar.4.mcm and it does indeed specify versions. So that confuses me why we don't have to modify the .mcm every time a new version is published.
That's because the updater does what you describe, but only for the *latest* update.mcm. The updater first loads all the specific versions that are in the list of update.mcm. With the *latest* update.mcm it then simply updates all packages to the latest version. For example:
updates.1.mcm: Kernel-aa.1.mcz Collections-bb.3.mcz
updates.2.mcm: Collections-aa-5.mcz Kernel-bb.7.mcz
updates.3.mcm Kernel-aa.15.mcz Collections-bb.7.mcz
First, the updater loads what is listed in updates.1.mcm (Kernel-aa.1.mcz, Collections-bb.3.mcz), then it goes on to updates.2.mcm (Collections-aa.5.mcz, Kernel-bb.7.mcz) then updates.3.mcm (Kernel-aa.15.mcz, Collections-bb.7.mcz).
Once it has loaded all these versions it takes updates.3.mcm and checks whether there are any new versions of Kernel or Collections. If there are, it loads (in the order that is given in updates.3.mcm; Kernel first, then Collections).
Perhaps a way to do what I want could involve specifying a local override to specific entries in the the mcm to only update to a certain version of a package or perhaps not even load a package at all.
It would be easy to support updating through a particular update.mcm only. It would be harder to update through a specific package version automatically but one could update to an earlier update.mcm and load the remaining packages manually.
Cheers, - Andreas
On 18.07.2009, at 19:50, Andreas Raab andreas.raab@gmx.de wrote:
Ken Causey wrote:
Perhaps a way to do what I want could involve specifying a local override to specific entries in the the mcm to only update to a certain version of a package or perhaps not even load a package at all.
It would be easy to support updating through a particular update.mcm only. It would be harder to update through a specific package version automatically but one could update to an earlier update.mcm and load the remaining packages manually.
Cheers,
- Andreas
One idea would be to "pin" down a particular package version locally. Or simply have a list of packages that should be excluded from updating beyond the latest version explicitly given in an mcm.
- Bert -
Am 18.07.2009 um 06:54 schrieb Andreas Raab:
Ken Causey wrote:
P.S. One thing the new update stream does appear to lack compared
to the
old update stream is the ability to easily update only up to a
certain
update number. Is there some way that could be implemented?
Clearly
the trunk is not the simplistic linear thing the old update stream
was.
We can do that and it's certainly worth considering. All it would take is to not do the last part of the above description, i.e., do not update beyond what is listed in the last configuration.
The consequence of the approach would be that once you've pushed a change and it works you need to do an additional step and update the configuration to include that package. If people feel it would be safer to work that way, it would require only a tiny modification of the script, at the cost of requiring two steps before a change really reaches everyone who updates.
Comments? Preferences? Opinions?
One advantage of having to update the configuration for each change would be that the update number could be used as a build number.
I have another question regarding the new development process: It is possible for a core developer to remove a package version from the trunk when he finds out that it breaks the update, right?
Cheers, Bernhard
Bernhard Pieber wrote:
I have another question regarding the new development process: It is possible for a core developer to remove a package version from the trunk when he finds out that it breaks the update, right?
Yes. All it takes is increasing the package version number. "Highest number wins" is the rule for incremental updates, so saving the same version again with a higher package version number will do the trick just fine. (you can't actually "delete" things from Squeaksource unless you are the server administrator)
Cheers, - Andreas
On 17.07.2009, at 18:28, Ken Causey wrote:
Edgar,
I started up my trunk development image today and as usual started by checking for updates. I had also done this yesterday. The very first update it seems for me was your Nebraska-edc.15. Loading this resulted in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
Ken
He, maybe we need to invent methods to punish developers who break the trunk in such a way ;)
But at least now that updating is possible again such problems will not go unnoticed for long.
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
- Bert -
2009/7/17 Bert Freudenberg bert@freudenbergs.de:
He, maybe we need to invent methods to punish developers who break the trunk in such a way ;)
Or maybe not. In a continuous integration process, edgar could have been notified by email that his changes broke the trunk. A carbon copy can also be sent to the repository admit.
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
That would make sense. The trunk should be frozen at some point in the perspective of a release and then enter in a release phase. And the release phase can be something along 3.11 proposal. My idea of both development process is that they are not mutually exclusive.
Are we going to have continuous integration on the trunk? Publishing results on a web page or something would be great.
Ian.
Ian Trudel wrote:
2009/7/17 Bert Freudenberg bert@freudenbergs.de:
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
That would make sense. The trunk should be frozen at some point in the perspective of a release and then enter in a release phase. And the release phase can be something along 3.11 proposal. My idea of both development process is that they are not mutually exclusive.
Why not make a branch rather than freezing the trunk? That way it should be easier to determine what goes into a release, especially if it's built from spec rather than hand crafted.
2009/7/17 Douglas Brebner squeaklists@fang.demon.co.uk:
Why not make a branch rather than freezing the trunk? That way it should be easier to determine what goes into a release, especially if it's built from spec rather than hand crafted.
That could be an option as far as I am concerned. It would probably better fit with a release process, as in 3.11 proposal.
Ian.
On 17.07.2009, at 19:38, Douglas Brebner wrote:
Ian Trudel wrote:
2009/7/17 Bert Freudenberg bert@freudenbergs.de:
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
That would make sense. The trunk should be frozen at some point in the perspective of a release and then enter in a release phase. And the release phase can be something along 3.11 proposal. My idea of both development process is that they are not mutually exclusive.
Why not make a branch rather than freezing the trunk? That way it should be easier to determine what goes into a release, especially if it's built from spec rather than hand crafted.
Given our rather small active developer community I do not find it advisable to split the work force. Everyone should work together towards a release and not just the few poor souls who work on the release branch. This way everyone uses the release candidate, it gets much wider testing etc.
I recently saw a presentation on the OpenBSD release process and found Theo's argument in favor of this convincing: http://www.youtube.com/watch?v=i7pkyDUX5uM
- Bert -
2009/7/17 Bert Freudenberg bert@freudenbergs.de:
Given our rather small active developer community I do not find it advisable to split the work force. Everyone should work together towards a release and not just the few poor souls who work on the release branch. This way everyone uses the release candidate, it gets much wider testing etc.
I recently saw a presentation on the OpenBSD release process and found Theo's argument in favor of this convincing: http://www.youtube.com/watch?v=i7pkyDUX5uM
I haven't checked the video yet. Your comment puts things back into perspective. Limited work force should taken into consideration and whatever the solutions are, it shouldn't give more work to those who actively participate.
This reminds me that we are perhaps trying to run before we can walk (again).
The community repositories is an experiment as far as I have understood, which should allow to reenact community commitment to Squeak and, ultimately, figure out a development model that will be fit to the community.
3.11 proposal is all about planning. Community development model is all about action. We need to get dirty and see how it turns out. Then, we can bring real solutions rather than solutions to problems that we haven't encountered yet. We cannot continuously step ahead problems.
Bert, I agree with you.
Ian.
On 17.07.2009, at 19:41, Ken Causey wrote:
On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
- Bert -
I would suggest an alternate model. Rather than forcing developers as a group to follow some sort of schedule why not consider a release a snapshot of the development trunk minus some questionable or problematic updates plus some additional cleanups relevant to a release.
Let's say I wanted to create a release today and let's posit that there are a number of known good updates after Nebraska 14 and 15. I could update to the update just before Nebraska 14, then manually merge in the updates afterward. Then do whatever clean up I want to do. Then release.
IMHO that would prolong the problem that the release is not a real community effort. For many years now, the release team consisted of very few people who had to do all the integration work themselves. I feel that this is simply too much of a burden for those individuals (even though they volunteered to do it) and at the same time a much greater sense of a shared product could be created in the community by actually working on that product together.
I think extending the number of committers is one of the most valuable aspects of the trunk model. It comes along with greater responsibility for all of course, but that can only be good I'd say.
- Bert -
On Fri, 2009-07-17 at 19:55 +0200, Bert Freudenberg wrote:
On 17.07.2009, at 19:41, Ken Causey wrote:
On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
- Bert -
I would suggest an alternate model. Rather than forcing developers as a group to follow some sort of schedule why not consider a release a snapshot of the development trunk minus some questionable or problematic updates plus some additional cleanups relevant to a release.
Let's say I wanted to create a release today and let's posit that there are a number of known good updates after Nebraska 14 and 15. I could update to the update just before Nebraska 14, then manually merge in the updates afterward. Then do whatever clean up I want to do. Then release.
IMHO that would prolong the problem that the release is not a real community effort. For many years now, the release team consisted of very few people who had to do all the integration work themselves. I feel that this is simply too much of a burden for those individuals (even though they volunteered to do it) and at the same time a much greater sense of a shared product could be created in the community by actually working on that product together.
I think extending the number of committers is one of the most valuable aspects of the trunk model. It comes along with greater responsibility for all of course, but that can only be good I'd say.
- Bert -
I don't see why the process of deciding what to remove and what to add in can't be done as a group. While my description is clearly a manual one I don't see that it can't be largely automated and that the description of what is done could be a joint one among those interested.
Personally I suspect that not all core developers find the details of individual releases to be all that interesting and are in fact willing to rely on others with more interest to define them. I don't wish to exclude anyone, but at the same time I see no reason why any particular individual must participate in this part of the process.
Ken
Am 17.07.2009 um 19:55 schrieb Bert Freudenberg:
IMHO that would prolong the problem that the release is not a real community effort. For many years now, the release team consisted of very few people who had to do all the integration work themselves. I feel that this is simply too much of a burden for those individuals (even though they volunteered to do it) and at the same time a much greater sense of a shared product could be created in the community by actually working on that product together.
I think extending the number of committers is one of the most valuable aspects of the trunk model. It comes along with greater responsibility for all of course, but that can only be good I'd say.
+10!
Cheers, Bernhard
On 17.07.2009, at 19:29, Ian Trudel wrote:
2009/7/17 Bert Freudenberg bert@freudenbergs.de:
He, maybe we need to invent methods to punish developers who break the trunk in such a way ;)
Or maybe not. In a continuous integration process, edgar could have been notified by email that his changes broke the trunk. A carbon copy can also be sent to the repository admit.
... and a Bad Developer Of The Week Award on the Squeak home page ;)
Just kidding.
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
That would make sense. The trunk should be frozen at some point in the perspective of a release and then enter in a release phase. And the release phase can be something along 3.11 proposal. My idea of both development process is that they are not mutually exclusive.
Are we going to have continuous integration on the trunk? Publishing results on a web page or something would be great.
Yes, that would be awesome to have.
- Bert -
On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
In any case a process where development slows down when nearing a release would be in order, we might need feature freezes etc. Maybe we simply set a release date now and then work towards it?
- Bert -
I would suggest an alternate model. Rather than forcing developers as a group to follow some sort of schedule why not consider a release a snapshot of the development trunk minus some questionable or problematic updates plus some additional cleanups relevant to a release.
Let's say I wanted to create a release today and let's posit that there are a number of known good updates after Nebraska 14 and 15. I could update to the update just before Nebraska 14, then manually merge in the updates afterward. Then do whatever clean up I want to do. Then release.
Ken
P.S. One thing the new update stream does appear to lack compared to the old update stream is the ability to easily update only up to a certain update number. Is there some way that could be implemented? Clearly the trunk is not the simplistic linear thing the old update stream was.
Ken Causey wrote:
Edgar,
I started up my trunk development image today and as usual started by checking for updates. I had also done this yesterday. The very first update it seems for me was your Nebraska-edc.15. Loading this resulted in an emergency debugger with a DNU on WorldState>>remoteCanvasesDo:.
Ken
Now if you look at the existing loadable Nebraska in Sake/Packages the definition for 3.10.2 is as follows
Nebraska
self name: 'Nebraska'. info category: 'Morphic'. info description: 'Nebraska load/unload'. info maintainer: 'kph'.
self version: '14'.
self load: [ (WorldState includesSelector: #remoteCanvasesDo:) ifTrue: [ WorldState organization classify: #remoteCanvasesDo: under: '*morphicextras-nebraska compatible'. ]. Installer squeaksource project: '311' ; install: 'Nebraska-kph.14'. ].
Do we really have to do everything 3 times?
Keith
In MC1.5 each package remembers in PackageInfo properties dictionary, where it was loaded from, so it is possible to get an update of the latest from the correct repository
Keith
On 7/17/09 4:41 PM, "Keith Hodges" keith_hodges@yahoo.co.uk wrote:
In MC1.5 each package remembers in PackageInfo properties dictionary, where it was loaded from, so it is possible to get an update of the latest from the correct repository
Keith
SqueakLighII don't use Bob, MC 1.5 , Sake , Installer or nothing with kph in it.
I have it working to my own satisfaction and try to get some of it to main 3.11.
But I can stop at any moment, as fork builders more wise as me do.
I quit of Release team before as you never get the word TEAM
I disagree with some Andreas say, but I choose he as Squeak CEO and do my best to learn and move Squeak to higher number as 7159 , which is same from two years ago...
Edgar
Edgar J. De Cleene wrote:
On 7/17/09 4:41 PM, "Keith Hodges" keith_hodges@yahoo.co.uk wrote:
In MC1.5 each package remembers in PackageInfo properties dictionary, where it was loaded from, so it is possible to get an update of the latest from the correct repository
Keith
SqueakLighII don't use Bob, MC 1.5 , Sake , Installer or nothing with kph in it.
I have it working to my own satisfaction and try to get some of it to main 3.11.
But I can stop at any moment, as fork builders more wise as me do.
I quit of Release team before as you never get the word TEAM
I understand perfectly what team means, years of sailing teaches you that you cannot do it all, and you need others to contribute, but every boat needs a captain, and every boat needs someone to clean the toilet. As a result, if the crew are seasick, or are not part of the team, it is not unusual to find the captain cleaning the toilet, and the boat sitting in port.
Keith
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bernhard Pieber -
Bert Freudenberg -
Douglas Brebner -
Edgar J. De Cleene -
Ian Trudel -
Keith Hodges -
Ken Causey