1. Euphoria 3.2 compatibility
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
-
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
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
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
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
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
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
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
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
