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

I>·>Странный у тебя офис. У меня всего 93 .exe, из них 41 .exe и 217 .dll в "C:\Program Files\Microsoft Office\root\Office16":
I>Да не, он просто конролирует каждую ножку у гусеницы и руками удаляет всё лишнее.
Зачем?

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

I>Похоже, что хг уже на расте пишут. Не знаю, какой там апи, похож на питоновский, или непохож.

Да хоть на чем, вообще пофиг. Главное, что его вполне осилили под винду без свалки говна.
Жаль что гит победил, хг куда более адекватные люди пилят.

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

N>Хм, интересная поставка. Что там в списке?
N>На Linux это всего 7 штук вместе с RTLD.

N>Или это вместе с реализацией GIT bash и GIT shell?

Там вот такое внутри:

• bin
  
• cmd
  
• dev
  
• etc
  
• mingw64
  
• tmp
  
• usr

N>Или это было не количество отдельных DLL, а какой-то другой прибор?

Именно DLL. Всего там разных файлов на ~500 метров.

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

C>>А зачем? Чтобы фапать на один экзешник?
CC>Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом.
Для работы гита, может и не нужна, но для работы — нужна.

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

I>>hg на питоне написан, у них искаропки внятный апи доступен.
Ops>Питон еще 140, в сумме 230. Все равно 600 не выходит.
git использует ntfs-хардлинки, для альясов. Например, "git.exe" имеет 127 хардлинков. И по факту занимает как раз столько же:

Folder "C:\soft\Git"
Folders:        712
Files:          5798
Files size:     600 MB
Allocated size: 257 MB (42%)

А с учётом, что функциональности у гита на порядок больше... ну его в топку этот ваш hg.

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

·>git использует ntfs-хардлинки, для альясов. Например, "git.exe" имеет 127 хардлинков. И по факту занимает как раз столько же:
·>

·>Allocated size: 257 MB (42%)
·>

Пусть, только вот выяснилось, что питон для hg под виндой не нужен, там все уже скомпилировано в exe, т.е. всего 90М вместе с черепахой

·>А с учётом, что функциональности у гита на порядок больше... ну его в топку этот ваш hg.

А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами, а для hg есть bitbucket.

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

Ops>·>Allocated size: 257 MB (42%)

Ops>Пусть, только вот выяснилось, что питон для hg под виндой не нужен, там все уже скомпилировано в exe, т.е. всего 90М вместе с черепахой
Тут скорее получается спор о том, что включено в поставку... По мне так полноценный шелл, подробная документация (сравни "hg help log" и "git help log"), и т.п. важнее черепахи. Всё равно нормальные IDE имеют лучшую интеграцию с vcs. А так при желании чисто git можно урезать до пары десятков мегов — вот только непонятно накой нужно.

Ops>·>А с учётом, что функциональности у гита на порядок больше... ну его в топку этот ваш hg.
Ops>А что не на 10 порядков?
Чтоб фанатам не так обидно было.

Ops>Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами, а для hg есть bitbucket.
bitbucket уже давно начал закапывать hg, тащут его в легаси режиме, и они сейчас ориентированы на git. Найди сколько раз встречается слова hg/mercurial на https://bitbucket.org/
Так что репо на bitbucket можно завести и с git. Плюс больше функциональности — git lfs, pr fetch — git only.
Кстати, совсем недавно github стал раздавать бесплатные приватные репы.

C>1) Head-of-line blocking. Если CSS будет в 10Мб, то придётся ждать пока он весь проедет. В HTTP2 потоки будут мультиплексированы в одном соединении.

Как я и написал, полезно использовать 2 соединения.

C>2) Оно используется только для GET-ов.

Это серьезное ограничение, ага...

C>3) Оно не работает: https://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_browsers

Вот это больше похоже на разумную причину. Есть веб сервера, которые не умеют pipelining, поэтому клиенты его не используют.

I>Скажем, если exec(`mkdir -p ${path}`) пишется за несколько секунд, то не совсем понятно, зачем пилить вот такое https://nachtimwald.com/2017/05/17/recursive-create-directory-in-c/

Тебе совсем не обязательно это "пилить", достаточно загуглить, скопировать, отредактировать. Для такой популярной задачи, как ты сказал, решения в изобилии водятся и интернете. Хотя, конечно, было бы удобнее, если бы оно было в самой библиотеке.

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

·>Тут скорее получается спор о том, что включено в поставку... По мне так полноценный шелл, подробная документация (сравни "hg help log" и "git help log"), и т.п. важнее черепахи.
В век интернета локальные html на компе разработчика, ты серьезно?
·>Всё равно нормальные IDE имеют лучшую интеграцию с vcs.
Но черепаха часто удобна.
·>А так при желании чисто git можно урезать до пары десятков мегов — вот только непонятно накой нужно.
Ну вот я бы именно такой ставил, но нет его.

·>Чтоб фанатам не так обидно было.
Ну т.е. по факту разницы почти нет.

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

I>>Скажем, если exec(`mkdir -p ${path}`) пишется за несколько секунд, то не совсем понятно, зачем пилить вот такое https://nachtimwald.com/2017/05/17/recursive-create-directory-in-c/

M>Тебе совсем не обязательно это "пилить", достаточно загуглить, скопировать, отредактировать.

Код, единожды внесенный в проект, нужно читать, тестировать и майнтейнить постоянно.
Каждый, кто залазит в проект, должен будет минимум раз познакомиться с этой рекурсией. Код по ссылке не учитывает кое каких кейсов, важных для проекта, опаньки, это г-но еще и дописывать надо, например, кавычки, пермишны и логирование.

Кроме того, здесь еще надо поприседать с линковкой, ибо проект кроссплатформенный, совсем как гит.

А вот одна строчка, как у меня, решает все проблемы. Дописывание занимает около нуля времени.

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

Таких мелочей, как у меня, надо под сотню для более-менее вменяемого приложения.

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

Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.

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

Ops>А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами, а для hg есть bitbucket.

И как это у меня на гитхабе все в привате лежит, чудо какое то....

Но вообще мне хг нравится больше гита.

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

Ops>·>Тут скорее получается спор о том, что включено в поставку... По мне так полноценный шелл, подробная документация (сравни "hg help log" и "git help log"), и т.п. важнее черепахи.
Ops>В век интернета локальные html на компе разработчика, ты серьезно?
Да это только под виндой так рисует, под линухом всё в порядке. Но собственно к сути претензий нет? К форме лишь придираешься?

Ops>·>Всё равно нормальные IDE имеют лучшую интеграцию с vcs.
Ops>Но черепаха часто удобна.
Для гита есть полно более удобных гуёвых клиентов, даже идущие в поставке gitk и git gui вполне неплохи. Черепаха хороша лишь для переезжающих с svn.

Ops>·>А так при желании чисто git можно урезать до пары десятков мегов — вот только непонятно накой нужно.
Ops>Ну вот я бы именно такой ставил, но нет его.
Зачем именно такой? Что это даст?

Ops>·>Чтоб фанатам не так обидно было.
Ops>Ну т.е. по факту разницы почти нет.
Был большой длинный спор по этому поводу. Вкратце, модель данных и хранилище git устроены более удачно для dvcs и это даёт больше возможностей. Для деталей — ищи флейм, я повторяться не буду.

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

I>А это значит, что куча общего кода, коего около 80-90%, будет вгружаться в каждый из запущеных процессов.
Это какого кода? Powerpoint и excel имеют не то чтобы сильно много общего внутри.

I>В норме таких приложений открыто несколько, а значит и расход памяти будет соответсвующий.
Ты можешь запустить хоть 100 вордов но бинарь в памяти будет ровно один.

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

·>Поинтересуйся зачем вначале, прежде чем очередную глупость заявлять.

Мудаки потому что.
Я с такими борюсь, потому что шрифты, которые они с собой приносят выглядят отвратительно.

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

I>Покажи, как создать рекурсивно фолдер без доп либ, так что бы для всех версий винды работало начиная где то с XP, с любыми путями, сетевыми папками, русскими буквами, длинные, короткие пути и тд.
Банальный рекурсивный спуск по строке пути до реально существующего path, и CreateDirectoryW на обратном пути

I>В таком подходе небольшая либа, которая покрывает еще сотню кейсов такой же сложности, пишется на коленке от силы за день и работает чуть не на всех платформах.
Какая ещё нахрен либа? Одна функция на десяток строк.

I>И снова пальцы веером Попробуй что ли денек или хотя бы пару часов без понтомёта пожить ?
Да потому что это детская задачка.
Ты какие то настолько смешные примеры приводишь что я вообще сомневаюсь что ты всерьёз.

I>Собственно такое отношение у многих системщиков, потому в винде и нет нормального файлового АПИ.
Конкретика хоть какая то будет наконец?

I>Мне, скажем, надо вызвать пару функций при старте приложения, создать, скопировать, удалить и тд.
Какие?

I>Вместо секундной задачи "проимпортировать функцию и вызвать", все превращается в квест — что импортировать в какой версии винды, какие пути формировать, как управлять памятью и тд и тд.
У меня есть суровые подозрения что ты вообще не знаешь какие API есть у винды и как они работают.

I>>>Как только начинаешь бороться с путями, файлами, фолдерами
CC>>О чём ты?
I>Всё о том же.
А конкретно?

I>https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-removedirectoryw
I>MAX_PATH до сих пор актуален, по факту.
Мда, и почему я не удивлён...
Все кто в теме используют строго *W функции с \\?\ путями.
Если ты вызываешь legacy API — ССЗБ.

I>Проще построить работу вокруг готового кроссплатформенного апи. И вот это готовое кроссплатформенное апи есть, при чем совсем не в том виде, как тебе нравится.
Говно и палки, говно и палки...

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

I>Вот разрабы гита понятно чего добивались, а чего ты хочешь добиться окромя как "должно быть один экзешник это круто, потому что иначе некруто"
Хочу чистоту и порядок. Говно и палки не люблю.

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

I>И чем ты заменишь код скриптов, который уже нормально работает на всех платформах ?
Бинарным кодом, будьте так любезны.

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

I>Скажем, если exec(`mkdir -p ${path}`) пишется за несколько секунд
И является чуть ли не классическим примером говнокода.

I> то не совсем понятно, зачем пилить вот такое https://nachtimwald.com/2017/05/17/recursive-create-directory-in-c/
Там всё страшно потому что на С и рукопашка со строками.

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

I>А вот одна строчка, как у меня, решает все проблемы.
Эта строчка сама по себе проблема.
Такой же говнокод как и тут: Минутка с-юмора

Автор: ononim
Дата: 16.01.19

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

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