может заработает

wut? Ассерты и сделаны для всего кода а не для юнит тестов только

Их можно свободно расставлять где угодно

Павел, сейчас попробую x32 билд твоего socks5 сервера собрать

Лучше компилятор возьми ldc2 и не RC версия

Надо тоже туда докерфайл зарелизить чтобы все могли собирать быстренько

а как дабу указать что LDC надо юзать?

а кажись вспомнил

--compiler=ldc2

Надо тоже туда докерфайл зарелизить чтобы все могли собирать быстренько

ИМХО докер нефига не проще. Я так его плюсы и не оценил.

(ldc-1.9.0)root@dlang:/apps/socks5d# ./socks5d --config=config.sdl 2018-05-02T17:47:12.339:app.d:main:26 Starting socks5d server v. 0.0.4-dev 2018-05-02T17:47:12.340:config.d:loadConfig:14 Parsing config file config.sdl Illegal instruction (ldc-1.9.0)root@dlang:/apps/socks5d# cat config.sdl server { listen "1.2.3.4" port=1488 auth login="dlang" password="dlang" }

Как же не проще, когда можно собрать программу за пару команд

В продакшене лучше не надо. В дебаговой сборке - вполне.

В продакшн они при всём желании не попадут

И потом скопировать получившийся бинарник к себе. И при этом хост система не будет засрана всякими компиляторами и сборочными пакетами

Как по мне докер хорош для трудноподдерживаемого говна гвоздями прибитого к окружению. Ди в этом плане от всех этих костылей избавиться

Короче не работает упорно — не нравится ему что-то в конфиге

server { listen "1.2.3.4" port=1488 auth login="dlang" password="dlang" }

замени на auth "dlang" password="dlang"

login= нет такого )

Как по мне докер хорош для трудноподдерживаемого говна гвоздями прибитого к окружению. Ди в этом плане от всех этих костылей избавиться

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

server { listen "1.2.3.4" port=1488 auth="dlang" password="dlang" } sdlang.exception.ParseException@/root/.dub/packages/sdlang-d-0.10.2/sdlang-d/src/sdlang/parser.d(257): config.sdl(3:9): Error: Found attribute, but no tag nam e. If you intended an anonymous tag, you must have at least one value before any attributes.

Зачем у тебя = после auth

У меня же нет в строчке выше

Так погоди. В примере у тебя: server { listen "127.0.0.1" port=1081 auth login="socks5d" password="socks5d" } Я делаю: server { listen "1.2.3.4" port=1488 auth login="dlang" password="dlang" } знаки равенства же есть, есть

Хм да, неправильно в примере, сейчас сделаю исправление

std.algorithm.iteration: uniq работает для строк?

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

похоже сравнивает поинтеры

из ["field name", "field name", "another field", "field name"] делает ["field name", "another field", "field name"]

А если отсортировать?

не должно влиять по идее

https://run.dlang.io/is/2X7ysR

uniq только unique consecutive elements обрабатывает

только подряд идущие повторы убирает

По хорошему, нужен Set

uniq только unique consecutive elements обрабатывает

млять. и там же написано что работает "как утилита uniq"

ок разобрались

спасибо

А как там называется "место, которого хватит для всех перечисленных типов"?

union

Точно

Еще один вопрос: а в D есть шаблон, который позволяет бинарно распарсить числов структуру? Типо 1ый бит - bool field1, 2ой - bool field2 и т.д.

Давно хотел спросить, Почему во всех фреймворках мы принимаем И запрос И ответ т.е. void handleRequest(HTTPServerRequest req, HTTPServerResponse res) { } Почему не? `HTTPServerResponse handleRequest(HTTPServerRequest req)``

Еще один вопрос: а в D есть шаблон, который позволяет бинарно распарсить числов структуру? Типо 1ый бит - bool field1, 2ой - bool field2 и т.д.

да

Давно хотел спросить, Почему во всех фреймворках мы принимаем И запрос И ответ т.е. void handleRequest(HTTPServerRequest req, HTTPServerResponse res) { } Почему не? `HTTPServerResponse handleRequest(HTTPServerRequest req)``

Иногда можно передать другому обработчику. Не везде

да

И что же?

Давно хотел спросить, Почему во всех фреймворках мы принимаем И запрос И ответ т.е. void handleRequest(HTTPServerRequest req, HTTPServerResponse res) { } Почему не? `HTTPServerResponse handleRequest(HTTPServerRequest req)``

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

И что же?

bitfields

И что же?

https://run.dlang.io/is/oPC9MP

https://run.dlang.io/is/oPC9MP

Не, не оно. Если мы что-то присвоим A.a, это не будет доступно из x, y, z или flag

Тогда точнее опиши свою хотелку

Тогда точнее опиши свою хотелку

Вроде union { int, bitfields }

Не, не оно. Если мы что-то присвоим A.a, это не будет доступно из x, y, z или flag

> Если мы что-то присвоим A.a, это не будет доступно из x, y, z или flag Будет

> Если мы что-то присвоим A.a, это не будет доступно из x, y, z или flag Будет

Можно пример? У меня не работает

протупил

ничто не мешает засунуть миксин в юнион

ничто не мешает засунуть миксин в юнион

А вдруг это сделали до меня?

https://run.dlang.io/is/p6KUTV

ну вот

Замечательно

https://geektimes.com/post/300547/ вспомнилаи сегодня Дракон, и вот он опять

долбанутым нет покоя

В упоминавшемся уже unreal engine визуальное программирование всё ещё используется для несложных задач.

Коллективное дежавю. Только зашел на хабр и там https://habr.com/post/354444/

Что ни говори а визуализация нужная тема

А кто нибудь может показать пример Dependency Injection на D?

Вообще кому либо этот паттерн пригождался в реальных проектах?

А кто нибудь может показать пример Dependency Injection на D?

Тебе это зачем?

ERROR: S client not available

Да просто сел про паттерны читать

Без DI просто смерть)

Вообще кому либо этот паттерн пригождался в реальных проектах?

Очень даже

Очень даже

А можешь пример привести очень простой какой нибудь?

Смотри

Мы реализовывали драйвера логера.

Сам механизм лога был простой до безумия

Типа write

С тегами и самим сообщением

Но то, куда логировать, решал сам драйвер

Сами же драйвера регистрировались в DI контейнере

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

Второй пример:

А можешь хотя бы один кейс на Ди показать. Ну там с foo и bar

чтобы понять как это все конструируется

Это было не на Ди

Но если бы я делал свой DI контейнер, то он бы выглядит что-то типа такого:

interface Gt { void test(int g);}

D.i!Gt().test(7);

Это если ты работаешь с глобальным DI контейнером

Можно их иметь просто массу и в каждом иметь свои зависимости

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

Но так, как твой объект может расширяться и со временем требовать все новые и новые зависимости, чтобы код не переписывать, или дописывать, ты можешь передавать в объект не сами зависимости, а DI контейнер

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

Скажем у тебя есть объект МАШИНА

И ты хочешь открыть дверь

Но дверь может быть во многих состояниях, разных конструкций и т.д.

Ты не знаешь как с ней работать

Ты передаешь в свой объект МАШИНА DI контейнер, который имеет объект, что имплементирует интерфейс работы с дверью, а ты знаешь только о интерфейсе

И в любой момент ты имеешь возможность подменить эту имплиментацию.

Также ты имеешь возможность подменить эту имплиментацию не только в одном объекте МАШИНА, а сразу во всех!

Или наоборот только в одном или нескольких объектах