Ну вот есть https://dlang.org/phobos/std_container_dlist.html может это тебе подойдет

> Реализация FIFO пишется строк в 10 Это не ответ. Есть много таких алгоритмов, которые уже в std.

Довольно эффективно написано

Я ubyte храню...

а там у них ссылки size_ptr

(подозреваю)

впрочем да, ты прав

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

Ну и замутить что-то типа кольцевой очереди

Вот такой бы шаблон в std готовый уже!..

Таких специфичных в std нету, там довольно обобщенные случаи.

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

У меня ругой кейс: мне надо быстро накидать а если вылезет проблема со скорсотью то уже свой сделать. Этот кейс решается присвоением слайса.

Кстати в dub можно найти довольно много пакетиков которые предоставляют всякие обобщенные штуки, может там есть. Дишники любят делать по 10му разу свои контейнеры и аллокаторы )

Ну тогда возьми тот double linked list

> которые предоставляют всякие обобщенные штуки и баги

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

ну ты ж понимаешь какого уровня эти проекты? на 1 нормальный там 10 написанных "лишь бы было"

Вот мой личный бугурт: https://github.com/msoucy/dproto/issues/96 даже не отмечен лейблом "баг"

> I haven't had much time for any side projects. Хех отличный ответ

Вот. При том что сейчас у нас нет другого работающего способа Protobuf читать

вот еще есть набор полезных штук https://github.com/dlang-community/containers

Ок, проблема номер 2: поиск code.dlang.org не находит такое

Я тоже только сегодня думал какое же говно "официальный" репозиторий пакетов. У него кстати даже нет API так что спарсить и построить на основе свое не получится.

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

> У него кстати даже нет API Есть но секретный

Надо как-нибудь будет написать Людвигу чтобы сделал публичный JSON чтобы все могли пользоваться.

https://github.com/dlang/dub-registry/issues/279

> написать Людвигу чтобы сделал А то у нас лапки!

Все зашиваются, всё в бабло упирается.

Подождите ко, какие еще лапки? Никто не может сделать это кроме него по факту, так как у него монополия на dub пакеты

Свое написать можно будет только вместе со своим же менеджером пакетов, а дальше что? Продвигать его? Война менеджеров пакетов?

Ну конфиг допустим нормальный уже у них. (имхо!)

а менеджер можно и другой, и регистрацию пакетов другую (+ спарсить ту что есть)

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

Недавно видел на форуме вроде вопрос поднимали про пакеты: что делать со старьём?

там есть пакеты которые заброшены и давно не собираются

а менеджер можно и другой, и регистрацию пакетов другую (+ спарсить ту что есть)

Да ну это бред, это как Tango vs Phobos будет

Конкретно с dub вроде проблема не в коде а в отсутствии понимания верного подхода. Мы не знаем как это сделать правильно. Недавно ознакомился с go - мне не понравилось, ява тоже, и нода.жс тоже.

Судя по всему не только я такой.

Конкретно с dub вроде проблема не в коде а в отсутствии понимания верного подхода. Мы не знаем как это сделать правильно. Недавно ознакомился с go - мне не понравилось, ява тоже, и нода.жс тоже.

Что именно сделать?

Так то в npm довольно хорошо сделано все

Да вот же недавно полинета лежало

Во! Кстати! Для code.dlang.org я бы принудительно выпилил блобы бинарные.

Есть такие пакеты которые (для винды обычно) юзают их вместо исходника лежащего рядом. Хз что там на самом деле.

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

Емае, вот это easter eggs у сайта ) Если зайти на страницу любого пакета и в урле дописать .json то выдается хорошая структурированная инфа по нему :)

угу. но это ТАЙНА)

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

особенно всякими CI-сборками

Ну то есть если делать свой фронтенд к репозиторию пакетов, то не стоит опираться на API и в любой момент все может сломаться.

Ещё мысль: надо попробовать дерево зависимостей публичных пакетов нарисовать. Очень похоже что есть 3-4 заброшенных, от которых вообще всё нафиг зависит.

Багу нашёл - при сборках релизной версии неверно работает core.bitop.bt - возвращает мусор. Думаю, проблема не с этой функцией, а код dmd генерит неверный. https://github.com/denizzzka/dcpu16/commit/6f2bf53411474daeb91a930bfaf323d7e70a8f01#diff-88543e6d645539c8eb75e58e103ebd3eL138

Ну это надо ишью заводить у них там

Это сначала надо уменьшить до разумного примера

Щас проверим по-другому - заменим стандартную bt на самописную дубовую не меняя больше ничего

Подтвердилось! https://github.com/denizzzka/dcpu16/commit/c5211945538c0b230580a7cf5d2e8c29d82c87f1

Выделил отдельной веткой. Хз что дальше делать - не могу запустить сборку одновременно релиза с юниттестами.

Ну поздравляю, надо делать ПР в core

Не, с чего PR? Баг не в функции.

Баг где-то в конпеляторе. Потому что иначе функция бы врала и на дебажных сборках.

А, ну значит issue

Воот, а чтобы issue надо уменьшить код. Я попробовал просто пример сделать - он на релизе норм отработал.

Есть!

кек

https://issues.dlang.org/show_bug.cgi?id=18461

пробуйте)

$ dub run --single bitop_bt.d --build=release Performing "release" build using /usr/bin/dmd for x86_64. bitop_bt ~master: building configuration "application"... Linking... Running ./bitop_bt Program exited with code -4

Надо запустить 10 раз

и увидеть что результат выполнения меняется

Да. Иногда нормально срабатывает, а иногда code -4

$ dmd --version DMD64 D Compiler v2.078.1 Copyright (c) 1999-2017 by The D Language Foundation written by Walter Bright

Вот -4 это нормально, а когда она просто завершается то это не нормально

Радует что это не только у меня )

Я этот багтрекер ненавижу, там баги еще где-то с 2013 наверно болтаются

Такое ощущение что всем плевать на него

Ну такое-то не оставят - обхода нет, бага явно не в самой функции а в том как её компилирует компилятор.

гейзенбаги никто не любит

@chebotarevp https://issues.dlang.org/show_bug.cgi?id=18461#c7 Дело раскрыто

фигасе как быстро

Какие у вас проблемы интересные, баги в языке ищете. А у меня code-d снова капризный какой-то.

Сначала работало все, а когда поставил в зависимости vibe.d, перестал любые проекты грузить.

а оно там автокомплит в виде демона не юзает ли?

Может он наелся сырцов vibe.d и поплохел?

Смотри в консоли разработчика, он там выплевывает ошибки

Может он наелся сырцов vibe.d и поплохел?

По логам до них не дошло.

Смотри в консоли разработчика, он там выплевывает ошибки

Так ничего нет, оно просто зависает

Речь о представлении ответа (от БД) в терминах языка

А разве Variant это не тип языка? Я думал когда не понятно что прилетит его юзают

Variant — это магия из std.variant)

привет. Как вы обычно поступаете с непонравившимися IDE для языка D - забываете про них или делаете feature requests ?

привет. Как вы обычно поступаете с непонравившимися IDE для языка D - забываете про них или делаете feature requests ?

А у нас есть выбор?

7.40 answer detected

я забил)

я забил)

+

Хотя оживить mono-d хотелось бы

но чет он совсем умер.

в большей степени потому, что feature request для eclipse «жрать поменьше оперативки» — это из разряда фантастики)

в большей степени потому, что feature request для eclipse «жрать поменьше оперативки» — это из разряда фантастики)

Оно вроде живое снова, да? А то помнится там застой был.