Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: Fwd: GSoC 2016 (Hartmut Kaiser)
2. Re: Fwd: GSoC 2016 (Ankit Aggarwal)
----------------------------------------------------------------------
Message: 1
Date: Sat, 19 Mar 2016 09:09:25 -0500
From: "Hartmut Kaiser" <[email protected]>
Subject: Re: [hpx-devel] Fwd: GSoC 2016
To: "'Ankit Aggarwal'" <[email protected]>,
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ankit,
> I was going through the Resumable Functions and I was not able to
> understand a difference between the stack-less coroutine and Resumable
> functions. Does both share the same meaning or is there any difference
> among them?
Both flavors of coroutines are what the name implies - coroutines. The main
semantic difference would be that stack-full coroutines can suspend their
execution at any level of the call stack, while stack-less coroutines can
suspend only on the uppermost level of the call stack (and only if the compiler
moves all local variables off the stack).
> Also,I was able to find the blog
> <http://meetingcpp.com/index.php/br/items/resumable-functions-async-and-
> await.html> where Thomas Heller(One of the mentor of HPX) has implemented
> the resumable functions in HPX,So is the further development needed to be
> done following the same principle of implementation or some other solution
> is required?
The solution to resumable functions we have is not generic and requires user
intervention. For instance, let's look at fibonacci (yes, yes, it's a dumb
example):
// using our dataflow construct
hpx::future<int> fibonacci(int n)
{
if (n < 2) return hpx::make_ready_future(n);
if (n < threshold) return hpx::make_ready_future(fibonacci_serial(n));
hpx::future<int> lhs_future = hpx::async(&fibonacci, n-1);
hpx::future<int> rhs_future = fibonacci(n-2);
return
hpx::dataflow(
hpx::util::unwrapped(
[](int lhs, int rhs)
{
return lhs + rhs;
})
, std::move(lhs_future), std::move(rhs_future)
);
}
// using what's proposed for resumable functions:
hpx::future<int> fibonacci(int n)
{
if (n < 2) coreturn hpx::make_ready_future(n);
if (n < threshold) coreturn hpx::make_ready_future(fibonacci_serial(n));
hpx::future<int> lhs_future = hpx::async(&fibonacci, n-1);
hpx::future<int> rhs_future = fibonacci(n-2);
coreturn await lhs_future + await rhs_future;
}
Both are 100% semantically equivalent, the second however requires compiler
support (await/coreturn).
> And most important what is needed to be present in the proposal for this
> project?
Here is a template of what you should base your proposal on:
https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
> Ankit Aggarwal
>
> On Thu, Mar 17, 2016 at 10:33 PM, Ankit Aggarwal
> <[email protected]> wrote:
> Sorry I was not able as soon as possible for the above discussion
> Yes,I will definitely want to work for this project.
> I will have the look at how "Resumable functions" work and what are the
> process required for there declaration.
>
> One major obstacle for me will how to extend the gcc or clang for this
> which I think, i can cover during April before coding begins (maybe
> earlier).
> "Ahh yes. This would also be a step in the direction of static dataflow
> graphs (build once, use often). This is also something supported by the
> resumable functions stuff, which allows to abstract Generators in a
> similar
> way as it abstracts Waitables."
> Can you please give me more insights on the above statement?
> Ankit Aggarwal
>
>
>
> On Thu, Mar 17, 2016 at 7:07 PM, Hartmut Kaiser <[email protected]>
> wrote:
> > > Uhh, I thought we can do that already (I may misunderstand what you
> > mean,
> > > however). Our suspension scheme relies on calling a function 'more
> than
> > > once'.
> >
> > Sure, but we only ever "return" once. the idea goes something like this:
> >
> >
> > void generate(generator<std::size_t> & yield, std::size_t n)
> > {
> > for(std::size_t i = 0; i != n; ++n)
> > {
> > yield(i * i);
> > }
> > yield.return();
> > }
> >
> > void consumer()
> > {
> > generator<std::size_t> yield;
> > hpx::future<std::size_t> f = yield.get_future();
> > while(f.valid())
> > {
> > std::cout << "got " << f.get() << '\n';
> > f = yield.get_future();
> > }
> > }
>
> Ahh yes. This would also be a step in the direction of static dataflow
> graphs (build once, use often). This is also something supported by the
> resumable functions stuff, which allows to abstract Generators in a
> similar
> way as it abstracts Waitables.
>
> This would indeed be a nice GSoC project!
>
> Aggrawal - would you be up to it?
>
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> > >> Hope that helps!
> > >>
> > >> Cheers,
> > >> Thomas
> > >>
> > >>>
> > >>> Ankit Aggarwal
> > >>>
> > >>> On Mon, Mar 14, 2016 at 11:02 PM, Hartmut Kaiser
> > >>> <[email protected] <mailto:[email protected]>> wrote:
> > >>>
> > >>> Ankit,
> > >>>
> > >>> > I was attached some of the links i was going through to
> > understand
> > >> the
> > >>> > plug-in mechanism in the C++
> > >>> >
> > >>> > <http://www.open-
> > >> std.org/jtc1/sc22/wg21/docs/papers/2006/n2015.pdf>
> > >>> > <http://www.drdobbs.com/cpp/building-your-own-plugin-
> framework-
> > >>> > part/204202899?pgno=1>
> > >>> >
> > >>> > To my understanding, what have been done till now is that
> third-
> > >> party
> > >>> > developer is able to write their own scheduler using the
> > scheduler
> > >> base
> > >>> > class and further work required is to develop the plug-in
> > manager
> > >> that
> > >>> > will manage the life system of the plug-in and expose the
> plug-
> > in
> > >> to core
> > >>> > library.
> > >>> >
> > >>> > Please correct me if I am wrong in understanding the project
> > >>> >
> > >>> > > "What's missing? We miss the dynamic discovery and loading
> > >> aspect. This
> > >>> > > however has been implemented for (dynamic) component already
> > >> from where it
> > >>> > > could be adapted and reused. Some refactoring of the
> existing
> > >> schedulers
> > >>> > > might be in order as well."
> > >>> >
> > >>> > I was not able to understand the term "component" in the above
> > >>> > statement.Does components refer to something other than plug-
> in?
> > >>>
> > >>> Yes,. In HPX dynamic components are a special type of plugins.
> > >>>
> > >>> Sorry for being insufficiently concise here.
> > >>> Regards Hartmut
> > >>> ---------------
> > >>> http://boost-spirit.com
> > >>> http://stellar.cct.lsu.edu
> > >>>
> > >>> >
> > >>> > Ankit Aggarwal
> > >>> >
> > >>> > On Sat, Mar 12, 2016 at 8:01 PM, Hartmut Kaiser
> > >> <[email protected] <mailto:[email protected]>>
> > >>> > wrote:
> > >>> > Ankit,
> > >>> >
> > >>> > > For the project "Plugin mechanism for thread scheduler" . It
> > is
> > >> directed
> > >>> > > that some initial work has already been done on this project
> > and
> > >> needed
> > >>> > to
> > >>> > > be continued from that.
> > >>> > >
> > >>> > > Can anyone give me more insights of the previous work done
> so
> > >> far and
> > >>> > what
> > >>> > > further is required ?
> > >>> >
> > >>> > The goal of this project is to separate out into external
> > modules
> > >> the
> > >>> > currently available schedulers from the core HPX library. This
> > is
> > >>> > beneficial as users could plug in their own schedulers at
> > runtime,
> > >> it
> > >>> > would also reduce the footprint of the core library as not all
> > >> available
> > >>> > schedulers would have to be linked into it.
> > >>> >
> > >>> > The only way to sensibly make this happen would be to
> transform
> > >> the
> > >>> > scheduler base class (scheduler_base) into an abstract base
> > class
> > >> which
> > >>> > exposes all necessary functionality through virtual functions.
> > >> Also, the
> > >>> > different schedulers themselves would need to be compiled as
> > >> separate
> > >>> > modules (shared libraries) which would require build system
> > >> changes.
> > >>> > Combined with a dynamic discovery and loading mechanism at
> > runtime
> > >> HPX
> > >>> > would be able to select the appropriate external scheduler
> > module
> > >> and load
> > >>> > and use it.
> > >>> >
> > >>> > What has been done so far? All or part of the necessary
> > scheduler
> > >>> > functionality has already been exposed through virtual
> functions
> > >> in
> > >>> > scheduler_base (see here: https://github.com/STEllAR-
> > >>> >
> > >>
> >
> GROUP/hpx/blob/master/hpx/runtime/threads/policies/scheduler_base.hpp#L62)
> > >>> > .
> > >>> >
> > >>> > What's missing? We miss the dynamic discovery and loading
> > aspect.
> > >> This
> > >>> > however has been implemented for (dynamic) component already
> > from
> > >> where it
> > >>> > could be adapted and reused. Some refactoring of the existing
> > >> schedulers
> > >>> > might be in order as well.
> > >>> >
> > >>> > A couple of pointers:
> > >>> >
> > >>> > We currently use this for abstracting the plugin aspect of an
> > >> external
> > >>> > module: https://github.com/STEllAR-
> > >> GROUP/hpx/tree/master/hpx/util/plugin
> > >>> > (this works for dynamic loading, but also for statically
> linked
> > >> binaries).
> > >>> >
> > >>> > Here is an example how we handle dynamic loading for various
> > >> plugins:
> > >>> > https://github.com/STEllAR-
> > >>> > GROUP/hpx/blob/master/src/util/init_ini_data.cpp#L308.
> > >>> >
> > >>> > HTH
> > >>> > Regards Hartmut
> > >>> > ---------------
> > >>> > http://boost-spirit.com
> > >>> > http://stellar.cct.lsu.edu
> > >>> >
> > >>> >
> > >>> > > Ankit Aggarwal
> > >>> > >
> > >>> > > On Wed, Mar 9, 2016 at 6:11 AM, Hartmut Kaiser
> > >>> > <[email protected] <mailto:[email protected]>>
> > >>> > > wrote:
> > >>> > > Resending, cc'ing Ankit...
> > >>> > >
> > >>> > > Regards Hartmut
> > >>> > > ---------------
> > >>> > > http://boost-spirit.com
> > >>> > > http://stellar.cct.lsu.edu
> > >>> > >
> > >>> > >
> > >>> > > > -----Original Message-----
> > >>> > > > From: Hartmut Kaiser [mailto:[email protected]
> > >> <mailto:[email protected]>]
> > >>> > > > Sent: Tuesday, March 8, 2016 7:06 AM
> > >>> > > > To: '[email protected]
> > >>> <mailto:[email protected]>'
> > >>> <[email protected] <mailto:hpx-
> > >> [email protected]>>
> > >>> > > > Subject: RE: [hpx-devel] Fwd: GSoC 2016
> > >>> > > >
> > >>> > > > Ankit,
> > >>> > > >
> > >>> > > > Thanks for your interest in our project!
> > >>> > > >
> > >>> > > > > I am a fourth year student at PEC,University of
> > >> Technology,India. I
> > >>> > am
> > >>> > > > > interested in the doing in the "Implement a Plugin
> > >> Mechanism" and
> > >>> > > > > "Coroutine like Interface" for GSoC 2016.
> > >>> > > > > Among needed skills I am comfortable with C++ as I have
> > been
> > >> using
> > >>> > it
> > >>> > > > for
> > >>> > > > > last 3 years including libraries like BOOST,OpenCV,
> > Zeromq
> > >> and many
> > >>> > > > > others.
> > >>> > > > > I also participated in GSoC 2015 - MBDyn
> > >>> > > > > <https://www.mbdyn.org/?News&id=19> (Project-2 "INTERNAL
> > >> LIBRARY
> > >>> > > > UPDATES)
> > >>> > > > > which I successfully completed and was also based on C++
> > >> language
> > >>> > > > > including Boost library ,STL etc. I have also attached
> the
> > >> letter of
> > >>> > > > > reference obtained from the mentor for consideration.
> > >>> > > > > I have already installed the HPX library and played
> around
> > >> with it
> > >>> > for
> > >>> > > a
> > >>> > > > > day on the basis syntax and workflow.
> > >>> > > > > I would really appreciate the know the starting point
> for
> > >> this
> > >>> > project
> > >>> > > > and
> > >>> > > > > any other requirements for this project.
> > >>> > > >
> > >>> > > > Give me a day or so, please, to get back to you on all of
> > your
> > >>> > > questions.
> > >>> > > >
> > >>> > > > Regards Hartmut
> > >>> > > > ---------------
> > >>> > > > http://boost-spirit.com
> > >>> > > > http://stellar.cct.lsu.edu
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> hpx-devel mailing list
> > >>> [email protected]
> > >>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > >>>
> > >>
> > >>
> > >> --
> > >> Thomas Heller
> > >> Friedrich-Alexander-Universit?t Erlangen-N?rnberg
> > >> Department Informatik - Lehrstuhl Rechnerarchitektur
> > >> Martensstr. 3
> > >> 91058 Erlangen
> > >> Tel.: 09131/85-27018
> > >> Fax: 09131/85-27912
> > >> Email: [email protected]
> > >> _______________________________________________
> > >> hpx-devel mailing list
> > >> [email protected]
> > >> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > >
> > > _______________________________________________
> > > hpx-devel mailing list
> > > [email protected]
> > > https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > >
> >
> >
> > --
> > Thomas Heller
> > Friedrich-Alexander-Universit?t Erlangen-N?rnberg
> > Department Informatik - Lehrstuhl Rechnerarchitektur
> > Martensstr. 3
> > 91058 Erlangen
> > Tel.: 09131/85-27018
> > Fax: 09131/85-27912
> > Email: [email protected]
>
> _______________________________________________
> hpx-devel mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
>
------------------------------
Message: 2
Date: Sat, 19 Mar 2016 14:30:49 +0000
From: Ankit Aggarwal <[email protected]>
Subject: Re: [hpx-devel] Fwd: GSoC 2016
To: [email protected], [email protected]
Message-ID:
<CAD0Pt-6novSA3dXaoF3cWnfreuf0sCbKna=-qed4qfdnrds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for such a brilliant reply
I think,now i understand the required work to some extent ( compiler
support for the await/coreturn).
Can you please recommend me which compiler to work (gcc or clang) for this
project ?
Ankit Aggarwal
On Sat, 19 Mar 2016 7:39 pm Hartmut Kaiser <[email protected]> wrote:
> Ankit,
>
> > I was going through the Resumable Functions and I was not able to
> > understand a difference between the stack-less coroutine and Resumable
> > functions. Does both share the same meaning or is there any difference
> > among them?
>
> Both flavors of coroutines are what the name implies - coroutines. The
> main semantic difference would be that stack-full coroutines can suspend
> their execution at any level of the call stack, while stack-less coroutines
> can suspend only on the uppermost level of the call stack (and only if the
> compiler moves all local variables off the stack).
>
> > Also,I was able to find the blog
> > <http://meetingcpp.com/index.php/br/items/resumable-functions-async-and-
> > await.html> where Thomas Heller(One of the mentor of HPX) has implemented
> > the resumable functions in HPX,So is the further development needed to be
> > done following the same principle of implementation or some other
> solution
> > is required?
>
> The solution to resumable functions we have is not generic and requires
> user intervention. For instance, let's look at fibonacci (yes, yes, it's a
> dumb example):
>
> // using our dataflow construct
> hpx::future<int> fibonacci(int n)
> {
> if (n < 2) return hpx::make_ready_future(n);
> if (n < threshold) return hpx::make_ready_future(fibonacci_serial(n));
>
> hpx::future<int> lhs_future = hpx::async(&fibonacci, n-1);
> hpx::future<int> rhs_future = fibonacci(n-2);
>
> return
> hpx::dataflow(
> hpx::util::unwrapped(
> [](int lhs, int rhs)
> {
> return lhs + rhs;
> })
> , std::move(lhs_future), std::move(rhs_future)
> );
> }
>
> // using what's proposed for resumable functions:
> hpx::future<int> fibonacci(int n)
> {
> if (n < 2) coreturn hpx::make_ready_future(n);
> if (n < threshold) coreturn
> hpx::make_ready_future(fibonacci_serial(n));
>
> hpx::future<int> lhs_future = hpx::async(&fibonacci, n-1);
> hpx::future<int> rhs_future = fibonacci(n-2);
>
> coreturn await lhs_future + await rhs_future;
> }
>
> Both are 100% semantically equivalent, the second however requires
> compiler support (await/coreturn).
>
> > And most important what is needed to be present in the proposal for this
> > project?
>
> Here is a template of what you should base your proposal on:
> https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-Submission-Template
>
> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> > Ankit Aggarwal
> >
> > On Thu, Mar 17, 2016 at 10:33 PM, Ankit Aggarwal
> > <[email protected]> wrote:
> > Sorry I was not able as soon as possible for the above discussion
> > Yes,I will definitely want to work for this project.
> > I will have the look at how "Resumable functions" work and what are the
> > process required for there declaration.
> >
> > One major obstacle for me will how to extend the gcc or clang for this
> > which I think, i can cover during April before coding begins (maybe
> > earlier).
> > "Ahh yes. This would also be a step in the direction of static dataflow
> > graphs (build once, use often). This is also something supported by the
> > resumable functions stuff, which allows to abstract Generators in a
> > similar
> > way as it abstracts Waitables."
> > Can you please give me more insights on the above statement?
> > Ankit Aggarwal
> >
> >
> >
> > On Thu, Mar 17, 2016 at 7:07 PM, Hartmut Kaiser <
> [email protected]>
> > wrote:
> > > > Uhh, I thought we can do that already (I may misunderstand what you
> > > mean,
> > > > however). Our suspension scheme relies on calling a function 'more
> > than
> > > > once'.
> > >
> > > Sure, but we only ever "return" once. the idea goes something like
> this:
> > >
> > >
> > > void generate(generator<std::size_t> & yield, std::size_t n)
> > > {
> > > for(std::size_t i = 0; i != n; ++n)
> > > {
> > > yield(i * i);
> > > }
> > > yield.return();
> > > }
> > >
> > > void consumer()
> > > {
> > > generator<std::size_t> yield;
> > > hpx::future<std::size_t> f = yield.get_future();
> > > while(f.valid())
> > > {
> > > std::cout << "got " << f.get() << '\n';
> > > f = yield.get_future();
> > > }
> > > }
> >
> > Ahh yes. This would also be a step in the direction of static dataflow
> > graphs (build once, use often). This is also something supported by the
> > resumable functions stuff, which allows to abstract Generators in a
> > similar
> > way as it abstracts Waitables.
> >
> > This would indeed be a nice GSoC project!
> >
> > Aggrawal - would you be up to it?
> >
> > Regards Hartmut
> > ---------------
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> >
> >
> > > >> Hope that helps!
> > > >>
> > > >> Cheers,
> > > >> Thomas
> > > >>
> > > >>>
> > > >>> Ankit Aggarwal
> > > >>>
> > > >>> On Mon, Mar 14, 2016 at 11:02 PM, Hartmut Kaiser
> > > >>> <[email protected] <mailto:[email protected]>>
> wrote:
> > > >>>
> > > >>> Ankit,
> > > >>>
> > > >>> > I was attached some of the links i was going through to
> > > understand
> > > >> the
> > > >>> > plug-in mechanism in the C++
> > > >>> >
> > > >>> > <http://www.open-
> > > >> std.org/jtc1/sc22/wg21/docs/papers/2006/n2015.pdf>
> > > >>> > <http://www.drdobbs.com/cpp/building-your-own-plugin-
> > framework-
> > > >>> > part/204202899?pgno=1>
> > > >>> >
> > > >>> > To my understanding, what have been done till now is that
> > third-
> > > >> party
> > > >>> > developer is able to write their own scheduler using the
> > > scheduler
> > > >> base
> > > >>> > class and further work required is to develop the plug-in
> > > manager
> > > >> that
> > > >>> > will manage the life system of the plug-in and expose the
> > plug-
> > > in
> > > >> to core
> > > >>> > library.
> > > >>> >
> > > >>> > Please correct me if I am wrong in understanding the project
> > > >>> >
> > > >>> > > "What's missing? We miss the dynamic discovery and loading
> > > >> aspect. This
> > > >>> > > however has been implemented for (dynamic) component
> already
> > > >> from where it
> > > >>> > > could be adapted and reused. Some refactoring of the
> > existing
> > > >> schedulers
> > > >>> > > might be in order as well."
> > > >>> >
> > > >>> > I was not able to understand the term "component" in the
> above
> > > >>> > statement.Does components refer to something other than plug-
> > in?
> > > >>>
> > > >>> Yes,. In HPX dynamic components are a special type of plugins.
> > > >>>
> > > >>> Sorry for being insufficiently concise here.
> > > >>> Regards Hartmut
> > > >>> ---------------
> > > >>> http://boost-spirit.com
> > > >>> http://stellar.cct.lsu.edu
> > > >>>
> > > >>> >
> > > >>> > Ankit Aggarwal
> > > >>> >
> > > >>> > On Sat, Mar 12, 2016 at 8:01 PM, Hartmut Kaiser
> > > >> <[email protected] <mailto:[email protected]>>
> > > >>> > wrote:
> > > >>> > Ankit,
> > > >>> >
> > > >>> > > For the project "Plugin mechanism for thread scheduler" .
> It
> > > is
> > > >> directed
> > > >>> > > that some initial work has already been done on this
> project
> > > and
> > > >> needed
> > > >>> > to
> > > >>> > > be continued from that.
> > > >>> > >
> > > >>> > > Can anyone give me more insights of the previous work done
> > so
> > > >> far and
> > > >>> > what
> > > >>> > > further is required ?
> > > >>> >
> > > >>> > The goal of this project is to separate out into external
> > > modules
> > > >> the
> > > >>> > currently available schedulers from the core HPX library.
> This
> > > is
> > > >>> > beneficial as users could plug in their own schedulers at
> > > runtime,
> > > >> it
> > > >>> > would also reduce the footprint of the core library as not
> all
> > > >> available
> > > >>> > schedulers would have to be linked into it.
> > > >>> >
> > > >>> > The only way to sensibly make this happen would be to
> > transform
> > > >> the
> > > >>> > scheduler base class (scheduler_base) into an abstract base
> > > class
> > > >> which
> > > >>> > exposes all necessary functionality through virtual
> functions.
> > > >> Also, the
> > > >>> > different schedulers themselves would need to be compiled as
> > > >> separate
> > > >>> > modules (shared libraries) which would require build system
> > > >> changes.
> > > >>> > Combined with a dynamic discovery and loading mechanism at
> > > runtime
> > > >> HPX
> > > >>> > would be able to select the appropriate external scheduler
> > > module
> > > >> and load
> > > >>> > and use it.
> > > >>> >
> > > >>> > What has been done so far? All or part of the necessary
> > > scheduler
> > > >>> > functionality has already been exposed through virtual
> > functions
> > > >> in
> > > >>> > scheduler_base (see here: https://github.com/STEllAR-
> > > >>> >
> > > >>
> > >
> >
> GROUP/hpx/blob/master/hpx/runtime/threads/policies/scheduler_base.hpp#L62)
> > > >>> > .
> > > >>> >
> > > >>> > What's missing? We miss the dynamic discovery and loading
> > > aspect.
> > > >> This
> > > >>> > however has been implemented for (dynamic) component already
> > > from
> > > >> where it
> > > >>> > could be adapted and reused. Some refactoring of the existing
> > > >> schedulers
> > > >>> > might be in order as well.
> > > >>> >
> > > >>> > A couple of pointers:
> > > >>> >
> > > >>> > We currently use this for abstracting the plugin aspect of an
> > > >> external
> > > >>> > module: https://github.com/STEllAR-
> > > >> GROUP/hpx/tree/master/hpx/util/plugin
> > > >>> > (this works for dynamic loading, but also for statically
> > linked
> > > >> binaries).
> > > >>> >
> > > >>> > Here is an example how we handle dynamic loading for various
> > > >> plugins:
> > > >>> > https://github.com/STEllAR-
> > > >>> > GROUP/hpx/blob/master/src/util/init_ini_data.cpp#L308.
> > > >>> >
> > > >>> > HTH
> > > >>> > Regards Hartmut
> > > >>> > ---------------
> > > >>> > http://boost-spirit.com
> > > >>> > http://stellar.cct.lsu.edu
> > > >>> >
> > > >>> >
> > > >>> > > Ankit Aggarwal
> > > >>> > >
> > > >>> > > On Wed, Mar 9, 2016 at 6:11 AM, Hartmut Kaiser
> > > >>> > <[email protected] <mailto:[email protected]>>
> > > >>> > > wrote:
> > > >>> > > Resending, cc'ing Ankit...
> > > >>> > >
> > > >>> > > Regards Hartmut
> > > >>> > > ---------------
> > > >>> > > http://boost-spirit.com
> > > >>> > > http://stellar.cct.lsu.edu
> > > >>> > >
> > > >>> > >
> > > >>> > > > -----Original Message-----
> > > >>> > > > From: Hartmut Kaiser [mailto:[email protected]
> > > >> <mailto:[email protected]>]
> > > >>> > > > Sent: Tuesday, March 8, 2016 7:06 AM
> > > >>> > > > To: '[email protected]
> > > >>> <mailto:[email protected]>'
> > > >>> <[email protected] <mailto:hpx-
> > > >> [email protected]>>
> > > >>> > > > Subject: RE: [hpx-devel] Fwd: GSoC 2016
> > > >>> > > >
> > > >>> > > > Ankit,
> > > >>> > > >
> > > >>> > > > Thanks for your interest in our project!
> > > >>> > > >
> > > >>> > > > > I am a fourth year student at PEC,University of
> > > >> Technology,India. I
> > > >>> > am
> > > >>> > > > > interested in the doing in the "Implement a Plugin
> > > >> Mechanism" and
> > > >>> > > > > "Coroutine like Interface" for GSoC 2016.
> > > >>> > > > > Among needed skills I am comfortable with C++ as I have
> > > been
> > > >> using
> > > >>> > it
> > > >>> > > > for
> > > >>> > > > > last 3 years including libraries like BOOST,OpenCV,
> > > Zeromq
> > > >> and many
> > > >>> > > > > others.
> > > >>> > > > > I also participated in GSoC 2015 - MBDyn
> > > >>> > > > > <https://www.mbdyn.org/?News&id=19> (Project-2
> "INTERNAL
> > > >> LIBRARY
> > > >>> > > > UPDATES)
> > > >>> > > > > which I successfully completed and was also based on
> C++
> > > >> language
> > > >>> > > > > including Boost library ,STL etc. I have also attached
> > the
> > > >> letter of
> > > >>> > > > > reference obtained from the mentor for consideration.
> > > >>> > > > > I have already installed the HPX library and played
> > around
> > > >> with it
> > > >>> > for
> > > >>> > > a
> > > >>> > > > > day on the basis syntax and workflow.
> > > >>> > > > > I would really appreciate the know the starting point
> > for
> > > >> this
> > > >>> > project
> > > >>> > > > and
> > > >>> > > > > any other requirements for this project.
> > > >>> > > >
> > > >>> > > > Give me a day or so, please, to get back to you on all of
> > > your
> > > >>> > > questions.
> > > >>> > > >
> > > >>> > > > Regards Hartmut
> > > >>> > > > ---------------
> > > >>> > > > http://boost-spirit.com
> > > >>> > > > http://stellar.cct.lsu.edu
> > > >>> > > >
> > > >>> > >
> > > >>> >
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> hpx-devel mailing list
> > > >>> [email protected]
> > > >>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Thomas Heller
> > > >> Friedrich-Alexander-Universit?t Erlangen-N?rnberg
> > > >> Department Informatik - Lehrstuhl Rechnerarchitektur
> > > >> Martensstr. 3
> > > >> 91058 Erlangen
> > > >> Tel.: 09131/85-27018
> > > >> Fax: 09131/85-27912
> > > >> Email: [email protected]
> > > >> _______________________________________________
> > > >> hpx-devel mailing list
> > > >> [email protected]
> > > >> https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > > >
> > > > _______________________________________________
> > > > hpx-devel mailing list
> > > > [email protected]
> > > > https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> > > >
> > >
> > >
> > > --
> > > Thomas Heller
> > > Friedrich-Alexander-Universit?t Erlangen-N?rnberg
> > > Department Informatik - Lehrstuhl Rechnerarchitektur
> > > Martensstr. 3
> > > 91058 Erlangen
> > > Tel.: 09131/85-27018
> > > Fax: 09131/85-27912
> > > Email: [email protected]
> >
> > _______________________________________________
> > hpx-devel mailing list
> > [email protected]
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20160319/70870b38/attachment.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 26, Issue 13
*****************************************
