Object >> future
Locked
12
12
 
|
Hi. Someone noticed on IRC today that Object >> future (and
friends like futureSend: and the compiler optimization of future) are kind of odd things to have in the base image. I said it's there for Croquet, but then I looked again, and noticed that Croquet actually changes the behavior of future (it uses a TFutureMaker rather than a FutureMaker). No idea whether the two implementations are compatable or not; haven't examined either in depth. Since I'm porting Cobalt to trunk, I may have to override this method in Cobalt, but I'm wondering: Why is it here in the first place? Is it something ported from Tweak? Is it something leftover from 3.3? Is it something else entirely like a remnant of Squeak-E? Or is it just a simple, if rarely used, method in core squeak? -- Matthew Fulmer (a.k.a. Tapple) |
|
|
(just happened to wake up in the middle of the night after being sick all day, so I'll try to make sense)
On Mar 10, 2010, at 12:21 AM, Matthew Fulmer wrote: > Hi. Someone "Keith". > noticed on IRC today that Object >> future (and > friends like futureSend: and the compiler optimization of > future) are kind of odd things to have in the base image. Yes, he was temporarily away from the community during the discussion about it. I added the changes to the Inbox as announced in: http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140078 Andreas did a better job of motivating the changes than I did. In particular, he anticipates Keith's reasonable IRC question, "what's wrong with Future in: deltaMSecs send: selector to: target with: arg?". The short answer is "convenience". http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140096 As Keith seems to, Colin also felt ambivalent about changing the language with a Compiler modification. In fact, the compiler change is merely an optimization (just like #ifTrue:). http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140125 Keith and I actually touched upon this topic ourselves, but never got very deep into it. http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/141378 http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/141482 > I said > it's there for Croquet, but then I looked again, and noticed > that Croquet actually changes the behavior of future (it uses a > TFutureMaker rather than a FutureMaker). No idea whether the two > implementations are compatable or not; haven't examined either > in depth. > TFutureMaker and FutureMaker should be perfectly compatible; they both result in #futureSend:at:args: being sent to the target object. The question is what to do with the default implementations of #futureSend:at:args: and #futureDo:at:args: in Object. In Croquet, every Process has an "island" variable. When introducing these changes, I wanted to keep them as small as possible, so changing Process was out of the question as long as there are alternatives. Project seems like a reasonable place in the trunk image (Cuis doesn't have "Project", so would have to implement the default methods differently... I won't go into this, since it is irrelevant to you porting Croquet to 4.1). The default implementation in Project even works in MVC, and the version in MorphicProject takes advantage of existing scheduling machinery in Morphic. Although the decision to use Project seems expedient and reasonable, it's certainly open to change if something else makes more sense later. For porting Croquet, the simplest thing would be to override Project class>>current to look like: current ^Processor activeProcess island ifNil: [CurrentProject] This assumes that Process>>island answers nil if you're not "in" an island. This is the behavior in a random Cobalt image on my disk. In our images at work, "Processor activeProcess island" answers " an Island(Squeak)" if you type it into a workspace. The implementation of Project class>>current might then look like: current | island | island := Processor activeProcess island. ^(island == Island default) ifTrue: [CurrentProject] ifFalse: [Processor activeProcess island] > Since I'm porting Cobalt to trunk, I may have to override this > method in Cobalt, but I'm wondering: Why is it here in the first > place? Hopefully the links above provide the motivation. > Is it something ported from Tweak? Is it something > leftover from 3.3? Is it something else entirely like a remnant > of Squeak-E? Or is it just a simple, if rarely used, method in > core squeak? > The last one. Hope this helps. Cheers, Josh > -- > Matthew Fulmer (a.k.a. Tapple) > |
|
|
Josh,
so now we have a feature in trunk called "future". I don't know if I want it in my version of Cuis or not. I am not even sure what this feature consists of, in that I cant see what its boundaries are. However if I do I will want it to be a load-able extra, because some package I want to load may need it. As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it. It is a relatively isolated piece of functionality, it doesn't need to be managed inside the image, it can easily be a load-able feature. Can you answer if you will, how you have packaged up this "future" innovation so that it would be useful to me? If your answer is that you committed it to trunk, and I am expected to harvest it from trunk, I think you can forget it. If your answer is that it is in Monticello inbox, then how can I get the most current version, surely the inbox version will have been tweaked in the image. And cuis being a kernel image doesn't have monticello. Previously you said: "if we can achieve some of your goals without sacrificing the benefits of the new process" Hopefully this will help you to see that trunk is not really process offering any benefits at all. As far as I can see it is simply promoting sloppy work practices, where everything new you can think of gets thrown into the soup of a monolithic image, and now everyone can join in throwing stuff at the future (if you excuse the pun) image. When I use the "grow" process I am now running and developing the same code, (even kernel level code that would break trunk) in all forks simultaneously. Every innovation or which is managed as a loadable extra, becomes a potential point of commonality between existing forks. The fact that trunk is not managing its features outside of the image, is a disaster. Heck you haven't even split System up (yet). regards Keith === "Branching is the new Forking" |
|
|
On 10 March 2010 13:14, keith <[hidden email]> wrote:
> Josh, > so now we have a feature in trunk called "future". I don't know if I want it > in my version of Cuis or not. I am not even sure what this feature consists > of, in that I cant see what its boundaries are. However if I do I will want > it to be a load-able extra, because some package I want to load may need it. > As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it. It is > a relatively isolated piece of functionality, it doesn't need to be managed > inside the image, it can easily be a load-able feature. > Can you answer if you will, how you have packaged up this "future" > innovation so that it would be useful to me? > If your answer is that you committed it to trunk, and I am expected to > harvest it from trunk, I think you can forget it. > If your answer is that it is in Monticello inbox, then how can I get the > most current version, surely the inbox version will have been tweaked in the > image. And cuis being a kernel image doesn't have monticello. > Previously you said: "if we can achieve some of your goals without > sacrificing the benefits of the new process" > Hopefully this will help you to see that trunk is not really process > offering any benefits at all. As far as I can see it is simply promoting > sloppy work practices, where everything new you can think of gets thrown > into the soup of a monolithic image, and now everyone can join in throwing > stuff at the future (if you excuse the pun) image. > When I use the "grow" process I am now running and developing the same code, > (even kernel level code that would break trunk) in all forks simultaneously. > Every innovation or which is managed as a loadable extra, becomes a > potential point of commonality between existing forks. The fact that trunk > is not managing its features outside of the image, is a disaster. Heck you > haven't even split System up (yet). Keith, i am agree with you that trunk is hard thing to harvest comitted things, like futures. Yes, the trunk development model easing the way how one could join the project and commit own ideas/changes/fixes, but concerning cherry-picking features for different images, we are not moved forward comparing to old development model(s), which is used by Squeak before. We all need a good and easy solution for that. I'd say, an easy is more important than good, because if we make a harvesting be a hard, multiple steps process, which requires a deep knowledge about many tools, then it would be not much better than current situation, where people, to cherry-pick thing, should manually grok through image and extract individual classes/methods. > regards > Keith > === > "Branching is the new Forking" > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by keith1y
2010/3/10 keith <[hidden email]>:
> Josh, > so now we have a feature in trunk called "future". I don't know if I want it > in my version of Cuis or not. I am not even sure what this feature consists > of, in that I cant see what its boundaries are. However if I do I will want > it to be a load-able extra, because some package I want to load may need it. > As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it. It is > a relatively isolated piece of functionality, it doesn't need to be managed > inside the image, it can easily be a load-able feature. > Can you answer if you will, how you have packaged up this "future" > innovation so that it would be useful to me? > If your answer is that you committed it to trunk, and I am expected to > harvest it from trunk, I think you can forget it. > If your answer is that it is in Monticello inbox, then how can I get the > most current version, surely the inbox version will have been tweaked in the > image. And cuis being a kernel image doesn't have monticello. > Previously you said: "if we can achieve some of your goals without > sacrificing the benefits of the new process" > Hopefully this will help you to see that trunk is not really process > offering any benefits at all. As far as I can see it is simply promoting > sloppy work practices, where everything new you can think of gets thrown > into the soup of a monolithic image, and now everyone can join in throwing > stuff at the future (if you excuse the pun) image. > When I use the "grow" process I am now running and developing the same code, > (even kernel level code that would break trunk) in all forks simultaneously. > Every innovation or which is managed as a loadable extra, becomes a > potential point of commonality between existing forks. The fact that trunk > is not managing its features outside of the image, is a disaster. Heck you > haven't even split System up (yet). > regards > Keith > === > "Branching is the new Forking" > > Keith, Unfortunately, this change is unlikely to be portable because it overrides internal Parser/Compiler methods. Due to this, all the noble features that you wish are void. The job has to be done N times for N images, independently of the tool used, this has nothing to do with MC. You cannot ask each guy to provide an N-images compatible change, or set of changes, This is not practicle, and simply won't work. With such a policy, progress will soon stop. Pharoers program for Pharo, squeakers for trunk, etc... Then, it does not prevent to exchange ideas and solutions, and it's better if we exchange before programming. I for sure will support unification on some Kernel features. But then, we can diverge,or what exactly is the point of having forks ? Nicolas |
|
|
In reply to this post by Igor Stasenko
2010/3/10 Igor Stasenko <[hidden email]>:
> On 10 March 2010 13:14, keith <[hidden email]> wrote: >> Josh, >> so now we have a feature in trunk called "future". I don't know if I want it >> in my version of Cuis or not. I am not even sure what this feature consists >> of, in that I cant see what its boundaries are. However if I do I will want >> it to be a load-able extra, because some package I want to load may need it. >> As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it. It is >> a relatively isolated piece of functionality, it doesn't need to be managed >> inside the image, it can easily be a load-able feature. >> Can you answer if you will, how you have packaged up this "future" >> innovation so that it would be useful to me? >> If your answer is that you committed it to trunk, and I am expected to >> harvest it from trunk, I think you can forget it. >> If your answer is that it is in Monticello inbox, then how can I get the >> most current version, surely the inbox version will have been tweaked in the >> image. And cuis being a kernel image doesn't have monticello. >> Previously you said: "if we can achieve some of your goals without >> sacrificing the benefits of the new process" >> Hopefully this will help you to see that trunk is not really process >> offering any benefits at all. As far as I can see it is simply promoting >> sloppy work practices, where everything new you can think of gets thrown >> into the soup of a monolithic image, and now everyone can join in throwing >> stuff at the future (if you excuse the pun) image. >> When I use the "grow" process I am now running and developing the same code, >> (even kernel level code that would break trunk) in all forks simultaneously. >> Every innovation or which is managed as a loadable extra, becomes a >> potential point of commonality between existing forks. The fact that trunk >> is not managing its features outside of the image, is a disaster. Heck you >> haven't even split System up (yet). > > Keith, i am agree with you that trunk is hard thing to harvest > comitted things, like futures. > Yes, the trunk development model easing the way how one could join the > project and commit own ideas/changes/fixes, > but concerning cherry-picking features for different images, we are > not moved forward comparing to old development model(s), > which is used by Squeak before. > We all need a good and easy solution for that. I'd say, an easy is > more important than good, because if we make a harvesting be a hard, > multiple steps process, which requires a deep knowledge about many > tools, then it would be not much better than current situation, where > people, to cherry-pick thing, should manually grok through image and > extract individual classes/methods. > I'm in line with Igor. Nicolas > >> regards >> Keith >> === >> "Branching is the new Forking" >> > > -- > Best regards, > Igor Stasenko AKA sig. > > |
|
|
In reply to this post by Nicolas Cellier
On 10.03.2010, at 14:28, Nicolas Cellier wrote:
> > > Unfortunately, this change is unlikely to be portable because it > overrides internal Parser/Compiler methods. Not true. The Parser/Compiler changes are purely optimization. Simply look at the actual implementation of #future - it does work, just not very efficiently. - Bert - |
|
|
In reply to this post by Nicolas Cellier
The compiler is a module isn't it? (It isnt?) Perhaps it could do with being more modular in itself.
You can ask him to package the core functionality separately from the integration functionality.
What you describe is your own personal offline development. When you have something to offer for integration, you can publish it in a form that is usable. i.e. if you publish it as a delta on a known image then it is easy to see what the innovation consists of. if however you roll it into the rolling trunk without any base line, it becomes absorbed into the blob.
Forking is old hat, when you can load the features you want. Keith
|
|
|
In reply to this post by Bert Freudenberg
2010/3/10 Bert Freudenberg <[hidden email]>:
> On 10.03.2010, at 14:28, Nicolas Cellier wrote: >> >> >> Unfortunately, this change is unlikely to be portable because it >> overrides internal Parser/Compiler methods. > > Not true. The Parser/Compiler changes are purely optimization. Simply look at the actual implementation of #future - it does work, just not very efficiently. > > - Bert - > OK optimization apart, it's just a class and two messages. Anyway, my point is that some kernel changes are to be done N-times, whatever the tool used. For example, when I changed TextStopConditions, I could not port directly to pharo, neither a changeSet, nor a MC package, because the two already had differences (scanSelectorAt: and others...). So, I just port the idea, not code, and I redo. I guess it would be the same for Cuis, because Cuis does not have multilingual. At a certain point of divergence, that is necessary... Nicolas |
|
|
In reply to this post by keith1y
2010/3/10 keith <[hidden email]>:
> > Keith, > Unfortunately, this change is unlikely to be portable because it > overrides internal Parser/Compiler methods. > > The compiler is a module isn't it? (It isnt?) Perhaps it could do with being > more modular in itself. > > Due to this, all the noble features that you wish are void. > The job has to be done N times for N images, independently of the tool > used, this has nothing to do with MC. > > You cannot ask each guy to provide an N-images compatible change, or > set of changes, This is not practicle, and simply won't work. > > You can ask him to package the core functionality separately from the > integration functionality. > > With > such a policy, progress will soon stop. > Pharoers program for Pharo, squeakers for trunk, etc... > > What you describe is your own personal offline development. > When you have something to offer for integration, you can publish it in a > form that is usable. > i.e. if you publish it as a delta on a known image then it is easy to see > what the innovation consists of. > if however you roll it into the rolling trunk without any base line, it > becomes absorbed into the blob. > > Then, it does not prevent to exchange ideas and solutions, and it's > better if we exchange before programming. I for sure will support > unification on some Kernel features. But then, we can diverge,or what > exactly is the point of having forks ? > > Forking is old hat, when you can load the features you want. > Keith > Agree, But that's just facts, when I port Pharo<->Squeak, I can't always port source code. > Nicolas > > > > > > |
|
|
In reply to this post by keith1y
I don't have time to spend on this, so I'll use the trick I learned from you and only respond to the points that I feel like. In this case, I chose the points that I can answer briefly. That's not to say that I don't have answers for the others, just that I'm gaining self-control, and experience tells me that it's not worth it to jump back into this quagmire with both feet.
On Mar 10, 2010, at 3:14 AM, keith wrote: > Can you answer if you will, how you have packaged up this "future" innovation so that it would be useful to me? If you mean useful to you to use in Cuis, then I have not. Why do you feel that you are entitled to have me make this available in whichever image you've decided to use? I have not heard users of Cuis, Pharo, or Cobalt ask for this functionality. Why should I spend my limited spare time creating and maintaining loadable packages for these? > > If your answer is that you committed it to trunk, and I am expected to harvest it from trunk, I think you can forget it. It becomes more clear with each of your posts. Your process requires me to do extra work to make functionality available in every Squeak dialect under the sun; you feel that you are entitled to my labor. And what if you start using VisualWorks? Am I then obliged to make it available there, too? Cheers, Josh |
|
|
In reply to this post by Nicolas Cellier
On 10 Mar 2010, at 16:13, Nicolas Cellier wrote: > 2010/3/10 Bert Freudenberg <[hidden email]>: >> On 10.03.2010, at 14:28, Nicolas Cellier wrote: >>> >>> >>> Unfortunately, this change is unlikely to be portable because it >>> overrides internal Parser/Compiler methods. >> >> Not true. The Parser/Compiler changes are purely optimization. >> Simply look at the actual implementation of #future - it does work, >> just not very efficiently. >> >> - Bert - >> > > OK optimization apart, it's just a class and two messages. > Anyway, my point is that some kernel changes are to be done N-times, > whatever the tool used. Its only an example... and you may know that it is a class and two messages but I don't. Why don't I know because there is no where that it says that it is only a class and two messages. I don't know what it depends on and what depends on it either. It could be packaged as a class and two messages then. I will do that. > For example, when I changed TextStopConditions, I could not port > directly to pharo, neither a changeSet, nor a MC package, because the > two already had differences (scanSelectorAt: and others...). > So, I just port the idea, not code, and I redo. I am not a fan of this piecemeal approach, I guess you are kind of forced to do it this way because you don't have enough control of the host image. My preferred approach would be to make the existing module modular and pluggable, then replace the whole module with your better one. This is how I am doing the changes/sources refactoring. > I guess it would be the same for Cuis, because Cuis does not have > multilingual. Take a simpler example Cuis doesnt have styled comments or source. My ExporterFileOut code is written for Cuis, but pharo/squeak simply subclass and specialise one method to add styled text support. This only works if you design the module with this in mind. So basically you have to expect to replace anything someone does with a non-modular mindset. > At a certain point of divergence, that is necessary. K |
|
|
In reply to this post by Josh Gargus
On Wed, Mar 10, 2010 at 01:56:13AM -0800, Josh Gargus wrote:
> > Hi. Someone > > "Keith". > > > noticed on IRC today that Object >> future (and > > friends like futureSend: and the compiler optimization of > > future) are kind of odd things to have in the base image. > > Yes, he was temporarily away from the community during the > discussion about it. I added the changes to the Inbox I see. It is useful outside the context of Croquet. Fair enough > TFutureMaker and FutureMaker should be perfectly compatible; > they both result in #futureSend:at:args: being sent to the > target object. The question is what to do with the default > implementations of #futureSend:at:args: and #futureDo:at:args: > in Object. Ok. I'm looking into how to best merge Cobalt given that future is now implemented correctly in trunk. There is also a second type of indirect message send in Croquet, the syncSend. I think the correct implementation of it in a non-island environment would be to just execute the message, but I'm not sure. It has a corresponding TMessageMaker class (of which TFutureMaker is a subclass). FutureMaker in trunk is identical to a flattening of TMessageMaker and TFutureMaker. Should I implement syncSend in trunk as well? Do I understand it's semantics correctly? It may be better to leave future in trunk alone and implement syncSend in cobalt as it was before; it's semantics are rather specific to island environments. To do this, I think I would reverse the class hierarchy: base TMessageMaker on trunk's FutureMaker, and drop TFutureMaker from cobalt. Any ideas as to what I should do? -- Matthew Fulmer (a.k.a. Tapple) |
|
|
On 3/10/2010 11:35 AM, Matthew Fulmer wrote:
> It may be better to leave future in trunk alone and implement > syncSend in cobalt as it was before; it's semantics are rather > specific to island environments. To do this, I think I would > reverse the class hierarchy: base TMessageMaker on trunk's > FutureMaker, and drop TFutureMaker from cobalt. > > Any ideas as to what I should do? The message #syncSend: is not meaningful outside of Croquet, and even in Croquet it's a bit of a hack. As a consequence there is no point in introducing it in Squeak in general. TMessageMaker / TFutureMaker: I would recommend keeping both and simply leave the implementation of Object>>future alone. There is no harm in having an extra class for historical reasons until you feel confident about the system. Rebasing TMessageMaker on FutureMaker: You could do that, but I wouldn't. A TMessageMaker isn't a FutureMaker, it's actually a different beast. Unless you feel very strongly that you don't want to duplicate a handful of methods, I'd leave it alone. Cheers, - Andreas |
|
|
In reply to this post by Josh Gargus
Because if you had thought about the problem first, in the light of the fact that we are living in a multi-fork world, then your innovation could have been designed to be potentially loadable in all forks from the start, and derived images (with tool support to help you with building and testing it in all targets) , and you could have used 3.10.2 as one example use case of the integration of that innovation, for others to copy. This is what us package developers have been doing for years. If I can do it for Rio, and Logging, you can do it for your stuff too. The crime is that the process you are using, "trunk" causes you by default to think and act as if you are in a one fork moving target world, and to think in a "I will just throw this in for good measure" manner. The end result being that your efforts integrating it into trunk will inevitably have to be repeated by others. However those others do not have your knowledge and will all have to reverse engineer everything you did and guess at all of your design decisions and the fixes you had to add to trunk to accommodate. This means that the net result for the community is that you, in your attempt to provide a simple new feature just for your own pleasure, have actually generated work for other people, and this is what i think can be improved. What is needed is some form of knowledge capture on the way. I am not saying you have to package it as loadable for everyone, but it would be helped by a process which identifies your work as a discrete separate lump, rather than mixing it in with everything else. If you had simply developed it for 3.10.2 rather than trunk, that would have done the trick. In the "grow" scheme I have 4 or 5 kernel innovations on the go. But they are all being developed relative to the base-dev image. This keeps things uncluttered. If these innovations interfere unduely with one another then this is a clue that I need to improve their modularity. It is then trivial to generate a build with all 5 innovations loaded, even though it may not work immediately. If one of the five innovations loads in cuis-base-dev, then the knowledge I need to make that happen is captured in the fixes that go into the cuis-base-dev package. When I load it into pharo, I port just that knowledge, into the pharo-base-dev package. As the base-dev images get more api commonality. Then when it comes to porting the other 4 innovations, to the other forks it gets easier. Keith |
|
|
2010/3/10 keith <[hidden email]>:
> > Why do you feel that you are entitled to have me make this available in > whichever image you've decided to use? I have not heard users of Cuis, > Pharo, or Cobalt ask for this functionality. Why should I spend my limited > spare time creating and maintaining loadable packages for these? > > > Because if you had thought about the problem first, in the light of the fact > that we are living in a multi-fork world, then your innovation could have > been designed to be potentially loadable in all forks from the start, and > derived images (with tool support to help you with building and testing it > in all targets) , and you could have used 3.10.2 as one example use case of > the integration of that innovation, for others to copy. Keith, This is absurd. We can not develop trunk patches in 3.10.2. If it would be true, that would mean that you can take all the "patches" applied from 3.10.2 up to latest trunk and reload them in any order. I really want you to try before speaking. I wonder what other squeakers think about closures/faster sets/new trailers/SmalltalkImage etc... : - shall we revert them and wait for a better engineered universal loading procedure ? - or are we happy with a better than nothing trunk-only version ? In fact, these are not even trunk-only, because Juan, you and pharoers can take a part of the burden and port important things to fork. I don't say that the statu quo is ideal, nor that we should not improve inter-fork exchange, but Keith, not this model please ! Nicolas > This is what us package developers have been doing for years. If I can do it > for Rio, and Logging, you can do it for your stuff too. > The crime is that the process you are using, "trunk" causes you by default > to think and act as if you are in a one fork moving target world, and to > think in a "I will just throw this in for good measure" manner. > The end result being that your efforts integrating it into trunk will > inevitably have to be repeated by others. However those others do not have > your knowledge and will all have to reverse engineer everything you did and > guess at all of your design decisions and the fixes you had to add to trunk > to accommodate. > This means that the net result for the community is that you, in your > attempt to provide a simple new feature just for your own pleasure, have > actually generated work for other people, and this is what i think can be > improved. What is needed is some form of knowledge capture on the way. > I am not saying you have to package it as loadable for everyone, but it > would be helped by a process which identifies your work as a discrete > separate lump, rather than mixing it in with everything else. > If you had simply developed it for 3.10.2 rather than trunk, that would have > done the trick. > In the "grow" scheme I have 4 or 5 kernel innovations on the go. But they > are all being developed relative to the base-dev image. This keeps things > uncluttered. If these innovations interfere unduely with one another then > this is a clue that I need to improve their modularity. > It is then trivial to generate a build with all 5 innovations loaded, even > though it may not work immediately. > If one of the five innovations loads in cuis-base-dev, then the knowledge I > need to make that happen is captured in the fixes that go into the > cuis-base-dev package. When I load it into pharo, I port just that > knowledge, into the pharo-base-dev package. As the base-dev images get more > api commonality. Then when it comes to porting the other 4 innovations, to > the other forks it gets easier. > Keith > > > > |
|
|
however not quite in any order though, dependencies can be defined if needed. Check the "theory of patches" used by "darcs" SCM. This is fairly close to the hypothesis behind darcs. However you cant do this with trunk because, you have a years worth of work in trunk. If you do not release more often, your deltas become too large to manage on this basis. The original goals for developing the release process included monthly time boxed releases. (slowed down to bi-monthly to allow everyone to keep up) When "trunk" is proposed, why didn't anyone ask the question, how long till the next release, over a year... forget it. Point of fact, the time is soon approaching when we will have waited longer for a release from the trunk process, than I was allowed on 3.11.
Well firstly you could have actually tried using the loading procedure that I put so much time into developing rather than ignoring it. Secondly at the point when Andreas override my work, I was documenting bob on vimeo, bob was released in February 2009, so you could have used it then. So what were you thinking you had to wait for? Secondly release teams have been saying that they wanted atomic loading for, I don't know 5 years now?!? Where is it if it is such a priority for making things easier?
If you are happy to settle for a better than nothing solution, you could have had the courtesy to actually ask what the state of play was on bob stuff before replacing it, with a worse than nothing solution.
This is where the problem lies. We would love to, however you have explicitly chosen a process which makes this hard, and you have put the knowledge in a form which is very difficult to harvest. It will usually take as much effort to port it as to implement it in the first place. So trunk is no help there.
Dont develop fixes on top of fixes on top of fixes, and then expect someone else to sift through and work out what the hell is going on. Develop ONE fix, and refine it over time, when it is ready publish it, and a single discrete lump, against a known fixed point, that you can see the delta clearly. Keith |
|
|
2010/3/10 keith <[hidden email]>:
> > Keith, > This is absurd. We can not develop trunk patches in 3.10.2. > If it would be true, that would mean that you can take all the > "patches" applied from 3.10.2 up to latest trunk and reload them in > any order. > > Correct. > however not quite in any order though, dependencies can be defined if > needed. Check the "theory of patches" used by "darcs" SCM. This is fairly > close to the hypothesis behind darcs. > However you cant do this with trunk because, you have a years worth of work > in trunk. If you do not release more often, your deltas become too large to > manage on this basis. > The original goals for developing the release process included monthly time > boxed releases. (slowed down to bi-monthly to allow everyone to keep up) > When "trunk" is proposed, why didn't anyone ask the question, how long till > the next release, over a year... forget it. > Point of fact, the time is soon approaching when we will have waited longer > for a release from the trunk process, than I was allowed on 3.11. > > I really want you to try before speaking. > I wonder what other squeakers think about closures/faster sets/new > trailers/SmalltalkImage etc... : > - shall we revert them and wait for a better engineered universal > loading procedure ? > > Well firstly you could have actually tried using the loading procedure that > I put so much time into developing rather than ignoring it. > Secondly at the point when Andreas override my work, I was documenting bob > on vimeo, bob was released in February 2009, so you could have used it then. > So what were you thinking you had to wait for? > > Secondly release teams have been saying that they wanted atomic loading for, > I don't know 5 years now?!? Where is it if it is such a priority for making > things easier? > > - or are we happy with a better than nothing trunk-only version ? > > If you are happy to settle for a better than nothing solution, you could > have had the courtesy to actually ask what the state of play was on bob > stuff before replacing it, with a worse than nothing solution. > > In fact, these are not even trunk-only, because Juan, you and pharoers > can take a part of the burden and port important things to fork. > > This is where the problem lies. We would love to, however you have > explicitly chosen a process which makes this hard, and you have put the > knowledge in a form which is very difficult to harvest. > It will usually take as much effort to port it as to implement it in the > first place. So trunk is no help there. > > I don't say that the statu quo is ideal, nor that we should not > improve inter-fork exchange, but Keith, not this model please ! > > Well I would say the same thing. Not this model please, anthing but this. > Dont develop fixes on top of fixes on top of fixes, and then expect someone > else to sift through and work out what the hell is going on. > Develop ONE fix, and refine it over time, when it is ready publish it, and a > single discrete lump, against a known fixed point, that you can see the > delta clearly. > Keith > Take the changes of Sets: they are faster and can include nil. Also, IdentitySet scale far better. What do you suggest ? Have only one change every two months ? Tell Levente "no no, we cannot accept your contribution, it's too fast" ? Nicolas |
|
|
In this case you would treat Sets as a load-able module managed outside of the image, publish version 1.0. Levente makes his changes available as version 1.0.1, and they are immediately available to all forks. When the next monthly build comes around it loads the latest version of Sets, and runs tests. If it breaks then some patches are required somewhere either before or after it loads. These patches are a "slice" of integration code that apply to this image only. Along comes Juan, wanting to load Sets, and he can see the implementation, before and after, and the integration code. All he has to do is come up with his own integration code. - If the Api changes significantly, then you have to be more creative, and there are a number of options. 1. Load both api's simultaneously, in parallel with poor mans namespaces, or real namespaces if you have them. 2. Use facades to provide a common face to two api's, and a switch between them. 3. Refactor all users of FIleDirectory into a recognizable protocol (method category, or tagged), that can be replaced in one simple slice. Keith |
|
|
2010/3/11 keith <[hidden email]>:
> > Take the changes of Sets: they are faster and can include nil. Also, > IdentitySet scale far better. What do you suggest ? > Have only one change every two months ? > Tell Levente "no no, we cannot accept your contribution, it's too fast" ? > > Nicolas > > In this case you would treat Sets as a load-able module managed outside of > the image, publish version 1.0. > Levente makes his changes available as version 1.0.1, and they are > immediately available to all forks. > When the next monthly build comes around it loads the latest version of > Sets, and runs tests. If it breaks then some patches are required somewhere > either before or after it loads. These patches are a "slice" of integration > code that apply to this image only. > Along comes Juan, wanting to load Sets, and he can see the implementation, > before and after, and the integration code. All he has to do is come up with > his own integration code. > - > If the Api changes significantly, then you have to be more creative, and > there are a number of options. > 1. Load both api's simultaneously, in parallel with poor mans namespaces, or > real namespaces if you have them. > 2. Use facades to provide a common face to two api's, and a switch between > them. > 3. Refactor all users of FIleDirectory into a recognizable protocol (method > category, or tagged), that can be replaced in one simple slice. > Keith > Well, the public API did not change. But the changes were deeper than Set. They contaminate the whole hierarchy down to MethodDictionary. They also concern changes of identityHash. So it is not solvable with an External package. That's a typical case where continuous integration helps. I'm convinced such work must be redone from scratch in each fork... ... or maybe re-buidling the whole image like gst. But it's not yet an option in Squeak. Nicolas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |