[Spirit] qi::parse at translation unit global scope?

I noticed this when I played around with wrapping qi::parse() in a
parse() function that does some things before and after qi::parse().

My code had been calling qi::parse(), with the `qi::` namespace prefix,
everywhere so I removed from a few calls and compiled before adding a
parse() declaration.  Lo and behold, compilation unexpectedly succeeded.
I've reduced the behaviour in a minimalistic sample program (attached).

I expect their to be *no* parse() function within the scope of main().
Can anyone clarify why the compiler has no trouble finding one and which
one it finds?

Adding a global scope operator to the call, i.e. saying ::parse(), does
result in the expected compile error.

Using Boost 1.46.1, gcc 4.6.2 on Debian wheezy.

Thanks in advance,
--

-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Spirit] qi::parse at translation unit global scope?

On 1 February 2012 20:33, Olaf Meeuwissen <olaf.meeuwissen <at> avasys.jp> wrote:
> I noticed this when I played around with wrapping qi::parse() in a
> parse() function that does some things before and after qi::parse().
>
> My code had been calling qi::parse(), with the `qi::` namespace prefix,
> everywhere so I removed from a few calls and compiled before adding a
> parse() declaration.  Lo and behold, compilation unexpectedly succeeded.
> I've reduced the behaviour in a minimalistic sample program (attached).
>
> I expect their to be *no* parse() function within the scope of main().
> Can anyone clarify why the compiler has no trouble finding one and which
> one it finds?
>
> Adding a global scope operator to the call, i.e. saying ::parse(), does
> result in the expected compile error.
>
> Using Boost 1.46.1, gcc 4.6.2 on Debian wheezy.
>
> Thanks in advance,
> --
> Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
> FSF Associate Member #1962               Help support software freedom
>                 http://www.fsf.org/jf?referrer=1962
>
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

The compiler uses Argument Dependent Lookup (ADL) to determine which

Re: Boost.Regex: Iterate over named captures/groups

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: Boost.Regex: Iterate over named captures/groups

>My question was the following: Is there a way to get a list or whatever of
>named captures/groups?

No sorry, not even Boost.Regexes private methods provide that functionality.

If there's a convincing use case then I can add that support I guess, but I 
don't think this is something that even Perl provides?

Regards, John. 

Re: Boost.Regex: Iterate over named captures/groups

Hi John,

I don't know if perl provides it, but PCRE based regex engines does (like Python or PHP)

It would be great if such feature could be implemented and/or access functions could be made public.

For regex_replace as an example the user then knows which sub expression could be used.

Best Regards
NoRulez

Am 01.02.2012 um 13:13 schrieb John Maddock <boost.regex <at> virgin.net>:

>> My question was the following: Is there a way to get a list or whatever of
>> named captures/groups?
> 
> No sorry, not even Boost.Regexes private methods provide that functionality.
> 
> If there's a convincing use case then I can add that support I guess, but I don't think this is something that
even Perl provides?
> 
> Regards, John. 
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

multi_array and move semantics

Does multi_array support move semantics?

If not, are there any plans to add move semantics?

Helmut
--

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

boost::this_thread::sleep

Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec)

On solaris we are using prstat to monitor the process and lightweight process details.

Prstat allows one to see thread level detail by using the –Lm option (prstat -Lm -p pid)

In this case a variety of information is output per thread (see prstat reference link at bottom of e-mail):
for example system time (SYS), user time (USR), sleep time (SLP), and user lock time (LCK). 

The user lock time is time spent waiting by a thread for synchronization (protected) resources.

Interestingly all of our threads show up with a high-level of user lock time. Wanting to understand this I
spent time today isolating the user lock time to the call to boost::this_thread::sleep(1000).

When our thread did nothing but wake up and go back to sleep for 1000 milliseconds the thread would show up
with 100% LCK rather than 100% SLP.

As an experiment I replaced the single call to boost::this::thread::sleep(1000) with a comparable call
to nanosleep(). In this case the thread shows up as 100% SLP, rather than 100% LCK (and looks more like what I
would have expected).

Having read a bit more about the boost::this_thread::sleep I believe that this may be because the boost
sleep implementation actually uses a mutex (synchronization object) and hence the thread really is
waiting for a synchronization resource.

I’ve come to the conclusion that this “100 % locked” indicator for our threads is not necessarily
indicative of a problem, rather it is just an artifact of the boost::this_thread::sleep implementation.

I’m still a bit queasy about this and would like some confirmation from the experts. Is the fact that our
boost threads (when sleeping) show up as 100% locked rather than 100% sleeping a problem, or is it just an
artifact of the boost thread implementation? 

----------------------------------------------

As a point of reference pls see the following link, it talks to the LCK output of prstat.

http://www.scalingbits.com/performance/prstat

Please see the section labeled: prstat usage Scenario – Excessive Locking

Thanks in advance for any insights in this regard.
-
This message is intended only for the addressee and may contain information that is company confidential
or privileged.  Any technical data in this message may be exported only in accordance with the U.S.
International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration
Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you
are not the intended recipient, or the person responsible for delivering to the intended recipient, you
should not read, copy, disclose or otherwise use this message. If you have received this email in error,
please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: Boost::mpl vector product

On 01/30/12 09:32, Larry Evans wrote:
> On 01/23/12 02:03, Allan Nielsen wrote:
>> Cool thanks a lot
>>
>> Best regards
>> Allan W. Nielsen
>>
>> On Sun, Jan 22, 2012 at 7:41 PM, Larry Evans <cppljevans <at> suddenlink.net> wrote:
>>> On 01/22/12 12:03, Larry Evans wrote:
>>> [snip]
>>>> The attached code uses variadic templates and code from:
>>>>
>>>> http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/mpl/
>>>>
>>>> and does what you want except, instead of mpl::pair, it produces
>>>> an mpl::vector whose size is the number of mpl sequences
>>>> on input.
>>>>
>>> OOPS, forgot outer_product_pack, which is attached.
>>>
> You might also have a look at Abel Sinkovics metaprogramming library:
> 
> http://abel.web.elte.hu/mpllibs/metamonad/index.html
> 
> I, as yet, have no idea of how to do what you want with
> Abel's library; however, I'd guess it could be done.
> In particular, I know list comprehensions:
> 
>   http://www.haskell.org/haskellwiki/List_comprehension
> 
> ( which are, AFAICT, flattened outer products)
> can be done with monads which Abel's library supplies.
> 
> Maybe you could ask Abel how to do this with his
> library.  I'd be interested in seeing that.
> 
> HTH.
> 
> -Larry
In a private email to me, Abel said his metaprogramming library could
do this.  I've attached a copy of his email.  I don't know if you can
use it, but I just thought it was interesting and may give some other
ideas of how to solve your problem.

-regards,
Larry

From: Abel Sinkovics <abel <at> elte.hu>
Subject: Re: Template metaprogramming libraries
Date: 2012-01-31 20:14:11 GMT

Hi Larry,

> Hi Abel,
>
> I thought maybe you'd be interested in using your
> library to solve the problem mentioned in the
>
>    Boost::mpl vector product
>
> problem posed in this thread:
>
>    http://article.gmane.org/gmane.comp.lib.boost.user/72558
>
> I'd be curious to see if it can be done.
> I hope it can.

Yes, it can. List comprehension can be implemented using the do notation 
(http://www.haskell.org/tutorial/monads.html#sect9.2). Since Metamonad 
supports the do notation, you can solve the problem the following way:

using boost::mpl::pair;

using mpllibs::metamonad::list_tag;
using mpllibs::metamonad::do_;
using mpllibs::metamonad::set;
using mpllibs::metamonad::do_return;

struct l1;
struct l2;

typedef
   do_<list_tag>::apply<
     set<l1, v1>,
     set<l2, v2>,
     do_return<pair<l2, l1> >
 >::type
   result;

Note that the list monad uses mpl::transform internally which doesn't 
work with range_c, thus v2 has to be a sequence that is a copy of 
range_c<....> 
(http://www.boost.org/doc/libs/1_48_0/libs/mpl/doc/refmanual/range-c.html).

Regards,
   Abel

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: boost::this_thread::sleep

Le 01/02/12 12:07, Sargrad, Dave a écrit :
> Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec)
>

> <snip>
> Interestingly all of our threads show up with a high-level of user lock time. Wanting to understand this I
spent time today isolating the user lock time to the call to boost::this_thread::sleep(1000).
>
> When our thread did nothing but wake up and go back to sleep for 1000 milliseconds the thread would show up
with 100% LCK rather than 100% SLP.
>
> As an experiment I replaced the single call to boost::this::thread::sleep(1000) with a comparable call
to nanosleep(). In this case the thread shows up as 100% SLP, rather than 100% LCK (and looks more like what I
would have expected).
>
> Having read a bit more about the boost::this_thread::sleep I believe that this may be because the boost
sleep implementation actually uses a mutex (synchronization object) and hence the thread really is
waiting for a synchronization resource.
>
> I’ve come to the conclusion that this “100 % locked” indicator for our threads is not necessarily
indicative of a problem, rather it is just an artifact of the boost::this_thread::sleep implementation.
>
> I’m still a bit queasy about this and would like some confirmation from the experts. Is the fact that our
boost threads (when sleeping) show up as 100% locked rather than 100% sleeping a problem, or is it just an
artifact of the boost thread implementation?
Hi,

I agree that it will be better if this_thread::sleep uses platform 
specifics that show your program is sleeping.

I see however the code in libs/thread/src/pthread/thread.cpp

         void sleep(const system_time& st)

...
#   elif defined(BOOST_HAS_NANOSLEEP)
                     timespec ts;
                     to_timespec_duration(xt, ts);

                     //  nanosleep takes a timespec that is an offset, not
                     //  an absolute time.
                     nanosleep(&ts, 0);

which uses nanosleep when available. Could you check if 
BOOST_HAS_NANOSLEEP is defined on Solaris? Hint:Add an #error after the 
elif.

Best,
Vicente
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: mpi/serialization:

Here's a much, much reduced version (w/o fftw)!
Thanks!
On Jan 31, 2012, at 4:34 AM, Riccardo Murri wrote:

> Hello,
> 
> On Tue, Jan 31, 2012 at 03:30, Jacques C. Richard <richard <at> tamu.edu> wrote:
>> terminate called after throwing an instance of
>> 'boost::archive::archive_exception'
>>   what():  array size too short
>> 
>> What does this error mean? The message was too small or std::vector size was
>> not big enough?
> 
> It's hard to say withour seeing any code.
> 
> Can you please post a minimal example that produces the error?
> 
> Best regards,
> Riccardo

Dr. Jacques C. Richard
NSF Research Experiences for Undergraduates (REU) Sites
Sr. Lecturer/Research Associate, Aerospace Engineering Dept.
Texas A & M University, College Station, TX 77843-3141
richard <at> tamu.edu 979-845-3916 (fax 6051) http://aeweb.tamu.edu/Richard/

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users