У гоу 0 зависимостей нужно, это точно)

Виндовый бинарь не переносим, требует dll-ки

по поводу markdown в pdf — это VS Code умеет и даже вроде можно стилизовать

Всё внутри, причём пакет переносим. Можно скомпилить на бубунте, скинуть на центось и всё заработает отлично

http://forum.dlang.org/post/l67ilc$2l53$1@digitalmars.com можно и так и так, теоретически

А как бы со вспомогательными либами? То есть, в гоу я могу скомпилить проект на винде, скинуть на вообще голую винду и он будет работать. В случае с D он начнёт ругаться на отсутствие всяких libeay32 и тд. Как вообще всё вшить внутрь?

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

Хочется как в гоу. Чисто из принципа, потому что он может)

так есть статическая libeay32.lib

всегда казалась странной идея standalone приложений, в чем плюс такого?)

особенно в разрезе того, что го вроде как топит за микросервисы, которы, в принципе, и на одной машине могут работать)

можно перемещать, нельзя поломать

меньше мусора в ФС

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

понятное дело, что в некоторых случаях dependency hell можно получить, но мне кажется, идея библиотек вполне укладывается в идею повторного использования кода, а вот standalone — это как копипаста

проще, быстрее, но кайнд оф говнокод)

dll хорошо когда много программ используют общий код, что бы не было как в LLVM, когда 10 повторяющихся exe с разными именами занимают 1ГБ. А со статической либой втягиваются только используемые куски + быстрее работает + суммарно меньше места занимает

везде свои плюсы и минусы

Ок. Поедположим в го https юзается. Как он без openssl будет на другом компе работать?

как вариант - в дистрибутив библиотеки http входит статическая либа openssl

второй вариант - нативная реализация ссл

гугл может себе позволить наверное

https://github.com/qorbani/docker-golang-hello-world/blob/master/hello-world я нашел hello world который весит 5 мегабайт. При таких размерах вполне норм вкомпилировать туда все что угодно

С ssl будет ну на мегабайт больше может.

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

А вот например на betterC можно накалякать хело ворлд в 8кб )

Тоесть получается в Го просто все либы по дефолту компилят в статические и если в Ди так же будут все делать, то бelen такие же портабельные бинарики как в Го?

Тоесть получается в Го просто все либы по дефолту компилят в статические и если в Ди так же будут все делать, то бelen такие же портабельные бинарики как в Го?

справедливо для любого языка

в go к этому жирным плюсом идет кросскомпиляция — на любой поддерживаемой системе ты можешь скомпилировать бинарник под любую другую поддерживаемую систему

по крайней мере, так заявляется)

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

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

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

бред блин

Тоесть получается в Го просто все либы по дефолту компилят в статические и если в Ди так же будут все делать, то бelen такие же портабельные бинарики как в Го?

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

Ну видимо как раз из-за того что он умеет как статически так и динамически, процесс статической линковки сложнее.

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

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

я смотрю на POSIX AIO, libuv, libasync и не могу понять. Возможность работать асинхронно нам предоставляет сама ОС. Я по началу думал, что libuv, libasync лишь удобные обертки над POSIX AIO. Но сейчас решил погрепать и там нет aio совсем. Потоки ведь не используются? Как выполняется асинхронный код? Кто-нибудь понимает?

Ну, асинхронно он выполняется :)

Это и есть userspace планировщик, ему не требуется никакого ядра поддержки

А aio, насколько я помню, это же какая то новая фича? Совсем недавно ее запилили

асинхнонный код выполняется по событию, а событие приходит через epoll, kqueue, select, и т.д.

А aio, насколько я помню, это же какая то новая фича? Совсем недавно ее запилили

в 2.6.чего.то.там добавили

Это и есть userspace планировщик, ему не требуется никакого ядра поддержки

userspace sheduling

?

это гуглить?

асинхнонный код выполняется по событию, а событие приходит через epoll, kqueue, select, и т.д.

я прогнал программу с aio через strace. И там нет ни select ни epoll

есть futex

ну aio это один из таких механизмов

libuv и прочие либы могут использовать его, а могут использовать другие механизмы

в libuv есть кучка дряйверов на все случаи жизни

Смотри как я это понимаю: это довольно просто. Есть бесконечный цикл while(true) { ... } который называется event loop Этот цикл на каждой итерации вызоывает системную функцию наподобие epoll() чего-то там, который просит операционную систему заполнить структуру со случившимися событиями во внешнем мире. 1. в дескриптор пришли данные 2. директори изменилась 3. и т.д. Как только event loop получил эти события, он идет и каждое событие обрабатывает.

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

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

Как только она вызывает какой-то асинхронный код библиотеки libasync, то управление возвращается в event loop и он передает его следующей корутине.

Потом когда он так все корутины перебрал, его цикл завершается, и все начинается снова. Снова получение событий извне и т.д.

https://habrahabr.ru/post/336498/

грепание показывает, что там есть и select|kqueue и тд. и pthread_create, потоки видимо тоже юзаются для чего либо

Кто-нибудь в курсе как объяснить dub.json использовать ldc2 ?

Я так понял надо подпихнуть куда-то путь до него в $DC, но вот куда как-то не могу воткнуть

--compiler=ldc2

Это флаг для передачи снаружи. Я хочу всё записать в dub.json и не думать об этом. Это возможно?

нет

Отстой :с

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

А это как понимать?

Это флаг для передачи снаружи. Я хочу всё записать в dub.json и не думать об этом. Это возможно?

ERROR: S client not available

нет

$DC генерит сам dub (например исходя из -compiler=Х)

Ну вот тут мануал на возможное содержимое dub.json. Вот у меня есть проект, и есть в нём dub.json, и есть этот мануал. Нахрена в этом мануале то, что я не смогу использовать в проекте? Я чото запутался)

это переменные для кастомных команд (перед и после компиляции)

ну а попробовать так DC=ldc dub... если

Это маунал не на то, что dub запишет в переменную окружения, а на то, что я могу записать туда через dub.json. Зачем мне записывать туда эти поля?

я имею ввиду второй список на скриншоте

Короче. Я хочу все флаги эти запихнуть в json, так как нафига мне простыню флагов каждый раз генерить для компила тестового? :/ Неужели нет вариантов простых? dub же сам запускает компилятор, ему чо трудно глянуть перед этим что мне надо в свой же конфиг

так сделай себе скрипт если надо

Но ведь уже есть конфиг проекта со всеми настройками... вот да фак, почему. Это же так просто бл*ть

?

Увы но да

https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1937/

И автор вайба пофиксит это потом как-нибудь, если будет очень надо.

Так что пиши мейкфайл )

https://www.mail-archive.com/search?l=digitalmars-d-learn@puremagic.com&q=subject:%22Re%5C%3A+Specify+dmd+or+ldc+compiler+and+version+in+a+json+dub+file%5C%3F%22&o=newest&f=1

Вот тут они типа объясняют, что это сделано потому что твой проект должен уметь собираться всеми компиляторами а не только каким то специфическим каким ты хочешь.

и это логично

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

dmd всегда поддерживает все фичи, у ldc уже есть проблемы, а с gdc вообще сложно собрать жирный проект с библиотеками )

Так что универсальность под компиляторы это миф

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

Ну в общем если часто собираешь, наверное имеет смысл какой-нибудь алиас себе создать dubl = 'dub --compiler=ldc2'

да лучше делать алиас сразу на даб. по идее и ИДЕ сразу должны подхватить

Хм, а dmd позволяет в статике собирать сразу всё в кучку?

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

да, просто передавать в параметрах все исходники и .lib файлы

на самом деле он потом просто все .obj и .lib файлы скармливает линковщику

Думал под виндой геморно будет баловаться, под мяткой уже второй час скомпилить пытаюсь хеллоу ворлд :D Performing "debug" build using ldc2 for x86_64. Build directory ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/.dub/build/library-debug-linux.posix-x86_64-ldc_2071-1FC5281FAB0A924808428BFBD487E51E/ is not writable. Falling back to direct build in the system's temp folder. vibe-d:utils 0.8.1: building configuration "library"... ldc2 -lib -of../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/libvibe-d_utils.a -d-debug -g -w -oq -od=.dub/obj -d-version=VibeLibeventDriver -d-version=Have_vibe_d_utils -I../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/memory_legacy.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/all.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/codegen.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/funcattr.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/traits.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/typetuple.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/meta/uda.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/rangeutil.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/utilallocator.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/internal/win32.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/array.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/dictionarylist.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/hashmap.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/memory.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/string.d ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/vibe/utils/validation.d -vcolumns Error: failed to create path to file: .dub/obj/../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils/libvibe-d_utils.a No such file or directory FAIL ../../../.dub/packages/vibe-d-0.8.1/vibe-d/utils vibe-d_utils staticLibrary ldc2 failed with exit code 1.

/usr/bin/ld: cannot find -levent /usr/bin/ld: cannot find -levent_pthreads /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status Error: linker exited with status 1 FAIL .dub/build/application-debug-linux.posix-x86_64-dmd_2077-6A0A03B88CCA273172966A7D2431C639/ test executable dmd failed with exit code 1.