Pull to refresh
-18
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)

Если вы про эту теорему: https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_%D0%93%D0%B0%D1%83%D1%81%D1%81%D0%B0


То какое она имеет отношение к обсуждаемому вопросу? Напомню, форма Солнца не сферическая.

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

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

Позволил себе пооптимизировать ваш алгоритм на 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 раза больше. Так компания растеряла весь отдел.

Не могу не поделиться своим разбором форматов данных: https://youtu.be/vBqJWQzPB3Y?list=PLXyFFhv8ucKSC96WOd7Ju2HmEWTA3jPa5&t=5652

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


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


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

1
23 ...

Information

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