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
Louis Dionne
@ldionne
But if you pass arrays as named parameters, they’ll have to be moved (which may be inefficient).
Or you can store the arguments with std::reference_wrappers, but then you’ll have to use args[“a”_param].get() inside the function.
Jason Rice
@ricejasonf
Would it be possible to add that auto operator= to type and integral_constant?
This message was deleted
Jason Rice
@ricejasonf
You mentioned some things about improving map before. I would like to discuss it, when you are not too busy.
Louis Dionne
@ldionne

Would it be possible to add that auto operator= to type and integral_constant?

You mean to create pairs? I think that's clearly out of Hana's scope, since Hana is a general purpose library, not a named parameter library. The right approach would be for you to create wrappers over type and integral_constant. Or more generally, I would probably do something like

template <typename Param>
struct param_t {
    // define operator=
};

template <typename Param>
constexpr param_t<Param> param{};

Then, you can use the thing as

f(param<hana::int_<3>> = "three", param<hana::type<int>> = "int", ...);

The syntactic overhead is very reasonable, and it clearly says what it's doing. Just my .02.

You mentioned some things about improving map before. I would like to discuss it, when you are not too busy.

I'd be happy to discuss it. I'll try to put my thoughts on paper and I'll create an issue documenting them. Then, we can talk about it either here or on GitHub. Sounds reasonable?

Jason Rice
@ricejasonf
:thumbsup:
Jason Rice
@ricejasonf
About the param thing, yeah, creating a wrapper is simple enough and I will do that, but I was speaking to constructing maps in general. (nbd of course)
constexpr auto foo = hana::type_c<int>;
constexpr auto bar = hana::type_c<double>;

hana::make_map(
    foo       = "foo",
    bar       = "bar",
    "foo"_s   = "foo",
    "bar"_s   = "bar",
    5_c       = "five",
    42_c      = "forty-two"
);
that's probably not that useful though
Louis Dionne
@ldionne

But then the following fails, because assignment is not what we expect it to be:

hana::tuple<int, int, hana::type<char>> t{1, 2, {}};
hana::tuple<int, int, hana::type<char>> u{3, 4, {}};
t = u;

Actually, it will even compile but fail to do the right thing. Since type, integral_constant & al are stateless this is OK strictly speaking (assignment has no effect anyway), but I really think this is conceptually wrong.

Jason Rice
@ricejasonf
yeah I guess that would be an abuse :sweat_smile:
Louis Dionne
@ldionne
@ricejasonf See #223 regarding hana::map optimizations.
@ricejasonf It’s not an easy one to tackle, but if you’re willing to give it a shot I’ll provide guidance and help as needed.
Btw, this is likely the single most important improvement that can be done to Hana right now. But it’s a chunk of work.
Jason Rice
@ricejasonf
@ldionne Yes, I definitely want to take a crack at this. :D I'll have to do some digging as to how you are automating benchmarks and their results.
Louis Dionne
@ldionne
Just ask if you need guidance.
Jason Rice
@ricejasonf
Do you know how to get cmake to look for ruby in /usr/local/bin ?
Louis Dionne
@ldionne
Hmm, it should probably look in that place on its own.
1 minute
Jason Rice
@ricejasonf
oh sorry.. I had to remove CMakeCache.txt I think
I was thinking there was a RUBY_ROOT option or something
Louis Dionne
@ldionne
I don’t see any RUBY_ROOT option in the documentation of the FindRuby.cmakemodule. If it does not work ,you can try adding /usr/local/bin to CMAKE_FIND_ROOT_PATH.
Jason Rice
@ricejasonf
heh.. I apt-get remove --purge ruby'd and then realized it was probably just stuck in CMakeCache.txt.
Louis Dionne
@ldionne
Does it work now?
Jason Rice
@ricejasonf
yep
sorry to bother you
Louis Dionne
@ldionne
No problem, really. The benchmarking system isn’t the prettiest thing, so don’t hesitate to let me know if you don’t understand or run into problems.
And if you have ideas to improve it, let me know.
Jason Rice
@ricejasonf
is there a limit to size on your static doc site?
var hana = github.getRepo('boostorg', 'hana');
    hana.getRef('heads/datasets', function(err, sha) {
      var repo = "https://cdn.rawgit.com/boostorg/hana/" + sha + "/release/clang-3.6.2/";
      $(".benchmark-chart").each(function(index, div) {
        var dataset = div.getAttribute("damplement efficiently, because it requires stopping at the first element which satisfies the given predicate. For the same reason, modern techniques don't really help us here, so this algorithm constitutes a good test of the implementation quality of Hana, without taking into account the free lunch given to use by C++14.
          Number of elementsTime (s)Compile-time behavior of findta-dataset");
        $.getJSON(repo + dataset, function(options) {
          Hana.initChart($(div), options);
        });
      });
that div.getAttribute argument looks awfully suspicious
Jason Rice
@ricejasonf
It looks like repo points to an absolute url which means the charts aren't coming from the same build
Louis Dionne
@ldionne
The charts in the documentation are always pointing to the latest charts. I know, this is wrong.
Couldn’t figure out how to do it differently.
But I can’t find that div.getAttribute, where is it?
What this "damplement efficiently, because it require…”?
Jason Rice
@ricejasonf
lol.. I was guessing that it is some kind of code generation bug
an attribute name is like class or style or something :laughing:
Louis Dionne
@ldionne
Where did you find this?
Jason Rice
@ricejasonf
the top of index.html
yeah the prod site actually says var dataset = div.getAttribute("data-dataset");
Louis Dionne
@ldionne
My local build/doc/index.html is also fine, showing ”data-dataset”.
Jason Rice
@ricejasonf
it's also statically set in header.html..
Louis Dionne
@ldionne
Disregard the generated documentation. What you need to look at is the doc/ subdirectory. There, you’ll find header.html which is pulled in a the top of each html page by Doxygen.
Jason Rice
@ricejasonf
sorry, I think the cat walked across the keyboard or something.. no idea how that got there
What if we pull the benchmark json files into the web root?
Jason Rice
@ricejasonf
or should I say "would it be okay?"
Louis Dionne
@ldionne
Yes, it would, but how would you do that? The benchmarks are generated on Travis CI in a separate job as the documentation job.
Jason Rice
@ricejasonf
Ah, I see. Actually I just wanted to make an easy way to view all of the benchmarks, but since it is possibly comparing across builds perhaps it should be an external thing anyways.
Louis Dionne
@ldionne
I think it should be stored externally like on AWS ideally, but I’m also not sure it’s worth the time to set this up, since I don’t know how.