Ну конкретно в отношении HiAsm: там не подключить произвольную библиотеку (без использования InlineCode - компонента, где как раз пишешь на ЯП), но в целом на наборе встроенных кубиков (не говоря о сделанных сообществом) не вижу каких-то критических ограничений, чтобы не получилось собрать произвольную программу. Есть и компоненты для работы с 3D (OpenGL), целые игрушки на них делали.
Так или иначе, я не про возможности, а про сам "визуальный язык". Использование иконок, цвета и разграничение назначения потоков данных (горизонталь - поток выполнения, вертикаль - данные) - концепции, которые, возможно, смогут помочь в вашем проекте преодолеть проблемы чтения вашего языка или хотя бы натолкнут на другие хорошие мысли.
Например, КДПВ я так и не смог распарсить в алгоритм, какие-то паттерны или правила построения этой схемы у меня не вышло вычислить. Линии разных цветов или мест соединений для данных или порядка выполнения мне бы могли помочь. Но, конечно, может я просто привык к другому из-за знания HiAsm.
А как в такой архитектуре планируется решать проблему передачи данных между воркерами?
Как я понял, обычная обработка ввода от пользователя превращается в поток следующих действий: Генерация события ввода символа в main thread -> трансфер события в воркер бизнес логики + сама бизнес логика -> трансфер стейта в рендед-воркер и пересчет vdom-а -> трансфер изменений/событий в main thread для отрисовки в DOM.
Итого минимум 3 трансфера, два из которых передают полный стейт приложения (или нет, но тогда как?). А если речь заходит о крупных веб-приложениях, то в них вроде как тенденция к тому, что стейт со временем сильнее пухнет. А трансфер стейта между воркерами - это всегда аналог json serialize/deserialize, что сильно грузит CPU. А технологии для перемещения объектов между потоками с минимумом накладных расходов по крайней мере мне еще не встречались.
Эта платформа дает возможность проводить видеоконференции с участием до 100 человек
У моей девушки ВУЗ выбрал данный сервис для проведения гос. экзамена удаленно. Несколько дней назад был пробный прогон. Подключились всего 4 человека, не у всех даже вышло включить камеру или микрофон, но все жаловались на сильные лаги картинки и звука. Некто, представившийся системным администратором, так и сказал, что подключилось слишком много людей за раз, и еще посоветовал использовать только браузер firefox. Так себе первое впечатление вышло.
Можно не просто не вычислять то, что не нужно, но и даже проверки в конечный код не попадет. Как бонус можно задать вычисление только самого последнего аргумента, не перечисляя всех предыдущих, как в случае с out-параметрами.
Был бы рад обновиться и до 58, и 58.0.1, но сдерживает один нюанс: если на Ubuntu 16.04 с дровами amdgpu-pro открыть вкладку с определенным сайтом, например, hh.ru или pogoda.yandex.ru, то вкладка роняет весь процесс, в котором крутится, причем в dmesg выводится сообщение об ошибке где-то в недрах amdgpu_dri.so. Список «падающих» сайтов точно не известен, как и конкретный контент, рендер которого вызывает крах. Тестил сначала на версии видеодров 17.10, обновил до 17.30 — то же самое.
Получается, что FF 58 не справляется с основной своей обязанностью — отображать сайты, и держать постоянно открытый по соседству хром ради таких особых сайтов как-то не хочется.
Подскажите, ни у кого не было такого? Или мне стоит копать в своей системе?
Подписываюсь, тоже интересует данный вопрос. Также помимо приведения кода к модульному виду не понятно, как потом собрать готовое приложение из преобразованных исходников? Введется понятие проекта? Ручное указание списка исходных файлов модуля? Еще что-то?
Столько вкусных фич! Даже не верится, что это будет все еще обеспечивающий высокую производительность C++. Надеюсь увидеть это в стандарте (и поддержку компиляторами) как можно быстрее.
Какие расчёты? Моё мнение таково, что точная дата обычно не нужна.
Расчеты того, какой сезон был "год и 6 месяцев назад". Причем это еще и посложнее будет, чем просто взглянуть на номер месяца. Ну по крайней мере, для меня: мне в голове достаточно сложно (и лениво) просчитывать что-то дальше +-1 месяца от текущего.
А почему ещё и «вчера»?
Да, наверное, без "вчера" даже лучше будет. Думал, что с ним проще отделять сегодняшние сообщения от вчерашних (старых, прочитанных вчера).
Абсолютные даты позволяют рассчитывать, сколько времени назад произошло событие с нужной точностью вам самим, а не разработчику сайта. По надписи "год назад" определить, было ли это летом или зимой — невозможно;
Если писать "год и 6 месяцев назад", то добавляются те же самые расчеты, от которых вы пытаетесь избавиться;
Быстро пробежавшись глазами по комментариям с подписями "1 месяц назад", не понять интенсивности обсуждения, т.е. с каким интервалом оставлялись эти сообщения (может, они все были оставлены в один день). И наводить курсор на все эти подписи — ну совсем не вариант.
Лично я был бы согласен только на один вариант с относительными датами: секунды, минуты, часы назад и вчера. Все, что раньше — полные даты.
Довольно удобная "проблема", красиво выходит. Похоже на применение флага --border-effect, но сколько я не пытался выставлять ему разные значения (vintage, border, даже дополнительный флаг -b пробовал), у меня ничего не дало подобного эффекта.
Как вы это сделали?
А почему убрали иконку портфеля? Мне казалось, так удобно, сразу видно, что это хабы, а не теги какие-нибудь. И для тегов вместо картинки теперь текст. А в целом очень классный дизайн!
Ну конкретно в отношении HiAsm: там не подключить произвольную библиотеку (без использования InlineCode - компонента, где как раз пишешь на ЯП), но в целом на наборе встроенных кубиков (не говоря о сделанных сообществом) не вижу каких-то критических ограничений, чтобы не получилось собрать произвольную программу. Есть и компоненты для работы с 3D (OpenGL), целые игрушки на них делали.
Так или иначе, я не про возможности, а про сам "визуальный язык". Использование иконок, цвета и разграничение назначения потоков данных (горизонталь - поток выполнения, вертикаль - данные) - концепции, которые, возможно, смогут помочь в вашем проекте преодолеть проблемы чтения вашего языка или хотя бы натолкнут на другие хорошие мысли.
Например, КДПВ я так и не смог распарсить в алгоритм, какие-то паттерны или правила построения этой схемы у меня не вышло вычислить. Линии разных цветов или мест соединений для данных или порядка выполнения мне бы могли помочь. Но, конечно, может я просто привык к другому из-за знания HiAsm.
А HiAsm не рассматривали? На мой взгляд, там удачное решение для визуальной композиции логики и иконки для ассоциаций и ориентирования в "коде"
Можно и без сокращения числа регистров сократить код. Набросал простенький оптимизатор на js :)
А как в такой архитектуре планируется решать проблему передачи данных между воркерами?
Как я понял, обычная обработка ввода от пользователя превращается в поток следующих действий:
Генерация события ввода символа в main thread -> трансфер события в воркер бизнес логики + сама бизнес логика -> трансфер стейта в рендед-воркер и пересчет vdom-а -> трансфер изменений/событий в main thread для отрисовки в DOM.
Итого минимум 3 трансфера, два из которых передают полный стейт приложения (или нет, но тогда как?). А если речь заходит о крупных веб-приложениях, то в них вроде как тенденция к тому, что стейт со временем сильнее пухнет. А трансфер стейта между воркерами - это всегда аналог json serialize/deserialize, что сильно грузит CPU. А технологии для перемещения объектов между потоками с минимумом накладных расходов по крайней мере мне еще не встречались.
У моей девушки ВУЗ выбрал данный сервис для проведения гос. экзамена удаленно. Несколько дней назад был пробный прогон. Подключились всего 4 человека, не у всех даже вышло включить камеру или микрофон, но все жаловались на сильные лаги картинки и звука. Некто, представившийся системным администратором, так и сказал, что подключилось слишком много людей за раз, и еще посоветовал использовать только браузер firefox. Так себе первое впечатление вышло.
Как бы там ни было, успехов сервису.
Скажите, а для чего вы используете интерполяцию, когда вся строка состоит из выражения? Отлично сокращается до
godbolt.org/g/4XsWU3
Можно не просто не вычислять то, что не нужно, но и даже проверки в конечный код не попадет. Как бонус можно задать вычисление только самого последнего аргумента, не перечисляя всех предыдущих, как в случае с out-параметрами.
Получается, что FF 58 не справляется с основной своей обязанностью — отображать сайты, и держать постоянно открытый по соседству хром ради таких особых сайтов как-то не хочется.
Подскажите, ни у кого не было такого? Или мне стоит копать в своей системе?
Расчеты того, какой сезон был "год и 6 месяцев назад". Причем это еще и посложнее будет, чем просто взглянуть на номер месяца. Ну по крайней мере, для меня: мне в голове достаточно сложно (и лениво) просчитывать что-то дальше +-1 месяца от текущего.
Да, наверное, без "вчера" даже лучше будет. Думал, что с ним проще отделять сегодняшние сообщения от вчерашних (старых, прочитанных вчера).
Лично я был бы согласен только на один вариант с относительными датами: секунды, минуты, часы назад и вчера. Все, что раньше — полные даты.
Довольно удобная "проблема", красиво выходит. Похоже на применение флага
--border-effect
, но сколько я не пытался выставлять ему разные значения (vintage, border, даже дополнительный флаг-b
пробовал), у меня ничего не дало подобного эффекта.Как вы это сделали?
Кажется, я начал понимать, почему новые стандарты C++ выходят раз в три года…