Evolution of Collaboration in Open Source Software Ecosystems
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Alexander Vaos [email protected] - 754.281.9609 - Alexvaos.Com
SENIOR FullStack SOFTWARE ENGINEER Alexander Vaos [email protected] - 754.281.9609 - alexvaos.com PERSONA Portfolio My name is Alexander Vaos and I love changing the world. Resume alexvaos.com/resume I’ve worn nearly ever hat I could put on in the last 18 years. I truly love being a part of something WEBSITE alexvaos.com meaningful. github github.com/kriogenx0 linkedin linkedin.com/pub/alex-vaos I love every part of creating a product: starting from an abstract idea, working through the experience, writing up it’s features, designing it, architecting it, building the front-end and back-end, integrating with stackoverflow stackoverflow.com/users/327934/alex-v other apps, bringing it together, testing, and ending at a physical result that makes a difference in Behance behance.net/kriogenx someone’s life. At an early age, I pursued design and programming, eventually learning some of the other Flickr flickr.com/alexvaos components of a business: marketing, product management, business development, sales. I worked as a part of every company size, from startup to enterprise. I've learned the delicacy of a startup, and how essential ROI can be for the roadmap of any company. I'd like to make an impact and create products people love, use, and can learn things from. I'd like the change the world one step at a time. FULL-TIME POSITIONS 2015-2018 SENIOR FullSTack ENGINEER Medidata Mdsol.com Overseeing 8 codebases, front-end applications and API services. Configured countless new applications from scratch with Rails, Rack, Express (Node), and Roda, using React/Webpack for front-end. -
ROOT Package Management: “Lazy Install” Approach
ROOT package management: “lazy install” approach Oksana Shadura ROOT Monday meeting Outline ● How we can improve artifact management (“lazy-install”) system for ROOT ● How to organise dependency management for ROOT ● Improvements to ROOT CMake build system ● Use cases for installing artifacts in the same ROOT session Goals ● Familiarize ROOT team with our planned work ● Explain key misunderstandings ● Give a technical overview of root-get ● Explain how root-get and cmake can work in synergy Non Goals We are not planning to replace CMake No change to the default build system of ROOT No duplication of functionality We are planning to “fill empty holes” for CMake General overview Manifest - why we need it? ● Easy to write ● Easy to parse, while CMakeLists.txt is impossible to parse ● Collect information from ROOT’s dependencies + from “builtin dependencies” + OS dependencies + external packages to be plugged in ROOT (to be resolved after using DAG) ● It can be easily exported back as a CMakeLists.txt ● It can have extra data elements [not only what is in CMakeLists.txt, but store extra info] ○ Dependencies description (github links, semantic versioning) ■ url: "ssh://[email protected]/Greeter.git", ■ versions: Version(1,0,0)..<Version(2,0,0) Manifest is a “dump” of status of build system (BS), where root-get is just a helper for BS Manifest - Sample Usage scenarios and benefits of manifest files: LLVM/Clang LLVM use CMake as a LLVMBuild utility that organize LLVM in a hierarchy of manifest files of components to be used by build system llvm-build, that is responsible for loading, verifying, and manipulating the project's component data. -
A Package Manager for Curry
A Package Manager for Curry Jonas Oberschweiber Master-Thesis eingereicht im September 2016 Christian-Albrechts-Universität zu Kiel Programmiersprachen und Übersetzerkonstruktion Betreut durch: Prof. Dr. Michael Hanus und M.Sc. Björn Peemöller Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig ver- fasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kiel, Contents 1 Introduction 1 2 The Curry Programming Language 3 2.1 Curry’s Logic Features 3 2.2 Abstract Curry 5 2.3 The Compiler Ecosystem 6 3 Package Management Systems 9 3.1 Semantic Versioning 10 3.2 Dependency Management 12 3.3 Ruby’s Gems and Bundler 16 3.4 JavaScript’s npm 19 3.5 Haskell’s Cabal 21 4 A Package Manager for Curry 25 4.1 The Command Line Interface 26 4.2 What’s in a Package? 29 4.3 Finding Packages 35 4.4 Installing Packages 37 4.5 Resolving Dependencies 38 vi A Package Manager for Curry 4.6 Interacting with the Compiler 43 4.7 Enforcing Semantic Versioning 46 5 Implementation 51 5.1 The Main Module 52 5.2 Packages and Dependencies 56 5.3 Dependency Resolution 58 5.4 Comparing APIs 71 5.5 Comparing Program Behavior 73 6 Evaluation 85 6.1 Comparing Package Versions 85 6.2 A Sample Dependency Resolution 88 6.3 Performance of the Resolution Algorithm 90 6.4 Performance of API and Behavior Comparison 96 7 Summary & Future Work 99 A Total Order on Versions 105 B A Few Curry Packages 109 C Raw Performance Figures 117 D User’s Manual 121 1 Introduction Modern software systems typically rely on many external libraries, reusing func- tionality that can be shared between programs instead of reimplementing it for each new project. -
Debugging at Full Speed
Debugging at Full Speed Chris Seaton Michael L. Van De Vanter Michael Haupt Oracle Labs Oracle Labs Oracle Labs University of Manchester michael.van.de.vanter [email protected] [email protected] @oracle.com ABSTRACT Ruby; D.3.4 [Programming Languages]: Processors| Debugging support for highly optimized execution environ- run-time environments, interpreters ments is notoriously difficult to implement. The Truffle/- Graal platform for implementing dynamic languages offers General Terms an opportunity to resolve the apparent trade-off between Design, Performance, Languages debugging and high performance. Truffle/Graal-implemented languages are expressed as ab- Keywords stract syntax tree (AST) interpreters. They enjoy competi- tive performance through platform support for type special- Truffle, deoptimization, virtual machines ization, partial evaluation, and dynamic optimization/deop- timization. A prototype debugger for Ruby, implemented 1. INTRODUCTION on this platform, demonstrates that basic debugging services Although debugging and code optimization are both es- can be implemented with modest effort and without signifi- sential to software development, their underlying technolo- cant impact on program performance. Prototyped function- gies typically conflict. Deploying them together usually de- ality includes breakpoints, both simple and conditional, at mands compromise in one or more of the following areas: lines and at local variable assignments. The debugger interacts with running programs by insert- • Performance: Static compilers -
Specialising Dynamic Techniques for Implementing the Ruby Programming Language
SPECIALISING DYNAMIC TECHNIQUES FOR IMPLEMENTING THE RUBY PROGRAMMING LANGUAGE A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences 2015 By Chris Seaton School of Computer Science This published copy of the thesis contains a couple of minor typographical corrections from the version deposited in the University of Manchester Library. [email protected] chrisseaton.com/phd 2 Contents List of Listings7 List of Tables9 List of Figures 11 Abstract 15 Declaration 17 Copyright 19 Acknowledgements 21 1 Introduction 23 1.1 Dynamic Programming Languages.................. 23 1.2 Idiomatic Ruby............................ 25 1.3 Research Questions.......................... 27 1.4 Implementation Work......................... 27 1.5 Contributions............................. 28 1.6 Publications.............................. 29 1.7 Thesis Structure............................ 31 2 Characteristics of Dynamic Languages 35 2.1 Ruby.................................. 35 2.2 Ruby on Rails............................. 36 2.3 Case Study: Idiomatic Ruby..................... 37 2.4 Summary............................... 49 3 3 Implementation of Dynamic Languages 51 3.1 Foundational Techniques....................... 51 3.2 Applied Techniques.......................... 59 3.3 Implementations of Ruby....................... 65 3.4 Parallelism and Concurrency..................... 72 3.5 Summary............................... 73 4 Evaluation Methodology 75 4.1 Evaluation Philosophy -
Freertos …What’S New in the Freertos Project
FreeRTOS …What’s new in the FreeRTOS project Richard Barry Founder, FreeRTOS Project Principal Engineer, AWS IoT © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Agenda The FreeRTOS Kernel Amazon FreeRTOS New Ecosystem Projects New Architecture Ports © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. FreeRTOS—Open source real time kernel © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. FreeRTOS downloads per month over 15 years 14,000 12,000 10,000 8,000 6,000 Downloads 4,000 2,000 0 Date © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. gbm java apache (http server) cerebro alks-cli oss-attribution-generator libfabric xen devel cryptography tslint-eslint-rules cynical glib incubator mxnet jruby arrow rollbar linux (kvm) hue rgp netlink gerrit-check web socket sharp cni jgi scapy tabular diaporama packer json11 postcss-extract-animations authenticator fast align tez emscripten lmdbjava gucumber securitymonkey linux-nvme-cli t licensee lombok dovecot smack aalto-xml homebrew nodejs pygresql amphtml flink gpy wing slight.alexa 2018 unicode cldr gpyoptapache phoenix libarchive capybara jcommander tslint appium little proxy typescript-fsa kotlinpoet zipper moby go-git cmock plantuml-syntax esp-open-rtos gradle kuromoji github-plugin cbmc elastalert libsoup eclipse paho mariadb-connector-j kappa irate mysql workbench pyzmq cnn r509-ocsp-responder cocoapods cmis_5 flask-sqlalchemy aws iot devkit tensorboard git git lfs rails fortune server server -
Mdevtalk-Swiftpm.Pdf
29.09.2016 HONZA DVORSKY @czechboy0 honzadvorsky.com Swift • created by Apple • announced in June 2014 • open sourced December 2015 • Swift 3.0 - September 2016 Swift Package Manager SwiftPM Listen carefully if you’re… • an iOS/macOS developer • backend developer • an Android developer • interested in what Apple sees as the future of programming Agenda • introduction to SwiftPM • demo • advanced topics [SwiftPM] is a tool for managing the distribution of Swift code. It’s integrated with the Swift build system to automate the process of downloading, compiling and linking dependencies. — swift.org/package-manager SwiftPM is a • dependency manager • build tool • test tool SwiftPM is • command line based • cross-platform (macOS, Linux) • decentralized • opinionated • convention over configuration Where to learn more about it • swift.org/package-manager • github.com/apple/swift-package-manager • Mailing list: swift-build-dev • Slack: https://swift-package-manager.herokuapp.com Swift Package Manager Swift Package Manager Package • is a folder • Package.swift • source files • contains modules Module • collection of source files (e.g. .swift files) • build instructions (e.g. “build as a library”) • e.g. Foundation, XCTest, Dispatch, … Example Package: Environment • 1 library module • 1 test module “I already use CocoaPods/Carthage, is this just another dependency manager?” — you “I already support CocoaPods, how can I support SwiftPM?” — you CocoaPods -> SwiftPM • https://github.com/neonichu/schoutedenapus • converts CocoaPods Spec to Package.swift -
The Ruby Intermediate Language ∗
The Ruby Intermediate Language ∗ Michael Furr Jong-hoon (David) An Jeffrey S. Foster Michael Hicks University of Maryland, College Park ffurr,davidan,jfoster,[email protected] Abstract syntax that is almost ambiguous, and a semantics that includes Ruby is a popular, dynamic scripting language that aims to “feel a significant amount of special case, implicit behavior. While the natural to programmers” and give users the “freedom to choose” resulting language is arguably easy to use, its complex syntax and among many different ways of doing the same thing. While this ar- semantics make it hard to write tools that work with Ruby source guably makes programming in Ruby easier, it makes it hard to build code. analysis and transformation tools that operate on Ruby source code. In this paper, we describe the Ruby Intermediate Language In this paper, we present the Ruby Intermediate Language (RIL), (RIL), an intermediate language designed to make it easy to ex- a Ruby front-end and intermediate representation that addresses tend, analyze, and transform Ruby source code. As far as we are these challenges. RIL includes an extensible GLR parser for Ruby, aware, RIL is the only Ruby front-end designed with these goals in and an automatic translation into an easy-to-analyze intermediate mind. RIL provides four main advantages for working with Ruby form. This translation eliminates redundant language constructs, code. First, RIL’s parser is completely separated from the Ruby in- unravels the often subtle ordering among side effecting operations, terpreter, and is defined using a Generalized LR (GLR) grammar, and makes implicit interpreter operations explicit. -
Ruby Objective-C Smalltalk-80 Typing
MacRuby (the bloodthirsty) Mario Aquino http://marioaquino.blogspot.com 1 MacRuby vantz ta drink yer blud 2 JRuby MacRuby IronRuby 3 4 Ruby Objective-C Smalltalk-80 Typing dynamic dynamic/static dynamic Runtime access to yes yes yes method names Runtime access to class yes yes yes names Runtime access to yes yes yes instance variable names Forwarding yes yes yes Metaclasses yes yes yes Inheritance mix-in single single Access to super method super super super root class Object Object (can have multiple) Object (can have multiple) Receiver name self self self Private Data yes yes yes Private methods yes no no Class Variables yes no yes Garbage Collection yes yes yes From http://www.approximity.com/ruby/Comparison_rb_st_m_java.html 5 Syntactic Comparison obj.method parameter [obj method:parameter] NSMutableArray *items = items = [] [[NSMutableArray alloc] init]; ‘Heynow’ @”Heynow” 6 Objective-C: Categories #import <objc/Object.h> #import "Integer.h" @interface Integer : Object @implementation Integer { - (int) integer int integer; { } return integer; } - (int) integer; - (id) integer: (int) _integer; - (id) integer: (int) _integer @end { integer = _integer; #import "Integer.h" return self; } @interface Integer (Arithmetic) @end - (id) add: (Integer *) addend; @end #import "Arithmetic.h" @implementation Integer (Arithmetic) - (id) add: (Integer *) addend { return [self integer: [self integer] + [addend integer]]; } 7 Ruby: Open Classes class Integer attr_reader :integer def integer=(_integer) @integer = _integer self end end class Integer -
Eventmachine Что Делать, Если Вы Соскучились По Callback-Ам?
EventMachine Что делать, если вы соскучились по callback-ам? Николай Норкин, 7Pikes Что такое асинхронность? 2 Наша жизнь синхронна и однопоточна 3 Наша жизнь синхронна и однопоточна 3 Асинхронность в вычислительной технике Работа Ожидание 4 Асинхронность в вычислительной технике Работа Ожидание 4 Reactor 5 Reactor Ожидание событий Events Event Loop Callbacks Обработка событий 5 EventMachine 6 Когда нам нужен EventMachine? 7 Когда нам нужен EventMachine? • Работа с сетью (HTTP, TCP, e.t.c) • Работа с ФС • Запросы к БД • любые другие операции, вынуждающие процесс ждать 7 Параллельные запросы 8 Threads threads = [] responses = [] responses_mutex = Mutex.new request_count.times do threads << Thread.new(responses) do |responses| response = RestClient.get URL responses_mutex.synchronize { responses << response } end end threads.each(&:join) 9 Время Threads 25 22,5 20 17,5 15 12,5 10 7,5 5 2,5 0 10 50 100 200 500 1000 10 Память Threads 1 200 1 080 960 840 720 600 480 360 240 120 0 10 50 100 200 500 1000 11 EventMachine responses = [] EventMachine.run do multi = EventMachine::MultiRequest.new request_count.times { |i| multi.add i, EM::HttpRequest.new(URL).get } multi.callback do responses = multi.responses[:callback].values.map(&:response) EventMachine.stop end end 12 Время Threads EventMachine 25 22,5 20 17,5 15 12,5 10 7,5 5 2,5 0 10 50 100 200 500 1000 13 Память Threads EventMachine 1 200 1 080 960 840 720 600 480 360 240 120 0 10 50 100 200 500 1000 14 Быстродействие 15 rack require 'rubygems' require 'rack' class HelloWorld def call(env) -
Practical Partial Evaluation for High-Performance Dynamic Language Runtimes
Practical Partial Evaluation for High-Performance Dynamic Language Runtimes Thomas Wurthinger¨ ∗ Christian Wimmer∗ Christian Humer∗ Andreas Woߨ ∗ Lukas Stadler∗ Chris Seaton∗ Gilles Duboscq∗ Doug Simon∗ Matthias Grimmery ∗ y Oracle Labs Institute for System Software, Johannes Kepler University Linz, Austria fthomas.wuerthinger, christian.wimmer, christian.humer, andreas.woess, lukas.stadler, chris.seaton, gilles.m.duboscq, [email protected] [email protected] Abstract was first implemented for the SELF language [23]: a multi- Most high-performance dynamic language virtual machines tier optimization system with adaptive optimization and de- duplicate language semantics in the interpreter, compiler, optimization. Multiple tiers increase the implementation and and runtime system, violating the principle to not repeat maintenance costs for a VM: In addition to a language- yourself. In contrast, we define languages solely by writ- specific optimizing compiler, a separate first-tier execution ing an interpreter. Compiled code is derived automatically system must be implemented [2, 4, 21]. Even though the using partial evaluation (the first Futamura projection). The complexity of an interpreter or a baseline compiler is lower interpreter performs specializations, e.g., augments the in- than the complexity of an optimizing compiler, implement- terpreted program with type information and profiling infor- ing them is far from trivial [45]. Additionally, they need to mation. Partial evaluation incorporates these specializations. be maintained and ported to new architectures. This makes partial evaluation practical in the context of dy- But more importantly, the semantics of a language need namic languages, because it reduces the size of the compiled to be implemented multiple times in different styles: For code while still compiling in all parts of an operation that are the first-tier interpreter or baseline compiler, language op- relevant for a particular program. -
Extendingruby1.9
Extending Ruby 1.9 Writing Extensions in C Dave Thomas with Chad Fowler Andy Hunt The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com. Copyright © 2010 The Pragmatic Programmers, LLC. 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 consent of the publisher. Printed in the United States of America. ISBN-10: ISBN-13: Printed on acid-free paper. 1.0 printing, November 2010 Version: 2010-11-11 Contents 1 Introduction 5 2 ExtendingRuby 6 2.1 Your First Extension ........................... 6 2.2 Ruby Objects in C ............................ 9 2.3 TheThreadingModel .........................