Haskell Communities and Activities Report 2014

Total Page:16

File Type:pdf, Size:1020Kb

Haskell Communities and Activities Report 2014 Haskell Communities and Activities Report http://tinyurl.com/haskcar Twenty-Seventh Edition — November 2014 Mihai Maruseac, Alejandro Serrano Mena (eds.) Andreas Abel Alexander Granin Heinrich Apfelmus Emil Axelsson Carl Baatz Doug Beardsley Jean-Philippe Bernardy Alexander Berntsen Jeroen Bransen Joachim Breitner Erik de Castro Lopo Lucas DiCioccio Roman Cheplyaka Olaf Chitil Alberto Gómez Corona Duncan Coutts Atze Dijkstra Péter Diviánszky Corentin Dupont Richard Eisenberg Andrew Farmer Dennis Felsing Julian Fleischer Michal J. Gajda Andrew Gibiansky Brett G. Giles Andy Gill Jurriaan Hage Greg Hale Bastiaan Heeren Sylvain Henry Lars Hupel PÁLI Gábor János Bob Ippolito Philipp Kant Robin KAY Anton Kholomiov Ian-Woo Kim Oleg Kiselyov Edward Kmett Eric Kow Nickolay Kudasov Ben Lippmeier Andres Löh Rita Loogen Boris Lykah Ian Lynagh Christian Maeder José Pedro Magalhães Ketil Malde Mihai Maruseac Dino Morelli JP Moresmau Ben Moseley Natalia Muska Tom Nielsen Rishiyur Nikhil Kiwamu Okabe Ivan Perez Jens Petersen Haskell Consultancy Munich Simon Peyton Jones Jeffrey Rosenbluth Ian Ross David Sabel Martijn Schrage Austin Seipp Carter Tazio Schonwald Jeremy Shaw Christian Höner zu Siederdissen Gideon Sireling Jim Snow Michael Snoyman Andrei Soare Kyle Marek-Spartz Doaitse Swierstra Henk-Jan van Tuyl Bernhard Urban Alessio Valentini Adam Vogt Daniel Wagner Greg Weber Kazu Yamamoto Edward Z. Yang Brent Yorgey Alan Zimmerman Preface This is the 27th edition of the Haskell Communities and Activities Report. As usual, fresh entries – either completely new or old entries which have been revived after a short temporarily disappearance – are formatted using a blue background, while updated entries have a header with a blue background. Entries on which no new activity has been reported for a year or longer have been dropped completely. Please do revive such entries next time if you do have news on them. A call for new HCAR entries and updates to existing ones will be issued on the Haskell mailing lists in March. It is possible that by that time we would have switched to a different generation pipeline. In that case, we might issue a call to update old entries which have been completely removed from the report in the past but are still there in the pipeline. Now enjoy the current report and see what other Haskellers have been up to lately. Any feedback is very welcome, as always. Mihai Maruseac, University of Massachusetts Boston, US Alejandro Serrano Mena, Utrecht University, Netherlands [email protected] 2 Contents 1 Community 4 1.1 Haskellers................................................... 4 2 Books, Articles, Tutorials 5 2.1 The Monad.Reader.............................................. 5 2.2 Oleg’s Mini Tutorials and Assorted Small Projects............................. 5 2.3 Agda Tutorial................................................. 6 2.4 School of Haskell............................................... 6 3 Implementations 7 3.1 The Glasgow Haskell Compiler........................................ 7 3.2 Ajhc Haskell Compiler............................................ 9 3.3 The Helium Compiler............................................. 10 3.4 UHC, Utrecht Haskell Compiler....................................... 10 3.5 Specific Platforms............................................... 10 3.5.1 Haskell on FreeBSD............................................. 10 3.5.2 Debian Haskell Group............................................ 11 3.5.3 Fedora Haskell SIG............................................. 11 4 Related Languages and Language Design 13 4.1 Agda...................................................... 13 4.2 MiniAgda................................................... 13 4.3 Disciple..................................................... 13 4.4 Ermine..................................................... 14 5 Haskell and . 15 5.1 Haskell and Parallelism............................................ 15 5.1.1 Eden..................................................... 15 5.1.2 speculation.................................................. 16 5.2 Haskell and the Web............................................. 16 5.2.1 WAI...................................................... 16 5.2.2 Warp..................................................... 16 5.2.3 Happstack.................................................. 17 5.2.4 Mighttpd2 — Yet another Web Server................................... 17 5.2.5 Yesod..................................................... 18 5.2.6 Snap Framework............................................... 19 5.2.7 Sunroof.................................................... 19 5.2.8 MFlow.................................................... 19 5.2.9 Scotty..................................................... 20 5.3 Haskell and Compiler Writing........................................ 21 5.3.1 MateVM................................................... 21 5.3.2 UUAG.................................................... 21 5.3.3 LQPL — A Quantum Programming Language Compiler and Emulator................ 22 5.3.4 free — Free Monads............................................. 23 5.3.5 bound — Making De Bruijn Succ Less.................................. 23 6 Development Tools 24 6.1 Environments................................................. 24 6.1.1 Haskell IDE From FP Complete...................................... 24 6.1.2 EclipseFP................................................... 24 6.1.3 ghc-mod — Happy Haskell Programming................................. 25 6.1.4 HaRe — The Haskell Refactorer...................................... 25 3 6.1.5 IHaskell: Haskell for Interactive Computing................................ 26 6.2 Code Management.............................................. 27 6.2.1 Darcs..................................................... 27 6.2.2 DarcsWatch................................................. 27 6.2.3 cab — A Maintenance Command of Haskell Cabal Packages...................... 27 6.3 Interfacing to other Languages........................................ 28 6.3.1 java-bridge.................................................. 28 6.3.2 fficxx..................................................... 28 6.4 Deployment.................................................. 29 6.4.1 Cabal and Hackage............................................. 29 6.4.2 Stackage: the Library Dependency Solution................................ 30 6.4.3 Haskell Cloud................................................ 30 6.5 Others..................................................... 31 6.5.1 lhs2TEX.................................................... 31 6.5.2 ghc-heap-view................................................ 31 6.5.3 ghc-vis.................................................... 31 6.5.4 Hat — the Haskell Tracer.......................................... 32 6.5.5 Tasty..................................................... 32 6.5.6 Automatic type inference from JSON................................... 33 7 Libraries, Applications, Projects 34 7.1 Language Features.............................................. 34 7.1.1 Conduit.................................................... 34 7.1.2 lens...................................................... 34 7.1.3 folds...................................................... 35 7.1.4 machines................................................... 35 7.1.5 exceptions.................................................. 35 7.1.6 tables..................................................... 35 7.1.7 Faking even more dependent types!.................................... 36 7.1.8 Type checking units-of-measure...................................... 36 7.1.9 Dependent Haskell.............................................. 36 7.2 Education................................................... 37 7.2.1 Exercism: crowd-sourced code reviews on daily practice problems................... 37 7.2.2 Talentbuddy................................................. 37 7.2.3 Holmes, Plagiarism Detection for Haskell................................. 37 7.2.4 Interactive Domain Reasoners....................................... 38 7.3 Parsing and Transforming.......................................... 39 7.3.1 epub-metadata................................................ 39 7.3.2 Utrecht Parser Combinator Library: uu-parsinglib............................ 39 7.3.3 Grammar Products, Set Grammars, and Automatic Outside Grammars................ 40 7.3.4 HERMIT................................................... 41 7.3.5 parsers.................................................... 41 7.3.6 trifecta.................................................... 42 7.4 Generic and Type-Level Programming................................... 42 7.4.1 Optimising Generic Functions....................................... 42 7.4.2 constraints.................................................. 42 7.5 Mathematics.................................................. 42 7.5.1 Rlang-QQ.................................................. 42 7.5.2 order-statistics................................................ 43 7.5.3 Eliminating Redundancies in Linear Systems............................... 43 7.5.4 linear..................................................... 43 7.5.5 algebra.................................................... 43 7.5.6 semigroups and semigroupoids....................................... 44 7.5.7 Arithmetics packages (Edward Kmett).................................. 44 7.5.8 ad....................................................... 44 7.5.9 integration.................................................
Recommended publications
  • ML Module Mania: a Type-Safe, Separately Compiled, Extensible Interpreter
    ML Module Mania: A Type-Safe, Separately Compiled, Extensible Interpreter The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citation Ramsey, Norman. 2005. ML Module Mania: A Type-Safe, Separately Compiled, Extensible Interpreter. Harvard Computer Science Group Technical Report TR-11-05. Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:25104737 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA ¡¢ £¥¤§¦©¨ © ¥ ! " $# %& !'( *)+ %¨,.-/£102©¨ 3¤4#576¥)+ %&8+9©¨ :1)+ 3';&'( )< %' =?>A@CBEDAFHG7DABJILKM GPORQQSOUT3V N W >BYXZ*[CK\@7]_^\`aKbF!^\K/c@C>ZdX eDf@hgiDf@kjmlnF!`ogpKb@CIh`q[UM W DABsr!@k`ajdtKAu!vwDAIhIkDi^Rx_Z!ILK[h[SI ML Module Mania: A Type-Safe, Separately Compiled, Extensible Interpreter Norman Ramsey Division of Engineering and Applied Sciences Harvard University Abstract An application that uses an embedded interpreter is writ- ten in two languages: Most code is written in the original, The new embedded interpreter Lua-ML combines extensi- host language (e.g., C, C++, or ML), but key parts can be bility and separate compilation without compromising type written in the embedded language. This organization has safety. The interpreter’s types are extended by applying a several benefits: sum constructor to built-in types and to extensions, then • Complex command-line arguments aren’t needed; the tying a recursive knot using a two-level type; the sum con- embedded language can be used on the command line.
    [Show full text]
  • Tierless Web Programming in ML Gabriel Radanne
    Tierless Web programming in ML Gabriel Radanne To cite this version: Gabriel Radanne. Tierless Web programming in ML. Programming Languages [cs.PL]. Université Paris Diderot (Paris 7), 2017. English. tel-01788885 HAL Id: tel-01788885 https://hal.archives-ouvertes.fr/tel-01788885 Submitted on 9 May 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Distributed under a Creative Commons Attribution - NonCommercial - ShareAlike| 4.0 International License Thèse de doctorat de l’Université Sorbonne Paris Cité Préparée à l’Université Paris Diderot au Laboratoire IRIF Ecole Doctorale 386 — Science Mathématiques De Paris Centre Tierless Web programming in ML par Gabriel Radanne Thèse de Doctorat d’informatique Dirigée par Roberto Di Cosmo et Jérôme Vouillon Thèse soutenue publiquement le 14 Novembre 2017 devant le jury constitué de Manuel Serrano Président du Jury Roberto Di Cosmo Directeur de thèse Jérôme Vouillon Co-Directeur de thèse Koen Claessen Rapporteur Jacques Garrigue Rapporteur Coen De Roover Examinateur Xavier Leroy Examinateur Jeremy Yallop Examinateur This work is licensed under a Creative Commons “Attribution- NonCommercial-ShareAlike 4.0 International” license. Abstract Eliom is a dialect of OCaml for Web programming in which server and client pieces of code can be mixed in the same file using syntactic annotations.
    [Show full text]
  • How Is Video Game Development Different from Software Development in Open Source?
    Delft University of Technology How Is Video Game Development Different from Software Development in Open Source? Pascarella, Luca; Palomba, Fabio; Di Penta, Massimiliano; Bacchelli, Alberto DOI 10.1145/3196398.3196418 Publication date 2018 Document Version Accepted author manuscript Published in Proceedings of the 15th International Conference on Mining Software Repositories, MSR. ACM, New York, NY Citation (APA) Pascarella, L., Palomba, F., Di Penta, M., & Bacchelli, A. (2018). How Is Video Game Development Different from Software Development in Open Source? In Proceedings of the 15th International Conference on Mining Software Repositories, MSR. ACM, New York, NY (pp. 392-402) https://doi.org/10.1145/3196398.3196418 Important note To cite this publication, please use the final published version (if applicable). Please check the document version above. Copyright Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim. This work is downloaded from Delft University of Technology. For technical reasons the number of authors shown on this cover page is limited to a maximum of 10. How Is Video Game Development Different from Software Development in Open Source? Luca Pascarella1,
    [Show full text]
  • Seaflow Language Reference Manual Rohan Arora, Junyang Jin, Ho Sanlok Lee, Sarah Seidman Ra3091, Jj3132, Hl3436, Ss5311
    Seaflow Language Reference Manual Rohan Arora, Junyang Jin, Ho Sanlok Lee, Sarah Seidman ra3091, jj3132, hl3436, ss5311 1 Introduction 3 2 Lexical Conventions 3 2.1 Comments 3 2.2 Identifiers 3 2.3 Keywords 3 2.4 Literals 3 3 Expressions and Statements 3 3.1 Expressions 4 3.1.1 Primary Expressions 4 3.1.1 Operators 4 3.1.2 Conditional expression 4 3.4 Statements 5 3.4.1 Declaration 5 3.4.2 Immutability 5 3.4.3 Observable re-assignment 5 4 Functions Junyang 6 4.1 Declaration 6 4.2 Scope rules 6 4.3 Higher Order Functions 6 5 Observables 7 5.1 Declaration 7 5.2 Subscription 7 5.3 Methods 7 6 Conversions 9 1 Introduction Seaflow is an imperative language designed to address the asynchronous event conundrum by supporting some of the core principles of ReactiveX and reactive programming natively. Modern applications handle many asynchronous events, but it is difficult to model such applications using programming languages such as Java and JavaScript. One popular solution among the developers is to use ReactiveX implementations in their respective languages to architect event-driven reactive models. However, since Java and JavaScript are not designed for reactive programming, it leads to complex implementations where multiple programming styles are mixed-used. Our goals include: 1. All data types are immutable, with the exception being observables, no pointers 2. The creation of an observable should be simple 3. Natively support core principles in the ReactiveX specification 2 Lexical Conventions 2.1 Comments We use the characters /* to introduce a comment, which terminates with the characters */.
    [Show full text]
  • JNI – C++ Integration Made Easy
    JNI – C++ integration made easy Evgeniy Gabrilovich Lev Finkelstein [email protected] [email protected] Abstract The Java Native Interface (JNI) [1] provides interoperation between Java code running on a Java Virtual Machine and code written in other programming languages (e.g., C++ or assembly). The JNI is useful when existing libraries need to be integrated into Java code, or when portions of the code are implemented in other languages for improved performance. The Java Native Interface is extremely flexible, allowing Java methods to invoke native methods and vice versa, as well as allowing native functions to manipulate Java objects. However, this flexibility comes at the expense of extra effort for the native language programmer, who has to explicitly specify how to connect to various Java objects (and later to disconnect from them, to avoid resource leak). We suggest a template-based framework that relieves the C++ programmer from most of this burden. In particular, the proposed technique provides automatic selection of the right functions to access Java objects based on their types, automatic release of previously acquired resources when they are no longer necessary, and overall simpler interface through grouping of auxiliary functions. Introduction The Java Native Interface1 is a powerful framework for seamless integration between Java and other programming languages (called “native languages” in the JNI terminology). A common case of using the JNI is when a system architect wants to benefit from both worlds, implementing communication protocols in Java and computationally expensive algorithmic parts in C++ (the latter are usually compiled into a dynamic library, which is then invoked from the Java code).
    [Show full text]
  • Difference Between Method Declaration and Signature
    Difference Between Method Declaration And Signature Asiatic and relaxed Dillon still terms his tacheometry namely. Is Tom dirt or hierarchal after Zyrian Nelson hasting so variously? Heterozygous Henrique instals terribly. Chapter 15 Functions. How junior you identify a function? There play an important difference between schedule two forms of code block seeing the. Subroutines in C and Java are always expressed as functions methods which may. Only one params keyword is permitted in a method declaration. Complex constant and so, where you declare checked exception parameters which case, it prompts the method declaration group the habit of control passes the positional. Overview of methods method parameters and method return values. A whole object has the cash public attributes and methods. Defining Methods. A constant only be unanimous a type explicitly by doing constant declaration or. As a stop rule using prototypes is the preferred method as it. C endif Class HelloJNI Method sayHello Signature V JNIEXPORT. Method signature It consists of the method name just a parameter list window of. As I breathe in the difference between static and dynamic binding static methods are. Most electronic signature solutions in the United States fall from this broad. DEPRECATED Method declarations with type constraints and per source filter. Methods and Method Declaration in Java dummies. Class Methods Apex Developer Guide Salesforce Developers. Using function signatures to remove a library method Function signatures are known important snapshot of searching for library functions The F libraries. Many different kinds of parameters with rather subtle semantic differences. For addition as real numbers the distinction is somewhat moot because is.
    [Show full text]
  • Data Types Are Values
    Data Types Are Values James Donahue Alan Demers Data Types Are Values James Donahue Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 Alan Demers Computer Science Department Cornell University Ithaca, New York 14853 CSL -83-5 March 1984 [P83-00005] © Copyright 1984 ACM. All rights reserved. Reprinted with permission. A bst ract: An important goal of programming language research is to isolate the fundamental concepts of languages, those basic ideas that allow us to understand the relationship among various language features. This paper examines one of these underlying notions, data type, with particular attention to the treatment of generic or polymorphic procedures and static type-checking. A version of this paper will appear in the ACM Transact~ons on Programming Languages and Systems. CR Categories and Subject Descriptors: 0.3 (Programming Languages), 0.3.1 (Formal Definitions and Theory), 0.3.3 (Language Constructs), F.3.2 (Semantics of Programming Languages) Additional Keywords and Phrases: data types, polymorphism XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 DATA TYPES ARE VALVES 1 1. Introduction An important goal of programming language research is to isolate the fundamental concepts of languages, those basic ideas that allow us to understand the relationship among various language features. This paper examines one of these underlying notions, data type, and presents a meaning for this term that allows us to: describe a simple treatment of generic or polymorphic procedures that preserves full static type-checking and allows unrestricted use of recursion; and give a precise meaning to the phrase strong typing, so that Language X is strongly typed can be interpreted as a critically important theorem about the semantics of the language.
    [Show full text]
  • Learning PHP 5 by David Sklar
    Learning PHP 5 By David Sklar Ripped by: Lilmeanman Dedication To Jacob, who can look forward to so much learning. Preface Boring web sites are static. Interesting web sites are dynamic. That is, their content changes. A giant static HTML page listing the names, pictures, descriptions, and prices of all 1,000 products a company has for sale is hard to use and takes forever to load. A dynamic web product catalog that lets you search and filter those products so you see only the six items that meet your price and category criteria is more useful, faster, and much more likely to close a sale. The PHP programming language makes it easy to build dynamic web sites. Whatever interactive excitement you want to create—such as a product catalog, a blog, a photo album, or an event calendar—PHP is up to the task. And after reading this book, you'll be up to the task of building that dynamic web site, too. Who This Book Is For This book is for: • A hobbyist who wants to create an interactive web site for himself, his family, or a nonprofit organization. • A web site builder who wants to use the PHP setup provided by an ISP or hosting provider. • A small business owner who wants to put her company on the Web. • A page designer who wants to communicate better with her developer co-workers. • A JavaScript whiz who wants to build server-side programs that complement her client-side code. • A blogger or HTML jockey who wants to easily add dynamic features to her site.
    [Show full text]
  • Enea® Linux Open Source Report
    Enea® Linux Open Source Report 4.0 Enea® Linux Open Source Report Enea® Linux Open Source Report Copyright Copyright © Enea Software AB 2014. This User Documentation consists of confidential information and is protected by Trade Secret Law. This notice of copyright does not indicate any actual or intended publication of this information. Except to the extent expressly stipulated in any software license agreement covering this User Documentation and/or corresponding software, no part of this User Documentation may be reproduced, transmitted, stored in a retrieval system, or translated, in any form or by any means, without the prior written permission of Enea Software AB. However, permission to print copies for personal use is hereby granted. Disclaimer The information in this User Documentation is subject to change without notice, and unless stipulated in any software license agreement covering this User Documentation and/or corresponding software, should not be construed as a commitment of Enea Software AB. Trademarks Enea®, Enea OSE®, and Polyhedra® are the registered trademarks of Enea AB and its subsidiaries. Enea OSE®ck, Enea OSE® Epsilon, Enea® Element, Enea® Optima, Enea® Linux, Enea® LINX, Enea® LWRT, Enea® Accelerator, Polyhedra® Flash DBMS, Polyhedra® Lite, Enea® dSPEED, Accelerating Network Convergence™, Device Software Optimized™, and Embedded for Leaders™ are unregistered trademarks of Enea AB or its subsidiaries. Any other company, product or service names mentioned in this document are the registered or unregistered trade- marks of their respective owner. Acknowledgements and Open Source License Conditions Information is found in the Release Information manual. © Enea Software AB 2014 4.0 ii Enea® Linux Open Source Report Table of Contents 1 - About this Report .......................................................................................................
    [Show full text]
  • Vector Graphics Computer Science Masters Dissertation
    Vector Graphics to improve BLAST graphic representations by Rafael Jimenez Computer Science Masters Dissertation School of Computer Science University of KwaZulu-Natal December, 2007 Abstract BLAST reports can be complicated. Viewing them graphically helps to understand them better, especially when the reports are long. At present "Web BLAST" and the stand-alone "wwwBLAST" versions, distributed by the NCBI, include graph- ical viewers for BLAST results. An alternative approach is "BLAST Graphic Viewer" developed by GMOD as part of the BioPerl library. It provides a more aesthetically pleasing and informative graphical visualization to represent BLAST results. All the strategies mentioned above are based on the use of bitmap graph- ics and dependent on JavaScript code embedded in HTML. We present Vector Graphic BLAST (VEGRA) a Python object orientated library based on BioPy- thon to yield graphical visualization of results from BLAST utilizing vector graph- ics. Graphics produced by VEGRA are better than bitmaps for illustration, more flexible because they can be resized and stretched, require less memory, and their interactivity is more effective as it is independent of tertiary technologies due to its integration into the graphic. In addition, the library facilitates a definition of any layout for the different components of the graphic, as well as adjustment of size and colour properties. This dissertation studies previous alternatives and improves them by making use of vector graphics and thus allowing more effective presentation of results. VEGRA is not just an improvement for BLAST visualiza- tion but a model that illustrates how other visualization tools could make use of vector graphics. VEGRA currently works with BLAST, nevertheless the library has been written to be extended to other visualization problems.
    [Show full text]
  • An Updated Maximum Likelihood Approach to Open Cluster Distance Determination M
    Astronomy & Astrophysics manuscript no. OCdistanceDeterminationAstroPh c ESO 2018 October 25, 2018 An updated maximum likelihood approach to open cluster distance determination M. Palmer1, F. Arenou2, X. Luri1, and E. Masana1 1 Dept. d’Astronomia i Meteorologia, Institut de Ciencies` del Cosmos, Universitat de Barcelona (IEEC-UB), Mart´ı Franques` 1, E08028 Barcelona, Spain. 2 GEPI, Observatoire de Paris, CNRS, Universite´ Paris Diderot, 5 place Jules Janssen, 92190, Meudon, France Preprint online version: October 25, 2018 ABSTRACT Aims. An improved method for estimating distances to open clusters is presented and applied to Hipparcos data for the Pleiades and the Hyades. The method is applied in the context of the historic Pleiades distance problem, with a discussion of previous criticisms of Hipparcos parallaxes. This is followed by an outlook for Gaia, where the improved method could be especially useful. Methods. Based on maximum likelihood estimation, the method combines parallax, position, apparent magnitude, colour, proper motion, and radial velocity information to estimate the parameters describing an open cluster precisely and without bias. Results. We find the distance to the Pleiades to be 120:3±1:5 pc, in accordance with previously published work using the same dataset. We find that error correlations cannot be responsible for the still present discrepancy between Hipparcos and photometric methods. Additionally, the three-dimensional space velocity and physical structure of Pleiades is parametrised, where we find strong evidence of mass segregation. The distance to the Hyades is found to be 46:35 ± 0:35 pc, also in accordance with previous results. Through the use of simulations, we confirm that the method is unbiased, so will be useful for accurate open cluster parameter estimation with Gaia at distances up to several thousand parsec.
    [Show full text]
  • Etir Code Lists
    eTIR Code Lists Code lists CL01 Equipment size and type description code (UN/EDIFACT 8155) Code specifying the size and type of equipment. 1 Dime coated tank A tank coated with dime. 2 Epoxy coated tank A tank coated with epoxy. 6 Pressurized tank A tank capable of holding pressurized goods. 7 Refrigerated tank A tank capable of keeping goods refrigerated. 9 Stainless steel tank A tank made of stainless steel. 10 Nonworking reefer container 40 ft A 40 foot refrigerated container that is not actively controlling temperature of the product. 12 Europallet 80 x 120 cm. 13 Scandinavian pallet 100 x 120 cm. 14 Trailer Non self-propelled vehicle designed for the carriage of cargo so that it can be towed by a motor vehicle. 15 Nonworking reefer container 20 ft A 20 foot refrigerated container that is not actively controlling temperature of the product. 16 Exchangeable pallet Standard pallet exchangeable following international convention. 17 Semi-trailer Non self propelled vehicle without front wheels designed for the carriage of cargo and provided with a kingpin. 18 Tank container 20 feet A tank container with a length of 20 feet. 19 Tank container 30 feet A tank container with a length of 30 feet. 20 Tank container 40 feet A tank container with a length of 40 feet. 21 Container IC 20 feet A container owned by InterContainer, a European railway subsidiary, with a length of 20 feet. 22 Container IC 30 feet A container owned by InterContainer, a European railway subsidiary, with a length of 30 feet. 23 Container IC 40 feet A container owned by InterContainer, a European railway subsidiary, with a length of 40 feet.
    [Show full text]