From hategan at mcs.anl.gov Fri Jun 5 14:29:07 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Fri, 5 Jun 2015 12:29:07 -0700 Subject: [Swift-devel] trying v2 stdlib Message-ID: <1433532547.13131.2.camel@echo3> Hi, Mike asked about how one can try the v2 library, so here it is: 1. use trunk 2. see https://github.com/swift-lang/swift-k/wiki/StandardLibrary for some documentation. The koala is the sign that a function is implemented in /K. 3. use import "stdlib.v2"; in the beginning of your script. Mihael From ketan at mcs.anl.gov Mon Jun 8 13:34:52 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Mon, 8 Jun 2015 13:34:52 -0500 Subject: [Swift-devel] trying v2 stdlib In-Reply-To: <1433532547.13131.2.camel@echo3> References: <1433532547.13131.2.camel@echo3> Message-ID: Trying this. Could it be the case that importing the stdlib.v2 suppresses the other functions: $ swift const.swift Swift trunk git-rev: f1abaa217c4e7c4b18b39e2323c572d9e0abc6d8 heads/master 6370 RunID: run007 Could not start execution: Compile error in procedure invocation at 6: No function or procedure 'tracef' found tracef() works when I remove the import line. Here is my test script: import "stdlib.v2"; //float PI=3.14159; //float E=2.71828; tracef("%f, %f\n" , PI,E); -- Ketan On Fri, Jun 5, 2015 at 2:29 PM, Mihael Hategan wrote: > Hi, > > Mike asked about how one can try the v2 library, so here it is: > > 1. use trunk > 2. see https://github.com/swift-lang/swift-k/wiki/StandardLibrary for > some documentation. The koala is the sign that a function is implemented > in /K. > 3. use > import "stdlib.v2"; > in the beginning of your script. > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From hategan at mcs.anl.gov Mon Jun 8 13:46:15 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 8 Jun 2015 11:46:15 -0700 Subject: [Swift-devel] trying v2 stdlib In-Reply-To: References: <1433532547.13131.2.camel@echo3> Message-ID: <1433789175.19146.0.camel@echo3> Yes. When you import v2 you lose v1. Mihael On Mon, 2015-06-08 at 13:34 -0500, Ketan Maheshwari wrote: > Trying this. Could it be the case that importing the stdlib.v2 > suppresses the other functions: > > $ swift const.swift > Swift trunk git-rev: f1abaa217c4e7c4b18b39e2323c572d9e0abc6d8 heads/master 6370 > RunID: run007 > Could not start execution: > Compile error in procedure invocation at 6: > No function or procedure 'tracef' found > > tracef() works when I remove the import line. > > Here is my test script: > > import "stdlib.v2"; > > //float PI=3.14159; > //float E=2.71828; > tracef("%f, %f\n" , PI,E); > > -- > Ketan > > On Fri, Jun 5, 2015 at 2:29 PM, Mihael Hategan wrote: > > Hi, > > > > Mike asked about how one can try the v2 library, so here it is: > > > > 1. use trunk > > 2. see https://github.com/swift-lang/swift-k/wiki/StandardLibrary for > > some documentation. The koala is the sign that a function is implemented > > in /K. > > 3. use > > import "stdlib.v2"; > > in the beginning of your script. > > > > Mihael > > > > _______________________________________________ > > Swift-devel mailing list > > Swift-devel at ci.uchicago.edu > > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel From iraicu at cs.iit.edu Thu Jun 11 07:34:23 2015 From: iraicu at cs.iit.edu (Ioan Raicu) Date: Thu, 11 Jun 2015 07:34:23 -0500 Subject: [Swift-devel] CFP: 2nd IEEE/ACM International Symposium on Big Data Computing (BDC) 2015 -- co-located with IEEE/ACM UCC 2015 Message-ID: <5579804F.7010202@cs.iit.edu> CALL FOR PAPERS --------------------------------------------------------------------------------------- 2nd IEEE/ACM International Symposium on Big Data Computing (BDC) 2015 http://datasys.cs.iit.edu/events/BDC2015/ --------------------------------------------------------------------------------------- December 7-10, 2015 St. Raphael Resort, Limassol, Cyprus Co-located with 8th IEEE/ACM International Conference on Utility and Cloud Computing ======================================================================================= Rapid advances in digital sensors, networks, storage, and computation along with their availability at low cost is leading to the creation of huge collections of data -- dubbed as Big Data. This data has the potential for enabling new insights that can change the way business, science, and governments deliver services to their consumers and can impact society as a whole. This has led to the emergence of the Big Data Computing paradigm focusing on sensing, collection, storage, management and analysis of data from variety of sources to enable new value and insights. To realize the full potential of Big Data Computing, we need to address several challenges and develop suitable conceptual and technological solutions for dealing them. These include life-cycle management of data, large-scale storage, flexible processing infrastructure, data modeling, scalable machine learning and data analysis algorithms, techniques for sampling and making trade-off between data processing time and accuracy, and dealing with privacy and ethical issues involved in data sensing, storage, processing, and actions. The International Symposium on Big Data Computing (BDC) 2015 -- held in conjunction with 8th IEEE/ACM International Conference on Utility and Cloud Computing (UCC) 2015, December 7-10, 2015, St. Raphael Resort, Limassol, Cyprus, aims at bringing together international researchers, developers, policy makers, and users and to provide an international forum to present leading research activities, technical solutions, and results on a broad range of topics related to Big Data Computing paradigms, platforms and their applications. The conference features keynotes, technical presentations, posters, and workshops. TOPICS: --------------------------------------------------------------------------------------- I. Big Data Science * Analytics * Algorithms for Big Data * Energy-efficient Algorithms * Big Data Search * Big Data Acquisition, Integration, Cleaning, and Best Practices * Visualization of Big Data II. Big Data Infrastructures and Platforms * Programming Systems * Cyber-Infrastructure * Performance evaluation * Fault tolerance and reliability * I/O and Data management * Storage Systems (including file systems, NoSQL, and RDBMS) * Resource management * Many-Task Computing * Many-core computing and accelerators III. Big Data Security and Policy * Management Policies * Data Privacy * Data Security * Big Data Archival and Preservation * Big Data Provenance IV. Big Data Applications * Scientific application cases studies on Cloud infrastructure * Big Data Applications at Scale * Experience Papers with Big Data Application Deployments * Data streaming applications * Big Data in Social Networks * Healthcare Applications * Enterprise Applications IMPORTANT DATES --------------------------------------------------------------------------------------- Papers: * Papers Due: 03 July, 2015 * Author Notifications: 21 August, 2015 * Final Papers Due: 21 September, 2015 Posters * Proceedings-published posters due: 28 August, 2015 * Notification of acceptance: 18 September, 2015 * Camera-ready posters due: 21 September, 2015 PAPER SUBMISSION --------------------------------------------------------------------------------------- Authors are invited to submit papers electronically. Submitted manuscripts should be structured as technical papers and may not exceed 10 letter size (8.5 x 11) pages including figures, tables and references using the following templates (latex, pdf, doc). Authors should submit the manuscript in PDF format and make sure that the file will print on a printer that uses letter size (8.5 x 11) paper. The official language of the meeting is English. All manuscripts will be reviewed and will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the conference attendees. Papers conforming to the above guidelines can be submitted through the BDC 2015 paper submission system (https://www.easychair.org/conferences/?conf=bdc2015). Submitted papers must represent original unpublished research that is not currently under review for any other conference or journal. Papers not following these guidelines will be rejected without review and further action may be taken, including (but not limited to) notifications sent to the heads of the institutions of the authors and sponsors of the conference. Submissions received after the due date, exceeding length limit, or not appropriately structured may also not be considered. Authors may contact the conference PC Chair for more information. Selected papers from BDC 2015 will be invited to extend and submit to the Special Issue on Big Data Computing in the IEEE Transaction on Cloud Computing. ORGANIZATION --------------------------------------------------------------------------------------- General Chairs * Rajkumar Buyya, University of Melbourne, Australia * George Angelos Papadopoulos,University of Cyprus, Cyprus Program Committee Chairs (bdc15-chairs at datasys.cs.iit.edu) * Ioan Raicu, Illinois Institute of Technology & Argonne National Laboratory, USA * Amy Apon, National Science Foundation, USA * Manish Parashar, Rutgers University, USA Program Committee Vice Chairs * Omer Rana, Cardiff University, UK * Ilkay Altintas, University of California, San Diego, USA Program Committee Members * Alexander Rasin, DePaul University, USA * Alok Choudhary, Northwestern University, USA * Abhishek Chandra, University of Minnesota, USA * Andre Luckow, BMW IT Research Center, USA * Daniel Katz, University of Chicago and Argonne National Lab, USA * Dongfang Zhao, Illinois Institute of Technology, USA * Douglas Thain, University of Notre Dame, USA * Florian Schintke, Zuse Institute Berlin, Germany * Giuliano Casale, Imperial College London, UK * Jaliya Ekanayake, Microsoft, USA * Jessica Chen-Burger, Heriot-Watt University, UK * Judy Qiu, Indiana University, USA * Justin Wozniak, Argonne National Lab, USA * Ke Wang, Illinois Institute of Technology, USA * Kesheng (John) Wu, Lawrence Berkeley National Lab, USA * Kyle Chard, University of Chicago and Argonne National Lab, USA * Lavanya Ramakrishnan, Lawrence Berkeley National Laboratory, USA * Marco Netto, IBM Research, Brazil * Matei Ripeanu, University of British Columbia, Canada * Matei Stroila, HERE, USA * Nagiza Samatova, North Carolina State University, USA * Paolo Missier, Newcastle University, UK * Paul Watson, NewCastle University, UK * Peter Burnap, Cardiff University, UK * Rahul Potharaju, Microsoft, USA * Rajkumar Kettimuthu, Argonne National Lab and University of Chicago, USA * Robert Ross, Argonne National Lab, USA * Samer Al-Kiswany, University of British Columbia, Canada * Scott Klasky, Oak Ridge National Lab, USA * Wei Tang, Argonne National Lab, USA * Weidong Shi, University of Houston, USA * Xiaolin (Andy) Li, University of Florida, USA * Yanlong Yin, Bloomberg, USA * Yong Chen, Texas Tech University, USA * Yong Zhao, University of Electronic Science and Technology, China * Zhao Zhang, University of California, Berkeley, USA Cyber Co-Chairs * Dongfang Zhao, Illinois Institute of Technology, USA Local Organizing Committee * George Angelos Papadopoulos, University of Cyprus, Cyprus SPONSORSHIP --------------------------------------------------------------------------------------- IEEE*, ACM*, and IIT* *Final approval on sponsorship is pending. -- ================================================================= Ioan Raicu, Ph.D. Assistant Professor, Illinois Institute of Technology (IIT) Guest Research Faculty, Argonne National Laboratory (ANL) ================================================================= Data-Intensive Distributed Systems Laboratory, CS/IIT Distributed Systems Laboratory, MCS/ANL ================================================================= Editor: IEEE TCC, Springer Cluster, Springer JoCCASA Chair: IEEE/ACM MTAGS, ACM ScienceCloud ================================================================= Office: 1-312-567-5704 Email: iraicu at cs.iit.edu Web: http://www.cs.iit.edu/~iraicu/ Web: http://datasys.cs.iit.edu/ LinkedIn: http://www.linkedin.com/in/ioanraicu Google: http://scholar.google.com/citations?user=jE73HYAAAAAJ ================================================================= ================================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Tue Jun 16 15:31:10 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 16 Jun 2015 13:31:10 -0700 Subject: [Swift-devel] swift js/editor Message-ID: <1434486670.29334.3.camel@echo3> Hi, I mentioned a swift javascript editor that I was playing with. Here it is: http://www.mcs.anl.gov/~hategan/cmswift/ It should be able to parse most modern Swift as you type it. Mihael From wilde at anl.gov Tue Jun 16 18:28:06 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 16 Jun 2015 18:28:06 -0500 Subject: [Swift-devel] swift js/editor In-Reply-To: <1434486670.29334.3.camel@echo3> References: <1434486670.29334.3.camel@echo3> Message-ID: <5580B106.5030703@anl.gov> It has a very nice feel to it so far. Does it have its own notion of indentation? Seems to let me do anything in that regard but seems to have some tab sensitivity. It was able to fix an underlined error for an undefined var after I defined it. It would be interesting to understand where this can ultimately go. The emacs compatibility is nice; how extensive is that? - Mike On 6/16/15 3:31 PM, Mihael Hategan wrote: > Hi, > > I mentioned a swift javascript editor that I was playing with. Here it > is: > > http://www.mcs.anl.gov/~hategan/cmswift/ > > It should be able to parse most modern Swift as you type it. > > Mihael > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Tue Jun 16 18:40:28 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 16 Jun 2015 16:40:28 -0700 Subject: [Swift-devel] swift js/editor In-Reply-To: <5580B106.5030703@anl.gov> References: <1434486670.29334.3.camel@echo3> <5580B106.5030703@anl.gov> Message-ID: <1434498028.31586.5.camel@echo3> On Tue, 2015-06-16 at 18:28 -0500, Michael Wilde wrote: > It has a very nice feel to it so far. > > Does it have its own notion of indentation? Seems to let me do anything > in that regard but seems to have some tab sensitivity. It's based on http://codemirror.net/index.html, which is also what LightTable is based on. Automatic indentation can be added. > > It was able to fix an underlined error for an undefined var after I > defined it. I think that's some form of accident. It currently does not highlight semantic errors, but that's clearly something that it should eventually do. It has an almost vanilla swift grammar in there. > > It would be interesting to understand where this can ultimately go. Technically there are many possibilities. > > The emacs compatibility is nice; how extensive is that? No idea. Didn't even know it existed until you mentioned it. Mihael From wilde at anl.gov Tue Jun 16 18:43:13 2015 From: wilde at anl.gov (Michael Wilde) Date: Tue, 16 Jun 2015 18:43:13 -0500 Subject: [Swift-devel] swift js/editor In-Reply-To: <1434498028.31586.5.camel@echo3> References: <1434486670.29334.3.camel@echo3> <5580B106.5030703@anl.gov> <1434498028.31586.5.camel@echo3> Message-ID: <5580B491.4040503@anl.gov> Very curious. It underlined a undefined var name with a wavy red line, like a spelling error, and that went away after I scrolled up and declared the var (an int array). Maybe it was some kind of default text-tool spelling semantics? Weird. - Mike On 6/16/15 6:40 PM, Mihael Hategan wrote: >> It was able to fix an underlined error for an undefined var after I >> >defined it. > I think that's some form of accident. It currently does not highlight > semantic errors, but that's clearly something that it should eventually > do. It has an almost vanilla swift grammar in there. > -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Tue Jun 16 18:47:56 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 16 Jun 2015 16:47:56 -0700 Subject: [Swift-devel] swift js/editor In-Reply-To: <5580B491.4040503@anl.gov> References: <1434486670.29334.3.camel@echo3> <5580B106.5030703@anl.gov> <1434498028.31586.5.camel@echo3> <5580B491.4040503@anl.gov> Message-ID: <1434498476.31586.7.camel@echo3> On Tue, 2015-06-16 at 18:43 -0500, Michael Wilde wrote: > Very curious. It underlined a undefined var name with a wavy red line, > like a spelling error, and that went away after I scrolled up and > declared the var (an int array). > > Maybe it was some kind of default text-tool spelling semantics? I don't think so. But it does have context, so if you have a parsing error, it might mark code that follows as an error. Mihael > > Weird. > > - Mike > > > On 6/16/15 6:40 PM, Mihael Hategan wrote: > >> It was able to fix an underlined error for an undefined var after I > >> >defined it. > > I think that's some form of accident. It currently does not highlight > > semantic errors, but that's clearly something that it should eventually > > do. It has an almost vanilla swift grammar in there. > > > From iraicu at cs.iit.edu Wed Jun 17 01:04:49 2015 From: iraicu at cs.iit.edu (Ioan Raicu) Date: Tue, 16 Jun 2015 23:04:49 -0700 Subject: [Swift-devel] Call for Participation: IEEE Cluster 2015 in Chicago, September 8-11 Message-ID: <55810E01.1010008@cs.iit.edu> IEEE International Conference on Cluster Computing September 8-11, 2015 Chicago, IL, USA http://www.mcs.anl.gov/ieeecluster2015/ **** NEWS **** * 38 full papers accepted out of 157 submissions (24% acceptance rate) * 28 short papers with oral presentations * 30 peer-reviewed posters * 3 keynotes * 6 workshops * Panel on exascale computing * 2 industry sessions with talks from Cray and DDN * Student Mentoring Program * Student Travel Support * Early bird registration: July 25th, 2015 * Hotel Reservation: August 17th, 2015 **** CALL FOR PARTICIPATION **** Clusters have become the workhorse for computational science and engineering research, powering innovation and discovery that advance science and society. They are the base for building today?s rapidly evolving cloud and HPC infrastructures, and are used to solve some of the most complex problems. Clusters are the base for building today?s rapidly evolving cloud and HPC infrastructure, and are used to solve some of the most complex problems. The challenge to make them scalable, efficient, and more functional requires the common effort of the cluster community in the areas of cluster system design, management and monitoring ? at hardware, system, middleware, and application level. The IEEE Cluster conference has precisely this goal: to be a major venue for such collective effort. We are happy to announce a rich, high-quality conference program for IEEE Cluster 2015 with 38 full papers accepted out of 157 submissions that went through a selective reviewing process (over 600 reviews), resulting in an acceptance rate of 24%. In addition the conference features 28 short papers and 30 peer-reviewed posters present exciting, emergent research directions. The conference program includes three keynotes, six workshops, a panel on exascale computing, and two industry sessions with talks from Cray and Data Direct Networks (DDN) - two major players with high impact in the area of cluster computing. We continue the successful Student Mentoring Program specific to PhD students, which will include student travel support; for more information, see http://www.mcs.anl.gov/ieeecluster2015/student-program/. The entire program of IEEE Cluster is now available at http://press3.mcs.anl.gov/ieeecluster2015/conference-program/technical-program. The Organizing Committee is happy to welcome you to Chicago and hopes you find Cluster 2015 an exciting and intellectually stimulating event! *Venue and Accommodation* The conference and the affiliated workshops are held in the Double Tree Hotel Chicago Magnificent Mile, which is centrally located and within walking distance of numerous attractions in downtown Chicago, Illinois. The hotel is holding a block of rooms reserved at a very special rate for Cluster 2015 participants. Book your room at: http://www.mcs.anl.gov/ieeecluster2015/registration-and-accommodation/accommodation/ *Registration* Register for the conference at http://www.mcs.anl.gov/ieeecluster2015/registration-and-accommodation/registration/ * **Important Dates* Early Bird Conference Registration Cut-off Date: July 25, 2015 Hotel Reservation Cut-off: August 17, 2015 Main Conference: September 8-11, 2015 Workshops: September 8, 2015 -- ================================================================= Ioan Raicu, Ph.D. Assistant Professor, Illinois Institute of Technology (IIT) Guest Research Faculty, Argonne National Laboratory (ANL) ================================================================= Data-Intensive Distributed Systems Laboratory, CS/IIT Distributed Systems Laboratory, MCS/ANL ================================================================= Editor: IEEE TCC, Springer Cluster, Springer JoCCASA Chair: IEEE/ACM MTAGS, ACM ScienceCloud ================================================================= Office: 1-312-567-5704 Email: iraicu at cs.iit.edu Web: http://www.cs.iit.edu/~iraicu/ Web: http://datasys.cs.iit.edu/ LinkedIn: http://www.linkedin.com/in/ioanraicu Google: http://scholar.google.com/citations?user=jE73HYAAAAAJ ================================================================= ================================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: From yadunand at uchicago.edu Mon Jun 22 15:48:16 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Mon, 22 Jun 2015 15:48:16 -0500 Subject: [Swift-devel] CI systems and services going out of support Message-ID: <55887490.9050700@uchicago.edu> Hi, David Forero is leaving CI by the first week of July, and he mentioned that there are no plans so far on who will take over his role. This directly impacts these machines and services: - login.ci.uchicago.edu : Website hosting for swift-lang.org - ci list host : swift-devel, swift-user, swift-info - swiftvm[1..4].ci.uchicago.edu : Tryswift hosting. - svn.ci.uchicago.edu : I am not sure how complete our move to github has been. The next time the system goes down, it might not come back up at all. - communicado/bridled. I am not sure who will maintain these machines. - ci support will be mostly non-responsive. In short we need to find alternatives for these services and move very soon. Thanks, Yadu From hategan at mcs.anl.gov Mon Jun 29 14:12:43 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 12:12:43 -0700 Subject: [Swift-devel] Parallel Works Message-ID: <1435605163.21437.13.camel@echo3> Hi, You might have heard this, but I wanted to mention it personally. I will be working for Parallel Works starting July 1st. While I wanted to keep my current CI position, the legal aspects were a bit too messy, so I will be resigning from the CI. In practice, there shouldn't be much difference from how things are now. While there is some uncertainty in any future plans, I expect that I would be devoting an equal amount of time to Swift things as I was over the past few years. The long term plans are still being worked on. We expect that this will be happening for three months, during which Parallel Works will figure out whether this arrangement should/can continue or not. Mike or I will probably let you know what's happening as we go along. Please feel free to ask questions. Mihael From hategan at mcs.anl.gov Mon Jun 29 15:57:45 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 13:57:45 -0700 Subject: [Swift-devel] Mailing lists, documentation update, etc. Message-ID: <1435611465.23895.17.camel@echo3> 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 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 From ketan at mcs.anl.gov Mon Jun 29 18:28:22 2015 From: ketan at mcs.anl.gov (Ketan Maheshwari) Date: Mon, 29 Jun 2015 18:28:22 -0500 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <1435611465.23895.17.camel@echo3> References: <1435611465.23895.17.camel@echo3> Message-ID: About mailing lists: can we move them to MCS mailing list? -- Ketan On Mon, Jun 29, 2015 at 3:57 PM, Mihael Hategan 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 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 From hategan at mcs.anl.gov Mon Jun 29 19:17:39 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 17:17:39 -0700 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: References: <1435611465.23895.17.camel@echo3> Message-ID: <1435623459.18276.2.camel@echo3> 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 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 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 From yadunand at uchicago.edu Mon Jun 29 19:53:38 2015 From: yadunand at uchicago.edu (Yadu Nand Babuji) Date: Mon, 29 Jun 2015 19:53:38 -0500 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <1435623459.18276.2.camel@echo3> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> Message-ID: <5591E892.8000209@uchicago.edu> 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 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 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 From hategan at mcs.anl.gov Mon Jun 29 20:02:30 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 18:02:30 -0700 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <5591E892.8000209@uchicago.edu> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> <5591E892.8000209@uchicago.edu> Message-ID: <1435626150.19410.5.camel@echo3> On Mon, 2015-06-29 at 19:53 -0500, Yadu Nand Babuji wrote: > 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. ... which seems to make MCS even more attractive. IT services does have something: https://itservices.uchicago.edu/services/mailing-lists However, when I try to log in, it doesn't recognize my cnet credentials. Btw, I'm acting on an email from Craig. I think these are sent to the list administrators, so you may not have seen it: ------------------------------ As previously announced, the CI mailing list server will soon be retired. You're receiving this message as a list owner of a list housed at lists.ci.uchicago.edu. Specifically, the following list: Swift-user at ci.uchicago.edu, Last post at Thu Jun 18 19:01:03 2015. https://lists.ci.uchicago.edu/mailman/listinfo/Swift-user (Note the above link also contains a link to any archives of the list as well.) If you do nothing, the list will stop working at end of July. Any archives that exist will disappear when the server is retired at that point. Mail sent to Swift-user at ci.uchicago.edu and Swift-user at lists.ci.uchicago.edu will bounce, and the sender will receive a notice that the address is no longer valid. 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). We don't have a way to automate this process of moving from one service to another, unfortunately. However, if you'd like a raw text dump of your existing configuration and membership, we can provide that, simply let us know. Otherwise, the web UI to see your existing configuration and membership can be found at https://lists.ci.uchicago.edu/mailman/admin/Swift-user. If you've forgotten the password for your list, please let us know and we'll reset it. Once you've got your new list configured and ready, if you'd like we can point the existing listname Swift-user at ci.uchicago.edu to that new address. Or you can simply switch to using the new address, whatever that may be. If you want the archives of your old CI list, let us know. We can provide the raw archives (including static HTML files) for you to use as you wish. We do not have a method of transferring the archives to whatever list provider you choose to use for your new list, however. Thanks, and sorry for the inconvenience. ------------------------------ Mihael From foster at anl.gov Mon Jun 29 20:42:30 2015 From: foster at anl.gov (Foster, Ian T.) Date: Tue, 30 Jun 2015 01:42:30 +0000 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <1435623459.18276.2.camel@echo3> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> Message-ID: <25C95E96-2303-437F-B733-9F285C5F7D60@anl.gov> 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 > 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 > 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hategan at mcs.anl.gov Mon Jun 29 20:57:50 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 18:57:50 -0700 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <25C95E96-2303-437F-B733-9F285C5F7D60@anl.gov> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> <25C95E96-2303-437F-B733-9F285C5F7D60@anl.gov> Message-ID: <1435629470.20175.2.camel@echo3> 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 > > 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 > > > 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 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 > > > From wilde at anl.gov Mon Jun 29 23:16:59 2015 From: wilde at anl.gov (Michael Wilde) Date: Mon, 29 Jun 2015 23:16:59 -0500 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <1435629470.20175.2.camel@echo3> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> <25C95E96-2303-437F-B733-9F285C5F7D60@anl.gov> <1435629470.20175.2.camel@echo3> Message-ID: <5592183B.8020507@anl.gov> This may be a good time to make the lists appear to be hosted at swift-lang.org. It would also be good to move the list archives to that domain. We should see if that is possible, an dhow forwarding would work. - Mike On 6/29/15 8:57 PM, Mihael Hategan wrote: > 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 >>> 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 >>>> 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 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 >>> > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel -- Michael Wilde Mathematics and Computer Science Computation Institute Argonne National Laboratory The University of Chicago From hategan at mcs.anl.gov Tue Jun 30 01:53:10 2015 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 29 Jun 2015 23:53:10 -0700 Subject: [Swift-devel] Mailing lists, documentation update, etc. In-Reply-To: <5592183B.8020507@anl.gov> References: <1435611465.23895.17.camel@echo3> <1435623459.18276.2.camel@echo3> <25C95E96-2303-437F-B733-9F285C5F7D60@anl.gov> <1435629470.20175.2.camel@echo3> <5592183B.8020507@anl.gov> Message-ID: <1435647190.20175.6.camel@echo3> On Mon, 2015-06-29 at 23:16 -0500, Michael Wilde wrote: > This may be a good time to make the lists appear to be hosted at > swift-lang.org. An even better idea. > > It would also be good to move the list archives to that domain. We > should see if that is possible, an dhow forwarding would work. Yeah, I don't get how this works, but from Ian's quote of what Craig says, the implementation and the interface seem to be different things. So we should probably talk to Craig. Mihael From tim.g.armstrong at gmail.com Tue Jun 30 16:54:40 2015 From: tim.g.armstrong at gmail.com (Tim Armstrong) Date: Tue, 30 Jun 2015 16:54:40 -0500 Subject: [Swift-devel] Parallel Works In-Reply-To: <1435605163.21437.13.camel@echo3> References: <1435605163.21437.13.camel@echo3> Message-ID: Congrats, I'm excited to see how things progress with Parallel Works! On 29 June 2015 at 14:12, Mihael Hategan wrote: > Hi, > > You might have heard this, but I wanted to mention it personally. > > I will be working for Parallel Works starting July 1st. While I wanted > to keep my current CI position, the legal aspects were a bit too messy, > so I will be resigning from the CI. > > In practice, there shouldn't be much difference from how things are now. > While there is some uncertainty in any future plans, I expect that I > would be devoting an equal amount of time to Swift things as I was over > the past few years. > > The long term plans are still being worked on. We expect that this will > be happening for three months, during which Parallel Works will figure > out whether this arrangement should/can continue or not. Mike or I will > probably let you know what's happening as we go along. > > Please feel free to ask questions. > > Mihael > > _______________________________________________ > Swift-devel mailing list > 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: