Fwd: Re: DIRECT version number
Locked
12
12
Re: Fwd: Re: DIRECT version number
 
|
On 7/19/2015 9:39 PM, Phil (list) wrote:
> ... > 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. I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that way. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
1) and 2) sounds like there is a need for an Ubuntu type of approach.
Labelled releases at regular intervals -- could be semi-annually or annually. Some of them receive important bux fixes thus constituting Long Term Releases. Or stable vs unstable branches in github. In two days on the 25th of July it will be exactly 2 years after the last release of 4.2. :-) A point to consider as well is that what Juan is doing constitutes a trunk from which releases are forked from time to time by other people. The ones who run Feature Tests .... --Hannes On 7/23/15, Juan Vuletich <[hidden email]> wrote: > On 7/19/2015 9:39 PM, Phil (list) wrote: >> ... >> 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. > > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that > way. > > 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
|
|
In reply to this post by Phil B
Another specific comment:
On 7/20/2015 10:58 PM, Phil (list) wrote: > 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. This is a very good thing! I need to know the extent of the trouble I create when I change something. This is no longer my private quest for the perfect Smalltalk-80. Your needs are really important now! If some changes have issues I didn't anticipate, I need to know. This is another force (amongst a few others) driving the evolution of Cuis. > ... > 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. I don't want that to happen. > 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...' But now, after all these years, most of the worst, convoluted, horrible, apis and code inherited from Squeak have been cleaned. Right now, if I break something badly, and without any prior communication, it is most likely a mistake on my part. If I do such mistake, I'll be willing to fix it. I think this has happened a few times in this last couple of years. >> ... >> 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. >> ... Hehehe. Yes. > 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...) :D No, the only important API change we have planned is to move from FileDirectory to FileMan. We'll be doing relatively risky stuff, but not with the objective of changing APIs, although that might be a consequence. Some things I'd like to work in the next months / years are: - Spur. The Spur object format requires a few changes in the compiler and core classes - 64 bit. Having 64 and 32 bit images might also break stuff (?) - Bootstrap from sources - Switch to Morphic 3 Maybe I'm forgetting about something... And at some point, if possible, I'd like to integrate (or support and use as optional packages) Ropes and Unicode from Ken, VMMaker, code generation, VM simulation. Morphic programming for app developers should be easier and more convenient... And we might come up with other cool stuff to be done, that could perhaps impact a bit on APIs used by others... >> What is the simplest thing that will work? >> -KenD > That is indeed the question we need to answer. Cheers, Juan Vuletich _______________________________________________ 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 Phil B
Hi Phil,
This is very good and stong advocacy on documented public APIs. Thank you! (a few comments inline) On 7/19/2015 6:38 PM, Phil (list) wrote: > 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? :-) Yes. :) >> 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? No that I can think of. A bit of experimentation is in order. > 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. Sure. >>> ... >>>> 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. I think pragmas are the best options. Also, "API existence tests" should ask for those APIs to be declared as public. > 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... And some automated scripts to generate thos pragmas to write :) Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Hannes Hirzel
On Thu, 2015-07-23 at 14:09 +0000, H. Hirzel wrote:
> 1) and 2) sounds like there is a need for an Ubuntu type of approach. > > Labelled releases at regular intervals -- could be semi-annually or > annually. Some of them receive important bux fixes thus constituting > Long Term Releases. > LTS releases are a *lot* of work and add quite a bit of drag. Back-porting can be as much work as forward-porting (sometimes more.) I was thinking we start off as streamlined as possible: when 4.3 is released, it becomes the stable branch. At some point 4.4 (or whatever version # makes sense) is nearing release and there is some period of RC status for it. When 4.4 goes stable, 4.3 is retired an so on. That way we only have one stable release at a time to be concerned with. Also on the subject of LTS, I think we want to be careful not to get into a Debian mode of operation. That results in extreme stability at the price of glacially slow change. > Or stable vs unstable branches in github. > > In two days on the 25th of July it will be exactly 2 years after the > last release of 4.2. :-) > It's safe to say 2 years is a bit long between stable releases while 3 months would probably be too short. I like yearly, but every 6 months works too. Since there's probably going to be a period of something along the lines of RC status (a week? a month? no idea...) you don't want the releases too often or you're chewing up a lot of time preparing and testing releases and people are complaining that releases are too frequent. But that's just me spit-balling... I'm fine with whatever people prefer. > A point to consider as well is that what Juan is doing constitutes a > trunk from which releases are forked from time to time by other > people. The ones who run Feature Tests .... > How this gets implemented depends largely on Juan's preference. I guess the way I envisioned it is that most of the changes being made could go directly to stable (i.e. they are *mostly* bug fixes and behind the scenes improvements). Unless I'm mistaken, no one is really complaining that a change might temporarily break something as the fixes for those is almost always quick to arrive and don't require changes on our end (at least nothing that I can recall.) This would be more about changes that will break/alter the behavior of the public APIs (i.e. there's good reason to expect code breakage), either that goes into a development/alpha branch or could be managed similarly to how I *believe* Juan is handling Morphic 3 (i.e. changesets/packages that don't get applied to stable but rather batched up until they're ready for release driven both by the development effort and release timing) For example, the FileMan code is something that I would be fine having introduced in the middle of a stable branch's lifecycle. Just don't 'flip the switch' on it (i.e. breaking code compatibility from an API standpoint) until the next major stable release when there is sufficient notice and documentation for people to make the move. For me, it's all a question of 'will the change break my code?' I rather like bug fixes, new features, and workflow improvements enough that to the extent possible these should be encouraged in stable. Would that be too aggressive for you? > --Hannes > > On 7/23/15, Juan Vuletich <[hidden email]> wrote: > > On 7/19/2015 9:39 PM, Phil (list) wrote: > >> ... > >> 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. > > > > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that > > way. > > > > 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 |
Re: (Rescued) Re: Fwd: Re: DIRECT version number
|
|
In reply to this post by Phil B
Could we do examples of such Feature Tests?
Class String is a good candidate to start with Reasons a) Is used everywhere b) Interface is non-trivial String selectors size 166 (in Cuis) 338 (in Pharo) 331 (in Squeak) --> there are issues when porting. We might want to have a StringExtensions package --Hannes On 7/22/15, Phil (list) <[hidden email]> wrote: > 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 > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: (Rescued) Re: Fwd: Re: DIRECT version number
|
|
Hi Hannes, You asked for an example of a Feature Test. I assume, but may be wrong, that you want this to understand better what the intention of such a test is. Of course I can only answer form my own imagination. 1 It should be something that provides a definite answer to a question about the image/system, but where there is not necessarily a good or bad outcome (as there is with a unit test; pass=good, fail or error=bad). So for instance it could test if there is any class loaded that implements AnsiDateAndTime protocol (or at least part of it and how much). Or it could test if the number of classes is less than the number of instance variables. Or it could test how many classes have a class comment. It could test how many literals may be in a method. Still, it seems logical to want to define Features in such a way that the presence of the feature is a good situation (better or no worse than the absence). 2 An essential feature of a Feature Test is that it should be able to load and run in in any image. Its no use of course if you want to figure something out and you can't load and run the test that determines what you want to know. So The Feature test must be able to compile and run source code (it could conceivably interpret syntax trees but that seems rather contrived given that the compiler is normally available in any image). And while doing that it should be able to suppress any problems. 3 There should be some way to (build Feature Test Suites suites and/or) run all the loaded Feature tests together, silently, and receive feedback only at the end. Most simply in the form of a document/text that shows how it went. Optionally using some kind of GUI, viz. SUnitBrowser. The default FeatureTestSuite could simply run all loaded Feature Tests, and you could subclass it if you wanted to define specific Suites. I think it would be great to have a FeatureTest class that you could subclass to run tests on how much of the Ansi standard is implemented in the image and how accurately it follows the semantics prescribed. The original Camp Smalltalk attempts at such a test suite were based on SUnit as the test framework, but that didn't work as it is essentially unsuited to loading tests about code that may not be laoded. Cheers, Peter On Fri, Jul 31, 2015 at 8:29 AM, H. Hirzel <[hidden email]> wrote: Could we do examples of such Feature Tests? _______________________________________________ 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 Phil B
On 19/07/2015 22:38, Phil (list) wrote:
> 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. I vaguely recall that many years ago there was a project called SmallInterfaces that let you define public interfaces to objects. (Or something like that). Would that be a good way to document the public/private api using code? (sorry for being so vague but I've been awake for 24+ hours now) _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
Hi Doug,
On 8/2/2015 4:04 AM, Douglas Brebner wrote: > On 19/07/2015 22:38, Phil (list) wrote: >> 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. > > I vaguely recall that many years ago there was a project called > SmallInterfaces that let you define public interfaces to objects. (Or > something like that). Would that be a good way to document the > public/private api using code? > > (sorry for being so vague but I've been awake for 24+ hours now) Thanks for the pointer. I took a look at it. It is quite like Java interfaces. The tools are interesting. But I see several downsides: - Each interface is a class. Each method in the protocol is an actual method. If we use this to document all public protocols in Cuis, it would mean a lot of new classes and methods. - The source code of (for example) OrderedCollection>>at: would not include the information of it belonging to interface "Indexable". Without additional support from tools users can't tell whether a message is public protocol or not. And the base image / package maintainer can't easily see he's about to change a public api. I think a method pragma, that includes the name of the protocol avoids these issues and is a better choice. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:
> Hi Doug, > > On 8/2/2015 4:04 AM, Douglas Brebner wrote: > > On 19/07/2015 22:38, Phil (list) wrote: > >> 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. > > > > I vaguely recall that many years ago there was a project called > > SmallInterfaces that let you define public interfaces to objects. (Or > > something like that). Would that be a good way to document the > > public/private api using code? > > > > (sorry for being so vague but I've been awake for 24+ hours now) > > Thanks for the pointer. I took a look at it. It is quite like Java > interfaces. The tools are interesting. But I see several downsides: > > - Each interface is a class. Each method in the protocol is an actual > method. If we use this to document all public protocols in Cuis, it > would mean a lot of new classes and methods. > - The source code of (for example) OrderedCollection>>at: would not > include the information of it belonging to interface "Indexable". > Without additional support from tools users can't tell whether a message > is public protocol or not. And the base image / package maintainer can't > easily see he's about to change a public api. > > I think a method pragma, that includes the name of the protocol avoids > these issues and is a better choice. > I agree. Let's keep it as simple as possible and see how far that gets us. > 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, 1. I'm totally against introducing pragma's (perhaps they already exist in Cuis, I don't know). First of all because they are not Smalltalk, and second because they are not needed. What would be wrong with simply introducing a convention and adding a method cuisPublicSelectors to a class? To avoid seeing them on the instance side, there could also be cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class side. At the top these would be defined as self allSelectors. If someone wanted to view only the public selectors in a browser, they would check the checkbox for that and the browser would hide the non-public selectors. Or the browser could show a nice public interface report added to the class comment. 2. On another point: interfaces such as indexable could simply be described by creating a class CuisInterfaceSpecification which gets a subclass for each interface specified. The methods belonging to the interface are defined and get a comment explaining the semantics of the method. This makes it easy for tools to check which interfaces are (probably) implemented by a class. If desired, each method could be additionally defined to return a MethodSpecification object that knows about preconditions, invariants, return values, argument and return types/interfaces...but then it becomes progressively more complicated. But anyway, in this way whoever thinks it's important enough, can add the info (for public selectors of a class or for whole interface specifications) without anyone who is not interested in that needing to know or care about that. In my mind that gels well with Cuis' philosophy of simplicity. But I could be missing the whole point... Cheers, Peter On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote:
> Hi, > > > 1. I'm totally against introducing pragma's (perhaps they already > exist in Cuis, I don't know). > Too late, they're already there (VM functionality) > > First of all because they are not Smalltalk, and second because they > are not needed. > > > What would be wrong with simply introducing a convention and adding a > method cuisPublicSelectors to a class? > > > To avoid seeing them on the instance side, there could also be > cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class > side. > > > At the top these would be defined as self allSelectors. > > > If someone wanted to view only the public selectors in a browser, they > would check the checkbox for that and the browser would hide the > non-public selectors. > > > Or the browser could show a nice public interface report added to the > class comment. > > > 2. On another point: interfaces such as indexable could simply be > described by creating a class CuisInterfaceSpecification which gets a > subclass for each interface specified. The methods belonging to the > interface are defined and get a comment explaining the semantics of > the method. This makes it easy for tools to check which interfaces are > (probably) implemented by a class. If desired, each method could be > additionally defined to return a MethodSpecification object that knows > about preconditions, invariants, return values, argument and return > types/interfaces...but then it becomes progressively more complicated. > > > But anyway, in this way whoever thinks it's important enough, can add > the info (for public selectors of a class or for whole interface > specifications) without anyone who is not interested in that needing > to know or care about that. > This is too complicated for what I think we're trying to achieve... > > In my mind that gels well with Cuis' philosophy of simplicity. But I > could be missing the whole point... > The intent (what I was going for at least) is to provide a means for Juan and anyone else modifying the core image / packages to have a bidirectional communications channel with anyone looking to have a stable set of APIs that they can depend on. It needs to be something that's simple and easy for both Juan and us to use, or it won't get used. I think that Juan's pragma approach accomplishes this. All it signals is that 'this method will keep working as it currently does until/unless it is formally decided to change it'. So here's an example of how this might work: 1) Let's say we propose that #asString as a public API and Juan agrees that this is a useful method and should be fairly stable. Implementations of #asString get marked with a publicAPI (or whatever name makes sense) pragma 2) Those of us who care can then work to ensure that our code is using these publicAPI methods when possible. This will also help drive out some of our own bad behavior where we were calling things that we really shouldn't have been. 3) Time passes and life is good :-) 4) Down the line (Cuis 5.x, 6.x... whatever) Juan decides that #asString needs to change (who knows... unicode support... or maybe he just decides that #asString is the wrong way to do it) Seeing that #asString is flagged publicAPI, he knows not to 'just do it' but rather make sure that the change gets called out in the release notes (after some mailing list discussion if he deems it worthwhile to do so... his call) and that since it will likely break code to probably wait for a major release. This also allows for deprecating things that are designated as publicAPI... just because something is public does not mean it always will be, just that the changes to things that are need to be communicated more richly. For me, the documentation aspect of it is a nice to have secondary objective that falls out of it... getting to a stable core is the primary objective. (i.e. we're not documenting for the sake of documenting) > > Cheers, Peter > > > > > > > > > > On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <[hidden email]> > wrote: > On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote: > > Hi Doug, > > > > On 8/2/2015 4:04 AM, Douglas Brebner wrote: > > > On 19/07/2015 22:38, Phil (list) wrote: > > >> 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. > > > > > > I vaguely recall that many years ago there was a project > called > > > SmallInterfaces that let you define public interfaces to > objects. (Or > > > something like that). Would that be a good way to document > the > > > public/private api using code? > > > > > > (sorry for being so vague but I've been awake for 24+ > hours now) > > > > Thanks for the pointer. I took a look at it. It is quite > like Java > > interfaces. The tools are interesting. But I see several > downsides: > > > > - Each interface is a class. Each method in the protocol is > an actual > > method. If we use this to document all public protocols in > Cuis, it > > would mean a lot of new classes and methods. > > - The source code of (for example) OrderedCollection>>at: > would not > > include the information of it belonging to interface > "Indexable". > > Without additional support from tools users can't tell > whether a message > > is public protocol or not. And the base image / package > maintainer can't > > easily see he's about to change a public api. > > > > I think a method pragma, that includes the name of the > protocol avoids > > these issues and is a better choice. > > > > > I agree. Let's keep it as simple as possible and see how far > that gets > us. > > > 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 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Fwd: Re: DIRECT version number
|
|
Thanks Phil for the explanation. Cheers, Peter On Tue, Aug 4, 2015 at 5:20 AM, Phil (list) <[hidden email]> wrote: On Mon, 2015-08-03 at 22:35 +0200, Peter van Rooijen wrote: _______________________________________________ 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 |