DOCSLIB.ORG

Method, 224 Vs. Typing Module Types

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Method, 224 Vs. Typing Module Types Index A migration metadata, 266 running migrations, 268, 269 Abstract base classes, 223 setting up a new project, 264 @abc.abstractmethod decorator, 224 using constants in migrations, 267 __subclasshook__(...) method, 224 __anext__() method, 330 vs. typing module types, 477 apd.aggregation package, 397, 516, 524 virtual subclasses, 223 clean functions (see clean functions) Actions, 560 database, 254 analysis process, 571, 572 get_data_by_deployment(...) config file, 573, 575 function, 413, 416 DataProcessor class, 561 get_data(...) function, 415 extending, 581 plot_sensor(...) function, 458 IFTTT service, 566 plotting data, 429 ingesting data, 567, 571 plotting functions, 421 logs, 567 query functions, 417 trigger, 563, 564 apd.sensors package, 106 Adafruit, 42, 486 APDSensorsError, 500 Adapter pattern, 229 DataCollectionError, 500 __aenter__() method, 331, 365 directory structure, 108 __aexit__(...) method, 331, 365 extending, 149 Aggregation process, 533 IntermittentSensorFailureError, 500 aiohttp library, 336 making releases, 141 __aiter__() method, 330 sensors script, 32, 36, 130, 147, 148, Alembic, 264 153, 155, 156, 535 ambiguous changes, 268 UserFacingCLIError, 502 creating a new revision, 265 apd.sunnyboy_solar package, 148, current version, 269 155, 173 downgrading, 268, 270 API design, 190 irreversible, migrations, 270 authentication, 190 listing migrations, 269 versioning, 240, 241, 243 merging, migrations, 269 589 © Matthew Wilkes 2020 M. Wilkes, Advanced Python Development, https://doi.org/10.1007/978-1-4842-5793-7 INDEX AssertionError, 71, 498 Event class, 333 Assert statement, 498 gather(...) function, 326, 330 Async code get_running_loop( ), 373 pytest plugin, 346 Lock class, 333 setup.cfg, 346 loop.add_signal_handler(...) method, Asynchronous databases 578 (see also Signal module) complex queries (see Complex loop.call_later(...) method, 578 queries, ORM) ython decorators.call_soon(...) SQLAlchemy ORM (see SQLAlchemy method, 578 ORM) loop.run_in_executor(...) Asynchronous test functions function, 334, 335, 373 aggregation code sensor endpoints, 347 run(...) function, 324, 345 HTTP response, 347 Semaphore class, 333 test server (see Test servers) sleep(...) function, 326, 332 AsyncIO code, 322 Audit log, 532 async def, 323 Automatic type inference, 159, 160 async for, 327, 329, 330 __await__( ) method, 325 async lock, 332 Awaitables, 325 async with, 331 cancel( ) method, 568 benchmarking, 340 implementation details, 325 comparison of tasks and tasks, 325 coroutines, 326 await keyword, 324 concurrent code safety, 333 concurrent execution, 326 event loop, 333 B force coroutine switch, 332 black, 94 has lost, 341 applying to existing codebase, 94 has won, 341 installing, 94 HTTP client, 336 purpose, 93 limitations, 339 Blocking, 285, 322 loop argument, 515 breakpoint( ) function, 48 synchronization, 332, 333 debugging threads, 11 synchronous libraries, 334, 335 builtins, 2 synchronous vs. asynchronous, 323, 334 breakpoint( ) function, 10 testing, 345 changing the debugger, 11 asyncio module, 324 using, 10 Condition class, 333 dir(...) function, 170 create_task(...) function, 325, 326 filter(...) function, 2 590 INDEX getattr(...) function, 158 customisation, 165 help(...) function, 2 enabling, 165 map(...) function, 278 @confirmation_option(...) open(...) function, 116 decorator, 167 print(...) function, 6, 35, 37 echo(...) function, 35 sorted(...) function, 202, 297 file handling, 162 vars(...) function, 170 flags, 278 bytecode, 296 group, 155 disassembling, 296 @help_option(...) decorator, 166 example, 297 metavar parameter, 154 .pyc files, 296 option, 156 simultaneous execution, 298 @password_option(...) decorator, 167 secho(...) function, 37, 161 @version_option(...) decorator, 166 C Closures, 197, 198 __call__(...) method, 204 minimal example, 197 CHANGES.md file using classes instead, 204 apd.sensors package, 136 collections.abc module, 477 semantic versioning, 138 AsyncIterator class, 477 Classic SQLAlchemy style Collection class, 492 run_in_executor(...) function, 374 Container class, 492 stmt objects, 370 Iterable class, 492 @classmethod decorator, 62, 263 Mapping class, 492 clean functions, 422 Sequence class, 492 clean_magnitude(...) function, 425 Sized class, 492 clean_passthrough(...) function, 422, collections module, 361, 426 424, 542 deque class, 426 clean_temperature_fluctuations(...) namedtuple(...) function, 361 (see also function, 474, 477 Dynamic class generation) clean_watthours_to_watts(...) Command-line interface, 29 function, 458, 459, 488 argparse module, 34 purpose, 422 argv, 30, 33 specifying in config, 423 bold text, 37 Click, 153 click, 34–37 argument types, 153, 162, 163, 278 command(...) decorator, 35 creating custom, 163 secho(...), 36 latitude/longitude example, 162 exit codes, 161 autocomplete, 163, 165, 182 flags, 31, 33, 153 591 INDEX Command-line interface (cont.) contextvars module ifmain, 29 context.run(...) function, 393 __name__ attribute, 30 ContextVar class, 393 signal handlers, 575 copy_context() function, 393 subcommands, 153 Control flows, 559 Command-line tool, 539, 571 Cookiecutter, 247 Complex queries, ORM aggregation process, 252–254 against views, 388–391 alembic documentation, 268 alembic revision, 381 apd.sensors, 250 ExprComparator type, 382, 385 install templates, 248 filter section, 381 preexisting templates, 248 @hybrid_property decorator, 381 pre/post-generation hooks, 251 hybrid property, 385 project creation, 248 indexes, 386 templates creation, 249, 250 transparent optimized comparator, 383 Coroutines, 324 update_expression, 382, 384 defining, 323 Config class, 448 CPython, 296 changes to support maps, 445 Custom classes, 361 (see also Maps) data classes, 361 (see also dataclasses created by end users, 481 module) draw(...) function, 448 custom initializers, 362 get_data(...) function, 448 defining fields, 362 SolarCumulativeOutput config, 155 dictionary conversion, 363 (see also apd.sunnyboy_solar equality, 363 package) field configuration, 363 typing, 447 immutability, 363 configparser, 174, 178 mutable defaults, 364 Configuration files, 174 ordering, 363 console_scripts, 129 uses, 361 Declarative approach, 130 (see also for mocking, 361 (see also mocking) setup.cfg) named tuple, 238, 361, 362 __contains__(...) method, 492 named tuple, adding methods to, 362 contextlib module, 364 __slots__, 461 @asynccontextmanager decorator, 365 Custom index server @contextmanager decorator, 364, 365 dependency metadata, 121 FakeAIOHttpClient, 365 integrity, 124, 125 Context managers, 295 warehouse, 120 Context variable, 582, 583 Custom map chart, 449, 450 592 INDEX D Descriptors, 260 alembic.ini file, 264 Data classes create_all(...) function, 263, 265 backwards compatibility of env.py, 265 constructors, 446 migration framework, 263 custom repr behavior, deserialize(...) functions, 235 comparison, 364 Design patterns, 229 dataclass decorator, 362 DHT base class, 506 hashable, 363 Discoverability, 354 dataclasses module, 361 dis module, 296 @dataclass decorator, 361, 362 Distribution, 105 field class, 363 C extensions, avoiding, 148 __post_init__(...) method, 362 converting to wheel, 126 DataPoint objects, 337, 397 cryptographic signing, 125 DataProcessor class, 561 hash, 123 datetime.date.today( ) function, 379 Immutability, 125 datetimes, 215 releasing, 141 db_session_var context variable, 399 source distribution, 110, 142 Debugging, 8, 400 src layout, 106 Decision tree, 218 Django, 105, 190, 258, 375, 386, 387 authorization, 191 Documentation, 130 databases, 255 draw(...) function, 479 generator control flow, 559 Duck typing, 51 metaclasses, 218 Dynamic class generation, 230 parallelization, 342 Dynamic dispatch, 51 Decorators, 196 single dispatch, 476 with arguments, 202, 204 URL-based dispatch for the web, 195 class-based, 204 generic decorators, 205 Minimal example, 200 E typed, 206 Elasticsearch, 256 Delayed teardown, 355 Enhanced generator, 548 Dependencies, 18 classes as an alternative, 551 conditional dependencies, 42, 111–113 converting to an iterator, 552 development dependencies, 19 iterable, 552 optional dependencies, 193 refactoring functions, 554, 555 pinning versions (see Version pin) return value of yield statement, 548 specifying, 110 sending data, 549 593 INDEX Enhanced generator (cont.) unittest package, 512 standard, 553 tracebacks, 502, 503 using classes, 551 block, 504–506 __enter__() method, 364 raise, 506, 507 entry_points, 129, 171 TypeError/ValueError, 497 find all groups, 171 Ethics, 382, 520 list group contents, 172 __exit__(...) method, 364 resolving references, 173 Extended tuple unpacking, 252 use, 170 enum module, 161 Flag class, 576 F implementing a bitmask, 576 File modes, 114 IntEnum class, 161 Filtering data .env files, 179 deployment_id, 406 Environment variables, 178 get_data(...) method, 404, 405 Microsoft Windows, 182 helper functions, 407, 408 PYTHONOPTIMIZE environment sensor deployments, 405 variable, 498 Fixture scoping PYTHONWARNINGS environment conftest.py module, 354 variable, 518 delayed, 355 reading, 178 effects, 355 setting with pipenv, 179 HTTP server, 354 __eq__(...) method, 362, 385 test_http_get.py test module, 355 Error handling, 491 FizzBuzz, 3 abstract base classes, 493 flake8, 93 custom exceptions, 498, 499, 501, 502 exclude checks, 95 exceptions, 496 Flask, 192, 288 implementations, 495 accessing request data, 205 IndexError, 497 API server, minimal example, 194 items from container, 492 @app.route(...) decorator, 194, 195, 210 KeyboardInterrupt, 496 blueprints, 241, 243 KeyError, 497 blueprints,
Load more

Recommended publications
  • The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 Minutes)
    EuroPython 2007 Contribution ID: 62 Type: not specified The Essentials of Stackless Python Tuesday, 10 July 2007 10:00 (30 minutes) This is a re-worked, actualized and improved version of my talk at PyCon 2007. Repeating the abstract: As a surprise for people who think they know Stackless, we present the new Stackless implementation For PyPy, which has led to a significant amount of new insight about parallel programming and its possible implementations. We will isolate the known Stackless as a special case of a general concept. This is a Stackless, not a PyPy talk. But the insights presented here would not exist without PyPy’s existance. Summary Stackless has been around for a long time now. After several versions with different goals in mind, the basic concepts of channels and tasklets turned out to be useful abstractions, and since many versions, Stackless is only ported from version to version, without fundamental changes to the principles. As some spin-off, Armin Rigo invented Greenlets at a Stackless sprint. They are some kind of coroutines and a bit of special semantics. The major benefit is that Greenlets can runon unmodified CPython. In parallel to that, the PyPy project is in its fourth year now, and one of its goals was Stackless integration as an option. And of course, Stackless has been integrated into PyPy in a very nice and elegant way, much nicer than expected. During the design of the Stackless extension to PyPy, it turned out, that tasklets, greenlets and coroutines are not that different in principle, and it was possible to base all known parallel paradigms on one simple coroutine layout, which is as minimalistic as possible.
    [Show full text]
  • Python Concurrency
    Python Concurrency Threading, parallel and GIL adventures Chris McCafferty, SunGard Global Services Overview • The free lunch is over – Herb Sutter • Concurrency – traditionally challenging • Threading • The Global Interpreter Lock (GIL) • Multiprocessing • Parallel Processing • Wrap-up – the Pythonic Way Reminder - The Free Lunch Is Over How do we get our free lunch back? • Herb Sutter’s paper at: • http://www.gotw.ca/publications/concurrency-ddj.htm • Clock speed increase is stalled but number of cores is increasing • Parallel paths of execution will reduce time to perform computationally intensive tasks • But multi-threaded development has typically been difficult and fraught with danger Threading • Use the threading module, not thread • Offers usual helpers for making concurrency a bit less risky: Threads, Locks, Semaphores… • Use logging, not print() • Don’t start a thread in module import (bad) • Careful importing from daemon threads Traditional management view of Threads Baby pile of snakes, Justin Guyer Managing Locks with ‘with’ • With keyword is your friend • (compare with the ‘with file’ idiom) import threading rlock = threading.RLock() with rlock: print "code that can only be executed while we acquire rlock" #lock is released at end of code block, regardless of exceptions Atomic Operations in Python • Some operations can be pre-empted by another thread • This can lead to bad data or deadlocks • Some languages offer constructs to help • CPython has a set of atomic operations due to the operation of something called the GIL and the way the underlying C code is implemented • This is a fortuitous implementation detail – ideally use RLocks to future-proof your code CPython Atomic Operations • reading or replacing a single instance attribute • reading or replacing a single global variable • fetching an item from a list • modifying a list in place (e.g.
    [Show full text]
  • Thread-Level Parallelism II
    Great Ideas in UC Berkeley UC Berkeley Teaching Professor Computer Architecture Professor Dan Garcia (a.k.a. Machine Structures) Bora Nikolić Thread-Level Parallelism II Garcia, Nikolić cs61c.org Languages Supporting Parallel Programming ActorScript Concurrent Pascal JoCaml Orc Ada Concurrent ML Join Oz Afnix Concurrent Haskell Java Pict Alef Curry Joule Reia Alice CUDA Joyce SALSA APL E LabVIEW Scala Axum Eiffel Limbo SISAL Chapel Erlang Linda SR Cilk Fortan 90 MultiLisp Stackless Python Clean Go Modula-3 SuperPascal Clojure Io Occam VHDL Concurrent C Janus occam-π XC Which one to pick? Garcia, Nikolić Thread-Level Parallelism II (3) Why So Many Parallel Programming Languages? § Why “intrinsics”? ú TO Intel: fix your #()&$! compiler, thanks… § It’s happening ... but ú SIMD features are continually added to compilers (Intel, gcc) ú Intense area of research ú Research progress: 20+ years to translate C into good (fast!) assembly How long to translate C into good (fast!) parallel code? • General problem is very hard to solve • Present state: specialized solutions for specific cases • Your opportunity to become famous! Garcia, Nikolić Thread-Level Parallelism II (4) Parallel Programming Languages § Number of choices is indication of ú No universal solution Needs are very problem specific ú E.g., Scientific computing/machine learning (matrix multiply) Webserver: handle many unrelated requests simultaneously Input / output: it’s all happening simultaneously! § Specialized languages for different tasks ú Some are easier to use (for some problems)
    [Show full text]
  • Uwsgi Documentation Release 1.9
    uWSGI Documentation Release 1.9 uWSGI February 08, 2016 Contents 1 Included components (updated to latest stable release)3 2 Quickstarts 5 3 Table of Contents 11 4 Tutorials 137 5 Articles 139 6 uWSGI Subsystems 141 7 Scaling with uWSGI 197 8 Securing uWSGI 217 9 Keeping an eye on your apps 223 10 Async and loop engines 231 11 Web Server support 237 12 Language support 251 13 Release Notes 317 14 Contact 359 15 Donate 361 16 Indices and tables 363 Python Module Index 365 i ii uWSGI Documentation, Release 1.9 The uWSGI project aims at developing a full stack for building (and hosting) clustered/distributed network applica- tions. Mainly targeted at the web and its standards, it has been successfully used in a lot of different contexts. Thanks to its pluggable architecture it can be extended without limits to support more platforms and languages. Cur- rently, you can write plugins in C, C++ and Objective-C. The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project. Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules fol- lowed). Contents 1 uWSGI Documentation, Release 1.9 2 Contents CHAPTER 1 Included components (updated to latest stable release) The Core (implements configuration, processes management, sockets creation, monitoring, logging, shared memory areas, ipc, cluster membership and the uWSGI Subscription Server) Request plugins (implement application server interfaces for various languages and platforms: WSGI, PSGI, Rack, Lua WSAPI, CGI, PHP, Go ...) Gateways (implement load balancers, proxies and routers) The Emperor (implements massive instances management and monitoring) Loop engines (implement concurrency, components can be run in preforking, threaded, asynchronous/evented and green thread/coroutine modes.
    [Show full text]
  • Goless Documentation Release 0.6.0
    goless Documentation Release 0.6.0 Rob Galanakis July 11, 2014 Contents 1 Intro 3 2 Goroutines 5 3 Channels 7 4 The select function 9 5 Exception Handling 11 6 Examples 13 7 Benchmarks 15 8 Backends 17 9 Compatibility Details 19 9.1 PyPy................................................... 19 9.2 Python 2 (CPython)........................................... 19 9.3 Python 3 (CPython)........................................... 19 9.4 Stackless Python............................................. 20 10 goless and the GIL 21 11 References 23 12 Contributing 25 13 Miscellany 27 14 Indices and tables 29 i ii goless Documentation, Release 0.6.0 • Intro • Goroutines • Channels • The select function • Exception Handling • Examples • Benchmarks • Backends • Compatibility Details • goless and the GIL • References • Contributing • Miscellany • Indices and tables Contents 1 goless Documentation, Release 0.6.0 2 Contents CHAPTER 1 Intro The goless library provides Go programming language semantics built on top of gevent, PyPy, or Stackless Python. For an example of what goless can do, here is the Go program at https://gobyexample.com/select reimplemented with goless: c1= goless.chan() c2= goless.chan() def func1(): time.sleep(1) c1.send(’one’) goless.go(func1) def func2(): time.sleep(2) c2.send(’two’) goless.go(func2) for i in range(2): case, val= goless.select([goless.rcase(c1), goless.rcase(c2)]) print(val) It is surely a testament to Go’s style that it isn’t much less Python code than Go code, but I quite like this. Don’t you? 3 goless Documentation, Release 0.6.0 4 Chapter 1. Intro CHAPTER 2 Goroutines The goless.go() function mimics Go’s goroutines by, unsurprisingly, running the routine in a tasklet/greenlet.
    [Show full text]
  • Continuations and Stackless Python
    Continuations and Stackless Python Or "How to change a Paradigm of an existing Program" Christian Tismer Virtual Photonics GmbH mailto:[email protected] Abstract 2 Continuations In this paper, an implementation of "Stackless Python" (a Python which does not keep state on the C 2.1 What is a Continuation? stack) is presented. Surprisingly, the necessary changes affect just a small number of C modules, and Many attempts to explain continuations can be found a major rewrite of the C library can be avoided. The in the literature[5-10], more or less hard to key idea in this approach is a paradigm change for the understand. The following is due to Jeremy Hylton, Python code interpreter that is not easy to understand and I like it the best. Imagine a very simple series of in the first place. Recursive interpreter calls are statements: turned into tail recursion, which allows deferring evaluation by pushing frames to the frame stack, x = 2; y = x + 1; z = x * 2 without the C stack involved. In this case, the continuation of x=2 is y=x+1; By decoupling the frame stack from the C stack, we z=x*2. You might think of the second and third now have the ability to keep references to frames and assignments as a function (forgetting about variable to do non-local jumps. This turns the frame stack into scope for the moment). That function is the a tree, and every leaf of the tree can now be a jump continuation. In essence, every single line of code has target.
    [Show full text]
  • Threading and GUI Issues for R
    Threading and GUI Issues for R Luke Tierney School of Statistics University of Minnesota March 5, 2001 Contents 1 Introduction 2 2 Concurrency and Parallelism 2 3 Concurrency and Dynamic State 3 3.1 Options Settings . 3 3.2 User Defined Options . 5 3.3 Devices and Par Settings . 5 3.4 Standard Connections . 6 3.5 The Context Stack . 6 3.5.1 Synchronization . 6 4 GUI Events And Blocking IO 6 4.1 UNIX Issues . 7 4.2 Win32 Issues . 7 4.3 Classic MacOS Issues . 8 4.4 Implementations To Consider . 8 4.5 A Note On Java . 8 4.6 A Strategy for GUI/IO Management . 9 4.7 A Sample Implementation . 9 5 Threads and GUI’s 10 6 Threading Design Space 11 6.1 Parallelism Through HL Threads: The MXM Options . 12 6.2 Light-Weight Threads: The XMX Options . 12 6.3 Multiple OS Threads Running One At A Time: MSS . 14 6.4 Variations on OS Threads . 14 6.5 SMS or MXS: Which To Choose? . 14 7 Light-Weight Thread Implementation 14 1 March 5, 2001 2 8 Other Issues 15 8.1 High-Level GUI Interfaces . 16 8.2 High-Level Thread Interfaces . 16 8.3 High-Level Streams Interfaces . 16 8.4 Completely Random Stuff . 16 1 Introduction This document collects some random thoughts on runtime issues relating to concurrency, threads, GUI’s and the like. Some of this is extracted from recent R-core email threads. I’ve tried to provide lots of references that might be of use.
    [Show full text]
  • Expert Python Programming Third Edition
    Expert Python Programming Third Edition Become a master in Python by learning coding best practices and advanced programming concepts in Python 3.7 Michał Jaworski Tarek Ziadé BIRMINGHAM - MUMBAI Expert Python Programming Third Edition Copyright © 2019 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Commissioning Editor: Kunal Chaudhari Acquisition Editor: Chaitanya Nair Content Development Editor: Zeeyan Pinheiro Technical Editor: Ketan Kamble Copy Editor: Safis Editing Project Coordinator: Vaidehi Sawant Proofreader: Safis Editing Indexer: Priyanka Dhadke Graphics: Alishon Mendonsa Production Coordinator: Shraddha Falebhai First published: September 2008 Second edition: May 2016 Third edition: April 2019 Production reference: 1270419 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78980-889-6 www.packtpub.com To my beloved wife, Oliwia, for her love, inspiration, and her endless patience.
    [Show full text]
  • Python Implementation Strategies
    Python Implementation Strategies Jeremy Hylton Python / Google Python language basics • High-level language – Untyped but safe – First-class functions, classes, objects, &c. – Garbage collected – Simple module system – Lexically scoped • Std primitive objects: str, num, dict, list, tuple • Object-orientation – Multiple inheritance, single dispatch – Metaclass for customization Introspection in Python • Nearly every object supports introspection – Classes and instances represented as dictionaries – Access to local variables via dictionary – Modify top-level name bindings in other modules – Load bytecode from string • Originally envisioned for debugging – But many projects find ways to abuse – Language does not provide encapsulation – Makes optimization more challenging Python implementation • Standard Python interpreter – Classic bytecode interpreter implemented in C – Small, straightforward implementation • Roughly 230k LOC, a dozen active developers – Large, platform-specific subsystems: Mac, Win32 •Jython – Python running on the JVM; development stalled • IronPython – Experimental implementation for CLR • Easy to extend / embed in host environment Memory management • All objects are heap allocated – Everything is boxed – Very high allocation rate • Reference counting + cyclic trash collection • Objects consume a lot of memory – Doubly-linked list of containers for cycle detection – Instances typically used dict to store variables • Optimizations? – Custom small object allocator – Type-specific free lists for int, frame Multithreading
    [Show full text]
  • CS164: Introduction to Programming Languages and Compilers, Spring 2012 Thibaud Hottelier UC Berkeley
    Lecture 5 Implementing Coroutines compile AST to bytecode, bytecode interpreter Ras Bodik Hack Your Language! Shaon Barman CS164: Introduction to Programming Thibaud Hottelier Languages and Compilers, Spring 2012 UC Berkeley 1 What you will learn today Implement Asymmetric Coroutines – why a recursive interpreter with implicit stack won’t do Compiling AST to bytecode - this is your first compiler; compiles AST to “flat” code Bytecode Interpreter - bytecode can be interpreted without recursion - hence no need to keep interpreter state on the call stack 2 PA2 PA2 was released today, due Sunday – bytecode interpreter of coroutines – after PA2, you will be able to implement iterators – in PA3, you will build Prolog on top of your coroutines – extra credit: cool use of coroutines (see L4 reading) HW3 has been assigned: cool uses of coroutines This homework is not graded. While it is optional, you are expected to know the homework material: 1) lazy list concatenation 2) regexes Solve at least the lazy list problem before you start on PA2 3 Code 4 Cal Hackathon Friday, February 3, 9:00pm to Saturday, February 4 5:00pm Soda Hall Wozniak Lounge Grand Prize: $1,500!!! Register @ http://code4cal.eventbrite.com/ More information about the event at http://stc.berkeley.edu. The Student Technology Council (STC), an advisory council for the UC Berkeley CIO, Shel Waggener, is hosting Code 4 Cal, a hackathon for students to create innovative, sustainable, and most of all, useful applications or widgets for Cal students. Student-developed app could be adopted by the University! Cash prizes start at $1,500. 4 Review of L4: Why Coroutines Loop calls iterator function to get the next item eg the next token from the input The iterator maintains state between two such calls eg pointer to the input stream.
    [Show full text]
  • AAAI Proceedings Template
    Rules versus Scripts in Games Artificial Intelligence Nathan Combs, Jean-Louis Ardoint BBN Technologies, ILOG S.A. [email protected] [email protected] Abstract indicate where they should move, e.g. pathways. The Most game behavior is written using scripts instead of rules. developer can coordinate objects and events graphically as Rules are declarative representations that, given variables in well as embed logic with the objects - behavior is added to the game, encode relationships and facts about the game. the objects by “drilling in” and associating scripts and/or From these facts one can reason about truth in the game changing property values. world. Scripts are imperative representations: they provide a set of instructions that are used to process game variables While details differ across individual games and genres, and compute some conclusion. Scripting is more intuitive the pattern is similar. For example, Operation Flashpoint for game designers and developers to work with. It is easier to conceptualize and write a script that says: "go right, go (Codemasters) provides a graphical mission editor, left, turn around twice, go straight, then fire your gun..." whereas, Unreal Tournament uses a more complex CAD then it is to formulate a set of rules that could shape an level-editor. This design pattern is an “environment- entities movement to the same effect. based programming” style that has its roots in early game systems (e.g., RuthMOO’s “Programming the While scripting allows developers to construct sophisticated Environment”) – where both the content and programming behaviors, typically these behaviors are brittle outside of the are intermingled.
    [Show full text]
  • Analysis of Threading Libraries for High Performance Computing
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TC.2020.2970706 © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Analysis of Threading Libraries for High Performance Computing Adrian´ Castello´ Rafael Mayo Gual Sangmin Seo Pavan Balaji Universitat Jaume I Universitat Jaume I Ground X Argonne National Laboratory Castellon´ de la Plana, Spain Castellon´ de la Plana, Spain Seoul, Korea Lemmont, USA Email: [email protected] Email: [email protected] Email: [email protected] Email: [email protected] Enrique S. Quintana-Ort´ı Antonio J. Pena˜ Universitat Politecnica` de Valencia` Barcelona Supercomputing Center (BSC) Valencia,` Spain Barcelona, Spain Email: [email protected] Email: [email protected] Abstract—With the appearance of multi-/many core machines, of hardware parallelism may be inefficient. In response to applications and runtime systems evolved in order to exploit the this problem, dynamic scheduling and lightweight threads new on-node concurrency brought by new software paradigms. (LWTs) (also known as user-level threads, or ULTs) models POSIX threads (Pthreads) was widely-adopted for that purpose were first proposed in [5] in order to deal with the required and it remains as the most used threading solution in current levels of parallelism, offering more efficient management, hardware.
    [Show full text]