кстати, приходится использовать иногда, тк некоторые простенькие роутеры умеют из коробки только L2TP и, о боже, PPTP.
Из альтернатив:
через консоль пробросить вручную шифрованный тоннель (если ядро прошивки умеет в XFRM). Но это до первой перезагрузки. В итоге оказалось, что мне проще добавить L2TP на сервер. Да и на моих кейсах поддержка XFRM вроде отсутствовала как правило.
собрать свою прошивку.. лично я пока на такое не созрел для мини-роутеров
Вопрос замусоренности cargo.io - это компромис. С другой стороны, зачем вообще туда тестовые крейты публиковать, если практически все можно потестировать и даже нормально использовать через git-платформу какую-нибудь, а далее "адресовать" версии и тд через параметризацию зависимостей в toml: rev, branch, tag.
ChatGPT часто "выглядит" (ведет себя) очень умно, по-человечески. И всё же, нельзя забывать, что у него нет осознания как самого себя, так и выдаваемых им результатов.
тут неявно присутствует утверждение, что феномен Сознания базируется на каких-то других принципах, нежели чатЖПТ. Но несмотря на то, что поиски желанного доказательства особенности Сознания идут давно, результат пока неутешительный. Поэтому на иллюстрации вместо AI можно смело написать Сознание.
стал осваивать данную тулзу с целью прикрутить к своим мини-недо-проектам и обнаружил, что, например, наличие tristate в файлах ‘kconfig’ не вызывает ошибок при открытии утилитой kconfig-mconf например, но активизировать ‘третье состояние’ никак невозможно.. опция ‘modules’ тупо вызывает ошибку - не поддерживается парсером.
Стал штудировать kernel.org - обнаружил, что там ещё переменные и другие фичи есть. Но всё это не работает!
А вот парсер, идущий с сырцами ядра, - ./scripts/kconfig/mconf, всё умеет.
Никакие apt-update и тд не помогали. Все варианты не умели в ‘третье состояние’ и переменные.
РЕШЕНИЕ: из сырцов ядра просто заменил в системе пару бинарников:
1) ./scripts/kconfig/mconf -> /bin/kconfig-mconf
2) ./scripts/kconfig/conf -> /bin/kconfig-conf
всё стало работать так, как описано в документации.
Но осадок остался. Должно же работать ‘из коробки’ по идее ?♂️ Как надо было бы нормально решать эту проблему?
всё еще "не взлетит"? или уже взлетел? как ситуация развивается? а то из-за некоторых необновляемых девайсов на iOS10 возникает иногда желание вспомнить старый добрый UIKit.. правда, его я использовал только с ObjC по сути.
Если я не ошибаюсь: 1) с большой буквы - это объявление типа (это стандартное соглашение). Других вариантов вроде бегло не нашел. 2) с маленькой буквы - это либо собственно экземпляр (это тоже стандартное соглашение), либо в паре мест это выступает как ключевое слово... точнее, псевдо-ключевое (как я понял). В общем, неоднозначность есть только по п.2, но вроде по контексту понятно, где что.
Наверное, если будут цитаты, можно будет более адресно ответить.
Статья очень помогла.
Кстати, недавно наткнулся на инфу, которая вдруг раскрыла, что же за элемент проекта SpriteKit под таинственным именем «GameScene.sks»
Оказывается это что-то вроде аналога сториборда, но для спрайткита — визуальный редактор сцены! Для заинтригованных ссылка тут
Выглядит не на 30% понятно, но заманчиво.
А можно ли где-нибудь найти реализацию этого «билдера»? Мне кажется, что на Swift он отсутствует, что несколько мотивирует портировать его туда.
А если и не портировать, то может какие-то идеи впитать.
Предвкушение чуда не оправдалось — примерно что-то подобное тоже получалось накидать, когда решил взглянуть на эту дилемму благодаря вашему замечанию. Раньше я вообще об этом не задумывался на столько серьезно. Поэтому в любом случае спасибо за повод разобраться и, возможно, переосознать!
И все же, тут есть над чем поломать копья.
Если такой код будет где-то не рядом с объявлением переменных
Объявление нелокальных переменных с неинформативными именами — это нередко целый букет систематических проблем уже само по себе. Это один из первых уроков, который я вынес когда-то из книжки «Чистый код» (кажется так она называлась), а потом и лично убедился, что мне содержательное именование переменных снимает львиную долю проблем.
Соглашусь так же, что реализация через методы дает дополнительный вариант «защиты» через содержательное именование самих методов. Такая опция для операторов кажется недоступна.
Но стоит ли так радикально ставить вопрос: либо только методы, либо только операторы?
Мне кажется, что истина посередине. Например: можно реализовать только однородные операторы (сложение/вычитание), которые подразумевают оба операнда однотипными.
Сделает это код более компактным, чем только реализуя через методы? Возможно.
Будет такой код более понятным относительно типов с операндами? Так же возможно.
Если по мне, то гибридный подход уже дает как минимум «probably Win probably Win»
можно прикинуть как это будет выглядеть в случаи с записью без операторов
Спасибо! Получилось, как у меня.
Здесь есть двоякий момент.
1) если создание временного объекта неизбежно (а так случается), то это придется делать вручную. В итоге:
кол-во действий увеличится (объект нужно объявить и создать),
способов ошибиться прибавиться (надо будет при поддержке кода отслеживать большее число элементов кода),
читаемость кода ухудшится (мы будем видеть доп.информацию о том, что делает компилятор в перемешку с тем, что собственно отражает логику замысла разработчика).
Но соптимизировать будет нечего.
2) а вот если создание временного объекта можно избежать, то это станет несколько очевиднее, чем в операторной записи. Например:
a = b+c
выполняет на одну операцию больше, чем
a=b
a+=c
Но это друга уже дилемма: на этапе Отладки предпочтительнее видеть Что хотим Мы сделать, а на этапе Оптимизации (если она нужна в данном куске кода) Как это будет Реализовывать Компилятор.
Бытует мнение, что всему свое время: для упрощения Отладки желательно иметь максимально понятную и прозрачную реализацию Задуманной логики, а на этапе Оптимизации желательно иметь Отлаженный (и оттестированный) код, который заменяется на аналогичный оптимизированный, а аналогичность Отлаженного и Оптимизированного кода опять же тестится достаточно легко и элегантно… но это друга тема.
В любом случае! Если не касаться проблем из-за оптимизации во время отладки, то и тут есть компромисы вместо крайностей: если не определять бинарные операторы, а только унарные с присвоением, то мы получим невозможность неявного создания временных объектов и это будет, как я понимаю, полная аналогия с подходом через методы.
Причем, это тоже можно реализовать не радикально: либо выкидываем бинарные операторы, либо используем, а гибко:
объявляем и полный набор операторов, но неоптимальные/медленные/итд выносим в блок или файл, который откючается (у меня автоматически), если компиляция переводиться в режим Оптимизации.
То есть, пока отлаживаем — пишем нормальные однострочные понятные формулы почти в том виде, как они в тетрадке/презентации/учебнике записаны.
А когда оптимизируем — компилятор перестанет понимать некоторые места, и мы их заменяем на аналогичные (в чем помогут тесты) развернутые/оптимизированные/использующие_регистры/итд реализации.
Но тут прозрачны все действия, которые происходят с объектами.
Аблсолютно!
Для оптимизации это крайне важно — видеть (или понимать) действия компилятора «под капотом».
И тут надо либо всегда под бинарным оператором иметь привычку видеть создание объекта (что требует дополнительной вдумчивости), либо иметь явно выписанные элементарные действия (тут уж никуда не деться).
Вопрос только в том, сколько нужно потратить времени и сил на этапе Отладки, чтобы из такого кода «дизассемблировать» и рассмотреть Логику, ради которой это все затеяно? А сколько потом нужно времени, чтобы понять, что неправильно понял, и потом все же надеяться, что с энного раза все же ее правильно понял? А как такой код поддерживать? Как немного скорректировать в процессе доводок? Как найти ошибку? И далее по изодранному списку вечных проблем… (ради ухода от которых решили перейти с машинных кодов на компиляторы).
В общем, можно на эти вопросы давать разные ответы с разной пропорцией субъективность/объективность.
Но именно эти вопросы лично меня заставили когда-то признать поражение моей Ассемблерной религии и перейти на С++. Поэтому фараза
Ага, выглядит как ассмеблерная запись вашего кода
очень даже уместна. В данном случае это действительно шаг в ту сторону.
Нужен этот шаг?
На этапе Оптимизации — несомненно!
Нужно ли заниматься Оптимизацией неОтлаженного кода?
Тут надо себе ответить самостоятельно.
Ну и еще пара моментов, отчасти как повторение-переформулировка
Наверное не стоит на уровне глобальной идеологии унифицировать противостояние операторов и методов
Для некоторых мега-классов операторы могут только вредить, не иметь внятного смысла или хотя бы возможности быть оптимальными не только в компиляции, но и в плане читабельности.
А для некоторых нано-структур даже Избегание создания временных объектов — это больше зло, чем накладные расходы из-за их использования, особенно, если эти классы-структуры могут целиком передаваться в паре регистров процессора.
По моему продолжительному, но скромному опыту, складывается впечатление, что Оптимизировать во время Отладки (тем более Разработки) — это не очень прямой путь: для Отладки нужна прозрачная просматриваемая логика, а для Оптимизации нужен Отлаженный модуль/приложение, которое вот теперь действительно предстоит закодировать в самом прямом смысле!!
кстати, приходится использовать иногда, тк некоторые простенькие роутеры умеют из коробки только L2TP и, о боже, PPTP.
Из альтернатив:
через консоль пробросить вручную шифрованный тоннель (если ядро прошивки умеет в XFRM). Но это до первой перезагрузки. В итоге оказалось, что мне проще добавить L2TP на сервер. Да и на моих кейсах поддержка XFRM вроде отсутствовала как правило.
собрать свою прошивку.. лично я пока на такое не созрел для мини-роутеров
Emac тоже умеет в Rust?!
Всегда думал, что VS - вот это экзотика, которую используют больше из-за стримов и ютуба. Оказывается ещё даже вон что! ?
Вопрос замусоренности cargo.io - это компромис.
С другой стороны, зачем вообще туда тестовые крейты публиковать, если практически все можно потестировать и даже нормально использовать через git-платформу какую-нибудь, а далее "адресовать" версии и тд через параметризацию зависимостей в toml: rev, branch, tag.
Супер! ??
Нашел опечатку в
Boolmarks -> Bookmarks
ipv4 без NAT вообще никак. просто к этому костылю все привыкли как к данности.
в ipv6 NAT нужен только частично: для легаси-v4 и/либо для узких специфичных задач.
если возможно, то извините, что не удержался поддержать оффтопик.
параллель не очень удачная: в отличие от термояда у кого-то ipv6 есть точно.
тут неявно присутствует утверждение, что феномен Сознания базируется на каких-то других принципах, нежели чатЖПТ. Но несмотря на то, что поиски желанного доказательства особенности Сознания идут давно, результат пока неутешительный. Поэтому на иллюстрации вместо AI можно смело написать Сознание.
привет из будущего!
кто тут про нейронки скепсис сеял?
стал осваивать данную тулзу с целью прикрутить к своим мини-недо-проектам и обнаружил, что, например, наличие tristate в файлах ‘kconfig’ не вызывает ошибок при открытии утилитой kconfig-mconf например, но активизировать ‘третье состояние’ никак невозможно.. опция ‘modules’ тупо вызывает ошибку - не поддерживается парсером.
Стал штудировать kernel.org - обнаружил, что там ещё переменные и другие фичи есть. Но всё это не работает!
А вот парсер, идущий с сырцами ядра, - ./scripts/kconfig/mconf, всё умеет.
Никакие apt-update и тд не помогали. Все варианты не умели в ‘третье состояние’ и переменные.
РЕШЕНИЕ: из сырцов ядра просто заменил в системе пару бинарников:
1) ./scripts/kconfig/mconf -> /bin/kconfig-mconf
2) ./scripts/kconfig/conf -> /bin/kconfig-conf
всё стало работать так, как описано в документации.
Но осадок остался. Должно же работать ‘из коробки’ по идее ?♂️ Как надо было бы нормально решать эту проблему?
из некритичного: я бы все же поправил с "придельно" на "предельно"
"В объявлении нашей функции getTextFromImage мы указали ключевое слово await"
может не await, а async?
это прям хед-шот )
можно и НУЖНО, если третий свифт использовать.
для объектов без "владения" нужно @ObservedObject.
Но это все для третьего Свифта. На ранних версиях (о которых тут речь) возможно это еще не было отшлифовано.
всё еще "не взлетит"? или уже взлетел? как ситуация развивается?
а то из-за некоторых необновляемых девайсов на iOS10 возникает иногда желание вспомнить старый добрый UIKit.. правда, его я использовал только с ObjC по сути.
offtopic: «Так можно было бы и до 6-ти байт дойти, но кодировать ими уже ничего.»
в конце «нЕчего» ☺️
Если я не ошибаюсь:
1) с большой буквы - это объявление типа (это стандартное соглашение). Других вариантов вроде бегло не нашел.
2) с маленькой буквы - это либо собственно экземпляр (это тоже стандартное соглашение), либо в паре мест это выступает как ключевое слово... точнее, псевдо-ключевое (как я понял).
В общем, неоднозначность есть только по п.2, но вроде по контексту понятно, где что.
Наверное, если будут цитаты, можно будет более адресно ответить.
кстати, мне кажется вместо «после команды in» должно быть «перед командой in»
Кстати, недавно наткнулся на инфу, которая вдруг раскрыла, что же за элемент проекта SpriteKit под таинственным именем «GameScene.sks»
Оказывается это что-то вроде аналога сториборда, но для спрайткита — визуальный редактор сцены!
Для заинтригованных ссылка тут
А можно ли где-нибудь найти реализацию этого «билдера»? Мне кажется, что на Swift он отсутствует, что несколько мотивирует портировать его туда.
А если и не портировать, то может какие-то идеи впитать.
И все же, тут есть над чем поломать копья.
Объявление нелокальных переменных с неинформативными именами — это нередко целый букет систематических проблем уже само по себе. Это один из первых уроков, который я вынес когда-то из книжки «Чистый код» (кажется так она называлась), а потом и лично убедился, что мне содержательное именование переменных снимает львиную долю проблем.
Соглашусь так же, что реализация через методы дает дополнительный вариант «защиты» через содержательное именование самих методов. Такая опция для операторов кажется недоступна.
Но стоит ли так радикально ставить вопрос: либо только методы, либо только операторы?
Мне кажется, что истина посередине. Например: можно реализовать только однородные операторы (сложение/вычитание), которые подразумевают оба операнда однотипными.
Сделает это код более компактным, чем только реализуя через методы? Возможно.
Будет такой код более понятным относительно типов с операндами? Так же возможно.
Если по мне, то гибридный подход уже дает как минимум «probably Win probably Win»
Спасибо! Получилось, как у меня.
Здесь есть двоякий момент.
кол-во действий увеличится (объект нужно объявить и создать),
способов ошибиться прибавиться (надо будет при поддержке кода отслеживать большее число элементов кода),
читаемость кода ухудшится (мы будем видеть доп.информацию о том, что делает компилятор в перемешку с тем, что собственно отражает логику замысла разработчика).
Но соптимизировать будет нечего.
выполняет на одну операцию больше, чем
Но это друга уже дилемма: на этапе Отладки предпочтительнее видеть Что хотим Мы сделать, а на этапе Оптимизации (если она нужна в данном куске кода) Как это будет Реализовывать Компилятор.
Бытует мнение, что всему свое время: для упрощения Отладки желательно иметь максимально понятную и прозрачную реализацию Задуманной логики, а на этапе Оптимизации желательно иметь Отлаженный (и оттестированный) код, который заменяется на аналогичный оптимизированный, а аналогичность Отлаженного и Оптимизированного кода опять же тестится достаточно легко и элегантно… но это друга тема.
В любом случае! Если не касаться проблем из-за оптимизации во время отладки, то и тут есть компромисы вместо крайностей: если не определять бинарные операторы, а только унарные с присвоением, то мы получим невозможность неявного создания временных объектов и это будет, как я понимаю, полная аналогия с подходом через методы.
Причем, это тоже можно реализовать не радикально: либо выкидываем бинарные операторы, либо используем, а гибко:
объявляем и полный набор операторов, но неоптимальные/медленные/итд выносим в блок или файл, который откючается (у меня автоматически), если компиляция переводиться в режим Оптимизации.
То есть, пока отлаживаем — пишем нормальные однострочные понятные формулы почти в том виде, как они в тетрадке/презентации/учебнике записаны.
А когда оптимизируем — компилятор перестанет понимать некоторые места, и мы их заменяем на аналогичные (в чем помогут тесты) развернутые/оптимизированные/использующие_регистры/итд реализации.
Аблсолютно!
Для оптимизации это крайне важно — видеть (или понимать) действия компилятора «под капотом».
И тут надо либо всегда под бинарным оператором иметь привычку видеть создание объекта (что требует дополнительной вдумчивости), либо иметь явно выписанные элементарные действия (тут уж никуда не деться).
Вопрос только в том, сколько нужно потратить времени и сил на этапе Отладки, чтобы из такого кода «дизассемблировать» и рассмотреть Логику, ради которой это все затеяно? А сколько потом нужно времени, чтобы понять, что неправильно понял, и потом все же надеяться, что с энного раза все же ее правильно понял? А как такой код поддерживать? Как немного скорректировать в процессе доводок? Как найти ошибку? И далее по изодранному списку вечных проблем… (ради ухода от которых решили перейти с машинных кодов на компиляторы).
В общем, можно на эти вопросы давать разные ответы с разной пропорцией субъективность/объективность.
Но именно эти вопросы лично меня заставили когда-то признать поражение моей Ассемблерной религии и перейти на С++. Поэтому фараза очень даже уместна. В данном случае это действительно шаг в ту сторону.
Нужен этот шаг?
На этапе Оптимизации — несомненно!
Нужно ли заниматься Оптимизацией неОтлаженного кода?
Тут надо себе ответить самостоятельно.
Для некоторых мега-классов операторы могут только вредить, не иметь внятного смысла или хотя бы возможности быть оптимальными не только в компиляции, но и в плане читабельности.
А для некоторых нано-структур даже Избегание создания временных объектов — это больше зло, чем накладные расходы из-за их использования, особенно, если эти классы-структуры могут целиком передаваться в паре регистров процессора.