Mojo good first issues

This issue highlights that the `numojo/routines/linalg/` module is missing several standard linear algebra routines found in libraries like NumPy and SciPy. Key missing functionalities include norms, eigenvalue/eigenvector decomposition, singular value decomposition, QR decomposition, Cholesky decomposition, pseudoinverse, and matrix rank calculations. The suggested approach is to implement `norm` first, followed by more complex decompositions.

The `_DLHandle.close` function in the Mojo standard library incorrectly calls `dlclose` on a potentially null handle. This can lead to undefined behavior as `dlclose` is not designed to handle null pointers. The proposed fix adds a check to ensure `dlclose` is only called when the handle is valid.

This bug report describes an issue where the Mojo compiler provides an overly complex and unhelpful error message when a `main` function attempts to raise an exception that is not an `Error` struct. The expected behavior is a clear message indicating that only `Error` structs are supported for exceptions in `main` functions.

This issue proposes several improvements to the `pow` function and the `Powable` trait in Mojo's standard library. Key tasks include adding documentation examples, implementing `__pow__` for `IntLiteral` (with a discussion needed on negative exponents), potentially adding tests for `Int`, and considering a `mod` argument similar to Python's `pow`.

This is a placeholder issue titled 'demo issue' with a body also containing 'demo'. It is labeled as a 'good first issue', suggesting it's intended for new contributors to get started.

This issue highlights the absence of several common NumPy ndarray manipulation routines in NuMojo, including functions for reshaping, splitting, repeating, padding, and finding unique elements. It also points out inconsistencies in the placement and availability of other functions like `squeeze`, `resize`, and `tile`. The suggested approach is to implement these functions one by one in separate pull requests, following established conventions and adding corresponding tests.

This bug report highlights an issue where floating-point division in Mojo produces unexpected, overly precise results, unlike Python's more user-friendly rounding. The user expects `314.0 / 100` to yield `3.14`, but Mojo returns `3.1400000000000001`. This behavior is consistently reproducible on the latest Mojo version on macOS.

This issue proposes to refactor the standard library by replacing manual index bounds checking and normalization logic with a new `normalize_index` helper function. The goal is to improve code consistency and reduce boilerplate across various collection types like List and InlinedFixedVector. The updates should be applied incrementally to facilitate easier code reviews.

The `scripts/commit-changes.py` script currently exits with an error when there are no changes to commit. This prevents CI workflows from completing successfully on clean runs. The goal is to modify the script so it exits with a success code when no changes are detected, ensuring the workflow proceeds as expected.

This issue proposes adding JPEG decoding functionality to the project, recognizing JPEG and PNG as the most common image formats. An existing, albeit outdated, Mojo example is provided as a starting point for implementation.

This feature request asks for support of RMSNorm without normalization weights, enabling a technique called FlashNorm. FlashNorm folds the RMSNorm weights into the subsequent linear layer, reducing inference overhead with no accuracy loss. The user has already demonstrated this optimization on several LLMs.

The CPython initialization logic in Mojo incorrectly calls `Py_Initialize` even after detecting an initialization error. This can lead to unexpected behavior or crashes when the Python library is not compatible or found. The proposed fix adds a conditional check to prevent `Py_Initialize` from being called if an error has already been set.

This feature request proposes adding a `drain()` or `take_items()` API to Mojo's `List` type. This would allow iterators to move items out of the list as they are consumed, avoiding unnecessary copies and improving performance in scenarios like initializing dictionaries or other collections from lists.

A bug has been reported where `llvm.masked.scatter` fails when used with shared memory on CUDA devices, resulting in an `CUDA_ERROR_ILLEGAL_ADDRESS`. The issue works correctly with global memory, and a potential solution involves providing a fallback mechanism or restricting the operation to `AddressSpace.GENERIC`.

This issue identifies significant gaps in test coverage for several existing routine modules within the numojo library. Specific functions in bitwise, functional, linalg, and statistics routines are either untested or have very limited test coverage. The suggested approach is to address these gaps by writing new tests for individual functions or modules.

This issue highlights two key missing features in the `numojo.random` module: the absence of seeding support for reproducible results and the lack of several common probability distributions found in libraries like NumPy. The suggested approach is to implement these missing distributions incrementally, making it suitable for contributions.

This issue requests the implementation of several missing NumPy mathematical, logical, and sorting routines within the NuMojo library. It lists specific functions like `convolve`, `interp`, `isin`, and `partition` that need to be added, along with their corresponding `NDArray` instance methods. The suggested approach is to implement these functions one by one with accompanying tests.

This issue requests the addition of several missing statistical routines to the numojo library, particularly focusing on nan-aware reductions that are present in numpy. The suggested approach involves implementing wrappers for nan-aware functions and developing new implementations for percentile, quantile, histogram, and bincount.

This issue proposes to improve error handling in NuMojo by standardizing the use of custom error types instead of generic ones. The goal is to make debugging easier and provide clearer error messages for users and contributors. This involves refactoring existing error raising and potentially adding new custom error types.

This is a feature request to extend Mojo's platform support to include NVIDIA's consumer Blackwell GPUs (sm_120/sm_121), such as those found in the RTX 50XX series. The goal is to identify and fix kernel issues and optimize performance for this new architecture, which differs significantly from existing supported Blackwell GPUs.

The `b64decode` function in Mojo's `base64` module incorrectly handles whitespace characters within the base64 encoded string. Instead of ignoring them as is standard for base64 decoding, it appears to treat them as invalid characters, leading to incomplete or corrupted decoding.

This feature request aims to migrate remaining abort tests in the Mojo standard library to use the `std.testing._assert_aborts()` function. The migration involves refactoring existing tests that use older patterns like `-D test=N` and `mojo_filecheck_test(expect_crash = True)` into new test functions and `mojo_test` targets.

On macOS, the `os.stat` function in Mojo incorrectly scales sub-second timestamps by a factor of 1000, leading to inaccuracies of up to ~1000 seconds. This occurs because Mojo assumes the `struct stat`'s nanosecond field provides microseconds on macOS, when it actually provides nanoseconds, causing incorrect comparisons of file modification, access, and creation times.

The Mojo parser incorrectly rejects a nested try-except statement when it's the last statement within a try-with-finally block. This leads to misleading "body must not be empty" and "expected 'except' or 'finally' block" errors, even though the syntax is valid.

This feature request asks for a non-mutating `--check` mode for the `mojo format` command. This mode would allow developers to verify if code is correctly formatted without altering files, making it suitable for CI pipelines and pre-commit hooks. The requested behavior includes exiting with a specific code (0 for formatted, 1 for unformatted) and reporting which files need changes.