This Erlang module provides a function to find the first non-repeating character in a given string. It's useful in text processing tasks where identifying unique elements is crucial, such as in data validation or simple...

The `find_first_non_repeating_char` function first handles the edge case of an empty input string, returning `null`. It then calls `build_frequency_map` to create a map where keys are characters and values are their counts within the string. This map is built using `lists:foldl`, efficiently updating counts for each character. The `build_frequency_map` function ensures that even if a character appears multiple times, its count is correctly incremented. After constructing the frequency map, `find_first_unique` is called. This helper function iterates through the original string, checking the frequency of each character in the map. The first character encountered with a frequency of exactly 1 is returned. If the loop completes without finding such a character (meaning all characters repeat or the string was empty), `null` is returned. The time complexity is O(N) because the string is traversed twice, and map operations (insertion/lookup) are O(1) on average. The space complexity is O(K), where K is the number of unique characters in the string, to store the frequency map. This approach guarantees correctness by ensuring every character's frequency is accounted for before determining uniqueness.

function find_first_non_repeating_char(string): if string is empty: return null frequency_map = create an empty map for each character in string: increment count for character in frequency_map, default to 0 if not presen...

This Erlang module defines a function `sum_list` that computes the sum of all integer elements within a given list. This is a fundamental operation in many programming tasks, such as calculating totals, averages, or perf...

The `sum_list` function is designed to sum integers in a list. It first checks if the input `List` is indeed a list. If it's an empty list (`[]`), it correctly returns `0` as the sum, serving as the base case for the recursion. Otherwise, it delegates the summation to a helper function `sum_helper`. The `sum_helper` function also has a base case: when it receives an empty list, it returns `0`. For a non-empty list `[Head | Tail]`, it checks if `Head` is an integer. If it is, `Head` is added to the result of recursively calling `sum_helper` on the `Tail`. If `Head` is not an integer, it's skipped, and the recursion continues with the `Tail`. This ensures that only integer elements contribute to the sum. The time complexity is O(N), where N is the number of elements in the list, as each element is visited once. The space complexity is O(N) in the worst case due to the recursion depth, although tail-call optimization might reduce this in some Erlang compilers. This recursive structure correctly handles all list lengths and gracefully ignores non-integer elements.

function sum_list(list): if list is empty: return 0 else: return sum_helper(list) function sum_helper(list): if list is empty: return 0 else: head = first element of list tail = rest of list if head is an integer: return...

This Erlang code implements a distributed lock manager. It uses Erlang's built-in distribution capabilities (`rpc`) to allow processes on different nodes to acquire and release locks for shared resources. A central lock...

The `dist_lock` module provides a distributed lock manager. The `start/0` function spawns a `lock_server_loop/1` process on the current node, which maintains a map of resources to their lock status (holder PID and wait queue). The `acquire_lock/2` function uses `rpc:call` to send a request to the lock server on a specified `Node`. The `lock_server_loop` handles `acquire` messages: if the resource is free, it grants the lock; otherwise, it adds the requester to the wait queue. `release_lock/2` removes the lock and grants it to the next in line if any. `is_locked/1` checks the lock status. A `node_down` message handler is included to attempt cleanup if a node disconnects, releasing locks held by processes on that node. The `handle_lock_request`, `handle_release_request`, and `handle_is_locked_request` functions act as RPC wrappers, sending messages to the local `lock_server_loop` and waiting for replies. Time complexity for lock acquisition/release is O(1) on average if the resource is free or the next in queue is readily available, but can be O(N) in the worst case where N is the number of processes waiting for a lock on a resource. Space complexity is O(R*W) where R is the number of resources and W is the maximum number of waiting processes per resource.

Lock Server Process (per node): State: Map of Resource -> {HolderPid, WaitQueue}. Receive 'acquire' message (RequesterPid, Resource): If Resource not in state: Grant lock to RequesterPid, add to state. Notify RequesterPi...

This Erlang GenServer implements a simple counter. It handles synchronous `call` requests for incrementing, retrieving, and resetting the counter's value. The `init` function sets the initial state to 0. The `handle_call...

The `counter_server` module defines a GenServer that maintains an integer state representing a counter. The `init/1` callback initializes the state to 0. The `handle_call/3` callback is the core logic, pattern matching on the message received. For `increment`, it adds 1 to the state and replies with `ok` and the new state. For `get`, it replies with the current state without changing it. For `reset`, it sets the state back to 0 and replies with `ok`. Any other call results in an error reply. The `handle_cast/2`, `handle_info/2`, `terminate/2`, and `code_change/3` callbacks are included for completeness but are not actively used in this simple example. The time complexity for each operation is O(1) as it involves simple arithmetic and state updates. Space complexity is O(1) as it only stores the counter value.

Start GenServer with initial state 0. Handle 'increment' call: increment state, reply 'ok' and new state. Handle 'get' call: reply current state and current state. Handle 'reset' call: set state to 0, reply 'ok' and new...

This Erlang code demonstrates hot code swapping for a GenServer. It defines an initial version (`hot_config_v1`) of a configuration manager. This GenServer stores a configuration value and allows it to be retrieved and u...

The `hot_config_v1` module implements a GenServer that holds a configuration value. The `init/1` callback initializes the state with the provided configuration. `handle_call/3` for `get_config` returns the current configuration. `handle_cast/2` for `update_config` updates the internal state. The `code_change/3` callback is designed to handle transitions between different versions of the module. In this v1, it simply returns `{ok, State}`, indicating no transformation is needed for the current state when upgrading from a hypothetical older version or when the module is loaded for the first time. To perform a hot swap, one would save this code as `hot_config_v1.erl`, start an instance, then save a new version (e.g., `hot_config_v2.erl`) with potentially different logic or an updated `code_change` function. After saving the new version, `code:purge(hot_config_v1)` and `code:load_file(hot_config_v2)` would be executed in the Erlang shell. The running GenServer would then use the new code. Time complexity for `get_config` and `update_config` is O(1). Space complexity is O(C) where C is the size of the configuration data.

GenServer (Version 1): State: Configuration value. init(InitialConfig): Set state to InitialConfig, log initialization. handle_call('get_config'): Reply with current state. handle_cast('update_config', NewConfig): Update...

This Erlang code implements a robust retry mechanism with exponential backoff. The `attempt_operation/3` function takes an operation (a function that returns `{ok, Result}` or `{error, Reason}`), a maximum number of retr...

The `retry_workflow` module provides a function `attempt_operation/3` to handle operations that might fail transiently. It uses a recursive helper function `do_attempt/4` to manage the retry logic. `do_attempt` first executes the `Operation`. If it succeeds, the result is returned. If it fails with a `{error, Reason}`, it checks if retries are left. If so, it prints a message, waits using `timer:sleep/1` for `CurrentDelayMs`, calculates the `NextDelayMs` using `exponential_backoff/2`, and recursively calls itself with decremented retries. `exponential_backoff/2` calculates the next delay by doubling the base delay for each attempt, capped at 60 seconds to prevent excessively long waits. The `attempt_operation/3` function also includes basic validation for its arguments. Time complexity is difficult to define precisely due to the `timer:sleep`, but each successful attempt is O(1) plus the operation's complexity. The total time spent waiting is a geometric series. Space complexity is O(R) where R is the maximum number of retries, due to the recursion depth.

Function attempt_operation(Operation, MaxRetries, InitialDelayMs): If MaxRetries < 0 or InitialDelayMs <= 0: Return {error, invalid_arguments}. Call do_attempt(Operation, MaxRetries, InitialDelayMs, 0). Function do_attem...

This Erlang code implements a basic message queue consumer. It uses a GenServer to hold the state of the message queue (represented as a list). The consumer continuously checks for new messages. When a message is receive...

The `mq_consumer` module defines a GenServer that acts as a message queue consumer. The `start_link/1` function initializes the GenServer with a list representing the message queue. The `init/1` callback simply stores the initial queue. The `handle_info/2` callback is the core of the consumer logic. It pattern matches on the `message` atom. If the queue is not empty (`[Head | Tail]`), it processes the `Head` message (prints it) and then updates the state to `Tail`, effectively acknowledging and removing the message. If the queue is empty (`[]`), it does nothing. Any other `handle_info` messages are logged as unexpected. The `handle_call` and `handle_cast` callbacks are included for completeness but are not used in this simple consumer. The time complexity for processing a message is O(1) assuming list head/tail operations are O(1). The space complexity is O(Q) where Q is the number of messages in the queue.

Consumer GenServer: State: List representing the message queue. init(Queue): Store Queue as state. handle_info('message'): If Queue is not empty (Head | Tail): Process Head (e.g., print). Update state to Tail (acknowledg...

This Erlang code implements the core logic for an event sourcing aggregate, specifically a shopping cart. The `apply_event/2` function takes the current state of the aggregate and an event, returning the new state after...

The `cart_aggregate` module defines functions for managing the state of a shopping cart using event sourcing principles. The `apply_event/2` function is a pure function that takes the current aggregate state (represented as a map) and an event (also a map or tuple) and returns the new state. It uses pattern matching to handle different event types (`cart_created`, `item_added`, `item_removed`, `cart_checked_out`) and updates the state accordingly, ensuring that events are only applied to valid states (e.g., items can only be added/removed if the cart is `created`). The `reconstruct/1` function takes a list of events and builds the current state by applying the first event to an initial empty state, then folding over the remaining events, applying each one to the accumulating state. This ensures that the state is always derived from its history. Time complexity for `apply_event/2` is O(1) for simple events and O(N) for `item_added`/`item_removed` if map operations are considered O(log N) or O(N) in worst case for list operations. `reconstruct/1` has a time complexity of O(E * A), where E is the number of events and A is the average complexity of `apply_event/2`. Space complexity is O(S) where S is the size of the aggregate state.

Aggregate State: Map: {items => Map of ItemId -> Quantity, total_price => Number, status => String}. apply_event(State, Event): If Event is 'cart_created': Initialize State with empty items, 0 price, status 'created', an...