From: Amitha P. <pe...@cs...> - 2006-03-20 15:53:48
|
Folks, Based on the compiler survey that Miguel initiated, and the pain of actually getting modern C++ code to work on VC6, I propose that we formally remove support for Visual Studio 6. Seconders? Objections? If agreed upon, the question is: when? While good release engineering dictates a deprecation period, I'm inclined to skip it for this. Few enough people have responded that they use VC6 to be worth the effort of working around the template-based linking issue currently on the dashboard. (The GCC errors have some other cause. Hopefully someone is looking into it.) Amitha. |
From: Matt L. <mat...@gm...> - 2006-03-20 16:00:41
|
I second that. I think it's time for VC6 to go. --Matt Leotta On 3/20/06, Amitha Perera <pe...@cs...> wrote: > Folks, > > Based on the compiler survey that Miguel initiated, and the pain of > actually getting modern C++ code to work on VC6, I propose that we > formally remove support for Visual Studio 6. Seconders? Objections? > > If agreed upon, the question is: when? While good release engineering > dictates a deprecation period, I'm inclined to skip it for this. Few > enough people have responded that they use VC6 to be worth the effort > of working around the template-based linking issue currently on the > dashboard. (The GCC errors have some other cause. Hopefully someone is > looking into it.) > > Amitha. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Ian S. <ian...@st...> - 2006-03-20 16:07:47
|
I support the deprecating of VC 6. However, I wouldn't like to decide this by majority voting. If there is anyone who heavily uses VXL under VC6 (bonus points if you are a maintainer) then I'd agree to supporting VXL for the time being. If such a person exists, then a commitment to abandoning VC6 by a agreed date in the not-too-distant future would be in order. Brad - you were the only one to explicitly argue for maintaining VC6 support is Miguel's survey. We could restrict VC6 support to vnl, vnl_algo, vcl, testlib for a few more releases. Would this be acceptable? In any case, I think minimal planned deprecation would be useful. This could consist of an email to vxl-announce that the next release of VXL will not support VC6. Ian. Amitha Perera wrote: > Folks, > > Based on the compiler survey that Miguel initiated, and the pain of > actually getting modern C++ code to work on VC6, I propose that we > formally remove support for Visual Studio 6. Seconders? Objections? > > If agreed upon, the question is: when? While good release engineering > dictates a deprecation period, I'm inclined to skip it for this. Few > enough people have responded that they use VC6 to be worth the effort > of working around the template-based linking issue currently on the > dashboard. (The GCC errors have some other cause. Hopefully someone is > looking into it.) > > Amitha. > |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-03-20 16:43:30
|
For what it's worth... I think deprecation of VC 6 is definitely in order. However, I do agree that we should accommodate the ITK's project needs, which shouldn't be hard to accomplish with some of CMake's magic... just my 0.0000001 cents ;) --Miguel Ian Scott wrote: > I support the deprecating of VC 6. > > However, I wouldn't like to decide this by majority voting. If there is > anyone who heavily uses VXL under VC6 (bonus points if you are a > maintainer) then I'd agree to supporting VXL for the time being. If such > a person exists, then a commitment to abandoning VC6 by a agreed date in > the not-too-distant future would be in order. > > Brad - you were the only one to explicitly argue for maintaining VC6 > support is Miguel's survey. We could restrict VC6 support to vnl, > vnl_algo, vcl, testlib for a few more releases. Would this be acceptable? > > In any case, I think minimal planned deprecation would be useful. This > could consist of an email to vxl-announce that the next release of VXL > will not support VC6. > > Ian. > > Amitha Perera wrote: >> Folks, >> >> Based on the compiler survey that Miguel initiated, and the pain of >> actually getting modern C++ code to work on VC6, I propose that we >> formally remove support for Visual Studio 6. Seconders? Objections? >> >> If agreed upon, the question is: when? While good release engineering >> dictates a deprecation period, I'm inclined to skip it for this. Few >> enough people have responded that they use VC6 to be worth the effort >> of working around the template-based linking issue currently on the >> dashboard. (The GCC errors have some other cause. Hopefully someone is >> looking into it.) >> >> Amitha. >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brad K. <bra...@ki...> - 2006-03-20 16:58:19
|
Ian Scott wrote: > I support the deprecating of VC 6. > > However, I wouldn't like to decide this by majority voting. If there is > anyone who heavily uses VXL under VC6 (bonus points if you are a > maintainer) then I'd agree to supporting VXL for the time being. If such > a person exists, then a commitment to abandoning VC6 by a agreed date in > the not-too-distant future would be in order. > > Brad - you were the only one to explicitly argue for maintaining VC6 > support is Miguel's survey. We could restrict VC6 support to vnl, > vnl_algo, vcl, testlib for a few more releases. Would this be acceptable? Yes. Meanwhile I'll bring this up with ITK developers. ITK is probably going to drop support soon anyway. -Brad |
From: Ian S. <ian...@st...> - 2006-03-21 09:13:38
|
While we are in to deprecating compiler support, it might be worth getting rid of a few other compilers at the same time. I'd suggest pre-emptively getting rid of VC7.0: It was never widely used, and it lacked support for some of the more advanced C++ used by Boost, etc. gcc 3.0 and 3.1: We have no dashboard builds for them, and they have been superceeded by better 3.* releases. BTW, We have already stopped support for GCC 2.95, BorlandCC 4, and IntelCC 7.0, without wide announcement. Ian. Amitha Perera wrote: > Folks, > > Based on the compiler survey that Miguel initiated, and the pain of > actually getting modern C++ code to work on VC6, I propose that we > formally remove support for Visual Studio 6. Seconders? Objections? > > If agreed upon, the question is: when? While good release engineering > dictates a deprecation period, I'm inclined to skip it for this. Few > enough people have responded that they use VC6 to be worth the effort > of working around the template-based linking issue currently on the > dashboard. (The GCC errors have some other cause. Hopefully someone is > looking into it.) > > Amitha. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Amitha P. <pe...@cs...> - 2006-03-21 16:26:40
|
Ian Scott wrote: > I'd suggest pre-emptively getting rid of > VC7.0: It was never widely used, and it lacked support for some of the > more advanced C++ used by Boost, etc. There is a current dashboard build for it, both for VXL and for our internal libraries. Personally, I have no strong tie to it, but I think that it's a recent enough compiler that I'd be more hesitant to immediately deprecate it. Unlike VC6, I think VC70 (.Net 2002) is still a vendor supported product. Deprecating VC7 is worth checking again with vxl-users. > gcc 3.0 and 3.1: We have no dashboard builds for them, and they have > been superceeded by better 3.* releases. Again, no objection, but I don't think they've given us the same level of frustration as has VC6. :-) For gcc, I don't mind deprecating more actively (but within reason), since there is no monetary cost involved in upgrading. Perhaps VC70 and gcc 3.0 and 3.1 could be part of a "proper" deprecation process? If no objections come up in our discussions here, I'll send a warning/request to vxl-users tomorrow, notifying folks that - VC6, gcc 3.0 and gcc 3.1 will not be supported in VXL 1.5 - Suggest that we want to deprecate VC70 in VXL 1.5, and remove support in VXL 1.6 Maybe by the end of next week, we can determine our courses of action. Amitha. |
From: Ian S. <ian...@st...> - 2006-03-21 16:24:52
|
Amitha Perera wrote: > Ian Scott wrote: > >>I'd suggest pre-emptively getting rid of >>VC7.0: It was never widely used, and it lacked support for some of the >>more advanced C++ used by Boost, etc. > > > There is a current dashboard build for it, both for VXL and for our > internal libraries. Personally, I have no strong tie to it, but I > think that it's a recent enough compiler that I'd be more hesitant to > immediately deprecate it. Unlike VC6, I think VC70 (.Net 2002) is > still a vendor supported product. Deprecating VC7 is worth checking > again with vxl-users. Some of the more advanced C++ I use in our internal code does not compile under VC7.0. Some of this may migrate into contrib/mul at some point. The main reason to get rid of VC7.0 support is to allow us to focus on 7.1 support - which I personally expect to use for a long time. > Perhaps VC70 and gcc 3.0 and 3.1 could be part of a "proper" > deprecation process? Sounds like a good idea. > > > If no objections come up in our discussions here, I'll send a > warning/request to vxl-users tomorrow, notifying folks that > - VC6, gcc 3.0 and gcc 3.1 will not be supported in VXL 1.5 > - Suggest that we want to deprecate VC70 in VXL 1.5, and remove > support in VXL 1.6 I've got a draft email already waiting to go. I just wanted to float the VC7.0, etc suggestion here, before I sent it. If you would prefer to send the email, let me know. Ian. |
From: Amitha P. <pe...@cs...> - 2006-03-21 17:30:45
|
Ian Scott wrote: > I've got a draft email already waiting to go. I just wanted to float the > VC7.0, etc suggestion here, before I sent it. If you would prefer to > send the email, let me know. No preference. Please go ahead. |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-03-21 16:57:38
|
FWIW, none of the users in the survey replied that they were using VC7.0 They were either using VC6 and willing to upgrade (which would mean to a VC7.1/VS8 I think) or they were using VC7.1. Users of GCC were at 3.3 and above... The survey results are still posted at: http://www.cse.msu.edu/~miguelf/vxl_compiler_survey.html --Miguel Ian Scott wrote: > Amitha Perera wrote: >> Ian Scott wrote: >> >>> I'd suggest pre-emptively getting rid of >>> VC7.0: It was never widely used, and it lacked support for some of >>> the more advanced C++ used by Boost, etc. >> >> >> There is a current dashboard build for it, both for VXL and for our >> internal libraries. Personally, I have no strong tie to it, but I >> think that it's a recent enough compiler that I'd be more hesitant to >> immediately deprecate it. Unlike VC6, I think VC70 (.Net 2002) is >> still a vendor supported product. Deprecating VC7 is worth checking >> again with vxl-users. > > Some of the more advanced C++ I use in our internal code does not > compile under VC7.0. Some of this may migrate into contrib/mul at some > point. The main reason to get rid of VC7.0 support is to allow us to > focus on 7.1 support - which I personally expect to use for a long time. > > >> Perhaps VC70 and gcc 3.0 and 3.1 could be part of a "proper" >> deprecation process? > > Sounds like a good idea. > >> >> >> If no objections come up in our discussions here, I'll send a >> warning/request to vxl-users tomorrow, notifying folks that >> - VC6, gcc 3.0 and gcc 3.1 will not be supported in VXL 1.5 >> - Suggest that we want to deprecate VC70 in VXL 1.5, and remove >> support in VXL 1.6 > > I've got a draft email already waiting to go. I just wanted to float the > VC7.0, etc suggestion here, before I sent it. If you would prefer to > send the email, let me know. > > Ian. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Amitha P. <pe...@cs...> - 2006-03-21 17:38:42
|
Miguel A. Figueroa-Villanueva wrote: > FWIW, none of the users in the survey replied that they were using VC7.0 > They were either using VC6 and willing to upgrade (which would mean to > a VC7.1/VS8 I think) or they were using VC7.1. It may well be that the dashboards are the only "people" using VC7.0, in which case removing support now rather than in 4 months may be warranted. I'm happy either way. I'll leave the call to you guys and whoever else cares about this issue. Amitha. |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-03-21 16:26:40
|
I don't have any ideas on it's popularity, but I can say that I have had to make some weird workarounds for template code that was running well in VC 7.1. --Miguel Ian Scott wrote: > While we are in to deprecating compiler support, it might be worth > getting rid of a few other compilers at the same time. > > I'd suggest pre-emptively getting rid of > VC7.0: It was never widely used, and it lacked support for some of the > more advanced C++ used by Boost, etc. > gcc 3.0 and 3.1: We have no dashboard builds for them, and they have > been superceeded by better 3.* releases. > > BTW, We have already stopped support for GCC 2.95, BorlandCC 4, and > IntelCC 7.0, without wide announcement. > > Ian. > > > > Amitha Perera wrote: >> Folks, >> >> Based on the compiler survey that Miguel initiated, and the pain of >> actually getting modern C++ code to work on VC6, I propose that we >> formally remove support for Visual Studio 6. Seconders? Objections? >> >> If agreed upon, the question is: when? While good release engineering >> dictates a deprecation period, I'm inclined to skip it for this. Few >> enough people have responded that they use VC6 to be worth the effort >> of working around the template-based linking issue currently on the >> dashboard. (The GCC errors have some other cause. Hopefully someone is >> looking into it.) >> >> Amitha. >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2006-03-21 16:27:02
|
I don't have any ideas on it's popularity, but I can say that I have had to make some weird workarounds for template code that was running well in VC 7.1. --Miguel Ian Scott wrote: > While we are in to deprecating compiler support, it might be worth > getting rid of a few other compilers at the same time. > > I'd suggest pre-emptively getting rid of > VC7.0: It was never widely used, and it lacked support for some of the > more advanced C++ used by Boost, etc. > gcc 3.0 and 3.1: We have no dashboard builds for them, and they have > been superceeded by better 3.* releases. > > BTW, We have already stopped support for GCC 2.95, BorlandCC 4, and > IntelCC 7.0, without wide announcement. > > Ian. > > > > Amitha Perera wrote: >> Folks, >> >> Based on the compiler survey that Miguel initiated, and the pain of >> actually getting modern C++ code to work on VC6, I propose that we >> formally remove support for Visual Studio 6. Seconders? Objections? >> >> If agreed upon, the question is: when? While good release engineering >> dictates a deprecation period, I'm inclined to skip it for this. Few >> enough people have responded that they use VC6 to be worth the effort >> of working around the template-based linking issue currently on the >> dashboard. (The GCC errors have some other cause. Hopefully someone is >> looking into it.) >> >> Amitha. >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Miguel A. Figueroa-V. <mi...@ms...> - 2006-03-27 18:18:33
|
Hello everyone, Is a vgui_adaptor for wxWidgets of interest to anyone? I have the adaptor and a working doc/view example that uses it (like the one in vgui/examples/mfc_example). The adaptor needs a few fixes still, but it is rendering, zooming, etc. This would allow to take advantage of the power of wxWidgets for GUI development while allowing to use the tableau in a child window. I haven't created the vgui_window and other vgui_toolkit parts, because, to be honest, I still don't understand everything that is going on in vgui, but I don't think that would be useful. In other words, I don't think there is much use in adding the capability of creating a minimal gui based on wxWidgets when there should be the alternative of another native toolkit. On the other hand, being able to build a full-blown cross-platform gui that supports the VXL tableaus is, in my opinion, quite useful. Amitha, if there is interest I can coordinate with you to commit it. Any feedback is appreciated. --Miguel |