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
"Equivalent to value, but can be passed to higher-order algorithms."
Louis Dionne
@ldionne
Correct.
I’ll add a note to value saying it can’t be passed to higher order algorithms"
Added note in boostorg/hana@18346fd
Jason Rice
@ricejasonf
thanks :grinning:
Louis Dionne
@ldionne
Well, thanks to you actually.
Jason Rice
@ricejasonf
index_if.hpp
detail/wrong.hpp
hash.hpp
remove_at.hpp
I think these are vestigal in map.hpp
in pr/hash_map
Louis Dionne
@ldionne
Fixed locally; thanks a lot. I’ll push when the current CI finishes.
Jason Rice
@ricejasonf
ricejasonf/hana@a339cba
I branched that off of pr/types. I was thinking about giving it a stuple_detail::make_uninitialized and let functions like append, drop_front do the placement new stuff.
(it's incomplete btw)

stuple :laughing:

Jason Rice
@ricejasonf
This message was deleted
Jason Rice
@ricejasonf
reinterpret_cast denied
apparently placement new is not allowed in constexpr either
Jason Rice
@ricejasonf
constexpr is right out
:P
Louis Dionne
@ldionne
Interesting. I’ll push what I had done.
Some algorithms can be written very efficiently using this representation, like scan_left.
Jason Rice
@ricejasonf
cool
Louis Dionne
@ldionne
@ricejasonf v0.7.0 is officially out and features the new hash table! There will surely be things to fix and improve, but at least this (big) change is in.
Thanks a lot for your work!
Jason Rice
@ricejasonf
nice! 😄
Louis Dionne
@ldionne
yup
Torsten Robitzki
@TorstenRobitzki
/help
\help
Louis Dionne
@ldionne
@TorstenRobitzki If you need help, just ask :-)
Jason Rice
@ricejasonf
types shows up under Data types in the doc side menu.
Louis Dionne
@ldionne
Not anymore :-). Thanks.
Jason Rice
@ricejasonf
@ldionne When you make a new blog post could you post a link in here or on twitter or something?
Jason Rice
@ricejasonf
(please) :P
Jason Rice
@ricejasonf
Your new post made me think of your todo in or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.
Jason Rice
@ricejasonf
Is it okay to do hana::optional<T> or does one have to use decltype(hana::just(std::declval<T>())? (the doc says "implementation defined" but I'm not sure to what extent)
The docs for map say hana::map< implementation_defined > but for optional it is hana::optional<...> which makes me think it might be okay.
Louis Dionne
@ldionne
I’ll change it. Technically it’s reall implementation defined. Actually, nothing’s type is optional<>, and just(x)’s type is optional<T>.
Jason Rice
@ricejasonf
so then me using hana::optional<T> and hana::optional<> directly is okay?
Louis Dionne
@ldionne
No, it isn’t in the current state of things. But perhaps it would be useful to allow it. What’s your use case?
I wasn’t clear in my original answer. What I meant is that the types were really implementation-defined, and that you shouldn’t rely on them.
Jason Rice
@ricejasonf

I'm not sure if what I am doing is a good idea yet, but I decided to not bother wrapping tuple and just represent a message as a tuple where some 'fields' like a payload might not be present.

    BOOST_HANA_CONSTANT_ASSERT(
      builder::entityMessages(entity_map, access_point)
        ==
      hana::make_tuple(
        hana::type_c<hana::tuple<
          hana::optional<>,
          channel::Upstream,
          action::Create,
          path_type,
          hana::optional<entity::E1>,
          hana::optional<>
        >>,
        hana::type_c<hana::tuple<
          hana::optional<bool>,
          channel::Downstream,
          action::Create,
          path_type,
          hana::optional<entity::E1>,
          hana::optional<>
        >>,
      )
    );

There is also this, but after a second look maybe I should have used value_or :P
https://github.com/ricejasonf/nbdl/blob/develop/src/mpdef/CollectSettings.hpp#L25
In any case it's nbd. I'll just avoid using it that way if it remains 'implementation_defined'.

hmm.. I don't think I used value_or because I wanted that map lookup to be lazy
Louis Dionne
@ldionne
Orthogonal question: Do you see a speedup with your own map implementation?
Jason Rice
@ricejasonf
the one that uses strictly types as keys?
Louis Dionne
@ldionne
Well mpdef::make_map.
Jason Rice
@ricejasonf
I didn't compare the benchmark against your version of the hash_map but the mpdef::Map registered at .5s for 200 lookups.
Louis Dionne
@ldionne

Your new post made me think of your todo in or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.

That is correct, at least I think so. But I can't do that without losing the generality of or_'s current definition, because someone could define a new Logical that's not a bool or a boolean IntegralConstant. But even disregarding this issue, I feel like the Logical concept might be flawed. I tried to be very general, but it gives something that provides bad compile-time performance for such basic operations. I would perhaps make more sense to only define these operations on boolean IntegralConstants. We would lose the ability to branch on runtime values too, but the rest of the library does not support runtime conditions anymore anyways.

I didn't compare the benchmark against your version of the hash_map but the mpdef::Map registered at .5s for 200 lookups.

Care to send me the benchmark? Or did you already do it previously and I just forgot? I remember you showing me this graph before.

Jason Rice
@ricejasonf
I don't think I saved the code for it. I can just make it real fast.