Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: Reverting merges to master (Hartmut Kaiser)
2. Re: Reverting merges to master (Agust?n K-ballo Berg?)
3. GSoC Weekly Report (Devang Bacharwar)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jun 2015 11:27:51 -0500
From: "Hartmut Kaiser" <[email protected]>
Subject: Re: [hpx-devel] Reverting merges to master
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
> On 6/16/2015 12:24 PM, Hartmut Kaiser wrote:
> >>>> Reverting broken code would then be an orthogonal question.
> >>>
> >>> Right, and that's a purely procedural question I wanted to discuss.
> >>
> >> So the question, if I understand it correctly, is why would we want to
> >> revert (or not revert) broken changes that build on top of pre-existing
> >> broken code?
> >
> > The change is not broken (at least not as far as I can see), it's the
> > pre-existing code which is broken.
>
> I did not mean to imply that the changes in itself are wrong, but I see
> it reads that way. Would you adjust the question as appropriate then?
Should we revert changes to master which make problems show up even if the
problems are unrelated to the changes applied (the problems are caused by
issues in pre-existing code)?
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
------------------------------
Message: 2
Date: Tue, 16 Jun 2015 13:39:36 -0300
From: Agust?n K-ballo Berg? <[email protected]>
Subject: Re: [hpx-devel] Reverting merges to master
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format=flowed
On 6/16/2015 1:27 PM, Hartmut Kaiser wrote:
>> On 6/16/2015 12:24 PM, Hartmut Kaiser wrote:
>>>>>> Reverting broken code would then be an orthogonal question.
>>>>>
>>>>> Right, and that's a purely procedural question I wanted to discuss.
>>>>
>>>> So the question, if I understand it correctly, is why would we want to
>>>> revert (or not revert) broken changes that build on top of pre-existing
>>>> broken code?
>>>
>>> The change is not broken (at least not as far as I can see), it's the
>>> pre-existing code which is broken.
>>
>> I did not mean to imply that the changes in itself are wrong, but I see
>> it reads that way. Would you adjust the question as appropriate then?
>
> Should we revert changes to master which make problems show up even if the
> problems are unrelated to the changes applied (the problems are caused by
> issues in pre-existing code)?
**Why** should we revert changes to master which make problems show up
~~even if the problems~~ that are unrelated to the changes applied?
Unless you do mean "even if", in which case it sounds more like:
**Why** should we revert changes to master which make problems show up?
And then, if there is any rationale for reverting changes which make
problems show up, those may or may not apply to problems unrelated to
the changes applied.
Regards,
--
Agust?n K-ballo Berg?.-
http://talesofcpp.fusionfenix.com
------------------------------
Message: 3
Date: Tue, 16 Jun 2015 22:26:06 +0530
From: Devang Bacharwar <[email protected]>
Subject: [hpx-devel] GSoC Weekly Report
To: "<[email protected]>" <[email protected]>,
Patricia Grubel <[email protected]>
Message-ID:
<cab4vc7d34oog8dtqs1tnak3ednb73vqnknfvgx8jznj-vxv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear All,
Done:
-> Read
http://stellar.cct.lsu.edu/files/hpx_0.9.5/html/hpx/manual/performance_counters.html
http://stellar.cct.lsu.edu/files/hpx_0.9.5/html/hpx/manual/performance_counters/providing.html
http://stellar.cct.lsu.edu/files/hpx_0.9.5/html/hpx/manual/performance_counters/names.html
-> Read up on different counters
-> Setted up and built hpx on hermione
-> Ran tests and got counters for different examples
-> Ran tests/timed_task_spawn.cpp to get CSV outputs
-> Finished exams
-> Figured out the functions to be used to get good CSV format out of
timed_task_spawn
To-Do:
-> Figure out the libraries being used to get counter values for regular
examples
-> Read up the library being used for getting counter data for regular
applications
-> Start coding up library for getting CSV output for any application.
Need help:
-> Figuring out which library is being used to get counter values for every
application
-> As per my understanding I am planning to integrate print_results,
format_build_date from tests/timed_task_spawn.cpp into the library that is
being already used to get counters from any application.
-> There are various distributions in timed_task_spawn like round
robin, static-balanced-stackless, static-balanced-stackbased,
static-imbalanced.
I will need some understanding on these and what are they needed for and
how'll they be integrated to the library.
Devang
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20150616/30095d43/attachment-0001.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 21, Issue 12
*****************************************
