чтобы там ошибку посмотреть — может что напишет

а дебаггера для д нет никакого?

ну как я понимаю тут он не очень поможет — vibed же 1. падает на удаленном сервере 2. в неизвестный момент

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

а, ну да

а дебаггера для д нет никакого?

gdb

и точки останова и стектрейс и переменные

и demangling имён d'шных есть

только вот запускать придётся под дебагером

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

Не уверен, что понял вопрос, но вроде существует какой-то шелл, которым можно заменить то ли bash, то ли ssh-сервер как таковой, и он будет подключаться к той же сессии после разрыва соединения. Но я сам не пробовал.

Вот, кажется, этот: https://mosh.org/

а тоесть дело в шеле? Чтобы он именно умел?

А можешь ещё раз спросить?) Я не уверен, что вопрос понял

на чём сервер то?

только вот запускать придётся под дебагером

или можно приконектиться к процессу уже запущенному по pid

Debian

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

Debian

на systemd они уже или ещё на sysvinit?

честно не в курсе...

зачем тебе та же сессия на сервере?

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

вот только journald это часть systemd и было много холиваров вокруг включения его в debian

а так это удобная штука в целом то

спрошу, наверное, проще: как в автозагрузку ты приложение поставил?

я вообще не ставил пока...

у меня даже с установкой Ди проблемы возникли на сервер. скрипт install предлагает выполнить команду source чnо-то там для текущей сесии

source в пути добавляет dmd

можно это и без source сделать

да и вообще

зачем тебе вне сессии dmd?

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

Ну чтобы компилить код. Я ж на винде работаю, а на сервере Линукс. Плюс после реконнекта код не компилится без повторного указания source

Ну так вне сессии то не нужен компилятор, в пределах одной сессии работаешь и всё. Но если это парит, то можно в bashrc прописать этот source и в каждой новой сессии у тебя будет компилятор

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

нет

и заголовки не имеет смысла выставлять?

и тип, по всей видимости тоже

смотря какие. content-* не имеет смысла

теоретически то всё это записать туда можно

должно быть достаточно url для подавляющего большинства случаев, так?

теоретически даже тело можно записать, но по HTTP RFC сервак должен ответить 400, что запрос не валиден. по факту мало кто так делает, но лучше не пробовать

да, но ещё лучше Allow, возможны всякие авторизации и многое другое

хотя основную часть служебного фреймвёрки типа vibe.d выставляют сами

так, тут мои знания закончились по этому вопросу... allow что сие?

хотя основную часть служебного фреймвёрки типа vibe.d выставляют сами

тогда не важно)))

спасибо)

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

хм... возможно, кстати, понадобится

и заголовки не имеет смысла выставлять?

Почему же, имеет. Часто токен сессии так передаётся.

часто это у кого?

У всех.

yandex direct принимает его в заголовке post запросов

yandex metrika принимает в параметрах get запроса

которые через '?' после url

Некоторые извращаются.

хм... будем иметь ввиду, спасибо

да... google adwards в header'е get запроса токен принимает(

Может яндекс может тоже в заголовках принять?

Я не уверен, но передача токена авторизации — это вроде стандарт.

https://tech.yandex.ru/oauth/doc/dg/reference/auto-code-client-docpage/

https://tech.yandex.ru/direct/doc/dg/concepts/format-docpage/

передаётся через post

https://tech.yandex.ru/metrika/doc/api2/intro/method-call-docpage/

а здесь через параметры в url вне зависимости от метода

Я не уверен, но передача токена авторизации — это вроде стандарт.

Это про HTTP Basic Authorization, наверное. Она да, стандарт, но всё же в 99% случаев пользователь убежит от неё как от огня. А все остальные авторизации работают на куках и не являются стандартами, насколько я знаю. Хотя OAuth или аналог неплохо бы куда-то уже включить, эт да.

Это про HTTP Basic Authorization, наверное. Она да, стандарт, но всё же в 99% случаев пользователь убежит от неё как от огня. А все остальные авторизации работают на куках и не являются стандартами, насколько я знаю. Хотя OAuth или аналог неплохо бы куда-то уже включить, эт да.

А при чём тут пользователь?

А, речь про API?

ERROR: S client not available

тады ой, тады да

А как GC ссвязан с аллокаторами? Как я понял аллоктаторы нужны чтобы грамотно распределять выделенную ОС память внутри приложения? так?

Я всегда думал что @property позволяют обращаться к функции как к переменной однако следующий код работает с property и без него: void main() { auto a = new A(); a.z = 5; } class A { void z(int o) @property { writeln(o); } }

в чем причина?

А как GC ссвязан с аллокаторами? Как я понял аллоктаторы нужны чтобы грамотно распределять выделенную ОС память внутри приложения? так?

Никак. А остальное – да

но ведь GC занимается освобождением памяти значит он как-то связан с GC

Почти все аллокаторы в д сделаны для ручного мм, кроме одного

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

Т.е. Аллокаторы это альтернатива ГК?

Т.е. Аллокаторы это альтернатива ГК?

Нет

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

Если не выделять память стандартными методами - нет

тобишь стандартными?

new ClassName

а с аллокаторами как это будет выглядеть?

Открой справку для конкретного аллокатора и посмотри

Их куча

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

все встроенные в синтаксис элементы управления памятью (new, ~) работают сейчас через gc

если от этих вещей отказаться можно построить приложение без gc

Олег, а про пропертис что скажешь? Вопрос выше писал

в чём причина, что можно обращаться к не property методу без скобок? не знаю, честно)

так сделали

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

типа void delegate() func() @property при написании func() должно возвращать делегат или вызывать его

это один из спорных моментов языка

Методы без @property можно вызывать без скобок. С @property — нужно вызывать без скобок. Но пока это в языке не форсится.

т.е. @property опционален?

т.е. @property опционален?

в случае getter'ов можно наверное так сказать, но для setter'ов нет

хм

и в случае setter'ов опционален

хотя @property накладывает определённые ограничения

и typeof(obj.myProp) для @property и без него разные будут