А если топику не выставили язык, или не все поддерживаемые языки выставили — клиент ничего не получит? А если клиент переключит язык — он снова получит те же самые уведомления?
Нет :)
Max Payne был долгостроем, и хотя сама идея и реализация скорее всего была сделана раньше, широкая общественность увидела её после фильма :(
Есть же даже статья в википедии ru.wikipedia.org/wiki/Буллет-тайм
Прикольно что до матрицы это использовали в фильме Блэйд
Как уже писали — сама по себе идея не была фундаментально новой, скорее мало знакомой широкому потребителю. В комбинации с другими приёмами фильм получился чем-то свежим и оригинальным. И хотя сиквелы продолжали инновации спецэффектов, этого нельзя сказать о сюжете.
Возможно источник не надёжный, но если верить aspe.hhs.gov/2019-poverty-guidelines, то дальнобойщик, получающий $30К в год не попадает под черту бедности для семьи из двух человек, которая там описана как $16,910.
Т.к. в США довольно распространена почасовая оплата, а дальнобойщик был представлен в статье как образец бедности, нуждающийся в этих 500$ — это была существенная прибавка к насчитанным мной 770$ :)
А теперь оказывается что это лишь одна пятая от его дохода, и чел ну ни разу не бедный
Первый фильм оставил яркие впечатления, остальные уже не так.
На уровне сценария очень мощной была бы депрессивная концовка «Матрица в Матрице» но, похоже, это лишь фанатские додумки.
Спасибо за пояснение. Тогда логично было бы писать что он получает за смену или за рабочий день. В формулировке сутки я исходил из определения что это именно 24 часа работы.
На мой взгляд просто назвать методы по-другому потребует минимальных усилий со стороны автора и в то же время сделает использование удобнее, и учебным целям это скорее способствует.
А какой великий смысл придумывать свои названия функций вместо стандартных?
contains вместо __contains__
get вместо __getitem__
addToEnd вместо append
removeBox вместо remove
Про SBO возможно стоит упомянуть трюк из С, но для этого придётся переставить порядок элементов — последним должен идти массив символов (по-моему flexible array member можно даже нулевого размера). Можно выделить через alloca нужный размер (больше чем сам struct), после чего обращаться к символам вне диапазона задекларированного массива.
Удобно при работе c POD
Считаете, что для этого надо дробить при кормлении? Лишние условия для проверки увеличат время работы.
Требует проверки, но не думаю что значительно. Можно поэкспериментировать на скрипте для «очистки», обрабатывая блоки в 4Кб, 8Кб, 16Кб… и т.д. вместо одной «строки»
И как по частям кормить DOM
В примере вы используете xml.etree.ElementTree.parse
Как это работает
Если заглянуть внутрь, там вот это:
def parse(source, parser=None):
"""Parse XML document into element tree.
*source* is a filename or file object containing XML data,
*parser* is an optional parser instance defaulting to XMLParser.
Return an ElementTree instance.
"""
tree = ElementTree()
tree.parse(source, parser)
return tree
Что ведёт к методу ElementTree
def parse(self, source, parser=None):
"""Load external XML document into element tree.
*source* is a file name or file object, *parser* is an optional parser
instance that defaults to XMLParser.
ParseError is raised if the parser fails to parse the document.
Returns the root element of the given source document.
"""
close_source = False
if not hasattr(source, "read"):
source = open(source, "rb")
close_source = True
try:
if parser is None:
# If no parser was specified, create a default XMLParser
parser = XMLParser()
if hasattr(parser, '_parse_whole'):
# The default XMLParser, when it comes from an accelerator,
# can define an internal _parse_whole API for efficiency.
# It can be used to parse the whole source without feeding
# it with chunks.
self._root = parser._parse_whole(source)
return self._root
while True:
data = source.read(65536)
if not data:
break
parser.feed(data)
self._root = parser.close()
return self._root
finally:
if close_source:
source.close()
По сути это XMLParser, которого кормят по-частям кусками по 64Кб :)
Как еда заканчивается, parser.close() вернёт root
Остается сожалеть, что данное достоинство не применимо к БД ФИАС, так как требуется предварительная работа с кодировками.
Вполне применимо, как я уже писал в комментарии.
Да, это не так красиво как просто дать имя файла. Придётся кормить парсер по-частям. Читать часть, чинить кодировку и кормить парсер :)
Для простого фильтра по тегам для SAX 27,5 ГБ ни о чем.
Тем более что парсер ничего кроме текущей «лексемы» не помнит.
DOM парсер для этого тоже подходит, его так-же можно кормить по-частям, но следить за объёмом «еды», как только размер достигнут — скормить ему фиктивный «конец», обработать «документ» и начать парсить новый, скормив ему фиктивное «начало». Это практически то-же самое, что было описано с разбиением файлов на маленькие в предыдущей статье, только без самих файлов (их не надо писать на диск и потом читать).
DOM парсер тоже можно кормить по-частям, смысл в том, чтобы избавиться от чтения/записи дополнительного «очищенного» файла, особенно если он довольно большой.
Фишка SAX тут скорее в другом — он может писать результаты ещё до того, как файл обработан целиком, в то время как с DOM можно работать только после загрузки целиком (ну и сожрёт много памяти).
На современном железе чтение из архива с распаковкой может работать даже быстрее, чем чтение уже распакованного файла с диска. Судя по примеру — для обработки требуется всего один проход по файлу, так что в идеале программа будет ограничена лишь скоростью работы с диском.
Ну значит кормить блоками некоторой длины :)
Просто ваш «код очистки» вроде написан построчно.
Про условия — пожалуй нечестно сравнивать
SAX: дергание coroutine+print на каждое событие
DOM: csvwriter только тегов HOUSE.
Тогда уж пусть и SAX просто пишет CSV в startElement, если тэг HOUSE
А если топику не выставили язык, или не все поддерживаемые языки выставили — клиент ничего не получит? А если клиент переключит язык — он снова получит те же самые уведомления?
При выборе варианта чтения wad файла почему-то пропущен вариант использовать файл отображаемый в память (memory mapped file).
Max Payne был долгостроем, и хотя сама идея и реализация скорее всего была сделана раньше, широкая общественность увидела её после фильма :(
Есть же даже статья в википедии ru.wikipedia.org/wiki/Буллет-тайм
Прикольно что до матрицы это использовали в фильме Блэйд
А теперь оказывается что это лишь одна пятая от его дохода, и чел ну ни разу не бедный
На уровне сценария очень мощной была бы депрессивная концовка «Матрица в Матрице» но, похоже, это лишь фанатские додумки.
Спасибо за пояснение. Тогда логично было бы писать что он получает за смену или за рабочий день. В формулировке сутки я исходил из определения что это именно 24 часа работы.
110$ это за 24 часа, или 3 рабочих дня. Получается 770$ в месяц
На заработанные таким образом деньги купить пива.
Я лично тупил смотря на хеш :)
contains вместо __contains__
get вместо __getitem__
addToEnd вместо append
removeBox вместо remove
Учитывая специфику игры (это рогалик) она не особо требовательна к ресурсам и нормально будет работать через эмулятор
Удобно при работе c POD
Требует проверки, но не думаю что значительно. Можно поэкспериментировать на скрипте для «очистки», обрабатывая блоки в 4Кб, 8Кб, 16Кб… и т.д. вместо одной «строки»
В примере вы используете xml.etree.ElementTree.parse
Что ведёт к методу ElementTree
По сути это XMLParser, которого кормят по-частям кусками по 64Кб :)
Как еда заканчивается, parser.close() вернёт root
Вполне применимо, как я уже писал в комментарии.
Да, это не так красиво как просто дать имя файла. Придётся кормить парсер по-частям. Читать часть, чинить кодировку и кормить парсер :)
Для простого фильтра по тегам для SAX 27,5 ГБ ни о чем.
Тем более что парсер ничего кроме текущей «лексемы» не помнит.
DOM парсер для этого тоже подходит, его так-же можно кормить по-частям, но следить за объёмом «еды», как только размер достигнут — скормить ему фиктивный «конец», обработать «документ» и начать парсить новый, скормив ему фиктивное «начало». Это практически то-же самое, что было описано с разбиением файлов на маленькие в предыдущей статье, только без самих файлов (их не надо писать на диск и потом читать).
DOM парсер тоже можно кормить по-частям, смысл в том, чтобы избавиться от чтения/записи дополнительного «очищенного» файла, особенно если он довольно большой.
Фишка SAX тут скорее в другом — он может писать результаты ещё до того, как файл обработан целиком, в то время как с DOM можно работать только после загрузки целиком (ну и сожрёт много памяти).
На современном железе чтение из архива с распаковкой может работать даже быстрее, чем чтение уже распакованного файла с диска. Судя по примеру — для обработки требуется всего один проход по файлу, так что в идеале программа будет ограничена лишь скоростью работы с диском.
Просто ваш «код очистки» вроде написан построчно.
Про условия — пожалуй нечестно сравнивать
SAX: дергание coroutine+print на каждое событие
DOM: csvwriter только тегов HOUSE.
Тогда уж пусть и SAX просто пишет CSV в startElement, если тэг HOUSE