Скрипт на Питоне? Я думал что есть apk-имплементации для Android:) Интересно именно собрать все протоколы, используемые для обмена через Bluetooth, в одном мобильном приложении.
Полезная статья, спасибо! А раз уж в заголовке AirDrop, то может уважаемое Сообщество посоветует какое-то приложение - универсальный комбайн под Android, работающий со всеми AirDrop-подобными протоколами, включая и сам AirDrop? Знаю что это разработка Эппла, но неужели никто до сих пор не отреверсил протокол и не сделал совместимое приложение для Android?
Кроме шуток, у меня есть похожая идея, возникшая в результате вполне реального кейса.
Сжатие - считаем хеш, смотрим в DHT (торренты и прочие p2p сети), если файл там есть - считаем что он сжат и включаем в архив хеш файла. Если нет - сжимаем как обычно.
Распаковка - если в архиве хеш, то ищем в DHT и скачиваем, если не хеш - распаковываем обычным образом.
Для всяких там дистрибутивов наверняка будут фантастические коэффициенты сжатия, потому что большинство файлов как правило не меняется.
А идея возникла вот на каком месте. На компьютерах тем или иным образом появляется множество файлов, о назначении которых пользователи могут забыть или не знать (обычно - файлопомойка в папке Downloads, но бывают и более экзотические случаи). Хорошо бы иметь сервис типа Virustotal, который по хешу файла говорил бы, что это вообще такое.
Научитесь сначала ценить и защищать жизнь ныне живущих людей. Научитесь жить без войн и без диктатур. А то какой смысл людям рождаться, если они имеют неиллюзорный шанс погибнуть в каком нибудь очередном империалистическом переделе сфер влияния?
Чистые функции это самая очевидная, но не единственно возможная реализация. Нет ничего плохого в том, чтобы создавать во время компиляции объекты, сохраняющие состояние между вызовами макросов и т.п. (и даже взаимодействовать с внешним миром - к примеру читать и писать в файлы и базы данных). Другое дело что такой код сложнее отлаживать, и ошибки в нем могут привести к некорректной работе компилятора.
А макросы в Си - это вообще подстановка без выполнения кода при компиляции (т.е. чистая квазицитата). И как показывает практика, во многих случаях такие макросы более чем достаточны (другое дело что в Си они реализованы на лексическом, а не на синтаксическом уровне, отсюда они игнорируют структуру кода, области видимости, права доступа и т.п.). В Rust этому вроде как соответствуют декларативные макросы (и они таки синтаксические), но какой же кривой и мозгодробительный синтаксис!
Такое чувство что языки Rust и С++ соревнуются, у кого более непонятное и запутанное метапрограммирование. Между тем, синтаксические макросы сами по себе - простая концепция, и при правильной реализации достаточно одной единственной разновидности, а не четырех.
Соединяем их с вот такого типа стильными очками дополненной реальности
И ко всему этому добавляем множество нейродатчиков в анимешно-фентезийном стиле. Вместо калибровки - встроенная самообучающаяся нейросеть для декодирования сигналов.
И получается устройство, которое действительно станет популярным. А так все что я вижу (и AR-очки, и нейроинтерфейсы) - вроде идеи хорошие, но дизайн какой-то уж больно убогий.
Справедливости ради, inline - это тоже не требование, а просьба
Да, я это и имел в виду (хотя фраза получилась неоднозначной, да). ИМХО, с точки зрения дизайна языка просьбы к компилятору вообще лучше оформлять не ключевыми словами, а какими-то атрибутами/аннотациями.
В gcc вообще много интересных расширений. Вместо того чтобы придумывать всякую фигню, комитету по стандартизации для начала следовало бы просто взять и стандартизировать расширения С/С++ из gcc.
По большому счету, к среднестатистической статье по программированию и так меньше десятка комментариев набирается. И так тут стало скучно, а если забанить всех кто ничего не писал с какого-то года или не имеет статей - вообще тоска настанет:)
А запрет комменариев и тем более просмотра ваших статей - это вообще как? А если человек вообще незарегистрирован на Хабре? Кстати такая фигня была (а может и есть) в Твиттере. Там можно кому-то запретить доступ к своим твитам - но если зайти без регистрации (с другого браузера) то всё прекрасно доступно.
Ну прежде всего конечно не "компиляция на этапе выполнения" а "выполнение на этапе компиляции":)
А вообще на мой взгляд все эти новые возможности C++ выглядят как-то костыльно. Если constexpr это вроде как просьба к компилятору, а не требование (по типу inline?) , то какие могут быть ошибки? Не получилось сделать во время компмляции - будет во время выполнения, или как?
Понятно что у кого-то возникла потребность использовать тот же код и для времени компиляции и для времени выполнения. Понятно что во время компиляции любой код не выполнить - есть ограничения. Но вот способ реализации этого в языке... странный. На мой взгляд было бы логичнее единственное ключевое слово с фигурными скобками, которое заставляло бы компилятор вычислять все содержимое блока во время компиляции - или выдавать ошибку. Зачем это привязали именно к объектам - непонятно.
Думаю, ни слова нет потому что пока непонятно получится ли в принципе, и Apple не хочет заранее что-то обещать. Но размещение таких устройств в гарнитуре практически гарантирует, что будут попытки независимых разработчиков написать софт именно для управления.
Удивился что аббревиатура FMRI здесь расшифровывается как "магнитная инфракрасная визуализация", посмотрел в оригинале - действительно так:)
Но вообще очень хорошо что стали двигаться в этом направлении. Давно ждал чего-то подобного, использование сигналов мозга - очевидное решение для управления гарнитурой вместо всяких дурацких голосовых команд. Вроде как и аппаратные решения уже были, возможно множество датчиков в сочетании с нейросетевыми декодерамм улучшит точность такого управления.
Религиозные войны и сейчас вовсю идут. Просто раньше верующие верили в основном богов, а теперь - в государства (хотя и то и другие - интерсубъективные сущности, не существующие вне человеческих мозгов).
А почему не получится? Android же использует ядро Linux.
Скрипт на Питоне? Я думал что есть apk-имплементации для Android:) Интересно именно собрать все протоколы, используемые для обмена через Bluetooth, в одном мобильном приложении.
Полезная статья, спасибо! А раз уж в заголовке AirDrop, то может уважаемое Сообщество посоветует какое-то приложение - универсальный комбайн под Android, работающий со всеми AirDrop-подобными протоколами, включая и сам AirDrop? Знаю что это разработка Эппла, но неужели никто до сих пор не отреверсил протокол и не сделал совместимое приложение для Android?
Кроме шуток, у меня есть похожая идея, возникшая в результате вполне реального кейса.
Сжатие - считаем хеш, смотрим в DHT (торренты и прочие p2p сети), если файл там есть - считаем что он сжат и включаем в архив хеш файла. Если нет - сжимаем как обычно.
Распаковка - если в архиве хеш, то ищем в DHT и скачиваем, если не хеш - распаковываем обычным образом.
Для всяких там дистрибутивов наверняка будут фантастические коэффициенты сжатия, потому что большинство файлов как правило не меняется.
А идея возникла вот на каком месте. На компьютерах тем или иным образом появляется множество файлов, о назначении которых пользователи могут забыть или не знать (обычно - файлопомойка в папке Downloads, но бывают и более экзотические случаи). Хорошо бы иметь сервис типа Virustotal, который по хешу файла говорил бы, что это вообще такое.
Вот настоящая ссылка: https://golangreview.ru/docs/intro
Научитесь сначала ценить и защищать жизнь ныне живущих людей. Научитесь жить без войн и без диктатур. А то какой смысл людям рождаться, если они имеют неиллюзорный шанс погибнуть в каком нибудь очередном империалистическом переделе сфер влияния?
Чистые функции это самая очевидная, но не единственно возможная реализация. Нет ничего плохого в том, чтобы создавать во время компиляции объекты, сохраняющие состояние между вызовами макросов и т.п. (и даже взаимодействовать с внешним миром - к примеру читать и писать в файлы и базы данных). Другое дело что такой код сложнее отлаживать, и ошибки в нем могут привести к некорректной работе компилятора.
А макросы в Си - это вообще подстановка без выполнения кода при компиляции (т.е. чистая квазицитата). И как показывает практика, во многих случаях такие макросы более чем достаточны (другое дело что в Си они реализованы на лексическом, а не на синтаксическом уровне, отсюда они игнорируют структуру кода, области видимости, права доступа и т.п.). В Rust этому вроде как соответствуют декларативные макросы (и они таки синтаксические), но какой же кривой и мозгодробительный синтаксис!
Такое чувство что языки Rust и С++ соревнуются, у кого более непонятное и запутанное метапрограммирование. Между тем, синтаксические макросы сами по себе - простая концепция, и при правильной реализации достаточно одной единственной разновидности, а не четырех.
Берем вот такого типа кавайные наушники с ушками
Соединяем их с вот такого типа стильными очками дополненной реальности
И ко всему этому добавляем множество нейродатчиков в анимешно-фентезийном стиле. Вместо калибровки - встроенная самообучающаяся нейросеть для декодирования сигналов.
И получается устройство, которое действительно станет популярным. А так все что я вижу (и AR-очки, и нейроинтерфейсы) - вроде идеи хорошие, но дизайн какой-то уж больно убогий.
network тоже по сути прикладная (точнее библиотечная) вещь. А вот рефлексия - чисто языковая.
Да, я это и имел в виду (хотя фраза получилась неоднозначной, да). ИМХО, с точки зрения дизайна языка просьбы к компилятору вообще лучше оформлять не ключевыми словами, а какими-то атрибутами/аннотациями.
В gcc вообще много интересных расширений. Вместо того чтобы придумывать всякую фигню, комитету по стандартизации для начала следовало бы просто взять и стандартизировать расширения С/С++ из gcc.
Можно было сделать как в языке zig, ключевое слово comptime:
Интуитивно просто, привязка именно к выражению (фрагменту кода), а не к объекту.
А вообще и разрешить блокам возвращать значения не помешало бы, во многих языках блоки кода работают как выражения.
Интересно как скоро появятся умные диоптрийные линзы, адаптирующиеся к зрению конкертного человека в конкретных условиях и для конкретных задач?
По большому счету, к среднестатистической статье по программированию и так меньше десятка комментариев набирается. И так тут стало скучно, а если забанить всех кто ничего не писал с какого-то года или не имеет статей - вообще тоска настанет:)
А запрет комменариев и тем более просмотра ваших статей - это вообще как? А если человек вообще незарегистрирован на Хабре? Кстати такая фигня была (а может и есть) в Твиттере. Там можно кому-то запретить доступ к своим твитам - но если зайти без регистрации (с другого браузера) то всё прекрасно доступно.
Ну прежде всего конечно не "компиляция на этапе выполнения" а "выполнение на этапе компиляции":)
А вообще на мой взгляд все эти новые возможности C++ выглядят как-то костыльно. Если constexpr это вроде как просьба к компилятору, а не требование (по типу inline?) , то какие могут быть ошибки? Не получилось сделать во время компмляции - будет во время выполнения, или как?
Понятно что у кого-то возникла потребность использовать тот же код и для времени компиляции и для времени выполнения. Понятно что во время компиляции любой код не выполнить - есть ограничения. Но вот способ реализации этого в языке... странный. На мой взгляд было бы логичнее единственное ключевое слово с фигурными скобками, которое заставляло бы компилятор вычислять все содержимое блока во время компиляции - или выдавать ошибку. Зачем это привязали именно к объектам - непонятно.
Если на компьютере жертвы можно запустить вредоносный код, то зачем все остальные телодвижения?
Думаю, ни слова нет потому что пока непонятно получится ли в принципе, и Apple не хочет заранее что-то обещать. Но размещение таких устройств в гарнитуре практически гарантирует, что будут попытки независимых разработчиков написать софт именно для управления.
Удивился что аббревиатура FMRI здесь расшифровывается как "магнитная инфракрасная визуализация", посмотрел в оригинале - действительно так:)
Но вообще очень хорошо что стали двигаться в этом направлении. Давно ждал чего-то подобного, использование сигналов мозга - очевидное решение для управления гарнитурой вместо всяких дурацких голосовых команд. Вроде как и аппаратные решения уже были, возможно множество датчиков в сочетании с нейросетевыми декодерамм улучшит точность такого управления.
Религиозные войны и сейчас вовсю идут. Просто раньше верующие верили в основном богов, а теперь - в государства (хотя и то и другие - интерсубъективные сущности, не существующие вне человеческих мозгов).