сейчас прочитал и вспомнил — из-за перечисленных там ограничений и не взяли.
в статье я среди плюсов упоминаю, что кривые можно мешать с контролами. Допустим нужен TextInput в слое определённого графика, но как ребёнок Scene — с этим велосипедом это возможно. Если соберёте самый первый черновой сэмпл graph — там на сцене как раз такая ситуация.
Добавлю также, что аналогичная ситуация справедлива и при отрисовке через FBO — мы могли каждый трек рисовать в FBO, потом сдёргивать текстуру и рисовать её в нужном прямоугольнике. В этом случае также встраивать контролы нельзя — только поверх (думаю под они не особо пригодятся).
я знаю, что заминусуете, но очень уж хочется высказать свою точку зрения.
Во-первых, все, абсолютно все комментарии сведены к «долой ГэБню! Пора заводить трактор! Когда они пришли за мной...» и прочий эмоциональный выброс. Не надо так.
Во-вторых, хоть кто-нибудь может объяснить, чем данные действия со стороны гос-ва плохи? Ведь от того, что в доверенных корневых сертификатах появится российский, остальные корневые не будут удалены, не перестанут работать и вообще, воображаемый МИТМ со стороны ФСБ не повлияет на каналы передачи, созданные с теми, «забугорными», сертификатами. Да, МИТМ это плохо; да, лично я не хочу, чтобы мои данные видели третьи люди, но, блин, два пункта: (1) только что описанное, что МИТМ с «русским» сертификатом на означает слива ВСЕГО потока данных с вашего компьютера, да и сеть не ограничивается лишь только рунетом и (2) а кто вам сказал (или даже гарантирует), что всякие там GoDaddy, DigiCert, Etcert не сливают данные? Ну вот кто? И что та же ФСБ у них не покупает слив.
В-третьих да, я надеюсь, что Гугл и Мозила выкинут данный корневой, как только появятся подтверждения МИТМа.
В целом новость грустная, конечно же, т.к. те же СберБанк Онлайны обяжут ставить российский сертификат, но есть и микроположительное. Много всяких гос. шараг со своими веб-сайтам (Госулуги в первую очередь), которые да, покупают сертификаты за бугром из наших налогов (ну ещё нефти/газа, да, но вроде как общее достояние).
Я хоть сварщик и не самого высокого разряда, но гари чуть понюхать
успел и могу высказать своё скромное мнение на этот счёт.
Первое — это вопрос "откуда вообще проблема возникает"? Может она
надумана? Нет, не надумана и виноваты в ней в первую очередь говнокодеры:
в подавляющем большинстве объект типа time_t преобразуется в int/long
и рассматривается как количество секунд, пройденных с начала эпохи. Почему
же я, такой надменный, смею называть этих лапшаделов негативным словом?
Просто в силу того, что в документации сказано, что внутренее строение
типа time_t
не задано! [http://en.cppreference.com/w/c/chrono/time_t]
Раз не задано, то и работать с ним напрямую нельзя, только
с использованием специального API:
time;
localtime;
gmtime;
mktime;
difftime — из-за чего, собственно, и преобразовывают к целому:
чтобы вычислить период времени, измеряемый в секундах. Да, раньше 89/90го
стандарта этой функции не было, но её возможно реализовать через
предыдущие, но это же сложнее!
Во вторую очередь — это само API является кривым. Даже если бы все
работали с объектами time_t "правильно", то решить проблему 2038го года
получилось бы костыльно:
текущее АПИ предполагает, что объекты копируются по значению.
Это мешает сделать простое using time_t = std::uint64_t;
нет функций по созданию и удалению объектов типа time_t. Это
означает, что при попытке сохранять в time_t индекс объекта в некой
таблице, придётся либо выделить память процессу сразу под всё
возможное их количество, либо выделять по мере необходимости — вызов
mktime; и освобождать весь этот массив по завершении процесса.
В-третьих, как должно выглядеть нормальное АПИ. Оно должно выглядеть
также, как и CreateFile/CloseHandle из WinAPI:
Заголовок спойлера
/* да, для красоты можно и сказать, что есть некий тип, но
его кишки вам смотреть запрещено!
struct TimeType;
using time_t = TimeType *;
*/
using time_t = void *;
const auto INVALID_TIMET_VALUE = /* ... */;
time_t create_time(/* some arguments */);
/* код ошибки - на всякий случай */
int free_time(time_t time_);
int mktime(struct tm * time_, time_t outTime_);
/* sample */
time_t currentTime = create_time(/* ... */);
if (INVALID_TIMET_VALUE == currentTime)
{
fprintf(stderr, "create_time failed; errno = %d\n", errno);
return;
}
const auto result = mktime(anotherTimeRepresentation, currentTime);
if (0 != result)
{
fprintf(stderr, "mktime failed; errno = %d\n", errno);
return;
}
/* работаем с currentTime */
const auto freeResult = free_time(currentTime);
И естественно, что эти функции должны быть экспортируемыми из
разделяемой библиотеки (dll, so, dylib, etclib).
Вот только при таком подходе замена нижележащей реализации не сломала
бы текущие скомпилированные программы.
Я понимаю, что всё это для user-space, однако и для ядрёных программ
бы подошло, но тут возникают вопросы производительности. Также ещё
можно подискутировать, сильным ли ограничением в ядре является 32х
битность представления диапазона времени.
А в-четвёртых — байка! Произошло это не непосредственно со мной, а
с моим другом по работе и горело за соседним столом так, что аж я учуял.
Понадобилось ребятам в json сериализовать время — то ли промежуток,
то ли прямо метку времени, не сильно важно. Важно то, что диалог был
примерно таким:
Предлагаем хранить время прямо в строком представлении.
А что, зачем, почему? Давайте прям time_t запишем, там же инт
и количество секунд с бороды 1970х...
Лёша, как бы это implementation defined! 2038й год там, все дела...
Да пофигу, я к тому времени уже на пенсии буду.
(На одной стороне передачи был C++-ный код, с другой — Java. Работало
всё лишь только потому, что повезло.)
Рукалицо в общем и занавес. Между собой мы всегда вспоминаем с улыбкой, но
друг ещё добавляет: "Вот это не наши! Хоть бы в следующем обновлении
студии/стандартной либы/етс изменили нижележащий тип и у них всё накрылось!
Чтобы до конца пенсии поминали!!1 "
Не знаю, серьёзно уж или нет, но ПО для торговли на бирже.
Да, когда переменная buffer выйдет из блока (т.е. попадёт к сборщику в руки), он что-то связанное с ней подчистит, однако deleteBuffer вызывать не будет (Конечно, может в обозревателях и реализовали такую возможность, но я сильно сомневаюсь), произойдёт потеря идентификатора, с помощью которого адресуются данные и освободить их в данном процессе уже никак не получится. Происходит это из-за того, что buffer "держит" данные непосредственно в памяти видеоускорителя.
Конечно, если речь идёт о какой-нибудь демке, то там всё равно, вызывать дилит объектам или нет — при закрытии вкладки/обозревателя ОС всё подчистит — кстати также, как и при закрытии родного приложения.
Однако для долгоиграющих приложений (игры, 2Д/3Д-редакторы графики, редакторы видео, ПО для моделирования) это должно учитываться. И выглядеть этот код будет один-в-один, как на C++. =)
И для каждого GL-ного объекта такая пара методов есть:
Развивая тему, хотелось бы отметить, что это не проблема JavaScript/WebGL в частности. Это вообще проблема сборщиков мусора — все думают, что они могут всё и ни за чем следить не нужно. Самое большое заблуждение! В общем случае приходится управлять ресурсами (память же — лишь частный её случай) и тут сборщики мусора никак не облегчают задачу, но даже мешают.
не требует установки специализированных расширений или библиотек
без драйверов видеокарты, а в случае Линукса ещё и правильно настроенных тех самых библиотек, ничего не взлетит.
втоматическое управление памятью. В отличие от OpenGL, в WebGL не надо выполнять специальные действия для выделения и очистки памяти.
если прошлое замечание больше похоже на придирку, то в этом случае всё серьёзно — это уже откровенная ложь. Лучше уберите этот пункт. Все данные, которые будут отображаться с помощью WebGL выделяются в памяти видеокарты. Соответственно, их также надо вручную освобождать, никакой сборщик мусора не поможет.
и поэтому нужны такие люди, как популяризаторы науки. В качестве примера — Я. И. Перельман, чьи «Занимательная Х» оказали на меня лично большое влияние.
В идеале — каждый учёный должен быть одновременно и популяризатором, но, видимо, не каждому дано, а может быть не каждый и хочет.
"clang" произносится как "шланг" =)
попробуйте https://github.com/google/compact_enc_det, у нас неплохо для ласов работает =).
А вообще эта задачка идеальна для нейросетей.
для чего контрол написали: Widgets или QML/Quick?
личный опыт тоже для нефтянки? )
сейчас прочитал и вспомнил — из-за перечисленных там ограничений и не взяли.
в статье я среди плюсов упоминаю, что кривые можно мешать с контролами. Допустим нужен TextInput в слое определённого графика, но как ребёнок Scene — с этим велосипедом это возможно. Если соберёте самый первый черновой сэмпл graph — там на сцене как раз такая ситуация.
Добавлю также, что аналогичная ситуация справедлива и при отрисовке через FBO — мы могли каждый трек рисовать в FBO, потом сдёргивать текстуру и рисовать её в нужном прямоугольнике. В этом случае также встраивать контролы нельзя — только поверх (думаю под они не особо пригодятся).
Сразу ограничивать себя мы не стали.
в списке возможных альтернатив у нас он мелькал, но если мне не изменяет память, он тоже рисует (или рисовал тогда) на CPU.
CMake засветился в ролике
Во-первых, все, абсолютно все комментарии сведены к «долой ГэБню! Пора заводить трактор! Когда они пришли за мной...» и прочий эмоциональный выброс. Не надо так.
Во-вторых, хоть кто-нибудь может объяснить, чем данные действия со стороны гос-ва плохи? Ведь от того, что в доверенных корневых сертификатах появится российский, остальные корневые не будут удалены, не перестанут работать и вообще, воображаемый МИТМ со стороны ФСБ не повлияет на каналы передачи, созданные с теми, «забугорными», сертификатами. Да, МИТМ это плохо; да, лично я не хочу, чтобы мои данные видели третьи люди, но, блин, два пункта: (1) только что описанное, что МИТМ с «русским» сертификатом на означает слива ВСЕГО потока данных с вашего компьютера, да и сеть не ограничивается лишь только рунетом и (2) а кто вам сказал (или даже гарантирует), что всякие там GoDaddy, DigiCert, Etcert не сливают данные? Ну вот кто? И что та же ФСБ у них не покупает слив.
В-третьих да, я надеюсь, что Гугл и Мозила выкинут данный корневой, как только появятся подтверждения МИТМа.
В целом новость грустная, конечно же, т.к. те же СберБанк Онлайны обяжут ставить российский сертификат, но есть и микроположительное. Много всяких гос. шараг со своими веб-сайтам (Госулуги в первую очередь), которые да, покупают сертификаты за бугром из наших налогов (ну ещё нефти/газа, да, но вроде как общее достояние).
Я хоть сварщик и не самого высокого разряда, но гари чуть понюхать
успел и могу высказать своё скромное мнение на этот счёт.
Первое — это вопрос "откуда вообще проблема возникает"? Может она
надумана? Нет, не надумана и виноваты в ней в первую очередь говнокодеры:
в подавляющем большинстве объект типа time_t преобразуется в int/long
и рассматривается как количество секунд, пройденных с начала эпохи. Почему
же я, такой надменный, смею называть этих лапшаделов негативным словом?
Просто в силу того, что в документации сказано, что внутренее строение
типа time_t
не задано! [http://en.cppreference.com/w/c/chrono/time_t]
Раз не задано, то и работать с ним напрямую нельзя, только
с использованием специального API:
чтобы вычислить период времени, измеряемый в секундах. Да, раньше 89/90го
стандарта этой функции не было, но её возможно реализовать через
предыдущие, но это же сложнее!
Во вторую очередь — это само API является кривым. Даже если бы все
работали с объектами time_t "правильно", то решить проблему 2038го года
получилось бы костыльно:
Это мешает сделать простое using time_t = std::uint64_t;
означает, что при попытке сохранять в time_t индекс объекта в некой
таблице, придётся либо выделить память процессу сразу под всё
возможное их количество, либо выделять по мере необходимости — вызов
mktime; и освобождать весь этот массив по завершении процесса.
В-третьих, как должно выглядеть нормальное АПИ. Оно должно выглядеть
также, как и CreateFile/CloseHandle из WinAPI:
И естественно, что эти функции должны быть экспортируемыми из
разделяемой библиотеки (dll, so, dylib, etclib).
Вот только при таком подходе замена нижележащей реализации не сломала
бы текущие скомпилированные программы.
Я понимаю, что всё это для user-space, однако и для ядрёных программ
бы подошло, но тут возникают вопросы производительности. Также ещё
можно подискутировать, сильным ли ограничением в ядре является 32х
битность представления диапазона времени.
А в-четвёртых — байка! Произошло это не непосредственно со мной, а
с моим другом по работе и горело за соседним столом так, что аж я учуял.
Понадобилось ребятам в json сериализовать время — то ли промежуток,
то ли прямо метку времени, не сильно важно. Важно то, что диалог был
примерно таким:
и количество секунд с бороды 1970х...
(На одной стороне передачи был C++-ный код, с другой — Java. Работало
всё лишь только потому, что повезло.)
Рукалицо в общем и занавес. Между собой мы всегда вспоминаем с улыбкой, но
друг ещё добавляет: "Вот это не наши! Хоть бы в следующем обновлении
студии/стандартной либы/етс изменили нижележащий тип и у них всё накрылось!
Чтобы до конца пенсии поминали!!1 "
Не знаю, серьёзно уж или нет, но ПО для торговли на бирже.
вот на примере буфера: https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteBuffer
Да, когда переменная buffer выйдет из блока (т.е. попадёт к сборщику в руки), он что-то связанное с ней подчистит, однако deleteBuffer вызывать не будет (Конечно, может в обозревателях и реализовали такую возможность, но я сильно сомневаюсь), произойдёт потеря идентификатора, с помощью которого адресуются данные и освободить их в данном процессе уже никак не получится. Происходит это из-за того, что buffer "держит" данные непосредственно в памяти видеоускорителя.
Конечно, если речь идёт о какой-нибудь демке, то там всё равно, вызывать дилит объектам или нет — при закрытии вкладки/обозревателя ОС всё подчистит — кстати также, как и при закрытии родного приложения.
Однако для долгоиграющих приложений (игры, 2Д/3Д-редакторы графики, редакторы видео, ПО для моделирования) это должно учитываться. И выглядеть этот код будет один-в-один, как на C++. =)
И для каждого GL-ного объекта такая пара методов есть:
Развивая тему, хотелось бы отметить, что это не проблема JavaScript/WebGL в частности. Это вообще проблема сборщиков мусора — все думают, что они могут всё и ни за чем следить не нужно. Самое большое заблуждение! В общем случае приходится управлять ресурсами (память же — лишь частный её случай) и тут сборщики мусора никак не облегчают задачу, но даже мешают.
без драйверов видеокарты, а в случае Линукса ещё и правильно настроенных тех самых библиотек, ничего не взлетит.
если прошлое замечание больше похоже на придирку, то в этом случае всё серьёзно — это уже откровенная ложь. Лучше уберите этот пункт. Все данные, которые будут отображаться с помощью WebGL выделяются в памяти видеокарты. Соответственно, их также надо вручную освобождать, никакой сборщик мусора не поможет.
В идеале — каждый учёный должен быть одновременно и популяризатором, но, видимо, не каждому дано, а может быть не каждый и хочет.
Может быть есть видео игрового процесса?