Tech News - Programming

Last week, Michael Thomsen, the Project Manager for Dart announced the stable release of Dart 2.5 SDK (Software Development Kit). This release includes two technical previews of ML Complete and the dart:ffi foreign function interface to be used for calling C code directly from Dart. Dart 2.5 also brings improved support for constant expressions. Preview of ML Complete In his blog, Thomsen has regarded ML Complete as a “powerful addition” to their existing suite of productivity tools like hot reload, customizable static analysis, and Dart DevTools. It works by training a model of possible member occurrences in a given context. The possible occurrences can be analyzed from the available open-source Dart code on Github. The training model uses TensorFlow Lite tools to predict the next probable symbol, while the developer is editing. As ML Complete is built directly into the Dart analyzer, it is available on all Dart-enabled editors including Android Studio, IntelliJ, and VS Code. Since it is still in preview, developers are advised to use the Flutter dev channel or the Dart dev channel for previewing this feature. Preview of the dart:ffi foreign function interface The dart:ffi feature enables users to take advantage of the existing native APIs, where Dart code is already running. Users can also utilize the existing cross-platform native libraries written in C. Currently, the support for calling C directly from Dart is limited to the Dart VM deep integration which uses native extensions. The new dart:ffi foreign function interface will function on a new mechanism, offering great performance, easy approach, and will work across many Dart supported platforms and compilers. Dart-C interop works on two main scenarios: Calling a C-based system API on the host operating system (OS) For calling a C-based system API, the Linux command system is used. The system command allows the execution of any system command. It also allows the argument to be essentially passed to the shell/terminal and also run there. For implementing the dart:ffi, the Dart code needs to represent the C function and the types of its arguments and return type. It also needs to represent the corresponding Dart function, and its types. Both the representations are done by defining two typedefs in the C header for the command. Calling a C-based library for a single OS or cross-platform The dart:ffi feature is also used to implore C-based frameworks and components. It will allow the user to run TensorFlow across all the operating systems where code completion is needed. It also offers high performance of the native TensorFlow implementation. Thomsen adds, “We also expect that the ability to call C-based libraries will be of great use to Flutter apps. You can imagine calling native libraries such as Realm or SQLite, and we think dart:ffi will be valuable for enabling plugins for Flutter desktop.” Developers are advised to use the Flutter master channel or a Dart dev channel to quickly learn about the changes and improvements in the dart:ffi feature. Read Also: Dart 2.2 is out with support for set literals and more! Improvements in constant expressions In the earlier versions, the abilities of constant expressions were limited, however, Dart 2.5 includes many new changes. In Dart 2.5, constant expressions can be defined using many ways, which includes the ability to use casts and the new control flow and collection spread features. Image Source: Medium Users love Dart 2.5 features. https://twitter.com/geek_timofey/status/1171507571372380167 https://twitter.com/Fredrikkerlund2/status/1171461649217097728 https://twitter.com/RashidG92908642/status/1171910418807369728 To know more about this announcement in detail, visit Michael Thomsen’s blog on Medium. Other Interesting News in Programming Microsoft releases Cascadia Code version 1909.16, the latest monospaced font for Windows Terminal and Visual Studio Code Microsoft open-sources its C++ Standard Library (STL) used by MSVC tool-chain and Visual Studio Linux 5.3 releases with support for AMD Navi GPUs, Zhaoxin x86 CPUs and power usage improvements

Yesterday the Mypy team uploaded mypy 0.730 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes many features, bug fixes and library stub updates. You can install it as follows: python3 -m pip install -U mypy Python creator Guido van Rossum tweeted about this release, he says “mypy 0.720 released. New semantic analyzer is now the default! Also, --warn-unreachable flag, and many more fixes and updates.” Major updates in Mypy 0.730 Some of the breaking changes in the Mypy 0.730 include: More precise error locations If you call a function with an incompatible argument type, mypy now points the error message to the argument with the incompatible type. Previously, mypy pointed to the function being called, which could be confusing in multi-line calls. Error codes Mypy 0.730 can now optionally display error codes. They are shown within square brackets after each error message: prog.py:24: error: "str" has no attribute "trim"  [attr-defined] Enable error codes using --show-error-codes (or show_error_codes = True in a configuration file). Ignoring specific error codes You can ignore only errors with specific error codes on a particular line by using a # type: ignore[code, ...] comment. This reduces the risk of ignoring unexpected, serious errors when using # type: ignore comments that ignore (almost) all possible errors on a line. Colors in output Mypy 0.730 now uses colored, more user-friendly output by default. You can use --no-color to disable colored output. You can use --no-error-summary to hide the summary line with the number of errors. Pretty output mode You can use --pretty to display each line which had errors and a caret that points to the location of the error on each line. Old semantic analyzer removed This release of Mypy 0.730 no longer includes the old semantic analyzer. Reachability and context managers The --warn-unreachable option now behaves more correctly with “exception-swallowing” context managers. If a context manager is currently declared to return bool but it never swallows exceptions, you should annotate the return of __exit__ as Literal[False] instead of bool, or otherwise mypy may complain about missing return statements. To know more about this release, read the full documentation on Read the Docs. Other interesting news in programming Łukasz Langa at PyLondinium19: “If Python stays synonymous with CPython for too long, we’ll be in big trouble” Microsoft introduces Pyright, a static type checker for the Python language written in TypeScript Python 3.8 alpha 2 is now available for testing

Go 1.12 was released yesterday with opt-in support for TLS 1.3, improved modules support, support for windows/arm, and improved macOS & iOS forwards compatibility. The previous Go version, Go 1.11 was released in August last year. What’s new in Go 1.12? Opt-in support for TLS 1.3 Go 1.12 adds opt-in support for TLS 1.3 in the crypto/tls package. It can be enabled by adding the value tls13 = 1 to the GODEBUG environment variable. It will be enabled by default in Go 1.13. All TLS 1.2 features except TLSUnique in ConnectionState and renegotiation are available in TLS 1.3 and provide equivalent or better security and performance. TLS 1.3 cipher suites are not configurable. Since TLS 1.3 0-RTT mode involves clients keeping state regarding which servers support 0-RTT, a Go 1.12 server cannot be part of a load-balancing pool where some other servers do support 0-RTT. In TLS 1.3, the client is the last one to speak in the handshake, so if it causes an error to occur on the server, it will be returned on the client by the first Read, not by Handshake. Improved Module support The go command now supports module-aware operations outside of a module directory, provided that those operations do not need to resolve import paths relative to the current directory or explicitly edit the go.mod file. Commands such as go get, go list, and go mod download behave as if in a module with initially-empty requirements. go commands that download and extract modules are now safe to invoke concurrently. The go directive in a go.mod file now indicates the version of the language used by the files within that module. The go command will now try to use the modules mentioned in the main module's replace directives before consulting the module cache and the usual network sources. This happens when an import cannot be resolved using the active modules. Other changes Go's new windows/arm port supports running Go on Windows 10 IoT Core on 32-bit ARM chips. It also supports AIX 7.2 and later on POWER8 architectures (aix/ppc64). For macOS, Go 1.13 will require macOS 10.11 El Capitan or later. The go vet command has been rewritten so go tool vet is no longer supported. The Go tour is no longer included in the main binary distribution. The build cache is now required as a step toward eliminating $GOPATH/pkg Go 1.12 will translate the C type EGLDisplay to the Go type uintptr. The compiler's live variable analysis has improved. Wrappers generated by the compiler to implement method expressions are no longer reported by runtime.CallersFrames and runtime.Stack. The compiler toolchain now uses different conventions to call Go functions and assembly functions. Go 1.12 is the last release that will include the godoc webserver; in Go 1.13 it will be available via go get. The trace tool now supports plotting mutator utilization curves, including cross-references to the execution trace. Go 1.12 significantly improves the performance of sweeping when a large fraction of the heap remains live. These are just a select few updates. For full details about the changes in Go 1.12, you may go through the Go 1.12 release notes. Go 1.11 support announced for Google Cloud Functions! Go 1.11.3 and Go 1.10.6 released with fixes to security issues Google Cloud announces new Go 1.11 runtime for App Engine

Researchers from Italy have published a research paper showcasing that quantum communication is feasible between high-orbiting satellites and a station on the ground. This new research proves that quantum communication is possible on a global scale by using a Global Navigation Satellite System (GNSS). The reports of the study are presented in a paper published last week titled Towards quantum communication from global navigation satellite system. In the experiment conducted, a single photon was exchanged over a distance of 20,000km between a ground station and a high-orbit satellite. The exchange was between the retroreflector array mounted on Russian GLONASS satellites and the Space Geodesy Centre on the Earth, Italian space agency. The challenge in high-orbit satellites is that the distance causes high diffraction losses in the channel. One of the co-authors, Dr. Giuseppe Vallone, University of Padova said to IOP Publishing: “Satellite-based technologies enable a wide range of civil, scientific and military applications like communications, navigation and timing, remote sensing, meteorology, reconnaissance, search and rescue, space exploration and astronomy.” He mentions that the crux of such systems is to safely transmit information from satellites in the air to the ground. It is important that these channels be protected from interference by third parties. “Space quantum communications (QC) represents a promising way to guarantee unconditional security for satellite-to-ground and inter-satellite optical links, by using quantum information protocols as quantum key distribution (QKD).” The quantum key distribution (QKD) protocols used in the experiment guarantee strong security for communication between satellites and satellites to Earth. In QKD, data is encrypted using quantum mechanics and interferences are detected quickly. Another co-author, Prof. Villoresi talks to IOP Publishing about their focus on high-orbit satellites despite the challenges: "The high orbital speed of low earth orbit (LEO) satellites is very effective for the global coverage but limits their visibility periods from a single ground station. On the contrary, using satellites at higher orbits can extend the communication time, reaching few hours in the case of GNSS.” After the experiments, the researchers estimated the requirements needed for an active source on a GNSS satellite. They aim towards QC from GNSS with state-of-the-art technology. This does not really mean faster internet/communication as only a single photon was transmitted in the experiment. This means that transferring large amounts of data quickly, i.e., faster internet is not likely gonna happen with this application. However, it does show that data transmission can be done over a large distance with a secure channel. For more details, you can check out the research paper on the IOPSCIENCE website. The US to invest over $1B in quantum computing, President Trump signs a law UK researchers build the world’s first quantum compass to overthrow GPS Quantum computing – Trick or treat?

Last week, the Linux Foundation introduced a new policy around the collection and usage of telemetry data. As per this new policy all linux projects before using any telemetry data collection mechanism will have to take permissions from the Linux Foundation and the proposed mechanism will undergo a detailed review. The Linux Foundation’s announcement follows closely after Gitlab’s telemetry data collection plan came to a halt. Last week, GitLab announced that it would begin collecting new data by inserting JavaScript snippets and interact with both GitLab and a third-party SaaS telemetry service. However, after receiving severe backlash from users, the company reversed its decision. The official statement from the Linux Foundation reads as follows, “Any Linux Foundation project is required to obtain permission from the Linux Foundation before using a mechanism to collect Telemetry Data from an open source project. In reviewing a proposal to collect Telemetry Data, the Linux Foundation will review a number of factors and considerations.” The Linux Foundation also states that the software sometimes includes the functionality to collect telemetry data. The data is collected through a “phone home” mechanism built into the software. And the end user deploying the software is typically presented with an option to opt-in to share this data with the developers. In doing so certain personal and sensitive information of the users might also get shared without realizing. Hence, to address such data breach and to adhere to the recent data privacy legislation like GDPR, the Linux Foundation has introduced this stringent telemetry data policy. Dan Lopez, a representative of the Linux Foundation states, “by default, projects of the Linux Foundation should not collect Telemetry Data from users of open source software that is distributed on behalf of the project.” New policy for telemetry data As per the new policy, if a project community desires to collect telemetry data, it must first coordinate with members of the legal team of the Linux Foundation to undergo a detailed review of the proposed telemetry data and collection mechanism. The review will include an analysis of the following: the specific data proposed to be collected demonstrating that the data is fully anonymized, and does not contain any sensitive or confidential information of users the manner in which users of the software are (1) notified of all relevant details of the telemetry data collection, use and distribution; and (2) required to consent prior to any telemetry data collection being initiated the manner in which the collected telemetry data is stored and used by the project community the security mechanisms that are used to ensure that collection of telemetry data will not result in (1) unintentional collection of data; or (2) security vulnerabilities resulting from the “phone home” functionality The Linux Foundation has also emphasized that telemetry data should not be collected unless and until the legal team approves the proposed collection. Additionally any telemetry data collection approved by the Linux Foundation must be fully documented, must make the collected data available to all participants in the project community, and at all times comply with the Linux Foundation’s Privacy Policy. A recap of the Linux Plumbers Conference 2019 IBM open-sources Power ISA and other chips; brings OpenPOWER foundation under the Linux Foundation Introducing kdevops, a modern DevOps framework for Linux kernel development GitLab retracts its privacy invasion policy after backlash from community

Mio, a cross-platform header-only C++11 memory mapping library with an MIT license, got released yesterday. Mio has been created with an objective of getting easily integrated into any C++ project. It uses a memory-mapped file IO without the need to pull in Boost libraries. The users faced issues with the Boost.Iostreams library as it didn’t work efficiently with respect to memory mapping. However, Mio has a lot of advantages over Boost.Iostreams. Advantages of Mio over Boost.Iostreams With Mio, the support for establishing a memory mapping with an already open file handle/descriptor became possible, which otherwise didn’t work with the Boost.Iostreams. Mio makes the memory mapping process easier by accepting any offset and finding the nearest page boundary. Whereas, Boost.Iostreams requires the user to pick offsets exactly at page boundaries, which may lead to errors. Boost.Iostreams implements a memory mapped file IO with a std::shared_ptr to provide shared semantics, even when it is not needed. This may lead to an overhead of the heap allocation, which may not be required. On the other hand, Mio solves this problem with its two use-cases, one that is move-only, which is a zero-cost abstraction over the system specific mapping functions and the other one which is similar to its Boost.Iostreams counterpart, with shared semantics. How does the memory mapping in Mio work? The three ways to map a file into memory are: Use the constructor, which throws on failure: mio::mmap_source mmap(path, offset, size_to_map Use the factory function: std::error_code error; mio::mmap_source mmap = mio::make_mmap_source(path, offset, size_to_map, error); Use the map member function: std::error_code error; mio::mmap_source mmap; mmap.map(path, offset, size_to_map, error); In each of the cases, you can either provide some string type for the file's path or you can simply use an existing, valid file handle. Mio does not check if the provided file descriptor has the same access permissions as the desired mapping, so the mapping process might fail. Such errors are reported via the std::error_code out parameter which is passed to the mapping function. CMake: A build system to help Mio As Mio is a header-only library, it has no compiled components. CMake build system assists Mio, by providing easy testing, installation, and subproject composition on many platforms and operating systems. In Testing When Mio is configured as the highest level CMake project, the suite of executables is built by default. Mio's test executables are integrated with the CMake test driver program, CTest. In Installation The CMake's find package intrinsic function helps Mio's build system to provide an installation target and support for downstream consumption to an arbitrary location. This can be specified by defining CMAKE_INSTALL_PREFIX at the time of configuration.  CMake will install Mio to conventional location based on the platform operating system in the absence of a user specification. Read more about Mio, in detail on the official GitHub page. Google releases Oboe, a C++ library to build high-performance Android audio apps Graph Nets – DeepMind’s library for graph networks in Tensorflow and Sonnet Ebiten 1.8, a 2D game library in Go, is here with experimental WebAssembly support and newly added APIs

Yesterday, the Qt team released Qt Design Studio 1.1, a UI design and development tool that enables designers and developers to prototype and develop complex UIs. Qt Design Studio makes collaboration between developers and designers easy and streamlined. Qt Design Studio 1.1 comes with the availability of Linux packages. What’s new in Qt Design Studio 1.1? Qt Design Studio 1.1 is available for Linux The developers who are using Linux can now use Qt Design Studio 1.1 directly on their development system. Qt Photoshop Bridge The team at Qt updated the Qt Photoshop Bridge (which allows sanitizing documents) for Qt Design Studio 1.1. But the PSD (Photoshop Document) files containing annotations from the Qt Photoshop Bridge 1.0, require to be sanitized. Annotations are added for exporting from a PSD file using the Qt Photoshop Bridge. Qt Photoshop Bridge and merging when importing It is now possible to merge the existing QML files with the newly re-imported QML while re-importing from Photoshop to an existing Qt Design Studio project. It is highly used when the user made changes to the exported .ui.qml files using Design Studio. The merging option can be enabled by using a checkbox in the import dialog. Update projects to Qt Design Studio 1.1 Users can update their projects to Qt Design Studio 1.1 by copying the controls from a newly created Qt Design Studio 1.1 project into the existing project from Qt Design Studio 1.0. The folder that needs to be replaced is “imports/QtQuick”. Replacing this folder will update the Qt Design Studio specific components that are used in the project. Major Changes Timeline The local record button has been fixed. The timeline has now been prevented from claiming too much space. Custom colors have been added to the timeline bar items. The issue with the status bar update has been fixed. Property Editor The issue with invalid access to network paths has been addressed. Item Library This release comes with an added support for enums in .metainfo files. The issue with Image.PreserveAspectFit has been fixed. Form Editor The issue with the visibility of the selection rectangle has been fixed. Components This release comes with an added support for negative length of zoom blur and for dash pattern. This release also features added cap style to components. Platform Specific This release features added support for the dark theme on macOS Mojave and Linux package for Linux. Major bug fixes The error messages have been fixed. The clamping keyframe positions to the animation range have been fixed. It is now possible to reset the status bar when changing the QML file. To know more about this news, check out Qt’s blog post. Qt for Python 5.12 released with PySide2, Qt GUI and more Qt team releases Qt Creator 4.8.0 and Qt 5.12 LTS Qt Design Studio 1.0 released with Qt photoshop bridge, timeline based animations and Qt live preview  

Yesterday, Google engineer Robert Griesemer published a blog post highlighting the outline of the next steps for Golang towards the Go 2 release. Google developer Russ Cox started the thought process behind Go 2 in his talk at GopherCon 2017. The talk was about the future of Go and pertaining to the changes that were talked about, the talk was informally called Go 2. A major change between the two versions is in the way design and changes are influenced. The first version only involved a small team but the second version will have much more participation from the community. The proposal process started in 2015, the Go core team will now work in the proposals for the second version of the programming language. The current status of Go 2 proposals As of November 2018, there are about 120 open issues on GitHub labeled Go 2 proposal. Most of them revolve around significant language or library changes often not compatible with Go 1. The ideas from the proposals will probably influence the language and libraries of the second version. Now there are millions of Go programmers and a large Go code body that needs to be brought together without an ecosystem split. Hence the changes done need to be less and carefully selected. To do this, the Go core team is implementing a proposal evaluation process for significant potential changes. The proposal evaluation process The purpose of the evaluation process is to collect feedback on a small number of select proposals to make a final decision. This process runs in parallel to a release cycle and has five steps. Proposal selection: The Go core team selects a few Go 2 proposals that seem good to them for acceptance. Proposal feedback: After selecting, the Go team announces the selected proposals and collects feedback from the community. This gives the large community an opportunity to make suggestions or express concerns. Implementation: The proposals are implemented based on the feedback received. The goal is to have significant changes ready to submit on the first day up an upcoming release. Implementation feedback: The Go team and community have a chance to experiment with the new features during the development cycle. This helps in getting further feedback. Final launch decision: The Go team makes the final decision on shipping each change at the end of the three-month development cycle. At this time, there is an opportunity to consider if the change delivers the expected benefits or has created any unexpected costs. When shipped, the changes become a part of the Go language. Proposal selection process and the selected proposals For a proposal to be selected, the minimum criteria are that it should: address an important issue for a large number of users have a minimal impact on other users is drafted with a clear and well-understood solution For trials a select few proposals will be implemented that are backward compatible and hence are less likely to break existing functionality. The proposals are: General Unicode identifiers based on Unicode TR31 which will allow using non-Western alphabets. Adding binary integer literals and support for_ in number literals. Not a very big problem solving change, but this brings Go up to par with other languages in this aspect. Permit signed integers as shift counts. This will clean up the code and get shift expressions better in sync with index expressions and built-in functions like cap and len. The Go team has now started with the proposal evaluation process and now the community can provide feedback. Proposals with clear, positive feedback will be taken ahead as they aim to implement changes by  February 1, 2019. The development cycle is Feb-May 2019 and the chosen features will be implemented as per the outlined process. For more details, you can visit the Go Blog. Golang just celebrated its ninth anniversary GoCity: Turn your Golang program into a 3D city Golang plans to add a core implementation of an internal language server protocol

Last week three IDEs were ported to Haiku OS. Now, Haiku OS users can build applications with Netbeans, Intellij IDEA, and PyCharm. Haiku is an offspring of BeOS which was created by an ex-Apple executive, Jean Luis Gassee. Haiku’s development began in 2001, the first beta was released in September 2018. It is a single user system targeted specifically for personal computing. It uses a custom kernel, a fully threaded design, and a cohesive interface. Haiku houses the progressive concepts from BeOS and delivers it in a free and open source package. Now, let’s look at the package ports to Haiku. Haiko OS users can now run both Netbeans and IntelliJ IDEA with the OpenJDK8 x86_64 port. This is not in the depot yet, only in the haikuports recipe. Moreover, due to the efforts of another community member, a package for PyCharm Community Edition 2018.3 is also available. There are some minor issues and users have to work around a few settings to get things working. The addition of NetBeans IDE 8.2 and Intellij IDEA Community Edition 2018.3 to Haiku OS has many of its users excited. A comment on Hacker news says: “That's a really impressive achievement I think, those are complex applications running on complex stacks. It's certainly a big step in the direction of making Haiku a system that a developer could plausibly run for the development of cross-platform applications. This coupled with the Libre Office port last year means there's a pretty strong selection of applications for it cropping up.” Note that, by default Haiku comes with the dying Python 2.7 and the next major version, Python 3 can be installed via the package manager. To keep an eye on updates of these IDEs, head over to the Haiku forums. Haiku beta released with package management, a new preflet, webkit and more The Haiku operating system has released R1/beta1 Haiku, the open source BeOS clone, to release in beta after 17 years of development

Apple announced Swift 5 for their Xcode 10.2 compiler. Swift in Xcode 10.2 beta brings a couple of new features like smaller app sizes when testing, new library, compiler features, and more. The application binary interface (ABI) is stable in Swift 5. Smaller app size App sizes on Swift 5 in Xcode 10.2 beta can be smaller now when deployed for testing. This is true when using TestFlight or when thinning an app for local distribution. Smaller app sizes are possible as Swift apps don’t include dynamically linked libraries for the Swift standard library anymore. Moreover, Swift SDK overlays for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2. Apple calls this concept ‘App thinning’. New features in Swift 5 A new attribute named @dynamicCallable allows dynamic language interoperability. Key paths support the identity keypath \.self. You can no longer write functions that take variadic arguments. Now you can change the enumeration case to ‘take an array explicitly and pass an array in.’ A try? block with an Optional type does not return a nested optional, instead of flattening the resulting option Literal types are modified so that expressions don’t overflow the default integer literal where the type is Int. String interpolation is now simpler, has better performance and efficiency. Changes in the Swift standard library The DictionaryLiteral type is now KeyValuePairs Swift strings bridged into Objective-C code can now return a non-nil value in certain cases The Sequence protocol is now disassociated from SubSequence. Native encoding in the string structure is now UTF-8 instead of UTF-16. What’s new in Swift package manager? When using Swift 5, targets can now declare commonly used build settings that are target-specific. In the Swift 5 Package.swift tools-version, packages can customize minimum deployment target settings. Top level packages can override dependency URLs The --enable-code-coverage flag helps other tools to use code coverage data generated by a tool Support for Swift 3 Package.swift tools-version has been dropped Larger packages are handled better by the package manager Package resolution for incompatible dependency versions are forced to fail A new --repl option in swift run launches the Swift REPL. This supports importing library targets of a package. Swift compiler Exclusive memory access is imposed at runtime by default. Swift 3 is removed. In Swift 5, switches on enumerations declared in Objective-C/system frameworks have to handle unknown cases For Swift modules, default arguments are printed in SourceKit-generated interfaces Support for Optional types is now added in unowned and unowned(unsafe) variables To know more details and bug fixes, visit the release notes. Swift is now available on Fedora 28 ABI stability may finally come in Swift 5.0 Swift 4.2 releases with language, library and package manager updates!

ClojureCUDA is a CUDA that supports parallel computations on the GPU with CUDA in the Clojure programming language. With this library, you can access high-performance Computing and GPGPU in Clojure. Installation ClojureCUDA 0.6.0 now has support for the new CUDA 10. To start using it: Install the CUDA 10 Toolkit Update your drivers Update the ClojureCUDA version in project.clj All the existing code should work without requiring any changes. CUDA and libraries CUDA is the most used environment for high-performance computing on NVIDIA GPUs. You can now use CUDA directly from the interactive Clojure REPL without having to wrangle with the C++ toolchain. High-performance libraries like Neanderthal take advantage of ClojureCUDA to deliver speed dynamically to Clojure programs. With these higher-level libraries, you can perform fast calculations with just a few lines of Clojure. You don’t even have to write the GPU code yourself. But writing the lower level GPU code is also not so difficult in an interactive Clojure environment. ClojureCUDA features The ClojureCUDA library has features like high performance and optimization for Clojure. High-performance computing CUDA enables various hardware optimizations on NVIDIA GPUs. Users can access the leading CUDA libraries for numerical computing like cuBLAS, cuFFT, and cuDNN. Optimized for Clojure ClojureCUDA is built with a focus on Clojure. The interface and functions fit into a functional style. They are also aligned to number crunching with CUDA. Reusable The library closely follows the CUDA driver API. Users translate examples from best CUDA books easily. Free and Open Source It is licensed under the Eclipse Public License (EPL) which is the same license used for Clojure. ClojureCUDA and other libraries by uncomplicate are open source. You can choose to contribute on GitHub or donate on Patreon. For more details and code examples, visit the dragan Blog. Clojure 1.10.0-beta1 is out! Stable release of CUDA 10.0 out, with Turing support, tools and library changes NVTOP: An htop like monitoring tool for NVIDIA GPUs on Linux

Gitlab released version 11.2 with new features to help developers get started and iterate faster. Major improvements in this version are enhancements to the Web IDE, support for manifesting files to import Android projects, and custom project templates enabled. Let us look at each in detail: Preview changes in Web IDE Contributing changes to your projects with an advanced code editor and commit staging right within your browser will be faster and easier with the new WebIDE version. You can now easily see the effect of your code change and debug even before you commit with the Gitlab 11.2. You can now preview your JavaScript web app in the Web IDE, viewing your changes in real time, right next to the code for client-side evaluation. In addition, with 11.2, you can delete and rename files and switch branches without ever leaving the Web IDE. Android Project Import Importing complex project structures with multiple sub-structures was a tedious, time-consuming task until now. With the new support for XML manifest files, you can now import larger project structures with multiple repositories altogether, including Android OS code from the Android Open Source Project (AOSP). Simplified Cloud Native & more features To help you quickly install Gitlab on Kubernetes, the Cloud Native Helm Chart is now generally available. A GitLab Runner is deployed, making it easy to get started with GitLab CI/CD. With 11.2, GitLab administrators can offer instance-wide custom project templates, allowing users to start new projects quickly by automating repetitive setup tasks. Features such as issue board milestone lists, summed weights for issue board lists, group milestones on the milestone dashboard page, and todos for epics enable better work management. Major changes and improvements are contributed by the Gitlab community itself. Check out the Gitlab page for more details. GitLab is moving from Azure to Google Cloud in July GitLab open sources its Web IDE in GitLab 10.7 GitLab’s new DevOps solution

Last week, Apache Storm PMC announced the release of Storm 2.0.0. The major highlight of this release is that Storm has been re-architected in pure Java. Previously a large part of Storm's core functionality was implemented in Clojure. This release also includes significant improvements in terms of performance, a new stream API, windowing enhancements, and Kafka integration changes. New Architecture Implemented in Java With this release, Storm has been re-architected, with its core functionality implemented in pure Java. This new implementation has improved its performance significantly and also has made internal APIs more maintainable and extensible. The previous language Clojure often posed a barrier for entry to new contributors. Storm's codebase will be now more accessible to developers who don't want to learn Clojure in order to contribute. New High-Performance Core Storm 2.0.0 has a new core featuring a leaner threading model, a blazing fast messaging subsystem and a lightweight back pressure model. This has been designed to push boundaries on throughput, latency, and energy consumption while maintaining backward compatibility. Also, this makes Storm 2.0, the first streaming engine to break the 1-microsecond latency barrier. New Streams API This version has a new typed API, which will express streaming computations more easily, using functional style operations. It builds on top of the Storm's core spouts and bolt APIs and automatically fuses multiple operations together. This will help in optimizing the pipeline. Windowing Enhancements Storm 2.0.0's windowing API can now save/restore the window state to the configured state backend. This will enable larger continuous windows to be supported. Also, the window boundaries can now be accessed via the APIs. Improvements in Kafka Kafka Integration Changes Removal of Storm-Kafka Due to Kafka's deprecation of the underlying client library, the storm-kafka module has been removed. Users will have to move, to the storm-kafka-client module. This uses Kafka's ‘kafka-clients’ library for integration. Move to Using the KafkaConsumer.assign API Kafka's own mechanism which was used in Storm 1.x has been removed entirely in 2.0.0. The storm-kafka-client subscription interface has also been removed, due to the limited control it offered over the subscription behavior. It has been replaced with the ‘TopicFilter’ and ‘ManualPartitioner’ interfaces. For custom subscription users, head over to the storm-kafka-client documentation, which describes how to customize assignment. Other Kafka Highlights The KafkaBolt now allows you to specify a callback that will be called when a batch is written to Kafka. The FirstPollOffsetStrategy behavior has been made consistent between the non-Trident and Trident spouts. Storm-kafka-client now has a transactional non-opaque Trident spout. Users have also been notified that the 1.0.x version line will no longer be maintained and have strongly encouraged users to upgrade to a more recent release. The Java 7 support has also been dropped, and Storm 2.0.0 requires Java 8. There has been a mixed reaction from users over the changes, in Storm 2.0.0. Few users are not happy with Apache dropping the Clojure language. As a user on Hacker News comments, “My team has been using Clojure for close to a decade, and we found the opposite to be the case. While the pool of applicants is smaller, so is the noise ratio. Clojure being niche means that you get people who are willing to look outside the mainstream, and are typically genuinely interested in programming. In case of Storm, Apache commons is run by Java devs who have zero interest in learning Clojure. So, it's not surprising they would rewrite Storm in their preferred language.” Some users think that this move of dropping Clojure language shows that developers nowadays are unwilling to learn new things As a user on Hacker News comments, “There is a false cost assigned to learning a language. Developers are too unwilling to even try stepping beyond the boundaries of the first thing they learned. The cost is always lower than they may think, and the benefits far surpassing what they may think. We've got to work at showing developers those benefits early; it's as important to creating software effectively as any other engineer's basic toolkit.” Others are quite happy with Storm getting Java enabled. A user on Reddit said, “To me, this makes total sense as the project moved to Apache. Obviously, much more people will be able to consider contributing when it's in Java. Apache goal is sustainability and long-term viability, and Java would work better for that.” To download the Storm 2.0.0 version, visit the Storm downloads page. Walkthrough of Storm UI Storing Apache Storm data in Elasticsearch Getting started with Storm Components for Real Time Analytics

Last week, the team behind RStudio released RStudio 1.2 that includes dozens of new productivity enhancements and capabilities. RStudio 1.2 is compatible with projects in SQL, Stan, Python, and D3. With this release, testing R code integrations for shinytest and testthat is easier. Users can create,  test, and publish APIs in R with Plumber and run R scripts. What’s new in RStudio 1.2? Python sessions This release uses a shared Python session for executing Python chunks. It comes with simple bindings to access R objects from Python chunks and vice versa. Keyring In RStudio 1.2, passwords and secrets are stored securely with keyring by calling rstudioapi::askForSecret(). Users can install keyring directly from dialog prompt. Run R scripts Users can now run any R script as a background job in a clean R session and can also have a look at the script output in real time. Testing with RStudio 1.2 Users can opt for Run Tests command in testthat R scripts for directly running their projects. The testthat output in the Build pane now comes with navigable issue list. PowerPoint Users can now create PowerPoint presentations with R Markdown Package management With RStudio 1.2, users can now Specify a primary CRAN URL and secondary CRAN repos from the package preferences pane. Users can link to a package’s primary CRAN page from the packages pane. The CRAN repos can be configured with a repos.conf configuration file and the r-cran-repos-file option. Plumber Users can now easily create Plumber APIs in RStudio 1.2 and execute them within RStudio to view Swagger documentation and make test calls to the APIs Bug fixes in RStudio 1.2 In this release, the issue regarding “invalid byte sequence” has been fixed. Incorrect Git status has been rectified. Issues with low/no-contrast colors with HTML widgets has been fixed. It seems most users are excited about this release and they think that this way, Python will be more accessible to R users. A user commented on HackerNews, “I’m personally an Emacs Speaks Statistics fan myself, but RStudio has been huge boon to the R community. I expect that this will go a long ways towards making Python more accessible to R users.” Some are not much happy with this release as they think it has less options for graphics. Another comment reads, “I wish rstudio would render markdown in-line. It also tends to forget graphics in output after many open and closes of rmd. I’m intrigued by .org mode but as far as I can tell, there are not options for graphical output while editing.” To know more about this news, check out the post by RStudio. How to create your own R package with RStudio [Tutorial] The new RStudio Package Manager is now generally available Getting Started with RStudio    

The stable release of LLVM 9.0 is expected to come in the next few weeks along with subprojects like Clang 9.0. As per the release notes, the upcoming Clang 9.0 release will come with experimental support for C++17 features in OpenCL, asm goto support, and much more. Read also: LLVM 9.0 RC3 is now out with official RISC-V support, updates to SystemZ and more What’s new coming in Clang 9.0.0 Experimental support for C++17 features in OpenCL Clang 9.0.0 will have experimental support for C++17 features in OpenCL. The experimental support includes improved address space behavior in the majority of C++ features. There is support for OpenCL-specific types such as images, samplers, events, and pipes. Also, the invoking of global constructors from the host side is possible using a specific, compiler-generated kernel. C language updates in Clang Clang 9.0.0 includes the __FILE_NAME__ macro as a Clang specific extension that is supported in all C-family languages. It is very similar to the __FILE__ macro except that it will always provide the last path component when possible. Another C language-specific update is the initial support for asm goto statements to control flow from inline assembly to labels. This construct will be mainly used by the Linux kernel (CONFIG_JUMP_LABEL=y) and glib. Building Linux kernels with Clang 9.0 With the addition of asm goto support, the mainline Linux kernel for x86_64 is now buildable and bootable with Clang 9. The team adds, “The Android and ChromeOS Linux distributions have moved to building their Linux kernels with Clang, and Google is currently testing Clang built kernels for their production Linux kernels.” Read also: Linux 4.19 kernel releases with open arms and AIO-based polling interface; Linus back to managing the Linux kernel Build system changes Previously, the install-clang-headers target used to install clang’s resource directory headers. With Clang 9.0, this installation will be done by the install-clang-resource-headers target. “Users of the old install-clang-headers target should switch to the new install-clang-resource-headers target. The install-clang-headers target now installs clang’s API headers (corresponding to its libraries), which is consistent with the install-llvm-headers target,” the release notes read. To know what else is coming in Clang 9.0, check out its official release notes. Other news in Programming Core Python team confirms sunsetting Python 2 on January 1, 2020 Developers from the Swift for TensorFlow project propose adding first-class differentiable programming to Swift Microsoft introduces Static TypeScript, as an alternative to embedded interpreters, for programming MCU-based devices