В целом я с вами согласен, но хочу сделать небольшое пояснение: в приведённом вами примере никакого сюрприза после добавления if-а не случится, т.к. ^i означает не просто "переменную i из вышестоящего [по отношению к текущему] scope", а переменную i, которая была скрыта переменной с таким же именем (i).
Вот пример кода:
F f()
V i = 1 // первая `i`
L
V i = 2 // вторая `i`
print(i) // выведет значение второй `i`
print(^i) // выведет значение первой `i`
I ...
I ...
print(i) // также выведет значение второй `i`
print(^i) // также выведет значение первой `i`
получается вот такая путаница «n» и «н», как у автора
А в чём тут путаница?
Переменная n названа так т.к. в тексте условия задачи на русском языке написано "строка набора входных данных содержит одно целое число n".
А переменная н обозначает просто порядковый номер. Можно было бы использовать i либо x, но, на мой взгляд, в данном случае н подходит чуть лучше.
Есть такой код на Python (который считает k-ое по счёту простое число для k = 1 000 000).
Скрытый текст
import math
def prime():
k = 1000000
n = k * 17
primes = [True] * n
primes[0] = primes[1] = False
for i in range(2, int(math.sqrt(n)) + 1):
if not primes[i]:
continue
for j in range(i * i, n, i):
primes[j] = False
for i in range(n):
if primes[i]:
if k == 1:
return i
k -= 1
print(prime())
Я попытался переписать его под Cython.
Скрытый текст
import math
from libc.stdlib cimport malloc, free
def prime():
cdef int k = 1000000
cdef int n = k * 17
cdef bint *primes = <bint *>malloc(17000000 * sizeof(bint))
cdef int i, j
for i in range(17000000):
primes[i] = True
primes[0] = False
primes[1] = False
for i in range(2, int(math.sqrt(n)) + 1):
if not primes[i]:
continue
for j in range(i * i, n, i):
primes[j] = False
for i in range(n):
if primes[i]:
if k == 1:
free(primes)
return i
k -= 1
В результате получилось всего лишь в 5 раз быстрее.
Что не так в приведённом Cython-коде?
(Для сравнения: оригинальный Python-код [вообще без каких-либо изменений] ускоряется посредством траспайлера Python → 11l → C++ почти в 20 раз, что сопоставимо по скорости с реализацией на C/C++.)
Если вкратце: все придуманное удобно для автора, но абсолютно неудобно и бессмысленно для пользователя.
Отвечу также вкратце: это дело привычки.
вложенные «древоспойлеры» лично меня бесят.… Но когда в тексте сноски идет еще одна сноска — это уже немножко бесяче.
Тут отчасти я с вами согласен. Сайт yearver.org в этом отношении является некоторым экспериментом, так как и я обычно стараюсь ограничиваться одним уровнем вложенности (как например тут (см. запись от 2017.11.22 10:03:36) или тут).
Поиск поломан, структуры никакой нет, снаружи на содержимое спойлера никак не сошлешься
Поиск и ссылки на древотекст сделать теоретически возможно (хотя и довольно сложно), но у меня лично при работе с документацией к 11l проблем с этим никогда не возникало.
Ожидается, что документация будет построена структурированно, по принципу «сначала кратенько об основном, потом подробненько разбор в деталях, в конце — всякие баги-глюки-закавыки».
Интересный тезис. А можете привести какой-нибудь реальный пример такой образцовой документации?
Теперь собственно о самом YearVer. Схема, опять-таки, удобна для автора (думать не надо), но бессмысленна для пользователя.
Простите за нескромный вопрос — а вы сами занимались разработкой ПО более или менее профессионально? Тогда разработкой какого ПО, если не секрет? [Я, если что, никакого секрета из своего профессионального опыта не делаю (вкратце он изложен на моей домашней странице).]
в игре — формат сохранения сейвов
Можете привести хоть один пример "увеличения major части версии" в играх? Если появляется вторая часть какой-то игры, то это уже просто другая/новая игра [как правило с полностью несовместимыми сейвами], а не новая версия старой игры. В обновлениях же игр формат хранения сейвов обычно не меняется, а если и меняется, то сейвы всех старых версий всегда поддерживаются в более новых версиях.
Остальные ваши рассуждения в пользу обычной практики версионирования семантического версионирования комментировать не вижу смысла, достаточно привести такой факт, что некоторые крупные компании переводят свои проекты с семантического версионирования на календарное (в том числе YearVer), например JetBrains (IntelliJ IDEA, PyCharm, CLion и пр.) и Unity.
А на основе моего личного опыта я могу сказать, что календарное версионирование (и в частности YearVer) подходит лучше, чем семантическое, практически для всех проектов, в которых я принимал участие.
Ваша стратегия для серверов, а я имел в виду стратегию для десктопов (забыл уточнить просто).
Если мы крашнулись по оперативе — сохраняем данные на диск без потери
Это о каких данных идёт речь?
И что если для сохранения на диск (в случае когда это сохранение выполняется на уровне приложения, а не операционной системы) требуется немного дополнительной памяти, а она кончилась?
А как обстоит с этим в самой PVS-Studio? Вы проверяете удалось ли выделить память? И что делаете в случае когда не удалось?
ИМХО, самый разумный способ разрулить это на уровне операционной системы, «замораживая» приложения в случае невозможности аллокации памяти, и предоставляя пользователю самому решать что делать: принудительно завершить приложение, либо оставив его «замороженным» закрыть другие приложения [дабы освободить немного памяти], разморозить «замороженное» приложение, сохранить свои данные и закрыть его (чтобы перезапустить).
мы же хотим чтобы весь контент, который есть на Хабре был доступен всем и всегда.
Хорошо если так. И если эту позицию разделяют все члены команды Хабра.
Но, тем временем, я бегло пробежался по своим статьям, пытаясь понять насколько сложно было бы их сверстать в новом WYSIWYG-редакторе. И оказалось, что это просто невозможно! Так как новый редактор не поддерживает:
код в таблице и спойлер в нумерованном списке (используется в этой статье);
вставку таблицы в цитату (используется в этой статье);
таблицу в таблице (используется в этой статье, хотя признаю, что такая возможность требуется крайне редко);
спойлер в таблице (используется в моей новой ещё не опубликованной статье);
невозможно добавить новый "абзац" [то, что в старом редакторе достигается простым нажатием Enter или вставкой тега <br>] без вертикального интервала между абзацами, в том числе в таблицах (не знаю, как лучше объяснить… можно посмотреть на однострочную табличку в самом конце данной статьи и попробовать сверстать её в новом редакторе; а также рекомендую попробовать сверстать раздел ‘Захват\Capture внешних переменных’ из этой же статьи — получается просто отвратительно, начиная с некрасивого интервала сразу после подзаголовка (он слишком маленький, а если нажать Enter — уже слишком большой), неуместного интервала перед ‘В 11l для этого ...’ и интервала после ‘C++:’, и заканчивая ненужными отвлекающими цифрами-номерами строк кода, я уж молчу про невозможность выделить буквы ‘Ca’ подзаголовка жирным шрифтом).
В итоге я пришёл к такому выводу, что новый редактор хорош в первую очередь для новостных статей и им подобных, когда надо склепать пост по-быстрому и не охота заморачиваться с тегами. Но как только требуется что-то более изощрённое, в новом редакторе это просто не получится написать. Если вам так не нравится legacy-код старого редактора, тогда может вы подумаете о том, чтобы переписать его с нуля под новую версию Хабра? Это будет всяко проще чем добавить в WYSIWYG-редактор поддержку таблиц [или кода, или других элементов] в цитатах или кода в таблицах [и уж тем более управление интервалами].
И так как WYSIWYG-редактор не подходит для всех статей, я предлагаю в новой версии сайта дать авторам выбор: использовать либо WYSIWYG-редактор, либо низкоуровневый язык разметки (не обязательно HTML, можете свой язык изобрести, главное, чтобы он обладал сопоставимыми возможностями HTML из старого редактора).
И в заключение приведу цитату отсюда (это реакция на сообщение о том, что BBCode объявлен устаревшим и в новых версиях форума Invision его поддержка будет прекращена):
Maybe I'm just a crusty old dinosaur, but I don't get this war against BBCode being waged everywhere. Just because something is old doesn't mean it doesn't work, and BBCode "just works". It's especially useful in posting prewritten text to include formatting. It's a much larger pain in the backside to use the post editor to do that.
Так и хочется перефразировать эту цитату к тому, что делают с Хабром:
… I don't get this war against HTML for writing posts and comments being waged everywhere. Just because something is old doesn't mean it doesn't work, and HTML "just works".
когда у нас почти половина трафика пошла с мобильных устройств
Ну нельзя же думать только категориями трафика и прибыли. Задумайтесь, что останется от вашей деятельности потомкам. Есть статьи, которые не устареют никогда [и, как я надеюсь, такими станут некоторые из статей, которые я пишу в данный момент и собираюсь написать]. Подумайте, насколько ваши решения способствуют появлению именно таких статей на Хабре. А не статей, ориентированных на максимальное количество просмотров, но которые потеряют актуальность уже через месяц, и навсегда останутся лишь информационным шумом.
Одинаково отображать все старые посты на всем зоопарке устройств, с которых нас читают, практически невозможно, в том числе поэтому мы отходим от использования HTML.
Красивое отображение на всех устройствах — это здорово. Но как это связано с использованием HTML?
[Тем более, что старый редактор поддерживает довольно ограниченное базовое подмножество HTML.]
К тому же, во-первых, в конечном счёте всё равно должен быть сгенерирован HTML, и от него уйти никуда не получится.
Во-вторых, даже если вы запретите писать посты на HTML, то хранить их вам всё равно как-то нужно, и, скорее всего, в некоем HTML-подобном формате.
Вы не могли бы дать авторам статей доступ к этому внутреннему формату?
[Чтобы сохранить возможность писать статьи локально и под системой управления версиями.]
[[Возможно, доступ к этому формату стоит давать только по специальному запросу от авторов, чтобы не добавлять кнопку/галочку, видимую всеми, и не захламлять интерфейс у тех, кому такая возможность не нужна.]]
Редко когда крутую публикацию получается написать на одном дыхании
Полностью согласен с этим. [Поэтому все свои статьи храню в Git-репозиториях, что позволяет наглядно отследить работу над ними.]
Не хочется обижать команду Хабра, но считаю принятое решение полностью отказаться от старого редактора несколько непрофессионально.
Как было бы профессионально?
Сделать 3 кнопки-переключатели HTML-WYSIWYG-Markdown [вместо двух HTML-Markdown].
Кнопка WYSIWYG вместо вкладки Просмотр [соответственно вкладки Редактор и Просмотр становятся ненужными], и она нажата по умолчанию (раз уж вам так нравится этот WYSIWYG).
При переключении на Markdown теги HTML, которые Markdown не поддерживает, остаются как есть, всё остальное по-честному переводится в Markdown.
И разумеется, переключение между HTML, WYSIWYG и Markdown должно полностью сохранять форматирование.
А текущее решение загоняет вас в тупик. Вы планируете поддерживать старый редактор бесконечно? Если нет, то как быть со всеми уже вышедшими статьями, запретить их редактировать? В общем, непрофессионально это, уж не обижайтесь.
Если не боитесь, можете создать опрос/голосование, что предпочтут пользователи-авторы статей: оставить поддержку старого редактора и при этом никаких новых фич на Хабре не добавлять вообще, либо новые фичи, но без поддержки старого редактора.
И в заключение.
Последние несколько лет каждая новая фича становилась верхушкой айсберга рефакторинга и копаний в legacy-коде.
Полностью разделяю такое беспокойство. Лично я порой возвращаюсь к уже написанным статьям и вношу небольшие правки. Для ревью изменений очень удобно использовать KDiff3, а сами исходники статей я храню на GitHub-е в формате пк-разметки. Я немало усилий потратил на реализацию очень качественного преобразования пк-разметки в HTML, используемый Хабром [для этого утилита pqmarkup поддерживает флаг --habr-html], и очень обидно будет потерять полный контроль над форматированием своих статей.
Прекращение поддержки Mercurial в Bitbucket :( сломало ): две последние ссылки из данного комментария.
Вот новые ссылки:
… Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
… Type заменяется на std::unique_ptr<Type> (пример).
Также хочу заметить, что такое поведение планируется пересмотреть, и в новой версии транспайлера 11l → C++ Type будет заменяться на std::unique_ptr<Type> всегда когда это возможно (т.е. при отсутствии в коде вызова share(obj) с объектом obj типа Type).
Так я ж не против. Возможно, такая запись и правда очень полезна.
У меня претензия к примеру — он совершенно не раскрывает пользу такой записи.
В идеале, пример должен быть из реального проекта. И неплохо бы показать не только код, использующий данную возможность, но и код, который приходится писать без такой возможности.
Предполагаю, что речь идёт о том, что размер [любого] указателя в программах на 64-разрядной платформе — 8 [=64/8] байт.
В данном случае речь идёт об указателях на списки для каждого ключа субхэша (типично субхэш = хэш_ключа % количество_элементов_в_хэштаблице). Ещё их [эти списки] изредка называют списками коллизий.
Неизвестно.
Да, конечно. Вот здесь представлены диаграммы производительности (конкретно Python в C++ транслирует Nuitka и Shed Skin).
В целом я с вами согласен, но хочу сделать небольшое пояснение: в приведённом вами примере никакого сюрприза после добавления if-а не случится, т.к.
^iозначает не просто "переменнуюiиз вышестоящего [по отношению к текущему] scope", а переменнуюi, которая была скрыта переменной с таким же именем (i).Вот пример кода:
А в чём тут путаница?
Переменная
nназвана так т.к. в тексте условия задачи на русском языке написано "строка набора входных данных содержит одно целое число n".А переменная
нобозначает просто порядковый номер. Можно было бы использоватьiлибоx, но, на мой взгляд, в данном случаенподходит чуть лучше.[Ссылка на вопрос на Quora.]
Я попытался переписать его под Cython.
В результате получилось всего лишь в 5 раз быстрее.
Что не так в приведённом Cython-коде?
(Для сравнения: оригинальный Python-код [вообще без каких-либо изменений] ускоряется посредством траспайлера Python → 11l → C++ почти в 20 раз, что сопоставимо по скорости с реализацией на C/C++.)
Отвечу также вкратце: это дело привычки.
Тут отчасти я с вами согласен. Сайт yearver.org в этом отношении является некоторым экспериментом, так как и я обычно стараюсь ограничиваться одним уровнем вложенности (как например тут (см. запись от 2017.11.22 10:03:36) или тут).
Поиск и ссылки на древотекст сделать теоретически возможно (хотя и довольно сложно), но у меня лично при работе с документацией к 11l проблем с этим никогда не возникало.
Интересный тезис. А можете привести какой-нибудь реальный пример такой образцовой документации?
Простите за нескромный вопрос — а вы сами занимались разработкой ПО более или менее профессионально? Тогда разработкой какого ПО, если не секрет? [Я, если что, никакого секрета из своего профессионального опыта не делаю (вкратце он изложен на моей домашней странице).]
Можете привести хоть один пример "увеличения major части версии" в играх? Если появляется вторая часть какой-то игры, то это уже просто другая/новая игра [как правило с полностью несовместимыми сейвами], а не новая версия старой игры. В обновлениях же игр формат хранения сейвов обычно не меняется, а если и меняется, то сейвы всех старых версий всегда поддерживаются в более новых версиях.
Остальные ваши рассуждения в пользу
обычной практики версионированиясемантического версионирования комментировать не вижу смысла, достаточно привести такой факт, что некоторые крупные компании переводят свои проекты с семантического версионирования на календарное (в том числе YearVer), например JetBrains (IntelliJ IDEA, PyCharm, CLion и пр.) и Unity.А на основе моего личного опыта я могу сказать, что календарное версионирование (и в частности YearVer) подходит лучше, чем семантическое, практически для всех проектов, в которых я принимал участие.
Ваша стратегия для серверов, а я имел в виду стратегию для десктопов (забыл уточнить просто).
Это о каких данных идёт речь?
И что если для сохранения на диск (в случае когда это сохранение выполняется на уровне приложения, а не операционной системы) требуется немного дополнительной памяти, а она кончилась?
ИМХО, самый разумный способ разрулить это на уровне операционной системы, «замораживая» приложения в случае невозможности аллокации памяти, и предоставляя пользователю самому решать что делать: принудительно завершить приложение, либо оставив его «замороженным» закрыть другие приложения [дабы освободить немного памяти], разморозить «замороженное» приложение, сохранить свои данные и закрыть его (чтобы перезапустить).
Но, тем временем, я бегло пробежался по своим статьям, пытаясь понять насколько сложно было бы их сверстать в новом WYSIWYG-редакторе. И оказалось, что это просто невозможно! Так как новый редактор не поддерживает:
<br>] без вертикального интервала между абзацами, в том числе в таблицах (не знаю, как лучше объяснить… можно посмотреть на однострочную табличку в самом конце данной статьи и попробовать сверстать её в новом редакторе; а также рекомендую попробовать сверстать раздел ‘Захват\Capture внешних переменных’ из этой же статьи — получается просто отвратительно, начиная с некрасивого интервала сразу после подзаголовка (он слишком маленький, а если нажать Enter — уже слишком большой), неуместного интервала перед ‘В 11l для этого ...’ и интервала после ‘C++:’, и заканчивая ненужными отвлекающими цифрами-номерами строк кода, я уж молчу про невозможность выделить буквы ‘Ca’ подзаголовка жирным шрифтом).В итоге я пришёл к такому выводу, что новый редактор хорош в первую очередь для новостных статей и им подобных, когда надо склепать пост по-быстрому и не охота заморачиваться с тегами. Но как только требуется что-то более изощрённое, в новом редакторе это просто не получится написать. Если вам так не нравится legacy-код старого редактора, тогда может вы подумаете о том, чтобы переписать его с нуля под новую версию Хабра? Это будет всяко проще чем добавить в WYSIWYG-редактор поддержку таблиц [или кода, или других элементов] в цитатах или кода в таблицах [и уж тем более управление интервалами].
И так как WYSIWYG-редактор не подходит для всех статей, я предлагаю в новой версии сайта дать авторам выбор: использовать либо WYSIWYG-редактор, либо низкоуровневый язык разметки (не обязательно HTML, можете свой язык изобрести, главное, чтобы он обладал сопоставимыми возможностями HTML из старого редактора).
И в заключение приведу цитату отсюда (это реакция на сообщение о том, что BBCode объявлен устаревшим и в новых версиях форума Invision его поддержка будет прекращена):
Так и хочется перефразировать эту цитату к тому, что делают с Хабром:
[Тем более, что старый редактор поддерживает довольно ограниченное базовое подмножество HTML.]
К тому же, во-первых, в конечном счёте всё равно должен быть сгенерирован HTML, и от него уйти никуда не получится.
Во-вторых, даже если вы запретите писать посты на HTML, то хранить их вам всё равно как-то нужно, и, скорее всего, в некоем HTML-подобном формате.
Вы не могли бы дать авторам статей доступ к этому внутреннему формату?
[Чтобы сохранить возможность писать статьи локально и под системой управления версиями.]
[[Возможно, доступ к этому формату стоит давать только по специальному запросу от авторов, чтобы не добавлять кнопку/галочку, видимую всеми, и не захламлять интерфейс у тех, кому такая возможность не нужна.]]
Или политика Хабра с тех пор поменялась?
Если нет, то что вы предлагаете? В каком другом месте следует писать статьи?
И вот ещё цитата отсюда:
Полностью согласен с этим. [Поэтому все свои статьи храню в Git-репозиториях, что позволяет наглядно отследить работу над ними.]
Не хочется обижать команду Хабра, но считаю принятое решение полностью отказаться от старого редактора несколько непрофессионально.
Как было бы профессионально?
Сделать 3 кнопки-переключатели HTML-WYSIWYG-Markdown [вместо двух HTML-Markdown].
Кнопка WYSIWYG вместо вкладки Просмотр [соответственно вкладки Редактор и Просмотр становятся ненужными], и она нажата по умолчанию (раз уж вам так нравится этот WYSIWYG).
При переключении на Markdown теги HTML, которые Markdown не поддерживает, остаются как есть, всё остальное по-честному переводится в Markdown.
И разумеется, переключение между HTML, WYSIWYG и Markdown должно полностью сохранять форматирование.
А текущее решение загоняет вас в тупик. Вы планируете поддерживать старый редактор бесконечно? Если нет, то как быть со всеми уже вышедшими статьями, запретить их редактировать? В общем, непрофессионально это, уж не обижайтесь.
Если не боитесь, можете создать опрос/голосование, что предпочтут пользователи-авторы статей: оставить поддержку старого редактора и при этом никаких новых фич на Хабре не добавлять вообще, либо новые фичи, но без поддержки старого редактора.
И в заключение.
Огласите весь список [этих фич], пожалуйста.
--habr-html], и очень обидно будет потерять полный контроль над форматированием своих статей.Или политика Хабра с тех пор поменялась?
Вот новые ссылки:
… Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
… Type заменяется на std::unique_ptr<Type> (пример).
Также хочу заметить, что такое поведение планируется пересмотреть, и в новой версии транспайлера 11l → C++
Typeбудет заменяться наstd::unique_ptr<Type>всегда когда это возможно (т.е. при отсутствии в коде вызоваshare(obj)с объектомobjтипаType).У меня претензия к примеру — он совершенно не раскрывает пользу такой записи.
В идеале, пример должен быть из реального проекта. И неплохо бы показать не только код, использующий данную возможность, но и код, который приходится писать без такой возможности.
лучше чем эта:
?
В данном случае речь идёт об указателях на списки для каждого
ключасубхэша (типичносубхэш = хэш_ключа % количество_элементов_в_хэштаблице). Ещё их [эти списки] изредка называют списками коллизий.