Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

Tech News - Programming

573 Articles
article-image-go-1-12-released-with-support-for-tls-1-3-module-support-among-other-updates
Sugandha Lahoti
26 Feb 2019
3 min read
Save for later

Go 1.12 released with support for TLS 1.3, module support among other updates

Sugandha Lahoti
26 Feb 2019
3 min read
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
Read more
  • 0
  • 0
  • 4259

article-image-iso-c-committee-announces-that-c20-design-is-now-feature-complete
Bhagyashree R
25 Feb 2019
2 min read
Save for later

ISO C++ Committee announces that C++20 design is now feature complete

Bhagyashree R
25 Feb 2019
2 min read
Last week, as per the schedule, the ISO C++ Committee met in Kona, Hawaii to finalize the feature set for the next International Standard (IS), C++ 20. The committee has announced that C++20 is now feature complete and they are planning to finish the C++20 specification at the upcoming meeting, which is scheduled to happen in July 2019. Once the specification is complete they are planning to send the Committee Draft for review. Some of the features this draft include Modules With the introduction of modules, developers will not require to separate their files into header and source parts. The committee has now fixed internal linkage escaping modules. Coroutines The committee has gone through the coroutines proposals and has decided to go ahead with the specification. According to the specification of this feature, three keywords will be added: co_await, co_yield, and co_return. Contracts Contracts are made up of preconditions, postconditions, and assertions. These act as a basic mitigation measure when a program goes wrong because of some mismatch of expectations between parts of the programs. The committee is focused on refining the feature and renamed expects/ensures to pre/post. Concepts The concepts library include the definitions of fundamental library concepts, which are used for compile-time validation of template arguments and perform function dispatch on properties of types. Ranges The ranges library comes with components for dealing with ranges of elements including a variety of view adapters. To read the entire announcement, check out this Reddit thread. Code completion suggestions via IntelliCode comes to C++ in Visual Studio 2019 How to build Template Metaprogramming (TMP) using C++[Tutorial] Mio, a header-only C++11 memory mapping library, released!
Read more
  • 0
  • 0
  • 6854

article-image-bmw-volleys-receives-clearance-to-open-source-ramses-a-3d-rendering-system
Melisha Dsouza
25 Feb 2019
2 min read
Save for later

BMW Volleys receives clearance to open-source RAMSES, a 3D rendering system

Melisha Dsouza
25 Feb 2019
2 min read
BMW has open-sourced its code to RAMSES ( Rendering Architecture for Multi-Screen EnvironmentS) under the GENIVI in-vehicle infotainment alliance. The code is under the Mozilla Public License 2.0 and will be useful to developers interested in distributed 3D rendering. RAMSES implements a distributed system for rendering 3D content with a focus on ensuring high performance in terms of bandwidth and resource consumption. According to KTelegram, RAMSES is designed to optimize the rendering of content from the entertainment systems, containing several screens. It is a layer that applies a client-server model for the rendering. One process generates the 3D content and the other process is engaged in its rendering. Rendering can be performed on another device or in a virtual environment.  RAMSES provides piping around existing OpenGL implementations and supports different versions of OpenGL (OpenGL ES 3.0+, OpenGL 4.2, 4.5, etc.) RAMSES also provides its own low-level API which encapsulates and packages the commands and resources to minimize traffic between the client and the server. This allows the transmission of high-quality 3D content over conventional networks for display, without delays and gaps. Google open sources Filament – a physically based rendering engine for Android, Windows, Linux and macOS Facebook releases DeepFocus, an AI-powered rendering system to make virtual reality more Real Meet Carlo, a web rendering surface for Node applications by the Google Chrome team
Read more
  • 0
  • 0
  • 2111
Visually different images

article-image-git-2-21-released-with-performance-improvement-multi-pack-indexes-enhanced-repositories-and-more
Amrata Joshi
25 Feb 2019
3 min read
Save for later

Git 2.21 released with performance improvement, multi-pack indexes, enhanced repositories and more

Amrata Joshi
25 Feb 2019
3 min read
Yesterday, the team at GitHub released Git 2.21 with a new date format, improved performance and bug fixes from over 60 contributors. What’s new in Git 2.21? Performance and internal implementation It is now possible to clean-up the code with optimization for the codepath that checks non-existence of loose objects. The "strncat()" function is now counted amongst the banned functions. This release comes with portability updates for the HPE NonStop platform. The loose object cache used for optimizing existence look-up has also been updated. The flaky tests can now be repeatedly run under load with the “--stress" option. Human-readable dates with --date=human This release comes with git log that displays the date for each authored commit. In this release, the timestamps will be displayed in Git’s “default” format (for example, “Tue Feb 12 09:00:33 2019 -0800”). Although Git 2.21 comes with a new date format --date=human which makes it possible to frequently switch between the human and machine-readable formats while putting together a pipeline. Multi-pack indexes Git 2.21 can create a multi-pack index file instead of repacking and this index file acts as a listing of objects residing in multiple packs while removing the need to perform expensive repacks. Delta reuse with bitmaps Git now comes with bitmaps and gives an optional on-disk data structure to record the sets of objects “reachable” from each commit. On the availability of this data, users can query it to quickly determine whether the client has a base object. This would result in server generating smaller packs that are produced more quickly for a faster experience. Enhanced repositories In Git 2.21, the repositories can now enumerate alternate tips, and make the corresponding transaction much faster. Major Fixes The corner cases in merge-recursive have been fixed. The Refspecs configured with "git -c var=val clone" which did not propagate to the resulting repository, have now been corrected. Now there is no need of configured username/email under user.useConfigOnly for creating commits. In this release, the http-backend CGI process now cleans up the child processes. Users seem to be excited about this release. One of the comments on HackerNews reads, “Few Detecting files that differ only in case being cloned onto a case-insensitive file system is a great feature.” To know more about this news, check out the release notes. GitHub launches draft pull requests GitHub increases its reward payout model for its bug bounty program GitLab considers moving to a single Rails codebase by combining the two existing repositories
Read more
  • 0
  • 0
  • 1840

article-image-qt-creator-4-9-beta-released-with-qml-support-programming-language-support-and-more
Amrata Joshi
22 Feb 2019
2 min read
Save for later

Qt Creator 4.9 Beta released with QML support, programming language support and more!

Amrata Joshi
22 Feb 2019
2 min read
The team at Qt has been coming with a lot of developments lately. This week, the Qt team released the Qt Design Studio 1.1 and yesterday the team announced the release of Qt Creator 4.9 Beta. What’s new in Qt Creator 4.9 Beta? Generic programming language support In this release, the team has added support for the document outline and for code actions, which allow the language server to suggest fixes or refactoring actions at a specified place in the code. The Qt highlighter is now based on the KSyntaxHighlighting library, which is the library used in KDE. Projects `Expand All` has been added to context menu. The `Close All Files in Project` action is now supported in this release. It’s now possible to close all the files of the project once the project is closed. C++ Support The UI for diagnostics from the Clang analyzer tools has been improved as they are grouped by file now. Diagnostics from the project’s headers files are also included. This release comes with a guard against applying Fix-its to files that have changed in the meantime. In the Clazy configuration, it is now possible to enable or disable individual checks. QML Support The QML parser has been updated to Qt 5.12. This release comes with an added support for ECMAScript 7. Support for Python This release comes with added project templates for Qt for Python. Nim Support The code completion has been added in this release based on NimSuggest. Profiling This release comes with Perf, which is a powerful performance profiling tool for software running on a Linux system. Operating systems For Windows, this release comes with an added support for MSVC 2019. On macOS, there is an added Touch Bar for running Qt Creator. For remote Linux targets, the Botan-based SSH backend has been exchanged by the use of OpenSSH tools. Major Fixes The dragging file from the `Projects` view has been fixed.   The crash on `Find Usages` has been fixed. To know more about this news, check out Qt’s official blog post. Qt Design Studio 1.1 released with Qt Photoshop bridge, updated timeline and more 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
Read more
  • 0
  • 0
  • 2483

article-image-gitlab-considers-moving-to-a-single-rails-codebase-by-combining-the-two-existing-repositories
Amrata Joshi
22 Feb 2019
4 min read
Save for later

GitLab considers moving to a single Rails codebase by combining the two existing repositories

Amrata Joshi
22 Feb 2019
4 min read
The team at GitLab is now considering to move towards a single Rails repository by combining the two existing repositories. Although the GitLab Community Edition code would remain open source and MIT licensed and also the GitLab Enterprise Edition code would remain source available and proprietary. The challenges with having two repositories? The Ruby on Rails code of GitLab is currently maintained in two repositories. The gitlab-ce repository for the code with an open source license and the gitlab-ee repository for code with a proprietary license which is source available. Having two similar but separate repositories, can make feature development difficult and error-prone while making any change in GitLab. To demonstrate the problem, the team at GitLab has given a few examples: Duplicated work during feature development The frontend only Merge Request needed a backport to CE repository. Backporting requires creating duplicate work in order to avoid future conflicts and changes to the code to support the feature. A simple change can break master A minor change in CE repository failed the pipeline in the master branch. Conflicts during preparation for regular releases There might be conflicts during preparation for a regular release, e.g. 11.7.5 release. Merge requests for both the CE repository and EE repository need to be created. And when the pipelines pass, the EE repository would require a merge from the CE repository. This would cause additional conflicts, pipeline failures, and similar delays during which the CE distribution release also would get delayed. Steps taken by GitLab team to improve the situation Before 2016, merging the CE repository into the EE repository was done when the team was ready to cut a release and the number of commits was small so it could be done by one person. As the number of commits between the two repositories grew in 2016, so the task got divided between seven developers who were responsible for merging the code once a day. This worked fine for some time until delays started happening due to failed specs or difficult merge conflicts. The team then merged an MR that allowed the creation of automated MRs between the two repositories by the end of 2017. This task ran every three hours, which allowed for a smaller number of commits to be worked on. The number of changes going into CE and EE repositories grew to thousands of commits in some cases by the end of 2018. This made the automated MR insufficient. The Merge Train tool was then created to automate these workflows further and which automatically rejected merge conflicts and preferred changes from one repository over the other. What is the GitLab team proposing? The gitlab-ce distribution package consists of gitlab-ce repository which offers only the Core feature set.  The gitlab-ee distribution package consists of gitlab-ee repository. The change which the team is considering proposing would be to merge the gitlab-ce and gitlab-ee repositories into a single gitlab repository. The design for merging two codebases requires the work and process changes in detail. Though the proposed change would pertain only to the Ruby on Rails repository. Expected changes The gitlab-ce and gitlab-ee repositories may be replaced with a gitlab repository, with all open issues and merge requests moved into the single repository. All frontend assets such as JavaScript, CSS, images, views will be open sourced under the MIT license. The proprietary backend code will be located in the /ee repository. All the documentation that will be merged together will now clearly state which features belong to which feature set. The downsides The GitLab team was clear about the possible downsides of this approach: Users with installations from the source are currently cloning the gitlab-ce repository. The clone will also fetch the proprietary code in /ee directory. The database migration code is open source and does not require additional maintenance so there is no additional work required. The team is now exploring better ways to solve the problem of busy work and plans to bring improvements to the current proposal. To know more about this news, check out the post by GitLab. Introducing GitLab Serverless to deploy cloud-agnostic serverless functions and applications GitLab 11.7 releases with multi-level child epics, API integration with Kubernetes, search filter box and more Why moving from a monolithic architecture to microservices is so hard, Gitlab’s Jason Plum breaks it down [KubeCon+CNC Talk]
Read more
  • 0
  • 0
  • 3070
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $15.99/month. Cancel anytime
article-image-ipython-7-3-releases-with-conda-and-pip-magics-and-python-3-8-compatibility
Bhagyashree R
22 Feb 2019
2 min read
Save for later

IPython 7.3 releases with %conda and %pip magics and Python 3.8 compatibility

Bhagyashree R
22 Feb 2019
2 min read
This Monday, Matthias Bussonnier, a core developer of the IPython and Jupyter Project team, announced the release of IPython 7.3. Along with some major bug fixes, this release comes with the %conda and %pip magics and compatibility with Python 3.8. The %conda and %pip magics IPython offers magic functions as an added enhancement on top of the Python syntax that is intended to solve common problems like data analysis using Python. The biggest update the team has introduced to this release is the implementation of the %conda and %pip magics. These magics will automatically install packages into the kernel that is currently running in an IPython or Jupyter notebook session. The %pip magic was already available, but it was limited to printing a warning and now, it will actually forward commands to pip. Users will still need to restart the interpreter or kernel for the newly installed packages to be taken into account. Though this update is great, users are recommended to use the conda/pip commands as their preferred way for installing. Bug fixes This release is compatible with Python 3.8, which comes with the addition of Assignment Expressions, better thread safety, and more. To opt out of shell variable expansion, the `@magic.no_var_expand` decorator is added to the execution magics. The behavior of the %reset magic has been changed by initializing the posix aliases `clear`, `less`, `more`, and `man` during a reset. IPython command line now will allow running *.ipynb files. To read more about the updates in IPython 7.3, check out its official announcement. IPython 7.2.0 is out! IPython 7.0 releases with AsyncIO Integration and new Async libraries PyPy 7.0 released for Python 2.7, 3.5, and 3.6 alpha
Read more
  • 0
  • 0
  • 3821

article-image-facebook-open-sources-sparta-to-simplify-abstract-interpretation
Natasha Mathur
21 Feb 2019
2 min read
Save for later

Facebook open sources SPARTA to simplify abstract interpretation

Natasha Mathur
21 Feb 2019
2 min read
Facebook announced yesterday that it’s making SPARTA, a  C++ library of software components that help build high-performance static analyzers, available as open-source yesterday. “This library is part of a broad, long-term vision to expand the use of abstract interpretation in our tools at Facebook. We are open-sourcing SPARTA to provide an industrial-scale abstract interpretation infrastructure for the broader static analysis community to use”, states the Facebook team. SPARTA is aimed at simplifying the engineering of Abstract Interpretation as its set of software components consist of a simple API. Since building an industrial-grade static analysis tool based on Abstract Interpretation from the very start is difficult, SPARTA is very beneficial.It’s also highly performant and can be assembled easily to build a production-quality static analyzer. Abstract Interpretation refers to a theory of semantic approximation that provides a foundational framework for the design of static program analyzers. SPARTA works by providing important data structures that are used in virtually every static analyzer. SPARTA encapsulates the complex implementation details of abstract interpretation and hence frees the developer to focus on the main fundamental axes in the design of an analysis. Other than that, all the static analyzers that are used in the ReDex code optimizer for Android are based on SPARTA’s library. These run on industrial-scale Android apps from Facebook and other large companies that have adopted ReDex.SPARTA makes it possible for these analyses to be expressed concisely and also guarantees high-level performance. Apart from the performance related benefits, SPARTA also makes it easier to write correct analyses. The algorithms and data structures implemented in SPARTA are also highly generic. It is language-independent; despite its use in ReDex, and contains no Android-specific logic. Also, its algorithms are capable of generalizing across different scopes of static analyses. “In the future, we could consider adding support for other features, including numerical abstractions or points-to analysis”, states the Facebook team. For more information, check out the official SPARTA blog post. Uber releases Ludwig, an open source AI toolkit that simplifies training deep learning models for non-experts Facebook open sources the ELF OpenGo project and retrains the model using reinforcement learning Google open sources ClusterFuzz, a scalable fuzzing tool
Read more
  • 0
  • 0
  • 2117

article-image-qt-design-studio-1-1-released-with-qt-photoshop-bridge-updated-timeline-and-more
Amrata Joshi
20 Feb 2019
3 min read
Save for later

Qt Design Studio 1.1 released with Qt Photoshop bridge, updated timeline and more

Amrata Joshi
20 Feb 2019
3 min read
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  
Read more
  • 0
  • 0
  • 2528

article-image-shazam-removes-third-party-sdks
Prasad Ramesh
20 Feb 2019
2 min read
Save for later

Shazam removes third-party SDKs

Prasad Ramesh
20 Feb 2019
2 min read
Shazam, the popular song-identifying app removed support for all third-party SDKs with one exception as reported by Appfigures blog. The removed SDKs were of ad networks, analytics trackers, etc. They were removed since these SDKs leaked data to third parties in some way. This is something that Apple is against and is following it on Shazam as they acquired it for $400M last September. The SDKs removed in the iOS update are: Admob Bolts Doubleclick FB ads FB analytics FB login Inmobi IAS Moat Mopub The only third party SDK retained is HockeyApp. Apple doesn't keep third-party SDKs in any of their apps except apple support. On Android, however, the following SDKs are still present for Shazam: Bolts FB analytics Butter knife Crashlytics Fabric Firebase Google maps Okhttp Otto Some users agree with the decision like this comment from Hacker news: “Makes sense, now that Apple owns them.” Another user shared his views on retaining the HockeyApp: “Makes sense to keep the HockeyApp integration as it is an amazing tool for crash analysis and they still need that. Integration with crash analytic is a different type of integration than facebook, advertisement and the other stuff (crap) they have removed.” Apple buys Shazam, and will soon make the app ad-free Apple acquires Pullstring to possibly help Apple improve Siri and other IoT-enabled gadgets China’s Huawei technologies accused of stealing Apple’s trade secrets, reports The Information
Read more
  • 0
  • 0
  • 1404
article-image-lazarus-released-with-lcl-interface-changes-ide-changes-and-much-more
Amrata Joshi
18 Feb 2019
2 min read
Save for later

Lazarus released with LCL interface changes, IDE changes and much more!

Amrata Joshi
18 Feb 2019
2 min read
Earlier this month, the team at Lazarus announced the release of Lazarus 2.0.0, an open-source cross-platform built with FPC 3.0.4 (Free Pascal Compiler). What’s new in Lazarus 2.0.0 LCL (Lazarus Component Library) Interface Changes ScreenToClient and ClientToScreen can now be calculated without scrollbar offset. Support for mouse wheel horz scrolling. This release comes with added flags to exclude support for some graphics formats to create smaller applications. The image list now supports multiple resolutions of one image. All the LCL controls now support High-DPI glyphs on Windows+Linux and Retina on Mac without any additional code. Every LCL control that supports ImageList now has a new ImagesWidth property for deciding what custom width at 96 PPI (100% scale) is to be used. IDE Changes This release includes several High-DPI IDE improvements and a retina support on Cocoa The IDE parses the custom compiler options for the fpc switch -FN<namespaces> for defining the default namespaces. Editor Lazarus 2.0.0 comes with "smart move cursor" moving commands for editor mappings. They are useful as an alternative for Ctrl+Left/+Right/+Shift+Left/+Shift+Right key. This release comes with added Goto/Toggle bookmark submenu for the toolbar. Additional options to fine-tune outline colors. Debugger This release comes with an added option "FixStackFrameForFpcAssert" to workaround fpc wrong frame pointer. There is an added option "FixIncorrectStepOver" to workaround "step over" issues experienced on some platforms. Components incompatibilities TSpinEditEx and TFloatSpinEditEx now inherit a common base class TSpinEditExBase. The reticule component is removed because the crosshair cursor is included in the more versatile charttools. To know more about this news, check out the Lazarus’ official post. Creating a Lazarus Component Microsoft joins the OpenChain Project to help define standards for open source software compliance Mapzen, an open-source mapping platform, joins the Linux Foundation project
Read more
  • 0
  • 0
  • 1849

article-image-cygwin-3-0-0-1-released
Prasad Ramesh
18 Feb 2019
3 min read
Save for later

Cygwin 3.0.0-1 released!

Prasad Ramesh
18 Feb 2019
3 min read
Last Saturday, Cygwin 3.0.0-1 was released. This major release brings support for new file systems, new tools, APIs and other changes. New features in Cygwin 3.0.0-1 Support is added for clocks like CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_RAW, CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM, CLOCK_BOOTTIME_ALARM. Case sensitive directories are now supported. Directories are created automatically by the mkdir(2) command within the Cygwin installation as case sensitive from this release. For this feature to work, you need Windows 10 1803 or later with Windows Subsystem for Linux (WSL) installed. There are two new file input output controls called FS_IOC_GETFLAGS and FS_IOC_SETFLAGS. The actual inode flags are Cygwin-specific. These flags allow setting or resetting the DOS attributes, file sparseness, FS level encryption, and compression. They can also be used for modifying case sensitivity programmatically. There are two new tools namely chattr(1) and lsattr(1) to utilize setting and viewing the new input output controls on the command line. Support for the following has been added: exFAT Linux-specific open(2) flag O_PATH Linux-specific linkat(2) flag AT_EMPTY_PATH. The counter for posix timers (via timer_getoverrun() or siginfo_t::si_overrun) are overrun now The following New APIs have been added: signalfd timerfd_create timerfd_gettime timerfd_settime timer_getoverrun. fork(2) now can now recover from a situation when an in-use executable/dll is removed or replaced during process runtime. This behavior is disabled by default and limited to EXE and DLL files on the same NTFS partition as Cygwin. Changes in Cygwin 3.0.0-1 clock_nanosleep, pthread_condattr_setclock and timer_create now support all clocks with the exception of CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID. clock_setres is a no-op in Cygwin 3.0.0-1. Renaming a file to another name of an in-use file deletes the other file now. Previously, it was moved to the recycle bin. You can use the new POSIX rename semantics on the NTFS starting with Windows 10 1809. Now, open(..., O_TMPFILE) moves the file to trash immediately in order to free the parent directory. The wctype functions are updated to Unicode 11.0. The matherr, SVID, and X/Open math library configurations are removed. IEEE is the default math library configuration now. uname(2) is improved for newly built applications. Kerberos/MSV1_0 S4U authentication replaces creating a token from scratch and Cygwin LSA authentication package. To know about bug fixes etc, you can keep up with the Cygwin mailing list. GitHub launches draft pull requests Introducing RustPython, a Python 3 interpreter written in Rust .NET Core 3 Preview 2 is here!
Read more
  • 0
  • 0
  • 2332

article-image-github-launches-draft-pull-requests
Amrata Joshi
15 Feb 2019
3 min read
Save for later

GitHub launches draft pull requests

Amrata Joshi
15 Feb 2019
3 min read
Yesterday, GitHub launched a new feature named draft pull requests, which allows users to start a pull request before they are done implementing all the code changes. Users can start a conversation with their collaborators once the code is ready. If a user ends up closing the pull request for some reason or is refactoring the code entirely, the pull request would work in collaboration. Also, if a user wants to signal a pull request to be the start of the conversation and the code isn’t ready, users can still let the people check it out locally and get feedback. The draft pull requests feature can tag users if they are still working on a PR and notify the team once it’s ready. This feature will also help the pull requests that are prematurely closed, or for times when users start working on a new feature and forget to send a PR. When a user opens a pull request, a drop-down arrow appears next to the ‘Create pull request’ button. Users can toggle the drop-down arrow for creating a draft. A draft pull request is differently styled for indicating that it is in a draft state. Users can change the status to ‘Ready for review’ near the bottom of the pull request for removing the draft state and allow merging according to the project’s settings. In case a user has ‘CODEOWNERS file’ in their repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review. Users have given mixed reviews to this news. According to a few users, this new feature will save up a lot of time. One of the users said, “It saves a lot of wasted effort by exploring the problem domain collaboratively before development begins.” While according to a few others this idea is not much effective. Another comment reads, “Someone suggested this on my team. I personally don’t like the idea because these policies often times lead to bureaucracy and then nothing getting released. It is not that I am against thinking ahead but if I have to in details explain everything I do, then more time is spent documenting than actually creating which is the part I enjoy.” To know more about this news, check out GitHub official post. Western Digital RISC-V SweRV Core is now on GitHub GitHub Octoverse: top machine learning packages, languages, and projects of 2018 Github wants to improve Open Source sustainability; invites maintainers to talk about their OSS challenges
Read more
  • 0
  • 0
  • 2304
article-image-go-1-12-release-candidate-1-is-here-with-improved-runtime-assembler-ports-and-more
Amrata Joshi
13 Feb 2019
3 min read
Save for later

Go 1.12 Release Candidate 1 is here with improved runtime, assembler, ports and more

Amrata Joshi
13 Feb 2019
3 min read
Yesterday, the team at Gophers released Go 1.12rc1, a release candidate version of Go 1.12. This release comes with improved runtime, updated libraries, ports and more. What’s new in Go 1.12rc1 Trace In Go 1.12rc1, the trace tool supports plotting mutator utilization curves, including cross-references to the execution trace. These are used to analyze the impact of the garbage collector on application latency and throughput. Assembler On arm64, the platform register was renamed from R18 to R18_PLATFORM to prevent accidental use, as the OS could choose to reserve this register. Runtime This release improves the performance of sweeping when a large fraction of the heap remains live. This reduces allocation latency following a garbage collection.The Go runtime now releases memory back to the operating system and particularly in response to large allocations that can't reuse existing heap space. In this release, the runtime’s timer and deadline code is faster and scales better with higher numbers of CPUs. It also improves the performance of manipulating network connection deadlines. Ports With this release, the race detector is now supported on linux/arm64. Go 1.12rc1 is supported on FreeBSD 10.x. Windows The new windows/arm port supports Go on Windows 10 IoT Core on 32-bit ARM chips such as the Raspberry Pi 3. AIX This release supports AIX 7.2 and later on POWER8 architectures (aix/ppc64). Though external linking, pprof, cgo, and the race detector aren't yet supported. Darwin This one is the last release to run on macOS 10.10 Yosemite, as Go 1.13 will need macOS 10.11 El Capitan or later. libSystem is now used while making syscalls on Darwin, which ensures forward-compatibility with future versions of macOS and iOS. This switch to libSystem has triggered additional App Store checks for private API usage. Tools The go tool vet is no longer supported. With this release, the go vet command has been rewritten to serve as the base for a range of different source code analysis tools. Even the external tools that use go tool vet must be changed to use go vet. Using go vet instead of go tool vet will work with all supported versions of Go. Even the experimental -shadow option is no longer available with go vet. Build cache requirement The build cache is now used for eliminating $GOPATH/pkg. With Go 1.12rc1, setting the environment variable GOCACHE=off will cause go commands to fail. Binary-only packages This one is the last release that will support binary-only packages. Cgo This release translates the C type EGLDisplay to the Go type uintptr. In this release, mangled C names are no longer accepted by the packages that use Cgo. The Cgo names are used now instead. Minor changes to the library Bufio: In this release, the reader's UnreadRune and UnreadByte methods will now return an error if they are called after Peek. Bytes: This release comes with a new function, ReplaceAll that returns a copy of a byte slice with all non-overlapping instances of a value replaced by another. To know more about this news, check out the official post. Introduction to Creational Patterns using Go Programming Go Programming Control Flow Essential Tools for Go Programming
Read more
  • 0
  • 0
  • 1686

article-image-pypy-7-0-released-for-python-2-7-3-5-and-3-6-alpha
Prasad Ramesh
12 Feb 2019
2 min read
Save for later

PyPy 7.0 released for Python 2.7, 3.5, and 3.6 alpha

Prasad Ramesh
12 Feb 2019
2 min read
Yesterday, PyPy 7.0 was announced in a blog post. It is a triple release for different Python versions. PyPy is a compliant Python interpreter which can be considered a replacement for CPython 2.7, 3.5, and 3.6. It’s faster due to the integrated tracing JIT compiler. The release supports x86 machines with common OSes, PPC64, and s390x running Linux. Since the ARM buildbots are out of service currently, binaries for ARM architecture will not be released. PyPy 7.0 includes the following interpreters. PyPy2.7 is an interpreter with support for syntax and features of Python 2.7 which will lose official support next year. PyPy3.5, supports the stable Python 3.5 PyPy3.6-alpha which is the first official PyPy release supporting 3.6 features. All of the three interpreters share a similar codebase allowing this triple release. Until packages can be distributed downstream, wheel (whl) packages are available for some common packages. GC hooks has been improved. It’s now possible to manage the GC by using a combination of gc.disable and gc.collect_step manually. The cffi module included in PyPy has been updated to version 1.12. The cppyy backend is also updated to version 1.4. For a JIT friendly experience, use the new versions to wrap your C and C++ code. PyPy 7.0 is fully compatible with the previous version. Several issues and bugs raised by the PyPy community have been addressed. PyPy3 and Windows PyPy3.5 releases are not yet up to quality to be used in production. There are open issues and the compatibility is not complete. The utf8 branch to change the internal representation of unicode to utf8 will be added in one of the future releases. Python Software foundation and JetBrains’ Python Developers Survey 2018 Python steering council election results are out for January 2019 Introducing RustPython, a Python 3 interpreter written in Rust
Read more
  • 0
  • 0
  • 2790