[Boost-users] Newbie Jamfile author question

From: Drumheller, Michael (michael.drumheller_at_[hidden])
Date: 2006-09-13 19:03:30

(Thank you to Rene and David.)
Rene,
Are you referring to the parsing phase?   Such behavior would not seem
so harmful there (to me anyway).  But if I add some actions, they get
done twice, which does seem very harmful.  I mean, it's like the
updating phase gets done twice, not just the parsing.  Here is another
example Jamfile:
------------------------ begin Jamfile--------------------------
   rule MyRule
   {
      Echo $(1) ; 
      MyAction $(1) ; 
      Depends all : $(1) ;
   }
   actions MyAction 
   {
      touch $(1) ;
      echo $(1) andAgain ;
   }
   MyRule HelloAgain ;
------------------------ end Jamfile--------------------------
Here is the output:
------------------------ begin output--------------------------
   c:/deleteme=> bjam
   HelloAgain
   HelloAgain
   ...found 9 targets...
   ...updating 1 target...
   MyAction HelloAgain
   HelloAgain andAgain ;
   MyAction HelloAgain
   HelloAgain andAgain ;
   ...updated 1 target...
------------------------ end Jamfile--------------------------
If the (lowercase) echo in MyAction had been a compilation, then I would
have compiled all my files twice.  (In fact, that is just the situation
that led me construct this simple example.)  Does bjam's behavior still
seem OK to you?
(I realize that bjam is used all the time by a zillion people--there
must be somethng I'm doing wrong, or something I'm just not
understanding--I'm sorry to be taking everyone's time with this.)

Thanks again,
Mike D.

>>> -----Original Message-----
>>> From: boost-users-request_at_[hidden] 
>>> [mailto:boost-users-request_at_[hidden]] 
>>> Sent: Wednesday, September 13, 2006 3:37 PM
>>> To: boost-users_at_[hidden]
>>> Subject: Boost-users Digest, Vol 1026, Issue 7
>>> 
>>> Send Boost-users mailing list submissions to
>>> 	boost-users_at_[hidden]
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> 	http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>> or, via email, send a message with subject or body 'help' to
>>> 	boost-users-request_at_[hidden]
>>> 
>>> You can reach the person managing the list at
>>> 	boost-users-owner_at_[hidden]
>>> 
>>> When replying, please edit your Subject line so it is more 
>>> specific than "Re: Contents of Boost-users digest..."
>>> 
>>> 
>>> Today's Topics:
>>> 
>>>    1. Re: bind, and member function with a parameter 
>>> (Arkadiy Vertleyb)
>>>    2. multi_index library, dynamic number of indices ( Ad?n 
>>> Cosgaya )
>>>    3. Re: Newbie Jamfile author question (David Klein)
>>>    4. Re: bind, and member function with a parameter
>>>       (Alexander Shyrokov)
>>>    5. Re: Newbie Jamfile author question (Rene Rivera)
>>>    6. mingw,	bjam and Boost.Python tutorial problem 
>>> (Import Error)
>>>       (Sune Mai)
>>>    7. Re: multi_index library, dynamic number of indices
>>>       (JOAQUIN LOPEZ MU?Z)
>>>    8. Re: Library Interface Design (Jens Theisen)
>>> 
>>> 
>>> ------------------------------------------------------------
>>> ----------
>>> 
>>> Message: 1
>>> Date: Wed, 13 Sep 2006 15:55:46 -0400
>>> From: "Arkadiy Vertleyb" <vertleyb_at_[hidden]>
>>> Subject: Re: [Boost-users] bind, and member function with a 
>>> parameter
>>> To: boost-users_at_[hidden]
>>> Message-ID: <ee9nob$v44$1_at_[hidden]>
>>> 
>>> "Peter Dimov" <pdimov_at_[hidden]> wrote
>>> 
>>> >> Just an idea -- is it possible to have one universal set of 
>>> >> placeholders in boost?  Bind, Lambda, MPL, and possibly other 
>>> >> libraries could then use some sort of redirection to their 
>>> >> specialized placeholders...  Might help to avoid some confusion.
>>> >
>>> > This isn't possible in general
>>> 
>>> Not sure I understand why...
>>> 
>>> AFAIU, placeholders are either types (MPL), in which case 
>>> some sort of traits can be used to redirect from, say, 
>>> boost::_1 to mpl::_1, or const objects (Bind, Lambda), in 
>>> which case some extra indirection through overload could 
>>> possibly do the trick something like:
>>> 
>>> template<class T> T redirect(const T&);
>>> template<int n> bind::arg<n> redirect(const boost::arg<n>&);
>>> 
>>> Regards,
>>> Arkadiy
>>> 
>>>  
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 2
>>> Date: Wed, 13 Sep 2006 17:37:44 -0300
>>> From: " Ad?n Cosgaya " <acosgaya_at_[hidden]>
>>> Subject: [Boost-users] multi_index library, dynamic number 
>>> of indices
>>> To: boost-users_at_[hidden]
>>> Message-ID:
>>> 	<df7e9fd90609131337u7844f495i1e857c265cb673b1_at_[hidden]>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>> 
>>> Hi, I am using multi_index to keep a set of d-dimensional 
>>> points, where each point is a vector inside the multi_index 
>>> container.
>>> e.g (3,5,8,9,5) is a 5-dimensional point (but this can vary 
>>> and be 3-d, 7-d, etc..). I need to have the set sorted by 
>>> each of the dimensions.
>>> 
>>> I can do it statically if I know in advance how many 
>>> dimensions I have, but I don't know how to make dynamic to 
>>> any number of dimensions.
>>> 
>>> I currently have:
>>> 
>>>  template<int N>
>>>  struct nth_coordinate
>>>  {
>>>    typedef int result_type;
>>> 
>>>    int operator()(const vector<int>& x)const
>>>    {
>>>      return x[N];
>>>    }
>>>  };
>>> 
>>>  typedef multi_index_container<
>>>    vector<int>,
>>>    indexed_by<
>>>      sequenced<>,
>>>      ordered_non_unique<nth_coordinate<0> >,
>>>      ordered_non_unique<nth_coordinate<1> >,
>>>      ordered_non_unique<nth_coordinate<2> >,
>>>      ordered_non_unique<nth_coordinate<3> >,
>>>      ordered_non_unique<nth_coordinate<4> >
>>>    >
>>>  > multi_index_Points;
>>> 
>>> is it possible do it without explicitly saying how many 
>>> indices do I need?
>>> 
>>> Also, I am trying to create a function which receives as a 
>>> parameter the dimension I want to work with, but it seems 
>>> that I need to explicitly say the number of the index in 
>>> nth_index (it obviously needs a constant). For
>>> example:
>>> 
>>> int median (int d){
>>>  ...
>>>     typedef multi_index_Points::nth_index< d >::type
>>> multi_index_Points_it;    ===> I would like to pass "d" as 
>>> a parameter
>>>    ...
>>> }
>>> 
>>> is there any workaround for this issues?
>>> 
>>> would you mind pointing me in the right direction with an 
>>> example of how to do it with thelibrary?
>>> 
>>> thanks in advance...
>>> 
>>> Adan
>>> -------------- next part --------------
>>> HTML attachment scrubbed and removed
>>> 
>>> ------------------------------
>>> 
>>> Message: 3
>>> Date: Wed, 13 Sep 2006 22:30:56 +0200
>>> From: David Klein <dave_chp_at_[hidden]>
>>> Subject: Re: [Boost-users] Newbie Jamfile author question
>>> To: boost-users_at_[hidden]
>>> Message-ID: <45086A80.7030308_at_[hidden]>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> 
>>> Drumheller, Michael wrote:
>>> > Hello:
>>> >
>>> > I am trying to write some Jamfiles and I am finding that 
>>> bjam tends to 
>>> > run my rules twice.
>>> >   
>>> hi michael,
>>> 
>>> just a guess but maybe this is,
>>> because a debug + release version is built?
>>> 
>>> --
>>> dave
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 4
>>> Date: Wed, 13 Sep 2006 16:52:20 -0400
>>> From: Alexander Shyrokov <shirokov_at_[hidden]>
>>> Subject: Re: [Boost-users] bind, and member function with a 
>>> parameter
>>> To: boost-users_at_[hidden]
>>> Message-ID: <45086F84.7080508_at_[hidden]>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> 
>>> Thanks! That solved the problem. Thanks a lot.
>>> 
>>> Peter Dimov wrote:
>>> 
>>> >> #include <vector>
>>> >> #include <algorithm>
>>> >> #include <boost/bind.hpp>
>>> >>
>>> >> int main(int argc, char **argv)
>>> >> {
>>> >> typedef std::vector<std::vector<bool> > T2Dimensional; 
>>> T2Dimensional 
>>> >> vec;
>>> >> std::for_each(vec.begin(),vec.end()
>>> >> ,boost::bind(&std::vector<bool>::resize,_1,10));
>>> >> return 0;
>>> >> }
>>> > 
>>> > Your code is fine, sort of. The problem is that 
>>> vector<>::resize takes 
>>> > two arguments. The second one has a default, but this 
>>> information is 
>>> > lost when the pointer to member 
>>> &std::vector<bool>::resize is taken. 
>>> > So you have to pass a value for it.
>>> > 
>>> >     std::for_each(vec.begin(),vec.end()
>>> >         ,boost::bind( &std::vector<bool>::resize, _1, 10, 
>>> false ) );
>>> --
>>> Regards,
>>>      Alexander.                http://sjcomp.com
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 5
>>> Date: Wed, 13 Sep 2006 15:57:08 -0500
>>> From: Rene Rivera <grafikrobot_at_[hidden]>
>>> Subject: Re: [Boost-users] Newbie Jamfile author question
>>> To: boost-users_at_[hidden]
>>> Message-ID: <450870A4.6000203_at_[hidden]>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> 
>>> Drumheller, Michael wrote:
>>> > Hello:
>>> > 
>>> > I am trying to write some Jamfiles and I am finding that 
>>> bjam tends to
>>> > run my rules twice.
>>> > Here is a tiny demo (using Boost 1.31.1 on Windows XP, 
>>> with zsh/cygwin,
>>> > bjam version
>>> > "3.1.13. OS=NT".).
>>> > 
>>> > % export BOOST_ROOT=c:/boost_1_33_1; cd c:/; rm -rf 
>>> deleteme; mkdir
>>> > deleteme; cd deleteme; echo 'Echo Hello Twice ;' > Jamfile; bjam
>>> > Hello Twice
>>> > Hello Twice
>>> > ...found 8 targets...
>>> > 
>>> > (Note:  If the first statement is "export BOOST_ROOT=;" 
>>> instead, I get
>>> > the error "Unable to
>>> > load Boost.Build: could not find 
>>> "boost-build.jam...Attempted search
>>> > from c:\deleteme up to
>>> > the root...etc.") 
>>> > 
>>> > Notice the double-execution. 
>>> 
>>> > Can anyone reproduce and/or explain this?
>>> 
>>> Yes, that's per design of the build system (v1 only). It 
>>> uses the first 
>>> pass to declare all the targets, and the second pass to 
>>> define them and 
>>> hence to possible refer to other declared targets.
>>> 
>>> 
>>> -- 
>>> -- Grafik - Don't Assume Anything
>>> -- Redshift Software, Inc. - http://redshift-software.com
>>> -- rrivera/acm.org - grafik/redshift-software.com
>>> -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 6
>>> Date: Wed, 13 Sep 2006 21:09:58 +0000
>>> From: "Sune Mai" <sunemai_at_[hidden]>
>>> Subject: [Boost-users] mingw,	bjam and Boost.Python 
>>> tutorial problem
>>> 	(Import Error)
>>> To: boost-users_at_[hidden]
>>> Message-ID: <BAY109-F15D5210B10D37A2C2F216FA7280_at_phx.gbl>
>>> Content-Type: text/plain; format=flowed
>>> 
>>> Hi,
>>> 
>>> I have a problem exactly similar to what is described in 
>>> great detail in an 
>>> earlier post to this list (with the same title):
>>> 
>>> http://lists.boost.org/boost-users/2006/02/17367.php
>>> 
>>> Unfortunatly, the thread ends without a solution...
>>> 
>>> Just as in the above post, the dll "hello.pyd" built with 
>>> bjam (following 
>>> the Boost.Python tutorial) doesn't export inithello. A 
>>> manual build does, 
>>> and the resulting "hello.pyd" works fine when imported into python.
>>> 
>>> One observation that might help pinpoint the problem is 
>>> that the sizes of 
>>> "hello.obj" and "hello.pyd", generated by the bjam build, are very 
>>> different:
>>> hello.obj: 766 kB
>>> hello.pyd:  13 kB
>>> 
>>> In the manual build they are both large (~800 kB).
>>> 
>>> If any further info is needed please tell me, and I'll see 
>>> what I can do - 
>>> but please be very specific, since I'm an absolute newbie 
>>> in the world of 
>>> boost, and not a very experienced  programmer in general either.
>>> 
>>> Regards
>>> \Sune Mai
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 7
>>> Date: Wed, 13 Sep 2006 23:59:55 +0200
>>> From: JOAQUIN LOPEZ MU?Z <joaquin_at_[hidden]>
>>> Subject: Re: [Boost-users] multi_index library, dynamic number of
>>> 	indices
>>> To: boost-users_at_[hidden]
>>> Message-ID: <2b076c2afda6.2afda62b076c_at_[hidden]>
>>> Content-Type: text/plain; charset=iso-8859-1
>>> 
>>> Ad?n Cosgaya ha escrito:
>>> > Hi, I am using multi_index to keep a set of d-dimensional
>>> > points, where each point is a vector inside the multi_index
>>> > container. e.g (3,5,8,9,5) is a 5-dimensional point (but
>>> > this can vary and be 3-d, 7-d, etc..). I need to have the
>>> > set sorted by each of the dimensions.
>>> > 
>>> > I can do it statically if I know in advance how many
>>> > dimensions I have, but I don't know how to make dynamic to
>>> > any number of dimensions. 
>>> > 
>>> > I currently have:
>>> > 
>>> >  template<int N>
>>> >  struct nth_coordinate
>>> >  {
>>> >    typedef int result_type;
>>> > 
>>> >    int operator()(const vector<int>& x)const
>>> >    {
>>> >      return x[N]; 
>>> >    }
>>> >  };
>>> > 
>>> >  typedef multi_index_container<
>>> >    vector<int>,
>>> >    indexed_by<
>>> >      sequenced<>,
>>> >      ordered_non_unique<nth_coordinate<0> >,
>>> >      ordered_non_unique<nth_coordinate<1> >, 
>>> >      ordered_non_unique<nth_coordinate<2> >,
>>> >      ordered_non_unique<nth_coordinate<3> >,
>>> >      ordered_non_unique<nth_coordinate<4> >
>>> >    >
>>> >  > multi_index_Points;
>>> > 
>>> > is it possible do it without explicitly saying how many
>>> > indices do I need?
>>> 
>>> Well, the short answer is no, you can't: multi_index_container
>>> is a compile-time construct, you cannot delay the specification
>>> to run time. That said, you can sort of have a kind of
>>> rudimentary dynamicity if you know the maximum number of
>>> coordinates and don't mind wasting memory and cpu cycles
>>> for those cases where the number of coordinates is less:
>>> rewrite nth_coordinate so as to not incur out of bounds
>>> accesses:
>>> 
>>>  template<int N>
>>>  struct nth_coordinate
>>>  {
>>>    typedef int result_type;
>>> 
>>>    int operator()(const vector<int>& x)const
>>>    {
>>>      if(x.size()>N)return x[N];
>>>      else          return 0; 
>>>    }
>>>  };
>>> 
>>> and add as many indices to multi_index_Points as the
>>> maximum number of coordinates you know you're going
>>> to handle.
>>>  
>>> > Also, I am trying to create a function which receives as a
>>> > parameter the dimension I want to work with, but it seems that
>>> > I need to explicitly say the number of the index in nth_index
>>> > (it obviously needs a constant). For example: 
>>> > 
>>> > int median (int d){
>>> >  ...
>>> >     typedef multi_index_Points::nth_index< d >::type 
>>> multi_index_Points_it;    ===> I would like to pass "d" as 
>>> a parameter 
>>> >    ...
>>> > }
>>> > 
>>> > is there any workaround for this issues? 
>>> 
>>> Well, you're experiencing a typical clash between compile-time
>>> (or static) and run-time (or dynamic) polymorphisn. In the
>>> particular case of your median function, what you propose cannot
>>> work as is because multi_index_Points_it would be of a *different*
>>> type for each d!
>>> There are some techniques to bridge the static and dynamic
>>> worlds, all of them involving some sort of "type erasure", i.e.
>>> absorbing several different types into one polymorphic proxy
>>> type. The following is a possible realization of a dynamic
>>> median facility:
>>> 
>>> class compile_time_median_table
>>> {
>>> private:
>>>   template<int D>
>>>   static int compile_time_median()
>>>   {
>>>     typedef typename multi_index_Points::
>>>       nth_index<D>::type multi_index_Points_it;
>>>     ...
>>>   }
>>> 
>>>   std::map<int,int (*)()> m;
>>> 
>>> public:
>>>   compile_time_median_table()
>>>   {
>>>     m[0]=compile_time_median<0>;
>>>     ...
>>>     m[6]=compile_time_median<6>;
>>>   }
>>> 
>>>   int operator()(int d)
>>>   {
>>>     return m[d]();
>>>   }
>>> };
>>> 
>>> int median(int d)
>>> {
>>>   static compile_time_median_table t;
>>>   return t(d);
>>> }
>>> 
>>> Here, we perform the type erasure by storing a pointer
>>> to every different instantiation of compile_time_median<D>
>>> and using those within a proxy function int median(int)
>>> which provides the illusion of runtime polymorphism.
>>> Maybe this sort of approach does suit your needs.
>>> 
>>> Best regards,
>>> 
>>> Joaqu?n M L?pez Mu?oz
>>> Telef?nica, Investigaci?n y Desarrollo
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 8
>>> Date: 13 Sep 2006 19:55:29 +0100
>>> From: Jens Theisen <jth02_at_[hidden]>
>>> Subject: Re: [Boost-users] Library Interface Design
>>> To: boost-users_at_[hidden]
>>> Message-ID: <87venrwq8u.fsf_at_[hidden]>
>>> Content-Type: text/plain; charset=us-ascii
>>> 
>>> Joel de Guzman <joel_at_[hidden]> writes:
>>> 
>>> > One-phase construction definitely!
>>> 
>>> I'd like to ask you a question about your parser framework that is
>>> related to this. I probably get most of the following 
>>> wrong, so please
>>> be patient.
>>> 
>>> More often than not, a parser constructs objects in a hierarchical
>>> manner that reflects the grammar:
>>> 
>>> print(a + b);
>>> 
>>> might be expressed as
>>> 
>>> statement(plus_expression(symbol("a"), symbol("b")))
>>> 
>>> in some language. The latter objects are better be designed without
>>> default constructors, in order to guarantee that we never 
>>> end up with,
>>> say, a meaningless symbol() or plus_expression().
>>> 
>>> When I write a parser by hand, that's straight forward:
>>> 
>>> boost::optional< plus_expression >
>>> parse_plus_expression(input_tokens tokens)
>>> {
>>>   ...
>>> }
>>> 
>>> The function will return boost::none if the expression 
>>> can't be parsed
>>> and no default plus_expressions will be necessary.
>>> 
>>> With spirit, there appear to be two approaches:
>>> 
>>> 1) semantic actions, which store away the parsed expression 
>>> in some way
>>> 
>>> and
>>> 
>>> 2) closures, which implicitly "return" their first member (member1).
>>> 
>>> I don't like 1 for most purposes, because it's too imperative for my
>>> taste. I need to keep track of what my actions did and, if something
>>> fails to parse at a point and backtracking occurs, need to manually
>>> revert the changes. This seems error prone to me.
>>> 
>>> 2 looks better, but, and this is the connection to the OP, 
>>> it appears
>>> that the returned value, as all closure members, must be default
>>> constructible. In particular, I risk returning such default
>>> constructed values when I failed to assign to them.
>>> 
>>> It's very likely that I missed something, as I didn't 
>>> seriously tried
>>> using spirit. Can you shed some light on this?
>>> 
>>> Jens
>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> _______________________________________________
>>> Boost-users mailing list
>>> Boost-users_at_[hidden]
>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>> 
>>> End of Boost-users Digest, Vol 1026, Issue 7
>>> ********************************************
>>>