эмм легковесный python и js? а можно в цифрах, вот последний lua на x64 вест 300кб
pocketpy это ~400 кб x86_64. Там весь интерпретатор это один .c объемом ~20k LOC.
Само собой это не весь дистрибутив Python -- это сам язык, его builtins и несколько полезных модулей типа sys, math, json и т. п.
И что по скорости вызова как python/js функций из C так и C функций из python/js?
Честно говоря, даже не задумывался о производительности вызовов фукций между скриптом и хостом, где там вообще можно накосячить?
Сам по себе pocketpy примерно в 1.5 раза медленее lua, но при этом чуточку быстрее cpython. То есть соврешенно обычная производительность, к которой все привыкли.
Лично мое мнение -- если производительности скрипта уровня базовых lua/cpython/duktape не хватает, то с высокой долей вероятности вы что-то делаете не так, пытаясь сделать слишком многое силами скрипта.
Да, могут быть такие единичные сценарии когда объективно нужна вся возможная производительность именно в скриптовой части, но в таких случаях тем более надо внимательно взвешивать все варианты.
На вентилятор спора про отличия Lua от остальных языков наброшу ещё такой аргумент: да, можно привыкнуть к индексации с единицы, глобальным переменным, чудному оператору "=~" и т. п., но зачем?
В современных реалиях куда более рациональным выглядит вариант прикрутить такой же легковесный и встраиваемый интерпретатор Python или Javascript и получить возможность писать скрипты с использованием несравнимо более распространенного и документированного синтаксиса.
Но зачем брать инструмент, для которого надо изучать и держать в уме мало применимые где-либо ещё нюансы,если можно взять более привычный и распространенный?
Аналогия с гвоздями и винтами плоха тем, что эти два типа метизов очень широко распространены и опыт работы с ними в любом случае будет полезен.
Но вот например включать в конструкцию чего-либо винты с левой резьбой без существенной на то причины просто потому что инженер должен уметь адаптироваться -- это как минимум контрпродуктивно.
В идеальном мире система сборки должна быть на 100% декларативной.
Увы, в реальности это практически невозможно. Всегда будет целая куча моментов, которые заранее в системе сборки предусмотреть невозможно, и которые будут скриптовать, кастомизировать, автоматизировать и т. д. и т. п. Остается только выбор будет ли это скрипт в рамках самой системы сборки (хоть сколько-нибудь единообразный и интегрируемый в остальную систему), или внешний костыль на bash/Python/etc.
CMake давным давно начал как по большей части императивный скрипт, с тех пор старается все сделать максимально декларативно, но полностью от императивности никогда не избавится.
Абстракция опции для сборки протекла под Windows с релизом толи MSVC 2012, то ли MSVC 2015, и архитектура указывается теперь специальным образом.
Не думаю, что это CMake виноват, что задание архитерктуры формализовано/стандартизовано только для системы сборки MSBuild.
Если бы у других систем сборки (Makefiles, Ninja и т. п.) были бы какие-то стандартные механизмы для выбора архитектуры, тогда наверное CMake смог бы абстрагировать эту опцию единым для всех образом.
Как выше уже отметили, JSON и не-JSON для одного инструмента, для ручного редактирования - ну такое.
Выглядит конечно так себе, но есть ли какие-то другие варианты?
Конфигурационный файл пресетов на языке CMake? CMakeLists.txt на JSON? Один другого хуже.
Кроме того, CMakeLists.txt это вынужденно императивный язык. А конфиги пресетов -- это именно конфиги, просто декларативный набор данных. В какой-то мере это как жаловаться что у C++ и clang-format разный синтаксис =).
Вообще если уж придираться к формату -- я бы пожаловался на выбор JSON для конфигов, которые явно будут часто редактироваться вручную. Ну есть же YAML (напоминаю, что JSON это подмножество YAML, по сути YAML это JSON с возможностью нормального, человеческого форматирования).
А если еще и CMakeCache.txt в расчет брать
А не надо CMakeCache.txt брать =) это внутренние дела CMake. Могут вообще в любой момент его формат поменять и будут правы.
Raspberry Pi там ни зачем особенно, в рамках своей концепции такой ноубук мог бы использовать любой другой одноплатник.
Просто Raspberry Pi самый надежный выбор: хорошо известный, документированный, повсеместно доступный одноплатный компьютер с вариантом исполнения в виде compute module, и ко всему прочему с гарантированным сроком производства и поддержки.
И одноплатный компьютер там очевидно не для того, чтобы на питоне через GPIO светодиодами мигать (хотя предусмотреть какой-нибудь разъем для них было бы логично, а вдруг все-таки), а просто как вариант такой вот унифицированной материнской платы.
Понятное дело что устройство будет очень нишевое. Но как очень крутая док-станция к используемому в роли мини-ПК одноплатнику -- вполне может найти применение. Я бы например взял для тестирования кросс-разработки/портирования под ARM -- покупать ультрабук на Snapdragon жабненько, а постоянно держать Raspberry Pi на столе с кучей проводов неудобно.
матрицу, которая по карману среднему DIY-щику <...> Но матрицы 36х24, пригодные для такого дела, я пока не встречал
А какие матрицы 36x24, пригодные для других дел вы встречали? =)
Доступных DIY матриц нормального размера вообще нет. Только мобильные сенсоры максимум 1/1.33" размером. Даже 1" не найти, что уж там говорить о полном кадре.
Чисто физически большую матрицу несложно купить в виде запчасти от какого-нибудь фотоаппарата, но ключевая проблема в том, что на них нет документации. Без подробных даташитов матрица это просто забавный сувенир.
В принципе, сенсоры с даташитами вам продадут, но только крупной партией и на индивидуально оговариваемых условиях. То есть не DIY.
Я бы с удовольствием попробовал бы сделать самодельную камеру, но увы, обычному инженеру-одиночке недоступны ни сенсор нормального размера, ни автофокусные объективы.
Panasonic: последняя зеркальная модель была выпущена в 2007 году.
Fujifilm: в 2007 году.
Olympus: в 2011 году.
Sony: в 2016 году (A99II). С тех пор Sony выпустили 15 беззеркальных моделей. В данный момент в официальном каталоге зеркальных моделей нет.
Canon: в январе 2020 года (1DX mkIII). С тех пор выпущено 14 беззеркальных моделей. В текущем каталоге есть по сути две серьезные зеркальные камеры (1DX mkIII и 5D mkIV) плюс 3-4 модели Rebel в зависимости от региона. Любопытно, что Canon были единственными кто уже в момент выпуска 1DX mkIII прямо признался что все, это последняя зеркальная модель.
Nikon: в феврале 2020 года (D6). С тех пор было выпущено 10 беззеркальных моделей. В текущем каталоге зеркальные камеры представлены четырьмя моделями 2017-2020 года выпуска.
Вышеперечисленные пять производителей занимают 95% рынка фотокамер. С практической точки зрения можно считать что зеркальные камеры уже не выпускаются.
Canon и Nikon предсказуемо были последними, кто полностью перешел на беззеркальную конструкцию -- с учетом размеров их пользовательской базы в то время, не так-то просто было взять и сменить технологию.
В итоге Nikon поплатились за эту неповоротливость: с уверенного второго места и серьезного конкурента Canon они скатились далеко на третье (всего 11% рынка).
Canon, Sony, Nikon, Fujifilm, Leica, Panasonic, OM (бывший Olympus) -- не выпускают зеркальные камеры уже много лет, а разработка новых была прекращена ещё раньше.
Это 99% рынка.
Даже если какой-нибудь Pentax производит несколько штук в год или если в некоторых магазинах до сих пор можно найти зеркалку Canon 2015 года выпуска в заводской упаковке -- ситуацию не меняет. Плёночные камеры тоже формально выпускают и их все ещё можно купить. Тем не менее плёночные камеры уже давно все и зеркалки тоже.
Плёночные камеры тоже. Суть в том, что зеркалки уже долгое время не выпускаются ни одним из сколь-нибудь заметных производителей на рынке. Зеркалка более не является синонимом слова фотоаппарат.
И судя по всему, все так же либо WSL2, либо VirtualBox -- включение WSL2 автоматически включает Hyper-V, а VirtualBox вместе с ним нормально работать не может, сваливаясь в какой-то очень медленный режим виртуализации.
возможно это вас удивит но в unicode влез не весь китайский и так было с самого начала его появления
Unicode намного, намного шире всего CJK вообще и китайского в частности.
Азиаты до сих пор используют не юникод кодировки ровно по той же причине, по которой не азиаты до сих пор используют не юникод -- грубо говоря, "исторически сложилось".
Вы же не будете утверждать, что кириллица не влезла в Unicode только лишь потому, что до сих пор в быту встречается Windows-1251?
Duktape (встраиваемый Javascript) еще меньше, 150-200 кб кода.
pocketpy это ~400 кб x86_64. Там весь интерпретатор это один .c объемом ~20k LOC.
Само собой это не весь дистрибутив Python -- это сам язык, его builtins и несколько полезных модулей типа sys, math, json и т. п.
Честно говоря, даже не задумывался о производительности вызовов фукций между скриптом и хостом, где там вообще можно накосячить?
Сам по себе pocketpy примерно в 1.5 раза медленее lua, но при этом чуточку быстрее cpython. То есть соврешенно обычная производительность, к которой все привыкли.
Лично мое мнение -- если производительности скрипта уровня базовых lua/cpython/duktape не хватает, то с высокой долей вероятности вы что-то делаете не так, пытаясь сделать слишком многое силами скрипта.
Да, могут быть такие единичные сценарии когда объективно нужна вся возможная производительность именно в скриптовой части, но в таких случаях тем более надо внимательно взвешивать все варианты.
Питон отлично встраивается в микропроцессорные системы: https://micropython.org/
Но возникает вопрос зачем уезжать именно в страну с левосторонним движением.
На вентилятор спора про отличия Lua от остальных языков наброшу ещё такой аргумент: да, можно привыкнуть к индексации с единицы, глобальным переменным, чудному оператору "=~" и т. п., но зачем?
Lua далеко не единственный встраиваемый скриптовый язык: https://github.com/dbohdan/embedded-scripting-languages
В современных реалиях куда более рациональным выглядит вариант прикрутить такой же легковесный и встраиваемый интерпретатор Python или Javascript и получить возможность писать скрипты с использованием несравнимо более распространенного и документированного синтаксиса.
Но зачем брать инструмент, для которого надо изучать и держать в уме мало применимые где-либо ещё нюансы,если можно взять более привычный и распространенный?
Аналогия с гвоздями и винтами плоха тем, что эти два типа метизов очень широко распространены и опыт работы с ними в любом случае будет полезен.
Но вот например включать в конструкцию чего-либо винты с левой резьбой без существенной на то причины просто потому что инженер должен уметь адаптироваться -- это как минимум контрпродуктивно.
13 февраля проект покинул один из его основателей и ключевых разработчиков, Hector Mertin:
https://www.phoronix.com/news/Hector-Martin-Resigns-Asahi
А 18 марта ушел ещё один ключевой разработчик, Asahi Lina, которая едва ли не в одиночку тащила разработку/реверс-инжиниринг драйверов GPU:
https://www.phoronix.com/news/Asahi-Lina-Steps-Down-Linux-GPU
(Есть теория, что это на самом деле один человек.)
В общем, есть некоторые опасения касаемо будущего проекта =(.
И потом портят его спорным DE.
Цены бы макбукам на M1 не было, если бы не macOS.
(личное мнение автора комментария)
В идеальном мире система сборки должна быть на 100% декларативной.
Увы, в реальности это практически невозможно. Всегда будет целая куча моментов, которые заранее в системе сборки предусмотреть невозможно, и которые будут скриптовать, кастомизировать, автоматизировать и т. д. и т. п. Остается только выбор будет ли это скрипт в рамках самой системы сборки (хоть сколько-нибудь единообразный и интегрируемый в остальную систему), или внешний костыль на bash/Python/etc.
CMake давным давно начал как по большей части императивный скрипт, с тех пор старается все сделать максимально декларативно, но полностью от императивности никогда не избавится.
Не думаю, что это CMake виноват, что задание архитерктуры формализовано/стандартизовано только для системы сборки MSBuild.
Если бы у других систем сборки (Makefiles, Ninja и т. п.) были бы какие-то стандартные механизмы для выбора архитектуры, тогда наверное CMake смог бы абстрагировать эту опцию единым для всех образом.
Выглядит конечно так себе, но есть ли какие-то другие варианты?
Конфигурационный файл пресетов на языке CMake? CMakeLists.txt на JSON? Один другого хуже.
Кроме того, CMakeLists.txt это вынужденно императивный язык. А конфиги пресетов -- это именно конфиги, просто декларативный набор данных. В какой-то мере это как жаловаться что у C++ и clang-format разный синтаксис =).
Вообще если уж придираться к формату -- я бы пожаловался на выбор JSON для конфигов, которые явно будут часто редактироваться вручную. Ну есть же YAML (напоминаю, что JSON это подмножество YAML, по сути YAML это JSON с возможностью нормального, человеческого форматирования).
А не надо CMakeCache.txt брать =) это внутренние дела CMake. Могут вообще в любой момент его формат поменять и будут правы.
Raspberry Pi там ни зачем особенно, в рамках своей концепции такой ноубук мог бы использовать любой другой одноплатник.
Просто Raspberry Pi самый надежный выбор: хорошо известный, документированный, повсеместно доступный одноплатный компьютер с вариантом исполнения в виде compute module, и ко всему прочему с гарантированным сроком производства и поддержки.
И одноплатный компьютер там очевидно не для того, чтобы на питоне через GPIO светодиодами мигать (хотя предусмотреть какой-нибудь разъем для них было бы логично, а вдруг все-таки), а просто как вариант такой вот унифицированной материнской платы.
Понятное дело что устройство будет очень нишевое. Но как очень крутая док-станция к используемому в роли мини-ПК одноплатнику -- вполне может найти применение. Я бы например взял для тестирования кросс-разработки/портирования под ARM -- покупать ультрабук на Snapdragon жабненько, а постоянно держать Raspberry Pi на столе с кучей проводов неудобно.
А какие матрицы 36x24, пригодные для других дел вы встречали? =)
Доступных DIY матриц нормального размера вообще нет. Только мобильные сенсоры максимум 1/1.33" размером. Даже 1" не найти, что уж там говорить о полном кадре.
Чисто физически большую матрицу несложно купить в виде запчасти от какого-нибудь фотоаппарата, но ключевая проблема в том, что на них нет документации. Без подробных даташитов матрица это просто забавный сувенир.
В принципе, сенсоры с даташитами вам продадут, но только крупной партией и на индивидуально оговариваемых условиях. То есть не DIY.
Я бы с удовольствием попробовал бы сделать самодельную камеру, но увы, обычному инженеру-одиночке недоступны ни сенсор нормального размера, ни автофокусные объективы.
Да какие тут иллюзии? В хронологическом порядке:
Panasonic: последняя зеркальная модель была выпущена в 2007 году.
Fujifilm: в 2007 году.
Olympus: в 2011 году.
Sony: в 2016 году (A99II). С тех пор Sony выпустили 15 беззеркальных моделей. В данный момент в официальном каталоге зеркальных моделей нет.
Canon: в январе 2020 года (1DX mkIII). С тех пор выпущено 14 беззеркальных моделей. В текущем каталоге есть по сути две серьезные зеркальные камеры (1DX mkIII и 5D mkIV) плюс 3-4 модели Rebel в зависимости от региона. Любопытно, что Canon были единственными кто уже в момент выпуска 1DX mkIII прямо признался что все, это последняя зеркальная модель.
Nikon: в феврале 2020 года (D6). С тех пор было выпущено 10 беззеркальных моделей. В текущем каталоге зеркальные камеры представлены четырьмя моделями 2017-2020 года выпуска.
Вышеперечисленные пять производителей занимают 95% рынка фотокамер. С практической точки зрения можно считать что зеркальные камеры уже не выпускаются.
Canon и Nikon предсказуемо были последними, кто полностью перешел на беззеркальную конструкцию -- с учетом размеров их пользовательской базы в то время, не так-то просто было взять и сменить технологию.
В итоге Nikon поплатились за эту неповоротливость: с уверенного второго места и серьезного конкурента Canon они скатились далеко на третье (всего 11% рынка).
Canon, Sony, Nikon, Fujifilm, Leica, Panasonic, OM (бывший Olympus) -- не выпускают зеркальные камеры уже много лет, а разработка новых была прекращена ещё раньше.
Это 99% рынка.
Даже если какой-нибудь Pentax производит несколько штук в год или если в некоторых магазинах до сих пор можно найти зеркалку Canon 2015 года выпуска в заводской упаковке -- ситуацию не меняет. Плёночные камеры тоже формально выпускают и их все ещё можно купить. Тем не менее плёночные камеры уже давно все и зеркалки тоже.
Плёночные камеры тоже. Суть в том, что зеркалки уже долгое время не выпускаются ни одним из сколь-нибудь заметных производителей на рынке. Зеркалка более не является синонимом слова фотоаппарат.
Оффтоп:
Интересно сколько ещё люди будут по старой привычке называть системные камеры зеркалками? =)
Отдельно иронично, что в "настоящих" камерах зеркал уже давно нет, а вот в смартфонах они часто есть, хоть и выполняют конечно совсем другую функцию.
Автор же прямо написал:
Он отрезал экран не для того, чтобы носить очки, а потому что он все равно носит очки и экран оказывается лишним.
И судя по всему, все так же либо WSL2, либо VirtualBox -- включение WSL2 автоматически включает Hyper-V, а VirtualBox вместе с ним нормально работать не может, сваливаясь в какой-то очень медленный режим виртуализации.
https://github.com/MicrosoftDocs/WSL/issues/798
Unicode намного, намного шире всего CJK вообще и китайского в частности.
Азиаты до сих пор используют не юникод кодировки ровно по той же причине, по которой не азиаты до сих пор используют не юникод -- грубо говоря, "исторически сложилось".
Вы же не будете утверждать, что кириллица не влезла в Unicode только лишь потому, что до сих пор в быту встречается Windows-1251?
Весь интересный простому обывателю софт уже давно есть в варианте под ARM:
https://armrepo.ver.lt/