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

[Mihael Hategan]

Right. I missed it at first. I'm guessing that means that we can keep
the @ci, so the only question is where it's hosted.

Mihael

On Mon, 2015-06-29 at 20:42 -0500, Foster, Ian T. wrote:
> 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>
> > 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
> > 
>