eclipse?

консоль + nvim

кстати, что интересно, что можно было заключить в библиотеки в ldc2 реализованно тоже через статику

там сносный плагин для DCD?

в nvim

ну по сути да, мне норм

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

Plug 'idanarye/vim-dutyl'

аа, этот

dutyl в себя включает dcd, dfmt и тд

да, знаю такой

только dfmt как-то криво работает в этой связке

тоже знаю

так nvim это почти vim

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

практически полностью совместим с плагинами

распи*дяи

)

больше причин я не вижу...

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

причём разработчиками языка

?

Ну для Go тоже парень из Еката сделал утилиту для дополнения

и работает вполне)

но там язык проще в плане анализа

go как-то проще

да да

кстати... никто не читал, что систему документирующих комментариев хотят переделать?

давно и мельком видел

может кто в курсе?

Попробовал свою софтину c gtkd собрать с ldc2... Результаты: dmd = 16.8mb dmd+strip = 6.8mb ldc2 = 15.3mb ldc2+strip = 3.9mb

видимо надо dub-у гдето прописать чтобы дебэг-инфо не включал

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

в принципе я доволен, 3.9 это уже куда не шло )

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

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

Всем привет

Такой вопрос

Использую visual d

Для создания файла проекта использую генератор из dub

При этом, когда в sdl проекта указан не исполняемый тип проекта, а либа или еще что-то

Генератор dub'а начинает ругаться

Никак нельзя .sln генерировать с неисполняемым типом проекта?

Попробовал свою софтину c gtkd собрать с ldc2... Результаты: dmd = 16.8mb dmd+strip = 6.8mb ldc2 = 15.3mb ldc2+strip = 3.9mb

dub --build=release

спасибо, но хотелось бы в сам json засунуть флаги

в свою очередь dub --build=release --compiler=ldc2 выдал 5.2mb, и если его strip то 2.5mb

идём на рекорд %)

Флаг релиза - это не ответственность json. Обычно при разработке ты часто делаешь дебаг билды и потом релиз билды, чтобы собрать проект который можно доставлять заказчику. А в json хранятся более фундаментальные неизменяемые настройки проекта.

это да сморозил )

в принципе так оно и лучше, dmd шустрее компилирует и для дэбага лучше подходит

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

главное что так еще меньше - 2.5mb вместо первичных 26.8mb

Очень круто, меня тоже смущают мои билды по 20-30 мегабайт

Хотя с другой стороны, я думаю возможно такой груз добавляется - это только на начальном этапе написания проекта? Если дальше писать программу то вес бинарника не должен расти так же линейно.

@nizovtsevnv а ты прям под мобильники уже запускаешь, или только с расчетом на будущее кодишь?

с даааальним расчётом )

это пока хобби

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

вообще опять таки для хобби я собирал для себя под дроиды на яве мелкашку, в том числе на libgdx и "вголую", на js с подкапотом cordova/phonegap, даже както roboto пробовал (или mruby не помню)

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

Я бы покодил под андроид на ди, а то под десктоп писать скучновато - никому особо не покажешь, да и писать особо нечего - все мелкие утилиты уже придуманы

А джаву и swift учить неохота ;)

я год назад ди мучал по этому поводу - не было ещё ничего толком, а сейчас вроде безпроблемно уже

в dlangui в папке сэмплов даже видел чтото с названием android

ну и ldc как-будто наше всё в этом пространстве

ERROR: S client not available

Всем привет. Итерируюсь тут, значит, по полям объекта, смотрю у каждого UDA и проверяю их типы. Эти типы мне нужно использовать в генерируемом коде (для mixin). foreach (fieldName; FieldNameTuple!M) { foreach (uda; __traits(getAttributes, __traits(getMember, M, fieldName))) { static if (__traits(compiles, cast(uda) null) && is(uda: Field)) { // ... Так вот, выражение uda.stringof даёт мне, скажем, TextField. Этого мне мало, так как мне ещё нужно сгенерировать импорт нужного файла (не все мои кастомные филды сразу импортированы в тот файл, где лежит этот генерящий код). Поэтому я смотрю в uda.classinfo.stringof, а там такое: &typeid(curtain.db.fields.text.TextField). Таким образом, взяв uda.classinfo.stringof[8..$-1], я могу получить то, что мне нужно — полное статическое обращение к классу: curtain.db.fields.text.TextField. Только вот выглядит это всё как-то больно уж костыльно и implementation-specific. Есть какие-то другие способы получить «полный титул» класса?

Если непонятно, то вот что я имею: class User: Model { @PrimaryKeyField uint num; @TextField string name; } И вот что должен получить (и, в принципе, успешно получаю): import curtain.db.field; import curtain.db.fields.text; class ModelFields { curtain.db.field.PrimaryKeyField num; curtain.db.fields.text.TextField name; this() { num = new curtain.db.field.PrimaryKeyField(); name = new curtain.db.fields.text.TextField(); } }

Если попытаться uda.classinfo.name, то компилятор ругается: Error: typeid(curtain.db.field.PrimaryKeyField).name is not yet implemented at compile time

Можно попробовать fullyQualifiedName http://dlang.org/phobos/std_traits.html#fullyQualifiedName

Супер! То, что надо! Спасибо.

Ребят, а как LDC под виндой ставить?

вот я скачал его и что в Path просто прописать?

Кстати. Всем кто системами компьютерного зрения интересуется. Сегодня первая версия DCV — fналога OpenCV на D вышла https://github.com/ljubobratovicrelja/dcv

Привет всем. Подскажите по concurrency, в языке D какой подход оптимальнее - как в Erlang плодить побольше потоков чтобы набить процессоры работой или как в олдскульных ООПах чтобы потоков было поровну с числом процессоров?

у Александреску есть вскользь что спаунить потоки ненапряжно, но очевидных выводов не дано, мол плодитесь и размножайтесь )

Ну есть потоки а есть типа корутины

Еще всякие файберы вроде

тут они корутины я думаю

spawn

общение через tid.send

Корутин можно сколько угодно, они не зависят от многопроцессорности

я спрашиваю как оно на практике ) как "легковесные" / "зелёные" потоки в реальности наполняют работой процессоры

можно ли сделать вывод что подход аля эрланг уместен

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

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

вообще для меня в D это одна из киллер-фич )

без бубнов нормальное приложение на многопроцессорные и распределённые системы сложно сделать в том же C

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

thanks

Но ты же можешь написать простые тесты

Создай 500к корутин и посмотри как они грузят ядра

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

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

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

Но я не оч компетентен в практике

сделал 10т spawn-ов - получилось потребление гдето по 12кб на spawn

но больше 11т никак не получается на моём компе создать