1. Euphoria 3.2 compatibility
- Posted by Larry Miller <larrymiller at s?sktel.n?t> Apr 24, 2008
- 704 views
I'm sure some people have considered this but many have not: Euphoria 3.2 or 4.0 in it's present form WILL cause many existing applications to break. There are 2 main causes. 1. Some programs use include files such as math.e, sequence.e, string.e, etc. Euphoria 3.2 adds these file to standard includes. This will cause errors if they define the same functions. 2. Many programs include files that define functions such as max(), min(), etc. These functions are defined in the new math.e include file. This will cause errors even if they do not explicitly include a math.e file. This is because many applications do include misc.e which currently includes math.e and sequence.e. This was done to avoid problems caused by a number of functions that were moved from misc.e to math.e and sequence.e. It may be best to move these functions back and remove the references to math.e and sequence.e from misc.e I know that Euphoria 3.2 has some changes to the include system but I don't think they address the above issues. Larry Miller
2. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at co??ar.com> Apr 24, 2008
- 657 views
Larry Miller wrote: > > I'm sure some people have considered this but many have not: Euphoria 3.2 or > 4.0 in it's present form WILL cause many existing applications to break. There > are 2 main causes. > > 1. Some programs use include files such as math.e, sequence.e, string.e, etc. > Euphoria 3.2 adds these file to standard includes. This will cause errors if > they define the same functions. > > 2. Many programs include files that define functions such as max(), min(), > etc. I think this is a reason to release it as 4.0. Then, instead of moving the functions back to misc.e, remove the includes in misc.e of math and sequence, since 4.0 is a major release. Yes, undoubtedly, *any* new function added to Euphoria either core or include/???.e *will* cause code to break. Even before I started on the standard library this was going to happen, because, a few functions were added: peeks, peek2s, peek2u, peek_string and poke2. Those are functions that many people use already but are not part of 3.1, thus 3.2 before the standard library would have broke many apps as well. So, I am in strong favor of 4.0. In addition to 4.0, I can create an "Upgrade" manual that states incompatibilities and what to do to make your app work in the new Euphoria. -- Jeremy Cowgar http://jeremy.cowgar.com
3. Re: Euphoria 3.2 compatibility
- Posted by c.k.lester <euphoric at ck?ester?com> Apr 24, 2008
- 658 views
Larry Miller wrote: > > many applications do include misc.e which currently includes math.e and > sequence.e. These includes need to be removed from misc.e.
4. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at c?wga?.com> Apr 24, 2008
- 663 views
c.k.lester wrote: > > Larry Miller wrote: > > > > many applications do include misc.e which currently includes math.e and > > sequence.e. > > These includes need to be removed from misc.e. Simply removing the includes will not solve the problem and will break things as well. The original intent was to provide some type of backward compatibility, but I think that's a dream. I am in agreement, they need to be removed, however, that's not a fix to the problem, is all I am saying. The problem can not be fixed, it's just a fact of life in this case. -- Jeremy Cowgar http://jeremy.cowgar.com
5. Re: Euphoria 3.2 compatibility
- Posted by OtterDad <otter at full-moon?com> Apr 24, 2008
- 652 views
Jeremy Cowgar wrote: > Yes, undoubtedly, *any* new function added to Euphoria either core or > include/???.e > *will* cause code to break. at the risk of being flamed to death, please see my previous reply which relates to upgrades and code breaking: http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=C&toMonth=8&toYear=C&postedBy=otterdad&keywords=frozen+language+versions or this entire thread: http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=7&fromYear=C&toMonth=9&toYear=C&keywords="Frozen+language+versions" <now dons fire retardant clothes> Yours, OtterDad Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
6. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at ?owgar.?om> Apr 24, 2008
- 667 views
OtterDad wrote: > > at the risk of being flamed to death, please see my previous reply which > relates > to upgrades and code breaking: OtterDad, I completely understand and with those applications, I too would stick with Euphoria 2.5. However, that's not to say that new programs you write cannot make use of all the new features of 3.x and 4.x. I also use Euphoria for production code at my work. I have not deployed to hundreds of thousands of people, but the code we have put together at work using Euphoria is in critical situations. The result if it fails too many times? I suppose I would be looking for a new job. Now, that being said, do I think Euphoria should stay as it was in 2.5? No. Euphoria needs a more standard library. What I, and others, are working on right now is to make a complete standard library. This is a huge jump for Euphoria. The whole intent is to make it complete and therefore, change as little as possible in the future. As it stands now, each new release of Euphoria changes a little bit and could possibly break code a little bit each release. I hate to keep going back to the peek2s example, but it's valid. If you made (or included) your own peek2s and upgrade to 3.2, then you will have a problem. Now, it's easily solved, yes, but a problem. Languages change and get better. That is what Euphoria is doing. Java, C, Forth, Ruby, etc... they all change. Some take change better than others. Euphoria is not one that takes change very well. For instance, in Java if you add a new method to the string class, your not going to break a thing. In Euphoria if you add a new method for strings called, say, pad_left(), that could potentially break a whole lot of code if you too have a function called pad_left(). That is the only reason that we see code breakages when upgrading Euphoria while we do not when we upgrade, say, Java. It's not because Java was designed perfectly from the start and never changes. Like wise, Euphoria was not designed perfectly from the start, as no language ever has. I am doing my best to break as little as possible, but with the addition of just 1 function, things will break. I hate that, but it's true and there is nothing that I can do about that. I am choosing function names carefully and when 4.0 is released I hope that it will contain a very robust set of functions that will make everyones coding much easier. We have not changed existing functions and have no plans of doing so. Does this make sense? -- Jeremy Cowgar http://jeremy.cowgar.com
7. Re: Euphoria 3.2 compatibility
- Posted by Matt Lewis <matthewwalkerlewis at gmail.c??> Apr 24, 2008
- 665 views
Jeremy Cowgar wrote: > > As it stands now, each new release of Euphoria changes a little bit and > could possibly break code a little bit each release. I hate to keep going > back to the peek2s example, but it's valid. If you made (or included) your > own peek2s and upgrade to 3.2, then you will have a problem. Now, it's > easily solved, yes, but a problem. Can you elaborate on how this will break any existing code--unless maybe if you're also using safe.e? Matt
8. Re: Euphoria 3.2 compatibility
- Posted by OtterDad <otter at f?ll-moon.com> Apr 24, 2008
- 658 views
Jeremy Cowgar wrote: > I am doing my best to break as little as possible, but with the addition of > just 1 function, things will break. I hate that, but it's true and there is > nothing that I can do about that. I am choosing function names carefully and > when 4.0 is released I hope that it will contain a very robust set of > functions > that will make everyones coding much easier. > > We have not changed existing functions and have no plans of doing so. > > Does this make sense? I'll buy your arguments. Believe me. I’m all for adding NEW features, just don’t break my existing Legacy code. My house payment depends on it :) Yours, OtterDad Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
9. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at cowg?r?com> Apr 24, 2008
- 656 views
Matt Lewis wrote: > > Jeremy Cowgar wrote: > > > > As it stands now, each new release of Euphoria changes a little bit and > > could possibly break code a little bit each release. I hate to keep going > > back to the peek2s example, but it's valid. If you made (or included) your > > own peek2s and upgrade to 3.2, then you will have a problem. Now, it's > > easily solved, yes, but a problem. > > Can you elaborate on how this will break any existing code--unless maybe if > you're also using safe.e? > Ok, so I just tried it. I'm wrong. Having peek2s will not break code, it will give a warning that it was redefined. Now, I tried this as well: === hi.e
global procedure hi() puts(1, "hi.e: Hi!\n") end procedure
=== test.e include hi.e procedure hi() puts(1, "test.e: Hi!\n") end procedure hi() </eucode> {{{ That works also, however, it does not give a warning that hi() was redefined. So, is the argument that new functions will break existing functions not valid? Therefore, we may have broke nothing what-so-ever in the 3.2/4.0 release? I guess I was just moving on things I thought I saw in the past and what others have stated as well. I just tried this test in 3.1 and it works as well in 3.1. -- Jeremy Cowgar http://jeremy.cowgar.com
10. Re: Euphoria 3.2 compatibility
- Posted by CChris <christian.cuvier at agricult?re.gouv?fr> Apr 24, 2008
- 662 views
OtterDad wrote: > > Jeremy Cowgar wrote: > > Yes, undoubtedly, *any* new function added to Euphoria either core or > > include/???.e > > *will* cause code to break. > > at the risk of being flamed to death, please see my previous reply which > relates > to upgrades and code breaking: > > <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=C&toMonth=8&toYear=C&postedBy=otterdad&keywords=frozen+language+versions">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=C&toMonth=8&toYear=C&postedBy=otterdad&keywords=frozen+language+versions</a> > > or this entire thread: > <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=7&fromYear=C&toMonth=9&toYear=C&keywords=">http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=7&fromYear=C&toMonth=9&toYear=C&keywords=</a>"Frozen+language+versions" > > <now dons fire retardant clothes> > > Yours, OtterDad > > Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford I can't remember who also wrote on this subject of legacy code and language stability. His strategy was to catalog exactly which version of which include, and which Eu version, each of his Eu apps used. In thatt way h said he was able to fully test any upgrade before proceeding to it, and to avoid surprises. Why not simply do that, and let the alive community add or enhance whatever exists? A lot of little things in Eu have been made overly simplistic, and the test of time has shown this was usually a liability, leading to either changes (value() now returns a 3 element sequence) or new routines (like find_from() from find()). CChris
11. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at cowga??com> Apr 24, 2008
- 677 views
Ok, I just tried:
include hi.e -- defines hi() procedure sequence hi hi = "Hi!" puts(1, hi & "\n")
That works w/o complaint. If I try to call hi(), as defined in hi.e, then I do get: Syntax error - expected to see =, +=, -=, *=, /= or &= hi() -- Jeremy Cowgar http://jeremy.cowgar.com
12. Re: Euphoria 3.2 compatibility
- Posted by Larry Miller <larrymiller at s?sk?el.net> Apr 24, 2008
- 656 views
I fear I have opened Pandora's box with my original post on this. I thought that the compatibility issues were important and everybody should be aware of them. I have read Jeremy's replies and I can understand where he is coming from. I can't say I agree completely but this is not a perfect world and complete agreement is not an achieveable goal. The version number should certainly by 4.0. When it is released there must be fairly long alpha and beta versions so the extent of any problems can be properly evaluated. Euphoria hasn't seen such extensive changes during my experience with the language. Larry Miller
13. Re: Euphoria 3.2 compatibility
- Posted by Matt Lewis <matthewwalkerlewis at gm?i?.com> Apr 24, 2008
- 646 views
Jeremy Cowgar wrote: > > > Ok, so I just tried it. I'm wrong. Having peek2s will not break code, it will > give a warning that it was redefined. > > Now, I tried this as well: > > === hi.e > }}} <eucode> > global procedure hi() > puts(1, "hi.e: Hi!\n") > end procedure > </eucode> {{{ > > === test.e > include hi.e > > procedure hi() > puts(1, "test.e: Hi!\n") > end procedure > > hi() > </eucode> {{{ > > That works also, however, it does not give a warning that hi() was redefined. > > So, is the argument that new functions will break existing functions not > valid? > Therefore, we may have broke nothing what-so-ever in the 3.2/4.0 release? > > I guess I was just moving on things I thought I saw in the past and what > others > have stated as well. I just tried this test in 3.1 and it works as well in > 3.1. It gets down to how symbols are resolved. Overloading a built in gives a warning. A local (or a global in the same file as it is being used) will take precedence over a global in another file. Two globals in other files will cause breakage:
-- app.ex include foo.e as foo include bar.e as bar procedure hi() puts(1, "app\n") end procedure hi() foo:hi() bar:hi() -- foo.e global procedure hi() puts(1,"foo\n") end procedure hi() -- bar.e include foo.e hi() global procedure hi() puts(1,"bar\n" ) end procedure hi()
$ exu app foo foo bar app foo bar Matt
14. Re: Euphoria 3.2 compatibility
- Posted by OtterDad <otter at full-moon?co?> Apr 24, 2008
- 655 views
CChris wrote: > His strategy was to catalog exactly which version of which include, > and which Eu version, each of his Eu apps used. <snip> Why not simply > do that, and let the alive community add or enhance whatever exists? I actually do that today. I store a copy of every included file and the entire bin directory used on every deployment. It bloats simple 20k exw files into 10 Meg deployment archives, but adds an invaluable stability layer that helps me sleep at night. Yours, OtterDad Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
15. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at cowga?.c?m> Apr 24, 2008
- 659 views
Matt Lewis wrote: > > It gets down to how symbols are resolved. Overloading a built in gives a > warning. A local (or a global in the same file as it is being used) will > take precedence over a global in another file. Two globals in other files > will cause breakage: So, with this in mind, the current SVN (be it 3.2 or 4.0) will break things if the user, say, defines min, max or say, remove as a global in one file and then also includes sequence.e. Because their file and sequence.e define those functions. So, we are breaking some things. Since peek2s is a built-in, it is not breaking anything. Correct? -- Jeremy Cowgar http://jeremy.cowgar.com
16. Re: Euphoria 3.2 compatibility
- Posted by Matt Lewis <matthewwalkerlewis at ?mai?.com> Apr 24, 2008
- 667 views
Jeremy Cowgar wrote: > > So, with this in mind, the current SVN (be it 3.2 or 4.0) will break things > if the user, say, defines min, max or say, remove as a global in one file and > then also includes sequence.e. Because their file and sequence.e define those > functions. sequence.e is a new file, so there's no backward compatibility involved. It's messing around with misc.e that will break some stuff. That's always been a troubling file to me. It deserves to be broken up. Anyone using any routines that were moved from there (most likely to break: sprint, reverse) will have to change code to include the new functions. I think this break in compatibility is probably the best argument for bumping the major version number. > So, we are breaking some things. Since peek2s is a built-in, it is not > breaking > anything. Correct? Correct. Matt
17. Re: Euphoria 3.2 compatibility
- Posted by Bernie Ryan <xotron at bl??frog.com> Apr 24, 2008
- 688 views
OtterDad wrote: > > CChris wrote: > > His strategy was to catalog exactly which version of which include, > > and which Eu version, each of his Eu apps used. <snip> Why not simply > > do that, and let the alive community add or enhance whatever exists? > > I actually do that today. I store a copy of every included file and the > entire bin directory used on every deployment. It bloats simple 20k exw > files into 10 Meg deployment archives, but adds an invaluable stability > layer that helps me sleep at night. > > Yours, OtterDad > > Don't sweat it -- it's not real life. It's only ones and zeroes. Gene > >Spafford OtterDad and others: This is what I think should happen. Stop adding features on up to 3.2. Start a NEW Version of Euphoria 4.0 and do all the changing you want; create new standard libraries but these will only be used by 4.0. This doesn't break any older code in the library if a person uses version 3.2. Then after the users get familiar with version 4.0 and iron out the bugs. The older archive programs can be gradualy rewritten to operate in version 4.0. Doing things the way they are now is stupid, people are running around to add new features while the other user's are trying to keep older code functioning with changes. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
18. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at ??wgar.com> Apr 24, 2008
- 692 views
Bernie Ryan wrote: > > This is what I think should happen. > Stop adding features on up to 3.2. No one is adding to 3.2. 3.2 does not exist. If we wish to release an interim copy of Euphoria before 4.0, we can easily grab it from SVN before work on the standard library began, but that would seem to create two rounds of changes? i.e. new functions are in 3.2 as well. The Changes, if that were done, would look like: ======== # Include file names with accent characters now supported. Implemented by C. Cuvier # Comments may now be embedded in data passed to value() in get.e. Implemented by C. Cuvier # Enhanced symbol resolution to take into account information regarding which files were included by which files. Implemented by Matthew Lewis # Namespaces for a source file now can be used for symbols in the specified file and for global symbols in all files included by the specified file. Implemented by Matthew Lewis # Added value_from() in get.e to return additional information about the parsing activity. Implemented by C. Cuvier # Command line arguments for the translator allow for creating binaries with debugging symbols, and to specify a different runtime library. Implemented by C. Cuvier # In trace mode, '?' will show the last defined variable of the requested name. Implemented by C. Cuvier # New builtin routines: peeks(), peek2s(), peek2u(), peek_string(), poke2() Implemented by Matthew Lewis # Include directories can now be specified based on command line arguments and config files in addition to environment variables. Implemented by Matthew Lewis # Improved accuracy in scanning numbers in scientific notation. Scanned numbers are accurate to the full precision of the IEEE 754 floating point standard. Implemented by Matthew Lewis ======== > Start a NEW Version of Euphoria 4.0 and do all the changing you > want; create new standard libraries but these will only be used > by 4.0. > > This doesn't break any older code in the library if a person uses > version 3.2. Why have the 3.2 interim release would be my question? Are there features there that people are dying to have? Why can this not be the 3.1.1 which is now tried and tested. If 3.2 were released and people treat it as the last "stable" release of Euphoria, it may only have 1 month of actual production usage at the time 4.0 is released. We as, if the 3.1.1 (current) is the last "stable 3.x" release, it already has 8 months of production use. Tried and true. > Then after the users get familiar with version 4.0 and iron out the > bugs. The older archive programs can be gradualy rewritten to > operate in version 4.0. Yes. I can see this. > Doing things the way they are now is stupid, people are running around > to add new features while the other user's are trying to keep older > code functioning with changes. I don't think this is happening? I hope no one is using a SVN trunk copy of anything for production use? I know some have been testing the new functionality in SVN trunk, which is fantastic and is needed. This will make the 1st release all that better. Also, I know it's not testing in the real world, but bear in mind that the new 4.0 now has over 250 unit tests running that verify the new functions are working according to how the author thinks they should work. This is not to say they are with out bugs, but, it's a great start. Euphoria has never had that before and I think it's a huge step. -- Jeremy Cowgar http://jeremy.cowgar.com
19. Re: Euphoria 3.2 compatibility
- Posted by c.k.lester <euphoric at ?klester.?om> Apr 24, 2008
- 662 views
- Last edited Apr 25, 2008
Jeremy Cowgar wrote: > > I hope no one is using a SVN trunk copy of anything for production use? Was that a comment or question. :P What's wrong with using trunk for production use? =8^O
20. Re: Euphoria 3.2 compatibility
- Posted by don cole <doncole at pacbel??net> Apr 24, 2008
- 669 views
- Last edited Apr 25, 2008
c.k.lester wrote: > > Jeremy Cowgar wrote: > > > > I hope no one is using a SVN trunk copy of anything for production use? > > Was that a comment or question. > > :P > > What's wrong with using trunk for production use? =8^O I think you guys are getting waaay off base here. Don Cole
21. Re: Euphoria 3.2 compatibility
- Posted by CChris <christian.cuvier at ag?icu?ture.gouv.fr> Apr 25, 2008
- 661 views
Jeremy Cowgar wrote: > > Bernie Ryan wrote: > > > > This is what I think should happen. > > Stop adding features on up to 3.2. > > No one is adding to 3.2. 3.2 does not exist. If we wish to release an interim > copy of Euphoria before 4.0, we can easily grab it from SVN before work on the > standard library began, but that would seem to create two rounds of changes? > i.e. new functions are in 3.2 as well. The Changes, if that were done, would > look like: > > ======== > > # Include file names with accent characters now supported. Implemented by C. > Cuvier > > # Comments may now be embedded in data passed to value() in get.e. Implemented > by C. Cuvier > > # Enhanced symbol resolution to take into account information regarding which > files were included by which files. Implemented by Matthew Lewis > > # Namespaces for a source file now can be used for symbols in the specified > file and for global symbols in all files included by the specified file. > Implemented > by Matthew Lewis > > # Added value_from() in get.e to return additional information about the > parsing > activity. Implemented by C. Cuvier > > # Command line arguments for the translator allow for creating binaries with > debugging symbols, and to specify a different runtime library. Implemented by > C. Cuvier Either I'm programming in my dreams using the cortex beta interface by ck lester, or this is an error. I have never dealt with the translator. > > # In trace mode, '?' will show the last defined variable of the requested > name. > Implemented by C. Cuvier > > # New builtin routines: peeks(), peek2s(), peek2u(), peek_string(), poke2() > Implemented by Matthew Lewis > > # Include directories can now be specified based on command line arguments and > config files in addition to environment variables. Implemented by Matthew > Lewis > > # Improved accuracy in scanning numbers in scientific notation. Scanned > numbers > are accurate to the full precision of the IEEE 754 floating point standard. > Implemented by Matthew Lewis > > ======== > > > Start a NEW Version of Euphoria 4.0 and do all the changing you > > want; create new standard libraries but these will only be used > > by 4.0. > > > > This doesn't break any older code in the library if a person uses > > version 3.2. > > Why have the 3.2 interim release would be my question? Are there features > there > that people are dying to have? Why can this not be the 3.1.1 which is now > tried > and tested. If 3.2 were released and people treat it as the last "stable" > release > of Euphoria, it may only have 1 month of actual production usage at the time > 4.0 is released. We as, if the 3.1.1 (current) is the last "stable 3.x" > release, > it already has 8 months of production use. Tried and true. > > > Then after the users get familiar with version 4.0 and iron out the > > bugs. The older archive programs can be gradualy rewritten to > > operate in version 4.0. > > Yes. I can see this. > > > Doing things the way they are now is stupid, people are running around > > to add new features while the other user's are trying to keep older > > code functioning with changes. > > I don't think this is happening? I hope no one is using a SVN trunk copy of > anything for production use? I know some have been testing the new > functionality > in SVN trunk, which is fantastic and is needed. This will make the 1st release > all that better. > > Also, I know it's not testing in the real world, but bear in mind that the new > 4.0 now has over 250 unit tests running that verify the new functions are > working > according to how the author thinks they should work. This is not to say they > are with out bugs, but, it's a great start. Euphoria has never had that before > and I think it's a huge step. Unit testing may or may not have caught the initial find_from() bug. Most bugs found so far in Eu (judging from the release notes) were in the translator and resulted from rare combinaions. I'm not saying unit testing is useless; that's something we have all done when developing a lib, I think, and it's trendy these days. The real bugs neeed more real world examples to show up, and I have no clear idea on how to automate part of their detection. Best thing so far is having as many users of the svn trunk as possible. CChris > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
22. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at cowga?.c?m> Apr 25, 2008
- 682 views
CChris wrote: > > Unit testing may or may not have caught the initial find_from() bug. > Most bugs found so far in Eu (judging from the release notes) were in the > translator > and resulted from rare combinaions. I'm not saying unit testing is useless; > that's something we have all done when developing a lib, I think, and it's > trendy > these days. The real bugs neeed more real world examples to show up, and I > have > no clear idea on how to automate part of their detection. Best thing so far > is having as many users of the svn trunk as possible. > Yes, but unit testing is more than trendy, it works. There are now over 350 tests. Normally, when developing a library (before unit testing), you created a test program that would output the results of many different operations and then you checked over it to make sure things looked right. How can you possibly look over 350 test points each time you make a change? Unit testing is going to ensure a more stable Euphoria. Again, as I said previously, in the real world there will be bugs that appear that unit testing did not catch. That's due to the inability to think of every possible test to create in unit testing. But once a bug is discovered, before it is fixed a unit test should be created exploiting the bug. When the unit tests are then run, the test should fail. A fix should then be made and it should be tested by the unit test. Now, from here until eternity, that bug should never appear again, as the unit test will catch it and report it to the developer. On large libraries or on modern scripting languages, there are thousands of tests. There is no reason to think that Euphoria will not be the same way. Now, in regards to the translator... That's no problem. Before releases, just translate the unit tests to a binary and run that. That should catch translator bugs too? -- Jeremy Cowgar http://jeremy.cowgar.com
23. Re: Euphoria 3.2 compatibility
- Posted by CChris <christian.cuvier at agricultur?.gouv?fr> Apr 25, 2008
- 661 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > Unit testing may or may not have caught the initial find_from() bug. > > Most bugs found so far in Eu (judging from the release notes) were in the > > translator > > and resulted from rare combinaions. I'm not saying unit testing is useless; > > that's something we have all done when developing a lib, I think, and it's > > trendy > > these days. The real bugs neeed more real world examples to show up, and I > > have > > no clear idea on how to automate part of their detection. Best thing so far > > is having as many users of the svn trunk as possible. > > > > Yes, but unit testing is more than trendy, it works. There are now over 350 > tests. Normally, when developing a library (before unit testing), you created > a test program that would output the results of many different operations and > then you checked over it to make sure things looked right. How can you > possibly > look over 350 test points each time you make a change? Unit testing is going > to ensure a more stable Euphoria. Again, as I said previously, in the real > world > there will be bugs that appear that unit testing did not catch. That's due to > the inability to think of every possible test to create in unit testing. But > once a bug is discovered, before it is fixed a unit test should be created > exploiting > the bug. When the unit tests are then run, the test should fail. A fix should > then be made and it should be tested by the unit test. Now, from here until > eternity, that bug should never appear again, as the unit test will catch it > and report it to the developer. On large libraries or on modern scripting > languages, > there are thousands of tests. There is no reason to think that Euphoria will > not be the same way. > > Now, in regards to the translator... That's no problem. Before releases, just > translate the unit tests to a binary and run that. That should catch > translator > bugs too? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> I agree that unit testing is an impressive looking bug trap that learns. Experience tells me that it hardly reduces the flow of bugs, who avoid it fast. It's a mean cat, but mice come the other way. Let's have it for the sake of peace of mind. CChris
24. Re: Euphoria 3.2 compatibility
- Posted by Jeremy Cowgar <jeremy at cowgar?c?m> Apr 25, 2008
- 667 views
CChris wrote: > > I agree that unit testing is an impressive looking bug trap that learns. > Experience > tells me that it hardly reduces the flow of bugs, who avoid it fast. It's a > mean cat, but mice come the other way. Let's have it for the sake of peace of > mind. > Hm, that's disappointing. Maybe I'm a bad programmer, but testing in my experience has caught many, many bugs before ever being deployed. I thought the function was done, the basics worked, but then I add weird unit tests and bugs appear, so I fix, and then deploy. It also gives great assurance, make a core change that affects large areas, then run unit tests. Great! Hundreds of functions that rely on the one I just changed still works! -- Jeremy Cowgar http://jeremy.cowgar.com
25. Re: Euphoria 3.2 compatibility
- Posted by c.k.lester <euphoric at ck?ester?com> Apr 25, 2008
- 648 views
Jeremy Cowgar wrote: > > It also gives great assurance, make a core change that affects large areas, > then run unit tests. Great! Hundreds of functions that rely on the one I just > changed still works! Yeah, at times I wish I had unit testing for BBCMF. :D
26. Re: Euphoria 3.2 compatibility
- Posted by Matt Lewis <matthewwalkerlewis at gmail.c??> Apr 25, 2008
- 661 views
CChris wrote: > > Jeremy Cowgar wrote: > > > > # Command line arguments for the translator allow for creating binaries > > with debugging symbols, and to specify a different runtime library. > > Implemented by C. Cuvier > > Either I'm programming in my dreams using the cortex beta interface by ck > lester, > or this is an error. I have never dealt with the translator. I'm pretty sure this was me. I also snipped massive amounts of text out of this post. Matt
27. Re: Euphoria 3.2 compatibility
- Posted by Matt Lewis <matthewwalkerlewis at gmail.?om> Apr 25, 2008
- 663 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > Unit testing may or may not have caught the initial find_from() bug. > > Most bugs found so far in Eu (judging from the release notes) were in > > the translator and resulted from rare combinaions. I'm not saying unit > > testing is useless; that's something we have all done when developing > > a lib, I think, and it's trendy these days. The real bugs neeed more > > real world examples to show up, and I have no clear idea on how to > > automate part of their detection. Best thing so far is having as many > > users of the svn trunk as possible. > > Yes, but unit testing is more than trendy, it works. I agree. We've just needed someone willing to get us started. Thanks for taking this on. But CChris is also correct. Lots of stuff will get by unit testing. At least we should reduce regressions. Matt