Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sweet Talk (part 2) Tool Support for Sweet Phil Quitslund.

Similar presentations


Presentation on theme: "Sweet Talk (part 2) Tool Support for Sweet Phil Quitslund."— Presentation transcript:

1 Sweet Talk (part 2) Tool Support for Sweet Phil Quitslund

2 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

3 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

4 Automating the Build The Problem: Manual builds considered painful

5 Automating the Build generative techniques require extra steps to stage builds The Problem: Manual builds considered painful

6 Automating the Build generative techniques require extra steps to stage builds The Problem: Manual builds considered painful the rub: manual builds hurt and interrupt programmer flow

7 public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } Automating the Build

8 public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

9 Automating the Build 3 “Introductions” public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

10 Automating the Build public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); }

11 Automating the Build repository S

12 Automating the Build repository J J J S

13 Automating the Build repository J J J S C C C

14 Managing Dependencies The Problem: Crufty Orphans

15 Managing Dependencies generated files are "orphaned" when their introductions get removed. The Problem: Crufty Orphans

16 Managing Dependencies generated files are "orphaned" when their introductions get removed. The Problem: Crufty Orphans the rub: manual maintenance is tedious and error prone

17 Managing Dependencies repository J J J S C C C

18 Managing Dependencies repository J J J S C C C

19 Managing Dependencies repository J J J S C C C

20 Managing Dependencies repository J J J S C C C

21 Managing Dependencies repository J J S C C C

22 Managing Dependencies repository J J S C C

23 Managing Dependencies repository J J S C C Done manually this is tedious and prone to error!

24 Error Handling The Problem: Say What?

25 Error Handling Errors in generated files can be hard to trace back to their source The Problem: Say What?

26 Error Handling Errors in generated files can be hard to trace back to their source The Problem: Say What? the rub: indirection decreases understandability

27 public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } Error Reporting

28 public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } Error Reporting Legal Sweet

29 public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; } Error Reporting Legal Sweet?

30 Error Reporting public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; } Legal Sweet? Nope…

31 Error Reporting Conflicting declarations public abstract class List { public case Nil public case Cons(private int head, private List tail) } public int length() case List abstract; case Nil { return 0; } case Cons { return 1 + tail.length(); } case Nil { return 1; }

32 Error Reporting (from 10,000ft) repository S S S

33 Error Reporting (from 10,000ft) repository S S S

34 Error Reporting (from 10,000ft) repository S S S

35 Error Reporting (from 10,000ft) repository S S S

36 Error Reporting (from 10,000ft) repository S S S

37 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

38 What is Eclipse? A universal platform for integrating development tools –“An IDE for everything and nothing in particular” An open, extensible architecture based on plug-ins

39 What is Eclipse? (a picture) Platform Runtime Workspace Help Team Workbench JFace SWT Eclipse Project Java Development Tools (JDT) Stellation Sweet Plugin Another Tool Plug-in Development Environment (PDE) Eclipse Platform Debug

40 What is Eclipse? Lot’s for free (well almost) –Tight integration of common core tools CVS, Ant, JUnit, diff –Extensible/open architecture Third-party plugins –ruby, c#, php, etc. –AOSD (aspectJ, hyperJ, FEAT, JQuery, etc)

41 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

42 Plugin Features Keyword awareness Integrated SweetBuilder Automated House-Cleaning Artifact Special Treatment Basic Error-Reporting Integrated Help

43 DEMO! ! Cross fingers please…

44 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

45 Automating the Build (Impl.) - Eclipse leverages the Observer (Listener) Design Pattern The idea is to register listeners to monitor for changes to resources that should trigger a build.

46 Automating the Build (Impl.) Our pipeline:

47 Automating the Build (Impl.) Ordered list of builders Insert SweetBuilder before JavaBuilder Our pipeline: SB JB

48 Managing Dependencies (Impl.) / pkgApkgBpkgC ouptut/ pkgApkgBpkgC Possible Approach: Parallel Worlds

49 Managing Dependencies (Impl.) / pkgApkgBpkgC ouptut/ pkgApkgBpkgC Possible Approach: Parallel Worlds Possible Solution: “make clean”

50 Managing Dependencies (Impl.) - Complete rebuild - Worst case every Java file re-compiled -File-based - subtler: de-values artifacts In a multi-view setting should be first-class! Parallel Worlds Disadvantages

51 Managing Dependencies (Impl.) - Use Sweet Parser to collect Introductions - Store in Resource object metadata Advantages: –Persistence for free –Limited introduction/deletion ripple Better: Mapping

52 Error Reporting (Impl.) -Should be integrated into environment -Shouldn’t re-route programmer flow -Minimize dissonance Ideal: Handle Like Errors NOT Exceptions!

53 Error Reporting (Impl.) - Extended Sweet Handler to collect Problem data - Data marshalled into a Marker object - Attached to Eclipse Resource Result: - visual (localized) cues, persistence, navigability Eclipse Resource Marker Strategy

54 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

55 Pitch Nice vision –“user as programmer” Nice Execution –Mature tool for Java and Plugin Development Growing market share –Research and Industry Active Developer Community In short: a viable tool to leverage now –http://www.eclipse.org

56 Caveats Steep Initial Learning Curve Lagging Documentation –but “system is the curriculum…” Designer Bias –“strong world view” –pervasively file-oriented

57 Plan 1.Sweet Tooling issues 2.Introduction to Eclipse 3.Sweet Plugin at a glance 4.Implementation notes 5.Pitch and Caveats 6.Where next

58 Where next Short Term –Plugin improvements Export metadata (introductions) to Ant More sophisticated Error Reporting Context visualization –Sweet Programming Guide Long Term –Multi-view support

59 Programming in the 21 st century Emphasis on“ilities” –Reusability, evolvability, etc. –What about the “archies?” (hier/heter) The rub: current SOC technologies (HyperJ, AspectJ, etc) depose the dominant decomposition only to replace it with their own! It remains to be seen if their decomposition is any better! Polyphonic Programming! The time for multi-view AOSD Tool-support is now!


Download ppt "Sweet Talk (part 2) Tool Support for Sweet Phil Quitslund."

Similar presentations


Ads by Google