Menu
▾
▴
Re: [Tuningforkvp-users] Timeline Graphs.
|
From: David F. B. <df...@wa...> - 2008-09-03 15:43:28
|
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...>, >>> tuningforkvp- >>> us...@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 > > > |
