с msvc build tools не работает. пробовал два дня назад

без установленного Visual Studio не собирается. никаких вариан ов

а почему не взлетело?

все время трындит про Visual Studio

подозреваю, нужно пути прописывать руками, так-то, что build tools, что тулчейн visual studio - это одно и то же, как они говорят

без установленного Visual Studio не собирается. никаких вариан ов

так не бывает, может ты неправильно пути в файле si.ini указал (или как он там называется) я себе сам прописывал, чтобы для VS2017 (и для ldc тоже пришлось настраивать)

там еще win sdk нужно...

@DmitryBubnenkov а зачем тебе workspace-d ? как ты хочеш его использовать?

автокомплит для Visual Code

как я понимаю он должен при сборке dcd и dscanner собрать

в общем, надо качать msvc build tools http://landinghub.visualstudio.com/visual-cpp-build-tools и ставить, тогда должно завестись

вроде помогло

ну, dcd и dscanner вроде и dmd может собрать (я раньше сам собирал). Посмотрел исходники code-d, те что на TypeScript (я его не знаю), пиздец там сложно разбироться, лямбда в лямбде и плюс ко всему, код у них как-то стремно отформатирован, пустые строки используют только межну объявлениями функций. Кажется что в действительности ldc там не обязателен, и можно заменить на dmd. Т.е. найте где там используется ldc2 и заменить на dmd. И в workspace-d сделать также.

вроде помогло

Что ты здесь еще делаешь, пиши блять код, раз помогло

это само собой

@adhoc там как я понимаю куча всего не собирется через dmd. d-workspace emsi контейнеры вроде где-то тащит.

Во всяком случае что-то такое мелькало

emsi что, особый ди там чтоле? собирай все это через дмд

хотя не, ldc же чаще лучше оптимизирует

Кто-нибудь знает что не хватает dub, когда он пишет Failed to lock <path/to/file>?

Неа

Кто-нибудь знает что не хватает dub, когда он пишет Failed to lock <path/to/file>?

DUB можно запустить с параметром --verbose или даже --vverbose чтобы больше информации было.

нда, само пофиксилось...(

Посмотрел исходники DUB: Эта ошибка возникает если несколько процессов DUB пытаются скачать один и тотже пакет, и положить его в одно и тоже место. Возможно ты просто запускал несколько DUB-процессов...

хм

ну да

так и было

Кстати, я не совсем понимаю. А есть разница между обращениями к БД по http и через драйвер напрямую. По идее драйвер же какой-то свой протокол должен использовать более быстрый чем http?

к примеру mongodb вроде как по http работает

разве монго по http работает?

я вот не помню...

https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/ тут вот говорят, что через TCP сокет

пишешь байты, читаешь байты в формате пакетов сообщений без всякого http

но можно и по HTTP получается работать?

нет, http - это протокол прикладного уровня

грубо говоря, есть протокол транспорного уровня - TCP, поверх него работают протоколы прикладного уровня, например http, ftp, подозреваю протокол mongo этого же уровня

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

конечно, всегда можно сделать какую-нибудь прослойку, которая будет отдавать в мир, например, rest интерфейс по http и внутри через сокет будет взаимодействовать с mongo, это, наверное, можно назвать mongo over http)

Может ты встречал какую-то обертку к монге которая предоставляет http интерфейс

моожет

а никто не видел либу для D которая умеет XML 2 JSON ?

а никто не видел либу для D которая умеет XML 2 JSON ?

Ноуп. Могу скинуть вечером код функции, которая это делает

м... кинь, может пригодится. Тут просто нужно XML перегонять в GeoJSON. Я посмотрел GeoJSON вроде с простым JSON совместим в том плане что у них отличия лишь в атрибутах

Кстати, а кто следит за newCTFE ? Почему это на столько актуальная тема и для кого/каких задач она наиболее актуальна?

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

актуален для всей кодогенерации, а например diet template в vibe.d

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

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

то есть те же шаблоны веб страниц требуют генерации не малого количества кода. это же всё конкатенация строк в компайл тайме, а дальше mixin(str)

создание этой самой строки должно стать быстрее

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

Кстати, одному мне кажется что diet template лишняя и пустая задумка? Я попытался их использовать, но очень быстро пришел к выводу, что они создают больше проблем чем решают и кроме этого целиком и полностью не подходят для создания сайтов в которых используются различный JS фреймворки.

diet нужен, если страница преимущественно создаётся на сервере

если всё делает клиент, то от него толку мало

А часто бывает нужно страницу на сервере создавать? Я просто реальных кейсов не могу придумать внятных

ну раньше всегда так делали :)

да и юзабилити сайта колосально выше, если его создаёт сервер

нет загрузки тяжёлыйх фреймвёрков, сайт показывает свой контент сразу, а не запускает тонны js

ну это понятно, просто сейчас без JS уже ничего толком не сделать. Можно конечно, но оно будет обычно малопригодное для чего-то

@andrushaTheSlayer не к сожалению твой класс не поможет видимо без ряда правок. Оно не в лоб конвертится. Слева вроде бы правильный GeoJSON. Справа исходный XML

так а что мешает html генерить при помощи diet, а потом на стороне клиента модифицировать дом каким-нибудь реактом или джейквери?

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

Сложно встраивать js фреймворки в код написанный на диете

Писать просто заморочено

ну вообще да, мне синтаксис diet не нравится)

но принципиальных проблем там не видно

А на Windows 10 можно как-то билдить приожения которые бы с гарантией на Linux запусккали? Там же дистрибутивов зоопарк.

ERROR: S client not available

формат запускаемых файлов один — elf)

пакетных менеджеров полно, но основные — это deb и rpm

каноникал сейчас активно продвигает идею самодостаточных snap пакетов

a apt-get это что? в wsl есть эта херня.

это пакетный менеджер, который deb пакеты ставит)

вернее, это его консольная утилита)

@DmitryBubnenkov так какая задача-то в конечном итоге?

просто разобраться могу ли я приложения для vibed ,илдить на винде и на Linux заливать копи-пастой

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

Кстати, а никто не заметил падение интереса к Rust? Просто число упоминаний резко упало. Комменты к новым версиям все какие-то унылые.

Просто года два назад хорошая истерия около него была. Сейчас этого нет

В соседнем чате про Elixir вот что рассказали — раст не может хвостовую рекурсию оптимизировать, не может и не собирается.

даже делать не хотели https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html

а почему не хотят и для кого это важно?

я ссылку указал, а если коротко, то у них что-то не получается, поэтому решили сказать что это фича сверх языков (ну или компиляторов).

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

@adhoc А в каких задачах она полезна и что понимтаь под оптимизацией. Если можно более простыми словами... а то по ссылке не разжовывается

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

@maxfreck ну вот я не уверен что успеют допилить. Могут легко увязнуть. Появятся сложности с интеграцией компонентов или какие-то баги плавающие и доля начнет падать ускоренными темпами

Просто я до сих пор плохо представляю проект в котором был бы нужен Rust. Тем более, что там куча проблем начинается уже в какой-то банальщине — типа срез строки сделать.

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

в этом и его плюс, и его минус

ну вот, в мире функционального программирования есть рекурсия и нету циклов, и вот как ты напишеш функцию высчитывающию факториал без циклов.. Для этого прийдется писать рекурсивную функцию, а если функия рекурсивная, то на каждый вызов, нужно положить зозвращаемое значение в стек, и тогда получается что мы не может вызывать функцию много раз, т.к. стек не резиновый, плюс скорость исполнения тоже замедляется. Хвостовая рекурсия - это такая рекурсия, когда возвращаемым значением функции есть результат вызова самой мебя, и такую рекурсию всегда (ну почти всегда, если функция обрабатывает исключения, то не выйдет, т.к. исключения раскручивают стек) можно отимизировть так, будто и небыло никаких рекурсивных вызовов.

Просто я до сих пор плохо представляю проект в котором был бы нужен Rust. Тем более, что там куча проблем начинается уже в какой-то банальщине — типа срез строки сделать.

Опыта мало просто

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

Просто активность в комментах и восторженных отзывов значительно меньше стало

ну если с этой точки зрения судить, то и к D меньше интереса

к сожалению да...

непонятно на что весь рынок нацелился. такое чувство на JS..))

разные сегменты на разное)

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

D ни в одну категорию пока не входит, как, собственно, и rust, поэтому и шумихи вокгур них мало