Первый фильм оставил яркие впечатления, остальные уже не так.
На уровне сценария очень мощной была бы депрессивная концовка «Матрица в Матрице» но, похоже, это лишь фанатские додумки.
Спасибо за пояснение. Тогда логично было бы писать что он получает за смену или за рабочий день. В формулировке сутки я исходил из определения что это именно 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 !?) и флешки.
На уровне сценария очень мощной была бы депрессивная концовка «Матрица в Матрице» но, похоже, это лишь фанатские додумки.
Спасибо за пояснение. Тогда логично было бы писать что он получает за смену или за рабочий день. В формулировке сутки я исходил из определения что это именно 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
P.S. Зачем заморачивались с coroutine я не понял :)
Раз уж решили использовать git/github, то можно было сделать лучше:
Превышен лимит скачивания, вы можете сохранить файл на Яндекс.Диск
Почему нельзя было сделать торрентом, например.
Однако непонятно, что делает IT-компанию «высокотехнологичной» и как их насчитали так много (какой % от IT-компаний высокотехнологичные, какой % средне- и низкотехнологичных). Может это фирмы-однодневки с раздутыми ожиданиями, чья единственная цель существования — прихватить инвестиционных денег и исчезнуть. Они венчурные, да. Но инновационные — вообще ни разу, так как никакого внедрения в народное хозяйство не происходит.
Человечество пережило ядерную войну и генетические модификации, но по-прежнему использует USB для отладки приложений и формат .exe для приложений (под ОС Windows !?) и флешки.
Рассказ мне понравился, остальное по сути мелочи.