I'm looking at how things are placed in the sandbox and wondering about something... Currently the sandbox mirrors the layout of the main Boost CVS. That is: boost-sandbox /boost/... /libs /libs/<library>/... That layout has a few drawbacks when dealing with a single isolated library... 1) It makes it harder to package as one has to filter out the rest of the stuff there. 2) One can get conflicts when something in another library's code gets accidentally used. I ran into this when evaluating named_params as some MPL related files got picked off from the sandbox instead of from the Boost CVS. 3) Makes finding things much harder when someone mentions to look in the sandbox for their library. Was there ever a discussion as to the layout? (A cursory search did not reveal anything) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
I understand that boost sandbox is considered successor to the file section. I'm not really happy with this. It means that those who want to try something out have to get cvs going in thier machine - or download the files one by one from the CVS tree. The yahoo file section ("vault") is ok - but having to register is a pain. Can't we find a directory withing boost (or maybe the wiki?) to just have this very important collection of zipped files? Robert Ramey "Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:419BBFC5.3010207@redshift-software.com...
I'm looking at how things are placed in the sandbox and wondering about something...
Currently the sandbox mirrors the layout of the main Boost CVS. That is:
boost-sandbox /boost/... /libs /libs/<library>/...
That layout has a few drawbacks when dealing with a single isolated library...
1) It makes it harder to package as one has to filter out the rest of the stuff there.
2) One can get conflicts when something in another library's code gets accidentally used. I ran into this when evaluating named_params as some MPL related files got picked off from the sandbox instead of from the Boost CVS.
3) Makes finding things much harder when someone mentions to look in the sandbox for their library.
Was there ever a discussion as to the layout? (A cursory search did not reveal anything)
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I understand that boost sandbox is considered successor to the file section. I'm not really happy with this. It means that those who want to try something out have to get cvs going in thier machine - or download the files one by one from the CVS tree.
The yahoo file section ("vault") is ok - but having to register is a pain.
Can't we find a directory withing boost (or maybe the wiki?) to just have this very important collection of zipped files?
As I understand it the sandbox is a supplement to the vault not a replacement. It has the large benefit of being CVS and getting revision control from it. Clearly the Yahoo vault needs to get replaced. And I did some search for a replacement recently. My suggestion would be to set aside some of the web space of the sandbox to provide our own file vault. The most natural replacement interface I found for this was: http://phpatm.kc-it.com/index.html PHP Advanced Transfer Manager (phpATM) It is very much like the Yahoo interface. And has the options to remove the hindrances that the Yahoo interface does not, like the registration. We could carve out something like 50Meg just for this. That gives people the area to put things without having SF access. And when something is closer to a submission they can move to get access to the sandbox. After that using the SourceForge file release system for submissions would also be of benefit. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Has the notes for the OOPSLA workshop been posted yet? RE: Fixing the problems with the Yahoo vault? Any conclusions as to whether to use the Wiki space or the Sandbox space as a replacement? Did anyone consider the replacement interface I mentioned below? I'd be willing to install this in the Sandbox if desired. Rene Rivera wrote:
Robert Ramey wrote:
The yahoo file section ("vault") is ok - but having to register is a pain.
Can't we find a directory withing boost (or maybe the wiki?) to just have this very important collection of zipped files?
As I understand it the sandbox is a supplement to the vault not a replacement. It has the large benefit of being CVS and getting revision control from it.
Clearly the Yahoo vault needs to get replaced. And I did some search for a replacement recently. My suggestion would be to set aside some of the web space of the sandbox to provide our own file vault. The most natural replacement interface I found for this was:
http://phpatm.kc-it.com/index.html PHP Advanced Transfer Manager (phpATM)
It is very much like the Yahoo interface. And has the options to remove the hindrances that the Yahoo interface does not, like the registration. We could carve out something like 50Meg just for this. That gives people the area to put things without having SF access.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Has the notes for the OOPSLA workshop been posted yet? RE: Fixing the problems with the Yahoo vault?
Any conclusions as to whether to use the Wiki space or the Sandbox space as a replacement?
Did anyone consider the replacement interface I mentioned below? I'd be willing to install this in the Sandbox if desired.
Why don't you just go ahead and do it? If it turns out to be any good, people will use it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Rene Rivera wrote:
Has the notes for the OOPSLA workshop been posted yet? RE: Fixing the problems with the Yahoo vault?
Any conclusions as to whether to use the Wiki space or the Sandbox space as a replacement?
Did anyone consider the replacement interface I mentioned below? I'd be willing to install this in the Sandbox if desired.
Why don't you just go ahead and do it? If it turns out to be any good, people will use it.
Will do :-) I was just trying to make sure no one else was already working on this. No point in duplicating work if it was. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
"Robert Ramey" <ramey@rrsd.com> writes:
I understand that boost sandbox is considered successor to the file section.
At OOPSLA we decided to add file upload capability to the Wiki and use that instead. But I think someone has to actually do it ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Rene Rivera <grafik.list@redshift-software.com> writes:
I'm looking at how things are placed in the sandbox and wondering about something...
Currently the sandbox mirrors the layout of the main Boost CVS. That is:
boost-sandbox /boost/... /libs /libs/<library>/...
That layout has a few drawbacks when dealing with a single isolated library...
1) It makes it harder to package as one has to filter out the rest of the stuff there.
2) One can get conflicts when something in another library's code gets accidentally used. I ran into this when evaluating named_params as some MPL related files got picked off from the sandbox instead of from the Boost CVS.
3) Makes finding things much harder when someone mentions to look in the sandbox for their library.
Was there ever a discussion as to the layout? (A cursory search did not reveal anything)
I like what I _think_ you're suggesting we actually should do, but would you mind spelling it out for everyone's benefit? Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Was there ever a discussion as to the layout? (A cursory search did not reveal anything)
I like what I _think_ you're suggesting we actually should do, but would you mind spelling it out for everyone's benefit?
I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (10)
-
David Abrahams -
Rene Rivera -
Robert Ramey