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 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

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

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

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

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 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
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>;
  });
}
Jason Rice
@ricejasonf
yes
Maik Klein
@MaikKlein
does it also ice for you?
Jason Rice
@ricejasonf
ice?
Maik Klein
@MaikKlein
internal compiler error
Jason Rice
@ricejasonf
no
Maik Klein
@MaikKlein
hm k
Jason Rice
@ricejasonf
It could be that you are still using an old version of libstd++ on your system
I don't remember how I fixed that on mine.
Maik Klein
@MaikKlein
I think that is the problem
readelf -sV /usr/lib/libstdc++.so.6 | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1
gives me version 3.4.21
Jason Rice
@ricejasonf
I want to say changing the symlink for the g++ binary fixed it.
Maik Klein
@MaikKlein
does the command above print 5.1 for you?
Jason Rice
@ricejasonf
jason@jason-nuc:/usr/lib/gcc/x86_64-linux-gnu/5.1.0$ readelf -sV libstdc++.so | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1
3.4.21
Jason Rice
@ricejasonf
@ldionne It occurred to me that I could give you push access to my fork if that is easier than having a branch in the upstream repo. (wrt #226)
Louis Dionne
@ldionne
Or I could just create that damn branch on the upstream. I’m sorry it’s been so long. The thing is that this PR is actualy a huge chunk; it’s hard to tell whether we’re improving or not, and there are also other approaches (hashing) available. 1 minute
Jason Rice
@ricejasonf
I'm not in a hurry or anything so no rush. ;)
We could always have multiple branches with different tweaks to run benchmarks on and contrast and compare.
I was actually thinking about making another PR to attempt to improve hana::pair. (maybe it would be faster if it wasn't a wrapper for a basic_tuple idk)
Louis Dionne
@ldionne
Yes, in retrospect I think that would be better. You can see my (rather extensive) changes here
I also removed the fast lane for looking up hana::types, since it was broken (the specialization would never match), and I did not take time to reimplement it properly.