tuningforkvp-development — Discussion of day-to-day TuningFork development

[Tuningforkvp-development] Getting TuningFork 2.0.0 release

[Peter F S. <pf...@us...>]

<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><div>A question about getting the TuningFork 2.0.0 release.<br><br>When I navigate SVN from
eclipse, the&nbsp; Stable.psf under tfroot -&gt; tags -&gt; 2.0.0 -&gt;
ProjectSets -&gt; TuningFork has the same latest changed revision, 746,
as Stable.psf under tfroot -&gt; trunk -&gt; ProjectSets -&gt;
TuningFork is 746.&nbsp; So how does one get to the TuningFork 2.0.0
release?<br><br>Thanks.<br><br>Peter<br>
<div>_____________________________<br>Peter&nbsp;F.&nbsp;Sweeney<br>Research&nbsp;Staff&nbsp;Member<br>Dynamic&nbsp;Optimization&nbsp;Group<br>IBM&nbsp;TJ&nbsp;Watson&nbsp;Research&nbsp;Center,&nbsp;Hawthorne<br>914&nbsp;784-6390<br></div></div></FONT>

[Tuningforkvp-development] OSS Usability Evaluation

[Arif R. <ar...@uw...>]

Hi there
 
Please find below a link  to a survey related to my PhD research work to evaluate OSS usability improvement from OSS developer's point of view.
It shall not not take more than 5 minutes of your precious time. 
Your identity is neither required nor recorded. The participation is highly valued and appreciated.
 
http://www.kwiksurveys.com/online-survey.php?surveyID=ILJEM_ba6da4db
 
Thank you and Best Regards
 
Arif Raza

[Tuningforkvp-development] Asserts

[Joshua A. <jo...@us...>]

I just fixed a bug in figure drag-and-drop which manifests as an assertion
failure.  In fact, the bug was sort of harmless, but the assertion was
actually sound and the invariant it was testing was probably worth
maintaining for code soundness in the long run.   Why was this bug never
noticed before?  Because assertions are off by default and must be enabled
by using the -ea flag when running the JVM.   I do this (which is why I
noticed the bug) and I strongly suggest that the rest of you do as well.
If you routinely launch TF from Eclipse all you have to do is edit the VM
arguments in the launch configuration.

Josh

Re: [Tuningforkvp-development] ForkTalk status for upcoming release

[David F. B. <df...@wa...>]

yes, i favor (3).

david


On Sep 27, 2008, at 2:36 PM, David P Grove wrote:

> Joshua Auerbach/Watson/IBM@IBMUS wrote on 09/27/2008 11:59:18 AM:
>
> > I may have missed the latest chats about when we are targeting the
> > upcoming release. But, whenever it happens, I will want to resolve
> > the status of ForkTalk for that release.
>
> Oct. 15th is the drop dead date to have all development done, with  
> a goal of actually being done by Oct 10th if possible.  We want a  
> release out there before OOPSLA (Oct 20).
>
>
> >
> > [ forktalk options ]
> >
> > I favor (3) but would like to understand the schedule so I will have
> > the time to do the small amount of work involved, also any  
> contrary opinions.
> >
>
> I agree.
>
> --dave
> ---------------------------------------------------------------------- 
> ---
> 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-development mailing list
> Tun...@li...
> https://lists.sourceforge.net/lists/listinfo/tuningforkvp-development

Re: [Tuningforkvp-development] ForkTalk status for upcoming release

[David P G. <gr...@us...>]

Joshua Auerbach/Watson/IBM@IBMUS wrote on 09/27/2008 11:59:18 AM:

> I may have missed the latest chats about when we are targeting the
> upcoming release. But, whenever it happens, I will want to resolve
> the status of ForkTalk for that release.

Oct. 15th is the drop dead date to have all development done, with a goal
of actually being done by Oct 10th if possible.  We want a release out
there before OOPSLA (Oct 20).


>
> [ forktalk options ]
>
> I favor (3) but would like to understand the schedule so I will have
> the time to do the small amount of work involved, also any contrary
opinions.
>

I agree.

--dave

[Tuningforkvp-development] ForkTalk status for upcoming release

[Joshua A. <jo...@us...>]

I may have missed the latest chats about when we are targeting the upcoming
release.   But, whenever it happens, I will want to resolve the status of
ForkTalk for that release.

Recall that ForkTalk is "working" but only lightly tested.  It does seem to
support simple time interval stream, sample stream, and event stream
derivations, including "concatenations" (unifying streams on a common
field) and many other things.   The status of complex relational
operations, cumulations, and other more stateful operations is that more
work is needed either to have the function at all or to make it fully
usable.   The state of the GUI is that some expertise and understanding of
the information model is required for an end user to use ForkTalk
effectively.    There is a document located in the reference section but it
is somewhat misplaced there as it is more of a specification for developers
to read than a true end-user document and it doesn't have examples.

I think there are three options for how to handle ForkTalk in the context
of the release.

(1) (Extreme rollback) -- Remove the document.  Remove the "Use ForkTalk"
item from the context menu of the Feed Explorer.   I would not, in any
case, remove the code, as that will be too disruptive to future
development.

(2) (Modest rollback) -- Remove the document.   Leave the context menu as
is.   Add an explanation in the appropriate place in the documentation
hierarchy (where that context menu is explained) stating that ForkTalk is
an experimental facility that is under development and refer highly
interested users to get in touch with us about it.

(3) (Modest roll-forward to open experimental status) -- Leave the context
menu as is.  Edit the document to be somewhat more helpful and to have some
examples.   Make clear that ForkTalk is experimental and will be improved
in the future.

I favor (3) but would like to understand the schedule so I will have the
time to do the small amount of work involved, also any contrary opinions.

Josh

[Tuningforkvp-development] Major ForkTalk Check-in also affects Stream / Event / Tuple / EventType hierarchies

[Joshua A. <jo...@us...>]

A somewhat working ForkTalk is checked in.  The GUI is still extremely
primitive and some aspects of the language are still incomplete but it is
now possible to do some stream derivations using ForkTalk.   Testing of new
functionality has been light.   I hope I've done enough regression testing
but the possibility of breakage remains.

This checkin involved some rippling changes that you might need to take
into account even if you don't care about ForkTalk.  I describe them in
this note.  The ForkTalk functionality is too extensive to cover in a
check-in note and I am overdue to check stuff in prior to another round of
changes.   I'll send some ForkTalk usage instructions separately
(eventually) or else talk to me.

1.  The class formerly known as EventType is now called TupleType and it
gains two new methods: hasTimestamp() which returns false, and getFactory()
which will be explained.   It loses its read() method.

2.  The new EventType extends TupleType.  It overrides hasTimestamp() to
return true and it overrides getFactory().  Thoughout the system, wherever
EventType was used to describe an ITuple specialization that isn't an
IEvent specialization, TupleType was subsituted for EventType.

3.  A new interface, TupleFactory, has the read() method that was removed
from EventType/TupleType and also has a newInstance() method.    The
getFactory() method that was added to TupleType and overridden in EventType
provides generic behavior, returning the best kind of factory for those
cases.   PersistedStreamData now gets the factory outside the loop and uses
the factory in the inner loop, which should improve performance for those
cases that don't specialize the EventType.

4.  Two new abstract classes, StaticEventType and StaticTupleType, extend
EventType and TupleType, respectively, and they implement TupleFactory.
Their getFactory() method returns 'this', and their read() and newInstance
() methods are abstract.  Every class that used to extend EventType now
extends one of these new classes.   Thus, all the old read() methods that
were placed in EventType specializations should continue to work.
However, each such specialization gains a newInstance method as well.

5.  There was an existing design pattern wherein data specialization
classes (like Sample) have a public static field named eventType containing
'the' single instance of the data class's associated EventType
specialization.   This convention is now required if the class is to be
usable from ForkTalk.   There are some funny corner cases where it was
impossible for the EventType specialization to have a single instance
because it needs constructor arguments having nothing to do with its
structure.  I have left some of these for now, meaning that there are some
tuple and event types that ForkTalk still can't construct.

6.  The addEvent method of Stream now takes IEvent instead of TypedEvent,
and the comment indicates that it should be overridden not only in base
streams (as before) but also in any stream that uses an IEvent as its
TimedData specialization (this now includes most streams).    In base
streams, the addEvent method just coerces its argument to TypedEvent and in
other streams that gained an addEvent, it just coerces its argument to the
appropriate type (e.g. Sample) and then calls the more specific adder.

7.  Stream has a new constructor, some new instance fields, and new run
loop method (called forkTalkRun).   Its getEventType method is no longer
abstract but will return an EventType stored by its new constructor.   The
new functionality only applies to ForkTalk derivations and is completely
bypassed by "normal" derivations.   This new construction pathway is
drilled upwards in selected places.   Specifically, EventStream and
SampleStream are no longer abstract and now support ForkTalk derivation.  I
will work on converting a larger set of Stream specializations after this
checkin.

Josh

[Tuningforkvp-development] code reformatting

[David P G. <gr...@us...>]

We've done a bulk reformat of all Java code to match project coding
conventions.  Be sure to update soon to reduce merge conflicts.

--dave