>The confusion is that your interpretation (more
>traditional) of a modern GUI framework is a bit
>different from notus. We are not concerned with
>building low-level controls. The low-level
>implementation is basically proveded by the platform
>(Mac, win32, etc.). Notus is just going to be usin
Brian McNamara <[EMAIL PROTECTED]> writes:
> I can't speak for bind/lambda, although I imagine there must be a way,
> probably involving delaying the evaluation of _1 for one step.
>
> Using FC++, it would be
>
>using fcpp::fun1;
>using fcpp::lambda;
>using fcpp::ptr_to_fun;
>fun1
Eugene,
one more thing when you implement the GUI library.
I ALWAYS hated the message maps from MFC/WTL.
So now I came up with a quite cute method of automating registering of events for a
given window.
(this should work for registering messages, etc.)
It's very flexible. In other words, whe
I am trying to compile Boost against the uClibc libraries. This requires
that I define a custom value for LD_LIBRARY_PATH, so that my uClibc
libraries are used instead of the standard system libraries.
The problem I have is that building Boost.Python generates its own
LD_LIBRARY_PATH definition
George A. Heintzelman wrote:
Given that I have a string 's' from somewhere, I'd like to create a
regular expression where some part must match that string. The problem
is, the 's' could contain characters that have a special meaning in
regular expressions. Is there some support function that can
David Abrahams wrote:
Martin Wille writes:
Hello,
a couple of libraries are regressing for gcc-2.95.3/Linux:
date_time
graph
iterator
multi_array
numeric/interval
numeric/ublas (only with stlport)
random
variant
Are those libraries supposed to support gcc-2.95?
iterator is. I
"Brock Peabody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Because for a pretty large number of applications you can really
> simplify your code a lot by relying on the GUI system to 'do the right
> thing':
>
>using boost::gui;
>
>void my_action() {...}
>void progr
Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
> On Mon, 11 Aug 2003, David Abrahams wrote:
>> According to your chart, the following libraries are all regressing:
>> function
>>
>> Are these real regressions or just newly-tested compilers? Can the
>> library authors/maintainers address these
Alisdair Meredith wrote:
> Aleksey Gurtovoy wrote:
>
> > 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 regr
Beman Dawes wrote:
> 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
> >
--- Joel de Guzman <[EMAIL PROTECTED]> wrote:
> E. Gladyshev <[EMAIL PROTECTED]> wrote:
> > 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
At 01:39 PM 8/8/2003, Martin Wille wrote:
>In order to avoid problems to be discovered too late for fixing them
>I'll list the tests that fail for many compilers/compiler versions
>on Linux:
>
>- filesystem::operations_test
Hum... That looks like a CVS problem. It looks like
boost-root/libs/files
At 08:00 AM 8/11/2003, John Maddock wrote:
>
>> I'm not sure how to proceed with this so if there is anything I can do
>> in the meantime, let me know. Feel free to e-mail me off the list.
>
>OK, I've got this working pretty well with regex - but as it entails
>changes
>to boost.config I'm not sur
>
> http://lists.boost.org/MailArchives/boost/msg46513.php
>
> indicating some interest in combining thread safety and
> decoration. It seems to me (a novice in threading) that
> what needs to be protected is the access to the end
> of the pipeline, i.e. the final streambuf, which is
> connected
[2003-08-11] David Abrahams wrote:
>Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
>> Well, sure, as long as we are in agreement about having differently
>> named toolsets for different compiler versions/configurations, e.g.
>>
>> bcc-5.5.1
>> bcc-5.6.4
>> intel-7.1-vc60
>> intel-7
David Abrahams wrote:
Martin Wille writes:
The fix made to the gcc toolset regarding the use of the
GXX variable should be backported to 1_30_2.
Please be more specific, i.e. post a patchset.
If I had a patchset then I would have applied it :)
(I sent a bug report some time ago to the JamBoost
16 matches
Mail list logo
