Menu
▾
▴
Re: [Tuningforkvp-users] Timeline Graphs.
|
From: Donnie J. <do...@da...> - 2008-09-03 15:25:03
|
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 >> >> >> > |
