что происходит. Я узнал про эту игрушку недавно когда в автомате китаянке не хватило игрушки и она сбросилась с высоты. Рядом наблюдаю pop-mart кажется магазин где ее продают, очереди постоянно, даже охрана стоит на случай месива. Нар**та наверное меньше прибыли приносит чем это поделие. В каком мире мы живет))
Реально видел такое в Малайзии. Чувак разложил iPad, ноут и внешнюю клаву. Насколько помню таких было несколько человек в один момент. Я думал эта шутка какая-то, так как редко хожу с СБ.
У нас тоже скелетон в пару строк просто анимация цветов с слабо серого до сильно серого. Можно использовать view builder чтобы убрать AnyView, он сам каждую бранчу завернет в нее автоматом.
Еще вспомнил, чем нам SPM колеса вставлял. Мы в одной тяжелой репе сделали SPM зависимость и ее подключали в проекта в другой репе. Так как репа либы весила 1 Гб, то SPM не только первый раз ее выкачивал полностью, а вообще всегда ее выкачивал, то есть почти на любой чих он качал 1 Гб что примерно занимало ожидание в 10 минут при открытии проекта. Cocoapods один раз скачивал и потом просто докачивал репу и ресетился на нужный коммит/версию. Когда мы с помощью специальной тулы убрали из репы тяжелые файлы то Cocoapods как полагается скачивал репу мгновенно, но SPM особенный и клонит репу с --mirror флагом вместо shallow (https://github.com/swiftlang/swift-package-manager/issues/6062), что запрашивает с сервера гита из кеша, то есть в нашем случае он снова скачивала удаленные бинарники на 1 Гб. Пришлось писать git core team чтобы они дропнули всё из кеша гита нашего репозитория.
в моем случае 2 сторонних пода ссылались на одну и ту же библиотеку разных версий + походу cocoapods проверяет совместимость версий только на "верхнем" уровне.
Нужно смотреть как прописаны версии зависимостей, насколько строго или свободно (https://guides.cocoapods.org/syntax/podfile.html#pod), поидее в Podfile.lock прописаны финальные версии на что зарезолвил cocoapods. Согласен, беда когда коллизия версий происходит.
по идее есть причем. SPM положил код в основной бинарник, а Cocoapods в виде динамики. Когда рантайм запустился то одна и та же функция есть в 2х местах и не известно что из них будет использовано. То есть нужно перестраивать или spm или cocoapods чтобы убрать warning. Но вы правы это всего лишь варнинг, и в нем нет ничего страшного если знать что он значит. Но я когда такое видел в консоли то не могу такое терпеть ибо не по феншую, я просто на cocoapods post install правил проект чтобы их убрать.
вспомнил, у нас давно тоже была библиотека только под интел, а с проектом уже работали на новых силиконах. Так вот, если в проекте есть либа под интел (x86_64), то и весь проект насколько помню будет собираться под интел и запускаться приложение на симуляторе будет через трансляцию Rosseta. Посмотрите в Xcode Build логах под какую архитектуру он собирает проект под симулятор при отсутствии либы под натив ?
Class _TtC9Alamofire11DataRequest is implemented in both /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Frameworks/Alamofire.framework/Alamofire (0x10193aaf0) and /private/var/containers/Bundle/Application/7AC9F854-BBAC-437A-B556-4DB94E6017DA/Foo.app/Foo.debug.dylib (0x1075719b8). One of the two will be used. Which one is undefined.
У вас Alamofire положен в виде динамической библиотеки в бандл приложения, скорее всего Cocoapods это сделал если не указано явно в Podfile static linkage. А SPM с недавних пор стал ликовать статично (в бинарник). Первое что приходит в голову это подправить возможно в Podfile чтобы после pod install этой либе прописывалась weak_framework или что-то подобное, но скорее всего да придется лезть еще глубже.
У меня тоже была подобная проблема, когда часть зависимостей ушли в Carthage, но часть зависимостей осталась в Cocoapods и им нужны эти Carthage либы. Пришлось форкать и править podspec чтобы этих зависимостей не было в podspec, а на pod install для этих зависимостей прописывать зависимости на Carthage. Но это того стоило, у нас как только RxSwift и его обвязка ушла в Carthage сразу стало на минуту быстрее собираться минимум. А когда ушли все гугловые либы так еще много минут ушло и из компиляции и индексации так как гугловый Firebase тянет за собой тонну сишных либ, один только grpc либа собирается пару минут.
x86_64 это симулятор под интел процессор, на силиконе уже идет под натив тоже arm64.
Всё, что нужно — ввести логин и пароль от приватного репозитория при добавлении его в проект. Это придется сделать всем, кто впервые затягивает обновленный проект.
если прописать путь до репозитория через git@git, а не https, то доступ будет без ввода пароля по ssh ключу.
До сих пор обхожу SPM стороной, на мой взгляд очень корявая вещь в плане скорости работы. Основной проект перевел на Carthage и оставил 10% на Cocoapods. Сборка проекта на СИ 1 минута 20 секунд для тестов. Когда открываешь проект то моментально можно работать, индексация кода происходит почти мгновенно.
Есть проект на SPM такого же размера, вот адище где, на СИ только spm resolve работает 3 минуты, что там так долго можно резолвить я до сих пор не понимаю, но собирает из кеша, что не плохо. Индексация проекта занимает колоссальное время потому что индексирует по-видимому все все сорцы засивимостей, я когда открываю проект просто ухожу на 10 минут пить кофе. AppCode и Xcode с SPM зависимостями съедает кучу оперативки в отличии от Carthage + SPM.
Thank you for writing in to GitHub Trust & Safety. I can confirm your repository has been reinstated after we identified its removal was made in error.
пс. Беру часть своих слов назад о гитхабе)) но всё равно пошел бекапить все репы в гитлаб и битбакет от греха подальше. Ждал полтора месяца их ответа.
Больше месяца жду ответа, пока не ответили. Запрашивал через официальную форму где прислали номер моего тикета и сказали ждите. Написали также так как у меня бесплатный аккаунт то ждать в общей очереди. На reddit видел подобные посты, там в комментариях писали, что ждать ответа от полугода приходилось. Как ответят дополню, что в итоге получилось.
Гитхаб это помойное ведро. 10 лет инвестируешь в него, создаешь проекты, участвуешь в комьюнити (ищешь проблемы в других проектах, заводишь issue), а в один прекрасный день без объяснения причины удаляют твой аккаунт без возможности даже скачать свои старые проекты которые никогда не бекапил так как верил, что гитхаб никогда такого не сделает, и несколько месяцев не отвечают на вопрос почему удалили, чистое свинство. Просто взяли и 10 лет моей работы удалили.
Так зачем делать аналитику, можно просто открыть график 4 года назад и понять почему эфир растет, биток подходит к концу цикла, альта начинает оживать. По фибо эфир вырастет до 12к-16к к зиме.
Нас кажется дизайнеры заставили убрать inputType=password так как им не нравится системный компонент ввода пароля и пришлось рисовать свой на обычном текст компоненте, долго спорили но в конце концов дизайнеры > разрабов как бы это грустно не звучало. Но было давно, может и вернули обратно чтобы поднималась системная форма автоввода пароля из keychain. Речь про iOS в моем примере.
Исторически сложилось так, что после халвинга биткоина, который произошел в апреле 2024 года, обычно следует период бычьего рынка, который может длиться от 12 до 18 месяцев. Если следовать этому паттерну, то медвежий рынок для биткоина может начаться в конце 2025 года или даже в 2026 году.
Цикл это очень простой пример. Я говорю про более сложные сценарии. Например недавно писал код ViewModel где есть 10 строковых (string type) публичных полей. В проекте MVVM архитектура (наверное), где у каждой ViewModel есть View, которая читает и рисует свойства с ViewModel. После того как я написал ViewModel и переставил курсор под конец класса ViewModel и начал писать (хотел начать писать класс для View для работы с ViewModel) "class " мне AI по табу написал класс View где сам заинжектил и ViewModel и написал код считывания полей с ViewModel, условно нагенерил строк 20-50 за несколько кликов по табу (клик по табу значит продолжить генерацию). Но разумеется я немного правил генеренный код, потому что от части код был обобщенный на основе всех соседних View.
Каждые 4 года одинаковое поведение его не удивило, а это удивило, капец эксперты.
что происходит. Я узнал про эту игрушку недавно когда в автомате китаянке не хватило игрушки и она сбросилась с высоты. Рядом наблюдаю pop-mart кажется магазин где ее продают, очереди постоянно, даже охрана стоит на случай месива. Нар**та наверное меньше прибыли приносит чем это поделие. В каком мире мы живет))
Реально видел такое в Малайзии. Чувак разложил iPad, ноут и внешнюю клаву. Насколько помню таких было несколько человек в один момент. Я думал эта шутка какая-то, так как редко хожу с СБ.
У нас тоже скелетон в пару строк просто анимация цветов с слабо серого до сильно серого. Можно использовать view builder чтобы убрать AnyView, он сам каждую бранчу завернет в нее автоматом.
Еще вспомнил, чем нам SPM колеса вставлял. Мы в одной тяжелой репе сделали SPM зависимость и ее подключали в проекта в другой репе. Так как репа либы весила 1 Гб, то SPM не только первый раз ее выкачивал полностью, а вообще всегда ее выкачивал, то есть почти на любой чих он качал 1 Гб что примерно занимало ожидание в 10 минут при открытии проекта. Cocoapods один раз скачивал и потом просто докачивал репу и ресетился на нужный коммит/версию. Когда мы с помощью специальной тулы убрали из репы тяжелые файлы то Cocoapods как полагается скачивал репу мгновенно, но SPM особенный и клонит репу с --mirror флагом вместо shallow (https://github.com/swiftlang/swift-package-manager/issues/6062), что запрашивает с сервера гита из кеша, то есть в нашем случае он снова скачивала удаленные бинарники на 1 Гб. Пришлось писать git core team чтобы они дропнули всё из кеша гита нашего репозитория.
Нужно смотреть как прописаны версии зависимостей, насколько строго или свободно (https://guides.cocoapods.org/syntax/podfile.html#pod), поидее в Podfile.lock прописаны финальные версии на что зарезолвил cocoapods. Согласен, беда когда коллизия версий происходит.
по идее есть причем. SPM положил код в основной бинарник, а Cocoapods в виде динамики. Когда рантайм запустился то одна и та же функция есть в 2х местах и не известно что из них будет использовано. То есть нужно перестраивать или spm или cocoapods чтобы убрать warning. Но вы правы это всего лишь варнинг, и в нем нет ничего страшного если знать что он значит. Но я когда такое видел в консоли то не могу такое терпеть ибо не по феншую, я просто на cocoapods post install правил проект чтобы их убрать.
Спасибо! Я сначала не понял зачем это всё сделано. Потом прочитал книгу по расту и там такое поведение по умолчанию и тогда сложилась картина.
вспомнил, у нас давно тоже была библиотека только под интел, а с проектом уже работали на новых силиконах. Так вот, если в проекте есть либа под интел (x86_64), то и весь проект насколько помню будет собираться под интел и запускаться приложение на симуляторе будет через трансляцию Rosseta. Посмотрите в Xcode Build логах под какую архитектуру он собирает проект под симулятор при отсутствии либы под натив ?
У вас Alamofire положен в виде динамической библиотеки в бандл приложения, скорее всего Cocoapods это сделал если не указано явно в Podfile static linkage. А SPM с недавних пор стал ликовать статично (в бинарник). Первое что приходит в голову это подправить возможно в Podfile чтобы после pod install этой либе прописывалась weak_framework или что-то подобное, но скорее всего да придется лезть еще глубже.
У меня тоже была подобная проблема, когда часть зависимостей ушли в Carthage, но часть зависимостей осталась в Cocoapods и им нужны эти Carthage либы. Пришлось форкать и править podspec чтобы этих зависимостей не было в podspec, а на pod install для этих зависимостей прописывать зависимости на Carthage. Но это того стоило, у нас как только RxSwift и его обвязка ушла в Carthage сразу стало на минуту быстрее собираться минимум. А когда ушли все гугловые либы так еще много минут ушло и из компиляции и индексации так как гугловый Firebase тянет за собой тонну сишных либ, один только grpc либа собирается пару минут.
x86_64 это симулятор под интел процессор, на силиконе уже идет под натив тоже arm64.
если прописать путь до репозитория через git@git, а не https, то доступ будет без ввода пароля по ssh ключу.
До сих пор обхожу SPM стороной, на мой взгляд очень корявая вещь в плане скорости работы. Основной проект перевел на Carthage и оставил 10% на Cocoapods. Сборка проекта на СИ 1 минута 20 секунд для тестов. Когда открываешь проект то моментально можно работать, индексация кода происходит почти мгновенно.
Есть проект на SPM такого же размера, вот адище где, на СИ только spm resolve работает 3 минуты, что там так долго можно резолвить я до сих пор не понимаю, но собирает из кеша, что не плохо. Индексация проекта занимает колоссальное время потому что индексирует по-видимому все все сорцы засивимостей, я когда открываю проект просто ухожу на 10 минут пить кофе. AppCode и Xcode с SPM зависимостями съедает кучу оперативки в отличии от Carthage + SPM.
Как только понадобится SPM зависимость буду интегрировать через Scipio https://github.com/giginet/Scipio
Спасибо за статью! чем больше читаю про SPM тем больше понимаю ну его к черту))
Это какая-то магия, но сработало. Восстановили.
пс. Беру часть своих слов назад о гитхабе)) но всё равно пошел бекапить все репы в гитлаб и битбакет от греха подальше. Ждал полтора месяца их ответа.
Больше месяца жду ответа, пока не ответили. Запрашивал через официальную форму где прислали номер моего тикета и сказали ждите. Написали также так как у меня бесплатный аккаунт то ждать в общей очереди. На reddit видел подобные посты, там в комментариях писали, что ждать ответа от полугода приходилось. Как ответят дополню, что в итоге получилось.
Гитхаб это помойное ведро. 10 лет инвестируешь в него, создаешь проекты, участвуешь в комьюнити (ищешь проблемы в других проектах, заводишь issue), а в один прекрасный день без объяснения причины удаляют твой аккаунт без возможности даже скачать свои старые проекты которые никогда не бекапил так как верил, что гитхаб никогда такого не сделает, и несколько месяцев не отвечают на вопрос почему удалили, чистое свинство. Просто взяли и 10 лет моей работы удалили.
Так зачем делать аналитику, можно просто открыть график 4 года назад и понять почему эфир растет, биток подходит к концу цикла, альта начинает оживать. По фибо эфир вырастет до 12к-16к к зиме.
Нас кажется дизайнеры заставили убрать inputType=password так как им не нравится системный компонент ввода пароля и пришлось рисовать свой на обычном текст компоненте, долго спорили но в конце концов дизайнеры > разрабов как бы это грустно не звучало. Но было давно, может и вернули обратно чтобы поднималась системная форма автоввода пароля из keychain. Речь про iOS в моем примере.
Что интересно даже Гугл так же считает
)) Если исходить из 16 летней истории битка то после ноября-декабря этого года начнется медведка на 4-6 лет.
Так логично, он же по фибе растет, давно уже известно до куда будет расти и когда начнет падать. Блогеры аналитики уже давно всё расчитали.
Цикл это очень простой пример. Я говорю про более сложные сценарии. Например недавно писал код ViewModel где есть 10 строковых (string type) публичных полей. В проекте MVVM архитектура (наверное), где у каждой ViewModel есть View, которая читает и рисует свойства с ViewModel. После того как я написал ViewModel и переставил курсор под конец класса ViewModel и начал писать (хотел начать писать класс для View для работы с ViewModel) "class " мне AI по табу написал класс View где сам заинжектил и ViewModel и написал код считывания полей с ViewModel, условно нагенерил строк 20-50 за несколько кликов по табу (клик по табу значит продолжить генерацию). Но разумеется я немного правил генеренный код, потому что от части код был обобщенный на основе всех соседних View.