<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">The original email said this about options:</div>
<div class=""><br class="">
</div>
<div class="">If you want to retain and move the list, your best option is to create a new<br class="">
list on the service of your choice (for example, ITS provides mailing lists at<br class="">
<a href="https://itservices.uchicago.edu/services/mailing-lists" class="">https://itservices.uchicago.edu/services/mailing-lists</a>). </div>
<div class=""><br class="">
Once you've got your new list configured and ready, if you'd like we can point<br class="">
the existing listname to that new address. Or you can<br class="">
simply switch to using the new address, whatever that may be.<br class="">
<br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 29, 2015, at 7:17 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" class="">hategan@mcs.anl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Looks pretty good to me. Just two questions: is that OK with MCS folk,<br class="">
and is that OK with the CI (Ian?)?<br class="">
<br class="">
Mihael<br class="">
<br class="">
On Mon, 2015-06-29 at 18:28 -0500, Ketan Maheshwari wrote:<br class="">
<blockquote type="cite" class="">About mailing lists: can we move them to MCS mailing list?<br class="">
<br class="">
--<br class="">
Ketan<br class="">
<br class="">
On Mon, Jun 29, 2015 at 3:57 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" class="">hategan@mcs.anl.gov</a>> wrote:<br class="">
<blockquote type="cite" class="">Hi,<br class="">
<br class="">
I believe that there are a few issues that need some attention.<br class="">
<br class="">
The first one is the email from systems that our mailing lists are going<br class="">
to be retired. While I don't think that is a good idea, since those<br class="">
lists provide both branding for the CI as well as a convenient/painless<br class="">
setup for CI projects, it is probably happening for a good reason.<br class="">
<br class="">
So, we need to find a new place to host our mailing lists and then save<br class="">
our archives and transition to the new lists. Ideas welcome.<br class="">
<br class="">
<br class="">
<br class="">
Second is documentation. I'm still writing, but it is now more than just<br class="">
the skeleton that it was. You can see a snapshot here:<br class="">
<a href="http://www.mcs.anl.gov/~hategan/docs/trunk/ug/ug.html" class="">http://www.mcs.anl.gov/~hategan/docs/trunk/ug/ug.html</a><br class="">
<br class="">
I welcome feedback on the overall structure and organization at this<br class="">
point. Also, if you want to contribute a section that is missing, or<br class="">
find certain sections to be unpalatable, let's discuss. Please don't<br class="">
bother noticing small things, such as broken links. Almost all links are<br class="">
broken because I just put placeholders there. They will be fixed<br class="">
systematically once the text is written.<br class="">
<br class="">
<br class="">
<br class="">
Finally, while writing docs I had the chance (or the mental discomfort)<br class="">
of trying to explain why certain things just don't make much sense. For<br class="">
example, we say that variables are single assignment, but defining what<br class="">
exactly an assignment is can be messy. If you have some file input, you<br class="">
don't really assign to the corresponding variable. In fact, the fact<br class="">
that you don't make any explicit assignments is what makes the variable<br class="">
an input variable which in turns makes it assigned though the mapping<br class="">
declaration. This kind of Catch-22 design bothers me.<br class="">
<br class="">
Swift/T deals with the issue in a nice way (as far as I understand).<br class="">
Inputs are always assigned through a file() constructor. This is more<br class="">
elegant, at least for inputs. We should probably do the same: provide<br class="">
file(), <T> T glob(), etc, and restrict the traditional mappers to<br class="">
outputs. Mike will probably like the unifying idea. Anyway, I'll try to<br class="">
write these things down once I'm done with #2 and we can discuss them.<br class="">
<br class="">
Mihael<br class="">
<br class="">
_______________________________________________<br class="">
Swift-devel mailing list<br class="">
Swift-devel@ci.uchicago.edu<br class="">
https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel<br class="">
</blockquote>
</blockquote>
<br class="">
<br class="">
_______________________________________________<br class="">
Swift-devel mailing list<br class="">
<a href="mailto:Swift-devel@ci.uchicago.edu" class="">Swift-devel@ci.uchicago.edu</a><br class="">
https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel<br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>