Menu
▾
▴
Re: [Tuningforkvp-users] Timeline Graphs.
|
From: Donnie J. <do...@da...> - 2008-08-14 16:17:19
|
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
>>>>
>>>
>>>
>>>
>>
>
>
|
