Ввести форматирование в юникод - идея слишком спорная
А форматирование и не надо вводить. Но я бы подумал о введении разметки. К примеру, верхние и нижние индексы имеются в Юникоде как отдельные символы, но не все - только цифры, некоторые латинские буквы, некоторые спецсимволы. При этом в html и других "богатых" форматах для верхнего и нижнего индекса есть отдельная "декорация" - работающая уже для любых символов. Далее, всякие ударения, умляуты и прочие диакритические знаки - это ведь тоже "декорации"? По идее их можно назначить любому символу. Про цвета уже говорили. Направление письма туда же. Кроме того в Юникоде есть вот такая хрень - это уже в чистом виде escape-разметка как я ее предлагаю, но для очень частного случая аннотирования иероглифов.
Но с моей точки зрения в существующий стандарт вводить ничего такого не нужно. А нужно думать о новом стандарте, в котором будут учтены и исправлены все ошибки предыдущего. Да, здесь может быть картинка про 15 конкурирующих стандартов. Но можно подходить к этому и по другому - иногда действительно лучше переделать что-то с нуля, а не тащить огромный груз кривой обратной совместимости (ситуация такая же как с С++ и новыми языками типа Rust и Carbon).
Я думаю что сам по себе регистр символов, кодируемый отдельными кодами - ошибка на миллиарды долларов. Вот имеются три символа:
С точки зрения инопланетянина, это очевидно три разных символа. Мы знаем что это по смыслу одна и та же буква. Но с точки зрения Юникода, первые два - разные, а третий - лишь курсивный вариант начертания второго в некоторых шрифтах. Регистра не существует для различных иероглифов, индийского и арабского письма. И по большому счету (если бы проектировать Юникод с нуля) регистр должен быть вариантом "декорации", также как bold и italic. А в Юникод (не нынешний, а проектируемый с нуля разумеется) должны быть введены спецкоды (escape-коды) переключения регистра. И заодно, спецкоды переключения тех же bold и italic , всевозможных подчеркиваний и перечеркиваний, поворотов и отражений букв, цвета и многого другого. Некоторые такие модификаторы все равно пролезают в нынешний Юникод, но в каком-то суперкривом виде - известный пример с "цветами кожи" для смайликов, так почему бы не сделать всё системно и универсально?
О, статья о редактированию видео! У меня пара вопросов, может кто подскажет, каким редактором и с помощью каких инструментов внутри редактора это можно сделать. Просто правильные названия, чтобы было от чего отталкиваться в дальшейшем поиске. Интересуют два эффекта.
Первый - "Виртуальная камера": имеется видео, я хочу вырезать из него видео меньшего разрешения, задавая для некоторых кадров координаты и размер "прямоугольника обрезки". Для промежуточных кадров координаты и размер интерполируются. Далее для каждого кадра вырезается эта область и приводится к единому ранее заданному размеру. Т.е. это не просто обрезка, когда все кадры обрезаются по фиксированным координатам, а как будто мы перемещаем "виртуальную камеру" по исходному видео и приближаем/удаляем изображение.
Второй - "Динамическое ретуширование". По тому же принципу что и в первом эффекте я задаю для некоторых диапазонов кадров (не для всех) небольшую область, а программа сама находит в этой области цветовую неоднородность и устарняет ее, используя алгоритм "восстанавливающая кисть" как в фотошопе.
Чем дальше в лес тем больше жути. Но если претендуешь называться "Разработчиком на С++" то вроде как надо знать:)
А вообще двойственное ощущение от всего этого. С одной стороны рефлексия - очень нужная и полезная вещь в любом языке и в любой более-менее сложной задаче. С другой, то куда катится С++ уже не выдерживает никакой критики. По сути программистов вынуждают дописывать внутренности компилятора на весьма кривом функциональном языке.
Самое забавное что довольно неплохая эмуляция рефлексии была возможна еще в Си, на макросах (и нет это не boost.preprocressor, всё проще). Например, если нужно в одном месте (во избежание рассогласования) определить нечто, что могло бы разворачиваться в структуру, перечисление, список строк, использоваться для сериализации и т.п., то делается запросто.
Все скачанные exe проверяю на virustotal, пока этого хватает. Но на всякий случай: какие есть утилиты для однократной проверки на вирусы, т.е. не в фоне с перехватом всего, как классические антивирусы, а именно отдельные утилиты которые работают только когда их явно запустишь? Знаю несколько - упомянутые AVZ, KVRT, еще вроде Dr.Web CureIt. А что еще, в том числе нероссийских разработчиков?
ИМХО, языку С++ уже ничего не поможет - именно из-за огромного груза обратной совместимости. То что добавляют новые фичи - это даже интересно, наблюдая за этим процессом можно учиться тому, что и как при проектировании новых языков делать надо а что и как не надо. Видно например, какие решения многолетней давности приводят к проблемам.
Carbon и Circle - довольно интересные разработки. Carbon - развитой системой дженериков с концептами, Circle - императивным метапрограммированием. Хотя последний стремится быть слишком похожим на С++ (вероятно чтобы было проще переносить код), из-за чего там уже сейчас прослеживается немало ошибок дизайна.
Хорошая среда разработки - достаточно легковесная, для линукса вообще одна из лучших. Но вот никак они не хотят добавить табы в редактор. Хотя плагины такие есть, но их же ставить нужно, иногда даже компилировать, а для этого нужны все исходники самого Creator'а...
Если это будут преподавать на уроках обществознания в 8 классе - это будет не так уж и плохо. Но боюсь что будет скорее наоборот - сейчас некоторые теории заговора являются частью гос.идеологии:(
Полностью согласен. Не представляю как можно пользоваться смартфоном вместо компьютера. А последнее время и вообще в смартфонах разочаровался. Раньше, когда всё начиналось (еще были "КПК" и "Коммуникаторы") - было интересно. Иметь такое устройство в дополнение к компьютеру было круто и престижно. А теперь, когда у каждого есть смартфон - уже неинтересно.
И смартфоны действительно не дают ощущения полного контроля над устройством. К примеру, я задумываюсь над тем что неплохо было бы иметь что-то вроде виртуализации и криптоконтейнеров для смартфонов - это когда некоторое приложение (браузер, мессенджер и т.д.) ставится в специальное окружение, так что оно имеет доступ только в виртуальному зашифрованному "диску"-криптоконтейнеру (как TrueCrypt), где и вынуждено хранить все данные. Но вряд ли такой софт существует.
Про то что приложения нередко просят доступ ко всему подряд, и хорошо бы для таких иметь возможность создавать виртуальные фейковые источники данных (списки контактов, гео координаты и т.д.) - уже многие писали.
Интересно когда же появятся децентрализованные пиринговые LLM. Чтобы не обязательно было иметь топвую видяху, а просто запускаешь в фоне процесс и он там что-то немного вычисляет для других участников, а тебе за это дают право самому пользоваться всей сетью.
Еще у меня были мысли о возможной кодификации эмоций на основе эмоциональных гормонов (таких как серотонин, допамин, кортизол, окситоцин, адреналин и т.д.).
Во-первых эти слизни нечитаемы. Я не понимаю что они обозначают. Если и делать то нужно что-то более узнаваемое, обычные смайлики подошли бы лучше.
Во-вторых, я и обычные лайки/дизлайки последнее время почти не применяю. Не знаю почему, статьи читаю а лайкать лень. Иногда лучше комментарий напишу.
Ну и наконец, по самим эмоциям. Это чисто теоретический вопрос. А как вообще наиболее правильно выбрать эмоции для оценки чего-либо? Нравится и не нравится - просто и понятно, линейная бинарная шкала. А эмоции? Есть ли какие-то базовые эмоции, их суперпозиции, сколько измерений в пространстве эмоций и применим ли вообще к ним такой математический подход?
Стоило ввести типы произвольной битовой длины signed<N> и unsigned<N>. В LLVM такие типы даже есть готовые, правда когда я последний раз смотрел - при попытке их применения всё падало, но с тех пор уже много времени и версий прошло, может и исправили.
Не прошло и полвека:) Хотя нет, прошло, год появления языка Си 1969, а это настолько низкоуровневая и фундаментальная фича, что она по здравому смыслу должна была быть еще в первой версии Си. Ну также как и бинарные литералы 0b00011011
Так что встраивание ресурсов можно будет делать стандартным способом
Встраивание ресурсов это простейший юзкейс. Истину говорю - как только constexpr чтение файлов появится, так сразу захотят сделать кодогенерацию из внешних конфигов (xml, json...) средствами компилятора. К примеру, перенести на уровень метапрограммирования метакомпилятор Qt и генерировать из ui файлов код на c++ без всяких внешних утилит.
Решил посмотреть что это такое, так как в принципе иметь удобный, универсальный и бесплатный инструмент рисования разных диаграмм весьма полезно. Запустил и долго пытался понять - после запуска jar открылось пустое окно, кнопка "выбрать директорию" и меню в котором почти ничего нет ("Open Sprite Window", "About" и "Exit"). Потом дошло, что PlantUML - это не классический WYSIWYG редактор диаграмм (где можно мышкой выбрать в "палитре" фигуры, соединить стрелочками и т.д.), а скорее генератор картинок по текстовому описанию.
Жаль, лично мне было бы интереснее именно визуальное редактирование.
А форматирование и не надо вводить. Но я бы подумал о введении разметки. К примеру, верхние и нижние индексы имеются в Юникоде как отдельные символы, но не все - только цифры, некоторые латинские буквы, некоторые спецсимволы. При этом в html и других "богатых" форматах для верхнего и нижнего индекса есть отдельная "декорация" - работающая уже для любых символов. Далее, всякие ударения, умляуты и прочие диакритические знаки - это ведь тоже "декорации"? По идее их можно назначить любому символу. Про цвета уже говорили. Направление письма туда же. Кроме того в Юникоде есть вот такая хрень - это уже в чистом виде escape-разметка как я ее предлагаю, но для очень частного случая аннотирования иероглифов.
Но с моей точки зрения в существующий стандарт вводить ничего такого не нужно. А нужно думать о новом стандарте, в котором будут учтены и исправлены все ошибки предыдущего. Да, здесь может быть картинка про 15 конкурирующих стандартов. Но можно подходить к этому и по другому - иногда действительно лучше переделать что-то с нуля, а не тащить огромный груз кривой обратной совместимости (ситуация такая же как с С++ и новыми языками типа Rust и Carbon).
Я думаю что сам по себе регистр символов, кодируемый отдельными кодами - ошибка на миллиарды долларов. Вот имеются три символа:
С точки зрения инопланетянина, это очевидно три разных символа. Мы знаем что это по смыслу одна и та же буква. Но с точки зрения Юникода, первые два - разные, а третий - лишь курсивный вариант начертания второго в некоторых шрифтах. Регистра не существует для различных иероглифов, индийского и арабского письма. И по большому счету (если бы проектировать Юникод с нуля) регистр должен быть вариантом "декорации", также как bold и italic. А в Юникод (не нынешний, а проектируемый с нуля разумеется) должны быть введены спецкоды (escape-коды) переключения регистра. И заодно, спецкоды переключения тех же bold и italic , всевозможных подчеркиваний и перечеркиваний, поворотов и отражений букв, цвета и многого другого. Некоторые такие модификаторы все равно пролезают в нынешний Юникод, но в каком-то суперкривом виде - известный пример с "цветами кожи" для смайликов, так почему бы не сделать всё системно и универсально?
О, статья о редактированию видео! У меня пара вопросов, может кто подскажет, каким редактором и с помощью каких инструментов внутри редактора это можно сделать. Просто правильные названия, чтобы было от чего отталкиваться в дальшейшем поиске. Интересуют два эффекта.
Первый - "Виртуальная камера": имеется видео, я хочу вырезать из него видео меньшего разрешения, задавая для некоторых кадров координаты и размер "прямоугольника обрезки". Для промежуточных кадров координаты и размер интерполируются. Далее для каждого кадра вырезается эта область и приводится к единому ранее заданному размеру. Т.е. это не просто обрезка, когда все кадры обрезаются по фиксированным координатам, а как будто мы перемещаем "виртуальную камеру" по исходному видео и приближаем/удаляем изображение.
Второй - "Динамическое ретуширование". По тому же принципу что и в первом эффекте я задаю для некоторых диапазонов кадров (не для всех) небольшую область, а программа сама находит в этой области цветовую неоднородность и устарняет ее, используя алгоритм "восстанавливающая кисть" как в фотошопе.
Чем дальше в лес тем больше жути. Но если претендуешь называться "Разработчиком на С++" то вроде как надо знать:)
А вообще двойственное ощущение от всего этого. С одной стороны рефлексия - очень нужная и полезная вещь в любом языке и в любой более-менее сложной задаче. С другой, то куда катится С++ уже не выдерживает никакой критики. По сути программистов вынуждают дописывать внутренности компилятора на весьма кривом функциональном языке.
Самое забавное что довольно неплохая эмуляция рефлексии была возможна еще в Си, на макросах (и нет это не boost.preprocressor, всё проще). Например, если нужно в одном месте (во избежание рассогласования) определить нечто, что могло бы разворачиваться в структуру, перечисление, список строк, использоваться для сериализации и т.п., то делается запросто.
Все скачанные exe проверяю на virustotal, пока этого хватает. Но на всякий случай: какие есть утилиты для однократной проверки на вирусы, т.е. не в фоне с перехватом всего, как классические антивирусы, а именно отдельные утилиты которые работают только когда их явно запустишь? Знаю несколько - упомянутые AVZ, KVRT, еще вроде Dr.Web CureIt. А что еще, в том числе нероссийских разработчиков?
Я при работе с С++ пользуюсь Qt (а иногда, если чисто для винды - даже MFC) и как правило вообще не испытываю потребности в стандартной библиотеке:)
ИМХО, языку С++ уже ничего не поможет - именно из-за огромного груза обратной совместимости. То что добавляют новые фичи - это даже интересно, наблюдая за этим процессом можно учиться тому, что и как при проектировании новых языков делать надо а что и как не надо. Видно например, какие решения многолетней давности приводят к проблемам.
Carbon и Circle - довольно интересные разработки. Carbon - развитой системой дженериков с концептами, Circle - императивным метапрограммированием. Хотя последний стремится быть слишком похожим на С++ (вероятно чтобы было проще переносить код), из-за чего там уже сейчас прослеживается немало ошибок дизайна.
А я закладками в браузере не пользуюсь вообще.
Я просто сохраняю всё интересное в оффлайн, в формате mhtml :)
А какую практическую задачу решает этот пример?
Хорошая среда разработки - достаточно легковесная, для линукса вообще одна из лучших. Но вот никак они не хотят добавить табы в редактор. Хотя плагины такие есть, но их же ставить нужно, иногда даже компилировать, а для этого нужны все исходники самого Creator'а...
Выглядит как будто это какие-то костыли к языку, который уже давно прогибается под огромным гнетом "обратной совместимости".
Если это будут преподавать на уроках обществознания в 8 классе - это будет не так уж и плохо. Но боюсь что будет скорее наоборот - сейчас некоторые теории заговора являются частью гос.идеологии:(
Полностью согласен. Не представляю как можно пользоваться смартфоном вместо компьютера. А последнее время и вообще в смартфонах разочаровался. Раньше, когда всё начиналось (еще были "КПК" и "Коммуникаторы") - было интересно. Иметь такое устройство в дополнение к компьютеру было круто и престижно. А теперь, когда у каждого есть смартфон - уже неинтересно.
И смартфоны действительно не дают ощущения полного контроля над устройством. К примеру, я задумываюсь над тем что неплохо было бы иметь что-то вроде виртуализации и криптоконтейнеров для смартфонов - это когда некоторое приложение (браузер, мессенджер и т.д.) ставится в специальное окружение, так что оно имеет доступ только в виртуальному зашифрованному "диску"-криптоконтейнеру (как TrueCrypt), где и вынуждено хранить все данные. Но вряд ли такой софт существует.
Про то что приложения нередко просят доступ ко всему подряд, и хорошо бы для таких иметь возможность создавать виртуальные фейковые источники данных (списки контактов, гео координаты и т.д.) - уже многие писали.
Интересно когда же появятся децентрализованные пиринговые LLM. Чтобы не обязательно было иметь топвую видяху, а просто запускаешь в фоне процесс и он там что-то немного вычисляет для других участников, а тебе за это дают право самому пользоваться всей сетью.
Фашизм какой-то.
О, спасибо, интересная тема!
Еще у меня были мысли о возможной кодификации эмоций на основе эмоциональных гормонов (таких как серотонин, допамин, кортизол, окситоцин, адреналин и т.д.).
Во-первых эти слизни нечитаемы. Я не понимаю что они обозначают. Если и делать то нужно что-то более узнаваемое, обычные смайлики подошли бы лучше.
Во-вторых, я и обычные лайки/дизлайки последнее время почти не применяю. Не знаю почему, статьи читаю а лайкать лень. Иногда лучше комментарий напишу.
Ну и наконец, по самим эмоциям. Это чисто теоретический вопрос. А как вообще наиболее правильно выбрать эмоции для оценки чего-либо? Нравится и не нравится - просто и понятно, линейная бинарная шкала. А эмоции? Есть ли какие-то базовые эмоции, их суперпозиции, сколько измерений в пространстве эмоций и применим ли вообще к ним такой математический подход?
Стоило ввести типы произвольной битовой длины signed<N> и unsigned<N>. В LLVM такие типы даже есть готовые, правда когда я последний раз смотрел - при попытке их применения всё падало, но с тех пор уже много времени и версий прошло, может и исправили.
Не прошло и полвека:) Хотя нет, прошло, год появления языка Си 1969, а это настолько низкоуровневая и фундаментальная фича, что она по здравому смыслу должна была быть еще в первой версии Си. Ну также как и бинарные литералы 0b00011011
Встраивание ресурсов это простейший юзкейс. Истину говорю - как только constexpr чтение файлов появится, так сразу захотят сделать кодогенерацию из внешних конфигов (xml, json...) средствами компилятора. К примеру, перенести на уровень метапрограммирования метакомпилятор Qt и генерировать из ui файлов код на c++ без всяких внешних утилит.
Решил посмотреть что это такое, так как в принципе иметь удобный, универсальный и бесплатный инструмент рисования разных диаграмм весьма полезно. Запустил и долго пытался понять - после запуска jar открылось пустое окно, кнопка "выбрать директорию" и меню в котором почти ничего нет ("Open Sprite Window", "About" и "Exit"). Потом дошло, что PlantUML - это не классический WYSIWYG редактор диаграмм (где можно мышкой выбрать в "палитре" фигуры, соединить стрелочками и т.д.), а скорее генератор картинок по текстовому описанию.
Жаль, лично мне было бы интереснее именно визуальное редактирование.