PjOrion - редактирование, компиляция, декомпиляция, обфускация модов (Версия: 1.3.5 Дата: 11.08.2019)

[GPCracker 2,088]

Потому что свой?

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

А для себя "и так сойдет", т.е. фактически идет основной упор на чтобы работало, а не чтобы понятно было.

Для однократного решения задачи - да, главное чтобы работало.

Если расчет на более-менее продолжительный срок - нужно писать нормально.

Известный эффект. Все люди делятся на две категории, те кто доносят мусор до урны и те, кто не доносят. Также и в программировании. Либо ты всегда делаешь годный код, либо ты притворяешься, когда смотрят, и кодишь ногами, когда ни кто не видит или не проверят. Это называется отношение.

У всех разное чувство приемлемости такого отношения. Для кого-то код, написанный ногами, приемлем только для отладки алгоритма (поскольку код на этой стадии очень сильно меняется, нужно сделать, чтобы работало и правильно работало), а для кого-то и в релизе.

[SkepticalFox 1,445]

Не говнокод, а обфускация.

[GPCracker 2,088]

Не говнокод, а обфускация.

Интеллектуальная обфускация в действии ))))

Это по принципу "Бей своих, чтобы враги боялись".

[Polar Fox 16]

Для однократного решения задачи - да, главное чтобы работало.

Если расчет на более-менее продолжительный срок - нужно писать нормально.

 

Я там чуть выше исправился. Тот случай когда два слова полностью меняют смысл.

 

Код, который работает хорошо, ещё далеко не хороший код, если с ним нужно работать.

 

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

[StranikS_Scan 4,210]

У всех разное чувство приемлемости такого отношения. Для кого-то код, написанный ногами, приемлем только для отладки алгоритма (поскольку код на этой стадии очень сильно меняется, нужно сделать, чтобы работало и правильно работало), а для кого-то и в релизе.

 

Ни чего подобного. Отношение не зависит от уровня знаний или сложившейся ситуации. Это точно также как сказать "да там такие обстоятельства были, что я просто вынужден был мусор выкинуть на газон". Ответ этому может быть только один - враньё, голимое враньё!

Edited August 28, 2015 by StranikS_Scan

[GPCracker 2,088]

Отношение не определяется уровнем знаний или сложившейся ситуаций.

В этом ты конечно прав, но я не это имел ввиду. Далеко не всегда получается написать нормально, особенно если ты не совсем понимаешь, как это надо писать, и пытаешься разобраться. Соответственно, делаешь код рабочим. Из-за большого количества изменений качество кода падает. Просто кто-то его потом переписывает по-нормальному, кто-то сразу, кто-то после полного тестирования, а кто-то оставляет как есть.

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

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

 

@StranikS_Scan, с чем могут быть связаны редкие потери вывода через трансмиттер, а также довольно нередкие задержки (подвисания) в выводе? Чтобы получить "зависший" вывод приходится отправлять принт, решение конечно, но все равно как-то немного неудобно, хотя и (спасибо за это) есть возможность выборочного выполнения. М.б. файлы-mutex'ы все-таки временами срабатывают одновременно?

Edited August 28, 2015 by GPCracker

[SkepticalFox 1,445]

Может уже вместо mutex'а использовать mmap?

[StranikS_Scan 4,210]

В этом ты конечно прав, но я не это имел ввиду.

 

Ээээ, да я вижу пацаны чего-то пишут, дай думаю тоже напишу

 

Может уже вместо mutex'а использовать mmap?

 

А может вы все таки вдвоем возьмете и напишите альтернативный код? Там всего пара модулей в wottransmission.zip. Я же не железный дровосек, как смог/сумел, так сделал. читай нарубил 

Edited August 28, 2015 by StranikS_Scan

[GPCracker 2,088]

Может уже вместо mutex'а использовать mmap?

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

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

Если решать вопрос более абстрактно, то можно использовать сокеты для передачи данных (тогда доступ будет непрерывным, данные будут получаться практически сразу, интервал обработки сокета), в качестве адреса использовать localhost/127.0.0.1. Насколько такой подход стабильный и кроссплатформенный - сказать не могу, с сокетами особо не работал. Да и работать с ними не так то и просто. Проблема в основном в грамотном описании их поведения, слишком уж сложные для контроля объекты (куча разных ошибок, которые нужно обрабатывать, нужен отдельный поток на обработку данных, буферизация, выборка (select/poll) и т.д.). Модуль asyncore конечно нехило помогает в этой теме, но там еще нужно неслабо покопаться. А так есть общий примерчик клиента и сервера, но там нужно допиливать обработку ошибок, краши из-за падения сокета (как раз таки самая главная проблема) не есть хорошо. Только вот времени на это пока нет...

[SkepticalFox 1,445]

 

 

шаринг флагов

Но mmap тоже умеет шарить файлы.

[GPCracker 2,088]

Но mmap тоже умеет шарить файлы.

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

Проблема состоит в том, что это реализуется через msvcrt, и, насколько я понимаю, работает только на винде, поэтому в питоне не реализовано (м.б. я ошибаюсь, не особо вчитывался, но ссылку я скинул).

Что касаемо mmap, он использует file.getfileno(), ЕМНИП, это как я понимаю, хэндл файла, а он вроде как (не уверен) будет разным для разных процессов, поскольку они независимо открывают файл. Хотя, учитывая что mmap как-то завязан на систему, поскольку конструктор для винды и юниксов разный, всякое может быть. Нужно внимательно читать доки и смотреть сорцы.

[SkepticalFox 1,445]

@GPCracker, не то я хотел сказать. Ой не то...

Можно вообще pyd написать и общаться между процессами на уровне ОЗУ)

 

Нужно внимательно читать доки и смотреть сорцы.

flags specifies the nature of the mapping. MAP_PRIVATE creates a private copy-on-write mapping, so changes to the contents of the mmap object will be private to this process, and MAP_SHARED creates a mapping that’s shared with all other processes mapping the same areas of the file. The default value is MAP_SHARED.

Вот вам доки.

 

У меня в лине все работает!

Синхронизация идеальна!

 

Что касаемо mmap, он использует file.getfileno(), ЕМНИП, это как я понимаю, хэндл файла, а он вроде как (не уверен) будет разным для разных процессов, поскольку они независимо открывают файл.

file.fileno() - file descriptor

Он действительно неодинаков для процессов.

Edited August 28, 2015 by ShadowHunterRUS

[StranikS_Scan 4,210]

Можно вообще pyd написать и общаться между процессами на уровне ОЗУ)

 

Не можно, юзание dll заблочено в клиенте в целях безопасности.

Edited August 28, 2015 by StranikS_Scan

[GPCracker 2,088]

Вот вам доки.

Хмм.... Однако. Неспроста там разные конструкторы для винды и юникса.

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

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

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

[POLIROID 210]

Не можно, юзание dll заблочено в клиенте в целях безопасности.

не заблочено Edited August 29, 2015 by POLIROID

[SkepticalFox 1,445]

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

Это вроде этого:

 

Если решать вопрос более абстрактно, то можно использовать сокеты для передачи данных (тогда доступ будет непрерывным, данные будут получаться практически сразу, интервал обработки сокета), в качестве адреса использовать localhost/127.0.0.1.

вариант с localhost - нужно попробовать.

 

mmap - отличный способ передачи/получения данных между питоном ориона и питоном WOT.

Да и wottransmission не особо переделывать придется.

 

не заблочено

Тогда вообще проблем не вижу.

Edited August 29, 2015 by ShadowHunterRUS

[GPCracker 2,088]

Это вроде этого:

Если ты хочешь сказать, что это забивание гвоздей микроскопом, то не совсем.

RPC

Процесс передачи команд и получения результата сильно напоминает RPC, правда придется делать его двунаправленным, ибо логи иногда приходят "сами по себе".

вариант с localhost - нужно попробовать.

Хммм... Но допиливать неслабо придется. Как минимум клиент писать. Да и в Орионе принцип "очередь на выполнении", а тут Лок.

mmap - отличный способ передачи/получения данных между питоном ориона и питоном WOT.

Способ неплохой, но как я уже писал, бывают рассинхроны. Когда вторая нода входит в блок установки блокировки, а первая уже там, но блокировку поставить не успела. Имеется ввиду использование n-го байта mmap как флага. Использовать файлы в качестве лока - лишняя нагрузка на хард + время на системные вызовы (опять же если хард не очень быстрый).

Да и wottransmission не особо переделывать придется.

Зато Орион придется. И, скорее всего, неслабо так. Не знаю, какова поддержка mmap на Делфях... А подымать ноду на питоне - это еще один процесс (ну не совсем процесс, но вы поняли). На терминал вешать не совсем хорошо (фейерверк при terminal->restart обеспечен). У сокетов наверняка есть поддержка в Делфях. Да и вообще можно в принципе заюзать что-то типа nc и просто перенаправить потоки ввода-вывода. Плюс возможность, как уже писали, подрубиться с нескольких устройств одновременно, либо просто с другого устройства (подрубиться с планшета и видеть логи сразу, не сворачивая игру, это очень даже прикольно). Просто локальный адрес выставляешь какой нужно на сервере)) К тому же, сокет - потоковый, и не нужно заморачиваться с блокировками доступа и т.д. - ты просто читаешь или пишешь из / в него когда тебе что-то нужно. Тем более, в питоне уже есть реализация SocketServer (насчет клиента - не знаю).

Самое веселье - это грамотная реализация очередей выполнения.

Edited August 29, 2015 by GPCracker

[SkepticalFox 1,445]

mmap по определению не нагружает хард.

[GPCracker 2,088]

mmap по определению не нагружает хард.

Ты невнимательно прочитал то, что я написал. А писал я про то, что для стабильной работы mmap-трансфера необходимы внешние Локи. Использовать файлы - нагрузка на хард. Что можно использовать кроме файлов между процессами - большой и весьма интересный вопрос. Зачастую проще бывает не решать проблему, а просто ее обойти, например, использовать поток вместо выделенной области памяти.

Я давненько еще игрался с mmap, немного кода осталось.

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

[o-0-0-0 77]

есть у кого 0.9.10_Decompile_WOT.zip  , за ранее спасибо . ( самому сделать не лень , кое что не декомпелируется почему то )