text:
[//]: # (title: What's new in Kotlin 1.4.0)

_[Released: 17 August 2020](releases.md#release-details)_

In Kotlin 1.4.0, we ship a number of improvements in all of its components, with the [focus on quality and performance](https://blog.jetbrains.com/kotlin/2020/08/kotlin-1-4-released-with-a-focus-on-quality-and-performance/).
Below you will find the list of the most important changes in Kotlin 1.4.0.

## Language features and improvements

Kotlin 1.4.0 comes with a variety of different language features and improvements. They include:

* [SAM conversions for Kotlin interfaces](#sam-conversions-for-kotlin-interfaces)
* [Explicit API mode for library authors](#explicit-api-mode-for-library-authors)
* [Mixing named and positional arguments](#mixing-named-and-positional-arguments)
* [Trailing comma](#trailing-comma)
* [Callable reference improvements](#callable-reference-improvements)
* [break and continue inside when included in loops](#using-break-and-continue-inside-when-expressions-included-in-loops)

### SAM conversions for Kotlin interfaces

Before Kotlin 1.4.0, you could apply SAM (Single Abstract Method) conversions only [when working with Java methods and Java
interfaces from Kotlin](java-interop.md#sam-conversions). From now on, you can use SAM conversions for Kotlin interfaces as well.
To do so, mark a Kotlin interface explicitly as functional with the `fun` modifier.

SAM conversion applies if you pass a lambda as an argument when an interface with only one single abstract method is expected
as a parameter. In this case, the compiler automatically converts the lambda to an instance of the class that implements the abstract member function.

```kotlin
fun interface IntPredicate {
    fun accept(i: Int): Boolean
}

val isEven = IntPredicate { it % 2 == 0 }

fun main() {
    println("Is 7 even? - ${isEven.accept(7)}")
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

[Learn more about Kotlin functional interfaces and SAM conversions](fun-interfaces.md).

### Explicit API mode for library authors

Kotlin compiler offers _explicit API mode_ for library authors. In this mode, the compiler performs additional checks that
help make the library's API clearer and more consistent. It adds the following requirements for declarations exposed
to the library's public API:

* Visibility modifiers are required for declarations if the default visibility exposes them to the public API.
This helps ensure that no declarations are exposed to the public API unintentionally.
* Explicit type specifications are required for properties and functions that are exposed to the public API.
This guarantees that API users are aware of the types of API members they use.

Depending on your configuration, these explicit APIs can produce errors (_strict_ mode) or warnings (_warning_ mode).
Certain kinds of declarations are excluded from such checks for the sake of readability and common sense:

* primary constructors
* properties of data classes
* property getters and setters
* `override` methods

Explicit API mode analyzes only the production sources of a module.

To compile your module in the explicit API mode, add the following lines to your Gradle build script:

<tabs group="build-script">
<tab title="Kotlin" group-key="kotlin">

```kotlin
kotlin {
    // for strict mode
    explicitApi()
    // or
    explicitApi = ExplicitApiMode.Strict

    // for warning mode
    explicitApiWarning()
    // or
    explicitApi = ExplicitApiMode.Warning
}
```

</tab>
<tab title="Groovy" group-key="groovy">

```groovy
kotlin {
    // for strict mode
    explicitApi()
    // or
    explicitApi = 'strict'

    // for warning mode
    explicitApiWarning()
    // or
    explicitApi = 'warning'
}
```

</tab>
</tabs>

When using the command-line compiler, switch to explicit API mode by adding  the `-Xexplicit-api` compiler option
with the value `strict` or `warning`.

```bash
-Xexplicit-api={strict|warning}
```

[Find more details about the explicit API mode in the KEEP](https://github.com/Kotlin/KEEP/blob/master/proposals/explicit-api-mode.md).

### Mixing named and positional arguments

In Kotlin 1.3, when you called a function with [named arguments](functions.md#named-arguments), you had to place all the
arguments without names (positional arguments) before the first named argument. For example, you could call `f(1, y = 2)`,
but you couldn't call `f(x = 1, 2)`.

It was really annoying when all the arguments were in their correct positions but you wanted to specify a name for one argument in the middle.
It was especially helpful for making absolutely clear which attribute a boolean or `null` value belongs to.

In Kotlin 1.4, there is no such limitation – you can now specify a name for an argument in the middle of a set of positional
arguments. Moreover, you can mix positional and named arguments any way you like, as long as they remain in the correct order.

```kotlin
fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Char = ' '
) {
    // ...
}

//Function call with a named argument in the middle
reformat("This is a String!", uppercaseFirstLetter = false , '-')
```

### Trailing comma

With Kotlin 1.4 you can now add a trailing comma in enumerations such as argument
and parameter lists, `when` entries, and components of destructuring declarations.
With a trailing comma, you can add new items and change their order without adding or removing commas.

This is especially helpful if you use multi-line syntax for parameters or values. After adding a trailing comma, you can
then easily swap lines with parameters or values.

```kotlin
fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Character = ' ', //trailing comma
) {
    // ...
}
```

```kotlin
val colors = listOf(
    "red",
    "green",
    "blue", //trailing comma
)
```

### Callable reference improvements

Kotlin 1.4 supports more cases for using callable references:

* References to functions with default argument values
* Function references in `Unit`-returning functions
* References that adapt based on the number of arguments in a function
* Suspend conversion on callable references

#### References to functions with default argument values

Now you can use callable references to functions with default argument values. If the callable reference
to the function `foo` takes no arguments, the default value `0` is used.

```kotlin
fun foo(i: Int = 0): String = "$i!"

fun apply(func: () -> String): String = func()

fun main() {
    println(apply(::foo))
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

Previously, you had to write additional overloads for the function `apply` to use the default argument values.

```kotlin
// some new overload
fun applyInt(func: (Int) -> String): String = func(0)
```

#### Function references in Unit-returning functions

In Kotlin 1.4, you can use callable references to functions returning any type in `Unit`-returning functions.
Before Kotlin 1.4, you could only use lambda arguments in this case. Now you can use both lambda arguments and callable references.

```kotlin
fun foo(f: () -> Unit) { }
fun returnsInt(): Int = 42

fun main() {
    foo { returnsInt() } // this was the only way to do it  before 1.4
    foo(::returnsInt) // starting from 1.4, this also works
}
```

#### References that adapt based on the number of arguments in a function

Now you can adapt callable references to functions when passing a variable number of arguments (`vararg`) .
You can pass any number of parameters of the same type at the end of the list of passed arguments.

```kotlin
fun foo(x: Int, vararg y: String) {}

fun use0(f: (Int) -> Unit) {}
fun use1(f: (Int, String) -> Unit) {}
fun use2(f: (Int, String, String) -> Unit) {}

fun test() {
    use0(::foo)
    use1(::foo)
    use2(::foo)
}
```

#### Suspend conversion on callable references

In addition to suspend conversion on lambdas, Kotlin now supports suspend conversion on callable references starting from version 1.4.0.

```kotlin
fun call() {}
fun takeSuspend(f: suspend () -> Unit) {}

fun test() {
    takeSuspend { call() } // OK before 1.4
    takeSuspend(::call) // In Kotlin 1.4, it also works
}
```

### Using break and continue inside when expressions included in loops

In Kotlin 1.3, you could not use unqualified `break` and `continue` inside `when` expressions included in loops. The reason was that these keywords were reserved for possible [fall-through behavior](https://en.wikipedia.org/wiki/Switch_statement#Fallthrough) in `when` expressions.

That's why if you wanted to use `break` and `continue` inside `when` expressions in loops, you had to [label](returns.md#break-and-continue-labels) them, which became rather cumbersome.

```kotlin
fun test(xs: List<Int>) {
    LOOP@for (x in xs) {
        when (x) {
            2 -> continue@LOOP
            17 -> break@LOOP
            else -> println(x)
        }
    }
}
```

In Kotlin 1.4, you can use `break` and `continue` without labels inside `when` expressions included in loops. They behave as expected by terminating the nearest enclosing loop or proceeding to its next step.

```kotlin
fun test(xs: List<Int>) {
    for (x in xs) {
        when (x) {
            2 -> continue
            17 -> break
            else -> println(x)
        }
    }
}
```

The fall-through behavior inside `when` is subject to further design.

## New tools in the IDE

With Kotlin 1.4, you can use the new tools in IntelliJ IDEA to simplify Kotlin development:

* [New flexible Project Wizard](#new-flexible-project-wizard)
* [Coroutine Debugger](#coroutine-debugger)

### New flexible Project Wizard

With the flexible new Kotlin Project Wizard, you have a place to easily create and configure different types of Kotlin
projects, including multiplatform projects, which can be difficult to configure without a UI.

![Kotlin Project Wizard – Multiplatform project](multiplatform-project-1-wn.png)

The new Kotlin Project Wizard is both simple and flexible:

1. *Select the project template*, depending on what you're trying to do. More templates will be added in the future.
2. *Select the build system* – Gradle (Kotlin or Groovy DSL), Maven, or IntelliJ IDEA.
    The Kotlin Project Wizard will only show the build systems supported on the selected project template.
3. *Preview the project structure* directly on the main screen.

Then you can finish creating your project or, optionally, *configure the project* on the next screen:

4. *Add/remove modules and targets* supported for this project template.
5. *Configure module and target settings*, for example, the target JVM version, target template, and test framework.

![Kotlin Project Wizard - Configure targets](multiplatform-project-2-wn.png)

In the future, we are going to make the Kotlin Project Wizard even more flexible by adding more configuration options and templates.

You can try out the new Kotlin Project Wizard by working through these tutorials:

* [Create a console application based on Kotlin/JVM](jvm-get-started.md)
* [Create a Kotlin/JS application for React](js-react.md)
* [Create a Kotlin/Native application](native-get-started.md)

### Coroutine Debugger

Many people already use [coroutines](coroutines-guide.md) for asynchronous programming.
But when it came to debugging, working with coroutines before Kotlin 1.4, could be a real pain. Since coroutines jumped between threads,
it was difficult to understand what a specific coroutine was doing and check its context. In some cases, tracking steps
over breakpoints simply didn't work. As a result, you had to rely on logging or mental effort to debug code that used coroutines.

In Kotlin 1.4, debugging coroutines is now much more convenient with the new functionality shipped with the Kotlin plugin.

> Debugging works for versions 1.3.8 or later of `kotlinx-coroutines-core`.
>
{type="note"}

The **Debug Tool Window** now contains a new **Coroutines** tab. In this tab, you can find information about both currently
running and suspended coroutines. The coroutines are grouped by the dispatcher they are running on.

![Debugging coroutines](coroutine-debugger-wn.png)

Now you can:
* Easily check the state of each coroutine.
* See the values of local and captured variables for both running and suspended coroutines.
* See a full coroutine creation stack, as well as a call stack inside the coroutine. The stack includes all frames with
variable values, even those that would be lost during standard debugging.

If you need a full report containing the state of each coroutine and its stack, right-click inside the **Coroutines** tab, and then
click **Get Coroutines Dump**. Currently, the coroutines dump is rather simple, but we're going to make it more readable
and helpful in future versions of Kotlin.

![Coroutines Dump](coroutines-dump-wn.png)

Learn more about debugging coroutines in [this blog post](https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-rc-debugging-coroutines/)
and [IntelliJ IDEA documentation](https://www.jetbrains.com/help/idea/debug-kotlin-coroutines.html).

## New compiler

The new Kotlin compiler is going to be really fast; it will unify all the supported platforms and provide
an API for compiler extensions. It's a long-term project, and we've already completed several steps in Kotlin 1.4.0:

* [New, more powerful type inference algorithm](#new-more-powerful-type-inference-algorithm) is enabled by default.
* [New JVM and JS IR backends](#unified-backends-and-extensibility). They will become the default once we stabilize them.

### New more powerful type inference algorithm

Kotlin 1.4 uses a new, more powerful type inference algorithm. This new algorithm was already available to try in
Kotlin 1.3 by specifying a compiler option, and now it's used by default. You can find the full list of issues fixed in
the new algorithm in [YouTrack](https://youtrack.jetbrains.com/issues/KT?q=Tag:%20fixed-in-new-inference%20). Here
you can find some of the most noticeable improvements:

* [More cases where type is inferred automatically](#more-cases-where-type-is-inferred-automatically)
* [Smart casts for a lambda's last expression](#smart-casts-for-a-lambda-s-last-expression)
* [Smart casts for callable references](#smart-casts-for-callable-references)
* [Better inference for delegated properties](#better-inference-for-delegated-properties)
* [SAM conversion for Java interfaces with different arguments](#sam-conversion-for-java-interfaces-with-different-arguments)
* [Java SAM interfaces in Kotlin](#java-sam-interfaces-in-kotlin)

#### More cases where type is inferred automatically

The new inference algorithm infers types for many cases where the old algorithm required you to specify them explicitly.
For instance, in the following example the type of the lambda parameter `it` is correctly inferred to `String?`:

```kotlin
//sampleStart
val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
    "weak" to { it != null },
    "medium" to { !it.isNullOrBlank() },
    "strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
)
//sampleEnd

fun main() {
    println(rulesMap.getValue("weak")("abc!"))
    println(rulesMap.getValue("strong")("abc"))
    println(rulesMap.getValue("strong")("abc!"))
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

In Kotlin 1.3, you needed to introduce an explicit lambda parameter or replace `to` with a `Pair` constructor with
explicit generic arguments to make it work.

#### Smart casts for a lambda's last expression

In Kotlin 1.3, the last expression inside a lambda wasn't  smart cast unless you specified the expected type. Thus, in the
following example, Kotlin 1.3 infers `String?` as the type of the `result` variable:

```kotlin
val result = run {
    var str = currentValue()
    if (str == null) {
        str = "test"
    }
    str // the Kotlin compiler knows that str is not null here
}
// The type of 'result' is String? in Kotlin 1.3 and String in Kotlin 1.4
```

In Kotlin 1.4, thanks to the new inference algorithm, the last expression inside a lambda gets smart cast, and this new,
more precise type is used to infer the resulting lambda type. Thus, the type of the `result` variable becomes `String`.

In Kotlin 1.3, you often needed to add explicit casts (either `!!` or type casts like `as String`) to make such cases work,
and now these casts have become unnecessary.

#### Smart casts for callable references

In Kotlin 1.3, you couldn't access a member reference of a smart cast type. Now in Kotlin 1.4 you can:

```kotlin
import kotlin.reflect.KFunction

sealed class Animal
class Cat : Animal() {
    fun meow() {
        println("meow")
    }
}

class Dog : Animal() {
    fun woof() {
        println("woof")
    }
}

//sampleStart
fun perform(animal: Animal) {
    val kFunction: KFunction<*> = when (animal) {
        is Cat -> animal::meow
        is Dog -> animal::woof
    }
    kFunction.call()
}
//sampleEnd

fun main() {
    perform(Cat())
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

You can use different member references `animal::meow` and `animal::woof` after the animal variable has been smart cast
to specific types `Cat` and `Dog`. After type checks, you can access member references corresponding to subtypes.

#### Better inference for delegated properties

The type of a delegated property wasn't taken into account while analyzing the delegate expression which follows the `by`
keyword. For instance, the following code didn't compile before, but now the compiler correctly infers the types of the
`old` and `new` parameters as `String?`:

```kotlin
import kotlin.properties.Delegates

fun main() {
    var prop: String? by Delegates.observable(null) { p, old, new ->
        println("$old → $new")
    }
    prop = "abc"
    prop = "xyz"
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

#### SAM conversion for Java interfaces with different arguments

Kotlin has supported SAM conversions for Java interfaces from the beginning, but there was one case that wasn't supported,
which was sometimes annoying when working with existing Java libraries. If you called a Java method that took two SAM interfaces
as parameters, both arguments needed to be either lambdas or regular objects. You couldn't pass one argument as a lambda and
another as an object.

The new algorithm fixes this issue, and you can pass a lambda instead of a SAM interface in any case,
which is the way you'd naturally expect it to work.

```java
// FILE: A.java
public class A {
    public static void foo(Runnable r1, Runnable r2) {}
}
```

```kotlin
// FILE: test.kt
fun test(r1: Runnable) {
    A.foo(r1) {}  // Works in Kotlin 1.4
}
```

#### Java SAM interfaces in Kotlin

In Kotlin 1.4, you can use Java SAM interfaces in Kotlin and apply SAM conversions to them.

```kotlin
import java.lang.Runnable

fun foo(r: Runnable) {}

fun test() {
    foo { } // OK
}
```

In Kotlin 1.3, you would have had to declare the function `foo` above in Java code to perform a SAM conversion.

### Unified backends and extensibility

In Kotlin, we have three backends that generate executables: Kotlin/JVM, Kotlin/JS, and Kotlin/Native. Kotlin/JVM and Kotlin/JS
don't share much code since they were developed independently of each other. Kotlin/Native is based on a new
infrastructure built around an intermediate representation (IR) for Kotlin code.

We are now migrating Kotlin/JVM and Kotlin/JS to the same IR. As a result, all three backends
share a lot of logic and have a unified pipeline. This allows us to implement most features, optimizations, and bug fixes
only once for all platforms. Both new IR-based back-ends are in [Alpha](components-stability.md).

A common backend infrastructure also opens the door for multiplatform compiler extensions. You will be able to plug into the
pipeline and add custom processing and transformations that will automatically work for all platforms.

We encourage you to use our new [JVM IR](#new-jvm-ir-backend) and [JS IR](#new-js-ir-backend) backends, which are currently in Alpha, and
share your feedback with us.

## Kotlin/JVM

Kotlin 1.4.0 includes a number of JVM-specific improvements, such as:

* [New JVM IR backend](#new-jvm-ir-backend)
* [New modes for generating default methods in interfaces](#new-modes-for-generating-default-methods)
* [Unified exception type for null checks](#unified-exception-type-for-null-checks)
* [Type annotations in the JVM bytecode](#type-annotations-in-the-jvm-bytecode)

### New JVM IR backend

Along with Kotlin/JS, we are migrating Kotlin/JVM to the [unified IR backend](#unified-backends-and-extensibility),
which allows us to implement most features and bug fixes once for all platforms. You will also be able to benefit from this
by creating multiplatform extensions that will work for all platforms.

Kotlin 1.4.0 does not provide a public API for such extensions yet, but we are working closely with our partners,
including [Jetpack Compose](https://developer.android.com/jetpack/compose), who are already building their compiler plugins
using our new backend.

We encourage you to try out the new Kotlin/JVM backend, which is currently in Alpha, and to file any issues and feature requests to our [issue tracker](https://youtrack.jetbrains.com/issues/KT).
This will help us to unify the compiler pipelines and bring compiler extensions like Jetpack Compose to the Kotlin community more quickly.

To enable the new JVM IR backend, specify an additional compiler option in your Gradle build script:

```kotlin
kotlinOptions.useIR = true
```

> If you [enable Jetpack Compose](https://developer.android.com/jetpack/compose/setup?hl=en), you will automatically be
> opted in to the new JVM backend without needing to specify the compiler option in `kotlinOptions`.
>
{type="note"}

When using the command-line compiler, add the compiler option `-Xuse-ir`.

> You can use code compiled by the new JVM IR backend only if you've enabled the new backend. Otherwise, you will get an error.
> Considering this, we don't recommend that library authors switch to the new backend in production.
>
{type="note"}

### New modes for generating default methods

When compiling Kotlin code to targets JVM 1.8 and above, you could compile non-abstract methods of Kotlin interfaces into
Java's `default` methods. For this purpose, there was a mechanism that includes the `@JvmDefault` annotation for marking
such methods and the `-Xjvm-default` compiler option that enables processing of this annotation.

In 1.4.0, we've added a new mode for generating default methods: `-Xjvm-default=all` compiles *all* non-abstract methods of Kotlin
interfaces to `default` Java methods. For compatibility with the code that uses the interfaces compiled without `default`,
we also added `all-compatibility` mode.

For more information about default methods in the Java interop, see the [interoperability documentation](java-to-kotlin-interop.md#default-methods-in-interfaces) and
[this blog post](https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-m3-generating-default-methods-in-interfaces/).

### Unified exception type for null checks

Starting from Kotlin 1.4.0, all runtime null checks will throw a `java.lang.NullPointerException` instead of `KotlinNullPointerException`,
`IllegalStateException`, `IllegalArgumentException`, and `TypeCastException`. This applies to: the `!!` operator, parameter
null checks in the method preamble, platform-typed expression null checks, and the `as` operator with a non-null type.
This doesn't apply to `lateinit` null checks and explicit library function calls like `checkNotNull` or `requireNotNull`.

This change increases the number of possible null check optimizations that can be performed either by the Kotlin compiler
or by various kinds of bytecode processing tools, such as the Android [R8 optimizer](https://developer.android.com/studio/build/shrink-code).

Note that from a developer's perspective, things won't change that much: the Kotlin code will throw exceptions with the
same error messages as before. The type of exception changes, but the information passed stays the same.

### Type annotations in the JVM bytecode

Kotlin can now generate type annotations in the JVM bytecode (target version 1.8+), so that they become available in Java reflection at runtime.
To emit the type annotation in the bytecode, follow these steps:

1. Make sure that your declared annotation has a proper annotation target (Java's `ElementType.TYPE_USE` or Kotlin's
`AnnotationTarget.TYPE`) and retention (`AnnotationRetention.RUNTIME`).
2. Compile the annotation class declaration to JVM bytecode target version 1.8+. You can specify it with `-jvm-target=1.8`
compiler option.
3. Compile the code that uses the annotation to JVM bytecode target version 1.8+ (`-jvm-target=1.8`) and add the
`-Xemit-jvm-type-annotations` compiler option.

Note that the type annotations from the standard library aren't emitted in the bytecode for now because the standard library is compiled
with the target version 1.6.

So far, only the basic cases are supported:

- Type annotations on method parameters, method return types and property types;
- Invariant projections of type arguments, such as `Smth<@Ann Foo>`, `Array<@Ann Foo>`.

In the following example, the `@Foo` annotation on the `String` type can be emitted to the bytecode and then used by the
library code:

```kotlin
@Target(AnnotationTarget.TYPE)
annotation class Foo

class A {
    fun foo(): @Foo String = "OK"
}
```

## Kotlin/JS

On the JS platform, Kotlin 1.4.0 provides the following improvements:

- [New Gradle DSL](#new-gradle-dsl)
- [New JS IR backend](#new-js-ir-backend)

### New Gradle DSL

The `kotlin.js` Gradle plugin comes with an adjusted Gradle DSL, which provides a number of new configuration options and is more closely aligned to the DSL used by the `kotlin-multiplatform` plugin. Some of the most impactful changes include:

- Explicit toggles for the creation of executable files via `binaries.executable()`. Read more about the [executing Kotlin/JS and its environment here](js-project-setup.md#execution-environments).
- Configuration of webpack's CSS and style loaders from within the Gradle configuration via `cssSupport`. Read more about [using CSS and style loaders here](js-project-setup.md#css).
- Improved management for npm dependencies, with mandatory version numbers or [semver](https://docs.npmjs.com/misc/semver#versions) version ranges, as well as support for _development_, _peer_, and _optional_ npm dependencies using `devNpm`, `optionalNpm` and `peerNpm`. [Read more about dependency management for npm packages directly from Gradle here](js-project-setup.md#npm-dependencies).
- Stronger integrations for [Dukat](https://github.com/Kotlin/dukat), the generator for Kotlin external declarations. External declarations can now be generated at build time, or can be manually generated via a Gradle task.

### New JS IR backend

The [IR backend for Kotlin/JS](js-ir-compiler.md), which currently has [Alpha](components-stability.md) stability, provides some new functionality specific to the Kotlin/JS target which is focused around the generated code size through dead code elimination, and improved interoperation with JavaScript and TypeScript, among others.

To enable the Kotlin/JS IR backend, set the key `kotlin.js.compiler=ir` in your `gradle.properties`, or pass the `IR` compiler type to the `js` function of your Gradle build script:

<!--suppress ALL -->

```groovy
kotlin {
    js(IR) { // or: LEGACY, BOTH
        // ...
    }
    binaries.executable()
}
```

For more detailed information about how to configure the new backend, check out the [Kotlin/JS IR compiler documentation](js-ir-compiler.md).

With the new [@JsExport](js-to-kotlin-interop.md#jsexport-annotation) annotation and the ability to **[generate TypeScript definitions](js-ir-compiler.md#preview-generation-of-typescript-declaration-files-d-ts) from Kotlin code**, the Kotlin/JS IR compiler backend improves JavaScript & TypeScript interoperability. This also makes it easier to integrate Kotlin/JS code with existing tooling, to create **hybrid applications** and leverage code-sharing functionality in multiplatform projects.

[Learn more about the available features in the Kotlin/JS IR compiler backend](js-ir-compiler.md).

## Kotlin/Native

In 1.4.0, Kotlin/Native got a significant number of new features and improvements, including:

* [Support for suspending functions in Swift and Objective-C](#support-for-kotlin-s-suspending-functions-in-swift-and-objective-c)
* [Objective-C generics support by default](#objective-c-generics-support-by-default)
* [Exception handling in Objective-C/Swift interop](#exception-handling-in-objective-c-swift-interop)
* [Generate release .dSYMs on Apple targets by default](#generate-release-dsyms-on-apple-targets-by-default)
* [Performance improvements](#performance-improvements)
* [Simplified management of CocoaPods dependencies](#simplified-management-of-cocoapods-dependencies)

### Support for Kotlin's suspending functions in Swift and Objective-C

In 1.4.0, we add the basic support for suspending functions in Swift and Objective-C. Now, when you compile a Kotlin module
into an Apple framework, suspending functions are available in it as functions with callbacks (`completionHandler` in
the Swift/Objective-C terminology). When you have such functions in the generated framework's header, you can call them
from your Swift or Objective-C code and even override them.

For example, if you write this Kotlin function:

```kotlin
suspend fun queryData(id: Int): String = ...
```

...then you can call it from Swift like so:

```swift
queryData(id: 17) { result, error in
   if let e = error {
       print("ERROR: \(e)")
   } else {
       print(result!)
   }
}
```

[Learn more about using suspending functions in Swift and Objective-C](native-objc-interop.md).

### Objective-C generics support by default

Previous versions of Kotlin provided experimental support for generics in Objective-C interop. Since 1.4.0, Kotlin/Native
generates Apple frameworks with generics from Kotlin code by default. In some cases, this may break existing Objective-C
or Swift code calling Kotlin frameworks. To have the framework header written without generics, add the `-Xno-objc-generics` compiler option.

```kotlin
kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xno-objc-generics"
        }
    }
}
```

Please note that all specifics and limitations listed in the [documentation on interoperability with Objective-C](native-objc-interop.md#generics) are still valid.

### Exception handling in Objective-C/Swift interop

In 1.4.0, we slightly change the Swift API generated from Kotlin with respect to the way exceptions are translated. There is
a fundamental difference in error handling between Kotlin and Swift. All Kotlin exceptions are unchecked, while Swift has
only checked errors. Thus, to make Swift code aware of expected exceptions, Kotlin functions should be marked with a `@Throws`
annotation specifying a list of potential exception classes.

When compiling to Swift or the Objective-C framework, functions that have or are inheriting `@Throws` annotation are represented
as `NSError*`-producing methods in Objective-C and as `throws` methods in Swift.

Previously, any exceptions other than `RuntimeException` and `Error` were propagated as `NSError`. Now this behavior changes:
now `NSError` is thrown only for exceptions that are instances of classes specified as parameters of `@Throws` annotation
(or their subclasses). Other Kotlin exceptions that reach Swift/Objective-C are considered unhandled and cause program termination.

### Generate release .dSYMs on Apple targets by default

Starting with 1.4.0, the Kotlin/Native compiler produces [debug symbol files](https://developer.apple.com/documentation/xcode/building_your_app_to_include_debugging_information)
(`.dSYM`s) for release binaries on Darwin platforms by default. This can be disabled with the `-Xadd-light-debug=disable`
compiler option. On other platforms, this option is disabled by default. To toggle this option in Gradle, use:

```kotlin
kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xadd-light-debug={enable|disable}"
        }
    }
}
```

[Learn more about crash report symbolication](native-ios-symbolication.md).

### Performance improvements

Kotlin/Native has received a number of performance improvements that speed up both the development process and execution.
Here are some examples:

- To improve the speed of object allocation, we now offer the [mimalloc](https://github.com/microsoft/mimalloc)
memory allocator as an alternative to the system allocator. mimalloc works up to two times faster on some benchmarks.
Currently, the usage of mimalloc in Kotlin/Native is experimental; you can switch to it using the `-Xallocator=mimalloc` compiler option.

- We've reworked how C interop libraries are built. With the new tooling, Kotlin/Native produces interop libraries up to
4 times as fast as before, and artifacts are 25% to 30% the size they used to be.

- Overall runtime performance has improved because of optimizations in GC. This improvement will be especially apparent
in projects with a large number of long-lived objects. `HashMap` and `HashSet` collections now work faster by escaping redundant boxing.

- In 1.3.70 we introduced two new features for improving the performance of Kotlin/Native compilation:
[caching project dependencies and running the compiler from the Gradle daemon](https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-3-70-released/#kotlin-native).
Since that time, we've managed to fix numerous issues and improve the overall stability of these features.

### Simplified management of CocoaPods dependencies

Previously, once you integrated your project with the dependency manager CocoaPods, you could build an iOS, macOS, watchOS,
or tvOS part of your project only in Xcode, separate from other parts of your multiplatform project. These other parts could
be built in IntelliJ IDEA.

Moreover, every time you added a dependency on an Objective-C library stored in CocoaPods (Pod library), you had to switch
from IntelliJ IDEA to Xcode, call `pod install`, and run the Xcode build there.

Now you can manage Pod dependencies right in IntelliJ IDEA while enjoying the benefits it provides for working with code,
such as code highlighting and completion. You can also build the whole Kotlin project with Gradle, without having to
switch to Xcode. This means you only have to go to Xcode when you need to write Swift/Objective-C code or run your application
on a simulator or device.

Now you can also work with Pod libraries stored locally.

Depending on your needs, you can add dependencies between:
* A Kotlin project and Pod libraries stored remotely in the CocoaPods repository or stored locally on your machine.
* A Kotlin Pod (Kotlin project used as a CocoaPods dependency) and an Xcode project with one or more targets.

Complete the initial configuration, and when you add a new dependency to `cocoapods`, just re-import the project in IntelliJ IDEA.
The new dependency will be added automatically. No additional steps are required.

[Learn how to add dependencies](native-cocoapods-libraries.md).

## Kotlin Multiplatform

> Support for multiplatform projects is in [Alpha](components-stability.md). It may change incompatibly and require manual migration in the future.
> We appreciate your feedback on it in [YouTrack](https://youtrack.jetbrains.com/issues/KT).
>
{type="warning"}

[Kotlin Multiplatform](multiplatform.md) reduces time spent writing and maintaining the same code for [different platforms](multiplatform-dsl-reference.md#targets)
while retaining the flexibility and benefits of native programming. We continue investing our effort in multiplatform features
and improvements:

* [Sharing code in several targets with the hierarchical project structure](#sharing-code-in-several-targets-with-the-hierarchical-project-structure)
* [Leveraging native libs in the hierarchical structure](#leveraging-native-libs-in-the-hierarchical-structure)
* [Specifying kotlinx dependencies only once](#specifying-dependencies-only-once)

> Multiplatform projects require Gradle 6.0 or later.
>
{type="note"}

### Sharing code in several targets with the hierarchical project structure

With the new hierarchical project structure support, you can share code among [several platforms](multiplatform-dsl-reference.md#targets)
 in a [multiplatform project](multiplatform-discover-project.md).

Previously, any code added to a multiplatform project could be placed either in a platform-specific source set, which is
limited to one target and can't be reused by any other platform, or in a common source set, like `commonMain` or `commonTest`,
which is shared across all the platforms in the project. In the common source set, you could only call a platform-specific
API by using an [`expect` declaration that needs platform-specific `actual` implementations](multiplatform-connect-to-apis.md).

This made it easy to [share code on all platforms](multiplatform-share-on-platforms.md#share-code-on-all-platforms), but it was
not so easy to [share between only some of the targets](multiplatform-share-on-platforms.md#share-code-on-similar-platforms),
especially similar ones that could potentially reuse a lot of the common logic and third-party APIs.

For example, in a typical multiplatform project targeting iOS, there are two iOS-related targets: one for iOS ARM64 devices,
and the other for the x64 simulator. They have separate platform-specific source sets, but in practice, there is rarely
a need for different code for the device and simulator, and their dependencies are much alike. So iOS-specific code could
be shared between them.

Apparently, in this setup, it would be desirable to have a *shared source set for two iOS targets*, with Kotlin/Native
code that could still directly call any of the APIs that are common to both the iOS device and the simulator.

![Code shared for iOS targets](iosmain-hierarchy.png){width=300}

Now you can do this with the [hierarchical project structure support](multiplatform-share-on-platforms.md#share-code-on-similar-platforms), which infers and adapts the API and language features
available in each source set based on which targets consume them.

For common combinations of targets, you can create a hierarchical structure with [target shortcuts](multiplatform-hierarchy.md#target-shortcuts).

For example, create two iOS targets and the shared source set shown above with the `ios()` shortcut:

```kotlin
kotlin {
    ios() // iOS device and simulator targets; iosMain and iosTest source sets
}
```

For other combinations of targets, [create a hierarchy manually](multiplatform-hierarchy.md#manual-configuration)
by connecting the source sets with the `dependsOn` relation.

![Hierarchical structure](manual-hierarchical-structure.png)

<tabs group="build-script">
<tab title="Kotlin" group-key="kotlin">

```kotlin
kotlin{
    sourceSets {
        val desktopMain by creating {
            dependsOn(commonMain)
        }
        val linuxX64Main by getting {
            dependsOn(desktopMain)
        }
        val mingwX64Main by getting {
            dependsOn(desktopMain)
        }
        val macosX64Main by getting {
            dependsOn(desktopMain)
        }
    }
}
```

</tab>
<tab title="Groovy" group-key="groovy">

```groovy
kotlin {
    sourceSets {
        desktopMain {
            dependsOn(commonMain)
        }
        linuxX64Main {
            dependsOn(desktopMain)
        }
        mingwX64Main {
            dependsOn(desktopMain)
        }
        macosX64Main {
            dependsOn(desktopMain)
        }
    }
}

```

</tab>
</tabs>

Thanks to the hierarchical project structure, libraries can also provide common APIs for a subset of targets. Learn more
about [sharing code in libraries](multiplatform-share-on-platforms.md#share-code-in-libraries).

### Leveraging native libs in the hierarchical structure

You can use platform-dependent libraries, such as Foundation, UIKit, and POSIX, in source sets shared among several
native targets. This can help you share more native code without being limited by platform-specific dependencies.

No additional steps are required – everything is done automatically. IntelliJ IDEA will help you detect common declarations
that you can use in the shared code.

[Learn more about usage of platform-dependent libraries](multiplatform-share-on-platforms.md#connect-platform-specific-libraries).

### Specifying dependencies only once

From now on, instead of specifying dependencies on different variants of the same library in shared and platform-specific
source sets where it is used, you should specify a dependency only once in the shared source set.

<tabs group="build-script">
<tab title="Kotlin" group-key="kotlin">

```kotlin
kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:%coroutinesVersion%")
            }
        }
    }
}
```

</tab>
<tab title="Groovy" group-key="groovy">

```groovy
kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:%coroutinesVersion%'
            }
        }
    }
}
```

</tab>
</tabs>

Don't use kotlinx library artifact names with suffixes specifying the platform, such as  `-common`, `-native`, or similar,
as they are NOT supported anymore. Instead, use the library base artifact name, which in the example above is `kotlinx-coroutines-core`.

However, the change doesn't currently affect:
* The `stdlib` library – starting from Kotlin 1.4.0, [the stdlib dependency is added automatically](#dependency-on-the-standard-library-added-by-default).
* The `kotlin.test` library – you should still use `test-common` and `test-annotations-common`. These dependencies will be
addressed later.

If you need a dependency only for a specific platform, you can still use platform-specific variants of standard and kotlinx
libraries with such suffixes as `-jvm` or` -js`, for example `kotlinx-coroutines-core-jvm`.

[Learn more about configuring dependencies](gradle-configure-project.md#configure-dependencies).

## Gradle project improvements

Besides Gradle project features and improvements that are specific to [Kotlin Multiplatform](#kotlin-multiplatform), [Kotlin/JVM](#kotlin-jvm),
[Kotlin/Native](#kotlin-native), and [Kotlin/JS](#kotlin-js), there are several changes applicable to all Kotlin Gradle projects:

* [Dependency on the standard library is now added by default](#dependency-on-the-standard-library-added-by-default)
* [Kotlin projects require a recent version of Gradle](#minimum-gradle-version-for-kotlin-projects)
* [Improved support for Kotlin Gradle DSL in the IDE](#improved-gradle-kts-support-in-the-ide)

### Dependency on the standard library added by default

You no longer need to declare a dependency on the `stdlib` library in any Kotlin Gradle project, including a multiplatform one.
The dependency is added by default.

The automatically added standard library will be the same version of the Kotlin Gradle plugin,
since they have the same versioning.

For platform-specific source sets, the corresponding platform-specific variant of the library is used, while a common standard
library is added to the rest. The Kotlin Gradle plugin will select the appropriate JVM standard library depending on
the `kotlinOptions.jvmTarget` [compiler option](gradle-compiler-options.md) of your Gradle build script.

[Learn how to change the default behavior](gradle-configure-project.md#dependency-on-the-standard-library).

### Minimum Gradle version for Kotlin projects

To enjoy the new features in your Kotlin projects, update Gradle to the [latest version](https://gradle.org/releases/).
Multiplatform projects require Gradle 6.0 or later, while other Kotlin projects work with Gradle 5.4 or later.

### Improved *.gradle.kts support in the IDE

In 1.4.0, we continued improving the IDE support for Gradle Kotlin DSL scripts (`*.gradle.kts` files). Here is what the new
version brings:

- _Explicit loading of script configurations_ for better performance. Previously, the changes you make to the build script
were loaded automatically in the background. To improve the performance, we've disabled the automatic loading of build script
configuration in 1.4.0. Now the IDE loads the changes only when you explicitly apply them.

  In Gradle versions earlier than 6.0, you need to manually load the script configuration by clicking **Load Configuration** in the editor.

  ![*.gradle.kts – Load Configuration](gradle-kts-load-config.png)

  In Gradle 6.0 and above, you can explicitly apply changes by clicking **Load Gradle Changes** or by reimporting the
Gradle project.

  We've added one more action in IntelliJ IDEA 2020.1 with Gradle 6.0 and above – **Load Script Configurations**, which loads changes
to the script configurations without updating the whole project. This takes much less time than reimporting the whole project.

  ![*.gradle.kts – Load Script Changes and Load Gradle Changes](gradle-kts.png)

  You should also **Load Script Configurations** for newly created scripts or when you open a project with new Kotlin plugin for the first time.

  With Gradle 6.0 and above, you are now able to load all scripts at once as opposed to the previous implementation where
  they were loaded individually. Since each request requires the Gradle configuration phase to be executed, this could be
  resource-intensive for large Gradle projects.

  Currently, such loading is limited to `build.gradle.kts` and `settings.gradle.kts` files (please vote for the related [issue](https://github.com/gradle/gradle/issues/12640)).
  To enable highlighting for `init.gradle.kts` or applied [script plugins](https://docs.gradle.org/current/userguide/plugins.html#sec:script_plugins),
  use the old mechanism – adding them to standalone scripts. Configuration for that scripts will be loaded separately when you need it.
  You can also enable auto-reload for such scripts.

  ![*.gradle.kts – Add to standalone scripts](gradle-kts-standalone.png)

- _Better error reporting_. Previously you could only see errors from the Gradle Daemon in separate log files. Now the
Gradle Daemon returns all the information about errors directly and shows it in the Build tool window. This saves you both
time and effort.

## Standard library

Here is the list of the most significant changes to the Kotlin standard library in 1.4.0:

- [Common exception processing API](#common-exception-processing-api)
- [New functions for arrays and collections](#new-functions-for-arrays-and-collections)
- [Functions for string manipulations](#functions-for-string-manipulations)
- [Bit operations](#bit-operations)
- [Delegated properties improvements](#delegated-properties-improvements)
- [Converting from KType to Java Type](#converting-from-ktype-to-java-type)
- [Proguard configurations for Kotlin reflection](#proguard-configurations-for-kotlin-reflection)
- [Improving the existing API](#improving-the-existing-api)
- [module-info descriptors for stdlib artifacts](#module-info-descriptors-for-stdlib-artifacts)
- [Deprecations](#deprecations)
- [Exclusion of the deprecated experimental coroutines](#exclusion-of-the-deprecated-experimental-coroutines)

### Common exception processing API

The following API elements have been moved to the common library:

* `Throwable.stackTraceToString()` extension function, which returns the detailed description of this throwable with its
stack trace, and `Throwable.printStackTrace()`, which prints this description to the standard error output.
* `Throwable.addSuppressed()` function, which lets you specify the exceptions that were suppressed in order to deliver
the exception, and the `Throwable.suppressedExceptions` property, which returns a list of all the suppressed exceptions.
* `@Throws` annotation, which lists exception types that will be checked when the function is compiled to a platform method
(on JVM or native platforms).

### New functions for arrays and collections

#### Collections

In 1.4.0, the standard library includes a number of useful functions for working with **collections**:

* `setOfNotNull()`, which makes a set consisting of all the non-null items among the provided arguments.

    ```kotlin
    fun main() {
    //sampleStart
        val set = setOfNotNull(null, 1, 2, 0, null)
        println(set)
    //sampleEnd
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `shuffled()` for sequences.

    ```kotlin
    fun main() {
    //sampleStart
        val numbers = (0 until 50).asSequence()
        val result = numbers.map { it * 2 }.shuffled().take(5)
        println(result.toList()) //five random even numbers below 100
    //sampleEnd
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `*Indexed()` counterparts for `onEach()` and `flatMap()`.
The operation that they apply to the collection elements has the element index as a parameter.

    ```kotlin
    fun main() {
    //sampleStart
        listOf("a", "b", "c", "d").onEachIndexed {
            index, item -> println(index.toString() + ":" + item)
        }

       val list = listOf("hello", "kot", "lin", "world")
              val kotlin = list.flatMapIndexed { index, item ->
                  if (index in 1..2) item.toList() else emptyList()
              }
    //sampleEnd
              println(kotlin)
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `*OrNull()` counterparts `randomOrNull()`, `reduceOrNull()`, and `reduceIndexedOrNull()`.
They return `null` on empty collections.

    ```kotlin
    fun main() {
    //sampleStart
         val empty = emptyList<Int>()
         empty.reduceOrNull { a, b -> a + b }
         //empty.reduce { a, b -> a + b } // Exception: Empty collection can't be reduced.
    //sampleEnd
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `runningFold()`, its synonym `scan()`, and `runningReduce()` apply the given operation to the collection elements sequentially,
 similarly to`fold()` and `reduce()`; the difference is that these new functions return the whole sequence of intermediate results.

    ```kotlin
    fun main() {
    //sampleStart
        val numbers = mutableListOf(0, 1, 2, 3, 4, 5)
        val runningReduceSum = numbers.runningReduce { sum, item -> sum + item }
        val runningFoldSum = numbers.runningFold(10) { sum, item -> sum + item }
    //sampleEnd
        println(runningReduceSum.toString())
        println(runningFoldSum.toString())
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `sumOf()` takes a selector function and returns a sum of its values for all elements of a collection.
`sumOf()` can produce sums of the types `Int`, `Long`, `Double`, `UInt`, and `ULong`. On the JVM, `BigInteger` and `BigDecimal` are also available.

    ```kotlin
    data class OrderItem(val name: String, val price: Double, val count: Int)

    fun main() {
    //sampleStart
        val order = listOf<OrderItem>(
            OrderItem("Cake", price = 10.0, count = 1),
            OrderItem("Coffee", price = 2.5, count = 3),
            OrderItem("Tea", price = 1.5, count = 2))

        val total = order.sumOf { it.price * it.count } // Double
        val count = order.sumOf { it.count } // Int
    //sampleEnd
        println("You've ordered $count items that cost $total in total")
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* The `min()` and `max()` functions have been renamed to `minOrNull()` and `maxOrNull()` to comply with the naming
  convention used across the Kotlin collections API. An `*OrNull` suffix in the function name means that it returns `null`
  if the receiver collection is empty. The same applies to `minBy()`, `maxBy()`, `minWith()`, `maxWith()` – in 1.4,
  they have `*OrNull()` synonyms.
* The new `minOf()` and `maxOf()` extension functions return the minimum and the maximum value of the given selector function
  on the collection items.

    ```kotlin
    data class OrderItem(val name: String, val price: Double, val count: Int)

    fun main() {
    //sampleStart
        val order = listOf<OrderItem>(
            OrderItem("Cake", price = 10.0, count = 1),
            OrderItem("Coffee", price = 2.5, count = 3),
            OrderItem("Tea", price = 1.5, count = 2))
        val highestPrice = order.maxOf { it.price }
    //sampleEnd
        println("The most expensive item in the order costs $highestPrice")
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

    There are also `minOfWith()` and `maxOfWith()`, which take a `Comparator` as an argument, and `*OrNull()` versions
of all four functions that return `null` on empty collections.

* New overloads for `flatMap` and `flatMapTo` let you use transformations with return types that don't match the receiver type, namely:
    * Transformations to `Sequence` on `Iterable`, `Array`, and `Map`
    * Transformations to `Iterable` on `Sequence`

    ```kotlin
    fun main() {
    //sampleStart
        val list = listOf("kot", "lin")
        val lettersList = list.flatMap { it.asSequence() }
        val lettersSeq = list.asSequence().flatMap { it.toList() }
    //sampleEnd
        println(lettersList)
        println(lettersSeq.toList())
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* `removeFirst()` and `removeLast()` shortcuts for removing elements from mutable lists, and `*orNull()` counterparts
of these functions.

#### Arrays

To provide a consistent experience when working with different container types, we've also added new functions for **arrays**:

* `shuffle()` puts the array elements in a random order.
* `onEach()` performs the given action on each array element and returns the array itself.
* `associateWith()` and `associateWithTo()` build maps with the array elements as keys.
* `reverse()` for array subranges reverses the order of the elements in the subrange.
* `sortDescending()` for array subranges sorts the elements in the subrange in descending order.
* `sort()` and `sortWith()` for array subranges are now available in the common library.

```kotlin
fun main() {
//sampleStart
    var language = ""
    val letters = arrayOf("k", "o", "t", "l", "i", "n")
    val fileExt = letters.onEach { language += it }
       .filterNot { it in "aeuio" }.take(2)
       .joinToString(prefix = ".", separator = "")
    println(language) // "kotlin"
    println(fileExt) // ".kt"

    letters.shuffle()
    letters.reverse(0, 3)
    letters.sortDescending(2, 5)
    println(letters.contentToString()) // [k, o, t, l, i, n]
//sampleEnd
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

Additionally, there are new functions for conversions between `CharArray`/`ByteArray` and `String`:
* `ByteArray.decodeToString()` and `String.encodeToByteArray()`
* `CharArray.concatToString()` and `String.toCharArray()`

```kotlin
fun main() {
//sampleStart
	val str = "kotlin"
    val array = str.toCharArray()
    println(array.concatToString())
//sampleEnd
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

#### ArrayDeque

We've also added the `ArrayDeque` class – an implementation of a double-ended queue.
A double-ended queue lets you add or remove elements both at the beginning or end of the queue in an amortized
constant time. You can use a double-ended queue by default when you need a queue or a stack in your code.

```kotlin
fun main() {
    val deque = ArrayDeque(listOf(1, 2, 3))

    deque.addFirst(0)
    deque.addLast(4)
    println(deque) // [0, 1, 2, 3, 4]

    println(deque.first()) // 0
    println(deque.last()) // 4

    deque.removeFirst()
    deque.removeLast()
    println(deque) // [1, 2, 3]
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

The `ArrayDeque` implementation uses a resizable array underneath: it stores the contents in a circular buffer, an `Array`,
and resizes this `Array` only when it becomes full.

### Functions for string manipulations

The standard library in 1.4.0 includes a number of improvements in the API for string manipulation:

* `StringBuilder` has useful new extension functions: `set()`, `setRange()`, `deleteAt()`, `deleteRange()`, `appendRange()`,
and others.

    ```kotlin
        fun main() {
        //sampleStart
            val sb = StringBuilder("Bye Kotlin 1.3.72")
            sb.deleteRange(0, 3)
            sb.insertRange(0, "Hello", 0 ,5)
            sb.set(15, '4')
            sb.setRange(17, 19, "0")
            print(sb.toString())
        //sampleEnd
        }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

* Some existing functions of `StringBuilder` are available in the common library. Among them are `append()`, `insert()`,
`substring()`, `setLength()`, and more.
* New functions `Appendable.appendLine()` and `StringBuilder.appendLine()` have been added to the common library. They
replace the JVM-only `appendln()` functions of these classes.

    ```kotlin
    fun main() {
    //sampleStart
        println(buildString {
            appendLine("Hello,")
            appendLine("world")
        })
    //sampleEnd
    }
    ```
    {kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

### Bit operations

New functions for bit manipulations:
* `countOneBits()`
* `countLeadingZeroBits()`
* `countTrailingZeroBits()`
* `takeHighestOneBit()`
* `takeLowestOneBit()`
* `rotateLeft()` and `rotateRight()` (experimental)

```kotlin
fun main() {
//sampleStart
    val number = "1010000".toInt(radix = 2)
    println(number.countOneBits())
    println(number.countTrailingZeroBits())
    println(number.takeHighestOneBit().toString(2))
//sampleEnd
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

### Delegated properties improvements

In 1.4.0, we have added new features to improve your experience with delegated properties in Kotlin:
- Now a property can be delegated to another property.
- A new interface `PropertyDelegateProvider` helps create delegate providers in a single declaration.
- `ReadWriteProperty` now extends `ReadOnlyProperty` so you can use both of them for read-only properties.

Aside from the new API, we've made some optimizations that reduce the resulting bytecode size. These optimizations are
described in [this blog post](https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/#delegated-properties).

[Learn more about delegated properties](delegated-properties.md).

### Converting from KType to Java Type

A new extension property `KType.javaType` (currently experimental) in the stdlib helps you obtain a `java.lang.reflect.Type`
from a Kotlin type without using the whole `kotlin-reflect` dependency.

```kotlin
import kotlin.reflect.javaType
import kotlin.reflect.typeOf

@OptIn(ExperimentalStdlibApi::class)
inline fun <reified T> accessReifiedTypeArg() {
   val kType = typeOf<T>()
   println("Kotlin type: $kType")
   println("Java type: ${kType.javaType}")
}

@OptIn(ExperimentalStdlibApi::class)
fun main() {
   accessReifiedTypeArg<String>()
   // Kotlin type: kotlin.String
   // Java type: class java.lang.String

   accessReifiedTypeArg<List<String>>()
   // Kotlin type: kotlin.collections.List<kotlin.String>
   // Java type: java.util.List<java.lang.String>
}
```
{kotlin-runnable="true" kotlin-min-compiler-version="1.4"}

### Proguard configurations for Kotlin reflection

Starting from 1.4.0, we have embedded Proguard/R8 configurations for Kotlin Reflection in `kotlin-reflect.jar`. With this
in place, most Android projects using R8 or Proguard should work with kotlin-reflect without needing any additional configuration.
You no longer need to copy-paste the Proguard rules for kotlin-reflect internals. But note that you still need to explicitly
list all the APIs you're going to reflect on.

### Improving the existing API

* Several functions now work on null receivers, for example:
    * `toBoolean()` on strings
    * `contentEquals()`, `contentHashcode()`, `contentToString()` on arrays

* `NaN`, `NEGATIVE_INFINITY`, and `POSITIVE_INFINITY` in `Double` and `Float` are now defined as `const`, so you can use
them as annotation arguments.

* New constants `SIZE_BITS` and `SIZE_BYTES` in `Double` and `Float` contain the number of bits and bytes used
to represent an instance of the type in binary form.

* The `maxOf()` and `minOf()` top-level functions can accept a variable number of arguments (`vararg`).

### module-info descriptors for stdlib artifacts

Kotlin 1.4.0 adds `module-info.java` module information to default standard library artifacts. This lets you use them with
[jlink tool](https://docs.oracle.com/en/java/javase/11/tools/jlink.html), which generates custom Java runtime images
containing only the platform modules that are required for your app.
You could already use jlink with Kotlin standard library artifacts, but you had to use separate artifacts to do so – the
ones with the "modular" classifier – and the whole setup wasn't straightforward.
In Android, make sure you use the Android Gradle plugin version 3.2 or higher, which can correctly process jar files with module-info.

### Deprecations

#### toShort() and toByte() of Double and Float

We've deprecated the functions `toShort()` and `toByte()` on `Double` and `Float` because they could lead to unexpected results
because of the narrow value range and smaller variable size.

To convert floating-point numbers to `Byte` or `Short`, use the two-step conversion: first, convert them to `Int`, and then
convert them again to the target type.

#### contains(), indexOf(), and lastIndexOf() on floating-point arrays

We've deprecated the `contains()`, `indexOf()`, and `lastIndexOf()` extension functions of `FloatArray` and `DoubleArray`
because they use the [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754) standard equality, which contradicts the total
order equality in some corner cases. See [this issue](https://youtrack.jetbrains.com/issue/KT-28753) for details.

#### min() and max() collection functions

We've deprecated the `min()` and `max()` collection functions in favor of `minOrNull()` and `maxOrNull()`, which more
properly reflect their behavior – returning `null` on empty collections.
See [this issue](https://youtrack.jetbrains.com/issue/KT-38854) for details.

### Exclusion of the deprecated experimental coroutines

The `kotlin.coroutines.experimental` API was deprecated in favor of kotlin.coroutines in 1.3.0. In 1.4.0, we're completing
the deprecation cycle for `kotlin.coroutines.experimental` by removing it from the standard library. For those who still
use it on the JVM, we've provided a compatibility artifact `kotlin-coroutines-experimental-compat.jar` with all the experimental
coroutines APIs. We've published it to Maven, and we include it in the Kotlin distribution alongside the standard library.

## Stable JSON serialization

With Kotlin 1.4.0, we are shipping the first stable version of [kotlinx.serialization](https://github.com/Kotlin/kotlinx.serialization) -
1.0.0-RC. Now we are pleased to declare the JSON serialization API in `kotlinx-serialization-core` (previously known as `kotlinx-serialization-runtime`)
stable. Libraries for other serialization formats remain experimental, along with some advanced parts of the core library.

We have significantly reworked the API for JSON serialization to make it more consistent and easier to use. From now on,
we'll continue developing the JSON serialization API in a backward-compatible manner.
However, if you have used previous versions of it, you'll need to rewrite some of your code when migrating to 1.0.0-RC.
To help you with this, we also offer the **[Kotlin Serialization Guide](https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/serialization-guide.md)** –
the complete set of documentation for `kotlinx.serialization`. It will guide you through the process of using the most
important features and it can help you address any issues that you might face.

>**Note**: `kotlinx-serialization` 1.0.0-RC only works with Kotlin compiler 1.4. Earlier compiler versions are not compatible.
>
{type="note"}

## Scripting and REPL

In 1.4.0, scripting in Kotlin benefits from a number of functional and performance improvements along with other updates.
Here are some of the key changes:

- [New dependencies resolution API](#new-dependencies-resolution-api)
- [New REPL API](#new-repl-api)
- [Compiled scripts cache](#compiled-scripts-cache)
- [Artifacts renaming](#artifacts-renaming)

To help you become more familiar with scripting in Kotlin, we've prepared a [project with examples](https://github.com/Kotlin/kotlin-script-examples).
It contains examples of the standard scripts (`*.main.kts`) and examples of uses of the Kotlin Scripting API and custom
script definitions. Please give it a try and share your feedback using our [issue tracker](https://youtrack.jetbrains.com/issues/KT).

### New dependencies resolution API

In 1.4.0, we've introduced a new API for resolving external dependencies (such as Maven artifacts), along with implementations
for it. This API is published in the new artifacts `kotlin-scripting-dependencies` and `kotlin-scripting-dependencies-maven`.
The previous dependency resolution functionality in `kotlin-script-util` library is now deprecated.

### New REPL API

The new experimental REPL API is now a part of the Kotlin Scripting API. There are also several implementations of it in
the published artifacts, and some have advanced functionality, such as code completion. We use this API in the
[Kotlin Jupyter kernel](https://blog.jetbrains.com/kotlin/2020/05/kotlin-kernel-for-jupyter-notebook-v0-8/)
and now you can try it in your own custom shells and REPLs.

### Compiled scripts cache

The Kotlin Scripting API now provides the ability to implement a compiled scripts cache, significantly speeding up subsequent
executions of unchanged scripts. Our default advanced script implementation `kotlin-main-kts` already has its own cache.

### Artifacts renaming

In order to avoid confusion about artifact names, we've renamed `kotlin-scripting-jsr223-embeddable` and `kotlin-scripting-jvm-host-embeddable`
to just `kotlin-scripting-jsr223` and `kotlin-scripting-jvm-host`. These artifacts depend on the `kotlin-compiler-embeddable`
artifact, which shades the bundled third-party libraries to avoid usage conflicts. With this renaming, we're making the usage of
`kotlin-compiler-embeddable` (which is safer in general) the default for scripting artifacts.
If, for some reason, you need artifacts that depend on the unshaded `kotlin-compiler`, use the artifact versions with the
`-unshaded` suffix, such as `kotlin-scripting-jsr223-unshaded`. Note that this renaming affects only the scripting artifacts
that are supposed to be used directly; names of other artifacts remain unchanged.

## Migrating to Kotlin 1.4.0

The Kotlin plugin's migration tools help you migrate your projects from earlier versions of Kotlin to 1.4.0.

Just change the Kotlin version to `1.4.0` and re-import your Gradle or Maven project. The IDE will then ask you about migration.

If you agree, it will run migration code inspections that will check your code and suggest corrections for anything that doesn't work
or that is not recommended in 1.4.0.

![Run migration](run-migration-wn.png){width=300}

Code inspections have different [severity levels](https://www.jetbrains.com/help/idea/configuring-inspection-severities.html),
to help you decide which suggestions to accept and which to ignore.

![Migration inspections](migration-inspection-wn.png)

Kotlin 1.4.0 is a [feature release](kotlin-evolution.md#feature-releases-and-incremental-releases) and therefore can
bring incompatible changes to the language. Find the detailed list of such changes in the **[Compatibility Guide for Kotlin 1.4](compatibility-guide-14.md)**.

<!-- ### Migrating multiplatform projects

To help you start using the new features of [Kotlin multiplatform](#kotlin-multiplatform) in existing projects, we
publish the TODO: [migration guide for multiplatform projects](multiplatform-hierarchy.md). -->

repository: JetBrains/kotlin-web-site

repo_name: JetBrains/kotlin-web-site


text:
## Bauxite

Bauxite is not only an ore but it's a small town caught between 2 rival school districts. Taylor lives in the rival school district. Many families have kids in both of these school districts so I thought instead of creating a Salt Bowl, I'd name this project after Bauxite which Reynolds Road cuts through while driving to Benton.

### Official Documentation

[Click here for the official documentation](https://github.com/illuminate3/bauxite)

### Laravel 5.6

Bauxite is built to work with 5.6.

### Introduction

Bauxite is a port of Laravel Boilerplate.
[![Latest Stable Version](https://poser.pugx.org/rappasoft/laravel-5-boilerplate/v/stable)](https://packagist.org/packages/rappasoft/laravel-5-boilerplate)

Bauxite adds a modular approach on top of what Laravel Boilerplate provides.

Laravel Boilerplate you with a massive head start on any size web application. It comes with a full featured access control system out of the box with an easy to learn API and is built on a Twitter Bootstrap foundation with a front and backend architecture. We have put a lot of work into it and we hope it serves you well and saves you time!

Anthony Rappa did a great job with Laravel Boilerplate but we wanted something that is module and would allow the ability to add modules. Obviously, if you don't link modules, I highly recommend to go with Boilerplate!

### Issues

If you come across any issues please [report them here](https://github.com/illuminate3/bauxite/issues).

### Contributing

if you want to contribute code, modules, or ideas  [please post them here](https://github.com/illuminate3/bauxite/issues).

### Security Vulnerabilities

If you come across any issues please [report them here](https://github.com/illuminate3/bauxite/issues) or reach out to us via our main page on github.

### License

MIT: [http://anthony.mit-license.org](http://anthony.mit-license.org)

MIT is awesome so fork, port or sell! If you do fork or port this code, please keep the history intact by giving Rappasoft a shout out! We wouldn't mind one too!

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
aop-sample-aspectj
==================

Sample AspectJ-based webapp for JBoss AS7.1.1

This is a sample web application to be deployed to JBoss AS7 for the purpose of evaluating different AOP libraries.  This is one of four AOP libraries/frameworks being evaluated:
- AspectJ
- SpringAOP
- Google Guice
- CDI

The web application for all four is a composed of a simple REST service that responds with a greeting.  It uses JBoss's built in jax-rs implementation - RestEasy, so additional configuration will be necessary if this is to be deployed on another application server, or servlet engine.

The AOP aspect is a simple method-interceptor that logs when the method is called and when it returns.

For this sample, you will need to set up a javaagent to run with your jvm.  The purpose of the javaagent is to perform load-time weaving (LTW) which applies the aspects to your class, when the class is loaded into the jvm.  Steps to set up LTW:
- download and install the latest stable release of AspectJ:
   http://www.eclipse.org/aspectj/downloads.php
- find the aspectjweaver.jar in the lib folder of AspectJ (that was just installed)
- Add a -javaagent argument to JBoss's standalone.conf:

JAVA_OPTS="$JAVA_OPTS -Dlog4j.debug -javaagent:/path/to/aspectj/home/lib/aspectjweaver.jar"

repository: logicpeters/dodecahelix

gha_language: Java

gha_license_id: MIT

repo_name: logicpeters/dodecahelix


text:
---
id: need_for_speed_bottom
---

Need 4 Speed is for every running level… even if you’ve never run before.

During a workout you will learn to run within your body so how you compare to other’s doesn’t matter. This is about teaching you to run correctly, efficiently, and safely.

If you’re more advanced, you’ll learn stride and posture improvements so you can run faster. Then you’ll be challenged with speed drills to unleash your new speed.

repository: wardpeet/gatsby-thistimefitness

repo_name: wardpeet/gatsby-thistimefitness


text:
## How delegation lookup works

Given the following registration:

```javascript
function divHandler(e) {
    e.preventDefault();
}
document.querySelector('div').addDelegateListener('click', 'a', divHandler);
```

and following HTML snippet:
```html
<body>
    <div>
        <a>
            <span>click me!</span>
        </a>
    </div>
</body>
```

If a `click` event is triggered on `<span>` the event propagates up to the `<div>` where the listener has been attached.

`event-delegation` will look from `event.target` (which is `<span>`) up to all parent elements until one matches the given `selector` (`a` in this case).

If none was found until the lookup process reaches the element on which event was originally attached to (`div` in this case) it stops and handler function is not triggered.

---

### Not matching example

```javascript
function divHandler(e) {
    e.preventDefault();
}
document.querySelector('div').addDelegateListener('click', '.myclass', divHandler);
```
applied to the following HTML snippet:
```html
<body>
    <section>
        <article>
            <div>
                <a>
                    <span>click me!</span>
                </a>
            </div>
        </article>
    </section>
</body>
```

If a `click` event is triggered on `<span>` the lookup process won't find any element matching with the given selector `.myclass`.

NOTICE that lookup will stops on `div` element, which is the one on which the listener is attached to, none of `div`'s parents will be considered and checked for matching.

**This improves performances and prevents any unwanted behaviour.**

gha_language: JavaScript


text:
# Primitive Hugo theme

## Usage

### Linking to pages by route name

The theme includes a shortcode, whick allows you to link to a page by using it's `route` parameter.

For a page:

```
---
title: "Route page"
date: 2018-12-08T06:22:26+01:00
route: "page-route"
---

This is a page.

```
Using

```
{{< linkto route="page-route" >}}
```

will render:

```
<a href="page.html">Route page</a>
```

or

```
{{< linkto route="bulgaria" title="My Page title">}}
```
will render:

```
<a href="page.html">My Page title</a>
```

## Installation

In your Hugo site `themes` directory, run:

```
$ git clone https://github.com/aquilax/primitive
```

Next, open `config.toml` in the base of the Hugo site and ensure the theme option is set to `primitive`.

```
theme = "primitive"
```

For more information read the official [setup guide](https://gohugo.io/getting-started/installing/) of Hugo.

## License

This theme is released under the [MIT license](https://github.com/aquilax/primitive/blob/master/LICENSE).


text:
face-audio-player
=================

Audio controls with your face

First crack at openFrameworks and using a multitude of addons hacked together a face tracking app that controls the audio playback volume and speed through your webcam and the position of the user's face on the screen.

position top    = speed audio playback up
position bottom = slow audio playback down
position right  = decrease volume
position left   = increase volume

Using the following addons
=================

https://github.com/micknoise/Maximilian
https://github.com/kylemcdonald/ofxCv ( face follow example )

repository: jshaw/face-audio-player

repo_name: jshaw/face-audio-player


text:
# IP2Currency

A Wordpress plugin to map client IP address to local currency

### Installation

1. Unpack the zip archive and place the folder ip2currency containing plugin source files, into the wordpress plugins directory.
2. Login as site admin
3. Activate the plugin

IP2Currency should now be installed

### Administration and usage

Once IP2Currency is activated you should see an admin page under Settings -> IP2Currency

On actvation one default price set is created for each product. This set of prices is used as default for the corresponding product in case
* the country of client IP is not set, and/or
* the country of client IP cannot be determined

These default rows cannot be deleted. However, they can be edited.

Also, while adding records, duplicate product and country combination is not permitted.

The prices set in this admin screen can be used in pages/posts using the following shortcode
```php
[ip2currency_get product_id=$product_id idx=$price_idx]
```
or using the following function in php templates
```php
ip2currency_get($product_id, $price_idx)
```
For, both the above `$product_id` and `$price_idx` start from 1.
`$product_id` takes values `1` and `2`, as it is setup for 2 products now.
`$price_idx` can take values `1,2,3,4` or `5` depending on which price record it is trying to get.

### Example
```php
[ip2currency_get_price product_id=1 idx=5]
```
gets Price5 for product '1 day course' in a post/page

and `<?php echo ip2currency_get_price(1,5) ?> ` gets the same price when used in a template.


text:
# Vulnerability roundup 107: git-2.31.1: 1 advisory [6.1]

[search](https://search.nix.gsc.io/?q=git&i=fosho&repos=NixOS-nixpkgs), [files](https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=git+in%3Apath&type=Code)

* [ ] [CVE-2021-21684](https://nvd.nist.gov/vuln/detail/CVE-2021-21684) CVSSv3=6.1 (nixos-21.05)

## CVE details

### CVE-2021-21684

Jenkins Git Plugin 4.8.2 and earlier does not escape the Git SHA-1 checksum parameters provided to commit notifications when displaying them in a build cause, resulting in a stored cross-site scripting (XSS) vulnerability.

-----
Scanned versions: nixos-21.05: 3b1789322fc.

Cc @globin
Cc @peti
Cc @primeos
Cc @wmertens

repository: ckauhaus/nixos-vulnerability-roundup

repo_name: ckauhaus/nixos-vulnerability-roundup


text:
---
verbs:
  - glance at
brief: Quickly look at something in your environment
see also:
  - look
actions:
  - scan:item:brief
syntaxes:
  - "<direct:object'thing>"
published: true
senses:
  - see
class: action
error: "Glance at what?"
---
This command allows you to see a brief description of something in the area around you.

repository: jgsmith/militerm

gha_language: Elixir

repo_name: jgsmith/militerm


text:
# Validator install files
The following files are copied over to validator machines and [validator_run](./validator_run.sh) is run.

The files are
*  [validator_run](./validator_run.sh) the one that does the install
*  [.bashrc](./.bashrc) setups up default paths
*  [terracli-server.service](./terracli-server.service) to start the LCD REST api for which the oracle will communicate to it with
*  [terrad.service](./terrad.service) the terrad service itself
*  [checksum.sh](./checksum.sh) [original](https://github.com/chainlayer/quicksync-playbooks/blob/master/roles/quicksync/files/checksum.sh) this set of scripts make use of the [quicksync](https://terra.quicksync.io/) service to speed up recovery
*  *.sum files are sha256sum files we download. we use this to verify their integrity

branch_name: refs/heads/main


text:
# Change Log

All notable changes to this project will be documented in this file.
See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.

## [0.1.2](https://github.com/reduxjs/redux-devtools/compare/slider-todomvc<EMAIL_ADDRESS>(2021-06-11)

**Note:** Version bump only for package slider-todomvc

## [0.1.1](https://github.com/reduxjs/redux-devtools/compare/slider-todomvc<EMAIL_ADDRESS>(2021-03-06)

**Note:** Version bump only for package slider-todomvc

# [0.1.0](https://github.com/reduxjs/redux-devtools/compare/slider-todomvc<EMAIL_ADDRESS>(2021-03-06)

### Features

- **redux-devtools-slider-monitor:** convert example to TypeScript ([#632](https://github.com/reduxjs/redux-devtools/issues/632)) ([ec75d3a](https://github.com/reduxjs/redux-devtools/commit/ec75d3a4b62d0f4b8d52a739a7727142421cc261))
- **redux-devtools-slider-monitor:** convert to TypeScript ([#631](https://github.com/reduxjs/redux-devtools/issues/631)) ([8991732](https://github.com/reduxjs/redux-devtools/commit/89917320e5ecf33dc3625b05daa1e9fe120a783d))

## [0.0.2](https://github.com/calesce/redux-slider-monitor/compare/slider-todomvc<EMAIL_ADDRESS>(2020-09-07)

**Note:** Version bump only for package slider-todomvc

## 0.0.1 (2020-08-14)

**Note:** Version bump only for package slider-todomvc

repository: MichaelDeBoey/redux-devtools

gha_language: TypeScript

repo_name: MichaelDeBoey/redux-devtools


text:
---
title: Arduino + Laser Tripwire + Camera
subtitle: Because who doesn't want a laser grid protecting their computer?
---
This project makes use of an Arduino and some fairly simple electronics to trigger a DSLR when a person breaks a laser beam. This laser beam is password-protected and can be enabled and disabled using an iPhone/iPod Touch web app. It's conceptually simple, and makes for really fun party games as well.

# The Laser

In my set up, I used several small mirrors to turn the single beam into a grid that covered a room.

{% include blogimage src="DSC_0885.jpg" caption="Laser beam reflected around a room." %}

The 5mw green laser is barely visible under normal conditions; the image above has a long exposure timing. The laser is turned on and off by the Arduino, and so this beam is not visible in photos. The laser is from a normal laser pointer, and looks like this:

{% include blogimage src="DSC_0902.jpg" caption="The laser pointer. It's held in a microphone clip mounted on a tiny tripod." %}

The laser pointer's button is held down by the clip, and the power supply to the laser is controlled using a relay. The detector The laser beam is detected by an LDR in a simple voltage divider circuit connected to the Arduino. The Arduino is configured to use an interrupt to process the voltage change - this will be described in detail a little further down. As the laser beam is scattered by the imperfections in the mirrors, it is first collected and focused onto the LDR using a fresnel lens. Here is a photo of the beam:

{% include blogimage src="DSC_0889.jpg" caption="Scattered laser beam" %}

And here is the beam collection set-up:

{% include blogimage src="DSC_0888.jpg" caption="Beam collection & detection" %}

Note the lens on the right. It is positioned to focus the incoming light onto the sensor. This saturates the LDR, allowing it's resistance to fall to around 300Î© (In complete darkness, it is around 30,000Î©). The circuit diagram is shown below (drawn in [fritzing](http://fritzing.org/)). Note that the LDR is in series with a 5kω of resistance, and that the voltage is being measured by digital input 2, not an analog input.

{% include blogimage src="vDivider_bb.png" caption="LDR voltage divider circuit to detect the laser beam" %}

The simple way of detecting if the light beam was interrupted would be to use the Arduino's built-in analog to digital converter and the handy [`analogRead()`](http://arduino.cc/en/Reference/analogRead) function to determine the potential across the LDR and use that to calculate the intensity of the incident light. The problem with this is that it's slow (100Î¼s per read) and it requires constant polling, which prevents it from doing anything else (strictly speaking, this is not true, but at best the polling frequency would suffer.)

By connecting it to digital pin 2, we can use the Arduino's external interrupt pin to call a function when the voltage rises from LOW to HIGH. Instead of setting a voltage threshold (as we would do in the simple method), we set the sensitivity of the trigger in hardware - by changing the resistance from +5v to the LDR, we can adjust the threshold intensity of light.

# The Camera Trigger

The camera trigger is a modified Yongnuo ML-L3 clone (available on eBay) that has additional female header pins soldered onto the button contacts. The remote's board has holes drilled in a convenient position. Modifying it is simple - just use a screwdriver to pry off the top sticker, solder on the female headers, cut the sticker and paste it back. The original button remains fully functional.

{% include blogimage src="DSC_0897-copy.jpg" caption="Camera Trigger" %}

An [optoisolator](http://en.wikipedia.org/wiki/Opto-isolator) is used (with the two headers connected across the phototransistor end) to trigger the shutter.

# The Laser & The Buzzer

Connecting these two is very easy - the buzzer is controlled using a transistor (I used the MPS-2222A, a small NPN transistor), and the laser is controlled using a relay, which is in turn controlled by a transistor.

The only caveat is that the laser diode expects a 3V power supply, and so the relay is connected to the Arduino's 3V output. Ideally, the laser would have its own power circuit and surge protection and it would be connected to an independent power supply. The photo of the breadboarded circuit may be helpful:

{% include blogimage src="DSC_0897.jpg" caption="The circuit on a breadboard" %}

Note the shroud for the LDR on the bottom left of the image. It's cut from a sheet of black paper, and it allows you to greatly increase the sensitivity of the circuit.

# The Code

The code is split up into three sections: An iPhone web app, a Python server running on a computer and finally the Arduino code. In the current version of the software, users can enable and disable the laser beam remotely using a very simple interface:

{% include blogimage src="photo.png" caption="iPhone/iPod Touch app." %}

The code is simple and commented, and can be downloaded [here](/download/Laser_grid_code-gauravmanek.com_.zip).

branch_name: refs/heads/production


text:
Sellsy-api-bundle
=================

Symfony bundle for [mehdi-ghezal/sellsy-api](https://github.com/mehdi-ghezal/sellsy-api) ; a PHP Wrapper for [Sellsy API](https://www.sellsy.fr/)

Status
------

This is a development version, not complete and not fully test. you can improve it for your need.
Of course, all pull request or issue report are welcome.

Documentation
-------------

The source of the documentation is stored in the `Resources/doc/` folder in this bundle

Installation
------------

All the installation instructions are located in the documentation.

License
-------

This bundle is under the MIT license.

repository: mehdi-ghezal/sellsy-api-bundle

repo_name: mehdi-ghezal/sellsy-api-bundle


text:
Getting started with Mutex Library
===================================

1) Installation
----------------------------------

The first step is to tell composer that you want to download Mutex which can
be achieved by entering the following line at the command prompt:

```bash
    $ php composer.phar require amf/mutex: ~1.0
```

> ***Note*** This command requires you to have Composer installed globally, as explained
in the [installation chapter](https://getcomposer.org/doc/00-intro.md)
of the Composer documentation.

After the download of the files is achieved:

repository: fattouchsquall/AMFMutex

branch_name: refs/heads/develop

gha_language: PHP

repo_name: fattouchsquall/AMFMutex


text:
# Repair & Conquer

## Folders

### src/

src/ is the folder for the phaser3 client source code.

### server/

server/ is meant for the server code which will reside on the server.
Its non-phaser3 code.

to start the server locally ma server/

## Available Commands

| Command | Description |
|---------|-------------|
| `npm install` | Install project dependencies |
| `npm start` | Build project and open web server running project |
| `nodejs server/server.js` | starts the needed server |

## Deploy for everyone

use the following tool to deploy: http://pionlib.de/game/index.php


text:
Pattern: Use of `[ 1 ]` instead of `true`

Issue: -

## Description

This is a stylistic suggestion to use `true` instead of `[ 1 ]`.

`[ 1 ]` seems to suggest that the value "1" is somehow relevant to the statement. This is not the case: it doesn't matter. You can replace it with `[ 0 ]` or `[ wombat ]`, and it will still always be true.

If you instead use `true`, the value is actually considered and can be inverted by replacing with `false`.

On bash, you can also use `(( 1 ))`, which evaluates to true much like in C. `(( 0 ))` is similarly false.

Example of **incorrect** code:

```sh
while [ 1 ]
do
  echo "infinite loop"
done
```

Example of **correct** code:

```sh
while true
do
  echo "infinite loop"
done
```

## Further Reading

* [ShellCheck - SC2161](https://github.com/koalaman/shellcheck/wiki/SC2161)

repository: Adroiti/docs-for-code-review-tools

repo_name: Adroiti/docs-for-code-review-tools


text:
---
layout: feature
title: 'Evident'
shortdef: 'Evidential'
udver: '2'
---

  Values:
  IPast
  RPast

`Case`

### `Nfh`: Non-firsthand

It is used to signal that the utterer of the sentence has not witnessed the event, but heard from it.

#### Examples

* _ _ “”

### `Fh`: Firsthand

It is used to signal that an event has been witnessed by the utterer of the sentence.

#### Examples

* _ _ “”

## Diffs

### Prague Dependency Treebank

The PDT tagset does not distinguish `Ptan` from `Plur` and `Coll` from `Sing`,
therefore this distinction is not being made in the converted data.

repository: UniversalDependencies/docs

branch_name: refs/heads/pages-source

gha_language: HTML

repo_name: UniversalDependencies/docs


text:
# nearby-pp
Color Connections to control a 12V RGB LED Strip

RaspberryPi3 Setup
![RaspberryPi3 Setup](pi/sketch.png "RaspberryPi3 Setup")

repository: holgi-s/nearby-pp

repo_name: holgi-s/nearby-pp


text:
# SNDMakes, Team Trinidad: Birdseye

### Table of contents

**What's in the repo (so far):**

-  **[Features list](https://github.com/TylerFisher/trinidad/blob/master/project%20planning/features.md):** Outlining the must-have and nice-to-have features for the prototype.
-  **[Basic XMP Parser](https://github.com/TylerFisher/trinidad/blob/master/images/parse_image.py):** Parsing the XMP data stored in an image file and writing it to a Python dict.
-  **[Sketches](https://github.com/TylerFisher/trinidad/tree/master/project%20planning/sketches):** From our initial wireframing.
-  **[Mockups](https://github.com/TylerFisher/trinidad/tree/master/project%20planning/mockups):** Planning layout and design.
-  **[Template](https://github.com/TylerFisher/trinidad/tree/master/template):** An early prototype built off of the [NPR App Template](http://github.com/nprapps/app-template). Follow the README in that folder to install the project.

### What is this
![Bird's Eye logo](/logo-final2.png "Bird's Eye logo")

A living, sortable contact sheet that shows the whole story.

Bird's Eye is a prototype built during [SNDMakes](http://www.snd.org/author/sndmakes/) in Washington, D.C. (April 2015). See the final presentation [here](https://docs.google.com/presentation/d/1_e6NVZNXBLZdGZdGOQ3cfS1qesOkiKHaydZxr9FrkVs/edit#slide=id.gad8bc852e_1_33).

### Who are we?

- [Tyler Fisher](http://twitter.com/tylrfishr)
- [Michael Grant](http://twitter.com/mikegrantme)
- [Kaeti Hinck](http://twitter.com/kaeti)
- [Kevin Koehler](http://twitter.com/kev097)
- [Kainaz Amaria](http://twitter.com/kainazamaria)

### The idea

**How might we allow readers to curate their own picture stories?**
Using the concept of a photoroll, our prototype will allow a user to view a large set of photos and filter based on tags like color, emotion, location, and more.

Editors can indicate featured images that will be called out in the interface more prominently than the smaller series of pictures. The user can click or press to expand any of the images.

Our hope is that showing a large set of photos will provide important context and location awareness, and allow users to immerse themselves into an event.

### Inspiration

- The iPhone photoroll interface
- [The Whale Hunt](http://thewhalehunt.org/)

### License

This repo is licensed under an MIT license. You are free to share and to remix this project (as long as you credit us).

### Suggestions

We welcome contributions and suggestions to help us improve any of these documents.

To contribute your changes:

1.  [Fork this repo](https://help.github.com/articles/fork-a-repo)
2.  Create a branch (git checkout -b my-branch)
3.    Push the changes to your fork (git push origin my-branch)
5.  [Submit a pull request to the parent repo](https://help.github.com/articles/creating-a-pull-request)

repository: TylerFisher/birdseye

repo_name: TylerFisher/birdseye


text:
---
title: Actix Web
layout: page
exclude: true
---

To **install actix-web** you need the dependencies: `actix-web` and `actix-rt`.
```
[dependencies]
actix-web = "2.0"
actix-rt = "1.0"
```

<!--stackedit_data:
eyJoaXN0b3J5IjpbLTE3MTgxOTcyMDBdfQ==
-->


text:
# Accelerate

Collection of different Rails Application templates to bootstrap new projects.

Inspired by [thoughtbot/suspenders](https://github.com/thoughtbot/suspenders) but not a gem.

## Usage

Make sure you have rails installed to run `rails new`.

    gem install rails

To use the `rails-base` template, run

    rails new project_name -m https://github.com/BiteKollektiv/accelerate/raw/master/rails-base/rails-base.rb

By default this will create a new git repository and a functional Rails Application.

There might be some dependencies missing, depending on your system.

## Gemfile

Application gems

 * [jQuery Rails](https://github.com/rails/jquery-rails) for jQuery
 * [Postgres](https://github.com/ged/ruby-pg) for access to the Postgres database
 * [Unicorn](http://unicorn.bogomips.org/) to serve HTTP requests
 * [Rails 12 Factor](https://github.com/heroku/rails_12factor) to make running Rails 4 apps easier on Heroku
 * [rails-i18n](https://github.com/svenfuchs/rails-i18n) to manage locales

Development gems

 * [Dotenv](https://github.com/bkeepers/dotenv) for loading environment variables
 * [Pry Rails](https://github.com/rweng/pry-rails) for debugging
 * [Spring](https://github.com/rails/spring) for fast Rails actions via pre-loading

Testing gems

 * [Capybara](https://github.com/jnicklas/capybara) for integration testing
 * [Factory Girl](https://github.com/thoughtbot/factory_girl) for test data
 * [RSpec](https://github.com/rspec/rspec) for unit testing
 * [Shoulda Matchers](https://github.com/thoughtbot/shoulda-matchers) for common RSpec matchers

## More stuff

 * Rails' flashes set up and in application layout
 * A few nice time formats set up for localization
 * [Rack::Deflater](https://github.com/rack/rack/blob/master/lib/rack/deflater.rb) to compress responses with Gzip
 * [Fast-failing factories](https://github.com/thoughtbot/factory_girl/commit/6a692fe711a43f3654480190af3110533786c29b)

Just like Suspenders, Accelerate fixes several of Rails' insecure defaults:

 * Accelerate uses Unicorn instead of WEBrick, allowing less verbose Server headers.
 * Accelerate is configured to pull your application secret key base from an environment variable, which means you won't need to risk placing it in version control.

repository: BiteKollektiv/accelerate

repo_name: BiteKollektiv/accelerate


text:
# tcpbin(1): TCP/UDP Request & Response Service [![Build Status](https://travis-ci.org/Kong/tcpbin.svg)](https://travis-ci.org/Kong/tcpbin)

Created and maintained by [Kong](https://konghq.com)

# FEATURES

Feature  | Description
------------- | -------------
TCP echo  | Echoes any request sent to **<IP_ADDRESS>:30000**
TCP info  | Get request info at **<IP_ADDRESS>:30001**
UDP echo  | Echoes any request sent to **<IP_ADDRESS>:40000**
UDP info  | Get request info at **<IP_ADDRESS>:40001**

# DESCRIPTION

This project has been started to help testing TCP and UDP requests in a very easy way. It is very useful for seeing what your clients are sending to TCP/UDP servers and debug problems. It can also be used for mock integration tests.

# EXAMPLES

### $ echo "Text to send to TCP" | ncat <IP_ADDRESS> 30000

```
Text to send to TCP
```

### $ echo "Get some TCP info" | ncat <IP_ADDRESS> 30001

```json
{
  "client-ip": "::ffff:<IP_ADDRESS>",
  "data": [71,101,116,32,115,111,109,101,32,84,67,80,32,105,110,102,111,10],
  "text-data": "Get some TCP info\n",
  "size": 18
}
```

### $ echo -n "Text to send to UDP" | nc -4u -w1 <IP_ADDRESS> 40000

```
Text to send to UDP
```

### $ echo -n "Get some UDP info" | nc -4u -w1 <IP_ADDRESS> 40001

```json
{
  "client-ip": "::ffff:<IP_ADDRESS>",
  "data": [71,101,116,32,115,111,109,101,32,85,68,80,32,105,110,102,111],
  "text-data": "Get some UDP info",
  "size": 17
}
```

# AUTHOR

A [Kong](https://konghq.com) project.

# SEE ALSO

[Mockbin.com](https://www.mockbin.com/) - Mock, Test & Track HTTP calls

[Apiembed.com](https://www.apiembed.com/) - Embeddable API Code snippets

[Konghq.com](https://konghq.com/) - The Cloud-Native API Gateway & Service Mesh

repository: narate/tcpbin

repo_name: narate/tcpbin


text:
# Crime Maps Project by Anant Joshi
This repository contains the source code for the Crime Maps Project website (www.thecrimemapsproject.com) and it contains the R scripts that were used to create the visualizations shown at the site.

****UPDATE****
Site is no longer live. The code for the visualizations can still be found within the repo.

This source code has been released under the Apache 2.0 license. More information can be found in the license.txt file.

repository: AnantJoshiCZ/Crime-Maps-Project

repo_name: AnantJoshiCZ/Crime-Maps-Project


text:
---
layout: page
title: About
permalink: /about/
---

Android security is a topic of great interest to me and the dynamic instrumentation toolkit [Frida](https://frida.re) is an interesting tool that I've been wanting to learn more about. A good way to learn new tools is to actually use them, another is to teach others how to use them. On this blog I combine the two approaches by using Frida to solve various reverse engineering challenges and similar and writing about how I solve them.

I'm working on a Windows computer, but what I do should be fairly similar on other operating systems as well. When I started this journey I had no experience at all with Frida. So even if you are completely new to Frida you should hopefully be able to follow along.

When you are ready, start your journey by [installing Frida]({{ site.baseurl }}{% post_url 2020-05-15-installing-frida %}).

repository: affilares/learning-frida

extension: markdown

repo_name: affilares/learning-frida