Eric Niebler wrote:
But that doesn't mean that more folks can't participate. If you ever
wanted to know how some part of proto worked, looked at the source code
and are now afraid you can't have children, ask here. If you wished for
a feature or hacked around some shortcoming of proto's, ask here
Eric Niebler wrote:
Thanks for the links. Some good bedtime reading for me. But obviously if
C++ is the host language, then a DSEL's syntax is necessarily
constrained to that of C++. That rules out nifty tricks like
meta-programming C++ in C++ a-la Lisp or Haskell. You can't make that
pig fly. Ma
OvermindDL1 wrote:
Proto already feels a lot like LISP, no doubt there is a lot to pull
from it. I have not made any Proto-based DSEL's yet, but no doubt I
could have a lot of input based on my LISP experience once I do..
It really does. Most of our proto DSL start their life as a ML or
Haskell
Eric Niebler wrote:
Joel, why write it in ML first?
Two reasons:
- ML is actually my first language so I can be quite productive with it.
C++ is just my second one ;)
- ML has a strong type checker than help you not writing erroneous
functions.
A classical thing is the match construct.
I'm pretty sure I understand this. I briefly looked into OCaml, so this
is familiar. Are the alternates tried in order or is there some notion
of "best match" like with template specialzations?
There is a funky algorithm to do this quite fast
If you "forgot" a case that make the function no
Eric Niebler wrote:
Is it that a vW evaluator is free to try *any* rule in the grammar in
place of the T? If so, that seems FAR too powerful to be useful. Indeed
the wikipedia entry says as much. Instead, it points to CDL
(http://en.wikipedia.org/wiki/Compiler_Description_Language) and affix
gram
On 23/07/10 17:32, Eric Niebler wrote
- Rewrite Phoenix3 expressions for parallel execution, or whatever
Note that it's exactly what I am doing atm after checkign out the P3 code :o
Other stuff it adds is the possibility of some JIT stuff from C++ like
expression.
For ppl who where at Boo
On 23/07/10 20:04, Eric Niebler wrote:
Awesome. I hope you give status updates on pr...@lists.boost.org. This
is important real-world usage, and the time for that is now while we
still have time to make changes and improvements based on your feedback
I'm still playing around, I have a lot of idea
These methods are aroudn since the Sh, the originator of RapidMind. They
build ASt at runtime and generate code that get JIT'ed.
Paul Kelly's DESOLA has some same techniques.
It's great for out-of-main CPU code geenration, I use somehtign simialr
for GPGPU code generation (except with proto as
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 bi
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 21:58, Eric Niebler wrote:
Blech! You can't even do at runtime the sorts of things proto lets you
do at compile time.
Yeah and even with this I have ahrd time convincing people in my article :o
Guess i'll have to get some hammer arguments :€
I once tried the RT approach, it was
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 re
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
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
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: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: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: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 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 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 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
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?
>>>
> 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
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
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
> 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
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
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
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 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.
_
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
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 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
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 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 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 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
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
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
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
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 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
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
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
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
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.
_
> 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
> 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:/
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
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 ove
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 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
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 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
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_if> dispatching, but now I see that
Dont. this incre
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
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
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.
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
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 has
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
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 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
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: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 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: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
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 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
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 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 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 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
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 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
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 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 do
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
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
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,
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 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
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 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 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 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
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
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 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 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
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
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
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 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
1 - 100 of 113 matches
Mail list logo
