Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix typos #984

Merged
merged 1 commit into from
Sep 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ We have two ways to represent data with Explorer:
permitted in series of any dtype.

- using a dataframe, that is just a way to represent one or more series together,
and work with them as a whole. The only restriction is that all the series shares
and work with them as a whole. The only restriction is that all the series share
the same size.

A series can be created from a list:
Expand Down Expand Up @@ -197,7 +197,7 @@ DF.filter(mountains, elevation > mean(elevation))
```

You can see that we can refer to the columns using their names, and use functions
without define them. This is possible due the powerful `Explorer.Query` features,
without defining them. This is possible due to the powerful `Explorer.Query` features,
and it's the main reason we need to "require" the `Explorer.DataFrame` module.

The result is going to look like this:
Expand Down Expand Up @@ -275,7 +275,7 @@ We support the following:
- `x86_64-unknown-linux-musl` - Linux running on Intel/AMD 64 bits CPUs, compiled with Musl.
- `x86_64-unknown-freebsd` - FreeBSD running on Intel/AMD 64 bits.

This means that the Explorer is going to work without the need to compile it from source.
This means that Explorer is going to work without the need to compile it from source.

This currently **only works for Hex releases**. For more information on how it works, please
check the [RustlerPrecompiled project](https://hexdocs.pm/rustler_precompiled).
Expand Down
2 changes: 1 addition & 1 deletion lib/explorer/application.ex
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ defmodule Explorer.Application do
@moduledoc false
use Application

def start(_args, _type) do
def start(_type, _args) do
children = [
{DynamicSupervisor, name: Explorer.Remote.Supervisor, strategy: :one_for_one},
Explorer.Remote.LocalGC
Expand Down
2 changes: 1 addition & 1 deletion lib/explorer/remote.ex
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ defmodule Explorer.Remote do
is garbage collected and if we attempt to read it later on,
from the caller node, it will no longer exist. Therefore,
we must explicitly place these resources in remote nodes
by spawning processes to hold these refernces. That's what
by spawning processes to hold these references. That's what
the `place/2` function in this module does.

We also need to guarantee these resources are not kept
Expand Down
Loading