If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Aleksei Matiushkin am-kantox @kantox Barcelona, España I was born October, 0 (aka September, 30) and I am still more functional than object oriented.

am-kantox/elixir-iteraptor 59

Handy enumerable operations implementation.

am-kantox/dry-behaviour 13

Tiny library inspired by Elixir protocol pattern.

am-kantox/envio 12

Application-wide registry with handy helpers to ease dispatching

am-kantox/cloister 11

Lightweight Cluster handling with support for consensus and dynamic configuration

am-kantox/easy_ets 11

The very simple ETS wrapper simplifying cross-process ETS handling (like `Agent`, but `:ets`).

am-kantox/camarero 7

Semi-static JSON API Scaffold for Elixir

am-kantox/ack 4

Tiny drop-in for painless acknowledgements across different applications.

am-kantox/bf 4

Implementation of Brainfuck-like language “😻” aka “❤Kitty” aka “LoveKitty”

am-kantox/agentex 3

Elixir distributed agent implementation on top of Mnesia

am-kantox/black_friday 3

Solution for internal Kantox test task (job applications) in Elixir

push eventam-kantox/tarearbol

Aleksei Matiushkin

commit sha ffbe14ef888b6bcbce524ad55cd9de59a4a8178a

Satisfy dyalizer

view details

push time in 44 minutes

created tagam-kantox/tarearbol


More handy task runner, allowing retries, callbacks, assurance that the task succeeded, and more

created time in 14 hours

push eventam-kantox/tarearbol

Aleksei Matiushkin

commit sha 30a969249fda635b209c9a960f2d64d61bdecc5b

Cleanup state on termination

view details

push time in 14 hours

PR opened safwank/ElixirRetry

`reduce_while/3` allowing passing the accumulator through

Th PR is inspired by this SO question.

In some cases, subsequent retries in reduce_while/2 might depend on the previous outcome. In such a case, it’d be great to pass the accumulator through instead of just discarding it. This PR provides reduce_while/3 allowing this functionality.


    test "allows an accumulator to be passed through" do
      result =
        retry_while {:count, 0}, with: linear_backoff(50, 1) |> take(5) do
          {:cont, count + 1}

      assert result == 6
+47 -0

0 comment

2 changed files

pr created time in a day

push eventam-kantox/ElixirRetry

Aleksei Matiushkin

commit sha 3798885a7420ae1999c72156a4fc53b72b4cab76

reduce_while/3 allowing passing the accumulator through

view details

push time in a day

fork am-kantox/ElixirRetry

Simple Elixir macros for linear retry, exponential backoff and wait with composable delays

fork in a day

push eventmudasobwa/

Aleksei Matiushkin

commit sha ae6c1a23b583e13893a3193d949b9e75890124d1


view details

push time in a month

push eventmudasobwa/

Aleksei Matiushkin

commit sha 7acfad55d92dc75240cba71ff4a07be009409a5d

New post

view details

push time in a month


started time in 2 months

issue closedmudasobwa/markright

Using `•` is always grouping itens

Hi, first of all. Thanks for the library.

We are currently evaluating it to use to create a custom markdown parse. We found this bug.

  test "parses [different types of] line items" do
    input = """
  • item 1
  • item 2

  output = {
      {:p, %{},
         {:ul, %{}, [{:li, %{}, "item 1"}, {:li, %{}, "item 2"}]},

  assert input
          |> Markright.to_ast() == output

   left:  {:article, %{}, [{:p, %{}, [{:ul, %{}, [{:li, %{}, ["item 1", {:ul, %{}, [{:li, %{}, "item 2"}]}]}]}]}]}
   right: {:article, %{}, [{:p, %{}, [{:ul, %{}, [{:li, %{}, "item 1"}, {:li, %{}, "item 2"}]}]}]}

As first, I thought some commit that we did had broken it, but using the 0.5.0 version does have the same behavior. This one is being a little trick to trace.

closed time in 2 months


issue commentmudasobwa/markright

Using `•` is always grouping itens

Wow, sounds great! I’ll definitely check it out. Sometimes I regret I never had a chance to rebuild markright from scratch or at least fix all the glitches I am aware of.

Always welcome.


comment created time in 2 months

push eventmudasobwa/huya-xkb

Aleksei Matiushkin

commit sha 74f8c1ef0815f07a073c08341f604322bd306270


view details

push time in 2 months

push eventmudasobwa/huya-xkb

Aleksei Matiushkin

commit sha df52d51f31d6e8e2fafeba2afa8c79b9d47c213e

Modern layouts

view details

push time in 2 months

PR opened elixir-lang/elixir

`Map.values/2` to retrieve values in predicted order

Map.values/1 delegates to :maps.values/1 and since erlang maps are not ordered (when size is greater than 32,) the result of Map.values(map) might be confusing when map_size(map) > 32.

list = Enum.to_list(1..33)
map = list |> |>

#⇒ [33, 12, 23, 29, 30, 26, 31, 11, 9, …]

This PR provides Map.values/2 function that accepts a list of keys to order returned values accordingly. This function might be particularly helpful when working with CSV-like inputs of considerable size using Flow, which is more friendly to maps in general and key: {:key, name} working with maps only in particular.

Map.values(map, list)
#⇒ [1, 2, 3, 4, 5, 6, 7, 8, 9, …]

Despite this function might be easily implemented whenever needed outside of the core library, its existence would be a good hint reminding everybody that maps are not ordered and one should not rely on Map.values/1 returning predictable and deterministic results.

+31 -2

0 comment

3 changed files

pr created time in 3 months

create barncham-kantox/elixir

branch : feature/map-get-values-ordered

created branch time in 3 months

fork am-kantox/elixir-1

Elixir is a dynamic, functional language designed for building scalable and maintainable applications

fork in 3 months