Комментарии 205
Реклама этой компании всегда будет только плюсоваться :)
Выражение «sizeof(P256_SPKI_PREFIX) != 0» всегда ложно.
Разве не наоборот?
Знаю троих разработчиков Chromium, все они не используют Visual Studio и Windows, обходятся текстовыми редакторами вроде vim и Textmate под Linux и OS X. Так что неудивительно, почему у вас все еще нет оффера от Гугла ;)
Статья именно для них — киньте им, пожалуйста, ссылку! Собственно теперь нам и не требуется Visual Studio для того, чтобы проверять Chromium.
Но все же требуется Windows. Видимо вам все же придется портировать. Пока не будет удобного способа проверять не на машине разработчика, а в облаке, боюсь Гугл на вас и не посмотрит.
Уже есть способ проверять не на машине разработчика, а в облаке.
И тем не менее в этой статье вы написали
и показали, как это сделать на Windows. Почему бы не сделать пример, как на Linux-машине встроить облачную проверку в сборочную систему?
Кстати, а в чем все-таки причина отсутствия nix-версии? Не видно рынка, или сложность портирования?
Вы видите, что теперь PVS-Studio легко встроить в сборочную систему.
и показали, как это сделать на Windows. Почему бы не сделать пример, как на Linux-машине встроить облачную проверку в сборочную систему?
Кстати, а в чем все-таки причина отсутствия nix-версии? Не видно рынка, или сложность портирования?
Почему бы не сделать пример, как на Linux-машине встроить облачную проверку в сборочную систему?
Мы делали проверку Chromium и на Linux. Все прошло без проблем, все работает. Описывать это в статье… Ну тогда бы статья была не 13 листов, а 20. И точно никто бы не прочитал.
Кстати, а в чем все-таки причина отсутствия nix-версии? Не видно рынка, или сложность портирования?
Мы не умеем продавать Linux-продукты. Не видим рынка, не умеем. Положа руку на сердце, кроме «энтузиастов» с Хабра вопросов про Linux-версию очень мало. А энтузиасты — они же не покупают.
Вопрос цены. Энтузиасты всегда пробуют что-то новое, а потом приходят на работу и говорят: «Надо купить то-то и то-то, это серьезно улучшит стабильность нашего кода и сэкономит нам время на написание не тривиальных тестов».
>Мы не умеем продавать Linux-продукты.
А модель сервиса вы всерьез рассматривали? Если при текущей модели ваш потолок (IMHO) — несколько сотен крупных проектов, которые посчитают оправданным встроить анализ в ежедневный workflow, то в модели сервиса вы можете заполучить и тысячи и десятки тысяч обычных команд, которые будут проверяться, скажем, раз в месяц или даже раз в год.
А модель сервиса вы всерьез рассматривали? Если при текущей модели ваш потолок (IMHO) — несколько сотен крупных проектов, которые посчитают оправданным встроить анализ в ежедневный workflow, то в модели сервиса вы можете заполучить и тысячи и десятки тысяч обычных команд, которые будут проверяться, скажем, раз в месяц или даже раз в год.
, которые будут проверяться, скажем, раз в месяц или даже раз в год.
Это самый неправильный способ использования анализатора. Нам совесть не позволяет обманывать людей, предлагая наиэффективнейший способ работы с инструментом. Пусть карма получше будет.
Если Вы не согласны, немедленно отключите все предупреждения в компиляторе, и включайте их раз в месяц или даже в год. :)
Не понимаю, в чем тут обман, объясните.
Конечно, это не самый эффективный способ, но почему он «неправильный», если поможет исправить накопившиеся ошибки?
Конечно, это не самый эффективный способ, но почему он «неправильный», если поможет исправить накопившиеся ошибки?
Такой подход имеет смысл, если команда, например, переносит код на 64-битную систему. Тогда открыли 100500 сообщений, выданных модулем Viva64 и начали усердно рефакторить код. Потом, анализатор можно выбросить и писать новый код уже правильно. Собственно, Viva64 так и преподносился, как инструмент миграции. Использовать его потом или нет — это уже по желанию.
В случае статического анализа общего назначения, основный смысл — регулярное его использование. Оно позволяет выявить ляпы и опечатки на самом раннем этапе. От этого собственно и есть основная польза.
Если этого не делать, эти ошибки в своём большинстве будут выявлены чуть позже другими (дорогими) способами. А на этапе запуска PVS-Studio от ошибок останутся рожки и ножки. В основном они будут находиться в крайне редко используемых участках кода. Например, в обработчиках ошибок. Кстати, именно это часто можно наблюдать в моих статьях. Многие другие ошибки, которые мог бы найти PVS-Studio, уже исправлены кровью и потом.
Так какой смысл предлагать ужасный способ использования?
В случае статического анализа общего назначения, основный смысл — регулярное его использование. Оно позволяет выявить ляпы и опечатки на самом раннем этапе. От этого собственно и есть основная польза.
Если этого не делать, эти ошибки в своём большинстве будут выявлены чуть позже другими (дорогими) способами. А на этапе запуска PVS-Studio от ошибок останутся рожки и ножки. В основном они будут находиться в крайне редко используемых участках кода. Например, в обработчиках ошибок. Кстати, именно это часто можно наблюдать в моих статьях. Многие другие ошибки, которые мог бы найти PVS-Studio, уже исправлены кровью и потом.
Так какой смысл предлагать ужасный способ использования?
Наверняка тесты Хромиума бегают в том числе на Виндовых машинах.
Я практически уверен, что на виндовых машинах в Гугле бегают только Вин-специфичные тесты, а все остальные — на линуксовых. Так что присоединюсь к «оракулам» выше/ниже: оффера не будет пока не появится полноценный линуксовый порт.
Как и ожидалось, вот и подтверждение от одного из разработчиков.
Где это там написано, что на винде бегают только тесты, «специфические для винды»? Как вообще понять, какой тест «специфический», если другой компилятор может даже самые базовые вещи по-другому реализовывать или оптимизировать?
Читайте между строк и используйте логику. Там написано, что у них есть некоторое количество Вин-машин, но добавление еще одной — тот еще гемор, и добавить линуксовую намного проще. С увеличением кодовой и тестовой базы нужно наращивать вычислительную мощь. Если для Вин-специфичных вещей выбора нет, то там, где выбор есть, он будет явно сделан в пользу Линукса.
Где Вы это всё там вычитали? Там написано, что добавление сервиса под Виндой труднее. При этом не написано, что невозможно и не написано ничего на счёт добавления машин. На счёт выбор есть\выбора нет — пользователи винды очень существенная (большая?) часть юзеров Хрома. Билд для них собирается студией. Что такого страшного, чтобы этот билд проверять какими-то инструментами, заточенными под винду или студию?
P.S. Вы понимаете, что проверять под линуксом билд Хромиума под gcc — не даёт права говорить об отсутствии багов под студией?
P.S. Вы понимаете, что проверять под линуксом билд Хромиума под gcc — не даёт права говорить об отсутствии багов под студией?
Вы думаете, я сейчас буду доказывать вам, что мое толкование слов автора того комментария более правильное, чем ваше? Ошибаетесь. Каждый волен в своих заблуждениях.
Безусловно. Я просто пытаюсь понять как Вы выводите валидность скомпилированного Visual Studio кода под Винду на основе каких-бы то там ни было проверок, пусть самыми лучшими инструментами, которые предлагаете делать только под Linux.
>Я просто пытаюсь понять как Вы выводите валидность скомпилированного Visual Studio кода под Винду на основе каких-бы то там ни было проверок
Начнем с того, что системы статического анализа не проверяют валидность скомпилированного кода. Они проверяют сам код.
Далее, большая часть кода как вебкита, так и хромиума в целом, платформо-независима. Они даже от STL постарались максимально уйти, и у них свои строки, свои контейнеры, и куча всего другого, которое живет в подпроекте с говорящмм названием «WTF» (нет, не то, что вы подумали, а Web Templates Framework :))
То есть практически весь «общий» код независим от платформы даже на уровне библиотек. Соответственно, различия начинаются только когда дело касается, скажем, рендеринга, и тут начинается полный Вавилон: тут вам и WinApi, и Cairo, и хренова туча других зверей разной степени монструозности. И вот именно эту часть нужно проверять на целевой платформе, тогда как большую часть WebCore, JavaScriptCore, WTF и т.д. — не нужно.
Начнем с того, что системы статического анализа не проверяют валидность скомпилированного кода. Они проверяют сам код.
Далее, большая часть кода как вебкита, так и хромиума в целом, платформо-независима. Они даже от STL постарались максимально уйти, и у них свои строки, свои контейнеры, и куча всего другого, которое живет в подпроекте с говорящмм названием «WTF» (нет, не то, что вы подумали, а Web Templates Framework :))
То есть практически весь «общий» код независим от платформы даже на уровне библиотек. Соответственно, различия начинаются только когда дело касается, скажем, рендеринга, и тут начинается полный Вавилон: тут вам и WinApi, и Cairo, и хренова туча других зверей разной степени монструозности. И вот именно эту часть нужно проверять на целевой платформе, тогда как большую часть WebCore, JavaScriptCore, WTF и т.д. — не нужно.
К сожалению, Вы не совсем правы. Это в теории, проблемы только в платформо-зависимых местах. А на практике, код из Chromium:
Этот код вполне «платформо-независим», но при этом не работает в Windows.
typedef UINT_PTR SOCKET;
SOCKET socket_;
int TCPServerSocketWin::Listen(....) {
....
socket_ = socket(address.GetSockAddrFamily(),
SOCK_STREAM, IPPROTO_TCP);
if (socket_ < 0) {
PLOG(ERROR) << "socket() returned an error";
return MapSystemError(WSAGetLastError());
}
....
}
Этот код вполне «платформо-независим», но при этом не работает в Windows.
Меня терзают смутные сомнения по поводу платформо-независимости класса с названием TCPServerSocketWin…
Да, это наверное к Win относится. Однако, это пример очень распространенного паттерна ошибок. Код вроде переносим, но не совсем. И не в Windows выявлен не будет. Сюда написал, первое что попалось под руку. Уверяю, можно подыскать и другие примеры.
Не понимаю, поясните.
Дано: общий код, который используется и под Windows, и под Linux. Запускаем PVS-Studio под Linux. Если в каком-то конкретном общем участке кода есть ошибка, то она будет выявлена вашим алгоритмом, так? Ему же пофигу, в какой среде он исполняется, правила-то одни и те же.
Глюки, которые проглатываются msvs и выскакивают в gcc (равно как и наоборот) мы не рассматриваем — у вас ведь полностью свой анализатор, я правильно понимаю?
Дано: общий код, который используется и под Windows, и под Linux. Запускаем PVS-Studio под Linux. Если в каком-то конкретном общем участке кода есть ошибка, то она будет выявлена вашим алгоритмом, так? Ему же пофигу, в какой среде он исполняется, правила-то одни и те же.
Глюки, которые проглатываются msvs и выскакивают в gcc (равно как и наоборот) мы не рассматриваем — у вас ведь полностью свой анализатор, я правильно понимаю?
Правила одни и те-же. А типы разные. В Linux тип SOCKET будет знаковым и никакую ошибку выявить невозможно. Конкретно для данного случая можно сделать особое правило. Но в целом, при смене типов что-то будет по другому. По хорошему, вообще надо проверять в разных режимах. В прочем это тема требует отдельного рассмотрения. Я просто хотел показать, что всё всегда сложнее, чем кажется. И успешные тесты обобщенного кода в одной системе, не обязательно гарантируют работоспособность в другой.
Ваш пример выше отлично иллюстрирует, что даже когда типы имеют одинаковое название, все равно платформо-специфичная реализация выносится в отдельный класс, а там уже и инклюды свои, и код тоже свой, и компилироваться он будет только под свою платформу.
В вебките это повсеместно (достаточно заглянуть хотя бы в любой подкаталог в Source/WebCore/platform/* или любом другом компоненте), и у меня очень сильное подозрение, что в Хромиуме используется тот же подход.
В вебките это повсеместно (достаточно заглянуть хотя бы в любой подкаталог в Source/WebCore/platform/* или любом другом компоненте), и у меня очень сильное подозрение, что в Хромиуме используется тот же подход.
Нет. Вы не осознали глубину всех глубин. :)
Вот код (это не Chromium, но не суть важно):
Код общий. Однако, как будет работать хеш-функция зависит от платформы. Беда — обрезание старших битов при явном приведении типа "(unsigned long)ptr". Причина — разная модель данных (long может быть 32-битным или 64-битным в 64-битных программах).
Вот код (это не Chromium, но не суть важно):
static int hash_void_ptr(void *ptr)
{
int hash;
int i;
hash = 0;
for (i = 0; i < (int)sizeof(ptr)*8 / TABLE_BITS; i++)
{
hash ^= (unsigned long)ptr >> i*8;
hash += i * 17;
hash &= TABLE_MASK;
}
return hash;
}
Код общий. Однако, как будет работать хеш-функция зависит от платформы. Беда — обрезание старших битов при явном приведении типа "(unsigned long)ptr". Причина — разная модель данных (long может быть 32-битным или 64-битным в 64-битных программах).
Хорошо. Как работает — зависит от платформы. А PVS-Studio предупреждение выдаст тоже в зависимости от платформы? Если она будет запущена на «беспроблемной» платформе, то предупреждение выдано не будет?
Конечно, не будет. Псевдокод:
На что ругаться, если это не Win?
#if define(_WIN32) typedef UINT_PTR MY_HANDLE; #else typedef long MY_HANDLE; #endif MY_HANDLE x = foo(); if (x < 0) Error();
На что ругаться, если это не Win?
>На что ругаться, если это не Win?
Эта фраза куда лучше смотрится вне контекста ;)
Ну а в целом проблема понятна: код, который написан под один-единственный компилятор, когда программист ни сном ни духом не ведает, что байтовые размеры типов могут как бы и отличаться — такой код нужно проверять полностью на каждой платформе.
Было бы очень интересно посмотреть на наличие таких косяков именно в коде Вебкита/Хромиума. И это как раз очень важно ;)
Эта фраза куда лучше смотрится вне контекста ;)
Ну а в целом проблема понятна: код, который написан под один-единственный компилятор, когда программист ни сном ни духом не ведает, что байтовые размеры типов могут как бы и отличаться — такой код нужно проверять полностью на каждой платформе.
Было бы очень интересно посмотреть на наличие таких косяков именно в коде Вебкита/Хромиума. И это как раз очень важно ;)
И этого оффера скорее всего не будет, пока не появятся порты PVS на Linux и OS X.
на с траницу с англоязычной версией неплохобыло бы добавить возможность комментировать статью
Можно комментировать на ycombinator.
Ошибка в tcmalloc присутствовала еще в прошлый раз. Тогда PVS не умел находить ошибки такого рода, или по какой-то причине пропустил ее?
Если ошибка существует давно, то возможны 3 варианта:
1) Не умел. Анализатор постоянно развивается. Причем добавляются не только новые диагностики, но и совершенствуются старые.
2) Я просто её просмотрел в прошлый раз.
3) Статьи получаются слишком большие и мне приходится иногда исключать описание некоторых предупреждений. Иначе это уже будет не статья, а безжалостный скучный отчёт.
1) Не умел. Анализатор постоянно развивается. Причем добавляются не только новые диагностики, но и совершенствуются старые.
2) Я просто её просмотрел в прошлый раз.
3) Статьи получаются слишком большие и мне приходится иногда исключать описание некоторых предупреждений. Иначе это уже будет не статья, а безжалостный скучный отчёт.
Я правильно понимаю, что вы отредактировали build.ninja? Он ведь генерируется. Это нормально для ручной проверки, но плохо для проверки на билдботах. Ожидаемый интерфейс для подобных вещей это GYP-variables и переменные среды. С правкой build.ninja можно жить, но разработчикам это не понравится.
Немного оффтоп, но я зашел на сайт узнать стоимость PVS-Studio и не нашел ее, вместо этого мне предлагают обратиться к поддержке. Я не потенциальный покупатель, но даже мне это показалось странным. На сайтах расширений, которыми я пользуюсь стоимость указывают (ReSharper, NCrunch). У меня возникло ощущение, что вы можете менять стоимость в зависимости от платежеспособности клиента у это не вызывает положительных ассоциаций.
Может это одна из причин, по которой Гугл не хочет использовать PVS-Studio?
Может это одна из причин, по которой Гугл не хочет использовать PVS-Studio?
Может это одна из причин, по которой Гугл не хочет использовать PVS-Studio?
Уж точно не причина
При этом у них везде написано что типа у них цены прозрачные и не зависят от объемов проекта :)
Вот тут все расписано. Там целая история, а внизу статьи есть цены.
Да, спасибо, интересно прочитать. Ту статью я пропустил. Но не каждый додумается искать цену инструмента на хабре.
А почему бы не написать в поддержку?
Как я писал выше, я не собирался покупать продукт, но интересен был порядок цен. И мне показалось странным что цены скрываются от пользователя.
А касательно других инструментов — цена на сайте помогает быстро сориентировать стоит ли дальше интересовать инструментом или нет. Например, ReSharper и NCrunch порядка $160 — приемлемо, а Xamarin за $999 за платформу — неприемлемо.
А касательно других инструментов — цена на сайте помогает быстро сориентировать стоит ли дальше интересовать инструментом или нет. Например, ReSharper и NCrunch порядка $160 — приемлемо, а Xamarin за $999 за платформу — неприемлемо.
Удивляют комментарии от тех, кто не собирается покупать продукт, но считает просто необходимым высказаться.
Я стараюсь писать комментарии по делу. И мне кажется, это как раз тот случай, когда комментарий стоило написать. Меня удивляет ваша реакция, ведь обратная связь от сообщества должна высоко цениться.
Меня удивляет количество людей, которым продукт не нужен, но считают своим долгом оставить комментарий и посоветовать как надо правильно. Из-за этого реально полезные отзывы оказываются пропущенными.
Если я знаю ценовую политику на инструмент заранее, и попадаю в проект, в котором он пригодится — обычно я могу сразу сказать/порекомендовать приобрести.
К примеру, зная, что бюджет на одну покупку до $300, я не стану рекомендовать выедать мозг через «request a quote» на продукты SciTools, когда есть более чем вписывающийся в этот бюджет и под требования Source Insight.
Но это ничто. А вот вопрос «качественная поддержка либо кряк» звучит поинтереснее.
К примеру, зная, что бюджет на одну покупку до $300, я не стану рекомендовать выедать мозг через «request a quote» на продукты SciTools, когда есть более чем вписывающийся в этот бюджет и под требования Source Insight.
Но это ничто. А вот вопрос «качественная поддержка либо кряк» звучит поинтереснее.
1. А где баг репорты в проекте хромиум? code.google.com/p/chromium/issues/list (может по этому и не пишут вам)
2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
4. Как я вижу, большинство ошибок не в самом хромиуме, а во всяких инкапсулированных библиотеках. Благо хоть WebKit они мучают без оглядки на Apple…
2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
4. Как я вижу, большинство ошибок не в самом хромиуме, а во всяких инкапсулированных библиотеках. Благо хоть WebKit они мучают без оглядки на Apple…
Баг-репорты в Chromium пишут тут: crbug.com.
и оно редиректит на code.google.com/p/chromium/issues/list…
2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
Отлично. Вот только вопрос, почему тогда я нашел эту ошибку? :)
Быть может, мы делаем что-то лучше?
3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
Думаю, у некоторых от этой фразы будет истерический смех.
Отлично. Вот только вопрос, почему тогда я нашел эту ошибку? :)
Быть может, мы делаем что-то лучше?
1. Видимо народ не особо смотрит на ворнинги при -Wall
2. Безусловно вы делаете, что то лучше иначе не было бы в вас смысла. К тому же вы узкоспециализированный инструмент и вы можете «бить в одну точку»…
Думаю, у некоторых от этой фразы будет истерический смех.
Если вы про то, что гугл и так использует Valgrind то я знаю — видимо мало смотрят. Если вы про то, что Valgrind находит мало ошибок — достаточно, коль даже их пропускают. Лучше поясните причину смеха этих «некоторых».
После огромных усилий, которые Google тратит на написание надежного кода, создания специальных инструментов для поиска ошибок, учреждает награду за поиск ошибок, брошенная в воздух фраза «могли бы тем же Valgrind помучать хотя бы», звучит как злая усмешка.
Видимо все их усилия не очень хорошо окупаются. Почему? Вот это и есть вопрос. Судя по тому, что не исправлены стандартные предупреждения gcc то либо у них нету времени на вылизывание кода (тесты проходит и ладно), либо они в целом этим не занимаются.
занимается отдельный отдел, который хорошо себя пиарит.
Я не утверждаю всё выше написанное, это только догадки. А вы думаете это всё потому, что их инструменты плохи и они просто не видят всех этих ошибок?
создания специальных инструментов для поиска ошибок
занимается отдельный отдел, который хорошо себя пиарит.
Я не утверждаю всё выше написанное, это только догадки. А вы думаете это всё потому, что их инструменты плохи и они просто не видят всех этих ошибок?
Нет, просто писать программы сложно. И все допускают ошибки.
Тогда ещё один инструмент поиска ошибок погоды не сделает, и серебряной пули для ошибок проекта не станет.
Вы думаете компания разработчик софта надеется на серебряную пулю?
Нет конечно, но внедрение чего то должно быть обоснованно как логически так и экономически.
Каков будет эффект от внедрения вашего продукта если они уже используют много чего, но продолжают пропускать -Wall?
Каков будет эффект от внедрения вашего продукта если они уже используют много чего, но продолжают пропускать -Wall?
Почему Вы думаете, что в Chromium не используется -Wall?
Кто сказал, что не используется!? Просто игнорируется его вывод… :) выше же нашли ошибки/предупреждения которые отлавливает gcc.
И даже
Однако, не в сторонних библиотеках — по весьма прагматическим причинам…
-Werror вроде как используется.Однако, не в сторонних библиотеках — по весьма прагматическим причинам…
Об этом я то же писал. Теперь вопрос к PVS почему они приводят примеры ошибок из сторонних библиотек? :)
Чтоб страшнее получилось ;)
Потому, что Chromium более чем на половину состоит из сторонних библиотек. Впрочем, какие они сторонние, если над многими работают всё те же люди.
Судя по тому, что не исправлены стандартные предупреждения gcc то либо у них нету времени на вылизывание кода (тесты проходит и ладно), либо они в целом этим не занимаются.
Это происходит потому, что сейчас Windows-версия Chromium собирается не с помощью GCC, а с помощью MSVC.
В долгосрочных планах переход на clang, когда он начнет хорошо работать под Windows (работы над этим ведутся при активном участии разработчиков из Google).
Плюсую за «а где баг репорты в проекте хромиум?»
и минусую за «могли бы тем же Valgrind помучать хотя бы»
build.chromium.org/p/chromium.memory.fyi/console
и минусую за «могли бы тем же Valgrind помучать хотя бы»
build.chromium.org/p/chromium.memory.fyi/console
Как я писал выше, я знаю что проект использует активно valgrind и прочие инструменты. Похоже я слишком резко высказался… мысль была такая: «по чаще бы они смотрели в Valgrind» :)
Ещё как смотрят!
Билдботы автоматически отправляют разработчикам персонализированный email «ты сломал вот это вот здесь» в течении 30-90 минут с момента коммита в репозиторий.
Билдботы автоматически отправляют разработчикам персонализированный email «ты сломал вот это вот здесь» в течении 30-90 минут с момента коммита в репозиторий.
Но ведь ошибки всё равно есть. :) И это похоже не по тому, что у них нету PVS.
Я думаю тут скорее проблема не в том, что «не все смотрят выдачу валгринда», а в том что динамический анализ (valgrind, etc) принципиально не может находить некоторые виды ошибок, которые может находить статический анализ (PVS).
Уверен на 146%, что если бы в хроме не применялся тот же Valgrind, AddressSanitizer и кучу чего ещё, то PVS находил бы не десяток интересных ошибок раз в полгода, а гораздо-гораздо больше.
Уверен на 146%, что если бы в хроме не применялся тот же Valgrind, AddressSanitizer и кучу чего ещё, то PVS находил бы не десяток интересных ошибок раз в полгода, а гораздо-гораздо больше.
Довольно странное у вас представление о баг-репортах…
Покажите, пожалуйста, как надо. На примере этой заметки.
Посмотрите внимательнее на коммент #2.
Что это значит?
Разработчики Chromium (N штук) прочитали ваш пост, после чего каждый второй
— полез в багтрекер искать «а не зафайлил ли уже вот эту конкретную ошибку кто-то ещё»,
— обнаружил что «не зафайлил» (90% далее были побеждены ленью...).
— начал файлить багрепорт, копипаст, всё такое.
Потом pkasting@ добавил зависимости части этих багов основному метабагу.
Минусы для Chromium:
1) сам по себе баг «посмотрите вот эту ссылку, там куча найденных ошибок» не несёт полезной информации, учитывая что ссылка на каждый новый пост про Chromium на вашем сайте мгновенно появляется на chromium-dev
2) с момента public disclosure (а ведь это могут быть и security баги, за которые Chromium даёт четырёхзначные награды) до момент фикса проходит лишние несколько часов/дней просто из-за того, что кто-то должен зафайлить и т.п.
3) часть найденных багов может потеряться по дороге (не факт, что это происходит на практике)
Минусы для вас:
1) У багов, найденных PVS, нету в трекере лейбла «найдено PVS studio», поэтому их сложнее искать
2) Даже если бы такой лейбл был, количество находимых багов получилось бы заниженным, т.к. не всем багам заводится issue
3) Вы не можете/вам неудобно следить за прогрессом по багам, например «пофикшено», «ой какая классная система», «баг неинтересен», «бага нет».
Рекомендация:
Находите новую багу — зафайлите crbug.com/new независимо от желания писать в обозримом будущем пост.
Баги вполне можно файлить в формате «имя файла с ошибокй, сниппет кода, очень краткое объяснение ошибки», без нерелевантной мишуры из серии «UserAgent».
Когда зафайлили критическую массу багов — пишете пост «как обычно», для каждой ошибки указывая ссылку на её crbug.
Вкратце, у вас сейчас получается «пост и баг, ссылающийся на пост», а я предлагаю «баги и пост, ссылающийся на баги».
То же могу посоветовать и для других опенсорс проектов.
Понимаю, что это немного лишней работы вашей команде (честно — действительно немного, я таких багов сотнями файлил и жив пока), которая на мой взгляд окупится вниманием и лояльностью.
Что это значит?
Разработчики Chromium (N штук) прочитали ваш пост, после чего каждый второй
— полез в багтрекер искать «а не зафайлил ли уже вот эту конкретную ошибку кто-то ещё»,
— обнаружил что «не зафайлил» (90% далее были побеждены ленью...).
— начал файлить багрепорт, копипаст, всё такое.
Потом pkasting@ добавил зависимости части этих багов основному метабагу.
Минусы для Chromium:
1) сам по себе баг «посмотрите вот эту ссылку, там куча найденных ошибок» не несёт полезной информации, учитывая что ссылка на каждый новый пост про Chromium на вашем сайте мгновенно появляется на chromium-dev
2) с момента public disclosure (а ведь это могут быть и security баги, за которые Chromium даёт четырёхзначные награды) до момент фикса проходит лишние несколько часов/дней просто из-за того, что кто-то должен зафайлить и т.п.
3) часть найденных багов может потеряться по дороге (не факт, что это происходит на практике)
Минусы для вас:
1) У багов, найденных PVS, нету в трекере лейбла «найдено PVS studio», поэтому их сложнее искать
2) Даже если бы такой лейбл был, количество находимых багов получилось бы заниженным, т.к. не всем багам заводится issue
3) Вы не можете/вам неудобно следить за прогрессом по багам, например «пофикшено», «ой какая классная система», «баг неинтересен», «бага нет».
Рекомендация:
Находите новую багу — зафайлите crbug.com/new независимо от желания писать в обозримом будущем пост.
Баги вполне можно файлить в формате «имя файла с ошибокй, сниппет кода, очень краткое объяснение ошибки», без нерелевантной мишуры из серии «UserAgent».
Когда зафайлили критическую массу багов — пишете пост «как обычно», для каждой ошибки указывая ссылку на её crbug.
Вкратце, у вас сейчас получается «пост и баг, ссылающийся на пост», а я предлагаю «баги и пост, ссылающийся на баги».
То же могу посоветовать и для других опенсорс проектов.
Понимаю, что это немного лишней работы вашей команде (честно — действительно немного, я таких багов сотнями файлил и жив пока), которая на мой взгляд окупится вниманием и лояльностью.
Роман, мы очень рады, что Вы заботитесь о качестве open-source. Вы можете очень легко помочь разработчикам Chromium. Скачайте исходные коды Chromium. Скомпилируйте. Если что-то не получится, мы или люди из Google подскажут. Мы с радостью бы дали уже имеющийся отчёт, но он на данный момент уже устарел. Напишите нам в почту. Мы выдадим Вам на время PVS-Studio, чтобы Вы имели возможность полноценно и внимательно проверить и проанализировать отчёт. После этого, разобравшись, что из сообщений является ошибкой и как её необходимо исправить, Вы сможете предложить репорты по их исправлению. Ведь я рассматривал только небольшую часть подозрительных мест. Общество Вам будет благодарно.
Ждём Вас с вопросами в почте.
Ждём Вас с вопросами в почте.
Пришлите мне лучше имеющийся отчёт, я разберусь с diff-ом исходников. Windows у меня нет ни на одной машине, а возиться с PVS и wine нет никакого желания.
Адрес моей почты можно получить, заменив подчёркивание в моём нике на точку и дописав в конце @ gmail.com.
Заодно посмотрю, что из отчёта найдёт анализатор clang.
Адрес моей почты можно получить, заменив подчёркивание в моём нике на точку и дописав в конце @ gmail.com.
Заодно посмотрю, что из отчёта найдёт анализатор clang.
Нет, так не пойдет. Вы опять просите нас сделать за вас работу?
сделать за вас работу
Нет, что вы. Наоборот, это я хотел сделать часть работы за вас. Но что-то в ответ вижу какие то унылые шуточки.
Если уж на то пошло, то инструменты вроде вашего как раз и должны делать нудную работу за разработчика. Ребята из JetBrains, к примеру, борятся за каждую мелочь, чтобы сделать процесс разработки приятнее. За это их очень многие любят.
Простите, а что именно не так в предложении?
Просьба, как по мне, вполне здравая, по крайней мере потому что у Вас этот отчёт уже есть, а время на полный анализ проекта, размерами с Chromium будет довольно большим, особенно если у roman_kashitsyn нет под рукой мощного сервера для такого анализа, ведь Cromium с сопутствующими библиотеками это несколько сотен МБ кода.
На счёт wine я тоже соглашусь, он, к сожалению, очень кривой, и при анализе такого большого объёма данных велика вероятность, что анализ в wine не удастся выполнить вообще по причине не стабильной работы :( А ставить Windows, пусть и в виртуалку довольно бестолковое занятие поскольку анализатору всё таки лучше дать ресурсов по максимуму, а накладные расходы на окружение минимизировать, я уже молчу о том, что эта затея выглядит странной для однократного использования.
p.s: у меня сейчас в wine под Ubuntu не ставятся даже редистрибутейбл от 2012 и 2013 студии, ставится только от 2010, при том не ставятся тихо, мирно, и совершенно молча, просто не запускаясь :( Сам мучаюсь с некоторым софтом, ибо нативную реализацию под *nix делать слишком накладно, а для работы в wine приходится либо функционал местами урезать, либо костыли городить, а самое обидное, что каждая следующая версия wine начинает вести совершенно иначе.
Просьба, как по мне, вполне здравая, по крайней мере потому что у Вас этот отчёт уже есть, а время на полный анализ проекта, размерами с Chromium будет довольно большим, особенно если у roman_kashitsyn нет под рукой мощного сервера для такого анализа, ведь Cromium с сопутствующими библиотеками это несколько сотен МБ кода.
На счёт wine я тоже соглашусь, он, к сожалению, очень кривой, и при анализе такого большого объёма данных велика вероятность, что анализ в wine не удастся выполнить вообще по причине не стабильной работы :( А ставить Windows, пусть и в виртуалку довольно бестолковое занятие поскольку анализатору всё таки лучше дать ресурсов по максимуму, а накладные расходы на окружение минимизировать, я уже молчу о том, что эта затея выглядит странной для однократного использования.
p.s: у меня сейчас в wine под Ubuntu не ставятся даже редистрибутейбл от 2012 и 2013 студии, ставится только от 2010, при том не ставятся тихо, мирно, и совершенно молча, просто не запускаясь :( Сам мучаюсь с некоторым софтом, ибо нативную реализацию под *nix делать слишком накладно, а для работы в wine приходится либо функционал местами урезать, либо костыли городить, а самое обидное, что каждая следующая версия wine начинает вести совершенно иначе.
Шелдон чувстовать сарказм.
Зря вы так. Если меня что-то не устраивает в open-source проектах и я могу это исправить — я это делаю.
Зря вы так. Если меня что-то не устраивает в open-source проектах и я могу это исправить — я это делаю.
Сомневаюсь, что сборка Chromium происходит под win. Без адекватного порта PVS смысла в нем мало.
А нерабочие && (указанные в документации) в конфиге ninja, это не знак ли того, что документация под *nix? Там это корректный оператор, а что в виндовом cmd с ним происходит — хз.
А нерабочие && (указанные в документации) в конфиге ninja, это не знак ли того, что документация под *nix? Там это корректный оператор, а что в виндовом cmd с ним происходит — хз.
Вы думаете, Chromium не собирается и не тестируется под win (в том числе под win)?
Сборка под win не подразумевает, что компилятор работает под win. Я именно про компилятор.
Gyp официально поддерживает генерацию проектов для Visual Studio, сборка под Visual Studio описана в официальной доке. Это как-то совсем было бы глупо — подписываться под поддержкой сборки под VS и при этом генерить бинарники каким-то раком под другими ОС.
Под Win используется Visual C++ 2012, которому к сожалению нужна винда.
Chromium под Windows компилируют с помощью Visual Studio, а Visual Studio на Linux не работает. Поэтому приходится собирать его под Windows. К тому же, все равно нужно пускать тесты под Windows. С кросс-компиляцией при тестировании возникает множество проблем, поэтому она используется только для arm'a.
У них, на мой взгляд, также достаточно ресурсов, чтобы допилить статический анализатор clang до нужного уровня. Возможно, разработчиков Chromium просто не особо задумываются о статическом анализе…
Нет, если уж допиливать, то анализатор Frama-C — допиливать много меньше, только поддержку C++ добавить.
допиливать много меньше, только поддержку C++ добавить
действительно, делов-то
С учётом масштаба инфраструктуры llvm и того факта, что большая часть разработчиков этого проекта работают в Google, вариант допиливания clang мне кажется более правдоподобным. Написали же они рантаймовые MemorySanitizer, AddressSanitizer, ThreadSanitizer, etc., да и статический анализ уже есть, только, быть может, не такой глубокий.
Ну, valgrind, к примеру, для Хрома используется.
Только мы не видим от них (Coverity, Klockwork) статей про то, как интегрировать их продукт с кодовой базой Chromium что-то…
У Klockwork очень удобный web-интерфейс отчетов, причем можно интегрировать в систему Code Review — таким образом происходит профилактика внесения ошибок, и удобство просмотра отчетов анализатора. Так же он интегрируется и с багтрекинговой системой — опять таки очень удобно.
Coverity интегрируется — инфа 100% ;)
Я — разработчик Chromium (хотя и не занимаюсь build infrastructure), так что могу высказать некоторые предположения, почему у нас не используется PVS-Studio.
1. Абсолютное большинство разработчиков используют Linux, так что напрямую использовать PVS не смогут. На втором месте из операционных систем, по-моему, OS X.
2. Большая часть инфраструктуры (билд, тест и т.д.) тоже на линуксе, и изменить это достаточно сложно.
Конечно, некоторое количество машин для сборки и тестирования на Windows есть, но добавить лишний сервис на Windows значительно сложнее, чем лишний сервис на Linux.
3. Chromium — open source проект и прилагаются усилия к тому, чтобы любой разработчик со стороны мог проделать с ним все необходимые действия: собрать, протестировать и т.д.
1. Абсолютное большинство разработчиков используют Linux, так что напрямую использовать PVS не смогут. На втором месте из операционных систем, по-моему, OS X.
2. Большая часть инфраструктуры (билд, тест и т.д.) тоже на линуксе, и изменить это достаточно сложно.
Конечно, некоторое количество машин для сборки и тестирования на Windows есть, но добавить лишний сервис на Windows значительно сложнее, чем лишний сервис на Linux.
3. Chromium — open source проект и прилагаются усилия к тому, чтобы любой разработчик со стороны мог проделать с ним все необходимые действия: собрать, протестировать и т.д.
И как это мешает отделу Google, который занимается выпуском Chrome, применять PVS-Studio и отправлять коммиты с исправленным кодом в Chromium?
Я ж говорю. Тем, что PVS-Studio не работает на Linux. Плюс, мне кажется неправильным, что такой вид тестирования будет доступен только отдельным разработчикам с лицензией.
Работает (в Wine). Мы не стали это в статье отмечать, что запускались в Linux. Скажем так, это интимный режим работы, который стоит обсуждать отдельно с потенциальными пользоателями. :)
Т.е. пусть лучше софт будет с багами, чем отдельные разработчики будут иметь софт с лицензией, которую им и сейчас ничего не мешает купить?
И создать особую тестовую среду для программу, которой пользуются сотни миллионов человек вроде довольно правильное решение, если это не чрезмерно сложно. Есть какая-то сложность, чтобы тестировать Chromium под Windows?
И создать особую тестовую среду для программу, которой пользуются сотни миллионов человек вроде довольно правильное решение, если это не чрезмерно сложно. Есть какая-то сложность, чтобы тестировать Chromium под Windows?
Софт будет с багами в любом случае, увы. Вопрос в их количестве, критичности и том, как наиболее эффективно использовать ресурсы, чтобы от них избавиться. Я пока не убеждён, что установка предлагаемого продукта себя оправдывает. (И я ничего на эту тему не решаю.)
> И создать особую тестовую среду для программу
Такая тестовая среда есть: build.chromium.org/p/chromium/waterfall
> Есть какая-то сложность, чтобы тестировать Chromium под Windows?
Да, есть. В рамках инфраструктуры Гугла поддерживать лишний сервис на Linux гораздо проще чем на Windows. Для Win нужна либо виртуализация, либо ручная поддержка серверов. Плюс, нужна обвязка, которая будет из общего билд-процесса будет вызывать какие-то операции на винде.
> И создать особую тестовую среду для программу
Такая тестовая среда есть: build.chromium.org/p/chromium/waterfall
> Есть какая-то сложность, чтобы тестировать Chromium под Windows?
Да, есть. В рамках инфраструктуры Гугла поддерживать лишний сервис на Linux гораздо проще чем на Windows. Для Win нужна либо виртуализация, либо ручная поддержка серверов. Плюс, нужна обвязка, которая будет из общего билд-процесса будет вызывать какие-то операции на винде.
Пробовали регистрироваться на Coverity Scan for Open Source?
Лично я — нет. Насколько я понимаю, настроить работу любого такого статического анализатора с Хромом — достаточно большая работа. (Кроме, быть может, Valgrind, который сразу с бинарником работает.)
Все правильно. И мы эту работу сделали.
Осталось всего ничего: сделать это для требуемой платформы, а не для той, которую вы посчитали нужной.
Мы это сделали в том числе и для Linux.
Судя по всему, вы сделали это для Wine, а не для Linux. Реакция немного предсказуема…
НЛО прилетело и опубликовало эту надпись здесь
>Дело в том, что я уверен, что Вы и eterevsky — самые обычные юниксовые красноглазики вот в каком смысле: вы поддерживаете позицию, что делать билд хрома зависимым от wine — плохо. Но! (тут потребуется Ваша честность в ответе на вопрос)
То есть я заранее в положении красноглазика, который сейчас попытается доказать, что он не красноглазик? :D Извините, но я принципиально не буду отвечать на вопрос, поставленный таким образом. Я давно вырос из возраста «в интернете кто-то неправ», а уж рассказывать про очевидные вещи «чем зависимость от Wine отличается от зависимости от Python» — это я даже не знаю…
Я не просто «задумывался» об этом, я совершенно точно знаю, почему это принципиально разные вещи.
То есть я заранее в положении красноглазика, который сейчас попытается доказать, что он не красноглазик? :D Извините, но я принципиально не буду отвечать на вопрос, поставленный таким образом. Я давно вырос из возраста «в интернете кто-то неправ», а уж рассказывать про очевидные вещи «чем зависимость от Wine отличается от зависимости от Python» — это я даже не знаю…
Я не просто «задумывался» об этом, я совершенно точно знаю, почему это принципиально разные вещи.
НЛО прилетело и опубликовало эту надпись здесь
Когда интересно, тогда вопросы задают более вежливо — это вам на будущее.
Не понимаю, почему у вас такой вопрос вообще возникает. Для получения ответа достаточно представить теоретическую, но воплне рабочую ситуацию: решение внедрили, и вдруг возникла проблема. Скажем, после очередного коммита в репозиторий процесс проверки начал завершаться с ошибкой. Что имеем в случае питоньих зависимостей? Имеем сами тесты, stack trace с указанием места ошибки, и полный набор инструментов для решения проблемы (начиная от кода тестов и заканчивая кодом интерпретатора питона). Что имеем в случае сабжа под Wine? Stack trace, на который смотрим, как баран на новые ворота: кода нет. Начинаем общение с разработчиками, разработчики отфутболивают к Wine, открещиваются от версии X, заявляют, что поддерживают только версию Y, и так далее и тому подобное. И я даже не беру в рассмотрение тот факт, что вероятности возникновения ошибки в интерпретаторе питона и в Wine различаются на пару порядков.
Минорный апдейт питона? Никто ничего не заметит. Минорный апдейт Wine? Здравствуйте, новые глюки, за которые никто не отвечает. Я был бы рад услышать от разработчиков PVS-Studio «мы будем поддерживать любую версию Wine на любом дистрибутиве», но я вам гарантирую, что этого мы не услышим — им для этого штат нужно будет в несколько раз расширить (куда больше, чем для создания нативного порта — но они ведь и этого не делают). А значит что? А значит максимум, что они выкатят — это поддержку конкретной версии Wine на конкретном дистрибутиве. И версия эта будет обновляться очень и очень неспешно, раз эдак в пару лет в лучшем случае.
И Гуглу предлагается за свои же деньги влезть в подобную кабалу? Да им проще Klocwork купить и не парить мозг. Ну и выплачивать премии за найденные баги.
Общая и главная мысль: сравнивать системы нужно не только с точки зрения «как оно работает», но и «что делать, когда оно не работает». Это не менее (а то и более) важный показатель при сравнительном анализе систем.
Не понимаю, почему у вас такой вопрос вообще возникает. Для получения ответа достаточно представить теоретическую, но воплне рабочую ситуацию: решение внедрили, и вдруг возникла проблема. Скажем, после очередного коммита в репозиторий процесс проверки начал завершаться с ошибкой. Что имеем в случае питоньих зависимостей? Имеем сами тесты, stack trace с указанием места ошибки, и полный набор инструментов для решения проблемы (начиная от кода тестов и заканчивая кодом интерпретатора питона). Что имеем в случае сабжа под Wine? Stack trace, на который смотрим, как баран на новые ворота: кода нет. Начинаем общение с разработчиками, разработчики отфутболивают к Wine, открещиваются от версии X, заявляют, что поддерживают только версию Y, и так далее и тому подобное. И я даже не беру в рассмотрение тот факт, что вероятности возникновения ошибки в интерпретаторе питона и в Wine различаются на пару порядков.
Минорный апдейт питона? Никто ничего не заметит. Минорный апдейт Wine? Здравствуйте, новые глюки, за которые никто не отвечает. Я был бы рад услышать от разработчиков PVS-Studio «мы будем поддерживать любую версию Wine на любом дистрибутиве», но я вам гарантирую, что этого мы не услышим — им для этого штат нужно будет в несколько раз расширить (куда больше, чем для создания нативного порта — но они ведь и этого не делают). А значит что? А значит максимум, что они выкатят — это поддержку конкретной версии Wine на конкретном дистрибутиве. И версия эта будет обновляться очень и очень неспешно, раз эдак в пару лет в лучшем случае.
И Гуглу предлагается за свои же деньги влезть в подобную кабалу? Да им проще Klocwork купить и не парить мозг. Ну и выплачивать премии за найденные баги.
Общая и главная мысль: сравнивать системы нужно не только с точки зрения «как оно работает», но и «что делать, когда оно не работает». Это не менее (а то и более) важный показатель при сравнительном анализе систем.
НЛО прилетело и опубликовало эту надпись здесь
>Я не увтерждал, что вы — красноглазики. Я только сказал, что я так думаю, а это — разные вещи
Вы сказали, что уверены в этом, а не «думаете», а это — разные вещи.
>А вы разработчиков спросили, готовы они поддерживать каждую новую версию Wine? Я вот уверен, что они готовы
А я вот уверен, что не готовы. Чья уверенность увереннее?
>А про минорный апдейт Wine — снова ваши домыслы, непонятно на чём основанные.
И вы, разумеется, снова в этом уверены?
Вот я, к примеру, уверен, что вы спорите ради самого спора. Вы просили поделиться моими соображениями — я это сделал, а вот непременно доказать вам свою точку зрения и в чем-то убедить — такого желания у меня как-то не возникает. Имеющий уши — да услышит.
Вы сказали, что уверены в этом, а не «думаете», а это — разные вещи.
>А вы разработчиков спросили, готовы они поддерживать каждую новую версию Wine? Я вот уверен, что они готовы
А я вот уверен, что не готовы. Чья уверенность увереннее?
>А про минорный апдейт Wine — снова ваши домыслы, непонятно на чём основанные.
И вы, разумеется, снова в этом уверены?
Вот я, к примеру, уверен, что вы спорите ради самого спора. Вы просили поделиться моими соображениями — я это сделал, а вот непременно доказать вам свою точку зрения и в чем-то убедить — такого желания у меня как-то не возникает. Имеющий уши — да услышит.
Я бы не отказался от возможности отказаться от Perl'a. А Apache я совсем не давно удалял из системы, после того, как мне его поставил скрипт установки зависимостей хрома (я не запускаю тесты, в которых он используется). А в этом баге люди уже второй год пытаются избавиться от cygwin'a: crbug.com/123026. Добавление новой зависимости для всех разработчиков — это очень плохо, добавление новой зависимости только для одного билдбота — нормально. Если же нужна группа билдботов, то уже нужно писать какие-то скрипты для автоматической установки/настройки и обновлять их. Задача значительно усложняется.
Вообще, в выборе между wine и нативным Windows, я бы предпочел нативный Windows. Дело в том, что когда программу пускают десять/сто раз в день при распараллеливании на один-другой десяток процессоров, программы начинают сбоить самыми загадочными способами. Разбираться в сбоях wine'a в дополнение к сбоям программы мне не хочется.
Вообще, в выборе между wine и нативным Windows, я бы предпочел нативный Windows. Дело в том, что когда программу пускают десять/сто раз в день при распараллеливании на один-другой десяток процессоров, программы начинают сбоить самыми загадочными способами. Разбираться в сбоях wine'a в дополнение к сбоям программы мне не хочется.
НЛО прилетело и опубликовало эту надпись здесь
Python содержит очень мало низкоуровневых API, реализация которых может вызвать сложности на Windows/Linux. Дополнительно, он хорошо защищен от многих проблем распараллеливания, поскольку использует процессы вместо потоков.
В Native Client, где POSIX-like api эмулируется поверх Windows и мы столкнулись с кучей проблем, когда некоторые вещи оказывается не возможным сделать на Windows. В Wine свое множество подобных проблем совместимости, которые готовы выстрелить в самый не подходящий момент параллельного билда. Когда количество запусков порядка десятка тысяч, проблемы начинают случаться регулярно. Если зависимость от wine будет на всех линуксовых ботах, проблемы будут случаться всегда. После этого, станет не возможным определение последней зеленой ревизии, которая используется, в частности, для релиза хрома.
PS По аналогичной причине не рекомендуется запускать 32-битный Native Client в виртуальной машине. Работа с сегментными регистрами в них плохо протестирована. Из-за этого возникают уязвимости, позволяющие выйти из сандбокса. 64-битный Native Client сегментных регистров не использует (да и не может использовать), поэтому работает под виртуальными машинами стабильно.
В Native Client, где POSIX-like api эмулируется поверх Windows и мы столкнулись с кучей проблем, когда некоторые вещи оказывается не возможным сделать на Windows. В Wine свое множество подобных проблем совместимости, которые готовы выстрелить в самый не подходящий момент параллельного билда. Когда количество запусков порядка десятка тысяч, проблемы начинают случаться регулярно. Если зависимость от wine будет на всех линуксовых ботах, проблемы будут случаться всегда. После этого, станет не возможным определение последней зеленой ревизии, которая используется, в частности, для релиза хрома.
PS По аналогичной причине не рекомендуется запускать 32-битный Native Client в виртуальной машине. Работа с сегментными регистрами в них плохо протестирована. Из-за этого возникают уязвимости, позволяющие выйти из сандбокса. 64-битный Native Client сегментных регистров не использует (да и не может использовать), поэтому работает под виртуальными машинами стабильно.
>Ты говоришь так словно в Wine полно багов и сбоев, гораздо больше, чем в том же Python
Вы так говорите, как будто вода мокрая, железо тяжелее воды, а на тело в окрестностях Земли действует сила притяжения, пропорциональная массе тела :)
>Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.
С одной конкретной версией PVS-Studio под одной конкретной версией Wine на одном конкретном релизе одного конкретного дистрибутива — да, проблем не возникло. Вас ничего не настораживает в этой цепочке? ;)
Вы так говорите, как будто вода мокрая, железо тяжелее воды, а на тело в окрестностях Земли действует сила притяжения, пропорциональная массе тела :)
>Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.
С одной конкретной версией PVS-Studio под одной конкретной версией Wine на одном конкретном релизе одного конкретного дистрибутива — да, проблем не возникло. Вас ничего не настораживает в этой цепочке? ;)
НЛО прилетело и опубликовало эту надпись здесь
>И всё же, я уверен, что у Вас данных, чтобы это утверждать никаких нет. А если и есть — то это сравнение работы тяжёлого софта на Wine против чего-то довольно простого на Питоне.
Интересно, на чем основывается ваша уверенность… Давайте так: я сообщаю вам, что участвовал в разработке проекта на Питоне, кодовая база которого перевалила за 300К строк (и это при том, что Питон — ну очень лаконичный язык), а вы обещаете, что больше не будете обобщать свой опыт на окружающих. Договорились? ;)
И были в этом проекте и сеть, и ORM, и multi-threading, и собственный REST-сервер с не одним десятком методов, и чего там только не было (то есть шансов напороться на грабли в интерпретаторе, сами понимаете, были весьма велики), однако интерпретатор фиксили буквально считаные разы, и то в основном для обхода GIL.
Но вообще мы отдалились от основной мысли. Даже если рассмотреть такой невероятный случай, что багов примерно одинаково, то процесс решения проблем с Python и с Wine+чья-то закрытая разработка различается кардинально.
Интересно, на чем основывается ваша уверенность… Давайте так: я сообщаю вам, что участвовал в разработке проекта на Питоне, кодовая база которого перевалила за 300К строк (и это при том, что Питон — ну очень лаконичный язык), а вы обещаете, что больше не будете обобщать свой опыт на окружающих. Договорились? ;)
И были в этом проекте и сеть, и ORM, и multi-threading, и собственный REST-сервер с не одним десятком методов, и чего там только не было (то есть шансов напороться на грабли в интерпретаторе, сами понимаете, были весьма велики), однако интерпретатор фиксили буквально считаные разы, и то в основном для обхода GIL.
Но вообще мы отдалились от основной мысли. Даже если рассмотреть такой невероятный случай, что багов примерно одинаково, то процесс решения проблем с Python и с Wine+чья-то закрытая разработка различается кардинально.
НЛО прилетело и опубликовало эту надпись здесь
1. Я фиксил баги в Wine, самолично для обхода некоторые проблем 1С 7.7. В том числе вручную портировал патчи итерософта в новые ветки. Код wine карйне сложен и нестабилен, а главное ОГРОМЕН по сравнению с интерпретатором Python.
2. Вы сравниваете тёплое с мягким — реализацию всего WinAPI (в том числе с различными интерпретаторами и компиляторами) и всего навсего, интерпретатор языка программирования (даже не компилятор! и без JIT). Они различаются как объёмом кода так и подходу к качеству разработки.
2. Вы сравниваете тёплое с мягким — реализацию всего WinAPI (в том числе с различными интерпретаторами и компиляторами) и всего навсего, интерпретатор языка программирования (даже не компилятор! и без JIT). Они различаются как объёмом кода так и подходу к качеству разработки.
Я не запускал Wine, но зато мне приходилось расследовать ошибки в cygwin, которые проявлялись при запуске компилятора. Более того, все найденные в cygwin ошибки проявлялись бы даже на программе которая использует из всего API только spawn/fork/exec (без каких-либо экзотических опций). Т.е. программе не нужно вызывать вообще никаких функций, чтобы cygwin начал сбоить при параллельной работе. Логично ожидать, что с wine тоже будут подобные проблемы. А находить их очень трудно. Поиск ошибки в cygwin'e занял больше месяца. Более того, вероятность сбоя часто сильно варьируется в зависимости от компьютера. В результате, к примеру, на локальном компьютере я первой нашел ошибку, которая на ботах встречалась в 10-100 раз реже, чем основная ошибка.
Ты говоришь так словно в Wine полно багов и сбоев, гораздо больше, чем в том же Python.Ну, а ты так говоришь, словно нет. Вот тебе пример: есть два компа с Ubuntu 12.04, на обоих стоит одинаковая версия Wine, на компах разные процы (Intel Core i5 и AMD Phenom II) и разные видюхи (Intel HD Graphics 2500 и GeForce 450 GTS). На первом крэшится даже инсталлятор Far Cry 3, на втором игра устанавливается и работает (с тормозами, разумеется). Вопрос знатокам: можно ли это назвать стабильностью и у кого подобное бывало с Python?
Хотя из того, что авторы PVS-Studio пишут про запуск на Linux можно сделать вывод, что у них никаких проблем с Wine не возникло.Странно, но я сделал вывод, что им удалось запустить PVS-Studio в Wine. Наверное, это потому, что я делаю выводы, выводя их логически, а ты выдаёшь желаемое за действительное. Я могу написать, что запустил Far Cry 2 в Wine с драйвером nouveau, но это не означает, что я в него смог поиграть, а не наблюдал вместо этого живописные чёрные леса и холмы без текстур на средних настройках и с дикими тормозами.
НЛО прилетело и опубликовало эту надпись здесь
Быть может, дело в hg-subversion? Far Cry 3 был просто приведён в качестве примера. Потрудись зайти на Wine AppDB, посмотреть, сколько приложений из общего количества имеют статус Platinum, и сделать соответствующие выводы. Напоминаю: Platinum означает, что все функции приложения работают не хуже, чем в Windows (полная совместимость).
Platinum — совсем не гарантирует, что работают все критичные функции — яркий пример Photoshop CS2 — не работает поддержка графических планшетов wacom — а без них по сути в большинстве случаев не возможно использовать программу по назначению. Скорее всего Platinum значит, что программа запускается и не должна падать в процессе работы.
>Раз они написали целый пост на хабре специально для гугла и в комментариях указали, что у них всё работает, значит проблем не было совсем или было мало и они их решили.
… или решили не заострять на них внимание, т.к. цель — продать продукт.
… или решили не заострять на них внимание, т.к. цель — продать продукт.
3. Chromium — open source проект и прилагаются усилия к тому, чтобы любой разработчик со стороны мог проделать с ним все необходимые действия: собрать, протестировать и т.д.
Все правильно. Не имею ничего против того, чтобы Google приобрел такую лицензию.
Вы имеете в виду запуск PVS-Studio в cloud? На серверах Google или на ваших?
Я имею ввиду, что если Google заинтересован в том, чтобы кто-то использовал в команде PVS-Studio — мы рады. Если Google заинтересован в том, чтобы ВСЕ разработчики Chromium использовали PVS-Studio (или могли) мы тоже рады. Как это реализовать — вопрос обсуждений и переговоров. Можем хоть программно-аппаратный комплекс продать, который будет выкачивать свежие исходники и проверять их :-).
Я просто пытаюсь представить модель того, как может быть устроено использование этого тула в билде Хрома. На данный момент почти все инструменты, используемые при сборке Хрома отвечают следующим требованиям:
1. Open source.
2. Работают под линукс и OS X.
3. Могут запускаться на билдботах.
4. Могут точно также запускаться на машине разработчика.
В случае PVS-Studio есть проблемы со всеми этими пунктами. Понятно, что если результат того стоит, то чем-то можно поступиться, но мне сходу вот неясно, стоит ли овчинка выделки.
1. Open source.
2. Работают под линукс и OS X.
3. Могут запускаться на билдботах.
4. Могут точно также запускаться на машине разработчика.
В случае PVS-Studio есть проблемы со всеми этими пунктами. Понятно, что если результат того стоит, то чем-то можно поступиться, но мне сходу вот неясно, стоит ли овчинка выделки.
Олег, Вы должны понимать, что наша маленькая команда сама себе зарабатывает деньги. И мы не можем просто так делать open source и под linux не имея финансирования. Есть ли в этом проблема? Да, есть :-).
Евгений, я понимаю, что ваша маленькая команда так зарабатывает деньги. Но это, к сожалению, не достаточный повод, чтобы Гугл покупал ваш продукт на неудобных ему условиях. It's just business.
Олег, а вариант, в котором облако PVS-studio будет брать dev-версию кода, анализировать и выдавать отчет в удобном для вас формате, возможен?
Это не вполне укладывается в существующую систему waterfall тестов и создаёт лишний, параллельный существующему механизм сообщения об ошибках. При том, что сборка Хрома — уже сейчас хрупкий и сложный процесс.
P.S. Согласен с этим комментарием.
P.S. Согласен с этим комментарием.
Евгений, вот от этого ответа вы могли бы и воздержаться, дабы не терять лицо.
Не нужно оправдываться. Вас никто не просит сейчас же, немедленно сделать ваш продукт open-source. И вам не стоит становиться в позу просителей, да еще перед человеком, который не принимает решения.
Зарабатывайте деньги и развивайте технологию без помощи Гугла.
Не нужно оправдываться. Вас никто не просит сейчас же, немедленно сделать ваш продукт open-source. И вам не стоит становиться в позу просителей, да еще перед человеком, который не принимает решения.
Зарабатывайте деньги и развивайте технологию без помощи Гугла.
Лично я вижу только один способ — запуск PVS-Studio на отдельном билдботе с Windows. Шерифы будут смотреть на отчеты, когда бот будет становится красным и откатывать изменения по git/svn blame. Учитывая время работы (при ежедневом обновлении webkit'a практически не избежна полная перекомпиляция проекта), запуск на трайботах или машине разработчика не имеет смысла. Люди из Build Infrastructure конечно Windows не любят, но процесс добавления или удаления ботов с Windows все равно происходит регулярно, так что они умеют это делать.
Программно-аппаратный комплекс? Xeon Phi?
Свершилось: PVS-Studio для Linux.
т.к. на данный момент анализатор PVS-Studio поддерживает только ОС Windows
1. Проприентарное.
2. Не кросс-платформенное.
И нафига оно сдалось?
1. Проприентарное.
2. Не кросс-платформенное.
И нафига оно сдалось?
И нафига вам комментировать, если нафига сдалось?
Может для того, что бы получить опровержение и доводы в сторону использования?
Доводы в сторону использования — найденные ошибки. В том числе, база ошибок в open source проектах, найденных с помощью PVS-Studio.
Их можно найти только используя ваш инструмент? Если нет, тогда он мало помогает делу.
Код можно скомпилоровать только с помощью Visual Studio? Нет, значит Visual Studio не помогает.
Если проект успешно использует mingw и в качестве редактора/IDE что то другое, то нет не помогает в задаче скомпилировать проект. Но вообще вы путаете тёплое с мягким. Причины использования VS и вашего инструмента различны, это совсем разного класса ПО.
Тут скорее другая аналогия: народ пропалывает грядки вручную, а вы предлагаете куртую и сложную технику для этого. Проблема не в том, что техника плоха или есть лучше конкуренты проблемы в том, что народ в принципе плохо смотрит на любую технику.
Если бы выбор был между инструментом 1 и вашим инструментом 2 который лучше то вопросов нету. Но выбора тут такого нету и он находится в другой плоскости.
Им бы начать по полной использовать те инструменты, что у них есть… и по больше времени на QA тратить.
Тут скорее другая аналогия: народ пропалывает грядки вручную, а вы предлагаете куртую и сложную технику для этого. Проблема не в том, что техника плоха или есть лучше конкуренты проблемы в том, что народ в принципе плохо смотрит на любую технику.
Если бы выбор был между инструментом 1 и вашим инструментом 2 который лучше то вопросов нету. Но выбора тут такого нету и он находится в другой плоскости.
Им бы начать по полной использовать те инструменты, что у них есть… и по больше времени на QA тратить.
Учитывая что цену не пишете, речь идет о четырехзначной цене на продукт. Не слишком ли дорого за полезный, но второстепенный тул? Visual Assist на 1 пользователя стоит от 99 долларов, и это не подписка.
Сделайте «indie» лицензию на 1 пользователя, плюс поддержку xcode (c++, objC не нужен) за фиксированную разумную цену — и я ваш.
Сделайте «indie» лицензию на 1 пользователя, плюс поддержку xcode (c++, objC не нужен) за фиксированную разумную цену — и я ваш.
70 тыс. рублей за огнетушитель — это слишком дорого? Больнице или нефтехранилищу — нет. Вам, вероятно, да, но у вас и риски не те.
Мне кажется, что, исходя из декларируемой функциональности и заявленной стоимости, очевидно, что инди-разработчики не являются целевой аудиторией данного продукта, и предъявлять компании какие-то претензии на эту тему бессмысленно.
Мне кажется, что, исходя из декларируемой функциональности и заявленной стоимости, очевидно, что инди-разработчики не являются целевой аудиторией данного продукта, и предъявлять компании какие-то претензии на эту тему бессмысленно.
Во-первых, исходя из декларируемой функциональности, я делаю вывод что данный софт мне потенциально интересен.
Никто не предъявляет претензии — в топике ясно написано «как мы пытаемся продать..». Я не гугл, но не думаю что автору статьи интересно послушать только гугл. Поэтому, со своей стороны высказываю условия, при которых захочу купить этот продукт. Дальше уже дело хозяина софта, решать — поддержать таких как я и предоставить льготные условия лицензирования, или продолжать жаловаться на гугл :).
Скромно предположу, что лучше продать тысячу индивидуальных лицензий по 99 долларов, чем одну энтерпрайзную гуглу, хоть и за 10-20k, тем более что ничего не мешает указать условия для дешевой лицензии, неприемлимые для больших и средних компаний. Поддерживать 1000 покупателей конечно сложнее, чем одного, но это тоже не непреодолимая проблема.
Никто не предъявляет претензии — в топике ясно написано «как мы пытаемся продать..». Я не гугл, но не думаю что автору статьи интересно послушать только гугл. Поэтому, со своей стороны высказываю условия, при которых захочу купить этот продукт. Дальше уже дело хозяина софта, решать — поддержать таких как я и предоставить льготные условия лицензирования, или продолжать жаловаться на гугл :).
Скромно предположу, что лучше продать тысячу индивидуальных лицензий по 99 долларов, чем одну энтерпрайзную гуглу, хоть и за 10-20k, тем более что ничего не мешает указать условия для дешевой лицензии, неприемлимые для больших и средних компаний. Поддерживать 1000 покупателей конечно сложнее, чем одного, но это тоже не непреодолимая проблема.
Вот если бы они не «пытались продать», а попытались сделать так, чтобы Гугл купил (а это разные вещи) — дело приняло бы совершенно другой оборот.
Но им уже который год твердят о Linux-порте (как раз в свете того, что крупные компании предпочитают держать билд-фермы именно на Linux), а они все отбрыкиваются «линуксоиды денег не платят, мы лучше знаем»…
Но им уже который год твердят о Linux-порте (как раз в свете того, что крупные компании предпочитают держать билд-фермы именно на Linux), а они все отбрыкиваются «линуксоиды денег не платят, мы лучше знаем»…
Учитывая, что подобные комментарии появляются практически в каждом топике про PVS Studio, полагаю, что автору уже давно неинтересно слушать инди-разработчиков.
Постойте-ка… вот, точно: неинтересно. И на то есть причины. И давайте уже заканчивать обсуждать ценообразование в топиках про PVS Studio: оно такое, как есть, оно обоснованно, оно зафиксировано, оно не изменится, и точка, об этом уже сто раз писали, авторам уже предлагали бизнес-модель, и даже угрожали, это было весело, но сейчас это уже не весело, это скучно, я не могу это больше видеть, зачем я всё это пишу, ааа, хватит, с меня хватит.
Давайте лучше обсуждать, почему порта на GNU/Linux нет, хотя бы закрытого. Mezomish дело предлагает :-)
Постойте-ка… вот, точно: неинтересно. И на то есть причины. И давайте уже заканчивать обсуждать ценообразование в топиках про PVS Studio: оно такое, как есть, оно обоснованно, оно зафиксировано, оно не изменится, и точка, об этом уже сто раз писали, авторам уже предлагали бизнес-модель, и даже угрожали, это было весело, но сейчас это уже не весело, это скучно, я не могу это больше видеть, зачем я всё это пишу, ааа, хватит, с меня хватит.
Давайте лучше обсуждать, почему порта на GNU/Linux нет, хотя бы закрытого. Mezomish дело предлагает :-)
Спасибо за обзорную экскурсию, теперь все ясно. Нет — так нет, все-равно у меня два необходимых условия было.
Без поддержки xcode (или в крайнем случае без интеграции, просто OSX) мне все-равно пока не нужно, VS не использую последние пару лет. Худо-бедный статический анализатор есть и в xcode, хоть он и хуже.
Без поддержки xcode (или в крайнем случае без интеграции, просто OSX) мне все-равно пока не нужно, VS не использую последние пару лет. Худо-бедный статический анализатор есть и в xcode, хоть он и хуже.
Давайте лучше обсуждать, почему порта на GNU/Linux нет,А что тут обсуждать? Очевидно, нет ресурсов и/или желания этот порт делать — я бы, кстати, тоже не стал. Тут я с создателями продукта согласен — разработчики под Linux это какая-то экзотика, плюс вряд ли они будут что-то покупать.
Разработчики по Linux экзотика? Вы серьезно?
Скорее разработчики крупных проектов под Windows экзотика.
OSX и Linux используется во всех крупных компаниях с которыми я имел дело за последние 5 лет.
Windows стоит только у менеджеров и остального планктона.
Скорее разработчики крупных проектов под Windows экзотика.
OSX и Linux используется во всех крупных компаниях с которыми я имел дело за последние 5 лет.
Windows стоит только у менеджеров и остального планктона.
«Используется» — для разработки коммерческих end-user решений? Не верю. Если все эти крупные компании связаны с Linux по роду деятельности — например, пишут какой-нибудь серверный софт или сугубо специфический (какие-нибудь управляющие станки на линуксе), то можно понять. Если же «крупная компания» делает коммерческий b2c софт, он должен запускаться под Windows, а значит и разрабатываться под Windows тоже. Это тупо удобнее, да и Visual Studio же.
Скоро мы узнаем, насколько Вы правы: PVS-Studio для Linux :). Или Linux версия разделит судьбу CppCat.
Большое спасибо. Приятно встретить понимание.
С текущей политикой компании, рядовому хабравчанину эта софтина не интересна. Я тогда совершено не понимаю зачем они тут пиарятся тем более на OpenSource проектах, мне это напоминает издёвку. Типо вон мы написали мега инструмент и нашли сколько ошибок у вас, но мы его вам не дадим и даже не продадим!
Говорите, пожалуйста, за себя, а не за «рядового хабравчанина». Этому мифическому герою, невзирая на абсолютную практическую неприменимость, почему-то чрезвычайно интересны посты про Curiosity, или вот про построение отказоустойчивого датацентра. Точно так же и здесь.
Я тут много чего написал… и в итоге стёр. В двух ваших примерах я понимаю какую новую информацию я получу (а значимость миссии НАСА так вообще трудно сравнивать с чем либо), но тут я не понимаю. Мы вроде и так знаем какие типы ошибок может отслеживать продукт, зачем нам ещё одно подтверждение? И не забывайте, что в начале поста они пафосно заявили, что хотят это продать в Google не имея даже unix версии и совместимости с gcc.
Предположим мне даже понравились возможности, но я даже купить не могу этот продукт, не говоря о том что Windows видел лет 10 назад, как дома так и на работе (Linux, FreeBSD, MacOSX винда только у менеджеров и бухов).
Ну и процитирую их:
т.е. статья не для нас с вами, а для гугла или разработчиков chromium (которые тут то же есть, но не большинство).
Одно дело помогать OpenSource, другое дело злорадствовать… про отсутствие багов в багтрекере по каждому пункту, уже сказали многие.
Ну и всё, выше сказанное я говорю за себя, надеюсь я тут не один такой.
Предположим мне даже понравились возможности, но я даже купить не могу этот продукт, не говоря о том что Windows видел лет 10 назад, как дома так и на работе (Linux, FreeBSD, MacOSX винда только у менеджеров и бухов).
Ну и процитирую их:
Поскольку мне интересно, что я делаю не так, и почему Google пока не использует PVS-Studio, я решил написать очередную статью.
т.е. статья не для нас с вами, а для гугла или разработчиков chromium (которые тут то же есть, но не большинство).
Одно дело помогать OpenSource, другое дело злорадствовать… про отсутствие багов в багтрекере по каждому пункту, уже сказали многие.
Ну и всё, выше сказанное я говорю за себя, надеюсь я тут не один такой.
Хороший отчёт, на этот раз ошибки веселее, чем в Geant4. Пишите ещё :-)
«Одноразовый» цикл — это немного «индусский», но корректный, метод получения первого элемента итератора, и NULL в случае пустого итератора.
Ага, использовал тут по рабочим нуждам кусок хрома — webrtc, бывший libjingle, там напихано всякой всячины в third_party типа openssl, jsoncpp, libjpeg, sqlite. У sqlite одного сотни тысяч тестов. Так что ничего удивительного, что десятки тысяч тестов прогоняются. Для продукта с миллионом возможностей это реально мало, это подтверждается тем, что ошибок в нём достаточно.
По поводу кода у меня ещё сложилось стойкое ощущение, что люди не пользуются ни нормальной IDE, ни анализаторами кода, не умеют разрешать зависимости, не знают, что такое git submodules, не осилили make, ещё основываются на том, что у всех установлен исключительно python2, остальным приходится ставить virtualenv или симлинкать python на python2. Firefox, конечно, не лучше со своим autoconf 2.13.
По поводу кода у меня ещё сложилось стойкое ощущение, что люди не пользуются ни нормальной IDE, ни анализаторами кода, не умеют разрешать зависимости, не знают, что такое git submodules, не осилили make, ещё основываются на том, что у всех установлен исключительно python2, остальным приходится ставить virtualenv или симлинкать python на python2. Firefox, конечно, не лучше со своим autoconf 2.13.
нормальной IDE
вы знаете нормальную IDE для с++?
не осилили make
make особенно удобен под windows, не так ли?
не умеют разрешать зависимости
поясните, пожалуйста, что вы имеете в виду
не знают, что такое git submodules
А зачем им знать, проект-то под svn
у всех установлен исключительно python2
это всё ещё основная стабильная версия python, разве нет?
Вы сами этот код видели? Не слишком понимаю, с чего бы после этого у вас столько вопросов возникло.
1. без понятия, но хотя бы одного стиля могли бы придерживаться
2. причиной для использования scons, а потом создания ninja была другая
3. действительно ли надо собирать {openssl,sqlite,...}, если достаточно было бы просто для рантайма требовать его установки в системе, а для сборки — его заголовков?
4. и, спрашивается, почему, потому что он структурирован плохо, а svn всё терпит?
5. отнюдь нет:
1. без понятия, но хотя бы одного стиля могли бы придерживаться
2. причиной для использования scons, а потом создания ninja была другая
3. действительно ли надо собирать {openssl,sqlite,...}, если достаточно было бы просто для рантайма требовать его установки в системе, а для сборки — его заголовков?
4. и, спрашивается, почему, потому что он структурирован плохо, а svn всё терпит?
5. отнюдь нет:
The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over two years of stable releases, including version 3.3 in 2012. This means that all recent standard library improvements, for example, are only available in Python 3.x.(источник)
There are two recommended production-ready versions at this point in time, because at the moment there are two branches of stable releases: 2.x and 3.x. Python 3.x may be less useful than 2.x, since currently there is more third party software available for Python 2 than for Python 3.
docs.python.org/3.4/faq/general
How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.
Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.
Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)
Guido van Rossum Answers Your Questions — August 26, 2013
Да, я видел код, когда пытался использовать gyp в своих проектах. Gyp, кстати, отлично задуман, но сыроват для использования вне chromium.
2. Какая, если не секрет?
3. И заставлять бедных виндовс-пользователей искать и устанавливать в систему зависимости? И долго разбираться с совместимостью различных версий 3-rd party библиотек?
Мне гораздо больше нравится идея hermetic builds.
4. Честно говоря, я большой фанат git. Я считаю его удивительной программой и каждый день удивляюсь, насколько это классный piece of software. Но вот конкретно git submodules я считаю неудачным. Слишком много непонятных ошибок возникает при использовании даже у опытных пользователей.
2. Какая, если не секрет?
3. И заставлять бедных виндовс-пользователей искать и устанавливать в систему зависимости? И долго разбираться с совместимостью различных версий 3-rd party библиотек?
Мне гораздо больше нравится идея hermetic builds.
4. Честно говоря, я большой фанат git. Я считаю его удивительной программой и каждый день удивляюсь, насколько это классный piece of software. Но вот конкретно git submodules я считаю неудачным. Слишком много непонятных ошибок возникает при использовании даже у опытных пользователей.
Переменная 'i' похожа на 1.
void SkCanvasStack::pushCanvas(....) { .... for (int i = fList.count() - 1; i > 0; --i) { SkIRect localBounds = canvasBounds; localBounds.offset(origin - fCanvasData[i-1].origin); fCanvasData[i-1].requiredClip.op(localBounds, SkRegion::kDifference_Op); fList[i-i]->clipRegion(fCanvasData[i-1].requiredClip); } .... }
Слабо заметить подозрительное? :) Анализатору нет.
Кстати — не слабо :) Тут явно видно, что код криво написан, i в цикле не используется вообще, используется только i-1, а это означает, что надо было это место сразу переписать по нормальному, ну т.е. ещё до того как это попало в репозиторий:
void SkCanvasStack::pushCanvas(....) {
....
for (int i = fList.count() - 2; i >= 0; --i) {
SkIRect localBounds = canvasBounds;
localBounds.offset(origin - fCanvasData[i].origin);
fCanvasData[i].requiredClip.op(localBounds,
SkRegion::kDifference_Op);
fList[i]->clipRegion(fCanvasData[i].requiredClip);
}
....
}
p.s: ну или хотя бы мантейнер должен был отправить такое на ревью до того как это попало в основную ветку.
p.p.s: и я не знаю какая была логика, хоть она и сохранилась, но у меня ощущение, что они тут обрабатывают не все данные.
Вот и ещё одна идея от диагностики ;)
fList.count() - 1 а потом i-1
fList.count() - 2
Вот и ещё одна идея от диагностики ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы пытаемся продать PVS-Studio в Google или очередные ошибки в Chromium