Probably each task should have a storyboard and at least one page of discussion of implementation and interface-design issues. List of functions/tasks: Divided into: revision control, librarian, communication, design/code. Revision control/configuration management: automatic "make" view/develop particular revision Checkin/merge create deliverable executable or library create corresponding deliverable documentation (hardcopy or online) release recover design rationale by viewing previous evolution Librarian: import and export chunks of the database w/ other Igor sites import and export ASCII Dylan text create interface to conventional (non-Igor) library or subsystem automatic, semi-automatic from header files locate code for reuse by searching or browsing other reuse code location tools? indexing for reuse: manual keyword, automatic from descriptive text programming in the large: visual programming composition semantic or knowledge-based searches -- In addition to storing language objects such as methods, classes and modules, the library also implements meta-linguistic concepts of reuse such as templates, frameworks and libraries [this more conventional usage of "library" is confusing here...] Communication and management: bug report tracking reports of compiler errors and test results tracking of implementation effort w.r.t. design & requirements change logging interface with mail system (need text ID of versions and definitions for mail references.) authentication Design/code/debug tasks: develop/debug heterogeneous programs with: bidirectional calls and data sharing (OO object sharing?) choose program views describe what state-changes should be animated define new program views/annotate code with possible views code browsing (e.g. to design modifications) by link-following by searching create/browse alternate view (cross-referencing) writing new code extend/modify existing code (ripple analysis) running programs for interactive test/debug view program state (inspecting) augment environment with application-specific test/debug tools semi-automatic creation of test stubs/drivers create templates, libraries, viewing styles and other meta-objects manual and automatic code cross-referencing (hyper-links) create/update documentation create/update/run automatic tests dialog with compiler for tuning or error correction instrument and observe code for tuning (profiling) detect memory leaks Goals/requirements: Timeline: -- Dylan interpreter and cross-compiler (file based). (8/93) -- Simple foreign interface. (8/93) -- Hypercode editor with multiple views. (proto 1/94) -- Stand-alone Dylan system w/ persistent hypercode and environment. (6/94) -- Integrate version control and project management tools. (6/94) -- Start work on additional ports and non-core libraries. (6/94) -- Delivery mode. (1/95) -- Librarian. (1/95) Additional deliverables: -- GUI toolkit -- OODB interface UI requirements: -- Reasonable response time for all commands: no user-interface lockup. If necessary, commands may complete in the background, but care must be taken to avoid confusion. -- A user interface that does not overly intimidate new users, but that also doesn't hinder experts. We're going to have some new functionality, and we want to encourage people to learn to use it. -- Easy transition between kinds of work (edit/debug/document/profile) and support for simultaneous reference/modification of all reasonable combinations of these modes. -- The code viewer allows consistent manipulation of code strings, templates, and modules in one framework, all the while preserving the programmer's ability to view and edit the code at different levels of abstraction. -- Support for management of complexity by consistently offering: - ellipsis - organizational structures (hierarchies and diagrams) - free choice of alternate views - uniform concept of object reference that allows almost anything to be cross-referenced or annotated. -- Automatically generated cross-referencing and visualization displays can be manually edited and preserved for future reference. -- Advisory sequencing style. Demons may discover issues to be addressed by the programmer, but this does not break the programmer's concentration. Advice does not require immediate response, it is displayed in an unintrusive way such as highlighting or a message area. Unresolved advisories are saved for future reference. Miscellaneous constraints/goals: -- Excellent efficiency in delivery mode; delivered code can run on platforms that are less powerful or more restrictive than the development platform. -- Excellent support for creating hetrogenous systems by gluing together existing software written in conventional languages. System resource requirements: -- medium to high-end networked color workstations -- must support projects at least as large as Igor: 10 programmers/workstations, 500k lines of code, 100k indexed objects -- should be scalable to large projects -- separate projects require no administrative or resource coordination William: Code is compiled in a current module. Variables are locals vars + used interfaces. Current subsystem: a library or program Libraries that you use. (an attribute of the current subsystem) Module trees of used libraries are unified when subsystem is configured Available interfaces are those defined in this module or in a used library. Graph of the "use" relation on subsystems. Leaves are programs. Possibly cyclic. "dylan" is the root. Library info is considered r/o and is cached. Libraries can be versioned so that we decache when a library is updated. internal module vars cannot be accessed across subsystem boundaries. Only certain interfaces can be seen by users of a library? This would be advantageous for library composition, since indirectly used libraries wouldn't pollute the linker/configuration namespace. Libraries are implicitly composed via the uses relation. The linker automatically traverses the library dependency graph Glossary: PROJECT: Each project has a central PROJECT DATABASE which contains the checked-in versions of the "stuff" for a particular system, and everything else we want to know about that system. As the name suggests, a project is to some degree an administrative unit, however a managerial project might have several project databases. Each project has a hierarchical namespace which is used to locate/retain the subsystems of that project. (SUB)SYSTEM: A subsystem is a collection of code (a set of definitions for methods, types, etc.) and an associated namespace (Dylan module.) Subsystems can depend on other subsystems (e.g. libraries), and are the basic unit of system construction. Subsystems persist across multiple revisions, so to refer to precise set of definitions, the version is also necessary (see CONFIGURATION). The proper relationship between subsystems and Dylan modules is unclear. Equating modules and subsystems is both attractively simple and well-precedented, but is somewhat arbitrary. However, there doesn't seem to be any real loss of power by requiring each subsystem to define a new namespace. Subsystems seem more heavy-weight than than modules, though. WORKSPACE: A workspace is the persistent state of a programmer's interaction with a project. Normally there would be one programmer per workspace, with the workspace server running on that programmer's workstation. However, we ought to support multiple SESSIONS on a workspace to allow cooperative debugging, etc. PROGRAMMER: A programmer (who may be a member of any number of projects) has some online information associated with them. Current login sessions, what their user interface preferences & customizations are, persistent state of the their last interactive session (window positions, etc.) SESSION: The non-persistent process or processes that implement the programmer interface. Generally the visible state of the session should be checkpointed in the programmer's database. Each session can have any number of TARGET (slave) processes which would contain code corresponding to some workspace. CONFIGURATION: A configuration is a (hopefully consistent) list of particular versions of the subsystems in a given system. Some of those subsystems might belong to other projects. RELEASE: A release is a configuration + policy options. Normally a workspace will be created as a copy of some base release that development departs from. Other projects can depend on or "use" released subsystems. This is a read-only relation in the sense that the project might decide to overwrite some of the stuff it inherits, but this will just shadow the actual definition, not modify it. For example, the system code will be a project which user applications will depend on. Normally a workspace will be created as a copy of some base release that development departs from. Building a release triggers a certain amount of work. Modified code must be recompiled under the specified policy, possibly involving delivery-mode block-compilation. Automatic regression testing might be done at this time. If the release is to be shared across projects or distributed, then a read-only copy of the relevant parts of the database must be created. Old source versions and other drek can be filtered out when replicating for release. The policy specifies whether the release needs to be copied, and what should be retained in the release. Releases are also versioned; building a release creates a new version of that release. The most recently built release does not automatically become current; it is possible to have pre-releases undergoing testing.