← Сtrl

xam1816 · Июнь 26, 2022 09:39:24

py.user.next
у меня программа сама себе пишет конфигурационные файлы. И там одна часть программы (подсистема) пишет конфигурационные файлы для другой части этой же программы (подсистемы), таким образом эти подсистемы через эти конфигурационные файлы взаимодействуют. Там и стратегии выбираются, и отчёты друг другу передаются. Одна подсистема другой говорит “я там отчёт приготовила, возьми его там-то и там-то” или там “я ковыряла вот это кусок данных и поняла, что там вот такая-то структура, так что ты примени вот такой алгоритм для дальнейшего разбора, а то другой алгоритм даст ошибку или будет неточным”. И там куча таких подсистем и они все друг с другом вот так вот общаются. Всё это инкапсулировано, изолировано и так далее. И уж что в этих конфигурационных файлах ты никак не представишь, потому что их языки я разрабатывал отдельно друг от друга. И там никакого JSON'а нет, XML'а и так далее, там просто тексты. Но какие тексты?

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

Это похоже на то, как люди общаются в общем чате, передают нужные файлы друг другу, говорят что с ними делать, и в любой момент можно посмотреть в этот чат и увидеть кто чем занимается, в любой момент можно подключить нового человека, объяснив ему правила этого чата и что от него ждут…

AD0DE412 · Июнь 26, 2022 19:23:36

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

1. пжлст, форматируйте код, это в панели создания сообщений, выделите код и нажмите что то вроде

2. чтобы вставить изображение залейте его куда нибудь (например), нажмите

и вставьте ссылку на его url
…
есчщо

Отредактировано AD0DE412 (Июнь 26, 2022 19:28:07)

py.user.next · Июнь 27, 2022 04:04:21

xam1816
Как организован файл конфигурации, как подсистема понимает что для нее пришло сообщение, именно как это организовано в коде, какой-нибудь бы короткий пример.

Начинается всё вот с этого конфигурационного файла

# This file is a configuration file of loadshots v0.0.1

# For the topic url enable a proxy. Values are "on" or "off".
topic_proxy=on

# For the topic url set the proxy host address. May be domain or ip.
topic_proxy_host=localhost

# For the topic url set the proxy port. A number should be.
topic_proxy_port=9050

# For the topic url set the proxy type. May be "socks4" or "socks5".
topic_proxy_type=socks4

# For the topic url set the proxy user. Only for proxy type socks5.
topic_proxy_user=

# For the topic url set the proxy password. Only for proxy type socks5.
topic_proxy_password=

# For the image url enable a proxy. Values are "on" or "off".
image_proxy=on

# For the image url set the proxy host address. May be domain or ip.
image_proxy_host=localhost

# For the image url set the proxy port. A number should be.
image_proxy_port=9050

# For the image url set the proxy type. May be "socks4" or "socks5".
image_proxy_type=socks4

# For the image url set the proxy user. Only for proxy type socks5.
image_proxy_user=

# For the image url set the proxy password. Only for proxy type socks5.
image_proxy_password=

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

Дальше, при запуске программа берёт этот конфигурационный файл и превращает его в такой

topic proxy on localhost 9050 socks4 - -
image proxy on localhost 9050 socks4 - -

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

Если в исходном конфигурационном файле на месте имени пользователя и пароля пользователя прокси-сервера стоит пустота, то во внутреннем конфигурационном файле, который якобы такой же, только сокращённый (это на первый взгляд так кажется, что это типа одно и то же и масло масляное), стоят дефисы. Дело в том, что пустота на месте пользователя, но не на месте пароля будет сдвигать непустой пароль на место имени пользователя и парольное поле будет восприниматься как пользовательское поле. Поэтому там дефисы. Они жётско позиционируют то, где именно и что находится, чтобы это было однозначно. То есть это не одно и то же, оно похоже на одно и то же, но это не одно и тоже. Оно похоже на то, будто мы просто из исходного конфигурационного файла комментарии стёрли, пустые строки убрали и компактно записали это всё. На самом деле, нет, там смысл изменён и внутренний конфигурационный файл может содержать любые разновидности прокси-серверов, которые в том числе и не указаны в исходном конфигурационном файле. Откуда же возьмутся эти прокси-серверы, если их нет в исходном конфигурационном файле, редактируемом пользователем программы? Они возьмутся при поиске прокси-сервера в Интернете. Когда мы подключаемся к одному прокси-серверу, а его там нет и он там нас перекидывает на другой прокси-сервер и таким образом пошла цепочка там какая-то, которая нас приводит в конце к какому-то нужному прокси-серверу, который в итоге и записывается в этот внутренний конфигурационный файл. Там может быть socks4, может быть socks5, а может быть какой-нибудь шлюз, идущий через tor, например. И этот внутренний конфигурационный файл расчитан на это всё, в то время как пользовательский конфигурационный файл расчитан только на socks4 и socks5. То есть это не просто для удобства сделано, а это разные вещи.

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

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

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

Второй внутренний конфигурационный файл

1 1 http://i1.screens.org/big/2009/1212/9a/c5e402e966a4bbc9739eeb90431ac19a.jpg box_view_wmv
1 2 http://i1.screens.org/big/2009/1212/ce/9671718b99191b779a146ec57d8d66ce.jpg cat_walks_wmv
...

Он хранит в себе информацию в каком дереве файл, какой номер по порядку у файла в дереве, адрес файла и имя, под которым нужно будет сохранять файл. На самом деле, это кусок имени файла, а не полное имя файла. А полное имя файла будет сформировано в следующей подсистеме, так как файлы не всегда загружаются с первого раза и по этим адресам содержатся пустышки, редиректы и просто какая-то хрень. И для борьбы с пустышками, редиректами и просто какой-то хренью есть подсистема обхода этих препятствий и перезагрузки файлов, которая после перезагрузки меняет имя у файла, дописывая в него то, что файл был перезагружен. Поэтому имя файла для загрузки не формируется сразу, как бы этого ни хотелось, чтобы типа всё просто загружать. В сложных ветвистых алгоритмах нельзя пренебрегать даже мелкими деталями. Это всегда сработает против тебя. Поэтому все детали находятся под контролем. И вот поэтому имя файла, под которым файл будет сохранён на диске после его загрузки прямой или опосредованной, формируется постепенно. Одна подсистема один кусочек имени файла получила, другая подсистема другой кусочек имени файла получила, потом в какой-то следующей подсистеме эти кусочки имени файла склеиваются правильным образом и таким образом в конце мы получаем имя файла, которое казалось бы должно быть видно изначально, а на самом деле изначально даже нельзя сказать, есть ли там этот файл или он давно уже удалён там и загружать оттуда просто нечего. Соответственно, если его там нет, то и сохранять ничего не надо под этим именем, оно просто выбрасывается.

Когда система загрузки загрузила файлы, она создаёт внутренний файл конфигурации для подсистемы перезагрузки

loaded scro test416579 001_001_box_view_wmv.jpg http://i1.screens.org/big/2009/1212/9a/c5e402e966a4bbc9739eeb90431ac19a.jpg
loaded scro test416579 001_002_cat_walks_wmv.jpg http://i1.screens.org/big/2009/1212/ce/9671718b99191b779a146ec57d8d66ce.jpg
...

Он хранит в себе информацию о том, как прошла загрузка (загрузился он вообще или нет), какой алгоритм загрузки использовался, под каким именем загружаемый файл сохранялся (имя содержит номер дерева и номер файла в дереве) и откуда реально он загружался (ссылки тоже не всегда можно использовать сразу, а сначала их надо переделать, сначала поняв, что они не прямые, а ссылки на маленькие файлы для предпросмотра, например). Тут загрузка шла с сайта screens.org, там она идёт по определённой схеме, поэтому в этом внутреннем конфигурационном файле указано имя этой схемы scro, так как в этой схеме загружаемые файлы могут не только на сайте screens.org находиться, но и на других сайтах, которые можно добывать в процессе загрузки, и имена у них другие, поэтому мы не можем из ссылки определить, что там за схема. Имя сайта для этого не подходит и даже формат ссылки для этого не подходит, так как ссылки одинакового формата могут получаться как в одной схеме загрузки, так и в другой, абсолютно другой, схеме загрузки. Поэтому схему загрузки мы пишем в этот файл отдельно, несмотря на то что по ссылке видно, откуда там файл загружается. По этому имени схемы загрузки в случае загрузки пустышки или редиректа подсистема перезагрузки будет определять, какой вид пустышки или редиректа там бывает обычно и как этот файл надо перезагружать, чтобы всё таки файл загрузить, и примет соответствующие меры для перезагрузки файла - либо она так его перезагрузит, либо так.

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

Выглядит это в конечном итоге всё вот так

[guest@localhost test]$ loadshots https://screens-site.com/topic?t=416579 test416579
Try `loadshots --help' for more information.
loadshots: Loading https://screens-site.com/topic?t=416579 ...
loadshots: Connect to topic with proxy socks4 localhost:9050
loadshots: Ok https://screens-site.com/topic?t=416579 loaded.
loadshots: Connect to image with proxy socks4 localhost:9050
loadshots: Found 3 trees with total 67 urls.
loadshots: Tree #1 has 15 urls.
loadshots: -|- Loading test416579 001_001_box_view_wmv.jpg ...
loadshots: -|- Loading test416579 001_002_cat_walks_wmv.jpg ...
^C
[guest@localhost test]$

Информация, отображаемая на экран, берётся из внутреннего конфигурационного файла. Обрати внимание на знак -|- . Что это? Это индикатор, который показывает, что данный файл загружается через соединение, настроенное через прокси-сервер. А когда прокси-сервера там нет, она рисует вот такое - - - .

loadshots: --- Loading test416579 001_001_box_view_wmv.jpg ...

То есть я всегда вижу, как я загружаю каждый файл.
И информация о том, как оно загружается, чтобы нарисовать тот или иной значок, берётся из внутреннего конфигурационного файла. То есть эта штука не встраивается в код напрямую, потому что система такая сложная, что сходу не ясно, как оно там и через что и куда и сколько раз загружается. Поэтому это всё формируется динамически. Что там написано в конфигурационных файлах, то и будет отражаться на экране конечном.

xam1816
Это похоже на то, как люди общаются в общем чате, передают нужные файлы друг другу, говорят что с ними делать, и в любой момент можно посмотреть в этот чат и увидеть кто чем занимается, в любой момент можно подключить нового человека, объяснив ему правила этого чата и что от него ждут…

Когда подсистема запускается, она не знает, откуда появился её входной внутренний конфигурационный файл. Также когда какая-то подсистема создаёт свой выходной внутренний конфигурационный файл, который становится входным внутренним конфигурационным файлом для следующей подсистемы, то эта подсистема, которая создаёт свой выходной внутренний конфигурационный файл, не знает ничего про следующую подсистему, которая будет этим внутренним конфигурационным файлом пользоваться, и она не знает, для чего она этот файл создаёт; она только знает, как его создать.

Что, так вот понятно всё? Кратенько написал тебе, не вдаваясь в подробности. Там ещё много всяких подсистем, я про них писать не стал просто, чтобы у тебя уши в трубочку не завернулись совсем уж. Там ещё подсистема преобразования ссылок, которая загружает страницы, отыскивает в них js-скрипты, в этих js-скриптах отыскивает адресы, потом собирает эти адресы из их частей, потом транслирует эти собранные из частей адресы в правильные адресы, потом их там сохраняет во внутренний конфигурационный файл и это всё отправляется потом на сборку команд для конечной загрузки в отдельную подсистему сборки команд, которая тоже там не два притопа три прихлопа, а тоже со своими заморочками там всякими.

Так что, думаю, для понимания того, как и что устроено, описания и этих пяти подсистем тебе хватит.

Отредактировано py.user.next (Июнь 27, 2022 05:07:37)

Python-сообщество

Уведомления

#1 Июнь 26, 2022 09:39:24

Возвращение значения из метода класса

#2 Июнь 26, 2022 19:23:36

Возвращение значения из метода класса

#3 Июнь 27, 2022 04:04:21

Возвращение значения из метода класса

Board footer