Здравствуйте, Cyberax, Вы писали:
C>А зачем? Чтобы фапать на один экзешник?
Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ops, Вы писали:
I>>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Рекурсивное создание фолдера еле родили. И то, не сильно в этом уверен. Как только начинаешь бороться с путями, файлами, фолдерами, сразу хочется перебить всех системщиков в округе. Одна функция умеет одни пути, другая — другие. Одна умеет рекурсивные фолдеры, другая не умеет. Одна может работать с длинными путями, другая не может. Рокет саенс, не иначе.
Ops>И как же hg вместе с черепахой умудряется в 90М помещаться?
hg на питоне написан, у них искаропки внятный апи доступен.
Здравствуйте, CreatorCray, Вы писали:
I>>Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность. CC>"Выиграла" идея организации репы, имплементация же отвратительна.
I>>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. CC> Щито? После виндового API на мешанину позикса без рвотных позывов смотреть нельзя.
Покажи, как создать рекурсивно фолдер без доп либ, так что бы для всех версий винды работало начиная где то с XP, с любыми путями, сетевыми папками, русскими буквами, длинные, короткие пути и тд.
Вот почти что идеальный вариант:
exec(`mkdir -p ${path}`)
В таком подходе небольшая либа, которая покрывает еще сотню кейсов такой же сложности, пишется на коленке от силы за день и работает чуть не на всех платформах.
I>> Рекурсивное создание фолдера еле родили. CC>О боги, rocket science! Без подгузников прикладники не в состоянии из готовых кубиков этот примитив сделать?
И снова пальцы веером Попробуй что ли денек или хотя бы пару часов без понтомёта пожить ?
Собственно такое отношение у многих системщиков, потому в винде и нет нормального файлового АПИ.
Мне, скажем, надо вызвать пару функций при старте приложения, создать, скопировать, удалить и тд.
Вместо секундной задачи "проимпортировать функцию и вызвать", все превращается в квест — что импортировать в какой версии винды, какие пути формировать, как управлять памятью и тд и тд.
Простой бутстраппер, в котором полезная функция делается в две-три строчки, вырастает в небольшое приложение где 99% кода приседания со строками, путями, файлами, фолдерами.
I>>Как только начинаешь бороться с путями, файлами, фолдерами CC>О чём ты?
Всё о том же.
I>>Одна функция умеет одни пути, другая — другие. CC>Например? I>>Одна может работать с длинными путями, другая не может. CC>Например?
Просто для примера: https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-removedirectoryw
MAX_PATH до сих пор актуален, по факту.
I>>>>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов CC>>>Потому что у его авторов руки из адских глубин жопы. I>>Намекаешь, что смог бы лучше? CC>Да.
Многие так думают. А реально для кроссплатформенного приложения углубляться в апи какой нибудь из систем смысла большого нет, более того, это убыток в чистом виде. Проще построить работу вокруг готового кроссплатформенного апи. И вот это готовое кроссплатформенное апи есть, при чем совсем не в том виде, как тебе нравится.
Здравствуйте, CreatorCray, Вы писали:
I>>А потому, что код длл один на все экзешники, а влинкуешь статически — по одному в каждом. CC>Ещё раз напоминаю, exeшник должен быть один.
Еще раз, для системщиков, exel, word, powerpoing и тд — разные приложени, по одному экзешнику на каждый.
А это значит, что куча общего кода, коего около 80-90%, будет вгружаться в каждый из запущеных процессов.
В норме таких приложений открыто несколько, а значит и расход памяти будет соответсвующий.
Здравствуйте, Ops, Вы писали:
Ops>·>Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут. Ops>Ну вот смотри, самое простое: сервер послал сначала малополезный на этапе отрисовки скрипт, а потом только стили, в результате отрисовка началась позже, на время передачи скрипта.
А что это за кейс такой, слать малополезный скрипт игнорируя приоритеты UI ?
Здравствуйте, CreatorCray, Вы писали:
C>>А зачем? Чтобы фапать на один экзешник? CC>Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом.
А это никакая не проблема. Это у тебя особое видение и эмоции. Какую конкретно проблему ты хочешь решать таким способом ?
Вот разрабы гита понятно чего добивались, а чего ты хочешь добиться окромя как "должно быть один экзешник это круто, потому что иначе некруто"
Здравствуйте, CreatorCray, Вы писали:
C>>А зачем? Чтобы фапать на один экзешник? CC>Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом.
А какие проблемы с ним? Лежит себе и лежит.
Ну да, я знаю, что в Винде фейловый стек местами в сотни раз тормознее Линуксового. Но таки git всё же не такой уж большой.
Здравствуйте, Ikemefula, Вы писали:
I>А это никакая не проблема. Это у тебя особое видение и эмоции. Какую конкретно проблему ты хочешь решать таким способом ?
Ты сам ее выше озвучивал — размер дистрибутива.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>·>Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут. Ops>Ну вот смотри, самое простое: сервер послал сначала малополезный на этапе отрисовки скрипт, а потом только стили, в результате отрисовка началась позже, на время передачи скрипта.
А зачем сервер так сделал? Что ему помешало послать стили в начале?
В случае http1 — этому мешает браузер и сеть — когда и куда какие запросы пойдут — никак не контролируется, да ещё и несколько сокетов в параллель канал забивают. В случае http2 сервер может сам принимать решения.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
CC>·>К тому же, сейчас применяют data:-урлы, которые раздувают объём и замедляют отрисовку. CC>Сейчас "дезихнеры" шрифты в base64 в CSS запихивают — вот за что надо конечности обрубать по самую жопу.
Поинтересуйся зачем вначале, прежде чем очередную глупость заявлять.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
I>>Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб. CC>У меня в D:/Soft/Office нашлось 6 exeшников: excel.exe, msohtmed.exe, ois.exe, proflwiz.exe, winword.exe, msohelp.exe CC>Я поставил только то, чем пользовался и уже сто лет не запускал.
Странный у тебя офис. У меня всего 93 .exe, из них 41 .exe и 217 .dll в "C:\Program Files\Microsoft Office\root\Office16":
AppSharingHookController64.exe
CLVIEW.EXE
CNFNOT32.EXE
EXCEL.EXE
excelcnv.exe
GRAPH.EXE
IEContentService.exe
lync.exe
lync99.exe
lynchtmlconv.exe
misc.exe
msoev.exe
MSOHTMED.EXE
msoia.exe
MSOSREC.EXE
MSOSYNC.EXE
msotd.exe
MSOUC.EXE
MSQRY32.EXE
NAMECONTROLSERVER.EXE
OcPubMgr.exe
officebackgroundtaskhandler.exe
OLCFG.EXE
ONENOTE.EXE
ONENOTEM.EXE
ORGCHART.EXE
OUTLOOK.EXE
PDFREFLOW.EXE
PerfBoost.exe
POWERPNT.EXE
PPTICO.EXE
protocolhandler.exe
SCANPST.EXE
SELFCERT.EXE
SETLANG.EXE
UcMapi.exe
VPREVIEW.EXE
WINWORD.EXE
Wordconv.exe
WORDICON.EXE
XLICONS.EXE
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
CC>>Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом. C>А какие проблемы с ним? Лежит себе и лежит.
C>Ну да, я знаю, что в Винде фейловый стек местами в сотни раз тормознее Линуксового. Но таки git всё же не такой уж большой.
Дело даже не в тормозах. Когда нужна небольшая утилитка, то вместо секундной задачи надо вдруг проходить квест по мега API.
Когда я писал на С++, мне такое было в кайф. А сейчас я пишу совсем другого уровня вещи и отвлекаться на низкий уровень никакой возможности нет.
Здравствуйте, Ops, Вы писали:
I>>Еще раз, медленно, hg написан на питоне, потому __вместо__ 600длл типа цыгвин, баш и тд, ты тащишь один питон.
Ops>Не хватает иксов и KDE. Маловат дистрибутив. Ops>Кстати, hg под виндой вроде даже питона не требует, там, кажись, все уже в exe скомпилено, а питон у меня для другого стоит
Похоже, что хг уже на расте пишут. Не знаю, какой там апи, похож на питоновский, или непохож.
Здравствуйте, Ops, Вы писали:
I>>А это никакая не проблема. Это у тебя особое видение и эмоции. Какую конкретно проблему ты хочешь решать таким способом ?
Ops>Ты сам ее выше озвучивал — размер дистрибутива.
И чем ты заменишь код скриптов, который уже нормально работает на всех платформах ?
Здравствуйте, ·, Вы писали:
I>>>Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб. CC>>У меня в D:/Soft/Office нашлось 6 exeшников: excel.exe, msohtmed.exe, ois.exe, proflwiz.exe, winword.exe, msohelp.exe CC>>Я поставил только то, чем пользовался и уже сто лет не запускал. ·>Странный у тебя офис. У меня всего 93 .exe, из них 41 .exe и 217 .dll в "C:\Program Files\Microsoft Office\root\Office16":
Да не, он просто конролирует каждую ножку у гусеницы и руками удаляет всё лишнее.