Skip to content

Commit d646e69

Browse files
authored
Fix typos (#11)
1 parent f0112e0 commit d646e69

File tree

3 files changed

+8
-8
lines changed

3 files changed

+8
-8
lines changed

.github/workflows/release.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ jobs:
2121
with:
2222
otp-version: ${{ matrix.otp_version }}
2323
elixir-version: ${{ env.ELIXIR_VERSION }}
24-
- name: Install system dependecies
24+
- name: Install system dependencies
2525
run: |
2626
sudo apt-get update
2727
sudo apt-get install -y build-essential automake autoconf pkg-config bc m4 unzip zip \

c_src/pythonx/pythonx.cpp

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -44,13 +44,13 @@ class PyGILGuard {
4444
// using libraries depending on pybind11.
4545
//
4646
// pybind11 is a popular library for writing C extensions in Python
47-
// packages. It provies convenient C++ API on top of the Python C
47+
// packages. It provides convenient C++ API on top of the Python C
4848
// API. In particular, it provides conveniences for dealing with
4949
// GIL, one of them being `gil_scoped_acquire`. The implementation
5050
// has a bug that results in a dangling pointer being used. This
5151
// bug only appears when the code runs in a non-main thread that
5252
// manages the `gil_scoped_acquire` checks if the calling thread
53-
// alread holds GIL with `PyGILState_Ensure` and `PyGILState_Release`.
53+
// already holds GIL with `PyGILState_Ensure` and `PyGILState_Release`.
5454
// Specifically, the GIL, in which case it stores the pointer to
5555
// the corresponding `PyThreadState`. After `PyGILState_Release`,
5656
// the thread state is freed, but subsequent usage of `gil_scoped_acquire`
@@ -292,7 +292,7 @@ fine::Ok<> init(ErlNifEnv *env, std::string python_dl_path,
292292
load_python_library(python_dl_path);
293293

294294
// The path needs to be available for the whole interpreter lifetime,
295-
// so we store it in a global varibale.
295+
// so we store it in a global variable.
296296
python_home_path_w = std::wstring(
297297
python_home_path.data, python_home_path.data + python_home_path.size);
298298

@@ -464,7 +464,7 @@ FINE_NIF(init, ERL_NIF_DIRTY_JOB_CPU_BOUND);
464464
fine::Ok<> janitor_decref(ErlNifEnv *env, uint64_t ptr) {
465465
auto init_guard = std::lock_guard<std::mutex>(init_mutex);
466466

467-
// If the intepreter is no longer initialized, ignore the call
467+
// If the interpreter is no longer initialized, ignore the call
468468
if (is_initialized) {
469469
auto gil_guard = PyGILGuard();
470470

@@ -1193,7 +1193,7 @@ eval(ErlNifEnv *env, ErlNifBinary code, std::string code_md5,
11931193
// of a class defined via evaluation. The pickle module consults
11941194
// sys.modules (in this case sys.modules["__main__"]) and looks up
11951195
// the class or function name. If we use a plain dict as globals,
1196-
// the class will be defined only in that dict and such lookups wil
1196+
// the class will be defined only in that dict and such lookups will
11971197
// fail.
11981198
//
11991199
// However, it is worth noting that the current approach is not
@@ -1241,7 +1241,7 @@ eval(ErlNifEnv *env, ErlNifBinary code, std::string code_md5,
12411241
// 1. We dump EvalInfo into Python bytes and store it in globals
12421242
// as __pythonx_eval_info_bytes__.
12431243
//
1244-
// 2. When IO happens, our custom sys.stdout.write (overriden on
1244+
// 2. When IO happens, our custom sys.stdout.write (overridden on
12451245
// init) retrieves the info from globals and calls the
12461246
// pythonx_handle_io_write C function, passing the info.
12471247
//

lib/pythonx.ex

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -60,7 +60,7 @@ defmodule Pythonx do
6060

6161
# Initializes the Python interpreter.
6262
#
63-
# > #### Reproducability {: .info}
63+
# > #### Reproducibility {: .info}
6464
# >
6565
# > This function can be called to use a custom Python installation,
6666
# > however in most cases it is more convenient to call `uv_init/2`,

0 commit comments

Comments
 (0)