Fwd: Re: DIRECT version number
Locked
12
12
Fwd: Re: DIRECT version number
 
|
Additional stuff about versioning, and how to keep your code working
as Cuis changes.
Please share your ideas and thoughts about this. We all want to ease development and maintenance of all sorts of projects while allowing a moderate rate of change to Cuis itself... Cheers, Juan Vuletich -------- Original Message --------
Hi Hannes, On 7/16/2015 9:57 AM, H. Hirzel wrote: > Thank you Juan, for answering. > > At the moment I feel uncomfortable using Cuis because it is currently > a quite fast moving target. I perceive quite a number of API changes > though this might be wrong. But I do not know because there are no > release notes which summarize it. Yes, that's true. Besides, we don't have a specification of what is an API and what is not. So, almost any change can be considered an API change. I don't want you to feel uncomfortable. Let's work this out. > And I do not now in which state my stuff and the general Cuis stuff ist. > > I need a new 'base line', i.e. a release number to which I can refer > to when upgrading my code. Well, but we do have that. It is the update number. It is part of any Cuis image I've ever committed to the repo. The problem, I think, is not identifying well defined Cuis releases. The problem is knowing how updates could affect your code. > Of course the other option is to just follow the most recent update > all the time. That would call for some kind of continuous integration > testing 'Cuis style' which I not have either. > > E.g. if you could do a writeup how you do test Cuis before each new > commit (there are over 50 this year) and which scripts you use I could > apply the same thing for my packages. > > It has to be something which can be done quickly. Semi-Automatic is > fine. A check list with > > - do this > - then execute that script > - Open .. this and that > - And finally run a report on ... > > would be fine. I don't have that either. I run the tests from time to time (I'll start doing it before any commit, and add the xml report to the rep). But this is not the most important reason why Cuis is solid. Cuis is very reliable because: - I'm not too bad as a coder. - I do my own code revisions at least one day after each change. - I use Cuis every day, and spot most problems in the updates, before commtting them to the repo. - I really, really care about code quality. - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that is a big responsibility, given how important I think Smalltalk-80 is. So, I suggest running your tests when updating your image, or migrating your code to an updated image. In any case, I think this doesn't answer your concerns. What you need is some way to know which updates could affect you, to review them in detail, and understanding their effect on your code. A list of the affected classes and/or methods for each update makes no sense. Cuis can already show you that very easily. Perhaps each update should include: 1) parts of the system that are affected: - Kernel - Compiler - Tools - Morphic - etc 2) Level of risk involved - very unlikely to break code that depends on this part of the system - could perhaps break code that depends on this part of the system - will most likely break code that depends on this part of the system Or something like that. BTW, this is a very relevant topic for discussing on the mail list. Feel free to answer there if you agree. Cheers, Juan Vuletich > However doing a release tag in github is really not a big deal if you > actually take the plunge. > > You are not alone in not using this option. > > It took me two years to realize that I can learn to do it and actually > do a release in 5 minutes..... > > So I suggest do a release just continuing where you left off last time. > > Then people will start to realise there is something to test against. > And new update requests will come and you can do another one. > > So the release which I am asking for is not a big deal. Just a tag on a commit. > > I'd like to explore the direct authoring tools offered by Ken Dickey. > > With the aim of producing a very simple Hypercard / Powerpoint like > authoring environment. > > And do more with OMeta. > > Happy continued Cuis curating ..... > And thank you very much indeed for your great work maintaining this environment. > > > Hannes > > > > On 7/16/15, Juan Vuletich[hidden email] wrote: >> On 7/12/2015 6:27 PM, H. Hirzel wrote: >>> Hi Juan >>> >>> Regarding a Cuis version number. I suggest that you just continue with >>> a new version number where you left off last time. >>> >>> It is just about having a version number to have a new baseline to >>> refer to. This is helpful for testing and documentation. >>> >>> I do not think it is a big issue. >>> >>> API changes require a new version number. >>> >>> Kind regards >>> Hannes >> Hi Hannes, >> >> Sometimes I don't pay enough attention to stuff like this, so feel free >> to request action from me when you feel appropriate :) >> >> Cheers, >> Juan Vuletich >> _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
On Fri, 17 Jul 2015 10:39:47 -0300
Juan Vuletich <[hidden email]> wrote: > The problem, I think, is not identifying well defined Cuis releases. The > problem is knowing how updates could affect your code. This is a large search space. It is easy for some minor change to have a cascaded interaction. In thinking about this, I like to think of aerodynamic drag. I want to be able to make rapid progress, so I like streamlined development processes. I also want stability and robustness. I think the inflection point where we go from laminar to turbulent air flow will change over time. At this point in time, there are the fewest users and projects Cuis is likely to have. I personally favor minimal drag and maximal progress at the expense of stability. As stability becomes more important, added drag (heavier duty release process) is justified. I once was talking with someone about garbage collection and they asked me how I could _prove_ that only "live" objects were left after each GC. I told them it was a "proof by contradiction". I.e. it's not a problem until it becomes a problem. I did software development for a living for a couple of decades. For me (a vote of 1) Release process is not yet a problem. But, hey, I'm an old hacker guy. What does everyone else think? -- -KenD PS: the random progress graphic is totally unrelated to this discussion. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
PropEdit-Screenshot.png (434K)
Re: Fwd: Re: DIRECT version number
|
On 17 Jul 2015 at 7:21, Ken.Dickey wrote:
> On Fri, 17 Jul 2015 10:39:47 -0300 > Juan Vuletich <[hidden email]> wrote: > > > The problem, I think, is not identifying well defined Cuis > releases. The > > problem is knowing how updates could affect your code. > > This is a large search space. It is easy for some minor change to > have a cascaded interaction. > > In thinking about this, I like to think of aerodynamic drag. I want > to be able to make rapid progress, so I like streamlined development > processes. I also want stability and robustness. > > I think the inflection point where we go from laminar to turbulent > air flow will change over time. > > At this point in time, there are the fewest users and projects Cuis > is likely to have. I personally favor minimal drag and maximal > progress at the expense of stability. As stability becomes more > important, added drag (heavier duty release process) is justified. > > I once was talking with someone about garbage collection and they > asked me how I could _prove_ that only "live" objects were left > after each GC. I told them it was a "proof by contradiction". > > I.e. it's not a problem until it becomes a problem. > > I did software development for a living for a couple of decades. > For me (a vote of 1) Release process is not yet a problem. But, > hey, I'm an old hacker guy. > +1 - Dan > What does everyone else think? > > -- > -KenD > > PS: the random progress graphic is totally unrelated to this > discussion. > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
On Fri, 2015-07-17 at 10:39 -0300, Juan Vuletich wrote:
> Additional stuff about versioning, and how to keep your code working > as Cuis changes. > > Please share your ideas and thoughts about this. > > We all want to ease development and maintenance of all sorts of > projects while allowing a moderate rate of change to Cuis itself... > > Cheers, > Juan Vuletich > > -------- Original Message -------- > From: > - Thu Jul 16 10:47:08 2015 > X-Mozilla-Status: > 0001 > X-Mozilla-Status2: > 00800000 > X-Mozilla-Keys: > > > Message-ID: > <[hidden email]> > Date: > Thu, 16 Jul 2015 10:47:06 -0300 > From: > Juan Vuletich <[hidden email]> > User-Agent: > Mozilla/5.0 (Windows; U; Windows NT > 6.1; en-US; rv:1.9.2.28) > Gecko/20120306 Thunderbird/3.1.20 > MIME-Version: > 1.0 > To: > H. Hirzel <[hidden email]> > Subject: > Re: DIRECT version number > References: > <CAGQxfVgD-0tAQxe5bZkYEQX=[hidden email]> <[hidden email]> <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=[hidden email]> > In-Reply-To: > <CAGQxfVhi7=W5c8wZur7aLnKk_wRb=[hidden email]> > Content-Type: > text/plain; charset=UTF-8; > format=flowed > Content-Transfer-Encoding: > 7bit > > > Hi Hannes, > > On 7/16/2015 9:57 AM, H. Hirzel wrote: > > Thank you Juan, for answering. > > > > At the moment I feel uncomfortable using Cuis because it is currently > > a quite fast moving target. I perceive quite a number of API changes > > though this might be wrong. But I do not know because there are no > > release notes which summarize it. > I totally feel Hannes' pain having gone through it a few times myself over the years. At the same time, I agree with Ken's point about not getting too bogged down in process since we're in the best position right now to break things for the better longer term. > Yes, that's true. Besides, we don't have a specification of what is an > API and what is not. So, almost any change can be considered an API change. > That's the problem! Both for you and us (it's a general 'Smalltalk Way' issue, not specific to Cuis) I believe it is largely fixable without tons of documentation and tests: the use of private (categories or method naming convention). Bernhard pointed out an existing capability a few months ago http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html While I personally like the idea of private categories, one of these approaches should really be seriously considered. Other than a few specific examples (i.e. mostly the base data types including the Collection and Number class hierarchies which are pretty mature and don't change all that much anyway) I would guesstimate that <20% (probably closer to 10%) of the methods, and and unknown % of classes (a significantly larger fraction though), should even be considered public. If things were indicated as private that would accomplish two things: 1) We could construct some simple tooling (some combination of up-front warnings in the editor and/or a lint-type tester after the fact) that would allow people to identify problematic calls within their code. (i.e. just because it works now doesn't mean it always will if you keep calling X, Y, Z...) 2) It would provide a way for people to know if something needs to be discussed. i.e. 'In class X method Y is private but I need that type of functionality' so you would know that there's a need and could consider either making it public, and therefore supported, or rethinking its implementation if you'd like to offer a better public API solution. > I don't want you to feel uncomfortable. Let's work this out. > > > And I do not now in which state my stuff and the general Cuis stuff ist. > > > > I need a new 'base line', i.e. a release number to which I can refer > > to when upgrading my code. > > Well, but we do have that. It is the update number. It is part of any > Cuis image I've ever committed to the repo. > > The problem, I think, is not identifying well defined Cuis releases. The > problem is knowing how updates could affect your code. > By narrowing the scope of what the public API is using private designators, this dramatically reduces what you need to be concerned with on this front. It's part of the reason that Apple, Google, and even Microsoft are so adamant about public APIs these days. They dealt with the pain of even major developers depending on private APIs for decades. It's only been in the last 10 years or so that they've been able to dig themselves out from under this issue. This gets back to the 'Smalltalk Way' issue I referenced earlier. The attitude of 'you have the source, play around, have fun!' has morphed into 'everything is a public API! there are no rules! isn't this great?' Well no, it's not great. It makes life impossible for image maintainers (Squeak has been in a coma for the last decade or so as the result of trying to keep everyone happy... yet no one seems to be) and miserable for those who are trying to keep code running on it (stuff still breaks all the time.) I personally believe the minimalism and simplicity that Cuis is based on has the best long term prospects but we have to get out of this 'everything is public' mindset. Sure, we have all the source: look at it, learn from it, poke around, refactor it, submit fixes, etc. But there needs to be a manageable subset of it which is considered the 'public API' that people can depend on to write frameworks and apps on top of that is relatively stable longer term. Let's start defining what that is and backfill changes to the public API (which will happen from time to time as we don't want things to be completely static) with tests and documentation so you can focus your efforts on where they matter most and you get the most enjoyment from. > > Of course the other option is to just follow the most recent update > > all the time. That would call for some kind of continuous integration > > testing 'Cuis style' which I not have either. > > > > E.g. if you could do a writeup how you do test Cuis before each new > > commit (there are over 50 this year) and which scripts you use I could > > apply the same thing for my packages. > > > > It has to be something which can be done quickly. Semi-Automatic is > > fine. A check list with > > > > - do this > > - then execute that script > > - Open .. this and that > > - And finally run a report on ... > > > > would be fine. > > I don't have that either. I run the tests from time to time (I'll start > doing it before any commit, and add the xml report to the rep). But this > is not the most important reason why Cuis is solid. Cuis is very > reliable because: reliable != stable > - I'm not too bad as a coder. > - I do my own code revisions at least one day after each change. > - I use Cuis every day, and spot most problems in the updates, before > commtting them to the repo. > - I really, really care about code quality. > - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that > is a big responsibility, given how important I think Smalltalk-80 is. > Agree to all this and more. Cuis would not be where it is without your continued effort and diligence. (i.e. setting aside that you obviously created it, if you had just tossed it out into the world and let it go at best it would have started looking something like Squeak or Pharo by now. It's a lot of effort over the long term to *keep* it small and focused. THANK YOU JUAN!) > So, I suggest running your tests when updating your image, or migrating > your code to an updated image. > +1 to tests as they do help quite a bit and are a very good practice. Just be judicious in what/where you test (I personally don't subscribe to the TDD approach where you spend your days mostly writing tests. That's just admitting defeat in that you spend all day writing executable documentation.) > In any case, I think this doesn't answer your concerns. What you need is > some way to know which updates could affect you, to review them in > detail, and understanding their effect on your code. A list of the > affected classes and/or methods for each update makes no sense. Cuis can > already show you that very easily. Perhaps each update should include: > > 1) parts of the system that are affected: > - Kernel > - Compiler > - Tools > - Morphic > - etc > > 2) Level of risk involved > - very unlikely to break code that depends on this part of the system > - could perhaps break code that depends on this part of the system > - will most likely break code that depends on this part of the system > > Or something like that. > > BTW, this is a very relevant topic for discussing on the mail list. Feel > free to answer there if you agree. > One final thought on this: I suspect a major cause of people abandoning Cuis (and Smalltalk in general), behind the 'it's too different from what I'm used to'/'not mainstream' reaction, is the instability of its APIs. > Cheers, > Juan Vuletich > > > > However doing a release tag in github is really not a big deal if you > > actually take the plunge. > > > > You are not alone in not using this option. > > > > It took me two years to realize that I can learn to do it and actually > > do a release in 5 minutes..... > > > > So I suggest do a release just continuing where you left off last time. > > > > Then people will start to realise there is something to test against. > > And new update requests will come and you can do another one. > > > > So the release which I am asking for is not a big deal. Just a tag on a commit. > > > > I'd like to explore the direct authoring tools offered by Ken Dickey. > > > > With the aim of producing a very simple Hypercard / Powerpoint like > > authoring environment. > > > > And do more with OMeta. > > > > Happy continued Cuis curating ..... > > And thank you very much indeed for your great work maintaining this environment. > > > > > > Hannes > > > > > > > > On 7/16/15, Juan Vuletich<[hidden email]> wrote: > >> On 7/12/2015 6:27 PM, H. Hirzel wrote: > >>> Hi Juan > >>> > >>> Regarding a Cuis version number. I suggest that you just continue with > >>> a new version number where you left off last time. > >>> > >>> It is just about having a version number to have a new baseline to > >>> refer to. This is helpful for testing and documentation. > >>> > >>> I do not think it is a big issue. > >>> > >>> API changes require a new version number. > >>> > >>> Kind regards > >>> Hannes > >> Hi Hannes, > >> > >> Sometimes I don't pay enough attention to stuff like this, so feel free > >> to request action from me when you feel appropriate :) > >> > >> Cheers, > >> Juan Vuletich > >> > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
Hi Folks,
(inline) On 7/17/2015 3:45 PM, Phil (list) wrote: > ...On 7/16/2015 9:57 AM, H. Hirzel wrote: >>> Thank you Juan, for answering. >>> >>> At the moment I feel uncomfortable using Cuis because it is currently >>> a quite fast moving target. I perceive quite a number of API changes >>> though this might be wrong. But I do not know because there are no >>> release notes which summarize it. > I totally feel Hannes' pain having gone through it a few times myself > over the years. At the same time, I agree with Ken's point about not > getting too bogged down in process since we're in the best position > right now to break things for the better longer term. > >> Yes, that's true. Besides, we don't have a specification of what is an >> API and what is not. So, almost any change can be considered an API change. > That's the problem! Both for you and us (it's a general 'Smalltalk Way' > issue, not specific to Cuis) I believe it is largely fixable without > tons of documentation and tests: the use of private (categories or > method naming convention). Bernhard pointed out an existing capability > a few months ago > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html > While I personally like the idea of private categories, one of these > approaches should really be seriously considered. > > Other than a few specific examples (i.e. mostly the base data types > including the Collection and Number class hierarchies which are pretty > mature and don't change all that much anyway) I would guesstimate that > <20% (probably closer to 10%) of the methods, and and unknown % of > classes (a significantly larger fraction though), should even be > considered public. If things were indicated as private that would > accomplish two things: > > 1) We could construct some simple tooling (some combination of up-front > warnings in the editor and/or a lint-type tester after the fact) that > would allow people to identify problematic calls within their code. > (i.e. just because it works now doesn't mean it always will if you keep > calling X, Y, Z...) > > 2) It would provide a way for people to know if something needs to be > discussed. i.e. 'In class X method Y is private but I need that type of > functionality' so you would know that there's a need and could consider > either making it public, and therefore supported, or rethinking its > implementation if you'd like to offer a better public API solution. Ok. Doing something along these lines would be great. But please note that it is a rather large amount of work. It is not something I'm able or willing to do it alone. If you (any of you all, not just Phil) wants to start defining the API for any part of the system or optional packages, please start doing it and send the changesets to the list. If we get this working, I'll start the tools you mention. <slowly diverging into OT rant> On the other hand (and please forgive me if this kills a bit of momentum), I don't really think we are changing APIs that much. And I don't think we'll be doing it any more in the future than we do today, at least in the base image. I hope to see most of the activity and incompatible changes to happen in optional packages, and affecting package dependencies... Mhhh, now that I write this I think that it doesn't really go against the idea of defining APIs. Maybe APIs in the base image will almost never change or be a problem, but packages should provide APIs too... Optional packages will (I hope!) always be improving, and new ones will appear all the time. If all this work, the Cuis will be a lot less about my personal effort and coding style, and the packages maintained by each one of us will become the main characters in this story. And this will be a very good thing. The base image should be about providing a good base for doing the really interesting stuff on top... Let me tell you a bit about how Cuis got started. Many years ago I did my thesis on audio/music processing. The I wanted to turn that into a novel and fun application for musicians (both pros and anyone willing to play with sound). I started to think about how a good GUI for that could be, giving the feeling of modifying sound by direct manipulation of it, as if it was clay, as if it was visual and not just auditory. Well, that was the start of my questioning of the whole GUI business and Morphic 3. And it became clear to me that Squeak had turned into something that was not the best possible environment to do all this. The idea of "fixing" Squeak, and thus make Cuis, was born. So, Cuis was not and end in itself, but a means for allowing experimentation, freedom to build applications in new styles, etc. (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other came later, as an observation on facts.) So, when the moment comes when Cuis stabilizes a bit, and interest moves to packages and applications built by all us, Cuis will start to fulfill its original objective. </slowly diverging into OT rant> >> ... >> The problem, I think, is not identifying well defined Cuis releases. The >> problem is knowing how updates could affect your code > By narrowing the scope of what the public API is using private > designators, this dramatically reduces what you need to be concerned > with on this front. It's part of the reason that Apple, Google, and > even Microsoft are so adamant about public APIs these days. They dealt > with the pain of even major developers depending on private APIs for > decades. It's only been in the last 10 years or so that they've been > able to dig themselves out from under this issue. > > This gets back to the 'Smalltalk Way' issue I referenced earlier. The > attitude of 'you have the source, play around, have fun!' has morphed > into 'everything is a public API! there are no rules! isn't this > great?' Well no, it's not great. It makes life impossible for image > maintainers (Squeak has been in a coma for the last decade or so as the > result of trying to keep everyone happy... yet no one seems to be) and > miserable for those who are trying to keep code running on it (stuff > still breaks all the time.) Yes. > I personally believe the minimalism and simplicity that Cuis is based on > has the best long term prospects but we have to get out of this > 'everything is public' mindset. Sure, we have all the source: look at > it, learn from it, poke around, refactor it, submit fixes, etc. But > there needs to be a manageable subset of it which is considered the > 'public API' that people can depend on to write frameworks and apps on > top of that is relatively stable longer term. Let's start defining what > that is and backfill changes to the public API (which will happen from > time to time as we don't want things to be completely static) with tests > and documentation so you can focus your efforts on where they matter > most and you get the most enjoyment from. I fully agree and support this. Maybe an alternative to yet-another-convention-on-categories could be to mark public methods with a pragma, or make them send 'self publicAPI' or such... This could be better for the tools, also. > ... >> I don't have that either. I run the tests from time to time (I'll start >> doing it before any commit, and add the xml report to the rep). But this >> is not the most important reason why Cuis is solid. Cuis is very >> reliable because: > reliable != stable ;) >> - I'm not too bad as a coder. >> - I do my own code revisions at least one day after each change. >> - I use Cuis every day, and spot most problems in the updates, before >> commtting them to the repo. >> - I really, really care about code quality. >> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that >> is a big responsibility, given how important I think Smalltalk-80 is. >> > Agree to all this and more. Cuis would not be where it is without your > continued effort and diligence. (i.e. setting aside that you obviously > created it, if you had just tossed it out into the world and let it go > at best it would have started looking something like Squeak or Pharo by > now. It's a lot of effort over the long term to *keep* it small and > focused. THANK YOU JUAN!) Thanks for your nice words, Phil. I really appreciate that you all accept this rather restrictive dev model for the base image, in contrast with a more open trunk style. Hopefully, as the base image becomes stable and almost irrelevant, this will be each time less of a problem. >> So, I suggest running your tests when updating your image, or migrating >> your code to an updated image. > +1 to tests as they do help quite a bit and are a very good practice. > Just be judicious in what/where you test (I personally don't subscribe > to the TDD approach where you spend your days mostly writing tests. > That's just admitting defeat in that you spend all day writing > executable documentation.) <OT> I don't subscribe to "extreme" TDD either. To me design is a creative activity, both technical and artistic. It should be "driven" by creativity and intelligence, not by a process. Any xDD process is admitting defeat on design itself! </OT> >> In any case, I think this doesn't answer your concerns. What you need is >> some way to know which updates could affect you, to review them in >> detail, and understanding their effect on your code. A list of the >> affected classes and/or methods for each update makes no sense. Cuis can >> already show you that very easily. Perhaps each update should include: >> >> 1) parts of the system that are affected: >> - Kernel >> - Compiler >> - Tools >> - Morphic >> - etc >> >> 2) Level of risk involved >> - very unlikely to break code that depends on this part of the system >> - could perhaps break code that depends on this part of the system >> - will most likely break code that depends on this part of the system >> >> Or something like that. >> >> BTW, this is a very relevant topic for discussing on the mail list. Feel >> free to answer there if you agree. > One final thought on this: I suspect a major cause of people abandoning > Cuis (and Smalltalk in general), behind the 'it's too different from > what I'm used to'/'not mainstream' reaction, is the instability of its > APIs. Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) is a PITA too... As a bottom line, let me repeat: This is too big for me to do it. Please, folks, start documenting the APIs you most care about. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
Hey all, Just 2 cents from a Cuis noob: 1. Releases... since this stuff is not being sold for money and not being distributed using off-line media, what use does a "release" have? I like that stuff gets improved as often as possible. I believe that the things that get improved the most often, have the best chance of becoming something really good. So, I am for adopting practices that increase the number of improvements. Practices that decrease the number of deteriorations seem helpful as well. See below if you wonder what my point is ;-). 2. Public vs private API. Stable APIs are nice, if you can get them. If you have authors who develop a base, and other authors who (have to) develop ON that base, you need stable APIs, or you will lose the authors dependent on your base. So, do we really have those different author groups? Somehow I doubt it. I recently changed the scoping rules for shared variables (I think they're done wrong in the base image). I could change what I wanted easily. So I think I am not in some outsider author group. Instead I am happy that I could change what I wanted without needing anyone's approval or cooperation. Suppose we were making money from outside author groups who want us to keep certain APIs stable. For the right price, I would be happy to provide that for them. In the mean time, I can live with free. Free to change what I want, free to use without paying, and others free to change what I am building on (sometimes frustrating). 3. Maybe what will help everybody is something that prevents functionality from being lost, especially *unintentionally*. This can include certain APIs as well. So what if an author who values a certain API, could invest some of his own time/money, to protect that API? What if he could write a software component (let's say a class) that was able to detect whenever an image did not provide the desired API? What if he could submit that class, and everybody who cared about not breaking that API, could use that class to see if perhaps they broke it? 4. I believe the idea could be generalized to include any feature of (the code in) an image for which presence or absence (as may be the case) can be determined by such a class. Bugs could be reified as classes, and the presence or absence of the bug could be determined by that class. Feature requests could be reified as classes, and whether or not the feature had actually been implemented could be determined by that class. 5. The things I am proposing would basically be Feature Tests, and would be rather different from Unit Tests (which apply to a unit and which you want to all be green when you share your software with users of it). Feature Tests would apply to a system (not a unit) and simply indicate which features are and which features are not present in the system. Every "release" could then come with a) the assertion that all the Unit Tests passed b) a list of the Feature Tests that passed and those that did not. 6. I think it would be pretty cool if people sent in feature requests in the form of Feature Tests, instead of messages to the mailing list (or the request tracker). So that anybody who (wished to impress somebody and) had some time on their hands, could then try to implement the functionality that made the Feature Test pass. Hope this helps somebody with something :) Cheers, Peter On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <[hidden email]> wrote: Hi Folks, _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
On Sun, 19 Jul 2015 11:20:19 -0300
Juan Vuletich <[hidden email]> wrote: > As a bottom line, let me repeat: This is too big for me to do it. > Please, folks, start documenting the APIs you most care about. Let me repeat, "you don't have to do it". I'd like to propose a simpler model based on the Smalltalk Way. We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number). Each Baseline Release has a release document which describes major changes since the previous baseline. This document is a light-weight description. Each baseline release starts a new fork. The only changes to the particular baseline release are bug fixes. Nice users test their packages and likewise fork a Package Release which matches a Baseline Release. This fork also only changes with bug fixes, and only in synch with its particular baseline. Baseline packages Feature the baseline release. So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward. Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear. Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable. Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold". $0.02 -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Fwd: Re: DIRECT version number
|
|
KenD
I like your proposal. And earlier you suggested to have one of these base line versions per year. --Hannes On 7/19/15, Ken.Dickey <[hidden email]> wrote: > On Sun, 19 Jul 2015 11:20:19 -0300 > Juan Vuletich <[hidden email]> wrote: > >> As a bottom line, let me repeat: This is too big for me to do it. >> Please, folks, start documenting the APIs you most care about. > > Let me repeat, "you don't have to do it". > > I'd like to propose a simpler model based on the Smalltalk Way. > > We take any stable revision, call it a version, give it a Baseline Version > Number (could be just the development version number). Each Baseline > Release has a release document which describes major changes since the > previous baseline. This document is a light-weight description. > > Each baseline release starts a new fork. The only changes to the particular > baseline release are bug fixes. > > Nice users test their packages and likewise fork a Package Release which > matches a Baseline Release. This fork also only changes with bug fixes, and > only in synch with its particular baseline. Baseline packages Feature the > baseline release. > > So we forge ahead as usual, once in a while we say "enough has changed that > we should re-baseline", do a new Baseline Release, test and release our > Package Releases, then again move on forward. > > Anyone can now pick any baseline release, require any associated packages, > and ship/demo without fear. > > Anyone with the time, energy, and interest can document baseline APIs to > whatever level they feel comfortable. > > Anyone can forge on ahead with the latest revision(s) with the usual "here > be dragons, but also gold". > > $0.02 > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
On Sun, 2015-07-19 at 11:20 -0300, Juan Vuletich wrote:
> Hi Folks, > > (inline) > > On 7/17/2015 3:45 PM, Phil (list) wrote: > > ...On 7/16/2015 9:57 AM, H. Hirzel wrote: > >>> Thank you Juan, for answering. > >>> > >>> At the moment I feel uncomfortable using Cuis because it is currently > >>> a quite fast moving target. I perceive quite a number of API changes > >>> though this might be wrong. But I do not know because there are no > >>> release notes which summarize it. > > I totally feel Hannes' pain having gone through it a few times myself > > over the years. At the same time, I agree with Ken's point about not > > getting too bogged down in process since we're in the best position > > right now to break things for the better longer term. > > > >> Yes, that's true. Besides, we don't have a specification of what is an > >> API and what is not. So, almost any change can be considered an API change. > > That's the problem! Both for you and us (it's a general 'Smalltalk Way' > > issue, not specific to Cuis) I believe it is largely fixable without > > tons of documentation and tests: the use of private (categories or > > method naming convention). Bernhard pointed out an existing capability > > a few months ago > > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html > > While I personally like the idea of private categories, one of these > > approaches should really be seriously considered. > > > > Other than a few specific examples (i.e. mostly the base data types > > including the Collection and Number class hierarchies which are pretty > > mature and don't change all that much anyway) I would guesstimate that > > <20% (probably closer to 10%) of the methods, and and unknown % of > > classes (a significantly larger fraction though), should even be > > considered public. If things were indicated as private that would > > accomplish two things: > > > > 1) We could construct some simple tooling (some combination of up-front > > warnings in the editor and/or a lint-type tester after the fact) that > > would allow people to identify problematic calls within their code. > > (i.e. just because it works now doesn't mean it always will if you keep > > calling X, Y, Z...) > > > > 2) It would provide a way for people to know if something needs to be > > discussed. i.e. 'In class X method Y is private but I need that type of > > functionality' so you would know that there's a need and could consider > > either making it public, and therefore supported, or rethinking its > > implementation if you'd like to offer a better public API solution. > > Ok. Doing something along these lines would be great. But please note > that it is a rather large amount of work. It is not something I'm able > or willing to do it alone. If you (any of you all, not just Phil) wants > to start defining the API for any part of the system or optional > packages, please start doing it and send the changesets to the list. If > we get this working, I'll start the tools you mention. > Agreed that this is a lot of work and I definitely wasn't expecting you to do it (other than reviewing the work for approval/rejection.) I'll be happy to work on this with anyone else who is interested. > <slowly diverging into OT rant> > > On the other hand (and please forgive me if this kills a bit of > momentum), I don't really think we are changing APIs that much. And I > don't think we'll be doing it any more in the future than we do today, > at least in the base image. I hope to see most of the activity and > incompatible changes to happen in optional packages, and affecting > package dependencies... Mhhh, now that I write this I think that it > doesn't really go against the idea of defining APIs. Maybe APIs in the > base image will almost never change or be a problem, but packages should > provide APIs too... Optional packages will (I hope!) always be > improving, and new ones will appear all the time. > You'd likely be very surprised. I'd say there's usually at least a couple changes a month that breaks something, somewhere in my code. A few recent examples that have been discussed on the list: removing clone broke OpenGL a bit (easy fix thanks to the on-list discussion), removing compilerClass killed OMeta, a while back you were considering removing storeString which would again break OMeta. etc. (that's just a few things off the top of my head from the last few months and note that all were probably considered minor, inconsequential changes) However the issue snowballs quickly if one misses a few updates and some of the breakage is related to changes that weren't discussed on the list or otherwise documented. I've been managing through this recently (the last 6 months or so) by upgrading my image very quickly after you commit changes but I doubt most people would be able / willing to have that level of diligence. A lot of this breakage is no one's 'fault', it's just how a lot of Smalltalk code has been historically written. Two examples of how this happens: 1) For ports of existing code, you're subject to the whims of the original author who often used techniques described in the next item to write their code. And of course, code coming from Squeak/Pharo means that there were often 10 or more possible ways they could have implemented parts of their solution. So after porting a few different packages, you have several different approaches to the same kinds of problems. 2) For one's own code because there is currently no distinction between public and private, you tend to go either with what you already know or whatever the first thing you find poking around the image that appears to make sense and work. Even in Cuis, there are still usually multiple ways to do most things, so you end up arbitrarily picking one or two that you like. As a result, you quickly end up with a potpourri of calls that may or may not be the best way to do things. Over time, you start building new code on top of this code and quickly end up with a house of cards that comes crashing down as the result of a subsequent image update. Again, this often results in each of us as authors deciding on superficially different solutions to the same problems. I'm not expecting you to not do things that might break my, or anyone else's code, going forward. Like Hannes, I'm just looking for ways to help manage through the changes and breakage. One of the key aspects of this is to have an opinion and to say 'hey, here are the one or two ways we should be doing this'. There may be disagreement and discussion as to what those one or two ways are, but at the end of the day we need to settle these issues so that both your and our lives are manageable. That's really the main thing that a public API is, IMO. There may be all sorts of internal helper methods and implementation details needed to make it all work, but like the cells of a living organism, these details should be hidden and their use discouraged. Hey, didn't someone say something along those lines once? :-) > If all this work, the Cuis will be a lot less about my personal effort > and coding style, and the packages maintained by each one of us will > become the main characters in this story. And this will be a very good > thing. The base image should be about providing a good base for doing > the really interesting stuff on top... > I both agree (that the packages become more important) and disagree (that Cuis fades into the background). I still view the core Cuis image as the philosophical and stylistic backbone that all of my stuff is based on. It's a constant reminder to clean up and get rid of as much cruft as possible in my code (especially for the packages that have yet other packages dependent on them) I freely admit that I am mostly falling short in my execution on this front, but it would be easy to lose sight of entirely if Cuis didn't stay the course. > Let me tell you a bit about how Cuis got started. Many years ago I did > my thesis on audio/music processing. The I wanted to turn that into a > novel and fun application for musicians (both pros and anyone willing to > play with sound). I started to think about how a good GUI for that could > be, giving the feeling of modifying sound by direct manipulation of it, > as if it was clay, as if it was visual and not just auditory. Well, that > was the start of my questioning of the whole GUI business and Morphic 3. > And it became clear to me that Squeak had turned into something that was > not the best possible environment to do all this. The idea of "fixing" > Squeak, and thus make Cuis, was born. So, Cuis was not and end in > itself, but a means for allowing experimentation, freedom to build > applications in new styles, etc. > > (The idea that Cuis is a truer Smalltalk-80 than Squeak or any other > came later, as an observation on facts.) > > So, when the moment comes when Cuis stabilizes a bit, and interest moves > to packages and applications built by all us, Cuis will start to fulfill > its original objective. > It's already this is as far as I'm concerned. I can't tell you much time I burned just trying to extract OpenGL from Croquet so that I could load it into Squeak, for example. It was painful on both sides, and by the time I was done I had to think for a bit to remind myself what my original objective was... I have *never* had this issue with Cuis. It is absolutely enabling me to play around with ideas and build things that I couldn't have / wouldn't have bothered in Squeak. The only issue I'm having is that once I've built it, I want to keep it running :-) > </slowly diverging into OT rant> Not at all a rant as it reaffirms *why* you're doing what you're doing. If you lost sight of that, that's when I'd start worrying about Cuis. > > >> ... > >> The problem, I think, is not identifying well defined Cuis releases. The > >> problem is knowing how updates could affect your code > > By narrowing the scope of what the public API is using private > > designators, this dramatically reduces what you need to be concerned > > with on this front. It's part of the reason that Apple, Google, and > > even Microsoft are so adamant about public APIs these days. They dealt > > with the pain of even major developers depending on private APIs for > > decades. It's only been in the last 10 years or so that they've been > > able to dig themselves out from under this issue. > > > > This gets back to the 'Smalltalk Way' issue I referenced earlier. The > > attitude of 'you have the source, play around, have fun!' has morphed > > into 'everything is a public API! there are no rules! isn't this > > great?' Well no, it's not great. It makes life impossible for image > > maintainers (Squeak has been in a coma for the last decade or so as the > > result of trying to keep everyone happy... yet no one seems to be) and > > miserable for those who are trying to keep code running on it (stuff > > still breaks all the time.) > > Yes. > > > I personally believe the minimalism and simplicity that Cuis is based on > > has the best long term prospects but we have to get out of this > > 'everything is public' mindset. Sure, we have all the source: look at > > it, learn from it, poke around, refactor it, submit fixes, etc. But > > there needs to be a manageable subset of it which is considered the > > 'public API' that people can depend on to write frameworks and apps on > > top of that is relatively stable longer term. Let's start defining what > > that is and backfill changes to the public API (which will happen from > > time to time as we don't want things to be completely static) with tests > > and documentation so you can focus your efforts on where they matter > > most and you get the most enjoyment from. > > I fully agree and support this. > Maybe an alternative to yet-another-convention-on-categories could be to > mark public methods with a pragma, or make them send 'self publicAPI' or > such... This could be better for the tools, also. > I like your idea better re: rather than having to go through and mark the majority as private, just mark the minority as public. I'm open to either of your proposed approaches. I just tossed out the two (method categories and naming) I was aware of but agree that they would not do much to ease developing tools to support/enforce. Of the two ideas, am I correct in believing that pragma would have the lowest runtime overhead? Are there any downsides you can think of to using pragma? Speaking of enforcing, I am not proposing that we make this a straight-jacket for anyone: it should be easy to opt-out the way things like underscore assignment are (except for pp which I'm still trying to get to an easily repro example with... :-) so that anyone who doesn't care about this isn't forced into it. On the other hand, for people who do care, they should be able to leave it 'enabled', whatever that ends up meaning, and get help from the tooling to help them minimize potential future breakage. The downside to opting out would be that you, as the author opting out, have decided to take it entirely on yourself to keep your code running across builds/releases. > > ... > >> I don't have that either. I run the tests from time to time (I'll start > >> doing it before any commit, and add the xml report to the rep). But this > >> is not the most important reason why Cuis is solid. Cuis is very > >> reliable because: > > reliable != stable > > ;) > > >> - I'm not too bad as a coder. > >> - I do my own code revisions at least one day after each change. > >> - I use Cuis every day, and spot most problems in the updates, before > >> commtting them to the repo. > >> - I really, really care about code quality. > >> - I think Cuis keeps Smalltalk-80 and its ideals alive. And I think that > >> is a big responsibility, given how important I think Smalltalk-80 is. > >> > > Agree to all this and more. Cuis would not be where it is without your > > continued effort and diligence. (i.e. setting aside that you obviously > > created it, if you had just tossed it out into the world and let it go > > at best it would have started looking something like Squeak or Pharo by > > now. It's a lot of effort over the long term to *keep* it small and > > focused. THANK YOU JUAN!) > > Thanks for your nice words, Phil. I really appreciate that you all > accept this rather restrictive dev model for the base image, in contrast > with a more open trunk style. Hopefully, as the base image becomes > stable and almost irrelevant, this will be each time less of a problem. > > >> So, I suggest running your tests when updating your image, or migrating > >> your code to an updated image. > > +1 to tests as they do help quite a bit and are a very good practice. > > Just be judicious in what/where you test (I personally don't subscribe > > to the TDD approach where you spend your days mostly writing tests. > > That's just admitting defeat in that you spend all day writing > > executable documentation.) > > <OT> > > I don't subscribe to "extreme" TDD either. To me design is a creative > activity, both technical and artistic. It should be "driven" by > creativity and intelligence, not by a process. Any xDD process is > admitting defeat on design itself! > Heh... I like the way you put that. > </OT> > > >> In any case, I think this doesn't answer your concerns. What you need is > >> some way to know which updates could affect you, to review them in > >> detail, and understanding their effect on your code. A list of the > >> affected classes and/or methods for each update makes no sense. Cuis can > >> already show you that very easily. Perhaps each update should include: > >> > >> 1) parts of the system that are affected: > >> - Kernel > >> - Compiler > >> - Tools > >> - Morphic > >> - etc > >> > >> 2) Level of risk involved > >> - very unlikely to break code that depends on this part of the system > >> - could perhaps break code that depends on this part of the system > >> - will most likely break code that depends on this part of the system > >> > >> Or something like that. > >> > >> BTW, this is a very relevant topic for discussing on the mail list. Feel > >> free to answer there if you agree. > > One final thought on this: I suspect a major cause of people abandoning > > Cuis (and Smalltalk in general), behind the 'it's too different from > > what I'm used to'/'not mainstream' reaction, is the instability of its > > APIs. > > Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 problem) > is a PITA too... True, neither extreme (changing nothing vs. changing everything) works very well. <cough>Perl 6</cough> :-) > > As a bottom line, let me repeat: This is too big for me to do it. > Please, folks, start documenting the APIs you most care about. > Ready to go... we just need to agree on how to do it (pragma/method call/method category/method name?) Also, this is most definitely related to the 'Canonical test cases?' thread from a few months ago as these types of test cases / docs are part of the backfill I was referring to. As I've been writing this it occurs to me that there's probably a pretty easy way to go about getting started on this: IIRC, there are ~1,500 distinct method names in the core image. If I do a count of how many times my code is calling any of those methods, that should pop out what, for my code, is the low hanging fruit. The long-tail of say 1-5 calls for the lesser used methods are the tedious work that will take more effort for me to sort through. We could use my 'short list' to at least provide a starting point and using these most frequently called methods you could scan through the list and could say 'hey, why are you calling X instead of Y?' or maybe you'd get some visibility in the sense of 'wow, I didn't think that was being used'. Hmm... I've got some analysis to do... > Cheers, > Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by KenDickey
On Sun, 2015-07-19 at 13:18 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 11:20:19 -0300 > Juan Vuletich <[hidden email]> wrote: > > > As a bottom line, let me repeat: This is too big for me to do it. > > Please, folks, start documenting the APIs you most care about. > > Let me repeat, "you don't have to do it". > I would agree that *Juan* doesn't need to do much of anything at this stage, but not that it doesn't need to be done. If and when it does get done, if he disregards it, it will have been a futile exercise. So I'd appreciate it if we could come to an agreement as to whether or not I should bother... > I'd like to propose a simpler model based on the Smalltalk Way. > > We take any stable revision, call it a version, give it a Baseline Version Number (could be just the development version number). Each Baseline Release has a release document which describes major changes since the previous baseline. This document is a light-weight description. > While I agree that there should be periodic major releases, there are a lot of things in motion between major releases that will either be forgotten about or not considered major enough to call out in the major version release notes. The issue is what constitutes a major change? If your code uses it it's major, if mine uses it it's minor? Coin toss? Without a public API what is considered major is either obvious (i.e. Morphic changes from global to local coords or changing the File/Directory API so obviously everything using them breaks) or arbitrary (sorry to hear that you depended on that... but it wasn't major, now it's gone) If the image snapshot is considered the public API, then everything must be both considered fair game to depend on and to change in the future which is unmanageable. Let's look at a few examples along the spectrum of what I'm talking about: 1) Things that hopefully we can all agree on as being obvious and relatively stable. We have a class called Morph. Is it reasonable to assume that that is going to be supported going forward? How about the #drawOn: method, is that going to be around for a while? If Juan were to randomly decide to change these, I'd expect there would be screaming from anyone who has a significant amount of drawing code. 2) Multiple ways to do the same thing. Morphs support stepping to do animated drawing etc. There are at least two different ways (one seemingly obvious, one less so... both different from how things used to work) currently to do stepping. Should this be the case, or should we just have one way we agree that everyone uses? What is lost by giving up the 2nd (and 3rd...) way(s)? Currently, if Juan were to change *any* of the approaches, it would probably break someones code. Why not just have one supported way for him to be concerned with? (if you think this doesn't happen, one of my pull requests in the last month was related to this) 3) Questionable usage / edge cases. Morph also has #resumeAfterDrawError and #resumeAfterStepError. Now taking a few seconds to look at them (never used myself) they seem like Morphic implementation details, but hey they're in the image and not even marked private so I should feel free to make my code depend on them, right? Conversely, Juan could look at them and decide 'no one would possibly need these' and change/remove them at any time. It seems to me that at least 1/2 of 2 and most use cases of 3 are unnecessary issues waiting to, and eventually will, happen. I personally try to stick to depending on things that are in category 1 or the obvious use case of 2. But imagine my surprise when I discover as the result of an update that something I was using was actually in category 2 (less obvious, to me at least) or 3. Sure, there's a lot of gray area that isn't so clear cut, but shouldn't we at least try to minimize the amount of breakage going forward when it can easily be avoided or manage it via documentation/communication when it can't? I'm not trying to restrict Juan in any way from making the changes he thinks are important for Cuis. His taste and direction have been generally excellent and the reason I'm here! If for example, he decides that #drawOn: is no longer the way to do things or that even Morph needed to go away, that's fine as long as what's going on gets communicated. However, a problem I think he faces right now is that he doesn't know who's using / depending on what. > Each baseline release starts a new fork. The only changes to the particular baseline release are bug fixes. > > Nice users test their packages and likewise fork a Package Release which matches a Baseline Release. This fork also only changes with bug fixes, and only in synch with its particular baseline. Baseline packages Feature the baseline release. > > So we forge ahead as usual, once in a while we say "enough has changed that we should re-baseline", do a new Baseline Release, test and release our Package Releases, then again move on forward. > > Anyone can now pick any baseline release, require any associated packages, and ship/demo without fear. > What you are describing is an application development model, not a platform development model. It handles dependencies by ignoring them. It really comes down to what is Cuis? Is it: 1) a minimal Smalltalk that you play around with ideas / prototype something in the short to intermediate term 2) a platform that you can take that idea you were playing around with, and if it proves out, build something more substantial from for the longer term 3) a completely experimental environment. Anything can change at any time. Supporting 1 is doable but 2 is doubtful. Right now, Cuis is great at 1 but seems like it should be able to handle both 1 and 2 if a bit of stability gets added. I don't think it's 3 at all, but who knows, others may disagree. If others look at it differently, I'd love to know how you look at Cuis. > Anyone with the time, energy, and interest can document baseline APIs to whatever level they feel comfortable. > > Anyone can forge on ahead with the latest revision(s) with the usual "here be dragons, but also gold". > > $0.02 > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Peter van Rooijen-2
On Sun, 2015-07-19 at 18:02 +0200, Peter van Rooijen wrote:
> Hey all, > > > Just 2 cents from a Cuis noob: > > > 1. Releases... since this stuff is not being sold for money and not > being distributed using off-line media, what use does a "release" > have? I like that stuff gets improved as often as possible. I believe > that the things that get improved the most often, have the best chance > of becoming something really good. > It's more a function of managing the dependent code bases than anything else. One's view of 'improved as often as possible' changes when said improvements break things you are depending on without warning. > > So, I am for adopting practices that increase the number of > improvements. Practices that decrease the number of deteriorations > seem helpful as well. See below if you wonder what my point is ;-). > > > 2. Public vs private API. Stable APIs are nice, if you can get them. > If you have authors who develop a base, and other authors who (have > to) develop ON that base, you need stable APIs, or you will lose the > authors dependent on your base. > Yup. See Hannes' original comments that started this thread. I chimed in because I've been bitten by this several times. And I'm sure there are others who don't participate in the lists. At the same time, I recognize that there are others like Ken who don't have an issue. It's just a discussion that needed to be had and a decision reached whether or not something needs to be done, and if so what. > > So, do we really have those different author groups? Somehow I doubt > it. I recently changed the scoping rules for shared variables (I think > they're done wrong in the base image). I could change what I wanted > easily. So I think I am not in some outsider author group. Instead I > am happy that I could change what I wanted without needing anyone's > approval or cooperation. > We absolutely do. I fall into several categories: I occasionally submit changes to 'core' Cuis, work on several add-on frameworks (OMeta and OpenGL are currently my main focuses on that front), and have a large-ish base of my own code that I'm developing and maintaining. The issue isn't one of permission as much as it is of communicating to those downstream what is considered stable/supported. Feel free to change anything you want, just don't be surprised if the next release breaks your changes. But what do you do when you're trying to write something that either won't break in the next release or at least have some indication before hand what you might run into... > > Suppose we were making money from outside author groups who want us to > keep certain APIs stable. For the right price, I would be happy to > provide that for them. In the mean time, I can live with free. Free to > change what I want, free to use without paying, and others free to > change what I am building on (sometimes frustrating). > That definitely makes sense when you're talking about things like LTS (Long Term Support) versions etc. Free and stable are not mutually exclusive. > > 3. Maybe what will help everybody is something that prevents > functionality from being lost, especially *unintentionally*. This can > include certain APIs as well. So what if an author who values a > certain API, could invest some of his own time/money, to protect that > API? What if he could write a software component (let's say a class) > that was able to detect whenever an image did not provide the desired > API? What if he could submit that class, and everybody who cared about > not breaking that API, could use that class to see if perhaps they > broke it? > > > 4. I believe the idea could be generalized to include any feature of > (the code in) an image for which presence or absence (as may be the > case) can be determined by such a class. Bugs could be reified as > classes, and the presence or absence of the bug could be determined by > that class. Feature requests could be reified as classes, and whether > or not the feature had actually been implemented could be determined > by that class. > > > 5. The things I am proposing would basically be Feature Tests, and > would be rather different from Unit Tests (which apply to a unit and > which you want to all be green when you share your software with users > of it). Feature Tests would apply to a system (not a unit) and simply > indicate which features are and which features are not present in the > system. Every "release" could then come with a) the assertion that all > the Unit Tests passed b) a list of the Feature Tests that passed and > those that did not. > I believe what you are proposing is similar to what I proposed a few months ago in the 'Canonical test cases?' thread. http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-February/001747.html > > 6. I think it would be pretty cool if people sent in feature requests > in the form of Feature Tests, instead of messages to the mailing list > (or the request tracker). So that anybody who (wished to impress > somebody and) had some time on their hands, could then try to > implement the functionality that made the Feature Test pass. > > > Hope this helps somebody with something :) > > > Cheers, Peter > > On Sun, Jul 19, 2015 at 4:20 PM, Juan Vuletich <[hidden email]> > wrote: > Hi Folks, > > (inline) > > On 7/17/2015 3:45 PM, Phil (list) wrote: > ...On 7/16/2015 9:57 AM, H. Hirzel wrote: > Thank you Juan, for answering. > > At the moment I feel uncomfortable > using Cuis because it is currently > a quite fast moving target. I perceive > quite a number of API changes > though this might be wrong. But I do > not know because there are no > release notes which summarize it. > I totally feel Hannes' pain having gone through it a > few times myself > over the years. At the same time, I agree with Ken's > point about not > getting too bogged down in process since we're in the > best position > right now to break things for the better longer term. > > Yes, that's true. Besides, we don't have a > specification of what is an > API and what is not. So, almost any change can > be considered an API change. > That's the problem! Both for you and us (it's a > general 'Smalltalk Way' > issue, not specific to Cuis) I believe it is largely > fixable without > tons of documentation and tests: the use of private > (categories or > method naming convention). Bernhard pointed out an > existing capability > a few months ago > http://jvuletich.org/pipermail/cuis_jvuletich.org/2015-March/001784.html > While I personally like the idea of private > categories, one of these > approaches should really be seriously considered. > > Other than a few specific examples (i.e. mostly the > base data types > including the Collection and Number class hierarchies > which are pretty > mature and don't change all that much anyway) I would > guesstimate that > <20% (probably closer to 10%) of the methods, and and > unknown % of > classes (a significantly larger fraction though), > should even be > considered public. If things were indicated as > private that would > accomplish two things: > > 1) We could construct some simple tooling (some > combination of up-front > warnings in the editor and/or a lint-type tester after > the fact) that > would allow people to identify problematic calls > within their code. > (i.e. just because it works now doesn't mean it always > will if you keep > calling X, Y, Z...) > > 2) It would provide a way for people to know if > something needs to be > discussed. i.e. 'In class X method Y is private but I > need that type of > functionality' so you would know that there's a need > and could consider > either making it public, and therefore supported, or > rethinking its > implementation if you'd like to offer a better public > API solution. > > Ok. Doing something along these lines would be great. But > please note that it is a rather large amount of work. It is > not something I'm able or willing to do it alone. If you (any > of you all, not just Phil) wants to start defining the API for > any part of the system or optional packages, please start > doing it and send the changesets to the list. If we get this > working, I'll start the tools you mention. > > <slowly diverging into OT rant> > > On the other hand (and please forgive me if this kills a bit > of momentum), I don't really think we are changing APIs that > much. And I don't think we'll be doing it any more in the > future than we do today, at least in the base image. I hope to > see most of the activity and incompatible changes to happen in > optional packages, and affecting package dependencies... Mhhh, > now that I write this I think that it doesn't really go > against the idea of defining APIs. Maybe APIs in the base > image will almost never change or be a problem, but packages > should provide APIs too... Optional packages will (I hope!) > always be improving, and new ones will appear all the time. > > If all this work, the Cuis will be a lot less about my > personal effort and coding style, and the packages maintained > by each one of us will become the main characters in this > story. And this will be a very good thing. The base image > should be about providing a good base for doing the really > interesting stuff on top... > > Let me tell you a bit about how Cuis got started. Many years > ago I did my thesis on audio/music processing. The I wanted to > turn that into a novel and fun application for musicians (both > pros and anyone willing to play with sound). I started to > think about how a good GUI for that could be, giving the > feeling of modifying sound by direct manipulation of it, as if > it was clay, as if it was visual and not just auditory. Well, > that was the start of my questioning of the whole GUI business > and Morphic 3. And it became clear to me that Squeak had > turned into something that was not the best possible > environment to do all this. The idea of "fixing" Squeak, and > thus make Cuis, was born. So, Cuis was not and end in itself, > but a means for allowing experimentation, freedom to build > applications in new styles, etc. > > (The idea that Cuis is a truer Smalltalk-80 than Squeak or any > other came later, as an observation on facts.) > > So, when the moment comes when Cuis stabilizes a bit, and > interest moves to packages and applications built by all us, > Cuis will start to fulfill its original objective. > > </slowly diverging into OT rant> > > ... > The problem, I think, is not identifying well > defined Cuis releases. The > problem is knowing how updates could affect > your code > By narrowing the scope of what the public API is using > private > designators, this dramatically reduces what you need > to be concerned > with on this front. It's part of the reason that > Apple, Google, and > even Microsoft are so adamant about public APIs these > days. They dealt > with the pain of even major developers depending on > private APIs for > decades. It's only been in the last 10 years or so > that they've been > able to dig themselves out from under this issue. > > This gets back to the 'Smalltalk Way' issue I > referenced earlier. The > attitude of 'you have the source, play around, have > fun!' has morphed > into 'everything is a public API! there are no rules! > isn't this > great?' Well no, it's not great. It makes life > impossible for image > maintainers (Squeak has been in a coma for the last > decade or so as the > result of trying to keep everyone happy... yet no one > seems to be) and > miserable for those who are trying to keep code > running on it (stuff > still breaks all the time.) > > Yes. > > I personally believe the minimalism and simplicity > that Cuis is based on > has the best long term prospects but we have to get > out of this > 'everything is public' mindset. Sure, we have all the > source: look at > it, learn from it, poke around, refactor it, submit > fixes, etc. But > there needs to be a manageable subset of it which is > considered the > 'public API' that people can depend on to write > frameworks and apps on > top of that is relatively stable longer term. Let's > start defining what > that is and backfill changes to the public API (which > will happen from > time to time as we don't want things to be completely > static) with tests > and documentation so you can focus your efforts on > where they matter > most and you get the most enjoyment from. > > I fully agree and support this. > Maybe an alternative to yet-another-convention-on-categories > could be to mark public methods with a pragma, or make them > send 'self publicAPI' or such... This could be better for the > tools, also. > > ... > I don't have that either. I run the tests from > time to time (I'll start > doing it before any commit, and add the xml > report to the rep). But this > is not the most important reason why Cuis is > solid. Cuis is very > reliable because: > reliable != stable > > ;) > > - I'm not too bad as a coder. > - I do my own code revisions at least one day > after each change. > - I use Cuis every day, and spot most problems > in the updates, before > commtting them to the repo. > - I really, really care about code quality. > - I think Cuis keeps Smalltalk-80 and its > ideals alive. And I think that > is a big responsibility, given how important I > think Smalltalk-80 is. > > Agree to all this and more. Cuis would not be where > it is without your > continued effort and diligence. (i.e. setting aside > that you obviously > created it, if you had just tossed it out into the > world and let it go > at best it would have started looking something like > Squeak or Pharo by > now. It's a lot of effort over the long term to > *keep* it small and > focused. THANK YOU JUAN!) > > Thanks for your nice words, Phil. I really appreciate that you > all accept this rather restrictive dev model for the base > image, in contrast with a more open trunk style. Hopefully, as > the base image becomes stable and almost irrelevant, this will > be each time less of a problem. > > So, I suggest running your tests when updating > your image, or migrating > your code to an updated image. > +1 to tests as they do help quite a bit and are a very > good practice. > Just be judicious in what/where you test (I personally > don't subscribe > to the TDD approach where you spend your days mostly > writing tests. > That's just admitting defeat in that you spend all day > writing > executable documentation.) > > <OT> > > I don't subscribe to "extreme" TDD either. To me design is a > creative activity, both technical and artistic. It should be > "driven" by creativity and intelligence, not by a process. Any > xDD process is admitting defeat on design itself! > > </OT> > > In any case, I think this doesn't answer your > concerns. What you need is > some way to know which updates could affect > you, to review them in > detail, and understanding their effect on your > code. A list of the > affected classes and/or methods for each > update makes no sense. Cuis can > already show you that very easily. Perhaps > each update should include: > > 1) parts of the system that are affected: > - Kernel > - Compiler > - Tools > - Morphic > - etc > > 2) Level of risk involved > - very unlikely to break code that depends on > this part of the system > - could perhaps break code that depends on > this part of the system > - will most likely break code that depends on > this part of the system > > Or something like that. > > BTW, this is a very relevant topic for > discussing on the mail list. Feel > free to answer there if you agree. > One final thought on this: I suspect a major cause of > people abandoning > Cuis (and Smalltalk in general), behind the 'it's too > different from > what I'm used to'/'not mainstream' reaction, is the > instability of its > APIs. > > Well, maybe. But the alternative (the whole Python 2.8 vs. 3.0 > problem) is a PITA too... > > As a bottom line, let me repeat: This is too big for me to do > it. Please, folks, start documenting the APIs you most care > about. > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Phil B
On Sun, 19 Jul 2015 20:39:31 -0400
"Phil (list)" <[hidden email]> wrote: > The issue is what constitutes a major change? If your code uses it it's > major, if mine uses it it's minor? Coin toss? Without a public API > what is considered major is either obvious (i.e. Morphic changes from > global to local coords or changing the File/Directory API so obviously > everything using them breaks) or arbitrary (sorry to hear that you > depended on that... but it wasn't major, now it's gone) If the image > snapshot is considered the public API, then everything must be both > considered fair game to depend on and to change in the future which is > unmanageable. I don't think this is the issue at all. The text editor comes up in every release with goals for Cuis. Backward compatibility is a stated non-goal. I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases. I trust Juan's leadership and judgment. His time is a scarce and valuable resource. He is very responsive to the Cuis community, including requests for backward compatibility and additional support. I do _not_ want to slow him down. If you have specific requirements, a package with Feature/Unit-tests is a good way to express this. > I'm not trying to restrict Juan in any way from making the changes he > thinks are important for Cuis. His taste and direction have been > generally excellent and the reason I'm here! If for example, he decides > that #drawOn: is no longer the way to do things or that even Morph > needed to go away, that's fine as long as what's going on gets > communicated. However, a problem I think he faces right now is that he > doesn't know who's using / depending on what. Pardon me, but this sounds exactly like you are trying to restrict certain changes. It seems that you are trying to "plan" and "rule set" rather than "discover quickly". My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path. My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process. I just prefer that process to be as small and painless (low drag) as possible. If some package is not in wide use, the author can test against releases as often as he/she feels it necessary. We can deal with breakage as it arises rather than planning search strategies for avoiding breakage. For me, this is much more efficient. Having API test suites is a good way to communicate importance. As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful. I heard that the Arabic word for "miracle" literally translates to "breaking the habit". Interesting thought. In the limit, we may be "agreeing loudly" here. Easy to sound strident in an email. Not the intent. What is the simplest thing that will work? -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Fwd: Re: DIRECT version number
|
|
On 7/20/15, Ken.Dickey <[hidden email]> wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400 > "Phil (list)" <[hidden email]> wrote: > >> The issue is what constitutes a major change? If your code uses it it's >> major, if mine uses it it's minor? Coin toss? Without a public API >> what is considered major is either obvious (i.e. Morphic changes from >> global to local coords or changing the File/Directory API so obviously >> everything using them breaks) or arbitrary (sorry to hear that you >> depended on that... but it wasn't major, now it's gone) If the image >> snapshot is considered the public API, then everything must be both >> considered fair game to depend on and to change in the future which is >> unmanageable. > > I don't think this is the issue at all. > > The text editor comes up in every release with goals for Cuis. Backward > compatibility is a stated non-goal. > > I am happy to baseline my packages a couple of times a year against a > baseline core release and maintain such matched baseline package releases. +1 > I trust Juan's leadership and judgment. His time is a scarce and valuable > resource. He is very responsive to the Cuis community, including requests > for backward compatibility and additional support. I do _not_ want to slow > him down. +1 > If you have specific requirements, a package with Feature/Unit-tests is a > good way to express this. +1 >> I'm not trying to restrict Juan in any way from making the changes he >> thinks are important for Cuis. His taste and direction have been >> generally excellent and the reason I'm here! If for example, he decides >> that #drawOn: is no longer the way to do things or that even Morph >> needed to go away, that's fine as long as what's going on gets >> communicated. +1 However, a problem I think he faces right now is that he >> doesn't know who's using / depending on what. > > Pardon me, but this sounds exactly like you are trying to restrict certain > changes. > > It seems that you are trying to "plan" and "rule set" rather than "discover > quickly". > > My experience is that quick discovery (like writing unit tests and running > them very frequently) is the fastest development path. > > My guess is that major packages which prove useful will either migrate into > the core packages or will be tested against as part of a larger release > process. I just prefer that process to be as small and painless (low drag) > as possible. > > If some package is not in wide use, the author can test against releases as > often as he/she feels it necessary. We can deal with breakage as it arises > rather than planning search strategies for avoiding breakage. For me, this > is much more efficient. > > Having API test suites is a good way to communicate importance. +1 > > As an aside, I have found some breakage to be very enlightening and > (sometimes painfully) helpful. I heard that the Arabic word for "miracle" > literally translates to "breaking the habit". Interesting thought. > > In the limit, we may be "agreeing loudly" here. Easy to sound strident in > an email. Not the intent. > > > What is the simplest thing that will work? > -KenD Probably the easiest is that Juan goes on as he is used to and a release manager or release team forks off a release / baseline from time to time. This allows for documenting an artifact which is no longer moving. Selected updates might be applied to the release until the next release is due. The documentation will got later on merged into the main branch as well. Hannes _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
In reply to this post by KenDickey
On Mon, Jul 20, 2015 at 3:55 PM, Ken.Dickey <[hidden email]> wrote:
I was thinking: "What should a Feature Test be?". I tried to look up what others have written, but found nothing useful (I probably did not look hard enough). Now, I don't mind thinking of something new, so here goes: 1. Clearly (to me), it should not be a kind of Unit Test. When you run a unit test, you assume that the unit under test is present in the system and you are trying to ascertain if it does certain things you expect. For this, unit tests have built-in facilities to detect execution errors and failed expectations, If such problems happen, unit tests are able to continue the testing process and report on the problems that occurred after the tests are run (this is the step forward that SUnit - or TSTTestingFramework as it ws known at the time - brought). 2. On the other hand, when you run a Feature Test, you may be testing one or more units, and one or more (or all) of those might not even be present. Therefore, a feature test should be able to run even if in the absence of the unit(s) supposed to implement the feature. So then, perhaps what a class FeatureTest should offer its subclasses, is a #run: aString method that tries to compile aString and if it compiles, execute it and look for any foreseen side effects and/or expression value. a test method might then look like: testApiReceiverIsPresentAndCanBeSetUp self run: 'ApiReceiver version > ''1.1.4''' expectEvaluationResult: true . self run: 'ApiReceiver setUp' . self expectSideEffect: 'ExpectedApiReceiver isSetUp' 3. Then it should be able to report that everything went well, or that there was a problem compiling (ideally with detailed info such as 'global Xxx was expected but was not present in the system'. If compiling went well, the execution should be protected and monitored similarly to unit tests that are already able to catch exceptions during execution. 4. Perhaps something along these lines would be the simplest thing that could possibly work? Would it help anyone if they had the FeatureTest class that they could subclass and as a result they could always, safely, test if some feature was present and did what you needed/expected of it? And you could have a Feature Test Runner that ran your feature test, made sure nothing crashed, and reported the results in a useful fashion. Just some thoughts, cheers, Peter _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by KenDickey
On Mon, 2015-07-20 at 06:55 -0700, Ken.Dickey wrote:
> On Sun, 19 Jul 2015 20:39:31 -0400 > "Phil (list)" <[hidden email]> wrote: > > > The issue is what constitutes a major change? If your code uses it it's > > major, if mine uses it it's minor? Coin toss? Without a public API > > what is considered major is either obvious (i.e. Morphic changes from > > global to local coords or changing the File/Directory API so obviously > > everything using them breaks) or arbitrary (sorry to hear that you > > depended on that... but it wasn't major, now it's gone) If the image > > snapshot is considered the public API, then everything must be both > > considered fair game to depend on and to change in the future which is > > unmanageable. > > I don't think this is the issue at all. > > The text editor comes up in every release with goals for Cuis. Backward compatibility is a stated non-goal. > The first issue (text editor working in every release) is the difference between reliability and stability, at least as I've been meaning in this discussion. Yes, it works in every release because it is part of what is at least implicitly tested to a degree as part of nearly every build. Cuis is very reliable in that within a given build things are generally working better than they did in the previous build. The backward compatibility non-goal seems like it should decrease as Cuis matures. (not sure if this is a recent change or not, but it actually does say that on the Cuis home page) Once we hit a minimal feature set, backwards incompatibility should largely go away as the result of a combination of Cuis becoming the simplest thing that would work and diminishing returns. Perhaps we disagree on how close to that point we are? As Juan indicated, at some point the packages start to play a larger role and at some point the same stability discussion becomes an issue there as well. (At least if the plan is to be able to build larger and more complex things using Cuis in the future) > I am happy to baseline my packages a couple of times a year against a baseline core release and maintain such matched baseline package releases. > In theory what you're saying makes sense but in practice I didn't find it worked. I tried that back in the 2.x days and again in 4.x but found the release notes just didn't have the detail to make this work for me. I disliked the results enough that I'm currently trying to stay within a build or two of Juan but that isn't realistic to expect most people to do (I don't think so, at least) and if I ever fall behind in the current model, I'm screwed... > I trust Juan's leadership and judgment. His time is a scarce and valuable resource. He is very responsive to the Cuis community, including requests for backward compatibility and additional support. I do _not_ want to slow him down. > I agree. The question is how do we accomplish this. My sense is that we are starting to chew up more of his time peppering him with questions / issues that he didn't anticipate resulting from recent changes. At the same time, for those who are not staying on the bleeding edge, there is a level of frustration in that we're living in an environment with very few constants and some of the changes have been starting to hurt. > If you have specific requirements, a package with Feature/Unit-tests is a good way to express this. > I guess I see explicitly identified public methods and feature/unit-tests as being complementary and helping lead to the same place. > > I'm not trying to restrict Juan in any way from making the changes he > > thinks are important for Cuis. His taste and direction have been > > generally excellent and the reason I'm here! If for example, he decides > > that #drawOn: is no longer the way to do things or that even Morph > > needed to go away, that's fine as long as what's going on gets > > communicated. However, a problem I think he faces right now is that he > > doesn't know who's using / depending on what. > > Pardon me, but this sounds exactly like you are trying to restrict certain changes. > Poor choice of wording on my part, I probably should have said something like 'prevent'. Putting any sort of limits on when / how changes can be made is a restriction. But I'm not actually asking him to *not* make the changes he thinks are necessary, but manage the when / how in some cases. > It seems that you are trying to "plan" and "rule set" rather than "discover quickly". > I am asking him to plan a bit more *only* for a subset of things that we agree need to be more stable than the rest. I still believe that is < 20% of the unique method names. > My experience is that quick discovery (like writing unit tests and running them very frequently) is the fastest development path. > > My guess is that major packages which prove useful will either migrate into the core packages or will be tested against as part of a larger release process. I just prefer that process to be as small and painless (low drag) as possible. > > If some package is not in wide use, the author can test against releases as often as he/she feels it necessary. We can deal with breakage as it arises rather than planning search strategies for avoiding breakage. For me, this is much more efficient. I don't think that most people will accept the compatibility through continual testing/fixing over a long period of time... most will likely give up after experiencing this for a while if they're attempting to use Cuis as something more than a playground. If the long term objective *isn't* for Cuis to be a platform, then an acceptable answer would be 'you're using it wrong'. Or Juan could simply say 'yeah, ok... but I really don't want to do that...' > > Having API test suites is a good way to communicate importance. > > > As an aside, I have found some breakage to be very enlightening and (sometimes painfully) helpful. I heard that the Arabic word for "miracle" literally translates to "breaking the habit". Interesting thought. > > In the limit, we may be "agreeing loudly" here. Easy to sound strident in an email. Not the intent. > I know you're generally pretty level headed and not looking to be disagreeable. I engaged in this discussion because it is an important one to have and it felt like the right time to have it. A lot of what is being proposed is a change from how things have historically been. But at the same time the pace of change has slowed down (ah, those whirlwind 1.x and 2.x days... :-) so it *seems* like trying to start to try to stabilize things a bit has relatively little downside. (Dunno... maybe Juan is working on chucking the whole Magnitude hierarchy or something major like that right now...) > > What is the simplest thing that will work? > -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Peter van Rooijen-2
On Tue, 21 Jul 2015 07:59:47 -0700
Peter van Rooijen <[hidden email]> wrote: >> I was thinking: "What should a Feature Test be?". I tend to think of a hierarchy of requirements. Perhaps something like: Feature requireAll: #( <feature name>.. ). Classes requireAll: #( <class name>.. ). Methods requireAll: #( <selector name>.. ). MethodsForKind class: <class name> requireAll: #( <selectorName>.. ). Tests requireAllPass: #( <unit test name> ). The Feature class lets us require named (macro) Features with a version check. I prefer that requirements at this level actually load the packages required and only report failure if that is not possible, although we could have a "preflight" verson which just checks without loading any featured packages. API's are basically "protocols", which in the absence of symbolic execution means checking that classes and specific method selectors exist, or more specifically, method selectors are applicable to specific KindOf: classes. Further, some Unit Tests may be required to pass to ensure compliance with some specification. We should be able to automate at least some of this, including a first pass of generating the test sets, which could then be pruned by hand as required. $0.02, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: (Rescued) Re: Fwd: Re: DIRECT version number
|
|
Hi Ken,
On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <[hidden email]> wrote: On Tue, 21 Jul 2015 07:59:47 -0700 Yeah, that's not at all what I'm thinking :). I'm thinking of something that is automatically runnable, like a unit test. It tests something, like a un test. But if the test does not pass, it is NOT a bug, unlike with a unit test. It's just that we would like to know about it. Also, with nit tests there is the assumption that the code that represents the test is always compilable, with feature tests that cannot be assumed, so there would need to be protection against that. Of course we want to be able to load the feature tests in any condition, so putting it in the form of source text and compiling that is a possibility. The fact that that makes it slower than unit tests is not a problem, because unlike unit tests, we don't have to run them continuously. The Feature class lets us require named (macro) Features with a version check. I prefer that requirements at this level actually load the packages required and only report failure if that is not possible, although we could have a "preflight" verson which just checks without loading any featured packages. I see. The thing I was thinking about merely reports about the state of a system (of code), it does not try to configure that in any way.
Well, in my mind some semantics could be expected (and tested for). For instance I might be interested if there is a DateTime class in the image and if it implements the ANSI DateAndTime protocol (not sure if there is one named that). Or perhaps another class that does that. These tests can test some actual semantics no problem. Perhaps some of you remember that Camp Smalltalk started with Ralph Johnson's desire to build an ANSI test suite. The way people went about it (extension methods to SUnit? I don't really remember) was wrong and could not possibly work (in my opinion anyway), but I could not convince a lot of people and such a test suite was never written. But with Feature Tests I think we could come a long way.
Well, except that the tests would not be unit tests in the strictest sense. But semantics, not merely interface, can be tested for sure.
Automate the running of the feature tests? Of course. including a first pass of generating the test sets, which could then be pruned by hand as required. That I don't see happening. You test what YOU think is important to be sure of. No machine can decide/calculate that for you. Perhaps I'm misunderstanding you. Cheers, Peter
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: (Rescued) Re: Fwd: Re: DIRECT version number
|
|
I'm thinking about some features (pun not intentional) of this Feature Test framework: 1. It's reasonable to assume that many tests will depend on something else working, but that cannot be counted on, and we would not want to repeat testing for that and also would not run into it failing all the time and that filling our feedback. 1a. So it would make sense to add a #precondition method to each Feature Test class. FeatureAnsiArray class precondition self run: 'Array' "i.e. the global Array must be present" then only if the precondition for the class is satisfied, will the test methods be executed. so if most of them start with 'Array new …' then they would all fail anyway so we don't need to test them. 2. You would want to be able to assure that in a particular object you would be able to access a particular variable. so in the test method you would write: FeatureTest1 class test1 self setContext: OrderdCollection new self run: 'elements' "determine if the inst var elements is present in a new OrderedCollection" self run: 'elements == nil' expect: false self run: 'elements isOrderedCollection' expect: true let's say the test runner would continue testing even if something failed, e.g. the array is called array, not elements. then we already know that the following expressions will fail so we might instead write: self run: 'elements' ifFail: [^self] 3. Instead of implicitly testing for a global using run: 'NameOfTheGlobal' or for a class var using setContext: and then run'NameOfTheClassVar' there could be convenience methods for self expectGlobal: 'NameOfTheGlobal' "argument may be given as a Symbol as well" self expectClass: 'NameOfTheClass' "additionally verified that the global holds a class" self expectSharedVariable: 'Foo' inClass: 'Bar' this would make for nicer feedback since the expectation is made clearer Okay just 2 more cents! Cheers, Peter On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Peter van Rooijen-2
On Wed, 22 Jul 2015 12:57:44 +0200
Peter van Rooijen <[hidden email]> wrote: > Hi Ken, > > On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey <[hidden email]> wrote: > > > On Tue, 21 Jul 2015 07:59:47 -0700 > > Peter van Rooijen <[hidden email]> wrote: > > > > >> I was thinking: "What should a Feature Test be?". > > > > I tend to think of a hierarchy of requirements. Perhaps something like: > > > > Feature requireAll: #( <feature name>.. ). > > Classes requireAll: #( <class name>.. ). > > Methods requireAll: #( <selector name>.. ). > > MethodsForKind class: <class name> requireAll: #( <selectorName>.. ). > > Tests requireAllPass: #( <unit test name> ). > > > > Yeah, that's not at all what I'm thinking :). I'm thinking of something > that is automatically runnable, like a unit test. It tests something, like > a un test. But if the test does not pass, it is NOT a bug, unlike with a > unit test. It's just that we would like to know about it. Also, with nit > tests there is the assumption that the code that represents the test is > always compilable, with feature tests that cannot be assumed, so there > would need to be protection against that. ... Remember the phrase "agreeing loudly"? OK, so you want the "preflight option" for Feature check. To not "fail a test" one has to test in sequence. - Are the Features present (as in Feature require: #<whatever> ) - Are the classes present? - Do the method selectors exist? - Are the right protocols there (method selectors exist for specific classes; e.g. #isFoo: is a method on a class for some aClass isKindOf: <foo>). - What code is expected to yield a specific result (actually run some code to check, like, well, a unit test). Failure at any step/level means something is missing and the more specific tests at the next level don't get run. A whole hierarchy of tests can be bundled as one Feature Test. How is this different than what you are proposing? -- -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
In reply to this post by Peter van Rooijen-2
On Wed, 2015-07-22 at 13:29 +0200, Peter van Rooijen wrote:
> I'm thinking about some features (pun not intentional) of this Feature > Test framework: > > > 1. It's reasonable to assume that many tests will depend on something > else working, but that cannot be counted on, and > we would not want to repeat testing for that and also would not run > into it failing all the time and that filling our feedback. > Why not? I agree that these would be a different category of test in that the dependencies would be more complex and often dependent on more than one package, but why would their functioning be considered optional? If they fail, shouldn't they either be addressed right away or explicitly deprecated? If you make the tests easy to ignore/forget about, they will be. If the functionality they are testing can't be counted on, it won't be used. If your thinking is that these would be tests that are part of package X but might rely on package Y which might not be loaded yet, why not instead just make the tests part of package Z which depends on package X and Y? The whole idea is that these are not unit tests in that sense... have them live where ever it is appropriate. > > 1a. So it would make sense to add a #precondition method to each > Feature Test class. > > > FeatureAnsiArray > class > precondition > > > self run: 'Array' "i.e. the global Array must be present" > > > then only if the precondition for the class is satisfied, will the > test methods be executed. so if most of them start with > > > 'Array new …' then they would all fail anyway so we don't need to test > them. > > > 2. You would want to be able to assure that in a particular object you > would be able to access a particular variable. > > > so in the test method you would write: > > > FeatureTest1 > class > test1 > > self setContext: OrderdCollection new > > > self run: 'elements' "determine if the inst var elements is > present in a new OrderedCollection" > > > self run: 'elements == nil' expect: false > > > self run: 'elements isOrderedCollection' expect: true > > > let's say the test runner would continue testing even if something > failed, e.g. the array is called array, not elements. then we already > know that the following expressions will fail > > > so we might instead write: > > > self run: 'elements' ifFail: [^self] > > > > 3. Instead of implicitly testing for a global using run: > 'NameOfTheGlobal' or for a class var using setContext: and then > run'NameOfTheClassVar' there could be convenience methods for > > > self expectGlobal: 'NameOfTheGlobal' "argument may be given as > a Symbol as well" > > > self expectClass: 'NameOfTheClass' "additionally verified that > the global holds a class" > > > self expectSharedVariable: 'Foo' inClass: 'Bar' > > > this would make for nicer feedback since the expectation is made > clearer I went the other way when I did the ApiFile tests in that it didn't seem terribly important to use most of the testing framework capabilities (other than the overall pass/fail aspect to keep the initial PoC as simple as possible) So they are simply small snippets of code that performed the desired task but didn't care where it failed (if it failed): the failure to successfully complete the task would be the indicator that there was a problem and we would know that either something being depended on had broken and needed to be fixed or that the test needed to be updated/overhauled to represent the new way of accomplishing the task. My thinking was that as we started to build up a number of these, we might start to see common breakage patterns and then we could decide whether or not to handle that them more explicitly (whether using the existing test framework capabilities, creating a new one, etc.) Trying to engineer it up front didn't seem like a great idea not knowing what common failure states would look like yet. > > > Okay just 2 more cents! > Mine as well. This is a worthwhile discussion/exercise IMO as we need to get to a common understanding of what we are doing here. > > Cheers, Peter > > > > > > On Wed, Jul 22, 2015 at 12:57 PM, Peter van Rooijen > <[hidden email]> wrote: > Hi Ken, > > On Wed, Jul 22, 2015 at 12:33 AM, Ken.Dickey > <[hidden email]> wrote: > On Tue, 21 Jul 2015 07:59:47 -0700 > Peter van Rooijen <[hidden email]> wrote: > > >> I was thinking: "What should a Feature Test be?". > > I tend to think of a hierarchy of requirements. > Perhaps something like: > > Feature requireAll: #( <feature name>.. ). > Classes requireAll: #( <class name>.. ). > Methods requireAll: #( <selector name>.. ). > MethodsForKind class: <class name> requireAll: > #( <selectorName>.. ). > Tests requireAllPass: #( <unit test name> ). > > > Yeah, that's not at all what I'm thinking :). I'm thinking of > something that is automatically runnable, like a unit test. It > tests something, like a un test. But if the test does not > pass, it is NOT a bug, unlike with a unit test. It's just that > we would like to know about it. Also, with nit tests there is > the assumption that the code that represents the test is > always compilable, with feature tests that cannot be assumed, > so there would need to be protection against that. Of course > we want to be able to load the feature tests in any condition, > so putting it in the form of source text and compiling that is > a possibility. The fact that that makes it slower than unit > tests is not a problem, because unlike unit tests, we don't > have to run them continuously. > > The Feature class lets us require named (macro) > Features with a version check. I prefer that > requirements at this level actually load the packages > required and only report failure if that is not > possible, although we could have a "preflight" verson > which just checks without loading any featured > packages. > > > I see. The thing I was thinking about merely reports about the > state of a system (of code), it does not try to configure that > in any way. > > > API's are basically "protocols", which in the absence > of symbolic execution means checking that classes and > specific method selectors exist, or more specifically, > method selectors are applicable to specific KindOf: > classes. > > > Well, in my mind some semantics could be expected (and tested > for). For instance I might be interested if there is a > DateTime class in the image and if it implements the ANSI > DateAndTime protocol (not sure if there is one named that). Or > perhaps another class that does that. These tests can test > some actual semantics no problem. > > > Perhaps some of you remember that Camp Smalltalk started with > Ralph Johnson's desire to build an ANSI test suite. The way > people went about it (extension methods to SUnit? I don't > really remember) was wrong and could not possibly work (in my > opinion anyway), but I could not convince a lot of people and > such a test suite was never written. But with Feature Tests I > think we could come a long way. > > Further, some Unit Tests may be required to pass to > ensure compliance with some specification. > > > Well, except that the tests would not be unit tests in the > strictest sense. But semantics, not merely interface, can be > tested for sure. > > We should be able to automate at least some of this > > > Automate the running of the feature tests? Of course. > > including a first pass of generating the test sets, > which could then be pruned by hand as required. > > > That I don't see happening. You test what YOU think is > important to be sure of. No machine can decide/calculate that > for you. Perhaps I'm misunderstanding you. > > > Cheers, Peter > > > $0.02, > -KenD > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |