Bug tracking (was: Re: [boost] Re: Release Manager's Checklist added)
- Original Message - From: David Abrahams [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 09, 2003 11:58 PM Subject: [boost] Re: Release Manager's Checklist added [...] That's probably wrong. They should use a tracker first and then discuss them on the mailing lists. I disagree. I think that we should try to focus information instead of spreading them around. That's exactly what a tracker is good for IMHO. Yes, agreed. One big problem though is that the SF trackers kinda suck. I'd be interested in trying something else, like http://roundup.sourceforge.net/ Interestingly enough they seem to use the SF trackers for their own bugs ;-). But the more important question probably is if there are any volunteers providing an alternative tracker for us? [...] The trackers are IMHO a problem because they require a lot of work. That could be, yes. Yeah, but that might just be the SF trackers. We don't have to use them as-is. Quality assurance simply is a lot of work. The current state shows that it is not maintained well, e.g. there are open bugs which are long closed in CVS, see #451535. Sure we could do better in theory, but is it worth it? Why not use regression tests to track bugs? AFAICS people pay a lot of attention to the regression tests and the whole systems work pretty well. Also, I hope that it could make the release manager's work easier to have fewer sources to track :) In my opinion it should be easier for the release manager to look into the tracker than to follow *all* mailing list traffic. Yeah. Also, you can't always get people who find bugs to make reproducible test cases in a form that integrates with the regression suite. OK, I'd be willing to spend some time working with the SF trackers in the near future (assumed we don't change the tracking system). OK, what do others think? Am I the only one who feels uncomfortable with the SF-trackers? Nope; I dislike them also. That doesn't mean trackers in general are a bad idea. I'd still be interested to hear some more opinions, especially user's. Thanks, Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: libs/config/configure screwed up in DOS format in 1.30.1
Pascal Bleser [EMAIL PROTECTED] writes: Just discovered that libs/config/configure is spoiled with CRLF in 1.30.1 Shouldn't be the case for a UN*X script ;) Fixed now. I wonder if it really ought to be checked in as binary so this doesn't happen? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_EXPLICIT_TEMPLATE_TYPE
Eric Friedman [EMAIL PROTECTED] writes:
Dave (and others):
Eric Friedman wrote:
David Abrahams wrote:
Hi,
BOOST_EXPLICIT_TEMPLATE_TYPE is great!
However:
[snip]
// specialization
template
int fvoid( /*what goes here?*/ )
{
}
we have no mechanism for handling these. Any ideas?
Wouldn't BOOST_EXPLICIT_TEMPLATE_TYPE(void) work?
Ooops, you're right. Guess I don't know the standard well enough.
I've added BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC (and so on) helper macros to
address this problem (in config/suffix.hpp) since it's actually been
creating problems with variant under gcc. Let me know if this solution
doesn't meet your expectations.
Thanks! The next time I need this, I'll look at what you've done.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] bind/lambda - unsupported use case?
-Original Message-
From: Aleksey Gurtovoy [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 4:27 AM
To: Boost mailing list
Subject: [boost] bind/lambda - unsupported use case?
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind( post_command
, ( bind( show_warning, message_dialog(), _1 ) )
// what goes here?
)
);
}
Could we make it work, somehow? Offers of a hand-written function
performing the composition are not accepted :)
Aleksey
I'm a bit confused by your request,
Do you want both fns to be called? in which case using boost/lambda.hpp and the
operator,() between two bind statements?
as in:
(bind(post_command), bind(show_warning, message_dialog(), _1) )
I haven't compiled it but it should call first the post_command, and then the
show_warning with the argument.
-Gary-
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: | What is the problem adapting pair of iterators to scalar vectors to produce | an iterator with complex value type? The problem is you can hardly adapt a pair. So using iterator_adaptor (the new class template) does not provide any benefit. Why is that? I did not look in depth on new version but I remember that old one allowed to adapt any source. For convenience one could've created object generators. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_2 tagged for release
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] writes: It appears that the tagging step for Version_1_30_1 got messed up somehow. Please have a look at RC_1_30_2, which is our release candidate for Version 1_30_2, and let me know if there are any problems. Our results are here: http://tinyurl.com/jipe. They seem to be fine. Should we run the regression tests continuosly? Yes, please! The tests should be on the RC_1_30_0 branch, not on RC_1_30_2 - it's not a branch tag and should've been labelled RC_1_30_2a2 or something. Would you also please try substituting the HEAD state of intel-win32-tools.jam for the one on RC_1_30_2? I think it might just eliminate that last error in lexical_cast_test. Thanks! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Announce: dynamic_any in the Boost Corner
http://www.cuj.com/documents/s=8470/cujweb0309nasonov/ -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
# if BOOST_WORKAROUND( __BORLANDC__, = 0x0560 ) I would just like to point out that if _USE_OLD_RW_STL is defined, BCB6 uses the roguewave STL from BCB5 and so doesn't have this _STL/std:: conflict. So it may be worth introducing that into the #if somehow. (I don't define this because I prefer STLPort to RW STL but it is a fix) Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filesystem feature request
Pavel Vozenilek [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] I need the ability to do interprocess synchronization through file locking, c.f. Java.File.createNewFile and Java.File.deleteOnExit: ... On Posix, the first one would be done with open(..., O_CREAT | O_EXCL) and the second, I suppose, would be done with a terminate handler. The second feature (delete-on-exit) is supported by OS: - on Win32 using FILE_FLAG_DELETE_ON_CLOSE flag in CreateFile() - on Unix using unlink() standard system call FILE_FLAG_DELETE_ON_CLOSE deletes the file when the last handle is closed, not when the process is terminated. It is therefore similar, but not quite the same. -- Craig ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ABI fixing and prefix/suffix headers (was the boost::signal sample crashes)
The main problem with shared_ptr 1.30.x and below is that the single- and multithreaded versions are incompatible. The CVS version is now binary compatible on Windows, so 1.31 will work across different threading models; still, the correct default for Borland should probably be to do a multithreaded build. By the way, this can't be fixed with prefix/suffix headers. Agreed, no-one is trying to fix that - threaded and non-threaded builds use different run time libraries for both the Microsoft and Borland compilers - mixing code that was built with threading turned on with code where it is turned off will *always* cause ODR violations, even if you're not using boost :-) but by default the libraries are all built using the default compiler option for the tool. The inlined (header-only) library are only tested against that default set, so why not enforce that default set for all boost libraries? If an individual library author then wants to enforce another set (different alignment or something) for optimisation purposes, then let then over-ride the defaults, But I don't want to enforce a set. I want (for example) shared_ptr to use whatever set the user has specified and not to override his settings. Which causes no end of issues for libraries with separate source, unless we abandon having a build system altogether and just tell people to build everything yourself. To put this in perspective for C++ Builder the following options effect the ABI: -b (on or off - effect emum sizes) -Vx (on or off - empty members) -Ve (on or off - empty base classes) -aX (alignment - 5 options). -pX (Calling convention - 4 options) -Vmx (member pointer size and layout - 5 options) -VC (on or off, changes name mangling) -Vl (on or off, changes struct layout). In addition, there are a whole bunch of separate runtime libraries - 4 C libraries, plus 2 STLPort versions on top (so 8 combinations). And that's not counting the optional diagnostic libraries or the optional use of Rogue Waves STL. So assuming we build libraries for the 8 runtime variants we can't control, that still leaves 2*2*2*5*4*5*2*2=3200!!! ABI options for each runtime variant. Seriously we need to get a handle on this where we can - and please don't forget users can always turn this off if they want to handle the ABI themselves. One final point - there was a reason that I moved regex to use automatic library selection and ABI fixing - without it I was getting a tonne of support requests along the lines of Your library doesn't work, it just crashes when I call anything, which almost always turned out to be caused by ODR violations (either the user had changed an ABI option, or had linked to the wrong runtime-library-build variant), these basically stopped overnight once I modified my code to stop those (this was all in pre-boost days BTW). Convinced yet? John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Infinite number of parameters?
That's a cool idea. It's a lot prettier than using the preprocessor.
Does anyone know whether or not a language solution is being considered
for this or variable class template arguments?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Philippe A. Bouchard
Sent: Monday, August 04, 2003 9:39 PM
To: [EMAIL PROTECTED]
Subject: [boost] Infinite number of parameters?
Hello,
Often some function and functors requires to be overloaded N times
to
handle undefinite number of arguments, depending on some default
setting.
Maybe the following could be used; it overloads operator , () and
gradually
creates a typelist. This typelist is used to replace the undefinite
number
of arguments:
#include iostream
using namespace std;
namespace infinite
{
template typename T = void, typename U = void
struct typelist : U
{
typedef T type;
T value;
typelist(T const a, U const b) : value(a), U(b) {}
};
template
struct typelistvoid, void
{
typedef void type;
};
template typename T
struct typelistT, void
{
typedef T type;
T value;
typelist(T const a) : value(a) {}
};
typelist const begin = typelist();
}
template typename V
infinite::typelistV, void operator , (infinite::typelist const ,
V
const v)
{
return infinite::typelistV, void(v);
}
template typename T, typename U, typename V
infinite::typelist V, infinite::typelistT, U operator ,
(infinite::typelistT, U const t, V const v)
{
return infinite::typelist V, infinite::typelistT, U (v,
infinite::typelistT, U(t));
}
// Usage example:
template typename T, typename U
void foo(infinite::typelistT, U const i)
{
cout __PRETTY_FUNCTION__ endl;
}
int main()
{
foo((infinite::begin, true, (char *) adasd, 12367, 127.2));
}
My 0,02$
Philippe
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Beman Dawes [EMAIL PROTECTED] writes: At 07:37 AM 8/11/2003, David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Beman Dawes wrote: Assuming I'm release manager for 1.31.0, I'm going to publish explicit release criteria for key platform/compiler pairs. Basically, the criteria will be 100% accounting for all failures on those platform/compiler pairs. While I totally support the failures markup goal, I would like to see _the_ release criteria to include no regressions from the previous release item as well, preferrably for all non-beta compilers that are currently under regression testing. Especially since now we have tools to ensure it. I worry a little about requiring library authors not to regress on compiler combinations they don't test with. For example, who is going to address the one lexical_cast failure that's plaguing the 1.30.2 release? It's only on intel-7.1 with STLPort and looks for all the world like a config problem. It can be very time consuming to track down the exact reason for failures. Thus we should focus our 1.31.0 effort on a small number of widely used compilers which don't have a lot of problems. For a lightly used toolset like intel-7.1 with STLPort, looks for all the world like a config problem seems like a good enough resolution to me. In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage; Re: Re: Re: Re: GUI/GDI template library]
Hi, I would like to say one word about the VCF library. I know it is totally unknown to most of people. I didn't see any comments beside the one of Bohdan. VCF is an extremely good GUI multiplatform library. And even if it is not yet at version 1.0, yet it does let people to program very fast with a very small learning time. And gives to people a big flexibility, because it is very scalable I was sceptical before using it, but now I am not. I am using the VCF in production work and I am very happy with that. The VCF uses the BSD license which essentially means that you can do everything you want with that code You might get some good hints from that library, and experience. I signalled this boost thread to the leader of the VCF library. He's available for giving you more informations if you desire. His contact informations are: Jim Crafton [EMAIL PROTECTED] or, in the evenings: IRC server: irc.freenode.net Port: 6667 Channel: #vcf About widgets... VCF usually wraps the native ones, like in the case of a list view But in some cases it is much less work to write it from scratch, like in the case of the ComboBox control. Hope it helps, Marcello Bohdan wrote: Trying to continue GUI libraries review ( FLTK, WxWin ) Any ideas about VCF ( visual component framework ) sourceforge project ? Its original idea was taken from Borland C++ Builder. Unfortunately, this IDE and VCL (pascal GUI library used by Delphi and c++ builder) doesn't allow to use c++ features like templates and multiple inheritance in gui components. Anyway idea is great. VCF project is trial to fix this drawback. They already have new IDE and GUI library more c++ friendly and portable. Despite it is relatively new project, it looks great. Can it be used somehow ? Or more lazy choice : ask developers to port it to boost ?:)) It is developed under BSD license. I'm not expert in licenses :(. If somebody can shed light on this license thanks. regards, bohdan Steve Hutton wrote: In article [EMAIL PROTECTED], Brock Peabody wrote: I suggest taking maybe some classes of WxWindows or Qt for basic portable [x1, y1, x2, y2] paint devices. This would be a beginning. I'm sure we could learn something at least. Note: Qt is GPL, WxWindows is (modified) LGPL. Obviously, there are potential licensing issues with creating a new implementation modeled after GPL/LGPL code. Studying the interfaces and documentation is probably fair game, but copying from the source has license implications for your library. On the other hand, if you create a derivative work that links to low level classes of one of these existing libraries, you could release an initial prototype under the matching library license, then later replace the low level classes with your own and change the license to a boost compatible one. Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Martin Wille [EMAIL PROTECTED] writes: David Abrahams wrote: In that case, can I release 1.30.2? I don't like having the 1.30.1 debacle hanging over my head. There are new regressions on Linux (RC_1_30_0 branch): http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html crc has regressions for gcc-3.1 and gcc-3.2.3 config, format and io have regressions for intel 7.1 According to your chart, the following libraries are all regressing: config crc date_time format function graph io math multi_array numeric/interval numeric/ublas optional random static_assert test type_traits utility Are these real regressions or just newly-tested compilers? Can the library authors/maintainers address these problems? Where is our maintenance wizard? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Also boost.random still does not compile on msvc6
1.30.0 boost.random did not compile on msvc6. I submitted patches right after 1.30.0 release and they were applied to CVS, but they did not made into 1.30.1, which is not surprising, given that random unit test is not a part of the regression suit. If there are plans on releasing 1.30.2 (since some files are missing, etc), it would be great if those patches were tagged for release. --Kirill Lapshin ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
E. Gladyshev [EMAIL PROTECTED] wrote: --- Brock Peabody [EMAIL PROTECTED] wrote: It stands for 'standard'. Maybe that's a little pretentious for us at this early stage :) gtl would probably be better. I suspect that if we get to a review some people may request something more verbose. Since GTL is already taken, how about GTF (GUI Template Framework)? Can't we be more imaginative than that? Aren't we all already saturated with acronyms and acronyms and yet more acronyms? There is no policy anyway that forces us to use acronyms in boost. When Spirit was being reviewed, I was a bit afraid that someone would come out and suggest that it be named as BPL. Akkk! Fortunately, no one did. And after all, BPL already stands for boost python library. In the world of computers, it is already a sea of acronyms. IMO, acronyms are ugly! This is my opinion of course. I am entitled to my own opinion right? :-) bicycle-shed-ingly-yrs, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
David Abrahams wrote: Matthias Troyer writes: Dear Boosters, Since some of the applications and libraries we plan on releasing soon rely on Boost features and bugfixes that are in the CVS but not in Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0 release? Since we would prefer to base our released software on a Boost release instead of a CVS snapshot I would be interested in hearing about the plans for a Boost 1.31 release As far as I know the CVS is in very good health at the moment. The only major thing I know needs to be done is to complete the documentation for the new iterator adaptors. I'd like to get that over with soon, so it isn't hanging over our heads much longer. There is still some work to be done on variant. In the next day or two, I plan to have sugared up recursive variant support such as the following: typedef boost::variant int , std::vector boost::recursive_variant my_variant; Also, Itay is continuing to work on the documentation and tests. I imagine we'll finish soon. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
