лично я просто субпекеджи делаю в текущем проекте и лью в репу самого проекта.

Ну такое(

Но вариантов не много...

Я бы докер использовал для таких целей

лично я просто субпекеджи делаю в текущем проекте и лью в репу самого проекта.

Ну вот так всякие dlib и получается, где в одном пакете разные совсем либы.

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

Ну вот так всякие dlib и получается, где в одном пакете разные совсем либы.

Ну я же свои проекты не пихаю в общий реестр. Я вообще-то рассказал, как лично я выкручиваюсь в коммерческих проектах.

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

Засираться будет, вопрос степени засирания.

Когда каждый день по три очередных бложика пихаются в реестр - это печально.

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

Наверное npm рекордсмен по количеству заброшенных говнолиб в реестре

Говорят в гошечке такой же треш творится

В гошечке нет своего даба вроде как

Там вообще прямые ссылки на гитхаб мастер были

У них там свой трэш творился

а это гоферы не котируют? https://github.com/golang/dep

это вроде сравнительно недавняя штука, раньше не было

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

Да ладно, а Гугл?)

Для примера apt

Я придумал решение))))

Менять хосты и делать свой сервер пакетов)))

Тех пакетов что нет - пробрасывать запрос на оригинальный сервер

Гы)))

Тот ещё костыль)))

Кто пишет микросервисы, как вы осуществляете IPC между ними? Если несколько серверов?

Неа?

Жалко :(

заставила жизнь попробовать std.experimental.allocator… пока счастлив

то что “текло” - не течет

В смысле сам аыделяешь и удаляешь память под свои объекты?

Плохо, что каждый норовит свое поделие в реестр DUB засунуть. Как бы оно не превратилось в ад, который сейчас творится в npm

ну так что в етом плохого? в Google Play 80% мусора и все равно живем

просто надо норм категории допилить, поиск, рейтинговую систему и будет ок

просто надо норм категории допилить, поиск, рейтинговую систему и будет ок

Согласен, а не одним плоским списком

В смысле сам аыделяешь и удаляешь память под свои объекты?

сам, но через IAllocator, без возни с malloc,emplace,addRange

сам, но через IAllocator, без возни с malloc,emplace,addRange

А в чем там разница? Я не в курсе

разница в том что через IAllocator это делается в две строки и без собственного кода

вместо auto a = new B(); пишешь allocator = allocatorObject(Mallocator()); auto a = allocator.make!B(); и вуаля, ты работаешь через malloc

а не с GC

вместо auto a = new B(); пишешь allocator = allocatorObject(Mallocator()); auto a = allocator.make!B(); и вуаля, ты работаешь через malloc

Тоесть не вычитываешь сколько тебе нужно выделять памяти и реально ее сам не выделяешь?

А чего не использовать стандартный алокатор? Как он там theAlocstor

Кажется так

а стандартный где выделяет?

Не знаю

Просто увидел, что ты свой декларируешь, решил уточнить

ну я думаю что стандартный выделяет в области GC, а я там не хочу

ну я думаю что стандартный выделяет в области GC, а я там не хочу

Ясно

Правда начинается пляски, а когда этот объект удалять то)

И массивы тоже через свой алокатор гонишь?

у меня ссылка на этот обьект из refcount структуры, я в её деструкторе вызываю dispose для объекта

то есть в конструкторе структуры создаю обьект и в деструкторе освобождаю. полный детерминизм

у меня ссылка на этот обьект из refcount структуры, я в её деструкторе вызываю dispose для объекта

Ну а если указатель где-то?

то есть в конструкторе структуры создаю обьект и в деструкторе освобождаю. полный детерминизм

Для каждого объекта у тебя +1 структура, верно?

ну представь структура с RC это дескриптор сокеты, а обьект который нужен это некие данные которые нужны в виде класса для этой сокеты.

А разве структура не сдохнет при выходе из скопа?

Или ты не в куче создаёшь?

сдохнет когда счетчик ссылок на нею обнулится

сдохнет когда счетчик ссылок на нею обнулится

Это какая-то стандартная структура?

theAllocator.make!T;

Деструктор не вызывается

Значит не в СМ создает

https://dlang.org/phobos/std_experimental_allocator.html

https://gist.github.com/anonymous/271e21408e4567becd527f55983eb4f9

Не, я о этой RC структуре имел ввиду

Где о ней можно почитать?

Или это самописное что-то?

не это RefCounted изstd.typecons

Спасибо, сейчас почитаю

блин я тут на канале в 10 раз больше знаний получил чем в книгах по D))

ERROR: S client not available

Именно так оно и работает. Телеграм это ценнейший источник актуальных знаний

Все равно не понял, как тот RC структура работает.

Она же удаляется при выходе из скопа

В чем прикол....

то что “текло” - не течет

Чем проверяешь на течь?

Не течь, а "течь". Смотрел top-ом на размер rss

В чем прикол....

внутри счетчик ссылок

при копировании увеличивается, при деструкции уменьшается. Как только счетчик становится нулем уничтожается сам объект.

точнее говоря внутри структуры указатель на кусок памяти, выделенный аллокатором (не ГЦ). В этом куске лежит объект и счетчик. Счетчик фактически считает сколько в приложении на данный момент есть копий этих структур с указателем.

если после очпредной деструкции (выход из скопа) счетчик обнулился, значит больше нет ссылок на выделенный объект, а значит он больше не нужен и уничтожается.

Не течь, а "течь". Смотрел top-ом на размер rss

а что текло-то? 32 бита?

тут вот более общая инфа https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D1%81%D1%87%D1%91%D1%82_%D1%81%D1%81%D1%8B%D0%BB%D0%BE%D0%BA

Пухло в памяти. Я не говорил что текло по настоящему. Теперь не пухнет,

Пухло в памяти. Я не говорил что текло по настоящему. Теперь не пухнет,

Ну, по-моему, это как раз и есть по-настоящему.

Просто создание классов в ГЦ ты заменил на RC?

Ну, по-моему, это как раз и есть по-настоящему.

Не соасем. Gc просто не видел пока повода запуститтся и почистить. Это было вид но профайлером.

Может он бы и начал ограничивать потом память

Не соасем. Gc просто не видел пока повода запуститтся и почистить. Это было вид но профайлером.

А если вставить GC.collect()?

Не пробовал, могу позже попробовать

в общем картина понятная: gc использует всю свою память пока не упирается в свой какой-то предел если не вызываешь GC.collect(). Всё это время растёт обьем dirty pages. Когда дошел до предела - начинает чистить и всё стабилизируется. Так-же стабилизируется если вызываешь GC.collect()

если использовать mallocator то память gc не используется совсем и diry pages нету.

при этом разница обьемов для этого синтетического теста - 40к и 800к

Не соасем. Gc просто не видел пока повода запуститтся и почистить. Это было вид но профайлером.

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

да

в общем картина понятная: gc использует всю свою память пока не упирается в свой какой-то предел если не вызываешь GC.collect(). Всё это время растёт обьем dirty pages. Когда дошел до предела - начинает чистить и всё стабилизируется. Так-же стабилизируется если вызываешь GC.collect()

Тогда значит не течет.

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

еще родной GC по-моему никогда не возвращает память системе

Даже если есть пустые пулы. Или нет?

есть вызов minimize

https://dlang.org/phobos/core_memory.html#.GC.minimize

и он конечно как-то работает

https://dlang.org/phobos/core_memory.html#.GC.minimize

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

естественно…