[Cuis] Cuis
Locked
1 ...
3456789
1 ...
3456789
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
 
|
2010/1/24 Igor Stasenko <[hidden email]>:
> 2010/1/24 keith <[hidden email]>: >> >> What's your goal ? >> Develop an application ? >> Develop a cross-fork module/package/library ? >> >> Both: Develop an application using cross-fork packages. >> However the way things are going, its all I can manage to do the >> application, keeping all the balls in the air is a problem. >> > > Developing an application means freezing a set of dependencies. > If you're not freezing them, then you not developing an application, > you just toying. > > Because, you'll never know that might be broken, when you update > dependencies to the latest, > so you are always doing it at own risk (and don't blame the devs about > breaking things - its absurd), because despite what package maintainer > says, there are always a chance that with even little and minimal > update, your application could stop working normally. > This is what we calling 'moving target'. > Sure thing, if package maintainer tries to preserve compatibility, > then in 99% cases everything ok, but if he not - then its up to you > to manually update the application to conform with newer version of > package. And always will. > > The only class of updates, which can be acceptable in such ecosystem > is bug fixes. But if you need to move forward, like introduce new & > better stuff, or remove obsolete cruft, you inevitably will meet > compatibility problems. > > Honestly, what kind of automation you can invent here to migrate your > application from using package version A, > to package version B , which potentially, can be completely rewritten > from scratch? > You doomed to either stay with version A, or do a lot of manual work > migrating to version B and no magic tool will help you with that. > > About cross-fork package development. > > Each package having an environment-agnostic behavior , and environment > dependent. > The goal of developer is to identify these parts and connect them nicely. > But this is gone too far. It is now about defining and enforcing a > good practices in package development to avoid cross-dialect pitfalls. > How many packages we has built with cross-compatibility in mind? > How many packages having all globals declared in a single place, not > scattered among code? > And what automated tools can solve the problems, when your package > code using 'SmalltalkImage current' instead of 'Smalltalk'? > > >> If the later (RIO), then use what every other cross-fork do, >> compatibility layers (Grease...). >> >> Never heard of it, I have been out of the loop for a while. >> Is grease a package? why didn't whoever developed Grease, add to LPF which >> is already doing this? Or perhaps we just need to add Grease to LPF. >> >> Otherwise, concentrate on the fork you have chosen and let people port >> if they are interested. >> >> I haven't chosen a fork, I was going to use pharo, but found it somewhat >> reliant on OB which I dont get along with. >> So discovering that I didnt actually have a fork that I found interesting I >> cam back here to see if cuis would do the trick. >> this looks like it might be too much work. >> So I will probably just stay where I am, earn some money and employ someone >> else to port things later on (you never know). >> In the meantime the community looses the maintainence of any of the >> cross-fork packages I already provide. >> Keith >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > Sure. Continuous integration is not that easy. However, I would try to make new developments in the bleeding edge version for these reasons: - react early to uncompatible changes - propose hooks to reduce the level of kernel patching You can't control everything but it's better to keep an eye opened rather than discovering unwanted changes lately. And it's even better if you can bend some developments toward your own direction. Nicolas |
Re: Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> >>> May I point out again that it doesn't work for me. My patches to trunk >>> would >>> be fixes for Monticello. These fixes would break trunk, therefore it >>> doesn't >>> work as you suppose. >> >> Strange, then , why calling it fix - fixes usually not breaking existing >> stuff. >> Call it replacement or rewrite, or upgrade, but not 'fix'. > > I think AGAIN you are missing the point completely > > Monticello cant load itself for anything other than the most minor of > changes. > See my other reply. MC can load code, which can do anything with MC. > Keith > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
No automation at all is needed.
Again no automated tools. I think you are getting hung up on the automated tools thing. Automation is nothing to do with this discussion. I am not asking you or anyone to automate tools or anything. I am asking you to use a process of thinking that documents what you do, in a way that enables it to be routinely harvestable. Its a process of knowledge capture. You can write it on paper if you like: Example: If you write me an explanation of how to install closures, it will be a lot easier to write if you say.... Start with a 3.10-release image. Do a,b,c,d,e and you will have a closures image, we shall call 3.10-closures. As a trunk developer you cant write me this explanation. If you write me an explanation of how to install closures following trunk, it will be... Hmm when we did it we had this image that was hacked on by 10 people, so this is how I did a,b,c,d,e but I cant be sure that this will work for you. that is the difference, and my example from the bazaar documentation clearly shows the difference Keith |
|
|
In reply to this post by Nicolas Cellier
I totally agree. It is much better to not get left behind too much. However the bending bit, you suggest is virtually impossible in this gang, that is why LPF exists, because any fix you suggest to the image, you will have to wait 2 years for integration into a release. That is also why Sake/Packages exists so you can patch other people's stuff a bit. Keith |
|
|
In reply to this post by Igor Stasenko
On 24 Jan 2010, at 18:55, Igor Stasenko wrote:
I look forward to seeing trunk with MC1.5 then, cool Keith |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by Nicolas Cellier
2010/1/24 Nicolas Cellier <[hidden email]>:
> > Sure. > Continuous integration is not that easy. > However, I would try to make new developments in the bleeding edge > version for these reasons: > - react early to uncompatible changes > - propose hooks to reduce the level of kernel patching > You can't control everything but it's better to keep an eye opened > rather than discovering unwanted changes lately. > And it's even better if you can bend some developments toward your own > direction. > Well, you can. But i think , then it is hard to separate the goals of what you want from your application and what you want from package (or system) in general. This could lead to inversion of your model, where design of base packages tends to serve only for your application and almost nothing else. We have a lot of such kind of things in squeak, where a package which should provide a generic interfaces, concentrating on some obscure bit of functionality, which used only in a single place of some dependent application/package. > Nicolas > > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak core dev is now like every other open source project! (was Re: [squeak-dev] [Cuis] Cuis)
|
|
In reply to this post by keith1y
2010/1/24 keith <[hidden email]>:
> > On 24 Jan 2010, at 18:55, Igor Stasenko wrote: > > 2010/1/24 keith <[hidden email]>: > > May I point out again that it doesn't work for me. My patches to trunk > > would > > be fixes for Monticello. These fixes would break trunk, therefore it > > doesn't > > work as you suppose. > > Strange, then , why calling it fix - fixes usually not breaking existing > > stuff. > > Call it replacement or rewrite, or upgrade, but not 'fix'. > > I think AGAIN you are missing the point completely > > Monticello cant load itself for anything other than the most minor of > > changes. > > > See my other reply. MC can load code, which can do anything with MC. > > I look forward to seeing trunk with MC1.5 then, cool if you remember, i already raised this topic here and in Pharo list. The problem is, that (as you pointing in another thread about capturing knowledge), there's no one left, having such knowledge about MC 1.5., to do such integration. > Keith > -- Best regards, Igor Stasenko AKA sig. |
Re: Squeak core dev is now like every other open source project! (was Re: [Cuis] Cuis)
|
|
Igor Stasenko wrote:
> 2010/1/24 keith <[hidden email]>: >> >> I look forward to seeing trunk with MC1.5 then, cool > > if you remember, i already raised this topic here and in Pharo list. > The problem is, that (as you pointing in another thread about > capturing knowledge), there's no one left, > having such knowledge about MC 1.5., to do such integration. We did the experiment earlier: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140345.html The problem is that MC 1.5 and 1.6 appear to be buggy in various areas and don't appear ready for prime time. Cheers, - Andreas |
|
|
In reply to this post by FDominicus
On Jan 23, 2010, at 10:44 PM, Friedrich Dominicus wrote: > Josh Gargus <[hidden email]> writes: > >> >> >> The "community" doesn't want only one thing, and different people in it want >> different things to different degrees. I don't dispute that what you have >> described above is desirable, in principle, to the vast majority of community >> members. However, it is fundamentally at odds with other goals that various >> community members hold dear. A balance must be struck. > You are right, but let's as it that way: > - how many of you do activly work in the "Kernel!" > - how many of you do use it for application development > > I would be suprised to see a ratio much higher than 1:10 000 or even > 1: 100 000 (kernel dev/application dev). > > As I understand Keiths posting he's mainly an application developer and > so it's clear that he does not like to re-write his code over and over > again (for whatever good/bad technical reason). > > I just can tell you a story from Eiffel wonderland where this ratia > surely was much more in favour of "application" developers. One > development team in Eiffel has broken old code with nearly every "minor" > update. This means software once written and "working" just stops. If > you ever have encountered that, you surely will understand Keiths points > very well. > > There's IMHO no better way to drive away people but to break their code > over and over again... > Fair enough. These are eminently valid concerns. I'm not yet convinced that the trunk approach is doomed to break everything, or that Keith's approach is necessarily any better. However, I do want to end this smoldering flame war once and for all. So, I guess we're going to have to get to the bottom of this... >> >> Here's a very specific example. I would like to see more integrated support >> for concurrent programming in the Squeak kernel. Toward that end, >> I've added a >> trivial implementation of "promises" to the trunk (hopefully, I'll take it >> further relatively soon... one of the things I've done in the interim was to >> re-read Mark Miller's dissertation). > Well so you are interested in another thing. Nothing wrong with that, right? The goals of my post were as follows: - to establish clearly that compatibility is not the only thing that the community cares about (it also cares about "progress") - to determine whether Keith acknowledges this fact - if so, to determine whether his approach may address the issue in some way that I missed > Well so you probably do not > see the points of Keiths mails. But I do, at least regarding the outcomes that he hopes to avoid. I'm just not convinced that his proposal the right way to go, but I'm making an honest effort to understand the issues. Cheers, Josh > > > Regards > Friedrich > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > |
|
|
In reply to this post by Andreas.Raab
On 24 Jan 2010, at 19:19, Andreas Raab wrote:
I have been using them for years now without trouble. How you cope with the old MC I dont know. I cant use it, it looses overides, and you have to maintain a separate image for every package you contribute to. MC1.6 should be less buggy, if traits support was finished. Keith |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
On Sun, Jan 24, 2010 at 10:59 AM, keith <[hidden email]> wrote:
I did that already. See http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt from http://www.mirandabanda.org/cogblog/downloads/. There are two problems with this.
1. the closure bootstrap is tricky (ask Juan). The closure bootstrap has to replace the compiler in just the right order so that the old compiler keeps working until the new compiler is ready to take over. Turns out that this is very sensitive on what you start from. The ocmpiler in 37 is different form that in 3.8 and 3.9. The compiler in a Croquet mage is different. Things are different if FFI is loaded, if Vassili's variadic ifNotNil: code is in or not, if pragmas are in or not. I provided two different bootstraps Croquet 1.0& Squeak 3.9 and did a third one in-house at Teleplace. I don't have the time to do a generic one and in fact I don't think it's practicable.
2. the closure code has evolved since the bootstrap. People found bugs and provided tests and I changed the closure analysis to compile inlined blocks (to:by:do: whileTrue: et al) correctly, and fixed debugger bugs, and provided support for closurised compressed temp names. Then Igor reimplemented the compressed temp names/surce pointer scheme to mase it much better and much more general. I discovered Colin Putney had done a really nice compiler error formaework that wasn't in the original. Now two things follow
a) it is simply way too expensive to go back and revamp those two bootstraps so that they end up at the new bugfixed improved code. b) it is pointless; Pharo, Cuis and Squeak trunk have all moved on from their pre-closure starting point. What they need is incremental bug fixes installing in their current state.
So what are the instructions to install closures now? As I'm planning to do this for Etoys sometime soon this is not hypothetical. The basic approach is to compare the starting point with the desired end-point packages (choose Compiler & Kernel-Methods and sundry associated extensions, being familiar with the compiler will make this easier, but its tediously error-prone). Then produce a set of file-ins that gets from the starting-point to as close to the end-pont ass results in a functioning compiler and Monticello. Load the relevant packages and you're done.
And the way I do that is that I file-in until something breaks (as it will, an MNU in the compiler will typically break the debugger because the debugger uses the compiler to create the source map for a method). When something breaks (usually the system locks up with an infinite recursion) I kill it, restart and use recently logged changes to find out what was the last method that I brought in that broke things and then I try and figure out why. SqueakDebug.log probably didn't get the error written to it because the crash was so deep-seated, so some head scratching is required. Then rinse and repeat. Eventually one has closures filed-in.
So - it isn't automatable, it isn't trivial and it isn't very hard; just tedious. Trying to do this will teach you much about the core of the system. People have worked out how to do this without asking me a single question, working out the above process themselves because its obvious. Ask Juan.
So why don't you have a go?
Bollocks.
|
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by Igor Stasenko
2010/1/24 Igor Stasenko <[hidden email]>:
> 2010/1/24 Nicolas Cellier <[hidden email]>: >> >> Sure. >> Continuous integration is not that easy. >> However, I would try to make new developments in the bleeding edge >> version for these reasons: >> - react early to uncompatible changes >> - propose hooks to reduce the level of kernel patching >> You can't control everything but it's better to keep an eye opened >> rather than discovering unwanted changes lately. >> And it's even better if you can bend some developments toward your own >> direction. >> > > Well, you can. But i think , then it is hard to separate the goals of > what you want from your application > and what you want from package (or system) in general. This could lead > to inversion of your model, > where design of base packages tends to serve only for your application > and almost nothing else. > We have a lot of such kind of things in squeak, where a package which > should provide a generic interfaces, > concentrating on some obscure bit of functionality, which used only in > a single place of some dependent application/package. > Since you can't fully control, you also have to convince. Nicolas >> Nicolas >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
|
|
In reply to this post by Josh Gargus
Hello Again Josh,
We were clearly told by the board years ago, that stella-progress was going to come in Squeak 5.0. In fact squeak 5.0 would have more progress than you could shake a stick at. They were so confident of this fact that at one point they cancelled 3.x development altogether. It is common for open source projects to maintain two branches, the red/blue pills, the blue/pink planes etc. Squeak 5.0 is the place for progress, 3.x is the place for stability. Simple as. So as an application developer, I don't want progress that does anything at all to rock the boat, I want stability increases and speed improvements month on month that is all. Anything else is not progress, its a pain in the rear. Fonts and traits I can do without. I have nothing against progress that has been thought about, and tested fully and is optional for me to load. (its called a package, every innovation can be delivered as a package, even a changeset can be delivered as a loadable package) Every innovation in the "3.x stable plane" should be developed, tested, COMPLETELY FINISHED and made loadable into 3.10 (and 3.9) since they are practically the same, so that all legacy code in 3.10 and 3.9 continues to work and there are no surprises. "trunk" is the pursuit of random "progress", on the fly, hacking, without thinking in advance, and without making the knowledge available in a usable form for anyone who is not in the "trunk" fork, and without a continuous testing framework. Trunk is purposefully a fork away from (3.9 and 3.10) And I cant tell my clients what is coming in 1 months time let alone a years time. If you want progress without compatability, go and nag Craig, who said he would deliver Squeak 5.0 18 months ago. Andreas should have supported, worked with and annoyed Craig, not me. All of "trunk" effort should be producing 5.x on top of spoon, not 3.x.
So yes I think you missed the point of my belief that we are supposed to be supporting squeak as a professional development product with a professional attitude. Currently the attitude is, release the image, forget about it, and move on to the next release, which will probably not be compatible with the previous one, and definitely will not have a migration path for you, sure we might fix some stuff but if you want to use it, you have to take all the pain of keeping up. 3.10 as a release should be a stable supported release, with fixes and improvements that do not break compatibility or continuity in 3.11 3.12 etc etc. The 3.x team is responsible for providing 3.x-1 users a migration path, and the easiest way to achieve this is to make all 3.x-innovations, optional loads into 3.x-1. Its not hard, its just a matter of making the choice not to group-hack. So when a professional developer starts using 3.10, he is continuously supported, with bug fixes, managed in a bug fix database, and new versions, all of which maintain compatibility. So the board's first responsibility is to support the existing users of squeak, by making sure that the maintained version is maintained, and "progress" occurs within the capabilities of the existing users. I do not have the ability to load closures into 3.10 on my own, this is a serious issue. By not insisting that closures are loadable into a raw 3.10 the board is letting me down. Secondly they want to make a brand shiny new product, to attract new users with new flashy capabilities. However, it is absolutely stupid to use one as a club to kill the other. Given that the "trunk" is not providing the migration path, it is a year away form being ready for me to use, and there is no ongoing support for me as a 3.10 user. I am very concerned that squeak was a bad choice to make as a development tool, that I had the cheek to sit in meetings with clients and say, its ok, we can develop stuff and it will keep going for years to come. Keith |
|
|
In reply to this post by Eliot Miranda-2
> > As a trunk developer you cant write me this explanation. If you > write me an explanation of how to install closures following trunk, > it will be... Hmm when we did it we had this image that was hacked > on by 10 people, so this is how I did a,b,c,d,e but I cant be sure > that this will work for you. > > Bollocks. That is precisely the explanation you just gave me, you said, "load these things, but results may vary." You didn't say, "load this and it will work, because I tested it." Keith |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
thanks for these
Agreed, however I do think that this should be motivation to adopt AtomicLoading, it was one of our top priorities. It does work you know. It is just traits that are not supported. Do you think that this would help?
Can allegedly be rebuilt on top of their pre-closure starting point.
How about, LPF loads MC1.5 into 3.8 and etoys2. So if I am not mistaken porting SystemEditor to 3.8 (if matthew hasnt already done it for cobalt), will provide AtomicLoading to, 3.8, etoys2, sophie, and Cobalt, amongst others. or am I an incurable optimist? regards Keith |
|
|
In reply to this post by Randal L. Schwartz
On Jan 24, 2010, at 8:08 AM, Randal L. Schwartz wrote: > Why is this viewed so much different from every other open source > project? > > Do you keep installing the daily release of the Linux Kernel on your > server machines? No! > > You wait for a major release of Fedora, or Debian, or Ubuntu, which > happens > every six months or year. One exception, of course, is bug and security fixes. I *want* to keep my production CentOS box up to date with bug and security fixes. I understand that those changes are going to come on their own timeframe. I do *not* necessarily want to track every new release of the OS. That, in my view, is a big drawback to the monolithic trunk update stream: it mixes (for example) important bug fixes with (for example) updates and extensions to browsers. So it would be nice if we had some code/tool/community support for dispersing code broadly to as many "forks" as possible, where "fork" means not just things like Pharo and Cuis but also older versions of Squeak and my little Squeak/Seaside image running on my CentOS box where I want to load as little code as possible so as to lower the chance of breaking something. David |
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
On Jan 24, 2010, at 2:04 PM, keith wrote: > >> >> As a trunk developer you cant write me this explanation. If you write me an explanation of how to install closures following trunk, it will be... Hmm when we did it we had this image that was hacked on by 10 people, so this is how I did a,b,c,d,e but I cant be sure that this will work for you. >> >> Bollocks. > > That is precisely the explanation you just gave me, you said, "load these things, but results may vary." > > You didn't say, "load this and it will work, because I tested it." He said "results may vary" because he didn't test it, not (as you imply, using clearly fallacious logic) because it would be impossible to write an explanation for trunk. The reason that your straw man is incorrect is that, if he set out to write a set of instructions, it would be against a known version (probably Squeak3.11-8931-alpha, released yesterday). It would not be against some random image with unknown code in it. Such a set of instructions would be no more difficult to create than for 3.9 or Cobalt. I'm very suspicious of all of your arguments of the form "I'll have to wait a year for the next release", because trunk images have been coming out at the rate of 1-2 per month since September. Why can't you try to load your codebase against each new trunk release, and holler if compatibility is gratuitously broken? Probably the breakage was accidental, and can easily be rectified. Cheers, Josh > > Keith > |
|
|
In reply to this post by keith1y
On Jan 24, 2010, at 1:50 PM, keith wrote:
True. I'm not sure it there's a point being made here, or if this is just a lead-in?
This doesn't make any sense. Spoon is apparently not coming. Why should that prevent me from having my "progress without compatibility" ;-)
Um, wow... What just happened? I stated that not everyone holds cross-fork compatibility as their highest goal, and asked whether you acknowledge this fact. You responded by saying that I don't seem to understand that your highest goal is to support Squeak as a professional development product. How is it possible for you to read what I've written, and say that I don't see that you are primarily concerned with compatibility. I mean, it's all you talk about. I'm looking back through the emails I've written, and my understanding of your general stance of "never break code, ever" shines through everywhere. Unless... Maybe you actually mean what you just literally said above: that *we* (including me, Josh) are supposed to be supporting Squeak as a "professional development product", and if that's not what we're doing, we're shirking our duties. Maybe you really are suggesting that I am obliged to support your vision? If so, think again... I'm under no obligation to do what you want. If not, then what on earth are you talking about?
If this was my attitude, I wouldn't be spending so much time looking for common ground.
The board cannot insist anything, they can only request. What would they say? Eliot, you better create a closure bootstrap for 3.10, or... what?
I'm guessing that you're talking about using the shiny trunk as a way to kill the trusty 3.10. I don't quite understand your analogy though, so I won't say anything further. Cheers, Josh
|
Re: Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]
|
|
In reply to this post by keith1y
On Sun, Jan 24, 2010 at 4:12 PM, keith <[hidden email]> wrote:
Yes, in those versions of Monticello that support it, and only if one can atomically load more than one package (I forgot to say that the closure compiler changes also touch System and Tools, not just Compiler and Kernel-Methods. So relying on solving a really hard problem (atomic loading) before one can solve a smaller problem (closures) wasn't a viable option this time around. But when it is available then of course it's the right approach, _provided_ every distro wants the same Kernel, System, Tools and Compiler and... they all differ, some (System, Tools) significantly. Oops.
I doubt that very much. Of course it is possible, but not without hard work. A naive install of the changed packages will fall over horribly (for reasons I allude to above). At least you have to use a closure-enabled VM.
I don't know, try it (porting SystemEditor and then trying to atomically load closures) and see. You still have to do a merge of the bits of Compiler, Kernel, System and Tools affected by closures to know what to load atomically.
The approach I've been taking does that merge as I go along.
I could care less ;)
|
|
|
In reply to this post by keith1y
On Jan 24, 2010, at 4:44 AM, keith wrote: >> What I really would like is to hear about REAL compatibility problem >> and not supposed compatibility problems. > > The real compatibility problem is this. > > I am working in a 3.10 based image NOW. > > I wont have the opportunity to move my code base and find out what the compatibility problems are until 3.11 is released in 6 months time. I don't understand why this is true. In another post you've described the comprehensive build/test framework that you currently use, and I observed that I cant see any reason why you can't run it against the bi-monthly trunk image releases (or for that matter, against nightly trunk images that you automatically update). > > In that 6 months I will have generated a considerable amount of code, that may be incompatible with 3.11 but I wont have known it. I will also have been saving my packages to squeaksource, but I will not know that these packages are not useful to 3.11 users. All the 3.11 users will load my packages and will either complain or write my code off as "it never works", and I will never find out. > > So, when I finally move my working image to 3.11, all my deployed production images are still in 3.10. So now I have to maintain 2 code bases of my packages. However if I could load a couple of patches into 3.10 that make them API equivalent, I wouldnt have to. Ok to do this I have to manually reverse-engineer the whole of the 3.11 effort. In short it is too difficult to contemplate, because non of the 3.11 effort was done with the expectation that it would need to be re-engineered. > > This is what happened in the case of ifNotNil: ifNotNilDo: merger. I'm not sure what you're referring to. The old method still exists, so no packages that you load can break from it. What am I missing? You were probably just unaware that #ifNotNilDo: still existed. Let's imagine for a moment that Nicholas was overzealous and removed it. If you were to run your automated tests against the latest trunk image, a lot of code would presumably break. You'd look at the failure logs, maybe curse (studies show it makes you feel better!), and fire off a civil email to the list. By the next day, #ifNotNilDo: would exist again. Problem solved. Cheers, Josh |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |