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
Jason Rice
@ricejasonf
ahh. ty
Louis Dionne
@ldionne
no problem
Jason Rice
@ricejasonf
{
  "title": {
    "text": "Compile-time behavior of at_key (look-up)"
  },
  "series": [
    {
      "name": "hana::tuple",
      "data": [[1, 0.5843498889589682], [6, 0.5881277859443799], [11, 0.6016017539659515], [16, 0.6185176270082593], [21, 0.6080989820184186], [26, 0.6109987029340118], [31, 0.619547626003623], [36, 0.626124283997342], [41, 0.6321631050668657], [46, 0.6390265320660546], [50, 0.6391948240343481], [75, 0.6661797270644456], [100, 0.6941793729783967], [125, 0.7158015809254721], [150, 0.739832898019813], [175, 0.7598226980771869], [200, 0.7836178879952058]]
    }, {
      "name": "hana::map",
      "data": [[1, 0.5030448969919235], [6, 0.502195259090513], [11, 0.5132971929851919], [16, 0.5068044670624658], [21, 0.5084114259807393], [26, 0.5053818440064788], [31, 0.5080094380537048], [36, 0.5079091669758782], [41, 0.5034812879748642], [46, 0.503438972053118], [50, 0.505198840983212], [75, 0.5013905420200899], [100, 0.5058683169772848], [125, 0.502474538050592], [150, 0.50477908202447], [175, 0.501015709945932], [200, 0.5029300260357559]]
    }, {
      "name": "hana::set",
      "data": [[1, 0.7033674489939585], [6, 0.7088698920561001], [11, 0.7151512850541621], [16, 0.7211668869713321], [21, 0.7242649940308183], [26, 0.7450731740100309], [31, 0.740562021965161], [36, 0.751805328996852], [41, 0.7428800358902663], [46, 0.7465192109812051], [50, 0.7522268139291555], [75, 0.788819869980216], [100, 0.801227223011665], [125, 0.8309568869881332], [150, 0.848692536004819], [175, 0.8715615950059146], [200, 0.896686622989364]]
    }
  ]
}
This message was deleted
^ That is with a light weight Product :D
Louis Dionne
@ldionne
Awesome! FYI, I’ve been doing changes to your patch and I’ll soon be ready to discuss them with you.
I’ve been busy with holidays (it’s over now!), which is why it took so long.
Jason Rice
@ricejasonf
@ldionne Cool. I'm looking forward to it.
Jason Rice
@ricejasonf

demux is freakin' awesome

      hana::unpack(hana::keys(state),
        hana::make_map ^hana::on^
        hana::demux(hana::make_pair)
        (
          hana::id,
          hana::demux(hana::maybe)
          (
            hana::partial(hana::at_key, state),
            hana::always(hana::just),
            hana::partial(hana::find, x)
          )
        )
      );

:sunglasses:

Jason Rice
@ricejasonf
It is probably just an oddity of bad form, but if you try to print a hana::map_tag{}, it will try to print it as a map because of the idempotent tag_of thing. (I just wrapped it in a type_c though).
Louis Dionne
@ldionne
Yeah, the map_tag thing is mostly an oddity, although one I had not thought about.
demux is very, very powerful. It was originally introduced as a way of working around the lack of constexpr lambdas. Unfortunately, it is a bit difficult to grok complicated expressions like the above. Soon, we should have constexpr lambdas in the language, and it should be more straightforward to write the above.
Jason Rice
@ricejasonf
idk I kind of like it :P
Louis Dionne
@ldionne
While fun to write, I challenge you to re-read this a month from now and to tell me what it does in less than 15 seconds. You can’t :smile:
Jason Rice
@ricejasonf
  template<typename... Tag>
  constexpr auto withSettings(Tag&&... tag) const
  {
    auto initial_state = mpdef::withSettings(std::forward<Tag>(tag)...);
    auto collectFinal =
        hana::reverse_partial(hana::transform,
          hana::reverse_partial(hana::unpack, //pair
            hana::demux(hana::make_pair)
            (
              hana::arg<1>,
              hana::flip(mpdef::collectSettings)
            )));
    return hana::curry<2>(hana::demux(collectFinal)
      (
       //(tree, summarize, pred)
        hana::demux(hana::partial(hana::flip(*this), initial_state))
        (hana::arg<2>, hana::always(mpdef::collectSettings), hana::arg<1>)
      )
    );
  }
I had to break that one up
Louis Dionne
@ldionne
@ricejasonf Do you know how I could share my changes to your patch with you? GitHub doesn’t have collaborative pull requests, and I’d like a way to discuss over my changes to your patch.
I could fork your fork of Hana and then submit a PR to your benchmarks/map branch. But that seems clunky, and it would break the automatic redirect from ldionne/hana to boostorg/hana, which is useful because I moved the repository to boostorg.
Jason Rice
@ricejasonf
You could put it into its own branch.
Louis Dionne
@ldionne
Right, I think that’s what I’ll do.
Jason Rice
@ricejasonf
@ldionne What do you think of this? I was playing around with matchers on a sort of 'abstract meta info tree' using nested hana containers. https://github.com/ricejasonf/nbdl/blob/8f255d5d3ec334fcae2d814a298f19047bd9d206/test/mpdef/find_in_tree.cpp
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