Menu
▾
▴
tuningforkvp-users
|
From: Donnie J. <do...@da...> - 2008-07-31 23:11:48
|
Hello, I am attempting to create a timeline graph of the changes in "states" of execution for the Glasgow Haskell Compiler (GHC) Run-time System (RTS). I would like to be able to create a timeline graph which has a single horizontal bar (same location on the y-axis) in which the colors change for the different "states". So far, I have only been able to accomplish timeline graphs where the different states are on separate horizontal bars on the y-axis in the timeline; I have linked a screenshot of such a graph [1]. This graph was created as a TimeIntervalStream in which each TimerEvent was a different "state" of execution. Any suggestions would be great. Thank you. __ Donnie Jones 1. http://darthik.com/tuning_fork/ghc/images/screenshot-TfCapTimerEvents.png |
|
From: David F. B. <df...@wa...> - 2008-07-31 23:28:36
|
select "cycle through display modes" from the dropdown in the figure (or use the button with the same icon). i think this will give you what you want. david On Jul 31, 2008, at 7:11 PM, Donnie Jones wrote: > Hello, > > I am attempting to create a timeline graph of the changes in > "states" of execution for the Glasgow Haskell Compiler (GHC) Run- > time System (RTS). I would like to be able to create a timeline > graph which has a single horizontal bar (same location on the y- > axis) in which the colors change for the different "states". So > far, I have only been able to accomplish timeline graphs where the > different states are on separate horizontal bars on the y-axis in > the timeline; I have linked a screenshot of such a graph [1]. This > graph was created as a TimeIntervalStream in which each TimerEvent > was a different "state" of execution. > > Any suggestions would be great. > Thank you. > __ > Donnie Jones > > 1. http://darthik.com/tuning_fork/ghc/images/screenshot- > TfCapTimerEvents.png > > > > ---------------------------------------------------------------------- > --- > 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 |
|
From: Donnie J. <do...@da...> - 2008-08-01 01:24:05
|
Hello David, That worked. Thank you. __ Donnie On Thu, Jul 31, 2008 at 7:27 PM, David F. Bacon <df...@wa...> wrote: > select "cycle through display modes" from the dropdown in the figure (or > use the button with the same icon). i think this will give you what you > want. > david > > > On Jul 31, 2008, at 7:11 PM, Donnie Jones wrote: > > Hello, > > I am attempting to create a timeline graph of the changes in "states" of > execution for the Glasgow Haskell Compiler (GHC) Run-time System (RTS). I > would like to be able to create a timeline graph which has a single > horizontal bar (same location on the y-axis) in which the colors change for > the different "states". So far, I have only been able to accomplish > timeline graphs where the different states are on separate horizontal bars > on the y-axis in the timeline; I have linked a screenshot of such a graph > [1]. This graph was created as a TimeIntervalStream in which each > TimerEvent was a different "state" of execution. > Any suggestions would be great. > Thank you. > __ > Donnie Jones > > 1. > http://darthik.com/tuning_fork/ghc/images/screenshot-TfCapTimerEvents.png > > > > ------------------------------------------------------------------------- > 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 > > > |
|
From: Donnie J. <do...@da...> - 2008-08-01 23:30:55
|
Hello, I have a follow-up question. If I have two threads executing, and I want to create a timeline graph of the "state" changes of each thread. The "states" are the same EventTypes for each thread, thus when I graph the threads "state" changes the TimeIntervalStream that is created combines the events into a single stream for each "state". I would like to graph an individual horizontal bar with colored "states" for each thread. Any suggestions? Thanks again. __ Donnie Jones On Thu, Jul 31, 2008 at 9:24 PM, Donnie Jones <do...@da...> wrote: > Hello David, > > That worked. Thank you. > __ > Donnie > > > On Thu, Jul 31, 2008 at 7:27 PM, David F. Bacon <df...@wa...>wrote: > >> select "cycle through display modes" from the dropdown in the figure (or >> use the button with the same icon). i think this will give you what you >> want. >> david >> >> >> On Jul 31, 2008, at 7:11 PM, Donnie Jones wrote: >> >> Hello, >> >> I am attempting to create a timeline graph of the changes in "states" of >> execution for the Glasgow Haskell Compiler (GHC) Run-time System (RTS). I >> would like to be able to create a timeline graph which has a single >> horizontal bar (same location on the y-axis) in which the colors change for >> the different "states". So far, I have only been able to accomplish >> timeline graphs where the different states are on separate horizontal bars >> on the y-axis in the timeline; I have linked a screenshot of such a graph >> [1]. This graph was created as a TimeIntervalStream in which each >> TimerEvent was a different "state" of execution. >> Any suggestions would be great. >> Thank you. >> __ >> Donnie Jones >> >> 1. >> http://darthik.com/tuning_fork/ghc/images/screenshot-TfCapTimerEvents.png >> >> >> >> ------------------------------------------------------------------------- >> 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 >> >> >> > |
|
From: Donnie J. <do...@da...> - 2008-08-01 23:36:49
|
Hello, I uploaded another screenshot for example. I would like to accomplish this same horizontal bar timeline graph but with each threads execution "states" on its own horizontal line. Screenshot: http://darthik.com/tuning_fork/ghc/images/screenshot-TfCapTimerEventsMultFeedlets.png Thank you. __ Donnie Jones On Fri, Aug 1, 2008 at 7:31 PM, Donnie Jones <do...@da...> wrote: > Hello, > > I have a follow-up question. If I have two threads executing, and I want > to create a timeline graph of the "state" changes of each thread. The > "states" are the same EventTypes for each thread, thus when I graph the > threads "state" changes the TimeIntervalStream that is created combines the > events into a single stream for each "state". I would like to graph an > individual horizontal bar with colored "states" for each thread. > > Any suggestions? > Thanks again. > __ > Donnie Jones > > > On Thu, Jul 31, 2008 at 9:24 PM, Donnie Jones <do...@da...> wrote: > >> Hello David, >> >> That worked. Thank you. >> __ >> Donnie >> >> >> On Thu, Jul 31, 2008 at 7:27 PM, David F. Bacon <df...@wa...>wrote: >> >>> select "cycle through display modes" from the dropdown in the figure (or >>> use the button with the same icon). i think this will give you what you >>> want. >>> david >>> >>> >>> On Jul 31, 2008, at 7:11 PM, Donnie Jones wrote: >>> >>> Hello, >>> >>> I am attempting to create a timeline graph of the changes in "states" of >>> execution for the Glasgow Haskell Compiler (GHC) Run-time System (RTS). I >>> would like to be able to create a timeline graph which has a single >>> horizontal bar (same location on the y-axis) in which the colors change for >>> the different "states". So far, I have only been able to accomplish >>> timeline graphs where the different states are on separate horizontal bars >>> on the y-axis in the timeline; I have linked a screenshot of such a graph >>> [1]. This graph was created as a TimeIntervalStream in which each >>> TimerEvent was a different "state" of execution. >>> Any suggestions would be great. >>> Thank you. >>> __ >>> Donnie Jones >>> >>> 1. >>> http://darthik.com/tuning_fork/ghc/images/screenshot-TfCapTimerEvents.png >>> >>> >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >>> >> > |
|
From: David F. B. <df...@wa...> - 2008-08-02 01:56:32
|
there is a new facility for creating streams of time intervals that include a "state" variable, which would do what you want. unfortunately, this is not yet exposed in the trace generation libraries, so to use it you'd have to generate the primitive events in the trace and then create an event typespace in tuningfork that would build the streams you need. however, you could also try using an oscilloscope figure and using the "interleaving mode" in the configuration dialog. that wouldn't require any programmatic changes, and might give you what you need. david On Aug 1, 2008, at 7:36 PM, Donnie Jones wrote: > Hello, > > I uploaded another screenshot for example. I would like to > accomplish this same horizontal bar timeline graph but with each > threads execution "states" on its own horizontal line. > > Screenshot: > http://darthik.com/tuning_fork/ghc/images/screenshot- > TfCapTimerEventsMultFeedlets.png > > Thank you. > __ > Donnie Jones > > > On Fri, Aug 1, 2008 at 7:31 PM, Donnie Jones <do...@da...> > wrote: > Hello, > > I have a follow-up question. If I have two threads executing, and > I want to create a timeline graph of the "state" changes of each > thread. The "states" are the same EventTypes for each thread, thus > when I graph the threads "state" changes the TimeIntervalStream > that is created combines the events into a single stream for each > "state". I would like to graph an individual horizontal bar with > colored "states" for each thread. > > Any suggestions? > Thanks again. > __ > Donnie Jones > > > On Thu, Jul 31, 2008 at 9:24 PM, Donnie Jones <do...@da...> > wrote: > Hello David, > > That worked. Thank you. > __ > Donnie > > > On Thu, Jul 31, 2008 at 7:27 PM, David F. Bacon > <df...@wa...> wrote: > select "cycle through display modes" from the dropdown in the > figure (or use the button with the same icon). i think this will > give you what you want. > > david > > > On Jul 31, 2008, at 7:11 PM, Donnie Jones wrote: > >> Hello, >> >> I am attempting to create a timeline graph of the changes in >> "states" of execution for the Glasgow Haskell Compiler (GHC) Run- >> time System (RTS). I would like to be able to create a timeline >> graph which has a single horizontal bar (same location on the y- >> axis) in which the colors change for the different "states". So >> far, I have only been able to accomplish timeline graphs where the >> different states are on separate horizontal bars on the y-axis in >> the timeline; I have linked a screenshot of such a graph [1]. >> This graph was created as a TimeIntervalStream in which each >> TimerEvent was a different "state" of execution. >> >> Any suggestions would be great. >> Thank you. >> __ >> Donnie Jones >> >> 1. http://darthik.com/tuning_fork/ghc/images/screenshot- >> TfCapTimerEvents.png >> >> >> >> --------------------------------------------------------------------- >> ---- >> 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 > > > > |
|
From: Donnie J. <do...@da...> - 2008-08-07 19:56:17
|
Hello David, On Fri, Aug 1, 2008 at 9:55 PM, David F. Bacon <df...@wa...> wrote: > there is a new facility for creating streams of time intervals that include > a "state" variable, which would do what you want. unfortunately, this is > not yet exposed in the trace generation libraries, so to use it you'd have > to generate the primitive events in the trace and then create an event > typespace in tuningfork that would build the streams you need. > 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? 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. > > however, you could also try using an oscilloscope figure and using the > "interleaving mode" in the configuration dialog. that wouldn't require any > programmatic changes, and might give you what you need. > > The oscilloscope figure with "interleaving mode" isn't quite what I am wanting. Thank you. __ Donnie |
|
From: Joshua A. <jo...@us...> - 2008-08-08 13:15:19
|
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. > 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. Josh |
|
From: Donnie J. <do...@da...> - 2008-08-11 16:06:58
|
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 |
|
From: Joshua A. <jo...@us...> - 2008-08-14 11:15:25
|
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-j...@mi...>,
tun...@li...
e.net,
tun...@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
|
|
From: David F. B. <df...@wa...> - 2008-08-14 13:48:11
|
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 |
|
From: Joshua A. <jo...@us...> - 2008-08-14 13:49:38
|
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
|
|
From: Donnie J. <do...@da...> - 2008-08-14 15:18:33
|
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
>>>
>>
>>
>>
>
|
|
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
>
>
>
>
|
|
From: Donnie J. <do...@da...> - 2008-11-03 15:37:43
|
Hello David, I see in the latest version of TuningFork a new view called TimeSlice, is this intended to be the Timeline view we have been discussing? Thank you. __ Donnie Jones On Wed, Oct 29, 2008 at 7:49 PM, Donnie Jones <do...@da...> wrote: > Hello David, > > I am following up to see if any progress has been made on the Timeline > graphs for Tuning Fork that we previously discussed. > > Thank you. > __ > Donnie Jones > > > On Tue, Sep 9, 2008 at 2:30 PM, Donnie Jones <do...@da...> wrote: > >> Hello David, >> >> Please try to email me once code is checked in, so I test it out. :) >> Thanks for the help. >> __ >> Donnie >> >> >> On Wed, Sep 3, 2008 at 11:41 AM, David F. Bacon <df...@wa...>wrote: >> >>> 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...>, >>>>>>>> >>>>>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >> > |
|
From: David P G. <gr...@us...> - 2008-11-04 20:22:44
|
"Donnie Jones" <do...@da...> wrote on 11/03/2008 10:37:34 AM: > > I see in the latest version of TuningFork a new view called > TimeSlice, is this intended to be the Timeline view we have been discussing? I think not, but I'm not positive. David is taking a vacation for a week without any email. I'm sure he'll give a definitive answer when he returns early next week. --dave |
|
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
>>>>
>>>
>>>
>>>
>>
>
>
|
|
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
|
|
From: David F. B. <df...@wa...> - 2008-08-14 15:19:49
|
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
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
>
>
|
|
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 >> >> >> > |
|
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 > > > |
|
From: Donnie J. <do...@da...> - 2008-09-09 18:30:11
|
Hello David, Please try to email me once code is checked in, so I test it out. :) Thanks for the help. __ Donnie On Wed, Sep 3, 2008 at 11:41 AM, David F. Bacon <df...@wa...> wrote: > 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...>, >>>>>> >>>>>> 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 >>> >>> >>> >> > > |
|
From: Donnie J. <do...@da...> - 2008-10-30 01:14:36
|
Hello David, I am following up to see if any progress has been made on the Timeline graphs for Tuning Fork that we previously discussed. Thank you. __ Donnie Jones On Tue, Sep 9, 2008 at 2:30 PM, Donnie Jones <do...@da...> wrote: > Hello David, > > Please try to email me once code is checked in, so I test it out. :) > Thanks for the help. > __ > Donnie > > > On Wed, Sep 3, 2008 at 11:41 AM, David F. Bacon <df...@wa...>wrote: > >> 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...>, >>>>>>> >>>>>>> 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 >>>> >>>> >>>> >>> >> >> > |
|
From: Donnie J. <do...@da...> - 2008-11-08 23:30:39
|
Hello David, On Sat, Nov 8, 2008 at 6:21 PM, David F. Bacon <df...@wa...> wrote: > no, timeslice is a way of showing complex data at an instant in time. it > draws a bunch of little squares of varying color and intensity. it can be > used for things like visualizing the state of memory (each box is one page) > or processors (each box is one cpu) or anything else you like. > we haven't forgotten about your feature request, just a lot of different > things to do.... > > Thank you for the clarification. I understand. :) __ Donnie |
Thanks for helping keep SourceForge clean.
X