Пиалу можно использовать для горячих напитков, так как вы держитесь за верхную негорячую часть. У термокружек можно игронировать ручку по совершенно другой причине — стенки неохотно пропускают тепло. При чём тут подстаканники я не понимаю — они превращают стакан в кружку и всё.
Кстати, вы уверены, что хотели ответить именно на этот мой комментарий? Я про пиалы и про стаканы не говорил ничего в этой теме вообще и в данном комментарии в частности.
Их можно разбить тряской, сильной тряской при закрытой крышке или просто оттрясти так, чтобы они попали в кружку не вам. Если конгломерат таков, что тряской его разбить нельзя, то это свидетельствует о загрязнении сахара неизвестными жидкостями. В последнем случае лучше поискать другую сахарницу, а не идти искать ложку.
В любом случае для того, чтобы не заметить такой конгломерат, нужно смотреть куда‐то в сторону. А если вы его смогли заметить, то сможете и принять меры.
И, кстати, я и раньше рассматривал использование ручек как вынужденное зло (в них постоянно не лезет то количество пальцев, которое я хочу туда засунуть, а даже если и лезет, то рука устаёт гораздо быстрее из‐за бо́льшего рычага). Так что не надо уговариваться на ручки, без них гораздо лучше. Тем более, что в вашем варианте их практически неизбежно будет две (или чашка будет кривой для компенсации ручки), что исключит возможность проигнорировать ручку и взять так.
Нормально горячие стаканы живут без ручек. Главное — стенки потолще, а лучше и вовсе двойные. Я у своей термокружки ручку (складную) не использую, т.к. двойные стенки отлично держат тепло там, где ему самое место — в напитке. Видел кружку без ручек с очень толстым стеклом, используемую для горячих напитков.
У меня и у секретарши в офисе компании, где я работаю, есть кружки, которым не нужны ручки. У меня — металлическая с двойными стенками (термокружка), у секретарши — стеклянная с очень толстыми стенками. Правда у меня ещё есть выбор (складная ручка, обычно прижата к кружке за ненадобностью), а у секретарши — нет.
Может достаточно просто увеличить толщину стенок. И, кстати, вы принципиально не рассматриваете то же самое, но из металла?
Берёте сахарницу, наклоняете над кружкой, трясёте. Если точность не нужна, а диаметр сахарницы не приближается к бесконечности (из слишком широких сахарниц сахар попадёт не только в кружку), то такой способ вполне работает.
Разумеется. hg grep ищет по всей истории и является частичным эквивалентом git log -S, git grep ищет либо в конкретной ревизии (одной!), либо в рабочем каталоге. Не надо сравнивать их скорость, это команды для разных целей. Используйте обычный grep с hg locate, если вам нужен git grep.
У git есть две реализации на C: libgit2 (ещё не закончена, но по большей части работает; предназначена для использования в качестве библиотеки и иногда быстрее (т.к. не надо создавать новый процесс и не надо парсить его вывод), иногда наоборот (сам код библиотеки иногда медленнее, возможно сейчас частично или полностью исправили)) и привычный клиент git (но здесь уже не только C:
Это похоже на кусок кода, используемого для отладки. Там вполне могло быть незаметно. Возможно даже malloc(0) всё время возвращал что‐то, куда можно записать требуемое число байт — я не знаю, что конкретно значит «a zero-length item in the heap»: если этот элемент всё время выделяется на странице, доступной для записи (а зачем выделять где‐то ещё?) и после него достаточно свободного пространства (или не свободного, но занятого чем‐то некритичным), то всё вполне могло работать.
У veracity на редкость неинформативный сайт. Попытался посмотреть, не добавили ли они поддержку (hg|bzr|svn|fossil) cat/git cat-file, а документации нет. И QA, где я видел (или задавал?) вопрос про эту возможность, недоступен.
Хотя после установки видно — всё же добавили. Только они единственные догадались зачем‐то после содержимого файла добавлять лишную новую строку, так что нельзя делать vv cat -rN foo.png > bar.png. И назвать это своё поведение «UNIX-style cat»! Впрочем, vv cat нельзя делать и по другим причинам: почему‐то изображение, на котором я проверял было обрезано с 189k до 1,4k.
Если что, то issue tracker’а нет, список рассылки закрыли, даже Q&A недоступен, поэтому пожаловаться разработчикам не представляется возможным.
В сообщении, на которое вы отвечаете ясно написано, что не работало. Но будь это обыкновенная snprintf, созданная в соответствии с C99, всё было бы в порядке: значит, вероятно, разработчики, не читая MSDN, решили, что микрософтские функции работают в соответствии с C99 (хотя таких функций там нет).
Для C есть различные решения вроде -fsanitize=bounds (для случаев, когда размеры массива могут быть определены статически) (clang), -fsanitize=memory и -fsanitize=address (проверяют чтение из неинициализированной памяти (первый) и выход за границы массива и различные другие ошибки вроде использования памяти после освобождения (второй)). И ещё есть valgrind и аналоги. Всё‐таки, C/C++ — это языки программирования с огромным количеством различных программ для разработчиков, проверяющих всё, что только можно. Delphi такое и не снилось (хотя тот же valgrind можно использовать для любой программы, статические анализаторы и sanitizer’ы clang’а и gcc — нет).
Другой вопрос, что внедрение всех этих статических анализаторов, sanitizer’ов и отладчиков, с последующим анализом и исправлением, гораздо более трудоёмкий процесс, чем включение нескольких опций компилятора.
Да ему даже не надо было FAQ читать: прямо в статье написано «и, конечно, статический анализ с помощью PVS-Studio» в списке методов, используемых для тестирования.
Я бы так не сказал. Каждый раз, когда я смотрю fish мне там чего‐то не хватает. То $var:a:h (полное имя каталога, в котором находится файл из данной переменной), то математики (обёртка над bc — это совершенно не то: попробуйте поработать с шестнадцатиричными цифрами), то автодополнения (оно есть для гораздо меньшего числа команд, нежели в bash или zsh), то нормального разбиения на аргументы ((command) разобьёт по новым строкам, если вы не станете трогать IFS, причём в документации об IFS не написано ничего (единственное упоминание — в документации read)). Короче, моё впечатление:
Zsh может всё, что делает fish.
Кроме fish autosuggestions. Zsh их тоже теоретически может (есть даже набор скриптов для получения fish‐подобных подсказок), но только используя набор хаков.
И подсветки. Она есть, она как бы работает, но для неё нет нормального парсера. Людям надо было писать его на perl или python, а не на zsh. Сейчас можно допилить pygments и взять мой zpython, но это более новый проект, чем zsh-syntax-highlighting.
Кроме вышеуказанных двух пунктов в fish нет ничего хорошего. Привычные по zsh возможности для написания скриптов в fish либо отсутствуют полностью, либо требуют очень много текста.
Во‐первых, куда вы дели обновления каталогов? В FAT не сохраняется информация о расположении файлов, она есть в каталогах. Во‐вторых, куда делась запись лишних (размер кластера − (размер файла mod размер кластера)) для каждого файла? Даже в случае, если вы с помощью кэширования дадите планировщику разобраться с оптимальным способом записи, от этих двух пунктов вас ничего не избавит.
В случае с архивом вы пишете 2 записи в FAT, одну в каталог, большой непрерывный кусок архива (с небольшим хвостиком из‐за кластеров) и всё. Возможно большой кусок будет разбит на несколько из‐за фрагментации, но при записи файлов это будет гораздо более вероятно (т.к. из‐за кластеров размер увеличивается, да и драйвер наверняка попытается втиснуть каждый файл в наиболее мелкую из имеющихся дырок).
Ага. Теперь вместо того, чтобы ждать N минут, пока скопируются все файлы, вам придётся ждать N минут, пока флэшка безопасно извлекается.
Кэш не позволит ни взять файлы с флэшки быстрее, ни записать файлы на неё быстрее: эти скорости ограничены пропускной способностью контроллера или скоростью чипов флэшки и кэш не способен исправить ничего из этого. Он нужен только в двух случаях: когда вы не собираетесь вынимать флэшку и хотите полюбоваться на быстрый прогресс‐бар или когда вы хотите прочитать файлы с флэшки два раза. В обоих случаях: и имеете достаточно оперативной памяти, чтобы хранить там файлы, с которым работаете.
Zip нужен для того, чтобы превратить случайные чтение/запись многих мелких файлов в последовательные одного большого архива: последовательные чтение/запись до сих пор быстрее случайных во всех хранилищах.
Кроме того, в FAT есть минимальный размер файла (равный размеру одного кластера). Каждый записываемый файл будет дополнен так, чтобы иметь размер, кратный минимальному. Пишет ли система что‐либо в «лишнее» место или нет — неважно: если она пишет — плохо — увеличивается объём данных, которые надо записать; если нет — плохо — теперь никакой планировщик не превратит случайную запись в последовательную. И вам в любом случае придётся изменять каталоги и таблицу FAT (причём последнее два раза) и для каждого файла — т.е. на один файл приходится не менее четырёх мест, которые надо изменить: таблица FAT (основная и резервная копия), каталог, в котором файл хранится, и само содержимое файла в области данных.
gzip никуда деваться не собирается, а вот bzip2 медленно, но верно, уступает xz. Когда мне нужно что‐то запаковать я обычно выбираю tar+xz, tar+gz, zip, 7z (последний для пользователей Windows, если нужно сжатие лучше, чем с zip или для текстовых файлов, которые я не собираюсь распространять (с -m0=ppmd)).
Интересно, почему все забили на 7z+PPMD? Я как‐то раз пробовал сжать лог сборки OpenOffice им, получился в 1,3 раза более компактный файл (7z -m0=ppmd -mx=9 в сравнении с xz -9), при этом создавался он в 4 раза быстрее.
В вашем примере «is» относится к «this», не к «data». Хотя «this» и надо согласовывать с «data» в этой фразе, лучше взять что‐то вида «The referenced data is invalid», где «is» относится к «data» непосредственно.
Кстати, вы уверены, что хотели ответить именно на этот мой комментарий? Я про пиалы и про стаканы не говорил ничего в этой теме вообще и в данном комментарии в частности.
В любом случае для того, чтобы не заметить такой конгломерат, нужно смотреть куда‐то в сторону. А если вы его смогли заметить, то сможете и принять меры.
Может достаточно просто увеличить толщину стенок. И, кстати, вы принципиально не рассматриваете то же самое, но из металла?
hg grepищет по всей истории и является частичным эквивалентомgit log -S,git grepищет либо в конкретной ревизии (одной!), либо в рабочем каталоге. Не надо сравнивать их скорость, это команды для разных целей. Используйте обычныйgrepсhg locate, если вам нуженgit grep.С perforce дело не имел, но git из атрибутов сохраняет вроде только +x и информацию о том, что файл является символической ссылкой, причина в этом?
(hg|bzr|svn|fossil) cat/git cat-file, а документации нет. И QA, где я видел (или задавал?) вопрос про эту возможность, недоступен.Хотя после установки видно — всё же добавили. Только они единственные догадались зачем‐то после содержимого файла добавлять лишную новую строку, так что нельзя делать
vv cat -rN foo.png > bar.png. И назвать это своё поведение «UNIX-style cat»! Впрочем,vv catнельзя делать и по другим причинам: почему‐то изображение, на котором я проверял было обрезано с 189k до 1,4k.Если что, то issue tracker’а нет, список рассылки закрыли, даже Q&A недоступен, поэтому пожаловаться разработчикам не представляется возможным.
snprintf, созданная в соответствии с C99, всё было бы в порядке: значит, вероятно, разработчики, не читая MSDN, решили, что микрософтские функции работают в соответствии с C99 (хотя таких функций там нет).-fsanitize=bounds(для случаев, когда размеры массива могут быть определены статически) (clang),-fsanitize=memoryи-fsanitize=address(проверяют чтение из неинициализированной памяти (первый) и выход за границы массива и различные другие ошибки вроде использования памяти после освобождения (второй)). И ещё есть valgrind и аналоги. Всё‐таки, C/C++ — это языки программирования с огромным количеством различных программ для разработчиков, проверяющих всё, что только можно. Delphi такое и не снилось (хотя тот же valgrind можно использовать для любой программы, статические анализаторы и sanitizer’ы clang’а и gcc — нет).Другой вопрос, что внедрение всех этих статических анализаторов, sanitizer’ов и отладчиков, с последующим анализом и исправлением, гораздо более трудоёмкий процесс, чем включение нескольких опций компилятора.
$var:a:h(полное имя каталога, в котором находится файл из данной переменной), то математики (обёртка над bc — это совершенно не то: попробуйте поработать с шестнадцатиричными цифрами), то автодополнения (оно есть для гораздо меньшего числа команд, нежели в bash или zsh), то нормального разбиения на аргументы ((command)разобьёт по новым строкам, если вы не станете трогать IFS, причём в документации об IFS не написано ничего (единственное упоминание — в документацииread)). Короче, моё впечатление:В случае с архивом вы пишете 2 записи в FAT, одну в каталог, большой непрерывный кусок архива (с небольшим хвостиком из‐за кластеров) и всё. Возможно большой кусок будет разбит на несколько из‐за фрагментации, но при записи файлов это будет гораздо более вероятно (т.к. из‐за кластеров размер увеличивается, да и драйвер наверняка попытается втиснуть каждый файл в наиболее мелкую из имеющихся дырок).
Кэш не позволит ни взять файлы с флэшки быстрее, ни записать файлы на неё быстрее: эти скорости ограничены пропускной способностью контроллера или скоростью чипов флэшки и кэш не способен исправить ничего из этого. Он нужен только в двух случаях: когда вы не собираетесь вынимать флэшку и хотите полюбоваться на быстрый прогресс‐бар или когда вы хотите прочитать файлы с флэшки два раза. В обоих случаях: и имеете достаточно оперативной памяти, чтобы хранить там файлы, с которым работаете.
Zip нужен для того, чтобы превратить случайные чтение/запись многих мелких файлов в последовательные одного большого архива: последовательные чтение/запись до сих пор быстрее случайных во всех хранилищах.
Кроме того, в FAT есть минимальный размер файла (равный размеру одного кластера). Каждый записываемый файл будет дополнен так, чтобы иметь размер, кратный минимальному. Пишет ли система что‐либо в «лишнее» место или нет — неважно: если она пишет — плохо — увеличивается объём данных, которые надо записать; если нет — плохо — теперь никакой планировщик не превратит случайную запись в последовательную. И вам в любом случае придётся изменять каталоги и таблицу FAT (причём последнее два раза) и для каждого файла — т.е. на один файл приходится не менее четырёх мест, которые надо изменить: таблица FAT (основная и резервная копия), каталог, в котором файл хранится, и само содержимое файла в области данных.
-m0=ppmd)).Интересно, почему все забили на 7z+PPMD? Я как‐то раз пробовал сжать лог сборки OpenOffice им, получился в 1,3 раза более компактный файл (
7z -m0=ppmd -mx=9в сравнении сxz -9), при этом создавался он в 4 раза быстрее.