Нет :)
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
Можно кормить sax парсер через feed построчно непосредственно во время «очистки» файла БД, это будет быстрее, чем писать/читать новый обработанный файл. Более того — можно читать данные непосредственно из архива, распаковывая по мере обработки.
P.S. Зачем заморачивались с coroutine я не понял :)
6/9 угадал, для венчурного инвестора достаточно. o_O
Однако непонятно, что делает IT-компанию «высокотехнологичной» и как их насчитали так много (какой % от IT-компаний высокотехнологичные, какой % средне- и низкотехнологичных). Может это фирмы-однодневки с раздутыми ожиданиями, чья единственная цель существования — прихватить инвестиционных денег и исчезнуть. Они венчурные, да. Но инновационные — вообще ни разу, так как никакого внедрения в народное хозяйство не происходит.
Да, но это вставки настоящего, а рассказ же из будущего :)
Человечество пережило ядерную войну и генетические модификации, но по-прежнему использует USB для отладки приложений и формат .exe для приложений (под ОС Windows !?) и флешки.
Нет, не уверен. С плюсами тоже не уверен :)
В краткосрочной перспективе уйти в минусы не сложно, но со временем результаты будут более объективными. Не думаю, что это фундаментальный недостаток.
Если автору понятно за что минус — то это нормальный инструмент обратной связи, такой же как и плюс.
P.S. В некоторых других системах это не обязательно +-1, а зависит от "опыта" пользователя. Голос новичка может "весить" в разы меньше, чем голос старожила, например +-0,01.
Да, есть ситауции, когда и минус поставить, так сказать «Добавить», если причина недовольства уже чётко донесена до автора другими комментаторами и поведение не адекватно, но лучше конкретно плюсовать с чем согласен, т.е. ответы.
P.S. Обидно, когда комментарий, критикующий статью набирает больше кармы, чем сама статья. Но это хорошо для автора статьи, для понимания что конкретно от статьи ожидали читатели. Это гораздо лучше просто заминусованной статьи без существенной обратной связи.
Я не имел ввиду "только ТВ сигнал", эмулятор не ограничен одной графикой и состоит из множества систем, точная симуляция которых довольно сложная. Точность эмуляции зависит от системы, не везде на практике нужно cycle accurate. ТВ сигнал является выходом для приставки и само отображение его на экране не является частью приставки как таковой. Я имел ввиду что ответственность эмулятора приставки за вывод графики на этом заканчивается.
Поздравляю! Но трёх дней недостаточно чтобы объективно оценить все особенности. По словам Ромеро люди просто устают от VR, вполне возможно что на это уходит больше трёх дней, так что продолжайте наблюдение :)
Ну я так понял что статья о «точной» эмуляции вывода картинки только.
По сути эмуляция приставки на ТВ сигнале и заканчивается, дальше уже идёт эмуляция дисплея/телевизора, что вообще отдельная тема.
Эмуляция всего железа cycle accurate для игрушек с приставки на мой взгляд особо и не нужна, те же эмуляторы PS1 заметно лучше оригинала в плане графики.
У меня нет кармы :), но даже если будет смысла минусовать я не вижу.
Если плюсуют, значит согласны, всё хорошо, ничего менять не надо.
Если минусуют, то значит что-то пошло не так, есть масса различных часто даже противоречивых причин. Мне лично как автору более интересно узнать что конкретно по мнению человека я делаю не так, а анонимный минус без пояснений в этом ничем не помогает.
Исходя из понимания что этот анонимный минус по сути ничем автору не поможет исправиться, на мой взгляд лучше написать комментарий (ну или если страшно, то хотя-бы прикрепить к анонимному минусу сообщение)