Тут были как то утверждения, что де эффекта нету от HTTP2 и все такое. На самом деле выходит, что эффект в полный рост, до десятикратного ускорения в разных условиях.
Здравствуйте, kov_serg, Вы писали:
_>С такими то тестами можно получить любой желаемы эффект.
Просто как пример: Если запустить тот же Grafana с http и http2 эфект ускорения UI сильный и заметен даже безо всяких тестов.
При грамотно постороенной delivery pipeline, http2 ничего не стоит кроме однократной работы DevOps-а на пару часов. Поэтому вывод однозначный — использовать.
Здравствуйте, Ikemefula, Вы писали:
I>Тут были как то утверждения, что де эффекта нету от HTTP2 и все такое. На самом деле выходит, что эффект в полный рост, до десятикратного ускорения в разных условиях.
1000: Loading 1000 small (819 bytes each) JavaScript files, simulating no concatenation.
"Опустим газету в серную кислоту а HTTP2 в дистилированную воду" (С)
Здравствуйте, Ikemefula, Вы писали:
I> Тут были как то утверждения, что де эффекта нету от HTTP2 и все такое. I> На самом деле выходит, что эффект в полный рост, до десятикратного ускорения в разных условиях.
При хорошо сделанном сайте эффект от http/2 на грани погрешности измерений. Для плохо сделанных сайтов задействовать хорошие инструменты измерения затруднительно (и затратно), а доступные инструменты так же не будут показывать особого профита.
Но это никак не отменяет того, что http/2 нужен, полезен и должен внедряться. Правда ускорения нынче достигаются другими крутилками.
P.S. Твоя ссылка от 2016 года. С тех пор сильно много воды утекло через этот ручей.
Здравствуйте, Anton Batenev, Вы писали:
AB>При хорошо сделанном сайте эффект от http/2 на грани погрешности измерений. Для плохо сделанных сайтов задействовать хорошие инструменты измерения затруднительно (и затратно), а доступные инструменты так же не будут показывать особого профита.
Только придется долго-долго приседать, что бы добиться такого же эффекта на http.
CC>>1000: Loading 1000 small (819 bytes each) JavaScript files, simulating no concatenation.
CC>>"Опустим газету в серную кислоту а HTTP2 в дистилированную воду" (С) I>В тестах http и http2 гоняют в одинаковых условиях — количество файлов и тд.
Как зовут того невменяйко, у которого на проде 1000 JS файлов по 800 байт?
Здравствуйте, Ikemefula, Вы писали:
I> AB>При хорошо сделанном сайте эффект от http/2 на грани погрешности измерений. Для плохо сделанных сайтов задействовать хорошие инструменты измерения затруднительно (и затратно), а доступные инструменты так же не будут показывать особого профита. I> Только придется долго-долго приседать, что бы добиться такого же эффекта на http.
Да ладно, было бы желание — нет там ничего такого. С HTTP/2 точно так же придется поприседать для достижения (наи)лучшего результата разве что в других местах.
CC>>>1000: Loading 1000 small (819 bytes each) JavaScript files, simulating no concatenation.
CC>>>"Опустим газету в серную кислоту а HTTP2 в дистилированную воду" (С) I>>В тестах http и http2 гоняют в одинаковых условиях — количество файлов и тд.
НС>Как зовут того невменяйко, у которого на проде 1000 JS файлов по 800 байт?
В статьях про http2 по сей день хором пишут, что де ручной бандлинг ни разу не нужен, можно без него.
Оказывается, это не так. И далее, сравнение, http2 и http, что было, что стало.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Ikemefula, Вы писали:
I>> AB>При хорошо сделанном сайте эффект от http/2 на грани погрешности измерений. Для плохо сделанных сайтов задействовать хорошие инструменты измерения затруднительно (и затратно), а доступные инструменты так же не будут показывать особого профита. I>> Только придется долго-долго приседать, что бы добиться такого же эффекта на http.
AB>Да ладно, было бы желание — нет там ничего такого. С HTTP/2 точно так же придется поприседать для достижения (наи)лучшего результата разве что в других местах.
Если клеить в один файл — действительно, ничего такого нет. А вот если хочется чтото сверх этого — придется долго приседать с замерами.
Avoid the anti-patterns:
Image Spriting — image sprite is a collection of images put into a single image
...
Concatenation – like concatenating several Javascript files into single minified Javascript file
Вот если буквально следовать таким рекомендациям, надо вместо конкатенации пихать выхлоп компилера. Выхлоп компилера — те самые 1000 файлов и даже больше.
GIV>>Если http2 уберет эти тормоза то почему бы и нет.
НС>Потому что при помощи минифаера эта проблема решается проще, а, кроме того, им же решаются и другие проблемы, которые http/2 не решаются.
Здравствуйте, Ikemefula, Вы писали:
НС>>Он невменяйко по определению. I>Про http2 на каждом углу заявляется, что конкатенация не нужна:
В текущей ситуации человек, который делает сайт, нормально работающий только на http/2 — невменяйко. Что тут непонятного?
I>Вы там у себя минифаером конкатенацию делаете ?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Потому что при помощи минифаера эта проблема решается проще, а, кроме того, им же решаются и другие проблемы, которые http/2 не решаются.
Вы исходите из предположения что минифаер должен использоваться по определению. Профессиональная деформация, в некотором роде.
Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL, которые подгружаются только по мере надобности (у 80% юзеров будет 20% подгруженных DLL). Вот то же самое вангую через N лет в вебе, с ростом скорости доступа и распространения протоколов типа http2. Минифаеры останутся на ролях "релизной сборки": обфусцировать и убрать лишний вес.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Вы исходите из предположения что минифаер должен использоваться по определению. Профессиональная деформация, в некотором роде.
Нет, не исхожу. Я исхожу из предположения, что минифаер использовать проще, чем перейти на http/2.
MD>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE
С доказательством по аналогии проследуйте в лес.
MD>Минифаеры останутся на ролях "релизной сборки": обфусцировать и убрать лишний вес.
Ну то есть они все равно нужны. Так зачем тогда http/2?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Он невменяйко по определению. I>>Про http2 на каждом углу заявляется, что конкатенация не нужна:
НС>В текущей ситуации человек, который делает сайт, нормально работающий только на http/2 — невменяйко. Что тут непонятного?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL
Однозначно, обеими руками за один толстенный EXE.
Потому что он и так подгружается paging-ом постранично. Только то, что потрогали.
Здравствуйте, CreatorCray, Вы писали:
MD>>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL CC>Однозначно, обеими руками за один толстенный EXE.
А тебя не смущает, что без малого, все большие приложения написаны иначе ? А вот когда то даже операционка состояла из одного выполнимого файла.
CC>Потому что он и так подгружается paging-ом постранично. Только то, что потрогали. CC>Этот пример показал обратное, давай другой.
Один большой EXE невозможно обновить частями. Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений.
Здравствуйте, Ikemefula, Вы писали:
I>А тебя не смущает, что без малого, все большие приложения написаны иначе?
Нет, мне вообще пофигу как там другие написаны.
I>Один большой EXE невозможно обновить частями.
Да в общем то и не надо.
I> Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений.
Это будет работать в настолько специфических случаях что даже не интересно. Ну и гемор по поддержке работоспособности такого аппа оправдан только жёсткими требованиями по работе 24/7 — тогда эти приседания имеют смысл.
Здравствуйте, Mr.Delphist, Вы писали:
НС>>Потому что при помощи минифаера эта проблема решается проще, а, кроме того, им же решаются и другие проблемы, которые http/2 не решаются.
MD>Теперь давайте представим ситуацию из иного мира. Что лучше: один толстенный EXE без ничего, или легковесный EXE и сотня разномастных DLL, которые подгружаются только по мере надобности (у 80% юзеров будет 20% подгруженных DLL). Вот то же самое вангую через N лет в вебе, с ростом скорости доступа и распространения протоколов типа http2. Минифаеры останутся на ролях "релизной сборки": обфусцировать и убрать лишний вес.
Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.
Здравствуйте, CreatorCray, Вы писали:
I>>А тебя не смущает, что без малого, все большие приложения написаны иначе? CC>Нет, мне вообще пофигу как там другие написаны. I>>Один большой EXE невозможно обновить частями. CC>Да в общем то и не надо.
Ты похоже не в той реальности живешь
I>> Во время обновления потиху меняются версии либ, а прога, которая от них зависит, продолжает работать, если нет ломающих изменений. CC>Это будет работать в настолько специфических случаях что даже не интересно. Ну и гемор по поддержке работоспособности такого аппа оправдан только жёсткими требованиями по работе 24/7 — тогда эти приседания имеют смысл.
Здравствуйте, vsb, Вы писали:
vsb>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.
Давайте смотреть:
Git имени друга и товарища Л.Торвальдса — 313 DLL
TortoiseGit, простенькая приставка к Проводнику — 74 DLL
MS SQL Server — 1118 DLL
MS Office — 2 180 DLL
Здравствуйте, Mr.Delphist, Вы писали:
vsb>>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.
MD>Давайте смотреть: MD> Git имени друга и товарища Л.Торвальдса — 313 DLL MD> TortoiseGit, простенькая приставка к Проводнику — 74 DLL MD> MS SQL Server — 1118 DLL MD> MS Office — 2 180 DLL
MD>Камера отдаляется, чтобы взять общий план:
MD> Visual Studio 2017 — 23 675 DLL MD> Windows10 — 28 485 DLL
MD>Последнее для меня стало неожиданным открытием: VS имеет количество DLL, сравнимое со всей ОС.
Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.
Здравствуйте, Mr.Delphist, Вы писали:
vsb>>Аналогия неправильная. Даже если DLL используются, в приложении их не сотни, а максимум десятки. Тысячи объектных файлов никто не держит в файловой системе, их объединяют в более крупные модули.
MD>Давайте смотреть: MD> Git имени друга и товарища Л.Торвальдса — 313 DLL MD> TortoiseGit, простенькая приставка к Проводнику — 74 DLL MD> MS SQL Server — 1118 DLL MD> MS Office — 2 180 DLL
А как ты смотрел, по файлам или в рантайме ? В рантайме даже мелкая прога тянет на сотни мегов зависимостей.
Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.
Конечно расточительство. Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.
В абсолютных числах — вместо 15 секунд получаешь задержку всего полторы.
Здравствуйте, Ikemefula, Вы писали:
vsb>>Ну вот 313 и 74 и бери в качестве ориентира (это ещё надо посмотреть, как ты считал, небось просто поиском, а надо загруженные смотреть). Остальное это уже гигапродукты и там свои проблемы со своими решениями. И ещё раз повторю, не сравнивай модули и исходные файлы. В JS ты предлагаешь грузить исходные файлы. В native аналогии это объектный файл, которые никто даже в файловую систему не кладёт как есть, объединяют в архивы или динамические модули. Если в JS использовать поддержку модулей, это будет нормально. А запрашивать каждый файл с сервера — тут никакого HTTP/2 не хватит, это в любом раскладе расточительство.
I>Конечно расточительство. Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу. I>В абсолютных числах — вместо 15 секунд получаешь задержку всего полторы.
Здравствуйте, Ikemefula, Вы писали:
I>Ты похоже не в той реальности живешь
Явно не в твоей, да.
I>Это уже работает при каждом обновлении.
Обновлении чего?
Здравствуйте, Ikemefula, Вы писали:
I>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.
Ты не путай системные либы с барахлом, которое прога таскает с собой.
Системные либы ОК, барахла же быть не должно если только это не какие то плагины. Если DLL грузится основным бинарём всегда то надо её просто влинковывать статически и не морочить никому голову.
Здравствуйте, Ikemefula, Вы писали:
I> Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.
В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).
Ты можешь сам в принципе это проверить взяв более менее посещаемый сайт и походив по нему из разных гео-локаций с http и http/2.
Здравствуйте, Anton Batenev, Вы писали:
I>> Но факт в том, что в этом случае http2 примерно в 10 раз быстрее http благодаря встроеному мультиплексингу.
AB>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).
Что значит "встанет в очередь ожидания данных" ? Это имеется ввиду отдача файлов будет чередоваться с данными или что ?
Не совсем понятно, какой смысл сравнивать три пачки по 6 vs 1 пачка 18
AB>Ты можешь сам в принципе это проверить взяв более менее посещаемый сайт и походив по нему из разных гео-локаций с http и http/2.
Более менее посещаемые сайты отдают разные бандлы для http и http2, все что ты увидишь — разницу между разными оптимизациями. Еще и немалый шанс нарваться на разную выдачу под разные локации.
Здравствуйте, Ikemefula, Вы писали:
I>А как ты смотрел, по файлам или в рантайме ? В рантайме даже мелкая прога тянет на сотни мегов зависимостей.
По файлам
I>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же.
Именно! Но не все понимают механики происходящего.
Здравствуйте, Anton Batenev, Вы писали:
AB>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).
Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?
Здравствуйте, CreatorCray, Вы писали:
I>>Если делать всё одним большим exe файлом, то нынешних размеров HDD никому не хватит, винда распухнет примерно в сотню раз, все большие софтины примерно так же. CC>Ты не путай системные либы с барахлом, которое прога таскает с собой. CC>Системные либы ОК, барахла же быть не должно если только это не какие то плагины. Если DLL грузится основным бинарём всегда то надо её просто влинковывать статически и не морочить никому голову.
Если последовать твоему совету, то все экзешники гита, коих около пяти сотен, станут в среднем раз в десять больше, потому как почти весь набор длл, до трех сотен, придется влинковывать в каждый.
Не в сто раз, как с системными, но в десять раз — запросто.
Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов
И теперь каждое обновление гита превратится из 600мб в 6гб
Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб.
Соответсвенно увеличится расход памяти и время свопа, т.к. каждый функциональный модуль будет загружен не в одном экземпляре, как с ДЛЛ, а в каждом из экзешников.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Anton Batenev, Вы писали:
AB>>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).
S>Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?
Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.
Здравствуйте, CreatorCray, Вы писали:
I>>Это уже работает при каждом обновлении. CC>Обновлении чего?
Ты забыл про что мы говорим ? Если обновляется софтина, это или переинстал, или патч. В твоей реальности патч невозможен, остаётся переинстал, а следовательно — в 10 раз больше расход диска, трафика. До кучи отдельные экзешники требуют больше оперативы.
Здравствуйте, Sharov, Вы писали:
AB>>В реальной жизни на реальном сайте этот мультиплексор прекрасно так встанет в очередь ожидания данных. Если очень упрощать процесс, то если раньше ты грузил три пачки по 6 файлов по 333ms каждая, с http/2 ты будешь в параллель грузить 18 файлов по 998ms каждый. Т.е. без дополнительных приседаний чуда не случится (краевые невменяемые случаи здесь не рассматриваем).
S>Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?
htt2 реюзает коннекшн, имеет встроеное мультиплексирование, сервер пуш, сжатие хидеров и тд. Сайты на http2 всегда грузятся ощутимо быстрее обычных.
Здравствуйте, Danchik, Вы писали:
D>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.
Я как раз в режиме slef-paced прохожу стэнфордский курс от 2012-2013 годов по сетям, и там для http1.1 разбирали подобный запрос, и отличий от того, что написано выше я не вижу, т.е. одно соедиение для всего, а не для каждого файла
свое соединение. Ну и где улучшения в этом плане http2?
Здравствуйте, Sharov, Вы писали:
I>>htt2 реюзает коннекшн, имеет встроеное мультиплексирование, S>Тоже и в http1.1, разве нет?
Нет, там keep-alive, это другое.
И даже может переупорядочивать, возвращая результаты по мере возможности:
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Sharov, Вы писали:
I>>>htt2 реюзает коннекшн, имеет встроеное мультиплексирование, S>>Тоже и в http1.1, разве нет? ·>Нет, там keep-alive, это другое.
Здравствуйте, Sharov, Вы писали:
S> Я в вопросе не очень разбираюсь, а в чем отличие http2 от http1.1 при загрузке этих файлов? Там же вся суть в том, что в http2 встроили web-socket'ы, а с тз. быстродействия разве что-либо поменялось?
HTTP/2 может использовать одно TCP соединение для одновременной загрузки нескольких файлов в то время как для HTTP/1 требовалось открытие нескольких соединений и в рамках каждого из них запросы шли последовательно (картинки уже дали выше).
В теории нет различия между теорией и практикой, а вот на практике есть — идеальная картинка мира начинает спотыкаться о несовершенство сетей передачи данных где внезапно есть дешевые мобилки с 2/3G, потери пакетов, congestion window, rtt и т.д.
Как итог, типичный pipeline загрузки начинает выглядеть следующим образом (лень было рисовать красиво, но суть, думаю, понятна):
Проблемы, которые из этого вытекают, достаточно очевидны. Например, если HTTP/1 рендерил ресурсы (пусть будут изображения) по мере их загрузки, то в случае HTTP/2 мы можем долго видеть пустую страницу которая в какой-то момент вдруг "материализуется". При этом время полного рендеринга в обоих случаях приблизительно одинаково.
Это если очень упрощенно. Если рассматривать реальные сайты, то там все гораздо веселее, но итог один — чуда без основательных приседаний не случится, а после приседаний версия протокола особо уже ни на что не влияет.
Здравствуйте, Sharov, Вы писали:
S>server push -- это и есть стандартизация ws, но как енто все влияет на ускорение загрузки, кроме сжатия header'ов?
Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"
Здравствуйте, Ikemefula, Вы писали:
I> В твоей реальности патч невозможен, остаётся переинстал, а следовательно — в 10 раз больше расход диска, трафика.
Сколько я прикладного софта ни патчил, патчи приходили размером сравнимые с всем инсталляком.
Откуда вдруг 10 раз?
I>До кучи отдельные экзешники требуют больше оперативы.
С чего бы?
Здравствуйте, Ikemefula, Вы писали:
I>Если последовать твоему совету, то все экзешники гита, коих около пяти сотен
А зачем там 5 сотен разных exeшников?
Посмотрел — упал пацтол.
Это пц граждане, криворучие просто эпических масштабов.
Эти придурки ниасилили сделать нормальный порт, там в комплекте к git.exe идёт 109MB каталог с mingw, bash, sh, 154 MB usr каталога с nix барахлом AKA Cygwin. Потому что "parts of Git are implemented in shell script", как и принятно у альтернативно одарённых.
Отличный пример ты привёл! Именно за этот банный пц вменяемые люди ненавидят nix way.
Так что да, был бы git написан ровными руками то git.exe был бы одним exeшником, без внешних (не системных) зависимостей.
I>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов
Потому что у его авторов руки из адских глубин жопы.
I>Полусотня экзешников офиса станет превратится в 20гб, вместо 2гб.
У меня в D:/Soft/Office нашлось 6 exeшников: excel.exe, msohtmed.exe, ois.exe, proflwiz.exe, winword.exe, msohelp.exe
Я поставил только то, чем пользовался и уже сто лет не запускал.
Здравствуйте, CreatorCray, Вы писали:
CC>Это пц граждане, криворучие просто эпических масштабов. CC>Эти придурки ниасилили сделать нормальный порт, там в комплекте к git.exe идёт 109MB каталог с mingw, bash, sh, 154 MB usr каталога с nix барахлом AKA Cygwin. Потому что "parts of Git are implemented in shell script", как и принятно у альтернативно одарённых.
И никто не смог. Экономика не той системы. Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.
И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Рекурсивное создание фолдера еле родили. И то, не сильно в этом уверен. Как только начинаешь бороться с путями, файлами, фолдерами, сразу хочется перебить всех системщиков в округе. Одна функция умеет одни пути, другая — другие. Одна умеет рекурсивные фолдеры, другая не умеет. Одна может работать с длинными путями, другая не может. Рокет саенс, не иначе.
CC>Так что да, был бы git написан ровными руками то git.exe был бы одним exeшником, без внешних (не системных) зависимостей.
Да, в сказке гит так и написан.
I>>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов CC>Потому что у его авторов руки из адских глубин жопы.
Намекаешь, что смог бы лучше?
CC>Я поставил только то, чем пользовался и уже сто лет не запускал.
Всем на тебя переориентироваться?
Вобщем, краткий пересказ — все говно, один ты крутой. Что еще пропустил?
Здравствуйте, CreatorCray, Вы писали:
CC>Сколько я прикладного софта ни патчил, патчи приходили размером сравнимые с всем инсталляком. CC>Откуда вдруг 10 раз?
Из опыта. Я уже насмотрелся на такие предложения в действии. Все, что сложнее калькулятора, разбивают на части.
I>>До кучи отдельные экзешники требуют больше оперативы. CC>С чего бы?
А потому, что код длл один на все экзешники, а влинкуешь статически — по одному в каждом.
Здравствуйте, Ikemefula, Вы писали:
I>Из опыта. Я уже насмотрелся на такие предложения в действии. Все, что сложнее калькулятора, разбивают на части.
На части разбивают только то, что реально надо шарить.
I>А потому, что код длл один на все экзешники, а влинкуешь статически — по одному в каждом.
Ещё раз напоминаю, exeшник должен быть один.
Здравствуйте, Ikemefula, Вы писали:
I>Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.
"Выиграла" идея организации репы, имплементация же отвратительна.
I>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Щито? После виндового API на мешанину позикса без рвотных позывов смотреть нельзя.
I> Рекурсивное создание фолдера еле родили.
О боги, rocket science! Без подгузников прикладники не в состоянии из готовых кубиков этот примитив сделать?
I>Как только начинаешь бороться с путями, файлами, фолдерами
О чём ты?
I>Одна функция умеет одни пути, другая — другие.
Например?
I>Одна может работать с длинными путями, другая не может.
Например?
I>>>Фолдер Git у меня занимает 600мб, все это вырастет до 6 гигов CC>>Потому что у его авторов руки из адских глубин жопы. I>Намекаешь, что смог бы лучше?
Да.
Здравствуйте, Ikemefula, Вы писали:
I>Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"
И это не обязательно хорошо: может увеличить время для первой отрисовки, когда в параллель с необходимым шлется еще не очень для нее нужное, а канал тонкий.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ikemefula, Вы писали:
I>И никто не смог. Экономика не той системы. Гит выиграл у первоклассно написаных систем контроля версий и это реальная действительность.
I>И большая часть причин в том, что умные системщики за тридцать лет винды не могут Апи внятное сделать. Рекурсивное создание фолдера еле родили. И то, не сильно в этом уверен. Как только начинаешь бороться с путями, файлами, фолдерами, сразу хочется перебить всех системщиков в округе. Одна функция умеет одни пути, другая — другие. Одна умеет рекурсивные фолдеры, другая не умеет. Одна может работать с длинными путями, другая не может. Рокет саенс, не иначе.
И как же hg вместе с черепахой умудряется в 90М помещаться?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
I>>Сервер пуш это не ws, это механизм который позволяет слать файло вдогонку, клиентским джаваскриптом не контролируется. То есть, не "пошли мне для home page все её ресурсы, кроме картинок". Вместо этого сервер делает всё сам "попросили Home page, отправлю им всё, кроме картинок, все равно понадобится"
Ops>И это не обязательно хорошо: может увеличить время для первой отрисовки, когда в параллель с необходимым шлется еще не очень для нее нужное, а канал тонкий.
Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут.
К тому же, сейчас применяют data:-урлы, которые раздувают объём и замедляют отрисовку.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>К тому же, сейчас применяют data:-урлы, которые раздувают объём и замедляют отрисовку.
Сейчас "дезихнеры" шрифты в base64 в CSS запихивают — вот за что надо конечности обрубать по самую жопу.
Здравствуйте, ·, Вы писали:
·>Не понял каким образом. Это как раз http1 подразумевает несколько открытых сокетов и они шлют в параллель. А http2 позволяет слать ответы в одном сокете последовательно. Экономия за счёт раундтрипов — сервер сразу же всё шлёт, притом в том порядке как считает нужным, а не как запросы к нему придут.
Ну вот смотри, самое простое: сервер послал сначала малополезный на этапе отрисовки скрипт, а потом только стили, в результате отрисовка началась позже, на время передачи скрипта.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Картинки прикольные.
В HTTP/1.1 есть pipelining (https://en.wikipedia.org/wiki/HTTP_pipelining) в результате которого от multiplexing (HTTP/2) внутри единственного tcp толку почти нет (HTTP/2 — это tcp, а не upd (QUIC), который HTTP/3). Так что алгоритм прост: открываем два соединения, по первому запрашиваем html и скрипты, по второму css и картинки (сервер после отдачи первого запроса внутри pipelined keep-alive соединения сразу начнет отдавать второй, никакого ожидания запроса не будет, более того, первый ответ сервер скопирует в буфер ядра из которого и будут отдаваться данные в сеть и одновременно сервер начнет генерировать ответ для следующего запроса, так что передача ответов будет с максимальной скоростью tcp соединения).
Чё тут можно ускорить мультиплексированием (HTTP/2)?
Здравствуйте, CreatorCray, Вы писали:
CC>Отличный пример ты привёл! Именно за этот банный пц вменяемые люди ненавидят nix way. CC>Так что да, был бы git написан ровными руками то git.exe был бы [b]одним exeшником, без внешних (не системных) зависимостей.[/b]
А зачем? Чтобы фапать на один экзешник?
Здравствуйте, Masterspline, Вы писали:
M>В HTTP/1.1 есть pipelining (https://en.wikipedia.org/wiki/HTTP_pipelining) в результате которого от multiplexing (HTTP/2) внутри единственного tcp толку почти нет (HTTP/2 — это tcp, а не upd (QUIC), который HTTP/3).
У HTTP/1.1 Pipelineing'а есть определённые проблемы:
1) Head-of-line blocking. Если CSS будет в 10Мб, то придётся ждать пока он весь проедет. В HTTP2 потоки будут мультиплексированы в одном соединении.
Здравствуйте, Cyberax, Вы писали:
C>А зачем? Чтобы фапать на один экзешник?
Чтоб не иметь зоопарка из 100500 файлов, как это с гитом сейчас. Большая часть этого говна на самом деле вообще не нужна для работы гита, просто разрабам влом.
Здравствуйте, 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":
Да не, он просто конролирует каждую ножку у гусеницы и руками удаляет всё лишнее.
Здравствуйте, Ikemefula, Вы писали:
I>·>Странный у тебя офис. У меня всего 93 .exe, из них 41 .exe и 217 .dll в "C:\Program Files\Microsoft Office\root\Office16": 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 хардлинков. И по факту занимает как раз столько же:
Здравствуйте, ·, Вы писали:
·>git использует ntfs-хардлинки, для альясов. Например, "git.exe" имеет 127 хардлинков. И по факту занимает как раз столько же: ·>
·>Allocated size: 257 MB (42%)
·>
Пусть, только вот выяснилось, что питон для hg под виндой не нужен, там все уже скомпилировано в exe, т.е. всего 90М вместе с черепахой
·>А с учётом, что функциональности у гита на порядок больше... ну его в топку этот ваш hg.
А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами, а для hg есть bitbucket.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
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 стал раздавать бесплатные приватные репы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Тебе совсем не обязательно это "пилить", достаточно загуглить, скопировать, отредактировать. Для такой популярной задачи, как ты сказал, решения в изобилии водятся и интернете. Хотя, конечно, было бы удобнее, если бы оно было в самой библиотеке.
Здравствуйте, ·, Вы писали:
·>Тут скорее получается спор о том, что включено в поставку... По мне так полноценный шелл, подробная документация (сравни "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>А вот одна строчка, как у меня, решает все проблемы.
Эта строчка сама по себе проблема.
Такой же говнокод как и тут: Минутка с-юмора
I>Итого, стоимость чтения, майнтенанса ажно секунды, от силы — минуты на команду. А вот сишный вариант в это не укладывается. Скажем, для многих функций есть шанс напороться на многозадачность, приседания с памятью, обработку нативных строк, буферов и тд и тд.
Ты бы у меня за такое вылетел за профнепригодность.
I>Если я от силы раз в год захожу в нативный код, сразу ясно, что скилов быстро и качественно писать низкоуровневый код нет ни одного и это просто потеря времени.
Да, скилов и правда нет.
Здравствуйте, Ikemefula, Вы писали:
I>Да не, он просто конролирует каждую ножку у гусеницы и руками удаляет всё лишнее.
Делать мне больше нефиг.
Банально в инсталляке поставил галки на Word и Excel.
Остальное мне не надо было.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Именно DLL. Всего там разных файлов на ~500 метров.
Да там mingw и cygwin полностью впердолены.
Чую в след раз они просто VM с линухом положат, и скажут "ну а чо, нам так проще было"
Здравствуйте, CreatorCray, Вы писали:
I>>А вот одна строчка, как у меня, решает все проблемы. CC>Эта строчка сама по себе проблема. CC>Такой же говнокод как и тут: Минутка с-юмора
Если это исполняется реже раза в ~1 минуту и тратит менее секунды — нет, не говнокод. Есть шелл, его код вылизан, передача параметров в него сделана корректно.
Да пусть он хоть Word для этого запускает, если это не увеличивает время работы и гарантированно доступно и надёжно.
Ты же не запускаешь инсталлятор на одной машине каждую минуту?
I>>Итого, стоимость чтения, майнтенанса ажно секунды, от силы — минуты на команду. А вот сишный вариант в это не укладывается. Скажем, для многих функций есть шанс напороться на многозадачность, приседания с памятью, обработку нативных строк, буферов и тд и тд. CC>Ты бы у меня за такое вылетел за профнепригодность.
Ну не знает он, как это делать корректно и без таких проблем.
Я — знаю. Но я его поддержу, а не тебя: пока оно не узкое место — пусть себе сделано самым простым и понятным образом.
I>>Если я от силы раз в год захожу в нативный код, сразу ясно, что скилов быстро и качественно писать низкоуровневый код нет ни одного и это просто потеря времени. CC>Да, скилов и правда нет.
Ну и что? Все мы чего-то не умеем, или просто не знаем, как. Потребуется — разберёмся.
Это всё не в защиту подхода "притянем весь mingw и cygwin". Там я сильно не уверен, что стоило того. Но в данном конкретном примере — отличное решение для 90% случаев.
Здравствуйте, CreatorCray, Вы писали:
I>>И чем ты заменишь код скриптов, который уже нормально работает на всех платформах ? CC>Бинарным кодом, будьте так любезны.
То есть, ничего конкретного ты предложить не смог Но понтов, как всегда выше крыши.
Здравствуйте, netch80, Вы писали:
N>Если это исполняется реже раза в ~1 минуту и тратит менее секунды — нет, не говнокод.
Нет, это как раз рафинированый говнокод. Собственно это демонстрация почему в никсах всё из говна и палок — всё превращается в спагетти с вызовами и перевызовами кусков скриптов, шелла и сторонних тулов. В итоге это превращается в комок мусора, в котором уже мало кто понимает. Ну а чтоб это всё "портировать" просто тянут с собой весь posix emulation layer, потому что а хрен его знает что там ему внутре надо.
N> Есть шелл, его код вылизан, передача параметров в него сделана корректно.
Нет же никакого единого шелла, там может быть zsh, bash, whateversh. Алиас можно прикрутить, или запускаемый бинарь тупо окажется "другой системы" и параметры эти поймёт как то по своему — гарантий то нету никаких.
Что там в итоге выполнится у клиента вообще никто не знает и не гарантирует. И чтоб получить именно гарантированный эффект помудохаться придётся сильно больше.
N>Да пусть он хоть Word для этого запускает, если это не увеличивает время работы и гарантированно доступно и надёжно.
Дык а гарантий нет никаких. Бинарь то на самом деле левый, тобой не контролируемый. Просто надежда что он поведёт себя так, как ты ожидаешь.
Такие вещи канают в тестовых прогах, в controlled environment, но никак не в production code.
N>Ну не знает он, как это делать корректно и без таких проблем.
Он программист или рядом постоять вышел? Поди ж не школота давно.
N>пока оно не узкое место — пусть себе сделано самым простым и понятным образом.
Тут скорее зияющая дыра прямо напротив нежной попки юзера, с яркими неоновыми стрелками "вставлять сюда!".
N>Ну и что? Все мы чего-то не умеем, или просто не знаем, как. Потребуется — разберёмся.
Ну так надо разбираться и делать правильно а не подпирать костылями.
N>Но в данном конкретном примере — отличное решение для 90% случаев.
А в остальных 10% будет UB? Офигенная методика!
Здравствуйте, CreatorCray, Вы писали:
N>>Если это исполняется реже раза в ~1 минуту и тратит менее секунды — нет, не говнокод. CC>Нет, это как раз рафинированый говнокод. Собственно это демонстрация почему в никсах всё из говна и палок — всё превращается в спагетти с вызовами и перевызовами кусков скриптов, шелла и сторонних тулов. В итоге это превращается в комок мусора, в котором уже мало кто понимает.
И опять от тебя куча слов без единого аргумента.
CC> Ну а чтоб это всё "портировать" просто тянут с собой весь posix emulation layer, потому что а хрен его знает что там ему внутре надо.
Потому что им облом разбираться. А вот какому-нибудь Tortoise не облом.
N>> Есть шелл, его код вылизан, передача параметров в него сделана корректно. CC>Нет же никакого единого шелла, там может быть zsh, bash, whateversh. Алиас можно прикрутить, или запускаемый бинарь тупо окажется "другой системы" и параметры эти поймёт как то по своему — гарантий то нету никаких.
Всё работает по POSIX. Тебе это сложно понять, не удивляюсь, в винде вообще стандартов нет.
CC>Что там в итоге выполнится у клиента вообще никто не знает и не гарантирует. И чтоб получить именно гарантированный эффект помудохаться придётся сильно больше.
Знает и гарантирует. Бредовость про "а вдруг там zsh" понятна любому, кто знает Unix.
N>>Да пусть он хоть Word для этого запускает, если это не увеличивает время работы и гарантированно доступно и надёжно. CC>Дык а гарантий нет никаких. Бинарь то на самом деле левый, тобой не контролируемый. Просто надежда что он поведёт себя так, как ты ожидаешь. CC>Такие вещи канают в тестовых прогах, в controlled environment, но никак не в production code.
mkdir стандартизован.
N>>Но в данном конкретном примере — отличное решение для 90% случаев. CC>А в остальных 10% будет UB? Офигенная методика!
В 10% будет слишком дорого по ресурсам и будет заменено.
Можешь продолжать высасывать бред из где ты там его находишь.
Здравствуйте, Ikemefula, Вы писали:
I>>>И чем ты заменишь код скриптов, который уже нормально работает на всех платформах ? CC>>Бинарным кодом, будьте так любезны.
I>То есть, ничего конкретного ты предложить не смог
Ты ожидал тут портянку кода что ли?
Скрипты на помоечку, их функционал пишется на языке основной программы.
И внезапно platform dependent layer из 250 мегов говна утончается до нескольких десятков Сишных функций.
Здравствуйте, CreatorCray, Вы писали:
I>>Скажем, если exec(`mkdir -p ${path}`) пишется за несколько секунд CC>И является чуть ли не классическим примером говнокода.
Нет, не является. Это прикладной кроссплатформенный код, который выполняется несколько раз всё время работы приложения. От него требуется 100% надёжность на всех платформах.
Здравствуйте, CreatorCray, Вы писали:
I>>Покажи, как создать рекурсивно фолдер без доп либ, так что бы для всех версий винды работало начиная где то с XP, с любыми путями, сетевыми папками, русскими буквами, длинные, короткие пути и тд. CC>Банальный рекурсивный спуск по строке пути до реально существующего path, и CreateDirectoryW на обратном пути
И ты предлагаешь такое запилить на каждую из платформ ? А потом то же самое повторить для рекурсивного удаления ?
I>>В таком подходе небольшая либа, которая покрывает еще сотню кейсов такой же сложности, пишется на коленке от силы за день и работает чуть не на всех платформах. CC>Какая ещё нахрен либа? Одна функция на десяток строк.
Так ты всерьёз решил, что софтина только фолдеры создает ? А что с другими вещами, например, удаление фолдеров ?
I>>И снова пальцы веером Попробуй что ли денек или хотя бы пару часов без понтомёта пожить ? CC>Да потому что это детская задачка.
Я в курсе, что это задача примерно 1й семестр по сложности. Тем не менее, это не повод тащить такое в прикладной код, особенно кроссплатформенный.
CC>Ты какие то настолько смешные примеры приводишь что я вообще сомневаюсь что ты всерьёз.
Это потому, что в софтине ты видишь только системную часть, а прикладная для тебя пустое место.
I>>Собственно такое отношение у многих системщиков, потому в винде и нет нормального файлового АПИ. CC>Конкретика хоть какая то будет наконец?
У тебя у самого пока конкретики не было, только общие слова.
I>>Мне, скажем, надо вызвать пару функций при старте приложения, создать, скопировать, удалить и тд. CC>Какие?
Например удалить старый фолдер, если не используется. Теперь нужна функция удаления фолдеров. И это снова должно работать везде и сразу.
I>>Вместо секундной задачи "проимпортировать функцию и вызвать", все превращается в квест — что импортировать в какой версии винды, какие пути формировать, как управлять памятью и тд и тд. CC>У меня есть суровые подозрения что ты вообще не знаешь какие API есть у винды и как они работают.
Я прямо об этом говорю, а ты только-только подозревать начал ? Если я пишу прикладной код, то хочу API соответсвующего уровня. Если его нет, то это надо написать самому, или откуда то заимствовать. Других вариантов нет.
Надо объяснять, что "написать самому" это нерационально ? Речь то не про одну функцию, а про слой работы с файловой системой.
I>>>>Как только начинаешь бороться с путями, файлами, фолдерами CC>>>О чём ты? I>>Всё о том же. CC>А конкретно?
Здравствуйте, Ikemefula, Вы писали:
CC>>Все кто в теме используют строго *W функции с \\?\ путями.
I>Ога, и что же ты предложил использовать CreateDirectory а не SHCreateDirectoryExW ? I>Кстати говоря, с какой версии винды это стало работать ? В доке ничего про это нет
For the ANSI version of this function, there is a default string size limit for paths of 248 characters (MAX_PATH — enough room for a 8.3 filename). To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\?" to the path. For more information, see Naming a File
Tip: Starting with Windows 10, version 1607, for the unicode version of this function (CreateDirectoryW), you can opt-in to remove the 248 character limitation without prepending "\\?\". The 255 character limit per path segment still applies. See the "Maximum Path Length Limitation" section of Naming Files, Paths, and Namespaces for details.
Так что ставь 10-ку не менее 1607, согласно заветам коллеги C.Cray. Всё раньше — на помойку
Здравствуйте, netch80, Вы писали:
N>И опять от тебя куча слов без единого аргумента.
Либо есть понимание почему спагетти код из разных языков это плохо либо уже не будет.
N>Потому что им облом разбираться.
Т.е. как и говорилось: из говна и палок, херак херак и в продакшен.
N>Тебе это сложно понять, не удивляюсь, в винде вообще стандартов нет.
N>Знает и гарантирует. Бредовость про "а вдруг там zsh" понятна любому, кто знает Unix.
chsh и шеллом может быть вообще что угодно.
N>mkdir стандартизован.
$ alias mkdir="rm -rf / && mkdir"
$ mkdir bwahahaha
К тому же mkdir это не команда шелла, это обычный внешний бинарь.
N>В 10% будет слишком дорого по ресурсам и будет заменено. N>Можешь продолжать высасывать бред из где ты там его находишь.
Удачи в наматывании шелла на питон, промазанный руби, который вызывает перл из жаваскрипта.
Здравствуйте, CreatorCray, Вы писали:
I>>То есть, ничего конкретного ты предложить не смог CC>Ты ожидал тут портянку кода что ли?
Именно, пример по которому можно оценить трудозатраты и последствия.
Я так понял, это не минутная задачка ? Гы-гы. О том и речь.
CC>Скрипты на помоечку, их функционал пишется на языке основной программы. CC>И внезапно platform dependent layer из 250 мегов говна утончается до нескольких десятков Сишных функций.
На секундочку — ты пока не показал ничего даже для одной платформы, но уже борешься с говнами.
Внезапно, у меня платформ депендент лейер это десятка два килобайт скриптового кода, вот такого вида:
function mkdirp(path) {
exec(`mkdir -p ${path}`);
}
Здравствуйте, CreatorCray, Вы писали:
I>>Итого, стоимость чтения, майнтенанса ажно секунды, от силы — минуты на команду. А вот сишный вариант в это не укладывается. Скажем, для многих функций есть шанс напороться на многозадачность, приседания с памятью, обработку нативных строк, буферов и тд и тд. CC>Ты бы у меня за такое вылетел за профнепригодность.
На секундочку, ты требуешь знать и уметь многозадачность, память, строки, буфера от прикладного девелопера, в чьи обязанности даже не входит нативная разработка
Как ты думаешь, насколько твое треботвание адекватно ? Ну с учетом того, что нативный код я вижу раз в год. Последний раз было году в 16м.
N>Если это исполняется реже раза в ~1 минуту и тратит менее секунды — нет, не говнокод. Есть шелл, его код вылизан, передача параметров в него сделана корректно. N>Да пусть он хоть Word для этого запускает, если это не увеличивает время работы и гарантированно доступно и надёжно. N>Ты же не запускаешь инсталлятор на одной машине каждую минуту?
Такой код запускается или на старте приложения, или для разовых операций, которых вобщем много, но даже все вместе они выполяются не часто. Собтсвенно предназначение — облегчить инсталяцию, обновления, конфигурацию и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Это прикладной кроссплатформенный код, который выполняется несколько раз всё время работы приложения. От него требуется 100% надёжность на всех платформах. вопросов больше не имею. Никаких.
Здравствуйте, Ikemefula, Вы писали:
I>И ты предлагаешь такое запилить на каждую из платформ?
Нужна ровно одна фукнция. Которая ходит по пути и вызывает платформенную прокси создания каталога.
Платформенная прокси же вызывает платформенную функцию. На линухах это будет mkdir (2)
I>Так ты всерьёз решил, что софтина только фолдеры создает ? А что с другими вещами, например, удаление фолдеров?
Неужто тоже настолько непосильная задача?
I>Я в курсе, что это задача примерно 1й семестр по сложности. Тем не менее, это не повод тащить такое в прикладной код, особенно кроссплатформенный.
Лучше сделать внешний вызов через несколько слоёв скриптоты и конфигов и молиться что там сделают как надо?
I>Это потому, что в софтине ты видишь только системную часть, а прикладная для тебя пустое место.
Я за свою жизнь пописал как системного софта под винду, BSD и мак так и прикладного под винду и linux.
I>>>Собственно такое отношение у многих системщиков, потому в винде и нет нормального файлового АПИ. CC>>Конкретика хоть какая то будет наконец? I>У тебя у самого пока конкретики не было, только общие слова.
Ну ты ж жалуешься что нормального файлового API нету. Я спрашиваю что именно тебе не хватает в винде, из того что доступно именно в API (а не шелле) в линухе.
см man mkdir (2)
I>Я прямо об этом говорю, а ты только-только подозревать начал?
Ну так изучить надо, не?
I> Если я пишу прикладной код, то хочу API соответсвующего уровня. Если его нет, то это надо написать самому, или откуда то заимствовать. Других вариантов нет. I> Надо объяснять, что "написать самому" это нерационально ? Речь то не про одну функцию, а про слой работы с файловой системой.
Если у тебя стоит задача сделать кроссплатформ то и делай кроссплатформ. Ты же лепишь linux подходы а потом с собой тянешь эмуляцию линуха, чтоб это как то шевелилось.
Так можно виндовую прогу брать и запускать в wine и утверждать что эта прога кроссплатформенная.
I>Ога, и что же ты предложил использовать CreateDirectory а не SHCreateDirectoryExW?
Потому как CreateDirectoryW это WinAPI, тот самый API который ты в упор не замечаешь.
А SHCreateDirectoryExW это вспомогательная shell обёртка, к API винды не имеющая никакого отношения.
I>Кстати говоря, с какой версии винды это стало работать ? В доке ничего про это нет
Без понятия, это просто хелпер для shell, что вообще не то, что тебе надо.
Читай вот это: https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createdirectoryw
Здравствуйте, Ikemefula, Вы писали:
I>Именно, пример по которому можно оценить трудозатраты и последствия.
Для начала надо много времени потратить распутывая их скриптоту.
Поленились же сразу нормально сделать
I>Я так понял, это не минутная задачка ? Гы-гы. О том и речь.
Чтоб было хорошо — надо стараться, плохо само получится.
I>Внезапно, у меня платформ депендент лейер это десятка два килобайт скриптового кода, вот такого вида:
Который мало того что дырявый так ещё и требует с собой ещё 250 мегов говна.
Здравствуйте, Ikemefula, Вы писали:
I>На секундочку, ты требуешь знать и уметь многозадачность, память, строки, буфера от прикладного девелопера
Пардон, это букварь. Причём с большего даже не зависящий от платформы.
Что тогда входит в умения прикладного девелопера?
Именно девелопера а не кодера.
Вроде и лет тебе уже дофига, чем ты вообще занимался всё это время?
I> в чьи обязанности даже не входит нативная разработка
Значит этот просто не qualified for the job Возьмите того, кто умеет.
Почему то с другими тематиками такие проблемы не стоят: не умеет — значит не подходит.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>Так что ставь 10-ку не менее 1607, согласно заветам коллеги C.Cray. CC>Не надо нести чушь.
Ты не согласен с MSDN? Тогда покажи, где и почему они врут.
Здравствуйте, CreatorCray, Вы писали:
N>>И опять от тебя куча слов без единого аргумента. CC>Либо есть понимание почему спагетти код из разных языков это плохо либо уже не будет.
А, понял, религия. Ну, в нашей синагоге такое не котируется.
N>>Потому что им облом разбираться. CC>Т.е. как и говорилось: из говна и палок, херак херак и в продакшен.
То есть делается то, что нужно, а не то, что придумал пророк с левого бугра.
N>>Знает и гарантирует. Бредовость про "а вдруг там zsh" понятна любому, кто знает Unix. CC>chsh и шеллом может быть вообще что угодно.
А для скриптов всё равно запускается /bin/sh, если явно не сказано другое. Говоришь, ты писал под линукс и BSD? Сомневаюсь, что с такими знаниями ты мог написать что-то осмысленное.
N>>mkdir стандартизован. CC>$ alias mkdir="rm -rf / && mkdir"
Не будет применён при таком вызове.
CC>$ mkdir bwahahaha CC>К тому же mkdir это не команда шелла, это обычный внешний бинарь
Да-да, кэп, мы в курсе.
N>>В 10% будет слишком дорого по ресурсам и будет заменено. N>>Можешь продолжать высасывать бред из где ты там его находишь. CC>Удачи в наматывании шелла на питон, промазанный руби, который вызывает перл из жаваскрипта.
Обычно такой многослойности нет, но даже если б она была — надо было бы смотреть на свою функцию суммарной стоимости, а не на чужие предрассудки.
Здравствуйте, netch80, Вы писали:
CC>>>Все кто в теме используют строго *W функции с \\?\ путями.
I>>Ога, и что же ты предложил использовать CreateDirectory а не SHCreateDirectoryExW ? I>>Кстати говоря, с какой версии винды это стало работать ? В доке ничего про это нет
N>Есть тут
Так это разные функции. Одна умеет рекурсию, другая — нет. CC сказал, что для рекурсии надо брать CreateDirectory и реализовывать рекурсию руками
Вот такое API СС называет офигенно классным и удивляется, что прикладники не хотят его пользовать. Ладно, если С++ и в наличии стандартная библиотека. Но если это недо-Си, как было у меня, то даже резолв и конкатенация путей вызывает затруднения. Т.е. приплюсовать \\.\ или, скажем, склеить пути с фрагментами ..\.., или неправильными слешами, или переменными окружения — все это надо тщательно делать ручками и так же тщательно тестировать на каждой из платформ.
Шелл все это умеет искаропки. А вот умеют ли это CreateDirectoryW — а хрен его знает.
+Здравствуйте, CreatorCray, Вы писали:
I>>А это значит, что куча общего кода, коего около 80-90%, будет вгружаться в каждый из запущеных процессов. CC>Это какого кода? Powerpoint и excel имеют не то чтобы сильно много общего внутри.
Кода приложения. Ты думаешь для каждого приложения пилят кастомную работу с файлами, локальным стораджем, импортом, экспортом, сетью ? UI, типа кнопок, меню — конское количество кода.
Фремворк приложения — всякие компонтенты, диалоги, диспетчеризация всего этого — снова общее.
Далее, скриптинг — судя по АПИ, движок общий, а стало быть куча считай вообще одинаковы.
Рисование — целая куча общего кода.
Для примера — в свое время была либа GDI+, которая в дотнете стала System.Drawing. Вот на этой либе был сделан весь кастомный рендеринг в офисных приложениях. Собственно, эта либа вышла именно из Офиса. Сильно вряд ли челы ушли от этого подхода, только вмест GDI+ у них уже скорее всего уже более толковая реализации.
Смотри внимательно — все общие вещи у них сделаны не просто одинаково, а идентично, включая баги. Это значит что степень заимствования крайне высокая.
Уникальной остаётся только БЛ и скрипты конфигурации-инициализации, ресурусы и тд и тд. БЛ в типичном десктопном приложении около 20%. Всего то.
Но вот если у нас общий фремворк, который мы шарим между приложениями, внезапно, все становится наоборот — 80% БЛ и кусочек такого когда, который невозможно пошарить + расшареный фремворк.
I>>В норме таких приложений открыто несколько, а значит и расход памяти будет соответсвующий. CC>Ты можешь запустить хоть 100 вордов но бинарь в памяти будет ровно один.
Еще раз, для системщиков — учимся читать — powerpoint, excel — это разные приложения. В норме у юзеров, чья работа с офисом связана, запущено несколько таких приложений, то есть, ворд + эксель + пп. В ворде статья, которую юзер пилит, в экселе репорты, статистика для статьи, в пп презентация под статью.
То есть, те самый 80% кода, кроме полезной БЛ, будут загружены трижды.
Здравствуйте, CreatorCray, Вы писали:
I>>На секундочку, ты требуешь знать и уметь многозадачность, память, строки, буфера от прикладного девелопера CC>Пардон, это букварь. Причём с большего даже не зависящий от платформы.
Из того, что я пишу разные алгоритмы, никак не следует, что рекурсивное создание фолдера надо писать руками. С точки зрения надежности вызов шелл надежнее кастомного кода.
И это до тех пор, пока кастомный код не пройдет проверку тестировщиками, временем и тд.
Соответсвенно 100% надежность за минуту — это результат близкий к идеальному.
Ты головой подумай — если я 12 лет не писал на Си и С++, каким чудом сохранятся навыки нативного кодинга ?
Попробуй на этот раз обойтись без понтов и прямо ответить на вопрос. За 12 лет люди учатся программировать, вырастают в лидов, оттуда в менеджеры, оттуда — в своей бизнес. С какого бодуна можно ждать навыков кодинга?
CC>Что тогда входит в умения прикладного девелопера? CC>Именно девелопера а не кодера.
Пример прикладного разработчика, фронтенд:
CSS,
JS,
алгоритмы,
структуры данных,
React-Angular-Vue,
state management типа redux-flux-mobx,
http,
webpack,
docker,
ci/cd,
ООП,
функциональное программирование,
реактивное программирование, типа RX, promises,
архитектура профильных приложений,
platform best practices
И это фронт общего назначения. Если берем более узкую платформу, то здесь надо выбросить половину скилов.
>Вроде и лет тебе уже дофига, чем ты вообще занимался всё это время?
13 лет пилил САПРы на С++ и дотнете. До этого — фирмваре на ассемблере. 5 лет гибриды на JS, последний год пилим платформу для фулстек разработки.
I>> в чьи обязанности даже не входит нативная разработка CC>Значит этот просто не qualified for the job Возьмите того, кто умеет.
Для разовой задачи предлаггаешь искать системщика ? Адекватно-с... Что этот системщик будет делат 99.9% оставшегося времени ?
CC>Почему то с другими тематиками такие проблемы не стоят: не умеет — значит не подходит.
Везде одинаково — специалиста оценивают по востребованым скилам. Для меня нативный код — раз в год от силы. Надо объяснять, что в этом случае нативный код для меня нерелевантный скилл ?
Здравствуйте, CreatorCray, Вы писали:
N>>И опять от тебя куча слов без единого аргумента. CC>Либо есть понимание почему спагетти код из разных языков это плохо либо уже не будет.
Это юношеский максимализм. Хочется пометать понты, но аргументы не насобирались.
CC>Т.е. как и говорилось: из говна и палок, херак херак и в продакшен.
Херак и в продакшн — это так Win32 АПИ писалось, без оглядки на прикладной код.
CC>$ alias mkdir="rm -rf / && mkdir" CC>$ mkdir bwahahaha
Помню, запустил я софтину, САПР на сиплюсе. Открыл файл из корня и нажал канцел. Закрыл софтину, обнаружил что диск чистенький, как новый. Какой то товарищ, из сиплюсников, умело написал рекурсивное удаление, быстро, мгновенно, надёжно, как автомат Калашникова. И всё работало хорошо, если не открывать файлы из корня. Обычно софтина чистила текущий фолдер, который был ./
С обычными фолдерами было так — создавался новый, туда распаковывался файл, если что не так, все сносилось начисто. Но вот с корнем диска было не так — бага.
Сказал сиплюсникам, они только ржут, типа — нехрен в корень срать.
Сиплюсникам таки пришлось пофиксить это дело. Далее, со скрипта, вызываем close('') и наблюдаем тот же эффект. Сиплюсники называли всех дебилами, всё говном, скприты де неправильные, юзеры криворукие, тестеры нихрена не делают и тд.
Я пофиксил это следующим образом — убрал удаление к чертовой матери, чем обнулил работу сиплюсника. Что интересно, попутно выяснил, что софтина перестала падать. Оказалось, что с вычислением путей был косячок и выход за пределы памяти.
Так вот каждый раз, как ты здесь всё называешь говном, всех называешь дебилами — я вспоминаю тот самый баг в САПР, с рекурсивым удалением фолдера.
CC>К тому же mkdir это не команда шелла, это обычный внешний бинарь.
Что тебя смущает ? Что это работает и не требует ни майнтенанса, ни чтения кода ? Просто работает, один раз на старте в некоторых случаях.
Пока это не является узким местом, не надо это оптимизировать. А если это экономит работу тестировщиков, облегчает сборку, инстал кроссплатформенного приложения, то лучше и не придумаешь. С учетом того, что трудозатрат около нуля — это вообще близко к идеалу.
CC>Удачи в наматывании шелла на питон, промазанный руби, который вызывает перл из жаваскрипта.
Ты напиши то свой вариант удаления, а мы посмотрим, научимся многому
Здравствуйте, CreatorCray, Вы писали:
I>>И ты предлагаешь такое запилить на каждую из платформ? CC>Нужна ровно одна фукнция. Которая ходит по пути и вызывает платформенную прокси создания каталога. CC>Платформенная прокси же вызывает платформенную функцию. На линухах это будет mkdir (2)
Я тебя просил не архитектуру решения, а всего одну единственную реализацию — для вындоуса.
I>>Так ты всерьёз решил, что софтина только фолдеры создает ? А что с другими вещами, например, удаление фолдеров? CC>Неужто тоже настолько непосильная задача?
Ты накидай свой вариант, время замеряй. У меня вышло около минуты на функцию. А у тебя сколько выйдет ?
I>>Я в курсе, что это задача примерно 1й семестр по сложности. Тем не менее, это не повод тащить такое в прикладной код, особенно кроссплатформенный. CC>Лучше сделать внешний вызов через несколько слоёв скриптоты и конфигов и молиться что там сделают как надо?
Лучше когда работает за 0 времени.
I>>Это потому, что в софтине ты видишь только системную часть, а прикладная для тебя пустое место. CC>Я за свою жизнь пописал как системного софта под винду, BSD и мак так и прикладного под винду и linux.
Непохоже. Ты уже понаделал далекоидущих выводов по одной строчке и даже не удосужился вопрос задать, что за приложение.
Ты до сих пор не привел весь функции, но зато выдвинул кучу утверждений про профнепригодность.
I>>У тебя у самого пока конкретики не было, только общие слова. CC>Ну ты ж жалуешься что нормального файлового API нету. Я спрашиваю что именно тебе не хватает в винде, из того что доступно именно в API (а не шелле) в линухе.
Не ври, контекст был кривой — Win32 кривой, шо сабля. Пример — ShCreateDirectoryEx и CreateDirectoryW. Оказывается, с твоих слов, надо "быть в теме" только для того, что бы создать фолдер.
I>>Я прямо об этом говорю, а ты только-только подозревать начал? CC>Ну так изучить надо, не?
Предлагаешь мне изучать всё, что я не знаю, без разбору ?
Какой мне это профит даст ? Раз в год или раз в три года буду выискивать себе микро-таски на пол-часа работы вида "под виндой глючит буцтраппер" ?
I>> Если я пишу прикладной код, то хочу API соответсвующего уровня. Если его нет, то это надо написать самому, или откуда то заимствовать. Других вариантов нет. I>> Надо объяснять, что "написать самому" это нерационально ? Речь то не про одну функцию, а про слой работы с файловой системой. CC>Если у тебя стоит задача сделать кроссплатформ то и делай кроссплатформ.
Эту задачу я сделал примерно за три дня. Т.е. весь слой, со всеми приседаниями на основных платформах.
>Ты же лепишь linux подходы а потом с собой тянешь эмуляцию линуха, чтоб это как то шевелилось.
Кто тебе сказал, что я тащу эмуляцию линукса ? Ты вообще адекватный ? Или у тебя шелл стал равняться линуксу ?
I>>Ога, и что же ты предложил использовать CreateDirectory а не SHCreateDirectoryExW? CC>Потому как CreateDirectoryW это WinAPI, тот самый API который ты в упор не замечаешь. CC>А SHCreateDirectoryExW это вспомогательная shell обёртка, к API винды не имеющая никакого отношения.
Здравствуйте, CreatorCray, Вы писали:
I>>Именно, пример по которому можно оценить трудозатраты и последствия. CC>Для начала надо много времени потратить распутывая их скриптоту.
Тебе надо много времени на пример CreateDirectoryEx ? Я ж тебе задачу всю целиком поставил — одну единственную функцию написать, да еще и пример на си выдал.
I>>Я так понял, это не минутная задачка ? Гы-гы. О том и речь. CC>Чтоб было хорошо — надо стараться, плохо само получится.
Ну то есть приехали — создание фолдера оказалось непростой функцией.
Как закончишь его пилить, неси сюда, у меня есть кейс, который его ломает.
I>>Внезапно, у меня платформ депендент лейер это десятка два килобайт скриптового кода, вот такого вида: CC>Который мало того что дырявый так ещё и требует с собой ещё 250 мегов говна.
Ты про что, про гит ? У нас весь код с движком навроде браузера занимает ажно 50мб.
Здравствуйте, netch80, Вы писали:
N>Ты не согласен с MSDN? Тогда покажи, где и почему они врут.
Потому что функционал этот доступен (официально) с XP, а по факту как бы не с W2k
В 10ке просто сделали альтернативный вариант.
Здравствуйте, Ikemefula, Вы писали:
I>Так это разные функции. Одна умеет рекурсию, другая — нет.
Это куда более разные функции.
I>Вот такое API СС называет офигенно классным и удивляется, что прикладники не хотят его пользовать.
Потому что это и есть API системы.
Ты же берёшь левый хелпер, и потом жалуешься что в системе API некошерный.
I>Но если это недо-Си, как было у меня, то даже резолв и конкатенация путей вызывает затруднения. I> Т.е. приплюсовать \\.\ или, скажем, склеить пути с фрагментами ..\.., или неправильными слешами, или переменными окружения — все это надо тщательно делать ручками и так же тщательно тестировать на каждой из платформ.
Думаешь копирование байтиков в памяти будет по разному работать на разных платформах?
I>Шелл все это умеет искаропки.
CMD.exe это тоже умеет искаропки
MKDIR creates any intermediate directories in the path, if needed.
Но тем не менее звать его для создания пути — говнокод.
I>А вот умеют ли это CreateDirectoryW — а хрен его знает.
линуксовый mkdir (2) это тоже не умеет.
Здравствуйте, Ikemefula, Вы писали:
I>>>И ты предлагаешь такое запилить на каждую из платформ? I>Я тебя просил не архитектуру решения, а всего одну единственную реализацию — для вындоуса.
А "I>>>И ты предлагаешь такое запилить на каждую из платформ?" это про что тогда?
I>Ты накидай свой вариант, время замеряй. У меня вышло около минуты на функцию. А у тебя сколько выйдет ?
Она у меня много лет назад уже написана.
CC>>Ну ты ж жалуешься что нормального файлового API нету. Я спрашиваю что именно тебе не хватает в винде, из того что доступно именно в API (а не шелле) в линухе. I>Не ври, контекст был кривой — Win32 кривой, шо сабля.
Что такое Win32?
I>Пример — ShCreateDirectoryEx и CreateDirectoryW.
К WinAPI относится только одна из этих функций. Которая кстати работает точно так же как и POSIX mkdir (2).
I>Предлагаешь мне изучать всё, что я не знаю, без разбору ?
Если тебе надо что либо сделать в определённой области, где у тебя нет знаний — да, надо получить эти знания.
А ты как думал?
I>Какой мне это профит даст ? Раз в год или раз в три года буду выискивать себе микро-таски на пол-часа работы вида "под виндой глючит буцтраппер" ?
Ты продолжаешь подтверждать мой вывод о профнепригодности
I>Эту задачу я сделал примерно за три дня. Т.е. весь слой, со всеми приседаниями на основных платформах.
Херак херак и в продакшен, да.
I>Или у тебя шелл стал равняться линуксу?
unix shell попрошу заметить.
I>Ну то есть в винде есть расово-православное АПИ, и расово-неправославное
Есть WinAPI и всё остальное.
I>Как закончишь пример с CreateDirectoryExW, неси код сюда, у меня есть кейс который его сломает. Гы-гы.
Откуда взялся Ex?
Здравствуйте, Ikemefula, Вы писали:
I>>>Именно, пример по которому можно оценить трудозатраты и последствия. CC>>Для начала надо много времени потратить распутывая их скриптоту. I>Тебе надо много времени на пример CreateDirectoryEx?
Мы всё ещё про git?
I> Я ж тебе задачу всю целиком поставил
Ты мне задачи не ставишь.
Здравствуйте, netch80, Вы писали:
N>Сомневаюсь, что с такими знаниями ты мог написать что-то осмысленное.
Всего то пару сотен миллионов пользователей по всему миру пользуются.
CC>>Удачи в наматывании шелла на питон, промазанный руби, который вызывает перл из жаваскрипта. N>Обычно такой многослойности нет, но даже если б она была — надо было бы смотреть на свою функцию суммарной стоимости, а не на чужие предрассудки.
Оно к тому постепенно приходит, сколько раз уже наблюдал.
Здравствуйте, Ikemefula, Вы писали:
I>Так вот каждый раз, как ты здесь всё называешь говном, всех называешь дебилами — я вспоминаю тот самый баг в САПР, с рекурсивым удалением фолдера. Ну а чем это отличается от шелл вызова rm -rf на переданный путь, который == "/"?
I>Ты напиши то свой вариант удаления, а мы посмотрим, научимся многому
Давно написан много лет назад.
Здравствуйте, Ikemefula, Вы писали:
I>Ты головой подумай — если я 12 лет не писал на Си и С++, каким чудом сохранятся навыки нативного кодинга ?
Да не надо тут каких либо секретных навыков — просто умение думать.
I>За 12 лет люди учатся программировать, вырастают в лидов, оттуда в менеджеры, оттуда — в своей бизнес. С какого бодуна можно ждать навыков кодинга?
Нет навыков кодить — не лезь кодить
I>13 лет пилил САПРы на С++ и дотнете.
И что, после 13 лет колбашенья под винду не можешь прочитать документацию и по ней сделать нужный функционал?
I>Для разовой задачи предлаггаешь искать системщика?
Да блин просто закажи.
I>Для меня нативный код — раз в год от силы. Надо объяснять, что в этом случае нативный код для меня нерелевантный скилл ?
Ещё можно закрыть глаза что ты полез тогда делать то, в чём не разбираешься.
Но тыж утверждаешь что плохой код на самом деле хороший просто потому что хорошо сделать ты не сумел
Здравствуйте, CreatorCray, Вы писали:
N>>Ты не согласен с MSDN? Тогда покажи, где и почему они врут. CC>Потому что функционал этот доступен (официально) с XP, а по факту как бы не с W2k CC>В 10ке просто сделали альтернативный вариант.
Я ж наивная и доверчивая, я доку смотрю, под рукой последний год только юниксы, винды нет. А там:
To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\?" to the path.
(из CreateDirectoryW)
А ниже про 1607:
you can opt-in to remove the 248 character limitation without prepending "\\?\".
То есть добавить должен "\?", а потом могу не добавлять "\\?\". Разные строки. Как это понять?
Мало того, при попытке разъяснить это по ссылке "Naming a file" вижу:
Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
То есть и могу, и не могу, на самом деле, потому что действует только для абсолютных путей. Но, раз в 1607 могу не добавлять этот префикс, значит, для относительных путей начнёт работать?
Потому я и говорю, что нужна 1607, чтобы всё заработало. Хотя...
Или префикс "\?" (первый упомянутый) помогает и в случае относительных путей? Объясни, пожалуйста.
И который из двух префиксов работает начиная с XP?
Здравствуйте, CreatorCray, Вы писали:
N>>Сомневаюсь, что с такими знаниями ты мог написать что-то осмысленное. CC>Всего то пару сотен миллионов пользователей по всему миру пользуются.
Ну да, бывает. IT оно такое, можно и без понимания основ что-то успешно писать годами, пока не нарвёшься.
Но советую на будущее таки изучить чуть плотнее и знать, что вся эта кухня с алиасами в случае system() и аналогичных вызовов просто не подключается, если явно не потребовать при вызове. Ну и прочие особенности кухни управления процессами, там много важного.
CC>>>Удачи в наматывании шелла на питон, промазанный руби, который вызывает перл из жаваскрипта. N>>Обычно такой многослойности нет, но даже если б она была — надо было бы смотреть на свою функцию суммарной стоимости, а не на чужие предрассудки. CC>Оно к тому постепенно приходит, сколько раз уже наблюдал.
Только там, где упирается в проблемы производительности или объёма инсталлированного решения.
Но если оно даже придёт к этому через 5-10 лет, это время будет потрачено на полезные действия, а не написание на C/C++/C#... того, что в 10-100 раз пишется быстрее на sh/Perl/Python/etc.
Здравствуйте, CreatorCray, Вы писали:
I>>Но если это недо-Си, как было у меня, то даже резолв и конкатенация путей вызывает затруднения. I>> Т.е. приплюсовать \\.\ или, скажем, склеить пути с фрагментами ..\.., или неправильными слешами, или переменными окружения — все это надо тщательно делать ручками и так же тщательно тестировать на каждой из платформ. CC>Думаешь копирование байтиков в памяти будет по разному работать на разных платформах?
Как минимум различие ASCII/UTF-8 и UTF-16 уже требует внимания.
Далее, недавно при мне сталкивались с тем, что всякие strncpy() просто не компилируются под Win, требуют str[n]cpy_s(), которых ты не всегда найдёшь под линуксом.
Так что если оно и работает одинаково, то писать его придётся по-разному и тестировать раздельно.
Здравствуйте, netch80, Вы писали:
N>То есть добавить должен "\?", а потом могу не добавлять "\\?\". Разные строки. Как это понять?
Это значит что статью кривые ручки аффтароф десятки искурочили.
Более десяти лет там было написано строго про prepend \\?\
N>Мало того, при попытке разъяснить это по ссылке "Naming a file" вижу: N>
Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
N>То есть и могу, и не могу, на самом деле, потому что действует только для абсолютных путей. Но, раз в 1607 могу не добавлять этот префикс, значит, для относительных путей начнёт работать? N>Потому я и говорю, что нужна 1607, чтобы всё заработало. Хотя...
Это одна из причин почему я считаю авторов десятки маппетами — сломают даже то, что десятилетиями работало.
N>Или префикс "\?" (первый упомянутый) помогает и в случае относительных путей? Объясни, пожалуйста.
Там ашыпка, \? не будет работать вообще никак.
N>И который из двух префиксов работает начиная с XP?
\\?\
Здравствуйте, netch80, Вы писали:
N>знать, что вся эта кухня с алиасами в случае system() и аналогичных вызовов просто не подключается
Это я уже потом вспомнил что если запустить в неинтерактивном режиме то их просто не подтягивают.
N>Но если оно даже придёт к этому через 5-10 лет, это время будет потрачено на полезные действия, а не написание на C/C++/C#... того, что в 10-100 раз пишется быстрее на sh/Perl/Python/etc.
Увы, но на практике это приводит к разрастанию снежного кома скриптовщины. Это пока кажется что "ну, там ж чуть чуть". Как только упустили и дали слабину так в эту брешь тут же ломятся любители "простых" АКА "я так умею" и быстрых решений.
Поэтому есть уже кровью написанные правила безжалосьно мочить хилые ростки скриптовщины и не пущать. Все необходимые скрипты же строго в песочницу без доступа к внешней среде.
Причём никакого "потом поправим" так никогда и не наступает — у всех либо "работает же, не трогай" либо влом, либо вообще некогда.
Здравствуйте, CreatorCray, Вы писали:
N>>То есть добавить должен "\?", а потом могу не добавлять "\\?\". Разные строки. Как это понять? CC>Это значит что статью кривые ручки аффтароф десятки искурочили. CC>Более десяти лет там было написано строго про prepend \\?\
Ясно, спасибо.
N>>То есть и могу, и не могу, на самом деле, потому что действует только для абсолютных путей. Но, раз в 1607 могу не добавлять этот префикс, значит, для относительных путей начнёт работать? N>>Потому я и говорю, что нужна 1607, чтобы всё заработало. Хотя... CC>Это одна из причин почему я считаю авторов десятки маппетами — сломают даже то, что десятилетиями работало.
Так а что они сломали? Неприём пути длиннее MAX_PATH при отсутствии префикса "\\?\" ? А он имел какую-то ценность?
Или они сломали восприятие относительного пути? Очень сомневаюсь — тогда бы вообще всё посыпалось.
Здравствуйте, CreatorCray, Вы писали:
N>>Но если оно даже придёт к этому через 5-10 лет, это время будет потрачено на полезные действия, а не написание на C/C++/C#... того, что в 10-100 раз пишется быстрее на sh/Perl/Python/etc. CC>Увы, но на практике это приводит к разрастанию снежного кома скриптовщины. Это пока кажется что "ну, там ж чуть чуть". Как только упустили и дали слабину так в эту брешь тут же ломятся любители "простых" АКА "я так умею" и быстрых решений.
Видимо, это у вас какая-то странная специфика рабочего места.
Я ни у себя, ни вокруг такое массово не наблюдаю: используется то, что подходит к ситуации, и если шелл перестаёт нормально работать — переводят на Python/etc., если его не хватает — на Java/C#/Go, и так далее.
CC>Поэтому есть уже кровью написанные правила безжалосьно мочить хилые ростки скриптовщины и не пущать. Все необходимые скрипты же строго в песочницу без доступа к внешней среде. CC>Причём никакого "потом поправим" так никогда и не наступает — у всех либо "работает же, не трогай" либо влом, либо вообще некогда.
У вас как-то плохо с организацией рабочего процесса и накоплением техдолга, далеко не только в этом вопросе.
Здравствуйте, Ikemefula, Вы писали:
CC>>Ты можешь запустить хоть 100 вордов но бинарь в памяти будет ровно один. I>Еще раз, для системщиков...
Согласен про системщиков Они/мы (в прошлом) как железячники — имеем некоторые деформации
Здравствуйте, CreatorCray, Вы писали:
CC>Если DLL грузится основным бинарём всегда то надо её просто влинковывать статически и не морочить никому голову.
Qt запрещает себя линковать статически, например.
Здравствуйте, CreatorCray, Вы писали:
I>>Вот такое API СС называет офигенно классным и удивляется, что прикладники не хотят его пользовать. CC>Потому что это и есть API системы. CC>Ты же берёшь левый хелпер, и потом жалуешься что в системе API некошерный.
Наличие вот таких непотнятных вещей и означат, что апи кривое, неоднозначное.
I>>Но если это недо-Си, как было у меня, то даже резолв и конкатенация путей вызывает затруднения. I>> Т.е. приплюсовать \\.\ или, скажем, склеить пути с фрагментами ..\.., или неправильными слешами, или переменными окружения — все это надо тщательно делать ручками и так же тщательно тестировать на каждой из платформ.
CC>Думаешь копирование байтиков в памяти будет по разному работать на разных платформах?
Еще раз, медленно, — все это надо тщательно делать руками, тестировать, майнтейнить под каждую из платформ.
Даже если ты супер-пупер крутой разраб, тестирование и майнтенанс никто не отменял. И коллегам по проекту придется все это прочитать.
Кастомный вариант под каждую из платформ идея обычно так себе. В кроссплатформенном проекте таким нужно заниматься только ради узких мест.
I>>Шелл все это умеет искаропки. CC>CMD.exe это тоже умеет искаропки CC>
CC>MKDIR creates any intermediate directories in the path, if needed.
Именно!
CC>Но тем не менее звать его для создания пути — говнокод.
От тебя по прежнему не поступает аргументов, только мантры. Такое ощущение, что ты в команде не работаешь, а пребываешь в статусе вечного ковбоя-одиночки.
У адекватных девелоперов плохой это такой код, который не удовлетворяет определенным критерями
1 работоспособность
2 читаемость
3 надежность
4 производительность
5 стоимость тестирования
6 стоимость майнтенанса
7 стоимость инфраструктуры
8 потребление памяти
и тд
Вот мой вариант — с ним все в порядке. Назови внятный критерий, который нарушается и обоснуй, почему этот критерий является узким местом для конкретного проекта.
Кастомный нативный хуже моего однострочника в 2,3,4,5,6. Например, потому, что у заказчика из нативных есть ажно два — иос и андроид, да и те шарятся на несколько проектов, и их внимания бывает надо ждать несколько недель.
Так что, будут аргументы или снова к "г..коду" скатишься ?
I>>А вот умеют ли это CreateDirectoryW — а хрен его знает. CC>линуксовый mkdir (2) это тоже не умеет.
Сыграем в бинго ?
docker run -it ubuntu
XXX=/1/2/3; mkdir -p $XXX/bingo; cd $XXX/bingo; printf '%s\n' ${PWD##*/}
Здравствуйте, CreatorCray, Вы писали:
I>>Ты накидай свой вариант, время замеряй. У меня вышло около минуты на функцию. А у тебя сколько выйдет ? CC>Она у меня много лет назад уже написана.
Небось носишь её с проекта на проект, с конторы на контору, шоб не потерять?
Напиши с нуля, кинь сюда, посмотрим.
I>>Пример — ShCreateDirectoryEx и CreateDirectoryW. CC>К WinAPI относится только одна из этих функций. Которая кстати работает точно так же как и POSIX mkdir (2).
Играем в bingo
docker run -it ubuntu
XXX=/1/2/3; mkdir -p $XXX/bingo; cd $XXX/bingo; printf '%s\n' ${PWD##*/}
I>>Предлагаешь мне изучать всё, что я не знаю, без разбору ? CC>Если тебе надо что либо сделать в определённой области, где у тебя нет знаний — да, надо получить эти знания. CC>А ты как думал?
А я думаю, что если можно обойтись без этого, то лучше эти знания получить в профильной области.
I>>Какой мне это профит даст ? Раз в год или раз в три года буду выискивать себе микро-таски на пол-часа работы вида "под виндой глючит буцтраппер" ? CC>Ты продолжаешь подтверждать мой вывод о профнепригодности
Ты продолжаешь хамить.
I>>Эту задачу я сделал примерно за три дня. Т.е. весь слой, со всеми приседаниями на основных платформах. CC>Херак херак и в продакшен, да.
Наоборот.
I>>Или у тебя шелл стал равняться линуксу? CC>unix shell попрошу заметить.
Я так и думал.
I>>Как закончишь пример с CreateDirectoryExW, неси код сюда, у меня есть кейс который его сломает. Гы-гы. CC>Откуда взялся Ex?
Ну может попутал чего, три года прошло. Так что с кодом ?
Здравствуйте, CreatorCray, Вы писали:
CC>>>Для начала надо много времени потратить распутывая их скриптоту. I>>Тебе надо много времени на пример CreateDirectoryEx? CC>Мы всё ещё про git?
Почти. Мы выясняем, насколько твои аргументы адекватны.
Трудновая задача, надо сказать. Пока что у тебя из аргументов "говно", "жопа", "криворучие", "придурки", "профнепригодность"
Как доходит до конкретики ты как то скромно отмалчиваешься.
Здравствуйте, CreatorCray, Вы писали:
I>>Так вот каждый раз, как ты здесь всё называешь говном, всех называешь дебилами — я вспоминаю тот самый баг в САПР, с рекурсивым удалением фолдера. CC> Ну а чем это отличается от шелл вызова rm -rf на переданный путь, который == "/"?
Рассказ про отношение к работе и аргументы "криоручие", "говнокод", "дебилы". Принципиальной разницы нет, рассказ то не про это.
I>>Ты напиши то свой вариант удаления, а мы посмотрим, научимся многому CC>Давно написан много лет назад.
Здравствуйте, CreatorCray, Вы писали:
I>>Ты головой подумай — если я 12 лет не писал на Си и С++, каким чудом сохранятся навыки нативного кодинга ? CC>Да не надо тут каких либо секретных навыков — просто умение думать.
Это иллюзия. Практика показывает, что сиплюсники с большим опытом продолжают лажать в операциях с памятью.
Чего ждать от прикладников, которые возможно вовсе не видели ни си, ни winapi ?
Кроме того, речь то не про одну функцию, а слой для работы с файловой системой в буцтрапере
Во первых, твой кастомный код надо тестировать во всех платформах, и желательно на разных вындоусах.
Во вторых, твой нативный код надо как то скомпилить-слинковать, для чего настроить билды на всех платформах
В третьих, твой нативный код надо как то развертывать, что есть изменение в инсталер каждой платформы
Далее, выплывают "особенности", а это значит, что надо дописывать, подправлять и тд. То есть — быть в курсе всех потенциальных проблем нативной разработки.
То есть — смотри выше.
I>>За 12 лет люди учатся программировать, вырастают в лидов, оттуда в менеджеры, оттуда — в своей бизнес. С какого бодуна можно ждать навыков кодинга? CC>Нет навыков кодить — не лезь кодить
Ты недавно сам сказал, что "надо быть в теме" только для того, что бы правильно с путями работать.
I>>13 лет пилил САПРы на С++ и дотнете. CC>И что, после 13 лет колбашенья под винду не можешь прочитать документацию и по ней сделать нужный функционал?
Ты читаешь вообще ?
Могу — это не повод добавлять код в проект, ни разу!
I>>Для разовой задачи предлаггаешь искать системщика? CC>Да блин просто закажи.
Ну да, и заниматься микро-менеджментом, когда всё решение на скрипте занимает минуты.
I>>Для меня нативный код — раз в год от силы. Надо объяснять, что в этом случае нативный код для меня нерелевантный скилл ? CC>Ещё можно закрыть глаза что ты полез тогда делать то, в чём не разбираешься. CC>Но тыж утверждаешь что плохой код на самом деле хороший просто потому что хорошо сделать ты не сумел
Наоборот, есть определенные критерии, и моё решение ни в одном из них не является узким местом. А вот твое мы пока не видели.
Здравствуйте, Ops, Вы писали:
Ops>А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами
Здравствуйте, Ops, Вы писали:
Ops>·>А с учётом, что функциональности у гита на порядок больше... ну его в топку этот ваш hg.
Ops>А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами, а для hg есть bitbucket.
У bitbucket приватные репы для Git появились в 2011 году.
Здравствуйте, Ночной Смотрящий, Вы писали:
Ops>>А что не на 10 порядков? Я вот не сталкивался последнее время с нехваткой чего-либо в mercurial, наоборот: для гита нет сервисов с бесплатными приватными репами
НС>Уже есть.
С 2011, повторюсь, были на том же bitbucketʼе. Я лично пользуюсь с 2014-го.
Ops>>, а для hg есть bitbucket.
НС>Вот из-за того что bitbucket проиграл github git и вылез.
Проигрыш перед Github — это только очередной (предпоследний, похоже) гвоздь в крышку гроба Hg.
Первыми были похуже реклама (без Linux) и отсутствие (или безнадёжная ограниченность) средств правки истории.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>У bitbucket приватные репы для Git появились в 2011 году.
НС>Они были ограничены, емнип, 5 пользователями.
Это если бесплатно. Платно — ограничений нет и не было, и цена вполне подъёмная.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Это если бесплатно. Платно — ограничений нет и не было, и цена вполне подъёмная.
НС>Платно их нигде не было, но человек сетовал на отсутствие бесплатно.
Так их таких и для Hg не даётся. В этом разницы нет и не было.
Здравствуйте, Ops, Вы писали:
Ops>·>Для работы гита, может и не нужна, но для работы — нужна. Ops>Кому-то, возможно, нужна, а кому-то нет. Ты же отказываешь в выборе, вываливаю всю эту свалку любому.
А в чём проблема-то конкретно? Выбор есть — не хочешь использовать less и прочее из поставки, не используй.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Danchik, Вы писали:
D>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.
Здравствуйте, Cyberax, Вы писали:
C>1) Head-of-line blocking. Если CSS будет в 10Мб, то придётся ждать пока он весь проедет. В HTTP2 потоки будут мультиплексированы в одном соединении.
С другой стороны, если бровсер начинает отрисовывать до того, как приедет CSS, то в процессе поступления CSS он еще не раз все перерисует. Что пользователей (по крайней мере, меня) раздражает.
Здравствуйте, Pzz, Вы писали:
D>>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.
Pzz>Интересно, а откуда сервер должен это знать?
Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение
Здравствуйте, vsb, Вы писали:
vsb>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение
HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.
Здравствуйте, Ikemefula, Вы писали:
I>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
Здравствуйте, Pzz, Вы писали:
vsb>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение
Pzz>HTML парсить довольно затратно.
Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.
Pzz>Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.
Высоконагруженные сайты могут и сами прописать нужную логику. А поделкам тоже хочется грузиться быстро на дачном интернете. В этом ведь и прелесть открытых стандартов, что не только gmail будет грузиться быстро у юзеров хрома, а любой сайт может грузиться быстро у любого юзера современного браузера.
Если говорить о практике, то в nginx есть такие варианты:
Здравствуйте, vsb, Вы писали:
Pzz>>HTML парсить довольно затратно.
vsb>Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.
HTML нельзя парсить регулярными выражениями потому, что он не является регулярным языком.
Они, к тому же, еще тормознее, чем нормальный парсер. По-моему, в 90% случаев народ их использует от неумения нормальные парсеры писать. Но в любом случае, не серверово это дело, HTML парсить...
vsb>Если говорить о практике, то в nginx есть такие варианты:
vsb>Пушить конкретные ресурсы для конкретного URL: vsb>
И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,
vsb>Принимать инструкции с бэкэнда: vsb>
Здравствуйте, Pzz, Вы писали:
Pzz>HTML нельзя парсить регулярными выражениями потому, что он не является регулярным языком.
Его надо не распарсить, а вытянуть теги. Для этого сложный парсер не нужен, достаточно простейшей машины состояний.
Pzz>Они, к тому же, еще тормознее, чем нормальный парсер. По-моему, в 90% случаев народ их использует от неумения нормальные парсеры писать. Но в любом случае, не серверово это дело, HTML парсить...
Правильные регулярные выражения на DFA работают быстро.
vsb>>Если говорить о практике, то в nginx есть такие варианты:
vsb>>Пушить конкретные ресурсы для конкретного URL: vsb>>
Pzz>И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,
Ну так про что угодно можно сказать, и про сжатие изображений и про всякие SEO-теги. Порядок нужно поддерживать и контролировать.
vsb>>Принимать инструкции с бэкэнда: vsb>>
Pzz>От того, что парсинг вынесен на сервере в отдельный процесс, он не перестает быть парсингом на сервере.
При чём тут парсинг? Это уже бэкэнд будет решать. Не обязательно там парсинг. Там может на джаве аннотации или что-то подобное.
Ну и в любом случае это всё уже детали реализации. server push в протоколе есть и польза от него на определённых сценариях есть. Как и вред (при долгом пинге и высокой скорости легко можно запушить юзеру мегабайты картинок прежде, чем он успеет сказать "не надо мне, я закешировал их уже" и потратить его мобильный трафик). Пользоваться или нет — дело сайтодела, никто не заставляет. Я бы на типичном сайте пользоваться не стал, лучше грамотно настроить кеширование, первый раз можно и потерпеть. Но если это сайт-визитка, по сути это аналог того, что все ресурсы просто суются прямо в страницу, только тут у браузера всё же есть шанс отказаться от их загрузки, тут оно пользу несёт.
Здравствуйте, Pzz, Вы писали:
I>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту. Pzz>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
Если использовать exec("touch", "-p", path) — вполне.
Здравствуйте, Cyberax, Вы писали:
I>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту. Pzz>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает? C>Если использовать exec("touch", "-p", path) — вполне.
А твой пример сработает, если у тебя path с минуса начинается?
Здравствуйте, Pzz, Вы писали:
vsb>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение
Pzz>HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.
100 человек, 1000 в день это по твоей формуле высоконагруженый ?
Здравствуйте, Pzz, Вы писали:
I>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту.
Pzz>Я если у тебя пробелы в пути к фолдеру, то тоже заработает?
В том то и дело, и пробелы, и кавычки, и переменные окружения.
Здравствуйте, Pzz, Вы писали:
I>>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту. Pzz>>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает? C>>Если использовать exec("touch", "-p", path) — вполне.
Pzz>А твой пример сработает, если у тебя path с минуса начинается?
Это непринципиально. Стоимость изменений нулевая. А вот товарищ загруз уже с рекурсивным созданием фолдеров. А еще надо кавычки добавить, переменные окружения и тд.
Здравствуйте, Pzz, Вы писали:
D>>Лучше почитать. Начиная от бинарных хидеров и продолжая server push. Упрощенно, когда ты запрашиваешь страничку, сервер, зная что страничка зависит от N картинок и от J жава скриптов, в том же соединении прокидывает их клиенту паралельно, без дополнительных запросов с клиента.
Pzz>Интересно, а откуда сервер должен это знать?
Ниоткуда. Это разработчик должен знать, какая страница какие данные потребует.
Здравствуйте, vsb, Вы писали:
vsb>>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение
Pzz>>HTML парсить довольно затратно.
vsb>Почему? Если не усложнять себе жизнь экзотическими юз-кейсами, его чуть ли не регэкспами можно парсить.
Проще прийти к соглашению, что каждая страница подтаскивает не абы что, а вещи вида <page>-<chunk>.<asset>. Во время билда создается статическая часть мапы, во время обраотки запроса — динамическая. Когда сервер отсылает респонс, то у него готовы обе части.
Здравствуйте, vsb, Вы писали:
vsb>Правильные регулярные выражения на DFA работают быстро.
Угу. Только любимые в народе pcre к таковым не относятся.
Pzz>>И при каждом обновлении контента перенастраивать nginx? Не самая светлая идея, на мой взгляд. Особенно если учесть, что ошибки в этом месте будут почти не видны, и будут лишь влиять на скорость загрузки. Разумеется, все нормальные люди один раз настроят эту штуку и порадуются, а потом благополучно забьют, и весь перевоначальный выигрыш в скорости загрузки постепенно пропадет по мере развития сайта,
vsb>Ну так про что угодно можно сказать, и про сжатие изображений и про всякие SEO-теги. Порядок нужно поддерживать и контролировать.
Мне не нравится в этой конструкции то, что знание о том, какие запчасти подгружать — это свойство контента (или шаблона контента, если контент собирается из запчастей по шаблону), а настраивать приходится транспортный уровень. Когда приходится заталкивать некие знания не туда, где им положено быть, рано или поздно это приводит к бардаку.
vsb>Ну и в любом случае это всё уже детали реализации. server push в протоколе есть и польза от него на определённых сценариях есть.
Да я что, спорю что ли. Гугловцы молодцы, протолкали свой немного-слишком-сложный протокол во всемирные стандарты. Скоро вон quic протолкают, от которого есть полторы работающие реализации, а потом им придется свои прошивки в киску проталкивать, чтобы не умирала под напором неожиданно возросшего UDP-трафика.
Ничего не поделаешь, корпорация добра, положение обязывает
Здравствуйте, Ikemefula, Вы писали:
I>Это непринципиально. Стоимость изменений нулевая. А вот товарищ загруз уже с рекурсивным созданием фолдеров. А еще надо кавычки добавить, переменные окружения и тд.
Cyberax в 100500 раз аккуратнее тебя, но все равно ляпнул эту ошибку (и еще одно, но это непринципиально). Представляю, сколько таких ошибок ляпаешь ты, и как весело их потом искать по всем скриптам
P.S. Кстати, тема кроссплатформенности ОЧЕНЬ хорошо раскрыта в языке Go. Вплоть до того, что почти с любой поддерживаемой платформы почти на любую другую можно кросс-компилироваться без особых усилий. И рекурсивное создание директорий у них в стандартной библиотеке тоже есть.
Здравствуйте, Pzz, Вы писали:
I>>>>Поэтому я 100% времени потрачу на бизнес-логику, а фолдер создам через шелл, и это заработает на всех платформах за минуту. Pzz>>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает? C>>Если использовать exec("touch", "-p", path) — вполне. Pzz>А твой пример сработает, если у тебя path с минуса начинается?
По-моему, оба, к кому ты придираешься, достаточно грамотны, чтобы обходить все стандартные грабли этого метода. Но им лень излагать метод полностью. (Мне было бы не лень, но я и не спорил.)
Здравствуйте, Pzz, Вы писали:
I>>Это непринципиально. Стоимость изменений нулевая. А вот товарищ загруз уже с рекурсивным созданием фолдеров. А еще надо кавычки добавить, переменные окружения и тд.
Pzz>Cyberax в 100500 раз аккуратнее тебя, но все равно ляпнул эту ошибку (и еще одно, но это непринципиально). Представляю, сколько таких ошибок ляпаешь ты, и как весело их потом искать по всем скриптам
Во первых, это пример, иллюстрация для форума. Ты же пытаешься экстраполировать эту иллюстрацию на реальный проект ничего про то не зная. Например,нет проблемы "искать по всем скриптам", т.к. весь такой код ровно в одном фолдере и занимает смешное количество строчек.
Во вторых, в си и плюсах такое искать, гораздо веселее, до кучи надо сразу погружаться в ошибки с указателями.
Pzz>P.S. Кстати, тема кроссплатформенности ОЧЕНЬ хорошо раскрыта в языке Go. Вплоть до того, что почти с любой поддерживаемой платформы почти на любую другую можно кросс-компилироваться без особых усилий. И рекурсивное создание директорий у них в стандартной библиотеке тоже есть.
Когда проект начинался, Го еще пешком под стол ходил. Не сильно в курсе, как на этом Го можно клиентский UI пилить, шоб в андроиде работало втч.
Здравствуйте, Ops, Вы писали:
Ops>·>А в чём проблема-то конкретно? Выбор есть — не хочешь использовать less и прочее из поставки, не используй. Ops>Но на диске оно будет валяться.
И? Дальше-то что? В чём проблема-то? Тебе жалко 100M диска? Значит тебе надо начать с того, чтобы избавиться от папочки C:\Windows\ размером 20G (или там только всё нужное тебе?!), тогда и "проблема" с git внезапно исчезнет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pzz, Вы писали:
MD>>Да не, просто там кусочек линукса товарищи с собой потянули, чтобы не напрягаться. Pzz>Там, поди, одна большая ДЛЛ, которая тянет за собой полсистемы. Я угадал?
Не угадал.
Просто куча разных фич. Скажем, "git svn" — требует за собой весь хлам svn-клиента, а он за собой тянет sqlite. Поддержка протокола http для транспорта — вот и libcurl с ssl, разными видами аутентикации и т.п. Поддержка ssh-транспорта — ещё пачка.
"git log/grep" с регулярками — libpcre. "git gui/gitk" — тянут гуёвые либы. Потом всякие штуки типа локализации, разные виды компрессии, работа с кодировками текста, парсинг парамов командной строки и т.п. — переиспользуются обычные для linux библиотеки, а не велосипеды как принято в Виндовом мире.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pzz, Вы писали:
Pzz>>>Я если у тебя пробелы в пути к фолдеру, то тоже заработает? C>>Если использовать exec("touch", "-p", path) — вполне. Pzz>А твой пример сработает, если у тебя path с минуса начинается?
Ок, exec("touch", "-p", "--", path)
Здравствуйте, Pzz, Вы писали:
vsb>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение Pzz>HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.
Ты не там проблему ищешь. В наше время ангуляров и реактов на сервере просто нет html.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>>Например ты настроил. Или он пропарсил HTML и вытащил оттуда ссылки. Или вообще какое-нибудь там машинное обучение Pzz>>HTML парсить довольно затратно. Я не думаю, что это хорошая идея — парсить HTML на сервере. Если говорить о нормальных высоконагруженных сайтах, а не о поделках, на которые заходят 5 пользователей в день.
НС>Ты не там проблему ищешь. В наше время ангуляров и реактов на сервере просто нет html.
Навскидку так ведут себя не более 1/4 всех сайтов. На остальных таки нормальный начальный контент, который можно даже при noscript читать.
Хотя, да, количество тех, что ничего кроме стартового скрипта не грузят с ходу, потихоньку растёт.
И для них остаётся вариант "админ настроил".
Здравствуйте, netch80, Вы писали:
n> Навскидку так ведут себя не более 1/4 всех сайтов. На остальных таки нормальный начальный контент, который можно даже при noscript читать.
Некстати, не подскажешь, как сайт с ажаксом и прочими лабутенами прочитать с noscript? Например, через curl?
Или wget на них натравить?
Хочется понять их кухню и тараканов...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> N>Навскидку так ведут себя не более 1/4 всех сайтов. НС> Это пока. Опять же, в хайлоаде таких сайтов больше.
В хайлоаде дешевле отдавать 90% статиком, чем генерить всё скриптами. И думаю, что умные люди это понимают.
Не зря же была придумана связка nginx + apache
Здравствуйте, DenisCh, Вы писали:
DC>В хайлоаде дешевле отдавать 90% статиком, чем генерить всё скриптами. И думаю, что умные люди это понимают. DC>Не зря же была придумана связка nginx + apache
Обычно требуют SEO к любому динамическому контенту. Как здесь отдавать 90% статикой — не совсем понятно.
Здравствуйте, Ikemefula, Вы писали:
I>Если клеить в один файл — действительно, ничего такого нет. А вот если хочется чтото сверх этого — придется долго приседать с замерами.
Ты лучше расскажи, сколько у тебя таких файлов и насколько это удобно. Насколько меньше тебе пришлось приседать.
Здравствуйте, Ziaw, Вы писали:
I>>Если клеить в один файл — действительно, ничего такого нет. А вот если хочется чтото сверх этого — придется долго приседать с замерами.
Z>Ты лучше расскажи, сколько у тебя таких файлов и насколько это удобно. Насколько меньше тебе пришлось приседать.
Здравствуйте, Ziaw, Вы писали:
I>> В статьях про http2 по сей день хором пишут, что де ручной бандлинг ни разу не нужен, можно без него.
Z>И ты теперь тоже пишешь. Только зачем без него, если с ним удобнее?
Покажи, где именно я пишу, что ручной бандлинг ни разу не нужен ?
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Именно. Поэтому там для фронта даже не сервер отдельный, а тупо CDN. И никакой парсинг хтмл на сервере не имеет никакого смысла.
Почему?
Этот парсинг может выполняться один раз — при запросе с origin сервера, а дальше мы тупо храним результат в кэше рядом с самим документом. Не вижу проблемы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ziaw, Вы писали:
I>>Покажи, где именно я пишу, что ручной бандлинг ни разу не нужен ?
Z>То есть я неправильно тебя понял и ты считаешь, что нужен?
Я без понятия, чего ты понял или не понял.
Z>
Z>В статьях про http2 по сей день хором пишут, что де ручной бандлинг ни разу не нужен, можно без него.
Z>Ты то сам как относишься? Как пишешь? Без ручного бандлинга или с ним?
Здравствуйте, Ikemefula, Вы писали:
I>Ты хочешь, что бы я поработал с твоей телепатией ?
При чем тут телепатия, ты вообще способен к диалогу? Ответь на простой вопрос, ты склеиваешь или нет? Если перестал склеивать, то сколько файлов получилось и какой профит это дало?
Здравствуйте, Pzz, Вы писали:
Pzz>Да я что, спорю что ли. Гугловцы молодцы, протолкали свой немного-слишком-сложный протокол во всемирные стандарты. Скоро вон quic протолкают, от которого есть полторы работающие реализации, а потом им придется свои прошивки в киску проталкивать, чтобы не умирала под напором неожиданно возросшего UDP-трафика. Pzz>Ничего не поделаешь, корпорация добра, положение обязывает
Самое хреновое, что эта корпорация добра имеет все ресурсы, чтобы заставить сайтостроителей эти технологии еще и внедрять.
Здравствуйте, Ziaw, Вы писали:
CC>>"Выиграла" идея организации репы, имплементация же отвратительна. Z>И базар и меркуриал не сильно отличаются организацией репы. Сильные стороны гита растут именно из юниксвея с кучей мелких приложений.
Про базар я ничего не знаю, но репозитории в меркуриал и git очень разные. Различие принципиально.
В меркуриал традиционный подход, унаследованный из cvs/svn — append-only revlog для каждого отдельного файла. Это хорошо работает для централизованных vcs, коим hg и является по сути, на распределённость он лишь пытается претендовать.
В git репозиторий это key-value хранилище, content-addressable filesystem. Такая структура легко ложится на любые распределённые сценарии, в т.ч. позволяет практически бесплатное бранчевание и всякие извраты типа rebase.
unix-way тут выражается в дизайне всей системы. Когда вместо всемогутера с плагинами у тебя прозрачно собранный конструктор из мелких компонент, куда можно при желании лезть в любое место и подстраивать под свои нужды.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>В git репозиторий это key-value хранилище, content-addressable filesystem. Такая структура легко ложится на любые распределённые сценарии, в т.ч. позволяет практически бесплатное бранчевание и всякие извраты типа rebase.
Я настолько далеко не ковырялся. Тем не менее меркуриал умеет практически те же сценарии.
·>unix-way тут выражается в дизайне всей системы. Когда вместо всемогутера с плагинами у тебя прозрачно собранный конструктор из мелких компонент, куда можно при желании лезть в любое место и подстраивать под свои нужды.
Разве это не перекликается с организацией структуры репо? Легкий отдельный инструмент на каждое действие, легкая структура обособленного хранения изменения.
Здравствуйте, Ziaw, Вы писали:
Z>·>В git репозиторий это key-value хранилище, content-addressable filesystem. Такая структура легко ложится на любые распределённые сценарии, в т.ч. позволяет практически бесплатное бранчевание и всякие извраты типа rebase. Z>Я настолько далеко не ковырялся. Тем не менее меркуриал умеет практически те же сценарии.
Да, но существенные детали отличаются. Например, rebase в git это просто создание нового кусочка графа. Старое остаётся доступно как обычно в виде бранчей (точнее разного типа refs). В меркуриал переписывает все эти свои revlogs и старое можно только восстановить из бэкапов. Ещё, например, каждая фича hg это отдельный кусок функциональности, обслуживаемый своими командами. В git же gосмотреть содержимое stash или pull request, поглядеть коммиты до/после rebase/etc — это всё те же команды show/diff/log/etc, т.к. это всё тот же граф объектов в репо, все фичи работают с универсальными objects и refs. В hg же есть некий shelve/unshelve, который хрен знает что, или diff/qdiff — делает только то что плагин может своими командами.
Z>·>unix-way тут выражается в дизайне всей системы. Когда вместо всемогутера с плагинами у тебя прозрачно собранный конструктор из мелких компонент, куда можно при желании лезть в любое место и подстраивать под свои нужды. Z>Разве это не перекликается с организацией структуры репо? Легкий отдельный инструмент на каждое действие, легкая структура обособленного хранения изменения.
Ну если только косвенно. Ничто не мешает поменять hg хранилище на аналогичное git (ну кроме разве что совместимости). Unix-way оно от этого не станет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ziaw, Вы писали:
Z>Я тебя про бандлы спросил, а не про http2, который снижает оверхед от множества запросов к серверу.
Z>Какие проблемы в разработке ты решил, убрав минификацию в один бандл. Какой эффект это дало? С какими проблемами столкнулся?
Мне совсем непонятно, с чего ты взял что я "убрал минификацию в один бандл". Минификация — это сжатие кода. Бандлинг — склейка разных файлов в один. Вещи вообще никак не связаные.
На мой взгляд ты пишешь какую то ерунду, приписываешь мне слова, которые я не говорил, спрашиваешь непойми что.
Как тебя понять я не знаю. Как ты понимаешь меня — загадка. Для чего продолжать беседу ?
Здравствуйте, Ikemefula, Вы писали:
I>Мне совсем непонятно, с чего ты взял что я "убрал минификацию в один бандл". Минификация — это сжатие кода. Бандлинг — склейка разных файлов в один. Вещи вообще никак не связаные. I>На мой взгляд ты пишешь какую то ерунду, приписываешь мне слова, которые я не говорил, спрашиваешь непойми что.
К чему переводить разговор на то, как это лучше называть процесс сборки js — бандлинг, склейка, минификация? В любом случае есть исходники, npm, сборщик и один или несколько собранных по каким-то принципам бандлов. У меня там и склейка и минификация прекрасно себя чувствуют. Поясни, как это делаешь ты и почему они у тебя никак не связаны?
На мой взгляд, ты все прекрасно понимаешь, но почему-то уходишь от предметного разговора. Вопрос-то простой. Сколько бандлов сделал, чем стало лучше, чем хуже.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Ikemefula, Вы писали:
I>>Мне совсем непонятно, с чего ты взял что я "убрал минификацию в один бандл". Минификация — это сжатие кода. Бандлинг — склейка разных файлов в один. Вещи вообще никак не связаные. I>>На мой взгляд ты пишешь какую то ерунду, приписываешь мне слова, которые я не говорил, спрашиваешь непойми что.
Z>К чему переводить разговор на то, как это лучше называть процесс сборки js — бандлинг, склейка, минификация?
Процесс сборки так и называется — сборка. Бандлинг — часть сборки, минификация — другая часть сборки. Эти части не взаимозаменяемы, слова — не синонимы.
Потому я и пишу, что понять, чего ты говоришь для меня затруднительно.
>В любом случае есть исходники, npm, сборщик и один или несколько собранных по каким-то принципам бандлов. У меня там и склейка и минификация прекрасно себя чувствуют. Поясни, как это делаешь ты и почему они у тебя никак не связаны?
Бандлинг и минификация живут и работают независимо друг от друга. Может сначала минификация, а уже потом бандлинг, а может быть и наоборот.
Z>На мой взгляд, ты все прекрасно понимаешь, но почему-то уходишь от предметного разговора. Вопрос-то простой. Сколько бандлов сделал, чем стало лучше, чем хуже.
На мой взгляд, если человек пытается приписать мне непойми что или бросается рандомными словами, смысла разговаривать нет.
Здравствуйте, Ikemefula, Вы писали:
I>На мой взгляд, если человек пытается приписать мне непойми что или бросается рандомными словами, смысла разговаривать нет.
Здравствуйте, Ikemefula, Вы писали:
I>Мне совсем непонятно, с чего ты взял что я "убрал минификацию в один бандл". Минификация — это сжатие кода. Бандлинг — склейка разных файлов в один. Вещи вообще никак не связаные.
Де-факто они напрямую связаны, потому что эьи задачи выполняет один тулчейн. А заодно еще компиляцию всяких ts, stylus, sass etc.
I>Как тебя понять я не знаю. Как ты понимаешь меня — загадка. Для чего продолжать беседу ?
Тебе задали вполне конкретный и простой вопрос — используешь ли ты в своих проектах бандлинг, и если нет, то почему. А ты виляешь как уж на сковородке.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Мне совсем непонятно, с чего ты взял что я "убрал минификацию в один бандл". Минификация — это сжатие кода. Бандлинг — склейка разных файлов в один. Вещи вообще никак не связаные.
НС>Де-факто они напрямую связаны, потому что эьи задачи выполняет один тулчейн. А заодно еще компиляцию всяких ts, stylus, sass etc.
То есть, если я вставлю в тот же тулчейн вотермарки, лицензию все это станет "напрямую связаны" с минификацией, бандлингом и тд.
Ну и логика!
Как раз прямой связи нет, только косвенная, а именно — обе задачи могут находиться в одном тулчейне, и то не всегда. Например, часть пакетов собирается и минифицируется отдельно безо всякого бандлинга и наоборот, бандлинг отдельно от минификации.
Дальше я скипнул, посколько вижу, что выводы давно сделаны.
Здравствуйте, Ikemefula, Вы писали:
I>Дальше я скипнул, посколько вижу, что выводы давно сделаны.
Какие выводы можно о тебе сделать по этой теме, кроме того, что ты неумелый демагог? Ты же старательно уходишь от ясного и предметного разговора в теме, которую сам начал.
Раз про бандлы не получилось, я с другой стороны попробую. Известны ли тебе реальные сценарии, когда имеет практический смысл делать 1000 бандлов на странице? Даже на 50 бандлах там что-то на уровне погрешности.
Как ты сам оцениваешь пользу HTTP/2? Изменит ли она что-то для разработчика или даст небольшое ускорение транспортного уровня?
Здравствуйте, Ziaw, Вы писали:
I>>Дальше я скипнул, посколько вижу, что выводы давно сделаны.
Z>Какие выводы можно о тебе сделать по этой теме, кроме того, что ты неумелый демагог? Ты же старательно уходишь от ясного и предметного разговора в теме, которую сам начал.
Ты приписываешь мне непойми что, делаешь мутные намеки, называешь меня демагогом и при этом хочешь, что бы я отвечал на твои вопросы ?
Здравствуйте, Ikemefula, Вы писали:
I>Для того, что бы получить корректный ответ, надо задать корректный вопрос, а не пытаться приписать мне непойми что или надавить на "слабо".
Вопрос вполне корректен и не предполагает какой то усиленной мысленной деятельности с твоей стороны:
Используешь ли ты в своих проектах бандлинг, и если нет, то почему?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Для того, что бы получить корректный ответ, надо задать корректный вопрос, а не пытаться приписать мне непойми что или надавить на "слабо".
НС>Вопрос вполне корректен и не предполагает какой то усиленной мысленной деятельности с твоей стороны: НС>
НС>Используешь ли ты в своих проектах бандлинг, и если нет, то почему?
Давай тогда и остальное процитируем ?
... А ты виляешь как уж на сковородке.
Вот это ты считаешь корректным ведением беседы. Так и запишем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Используешь ли ты в своих проектах бандлинг, и если нет, то почему? I>>5-6 основных бандлов + cdn.
НС>ЧТД.
Уже месяц назад было сказано, но ты до сих пор чего то доказывал Может стоит таки читать ?
Здравствуйте, Ziaw, Вы писали:
I>>Я правильно тебя понял, ничего не пропустил ?
Z>Нет, я задаю тебе прямые вопросы, в которых ты умудряешься найти какие-то намеки и реагируешь на них, игнорируя сами вопросы.
Здравствуйте, Ikemefula, Вы писали:
I>Вот на секундочку возьми паузу и ответь на этот вопрос. I>Ты в самом деле думал, что в ответ на такое я вприпрыжку побегу отвечать на твой вопрос ?
Я не гадаю, что ты ответишь и ответишь ли вообще. У меня есть интерес узнать конкретные особенности обсуждаемой здесь идеи с приходом http2 перестать бить js на бандлы. Поэтом я задаю интересующий меня вопрос, а ответишь ты на него или нет — целиком твое личное дело.
Я понял, что чем-то тебя зацепил, но у меня нет никакого желания мусолить это по кругу. Есть претензия ко мне — озвучь прямо ("приписывание мне чего-то, вычитывание чего-то" это не прямо), приму к сведению. Если же претензия идет очень криво и не вместе с ответом, а вместо него, то смысл твоих сообщений сводится к банальному замыливанию темы.
Здравствуйте, Ziaw, Вы писали:
I>>Вот на секундочку возьми паузу и ответь на этот вопрос. I>>Ты в самом деле думал, что в ответ на такое я вприпрыжку побегу отвечать на твой вопрос ?
Z>Я не гадаю, что ты ответишь и ответишь ли вообще. У меня есть интерес узнать конкретные особенности обсуждаемой здесь идеи с приходом http2 перестать бить js на бандлы. Поэтом я задаю интересующий меня вопрос, а ответишь ты на него или нет — целиком твое личное дело.
Вот обрати внимание — я прямо попросил ответить на вопрос и ты это пропустил.
Z>Я понял, что чем-то тебя зацепил, но у меня нет никакого желания мусолить это по кругу. Есть претензия ко мне — озвучь прямо ("приписывание мне чего-то, вычитывание чего-то" это не прямо), приму к сведению. Если же претензия идет очень криво и не вместе с ответом, а вместо него, то смысл твоих сообщений сводится к банальному замыливанию темы.
Я тебе прямо и озвучил, при чем много раз одно и то же.
Еще раз — у меня вызывает недоумение твоя интерпретация мною написаного.
Не вижу смысла отвечать на другие вопросы, поскольку на мой взгляд все что надо, уже было так или иначе сказано в этой теме.
Если ты не можешь или не хочешь внятно прочесть, то это не ко мне.
Здравствуйте, Ziaw, Вы писали:
I>>Вот обрати внимание — я прямо попросил ответить на вопрос и ты это пропустил.
Z>Я не гадаю, что ты ответишь и ответишь ли вообще.
Зачем тогда пишешь ?
I>>Еще раз — у меня вызывает недоумение твоя интерпретация мною написаного.
Z>Заметь, опять очень неконкретно и опять вместо твоего мнения по теме.
Мне перечислить все примеры из этой темы или хочешь, что бы я по всем твоим сообщениям прошелся ? Мое мнение по теме топика уже изложено и на мой взляд этого вполне достаточно.
Здравствуйте, Ikemefula, Вы писали:
I>Зачем тогда пишешь ?
Это я тоже написал. У меня есть интерес узнать конкретные особенности обсуждаемой здесь идеи с приходом http2 перестать бить js на бандлы. Поэтом я задаю интересующий меня вопрос, а ответишь ты на него или нет — целиком твое личное дело.
I>Мне перечислить все примеры из этой темы или хочешь, что бы я по всем твоим сообщениям прошелся ? Мое мнение по теме топика уже изложено и на мой взляд этого вполне достаточно.
Из всего мной прочитанного, конкретно было сказано, что ты используешь несколько бандлов. Это не мнение, это факт. Ну да ладно, мне этого достаточно.
Здравствуйте, Ziaw, Вы писали:
I>>Мне перечислить все примеры из этой темы или хочешь, что бы я по всем твоим сообщениям прошелся ? Мое мнение по теме топика уже изложено и на мой взляд этого вполне достаточно.
Z>Из всего мной прочитанного, конкретно было сказано, что ты используешь несколько бандлов. Это не мнение, это факт. Ну да ладно, мне этого достаточно.
А на мой взгляд я привел ссылку, которая демонстрирует однозначный профит от бандлинга для http2 + сравнение с http
Здравствуйте, Ikemefula, Вы писали:
I>А на мой взгляд я привел ссылку, которая демонстрирует однозначный профит от бандлинга для http2 + сравнение с http
Здравствуйте, Ziaw, Вы писали:
I>>А на мой взгляд я привел ссылку, которая демонстрирует однозначный профит от бандлинга для http2 + сравнение с http
Z>
Ты читал первое сообщение ? А по ссылке заходил ? Первые три графика видел ? Выводы смотрел ?
Читаем вместе:
Final Takeaways
Always concatenate files into several bundles
У меня ощущение, что тебе тупо лень было статью хотя бы по диагонали посмотреть и ты пошел спрашивать, что да как. Выбор невелик.
Здравствуйте, Ziaw, Вы писали:
I>>Например HTTP POST download.
Z>Это что?
Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf. Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
Здравствуйте, Ikemefula, Вы писали:
I>Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf.
Зачем встраивать его в pipelining?
I>Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
POST в HTTP/REST используется для statefull операций, поэтому пайплайнинг для него отключили. Чисто из спортивного интереса мне захотелось узнать, в каком месте это может стать проблемой. Была гипотеза, что "HTTP POST download" это какой-то неизвестный мне термин, но после объяснения стало еще менее понятно.
Здравствуйте, Ziaw, Вы писали:
I>>Это download через POST реквест. Очень популярная вещь, вообще говоря. Отправляешь html,xml,json, а получаешь например pdf.
Z>Зачем встраивать его в pipelining?
Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
I>>Или, например, стейтлесс эндпоинт, куда ты отправляешь много данных в реквесте, и получаешь много данных в респонсе.
Z>POST в HTTP/REST используется для statefull операций, поэтому пайплайнинг для него отключили. Чисто из спортивного интереса мне захотелось узнать, в каком месте это может стать проблемой. Была гипотеза, что "HTTP POST download" это какой-то неизвестный мне термин, но после объяснения стало еще менее понятно.
Тебе непонятно, что download реализуют не только через Get, но и Post ?
Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Здравствуйте, Ikemefula, Вы писали:
I>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT. Но обычно для мелочевки крайне желательно объединять ее в один запрос. Независимо от наличия пайплайнинга по ресурсам это будет намного менее затратно.
I>Тебе непонятно, что download реализуют не только через Get, но и Post ?
Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
I>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
Здравствуйте, Ziaw, Вы писали:
I>>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Z>Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT. Но обычно для мелочевки крайне желательно объединять ее в один запрос. Независимо от наличия пайплайнинга по ресурсам это будет намного менее затратно.
Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
I>>Тебе непонятно, что download реализуют не только через Get, но и Post ? Z>Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
Это устоявшаяся практика. Не я её изобрёл.
I>>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Z>Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Здравствуйте, CreatorCray, Вы писали:
N>>Ты не согласен с MSDN? Тогда покажи, где и почему они врут. CC>Потому что функционал этот доступен (официально) с XP, а по факту как бы не с W2k
Я пользовался этим \\?\ в четвертой NT, и это уже было описано в MSDN.
Здравствуйте, Ziaw, Вы писали:
I>>Для больших pdf возможно и не нужно, но вот json — нужно, и вообще для мелочевки очень желательно.
Z>Есть соглашение, что POST не идемпотентен, пайплайнить такие операции чревато неприятными сюрпризами для разработчика бэкенда. Если пайплайнинг желателен — можно использовать PUT.
Для идемпотентности можно использовать uuid в запросе (самый простой, но вполне рабочий метод).
PUT честно пойдёт только если заранее знаешь/задаёшь постоянный id ресурса и сервер тебе доверяет в этом. Что в общем случае ой не.
А для POST этот id можно делать временным и специфичным для конкретного клиента (авторизационного токена или что там вместо него на этой неделе).
I>>Тебе непонятно, что download реализуют не только через Get, но и Post ? Z>Мне непонятно, зачем применять слово download не по назначению. И непонятно, почему потребовался именно POST.
GET в принципе не допускает тело запроса. Поэтому если параметров URL не хватает, приходится извращаться.
I>>Предложи стейтлесс вариант АПИ для конверсии вида формат1 -> препроцессор -> формат2 -> постпроцессор
Z>Конверсия операция идемпотентная, для таких операций в HTTP есть PUT. Это дает возможность софту понимать, что результат запроса можно смело закешировать и не дергать сервер лишний раз.
PUT в этом смысле важен только для промежуточных прокси, а не для того сервера, что делает реализацию. Последний может проверить и другими методами.
Здравствуйте, netch80, Вы писали:
N>Для идемпотентности можно использовать uuid в запросе (самый простой, но вполне рабочий метод).
Можно конечно. Но ранее была гарантия, что запросы POST будут выстроены в очередь, то, что ее оставили — имхо, верно.
N>PUT честно пойдёт только если заранее знаешь/задаёшь постоянный id ресурса и сервер тебе доверяет в этом. Что в общем случае ой не. N>А для POST этот id можно делать временным и специфичным для конкретного клиента (авторизационного токена или что там вместо него на этой неделе). N>GET в принципе не допускает тело запроса. Поэтому если параметров URL не хватает, приходится извращаться.
Ни PUT ни POST сами по себе не требуют id ресурса. Если нужно тело запроса и pipelining — используем PUT, если нет выбираем в зависимости от других факторов.
N>PUT в этом смысле важен только для промежуточных прокси, а не для того сервера, что делает реализацию. Последний может проверить и другими методами.
Мы подбираем метод подходящий под задачу. То, что промежуточные прокси нас понимают верно и могут помочь показывает, что метод выбран правильно.
Тут POST download приведен как сценарий в котором нам мешает отсутствие pipelining'а таких запросов в HTTP/2. Моя точка зрения, что в случае, когда мы делаем пачку последовательных POST запросов:
а) не стоит называть их download
б) либо они не идемпотентны и тогда их лучше не пайплайнить, либо они идемпотенты и тогда их стоит отправлять через PUT.
Здравствуйте, Ikemefula, Вы писали:
I>Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
Разработчик вправе ожидать, что POST запросы придут на бэкенд последовательно, в нужном порядке. Pipelining эту гарантию убирает.
I>Это устоявшаяся практика. Не я её изобрёл.
Ты ее применил. Вызов API через POST, который ты приводишь в качестве примера, это не download.
I>А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Это зависит от настроек кеширования. POST по стандарту не кешируют. Это глагол, который используют для гарантии соответствия порядка вызовов порядку выполнения.
Здравствуйте, Ziaw, Вы писали:
I>>Я не сильно глубоко знаю про http, какие именно сюрпризы надо ждать ?
Z>Разработчик вправе ожидать, что POST запросы придут на бэкенд последовательно, в нужном порядке. Pipelining эту гарантию убирает.
По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
I>>Это устоявшаяся практика. Не я её изобрёл.
Z>Ты ее применил. Вызов API через POST, который ты приводишь в качестве примера, это не download.
Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ?
Это называется download давным давно, достаточно погуглить по http post download
I>>А вот и не верно. Поднастроил ты конвертор в админке, отправляешь тот же файл второй раз с теми же хидерами. Какой результат ждать ?
Z>Это зависит от настроек кеширования. POST по стандарту не кешируют. Это глагол, который используют для гарантии соответствия порядка вызовов порядку выполнения.
Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Здравствуйте, Ikemefula, Вы писали:
I>По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
Почему? Не идемпотентные операциии должны приходить в нужном порядке, если на это нельзя рассчитывать, на бэкэнде придется городить очень сложные и хрупкие механизмы по искусственному выстраиванию этого порядка.
I>Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ?
Не чувствую.
I>Это называется download давным давно, достаточно погуглить по http post download
И что же показывает твой гугл? Мой показывает ссылки:
Is it possible to download a file with HTTP POST? — Stack Overflow
HTTP Download of large file with POST-Request — Chilkat Forum
Downloading a file via HTTP post and HTTP get in C# — Techcoil Blog
File download using HTTP request — Pulkit Goyal
Везде идет речь про скачивание файла и нигде нет твоего "устоявшегося" термина. Я не знаю, что это за практика и где ты ее нашел. Нигде не встречал, чтобы вызов API через POST назывался http POST download. Для чего ты сейчас настаиваешь на его употреблении?
I>Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Не получится выбрать потенциально кешируемый метод и не зависеть от настроек кеширования. Я напомню с чего мы начали, я попросил пример, где нужен pipelining запросов POST. Ты приводишь примеры где POST не лучший выбор и меняешь требования на ходу. Сначала требуешь реализовать stateless сервис, потом требуешь чтобы он перестал быть stateless.
Здравствуйте, Ziaw, Вы писали:
I>>По моему, при разработке бакенда не надо делать никаких предположений вида "запросы придут последовательно"
Z>Почему? Не идемпотентные операциии должны приходить в нужном порядке, если на это нельзя рассчитывать, на бэкэнде придется городить очень сложные и хрупкие механизмы по искусственному выстраиванию этого порядка.
I>>Ты снова злоупотребляешь телепатией. Я указал, а не применил. Разницу чувствуешь ? Z>Не чувствую.
Если я указываю на существование некоего явления, из этого никак не следует, что у себя в проекте я сделал ровно то же.
А вот с твоей точки рения это одно и то же, потому как разницы, по твоим же словам, не чувствуешь.
I>>Это называется download давным давно, достаточно погуглить по http post download Z>И что же показывает твой гугл? Мой показывает ссылки:
Z>Is it possible to download a file with HTTP POST? — Stack Overflow Z>HTTP Download of large file with POST-Request — Chilkat Forum Z>Downloading a file via HTTP post and HTTP get in C# — Techcoil Blog Z>File download using HTTP request — Pulkit Goyal
Z>Везде идет речь про скачивание файла и нигде нет твоего "устоявшегося" термина.
То есть, "устоявшаяся практика" ты читаешь как "устоявшийся термин" ? Блеск!
Читаем вместе — почти все результаты с первой страницы про скачивание через метод Post по протоколу HTTP. Самая первая ссылка датирована еще 11м годом, а чуть дальше и вовсе 2006й год. Дальше, если ты не заметил, у первой ссылки есть кучка похожих, ровно про то же. Вот это и значит, что вещь уже давным давно известна и применяется.
I>>Если "зависит от настроек кеширования", то в этом случае кеш у тебя стал стейтфул сущностью, что уже само по себе проблема. А вот пользователь ожидает, что после изменения настроек он получит ответ с уже примененными настройками.
Z>Не получится выбрать потенциально кешируемый метод и не зависеть от настроек кеширования. Я напомню с чего мы начали, я попросил пример, где нужен pipelining запросов POST. Ты приводишь примеры где POST не лучший выбор и меняешь требования на ходу. Сначала требуешь реализовать stateless сервис, потом требуешь чтобы он перестал быть stateless.
Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил.
Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс?
Здравствуйте, Ikemefula, Вы писали:
I>Если я указываю на существование некоего явления, из этого никак не следует, что у себя в проекте я сделал ровно то же. I>А вот с твоей точки рения это одно и то же, потому как разницы, по твоим же словам, не чувствуешь.
Я не утверждал, что ты что-то применяешь в проекте. Речь шла про применение термина.
I>То есть, "устоявшаяся практика" ты читаешь как "устоявшийся термин" ? Блеск!
Если ты вводишь термин и на указание о его не соответствии говоришь, что это устоявшаяся практика, именно так и читаю.
I>Читаем вместе — почти все результаты с первой страницы про скачивание через метод Post по протоколу HTTP. Самая первая ссылка датирована еще 11м годом, а чуть дальше и вовсе 2006й год. Дальше, если ты не заметил, у первой ссылки есть кучка похожих, ровно про то же. Вот это и значит, что вещь уже давным давно известна и применяется.
Какая вещь известна и применяется? Если скачивание файлов, про которое говорит гугл, то зачем ему pipelining?
I>Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил. I>Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс?
Не вижу смысла обсуждать толкование stateless. Что именно ты понимаешь под термином "http post download" которому мешает отсутствие pipelining?
Здравствуйте, ·, Вы писали:
·>Ну если только косвенно. Ничто не мешает поменять hg хранилище на аналогичное git (ну кроме разве что совместимости). Unix-way оно от этого не станет.
Тогда будет проще большинство операций делать простыми инструментами, которые заточены под конкретную мелкую задачу. Разработчики это быстро поймут и hg начнет двигаться в сторону unix-way. Вопрос не в количестве экзешников, а в универсальности элементарных операций.
И наоборот, когда разработка начинается с простых инструментов, структура хранилища проектируется так, чтобы им было удобно.
Здравствуйте, Ikemefula, Вы писали:
_>>С такими то тестами можно получить любой желаемы эффект.
I>А что не так с тестами?
Синтетические сильно: сейчас большинство фреймворков по умолчанию дают упаковку скриптов и стилей (и в некоторых случаях изображений), так что во многих случаях получается 3-5 файлов (включая саму страницу). С другой стороны массовая загрузка библиотек скриптов идёт с CDN, Yandex, google и прочего — т.е. отдельные соединения ко множеству сайтов, и фичи HTTP2 не так уж заметны в этом случае (грузится малое количество файлов из большого количества источников). Ну и 1000 запросов это само по себе синтетика — нужно специально постараться чтобы получить подобное в реальном проекте.
Здравствуйте, Ziaw, Вы писали: Z>Какая вещь известна и применяется? Если скачивание файлов, про которое говорит гугл, то зачем ему pipelining?
Ты похоже вообще не читаешь. I>>Конверсия как была, так и осталась стейтлесс. А вот если добавить вещи типа "поставить на паузу", "продолжить", "повторить два предыдущих шага конверсии" — вот это будет стейтфул. И нигде ничего подобного я не просил. I>>Тебя не смущает, что у стейтлесс сервисов есть база данных, сторадж, и они от этого не перестают быть стейтлесс? Z>Не вижу смысла обсуждать толкование stateless. Что именно ты понимаешь под термином "http post download" которому мешает отсутствие pipelining?
Кейс — юзер жмет кнопку и у него в браузере показывается окошко "download". Щас, похоже, ты будешь неделю уточнять что это такое ?
На всякий
Какой метод используется — по разному, чаще GET, но бывает и POST.
Теперь надо вспомнить историю веба. Поначалу всякие методы типа put, delete были дикой экзотикой и не проходили через промежуточные прокси и фаерволы.
Было два основных метода — get и post.
Post — через это работала самая обычная кнопка сабмит. Как закинуть файл на сервер ? Сабмит. Сабмит. Сабмит.
А как быть, если сервер не хранит промежуточное состояние, но надо реализовать навроде конвертора ? Сабмит. Сабмит. Сабмит. Сабмит. Сабмитаешь один файл, в респонсе получаешь другой.
Эта вещь такая же старая, как и весь интернет.
Почему нужен пайплайн — для тех же целей, что и в других случаях.
GEt имеет фундаментальное ограничение — в строку адреса и квери много не напихаешь. Как отсылать данные на сервер ? POST.
А если надо отослать данные на сервер и сразу принять их целую кучу ? Ну, скажем, обычный json из которого будет рендериться часть страницы на клиенте ? Делать два реквеста ? Зачем, если можно одним ?
Как реализовать функционал навроде конвертора если сервер не хранит промежуточное состояние ? POST.
Итого, основных вариантов http download всего два — get и post. Разница только в приседаниях со стороны браузера, для post надо делать дополнительные приседания, что бы вызвать то самое окошко.
Здравствуйте, Somescout, Вы писали:
_>>>С такими то тестами можно получить любой желаемы эффект.
I>>А что не так с тестами?
S>Синтетические сильно: сейчас большинство фреймворков по умолчанию дают упаковку скриптов и стилей (и в некоторых случаях изображений), так что во многих случаях получается 3-5 файлов (включая саму страницу). С другой стороны массовая загрузка библиотек скриптов идёт с CDN, Yandex, google и прочего — т.е. отдельные соединения ко множеству сайтов, и фичи HTTP2 не так уж заметны в этом случае (грузится малое количество файлов из большого количества источников). Ну и 1000 запросов это само по себе синтетика — нужно специально постараться чтобы получить подобное в реальном проекте.
Понятно, что синтетические. Такие тесты показывают, за счет чего будет профит и где именно.
Во первых, до сих пор слишком часто пишут, что де ручной бандлинг уже анти-паттерн, что де http2 всё разрулит как надо, что его мультплексор сделает всё в лучшем стиле. Я одно время даже поверил, потому что это приводилось в одной из книг, что я читал.
Во вторых, я, например, вижу, что все http2 версии сайтов работают намного быстрее и сильно замедляются, если отключить http2.
Здравствуйте, Ikemefula, Вы писали:
I>Это называется download давным давно, достаточно погуглить по http post download
Сам то гуглил?
По первой ссылке:
Looks like you'd like to generate the POST request from Javascript. I believe there is no way to get the browser to treat the result of an AJAX request as a download. Even if the Content-Type is set to something that browsers would normally offer as a download (e.g. to "application/octet-stream"), the browser will only deposit the data in the XMLHttpRequest object.
Furthermore, as you probably already know, there is no way to make window.open() issue a POST request.
I think the best way is to make an AJAX request which generates a file on the server. On the browser, when that request completes, use window.open() to download the generated file.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Это называется download давным давно, достаточно погуглить по http post download
НС>По первой ссылке:
Ты скромно скипнул сам вопрос и первый ответ
Читаем вместе:
Q: Is it possible to download a file with HTTP POST? I know the "Get" way(windows.location), but in my case, there are a lot of param that should be passed to server
A: Yes, the rest of a POST request can direct a browser to download a file. The file contents would be sent as the HTTP response, same as in the GET case.
С этим все понятно? Переводить нужно?
НС>Упс.
Твоя цитата фактически про это " I believe there is no way to get the browser to treat the result of an AJAX request as a download."
Перевожу, для тех у кого плохо с английским "Я не верю, что есть способ... "
Как часто бывает, пути веры несовместимы с инженерией. Но ты свой выбор сделал
На самом деле это используется ширше, например, тебе показывают превью того, что пришло с сервера, и только потом ты решаешь, сохранять это или нет. И никакого доп-реквеста не надо, ибо всё что надо, уже есть.
На счет самого http post download. Сам подумай, как работала кнопка сабмит, когда люди еще аджакс не изобрели. Был такой кейс — жмешь сабмит, отправляешь на сервак файл, сервер отдает тебе другой файл.
Как же это работало, каким чудом ?
И что интересно — по твоей же ссылке ответ, только чуть дальше — создаешь FormData, заполняешь, вызываешь руками Submit. И это тоже http post download, только без ajax.
НС>Сам то гуглил?
Здравствуйте, Ikemefula, Вы писали:
I>Кейс — юзер жмет кнопку и у него в браузере показывается окошко "download". Щас, похоже, ты будешь неделю уточнять что это такое ?
Нет, сейчас я спрошу, зачем ему pipelining?
I>Теперь надо вспомнить историю веба.
В другом топике пожалуйста.
I>Итого, основных вариантов http download всего два — get и post.
Плюс еще несколько. Которые используются в тех случаях, где нужно отправить что-то в теле запроса и не обломаться с pipelining.
I>Разница только в приседаниях со стороны браузера, для post надо делать дополнительные приседания, что бы вызвать то самое окошко.
Зачем ты мне рассказываешь про эти приседания? Какое отношение они имеют к теме?
Здравствуйте, Ziaw, Вы писали:
I>>Кейс — юзер жмет кнопку и у него в браузере показывается окошко "download". Щас, похоже, ты будешь неделю уточнять что это такое ?
Z>Нет, сейчас я спрошу, зачем ему pipelining?
см ответ 23 в этой ветке от 8го апреля. Чего тебе в том ответе не хватило ?
I>>Итого, основных вариантов http download всего два — get и post.
Z>Плюс еще несколько. Которые используются в тех случаях, где нужно отправить что-то в теле запроса и не обломаться с pipelining.
Какие именно эти варианты download ?
И как тебя обламывает pipelining если он по факту отключен чуть не везде ?
I>>Разница только в приседаниях со стороны браузера, для post надо делать дополнительные приседания, что бы вызвать то самое окошко.
Z>Зачем ты мне рассказываешь про эти приседания? Какое отношение они имеют к теме?
Затем, что когда я отвечаю на твой вопрос, цитирую буквально "Это download через POST реквест." тебе ответ непонятен. Это следует из того, что ты продолжаешь вопрошать, что же имелось ввиду под http post download.
Видишь ? Здесь прямой ответ на твой вопрос. А раз так, то я делаю вывод, что ты не в курсе, что такое download и почему это делается в не только через get, но и через post. Соответсвенно пытаюсь объяснить получше.
Итого — теперь тебе стало понятно, что имелось ввиду под "http post download" ? Надо эту часть мусолить ?
Здравствуйте, Ikemefula, Вы писали:
I>Итого — теперь тебе стало понятно, что имелось ввиду под "http post download" ? Надо эту часть мусолить ?
Давай сначала:
Я спросил:
— Интересно, а в каком месте это может стать проблемой?
Ты ответил невероятно кратко — http post download. Я усомнился в том, что я правильно тебя понял, потому, что при скачивании файла пайплайнинг не нужен от слова совсем. Поэтому я решил уточнить, что же это означает.
Порядка 10 постов ты выдавал разные версии и посылал меня в гугл, потом остановился на том это сохранение файла на диск из браузера. Когда я спросил, зачем там пайплайнинг — ты послал меня в другой пост, где речь идет про вызов API с получением множества JSON.
Может ты наконец перестанешь рассказывать мне разные истории про меня и про веб и ответишь, как можно было бы использовать пайплайнинг в http post download? Изложи сценарий по пунктам, без посылок в гугл, туманных цепочек вида А -> B -> C, скриншотов браузера и идиотских вопросов ко мне типа "тебе непонятно, что download бывает не только через GET?".
Здравствуйте, Ziaw, Вы писали:
I>>Итого — теперь тебе стало понятно, что имелось ввиду под "http post download" ? Надо эту часть мусолить ?
Z>Давай сначала:
Повторяю вопрос — стало ли тебе понятно, что я имею ввиду под "http post download" ? Я хочу получить однозначный ответ на этот вопрос.
Z>Порядка 10 постов ты выдавал разные версии и посылал меня в гугл, потом остановился на том это сохранение файла на диск из браузера. Когда я спросил, зачем там пайплайнинг — ты послал меня в другой пост, где речь идет про вызов API с получением множества JSON.
Цитирую в очередной раз:
Z>Это что?
Это download через POST реквест.
Что тебе здесь непонятно ? download, POST, реквест — какая часть этого ответа у тебя вызывает затруднение с пониманием ?
Z>Может ты наконец перестанешь рассказывать мне разные истории про меня и про веб и ответишь, как можно было бы использовать пайплайнинг в http post download? Изложи сценарий по пунктам, без посылок в гугл, туманных цепочек вида А -> B -> C, скриншотов браузера и идиотских вопросов ко мне типа "тебе непонятно, что download бывает не только через GET?".
Ты вероятно не заметил, что в таком тоне со мной смысла нет разговаривать ?
В статьях про http2 по сей день хором пишут, что де ручной бандлинг ни разу не нужен, можно без него.
Попробуй что ли денек или хотя бы пару часов без понтомёта пожить ?
