[Swift-devel] Planning next set of Swift features and releases
Michael Wilde
wilde at mcs.anl.gov
Tue Apr 21 13:32:54 CDT 2009
Before 0.9 is released, I want to discuss an agreed upon sequence for
the next set of enhancements and improvements, and a target set of dates
and release numbers for them.
It is a minor issue, but I see Swift 1.0 as having some greater
significance as a release number. You may or may not agree - but it
should be discussed and we should make a conscious decision on whats
next. Also minor but going from 0.9 to 0.10 is odd. 0.09 to 0.10 would
have been OK. 0.91 .92 makes more sense, or 0.9.1. I dont much care at
the moment.
The significance of calling something 1.0 thought will extend to funding
issues, as our next NSF report will be due soon - June 1 I think - and
concurrently I need to go to NSF and other agencies for continued
funding, probably with an unsolicited proposal.
My preference is to do 2 or more point releases in the next 16 weeks and
shoot for 1.0 by the end of August. The significance of that release is
that it will be the last under the current round of NSF funding. So
whether we call it 1.0, 1.1, whatever, it will be a milestone of sorts.
Below is a *very* rough draft of my features priorities. I want to ask
others to make a list of features important to you, so we can sort and
prioritize, and turn into a set of planned point releases.
Ian challenged me to narrow it to 10 features; I came close but have not
yet given it the thought it needs, looked through bugzilla, etc. Then I
backslid, but to pick 10, we need to consider more.
Serious effort on the feature and release list can start next week after
0.9 (and after my current grant pressure eases up a bit).
- Mike
*** rough features on Mike's mind:
(These are not sorted into categories yet, not of similar size; A few
more distant features crept in; others are missing)
Some of these require language deliberation, which makes them harder.
Some would make huge differences in usability (like better runtime
errors, with line numbers. Also hard, but very valuable).
Clean up mapper model.
- Names and interfaces (and maybe model):
- pos params to make externs more compact;
- single_file_mapper to take expressions in its short form.
- re-consider mixed type mappings (file and scalar)
Structure assignment and related issues
- remove limitations on this
- maybe some similar language limits to address
Good run time error messages with source code line numbers
- summary of errors at end of output is ineffective
- review of messages in log that should go to output
- review of message content in log
Coaster polishing and testing/robustness
- address scheduler anomalies
- 3 modes of provisioning
Condor-G support
tc.data and PATH extensions
- rename tc.data (e.g.: applist.txt)?
- clean up its format, make simpler to add apps.
app() syntax review
- trailing ";" confusing
- quoting review and improvements if needed
- multi-line
Auto app install
Make sites & tc config easy/instant for osg, tg, local clusters
- productive ADEM
namespace::name:version for function/app identifiers
Global variables
Swift command
- multi-site selection
- run management (maybe a separate command)
Scaling
- Efficient handling of 1M and more jobs per wf
- what else needed here?
Library / #include feature
Provenance
- make it end-user useful and ready
- easy to get perf numbers
- easy to associate swift parameters with files and runs
More logging / status reporting enhancement
- enhance format and info content of log tools report
Review of iteration and related flow of control issues
- why iterate seems hard to use
- for, do, while?
- functional equivalents
Built-in and/or intrinsic functions
- remove @
- additional string functions, perhaps other related builtins
- (time, date, sizeof, ...)
- Built-in function extensibility
- general external function mechanism - shell out? lib path?
-- Longer term:
Coasters on bgp, kraken and sico
IO and Data management improvements
- mtdm (cio) data management fully integrated, with extensibility
- broadcast
- pull
- batched output
- local data transfer bypass
More information about the Swift-devel
mailing list