DOCSLIB.ORG

An Introduction to .NET Core Development on Openshift Introductions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

An introduction to .NET Core development on OpenShift Introductions Andrew Slice Bob Davis Senior Linux .NET Core Developer Senior Product Manager .NET Core PM, among other things [email protected] [email protected] @bobdavis A Hasty Overview What is OpenShift? A container orchestration platform built on Kubernetes. Allows for the collective management of containers. Enables automatic container build and deployment pipelines. Enables container health checks, resource quotas, and load balancing. Openshift clusters can exist locally, in the cloud, and extend across both. What is Dotnet? A cross-platform family of languages (C#, F#, VB) that share a common API. Has automatic memory management with garbage collection. Also allows for manual memory management (including things like function pointers) Can interface with “unmanaged code” (C, C++, assembly, etc.) Programs compile to a ‘common intermediate language’ This bytecode can then be run on a VM (like Java) or recompiled into a native application. Dotnet on Linux? Specifically, .NET Core and ASP.NET Core NOT .NET Framework Available as RPMs on RHEL, Centos, and Fedora. Containers available from the RedHat and Centos registries. Source Code is on Github. Mostly open source, growing more open with every release. Can build for other platforms (i.e. for Windows from Linux and vice versa) lldb and gdb can be used to debug dump files https://github.com/dotnet/coreclr/blob/master/Documentation/building/debugging-instructions.md Is it Mono? Is it Mono? No! Is it Mono? No! It’s a native build from the same source code used for the MS releases. Why .NET Core from Red Hat? ● We build .NET Core from source with our build system ● We test .NET Core on our supported platforms ● Our container images are always updated whenever there’s a CVE in any part of the container contents, as well as when there’s a CVE in .NET Core ● Fully supported on any Red Hat platform hosted on prem or on cloud, physical, virtual or container ● We follow fast behind the upstream: ○ New versions generally within 5 days (rpms and containers) ○ .NET Core CVEs usually available in rpms on same day, with updated containers available in under a week. ● Full support available throughout the lifecycle of the version. When we can’t identify the problem, we escalate to Microsoft for you. Where to get this all? To install .NET Core, you can either start by installing the content in RHEL or by downloading the appropriate container image from the Red Hat Container Catalog. RHEL 7: Containers: 1. Enable the dotnet repository 2. Install : $ su - # yum install rh-dotnet22 RHEL 8: 1. Install from Application Streams 2. sudo yum install dotnet-sdk-2.1 .NET Core Lifecycle Red Hat supports .NET Core on Red Hat platforms on the same schedule as Microsoft - ● LTS Releases: 3 years, or 1 year after the following LTS release ● Current Releases: 3 months after the general availability of a subsequent (Current or LTS) release Currently Supported Versions Version Support Level General Availability End of Life 1.0 Maintenance June 2016 June 27, 2019 1.1 Maintenance November 2016 June 27, 2019 2.1 LTS June 2018 At least three years from LTS declaration (August 21, 2018) 2.2 Current December 2018 3 months after a subsequent Current or LTS release .NET Core Development on Linux VS Code w/C# Plugin Eclipse w/ aCute Plugin Eclipse Che w/ .NET Stack VIM!!! Things to Consider ● Not all libraries are supported (for example, WinForms). This is improving. ● While new releases tend to have little to no delay, beta and preview releases are not synced. ● Some low level functions (usually related to file or shell access) may behave slightly differently between Windows and Linux. ● Microsoft’s .NET Core Debugger (vsdbg) is not open source. ○ There are some community alternatives out there though. Things to Consider ● Not all libraries are supported (for example, WinForms). This is improving. ● While new releases tend to have little to no delay, beta and preview releases are not synced. ● Some low level functions (usually related to file or shell access) may behave slightly differently between Windows and Linux. ● Microsoft’s .NET Core Debugger (vsdbg) is not open source. ○ There are some community alternatives out there though. Some are more helpful than others. .NET Core on Containers Why Containers? Isolation and Repeatability Scalability High Availability Layerability (not just for clothes anymore) Multiple version and platform support - ability Developing on Containers? Not all that different than normal development. Builds can either happen on a dev system or a build server. Builds can be triggered manually or automatically. Development Tip! Mount your local source drive into the build container. Keeps build artifacts and nuget packages on your local machine. Develop in a local IDE, with your own packages, tools, and configs. Repeatedly build/run in the same container. Build/Run environment is not affected by your toolset. [aslice@aslice example]$ podman run --rm -v=`pwd`:/opt/app-root/src -it dotnet/dotnet-21-rhel7 bash bash-4.2$ dotnet watch run watch : Polling file watcher is enabled watch : Started OpenShift Deploy Plugins Red Hat has created plugins to simplify development and deployment to OpenShift from popular IDEs and DevOps Toolchains: - Azure DevOps - VS Code - JetBrains IDEs (e.g. IntelliJ) - CodeReady Workspaces - Eclipse IDE Use It To: Enable simple deployment to OpenShift from IDEs and Toolchains What about OpenShift deployment? Container Development Kit (CDK) Download and run to setup a quick openshift cluster that runs in a VM. Ports automatically mapped for access to the browser interface, or just use the command line. OpenShift cluster is completely self contained. What about OpenShift deployment? Quick Deploy Templates ● Select a template, point it to a git repo, and the containers are created for you. ● Hooks can be used to automatically rebuild and redeploy on every git commit. ● Hooks can also be used to rebuild when the base Dotnet container updates (like for security fixes) ● Custom templates can be created to do things like deploy database containers alongside the build and runtime containers. ● Build on a full SDK container, and deploy on a minimalistic runtime container. What about OpenShift deployment? Quick Deploy Templates What about OpenShift deployment? Quick Deploy Templates What about OpenShift deployment? CodeReady Workspaces What about OpenShift deployment? OpenShift Online What about OpenShift deployment? OpenShift on AWS and Azure Roll out openshift nodes in the cloud. Nodes can form a cluster with local, on-premises nodes as well. Use the previously mentioned templates, or CodeReady Workspaces, with these cloud nodes as well. Or work with local containers and push them into the Openshift registry for deployment. Migrating from Windows Checking for Portability ● Microsoft has a portability checker plugin for visual studio. ○ https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer ● It will attempt to offer recommendations for more platform generic libraries. First Steps Cross platform build targets let you use Linux for development, even if you deploy to Windows servers. It also lets you develop on Windows and deploy on Linux servers/containers. This allows for a slow transition. It also lets you keep a consistent development environment, even when developing for multiple platforms. First Steps First Steps Like MS SQL? It runs on Linux, and we have containers for it. We even have an article about it with a demo. An ASP.NET app container paired with an MS SQL container in a single deployment. Manage it with SQL Operations Studio Using containers on the CDK means no server installation. Database gets in a bad state during development? Throw the container away and deploy a new one. Try the demo https://developers.redhat.com/blog/2018/09/25/sql-server-on-openshift/ First Steps First Steps The Inevitable Question The Inevitable Question The Inevitable Question Yes you can. The Inevitable Question Yes you can. No, I won’t help you. .
Recommended publications
  • Ironpython in Action

    Ironpython in Action

    IronPytho IN ACTION Michael J. Foord Christian Muirhead FOREWORD BY JIM HUGUNIN MANNING IronPython in Action Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> IronPython in Action MICHAEL J. FOORD CHRISTIAN MUIRHEAD MANNING Greenwich (74° w. long.) Download at Boykma.Com Licensed to Deborah Christiansen <[email protected]> For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. Sound View Court 3B fax: (609) 877-8256 Greenwich, CT 06830 email: [email protected] ©2009 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15% recycled and processed without the use of elemental chlorine.
  • Opening Presentation

    Opening Presentation

    Mono Meeting. Miguel de Icaza [email protected] October 24, 2006 Mono, Novell and the Community. Mono would not exist without the community: • Individual contributors. • Companies using Mono. • Organizations using Mono. • Companies using parts of Mono. • Google Summer of Code. Introductions. 2 Goals of the Meeting. A chance to meet. • Most of the Novell/Mono team is here. • Many contributors are here. • Various breaks to talk. Talk to others! • Introduce yourself, ask questions. Talk to us! • Frank Rego, Mono's Product Manager is here. • Tell us what you need in Mono. • Tell us about how you use Mono. 3 Project Status Goals Originally: • Improve our development platform on Linux. As the community grew: • Expand to support Microsoft APIs. As Mono got more complete: • Provide a complete cross platform runtime. • Allow Windows developers to port to Linux. 5 Mono Stacks and Goals. MySMQySQLL//PPosstgtrgesrsess EvEovolluutitioonn# # ASP.NET Novell APIs: MMoozzillala Novell iFolder iFolder, LDAP, Identity ADO.NET ApAapchachee MMonoono DesktoGpTK#: GTK# OpNoevenlOl LfDfAiPce GCneomceil# Windows.Forms JavaJa vCa oCommpaatitbilbitiylity Google APIs Microsoft Compatibility Libraries Mono Libraries Mono Runtime (Implementation of ECMA #335) 6 Platforms, CIL, Code Generation. 7 API space Mono 1.0: July 2004 “T-Bone” Mono 1.2: November 2006 “Rump steak” Mono 1.2 bits. Reliability and C# 2.0, .NET 2.0 scalability: • Complete. • With VM support. • ZenWorks and iFolder • Some 2.0 API support. pushed Mono on the server. • IronPython works. • xsp 1.0: 8 request/second. • xsp 1.2: 250 Debugger: request/second. • x86 and x86-64 debugger. GUI • CLI-only, limited in scenarios (no xsp).
  • Challenges in Debugging Dynamically Compiled Languages As Exemplified by C# Debugger for Tizen

    Challenges in Debugging Dynamically Compiled Languages As Exemplified by C# Debugger for Tizen

    Samsung R&D Institute Russia Center of System Software Challenges in debugging dynamically compiled languages as exemplified by C# debugger for Tizen Dmitri Botcharnikov 1 Agenda Dynamically compiled languages Tizen .NET Debugging Challenges Tizen .NET Debugger internals Future plans 2 Dynamically compiled languages Dynamically (Just-In-Time) compiled languages VM manages low-level details: memory allocation, exception handling But for debuggers… 3 Tizen .NET Visual Studio Tools for Tizen preview were released C# was added to Tizen Over 1,400,000 C# developers worldwide Tizen running on 50 millions Samsung devices (TV, wearables, mobile, IoT) http://developer.tizen.org 4 Technologies Tizen OS (emulator, platform-specific APIs) Xamarin.Forms .NET Core (CoreCLR, CoreFX, Roslyn) Visual Studio 2015 (Windows) 5 C# Compilation & Execution C# source MSIL Output CLR Roslyn JIT Language-specific compiler: C# => MSIL CLR JIT compiler: MSIL => native code 6 Debugging Challenges Source code to native code mapping ◦ C# compiler generates debugging information for source code to MSIL mapping Stepping in and over ◦ Stepping into not yet compiled code ◦ Managed exception handlers ◦ Lambdas, closures & iterators Local variables & arguments inspection ◦ C# compiler generates debugging information for MSIL variables 7 LLDB Subproject of LLVM (http://lldb.llvm.org) Native debugger builds on LLVM and Clang libraries Supports X86 and ARM architectures 8 SOS debugger plug-in Plug-in for LLDB (libsosplugin.so, libsos.so) Port of SOS.dll
  • LLDB Tutorial: Adding Debugger Support for Your Target LLVM 2016 Tutorial

    LLDB Tutorial: Adding Debugger Support for Your Target LLVM 2016 Tutorial

    LLDB Tutorial: Adding debugger support for your target LLVM 2016 tutorial Deepak Panickal Andrzej Warzyński Codeplay Soware @codeplayso March 18, 2016 Outline • LLDB architecture crash course I Overview of LLDB I User scenarios such as breakpoints, stack-walking etc. I Debugging ps • Both generic and specialized architectures are covered I MSP430 lldb debugging, which we have implemented for this tutorial I github.com/codeplaysoftware/lldb-msp430 I ARM architecture is also referred to for the generic cases • Focusing on debugging ELF executables on Linux EuroLLVM 2016 Outline 2 / 54 Overview Part 1: The Basics Part 2: ELF And Architecture Support Part 3: Registers Part 4: Memory and Breakpoints Part 5: Other Key Features Part 6: Debugging Tips Part 7: MSP430 Quick Recap EuroLLVM 2016 Outline 3 / 54 Part 1 The Basics EuroLLVM 2016 Part 1: The Basics 4 / 54 LLDB - Architecture lldb user driver TCP Socket GDB RSP . lldb-server debug API Architecture of LLDB LLDB offers mulple opons: I user drivers: command line, lldb-mi, Python I debug API: ptrace/simulator/runme/actual drivers EuroLLVM 2016 Part 1: The Basics 5 / 54 lldb/lldb-server lldb • Runs on host • Interacts with the user • Understands symbols, DWARF informaon, data formats, etc. • Plugin architecture I ProcessGDBRemote, DynamicLoaderPOSIXDYLD, ABISysV_msp430 are some... lldb-server • Runs on both remote and host, communicates to lldb via RSP over whichever medium is available • Interacts with the hardware/simulator • Deals with binary data and memory addresses • Plugin architecture I ObjectFileELF, ProcessLinux, are some... EuroLLVM 2016 Part 1: The Basics 6 / 54 GDB Remote Serial Protocol • Simple, ASCII message based protocol • Designed for debugging remote targets • Originally developed for gdb<->gdbserver communicaon • Extended for LLDB, see lldb-gdb-remote.txt Packet structure: checksum $.

  • Nateguyver Breakpoints LLDB Debug Toolchain More

    ��������������������������� ��������������������������� �������� ����������������������������������������������������������������������������������� ���������������������������������������������������������������������������������������������� ������������������������������������������������������������������������������������������� ������������������������������� ��������������������������������������������������������������������������������������� ����������������������������������������������������������������������� �������������������������������������������������������������������������������������� �������������������������������������������� ◼ Breakpoints & watchpoints ◼ Xcode's graphical debugger ◼ LLDB �������������� “ ������������������������������������������������������������������������������������ ��������������������������� ”������������������ ���������������������������� ◼ Assertions, Logging, and Debug configuration ◼ Static analysis & runtime memory tools ◼ Unit testing in xcode ���������������� ◼ Emphasis on LLDB as our debugging foundation ◼ Tips and tricks to stramline your the debuggin experience ◼ Use LLDB as an extensible investigative tool “�������������”������������ “��’���������������������������������������������������’���������������������’�������������� ��������’����������������������������������� ”������������������ ��������������������������������������������������� ���������������������������������������������������������������������������������� ����������������������������������������������������������������������������
  • Why and How to Migrate from .NET to .NET Core. - Oliver Ray, Managing Director @ Number8

    Why and How to Migrate from .NET to .NET Core. - Oliver Ray, Managing Director @ Number8

    Why and How to Migrate from .NET to .NET Core. - Oliver Ray, Managing Director @ number8 There’s no time like the present when it comes to paying down technical debt, investing in high-value features, and keeping up with development house-keeping. These practices allow development velocity to skyrocket. And For most companies still utilizing .NET, migrating to .NET Core is the most impactful technical investment they can make right now. This transition will simplify your teams’ development cycles and have a measurable impact on your bottom-line. However, it can also include unforeseen complexities and dependencies, so it’s crucial that the planning and prep work is done throughly. Our team at number8 took the time to detail a few high-level benefits that every team should consider during this transition. So, let’s get started. Why migrate from .NET to .NET Core? .NET Core 1.0 was announced in 2014 and aimed to bring the .NET framework into the open source world. The ultimate goal of this initiative was to make .NET projects more portable to other platforms. With the explosion of commodity platforms like Linux and ARM64 processors, .NET had to become more open to survive. From it’s initial release .NET Core has continued to evolve to leverage a wide range of technologies that allow teams to develop systems in whatever way they see fit. A significant example of this forward thinking was early support for Docker containers and Kubernetes. Teams Start Planning everywhere are trying to rethink core enterprise Now applications to fully see the benefit of cloud tooling.
  • Crossplatform ASP.NET with Mono

    Crossplatform ASP.NET with Mono

    CrossPlatform ASP.NET with Mono Daniel López Ridruejo [email protected] About me Open source: Original author of mod_mono, Comanche, several Linux Howtos and the Teach Yourself Apache 2 book Company: founder of BitRock, multiplatform installers and management software About this presentation The .NET framework An overview of Mono, a multiplatform implementation of the .NET framework mod_mono : run ASP.NET on Linux using Apache and Mono The Microsoft .Net initiative Many things to many people, we are interested in a subset: the .NET framework Common Language Runtime execution environment Comprehensive set of class libraries As other technologies, greatly hyped. But is a solid technical foundation that stands on its own merits The .NET Framework .NET Highlights (1) Common Language Runtime : Provides garbage collection, resource management, threads, JIT support and so on. Somewhat similar to JVM Common Intermediate Language, multiple language support: C#, Java, Visual Basic, C++, JavaScript, Perl, Python, Eiffel, Fortran, Scheme, Pascal Cobol… They can interoperate and have access to full .NET capabilities. Similar to Java bytecode .NET Highlights (2) Comprehensive Class Library: XML, ASP.NET, Windows Forms, Web Services, ADO.NET Microsoft wants .NET to succeed in other platforms: standardization effort at ECMA, Rotor sample implementation. P/Invoke: Easy to incorporate and interoperate with existing code Attributes, delegates, XML everywhere Mono Project Open Source .NET framework implementation. Covers ECMA standard plus
  • Programming with Windows Forms

    Programming with Windows Forms

    A P P E N D I X A ■ ■ ■ Programming with Windows Forms Since the release of the .NET platform (circa 2001), the base class libraries have included a particular API named Windows Forms, represented primarily by the System.Windows.Forms.dll assembly. The Windows Forms toolkit provides the types necessary to build desktop graphical user interfaces (GUIs), create custom controls, manage resources (e.g., string tables and icons), and perform other desktop- centric programming tasks. In addition, a separate API named GDI+ (represented by the System.Drawing.dll assembly) provides additional types that allow programmers to generate 2D graphics, interact with networked printers, and manipulate image data. The Windows Forms (and GDI+) APIs remain alive and well within the .NET 4.0 platform, and they will exist within the base class library for quite some time (arguably forever). However, Microsoft has shipped a brand new GUI toolkit called Windows Presentation Foundation (WPF) since the release of .NET 3.0. As you saw in Chapters 27-31, WPF provides a massive amount of horsepower that you can use to build bleeding-edge user interfaces, and it has become the preferred desktop API for today’s .NET graphical user interfaces. The point of this appendix, however, is to provide a tour of the traditional Windows Forms API. One reason it is helpful to understand the original programming model: you can find many existing Windows Forms applications out there that will need to be maintained for some time to come. Also, many desktop GUIs simply might not require the horsepower offered by WPF.
  • NET Core: from Architecture to Code

    NET Core: from Architecture to Code

    .NET Core: from architecture to code Raffaele Rialdi @raffaeler [email protected] http://iamraf.net Big, big thanks to the Sponsors!!! About myself ... ▪ I started working professionally with software in 1987 ▪ In 2003 I received my first MVP Award (I got my 14th few days ago!) ▪ In a couple of weeks I will attend the MVP Summit in Redmond ▪ I am a Senior Software Architect ▪ Working as both as consultant and driving a a software division in Vevy Europe ▪ I have a lot of fun with exciting projects: ▪ Financial, Racing, Manufacturing, ... ▪ I have been in Romania several times ▪ «Visual Studio 2010 Launch» Keynote in Bucharest ▪ Regular speaker in ITCamp @ Cluj Napoca since 2012 Rationale for re-architecting the .NET Framework ▪ Rebuild the .NET platform to reach new goals ▪ Cross-platform: we live in an etherogeneous world ▪ Remove global dependencies: making xcopy work everywhere ▪ better versioning, side-by-side deployment ▪ Easier load balancing and designing scalable apps ▪ Getting better performance from modern hardware ▪ No compromises ▪ But looking for the lowest possible breaking changes .NET Framework (versions 1.0 to 4.62) ▪ 15 years, 1.8 billion installations VB C++ C# F# … ▪ Multiple codebase/flavors Common Language Specification .NET Framework ▪ Desktop, Silverlight Ado.net Asp.net Winform WPF ... ▪ x86 - Windows Base Class Library (BCL) ▪ Compact Framework ▪ ARM – Windows CE Common Language Runtime (CLR) ▪ Micro Framework ▪ ARM Duplicated BCL Codebase .NET ▪ Non-Microsoft .NET Mono ▪ Mono / Xamarin & ▪ Linux, iOS, MacOS,
  • Ink, Touch, and Windows Presentation Foundation

    Ink, Touch, and Windows Presentation Foundation

    9/2/2015 Ink, Touch, and Windows Presentation Foundation Lecture #4: Ink and WPF Joseph J. LaViola Jr. Fall 2015 Fall 2015 CAP 6105 – Pen-Based User Interfaces ©Joseph J. LaViola Jr. From Last Time Windows Presentation Foundation (WPF) integration of Ink multi-touch 2D Graphics 3D Graphics video and audio uses visual tree model component based XAML and C# code Important control – InkCanvas Fall 2015 CAP 6105 – Pen-Based User Interfaces ©Joseph J. LaViola Jr. 1 9/2/2015 Ink Environment Choices Microsoft traditional dev stream: Visual Studio, C#, WPF or (Mono+Xamarin) Pros: Mature platform with many online resources Cons: Can be deployed only on Windows ecosystem Using Mono+Xamarin can be deployed cross-platform Microsoft new dev stream: Visual Studio, JavaScript(or Typescript),HTML Pros: Can be deployed cross-platform(windows, android or IOS) Cons: Relatively new computing environment with new API Other alternatives, such as Python/Kivy, IOS, Android. Pros: Open-source with many online collaboration. Cons: Have little support on inking Fall 2015 CAP 6105 – Pen-Based User Interfaces ©Joseph J. LaViola Jr. Traditional Ink and Touch Ink SDK Before Windows 8.1: The inking API is System.Windows.Ink Online Sample code: Adventures into Ink API using WPF After Windows 8.1: The inking API is Windows.UI.Input.Inking Online Sample code: Input:Simplied ink sample You can find more articles or sample code resources from Microsoft Windows Dev Center or Code project Fall 2015 CAP 6105 – Pen-Based User Interfaces ©Joseph J. LaViola Jr. 2 9/2/2015 Important Ink Components InkCanvas – System.Windows.Controls receives and displays ink strokes starting point for ink applications stores ink in Strokes System.Windows.Ink Namespace contains classes to interact with and manipulate ink examples Stroke GestureRecognizer InkAnalyzer now separate (only on 32 bit) needs IACore.dll, IAWinFX.dll and IALoader.dll Fall 2015 CAP 6105 – Pen-Based User Interfaces ©Joseph J.
  • Improving Program Reconstruction in LLDB Using C++ Modules

    Improving Program Reconstruction in LLDB Using C++ Modules

    Beyond Debug Information: Improving Program Reconstruction in LLDB using C++ Modules Master’s Thesis in Computer Science and Engineering RAPHAEL ISEMANN Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2019 Master’s thesis 2019 Beyond Debug Information: Improving Program Reconstruction in LLDB using C++ Modules Raphael Isemann Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2019 Beyond Debug Information: Improving Program Reconstruction in LLDB using C++ Modules Raphael Isemann © Raphael Isemann, 2019. Supervisor: Thomas Sewell, Department of Computer Science and Engineering Examiner: Magnus Myreen, Department of Computer Science and Engineering Master’s Thesis 2019 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: The LLVM logo, owned by and royality-free licensed from Apple Inc. Typeset in LATEX Gothenburg, Sweden 2019 iv Beyond Debug Information: Improving Program Reconstruction in LLDB using C++ Modules Raphael Isemann Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Abstract Expression evaluation is a core feature of every modern C++ debugger. Still, no C++ debugger currently features an expression evaluator that consistently supports advanced language features such as meta-programming with templates. The under- lying problem is that the debugger can often only partially reconstruct the debugged program from the debug information. This thesis presents a solution to this problem by using C++ modules as an additional source of program information. We devel- oped a prototype based on the LLDB debugger that is loading missing program components from the C++ modules used by the program.
  • Swift for Beginners: Develop and Design, Second Edition Boisy G

    Swift for Beginners: Develop and Design, Second Edition Boisy G

    Swift for Beginners DEVELOP AND DESIGN SECOND EDITION Boisy G. Pitre Swift for Beginners SECOND EDITION DEVELOP AND DESIGN Boisy G. Pitre PEACHPIT PRESS WWW.PEACHPIT.COM Swift for Beginners: Develop and Design, Second Edition Boisy G. Pitre Peachpit Press www.peachpit.com To report errors, please send a note to [email protected]. Peachpit Press is a division of Pearson Education. Copyright © 2016 by Boisy G. Pitre Editor: Connie Jeung-Mills Production editor: David Van Ness Development editor: Robyn G. Thomas Copyeditor and proofreader: Scout Festa Technical editor: Steve Phillips Compositor: Danielle Foster Indexer: Valerie Haynes Perry Cover design: Aren Straiger Interior design: Mimi Heft Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechani- cal, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting permission for reprints and excerpts, contact [email protected]. Notice of Liability The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of the book, neither the author nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it. Trademarks Apple, Cocoa, Cocoa Touch, Objective-C, OS X, Swift, and Xcode are registered trademarks of Apple Inc., registered in the U.S. and other countries. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks.