New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate unwrapped and implement unwrap and unwrapping #2741

Merged
merged 23 commits into from Jul 28, 2017

Conversation

Projects
None yet
4 participants
@Naios
Contributor

Naios commented Jul 5, 2017

This is the second PR of my GSoC 馃尀 project

  • Some fixes to the pack traversal API
  • It replaces the internal implementation of the unwrapped internals to use the pack_traversal API.
  • The functional unwrap is now called unwrapping, the new immediate unwrap: unwrap. The API provides two alternatives for both functions: unwrap_n, unwrap_all, unwrapping_n, unwrapping_all which unwrap until a particular level of futures or all futures which are found recursively inside the arguments.
    • Tuples which are passed as only argument to unwrap aren't unwrapped anymore. We could provide an explode or spread function for this behaviour.
  • For now all internal stuff of HPX is using a proxy function unwrapped which calls the new API unwrap.

Probably there are some remaing build failures and inconsisties which need to be fixed, however I want to receive feedback early.

For now:
鉁旓笍 hpx base library builds
鉁旓笍 unwrapped_test builds (using the unit tests of the old implementation for the new one)
鉁旓笍 unwrap_test builds
鉁旓笍 examples build
鉁旓笍 tests build

Outstanding points (need to be fixed before merging):

  • More unit tests for unwrap and unwrapping
  • Fix the remaining inconsistencies between the old implementation and the new one.
  • Replace using namespace
  • Add constexpr and noexcept
  • Replace unwrapped by unwrap and unwrapping
  • Add deprecation notice

@Naios Naios changed the title from Replace the unwrapped internals for using the pack_traversal API to [WIP] Replace the unwrapped internals for using the pack_traversal API Jul 5, 2017

@hkaiser hkaiser added this to the 1.1.0 milestone Jul 5, 2017

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 7, 2017

Contributor

@hkaiser did you take a look on this already?
It would be great if you could give me feedback whether I'm moving into the right direction here.

Contributor

Naios commented Jul 7, 2017

@hkaiser did you take a look on this already?
It would be great if you could give me feedback whether I'm moving into the right direction here.

@hkaiser

This looks very nice, overall.

using element_of_t = typename std::conditional<
std::is_rvalue_reference<Container&&>::value,
decltype(std::move(*(std::declval<Container>().begin()))),
decltype(*(std::declval<Container>().begin()))>::type;

This comment has been minimized.

@hkaiser

hkaiser Jul 7, 2017

Member

Can this be simplified (i.e. encapsulated in a separate facility)?

@hkaiser

hkaiser Jul 7, 2017

Member

Can this be simplified (i.e. encapsulated in a separate facility)?

This comment has been minimized.

@Naios

Naios Jul 9, 2017

Contributor

element_of_t also emulates the behaviour of container_accessor which means that it's quite difficult to refactor this into a seperate facility. However, I'm open for suggestions.

@Naios

Naios Jul 9, 2017

Contributor

element_of_t also emulates the behaviour of container_accessor which means that it's quite difficult to refactor this into a seperate facility. However, I'm open for suggestions.

This comment has been minimized.

@hkaiser

hkaiser Jul 10, 2017

Member

I just find this construct to be difficult to parse. Could you at least add an explaining comment, please?

@hkaiser

hkaiser Jul 10, 2017

Member

I just find this construct to be difficult to parse. Could you at least add an explaining comment, please?

This comment has been minimized.

@Naios

Naios Jul 10, 2017

Contributor

Yes, I'll do.

@Naios

Naios Jul 10, 2017

Contributor

Yes, I'll do.

This comment has been minimized.

@Naios

Naios Jul 11, 2017

Contributor

I added more documentation to this alias.

@Naios

Naios Jul 11, 2017

Contributor

I added more documentation to this alias.

{
}
auto begin()

This comment has been minimized.

@hkaiser

hkaiser Jul 7, 2017

Member

Can this be const?

@hkaiser

hkaiser Jul 7, 2017

Member

Can this be const?

This comment has been minimized.

@Naios

Naios Jul 8, 2017

Contributor

I'll ckeck that

@Naios

Naios Jul 8, 2017

Contributor

I'll ckeck that

This comment has been minimized.

@Naios

Naios Jul 11, 2017

Contributor

The begin and end method can't be a const references because we must allow the mapping from non const l-value references too (this was fixed today).

@Naios

Naios Jul 11, 2017

Contributor

The begin and end method can't be a const references because we must allow the mapping from non const l-value references too (this was fixed today).

return std::make_move_iterator(container_.begin());
}
auto end()

This comment has been minimized.

@hkaiser

hkaiser Jul 7, 2017

Member

Same here: const?

@hkaiser

hkaiser Jul 7, 2017

Member

Same here: const?

This comment has been minimized.

@Naios

Naios Jul 8, 2017

Contributor

Same as above

@Naios

Naios Jul 8, 2017

Contributor

Same as above

Show outdated Hide outdated hpx/util/detail/pack_traversal_impl.hpp
Show outdated Hide outdated hpx/util/detail/pack_traversal_impl.hpp
Show outdated Hide outdated hpx/util/detail/unwrap_impl.hpp
/// - `hpx::future<int>` -> `int`
/// - `hpx::future<std::vector<float>>` -> `std::vector<float>`
/// - `std::vector<future<float>>` -> `std::vector<float>`
///

This comment has been minimized.

@hkaiser

hkaiser Jul 7, 2017

Member

Would this unwrap std::vector<std::vector<hpx::future<T>>> ?

@hkaiser

hkaiser Jul 7, 2017

Member

Would this unwrap std::vector<std::vector<hpx::future<T>>> ?

This comment has been minimized.

@Naios

Naios Jul 9, 2017

Contributor

Yes, it would. Also futures nested inside arbitrary combinations of tuples, pairs and homogeneous containers like std::list or std::vector are being remapped. For instance:

std::list<
  std::pair<
    int,
    std::tuple<
      int,
      std::vector<
        hpx::lcos::future<int>
      >,
      double
    >
  >
>

is also unwrapped.

@Naios

Naios Jul 9, 2017

Contributor

Yes, it would. Also futures nested inside arbitrary combinations of tuples, pairs and homogeneous containers like std::list or std::vector are being remapped. For instance:

std::list<
  std::pair<
    int,
    std::tuple<
      int,
      std::vector<
        hpx::lcos::future<int>
      >,
      double
    >
  >
>

is also unwrapped.

This comment has been minimized.

@hkaiser

hkaiser Jul 10, 2017

Member

That's great. We just ran into the need for when_all() to be able to handle a vector<vector<future<T>>> the other day...

@hkaiser

hkaiser Jul 10, 2017

Member

That's great. We just ran into the need for when_all() to be able to handle a vector<vector<future<T>>> the other day...

This comment has been minimized.

@Naios

Naios Jul 10, 2017

Contributor

Sadly the underlying API is only capable of doing a synchronous unwrap which isn't suitable for the current implementation of when_all.
In order to improve when_all we would have to use a stackful coroutine with this API or
implement another version of the traversal API which is completely stateless (to emulate a stackless coroutine).

@Naios

Naios Jul 10, 2017

Contributor

Sadly the underlying API is only capable of doing a synchronous unwrap which isn't suitable for the current implementation of when_all.
In order to improve when_all we would have to use a stackful coroutine with this API or
implement another version of the traversal API which is completely stateless (to emulate a stackless coroutine).

This comment has been minimized.

@hkaiser

hkaiser Jul 10, 2017

Member

Yes, forgot about that. Thanks.

@hkaiser

hkaiser Jul 10, 2017

Member

Yes, forgot about that. Thanks.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 22, 2017

Member

@Naios This is impressive work! The only thing I'd ask is for you to use meaningful commit messages. Otherwise it will be impossible to reconstruct the changes you applied, if necessary. You might even want to go back and to merge commits or to rewrite some of the history on this branch to make things more transparent.

Member

hkaiser commented Jul 22, 2017

@Naios This is impressive work! The only thing I'd ask is for you to use meaningful commit messages. Otherwise it will be impossible to reconstruct the changes you applied, if necessary. You might even want to go back and to merge commits or to rewrite some of the history on this branch to make things more transparent.

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 22, 2017

Contributor

@hkaiser Thank you. Yes, I'll interactively rebase the commits back into the 7 first commits, so everything looks like atomic changes, as soon as I'll have a proper state. Usually I keep the commits rebased with the current master.
Just wanted to keep the history as long as possible so I have a chance for reverts and also that you can take a look at my current progress (note that my actual working branch is Naios/hpx/unwrap so the CI isn't stressed that much).

Contributor

Naios commented Jul 22, 2017

@hkaiser Thank you. Yes, I'll interactively rebase the commits back into the 7 first commits, so everything looks like atomic changes, as soon as I'll have a proper state. Usually I keep the commits rebased with the current master.
Just wanted to keep the history as long as possible so I have a chance for reverts and also that you can take a look at my current progress (note that my actual working branch is Naios/hpx/unwrap so the CI isn't stressed that much).

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 23, 2017

Contributor

@hkaiser For me it seems like the functional part of this PR is done now, since all the unit tests pass with the new unwrap implementation and the changes I applied recently.
I'll work on the few outstanding ToDo items now, in order to get the PR ready for merge in the next 2 days.

Additionally, I have one outstanding question regarding the originally planned compatibility layer between unwrap and unwrapped.

Since the 1:n mapping improvements, the original unwrapped and the new unwrap unwrap implementation just distingiush theirself in one point: unwrapped did unwrap the first occurring tuple regardless the callable was called with more than one argument or not. Thus tuples which were passed to unwrapped were unpacked by default as shown in the following unit test:

int add(int c1, int c2)
{
    return c1 + c2;
}

// ...

hpx::util::tuple<future<int>, future<int> > tuple =
                hpx::util::forward_as_tuple(
                    hpx::make_ready_future(42), hpx::make_ready_future(42));

HPX_TEST_EQ(unwrapped(&add)(tuple), 42 + 42);

Because uwrapped will be deprecated anyway, I would like to drop this behaviour immediatly (and delete the unit test above), so we don't need to add an additional compatibility layer (and duplicate the implementation headers). Since this particular functionality of unwrapped isn't documented nor used in the overall framework, I think we can apply this change without risking to break the API.

Do you think this is arguable?

Contributor

Naios commented Jul 23, 2017

@hkaiser For me it seems like the functional part of this PR is done now, since all the unit tests pass with the new unwrap implementation and the changes I applied recently.
I'll work on the few outstanding ToDo items now, in order to get the PR ready for merge in the next 2 days.

Additionally, I have one outstanding question regarding the originally planned compatibility layer between unwrap and unwrapped.

Since the 1:n mapping improvements, the original unwrapped and the new unwrap unwrap implementation just distingiush theirself in one point: unwrapped did unwrap the first occurring tuple regardless the callable was called with more than one argument or not. Thus tuples which were passed to unwrapped were unpacked by default as shown in the following unit test:

int add(int c1, int c2)
{
    return c1 + c2;
}

// ...

hpx::util::tuple<future<int>, future<int> > tuple =
                hpx::util::forward_as_tuple(
                    hpx::make_ready_future(42), hpx::make_ready_future(42));

HPX_TEST_EQ(unwrapped(&add)(tuple), 42 + 42);

Because uwrapped will be deprecated anyway, I would like to drop this behaviour immediatly (and delete the unit test above), so we don't need to add an additional compatibility layer (and duplicate the implementation headers). Since this particular functionality of unwrapped isn't documented nor used in the overall framework, I think we can apply this change without risking to break the API.

Do you think this is arguable?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 23, 2017

Member

That is fine. We need to add a note about the breaking change in the docs, though (here).

Also, we may be able not to rename the existing unwrapped, or do should we do that in any case?

Member

hkaiser commented Jul 23, 2017

That is fine. We need to add a note about the breaking change in the docs, though (here).

Also, we may be able not to rename the existing unwrapped, or do should we do that in any case?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 23, 2017

Member

@Naios: could you please also clarify what relation this PR has to #1404, #1400, and #1126?

Member

hkaiser commented Jul 23, 2017

@Naios: could you please also clarify what relation this PR has to #1404, #1400, and #1126?

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 23, 2017

Contributor

Internally I'll rename the function calls to unwrap or unwrapping accordingly so I can flag unwrapped with HPX_DEPRECATED.
Because HPX itself and all the unit tests and examples build with the new behaviour, there is nothing against the rename in my opinion.

Because of the issues: #1404, #2456 and #1400 will be resolved, #1126 is only solved half because when_all and dataflow are still missing the changes (which require the async traversal API).
I'll add closing comments to the last commit in this PR so the issues get resolved automatically through merging.

Contributor

Naios commented Jul 23, 2017

Internally I'll rename the function calls to unwrap or unwrapping accordingly so I can flag unwrapped with HPX_DEPRECATED.
Because HPX itself and all the unit tests and examples build with the new behaviour, there is nothing against the rename in my opinion.

Because of the issues: #1404, #2456 and #1400 will be resolved, #1126 is only solved half because when_all and dataflow are still missing the changes (which require the async traversal API).
I'll add closing comments to the last commit in this PR so the issues get resolved automatically through merging.

@Naios Naios changed the title from [WIP] Replace the unwrapped internals for using the pack_traversal API to Deprecate unwrapped and implement unwrap and unwrapping Jul 24, 2017

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 24, 2017

Contributor

@hkaiser From my side this PR is finished and ready for merging 馃帀

Contributor

Naios commented Jul 24, 2017

@hkaiser From my side this PR is finished and ready for merging 馃帀

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 24, 2017

Member

@Naios: the only real question I have is whether we should retain the old name (at least for the functional part of unwrapped).

Member

hkaiser commented Jul 24, 2017

@Naios: the only real question I have is whether we should retain the old name (at least for the functional part of unwrapped).

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 24, 2017

Contributor

@hkaiser My personal opinion on this is to also take a new name for the functional part since the overall capability of the function was changed and thus library users should be forced to review this change.

But if it's decided to keep the old name for the functional implementation, I could change it back easily.
However, this would prevent users from using the current deprecated unwrapped function which stays functionable until removal (in this case we would remove the old unwrapped completely without deprecating it officially).

Contributor

Naios commented Jul 24, 2017

@hkaiser My personal opinion on this is to also take a new name for the functional part since the overall capability of the function was changed and thus library users should be forced to review this change.

But if it's decided to keep the old name for the functional implementation, I could change it back easily.
However, this would prevent users from using the current deprecated unwrapped function which stays functionable until removal (in this case we would remove the old unwrapped completely without deprecating it officially).

@aserio

This comment has been minimized.

Show comment
Hide comment
@aserio

aserio Jul 24, 2017

Contributor

@Naios, Congratulations on your first pull request! After this is merged we can coordinate to get you an HPX T-shirt ;)

Contributor

aserio commented Jul 24, 2017

@Naios, Congratulations on your first pull request! After this is merged we can coordinate to get you an HPX T-shirt ;)

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 25, 2017

Member

@Naios: well, we have to think about code out there using unwrapped today. We have two possible ways forward:

  • either we leave the name unwrapped (instead of unwrapping), or
  • deprecate unwrapped the usual way (in three stages, as described earlier)

I personally think we should deprecate today's unwrapped as a simple renaming doesn't cover all possible use cases.

For this reason, may I ask you to add a preprocessor constant (for instance HPX_WITH_UNWRAPPED_COMPATIBILITY/HPX_HAVE_UNWRAPPED_COMPATIBILITY) which wraps the old code (no need to try to 'emulate' the old behavior in the new code) and to mark the definition of the old unwrapped usingHPX_DEPRECATED`. Also, please add a sentence or two to the docs describing the necessary changes to existing code, including the name of the configuration constant you used.

Member

hkaiser commented Jul 25, 2017

@Naios: well, we have to think about code out there using unwrapped today. We have two possible ways forward:

  • either we leave the name unwrapped (instead of unwrapping), or
  • deprecate unwrapped the usual way (in three stages, as described earlier)

I personally think we should deprecate today's unwrapped as a simple renaming doesn't cover all possible use cases.

For this reason, may I ask you to add a preprocessor constant (for instance HPX_WITH_UNWRAPPED_COMPATIBILITY/HPX_HAVE_UNWRAPPED_COMPATIBILITY) which wraps the old code (no need to try to 'emulate' the old behavior in the new code) and to mark the definition of the old unwrapped usingHPX_DEPRECATED`. Also, please add a sentence or two to the docs describing the necessary changes to existing code, including the name of the configuration constant you used.

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 25, 2017

Contributor

@hkaiser I applied the requested changes as discussed.

Contributor

Naios commented Jul 25, 2017

@hkaiser I applied the requested changes as discussed.

Naios added some commits Jun 26, 2017

Fix tuple_cat when using l-value references
* Add basic unit tests to ensure the correctness of tuple_cat.
Implement the rewritten version of unwrapped (called unwrap and unwra鈥
鈥ping)

* unwrapped will be deprecated, until it's removed unwrapped
  will use unwrap as underlying implementation.
* The re-implementation and deprecation was required due
  to unresolvable issues in the old implementation,
  which mainly arised from the requirement to route
  non future values through.
Remove the old implementation of unwrapped
* Add a proxy which emulates its behaviour using the new unwrap API
* The proxy will be flagged as deprecated once the usage
  of unwrapped was replaced inside all unit tests and examples.
Fix the mapping of l-value references (hpx::lcos::shared_future)
* Add some unit tests to ensure the behaviour
Propagate empty mappings back to the caller
* Required for returning empty mappings from vector<future<void>>
Implement unit tests for unwrap and unwrapping
* Partially re-uses the previous tests of tests/unit/util/unwrapped.cpp
Remove unsupported tests of unwrap
* Disable deprecation warnings inside the legacy unwrapped tests
Remove using namespace in the pack_traversal unit test
* Correct the naming of some functions
Rename the internal mapper invoke to invoke_mapper
* Prevents wrong function selection caused through ADL
* Also namespace a call to make_tuple

Naios added some commits Jul 24, 2017

Deprecate hpx::util::unwrapped
* Use hpx::util::unwrap and hpx::util::unwrapping instead,
  that clearify which underlying implementation should
  be used (the immediate or the deferred one).
  The automatic implementation selection was broken since
  unwrapped allowed to pass non future arguments through.
* Closes #1400
* Closes #1404
* Closes #2456
* Ref #1126
* Ref #1132
@hkaiser

LGTM, thanks a lot!

@hkaiser hkaiser merged commit 8ba2a4e into STEllAR-GROUP:master Jul 28, 2017

2 checks passed

ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@taeguk

This comment has been minimized.

Show comment
Hide comment
@taeguk

taeguk Jul 29, 2017

Member

@Naios What compilers this PR was tested with?
In Visual Studio 2015, I found compile error messages related to this PR.

c:\users\xornr\onedrive\documents\github\hpx\hpx\util\detail\unwrap_impl.hpp(176): error C2297: '&&': 鞓るジ飒 頂检棸靷办瀽 順曥嫕鞙茧 'Unique-Type-value'鞚(毳) 靷毄頃 靾 鞐嗢姷雼堧嫟.

There is the error message above. (Sorry to korean error message. Maybe you need to translate the message to english.)

Member

taeguk commented Jul 29, 2017

@Naios What compilers this PR was tested with?
In Visual Studio 2015, I found compile error messages related to this PR.

c:\users\xornr\onedrive\documents\github\hpx\hpx\util\detail\unwrap_impl.hpp(176): error C2297: '&&': 鞓るジ飒 頂检棸靷办瀽 順曥嫕鞙茧 'Unique-Type-value'鞚(毳) 靷毄頃 靾 鞐嗢姷雼堧嫟.

There is the error message above. (Sorry to korean error message. Maybe you need to translate the message to english.)

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 29, 2017

Contributor

@taeguk I'm sorry because it seems the PR was only tested with with Visual Studio 2017.
I blindly trusted the AppVeyor CI which uses Visual Studio 2017 too, I totally missed that Visual Studio 2015 is still supported.

What you could try is to patch your locale Visual Studio version to Visual Studio 2015 Update 3, which eventually could fix your issue.
Beside of this I'll take a look on this.

@hkaiser Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?
It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.
Also maybe we could align the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

Contributor

Naios commented Jul 29, 2017

@taeguk I'm sorry because it seems the PR was only tested with with Visual Studio 2017.
I blindly trusted the AppVeyor CI which uses Visual Studio 2017 too, I totally missed that Visual Studio 2015 is still supported.

What you could try is to patch your locale Visual Studio version to Visual Studio 2015 Update 3, which eventually could fix your issue.
Beside of this I'll take a look on this.

@hkaiser Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?
It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.
Also maybe we could align the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 29, 2017

Member

Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?

So far we've had the policy to support the latest two versions of Visual Studio. We just dropped support for VS 2013 the other day,

It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.

Ok, patches welcome. Anybody?

Also maybe we could align the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

That should be doable as well.

Member

hkaiser commented Jul 29, 2017

Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?

So far we've had the policy to support the latest two versions of Visual Studio. We just dropped support for VS 2013 the other day,

It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.

Ok, patches welcome. Anybody?

Also maybe we could align the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

That should be doable as well.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 29, 2017

Member

@Naios: another option would be to leave the old unwrapped code in place when compiling with VS2015. I don't particularly care about this version as VS2017 is ABI compatible and everybody can simply download the newer one. This however would require some discussion, I'd like to hear the opinion of others.

Member

hkaiser commented Jul 29, 2017

@Naios: another option would be to leave the old unwrapped code in place when compiling with VS2015. I don't particularly care about this version as VS2017 is ABI compatible and everybody can simply download the newer one. This however would require some discussion, I'd like to hear the opinion of others.

Naios added a commit to Naios/hpx that referenced this pull request Jul 29, 2017

Naios added a commit to Naios/hpx that referenced this pull request Jul 29, 2017

Naios added a commit to Naios/hpx that referenced this pull request Jul 29, 2017

Fix potential unconditial moves
* Thanks to K-ballo for pointing this out
* We use hpx::util::get now for retrieving a specific
  element at index i instead of the internal
  tuple_element API.
* Ref #2741

@Naios Naios referenced this pull request Jul 29, 2017

Merged

Unwrap hotfixes #2787

@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 29, 2017

Contributor

@hkaiser @taeguk I provided the fixes for both known issues of this PR in #2787.
The MSVC 2015 issue should be fixed.

Contributor

Naios commented Jul 29, 2017

@hkaiser @taeguk I provided the fixes for both known issues of this PR in #2787.
The MSVC 2015 issue should be fixed.

Naios added a commit to Naios/hpx that referenced this pull request Jul 29, 2017

Fix potential unconditial moves
* Thanks to K-ballo for pointing this out
* We use hpx::util::get now for retrieving a specific
  element at index i instead of the internal
  tuple_element API.
* Ref #2741
@taeguk

This comment has been minimized.

Show comment
Hide comment
@taeguk

taeguk Jul 30, 2017

Member

@Naios I found that issue with Visual Studio 2015 Enterprise Update 3.
Now, is my issue fixed??

Member

taeguk commented Jul 30, 2017

@Naios I found that issue with Visual Studio 2015 Enterprise Update 3.
Now, is my issue fixed??

Naios added a commit to Naios/hpx that referenced this pull request Jul 30, 2017

Naios added a commit to Naios/hpx that referenced this pull request Jul 30, 2017

Fix potential unconditial moves in hpx::util::tuple_cat
* Thanks to K-ballo for pointing this out
* We use hpx::util::get now for retrieving a specific
  element at index i instead of the internal
  tuple_element API.
* Ref #2741
@Naios

This comment has been minimized.

Show comment
Hide comment
@Naios

Naios Jul 30, 2017

Contributor

@taeguk I'm really sorry for the inconveniences.
The build fix for MSVC 2015 is provided in #2787.

As temporary workaround you may cherry-pick the fix locally:

git remote add msvcfix https://github.com/Naios/hpx.git
git fetch msvcfix
git cherry-pick 320f515335b43f0342

Or as alternative you could exclude this PR from your locale history through interactive rebasing git rebase -i 2bd90f07b3a5.

Contributor

Naios commented Jul 30, 2017

@taeguk I'm really sorry for the inconveniences.
The build fix for MSVC 2015 is provided in #2787.

As temporary workaround you may cherry-pick the fix locally:

git remote add msvcfix https://github.com/Naios/hpx.git
git fetch msvcfix
git cherry-pick 320f515335b43f0342

Or as alternative you could exclude this PR from your locale history through interactive rebasing git rebase -i 2bd90f07b3a5.

@taeguk

This comment has been minimized.

Show comment
Hide comment
@taeguk

taeguk Jul 30, 2017

Member

@Naios Thanks for your fast fix!
Don't worry for me. I'm already doing my works in the point which this PR is not applied.

Member

taeguk commented Jul 30, 2017

@Naios Thanks for your fast fix!
Don't worry for me. I'm already doing my works in the point which this PR is not applied.

Naios added a commit to Naios/hpx that referenced this pull request Jul 31, 2017

Fix a potential unconditial moves in hpx::util::tuple_cat
* Thanks to K-ballo for pointing this out
* We use hpx::util::get now for retrieving a specific
  element at index i instead of the internal
  tuple_element API.
* Ref #2741

Naios added a commit to Naios/hpx that referenced this pull request Jul 31, 2017

Fix a potential unconditial moves in hpx::util::tuple_cat
* Thanks to K-ballo for pointing this out
* We use hpx::util::get now for retrieving a specific
  element at index i instead of the internal
  tuple_element API.
* Ref #2741
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment