если только double на строку менять и округлять через sprintf, или что там в Ди.

Очень странно. Тогда надо написать свой символьный округлятор.

Вотя тоже к этому пришёл :) Но не хочется велосипедить на ровном месте

если только double на строку менять и округлять через sprintf, или что там в Ди.

Попробовал. ЬТогда появляются лишние ковычки :)

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

ну, ты сам написал, что особенности double) хотя часть чисел округлится, можэет получится сэкономить

В похапе для этого даже специально придумали функцию number_formar

почему при работе со временем Duration заточен на строковые параметры типа "msecs", а не на enum?

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

там aliases есть

alias msecs = dur!"msecs".dur;

alias msecs = dur!"msecs".dur;

спасибо, не догадался.

не, я это не придумал

alias в std

core.time

import core.time

и будет у Вас msecs

Интересно, а есть какие нибудь генераторы докер-компоус файлов?

https://jsplumbtoolkit.com/demos/toolkit/database-visualizer/index.html

Глянь - из дядиной скворешни, кабинетный и босой, вылетает кибернетик с двухметровою губой! ожерелье зачихало, растопорщилась кора, солнце громко раздвоилось, и обуглилась икра... https://t.me/MachineHumor

с другой стороны, использование в D-проекте C/C++ библиотеки - это риск заполучить утечки памяти. так?

Для поиска утечек в С/С++ существует много инструментов. Чем тут похвастается D?

А как профайлить мешанину из спп и ди?

А что профайлить легче, D, или C++? =)

Я пробовал его профайлер, он генерил мне огромный html файл на пару мегабайт

Который с трудом открывался. Ну и там была проблема с замерами повторяющихся в циклах участков.

У меня там запуск веб сервера и загрузка первоначальных данных занимали условно 80% времени, а потом на сервер сыпались запросы. И профайлер показывал что каждый участок цикла примерно 0.001% времени занял. В общем не очень репрезентативно.

Посоны, у меня претензия к vibe core lib event опять - не видит оно ошибок обрыва соединения на сокете почему-то

auto event = createFileDescriptorEvent(this.posixSocket, FileDescriptorEvent.Trigger.any);

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

последний коммит туда от Jul 9, 2018

не сдох ли?

struct FileDescriptorEvent { /** Event mask selecting the kind of events to listen for. */ enum Trigger { none = 0, /// Match no event (invalid value) read = 1<<0, /// React on read-ready events write = 1<<1, /// React on write-ready events any = read|write /// Match any kind of event } Возникает вопрос: а если ошибка канала?

Удаленный закрыл это готовность на чтение и чтение 0 байт

щас подумаю, почему у меня оно не срабатывает

Обрыв соединения и обрыв соединения по инициативе удаленного сервера это разные вещи

Первое обнаружить весьма сложно, обычно по таймауту. А второе легко.

у нас в докере сервер базы данных, его перезагружают так: docker stop postgres docker rm postgres docker run --name postgres -d -e POSTGRES_PASSWORD=$PG_PASSWORD -e POSTGRES_USER=$PG_USER_NAME -e POSTGRES_DB=$PG_DB_NAME --restart="unless-stopped" --net="host" postgres:$PG_VER

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

щас телнетом проверю

$ telnet localhost 5432 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. EFATAL: terminating connection due to unexpected postmaster exit Connection closed by foreign host.

да, обрывается корректно и сразу

А у меня оно падает по тайм-ауту тут: https://github.com/denizzzka/vibe.d.db.postgresql/blob/master/source/vibe/db/postgresql/package.d#L147

Удаленный закрыл это готовность на чтение и чтение 0 байт

Похоже, это

Удаленный закрыл это готовность на чтение и чтение 0 байт

А если не через vibe-core а через обычный libevent (или что там аналогом идёт устаревшим) - то же самое?

Т.е., это некое стандартное поведение? Чтобы два раза разный код не писать для разных библиотек.

это поведение сокеты, а во что это превращает библиотека - зависит от автора

А у сокета флагов нет типа ERR_DISCONNECTED?

которые через ioctl проверить можно было бы

есть то закрытие сокеты это не ошибка

ошибки возникают в других ситуациях

щас бы ещё вспомнить как количество байт на чтение в сокете узнать

Сокет из фобоса юзать не хочу- медленный из-за класса

зачем? просто читаешь. елси прчел 0 - сокет закрылся

если -1 - это ошибка

нельзя просто читать - висанёт, блокирующее оно

надо узнать сколько ожидает, если 0 и событие было read значит это ошибка

ну тут не подскажу

там вообще нет функции "читай" у меня - там consumeInput, а оно может и 0 прочитать без проблем

https://github.com/postgres/postgres/blob/322548a8abe225f2cfd6a48e07b99e2711d28ef7/src/interfaces/libpq/fe-exec.c#L1682

вот оно как выглядит

просто читает и всё, если там 0 то оно просто подумает что нечего читать и скажет всё збс

в результате оно возвращается и ждёт опять чтения, а потом отваливается по тайм-ауту

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

скорее до попытки чтения

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

гоню.

ERROR: S client not available

а вообще ошибок же много бывает, они все обозначаются как read+0 ?

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

нет, как -1

тоже так будет?

из доки A typical application using these functions will have a main loop that uses select() or poll() to wait for all the conditions that it must respond to. One of the conditions will be input available from the server, which in terms of select() means readable data on the file descriptor identified by PQsocket. When the main loop detects input ready, it should call PQconsumeInput to read the input. It can then call PQisBusy, followed by PQgetResult if PQisBusy returns false (0).

Обрати внимание, тот ничего про обработку ошибок

https://github.com/denizzzka/vibe.d.db.postgresql/blob/master/source/vibe/db/postgresql/package.d#L150

вот щас оно тут

по идее в случаее ошибки PQgetResult / PQresultStatus это покажут?

до них не доходит

может да а может и нет

но этот цикл возвращается в read и ждёт там до тайм-аута

PQconsumeInput 0 возвращает в случае ошибки. но он заблокируется, если данных нет. то есть throw new PostgresClientTimeoutException(__FILE__, __LINE__); вот сюда попадает? если да, то логично. ошибок же нет в сокете

> PQconsumeInput 0 возвращает в случае ошибки Пруфы?

в его коде ничего такого не нашёл, вот: https://github.com/postgres/postgres/blob/322548a8abe225f2cfd6a48e07b99e2711d28ef7/src/interfaces/libpq/fe-exec.c#L1682

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

> т.е. сервера больше нет, но клиент об этом не знает

PQconsumeInput normally returns 1 indicating “no error”, but returns 0 if there was some kind of trouble (in which case PQerrorMessage can be consulted)

щас телнетом проверю

$ telnet localhost 5432 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. EFATAL: terminating connection due to unexpected postmaster exit Connection closed by foreign host.

да, обрывается корректно и сразу

т.е. с докером всё ок, дело в моём коде обработки закрытий от сервера

PQconsumeInput normally returns 1 indicating “no error”, but returns 0 if there was some kind of trouble (in which case PQerrorMessage can be consulted)

А, это другие ошибки имеются ввиду

это если например данные пришли не в том формате

код PQconsumeInput посмотри, там 5 строк

ага, только он вызывает pqReadData, которая, похоже, при ошибках IO вернет -1) надо смотреть, но PQconsumerInput 0 вернет в случае ошибки IO, очень на это похоже

https://github.com/postgres/postgres/blob/322548a8abe225f2cfd6a48e07b99e2711d28ef7/src/interfaces/libpq/fe-misc.c#L629 вот она, давай посмотрим

Бегло посмотрел - похоже, нет. Везде с < 0 сравнивают

а надо с == 0

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

Но потом она выставляет CONNECTION_BAD