Здравствуйте, Sinclair, Вы писали:
S>Ну, идея писать приложения ровно на той же платформе, что и исполнять их, устарела уже лет двадцать как.

Кросс-компиляция в первую очередь необходима для встраивальщины (т.е. либо очень слабые вычислительные мощности целевой платформы, либо нет периферии, удобной для разраба).
Эппловский M1/2 — это не тот случай, и ЕМНИП даже уделывал тогдашних топов мобильных интелов, ну а с т.з. периферии ноут он и есть ноут.

Здравствуйте, Sinclair, Вы писали:

S>Решение с удалённым запуском компиляции на устройстве мне понятно. Но оно не требует наличия на устройстве студии и всего девеломпент стека.

Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна. Но при необходимости, VS Code умеет быть установленным у разработчика и по ssh работать с удалённым устройством. То есть там нужен просто тулчейн.

S>Вот, скажем, мне не составляет никакой проблемы покупать молоко в разных магазинах. Но это не означает, что я искусственно буду заставлять себя чередовать эти магазины.

Вот, я смотрю на твой путь примерно также: зачем тебе на одном компе агрегировать сразу всё? Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение. Сделаю свою часть, отлажусь, напишу тесты, проверю и отдам дальше.

S>Вот это хотелось бы как-то обосновать. Если одно устройство компилирует быстрее, чем другое — надо всё компилировать на нём. Если можно распределить компиляцию на оба устройства — надо параллелить.

Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём. Ну ещё зависит от того, насколько оно доступно, конечно. Если оно одно на большую команду (такое тоже бывает), то все работают у себя.

S>Если одно устройство обладает более отзывчивым/просторным/хорошим гуём, то редактировать код надо на нём.
S>Потому что скорость разработки = скорости цикла "протестировал — исправил — скомпилировал". Соответственно, выбираем то, на котором эти шаги быстрее.

Можно по разному:
1. можно всё делать на нём;
2. можно редактировать по сети, но исходники и тулчен на устройстве;
3. можно всю сборку делать у себя, деплоить бинарники на девайс и там запускать тесты;
4. можно работать с эмулятором и совсем без устройства.

S>Здесь явно подразумевается, что приложения под ARM нужно и разрабатывать, сидя под ARM. И вы продолжаете агитировать в ту же сторону, хотя утверждаете, что вроде как нет.

И да, и нет. Если есть шанс разрабатывать на АРМ — прекрасно и великолепно, это самый простой путь и его лучше сделать.

Здравствуйте, CreatorCray, Вы писали:

P>>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути
CC>Мда, и опять выходит что винда лучше линух чем сам линух
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

Здравствуйте, Pauel, Вы писали:

P>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд.

Ес-но.
Еще удалённым дебаггером на девайсе, потребляющим минимум ресурсов.

Здравствуйте, Dair, Вы писали:

D>А в чём проблема код на C собрать под другую платформу?

Ну дьявол, как обычно, в деталях. Наверняка без ассемблерных вставок и пр. низкоуровневого не обошлось.

Здравствуйте, Serginio1, Вы писали:

P>>В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него
S> Это как? Ты отлаживаешь ровно так же как на своем компе. Какие проблемы?

Проблема в том, что на удаленный комп вы заходите ничтожную часть времени, вы там не сидите 100% времени, не инсталируете всякий хлам.
У меня, например, сколько ни работал, удаленный комп работает как часы — там все чистенько, стерильно, быстро и аккуратно.
У типичного пользователя никогда не бывает чистой и стерильной ОС — она всегда забита разного рода дрянью, которая дает разные эффекты.
Хотите быть ближе к типичному пользователю — избегайте отладки в чистой и стерильной ОС.

S>Чем удаленная отладка по Tcp/IP сильно отличается от отладки на компе.

Вы вообще читаете? Я пишу про то, где должен работать разработчик основную часть времени, а не про протокол, отладчик или компилятор.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, Serginio1, Вы писали:

P>>>В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него
S>> Это как? Ты отлаживаешь ровно так же как на своем компе. Какие проблемы?

P>Проблема в том, что на удаленный комп вы заходите ничтожную часть времени, вы там не сидите 100% времени, не инсталируете всякий хлам.
P>У меня, например, сколько ни работал, удаленный комп работает как часы — там все чистенько, стерильно, быстро и аккуратно.
P>У типичного пользователя никогда не бывает чистой и стерильной ОС — она всегда забита разного рода дрянью, которая дает разные эффекты.
P>Хотите быть ближе к типичному пользователю — избегайте отладки в чистой и стерильной ОС.
Так используй рабочий комп. Обычно удаленная отладка используется для обнаружения проблем на удаленном компе.
Те же девайсы тоже рабочие, на которых возникают проблемы.
S>>Чем удаленная отладка по Tcp/IP сильно отличается от отладки на компе.

P>Вы вообще читаете? Я пишу про то, где должен работать разработчик основную часть времени, а не про протокол, отладчик или компилятор.
У меня как раз удаленная отладка там где есть проблемы. Обычно и эмуляторов хватает.
И комп разработчика ооочень сильно отличается от рабочего варианта!

Опять же куча версий того же андроида, оборудования. Как и линукса.
На всех на них студию устанавливать?

Здравствуйте, Shmj, Вы писали:

S>Вопрос такой.

S>Вроде Xcode — это гигант, даже судя по размеру бинарников. Как так быстро смогли перевести под ARM?

А ты уверен, что быстро? слухи о переходе появились в 2011 году. То бишь это заняло около 10 лет. А может и больше. Не очень-то быстро.

S>Ну и главное — сможет ли MS сделать так же со своей VS или там все намного хуже?

Всё упирается в деньги. Захотят инвестировать — смогут. Может уже и делают. Хотя у меня складывается впечатление, что MS инвестирует в VS Code, а старую студию выкинут в какой-то момент. Странно тянуть две IDE.

Здравствуйте, Shmj, Вы писали:

D>>А в чём проблема код на C собрать под другую платформу?
S>Ну дьявол, как обычно, в деталях. Наверняка без ассемблерных вставок и пр. низкоуровневого не обошлось.

Ну, CreatorCray не расскажет потому что NDA, но даже если они там есть, то в чём проблема их переписать? Это всего лишь какое-то потраченное время на разработку.

Здравствуйте, Pauel, Вы писали:

P>Если вы пользуетесь для своих целей, то это очень круто. Но вобщем большинство разработчиков так не делают — надеются на QA
Когда работал в компании с мобильным продуктом — делал. Мне до сих пор нотификации про новые сборки приходят

P>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе.
Повторю очевидное: девелоперы могут хоть обсидеться на "той платформе". Вопрос не в том, в чём они девелопят. Если это фотошоп — то шрифты в нём так и продолжат дрожать, т.к. в студии у них всё отлично.

P>Не только студию, а большие десктопные приложения или приложения требовательные к ресурсам.
Я по-прежнему не понимаю, чем фотошопу под АРМ поможет написание исходников фотошопа под АРМом. Или, скажем, CAD-системе. Оба — большие, ресурсоёмкие приложения. Ну и что?

P>Дело не в том, где вы студию запускаете, а где разработчик проводит бОльшую часть времени.
Ну да, в студии он его и проводит. А где ещё? Он же разработчик.

P>Я собственно про догфудинг если правильно этот термин понимаю, а не самого компилятора.
Ну так вот догфудинг строго ортогонален тому месту, где бегает студия. Догфудинг означает "самостоятельное использование продукта авторами этого продукта".
Например, парням из Microsoft было запрещено пользоваться Вебексом. Были обязаны проводить конференции только через Lync.

Здравствуйте, Nuzhny, Вы писали:
N>Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна. Но при необходимости, VS Code умеет быть установленным у разработчика и по ssh работать с удалённым устройством. То есть там нужен просто тулчейн.
Ну, и я примерно о том же.

N>Вот, я смотрю на твой путь примерно также: зачем тебе на одном компе агрегировать сразу всё? Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение. Сделаю свою часть, отлажусь, напишу тесты, проверю и отдам дальше.
Может у вас оно так и работает. Но это вы наверное просто заранее готовы прогнуться под любой тулчейн и окружение. А в моём мирке у разработчиков разные предпочтения. Один пользуется VS Code, другой VS Professional, третий всё пишет в vi, четвёртому жизнь не мила без Notepad++. И тут мы приносим устройство, на котором стоит что-то не то, к чему разработчик привык.

Вы, судя по всему, говорите об удалённой отладке — когда весь шелл стоит локально на машине, и, скажем, на stackoverflow пользователь ходит по привычным закладкам.
А то, с чем я спорил — это именно работа внутри студии на целевой машине. Которая, к примеру, может вообще наружу выхода не иметь, ибо зачем? И там даже на гитхаб сходить — уже проблема. Зато воспроизводится проблема, которую нужно проанализировать. Ну, вот как раз ssh и вперёд. Для него никакая студия на той стороне не нужна.

N>Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём. Ну ещё зависит от того, насколько оно доступно, конечно. Если оно одно на большую команду (такое тоже бывает), то все работают у себя.

N>Можно по разному:
N>1. можно всё делать на нём;
N>2. можно редактировать по сети, но исходники и тулчен на устройстве;
N>3. можно всю сборку делать у себя, деплоить бинарники на девайс и там запускать тесты;
N>4. можно работать с эмулятором и совсем без устройства.

S>>Здесь явно подразумевается, что приложения под ARM нужно и разрабатывать, сидя под ARM. И вы продолжаете агитировать в ту же сторону, хотя утверждаете, что вроде как нет.

N>И да, и нет. Если есть шанс разрабатывать на АРМ — прекрасно и великолепно, это самый простой путь и его лучше сделать.
Наверное, у меня мозг искажён мультиплатформенностью, в которой "приложений для ARM" не существует, а существуют продукты, которые должны работать на нескольких аппаратных платформах и под разными ОС.
Тогда прыгать между виндой/линуксом/ARM/Intel просто заради фана кажется неэффективным.

Если предстоит длинный проект, который ARM-only — то да, временно переехать на другую платформу будет оправдано, согласен.
Но это опять же при условии, что там есть всё, что нужно. А при отсутствии там, скажем, Visual Studio, можно продолжать работать по ssh.

Подозреваю что, так как Apple изначально все было на powerpc и лишь потом они с большим успехом перешли на intel, то они спецы в процессах перехода с одной платформы на другую. Может архитектуру многоплатформенную еще тогда во все свои продукты заложили, может тупо записали все ходы. Поэтому переход на ARM по накатанной. А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет и поэтому никуда они не перейдут. Уже было пытались пару раз но что-то все заканчивалось провалами.

Здравствуйте, qqqqq, Вы писали:

Q>А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет и поэтому никуда они не перейдут.
?
какой-то бред, arm64 версия винды уже давно доступна. Да и вообще — HAL придумали именно в МС, когда у них была powerPc версия NT4 а это на секунду 1996й год

Q> Может архитектуру многоплатформенную еще тогда во все свои продукты заложили, может тупо записали все ходы
Да нет в юзермоде никакой архитектуры многоплатформенной. Вся архитектура — не писать на асме, а если уж захотелось пописать оптимизации ради местами — оставлять дефолтовые реализации на сишке. Но я очень сомневаюсь что в Xcode есть чтото, написанное на асме.
В остальном, в случае одинаковой endianess и битности платформ (а тут ниче не менялось), все просто компилируется в другой проц, после чего фиксятся сколлапсировавшие гейзенбаги и вуаля.

Q> А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет
Винда по многоплатформенности всегда была впереди планеты всей.

не договариваешь
_>arm64 версия винды уже давно доступна
...и нахрен никому не нужна. Ты много устройств таких видал? В том то и дело что когда самый главный начальник в микрософте вызывает на ковер и говорит что за хрень? почему у компании Х есть такая вот вещь а у нас нет, то в дело бросются мульены, засучиваются рукава по локоть, таки выдают на гора аналог и отчитываются. Но оказывается что вещь не такая уж и вещь и все так и продолжают пользоваться Х.

Здравствуйте, Nuzhny, Вы писали:

N>Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна.
После того как попользуешься профессиональным гайковёртом с регулируемым усилием как то совсем не хочется возвращаться к простому гаечному ключу без крайней на то нужды.

N>VS Code
ужасен

N>Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение.
Интересные у тебя устройства, на которых сразу и toolchain и окружение, и поди весь нужный SDK на гигабайты сразу тоже там лежит?

N>Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём.
Как правило у девелопера не то чтобы сильно более дохлая машина чтоб это имело совсем настолько существенную разницу.
Больше смысла работать на уже настроенном окружении, где всё что надо уже гарантированно есть.
Поэтому у меня нет разницы что я дебажу — новую beefy mac studio или старые часы с одним гигом памяти. Просто дебаг probe перетыкаешь в другой девайс и всё.

Здравствуйте, Pauel, Вы писали:

P>У Микрософта это традиция — приобщиться к конкурентам, и переделывать под себя.
И совершенно правильно делают между прочим

Здравствуйте, Pauel, Вы писали:

P>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе.
И как тебе тут поможет запуск студии на именно этой же машине?

P>Про догфудинг — проверял тушенку для кота на себе, жена не успевала покупать
Ты зачем котэ объедаешь?

Здравствуйте, Sinclair, Вы писали:

S>Например, парням из Microsoft было запрещено пользоваться Вебексом. Были обязаны проводить конференции только через Lync.
Ох, соболезную им! Лютое говно этот Lync

Здравствуйте, CreatorCray, Вы писали:

CC>Ох, соболезную им! Лютое говно этот Lync
Подозреваю это старые сведения, Lync скорее всего уже похоронен и сейчас лютое говно это teams.