DOCSLIB.ORG

Automated Fortran–C++ Bindings for Large-Scale Scientific Applications

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Automated Fortran–C++ Bindings for Large-Scale Scientific Applications Automated Fortran–C++ Bindings for Large-Scale Scientific Applications Seth R Johnson HPC Methods for Nuclear Applications Group Nuclear Energy and Fuel Cycle Division Oak Ridge National Laboratory ORNL is managed by UT–Battelle, LLC for the US Department of Energy github.com/swig-fortran Overview • Introduction • Tools • SWIG+Fortran • Strategies • Example libraries 2 Introduction 3 How did I get involved? • SCALE (1969–present): Fortran/C++ • VERA: multiphysics, C++/Fortran • MPACT: hand-wrapped calls to C++ Trilinos 4 Project background • Exascale Computing Project: at inception, many scientific app codes were primarily Fortran • Numerical/scientific libraries are primarily C/C++ • Expose Trilinos solver library to Fortran app developers: ForTrilinos product 5 ECP: more exascale, less Fortran Higher-level { }Fortran ECP application codes over time (credit: Tom Evans) 6 Motivation • C++ library developers: expand user base, more F opportunities for development and follow-on funding • Fortran scientific app developers: use newly exposed algorithms and tools for your code C • Multiphysics project integration: in-memory coupling of C++ physics code to Fortran physics code • Transitioning application teams: bite-size migration from Fortran to C++ C++ 7 Tools 8 Wrapper “report card” • Portability: Does it use standardized interoperability? • Reusability: How much manual duplication needed for new interfaces? • Capability: Does the Fortran interface have parity with the C++? • Maintainability: Do changes to the C++ code automatically update the Fortran interface? • Robustness: Is it possible for silent failures to creep in? • Integration: How much overhead is needed to get the glue code working in development/deployment? 9 Hand-rolled binding code Portability � • Often based on hand-rolled C interface layer Reusablity � • Often targets F77/90 using configure-time bindings Capability � Maintainability � • Examples: SuperLU, STRUMPACK, TASMANIAN Robustness � Integration �/� 10 Project-specific scripts • Text processing engines hardcoded to a Portability � particular project’s data types, header Reusablity � formatting Capability � • Simple translations of function signatures Maintainability and types to “glue code” � Robustness � • Examples: MPICH, HDF5, Silo, PETSc Integration �/� 11 Automated code generators (manual C++ declaration) Portability � • CIX: in-house ORNL tool Reusablity � (template substitution) Capability � • Shroud: recent LLNL development Maintainability � (custom YAML) Robustness � Integration �/� 12 Automated code generators (integrated C++ parsing) Portability � Reusablity � Capability � • SWIG+Fortran: fork of Simplified Wrapper Interface Generator Maintainability � Robustness � Integration � 13 SWIG+Fortran 14 Supported SWIG: Simplified Wrapper and Interface Generator Languages • Allegro CL • C# • CFFI • CLISP • • Chicken Generate interfaces to existing C and C++ code and data • D types so that a target language can invoke functions and use • Go • Guile the data • Java • Javascript • “Glue” code: flat C-linkage wrappers to C++ functions, • Lua • Modula-3 corresponding interfaces in target language • Mzscheme • OCAML • Does not couple target languages to other target languages • Octave • Perl • Does not parse target languages or create C++ proxy • PHP • Python wrappers • R • Ruby • Scilab • Tcl • UFFI 15 SWIG execution sequence • SWIG reads .i interface file which may %include other C/C++ headers to parse them • Interface file can be as little as a couple of lines for simple interfaces • More difficult C++/Fortran conversions require more interface code • SWIG generates source code files: .cxx and .f90 • This wrapper code can be distributed like regular source files • Library users don’t need to know SWIG User-written code SWIG-generated code Foo.cxx Foo.hh SWIG foo.f90 main.f90 Foo.i foo_wrap.cxx 16 Control flow and data conversion Call “native” procedure user.f90 Public module procedure Convert Fortran types to ISO_C_BINDING types module.f90 Call BIND(C) interface • Fortran 2003 standard defines C-compatible datatypes • Use only Fortran-compatible ISO C datatypes extern "C" wrapper function Convert C type to C++ type • Minimize data movement of numerical arrays Call C++ library function module_wrap.cxx C++ Library code library.cxx 17 Features • Primitive types • Function overloading • Enumerations • Template instantiation • Classes (with inheritance) • Compile-time constants • C strings and std::string • Exception handling • Function pointers • OpenACC and Thrust • Arrays and std::vector 18 Addition with “native” int: input and generated C code F/C interface #ifndef simplest_h SWIGEXPORT int _wrap_add( #define simplest_h int const *farg1, int add(int a, int b); #endif int const *farg2) { int fresult ; Input argument int arg1 ; conversion simplest.h int arg2 ; int result; arg1 = (int)(*farg1); arg2 = (int)(*farg2); %module simplest Wrapped result = (int)add(arg1,arg2); function call %typemap(ftype, in="integer, intent(in)") fresult = (int)(result); int "integer" return fresult; %typemap(fin) int "$1 = int($input, C_INT)" %typemap(fout) int "$result = int($1)" } %include "simplest.h" simplest.i Output simplest_wrap.c argument conversion 19 Addition with “native” int: generated Fortran Fortran proxy function module simplest .... use, intrinsic :: ISO_C_BINDING F/C implicit none interface function add(a, b) & private result(swig_result) public :: add integer :: swig_result interface integer, intent(in) :: a function swigc_add(farg1, farg2) & integer, intent(in) :: b bind(C, name="_wrap_add") & integer(C_INT) :: fresult Input result(fresult) integer(C_INT) :: farg1 argument integer(C_INT), intent(in) :: farg1 integer(C_INT) :: farg2 integer(C_INT), intent(in) :: farg2 conversion integer(C_INT) :: fresult farg1 = int(a, C_INT) Wrapper end function farg2 = int(b, C_INT) function call end interface fresult = swigc_add(farg1, farg2) contains Output swig_result = int(fresult) argument end function .... conversion end module simplest.f90 20 Simple addition function: the part app devs care about SWIGEXPORT int swigc_add(int const *farg1, program main int const *farg2); use simplest, only : add write (0,*) add(10, 20) end program simplest_wrap.c module simplest use, intrinsic :: ISO_C_BINDING main.f90 … contains function add(a, b) & result(swig_result) integer :: swig_result integer, intent(in) :: a integer, intent(in) :: b … end function $ ./main.exe end module simplest.f90 30 21 Automatic BIND(C) wrapping %module bindc module bindc Only generate … interface code type, bind(C), public :: Point %fortranbindc; real(C_FLOAT), public :: x %fortran_struct(Point) real(C_FLOAT), public :: y Don’t create real(C_FLOAT), public :: z proxy class end type Point %inline { … interface typedef struct { float x, y, z; } Point; subroutine print_point(p) & void print_point(const Point* p); bind(C, name="print_point") void make_point(Point* pt, use, intrinsic :: ISO_C_BINDING import :: point const float xyz[3]); type(Point), intent(in) :: p } end subroutine subroutine make_point(pt, xyz) & bind(C, name="make_point") use, intrinsic :: ISO_C_BINDING import :: point type(Point) :: pt real(C_FLOAT), dimension(3), intent(in) :: xyz end subroutine end interface bindc.i end module bindc.f90 22 Templated class template<typename T> Insert raw C++ %module "templated" Tell SWIG to class Thing { code into parse the T val_; generated %{ header file public: wrapper file #include "templated.hpp" Thing(T val); %} T get() const; %include "templated.hpp" }; // Instantiate templated classes template<typename T> %template(Thing_Int) Thing<int>; void print_thing(const Thing<T>& t); %template(Thing_Dbl) Thing<double>; // Instantiate and overload a function Instantiate %template(print_thing) print_thing<int>; templates %template(print_thing) print_thing<double>; at SWIG time templated.i 23 Templated class: generated Fortran wrapper code Memory module templated ownership interface print_thing … module procedure swigf_print_thing__SWIG_1, integer, parameter, public :: swig_cmem_own_bit = 0 swigf_print_thing__SWIG_2 integer, parameter, public :: swig_cmem_rvalue_bit = 1 end interface public :: print_thing type, bind(C) :: SwigClassWrapper interface Overloaded type(C_PTR), public :: cptr = C_NULL_PTR subroutine swigc_delete_Thing_Int(farg1) & integer(C_INT), public :: cmemflags = 0 bind(C, name="_wrap_delete_Thing_Int") function end type Opaque class … ! class Thing< int > contains type, public :: Thing_Int wrapper subroutine swigf_release_Thing_Int(self) type(SwigClassWrapper), public :: swigdata Call delete if use, intrinsic :: ISO_C_BINDING contains we “own” procedure :: get => swigf_Thing_Int_get class(Thing_Int), intent(inout) :: self procedure :: release => swigf_release_Thing_Int type(SwigClassWrapper) :: farg1 the memory procedure, private :: swigf_Thing_Int_op_assign__ farg1 = self%swigdata generic :: assignment(=) => swigf_Thing_Int_op_assign__ if (btest(farg1%cmemflags, swig_cmem_own_bit)) then end type Thing_Int call swigc_delete_Thing_Int(farg1) interface Thing_Int endif module procedure swigf_create_Thing_Int Fortran farg1%cptr = C_NULL_PTR end interface farg1%cmemflags = 0 ! class Thing< double > proxy class self%swigdata = farg1 type, public :: Thing_Dbl Second end subroutine … template … end type Thing_Dbl instantiation end module … templated.f90 (2/2) 24 Exception handling %module except program main %include <std_except.i> use except, only : do_it, do_it_again, ierr, get_serr %exception { call do_it(-3) SWIG_check_unhandled_exception();
Load more

Recommended publications
  • Scala−−, a Type Inferred Language Project Report
    Scala−−, a type inferred language Project Report Da Liu [email protected] Contents 1 Background 2 2 Introduction 2 3 Type Inference 2 4 Language Prototype Features 3 5 Project Design 4 6 Implementation 4 6.1 Benchmarkingresults . 4 7 Discussion 9 7.1 About scalac ....................... 9 8 Lessons learned 10 9 Language Specifications 10 9.1 Introdution ......................... 10 9.2 Lexicalsyntax........................ 10 9.2.1 Identifiers ...................... 10 9.2.2 Keywords ...................... 10 9.2.3 Literals ....................... 11 9.2.4 Punctions ...................... 12 9.2.5 Commentsandwhitespace. 12 9.2.6 Operations ..................... 12 9.3 Syntax............................ 12 9.3.1 Programstructure . 12 9.3.2 Expressions ..................... 14 9.3.3 Statements ..................... 14 9.3.4 Blocksandcontrolflow . 14 9.4 Scopingrules ........................ 16 9.5 Standardlibraryandcollections. 16 9.5.1 println,mapandfilter . 16 9.5.2 Array ........................ 16 9.5.3 List ......................... 17 9.6 Codeexample........................ 17 9.6.1 HelloWorld..................... 17 9.6.2 QuickSort...................... 17 1 of 34 10 Reference 18 10.1Typeinference ....................... 18 10.2 Scalaprogramminglanguage . 18 10.3 Scala programming language development . 18 10.4 CompileScalatoLLVM . 18 10.5Benchmarking. .. .. .. .. .. .. .. .. .. .. 18 11 Source code listing 19 1 Background Scala is becoming drawing attentions in daily production among var- ious industries. Being as a general purpose programming language, it is influenced by many ancestors including, Erlang, Haskell, Java, Lisp, OCaml, Scheme, and Smalltalk. Scala has many attractive features, such as cross-platform taking advantage of JVM; as well as with higher level abstraction agnostic to the developer providing immutability with persistent data structures, pattern matching, type inference, higher or- der functions, lazy evaluation and many other functional programming features.
    [Show full text]
  • The Scala Experience Safe Programming Can Be Fun!
    The Scala Programming Language Mooly Sagiv Slides taken from Martin Odersky (EPFL) Donna Malayeri (CMU) Hila Peleg (Technion) Modern Functional Programming • Higher order • Modules • Pattern matching • Statically typed with type inference • Two viable alternatives • Haskel • Pure lazy evaluation and higher order programming leads to Concise programming • Support for domain specific languages • I/O Monads • Type classes • ML/Ocaml/F# • Eager call by value evaluation • Encapsulated side-effects via references • [Object orientation] Then Why aren’t FP adapted? • Education • Lack of OO support • Subtyping increases the complexity of type inference • Programmers seeks control on the exact implementation • Imperative programming is natural in certain situations Why Scala? (Coming from OCaml) • Runs on the JVM/.NET • Can use any Java code in Scala • Combines functional and imperative programming in a smooth way • Effective libraries • Inheritance • General modularity mechanisms The Java Programming Language • Designed by Sun 1991-95 • Statically typed and type safe • Clean and Powerful libraries • Clean references and arrays • Object Oriented with single inheritance • Interfaces with multiple inheritance • Portable with JVM • Effective JIT compilers • Support for concurrency • Useful for Internet Java Critique • Downcasting reduces the effectiveness of static type checking • Many of the interesting errors caught at runtime • Still better than C, C++ • Huge code blowouts • Hard to define domain specific knowledge • A lot of boilerplate code •
    [Show full text]
  • A Trusted Mechanised Javascript Specification
    A Trusted Mechanised JavaScript Specification Martin Bodin Arthur Charguéraud Daniele Filaretti Inria & ENS Lyon Inria & LRI, Université Paris Sud, CNRS Imperial College London [email protected] [email protected] d.fi[email protected] Philippa Gardner Sergio Maffeis Daiva Naudžiunien¯ e˙ Imperial College London Imperial College London Imperial College London [email protected] sergio.maff[email protected] [email protected] Alan Schmitt Gareth Smith Inria Imperial College London [email protected] [email protected] Abstract sation was crucial. Client code that works on some of the main JavaScript is the most widely used web language for client-side ap- browsers, and not others, is not useful. The first official standard plications. Whilst the development of JavaScript was initially just appeared in 1997. Now we have ECMAScript 3 (ES3, 1999) and led by implementation, there is now increasing momentum behind ECMAScript 5 (ES5, 2009), supported by all browsers. There is the ECMA standardisation process. The time is ripe for a formal, increasing momentum behind the ECMA standardisation process, mechanised specification of JavaScript, to clarify ambiguities in the with plans for ES6 and 7 well under way. ECMA standards, to serve as a trusted reference for high-level lan- JavaScript is the only language supported natively by all major guage compilation and JavaScript implementations, and to provide web browsers. Programs written for the browser are either writ- a platform for high-assurance proofs of language properties. ten directly in JavaScript, or in other languages which compile to We present JSCert, a formalisation of the current ECMA stan- JavaScript.
    [Show full text]
  • 1 Ocaml for the Masses
    PROGRAMMING LANGUAGES OCaml for the Masses Why the next language you learn should be functional Yaron Minsky, Jane Street Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function. - John Carmack Functional programming is an old idea with a distinguished history. Lisp, a functional language inspired by Alonzo Church’s lambda calculus, was one of the first programming languages developed at the dawn of the computing age. Statically typed functional languages such as OCaml and Haskell are newer, but their roots go deep—ML, from which they descend, dates back to work by Robin Milner in the early ’70s relating to the pioneering LCF (Logic for Computable Functions) theorem prover. Functional programming has also been enormously influential. Many fundamental advances in programming language design, from garbage collection to generics to type inference, came out of the functional world and were commonplace there decades before they made it to other languages. Yet functional languages never really made it to the mainstream. They came closest, perhaps, in the days of Symbolics and the Lisp machines, but those days seem quite remote now. Despite a resurgence of functional programming in the past few years, it remains a technology more talked about than used. It is tempting to conclude from this record that functional languages don’t have what it takes. They may make sense for certain limited applications, and contain useful concepts to be imported into other languages; but imperative and object-oriented languages are simply better suited to the vast majority of software engineering tasks.
    [Show full text]
  • BCL: a Cross-Platform Distributed Data Structures Library
    BCL: A Cross-Platform Distributed Data Structures Library Benjamin Brock, Aydın Buluç, Katherine Yelick University of California, Berkeley Lawrence Berkeley National Laboratory {brock,abuluc,yelick}@cs.berkeley.edu ABSTRACT high-performance computing, including several using the Parti- One-sided communication is a useful paradigm for irregular paral- tioned Global Address Space (PGAS) model: Titanium, UPC, Coarray lel applications, but most one-sided programming environments, Fortran, X10, and Chapel [9, 11, 12, 25, 29, 30]. These languages are including MPI’s one-sided interface and PGAS programming lan- especially well-suited to problems that require asynchronous one- guages, lack application-level libraries to support these applica- sided communication, or communication that takes place without tions. We present the Berkeley Container Library, a set of generic, a matching receive operation or outside of a global collective. How- cross-platform, high-performance data structures for irregular ap- ever, PGAS languages lack the kind of high level libraries that exist plications, including queues, hash tables, Bloom filters and more. in other popular programming environments. For example, high- BCL is written in C++ using an internal DSL called the BCL Core performance scientific simulations written in MPI can leverage a that provides one-sided communication primitives such as remote broad set of numerical libraries for dense or sparse matrices, or get and remote put operations. The BCL Core has backends for for structured, unstructured, or adaptive meshes. PGAS languages MPI, OpenSHMEM, GASNet-EX, and UPC++, allowing BCL data can sometimes use those numerical libraries, but are missing the structures to be used natively in programs written using any of data structures that are important in some of the most irregular these programming environments.
    [Show full text]
  • An Overview of the Scala Programming Language
    An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips.
    [Show full text]
  • How to Run Your Favorite Language on Web Browsers
    Benjamin Canou, Emmanuel Chailloux and Jérôme Vouillon Laboratoire d'Informatique de Paris 6 (LIP6) Laboratoire Preuves Programmes et Systèmes (PPS) How to Run your Favorite. Language on Browsers The Revenge of Virtual Machines WWW 2012, Lyon, France Introduction. Introduction . 3/20 What ? I You have a favorite language I You have just designed or extended one I You want to run it on a Web browser Why ? I To program a new Web app I To program your client with the same language than your server I To run an online demo of an existing app Introduction . 4/20 How ? I Use applets I Write an interpreter in JavaScript I Write a compiler to JavaScript Or as we present in this talk: I Reuse the language bytecode compiler I Write a bytecode interpreter in JavaScript I Write a bytecode to JavaScript expander Introduction . 5/20 An experiment report: I Project Ocsigen: use OCaml to code entire Web apps I OBrowser: an OCaml bytecode interpreter I js_of_ocaml: an OCaml bytecode expander Retrospectively, a good approach: I Reasonable time to obtain a first platform I Good performance achievable I Fidelity to language/concurrency models Core techniques. Bytecode interpretation (1/3). 7/20 Main method: 1. Make the bytecode file network compliant (ex. JSON array) 2. Choose/implement the representation of values 3. Write a minimal runtime and standard library 4. Write the main interpretation loop 5. Run tests and extend the library as needed Possible improvements: I Use core, well supported/optimized JavaScript control structures I Use simple, array based memory representation I Preliminary bytecode cleanup pass Bytecode interpretation (2/3).
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Metal C Programming Guide and Reference
    z/OS Version 2 Release 3 Metal C Programming Guide and Reference IBM SC14-7313-30 Note Before using this information and the product it supports, read the information in “Notices” on page 159. This edition applies to Version 2 Release 3 of z/OS (5650-ZOS) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2019-02-15 © Copyright International Business Machines Corporation 1998, 2017. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Figures...................................................................................................... vii List of Tables........................................................................................................ ix About this document.............................................................................................xi Who should read this document................................................................................................................. xi Where to find more information..................................................................................................................xi z/OS Basic Skills in IBM Knowledge Center.......................................................................................... xi How to read syntax diagrams......................................................................................................................xi How to send your comments to IBM......................................................................xv
    [Show full text]
  • Programming in Java
    Introduction to Programming in Java An Interdisciplinary Approach Robert Sedgewick and Kevin Wayne Princeton University ONLINE PREVIEW !"#$%&'(')!"*+,,,- ./01/23,,,0425,67 Publisher Greg Tobin Executive Editor Michael Hirsch Associate Editor Lindsey Triebel Associate Managing Editor Jeffrey Holcomb Senior Designer Joyce Cosentino Wells Digital Assets Manager Marianne Groth Senior Media Producer Bethany Tidd Senior Marketing Manager Michelle Brown Marketing Assistant Sarah Milmore Senior Author Support/ Technology Specialist Joe Vetere Senior Manufacturing Buyer Carol Melville Copyeditor Genevieve d’Entremont Composition and Illustrations Robert Sedgewick and Kevin Wayne Cover Image: © Robert Sedgewick and Kevin Wayne Page 353 © 2006 C. Herscovici, Brussels / Artists Rights Society (ARS), New York Banque d’ Images, ADAGP / Art Resource, NY Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trade- marks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial caps or all caps. The interior of this book was composed in Adobe InDesign. Library of Congress Cataloging-in-Publication Data Sedgewick, Robert, 1946- Introduction to programming in Java : an interdisciplinary approach / by Robert Sedgewick and Kevin Wayne. p. cm. Includes index. ISBN 978-0-321-49805-2 (alk. paper) 1. Java (Computer program language) 2. Computer programming. I. Wayne, Kevin Daniel, 1971- II. Title. QA76.73.J38S413 2007 005.13’3--dc22 2007020235 Copyright © 2008 Pearson Education, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.
    [Show full text]
  • Draft ANSI Smalltalk Standard
    NCITS J20 DRAFT December, 1997 of ANSI Smalltalk Standard revision 1.9 Draft American National Standard for Information Systems - Programming Languages - Smalltalk Notice This is a draft proposed American National Standard. As such, this is not a completed standard. The Technical Committee may modify this document as a result of comments received during public review and its approval as a standard. Permission is granted to members of NCITS, its technical committees, and their associated task groups to reproduce this document for the purposes of NCITS standardization activities without further permission, provided this notice is included. All other rights are reserved. Any commercial or for-profit reproduction is strictly prohibited. NCITS J20 DRAFT December, 1997 ii of ANSI Smalltalk Standard revision 1.9 Copyright Copyright 1997 National Committee for Information Technology Standards Permission is granted to duplicate this document for the purpose of reviewing the draft standard. NCITS J20 DRAFT December, 1997 iii of ANSI Smalltalk Standard revision 1.9 Table of Contents Page FORWARD vi 1. GOALS AND SCOPE .................................................................................................................... 5 2. CONFORMING IMPLEMENTATIONS AND PROGRAMS .................................................. 7 3. THE SMALLTALK LANGUAGE ............................................................................................... 8 3.1 COMPUTATIONAL MODEL OF SMALLTALK EXECUTION................................................................
    [Show full text]
  • Installation and Configuration of Ocaml for Windows 10
    Installation and Configuration of OCaml for Windows 10 By: Brandon Kim, Jonathan Morley, Francis Oyebanjo, and BT Rappaport Table of Contents Introduction 2 Installing OPAM and OCaml 3 Checkpoint 7 Installing Extra Packages (OCamlfind, OUnit, rlwrap) 8 Ensuring Correct Installation and Configuration 11 Troubleshooting Errors 12 Glossary 16 1 Introduction This manual is for OCaml beginners who would like to use OCaml on a Windows 10 computer. OCaml is not very compatible for installation on a Windows computer but is made simple with Bash on Ubuntu on Windows, a brand new Windows 10 feature that enables direct use of Linux command-line tools. However, the directions available are usually not Windows 10 specific and assume the audience is already well versed in Linux tools. This manual provides beginners to OCaml and Linux with a clear and orderly set of instructions for installing and configuring OCaml on Windows 10. OCaml is a heavy-duty programming language that supports functional, imperative and object- oriented styles. OCaml’s safety, advanced type system, and automatic memory management are a few features that make it a highly effective programming tool. Even though OCaml is a powerful language, it is also simple and easy to use, making it an ideal language to expose to students in undergraduate computer science courses. In this manual we will install OCaml via OPAM, a package manager (collection of tools that automates the process of installing, upgrading, configuring, and removing programs from a computer) for OCaml. Requirements/ Materials ● Computer running Windows 10 (64-bit) with build 14393 or later ● Administrative access of the computer ● Bash on Ubuntu on Windows installed and setup ○ https://msdn.microsoft.com/en-us/commandline/wsl/install_guide ● Internet access with decent download speed Important Notes ● Copy and paste (to paste simply right click in bash where you want to paste) the commands from the manual into Bash, especially if they are long.
    [Show full text]