Menu
▾
▴
tuningforkvp-users — Tuning Fork user mailing list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(16) |
Sep
(3) |
Oct
(5) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Sripathi K. <sri...@in...> - 2009-11-11 10:48:08
|
Hi, I am trying to use Tuningfork 2.0.0 on x86_64/Linux. Recently I noticed that Tuningfork started crashing with a SEGV in one of system libraries (libxul or UTF). It now happens every single time I try to start TuningFork. However, I remembered that it had been working a few days ago and I still had that directory intact. I started comparing the two directories and narrowed down the problem to this: In the directory Go to $ cd tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0 Create this file to prevent the problem from happening: $ cat org.eclipse.ui.prefs #Mon Nov 09 14:01:45 IST 2009 eclipse.preferences.version=1 showIntro=false Specifically, the line "showIntro=false" prevents the crash from happening. Could anyone please tell me what this setting does and why is this needed to prevent the crash from happening? Java version: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20090707 (SR10 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20090707 (JIT enabled) J9VM - 20090706_38445_lHdSMr JIT - 20090623_1334_r8 GC - 200906_09) JCL - 20090705 A typical console log when the crash happens: There are 0 temp files in the cache directory. Deleted 0 old temp files in the cache directory. Using direct invoke of paint from refresh loop workaround for Linux Unhandled exception Type=Segmentation error vmState=0x00040000 J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000002 Handler1=F7C78AE7 Handler2=F7C3C9F7 InaccessibleAddress=C5FFD000 EDI=C5FFD002 ESI=0B1F8848 EAX=0B1F884C EBX=C5FE9FF4 ECX=C5FFD000 EDX=00000000 EIP=C5FE788D ES=002B DS=002B ESP=FFFACC1C EFlags=00210287 CS=0023 SS=002B EBP=FFFACCE8 Module=/usr/lib/gconv/UTF-16.so Module_base_address=C5FE7000 Symbol=gconv Symbol_address=C5FE7690 Target=2_30_20090706_38445_lHdSMr (Linux 2.6.31-rc5.3.el5rt) CPU=x86 (4 logical CPUs) (0x1ec38b000 RAM) JVMDUMP006I Processing dump event "gpf", detail "" - please wait. JVMDUMP032I JVM requested System dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/core.20091111.151000.8789.0001.dmp' in response to an event JVMDUMP010I System dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/core.20091111.151000.8789.0001.dmp JVMDUMP032I JVM requested Snap dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/Snap.20091111.151000.8789.0002.trc' in response to an event JVMDUMP010I Snap dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/Snap.20091111.151000.8789.0002.trc JVMDUMP032I JVM requested Java dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/javacore.20091111.151000.8789.0003.txt' in response to an event JVMDUMP010I Java dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/javacore.20091111.151000.8789.0003.txt JVMDUMP013I Processed dump event "gpf", detail "". [root@llm50 tuningforkvp-2.0.0]# Thanks, Sripathi. |
|
From: Daniel S. <dsh...@fa...> - 2009-04-18 19:10:29
|
Hello,
I am developing a plugin with an IncrementalSummarizingEventStream. I
am taking data from my original stream and whenever I have new data
with the same key in my original stream, I want it replaced in the
summarized stream. Essentially I want a derived stream that keeps the
freshest data whenever I have duplicate keys. This seems very similar
to what the jikesrvm summarizer does and so I tried to duplicate its
functionality. However, it seems that whenever I return the summary,
it only contains the first element from the original stream. Is there
something I am missing. Here is my summarizer code and the code I use
to get the data from the derived stream.
Thanks for your help,
Daniel Shteremberg
public class TopologySummarizer implements IEventSummarizer {
public static final int SOURCE_INDEX = 0;
public static final int DESTINATION_INDEX = 1;
private static final EventType summaryEventType = new
EventType("Topology State", "State of the topology",
new
EventAttribute[] {
new EventAttribute("source", "source", AttributeType.INT),
new EventAttribute("destination", "destination", AttributeType.INT)
});
private long lastTime;
private final HashMap<Integer, NodeTuple> storage = new
HashMap<Integer, NodeTuple>();
public TopologySummarizer() {
}
public void addToSummary(ITimedData data, Stream stream) {
if (data != null) {
Event event = (Event) data;
int source = event.getInt(SOURCE_INDEX);
int destination = event.getInt(DESTINATION_INDEX);
storage.put(source, new NodeTuple(source, destination,
new Annotation(Integer.toString(source),
Integer.toString(destination))));
lastTime = event.getTime();
}
}
public Event_Relation getSummary() {
NodeTuple [] tuples = new NodeTuple[storage.size()];
int i = 0;
for (Integer index: storage.keySet()) {;
tuples[i++] = storage.get(index);
}
return new Event_Relation(lastTime, new Relation(tuples));
}
public EventType getSummaryEventType() {
return summaryEventType;
}
public String getName() {
return "Topology Summarizer";
}
public void reset() {
storage.clear();
}
public synchronized IEventSummarizer createNew(IEvent original) {
TopologySummarizer summarizer = new TopologySummarizer();
summarizer.lastTime = original.getTime();
IRelation initialState = original.getRelation(0);
for (ITuple tuple : initialState) {
NodeTuple nt = (NodeTuple)tuple;
summarizer.storage.put(nt.source, nt);
}
return summarizer;
}
}
------------------
In this code, the size of the relation is always one and the data is
always the first element in the original stream
public void paintFigure(Graphics g, Area area) {
player.setTimeRange(getTimeRange());
long time = getCurrentTime();
String msg = " Hey...";
IStreamCursor cursor = stream.newCursor(time, 0);
Event_Relation e = (Event_Relation) cursor.getNext();
if (e != null) {
IRelation relation = e.getRelation(0);
String string = relation.toString();
msg += " toString()="+string + ". Size: "+relation.size();
}
drawInfo(g, time, area, msg);
painter.drawSpiderGraph(g, area);
} |
|
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 |
|
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-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" >>>>>>>> <dfb@watson.ibm.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...urceforg >>>>>>>> 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...urceforg >>>>>>>>> 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-03 13:40:34
|
Hello David, Your updates fixed the problem. Thank you. __ Donnie On Fri, Oct 31, 2008 at 4:51 PM, Donnie Jones <do...@da...> wrote: > Hello David, > > Thanks! I'll test it out soon. > __ > Donnie > > > On Fri, Oct 31, 2008 at 2:10 PM, David P Grove <gr...@us...> wrote: > >> Hi, >> >> I believe I fixed it. Changes checked in right before lunch. The problem >> was that we had updated the feature version numbers from 1.2 to 2.0 and >> hadn't made the corresponding change in the TuningFork.product file. >> Needless to say the error message was less than helpful...took quite a while >> to figure out what was wrong :( >> >> --dave >> >> >> "Donnie Jones" <do...@da...> wrote on 10/30/2008 01:10:03 AM: >> >> > >> > I updated my TuningFork repository, but now when I try to run >> > TuningFork I get this error: >> > >> > !SESSION Thu Oct 30 01:00:43 EDT 2008 >> > ------------------------------------------ >> > !ENTRY org.eclipse.equinox.launcher 4 0 2008-10-30 01:00:43.933 >> > !MESSAGE Exception launching the Eclipse Platform: >> > !STACK >> > java.lang.ClassNotFoundException: >> > org.eclipse.core.runtime.adaptor.EclipseStarter >> > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) >> > at java.security.AccessController.doPrivileged(Native Method) >> > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) >> > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) >> > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:505) >> > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) >> > at org.eclipse.equinox.launcher.Main.run(Main.java:1173) >> > at org.eclipse.equinox.launcher.Main.main(Main.java:1148) >> > >> > Any ideas how to fix this? >> > Thank you. >> > __ >> > Donnie Jones >> > >> ------------------------------------------------------------------------- >> > 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-31 21:51:25
|
Hello David, Thanks! I'll test it out soon. __ Donnie On Fri, Oct 31, 2008 at 2:10 PM, David P Grove <gr...@us...> wrote: > Hi, > > I believe I fixed it. Changes checked in right before lunch. The problem > was that we had updated the feature version numbers from 1.2 to 2.0 and > hadn't made the corresponding change in the TuningFork.product file. > Needless to say the error message was less than helpful...took quite a while > to figure out what was wrong :( > > --dave > > > "Donnie Jones" <do...@da...> wrote on 10/30/2008 01:10:03 AM: > > > > > I updated my TuningFork repository, but now when I try to run > > TuningFork I get this error: > > > > !SESSION Thu Oct 30 01:00:43 EDT 2008 > > ------------------------------------------ > > !ENTRY org.eclipse.equinox.launcher 4 0 2008-10-30 01:00:43.933 > > !MESSAGE Exception launching the Eclipse Platform: > > !STACK > > java.lang.ClassNotFoundException: > > org.eclipse.core.runtime.adaptor.EclipseStarter > > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:505) > > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) > > at org.eclipse.equinox.launcher.Main.run(Main.java:1173) > > at org.eclipse.equinox.launcher.Main.main(Main.java:1148) > > > > Any ideas how to fix this? > > Thank you. > > __ > > Donnie Jones > > ------------------------------------------------------------------------- > > 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-10-31 18:11:23
|
Hi,
I believe I fixed it. Changes checked in right before lunch. The
problem was that we had updated the feature version numbers from 1.2 to 2.0
and hadn't made the corresponding change in the TuningFork.product file.
Needless to say the error message was less than helpful...took quite a
while to figure out what was wrong :(
--dave
"Donnie Jones" <do...@da...> wrote on 10/30/2008 01:10:03 AM:
>
> I updated my TuningFork repository, but now when I try to run
> TuningFork I get this error:
>
> !SESSION Thu Oct 30 01:00:43 EDT 2008
> ------------------------------------------
> !ENTRY org.eclipse.equinox.launcher 4 0 2008-10-30 01:00:43.933
> !MESSAGE Exception launching the Eclipse Platform:
> !STACK
> java.lang.ClassNotFoundException:
> org.eclipse.core.runtime.adaptor.EclipseStarter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:505)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1148)
>
> Any ideas how to fix this?
> Thank you.
> __
> Donnie Jones
> -------------------------------------------------------------------------
> 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 05:10:09
|
Hello TuningFork,
I updated my TuningFork repository, but now when I try to run TuningFork I
get this error:
!SESSION Thu Oct 30 01:00:43 EDT 2008
------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2008-10-30 01:00:43.933
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException:
org.eclipse.core.runtime.adaptor.EclipseStarter
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:505)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)
at org.eclipse.equinox.launcher.Main.main(Main.java:1148)
Any ideas how to fix this?
Thank you.
__
Donnie Jones
|
|
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" >>>>>>> <dfb@watson.ibm.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...urceforg >>>>>>> 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...urceforg >>>>>>>> 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" >>>>>> <dfb@watson.ibm.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...urceforg >>>>>> 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...urceforg >>>>>>> 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" >>> <dfb@watson.ibm.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...urceforg >>> 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...urceforg >>> 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-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" >>>>> <dfb@watson.ibm.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...urceforg >>>>> 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...urceforg >>>>>> 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 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"
>> <dfb@watson.ibm.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...urceforg
>> 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...urceforg
>> 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-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"
>>> <dfb@watson.ibm.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...urceforg
>>> 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...urceforg
>>>> 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"
> <dfb@watson.ibm.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...urceforg
> 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...urceforg
> 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 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"
> <dfb@watson.ibm.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...urceforg
> 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...urceforg
>> 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"
>> <dfb@watson.ibm.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...urceforg
>> 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...urceforg
>>> 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"
<dfb@watson.ibm.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...urceforg
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...urceforg
> 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 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...urceforg > 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 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...urceforg
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: 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-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-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: 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 > > > > |
2 messages has been excluded from this view by a project administrator.
