M
Если запуск именно на винде непринципиален, то можно WSL юзать
elixir лежит?Size: a a a
2021 March 19
n
А где сам
LL
Видимо не может подхватить какие-то файлы из
System32DG
Elixir почему то работает только в C:\Windows\System32, на втором скриншоте мой PATH. У кого-то есть идеи как это исправить?
А как пришла идея запускать elixir внутри System32?
Мне кажется, тут есть какая-то предыстория, в которой скрыта разгадка.
Мне кажется, тут есть какая-то предыстория, в которой скрыта разгадка.
n
А как пришла идея запускать elixir внутри System32?
Мне кажется, тут есть какая-то предыстория, в которой скрыта разгадка.
Мне кажется, тут есть какая-то предыстория, в которой скрыта разгадка.
я попытался запустить консоль от имени администратора и тогда это сработало, но я заметил, что всё работало не из-за прав администратора, а именно из-за того, что я нахожусь в System32
DG
я попытался запустить консоль от имени администратора и тогда это сработало, но я заметил, что всё работало не из-за прав администратора, а именно из-за того, что я нахожусь в System32
Я пока не очень уверенный пользователь Windows, но нагугливается много подобного:
Что, если добавить?
Я чуть позже на свой машине с Windows могу посмотреть.
PATH=C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x8 6)\WinSCP;C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS \System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
То есть - System32 у вас там вроде как стандартная часть PATH.Что, если добавить?
Я чуть позже на свой машине с Windows могу посмотреть.
DG
Я ставил Elixir на Windows установщиком с офф.сайта и оно сразу как-то работало, могу найти видео своей установки. Там были только проблемы со сборкой некоторый native extensions
n
Я пока не очень уверенный пользователь Windows, но нагугливается много подобного:
Что, если добавить?
Я чуть позже на свой машине с Windows могу посмотреть.
PATH=C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x8 6)\WinSCP;C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS \System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
То есть - System32 у вас там вроде как стандартная часть PATH.Что, если добавить?
Я чуть позже на свой машине с Windows могу посмотреть.
я добавил C:\WINDOWS\System32 в Path и оно заработало! Ранее я пробовал такой способ, но видимо по ошибке добавил C:\WINDOWS\system32. Спасибо!
MZ
Эээээм
ع
я добавил C:\WINDOWS\System32 в Path и оно заработало! Ранее я пробовал такой способ, но видимо по ошибке добавил C:\WINDOWS\system32. Спасибо!
A
А как можно процессам запущенным в одном супервизоре обменяться своими pid?
Например создаю сервер с сокетом и динамический супервайзор рядом с ним. Сервер после приёма соединения создаёт процесс для его обработки и передаёт динамику для управления. Как получить в сервере pid динамика?
Думал про имена. Получается их надо как-то генерировать, например по номеру порта, ощущение кривизны и хрупкости конструкции.
Например создаю сервер с сокетом и динамический супервайзор рядом с ним. Сервер после приёма соединения создаёт процесс для его обработки и передаёт динамику для управления. Как получить в сервере pid динамика?
Думал про имена. Получается их надо как-то генерировать, например по номеру порта, ощущение кривизны и хрупкости конструкции.
ŹR
Registry
A
Registry
Что-то вроде генерировать только имя этого реестра а в нём просто использовать имена модулей для регистрации?
A
Есть наверно лучше формулировка вопроса. Нормально ли при инициализации сервиса генерировать какой то instance id и дальше передавать его всем процессам чтобы они коммуницировали друг с другом по именам с этим id. Не важно используя его для формирования глобальных имён или через Registy. Или это какой-то велик и процессы из одной иерархии могут проще дискаверить друг друга?
AD
Есть наверно лучше формулировка вопроса. Нормально ли при инициализации сервиса генерировать какой то instance id и дальше передавать его всем процессам чтобы они коммуницировали друг с другом по именам с этим id. Не важно используя его для формирования глобальных имён или через Registy. Или это какой-то велик и процессы из одной иерархии могут проще дискаверить друг друга?
если процессы по одной штуке создаются, то можно по именам
AD
GenServer.start_link(__MODULE__, ..., [name: __MODULE__])например
A
GenServer.start_link(__MODULE__, ..., [name: __MODULE__])например
Не, я про случай когда может быть несколько экземпляров одного сервиса.
LL
Есть наверно лучше формулировка вопроса. Нормально ли при инициализации сервиса генерировать какой то instance id и дальше передавать его всем процессам чтобы они коммуницировали друг с другом по именам с этим id. Не важно используя его для формирования глобальных имён или через Registy. Или это какой-то велик и процессы из одной иерархии могут проще дискаверить друг друга?
Нормально
A
Registry
Вот же ж
AN
Есть наверно лучше формулировка вопроса. Нормально ли при инициализации сервиса генерировать какой то instance id и дальше передавать его всем процессам чтобы они коммуницировали друг с другом по именам с этим id. Не важно используя его для формирования глобальных имён или через Registy. Или это какой-то велик и процессы из одной иерархии могут проще дискаверить друг друга?
этого нет из коробки, хотя могло бы, ведь супервизор знает свои процессы. Но тут надо Registry или мэнеджер какой-то, или в ets складывать