On Wednesday 11 August 2010 00:45:44 Eric Niebler wrote:
On 8/10/2010 3:52
PM, Thomas Heller wrote:
On Tue, Aug 10, 2010 at 8:56 PM, Eric Niebler
wrote:
Good. Now if you are saying that Proto's existing transforms
are
too low-level and that things like pre- and post-order traversals
On Sunday 15 August 2010 18:16:07 Mathieu - wrote:
On 15 August 2010 17:46, Tim Moore t...@montecito-software.com 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
, Thomas Heller wrote:
snip
Solved the mistery. here is the code, explanation comes afterward:
snip
So, everything works as expected!
Thomas,
wow, this was driving me crazy, thanks for solving and explaining in all
the detail! :-)
I am still not sure if this isn't a conceptual problem
Eric Niebler wrote:
On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller
thom.heller-gM/ye1e23mwn+bqq9rb...@public.gmane.orgwrote:
snip
I'll also point out that this solution is FAR more verbose that the
original which duplicated part of the grammar. I also played with such
visitors
On Thursday 07 October 2010 23:06:24 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
On Wednesday 20 October 2010 15:02:01 Eric Niebler wrote:
On 10/14/2010 12:27 PM, Eric Niebler wrote:
snip
- A new set of actions can be created easily by delegating
to MyActions::action by default, and specializing only those
rules that need custom handling.
The code I sent
On Friday 22 October 2010 09:58:25 Eric Niebler wrote:
On 10/22/2010 12:33 AM, Thomas Heller wrote:
On Friday 22 October 2010 09:15:47 Eric Niebler wrote:
On 10/21/2010 7:09 PM, Joel de Guzman wrote:
Check out the doc I sent (Annex A). It's really, to my mind,
generic languages
On Friday 22 October 2010 11:29:07 Joel de Guzman wrote:
On 10/22/10 4:17 PM, Thomas Heller wrote:
On Friday 22 October 2010 09:58:25 Eric Niebler wrote:
On 10/22/2010 12:33 AM, Thomas Heller wrote:
On Friday 22 October 2010 09:15:47 Eric Niebler wrote:
On 10/21/2010 7:09 PM, Joel de
On Friday 22 October 2010 11:29:07 Joel de Guzman wrote:
On 10/22/10 4:17 PM, Thomas Heller wrote:
On Friday 22 October 2010 09:58:25 Eric Niebler wrote:
On 10/22/2010 12:33 AM, Thomas Heller wrote:
On Friday 22 October 2010 09:15:47 Eric Niebler wrote:
On 10/21/2010 7:09 PM, Joel de
@lists.boost.org
Reply-To: Discussions about Boost.Proto and DSEL design
proto@lists.boost.org
Subject: Re: [proto] Visitor Design Pattern
On 10/23/2010 5:36 AM, Eric Niebler wrote:
On 10/22/2010 10:45 AM, Eric Niebler wrote:
On 10/22/2010 10:01 AM, Thomas Heller wrote:
I think
On Sun, Oct 24, 2010 at 9:59 AM, Joel de Guzman
j...@boost-consulting.com wrote:
On 10/24/2010 1:16 PM, Eric Niebler wrote:
Now, what to call the traveral/algorithm/action/on thingy. None of those
feel right. Maybe if I describe in words what it does, someone can come
up with a good name.
Eric Niebler e...@... writes:
On 11/17/2010 2:18 PM, joel falcou wrote:
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
Eric Niebler wrote:
On 11/18/2010 3:31 PM, Eric Niebler wrote:
On 11/18/2010 1:45 PM, Thomas Heller wrote:
Eric Niebler e...@... writes:
It's REALLY hard. The let context needs to be bundled with the Expr,
State, or Data parameters somehow, but in a way that's transparent. I
don't actually
Eric Niebler wrote:
On 12/6/2010 4:50 PM, Thomas Heller wrote:
Eric Niebler wrote:
I played with the let transform idea over the weekend. It *may* be
possible to accomplish without the two problems I described above. See
the attached let transform (needs latest Proto trunk). I'm also
Eric Niebler wrote:
On 12/7/2010 3:13 PM, Thomas Heller wrote:
Eric Niebler wrote:
Now they do: T()(e,s,d). Inside T::impl, D had better be the type of d.
Nowhere does the _data transform appear in this code, so changing _data
to be smart about environments and scopes won't save you
Eric Niebler wrote:
On 12/7/2010 2:37 PM, Thomas Heller wrote:
Hi,
I have been trying to extend a domain by subdomaining it. The sole
purpose of this subdomain was to allow another type of terminal
expression.
Please see the attached code, which is a very simplified version of what
I
Eric Niebler wrote:
On 12/7/2010 2:37 PM, Thomas Heller wrote:
Hi,
I have been trying to extend a domain by subdomaining it. The sole
purpose of this subdomain was to allow another type of terminal
expression.
Please see the attached code, which is a very simplified version of what
I
Eric Niebler wrote:
On 12/8/2010 5:30 AM, Thomas Heller wrote:
Eric Niebler wrote:
On 12/7/2010 2:37 PM, Thomas Heller wrote:
So, How to handle that correctly?
Yup, that's a problem. I don't have an answer for you at the moment,
sorry.
I think i solved the problem. The testcase
Eric Niebler wrote:
On 12/8/2010 4:44 PM, Thomas Heller wrote:
I will try to present a patch. I urgently need this feature to be
become officially supported to use it for phoenix3 (a scope opened by let
or lambda should be it's own sub domains in order to allow local
variables, theses shall
Eric Niebler wrote:
On 12/8/2010 5:30 PM, Thomas Heller wrote:
I don't really now how to do it otherwise with the current design.
There is really only this part of the puzzle missing. If it is done, we
have a working and clean Phoenix V3.
For the time being, I can live with the workaround I
Eric Niebler wrote:
On 12/8/2010 5:30 PM, Thomas Heller wrote:
I don't really now how to do it otherwise with the current design.
There is really only this part of the puzzle missing. If it is done, we
have a working and clean Phoenix V3.
For the time being, I can live with the workaround
Eric Niebler wrote:
On 12/10/2010 3:23 AM, Thomas Heller wrote:
snip
However, the solution I am looking for is different.
The sub-domain i tried to define should also extend its super domain, BUT
expressions valid in this sub-domain should not be valid in the super
domain, only in the sub
Hi,
I recently run into an ICE by compiling phoenix3 with gcc-4.2. It seems this
particular can not handle proto::detail::poly_function_traits properly.
the problem is the default Switch template initialization ... by replacing
std::size_t Switch = sizeof(test_poly_functionFun(0,0)) by typename
Hi,
I just wanted you to know that phoenix3 is in a working state once again.
I refactored everything with the changes we discussed ...
All tests from boost.bind are passing!
Placeholder unification is in place!
Now ... up to documentation writing and checking for BLL compatibility ...
Regards,
Eric Niebler wrote:
On 12/27/2010 5:26 AM, Joel Falcou wrote:
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
Eric Niebler wrote:
On 12/28/2010 5:39 AM, Thomas Heller wrote:
I just saw that you added functional::at.
I was wondering about the rationale of your decision to make it a non
template.
My gut feeling would have been to have proto::functional::atN(seq)
and not proto::functional::at(seq, N
Eric Niebler wrote:
On 12/28/2010 11:43 AM, Thomas Heller wrote:
Eric Niebler wrote:
On 12/28/2010 5:39 AM, Thomas Heller wrote:
I just saw that you added functional::at.
I was wondering about the rationale of your decision to make it a non
template.
My gut feeling would have been
On Monday, March 14, 2011 01:39:41 PM Christophe Henry wrote:
Hi Thomas,
Row source_state , event , target_state, action , guard
I suggest you to look into spirit how semantic actions are dealt with, it
reminds me of exactly this:
Ok I will, thanks.
Keep in mind, spirit uses Phoenix
On Monday, March 14, 2011 10:12:09 PM Christophe Henry wrote:
Calling phoenix expressions from the statement module return void.
Calling phoenix expressions from any other modules return whatever ...
depending on the C++-Sense.
It's ok, I can live with it, though I'll need to find a way
On Wed, Mar 16, 2011 at 9:56 PM, Christophe Henry
christophe.j.he...@googlemail.com wrote:
Hi,
Sorry for the late reply ...
I have my eUML grammar, defing, for example a transition as:
SourceState+ Event [some_guard] == TargetState
I want to write for some_guard an expression of a phoenix
On Fri, Apr 8, 2011 at 2:03 PM, Karsten Ahnert
karsten.ahn...@ambrosys.de wrote:
Why not just write a transform that calculates one derivative and call
it N times to get the Nth derivative?
Yes, that may be easy if you need two or three higher derivatives. For my
application I need 10 to 20
On Monday, April 25, 2011 06:39:14 PM Christophe Henry wrote:
Hi Thomas,
Sorry to come back to the subject so late, I didn't manage before :(
If you want to use it as a transform you need the evaluator with an
appropriate action that does the desired transform... here is an
example:
On Thu, May 5, 2011 at 5:47 AM, Eric Niebler e...@boostpro.com wrote:
On 5/5/2011 2:27 AM, Bart Janssens wrote:
On Wed, May 4, 2011 at 7:55 PM, Eric Niebler
eric-xT6NqnoQrPdWk0Htik3J/w...@public.gmane.org wrote:
Bart, how high can N go in your EDSL? Is it really arbitrarily large?
I didn't
On Monday, May 09, 2011 11:18:50 PM Christophe Henry wrote:
Hi,
Thanks to Eric's latest changes (which removed conflicts between MSM
and phoenix), and Thomas' help, I added the possibility to use phoenix
as an action inside eUML.
There is still quite a bit to be done to be able to do with
Hi,
Today I experimented a little bit with phoenix and proto.
My goal was to decrease the compile time of phoenix. When I started the
development of phoenix, Eric advised me to use proto::basic_expr to reduce
compile times.
Which makes sense giving the argumentation that on instatiating the
On 07/10/2012 11:18 PM, Eric Niebler wrote:
I just committed to the proto-11 codebase a new transform called
_unpack. You use it like this:
_unpackf0(Tfx, f1(_)...)
Where Tfx represents any transform (primitive or otherwise) f0 is any
callable or object type, and f1(_) is an object or
36 matches
Mail list logo