From: Borut R. <bor...@si...> - 2007-06-08 21:03:08
|
Hello Raphael, I saw that you made some changes on pic regression tests, located at src/regression. I have some concerns about it: currently we have 2 regression test suites: - the pic14 specific one on src/regression, which you now enhanced to support also pic16 - the support/regression one which covers all targets, including pic14 and pic16 Probably there is a historical reason why the pic specific suite exists - it was created by Scott Dattalo back in December 2000, when he was working on pic back end. But currently I don't see the need for it's existence, as both pic targets are supported by the common src/regression suite. I think that some tests were already moved from src/regression to support/regression: the file names staring with scott-*. In order to avoid confusion I propose to make the suite at src/regression obsolete and remove it some when in the future. Please let me know your opinion. Borut |
From: Raphael N. <rn...@we...> - 2007-06-08 21:39:33
|
Hi Borut, > In order to avoid confusion I propose to make the suite at > src/regression obsolete and remove it some when in the future. I use the simpler testsuite for reference just because it is simpler to have individual files compiled and run. I have not dug too deep into the official testsuite, but that one seems to be rather well-suited if assuming that all tests pass. As for the PIC16 target, I get nigh on 100 failures, which does not help a lot and rather obfuscates the problems than pointing them out. More seriously, I guess changing the regression test while hunting bugs is not as straight forward as with the simpler suite. If I am not mistaken, the official suite generates the source files from a template according to some text replacement schemes embedded in the sources, which is great for generating huge amounts of test cases and checking a lot of type combinations, but in my eyes is the wrong approach to improving the PIC ports. > Please let me know your opinion. I would opt to keep the two regression test suites until the PIC ports are sufficiently complete/stable to make proper use of the official regression test suite. Alternatively, I could setup a local copy of the testsuite so that we can remove it from the svn repository in order not to confuse our user base. This, however, somehow goes against the spirit of sharing the code/results/tools used in development... Let's see how the PIC ports progress. Maybe we can plan removal of the suite for the 2.8.0 release? Regards, Raphael |
From: Maarten B. <sou...@ds...> - 2007-06-09 05:49:22
|
Raphael, Borut, I can fully agree with Raphael. If the src/regression tests help to develop the pic ports that's fine. But we must not consider them the regression test suite against which a stable version is checked. Maarten > Hi Borut, > > > In order to avoid confusion I propose to make the suite at > > src/regression obsolete and remove it some when in the future. > > I use the simpler testsuite for reference just because it is simpler to > have individual files compiled and run. I have not dug too deep into the > official testsuite, but that one seems to be rather well-suited if > assuming that all tests pass. As for the PIC16 target, I get nigh on 100 > failures, which does not help a lot and rather obfuscates the problems > than pointing them out. More seriously, I guess changing the regression > test while hunting bugs is not as straight forward as with the simpler > suite. If I am not mistaken, the official suite generates the source > files from a template according to some text replacement schemes > embedded in the sources, which is great for generating huge amounts of > test cases and checking a lot of type combinations, but in my eyes is > the wrong approach to improving the PIC ports. > > > Please let me know your opinion. > > I would opt to keep the two regression test suites until the PIC ports > are sufficiently complete/stable to make proper use of the official > regression test suite. > > Alternatively, I could setup a local copy of the testsuite so that we > can remove it from the svn repository in order not to confuse our user > base. This, however, somehow goes against the spirit of sharing the > code/results/tools used in development... > > Let's see how the PIC ports progress. Maybe we can plan removal of the > suite for the 2.8.0 release? > > Regards, > Raphael > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2007-06-09 06:40:03
|
Raphael, thank you for the explanation. I was just afraid that you are considering/using the src/regression as the "main" pic regtest suite. I don't mind to keep it in SVN, as long as we know it's purpose. And Maarten, I agree with you too. Borut Maarten Brock wrote: > Raphael, Borut, > > I can fully agree with Raphael. If the src/regression > tests help to develop the pic ports that's fine. But we > must not consider them the regression test suite against > which a stable version is checked. > > Maarten > > >> Hi Borut, >> >> >>> In order to avoid confusion I propose to make the suite at >>> src/regression obsolete and remove it some when in the future. >>> >> I use the simpler testsuite for reference just because it is simpler to >> have individual files compiled and run. I have not dug too deep into the >> official testsuite, but that one seems to be rather well-suited if >> assuming that all tests pass. As for the PIC16 target, I get nigh on 100 >> failures, which does not help a lot and rather obfuscates the problems >> than pointing them out. More seriously, I guess changing the regression >> test while hunting bugs is not as straight forward as with the simpler >> suite. If I am not mistaken, the official suite generates the source >> files from a template according to some text replacement schemes >> embedded in the sources, which is great for generating huge amounts of >> test cases and checking a lot of type combinations, but in my eyes is >> the wrong approach to improving the PIC ports. >> >> >>> Please let me know your opinion. >>> >> I would opt to keep the two regression test suites until the PIC ports >> are sufficiently complete/stable to make proper use of the official >> regression test suite. >> >> Alternatively, I could setup a local copy of the testsuite so that we >> can remove it from the svn repository in order not to confuse our user >> base. This, however, somehow goes against the spirit of sharing the >> code/results/tools used in development... >> >> Let's see how the PIC ports progress. Maybe we can plan removal of the >> suite for the 2.8.0 release? >> >> Regards, >> Raphael >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> >> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > |
From: Maarten B. <sou...@ds...> - 2007-06-09 07:55:46
|
Fellow developers, I know some of you use virtualization for testing SDCC. I've tried and abandoned QEMU for setting up a virtual machine running linux on a windows host. Now I've tried VMWare and was successful in it's install. I've got Debian running and SDCC compiles and passes regression tests like on a native debian box. I also got samba running and can share and compare files with my windows system. And now for the question: Even though I enabled ntp the virtual clock still skews heavily. So when I update a file on the virtual machine from the host, it gets a time in the future which 'make' never forgets to mention. How do you handle this? Greets, Maarten |
From: Borut R. <bor...@si...> - 2007-06-10 12:10:44
|
Maarten, try this: - run vmware-toolbox gui - on "Options" tab enable "Time synchronization between the virtual machine and the operating system" Let me know if this will help. Borut Maarten Brock wrote: > Fellow developers, > > I know some of you use virtualization for testing SDCC. > > I've tried and abandoned QEMU for setting up a virtual > machine running linux on a windows host. Now I've tried > VMWare and was successful in it's install. I've got > Debian running and SDCC compiles and passes regression > tests like on a native debian box. I also got samba > running and can share and compare files with my windows > system. > > And now for the question: Even though I enabled ntp the > virtual clock still skews heavily. So when I update a > file on the virtual machine from the host, it gets a > time in the future which 'make' never forgets to > mention. How do you handle this? > > Greets, > Maarten > |
From: Maarten B. <sou...@ds...> - 2007-06-10 15:24:10
|
Borut, Thanks. Somehow today the problem has vanished. I ran the update VMWare proposed me to run and I closed and reopened the debian VM and now time stays in sync. Anywhy I'm happy with it. Greets, Maarten > Maarten, > > try this: > - run vmware-toolbox gui > - on "Options" tab enable "Time synchronization between the virtual > machine and the operating system" > > Let me know if this will help. > > Borut > > > Maarten Brock wrote: > > Fellow developers, > > > > I know some of you use virtualization for testing SDCC. > > > > I've tried and abandoned QEMU for setting up a virtual > > machine running linux on a windows host. Now I've tried > > VMWare and was successful in it's install. I've got > > Debian running and SDCC compiles and passes regression > > tests like on a native debian box. I also got samba > > running and can share and compare files with my windows > > system. > > > > And now for the question: Even though I enabled ntp the > > virtual clock still skews heavily. So when I update a > > file on the virtual machine from the host, it gets a > > time in the future which 'make' never forgets to > > mention. How do you handle this? > > > > Greets, > > Maarten > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |