Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 2019 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 2019 02:04
    pthom commented #432
  • Jan 18 2019 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 2019 22:27
    ricejasonf commented #434
  • Jan 05 2019 06:22
    ricejasonf commented #330
  • Jan 03 2019 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 2019 00:33
    ricejasonf closed #434
  • Jan 02 2019 00:33
    ricejasonf commented #434
  • Jan 02 2019 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Jason Rice
@ricejasonf
The standard 'directive' is a pair(tag, map). That test takes about 3 seconds to compile. (with the old map)
Louis Dionne
@ldionne
Hmm, I’d have to take a closer look. I’m neck deep until next Sunday, after which I’ll have more time to look at this.
Jason Rice
@ricejasonf
np
Louis Dionne
@ldionne
Sorry, but I’m taking the plane tomorrow morning and I have a bunch of fires to put out.
But 3 seconds is certainly better than I would have expected. With a different map implementation or design, we should be able to reduce this. We’ll talk about this when I’m back, as it’s 100% related to your pull request. BTW, in the meantime, you might want to take a look at this.
I’m thinking more and more that the right way to go is in fact to use a hash-based map. The hash would be a type, not an integer, however. And then we would linear-search in each bucket, which could be a tuple.
This way, we would get O(1) lookup for hana::type, hana::string and basically any other singleton type, by design.
Louis Dionne
@ldionne
Just keep this idea around in your head, and we’ll discuss it further if you want.
Jason Rice
@ricejasonf
Yes, I look forward to it.
Maik Klein
@MaikKlein
Did anyone run into a compiler seqfault with clang 3.7 + hana yet?
Maik Klein
@MaikKlein
Just came back to some old code :d
template <class Tup>
auto tuple_ref(Tup&  tup)
{
  return hana::transform(tup, [](auto& t) { return std::ref(t); });
}

   ....
    auto cg_ref = tuple_ref(component_groups_tuple);
    auto filterd_cg_ref = hana::filter(cg_ref, [](auto& cg) {
      return hana::bool_c<true>;
    });
Seems like something weird is going on with std::reference_wrapper and filter, I will try to make an isolated example later.
Maik Klein
@MaikKlein
struct position
{
  float x, y;
};
struct velocity
{
  float x, y;
};

int main()
{
  auto tup = hana::make_tuple(position{1,2}, velocity{1,2});
  auto tup_ref =  hana::transform(tup, [](auto& t) { return std::ref(t); });
  auto test = hana::filter(tup_ref, [](auto& tref){
    return hana::bool_c<true>;
  });
}
1.      <eof> parser at end of file
2.      ../dependencies/hana/include/boost/hana/filter.hpp:103:18: instantiating function definition 'operator()'
3.      ../dependencies/hana/include/boost/hana/filter.hpp:103:18: LLVM IR generation of declaration 'boost::hana::detail::make_filter_indices<(lambda at ../examples/ecs/main.cpp:113:37)>::operator()'
4.      ../dependencies/hana/include/boost/hana/filter.hpp:103:18: Mangling declaration 'boost::hana::detail::make_filter_indices<(lambda at ../examples/ecs/main.cpp:113:37)>::operator()'
clang-3.7: error: unable to execute command: Segmentation fault (core dumped)
clang-3.7: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang-3.7: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang-3.7: note: diagnostic msg:
This is in master, works in 0.6.0. Just wanted to let you know. Should I make a github issue?
Maik Klein
@MaikKlein
Haha lol now another library also results in an ICE, what is going on today.
Jason Rice
@ricejasonf
Is that using libstd++?
Maik Klein
@MaikKlein
don't know, is libstd++ default in clang?
Jason Rice
@ricejasonf
It depends on the system. Linux distros typically use libstd++. My version of Ubuntu uses gcc 5.0 by default which has bugs that break hana. When I upgraded to 5.1 they went away. (It was throwing up with large maps https://gist.github.com/ricejasonf/c2cd831d207912583549#file-large_map_1-cpp)
@MaikKlein ^
Maik Klein
@MaikKlein
Should I use libc++ or libstdc++?
Jason Rice
@ricejasonf
I guess libc++ is better, but I use libstd++ because my system libraries are compiled with it.
but it needs to be >=5.1
Maik Klein
@MaikKlein

btw is there some restriction in hana::filter?

    auto components_filter = hana::filter(components_ref, [&filter](auto cref) {
      return contains_type(filter, cref.get());
    });

If I create a custom move constructor for the type of cref it doesn't compile anymore and throws

../dependencies/hana/include/boost/hana/basic_tuple.hpp:168:20: error: no matching function for call to object of type 'boost::hana::detail::make_filter_indices<(lambda at ../src/ecs/core/core.hpp:39:59)>'
            return static_cast<F&&>(f)(
No idea what to make of it
cref is also a reference_wrapper of type T where type T has a custom move constructor.
Jason Rice
@ricejasonf
does it say anything about the candidate functions?
maybe it has something to do with the decay that was added
Maik Klein
@MaikKlein
It's this
return Unpack::apply(static_cast<Xs&&>(xs), static_cast<F&&>(f));
I try to make a self contained example
Jason Rice
@ricejasonf
Is there anything like this in your errors? "candidate template ignored: substitution failure"
Maik Klein
@MaikKlein
yes
note: candidate template ignored: substitution failure [with X = <const std::reference_wrapper<breeze::util::container::handle_container<position, std::vector<position, std::allocator<position> > > > &, const std::reference_wrapper<breeze::util::container::handle_container<velocity, std::vector<velocity, std::allocator<velocity> > > > &>]
            auto operator()(X&& ...x) const -> filter_indices<
nvm oh my god
Maik Klein
@MaikKlein
I am so stupid
Jason Rice
@ricejasonf
What does your contains_type function return?
Maik Klein
@MaikKlein
lol
constexpr auto contains_type(Tup&& tup, T)
forgot to make it T&
god damn it that should have been obvious
Jason Rice
@ricejasonf
for a parameter that isn't used?
Maik Klein
@MaikKlein
yes
I thought it shouldn'T matter
Jason Rice
@ricejasonf
lol.... "shouldn'T"
Maik Klein
@MaikKlein
template <class Tup, class T>
constexpr auto contains_type(Tup&& tup, T&)
{
  return hana::contains(tup, hana::type_c<T>);
}
Jason Rice
@ricejasonf
ooh
Maik Klein
@MaikKlein
Not quite sure why I got the error with static_castthough.
btw I have gcc 5.3 so I think my library should be recent enough?
Could you compile this with master?
```
struct position
{
  float x, y;
};
struct velocity
{
  float x, y;
};

int main()
{
  auto tup = hana::make_tuple(position{1,2}, velocity{1,2});
  auto tup_ref =  hana::transform(tup, [](auto& t) { return std::ref(t); });
  auto test = hana::filter(tup_ref, [](auto& tref){
    return hana::bool_c<true>;
  });
}