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 (Thomas Heller)
2. Re: Fwd: GSoC 2016 (Hartmut Kaiser)
3. Re: Fwd: GSoC 2016 (Thomas Heller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 17 Mar 2016 14:07:33 +0100
From: Thomas Heller <[email protected]>
Subject: Re: [hpx-devel] Fwd: GSoC 2016
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Ankit,
Sorry for the delay ... see my answer below.
On 03/16/2016 06:24 AM, Ankit Aggarwal wrote:
> Hi Everyone
>
> For the project of "Coroutine like interface",I was able to find some of
> the basic examples using BOOST.Coroutine which can be used to achieve
> the required motive. I have been going through this webpage
>
> <http://aldrin.co/coroutine-basics.html>
>
> which provides basic implementation of the yield.
>
> Is this the good starting point for this project?
The project idea is a little old. The idea was to create coroutine like
generators and so on within our current API.
Recent development within the C++ community lead to a different
approach: Resumable functions. We currently prefer that, however
there is only an implementation for the Microsoft compiler, and an
alternative for gcc or clang would be nice! There is a project idea for
that:
https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2016-Project-Ideas#a-free-resumable-functions-implementation
Would you be interested to work on that instead? The alternative would
be to create an interface on a pure library based solution. Keep in
mind, that HPX threads themselves are already coroutines and we merely
miss the functionality to "return" more than once from a function.
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:[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]
------------------------------
Message: 2
Date: Thu, 17 Mar 2016 07:45:56 -0500
From: "Hartmut Kaiser" <[email protected]>
Subject: Re: [hpx-devel] Fwd: GSoC 2016
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
> Sorry for the delay ... see my answer below.
>
> On 03/16/2016 06:24 AM, Ankit Aggarwal wrote:
> > Hi Everyone
> >
> > For the project of "Coroutine like interface",I was able to find some of
> > the basic examples using BOOST.Coroutine which can be used to achieve
> > the required motive. I have been going through this webpage
> >
> > <http://aldrin.co/coroutine-basics.html>
> >
> > which provides basic implementation of the yield.
> >
> > Is this the good starting point for this project?
>
> The project idea is a little old. The idea was to create coroutine like
> generators and so on within our current API.
> Recent development within the C++ community lead to a different
> approach: Resumable functions. We currently prefer that, however
> there is only an implementation for the Microsoft compiler, and an
> alternative for gcc or clang would be nice! There is a project idea for
> that:
> https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2016-Project-Ideas#a-free-
> resumable-functions-implementation
I know that a guy from the clang team at google is working on this.
> Would you be interested to work on that instead? The alternative would
> be to create an interface on a pure library based solution. Keep in
> mind, that HPX threads themselves are already coroutines and we merely
> miss the functionality to "return" more than once from a function.
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'.
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
------------------------------
Message: 3
Date: Thu, 17 Mar 2016 14:51:32 +0100
From: Thomas Heller <[email protected]>
Subject: Re: [hpx-devel] Fwd: GSoC 2016
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 03/17/2016 01:45 PM, Hartmut Kaiser wrote:
>
>> Sorry for the delay ... see my answer below.
>>
>> On 03/16/2016 06:24 AM, Ankit Aggarwal wrote:
>>> Hi Everyone
>>>
>>> For the project of "Coroutine like interface",I was able to find some of
>>> the basic examples using BOOST.Coroutine which can be used to achieve
>>> the required motive. I have been going through this webpage
>>>
>>> <http://aldrin.co/coroutine-basics.html>
>>>
>>> which provides basic implementation of the yield.
>>>
>>> Is this the good starting point for this project?
>>
>> The project idea is a little old. The idea was to create coroutine like
>> generators and so on within our current API.
>> Recent development within the C++ community lead to a different
>> approach: Resumable functions. We currently prefer that, however
>> there is only an implementation for the Microsoft compiler, and an
>> alternative for gcc or clang would be nice! There is a project idea for
>> that:
>> https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2016-Project-Ideas#a-free-
>> resumable-functions-implementation
>
> I know that a guy from the clang team at google is working on this.
>
>> Would you be interested to work on that instead? The alternative would
>> be to create an interface on a pure library based solution. Keep in
>> mind, that HPX threads themselves are already coroutines and we merely
>> miss the functionality to "return" more than once from a function.
>
> 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();
}
}
>
> 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
End of hpx-devel Digest, Vol 26, Issue 9
****************************************
