Le 27/07/2012 08:11, Eric Niebler a écrit :
You mean, a proto callable that wraps fusion::transform? No, we don't
have one yet. If you write one, I'll put it in proto.
OK
Naming is becoming an issue, though. We already have proto::transform.
You'd be adding proto::functional::transform that w
Yeah i figured the code was amiss.
After corrections and using your tip, it works.
The I discovered it was not what I wanted ;)
What I actually need to do is that when I encounter a bunch of
bitwise_and_ node, I need to flatten them then pass this flattened
tree + the initial tuple to the equival
Here is the deal:
https://gist.github.com/3182676
THis code defines a DSL that allwo creating combo of functions using the
following semantic:
(task(f) | task(g))(x) computes g(f(x))
(task(f) & task(g))(x) computes make_tuple(x)),g(at<1>(x))>
We use external_trasnforms here because we will
Le 13/07/2012 23:55, Eric Niebler a écrit :
This is an instance of the larger "common subexpression elimination"
problem. The problem is complicated by the fact that it can't be solved
with type information alone. u_adv*nable(u) might have the same type as
u_adv*nable(v) but different values. A h
On 06/24/2012 01:10 AM, Eric Niebler wrote:
I've made some good progress on the C++11 proto rewrite that I'd like to
share. So far, it's been a less radical shift than I expected.
You didn't try hard enough ;)
Expressions vs. Grammars
Many new users are confused by th
Just a question that just struck me. Will this rewrite be backward
compatible with C++03 for the features that make sense ? I think the
C++03 version may benefit from the new expression extension mechanism etc.
___
proto mailing list
proto@lists.boos
Hi,
i'm in the process of writing a journal paper about proto and I wanted
to give
a realistic snapshot of who is using proto and for what. I know some already
(the whole MSM & Spirit team etc ) but i am sure there is other people
lurking
around here.
So, if you want to contribute, I wish an
Le 04/06/2012 21:18, Eric Niebler a écrit :
The make_expr function object takes as arguments the tag and the
children. You can do whatever you want. If open extensibility matters,
you can dispatch to a function found by ADL or to a template specialized
on the tag like proto::switch_. It's up to y
On 01/06/2012 07:55, Eric Niebler wrote:
However, it means that you will no longer be able to use a proto grammar
as a generator. That was cute functionality, but I don't think it was
terribly useful in practice. How do folks feel about the loss of that
functionality?
I personnally never used i
On 03/06/2012 09:41, Eric Niebler wrote:
Hey all, this is just an FYI. I've been hard at work at a ground-up
redesign of proto for C++11.
Great news !
1) Rather than writing expression wrappers, you'll be writing actual
expression types. Proto provides helpers that make this easy. To get th
On 05/29/2012 08:21 PM, Eric Niebler wrote:
On 5/29/2012 1:44 AM, Karsten Ahnert wrote:
I have an arithmetic expression template where multiplication is
commutative. Is there an easy way to order a chain of multiplications
such that terminals with values (like proto::terminal< double>) appear
a
On 04/29/2012 02:41 AM, Eric Niebler wrote:
And some_terminal is not in your domain? How does your generator get
invoked? I guess I'm confused. Can you send a small repro?
everything is in my domain, no problem ont his side, I'll try Mathias
idea and report if anything breaks.
__
How can I use a custom generator to turn a specific node expression into
a different version of itself without triggering endless recursive call ?
My use cas is the following, i want to catch all function node looking
like
tag::function( some_terminal, grammar, ..., grammar )
with any nbr of g
On 04/24/2012 12:15 AM, Eric Niebler wrote:
implicit_expr() returns an object that holds its argument and is
convertible to any expression type. The conversion is implemented by
trying to implicitly convert all the child expressions, recursively.
It sort of worked, but I never worked out all th
Let's say we have a bunch of functions like sum and sqr defined on a
proto domain to return
expression of tag sum_ and sqr_ in this domain. One day we want to make
a norm2(x) function
which is basically sum(sqr(x)).
My feeling is that I should be able to write it using sqr and sum
expressions.
On 10/04/2012 00:00, Eric Niebler wrote:
Thanks. I thought long about whether to handle the fundamental types
differently than user-defined types and decided against it. The
capture-everything-by-reference-by-default model is easy to explain and
reason about. Special cases can be handled on a per
On 30/12/2011 17:34, Bart Janssens wrote:
On Fri, Dec 30, 2011 at 7:01 AM, Eric
Niebler wrote:
Are you certain your problem is caused by using operator() for grouping?
I think this is just a very big expression template, and any syntax you
choose for grouping will result in long compile times
Le 29/08/2011 17:33, Eric Niebler a écrit :
Good. Obviously, this needs to be called switch_ instead of select_.
Sure I was testing the water inside nt2 first
There needs to be an appropriate default for the Transform parameter,
something like tag_of<_>(). There should also be a specializatio
Le 06/08/2011 08:10, Eric Niebler a écrit :
On 8/5/2011 10:55 PM, Joel falcou wrote:
On 06/08/11 07:30, Eric Niebler wrote:
That wouldn't be enough because proto::matches "knows" about
proto::switch_. It would be easy enough to extend proto::switch_ to take
an optional mpl me
Le 26/08/2011 17:56, Eric Niebler a écrit :
On 8/26/2011 11:44 AM, Eric Niebler wrote:
Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector
Le 26/08/2011 17:44, Eric Niebler a écrit :
On 8/26/2011 11:23 AM, Joel Falcou wrote:
On 26/08/2011 17:18, Eric Niebler wrote:
Why can't you use a grammar to recognize patterns like these and
take appropriate action?
we do. Another point is that container based operation in our system
On 26/08/2011 17:27, Brandon Kohn wrote:
I solved this kind of problem by tagging the various types in traits
structs and then embedding these traits in the transforms for the
various operations.
Here are examples of my expression, grammar, and binary function
definitions:
https://github.com/br
On 26/08/2011 17:18, Eric Niebler wrote:
Why can't you use a grammar to recognize patterns like these and take
appropriate action?
we do. Another point is that container based operation in our system
need to know the number of dimension of the container. Domains carry
this dimensions informat
On 26/08/2011 16:45, Eric Niebler wrote:
Before I answer, can you tell me why you've decided to put vector and
matrix operations into separate domains? This seems like an artificial
and unnecessary separation to me.
We have a system of specialisation where being able to make this
distinction a
On 06/08/11 21:01, Eric Niebler wrote:
Besides, enable_if is yuk.
Care to elaborate (not like we use it like over 9000 times in our code
base) /
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 06/08/11 07:30, Eric Niebler wrote:
That wouldn't be enough because proto::matches "knows" about
proto::switch_. It would be easy enough to extend proto::switch_ to take
an optional mpl metafunction that accepts and expression and returns a
type to dispatch on. It would default to proto::tag_o
There is few use case where I wish i can have a proto::switch_ like
transform being extendable externally but based on something else than
the expression tag like the result of an arbitrary meta-function.
Is cloning proto::swicth_ and changing the way it dispatch over its
internal cases_ enoug
On 17/06/11 01:25, Eric Niebler wrote:
Doable, but not easy. The problem you'll have is that all Proto
expression types have a nested fusion_tag that is a typedef for
proto::tag::proto_expr. That is how Fusion figures out how to iterate
over Proto expressions. You'll need to define your own tag,
proto expression are fusion sequence that iterates over the node
children. All fine and dandy.
Now here is my use case. I have expression whose terminal are fusion
sequence that access tot he terminal values (think terminal holding a
std:;array for example) and I wished to have expression of t
Seems somethign crooky on this front. Calling fusion::at_c on expression
ends up in error even after including boost/proto/fusion.hpp.
Same way, flatten used as a transform seems to not give me a type that
can be passed to any fusion or mpl function. Looking at
proto/fusion.hpp I noticed that the
On 09/05/11 20:36, Eric Niebler wrote:
Right, that's not going to work. I'm surprised it ever did.
it was long shot by us I confess. I'll repent I promise
Can you you boost/typeof.hpp
For w/e reason it fails horribly in flames and brimstone under MSVC2010
in our test cases.
PROTO_DECLTYPE do
On 09/05/11 21:12, Eric Niebler wrote:
FWIW, this was due to a missing #include, which I've since fixed. This
*should* work again, but it's not part of Proto's public documented
interface. I reserve the right to break your code. ;-)
No problem. This is anyway some ugly fix. We have to slaps MSVC
I got these error compiling NT2 with proto trunk
/usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:56:
error: 'M0' has not been declared
/usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1:
error: expected identifier before '~' token
/usr/local/include/boost-la
On 01/05/11 04:41, Eric Niebler wrote:
In some cases, I really want to write something like
proto::make_expr(
proto::as_child(a0),
proto::as_child(a1)
)
but that kind of thing doesn't work, due to the funny way make_expr works.
It doesn't work? I *think* that would have the effect of b
Hello,
we need a way to know if a given expression is the "top level" one.
The use case is to detect the last = in expression like:
a = b = c = x * y;
A working but runtime version is given as : http://codepad.org/MO2NUgI2
Havign this feature at compiel time sounds a lot better. I think it
re
On 14/03/11 22:28, Christophe Henry wrote:
.. the talk from Matt Calabrese last year at boostcon with the
MPL/Fusion hybrid
using decltype and auto. I think this is an interesting venture all in
all and should
be extended.
Yes, I have this in mind too.
I think it is worthy of *at least* consid
On 14/03/11 04:49, Eric Niebler wrote:
Exciting stuff! Truly Christophe, your ideas re decltype and EDSLs in
C++ are revolutionary. But unfortunately, I fear it will require a
revolution. This is all do-able, but the changes to MPL, Proto and even
to Phoenix in the case of the lambda capture stuf
On 26/02/11 12:55, Eric Niebler wrote:
But maybe it wouldn't hurt. Maybe RVO kicks in. It's worth testing. Joel
F., are you listening? Yours is probably the most performance sensitive
application of Proto. Can you try compiling with
BOOST_PROTO_STRICT_RESULT_OF and let us know if there's a perf h
On 26/02/11 10:50, Eric Niebler wrote:
Sure. This is pretty easy. I suggest you introduce an additional unary
node with a special tag that is recognized by your grammar. For
instance, exponentbits currently returns:
unary_expr< exponentbits, arg>
Instead, make it return:
unary_expr< ex
On 26/02/11 02:18, Nate Knight wrote:
I'm trying to understand why the two commented out lines fail to compile. It
seems to me
that ideally they would compile, but I may be missing some constraint that
makes these
lines incorrect. In the first case, it seems like the return type of the
defau
Hi,
while adding function to my SIMD library built on proto. I stumbled into
this problem:
http://codepad.org/dd5WB8Xu
I have a template grammar/generator/domain that helps me not mixing
vector of different type/cardinal.
However some functions are designed to take vector of float and turn
On 20/02/11 12:41, Eric Niebler wrote:
On 2/20/2011 6:40 PM, Joel Falcou wrote:
On 20/02/11 12:31, Karsten Ahnert wrote:
It is amazing that the proto expression is faster then the naive one.
The compiler must really love the way proto evaluates an expression.
I still dont really know why
On 20/02/11 12:31, Karsten Ahnert wrote:
It is amazing that the proto expression is faster then the naive one.
The compiler must really love the way proto evaluates an expression.
I still dont really know why. Usual speed-up in our use cases here is
like ranging from 10 to 50%.
On 20/02/11 12:03, Karsten Ahnert wrote:
On 02/20/2011 12:02 PM, Joel Falcou wrote:
On 20/02/11 11:55, Karsten Ahnert wrote:
On 02/20/2011 11:57 AM, Eric Niebler wrote:
It gcc 4.4 on a 64bit machine. Of course, I compile with -O3.
Ding! welcome to gcc-4.4 64bits compiler hellfest.
Try 4.5
On 20/02/11 11:55, Karsten Ahnert wrote:
On 02/20/2011 11:57 AM, Eric Niebler wrote:
It gcc 4.4 on a 64bit machine. Of course, I compile with -O3.
Ding! welcome to gcc-4.4 64bits compiler hellfest.
Try 4.5, 4.4 64bits can't inlien for w/e reason.
___
On 20/02/11 11:57, Eric Niebler wrote:
On 2/20/2011 5:52 PM, Joel Falcou wrote:
1/ how do you measure performances ? Anything which is not the median of
1-5K runs is meaningless.
You can see how he measures it in the code he posted.
I clicked send too fast :p
2/ Don't use context, tran
1/ how do you measure performances ? Anything which is not the median of
1-5K runs is meaningless.
2/ Don't use context, transform are usually better optimized by compilers
3/ are you using gcc on a 64 bits system ? On this configuration a gcc
bug prevent proto to be inlined.
__
On 31/01/11 04:38, Eric Niebler wrote:
This is a judgment call that only you, as library author, can make. If
doing the checking early imposes too high a compile-time requirement,
then it may make sense to delay it until it's less expensive to do, and
accept worse error messages.
*nods*
But at
I'm trying to polish the last layer of compile time error handling in nt2.
my concern at the moment is that, if have a function foo(a,b) that works
on any real a and any char b, i dont want my foo function working on nt2
container to work with nothing but matrix of real and matrix of char.
nt2 has
Error found.
The problem was in the and_impl transform. It uses comma operator to
chain calls to each and_ alternatives.
However, when this is used in a grammar used as a Generator, it enters a
subtle infinite loop as each comma
want to build an expression with the newly generated expression.
OK, small road bump.
I tried a simple "grammar as geenrator" thingy but using the idea that i
didnt wanted to replicate all possible generator out there.
So i made a template grammar taking a Generator and doing thing around:
struct print_tag : proto::callable
{
typedef void result_type;
t
Disregard last question. a generator is just a callable, so i can use a
grammar as a generator I guess hence using the grammar to dispacth
the proper actions on my ast construction. Am I right ?
___
proto mailing list
proto@lists.boost.org
http://lists.
Last question. The geenrator awaits a Expr as parameters, what can be
the way to specialize this operator() dependign on the tag passed to the
generator ?
Extract tag_of out of Expr and then dispacth internally ?
___
proto mailing list
proto@lists.boos
On 28/12/10 23:13, Eric Niebler wrote:
On 12/28/2010 5:05 PM, Joel Falcou wrote:
Here i smy use case. I guess Eric answer will be "do this at
evaluation time"
Do this at evaluation time. Just kidding.
See :p I was *sure* you will say that :p
You missed the
Here i smy use case. I guess Eric answer will be "do this at evaluation
time" but let's
I have some array/matrix DSEL going on. I want to test if two expression
containing
said matrix has compatible size before creating a proto ast node.
e.g if a,b are matrices, a + b should assert if size(a) !
On 27/12/10 11:02, Maxim Yanchenko wrote:
Hi Eric and other gurus,
Sorry in advance for a long post.
I'm making a mini-language for message processing in our system.
It's currently implemented in terms of overloaded functions with
enable_if> dispatching, but now I see that
Dont. this incre
nice xmas present :D
can't wait for the doc ;D
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 04/12/10 18:01, Eric Niebler wrote:
Something along those lines would be a big improvement. I've gotten
better at explaining Proto since I wrote those docs, and they could use
a major facelift.
I still like the fundamental idea of structuring the users guide around
the idea of Proto as a comp
Hey,
recently I have been promoting Proto to a few fellow coworker in some
academic circles as well as in
some industrial contexts. Most of these evangelisation process turned
quite well but I felt a lot of time
that something wasn't clinking as it should and I think it's partially
because of
On 23/11/10 17:20, Eric Niebler wrote:
On 11/23/2010 10:19 AM, Joel Falcou wrote:
So, question is: is there a way to have an extensible list of
when that can be extended "from the outside", something
like a proto::switch_ but with patterns instead of tag ?
No. The best you can do i
Here is some classical pattern matching using proto::or_
https://gist.github.com/711891
This is pretty canonical I guess (unless my proto-fu is rusting).
As stated in the comments, my main concern is that adding new
pattern->value rules need to edit or_<>. Also classical.
For a long time it d
On 17/11/10 19:46, Eric Niebler wrote:
See the attached code. I wish I had a better answer. It sure would be
nice to generalize this for other times when new state needs to bubble
up and back down.
Just chiming in. We had the exact same problem in quaff where needed to
carry on a process ID ove
That's a tough one :/
Main problem is probably the fact you can't control when/Where eigen do
his bidding.
Best shot is to externally make eigen temporary proto terminals, write a
grammar that disable operators onthem and then write a transform dealing
with the composite E.T AST.
___
On 26/10/10 19:44, Eric Niebler wrote:
struct my_actions_with_state
{
// specializations to look up transforms
// using rules:
template
struct when;
// any ol' state can go here:
int my_state;
};
Now, you can pass an instance of my_actions_with_state as a data
para
> You could pass it as state
OK
> or bundle it with the external transforms.
> All you need is a nested when template. Does that help?
A short example of this for my poor 7am self without coffee ;) ?
___
proto mailing list
proto@lists.boost.org
http:/
> There, that's better. I don't think I'll mess with it any more. Go ahead
> and use it, Thomas.
just a small question: what if I need a transform that use external data ?
in nt2, we have thsi compute trnsform that recursively eats the AST and
call the approprite function passing a n dimension po
On 24/10/10 11:53, Joel de Guzman wrote:
Am I the only one thinking that "actor" should be more a part of proto
than
phoenix? I'd love to use such a generic extension mechanism for Spirit
too,
for example.
I *need* it for nt2 too, makes some optimisation far simpler than before.
_
On 20/10/10 21:34, Thomas Heller wrote:
On Wednesday 20 October 2010 21:24:49 joel falcou wrote:
Using thomas code and my own functor class , i designed a new
computation transform but it fails
to dispatch.
Actually it is Eric's code and idea we are using. So it is him who nee
I took the liberty to peruse this design to redesign nt2 computation
evaluation.
As nt2 provides a lot of functions on its various DSL terminal, we're
seeking
some solution that scale - as havign 200+ case specialization is a
bit unpractical.
S, despite ppl telling me dispacthing on tag ca
I can imagine a lot of usecases that benefit from this feature. Let me
list a few here:
- Multi Stage programming: evaluate the phoenix expression to
another language that can
be compiled by some external compiler. The prime example i
imagine for this is that someone
picks that top
On 15/10/10 09:22, Eric Niebler wrote:
Goodness Joel, I have no idea what you're asking. What's the "visitor
level"? Why would you have to transform the AST? What are you trying to
do, exactly?
LOL, please excuse my non-caeffinated post at 8am :€
I have some AST that represent arithmetic co
Eric Niebler wrote:
Dispatch to transforms on grammar rules.
wait Jolly Jumper ! Does this means I could
traverse a SIMD EDSL AST in search for a*b+c
at the *visitor* level and not requiring to
transform the AST beforehand by dispacthing
over plus> ?
If yes, sign me up :o
_
On 13/10/10 22:54, Eric Niebler wrote:
- constant can mix with any other EDSL
Make them terminals in no particular domain (proto::default_domain).
Check
Define a SIMD domain with no super-domain.
I thought domain with no super-domain ended up in default_domain ?
This sounds
OK, I have a situation in which proto domain/subdomain could help me but
i can't
wrap my head around a proper solution. Here is the deal, i have various
sub EDSL that goes like:
- constants EDSL provides named consatnts (like zero_, one_, pi_ etc)
that are meant to be terminal
usable in any ot
Trying to use template domain class with BOOST_PROTO_BASIC_EXTENDS
ends up in an error leading to the fact this ligne in the macro is incorrect
when the Domain is template:
BOOST_PROTO_BASIC_EXTENDS_(Expr, Derived, Domain)
typedef void proto_is_aggregate_;
typedef Domain::proto_genera
On 07/10/10 23:06, Eric Niebler wrote:
On 10/4/2010 1:55 PM, Eric Niebler wrote:
The idea of being able to specify the transforms separately from the
grammar is conceptually very appealing. The grammar is the control flow,
the transform the action. Passing in the transforms to a grammar woul
On 05/10/10 08:51, Thomas Heller wrote:
Having that said, just having "plain" evaluation of phoenix expressions
seemed to me that it is wasting of what could become possible with the power
of proto. I want to do more with phoenix expressions, let me remind you that
phoenix is "C++ in C++" and wit
On 04/10/10 20:45, Eric Niebler wrote:
I'm not opposed to such a thing being in Proto, but I (personally) don't
feel a strong need. I'd be more willing if I saw a more strongly
motivating example. I believe Joel Falcou invented something similar.
Joel, what was your use sce
On 16/08/10 23:46, Daniel Oberhoff wrote:
ha, its alive :)
Getting it out is my main priority for 2010.
did you get my query as to wether it will be possible to get sse acceleration
without having to specify it in the type or having sizes be divisible by four
(or even satisfying alignment
On 16/08/10 23:30, Daniel Oberhoff wrote:
I am still dreaming of a numeric library with a blitz like interface that
dispatches automatically (with both static and dynamic dispatch as appropriate)
to serial, sse, openmp-style, and cuda code.
Follow http://github.com/jfalcou/nt2 in the up
Got some error trying to compile this vs boost :: trunk
j...@dell-desktop:~/Desktop$ time g++-4.3 -O3 -c options.cpp -I./
-I/usr/local/include/boost-trunk
options.cpp: In member function ‘typename
boost::option_expr::result
()(Option, Default)>::type boost::option_expr::operator()(const
Optio
On 15/08/10 23:21, Eric Niebler wrote:
Haha! I admit I was a bit suspicious at first. Nobody ever said, "Wow,
Proto sped up my compiles!" ;-)
I wish :)
But looking at Joel's implementation, I suspect it can be sped up
considerably by avoiding fusion vectors and maps. (I've found fusion to
On 15/08/10 20:21, Daniel Wallin wrote:
So you implemented something significantly slower (3 times on machine
with gcc4.3). Not very surprising; adding complex abstraction in the
implementation rarely makes things faster.
As I said, it's more of an exercice than anything else.
_
Code is now uplaoded to some GIT repo:
http://github.com/jfalcou/boosties/
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
On 15/08/10 17:46, Tim Moore wrote:
Nice. I've been meaning to start using Boost.Parameter in one of my
projects but I definitely like this syntax better. I'll probably
start using this soon (like this week).
Please post if you make updates.
Thanks for the interest.It's still in its infanc
So, Thomas and I felt bored or some suhc this afternoon. Incidentally, I
needed to use Boost::Parameters
in NT² but found the compile time to be somehow slow. So in a flash of
defiance, we went to reimplementing
a subset of parameters using proto. The syntax is ratehr different but
the effect is
> This is kind of like Proto's evaluation contexts, IIUC. I'm not wild for
> them because often just the tag isn't enough information to find the
> right handler. But maybe it covers enough use cases and can be made
> easier to use. Right now, proto has an "eval" function that takes an
> expression
On 11/08/10 17:52, Eric Niebler wrote:
I don't exactly recall the details of Joel's technique. My experiments
to separate transforms from grammars were largely unsuccessful because
control flow often need pattern matching. I'd like to see alternate designs.
Mine was just a post-order traversa
On 11/08/10 09:53, Thomas Heller wrote:
Joel Falcou showed a technique which, to
some extend is able to deal with the no-repetition part.
Fact is that I just play on the fact Transform X can be applied one
xpression buitl on Grammar Z, Z and X being unrelated.
We use that quite a lot in
> Good. Now if you are saying that Proto's existing transforms are too
> low-level and that things like pre- and post-order traversals should be
> first class Proto citizens ... no argument. Patch? :-
Yup exactly as soon as i haver a real kboard
___
pr
ly know what
> you guys are after.
>
>> On Aug 10, 2010, at 2:47 AM, joel falcou wrote:
>>> On 10/08/10 05:24, Gordon Woodhull wrote:
>>>>
>>>> I wonder if Dan Marsden's Traversal library would solve this out of
>>>> the box?
>>>
On 10/08/10 05:24, Gordon Woodhull wrote:
Sorry for the slow response - been on vacation offline.
No problem ;)
I wonder if Dan Marsden's Traversal library would solve this out of
the box?
http://boost-spirit.com/dl_docs/traversal/html/traversal/introduction.html
Oh nice link, I didn't knew
On 04/08/10 19:42, Eric Niebler wrote:
IIRC, you use some tricks to bring down compile times, right? I think
that would make a very good section for the docs, yes.
Basically:
- using make_expr instead of function objetc made CT linear instead of
quadratic
- swicth and other stuff to kee
On 04/08/10 01:00, Eric Niebler wrote:
Most folks here don't know this, but the version of Proto y'all are
using is actually v4. (Three times the charm wasn't true for Proto.)
Anyway, there are so many goodies coming in Boost 1.44 that think of it
as Proto v4.1.
I just posted the release notes f
On 27/07/10 15:56, Alp Mestanogullari wrote:
On Tue, Jul 27, 2010 at 3:25 PM, joel falcou wrote:
I do this in NT2 all the time IIRC I gave a link to some svn repo with an
example.
It wasn't selected as core phoenix 3 though :p
Yeah I remember discussing that code with you o
On 27/07/10 15:21, Alp Mestanogullari wrote:
Yeah definitely. They would just have to provide the node transform,
and you would just forward it to the tree traversal metafunction.
Quite straight for an extension mechanism!
I do this in NT2 all the time IIRC I gave a link to some svn repo wi
On 27/07/10 15:15, Christophe Henry wrote
I think you should talk to Gordon Woodhull. He's building a metagraph
(among others) library, which I am going to use in msm for
compile-time calculations and fsm analysis. This means there will be
temporarily a metagraph library inside msm as proof of co
On 27/07/10 15:08, Eric Niebler wrote:
That would be awesome, Joel!
WHat's the easiest in term of code ?
I can bring up some git repo or shoudl I work in some svn branches of
proto somewhere at boost ?
___
proto mailing list
proto@lists.boost.o
On 27/07/10 15:08, Eric Niebler wrote:
That would be awesome, Joel!
I'll count on you for helping me making those looking nice :p
What's the easiest ? getting a proto-tree branch or what ?
___
proto mailing list
proto@lists.boost.org
http://lists
what about having some Tree related trasnform/function/meta-function then ?
I'm often thinking : "dang, this transform is basically a BFS for a node
verifying meta-function foo<>"
and have to rewrite a BFS usign default_ and such, which is relatively easy.
Now, sometimes it is "dang, this code
1 - 100 of 113 matches
Mail list logo
