From: Matt L. <mat...@ki...> - 2012-02-09 20:26:49
|
VXL users and maintainers, At Kitware we've toying with the idea of creating Python bindings for VXL. The main goal would be to allow the use of VXL's core classes and functions from Python. We also want to integrate vnl and vil tightly with NumPy. OpenCV and many other C++ libraries have similar functionality. We've done some proof of concept test and found that, for example, we can wrap a vil_image_view as a NumPy array and manipulate the underlying memory without deep copying. The reverse is also possible. Before we invest much more effort into this I'd like to gauge developers interest and acceptance of this idea. I suspect the interest from VXL users would be high, but I'm less confident such bindings could actually be committed back to the VXL repository without updating our policies. We would be using Boost.Python to create the bindings since this is far easier than manually doing it with Python's C interface. In addition to Boost this would require linking to Python and NumPy libraries. I would not want to have to put any of these in v3p. The code for these binding would also make heavy use of modern C++ features, like namespaces, that are generally frowned upon in VXL. I see this as an optional component to VXL, so either: 1) This code is contributed to the VXL repository, but lives in a separate subdirectory, and is disabled in CMake by default. Building Python bindings would require the user to provide Python, Boost.Python, and NumPy. 2) The code is a separate project that depends on VXL and has its own version control repository. It would probably use a newer version of CMake, use "newer" C++ features (C++03, not C++11), and be maintained separately. Either way, we would probably set up the framework and wrap just some key classes and functions at first. Initial focus would be on vil and vnl, secondary focus on vgl and vpgl. We would probably not go much beyond that and allow the community to contribute additional bindings as needed. There is no need to wrap some libraries like vpl and vul since Python already has these capabilities. Does anyone have any opinions on this matter? Is anyone interested in helping if we can get the ball rolling? Thanks, Matt |
From: Joseph M. <mu...@le...> - 2012-02-09 21:59:36
|
Matt, This idea is appealing to us. We already use Python extensively as you know to loosely couple to VXL via cached memory objects. This approach seems a good step forward from what we are doing. We can likely help if you get the framework set up. Joe -----Original Message----- From: Matt Leotta [mailto:mat...@ki...] Sent: Thursday, February 09, 2012 3:27 PM To: Vxl-maintainers; vxl-users Cc: Ben Boeckel Subject: [Vxl-maintainers] Python bindings for VXL and NumPy integration VXL users and maintainers, At Kitware we've toying with the idea of creating Python bindings for VXL. The main goal would be to allow the use of VXL's core classes and functions from Python. We also want to integrate vnl and vil tightly with NumPy. OpenCV and many other C++ libraries have similar functionality. We've done some proof of concept test and found that, for example, we can wrap a vil_image_view as a NumPy array and manipulate the underlying memory without deep copying. The reverse is also possible. Before we invest much more effort into this I'd like to gauge developers interest and acceptance of this idea. I suspect the interest from VXL users would be high, but I'm less confident such bindings could actually be committed back to the VXL repository without updating our policies. We would be using Boost.Python to create the bindings since this is far easier than manually doing it with Python's C interface. In addition to Boost this would require linking to Python and NumPy libraries. I would not want to have to put any of these in v3p. The code for these binding would also make heavy use of modern C++ features, like namespaces, that are generally frowned upon in VXL. I see this as an optional component to VXL, so either: 1) This code is contributed to the VXL repository, but lives in a separate subdirectory, and is disabled in CMake by default. Building Python bindings would require the user to provide Python, Boost.Python, and NumPy. 2) The code is a separate project that depends on VXL and has its own version control repository. It would probably use a newer version of CMake, use "newer" C++ features (C++03, not C++11), and be maintained separately. Either way, we would probably set up the framework and wrap just some key classes and functions at first. Initial focus would be on vil and vnl, secondary focus on vgl and vpgl. We would probably not go much beyond that and allow the community to contribute additional bindings as needed. There is no need to wrap some libraries like vpl and vul since Python already has these capabilities. Does anyone have any opinions on this matter? Is anyone interested in helping if we can get the ball rolling? Thanks, Matt ---------------------------------------------------------------------------- -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brendan M. <bre...@gm...> - 2012-02-13 07:37:08
|
Hi Matt, I am very much in support of this move. I can see benefits and draw-backs to both option 1 and 2 below. I have a slight preference for option 2, but in that case, I would prefer all of contrib to be split off into a separate project. This has the advantage of making official releases rather easier since core does not change often (but that's my bias showing both as the release guy and someone who has used very little of contrib). Either way, I'm strongly in favour of python bindings for vxl. I might be able to help a bit, but probably shouldn't be relied upon for any heavy lifting. On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: > VXL users and maintainers, > > At Kitware we've toying with the idea of creating Python bindings for > VXL. The main goal would be to allow the use of VXL's core classes and > functions from Python. We also want to integrate vnl and vil tightly > with NumPy. OpenCV and many other C++ libraries have similar > functionality. We've done some proof of concept test and found that, > for example, we can wrap a vil_image_view as a NumPy array and > manipulate the underlying memory without deep copying. The reverse is > also possible. > > Before we invest much more effort into this I'd like to gauge developers > interest and acceptance of this idea. I suspect the interest from VXL > users would be high, but I'm less confident such bindings could actually > be committed back to the VXL repository without updating our policies. > We would be using Boost.Python to create the bindings since this is far > easier than manually doing it with Python's C interface. In addition to > Boost this would require linking to Python and NumPy libraries. I would > not want to have to put any of these in v3p. The code for these binding > would also make heavy use of modern C++ features, like namespaces, that > are generally frowned upon in VXL. > > I see this as an optional component to VXL, so either: > > 1) This code is contributed to the VXL repository, but lives in a > separate subdirectory, and is disabled in CMake by default. Building > Python bindings would require the user to provide Python, Boost.Python, > and NumPy. > > 2) The code is a separate project that depends on VXL and has its own > version control repository. It would probably use a newer version of > CMake, use "newer" C++ features (C++03, not C++11), and be maintained > separately. > > Either way, we would probably set up the framework and wrap just some > key classes and functions at first. Initial focus would be on vil and > vnl, secondary focus on vgl and vpgl. We would probably not go much > beyond that and allow the community to contribute additional bindings as > needed. There is no need to wrap some libraries like vpl and vul since > Python already has these capabilities. > > Does anyone have any opinions on this matter? Is anyone interested in > helping if we can get the ball rolling? > > Thanks, > Matt > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@ki...> - 2012-02-13 18:28:29
|
Brendan, I would also be in favor of splitting contrib off into a separate repository, or even one repository per contributor. This would make release management much easier. The official release would only contain VXL core libraries. Each contributor would then have the responsibility of making releases of their own contrib sections, if they care about releases. The Python bindings could be another add-on repository. At Kitware we would handle this setup with what we call "superbuilds". A superbuild is a repository that refers to specific commits of various other repositories. So you could checkout and build the various projects separately if you want, but you can also checkout the superbuild and it will checkout all the repositories you need and build everything in one massive build. This allows for smaller sub-projects that are easier to manage, but also makes it easy to do a single unified build of everything if that is what you want. I'm not sure if this can be done effectively with subversion, but it works well with git using the git submodule feature. At Kitware we have migrated all of our code repositories from svn and cvs to git. In fact we do all our VXL work in git and push changes back upstream via the git-svn interface. Git has a bit of a learning curve, but is so much more powerful than svn or cvs that once you learn it is very hard to go back. What is the VXL community's feeling on moving to git? If a good portion of developers are already familiar with git then it maybe it would make sense to switch. I can see the possibility of Kitware migrating VXL to git, splitting it into separate repositories, setting up the superbuild, and then taking responsibility for making the stable releases of VXL core. I can't promise anything right now because I have to check that we can find funding to do this. However, we certainly have the technical experience to do this migration if the community is in favor of it. Moving from svn to git is about more than the submodule feature. It's a fundamental shift from centralized version control to distributed version control. It requires a totally different mindset on version control. I expect there will need to be a lot of debate about whether or not to migrate to git and also what the work flow would be if we adopted git. git supports various different development work flows, the simplest of which is the linear, single-branch of history used by cvs and svn. There are other work flows that are better suited toward managing stable releases. --Matt On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: > Hi Matt, > > I am very much in support of this move. I can see benefits and > draw-backs to both option 1 and 2 below. I have a slight preference for > option 2, but in that case, I would prefer all of contrib to be split > off into a separate project. This has the advantage of making official > releases rather easier since core does not change often (but that's my > bias showing both as the release guy and someone who has used very > little of contrib). > > Either way, I'm strongly in favour of python bindings for vxl. I might > be able to help a bit, but probably shouldn't be relied upon for any > heavy lifting. > > On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: > > VXL users and maintainers, > > > > At Kitware we've toying with the idea of creating Python bindings for > > VXL. The main goal would be to allow the use of VXL's core classes and > > functions from Python. We also want to integrate vnl and vil tightly > > with NumPy. OpenCV and many other C++ libraries have similar > > functionality. We've done some proof of concept test and found that, > > for example, we can wrap a vil_image_view as a NumPy array and > > manipulate the underlying memory without deep copying. The reverse is > > also possible. > > > > Before we invest much more effort into this I'd like to gauge developers > > interest and acceptance of this idea. I suspect the interest from VXL > > users would be high, but I'm less confident such bindings could actually > > be committed back to the VXL repository without updating our policies. > > We would be using Boost.Python to create the bindings since this is far > > easier than manually doing it with Python's C interface. In addition to > > Boost this would require linking to Python and NumPy libraries. I would > > not want to have to put any of these in v3p. The code for these binding > > would also make heavy use of modern C++ features, like namespaces, that > > are generally frowned upon in VXL. > > > > I see this as an optional component to VXL, so either: > > > > 1) This code is contributed to the VXL repository, but lives in a > > separate subdirectory, and is disabled in CMake by default. Building > > Python bindings would require the user to provide Python, Boost.Python, > > and NumPy. > > > > 2) The code is a separate project that depends on VXL and has its own > > version control repository. It would probably use a newer version of > > CMake, use "newer" C++ features (C++03, not C++11), and be maintained > > separately. > > > > Either way, we would probably set up the framework and wrap just some > > key classes and functions at first. Initial focus would be on vil and > > vnl, secondary focus on vgl and vpgl. We would probably not go much > > beyond that and allow the community to contribute additional bindings as > > needed. There is no need to wrap some libraries like vpl and vul since > > Python already has these capabilities. > > > > Does anyone have any opinions on this matter? Is anyone interested in > > helping if we can get the ball rolling? > > > > Thanks, > > Matt > > > > > > ------------------------------------------------------------------------------ > > Virtualization & Cloud Management Using Capacity Planning > > Cloud computing makes use of virtualization - but cloud computing > > also focuses on allowing computing to be delivered as a service. > > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Ricardo F. <ric...@us...> - 2012-02-13 18:54:51
|
Hi, I would suggest having the separate Python binding repository hosted in the same VXL's sourceforge account. Multiple Git repositories can be set there. That way the two projects can maximize each other's visibility. I am very much in favor of the move to Git and have pushed for it in the past. I currently use it with VXL SVN the same way Matt does: https://sourceforge.net/apps/trac/vxl/wiki/GitSvn Moving to Git has the drawback that most users would have to download the entire history with a simple "git clone". For a project this big, a "git clone --bare" is an important thing to stress for casual users, otherwise the download may take too long. Of course, for developers it is a huge benefit to have the history locally accessible. I can also help occasionally with the Python move, if needed. Best, Ricardo -- www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ On Mon, Feb 13, 2012 at 4:28 PM, Matt Leotta <mat...@ki...> wrote: > Brendan, > > I would also be in favor of splitting contrib off into a separate > repository, or even one repository per contributor. This would make > release management much easier. The official release would only contain > VXL core libraries. Each contributor would then have the responsibility > of making releases of their own contrib sections, if they care about > releases. The Python bindings could be another add-on repository. > > At Kitware we would handle this setup with what we call "superbuilds". > A superbuild is a repository that refers to specific commits of various > other repositories. So you could checkout and build the various > projects separately if you want, but you can also checkout the > superbuild and it will checkout all the repositories you need and build > everything in one massive build. This allows for smaller sub-projects > that are easier to manage, but also makes it easy to do a single unified > build of everything if that is what you want. > > I'm not sure if this can be done effectively with subversion, but it > works well with git using the git submodule feature. At Kitware we have > migrated all of our code repositories from svn and cvs to git. In fact > we do all our VXL work in git and push changes back upstream via the > git-svn interface. Git has a bit of a learning curve, but is so much > more powerful than svn or cvs that once you learn it is very hard to go > back. > > What is the VXL community's feeling on moving to git? If a good portion > of developers are already familiar with git then it maybe it would make > sense to switch. I can see the possibility of Kitware migrating VXL to > git, splitting it into separate repositories, setting up the superbuild, > and then taking responsibility for making the stable releases of VXL > core. I can't promise anything right now because I have to check that > we can find funding to do this. However, we certainly have the > technical experience to do this migration if the community is in favor > of it. > > Moving from svn to git is about more than the submodule feature. It's a > fundamental shift from centralized version control to distributed > version control. It requires a totally different mindset on version > control. I expect there will need to be a lot of debate about whether > or not to migrate to git and also what the work flow would be if we > adopted git. git supports various different development work flows, the > simplest of which is the linear, single-branch of history used by cvs > and svn. There are other work flows that are better suited toward > managing stable releases. > > --Matt > > On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: >> Hi Matt, >> >> I am very much in support of this move. I can see benefits and >> draw-backs to both option 1 and 2 below. I have a slight preference for >> option 2, but in that case, I would prefer all of contrib to be split >> off into a separate project. This has the advantage of making official >> releases rather easier since core does not change often (but that's my >> bias showing both as the release guy and someone who has used very >> little of contrib). >> >> Either way, I'm strongly in favour of python bindings for vxl. I might >> be able to help a bit, but probably shouldn't be relied upon for any >> heavy lifting. >> >> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: >> > VXL users and maintainers, >> > >> > At Kitware we've toying with the idea of creating Python bindings for >> > VXL. The main goal would be to allow the use of VXL's core classes and >> > functions from Python. We also want to integrate vnl and vil tightly >> > with NumPy. OpenCV and many other C++ libraries have similar >> > functionality. We've done some proof of concept test and found that, >> > for example, we can wrap a vil_image_view as a NumPy array and >> > manipulate the underlying memory without deep copying. The reverse is >> > also possible. >> > >> > Before we invest much more effort into this I'd like to gauge developers >> > interest and acceptance of this idea. I suspect the interest from VXL >> > users would be high, but I'm less confident such bindings could actually >> > be committed back to the VXL repository without updating our policies. >> > We would be using Boost.Python to create the bindings since this is far >> > easier than manually doing it with Python's C interface. In addition to >> > Boost this would require linking to Python and NumPy libraries. I would >> > not want to have to put any of these in v3p. The code for these binding >> > would also make heavy use of modern C++ features, like namespaces, that >> > are generally frowned upon in VXL. >> > >> > I see this as an optional component to VXL, so either: >> > >> > 1) This code is contributed to the VXL repository, but lives in a >> > separate subdirectory, and is disabled in CMake by default. Building >> > Python bindings would require the user to provide Python, Boost.Python, >> > and NumPy. >> > >> > 2) The code is a separate project that depends on VXL and has its own >> > version control repository. It would probably use a newer version of >> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained >> > separately. >> > >> > Either way, we would probably set up the framework and wrap just some >> > key classes and functions at first. Initial focus would be on vil and >> > vnl, secondary focus on vgl and vpgl. We would probably not go much >> > beyond that and allow the community to contribute additional bindings as >> > needed. There is no need to wrap some libraries like vpl and vul since >> > Python already has these capabilities. >> > >> > Does anyone have any opinions on this matter? Is anyone interested in >> > helping if we can get the ball rolling? >> > >> > Thanks, >> > Matt >> > >> > >> > ------------------------------------------------------------------------------ >> > Virtualization & Cloud Management Using Capacity Planning >> > Cloud computing makes use of virtualization - but cloud computing >> > also focuses on allowing computing to be delivered as a service. >> > http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> > _______________________________________________ >> > Vxl-maintainers mailing list >> > Vxl...@li... >> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> >> > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@ki...> - 2012-02-13 19:25:55
|
On Mon, 2012-02-13 at 16:54 -0200, Ricardo Fabbri wrote: > Hi, > > I would suggest having the separate Python binding repository hosted > in the same VXL's sourceforge account. Multiple Git repositories can > be set there. That way the two projects can maximize each other's > visibility. Yes, I agree. It makes sense for each of these repositories to be co-located as part of the same sourceforge project. > > I am very much in favor of the move to Git and have pushed for it in > the past. I currently use it with VXL SVN the same way Matt does: > https://sourceforge.net/apps/trac/vxl/wiki/GitSvn > > Moving to Git has the drawback that most users would have to download > the entire history with a simple "git clone". For a project this big, > a "git clone --bare" is an important thing to stress for casual users, > otherwise the download may take too long. Of course, for developers it > is a huge benefit to have the history locally accessible. I think "git clone --bare" will still pull the entire history, but it will not make a local working source tree. Maybe you are thinking of "git clone --depth n" that will only checkout the last n commits. Anyway, my current git clone of VXL is 112Mb. That's big, but not too unreasonable for a one-time download. It's much worse when you run git-svn yourself and git has to checkout every commit of VXL via the svn interface. That can take all day. Once you built the initial git history, standard git cloning isn't too much of a problem. We have a git-svn clone of VXL on our internal network that keeps itself synchronized to the upstream VXL. Then we can interact with it as if it was a native git repository until we need to push change back upstream. > > I can also help occasionally with the Python move, if needed. Thanks for the offer. --Matt > > Best, > Ricardo > -- > www.lems.brown.edu/~rfabbri > pt.wikipedia.org/wiki/IPRJ > > > On Mon, Feb 13, 2012 at 4:28 PM, Matt Leotta <mat...@ki...> wrote: > > Brendan, > > > > I would also be in favor of splitting contrib off into a separate > > repository, or even one repository per contributor. This would make > > release management much easier. The official release would only contain > > VXL core libraries. Each contributor would then have the responsibility > > of making releases of their own contrib sections, if they care about > > releases. The Python bindings could be another add-on repository. > > > > At Kitware we would handle this setup with what we call "superbuilds". > > A superbuild is a repository that refers to specific commits of various > > other repositories. So you could checkout and build the various > > projects separately if you want, but you can also checkout the > > superbuild and it will checkout all the repositories you need and build > > everything in one massive build. This allows for smaller sub-projects > > that are easier to manage, but also makes it easy to do a single unified > > build of everything if that is what you want. > > > > I'm not sure if this can be done effectively with subversion, but it > > works well with git using the git submodule feature. At Kitware we have > > migrated all of our code repositories from svn and cvs to git. In fact > > we do all our VXL work in git and push changes back upstream via the > > git-svn interface. Git has a bit of a learning curve, but is so much > > more powerful than svn or cvs that once you learn it is very hard to go > > back. > > > > What is the VXL community's feeling on moving to git? If a good portion > > of developers are already familiar with git then it maybe it would make > > sense to switch. I can see the possibility of Kitware migrating VXL to > > git, splitting it into separate repositories, setting up the superbuild, > > and then taking responsibility for making the stable releases of VXL > > core. I can't promise anything right now because I have to check that > > we can find funding to do this. However, we certainly have the > > technical experience to do this migration if the community is in favor > > of it. > > > > Moving from svn to git is about more than the submodule feature. It's a > > fundamental shift from centralized version control to distributed > > version control. It requires a totally different mindset on version > > control. I expect there will need to be a lot of debate about whether > > or not to migrate to git and also what the work flow would be if we > > adopted git. git supports various different development work flows, the > > simplest of which is the linear, single-branch of history used by cvs > > and svn. There are other work flows that are better suited toward > > managing stable releases. > > > > --Matt > > > > On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: > >> Hi Matt, > >> > >> I am very much in support of this move. I can see benefits and > >> draw-backs to both option 1 and 2 below. I have a slight preference for > >> option 2, but in that case, I would prefer all of contrib to be split > >> off into a separate project. This has the advantage of making official > >> releases rather easier since core does not change often (but that's my > >> bias showing both as the release guy and someone who has used very > >> little of contrib). > >> > >> Either way, I'm strongly in favour of python bindings for vxl. I might > >> be able to help a bit, but probably shouldn't be relied upon for any > >> heavy lifting. > >> > >> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: > >> > VXL users and maintainers, > >> > > >> > At Kitware we've toying with the idea of creating Python bindings for > >> > VXL. The main goal would be to allow the use of VXL's core classes and > >> > functions from Python. We also want to integrate vnl and vil tightly > >> > with NumPy. OpenCV and many other C++ libraries have similar > >> > functionality. We've done some proof of concept test and found that, > >> > for example, we can wrap a vil_image_view as a NumPy array and > >> > manipulate the underlying memory without deep copying. The reverse is > >> > also possible. > >> > > >> > Before we invest much more effort into this I'd like to gauge developers > >> > interest and acceptance of this idea. I suspect the interest from VXL > >> > users would be high, but I'm less confident such bindings could actually > >> > be committed back to the VXL repository without updating our policies. > >> > We would be using Boost.Python to create the bindings since this is far > >> > easier than manually doing it with Python's C interface. In addition to > >> > Boost this would require linking to Python and NumPy libraries. I would > >> > not want to have to put any of these in v3p. The code for these binding > >> > would also make heavy use of modern C++ features, like namespaces, that > >> > are generally frowned upon in VXL. > >> > > >> > I see this as an optional component to VXL, so either: > >> > > >> > 1) This code is contributed to the VXL repository, but lives in a > >> > separate subdirectory, and is disabled in CMake by default. Building > >> > Python bindings would require the user to provide Python, Boost.Python, > >> > and NumPy. > >> > > >> > 2) The code is a separate project that depends on VXL and has its own > >> > version control repository. It would probably use a newer version of > >> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained > >> > separately. > >> > > >> > Either way, we would probably set up the framework and wrap just some > >> > key classes and functions at first. Initial focus would be on vil and > >> > vnl, secondary focus on vgl and vpgl. We would probably not go much > >> > beyond that and allow the community to contribute additional bindings as > >> > needed. There is no need to wrap some libraries like vpl and vul since > >> > Python already has these capabilities. > >> > > >> > Does anyone have any opinions on this matter? Is anyone interested in > >> > helping if we can get the ball rolling? > >> > > >> > Thanks, > >> > Matt > >> > > >> > > >> > ------------------------------------------------------------------------------ > >> > Virtualization & Cloud Management Using Capacity Planning > >> > Cloud computing makes use of virtualization - but cloud computing > >> > also focuses on allowing computing to be delivered as a service. > >> > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> > _______________________________________________ > >> > Vxl-maintainers mailing list > >> > Vxl...@li... > >> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >> > >> > > > > > > > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ben B. <ben...@ki...> - 2012-02-13 19:08:55
|
On Mon, Feb 13, 2012 at 16:54:24 -0200, Ricardo Fabbri wrote: > Moving to Git has the drawback that most users would have to download > the entire history with a simple "git clone". For a project this big, > a "git clone --bare" is an important thing to stress for casual users, > otherwise the download may take too long. Of course, for developers it > is a huge benefit to have the history locally accessible. The --bare option doesn't set up a working tree or point to the remote repository. The download size is the same with or without --bare. Maybe you mean --depth? That cuts the download amount, but it has the drawback that you cannot interact with other repositories from it (patches and the like are possible though). I believe a shallow clone can be converted into a full clone though (git fetch --depth=... looks like it can extend the history, but I see no "all" value). There is also gitweb which sourceforge runs which allows for downloading of tarballs directly if a specific revision is required. --Ben |
From: Brendan M. <bre...@gm...> - 2012-02-13 21:39:36
|
Hi Matt, I think your plan (of separate repos + super builds) is an excellent one. I have no problem with a move to git (as long as I don't have to do the migration:-). If Kitware would then like to take over releases for core, that would be great too (Lianqing Yu is also willing to take over the releases). On 14 February 2012 07:28, Matt Leotta <mat...@ki...> wrote: > Brendan, > > I would also be in favor of splitting contrib off into a separate > repository, or even one repository per contributor. This would make > release management much easier. The official release would only contain > VXL core libraries. Each contributor would then have the responsibility > of making releases of their own contrib sections, if they care about > releases. The Python bindings could be another add-on repository. > > At Kitware we would handle this setup with what we call "superbuilds". > A superbuild is a repository that refers to specific commits of various > other repositories. So you could checkout and build the various > projects separately if you want, but you can also checkout the > superbuild and it will checkout all the repositories you need and build > everything in one massive build. This allows for smaller sub-projects > that are easier to manage, but also makes it easy to do a single unified > build of everything if that is what you want. > > I'm not sure if this can be done effectively with subversion, but it > works well with git using the git submodule feature. At Kitware we have > migrated all of our code repositories from svn and cvs to git. In fact > we do all our VXL work in git and push changes back upstream via the > git-svn interface. Git has a bit of a learning curve, but is so much > more powerful than svn or cvs that once you learn it is very hard to go > back. > > What is the VXL community's feeling on moving to git? If a good portion > of developers are already familiar with git then it maybe it would make > sense to switch. I can see the possibility of Kitware migrating VXL to > git, splitting it into separate repositories, setting up the superbuild, > and then taking responsibility for making the stable releases of VXL > core. I can't promise anything right now because I have to check that > we can find funding to do this. However, we certainly have the > technical experience to do this migration if the community is in favor > of it. > > Moving from svn to git is about more than the submodule feature. It's a > fundamental shift from centralized version control to distributed > version control. It requires a totally different mindset on version > control. I expect there will need to be a lot of debate about whether > or not to migrate to git and also what the work flow would be if we > adopted git. git supports various different development work flows, the > simplest of which is the linear, single-branch of history used by cvs > and svn. There are other work flows that are better suited toward > managing stable releases. > > --Matt > > On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: >> Hi Matt, >> >> I am very much in support of this move. I can see benefits and >> draw-backs to both option 1 and 2 below. I have a slight preference for >> option 2, but in that case, I would prefer all of contrib to be split >> off into a separate project. This has the advantage of making official >> releases rather easier since core does not change often (but that's my >> bias showing both as the release guy and someone who has used very >> little of contrib). >> >> Either way, I'm strongly in favour of python bindings for vxl. I might >> be able to help a bit, but probably shouldn't be relied upon for any >> heavy lifting. >> >> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: >> > VXL users and maintainers, >> > >> > At Kitware we've toying with the idea of creating Python bindings for >> > VXL. The main goal would be to allow the use of VXL's core classes and >> > functions from Python. We also want to integrate vnl and vil tightly >> > with NumPy. OpenCV and many other C++ libraries have similar >> > functionality. We've done some proof of concept test and found that, >> > for example, we can wrap a vil_image_view as a NumPy array and >> > manipulate the underlying memory without deep copying. The reverse is >> > also possible. >> > >> > Before we invest much more effort into this I'd like to gauge developers >> > interest and acceptance of this idea. I suspect the interest from VXL >> > users would be high, but I'm less confident such bindings could actually >> > be committed back to the VXL repository without updating our policies. >> > We would be using Boost.Python to create the bindings since this is far >> > easier than manually doing it with Python's C interface. In addition to >> > Boost this would require linking to Python and NumPy libraries. I would >> > not want to have to put any of these in v3p. The code for these binding >> > would also make heavy use of modern C++ features, like namespaces, that >> > are generally frowned upon in VXL. >> > >> > I see this as an optional component to VXL, so either: >> > >> > 1) This code is contributed to the VXL repository, but lives in a >> > separate subdirectory, and is disabled in CMake by default. Building >> > Python bindings would require the user to provide Python, Boost.Python, >> > and NumPy. >> > >> > 2) The code is a separate project that depends on VXL and has its own >> > version control repository. It would probably use a newer version of >> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained >> > separately. >> > >> > Either way, we would probably set up the framework and wrap just some >> > key classes and functions at first. Initial focus would be on vil and >> > vnl, secondary focus on vgl and vpgl. We would probably not go much >> > beyond that and allow the community to contribute additional bindings as >> > needed. There is no need to wrap some libraries like vpl and vul since >> > Python already has these capabilities. >> > >> > Does anyone have any opinions on this matter? Is anyone interested in >> > helping if we can get the ball rolling? >> > >> > Thanks, >> > Matt >> > >> > >> > ------------------------------------------------------------------------------ >> > Virtualization & Cloud Management Using Capacity Planning >> > Cloud computing makes use of virtualization - but cloud computing >> > also focuses on allowing computing to be delivered as a service. >> > http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> > _______________________________________________ >> > Vxl-maintainers mailing list >> > Vxl...@li... >> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> >> > > -- Cheers, Brendan |
From: Ricardo F. <ric...@us...> - 2012-02-13 22:58:29
|
Here's one approach for migrating to Git that worked for me in the past: Create a temporary Git repository to download the SVN information: mkdir repos_tmp cd repos_tmp git svn init VXL_SVN_URL --no-metadata --stdlayout git svn fetch Cleanup undesired SVN info by cloning the temporary repository to a final one: cd .. git clone repos_tmp repos_final cd repos_final Configure the final repository to interact with Sourceforge: git remote rm origin git remote add origin ssh://USE...@vx.../gitroot/vxl/vxl git config branch.master.remote origin git config branch.master.merge refs/heads/master git push origin master More details (e.g. how to deal with tagging) are in the 2nd answer to the following stackoverflow question: http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository Ricardo Fabbri -- Linux registered user #175401 www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net On Mon, Feb 13, 2012 at 7:39 PM, Brendan McCane <bre...@gm...> wrote: > Hi Matt, > > I think your plan (of separate repos + super builds) is an excellent > one. I have no problem with a move to git (as long as I don't have to > do the migration:-). If Kitware would then like to take over releases > for core, that would be great too (Lianqing Yu is also willing to take > over the releases). > > On 14 February 2012 07:28, Matt Leotta <mat...@ki...> wrote: >> Brendan, >> >> I would also be in favor of splitting contrib off into a separate >> repository, or even one repository per contributor. This would make >> release management much easier. The official release would only contain >> VXL core libraries. Each contributor would then have the responsibility >> of making releases of their own contrib sections, if they care about >> releases. The Python bindings could be another add-on repository. >> >> At Kitware we would handle this setup with what we call "superbuilds". >> A superbuild is a repository that refers to specific commits of various >> other repositories. So you could checkout and build the various >> projects separately if you want, but you can also checkout the >> superbuild and it will checkout all the repositories you need and build >> everything in one massive build. This allows for smaller sub-projects >> that are easier to manage, but also makes it easy to do a single unified >> build of everything if that is what you want. >> >> I'm not sure if this can be done effectively with subversion, but it >> works well with git using the git submodule feature. At Kitware we have >> migrated all of our code repositories from svn and cvs to git. In fact >> we do all our VXL work in git and push changes back upstream via the >> git-svn interface. Git has a bit of a learning curve, but is so much >> more powerful than svn or cvs that once you learn it is very hard to go >> back. >> >> What is the VXL community's feeling on moving to git? If a good portion >> of developers are already familiar with git then it maybe it would make >> sense to switch. I can see the possibility of Kitware migrating VXL to >> git, splitting it into separate repositories, setting up the superbuild, >> and then taking responsibility for making the stable releases of VXL >> core. I can't promise anything right now because I have to check that >> we can find funding to do this. However, we certainly have the >> technical experience to do this migration if the community is in favor >> of it. >> >> Moving from svn to git is about more than the submodule feature. It's a >> fundamental shift from centralized version control to distributed >> version control. It requires a totally different mindset on version >> control. I expect there will need to be a lot of debate about whether >> or not to migrate to git and also what the work flow would be if we >> adopted git. git supports various different development work flows, the >> simplest of which is the linear, single-branch of history used by cvs >> and svn. There are other work flows that are better suited toward >> managing stable releases. >> >> --Matt >> >> On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: >>> Hi Matt, >>> >>> I am very much in support of this move. I can see benefits and >>> draw-backs to both option 1 and 2 below. I have a slight preference for >>> option 2, but in that case, I would prefer all of contrib to be split >>> off into a separate project. This has the advantage of making official >>> releases rather easier since core does not change often (but that's my >>> bias showing both as the release guy and someone who has used very >>> little of contrib). >>> >>> Either way, I'm strongly in favour of python bindings for vxl. I might >>> be able to help a bit, but probably shouldn't be relied upon for any >>> heavy lifting. >>> >>> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: >>> > VXL users and maintainers, >>> > >>> > At Kitware we've toying with the idea of creating Python bindings for >>> > VXL. The main goal would be to allow the use of VXL's core classes and >>> > functions from Python. We also want to integrate vnl and vil tightly >>> > with NumPy. OpenCV and many other C++ libraries have similar >>> > functionality. We've done some proof of concept test and found that, >>> > for example, we can wrap a vil_image_view as a NumPy array and >>> > manipulate the underlying memory without deep copying. The reverse is >>> > also possible. >>> > >>> > Before we invest much more effort into this I'd like to gauge developers >>> > interest and acceptance of this idea. I suspect the interest from VXL >>> > users would be high, but I'm less confident such bindings could actually >>> > be committed back to the VXL repository without updating our policies. >>> > We would be using Boost.Python to create the bindings since this is far >>> > easier than manually doing it with Python's C interface. In addition to >>> > Boost this would require linking to Python and NumPy libraries. I would >>> > not want to have to put any of these in v3p. The code for these binding >>> > would also make heavy use of modern C++ features, like namespaces, that >>> > are generally frowned upon in VXL. >>> > >>> > I see this as an optional component to VXL, so either: >>> > >>> > 1) This code is contributed to the VXL repository, but lives in a >>> > separate subdirectory, and is disabled in CMake by default. Building >>> > Python bindings would require the user to provide Python, Boost.Python, >>> > and NumPy. >>> > >>> > 2) The code is a separate project that depends on VXL and has its own >>> > version control repository. It would probably use a newer version of >>> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained >>> > separately. >>> > >>> > Either way, we would probably set up the framework and wrap just some >>> > key classes and functions at first. Initial focus would be on vil and >>> > vnl, secondary focus on vgl and vpgl. We would probably not go much >>> > beyond that and allow the community to contribute additional bindings as >>> > needed. There is no need to wrap some libraries like vpl and vul since >>> > Python already has these capabilities. >>> > >>> > Does anyone have any opinions on this matter? Is anyone interested in >>> > helping if we can get the ball rolling? >>> > >>> > Thanks, >>> > Matt >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > Virtualization & Cloud Management Using Capacity Planning >>> > Cloud computing makes use of virtualization - but cloud computing >>> > also focuses on allowing computing to be delivered as a service. >>> > http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> > _______________________________________________ >>> > Vxl-maintainers mailing list >>> > Vxl...@li... >>> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>> >>> >> >> > > > > -- > Cheers, > > Brendan > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@ki...> - 2012-02-13 23:13:07
|
Ricardo, This is approximately the process we have used in the past. There are usually a few addition steps required to make sure users are mapped correctly, etc. -Matt On Feb 13, 2012, at 5:58 PM, Ricardo Fabbri <ric...@us...> wrote: > Here's one approach for migrating to Git that worked for me in the past: > > Create a temporary Git repository to download the SVN information: > > mkdir repos_tmp > cd repos_tmp > git svn init VXL_SVN_URL --no-metadata --stdlayout > git svn fetch > > Cleanup undesired SVN info by cloning the temporary repository to a final one: > > cd .. > git clone repos_tmp repos_final > cd repos_final > > Configure the final repository to interact with Sourceforge: > > git remote rm origin > git remote add origin ssh://USE...@vx.../gitroot/vxl/vxl > git config branch.master.remote origin > git config branch.master.merge refs/heads/master > git push origin master > > > More details (e.g. how to deal with tagging) are in the 2nd answer to > the following stackoverflow question: > > http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository > > > Ricardo Fabbri > -- > Linux registered user #175401 > www.lems.brown.edu/~rfabbri > pt.wikipedia.org/wiki/IPRJ > labmacambira.sf.net > > > On Mon, Feb 13, 2012 at 7:39 PM, Brendan McCane > <bre...@gm...> wrote: >> Hi Matt, >> >> I think your plan (of separate repos + super builds) is an excellent >> one. I have no problem with a move to git (as long as I don't have to >> do the migration:-). If Kitware would then like to take over releases >> for core, that would be great too (Lianqing Yu is also willing to take >> over the releases). >> >> On 14 February 2012 07:28, Matt Leotta <mat...@ki...> wrote: >>> Brendan, >>> >>> I would also be in favor of splitting contrib off into a separate >>> repository, or even one repository per contributor. This would make >>> release management much easier. The official release would only contain >>> VXL core libraries. Each contributor would then have the responsibility >>> of making releases of their own contrib sections, if they care about >>> releases. The Python bindings could be another add-on repository. >>> >>> At Kitware we would handle this setup with what we call "superbuilds". >>> A superbuild is a repository that refers to specific commits of various >>> other repositories. So you could checkout and build the various >>> projects separately if you want, but you can also checkout the >>> superbuild and it will checkout all the repositories you need and build >>> everything in one massive build. This allows for smaller sub-projects >>> that are easier to manage, but also makes it easy to do a single unified >>> build of everything if that is what you want. >>> >>> I'm not sure if this can be done effectively with subversion, but it >>> works well with git using the git submodule feature. At Kitware we have >>> migrated all of our code repositories from svn and cvs to git. In fact >>> we do all our VXL work in git and push changes back upstream via the >>> git-svn interface. Git has a bit of a learning curve, but is so much >>> more powerful than svn or cvs that once you learn it is very hard to go >>> back. >>> >>> What is the VXL community's feeling on moving to git? If a good portion >>> of developers are already familiar with git then it maybe it would make >>> sense to switch. I can see the possibility of Kitware migrating VXL to >>> git, splitting it into separate repositories, setting up the superbuild, >>> and then taking responsibility for making the stable releases of VXL >>> core. I can't promise anything right now because I have to check that >>> we can find funding to do this. However, we certainly have the >>> technical experience to do this migration if the community is in favor >>> of it. >>> >>> Moving from svn to git is about more than the submodule feature. It's a >>> fundamental shift from centralized version control to distributed >>> version control. It requires a totally different mindset on version >>> control. I expect there will need to be a lot of debate about whether >>> or not to migrate to git and also what the work flow would be if we >>> adopted git. git supports various different development work flows, the >>> simplest of which is the linear, single-branch of history used by cvs >>> and svn. There are other work flows that are better suited toward >>> managing stable releases. >>> >>> --Matt >>> >>> On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: >>>> Hi Matt, >>>> >>>> I am very much in support of this move. I can see benefits and >>>> draw-backs to both option 1 and 2 below. I have a slight preference for >>>> option 2, but in that case, I would prefer all of contrib to be split >>>> off into a separate project. This has the advantage of making official >>>> releases rather easier since core does not change often (but that's my >>>> bias showing both as the release guy and someone who has used very >>>> little of contrib). >>>> >>>> Either way, I'm strongly in favour of python bindings for vxl. I might >>>> be able to help a bit, but probably shouldn't be relied upon for any >>>> heavy lifting. >>>> >>>> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: >>>>> VXL users and maintainers, >>>>> >>>>> At Kitware we've toying with the idea of creating Python bindings for >>>>> VXL. The main goal would be to allow the use of VXL's core classes and >>>>> functions from Python. We also want to integrate vnl and vil tightly >>>>> with NumPy. OpenCV and many other C++ libraries have similar >>>>> functionality. We've done some proof of concept test and found that, >>>>> for example, we can wrap a vil_image_view as a NumPy array and >>>>> manipulate the underlying memory without deep copying. The reverse is >>>>> also possible. >>>>> >>>>> Before we invest much more effort into this I'd like to gauge developers >>>>> interest and acceptance of this idea. I suspect the interest from VXL >>>>> users would be high, but I'm less confident such bindings could actually >>>>> be committed back to the VXL repository without updating our policies. >>>>> We would be using Boost.Python to create the bindings since this is far >>>>> easier than manually doing it with Python's C interface. In addition to >>>>> Boost this would require linking to Python and NumPy libraries. I would >>>>> not want to have to put any of these in v3p. The code for these binding >>>>> would also make heavy use of modern C++ features, like namespaces, that >>>>> are generally frowned upon in VXL. >>>>> >>>>> I see this as an optional component to VXL, so either: >>>>> >>>>> 1) This code is contributed to the VXL repository, but lives in a >>>>> separate subdirectory, and is disabled in CMake by default. Building >>>>> Python bindings would require the user to provide Python, Boost.Python, >>>>> and NumPy. >>>>> >>>>> 2) The code is a separate project that depends on VXL and has its own >>>>> version control repository. It would probably use a newer version of >>>>> CMake, use "newer" C++ features (C++03, not C++11), and be maintained >>>>> separately. >>>>> >>>>> Either way, we would probably set up the framework and wrap just some >>>>> key classes and functions at first. Initial focus would be on vil and >>>>> vnl, secondary focus on vgl and vpgl. We would probably not go much >>>>> beyond that and allow the community to contribute additional bindings as >>>>> needed. There is no need to wrap some libraries like vpl and vul since >>>>> Python already has these capabilities. >>>>> >>>>> Does anyone have any opinions on this matter? Is anyone interested in >>>>> helping if we can get the ball rolling? >>>>> >>>>> Thanks, >>>>> Matt >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Vxl-maintainers mailing list >>>>> Vxl...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>>> >>>> >>> >>> >> >> >> >> -- >> Cheers, >> >> Brendan >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <sc...@im...> - 2012-02-20 10:53:45
|
The python integration seems like a great idea for those who use python. I can't see any great difference between a new contrib directory and a separate repository. BTW Matt, Did Kitware get anywhere with the LAPACK upgrade for VXL? I'm not so sure of moving to git. I am aware of the general arguments in favour of git, but not how they apply to VXL, and to our users in particular. In any case, python and GIT changes are two separate suggestions and I would prefer they were handled separately. If Ricardo and Matt want to lobby for moving to GIT, please can you post a proper proposal, with the pros, cons and migration steps listed. Ian. On 13/02/2012 23:12, Matt Leotta wrote: > Ricardo, > > This is approximately the process we have used in the past. There are > usually a few addition steps required to make sure users are mapped > correctly, etc. > > -Matt > > On Feb 13, 2012, at 5:58 PM, Ricardo Fabbri > <ric...@us...> wrote: > >> Here's one approach for migrating to Git that worked for me in the past: >> >> Create a temporary Git repository to download the SVN information: >> >> mkdir repos_tmp >> cd repos_tmp >> git svn init VXL_SVN_URL --no-metadata --stdlayout >> git svn fetch >> >> Cleanup undesired SVN info by cloning the temporary repository to a final one: >> >> cd .. >> git clone repos_tmp repos_final >> cd repos_final >> >> Configure the final repository to interact with Sourceforge: >> >> git remote rm origin >> git remote add origin ssh://USE...@vx.../gitroot/vxl/vxl >> git config branch.master.remote origin >> git config branch.master.merge refs/heads/master >> git push origin master >> >> >> More details (e.g. how to deal with tagging) are in the 2nd answer to >> the following stackoverflow question: >> >> http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository >> >> >> Ricardo Fabbri >> -- >> Linux registered user #175401 >> www.lems.brown.edu/~rfabbri >> pt.wikipedia.org/wiki/IPRJ >> labmacambira.sf.net >> >> >> On Mon, Feb 13, 2012 at 7:39 PM, Brendan McCane >> <bre...@gm...> wrote: >>> Hi Matt, >>> >>> I think your plan (of separate repos + super builds) is an excellent >>> one. I have no problem with a move to git (as long as I don't have to >>> do the migration:-). If Kitware would then like to take over releases >>> for core, that would be great too (Lianqing Yu is also willing to take >>> over the releases). >>> >>> On 14 February 2012 07:28, Matt Leotta<mat...@ki...> wrote: >>>> Brendan, >>>> >>>> I would also be in favor of splitting contrib off into a separate >>>> repository, or even one repository per contributor. This would make >>>> release management much easier. The official release would only contain >>>> VXL core libraries. Each contributor would then have the responsibility >>>> of making releases of their own contrib sections, if they care about >>>> releases. The Python bindings could be another add-on repository. >>>> >>>> At Kitware we would handle this setup with what we call "superbuilds". >>>> A superbuild is a repository that refers to specific commits of various >>>> other repositories. So you could checkout and build the various >>>> projects separately if you want, but you can also checkout the >>>> superbuild and it will checkout all the repositories you need and build >>>> everything in one massive build. This allows for smaller sub-projects >>>> that are easier to manage, but also makes it easy to do a single unified >>>> build of everything if that is what you want. >>>> >>>> I'm not sure if this can be done effectively with subversion, but it >>>> works well with git using the git submodule feature. At Kitware we have >>>> migrated all of our code repositories from svn and cvs to git. In fact >>>> we do all our VXL work in git and push changes back upstream via the >>>> git-svn interface. Git has a bit of a learning curve, but is so much >>>> more powerful than svn or cvs that once you learn it is very hard to go >>>> back. >>>> >>>> What is the VXL community's feeling on moving to git? If a good portion >>>> of developers are already familiar with git then it maybe it would make >>>> sense to switch. I can see the possibility of Kitware migrating VXL to >>>> git, splitting it into separate repositories, setting up the superbuild, >>>> and then taking responsibility for making the stable releases of VXL >>>> core. I can't promise anything right now because I have to check that >>>> we can find funding to do this. However, we certainly have the >>>> technical experience to do this migration if the community is in favor >>>> of it. >>>> >>>> Moving from svn to git is about more than the submodule feature. It's a >>>> fundamental shift from centralized version control to distributed >>>> version control. It requires a totally different mindset on version >>>> control. I expect there will need to be a lot of debate about whether >>>> or not to migrate to git and also what the work flow would be if we >>>> adopted git. git supports various different development work flows, the >>>> simplest of which is the linear, single-branch of history used by cvs >>>> and svn. There are other work flows that are better suited toward >>>> managing stable releases. >>>> >>>> --Matt >>>> >>>> On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: >>>>> Hi Matt, >>>>> >>>>> I am very much in support of this move. I can see benefits and >>>>> draw-backs to both option 1 and 2 below. I have a slight preference for >>>>> option 2, but in that case, I would prefer all of contrib to be split >>>>> off into a separate project. This has the advantage of making official >>>>> releases rather easier since core does not change often (but that's my >>>>> bias showing both as the release guy and someone who has used very >>>>> little of contrib). >>>>> >>>>> Either way, I'm strongly in favour of python bindings for vxl. I might >>>>> be able to help a bit, but probably shouldn't be relied upon for any >>>>> heavy lifting. >>>>> >>>>> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: >>>>>> VXL users and maintainers, >>>>>> >>>>>> At Kitware we've toying with the idea of creating Python bindings for >>>>>> VXL. The main goal would be to allow the use of VXL's core classes and >>>>>> functions from Python. We also want to integrate vnl and vil tightly >>>>>> with NumPy. OpenCV and many other C++ libraries have similar >>>>>> functionality. We've done some proof of concept test and found that, >>>>>> for example, we can wrap a vil_image_view as a NumPy array and >>>>>> manipulate the underlying memory without deep copying. The reverse is >>>>>> also possible. >>>>>> >>>>>> Before we invest much more effort into this I'd like to gauge developers >>>>>> interest and acceptance of this idea. I suspect the interest from VXL >>>>>> users would be high, but I'm less confident such bindings could actually >>>>>> be committed back to the VXL repository without updating our policies. >>>>>> We would be using Boost.Python to create the bindings since this is far >>>>>> easier than manually doing it with Python's C interface. In addition to >>>>>> Boost this would require linking to Python and NumPy libraries. I would >>>>>> not want to have to put any of these in v3p. The code for these binding >>>>>> would also make heavy use of modern C++ features, like namespaces, that >>>>>> are generally frowned upon in VXL. >>>>>> >>>>>> I see this as an optional component to VXL, so either: >>>>>> >>>>>> 1) This code is contributed to the VXL repository, but lives in a >>>>>> separate subdirectory, and is disabled in CMake by default. Building >>>>>> Python bindings would require the user to provide Python, Boost.Python, >>>>>> and NumPy. >>>>>> >>>>>> 2) The code is a separate project that depends on VXL and has its own >>>>>> version control repository. It would probably use a newer version of >>>>>> CMake, use "newer" C++ features (C++03, not C++11), and be maintained >>>>>> separately. >>>>>> >>>>>> Either way, we would probably set up the framework and wrap just some >>>>>> key classes and functions at first. Initial focus would be on vil and >>>>>> vnl, secondary focus on vgl and vpgl. We would probably not go much >>>>>> beyond that and allow the community to contribute additional bindings as >>>>>> needed. There is no need to wrap some libraries like vpl and vul since >>>>>> Python already has these capabilities. >>>>>> >>>>>> Does anyone have any opinions on this matter? Is anyone interested in >>>>>> helping if we can get the ball rolling? >>>>>> >>>>>> Thanks, >>>>>> Matt >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Virtualization& Cloud Management Using Capacity Planning >>>>>> Cloud computing makes use of virtualization - but cloud computing >>>>>> also focuses on allowing computing to be delivered as a service. >>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>>> _______________________________________________ >>>>>> Vxl-maintainers mailing list >>>>>> Vxl...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> >>> Brendan >>> >>> ------------------------------------------------------------------------------ >>> Try before you buy = See our experts in action! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-dev2 >>> _______________________________________________ >>> Vxl-maintainers mailing list >>> Vxl...@li... >>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users > |
From: Matt L. <mat...@gm...> - 2012-02-20 14:32:21
|
On Mon, 2012-02-20 at 10:53 +0000, Ian Scott wrote: > The python integration seems like a great idea for those who use python. > I can't see any great difference between a new contrib directory and a > separate repository. Well, I'm not sure a new contrib directory makes sense for Python bindings. Python bindings would be much more similar to how vsl is used in core with the io add-on libraries. Each core library that is to be wrapped will need a Python wrapping add-on library. These could be interleaved into core directories like the io and algo subdirectories, or they could have a separate directory tree that parallels core. The reason that this does not make as much sense as a contrib directory is that these binding are likely to expand into existing contrib directories, probably starting with brl, given Brown's interest. It would be messy to have a special contrib directory that is dependent on all other contrib directories and builds subsets of itself depending on which other contrib libraries are enabled. I think it makes more sense to either have the Python binding code interleaved with the core libraries like io and algo, or to have a new top level directory and mirror the directory layout of both core and contrib within it. Either way there would be a top level CMake variable to enable building Python bindings, and it would be off by default. The proposal for a separate repository was mainly to allow us define an updated set of standards for that new code. For example, we would like to use namespaces, depend on Boost, and possibly even use the std namespace instead of vcl. If there are no objections to us doing this in the VXL repository, then I prefer we keep the code in the VXL repository. > > BTW Matt, Did Kitware get anywhere with the LAPACK upgrade for VXL? I don't know. That was a separate funding source and I wasn't part of that effort. I will check with Chuck Atkins. > > I'm not so sure of moving to git. I am aware of the general arguments in > favour of git, but not how they apply to VXL, and to our users in > particular. In any case, python and GIT changes are two separate > suggestions and I would prefer they were handled separately. If Ricardo > and Matt want to lobby for moving to GIT, please can you post a proper > proposal, with the pros, cons and migration steps listed. I agree that a move to git is a separate issue and should not be entangled with the Python binding discussion. I will post a separate e-mail thread related to git and take a survey of vxl users and maintainers experience in git and interest in seeing vxl move to git. --Matt > > Ian. > > > On 13/02/2012 23:12, Matt Leotta wrote: > > Ricardo, > > > > This is approximately the process we have used in the past. There are > > usually a few addition steps required to make sure users are mapped > > correctly, etc. > > > > -Matt > > > > On Feb 13, 2012, at 5:58 PM, Ricardo Fabbri > > <ric...@us...> wrote: > > > >> Here's one approach for migrating to Git that worked for me in the past: > >> > >> Create a temporary Git repository to download the SVN information: > >> > >> mkdir repos_tmp > >> cd repos_tmp > >> git svn init VXL_SVN_URL --no-metadata --stdlayout > >> git svn fetch > >> > >> Cleanup undesired SVN info by cloning the temporary repository to a final one: > >> > >> cd .. > >> git clone repos_tmp repos_final > >> cd repos_final > >> > >> Configure the final repository to interact with Sourceforge: > >> > >> git remote rm origin > >> git remote add origin ssh://USE...@vx.../gitroot/vxl/vxl > >> git config branch.master.remote origin > >> git config branch.master.merge refs/heads/master > >> git push origin master > >> > >> > >> More details (e.g. how to deal with tagging) are in the 2nd answer to > >> the following stackoverflow question: > >> > >> http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository > >> > >> > >> Ricardo Fabbri > >> -- > >> Linux registered user #175401 > >> www.lems.brown.edu/~rfabbri > >> pt.wikipedia.org/wiki/IPRJ > >> labmacambira.sf.net > >> > >> > >> On Mon, Feb 13, 2012 at 7:39 PM, Brendan McCane > >> <bre...@gm...> wrote: > >>> Hi Matt, > >>> > >>> I think your plan (of separate repos + super builds) is an excellent > >>> one. I have no problem with a move to git (as long as I don't have to > >>> do the migration:-). If Kitware would then like to take over releases > >>> for core, that would be great too (Lianqing Yu is also willing to take > >>> over the releases). > >>> > >>> On 14 February 2012 07:28, Matt Leotta<mat...@ki...> wrote: > >>>> Brendan, > >>>> > >>>> I would also be in favor of splitting contrib off into a separate > >>>> repository, or even one repository per contributor. This would make > >>>> release management much easier. The official release would only contain > >>>> VXL core libraries. Each contributor would then have the responsibility > >>>> of making releases of their own contrib sections, if they care about > >>>> releases. The Python bindings could be another add-on repository. > >>>> > >>>> At Kitware we would handle this setup with what we call "superbuilds". > >>>> A superbuild is a repository that refers to specific commits of various > >>>> other repositories. So you could checkout and build the various > >>>> projects separately if you want, but you can also checkout the > >>>> superbuild and it will checkout all the repositories you need and build > >>>> everything in one massive build. This allows for smaller sub-projects > >>>> that are easier to manage, but also makes it easy to do a single unified > >>>> build of everything if that is what you want. > >>>> > >>>> I'm not sure if this can be done effectively with subversion, but it > >>>> works well with git using the git submodule feature. At Kitware we have > >>>> migrated all of our code repositories from svn and cvs to git. In fact > >>>> we do all our VXL work in git and push changes back upstream via the > >>>> git-svn interface. Git has a bit of a learning curve, but is so much > >>>> more powerful than svn or cvs that once you learn it is very hard to go > >>>> back. > >>>> > >>>> What is the VXL community's feeling on moving to git? If a good portion > >>>> of developers are already familiar with git then it maybe it would make > >>>> sense to switch. I can see the possibility of Kitware migrating VXL to > >>>> git, splitting it into separate repositories, setting up the superbuild, > >>>> and then taking responsibility for making the stable releases of VXL > >>>> core. I can't promise anything right now because I have to check that > >>>> we can find funding to do this. However, we certainly have the > >>>> technical experience to do this migration if the community is in favor > >>>> of it. > >>>> > >>>> Moving from svn to git is about more than the submodule feature. It's a > >>>> fundamental shift from centralized version control to distributed > >>>> version control. It requires a totally different mindset on version > >>>> control. I expect there will need to be a lot of debate about whether > >>>> or not to migrate to git and also what the work flow would be if we > >>>> adopted git. git supports various different development work flows, the > >>>> simplest of which is the linear, single-branch of history used by cvs > >>>> and svn. There are other work flows that are better suited toward > >>>> managing stable releases. > >>>> > >>>> --Matt > >>>> > >>>> On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote: > >>>>> Hi Matt, > >>>>> > >>>>> I am very much in support of this move. I can see benefits and > >>>>> draw-backs to both option 1 and 2 below. I have a slight preference for > >>>>> option 2, but in that case, I would prefer all of contrib to be split > >>>>> off into a separate project. This has the advantage of making official > >>>>> releases rather easier since core does not change often (but that's my > >>>>> bias showing both as the release guy and someone who has used very > >>>>> little of contrib). > >>>>> > >>>>> Either way, I'm strongly in favour of python bindings for vxl. I might > >>>>> be able to help a bit, but probably shouldn't be relied upon for any > >>>>> heavy lifting. > >>>>> > >>>>> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote: > >>>>>> VXL users and maintainers, > >>>>>> > >>>>>> At Kitware we've toying with the idea of creating Python bindings for > >>>>>> VXL. The main goal would be to allow the use of VXL's core classes and > >>>>>> functions from Python. We also want to integrate vnl and vil tightly > >>>>>> with NumPy. OpenCV and many other C++ libraries have similar > >>>>>> functionality. We've done some proof of concept test and found that, > >>>>>> for example, we can wrap a vil_image_view as a NumPy array and > >>>>>> manipulate the underlying memory without deep copying. The reverse is > >>>>>> also possible. > >>>>>> > >>>>>> Before we invest much more effort into this I'd like to gauge developers > >>>>>> interest and acceptance of this idea. I suspect the interest from VXL > >>>>>> users would be high, but I'm less confident such bindings could actually > >>>>>> be committed back to the VXL repository without updating our policies. > >>>>>> We would be using Boost.Python to create the bindings since this is far > >>>>>> easier than manually doing it with Python's C interface. In addition to > >>>>>> Boost this would require linking to Python and NumPy libraries. I would > >>>>>> not want to have to put any of these in v3p. The code for these binding > >>>>>> would also make heavy use of modern C++ features, like namespaces, that > >>>>>> are generally frowned upon in VXL. > >>>>>> > >>>>>> I see this as an optional component to VXL, so either: > >>>>>> > >>>>>> 1) This code is contributed to the VXL repository, but lives in a > >>>>>> separate subdirectory, and is disabled in CMake by default. Building > >>>>>> Python bindings would require the user to provide Python, Boost.Python, > >>>>>> and NumPy. > >>>>>> > >>>>>> 2) The code is a separate project that depends on VXL and has its own > >>>>>> version control repository. It would probably use a newer version of > >>>>>> CMake, use "newer" C++ features (C++03, not C++11), and be maintained > >>>>>> separately. > >>>>>> > >>>>>> Either way, we would probably set up the framework and wrap just some > >>>>>> key classes and functions at first. Initial focus would be on vil and > >>>>>> vnl, secondary focus on vgl and vpgl. We would probably not go much > >>>>>> beyond that and allow the community to contribute additional bindings as > >>>>>> needed. There is no need to wrap some libraries like vpl and vul since > >>>>>> Python already has these capabilities. > >>>>>> > >>>>>> Does anyone have any opinions on this matter? Is anyone interested in > >>>>>> helping if we can get the ball rolling? > >>>>>> > >>>>>> Thanks, > >>>>>> Matt > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------------------ > >>>>>> Virtualization& Cloud Management Using Capacity Planning > >>>>>> Cloud computing makes use of virtualization - but cloud computing > >>>>>> also focuses on allowing computing to be delivered as a service. > >>>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >>>>>> _______________________________________________ > >>>>>> Vxl-maintainers mailing list > >>>>>> Vxl...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Cheers, > >>> > >>> Brendan > >>> > >>> ------------------------------------------------------------------------------ > >>> Try before you buy = See our experts in action! > >>> The most comprehensive online learning library for Microsoft developers > >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > >>> Metro Style Apps, more. Free future releases when you subscribe now! > >>> http://p.sf.net/sfu/learndevnow-dev2 > >>> _______________________________________________ > >>> Vxl-maintainers mailing list > >>> Vxl...@li... > >>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ > > Vxl-users mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-users > > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |