1. Revision 417 -- tests are broke
Chris,
I did an SVN up and the tests do not run any more due to a syntax error, missing
an ending paren in two places.
Then when I run the tests, functions that previously worked no longer work.
Can you please run the unittests before committing?
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Revision 417 -- tests are broke
Jeremy Cowgar wrote:
>
> Chris,
>
> I did an SVN up and the tests do not run any more due to a syntax error,
> missing
> an ending paren in two places.
>
> Then when I run the tests, functions that previously worked no longer work.
>
> Can you please run the unittests before committing?
>
Ok, after fixing the syntax errors in the unittests, I looked at the results.
The functions are returning incorrect values. So, my subject is not correct. The
tests are not broke, the functions are.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: Revision 417 -- tests are broke
Jeremy Cowgar wrote:
>
> Jeremy Cowgar wrote:
> >
> > Chris,
> >
> > I did an SVN up and the tests do not run any more due to a syntax error,
> > missing
> > an ending paren in two places.
> >
> > Then when I run the tests, functions that previously worked no longer work.
> >
> > Can you please run the unittests before committing?
> >
>
> Ok, after fixing the syntax errors in the unittests, I looked at the results.
> The functions are returning incorrect values. So, my subject is not correct.
> The tests are not broke, the functions are.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Running the unit tests means the interpreter should choose the right include
files, and it must be the the right interpreter as well. EUING and EUDIR normally
take care, but changing them under Windows is a pain (need to reboot the
machine).
Is anything like configuration files that override the environment working?
btw, which routines don't return as expected?
CChris
4. Re: Revision 417 -- tests are broke
CChris wrote:
>
> Running the unit tests means the interpreter should choose the right include
> files, and it must be the the right interpreter as well. EUING and EUDIR
> normally
You have to test functions before committing though! How do you know if they
work? For instance, some things added were missing a ending paren. Please do not
commit without testing. The repo has been broke for some time now. Other people
working on functions for standard library (me right now, but in the future others
as well) cannot really proceed because unit testing is broke, etc...
We must do our best to keep the repo in a working order. There will always be
times when we commit something that doesn't work on accident or that has a
serious flaw we did not detect, but it should not be because we didn't test what
we've changed.
> Is anything like configuration files that override the environment working?
No, but the way I do it is pretty easy (I think). I have:
C:\EUPHORIA
C:\EUPHORIA31 -or- C:\EUPHORIA40
I then have two batch files:
eu40.bat
eu31.bat
eu40.bat simply:
1. renames C:\EUPHORIA to C:\EUPHORIA31
2. renames C:\EUPHORIA40 to C:\EUPHORIA
eu31.bat simply:
1. renames C:\EUPHORIA to C:\EUPHORIA40
2. renames C:\EUPHORIA31 to C:\EUPHORIA
I then keep:
SET EUDIR=C:\EUPHORIA
SET PATH=C:\EUPHORIA\BIN;%PATH%
> btw, which routines don't return as expected?
Well, that's hard to say because I only get a few bad returns before Euphoria
crashes.
regex.e:
failed: search_replace() #1. expected: "the ABC ran ABC" but got: {
116't',
104'h',
101'e',
32' ',
"ABC",
32' ',
114'r',
97'a',
110'n',
32' ',
"ABC"
}
failed: search_replace_user() #1. expected: "the dog ran up" but got: {
116't',
104'h',
101'e',
32' ',
"dog",
32' ',
114'r',
97'a',
110'n',
32' ',
"up"
}
sequence.e:
failed: split_adv() single sequence delimiter. expected: {
"while 1 ",
" end while ",
""
} but got: {
"while 1 ",
"",
" en",
" while ",
"",
""
}
Then I get:
/opt/euphoria/include/sequence.e:103 in function remove()
type_check failure, start is 1.5
... called from ./t_sequence.e:56
--> See ex.err
Can you please fix these mistakes and then run the unit tests to make sure they
are working again and commit the fixes? To run the unit tests takes about 3
seconds and to run them, you:
C:\ > cd C:\EUPHORIA\TESTS
C:\EUPHORIA\TESTS > exwc all.ex
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: Revision 417 -- tests are broke
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> > Running the unit tests means the interpreter should choose the right include
> > files, and it must be the the right interpreter as well. EUING and EUDIR
> > normally
>
> You have to test functions before committing though! How do you know if they
> work? For instance, some things added were missing a ending paren. Please do
> not commit without testing. The repo has been broke for some time now. Other
> people working on functions for standard library (me right now, but in the
> future
> others as well) cannot really proceed because unit testing is broke, etc...
>
> We must do our best to keep the repo in a working order. There will always be
> times when we commit something that doesn't work on accident or that has a
> serious
> flaw we did not detect, but it should not be because we didn't test what we've
> changed.
>
> > Is anything like configuration files that override the environment working?
>
> No, but the way I do it is pretty easy (I think). I have:
>
> C:\EUPHORIA
> C:\EUPHORIA31 -or- C:\EUPHORIA40
>
> I then have two batch files:
>
> eu40.bat
> eu31.bat
>
> eu40.bat simply:
>
> 1. renames C:\EUPHORIA to C:\EUPHORIA31
> 2. renames C:\EUPHORIA40 to C:\EUPHORIA
>
> eu31.bat simply:
>
> 1. renames C:\EUPHORIA to C:\EUPHORIA40
> 2. renames C:\EUPHORIA31 to C:\EUPHORIA
>
> I then keep:
>
> SET EUDIR=C:\EUPHORIA
> SET PATH=C:\EUPHORIA\BIN;%PATH%
>
> > btw, which routines don't return as expected?
>
> Well, that's hard to say because I only get a few bad returns before Euphoria
> crashes.
>
> regex.e:
> failed: search_replace() #1. expected: "the ABC ran ABC" but got: {
> 116't',
> 104'h',
> 101'e',
> 32' ',
> "ABC",
> 32' ',
> 114'r',
> 97'a',
> 110'n',
> 32' ',
> "ABC"
> }
> failed: search_replace_user() #1. expected: "the dog ran up" but got: {
> 116't',
> 104'h',
> 101'e',
> 32' ',
> "dog",
> 32' ',
> 114'r',
> 97'a',
> 110'n',
> 32' ',
> "up"
> }
> sequence.e:
> failed: split_adv() single sequence delimiter. expected: {
> "while 1 ",
> " end while ",
> ""
> } but got: {
> "while 1 ",
> "",
> " en",
> " while ",
> "",
> ""
> }
>
> Then I get:
>
> /opt/euphoria/include/sequence.e:103 in function remove()
> type_check failure, start is 1.5
>
> ... called from ./t_sequence.e:56
>
> --> See ex.err
>
>
> Can you please fix these mistakes and then run the unit tests to make sure
> they
> are working again and commit the fixes? To run the unit tests takes about 3
> seconds and to run them, you:
>
> C:\ > cd C:\EUPHORIA\TESTS
> C:\EUPHORIA\TESTS > exwc all.ex
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
The issue with split_adv() had occurred while I was testing, but I no longer get
it.
Adding ?split_adv("while 1 do end while do","do",0,0)?1/0
to sequence.e and running it (under 3.1), I get the expected result as shown in
t_sequence.e.
Guess I'll have to do the rename trick to keep going, including for compiling
4.0 (intoptions, get_switches and three other unknown refs at link time).
CChris
Running
6. Re: Revision 417 -- tests are broke
CChris wrote:
>
> Guess I'll have to do the rename trick to keep going, including for compiling
> 4.0 (intoptions, get_switches and three other unknown refs at link time).
>
Do you have 4.0? I've been able to help get 4.0 compiling on a few other peoples
machines via IRC. If you are having problems with those undefined vars/functions
or whatever, I can help on IRC get that resolved.
irc.freenode.net #euphoria
--
Jeremy Cowgar
http://jeremy.cowgar.com
7. Re: Revision 417 -- tests are broke
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> > Guess I'll have to do the rename trick to keep going, including for
> > compiling
> > 4.0 (intoptions, get_switches and three other unknown refs at link time).
> >
>
> Do you have 4.0? I've been able to help get 4.0 compiling on a few other
> peoples
> machines via IRC. If you are having problems with those undefined
> vars/functions
> or whatever, I can help on IRC get that resolved.
>
> irc.freenode.net #euphoria
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I'm told that "It works!". Happy, but not quite...
CChris
8. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at cowga?.c?m>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
>
> I'm told that "It works!". Happy, but not quite...
>
I'm not sure I follow. I did an svn up and the same tests still fail. Are you
talking about the compile worked?
--
Jeremy Cowgar
http://jeremy.cowgar.com
9. Re: Revision 417 -- tests are broke
- Posted by CChris <christian.cuvier at agricultur?.g?uv.fr>
May 08, 2008
-
Last edited May 09, 2008
At revision 424:
All tests for sequence.e and search.e pass under Eu 3.1.1 .
I cannot yet compile Eu 4.0 under WinXP, OpenWatcom 1.7, getting these errors,
already reported iirc:
linking all the files...
Warning! W1008: cannot open graph.lib : No such file or directory
Error! E2028: _4wildcard_file_ is an undefined reference
Error! E2028: _18scientific_to_atom_ is an undefined reference
Error! E2028: _22intoptions_ is an undefined reference
Error! E2028: _23get_switches_ is an undefined reference
Error! E2028: compile_pcre_ is an undefined reference
Error! E2028: exec_pcre_ is an undefined reference
file file.obj(C:\EUPHORIA\source\file.c): undefined symbol _4wildcard_file_
file scanner.obj(C:\EUPHORIA\source\scanner.c): undefined symbol _18scientific_t
o_atom_
file backend.obj(C:\EUPHORIA\source\backend.c): undefined symbol _22intoptions_
file backend.obj(C:\EUPHORIA\source\backend.c): undefined symbol _23get_switches
_
file be_machine.obj(C:\EUPHORIA\source\be_machine.c): undefined symbol compile_p
cre_
file be_machine.obj(C:\EUPHORIA\source\be_machine.c): undefined symbol exec_pcre
_
irc.freenode.net displays a page saying "It works!" Good to know, but not quite
functional...
CChris
10. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at cowgar.?om>
May 08, 2008
-
Last edited May 09, 2008
Chris,
I noticed in r424, that the change log message is:
Now all tests pass for sequence.e and search.e under Eu3.1
Do you have 4.0 installed? It really does not matter if the 4.0 libs pass in
3.1. It may not pass in 4.0 due to internal changes or, for instance, requiring
4.0 internal features.
We really need to test 4.0 with 4.0. Do you have it installed?
--
Jeremy Cowgar
http://jeremy.cowgar.com
11. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at c?w?ar.com>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
>
>
> irc.freenode.net displays a page saying "It works!" Good to know, but not
> quite
> functional...
>
Huh that's strange. However, you do not need to connect via a web browser. You
need to use an IRC client. mirc for windows is a nice one, or you can connect
via: http://www.rapideuphoria.com/chatroom.html
That will get you in too. Please come and we will get your problems figured out
w/4.0 compiling.
--
Jeremy Cowgar
http://jeremy.cowgar.com
12. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at cow?ar.?om>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
>
>
> At revision 424:
> All tests for sequence.e and search.e pass under Eu 3.1.1 .
>
stack.e still fails but the others are cleared up, yay! Thanks.
stack.e:
failed: FIFO dup(). expected: {1,30,20,10,10} but got: {1,30,30,20,10}
failed: FIFO pop() #1. expected: {1,30,20} but got: {1,30,30}
--
Jeremy Cowgar
http://jeremy.cowgar.com
13. Re: Revision 417 -- tests are broke
- Posted by CChris <christian.cuvier at a??iculture.gouv.fr>
May 08, 2008
-
Last edited May 09, 2008
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> >
> > At revision 424:
> > All tests for sequence.e and search.e pass under Eu 3.1.1 .
> >
>
> stack.e still fails but the others are cleared up, yay! Thanks.
>
> stack.e:
> failed: FIFO dup(). expected: {1,30,20,10,10} but got: {1,30,30,20,10}
> failed: FIFO pop() #1. expected: {1,30,20} but got: {1,30,30}
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
As I mentioned earlier, it depends on whether dup() is supposed to duplicate the
last pushed value or the top(). I don't remember you replied to this.
The second failure is caused by the same issue, since the stack is not in the
expected shape.
CChris
PS: Looks like a test for the tests is needed 
14. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at cowg?r?com>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
>
>
> As I mentioned earlier, it depends on whether dup() is supposed to duplicate
> the last pushed value or the top(). I don't remember you replied to this.
> The second failure is caused by the same issue, since the stack is not in the
> expected shape.
>
> CChris
> PS: Looks like a test for the tests is needed
http://www.openeuphoria.org/EUforum/m20654.html
dup() should duplicate the top item. Whenever working with a stack, almost
everything happens to the top item. swap() for instance, swaps the top item with
the one below it. drop() (pop()) removes the top item, etc...
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at cowga??com>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
> PS: Looks like a test for the tests is needed
Well, about unit testing. When the author writes a new function, he/she writes a
tests to ensure it's working like they think it should. If a change is made and
that test no longer works, then it should be assumed that since it's in the repo
that the author gave it's functionality his/her stamp of approval. So, that means
that it's working according to their spec of how it should work.
Now, as you found in a couple of places, maybe their spec was wrong. If you
think it was but are unsure, then you should contact them about it and ask, why
is it doing it like this. In a few today that you found, it was clear the spec
(or name) was a tad off, so fixing it is good.
So, I do not think a test needs to be made for the tests, we just need to ensure
that the tests are run and continue to pass and if not, figure out why. For
instance, right now the document generation uses the new 4.0 stack (it is, after
all the 4.0 doc generator). Luckily it uses the FILO stack, otherwise, CK lester
would have been out of business today because the stack is broke.
--
Jeremy Cowgar
http://jeremy.cowgar.com
16. Re: Revision 417 -- tests are broke
- Posted by CChris <christian.cuvier at agr?culture.go?v.fr>
May 08, 2008
-
Last edited May 09, 2008
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> >
> > As I mentioned earlier, it depends on whether dup() is supposed to duplicate
> > the last pushed value or the top(). I don't remember you replied to this.
> > The second failure is caused by the same issue, since the stack is not in
> > the
> > expected shape.
> >
> > CChris
> > PS: Looks like a test for the tests is needed
>
> <a
> href="http://www.openeuphoria.org/EUforum/m20654.html">http://www.openeuphoria.org/EUforum/m20654.html</a>
>
>
>
> dup() should duplicate the top item. Whenever working with a stack, almost
> everything
> happens to the top item. swap() for instance, swaps the top item with the one
> below it. drop() (pop()) removes the top item, etc...
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Ok, reverting the changes to stack.e then.
CChris
17. Re: Revision 417 -- tests are broke
- Posted by Jeremy Cowgar <jeremy at co?gar.co?>
May 08, 2008
-
Last edited May 09, 2008
CChris wrote:
>
>
> Ok, reverting the changes to stack.e then.
>
push() acts differently depending on type of stack... FIFO = First in first out
or FILO = First in last out. So, since push alters which end of the stack items
are added to, that allows functions like dup(), top(), at(), swap() all to work
the same way regardless of stack type.
BTW... Just SVN up'ed
636 tests run, 636 passed, 0 failed, 100% success
Yay! Yay! Yay! Thanks!
--
Jeremy Cowgar
http://jeremy.cowgar.com
18. Re: Revision 417 -- tests are broke
CChris wrote:
>
>
> Running the unit tests means the interpreter should choose the right include
> files, and it must be the the right interpreter as well. EUING and EUDIR
> normally
Are you running 95 or 98? Even there, you should be able to set variables in
a shell, right?
> Is anything like configuration files that override the environment working?
It should be. There should probably be an euinc.conf in the tests directory
that includes something like this:
../include
Since that should be the relative path to the include directory.
Matt
19. Re: Revision 417 -- tests are broke
CChris wrote:
>
>
> At revision 424:
> All tests for sequence.e and search.e pass under Eu 3.1.1 .
>
> I cannot yet compile Eu 4.0 under WinXP, OpenWatcom 1.7, getting these errors,
> already reported iirc:
<snip>
This is only slightly helpful. What did you do to get these? What you
probably want to do is:
> wmake -f makefile.wat interpreter
...or, if you want it to build all windows stuff:
> wmake -f makefile.wat winall
The top of the makefile has comments to tell you different targets and
parameters that can be passed.
Matt
20. Re: Revision 417 -- tests are broke
Matt Lewis wrote:
>
> CChris wrote:
> >
> >
> > At revision 424:
> > All tests for sequence.e and search.e pass under Eu 3.1.1 .
> >
> > I cannot yet compile Eu 4.0 under WinXP, OpenWatcom 1.7, getting these
> > errors,
> > already reported iirc:
>
> <snip>
>
> This is only slightly helpful. What did you do to get these? What you
> probably want to do is:
>
Matt,
I've been able to help everyone who has come to IRC build 4.0. No one has been
unable to build. What I've found is EUDIR and/or EUINC env vars are set wrong
causing the .c files generated from a few include\ files to be incorrect. For
instance, wildcard.e use to include upper() and lower(), but now sequence.e does.
The Makefiles look for sequence.c in intobj (and others) but if generated off old
3.1 builds, sequence.c will not exist.
Once the EUDIR and EUINC vars are set correctly, no one has had a problem
building.
--
Jeremy Cowgar
http://jeremy.cowgar.com
