headers
Vesa Karvonen | 1 Nov 2004 03:55
Picon
Favicon

Lazy Metaprogramming Library [UPDATE]

Hi,

I have made some optimizations (resulting in an order of magnitude (10x)
improvement in compile-time in some cases on GNU g++) to the library
and implemented a couple of new metafunctions. The latest snapshot can
now be downloaded from the Files Section (both zip and tar.bz for your
convenience):

  http://groups.yahoo.com/group/boost/files/LazyMPL/

Please note that the library is only a proof-of-concept made in about 2 
days.
It should be quite possible to provide a more comprehensive library of lazy
metafunctions and provide facilities like the lambda-facility of Boost MPL.
(Also, you shouldn't worry about the upper case naming used in the library.)

Lazy template metaprogramming, as shown by the lazy metaprogramming
library, eliminates the number one stumbling block of template
metaprogramming as described by every introduction or guide to template
metaprogramming (e.g. http://www.boost.org/libs/mpl/doc/#applyif and
Generative Programming section 10.11.1.3 Taking Advantage of Lazy
Behavior (particularly pages 441-443... "You should remember this when
writing static code" ;)).

In lazy template metaprogramming, invocations (::type) are only needed
when a value needs to be explicitly examined (e.g. to extract the head
of a list). Use of the typename-keyword can be practically eliminated and
forwarding (use of inheritance) is the usual way to implement functions.

Explicit invocations can (are) also be used for optimizing lazy
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aleksey Gurtovoy | 1 Nov 2004 06:25
Favicon

Re: Lazy Metaprogramming Library [UPDATE]

Vesa Karvonen writes:
> Hi,
> 
> I have made some optimizations (resulting in an order of magnitude (10x)
> improvement in compile-time in some cases on GNU g++) to the library
> and implemented a couple of new metafunctions. The latest snapshot can
> now be downloaded from the Files Section (both zip and tar.bz for your
> convenience):
> 
>   http://groups.yahoo.com/group/boost/files/LazyMPL/
> 
> Please note that the library is only a proof-of-concept made in about 2 
> days.
> It should be quite possible to provide a more comprehensive library of lazy
> metafunctions and provide facilities like the lambda-facility of Boost MPL.
> (Also, you shouldn't worry about the upper case naming used in the library.)
> 
> Lazy template metaprogramming, as shown by the lazy metaprogramming
> library, eliminates the number one stumbling block of template
> metaprogramming as described by every introduction or guide to template
> metaprogramming (e.g. http://www.boost.org/libs/mpl/doc/#applyif and
> Generative Programming section 10.11.1.3 Taking Advantage of Lazy
> Behavior (particularly pages 441-443... "You should remember this when
> writing static code" ;)).
> 
> In lazy template metaprogramming, invocations (::type) are only needed
> when a value needs to be explicitly examined (e.g. to extract the head
> of a list). Use of the typename-keyword can be practically eliminated and
> forwarding (use of inheritance) is the usual way to implement functions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksey Gurtovoy | 1 Nov 2004 07:21
Favicon

Re: Re: [1.32 Release] Draft tarballs are available

Eric Niebler writes:
> Aleksey Gurtovoy wrote:
> 
> > 
> > For your convenience, the unpacked contents is also available online
> > at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You
> > can consider this to be a draft version of post-1.32 Boost website.
> > 
> 
> 
> It looks like only some of the documentation is using the new style 
> sheet. 

It's more than that, but you're probably right that a uniform stylesheet
would smooth the most visible differences.

> Compare these two:
> 
> http://www.meta-comm.com/engineering/boost/1_32_0_draft/doc/html/any.html

This one is BoostBook-generated.

> http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/bind/bind.html

And this one is hand-crafted (AFAIK).

> 
> Kind of messed up. 

I agree that the lack of consistency is significantly more obvious than what
(Continue reading)

Permalink | Reply | 14 comments |
headers
Aleksey Gurtovoy | 1 Nov 2004 07:48
Favicon

Strange Linux regressions


A number of libraries fail with various versions of GCC and Intel with 
the following output (e.g. http://tinyurl.com/4q93w):

  g++: Internal compiler error: program as got fatal signal 11

and (http://tinyurl.com/3s92x):

  icpcbin: error: Fatal error in /opt/intel/compiler70/ia32/bin/mcpcom, terminated by segmentation violation

Martin, is this the dreadful memory problem that you've been talking 
about?

--
Aleksey Gurtovoy
MetaCommunications Engineering

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Aleksey Gurtovoy | 1 Nov 2004 08:12
Favicon

Re: [1.32 Release] Draft tarballs are available

Aleksey Gurtovoy writes:
[...]
>
> KNOWN ISSUES
> ------------
> 
> The following is a list of known issues present in the tarballs
> which grant them their draft status:
> 
> 1) A small number of unmarked test failures (but no regressions).
> 
> 2) A small number of broken links as follows:
> 
>     doc/html/date_time/doxy.html: broken link:
../../../boost/date_time/dst_transition_day_generators.hpp, broken link:
> ../../../boost/date_time/local_time_base.hpp
>     doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png
>     doc/html/libraries.html: broken link: ../boost.pdf
>     libs/libraries.htm: broken link: ../boost.docbook, broken link: ../boost.fo, broken link: ../boost.pdf
>     libs/numeric/conversion/doc/converter.html: broken link: udt_support.html
>     libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html

  2.5) Program Options library is missing from 
  http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/libraries.htm
  [Reported by Matthew Burgess and fixed in the branch]

--
Aleksey Gurtovoy
MetaCommunications Engineering
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vladimir Pozdyayev | 1 Nov 2004 08:21
Picon

Re: [regex] any interest in finite automata-based regexengine?

John,
I've studied the interfaces you suggested, and here are my
observations. Please correct me if I'm wrong.

<perl_matcher> is a collection of algorithms which sort of hack
into the underlying <basic_regex>'s internal data structures and
use them to perform matching or whatever they're up to.

<basic_regex_creator> is a "syntax features to internals"
converter which is called directly by the parser. In theory,
implementing it should be the better way to initialize customized
structures. However, the way it is used is somewhat tricky: it
fills not its own data structures, but structures of the class
that called the parser itself---the <basic_regex_implementation>.
So this one would need reimplementing, too.

Now for the real problem. Both <perl_matcher> and
<basic_regex_creator> deal with the already compiled state machine
or its elements. The first one works directly with the regex
internals, the second one gets <append_state> and similar calls
from the parser. The trouble is, some of my algorithms'
calculations have to be performed directly on the expression tree,
the compiled state machine won't help. Is it possible to restore
the tree from the information provided by the library? That is,
given the regex "((?:a|b)*?)(b+)", end up with an object like

    new cat(
        new match(
            new kleene_lazy(
                new alt(
(Continue reading)

Permalink | Reply | 11 comments |
headers
Johan Nilsson | 1 Nov 2004 08:29
Picon

Re: Re: Re: FORMAL review process not working well?


"Victor A. Wagner Jr." <vawjr <at> rudbek.com> wrote in message news:6.1.2.0.2.20041031093821.048ac038 <at> mail.rudbek.com...
> At Sunday 2004-10-31 04:36, you wrote:
> 
> 
> >[deleted]
> >>>However, I
> >>>think groups are unbeatable at uncovering design-flaws.
> >>
> >>True, OTOH it is much easier to find a design flaw than to generate a
> >>good, solid design.
> >
> >Agreed.
> 
> if it's so much easier to find flaws, how come so many thing are released 
> w/ so many flaws?

Design or implementation flaws?

// Johan

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Eric Niebler | 1 Nov 2004 08:29
Picon
Favicon

Re: [1.32 Release] Draft tarballs are available

Aleksey Gurtovoy wrote:
> Eric Niebler writes:
>>Should I edit all the HTML files to make them refer to the new style sheet? 
> 
> I'm afraid that would require approval from the corresponding authors of the
> library.

Good point.

>>Or back out the style sheet for this release?
> 
> I'd consider backing out on the fonts, and leaving everything else as is.
> 

That doesn't appeal to me, but I'd be interested to hear other opinions. 
There was broad consensus on boost-docs that sans-serif was ultimately 
what we wanted for boostbook documentation. I'm inclined to stick with 
it, live with the inconsistency for this release, and encourage people 
to port their docs to boostbook for the next one.

BTW, how come the "Nightly CVS" documentation (linked to from 
boost.org/) doesn't have the non-boostbook docs? And in general, it 
doesn't look much like the documentation in the tarball? Seems that 
whatever process we're using to generate the docs for the release should 
be the same as what we use to generate the "Nightly CVS" documentation, 
so that any problems can be spotted early.

--

-- 
Eric Niebler
Boost Consulting
(Continue reading)

Permalink | Reply | 12 comments |
headers
Vladimir Prus | 1 Nov 2004 08:44
Picon
Favicon

Re: [1.32 Release] Draft tarballs are available

Aleksey Gurtovoy wrote:

>   2.5) Program Options library is missing from
>  
http://www.meta-comm.com/engineering/boost/1_32_0_draft/libs/libraries.htm
>   [Reported by Matthew Burgess and fixed in the branch]

Thanks! Should I do RC->trunk merge?

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Johan Nilsson | 1 Nov 2004 09:21
Picon

Re: logging lib, v1.3


"Darryl Green" <darryl.green <at> unitab.com.au> wrote in message news:loom.20041031T021329-215 <at> post.gmane.org...
> Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:
> > "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message 
> news:loom.20041030T055250-159 <at> post.gmane.org...
> > > The library actually supports overriding the types used for logging 
> including
> > > the threading primitives used, which (unless you use the ts_appender) is 
> only
> > > a simple mutex and corresponding scoped lock class. So you should be able to
> > > keep those managers happy by using/wrapping other mutex/lock classes.
> > 
> > I don't recognize that, is it documented somewhere?
> 
> No, but it will be. The lib is a bit pre-release at present. Maybe 0.3 would be 
> a better rev number than 1.3...
> > 
> > > 3) Something quite radically different such as a log where the "stream" is
> > > something into which structured log information can be assembled, and
> > > the "string" carries that information to appenders that use that structured
> > > information (format it for textual output, write it to a database table...).
> > 
> > Is this actually possible? How?
> 
> Have a look at log_fwd.hpp You will see that there is a default_log_manger 
> struct which defines the char_t, string, stream types.
> 
> You will also see that log_manager is a (trivial) metafunction class taking an 
> int parameter that returns the default_log_manager type by default. In log,hpp 
> log_manager<0>::type is used to obtain the types used throughout the logger.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane