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
Louis Dionne
@ldionne
That seems accurate to me?
Jason Rice
@ricejasonf
mabye I'm being a noob, but the lambda makes it look like it could be used like a function object
at_c actually has a note stating this though
tiny, tiny nitpick
lol sorry
Louis Dionne
@ldionne
OH
Jason Rice
@ricejasonf
wait.. is it a function object?
that's why value_of exists right?
"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