@deviator по поводу той ошибки с дикой утечкой памяти. Я все проверил и как и советовал создатель mysql драйвера собрал 64 битную сборку командой: dub -a=x86_64 Оно не только стало есть меньше памяти, но и стало ее освобждать нормально. x32 сборка. Один трек загруженный из БД в оперативку занимал 165 МБ (после твоих оптимизаций до них 240). 64-битная сборка на том же файле потребляет 77MB оперативки.

это только под виндой так или вообще в целом?

и это только с драйвером mysql?

я просто не помню что тот парень написал

или это проблема вообще в целом dmd для 32 бит?

https://github.com/mysql-d/mysql-native/issues/104

Под Linux я пока не проверял. Проблему встретил только в msql драйвере

он там пишет, что это GC на dmd x32 тупит

забавно

Вальтер наверно себя чувствует Apple которая убивает поддержку 32 битных приложений на iOS

Ну а че? Уже даже на RPi 64 бита. Времена 32 бит прошли)

Но это не повод забивать на баги

Во какую интересную штуку нашел http://osv.io

никак не пойму это Linux очередной или нет

https://en.wikipedia.org/wiki/OSv судя по всему, нет)

какое-то свое монолитное ядро у них

и в этом ядре, видимо, только jvm и слой совместимости с posix

как я понимаю vibed можно будет запускать и на redox с минимальными модификациями? https://github.com/redox-os/redox/issues/925

просто libc они вроде портировали, как я понимаю это одно из главных?

Кстати, а кто понял в чем суть? https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md Я прочитал несколько раз, но так и не понял что мешает делать локальный импорт. Они городят какой то with(import foo.bar) или что то подобное

я как-то поверхностно пробежался, но сути особой не уловил

типа быстрее собирается если импорты локальные

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

типа void foo(SysTime tm) { import std.datetime; ... }

если с импортом функции foo не будет имортироваться SysTime, то это бредятина

хотя сейчас так и есть

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

вот что я понял из 1005

http://dlang.org/blog/2017/02/13/a-new-import-idiom/ вот статья про это

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

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

Было: import std.stdio; void someFun(File f) { … } Стало: template from(string moduleName) { mixin("import from = " ~ moduleName ~ ";"); } void someFun(from!"std.stdio".File f) { import std.stdio; … }

как-то так)

меня прям радует io в d

from!"std.stdio".stdout ?

std std std

Что поделать) исправить это теперь трудно)

Меня больше радует, что File описан в std.stdio, а есть ещё std.file)

И он тащит с собой кучу зависимостей)

Можно просто сделать import std.file и посмотреть, как тут же разбухнет экзешник)

кстати, кто-нибудь делал фишку с автодобавлением версии и билда?

типа собираешь, а у тебя в исполняемом файле номера сами добавляются

я вот сейчас смотрю в git и что-то как-то не вижу того, чего хочу)

dub как-то умеет совмещать версию и коммит

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

короче намутил https://gist.github.com/deviator/9ebddcde784f26700bd84accb8b58792

Было: import std.stdio; void someFun(File f) { … } Стало: template from(string moduleName) { mixin("import from = " ~ moduleName ~ ";"); } void someFun(from!"std.stdio".File f) { import std.stdio; … }

Жесть какая, неужели прям так ужасно объявить импорт в начале модуля, что хотят городить эти костыли с импортом в compile time...

Ну вот выглядит да, стремновато.

Похоже на попытку изобрести неймспейсы

Жесть какая, неужели прям так ужасно объявить импорт в начале модуля, что хотят городить эти костыли с импортом в compile time...

дело не в compile time, а втом, что глобальные импорты по умолчанию влючаются в экзешник

если каждая функция свои импорты будет тянуть самостоятельно, то текущие модули можно будет раздробить, и не придется кучу всего лишнего тянуть в .exe

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

а анализ того какие импорты нужны, а какие нет он очень долгий?

это уже вопрос не ко мне, а к тем, кто пилит компилятор)

Всем привет)

привет

Почитал про язык. До этого учил и учу С++. Стоит ли учить D?

Смотря что ты хочешь от жизни

Я бы советовал немного поучить Си и потом переключиться полностью на D/C#. В С++ сейчас смысла мало

Ну мне просто нравится пока что. Так то не определился еще. Просто все плюют на плюсы а в канале про с++ спрашиваю так там все выебываться начинают какие они крутые и с таким нубским вопросом не лезь.

С++ это прошлый век. Смысла на нем писать сейчас крайне мало. Максимум — легаси код.

Просто когда то узнал что такое алгоритмы мне понравилась эта область. Но везде примеры практически на С++ потому выбор пал на него

Мнение эксперта

С++ это прошлый век. Смысла на нем писать сейчас крайне мало. Максимум — легаси код.

У меня 90% народу перешло на более высокоуровневые языки. На плюсах только пару человек пишет.

Да и спецификацию в 1700 страниц (может уже больше) я думаю из тех кто пишет на плюсах никто не читал. В итоге пишут реально как умеют

ERROR: S client not available

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

Ну я тут как бы не согласен, хоть и прошлый век, однако куча работы на с++ а на D найти нереально.

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

Если все это не хобби для тебя.

Если честно то хобби. Единственное что у меня получается и нравится.

А на ди что пишут. Читал статьи по нему, но лучше тут спросить я думаю тут опытные "дишники" )))

да толком ничего не пишут, слишком маленькое сообщество)

а так, в идеале, можно писать все от сайтов до драйверов)

в целом хорошая замена плюсам

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

но это язык для ценителей, наверное

так как если пофигу на чём и что писать, обычно берут что-то вроде C# и Java, потому что "библиотек много и IDE классная"

а откуда у меня вот тут nan может вылезать?

просто так число выводит, но строкой ниже уже заполняет структуру как если бы там nan был

судя по всему дело в этом: "If the VariantN object holds a value of the __exact__ type T, returns a pointer to that value" т.е. у меня тип просто не тот там

кстати в следующей версии фобоса должен появиться компилятор как библиотека http://dlang.org/phobos-prerelease/ddmd_expression.html

Я догадываюсь что это большое событие, но на твой взгялд что оно даст?

хохохохохохо!

mary christmas!!1

кстати в следующей версии фобоса должен появиться компилятор как библиотека http://dlang.org/phobos-prerelease/ddmd_expression.html

Это как?

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

т.е. dcd будет уже не нужен?

dcd сейчас базируется на самописной либе dsymbol, которую можно будет заменить этим

М... получается что у Ди будет такой же умный автокомплит как у C#?

Там они год назад тоже компилятор как либу сделали

т.е. dcd будет уже не нужен?

мне кажется не всё так просто и dcd тупо перебазируется бэкэндом на стандартную либу

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

Так я и не говорю что бросит. Но dsymbol незачем поддерживать, когда есть либа, которая всегда актуальна и тестируется компилятором

Ребят, кто-нить юзает dlang в продакшене?

@deviator изображения со спутиника обрабатывает

Раньше