Menu
▾
▴
Re: [Tuningforkvp-users] Timeline Graphs.
|
From: Donnie J. <do...@da...> - 2008-10-30 01:14:36
|
Hello David, I am following up to see if any progress has been made on the Timeline graphs for Tuning Fork that we previously discussed. Thank you. __ Donnie Jones On Tue, Sep 9, 2008 at 2:30 PM, Donnie Jones <do...@da...> wrote: > Hello David, > > Please try to email me once code is checked in, so I test it out. :) > Thanks for the help. > __ > Donnie > > > On Wed, Sep 3, 2008 at 11:41 AM, David F. Bacon <df...@wa...>wrote: > >> other projects have occupied my time. we're about to make a push to get a >> stable release of tuningfork out by the end of the month, so i hope to have >> the feature in by then. >> david >> >> >> On Sep 3, 2008, at 11:25 AM, Donnie Jones wrote: >> >> Hello David, >> >> Just wanted to follow-up, any updates on the [State|Category]TimeInterval >> support in Tuning Fork? Were you able to use my trace file as a test case? >> >> Cheers. >> __ >> Donnie >> >> On Thu, Aug 14, 2008 at 3:10 PM, Donnie Jones <do...@da...> wrote: >> >>> Hello David, >>> >>> Linked below is my trace output, "TfCapTimerEventsMultFeedlets.trace", >>> which is a simulation of random states, not actual program behavior, so >>> don't expect the "states" to make sense. ;) >>> >>> >>> http://darthik.com/tuning_fork/ghc/traces/TfCapTimerEventsMultFeedlets.trace >>> >>> This file represents two feedlets, which is a feedlet for each thread >>> ("Capabilities" in our case), in which during the simulated execution the >>> threads randomly start and stop particularly "states" for a random time >>> period. The "states" are represented by integer values, but also have >>> string descriptions for the labels. >>> >>> Let me know if you have any issues with my trace file. >>> Thank you. >>> __ >>> Donnie >>> >>> On Thu, Aug 14, 2008 at 1:29 PM, David F. Bacon <df...@wa...>wrote: >>> >>>> if you change it to emit ints and send me a trace file, i'll use that as >>>> a test case. >>>> david >>>> >>>> >>>> On Aug 14, 2008, at 12:17 PM, Donnie Jones wrote: >>>> >>>> Hello David, >>>> >>>> I used doubles simply because the example in the CTraceGenerationLibrary >>>> used doubles. They are actually integers, but I was just mocking the >>>> example in an attempt to decrease possible errors in my tests. They are >>>> definitely "states" / "categories" represented by integers. >>>> >>>> Would you still like for me to send you my test trace file so you can >>>> try it as a test case? >>>> >>>> Sorry for the confusion. >>>> __ >>>> Donnie >>>> >>>> On Thu, Aug 14, 2008 at 12:05 PM, David F. Bacon <df...@wa...>wrote: >>>> >>>>> why are the states doubles? if they really are "states" or >>>>> "categories", then they ought to form a dense set of integers. >>>>> david >>>>> >>>>> >>>>> On Aug 14, 2008, at 11:18 AM, Donnie Jones wrote: >>>>> >>>>> Hello David, >>>>> >>>>> On Thu, Aug 14, 2008 at 10:46 AM, David F. Bacon <df...@wa...>wrote: >>>>> >>>>>> ah, i see. doing the eventtypespace extension wouldn't be hard. we >>>>>> mostly need a convention about how you name the start/stop events and where >>>>>> the state value lives (in the start or in the end event). >>>>>> >>>>>> i think it could be done simply by using the same name ("Interval >>>>>> Start: foo") and looking at the event type to see whether it has an integer >>>>>> field or not. it could also look at both the start and stop events for the >>>>>> integer field, with the requirement that there be an integer field in >>>>>> exactly one of those. if that makes sense to everyone, i could hack that in >>>>>> tomorrow probably. >>>>>> >>>>>> david >>>>>> >>>>>> >>>>> Per your guidance in previous emails, my test case does exactly what >>>>> you suggest --- "Interval Start: foo" and "Interval Stop: foo" with one of >>>>> the two events containing a double field for the state. >>>>> >>>>> However, IMHO, I find it more intuitive for both the "Start" and "Stop" >>>>> events to contain the state field, as it seems more consistent to me. I'm >>>>> not sure if that changes your implementation, or how you might handle an >>>>> error in which the state doesn't match for both the "Start" and "Stop" >>>>> events. Just something to ponder... >>>>> >>>>> We greatly appreciate your willingness to consider adding the >>>>> [State|Category]TimeInterval support. >>>>> Thank you. :) >>>>> __ >>>>> Donnie >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Aug 14, 2008, at 9:47 AM, Joshua Auerbach wrote: >>>>>> >>>>>> Just to clarify, when you say "add support to the trace library" I >>>>>>> assume >>>>>>> you mean "add support to both high level libraries (Java and C++) and >>>>>>> to >>>>>>> the generic EventTypeSpace." I agree that you wouldn't add support >>>>>>> to the >>>>>>> EventTypeSpace without matching support in those libraries that are >>>>>>> specifically designed to feed it. But, Donnie is using the C library >>>>>>> which >>>>>>> lacks high level event construction functions ... he is already doing >>>>>>> the >>>>>>> event construction manually. What he really needs is the support at >>>>>>> the >>>>>>> other end (in the generic EventTypeSpace). Of course, somewhat >>>>>>> higher >>>>>>> level functionality in the C library would be nice, too, but adding >>>>>>> support >>>>>>> for [State|Category]TimeInterval alone, without also adding support >>>>>>> for >>>>>>> TimeInterval and Sample would be illogical. >>>>>>> >>>>>>> Josh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> "David F. Bacon" >>>>>>> <df...@wa....c >>>>>>> om> >>>>>>> To >>>>>>> Joshua >>>>>>> Auerbach/Watson/IBM@IBMUS >>>>>>> 08/14/2008 09:36 >>>>>>> cc >>>>>>> AM Donnie Jones < >>>>>>> do...@da...>, >>>>>>> Simon Marlow < >>>>>>> mar...@gm...>, >>>>>>> >>>>>>> tun...@li... >>>>>>> e.net, Jost Berthold >>>>>>> <t-j...@mi...>, Hai >>>>>>> Chuan >>>>>>> Wang <wan...@cn...> >>>>>>> >>>>>>> Subject >>>>>>> Re: [Tuningforkvp-users] >>>>>>> Timeline >>>>>>> Graphs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> i think we should probably add support to the trace library for >>>>>>> StateTimeIntervals. hai chuan, are you interested in doing that? >>>>>>> also, we were planning on renaming them to CategoryTimeInterval. hai >>>>>>> chuan, are you ready for that? do you want to do it fro your side >>>>>>> and commit it? that would avoid breaking the thor code. >>>>>>> >>>>>>> david >>>>>>> >>>>>>> >>>>>>> On Aug 14, 2008, at 6:58 AM, Joshua Auerbach wrote: >>>>>>> >>>>>>> Since the difference between a TimeInterval and a StateTimeInterval >>>>>>>> is >>>>>>>> fairly minor, I don't know if we would create a whole new >>>>>>>> EventTypeSpace or >>>>>>>> just add support for StateTimeIntervals to our existing generic >>>>>>>> EventTypeSpace and I don't know the timeframe for doing either; >>>>>>>> David can >>>>>>>> comment on that. >>>>>>>> >>>>>>>> But, meanwhile, I am working on something that could allow somewhat >>>>>>>> advanced end-users like yourself (e.g., people who know what's in >>>>>>>> their >>>>>>>> specialized feeds but don't want to do Java hacking on Tuningfork >>>>>>>> itself) >>>>>>>> to derive some of these more advanced kinds of streams without >>>>>>>> writing an >>>>>>>> EventTypeSpace. This facility (called ForkTalk) is already >>>>>>>> starting to >>>>>>>> appear in the code but will only become functional probably later >>>>>>>> this week >>>>>>>> (and will still be kind of buggy for a while). If you send me a >>>>>>>> sample >>>>>>>> trace that has your new state events in it, I will use it as a test >>>>>>>> case. >>>>>>>> Then, perhaps in a week or two, it *might* be able to do what you >>>>>>>> want. I >>>>>>>> can't really promise but it does seem like this is a case that >>>>>>>> ForkTalk >>>>>>>> should handle easily. >>>>>>>> >>>>>>>> Josh >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "Donnie Jones" >>>>>>>> <donnie@darthik.c >>>>>>>> >>>>>>>> om> To >>>>>>>> Joshua Auerbach/Watson/ >>>>>>>> IBM@IBMUS >>>>>>>> 08/11/2008 >>>>>>>> 12:07 cc >>>>>>>> PM "David F. Bacon" >>>>>>>> <df...@wa...>, "Simon >>>>>>>> Marlow" >>>>>>>> <mar...@gm...>, "Jost >>>>>>>> Berthold" <t- >>>>>>>> jo...@mi...>, >>>>>>>> tuningforkvp- >>>>>>>> us...@li... >>>>>>>> e.net, >>>>>>>> tuningforkvp-users- >>>>>>>> bo...@li... >>>>>>>> urceforge.net >>>>>>>> >>>>>>>> Subject >>>>>>>> Re: [Tuningforkvp-users] >>>>>>>> Timeline >>>>>>>> Graphs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hello Josh, >>>>>>>> >>>>>>>> On Fri, Aug 8, 2008 at 9:13 AM, Joshua Auerbach <jo...@us...> >>>>>>>> wrote: >>>>>>>> David may want to answer as well, but since part of your question >>>>>>>> involves >>>>>>>> the C tracing library, which he may not know in detail, I will >>>>>>>> attempt an >>>>>>>> answer. >>>>>>>> >>>>>>>> Honestly, I'm not sure what you mean by "primitive events". The >>>>>>>>> closest description to "primitive events" I have found in the C >>>>>>>>> Trace Generation Library would be "AddSimpleEvent()". Would >>>>>>>>> AddDoubleEvent() satisfy for generating the "primitive events" with >>>>>>>>> the "state" variable? >>>>>>>>> >>>>>>>> >>>>>>>> Your goal is to generate events that can later be used to >>>>>>>> reconstruct a >>>>>>>> StateTimeInterval, which has a timestamp like any event >>>>>>>> (representing a >>>>>>>> start time), another long representing the end time, and a state, >>>>>>>> represented as an int. Right now I believe you are just using two >>>>>>>> events, >>>>>>>> named appropriately, to cause an ordinary TimeInterval to be >>>>>>>> generated. >>>>>>>> Well, you would still use two events, given that that is working >>>>>>>> for you >>>>>>>> now. One of them (either the start or the end) would continue to >>>>>>>> be a >>>>>>>> simple event with just a timestamp. The other would be created >>>>>>>> with >>>>>>>> tfAddIntEvent so that it conveys both a timestamp and a state. >>>>>>>> Whether >>>>>>>> you >>>>>>>> record the state at the start of the interval or at the end is up >>>>>>>> to you. >>>>>>>> You would also have to use tfAddEventType to define both events, >>>>>>>> but I >>>>>>>> think you are already doing that. The difference is that one of >>>>>>>> the two >>>>>>>> events would have an additional int attribute. >>>>>>>> >>>>>>>> I was attempting something similar but including the "state" in >>>>>>>> both the >>>>>>>> start and stop events with tfAddIntEvent(). Thank you for the >>>>>>>> clarification. >>>>>>>> >>>>>>>> >>>>>>>> How do I go about creating an event typespace in Tuning Fork? Use >>>>>>>>> "derive stream" in Tuning Fork? I only see an "event typespace" >>>>>>>>> mentioned in the trace generation libraries, not in the Tuning Fork >>>>>>>>> >>>>>>>> GUI/menus. >>>>>>>> >>>>>>>> This is a Java coding activity, not an end-user GUI activity. In >>>>>>>> the >>>>>>>> source, you can get a sense of what is involved by >>>>>>>> looking at the EventTypeSpace class and its many subclasses (for >>>>>>>> example, >>>>>>>> use the type hierarchy view in Eclipse). This may not be the way >>>>>>>> to go >>>>>>>> if >>>>>>>> you are not comfortable with Eclipse's plugin structure, since >>>>>>>> you need a >>>>>>>> plugin that extends the >>>>>>>> com.ibm.tuningfork.core.eventTypeSpaceFactory >>>>>>>> extension point in order to do this cleanly. If you want to >>>>>>>> delve in, we >>>>>>>> can provide more guidance. On the other hand, perhaps you just >>>>>>>> want to >>>>>>>> stay at the user level and wait for some more GUI support for >>>>>>>> what you >>>>>>>> want >>>>>>>> to do. >>>>>>>> >>>>>>>> >>>>>>>> Hmm, at this point, it would definitely be preferred to stay at the >>>>>>>> user >>>>>>>> level and hope for GUI support that provides the graphing >>>>>>>> capabilities that >>>>>>>> I desire. Any idea if the EventTypeSpace that I am needing may be >>>>>>>> added >>>>>>>> soon? :) >>>>>>>> >>>>>>>> Both you and David have been extremely helpful. >>>>>>>> Thank you. >>>>>>>> __ >>>>>>>> Donnie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>>>>> challenge >>>>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>>>> great prizes >>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>>>>> the world >>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>>>> _______________________________________________ >>>>>>>> Tuningforkvp-users mailing list >>>>>>>> Tun...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/tuningforkvp-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>> world >>>> >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________ >>>> Tuningforkvp-users mailing list >>>> Tun...@li... >>>> https://lists.sourceforge.net/lists/listinfo/tuningforkvp-users >>>> >>>> >>>> >>> >> >> > |
