Pull to refresh
270
0
Владимир Казанов @VlK

Программист

Send message
а как вы калибр измеряется? Вики, например, говорит, что выручка у компаний одного порядка, пускай EA и жирней.
Нет, вы все не так поняли. Это и есть «Радио свобода», просто наоборот.
А что вообще мне там может быть нужно, в этом коде? Т.е., зачем мне разбираться в софтине на тысячи строк кода, когда все решение занимает меньше двух сотен строк?

Опять же, какое отношение софт для просмотра файлов с вики-подобным синтаксисом имеет к скриптам, работающим с файловой системой?
Т.е. вы предлагаете адаптировать программу, визуально отображающую файлы с вики-подобной разметкой в виде дерева..?

Я, вероятно, не совсем вас сразу понял.
А по скриптам — так вообще не понял, наоборот же, проще каждому скрипту рассказать в какой файл он должен писать, чем объяснить структуру единого файла.


Именно про это я и говорю. Писать легче в отдельные файлы. Поэтому большой конфиг превращается в файлы.

Но этот же конфиг мне нужен как один штука, потому что только один штука на входе понимает та система, которая его переваривает. Вот и все дела :-)
Вы не читаете то, что я уже написал: файл нужен как единое целое в другом месте.

Более того, этот скрипт и делает это самое «создать N файлов иерархически» совершенно автоматически.
Может быть, я не достаточно аккуратно изложил проблему.

Есть единый сложный файл, который в принципе кормится одной системе как единый файл, и с этим трудно что-то сделать. С другой стороны, хочется с некоторыми ветками дерева этого файла работать прямо из консоли, простыми скриптами.

Вот и все дела.
У меня нет проблемы сделать из файла древовидную структуру :-) Такие вещи называются парсерами, и с этим уже давно ни у кого нет проблем.

У меня проблема — представление одной древовидной структуры в виде другой, файловой.
Ну да, отчасти вы, конечно, правы. С другой стороны, у меня было несколько часов на все про все, и тут уж не до спасения планеты. :-)

Ваша идея тоже звучит интересно, признаться, но это ваша идея и ваш интерес, не могу ж я их взять и украсть :-)
Да, мне очень нравится этот подход, когда все — файлы, и поэтому все инструменты являются универсальными.

собственно говоря, FUSE, Sysfs и procfs в Линуксах появились по мотивам разработок Plan9
ZIM, который формат файла? А при чем здесь вообще конкретный формат файла?

Статья ведь про то, что файлы с иерархией можно легко монтировать как файловую систему, и тогда для работы с содержимым можно пользоваться любыми привычными инструментами.
Хабр не вполне корректно обрабатывает переносы. Спасибо, исправил.
Я вроде не написал, что данное решение мне срочно надо использовать для обработки миллионов запросов в секунду…

Для скорости я бы писал не на Питоне, и обрабатывал системные вызовы бы не в один поток, и т.д. и т.п. В конце концов можно написать модуль файловой системы для ядра.

И если вам действительно надо условный миллион раз за условную же наносекунду читать конфиг, то, быть может, вы что-то делалете не то..?
Дык речь о теории в физике. У математиков своего критерия Поппера нетуть по определению, у них других заморочки, которые с полнотой и непротиворечивостью :-)
Ну… Теперь, конечно, легко говорить, что это не «черный лебедь». Но до референдума даже сторонники выхода здесь, в Лондоне, не воспринимали собственную кампанию всерьез.

Это видно, например, по тому, что по результатам голосования фактически все политики со всех сторон подали в отставку.
Простите, но фраза «какое отношение компилятор имеет к архитектуре» звучит, скажем так, чересчур громко.

Компилятор — или его бэкэнд — пишется под конкретную архитектуру. Некоторые архитектуры без корректного компилятора вообще не имеют смысла.

Например, тот же Эльбрус.
Пишут-пишут… У меня в читалке штук десять англоязычных книг про разные компиляторы, их архитекутуру, различные: lcc, gcc, LLVM, оптимизирующие компиляторы и т.д.

Вообще, в эпоху открытого кода этими вещами никого уже не удивить. Признаться, мое любопытство диктуется скорее уже коллекционными соображениями, чем недостатком материала на английском.

Тут выше кто-то заметил, что российская школа разработки компиляторов очень развита, ну мне и стало любопытно, какую литературу издают и читают.
Собственно, эта плюс еще одна политеховская и были у меня в универе (питерский политех). Это сугубо теоретическая книга по теории компиляторов.

Но компиляторы — не только теория парсеров. Собственно, про практические аспекты книг я никогда не видел, к огромному моему сожалению.
Ну, если по-честному, я сталкивался еще будучи студентом с парой русских книг по теории компиляторов. И да, конкретно парсер, тем более для несложного Си, найти в наши дни очень даже реально.

Более того, я точно знаю, что за три-четыре месяца полноценной дневной работы можно сделать парсер и генератор кода для небольшого языка и несложной архитектуры, реальной или виртуальной. Сам делал пару раз в качестве развлечения и один раз по работе.

Но я не уверен, что аналог GCC или Clang — дело столь же подъемное.

Впрочем, ладно. Процессор и собственная архитектура вообще — дело гораздо более широкое, как вы вполне резонно заметили.

Мне на самом деле интересно, какая есть литература от русских авторов на тему компиляторов, поэтому и спрашиваю. Разумеется, речь не только о парсере, но и об остальных аспектах задачи.

Может, подскажете..?
ТАКИХ компиляторов у меня самого полный Гитхаб :-)

Information

Rating
Does not participate
Location
Bromley, England - London, Великобритания
Date of birth
Registered
Activity