Pull to refresh
-17
0
Дмитрий Карловский @vintage

Адвокат Дьявола

Send message

Вы сами-то хоть раз заглядывали к нам, чтобы такое утверждать? Или тоже повторяете чьи-то вбросы из какого-то по настоящему токсичного сообщества?

Стоит иметь ввиду, что вероятность коллизий в случае рандома по началу крайне мала и только со временем, по мере насыщения, начинает расти. Если взять полные 128 бит рандома, то вероятность за четверть века получить хотя бы одну коллизию всего 0.1%:

При этом в первый год вероятность коллизии в 500 раз меньше:

Кроме того, если рандому плевать когда были сгенерированы идентификаторы, то всем схемам с таймштампами уже не плевать и поэтому любые неравномерности в частоте генерации идентификаторов повышают риск коллизии.

А чем, собственно, wasm не подходит на эту роль?

Конечно: https://github.com/eigenmethod/mol/blob/master/fiber/readme.md


Можно даже так, в 3 строки:


const syncFakeFetch = $mol_fiber_sync( fakeFetch )
const fetchReducer = ( arg , url )=> syncFakeFetch( url , arg )
const fiberWay = $mol_fiber_root( ()=> urls.reduce( fetchReducer , undefined ) )

Я просто оставлю это здесь:


const syncFakeFetch = $mol_fiber_sync( fakeFetch )

const fiberWay = $mol_fiber_root( ()=> {
    return urls.reduce( ( arg , url )=> syncFakeFetch( url , arg ) , undefined )
} )

Я не совсем понял, что вы пишете в логи, но вы не хотите писать их в более структурированном и наглядном виде? Например, в формате tree:


error
    time \2019-02-21 15:54:11:486
    class \io.infinite.pigeon.threads.SenderThread
    method \SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY
    guid \a64aceed-8e4c-4d4b-8030-0c23bc3b3f0d
    type \java.lang.NullPointerException
    stack
        \at io.infinite.pigeon.threads.SenderThread.sendMessage(SenderThread.groovy:98)
        \at io.infinite.pigeon.threads.SenderThread.run(SenderThread.groovy:44)
    calls
        \sendMessage(60,5,100,6)
        \run(40,5,50,6)

Вместо этого нечитаемого месива:


2019-02-21 15:54:11:486|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|EXCEPTION (first occurrence):
2019-02-21 15:54:11:492|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|a64aceed-8e4c-4d4b-8030-0c23bc3b3f0d
2019-02-21 15:54:11:493|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|java.lang.NullPointerException
    at io.infinite.pigeon.threads.SenderThread.sendMessage(SenderThread.groovy:98)
    at io.infinite.pigeon.threads.SenderThread.run(SenderThread.groovy:44)

2019-02-21 15:54:11:493|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|METHOD EXCEPTION: sendMessage.io.infinite.pigeon.threads.SenderThread(60,5,100,6)
2019-02-21 15:54:11:493|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|EXCEPTION (additional occurrence):
2019-02-21 15:54:11:494|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|a64aceed-8e4c-4d4b-8030-0c23bc3b3f0d
2019-02-21 15:54:11:494|error|SELF_TEST_RETRY_OUTPUT_RETRY_SENDER_1_RETRY|io.infinite.pigeon.threads.SenderThread|METHOD EXCEPTION: run.io.infinite.pigeon.threads.SenderThread(40,5,50,6)

Под своими постами видел раньше, но по ходу дела после слива кармы эта кнопка пропадает.

Большинство людей не понимает, что поиск виноватых не решает проблему, а лишь усугубляет её. Проблему решает только поиск решения. А когда есть решение — не важно уже кто виноват.

Позволил себе пооптимизировать ваш алгоритм на D.


Добавил функцию min, которая не использует ветвления:


auto min(N)(N a, N b)
{
    auto d = b - a;
    return a + (d & (d >> (N.sizeof * 8 - 1)));
}

Избавился от второго массива и лишних обращений к массивам по индексу:


long levDist(String)(in String str1, in String str2)
{
    if (str1.length == 0)
        return str2.length;
    if (str2.length == 0)
        return str1.length;

    long[] costs = str1.length.to!long.iota.array;

    foreach (i, char1; str1)
    {
        auto delCost = costs[0];
        auto insCost = i.to!long + 1;

        foreach (j, char2; str2)
        {
            auto substCost = delCost;
            if (char1 == char2)
                --substCost;

            delCost = costs[j];

            insCost = 1 + substCost.min(delCost).min(insCost);

            costs[j] = insCost;
        }
    }

    return costs[str1.length - 1];
}

Ну и код переписал более идиоматично. Возможно где-то накосячил, не до конца разобравшись в алгоритме.

Я когда пришёл за повышением спустя год работы, мне сказали, что повысят, если возьму доп обязанности и хорошо покажу себя. Ну я согласился. По итогу нашли недовольство от одного из клиентов, и ничего не повысили. Чуть позже в другом месте мне предложили сходу почти в 2 раза больше. Так компания растеряла весь отдел.

Вы молодец, что делаете дополнительную бессмысленную работу по актуализации каждого комита после ребейза. Успехов вам. Нормальные же пацаны просто не занимаются этой ерундой и актуализируют лишь один единственный мерж-комит, а оставшееся время тратят на более полезные вещи, чем подделка истории.


Как ни пытайтесь вы преуменьшить значимость проблем ребейза, суть не поменяется: при ребейзе проблемы есть, при мерже — нет. И не надо высасывать из пальца проблемы мержа и выдавать за них проблемы вашего процесса или гит-клиента. Тот же TortoiseGit всё отлично показывает.


Ну и про CI — вы реально предлагаете гонять CI по всем коммитам, а не только по последнему? И это в ваших условиях, когда "пересборки и проверки занимают достаточно много времени". Впрочем, вам бы стоило прежде всего решить проблему долгой сборки, так как она много чему мешает. Не только использованию bisect.

1
23 ...

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity