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