Menu
▾
▴
Re: [Tuningforkvp-users] Timeline Graphs.
|
From: David F. B. <df...@wa...> - 2008-08-14 16:09:42
|
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
>
>
>
>
|
