[Swift-devel] Mailing lists, documentation update, etc.

[Foster, Ian T.]

The original email said this about options:

If you want to retain and move the list, your best option is to create a new
list on the service of your choice (for example, ITS provides mailing lists at
https://itservices.uchicago.edu/services/mailing-lists).

Once you've got your new list configured and ready, if you'd like we can point
the existing listname to that new address.  Or you can
simply switch to using the new address, whatever that may be.



On Jun 29, 2015, at 7:17 PM, Mihael Hategan <hategan at mcs.anl.gov<mailto:hategan at mcs.anl.gov>> wrote:

Looks pretty good to me. Just two questions: is that OK with MCS folk,
and is that OK with the CI (Ian?)?

Mihael

On Mon, 2015-06-29 at 18:28 -0500, Ketan Maheshwari wrote:
About mailing lists: can we move them to MCS mailing list?

--
Ketan

On Mon, Jun 29, 2015 at 3:57 PM, Mihael Hategan <hategan at mcs.anl.gov<mailto:hategan at mcs.anl.gov>> wrote:
Hi,

I believe that there are a few issues that need some attention.

The first one is the email from systems that our mailing lists are going
to be retired. While I don't think that is a good idea, since those
lists provide both branding for the CI as well as a convenient/painless
setup for CI projects, it is probably happening for a good reason.

So, we need to find a new place to host our mailing lists and then save
our archives and transition to the new lists. Ideas welcome.



Second is documentation. I'm still writing, but it is now more than just
the skeleton that it was. You can see a snapshot here:
http://www.mcs.anl.gov/~hategan/docs/trunk/ug/ug.html

I welcome feedback on the overall structure and organization at this
point. Also, if you want to contribute a section that is missing, or
find certain sections to be unpalatable, let's discuss. Please don't
bother noticing small things, such as broken links. Almost all links are
broken because I just put placeholders there. They will be fixed
systematically once the text is written.



Finally, while writing docs I had the chance (or the mental discomfort)
of trying to explain why certain things just don't make much sense. For
example, we say that variables are single assignment, but defining what
exactly an assignment is can be messy. If you have some file input, you
don't really assign to the corresponding variable. In fact, the fact
that you don't make any explicit assignments is what makes the variable
an input variable which in turns makes it assigned though the mapping
declaration. This kind of Catch-22 design bothers me.

Swift/T deals with the issue in a nice way (as far as I understand).
Inputs are always assigned through a file() constructor. This is more
elegant, at least for inputs. We should probably do the same: provide
file(), <T> T glob(), etc, and restrict the traditional mappers to
outputs. Mike will probably like the unifying idea. Anyway, I'll try to
write these things down once I'm done with #2 and we can discuss them.

Mihael

_______________________________________________
Swift-devel mailing list
Swift-devel at ci.uchicago.edu
https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel


_______________________________________________
Swift-devel mailing list
Swift-devel at ci.uchicago.edu<mailto:Swift-devel at ci.uchicago.edu>
https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150630/1ebe0b02/attachment.html>