tmptrash / jevo Goto Github PK

Поддержка нескольких инстансов/процессов. Они должны общаться между собой с помощью Client/Server модулей в "быстром" режиме.

• попробовать создавать сразу все организмы и хранить их в массиве вместе с тасками (OrganismTask тип). При удалении просто помечать их, как удаленные и хранить индексы освободившихся в отдельном стеке.
• словарь ManagerData.organisms заменить на массив организмов. Их id - это индекс.
• Сделать _killOrganism() с удалением таски внутри (splice!()). После этого istaskdone() проверки уже не будут нужны. Еще нужно будет поменять главный цикл по организмам в _updateOrganisms() на обратный. Как в _updateOrganismsEnergy() чтобы удаление работало. Еще нужно останавливать таск организма после вызова _killOrganism() где это нужно. Например в _onGrab(). (этот пункт еще актуален?)

Перестать использовать глобальный Manager.xxx. Передавать его как параметр в функции. То же самое с Config._data. Нужно передавать его первым параметром.

Смотри фотку с свойствами орг-ма. Это фотография идей, записанных на песке в Тайланде :). Нужно найти её и внести забытые пункты сюда.

Почему я не вижу скажем команду getEnergy() в коде организмов? Это случайность или там что-то поломалось?

Проверить что тормозит - замыкание либо анонимные фу-ии. Если второе, то нужно глянуть на FastAnonymous пакет. Вроде, как в v0.5 анонимные функции - быстрые.

Добавить produce() в метод _onDot(), чтобы движение организмов было плавное. Зависит от фикса баги: #15017. При включении этой фичи появляется проблема неправильного подсчета ips, так как код всех организмов не выполняется за один раз полностью.

У каждого организма должен быть собственный counter на основе которого делаются мутации, уменьшение энергии, клонирование и т.д. Это поспособствует более плавному распределению в выполнении их кода. Сейчас все "тяжелые" операции, такие как мутации или удаление "самых слабых" производятся сразу для всех организмов. В этот момент вся система "подвисает".

Добавить рекомбинацию генов и половое размножение одновременно со случайными мутациями (как?!) Меняться функциями.

Ввести абсолютное количество итераций, которое будет заменять организмам время. Так же ввести совокупное время, которое прошло с момента запуска популяции. Еще, должно быть время и ips с момента последней смерти популяции. Всего будет 4 параметра.

Добавить графики реального времени об изменении разных параметров: енергии, размера кода, частоте мутаций, всех параметров Organism типа, количество поломок (exceptions), общее кол-во энергии популяции

• общее кол-во энергии в популяции (min,max,cur)
• общая адаптация (мутации*енергию)
• общее кол-во мутаций
• общая вероятность добавл/изм/удал мутаций
• сколько определенных кодовых конструкций сейчас в популяции (смотри CodePart тип)
• отчего умирают организмы: старость, съедение, уменьшение энергии, альструизм
• количество неудавшихся мутаций
• Пройтись по всем свойствам организма и системы

Исправить проблему с черными организмами

Использовать codeSize. Вычитать его на каждой итерации. Проверить работает ли он.

Сделать невозможным отключение всех мутаций. Как минимум одни мутации (при рождении или периодические) должны быть включены. Иначе все организмы просто вымрут. Так уже было :)

Добавить while(true) внутри Task() функции, чтобы организмы могли "помнить" свое состояние. Под вопросом.

Добавить команду termFollow(orgId, color). Она будет переключаться между менеджерами и "следить" за одним организмом. Возможно нужно будет временно менять его цвет или как-то выделять среди других.

Добавить 3 измерение.

ManagerData.totalOrganisms не сбрасывается при вымирании всей популяции. Нужно добавить еще одно свойство, которое будет показывать количество организмов с момента рождения популяции.

Глянуть на FastAnonymous пакет. Нужно внедрить его в анонимные функции организмов. Как вариант, можно попробовать измерять скорость в julia v0.5.0

• Добавить остановку сервера с консоли. При остановке процесс должен вернуть 0.
• Так же, добавить реконнект клиентов к серверу, если он перезагрузился

Если нет активных соединений нужно не вызывать yield() в главном цикле. Она забирает очень много ресурсов. Как вариант, можно проверять если ли на одном из сокетов данные, если нет, то не вызывать yield(). Если есть, вызывать. Но этот подход нужно проверить. Возможно он не так быстр, как мне кажется...

Сделать два режима раскраски организмов: по родству и по кол-ву энергии. По родству на данный момент уже реализовано.

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

Обьединить remote world и terminal

Добавить версии для сервера, визуализатора, терминала,...

Попробовать Lint.jl и TypeCheck.jl

Использовать code coverage для юнит тестов. Смотри: https://github.com/JuliaCI/Coverage.jl/blob/master/README.md

Объединить Connections и ManagerData в ManagerData

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

Написать тесты (функ. юнит) для всех модулей. В первую очередь: Mutator, Code

Добавить smallchange мутацию. Смотри Mutator._onSmallChange(). Думаю универсального способа сделать не выйдет. Лучше делать для каждого метода свой личный small mutator. Он будет знать формат выражения и добавить мутации без ошибок.

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

Добавить функцию мутирования: 'копирование' помимо add/change/del...

• Оптимизация с помощью ProfileView.
• Нужно протестировать приложение на статических организмах. Не должен вызываться eval(). Так будет реально видно что в организмах или системе тормозит. Сейчас eval() скрывает эту информацию.
• Еще, можно тестировать скорость по ips, отключая разные ее части и смотреть на сколько быстрее стало.
• Так же попробовать тестировать с уже сохраненными и сложными организмами в бакап файле чтобы понять сколько занимают коды организмов, а сколько сама система

Минимизировать ошибки: удаление переменных/фу-ий, которые используются, замена объявления переменной на ее вызов,...

Отправлять ips, только когда он меняется

Добавить время к сообщениям в логах сервера

Переписать комменты на julia docile. Нужно разобраться где это может использоваться. Может нам нужна обычная документация?

Сделать частичную компиляцию кода. Например можно компилировать отдельные смутировавшие функции, а не весь код.

В _updateOrganisms() нужно создавать массив probs один раз и просто заполнять его. Так же, нужно указывать его длину и передавать её как параметр в getProbIndex()

counter переменная в _updateOrganisms() не должна быть равна нулю. После maxtype() присваивать 1. Это может вызвать ошибку деления.

Записать видео объяснение по jevo

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

Расширить атомарные элементы кода организмов на основе которых герерируются мутации. Сейчас список поддерживаемых команд очень короткий. Смотри тип CODE_PARTS в модуле Code.
Идеи:

• функции eatXXX() должны возвращать количество съеденной энергии
• функции stepXXX() должны возвращать статус (Bool) получилось ли стать в то место

Добавить лейбу с тестами на гитхаб

Продумать систему координат. В двух местах я все переварачиваю: в массиве и в opengl визуализаторе.

Строка "if Manager._cons.streamInit::Bool return counter end" должна быть в начале цикла. Просто сделай это...

Всё должно быть эволюционирующим/наследуемым признаком (кроме енергии)

Оптимизация: fn(a, ...), types, маленькие фу-ии по типу аргументов, одинаковый return функций, "$(...)" -> string("..", ".."). Нигде не должны создаваться массивы. Нужно создавать их раз в начале и просто переприсваивать элементы. Cмотри эту статью для деталей

Добавить примитивы для общения: say(var::Int8), listen(pos)::Int8. say() должен ложить число в свой локальный буфер. listen() забирать из этого буфера. При забирании число остается в буфере. Буфер должен быть цикличным.