On 26/07/10 21:36, Manjunath Kudlur wrote:
If you have to do heavy-weight things like optimizing the generated
AST, you got to anyway do it at runtime. You can still inspect the
code, transform it, etc at runtime. (Note : I am not trying to defend
the runtime retained execution model. I am a big
On 26/07/10 21:52, Eric Niebler wrote:
I confess I'm having a hard time seeing how the code posted in
Manjunath's original email could result in something that can be
introspected at runtime. Does it generate byte code? A runtime
polymorphic AST? And the JIT ... does it actually generate machine
On 26/07/10 22:12, Eric Niebler wrote:
Convincing people of what in your article?
That C++ EDSL are good thanks to templae meta-programming in general
That compile-time introspection is a Good Thing?
Among other
What are the complaints you hear most often?
It's C++ ?!?
Why not making a real
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
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
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
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
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 and
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_exprExpr::resultconst boost::option_exprExpr
()(Option, Default)::type
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.
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
On 26/10/10 19:44, Eric Niebler wrote:
struct my_actions_with_state
{
// specializations to look up transforms
// using rules:
templatetypename Rule
struct when;
// any ol' state can go here:
int my_state;
};
Now, you can pass an instance of my_actions_with_state
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 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
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
whenpattern,rule that can be extended from the outside, something
like a proto::switch_ but with patterns instead of tag ?
No. The best you can do
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
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 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_ifmatchGrammar dispatching, but now I see that
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 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 Generator parameter
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
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
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;
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.
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
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
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, transform
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 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 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
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*
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
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
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
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
On 30/12/2011 17:34, Bart Janssens wrote:
On Fri, Dec 30, 2011 at 7:01 AM, Eric
Nieblereric-xT6NqnoQrPdWk0Htik3J/w...@public.gmane.org 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
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
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
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
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.
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
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
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
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
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
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
46 matches
Mail list logo
