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

[Yadu Nand Babuji]

There was mention of UChicago IT services taking over for critical 
services, though
it wasn't clear what services they will take over. I can check with 
David again
tomorrow, but the last time I talked to him, he said that there was no 
clear plan in place.

-Yadu

On 06/29/2015 07:17 PM, Mihael Hategan 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> 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
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel