gdc пока вообще нового нет, там используется fe старого dmd, который ещё был на C++ (с бэкпортом некоторых фич, но всё же), скорее всего только в 12 будет свежий fe на D (gcc требует чтобы можно было собрать новый используя только старый gcc без доп инструментов)
Странное предложение "попробовать поразрабатывать". Есть задача, есть конкретное оборудование, это оборудование на борту содержит 256Мб оперативы. Зачем мне пробовать делать то же самое на STM32? Была бы задача сделать это на STM32, был бы выбран другой язык и инструменты (а в нашей конторе и другой программист, который именно на stm специализируется, ибо специфика разработки под stm подразумевает более комплексное знание схемотехники и физики процессов). Не спорю что можно ту же задачу решить и за меньшее кол-во Мб оперативной памяти, меньшее кол-во Гц процессора и тд, но в нашем конкретном случае стоимость трудозатрат будет выше чем выигрыш от выбора более дешёвого железа.
А насчёт понимания я полностью согласен, оно должно быть и должно быть хорошим, иначе никак (вообще в любой технологии), но "писать быстро и с GC" не значит бездумно. Напротив, зачастую попытки выжать из железа максимум приводят к неоправданной трате времени (денег) и могут погубить разработку из-за увеличения стоимости поддерживания сверхсложного кода. Лучше сделать хорошо и в срок, чем идеально и никогда. Понимание этого аспекта так же необходимо при разработке ПО.
Занимаюсь разработкой систем мониторинга оборудования, платформа в основном arm. Один из последних продуктов написан на D, работает на железке с 256Мб оперативы и занимает из них всего 4% (около 10Мб). При этом никак сборщик мусора не модифицировал, просто писал код аккуратно (советы из статьи в этом плане очень полезны). Гипертрофировать не нужно, GC в D не такой страшный, зато даёт спокойствие и радость при написании кода =)
Стандартный синтаксис (операция конкатенации ~) требует, но строки это просто массивы и с ними можно работать как и с другими массивами. Это менее удобно и наглядно, но всё же возможно.
У D помимо GC ещё есть много разных фишек. Метапрограммирование читабельное и мощное, модули, пакетный менеджер, работа с массивами и т.д. Наконец синтаксис более приятный.
Насчёт неиспользуемости стандартной библиотеки без gc не совсем верно сказанно. Большая часть вкусностей перестаёт быть доступна, но многое остаётся. Сами по себе диапазоны как концепция не требуют gc. Можно реализовывать свои диапазоны без gc и такие уже есть в сторонних библиотеках. Единственная конструкция языка, которая не позволяет обойтись без gc это захват контекста делегата.
Не понял связи плавания ABI и сторонних библиотек. Библиотеки не на D какими были, такими и остаются, библиотеки на D собираются с проектом как зависимости dub.
Да, можно сделать бинарник меньше. 25мб это с полным vibe и debug-информацией. Не меняя сборочного рецепта ./ddb make release=y выдаёт бинарник в 6.2мб, при использовании vibe-d:core и vibe-d:http размер можно уменьшить до 6мб, используя strip можно ещё парочку убрать.
Конкретно этот hello world весит 25Mb, требование по памяти при ab -ab -k -c 50 -n 50000 / 41268 7736 5360 (виртуальная, резидентная, разделяемая соответственно).
Проверял на rpi 3b+.
Хм… У меня нет предположений, почему так происходит. В клиенте функция toRestString возвращает (в данной реализации vibe) само переданное значение без изменений. Для меня веб свежая тема пока и, наверное, с такими вопросами (про стандарты и их неправильные реализации) стоит обращаться к более опытным людям)
Но мне придётся столкнуться с передачей чисел с плавающей точкой и огромное спасибо, что Вы обратили моё внимание на такой момент сейчас (меньше волос вырву при отладке). В любом случае разбираться придётся и если никто меня не опередит, то отвечу на этот вопрос тут.
Как я понял, формат rest взаимодействия не подразумевает сохранение состояния, в частности авторизации и/или аутентификации. Что, впрочем, и реализуется всеми известными мне api (yandex, google, vk): есть oauth, который производит авторизацию/аутентификацию и отдаёт токен, далее этот токен используется в каждом запросе к api.
В данном примере путь http://127.0.0.1:8080/triangle_area_by_points, но можно корректировать путь к самой модели с помощью UDA @path("pathtorest"), которым нужно пометить сам интерфейс, тогда путь будет http://127.0.0.1:8080/pathtorest/triangle_area_by_points. Сам запрос ничего особенного не несёт в себе: метод, url, тело и тд. В заголовке ещё выставляется Content-Type: application/json. Все данные туда и обратно в json формате передаются.
gdc пока вообще нового нет, там используется fe старого dmd, который ещё был на C++ (с бэкпортом некоторых фич, но всё же), скорее всего только в 12 будет свежий fe на D (gcc требует чтобы можно было собрать новый используя только старый gcc без доп инструментов)
как-то сложно...
https://github.com/deviator/duseful/tree/master/manuals/crosscompile
Странное предложение "попробовать поразрабатывать". Есть задача, есть конкретное оборудование, это оборудование на борту содержит 256Мб оперативы. Зачем мне пробовать делать то же самое на STM32? Была бы задача сделать это на STM32, был бы выбран другой язык и инструменты (а в нашей конторе и другой программист, который именно на stm специализируется, ибо специфика разработки под stm подразумевает более комплексное знание схемотехники и физики процессов). Не спорю что можно ту же задачу решить и за меньшее кол-во Мб оперативной памяти, меньшее кол-во Гц процессора и тд, но в нашем конкретном случае стоимость трудозатрат будет выше чем выигрыш от выбора более дешёвого железа.
А насчёт понимания я полностью согласен, оно должно быть и должно быть хорошим, иначе никак (вообще в любой технологии), но "писать быстро и с GC" не значит бездумно. Напротив, зачастую попытки выжать из железа максимум приводят к неоправданной трате времени (денег) и могут погубить разработку из-за увеличения стоимости поддерживания сверхсложного кода. Лучше сделать хорошо и в срок, чем идеально и никогда. Понимание этого аспекта так же необходимо при разработке ПО.
Занимаюсь разработкой систем мониторинга оборудования, платформа в основном arm. Один из последних продуктов написан на D, работает на железке с 256Мб оперативы и занимает из них всего 4% (около 10Мб). При этом никак сборщик мусора не модифицировал, просто писал код аккуратно (советы из статьи в этом плане очень полезны). Гипертрофировать не нужно, GC в D не такой страшный, зато даёт спокойствие и радость при написании кода =)
Стандартный синтаксис (операция конкатенации
~) требует, но строки это просто массивы и с ними можно работать как и с другими массивами. Это менее удобно и наглядно, но всё же возможно.У D помимо GC ещё есть много разных фишек. Метапрограммирование читабельное и мощное, модули, пакетный менеджер, работа с массивами и т.д. Наконец синтаксис более приятный.
Уже реализован dip для исключений на RC.
Насчёт неиспользуемости стандартной библиотеки без gc не совсем верно сказанно. Большая часть вкусностей перестаёт быть доступна, но многое остаётся. Сами по себе диапазоны как концепция не требуют gc. Можно реализовывать свои диапазоны без gc и такие уже есть в сторонних библиотеках. Единственная конструкция языка, которая не позволяет обойтись без gc это захват контекста делегата.
Не понял связи плавания ABI и сторонних библиотек. Библиотеки не на D какими были, такими и остаются, библиотеки на D собираются с проектом как зависимости dub.
Да, можно сделать бинарник меньше. 25мб это с полным vibe и debug-информацией. Не меняя сборочного рецепта
./ddb make release=yвыдаёт бинарник в 6.2мб, при использованииvibe-d:coreиvibe-d:httpразмер можно уменьшить до 6мб, используяstripможно ещё парочку убрать.Разработчики призывают использовать
dlangв поисковых запросах.Конкретно этот hello world весит 25Mb, требование по памяти при ab -ab -k -c 50 -n 50000 / 41268 7736 5360 (виртуальная, резидентная, разделяемая соответственно).
Проверял на rpi 3b+.
[deleted]
Спасибо за замечания, исправил про UDA и before.
Хм… У меня нет предположений, почему так происходит. В клиенте функция
toRestStringвозвращает (в данной реализации vibe) само переданное значение без изменений. Для меня веб свежая тема пока и, наверное, с такими вопросами (про стандарты и их неправильные реализации) стоит обращаться к более опытным людям)Но мне придётся столкнуться с передачей чисел с плавающей точкой и огромное спасибо, что Вы обратили моё внимание на такой момент сейчас (меньше волос вырву при отладке). В любом случае разбираться придётся и если никто меня не опередит, то отвечу на этот вопрос тут.
http://127.0.0.1:8080/triangle_area_by_points, но можно корректировать путь к самой модели с помощью UDA@path("pathtorest"), которым нужно пометить сам интерфейс, тогда путь будетhttp://127.0.0.1:8080/pathtorest/triangle_area_by_points. Сам запрос ничего особенного не несёт в себе: метод, url, тело и тд. В заголовке ещё выставляетсяContent-Type: application/json. Все данные туда и обратно в json формате передаются.