forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Ценой перевода Mercurial на Python 3 может стать шлейф непре..., opennews (ok), 14-Янв-20, (0) [смотреть все] +1

Хм Тут, скорее, вопрос о качестве кодовой базы Mercurial, kai3341 (ok), 23:09 , 14-Янв-20, (1) +22 //

Ну то есть вы, как специалист по кодовой базе Mercurial, имеющий многолетний опы, Аноним (8), 23:29 , 14-Янв-20, (8) +6 //

Вроде сами признали, по тексту новости сложилось такое впечатление Может вы что, brzm (ok), 23:42 , 14-Янв-20, (15) +5 //

Механический подсчет покрытия тоже не гарантирует ничего Вот, допустим, есть так, Аноним (30), 00:24 , 15-Янв-20, (30) +7

Удваиваю Покрытие ради покрытия ещё ни о чём не говоритОсобенно грустно, когда , kai3341 (ok), 00:38 , 15-Янв-20, (35)

Покрывать тестами надо и то, и другое Юнит-тесты хороши для библиотек, реализующ, Аноним (30), 00:46 , 15-Янв-20, (41) +1

В качестве ответа я сошлюсь на Линуса Не ломать юзерленд -- это значит не мен, kai3341 (ok), 00:50 , 15-Янв-20, (43) –1

А тут я полностью согласен Но тестами на API сложно покрыть edge cases в алгори, Аноним (30), 00:59 , 15-Янв-20, (53)

Очень вероятно, что мы называем одни и те же вещи разными словами Тест внешнего, kai3341 (ok), 01:09 , 15-Янв-20, (62) –1

Тут ещё вопрос, где API Например, в Solaris был баг в реализации qsort , котор, Аноним (30), 01:59 , 15-Янв-20, (70) +2

Принято Речь о тонкой границе, когда компонент реализации стабилизируется и ста, kai3341 (ok), 02:21 , 15-Янв-20, (75) –1

Вероятно, вы говорите о разных вещах одними словами И для этих разных вещей при, Аноним (221), 14:52 , 15-Янв-20, (221) +1

Спасибо Учту, kai3341 (ok), 15:13 , 15-Янв-20, (226) –1

Так вы, это, мутируйте поменьше, и никто никуда падать не будет , Вашье (?), 00:49 , 15-Янв-20, (42)

Это тоже ничего не гарантирует Точно такую же проблему можно показать и на чист, Аноним (30), 00:53 , 15-Янв-20, (45)
Иммутабельность не является гарантией отсутствия ошибок Иммутабельность не гара, kai3341 (ok), 00:53 , 15-Янв-20, (46)

Скрыто модератором, Anonymoustus (ok), 00:13 , 15-Янв-20, (26) +1 //

Скрыто модератором, Аноним (48), 00:55 , 15-Янв-20, (48) –2

Скрыто модератором, Anonymoustus (ok), 00:57 , 15-Янв-20, (51) +2

Скрыто модератором, Аноним (48), 00:59 , 15-Янв-20, (54) –1

Скрыто модератором, Аноним (88), 06:19 , 15-Янв-20, (88)

Скрыто модератором, Аноним (88), 06:19 , 15-Янв-20, (87)

Ситуация настолько очевидна, что наилучшее решение может огласить любой не-специ, Аноним (48), 00:57 , 15-Янв-20, (50)
Да тут к гадалке не ходи Ну подумайте хоть немного переход на Python3 давно с, myhand (ok), 12:50 , 15-Янв-20, (176) –1 //

Справедливости ради, у них не было стапятисот ваcянских плагинов, с которыми над, Аноним (183), 13:07 , 15-Янв-20, (183)

Вы знаете, тут все не так однозначно АПИ плагинам же не феи-валшебницы нарисов, myhand (ok), 18:41 , 15-Янв-20, (238)

Зашёл на сайт какой-нибудь pandas Нажал 171 get pandas 187 , 171 download , PereresusNeVlezaetBuggy (ok), 22:08 , 15-Янв-20, (256)

И рассказал об этом на opennet, а не мейнтейнерам Честно говоря, мне бы в голо, kai3341 (ok), 22:33 , 15-Янв-20, (257)

Я рассказал об этом человеку, который первый заговорил о pandas как о примере ка, PereresusNeVlezaetBuggy (ok), 00:21 , 16-Янв-20, (264) +2

У вас странная манера судить о качестве продукта Битая ссылка, которая никомуо, myhand (ok), 01:06 , 16-Янв-20, (266) +1

Я всего лишь зеркалил ущербную логику оппонента Странно, что вам это надо объяс, PereresusNeVlezaetBuggy (ok), 01:22 , 16-Янв-20, (268) +1

Как-бы я ваш оппонент, получается Так что ежели уж я не вижу у вас дажетени ло, myhand (ok), 10:19 , 16-Янв-20, (278)

Объяснял уже несколько раз говорить 171 pandas смог, почему же Mercurial не с, Аноним (8), 11:06 , 16-Янв-20, (281)

Рука бойца колоть устала Вам же объяснили почему это проекты одинакового разм, myhand (ok), 13:03 , 16-Янв-20, (287)

Кроме размера есть еще такое понятие как качество Но когда пишут на питоне - ре, Аноним (-), 17:29 , 18-Янв-20, (330) +1
Т е вы не можете по этому параметру сравнить два проекта на питоне Ну такнафи, myhand (ok), 18:12 , 18-Янв-20, (341)
То-есть я совсем другой тип и моя ремарка касалась исключительно аппеляций к раз, Аноним (-), 19:27 , 18-Янв-20, (343)
Увы, не заметно Ну вот как-бы у большинства гор гуано с переходом на третий , myhand (ok), 19:59 , 18-Янв-20, (347)
Не, не считаю - убунта версий 5 к ряду бодро репортила новых версий не обнаруже, Аноним (-), 20:08 , 18-Янв-20, (350) –1
А вы не думаете, что проблема была не в питоне, а в каком-нибудьохвисном гении и, myhand (ok), 21:03 , 18-Янв-20, (355)
Если б так прикалывались только эти компоненты - я бы в это поверил Но это вооб, Аноним (-), 17:46 , 20-Янв-20, (367)
На какой выборке вы оценили типичность и как Им - это бубунту Не использовал, myhand (ok), 08:58 , 21-Янв-20, (379)
На то что мне попадалось А так то конечно, если майнтайнеры за тебя подолбались, Аноним (-), 21:57 , 24-Янв-20, (393)
Т е как таковая статистика отсутствует, просто я щетаю было неудобно сразу пи, myhand (ok), 09:39 , 26-Янв-20, (403)

Что такое virtualenv и как им пользоваться -- это хорошие вопросы джуну на собес, kai3341 (ok), 04:28 , 16-Янв-20, (272)

Если мне на собеседовании начнут рассказывать, как это здорово 8212 плодить п, Аноним (8), 07:56 , 16-Янв-20, (275) +1

А для этого вообще луше go какой-нибудь освоить, чтоли Гугл с питона не просто , Аноним (-), 00:58 , 18-Янв-20, (301) –1

Ну сообщите об этом разработчикам, может они вдруг не знают Извиняюсь, а зачем, myhand (ok), 00:51 , 16-Янв-20, (265) +1

Сообщил, сообщил, не волнуйтесь Потому что если бы вдруг выяснилось, что оно мне, PereresusNeVlezaetBuggy (ok), 01:13 , 16-Янв-20, (267) +1

Не вижу бага Вы страдаете телепатией Вы понимаете, что RC - это RC, а не релиз, myhand (ok), 10:05 , 16-Янв-20, (277)

Нет, это вы страдаете невнимательностью, и я начинаю подозревать, что она перехо, Аноним (8), 10:22 , 16-Янв-20, (279) +1

В смысле отдельный От чего отдельный и причем это вообще тут Вы сами так реш, myhand (ok), 10:47 , 16-Янв-20, (280) –1

А как, интересно, вы проверяли, отправил ли я баг И вы ушли от ответа, почему я, Аноним (8), 11:40 , 16-Янв-20, (285)

По багтрекеру На мой взгляд, это проблема основного проекта, хотятехнически св, myhand (ok), 13:18 , 16-Янв-20, (288)

Значит, твой взгляд сильно отличается от взгляда разработчиков Pandas https g, Аноним (300), 00:00 , 18-Янв-20, (300)
Да я уж понял, что он открыл баг в другом репе Вы решили, что это правильно по, myhand (ok), 10:53 , 18-Янв-20, (320)
За напыщенное фееричное ламерство, например Хоть я и не тот аноним и не перерез, Аноним (-), 17:32 , 18-Янв-20, (331)
Может оно вам привиделось , myhand (ok), 18:07 , 18-Янв-20, (340)
Походу не мне одному А как минимум еще 1 анониму и перерезусу , Аноним (-), 19:28 , 18-Янв-20, (344)
До миллионов мух и с этим далеко, конечно , myhand (ok), 20:01 , 18-Янв-20, (349)
Дело хозяйское Но репутацию питонистов таки деятельно подтверждает , Аноним (-), 20:11 , 18-Янв-20, (351)

Лучше бы они его целиком на Rust переписали вместо этого, Аноним (2), 23:15 , 14-Янв-20, (2) –1 //

приступайте , Аноним (4), 23:17 , 14-Янв-20, (4) +12 //

Уже приступил https www mercurial-scm org wiki OxidationPlan, Анонимус2 (?), 13:29 , 15-Янв-20, (194) +3 //

И что самое смешное, чтобы переехать на Rust, им всё равно надо сначала переехат, PereresusNeVlezaetBuggy (ok), 01:32 , 16-Янв-20, (269)
Хипстеры как они есть - они там на самом деле модные моложедные ЯПы разучивают, , Аноним (-), 01:19 , 18-Янв-20, (302) –1

Вот этого точно не надо Дайте Mercurial умереть спокойно , burjui (ok), 00:41 , 15-Янв-20, (39) +9
Взяв за основу git как более успешный проект И назвать gitarust , Аноним (48), 00:58 , 15-Янв-20, (52) +6 //

Гита - подразумевается женское имя , Аноним (146), 11:23 , 15-Янв-20, (146) //

Индийское А в английском поработаю за КО слово гит означает мyдак Скромня, Аноним (183), 11:31 , 15-Янв-20, (154) +4

В индийских хинди- языках женские имена заканчиваются на -и На -а заканчиваетс, Аноним (239), 19:04 , 15-Янв-20, (239) +1
Мог удержаться, да автор комментария 154 , PereresusNeVlezaetBuggy (ok), 04:00 , 16-Янв-20, (271)

Это чтобы оправдать зваиние пихтонрастов , Аноним (88), 06:20 , 15-Янв-20, (89) –1
На расте уже пишут Пихуль , Аноним (127), 09:24 , 15-Янв-20, (127) //

Валентин Саввич Он вроде на расте не писал , Аноним (183), 13:18 , 15-Янв-20, (189) +3 //

https pijul org же ну, Аноним (205), 13:47 , 15-Янв-20, (205) +1

комментируя комментатора - не-майнтейнер полагает, что решение использовать для, Аноним (4), 23:17 , 14-Янв-20, (3) +8 //

два чаю этому анониму, freehck (ok), 23:29 , 14-Янв-20, (7) +1
Боюсь что когда вышел этот якобы модный-молодёжный язычок тебя ещё даже в планах, Аноним (12), 23:40 , 14-Янв-20, (12) +2 //

Питон язык модный И на нём пишет молодёжь Russian Do you speak it , freehck (ok), 23:45 , 14-Янв-20, (17) +2 //

Пиши на COBOL Будь не таким как все , kai3341 (ok), 00:05 , 15-Янв-20, (20) –3

8212 Программист Соренсон приветствует тебя 8212 Почему ты такая Что с то, Аноним (143), 11:20 , 15-Янв-20, (143) –2

У той молодёжи, которая модно писала на нём лет 20 назад, уже дети выросли, и вн, Аноним (48), 01:25 , 15-Янв-20, (67) –2

Вебмакакой можно быть в и 60 , Аноним (88), 06:21 , 15-Янв-20, (90) +4

Шестидесятилетних не знаю Знаю сорокалетних бабуинов, которые пишут на Java И , Аноним (183), 11:28 , 15-Янв-20, (151) –1

Ну он как бы low entry barrier, типа этакого современного варианта BASIC, чтоли , Аноним (-), 01:23 , 18-Янв-20, (303)

на эту роль прекрасно подходит LUA, а не этот ужас, Ananan (?), 21:41 , 18-Янв-20, (359) +1

20 А-ха-ха-ха-ха Двадцать лет назад только-только вышел питон 2 0 и о нем вообщ, Я (??), 11:12 , 15-Янв-20, (141) +2

и на нем тут же написали yum , поправил, не благодари , пох. (?), 11:30 , 15-Янв-20, (153) –1

Скорее стоит вспомнить up2date, предшественник yum-а в RHEL Тоже на Python Хотя, Аноним (183), 13:05 , 15-Янв-20, (182)

он ни разу не предшественник, он предшественник rhnЕго задачей было обновляться,, пох. (?), 13:29 , 15-Янв-20, (195) –1

и о боже, я понял если кто-то что-то написал на только что появившемся языке - , Урри (?), 13:30 , 15-Янв-20, (196) –1

Да там всё просто пишешь не на паскале 8212 ты 171 вебмакака 187 8482 , Аноним (183), 13:42 , 15-Янв-20, (203) –3
ну как бы если на только что появившемся языке пишут довольно существенную часть, пох. (?), 14:20 , 15-Янв-20, (215)

Бредятина какая-то Хотя Opennet , iPony129412 (?), 05:59 , 15-Янв-20, (86) –2

Нужно было сразу на Rust-е писать , Ями (?), 23:41 , 14-Янв-20, (14) //

Он тоже модно-молодёжный Есть же нормальные, проверенные временем языки Pascal,, Аноним (48), 01:14 , 15-Янв-20, (64) +2 //

макакам нормальные неизвестны - их вот в школе мучали паскалем - они запомнили п, Аноним (4), 07:22 , 15-Янв-20, (101) –3

Последние лет 20, НЯЗ, в школе программирование не выходит дальше Лого и Бейсика, Аноним (183), 11:26 , 15-Янв-20, (148)

Ну вот у нас на кафедре высшей математики до недавнего времени изучение программ, PereresusNeVlezaetBuggy (ok), 23:39 , 15-Янв-20, (259)

а мы потом слушаем сказочки что fuse это всегда в разы медленнее и неэффективне, пох. (?), 12:30 , 16-Янв-20, (286)

И что характерно, он в разу медленнее чем модуль в ядре Проверено exFAT и NTFS , Аноним (-), 01:30 , 18-Янв-20, (304) –1

Забыл самое главное 8212 не просто по желанию левой пятки, а _неожиданно_ и б, Аноним (48), 01:12 , 15-Янв-20, (63) +7 //

от ее ожидаемости , конечно же, само собой найдется время квалифицированных раз, Аноним (4), 07:21 , 15-Янв-20, (100) +4 //

Ну вот такие интересные разработчики - оказывается, могут себе позволить взять л, Аноним (-), 07:37 , 15-Янв-20, (108)

пока что наоборот - понемного разгребают, но не делают это приоритетом - о чем и, пох. (?), 11:34 , 15-Янв-20, (155)

Мы вроде одну и ту же новость прочитали Но я увидел там мигрировать тонны лапш, Аноним (183), 13:17 , 15-Янв-20, (188) +1
Боюсь, им бесполезно объяснять В их мире есть только те, кто одной левой выполн, Аноним (8), 08:52 , 16-Янв-20, (276) +1
Мы тут страдали легким прогрммизмом и сдуру вляпались, поэтому хрен его знает к, Аноним (-), 01:38 , 18-Янв-20, (305) –1

Только С и Git незыблемы и вечны , тот_же_анон_только_с_мабилы (?), 23:24 , 14-Янв-20, (5) +8 //

Про perl забыл , Аноним (12), 23:41 , 14-Янв-20, (13) +7 //

К счастью, в последнее время его гробницу оскверняют всё реже , Аноним (48), 01:01 , 15-Янв-20, (57) –3 //

если бы одна шибкопопулярная vcs не таскала ее примотанной к заднице - я бы в эт, пох. (?), 11:34 , 15-Янв-20, (156) +3

Советую почитать соседнюю новость Там как раз про то, что осквернять гробницы , Аноним (183), 11:51 , 15-Янв-20, (166) +2

начальная реализация еще одной мелкой фигни Ждите, ждите, еще лет десять - а , пох. (?), 12:00 , 15-Янв-20, (170)

Ну так перл в гите и нужен для нескольких мелких фиговин, вообще-то Гит 8212 , Аноним (183), 12:46 , 15-Янв-20, (175) +1

из которых он и состоит - поскольку в противном случае в сторону юзера вместо хо, пох. (?), 13:33 , 15-Янв-20, (198) –2

7 8212 это из которых он и состоит Ну ладно, окей, вы меня уели Не вижу с, Аноним (183), 13:40 , 15-Янв-20, (202)

а на самом деле было большой ошибкой продолжать совместимость Меркуриала с pytho, Аноним (6), 23:28 , 14-Янв-20, (6) //

Ну как это что Написано же в новости пытались обеспечить обратную совместимост, freehck (ok), 23:30 , 14-Янв-20, (9) +2 //

пофиксил , Аноним (34), 00:35 , 15-Янв-20, (34) –3 //

Прямо как в суровом энтерпрайзе кстати, у нас тут тоже коллективный плач по вто, Аноним (48), 01:05 , 15-Янв-20, (59) +1

вебмакакам и участь вебмакачья, Аноним (-), 06:54 , 15-Янв-20, (91)

Пусть покупают подписку на python2 EEE LTS ESR , Andrey Mitrofanov_N0 (??), 08:12 , 15-Янв-20, (121) +1

предлагаешь замутить стартап Хотя не, не покатит - тебе не дадут назвать интерпр, пох. (?), 11:28 , 15-Янв-20, (150) –1

При такой тяге к разгребанию за другими - дворником все ж менее мучительно будет, Аноним (-), 01:43 , 18-Янв-20, (306) –1

настоящему энтерпрайзу никто не мешает спокойно пользоваться дальше вторым питон, пох. (?), 11:29 , 15-Янв-20, (152) –1

Люблю теоретиков Как работает система пакетов в питоне 8212 не знает, но мне, Аноним (183), 11:39 , 15-Янв-20, (162) +1

классный у вас ентер-прайс Каждый день, или просто при каждом запуске пипискает, пох. (?), 11:52 , 15-Янв-20, (167) +1

Не каждый день, но в некоторых ситуациях например, при наличии специфических --, Аноним (183), 12:39 , 15-Янв-20, (173) –1

Хана вам , Урри (?), 13:35 , 15-Янв-20, (199) +1
в моем случае пересобрать - не получится,он не знает, из чего их собирать и как , пох. (?), 13:36 , 15-Янв-20, (200) –1

Конечно, вам виднее Что-то, правда, мне подсказывает, что вы никогда не видели , Аноним (8), 23:32 , 14-Янв-20, (11) +1 //

мда, так ценят целостность репозиториев, что выбрали язык без типов и при этом д, annual slayer (?), 00:09 , 15-Янв-20, (22) //

Git написан на , Аноним (44), 00:52 , 15-Янв-20, (44) –1

Неужели тоже на языке без типизации , Аноним (48), 01:03 , 15-Янв-20, (58) +1

Ужас, как дальше жить , Аноним (30), 02:04 , 15-Янв-20, (71)
perl, который который позволяет обфусцировать код прямо из коробки, Аноним (78), 02:34 , 15-Янв-20, (78) –2

там на перле и баше написаны только вспомогательные утилиты которые дергают в, annual slayer (?), 05:23 , 15-Янв-20, (81)
C 48 8 Shell 35 7 Perl 6 7 Tcl 4 6 Python 2 0 Makefile 0 8 Other 1 4 Хорошо нынч, Аноним (183), 13:22 , 15-Янв-20, (191) +2

а это-то там где tcl bindings столько занимают , пох. (?), 14:22 , 15-Янв-20, (216) –2

Здрастье, штатный GUI gitk на tcl tk, Аноним (220), 14:44 , 15-Янв-20, (220) +1

аааа У него есть штатный gui в ужасе убегает в сторону ближайшего окна , пох. (?), 18:06 , 15-Янв-20, (232) –1

В основном на сях, с прослойками на шелле и перле местами В сях типы таки есть , Аноним (-), 06:54 , 15-Янв-20, (92) –1

В сях типы таки так себе , funny.falcon (?), 10:58 , 15-Янв-20, (134) +2

Типы как типы, уж получше чем у всяких питоноявоскриптов - по крайней мере, комп, Аноним (307), 01:48 , 18-Янв-20, (307)

cloc git-2 25 0 code Language files blank , анонн. (?), 13:24 , 15-Янв-20, (192)

это может быть сборочницей, а не необходимым для работы собранного И скорее всег, пох. (?), 14:23 , 15-Янв-20, (217) –1

https github com git git blob master contrib git-resurrect shhttps github co, анонн. (?), 16:24 , 15-Янв-20, (229)

так ценят - что у них - получилось Я ни одного поломавшегося репозитория на hg н, пох. (?), 11:25 , 15-Янв-20, (147) +1

Действительно вряд ли придется Много у тебя вообще репозиториев на ртути было-т, Аноним (174), 12:43 , 15-Янв-20, (174)

больше чем на svn, во всяком случае по очевидным причинам - которому таки прих, пох. (?), 14:26 , 15-Янв-20, (218)

работало-работало, да вот перестало, annual slayer (?), 13:54 , 15-Янв-20, (210)

в ужасе убегает делать hg verify не, врут - как работало, так и работает , пох. (?), 14:11 , 15-Янв-20, (212)

автор говорит, что не должно, а у тебя работаетможет, помоги пацанам, раз ты так, annual slayer (?), 14:58 , 15-Янв-20, (223) –1

а, я не увидел твой никнейм, тогда ничего кроме комментов на опеннете от тебя ож, annual slayer (?), 14:59 , 15-Янв-20, (224)

Вы тут сами с собой общаетесь , АнонАнон (?), 17:46 , 15-Янв-20, (230) +1

всего навсего не могу редактировать сообщения, annual slayer (?), 19:40 , 15-Янв-20, (241)

автор говорит что могут быть проблемы у пользователей новых модных дистрибутивов, пох. (?), 18:12 , 15-Янв-20, (235) +1

ну в немодных обещают питон2 дропнуть в 2024 или 2025 даже автор ртути признал, annual slayer (?), 19:40 , 15-Янв-20, (240)

-rw-r--r-- 1 root root 118 Nov 2 2011 etc os-releaseкак ты думаешь, мне есть , пох. (?), 20:18 , 15-Янв-20, (244)

Вместо продуктивной активности по добавлению тестов или сизифова труда по миграц, annual slayer (?), 07:05 , 16-Янв-20, (273)

назовите целое одно такое исправление и дату когда оно сделано И отдельно - расс, пох. (?), 11:08 , 16-Янв-20, (282)
https www cvedetails com vulnerability-list vendor_id-8291 Mercurial htmlи это, annual slayer (?), 15:37 , 16-Янв-20, (290)
то есть назвать - вы не можете Что и требовалось доказать тем кому пользоваться, пох. (?), 18:01 , 16-Янв-20, (291)
продолжай себя утешать, что первым 6-и багам в списке, проявляющимся в том числе, annual slayer (?), 23:08 , 16-Янв-20, (292)
главное - веровать Разбираться или просто понимать о чем речь - необязательно , пох. (?), 11:16 , 17-Янв-20, (293)
ну вот и веруй, что никто не разобрался как эксплуатировать те возможностиа гит , annual slayer (?), 17:24 , 17-Янв-20, (295) +1
ну, вот тебе - точно не судьба Ты так и не удосужился посмотреть описания Или , пох. (?), 18:56 , 17-Янв-20, (296)
Если ремота захочет тебе rce сделать, есть способы проще Например, код тебе отг, Аноним (307), 01:51 , 18-Янв-20, (309) –1
Да наверняка море всего Качество в софте на питоне и не ночевало - там кодят ск, Аноним (332), 17:41 , 18-Янв-20, (332)

У них получилось Облажаться на публику , Аноним (307), 01:49 , 18-Янв-20, (308)

будущее Python 3 тогда было туманным, его судьба могла сложиться как у Perl 6, cio (?), 23:48 , 14-Янв-20, (18) +4 //

прямо все 12 лет с 2008-го года было туманным , annual slayer (?), 00:10 , 15-Янв-20, (23) //

а когда жареный петух в жoпу клюнул -- че-то резко всё прояснилось сразу, annual slayer (?), 00:11 , 15-Янв-20, (24) +1
До 1 января 2020 никто не верил, что это всерьёз Думали, завтра проснутся, а не, Аноним (48), 01:08 , 15-Янв-20, (61) +5

А в третьей ветке великолепная обратная совместимость с самой собой Да, анон , Anonymoustus (ok), 00:17 , 15-Янв-20, (27) +3 //

Именно поэтому в демьяне майнтайнеры откалывали знатные тантры перед релизом, по, Аноним (-), 06:56 , 15-Янв-20, (93) +2 //

Если б только в Debian Все, кто независимую пакетную базу поддерживает, наелись, PereresusNeVlezaetBuggy (ok), 23:49 , 15-Янв-20, (262) +1

Ну так если не заметили, многие уже с питоном наигрались и наелись вот такого сч, Аноним (307), 01:52 , 18-Янв-20, (310)

Меркуриал модульный, для него написана масса сторонних расширений Такой переход, Аноним (30), 00:30 , 15-Янв-20, (33) +3 //

Да, должны Не смогли - до свидания Ваше расширение очень важно для нас Настол, Аноним (34), 00:40 , 15-Янв-20, (38) –6 //

Тут недавно FF стороение дополнения дррпнул, Аноним (44), 00:54 , 15-Янв-20, (47) +2

Ну так у него юзербаза за это тоже неплохо дропнулась Скоро придется им быть шк, Аноним (105), 07:31 , 15-Янв-20, (105) –1

Ух ты, все решается одной консольной командой Срочно расскажите разработчикам m, Аноним (30), 02:09 , 15-Янв-20, (72) +1

Вот ты и расскажи Я тольго гитом пользуюсь из VCS , Аноним (34), 02:26 , 15-Янв-20, (77) –3
код на питоне без тестов только умные и пишут, annual slayer (?), 05:28 , 15-Янв-20, (82)

Обкладывать картонный макет программы тестами Хы , Аноним (105), 07:30 , 15-Янв-20, (104) +1

ну перед тем как переписывать с макета на чистовик по-нормальному - да, обкладыв, annual slayer (?), 13:57 , 15-Янв-20, (211)

юнит-тесты так не работают Впрочем, и волшебной панацеей тоже не являются , пох. (?), 18:57 , 17-Янв-20, (297)

Обложить макет тестами А потом подумать - тесты мол, некачественные, давайте их, Аноним (-), 01:55 , 18-Янв-20, (311)
просвяти всех как они работают D особенно в контексте рефакторинга прототипа в , annual slayer (?), 02:25 , 18-Янв-20, (314)

У него врядли есть духовный сан с таким то ником Если про юнит тесты, это прим, Аноним (332), 17:49 , 18-Янв-20, (333)

для этого и меряют покрытие тестамии это даже не говоря о том, что в большом про, annual slayer (?), 18:28 , 18-Янв-20, (342)

Ясен перец Правда и они тоже не панацея Натурные эксперименты показали что есл, Аноним (-), 19:34 , 18-Янв-20, (345)
согласен, забыл упомянуть про fuzzingно им обычно тестируют не совсем то же само, annual slayer (?), 21:35 , 18-Янв-20, (357)
так же я забыл упомянуть, что coverage обычно не учитывает диапазоны значений вх, annual slayer (?), 21:40 , 18-Янв-20, (358)
Отож Особенно актуально для алгоритмов и прочей core-логики А смысл Даже если , Аноним (-), 18:02 , 20-Янв-20, (369) –1
я предполагаю, это могло бы сократить время написания тестов для UI и как замена, annual slayer (?), 18:20 , 20-Янв-20, (371)
Частично делается заскриптованными тестами, но это специфично для прог и все-так, Аноним (-), 21:12 , 20-Янв-20, (376)
ну да, пожалуй задать вручную BVA для GUI тестов будет проще чем пытаться исполь, annual slayer (?), 18:47 , 21-Янв-20, (381)

Хром Хромиум Ничё, жив пока , Аноним (146), 11:36 , 15-Янв-20, (158)
Ну да, можно подумать что hg ожидают радужные перспективы , myhand (ok), 12:53 , 15-Янв-20, (177)

Большой ошибкой было использовать неподходящий инструмент для написания Mercuria, Vkni (ok), 02:12 , 15-Янв-20, (73) +3 //

Они одним только названием намекали что проект какой-то токсичный , Аноним (-), 06:57 , 15-Янв-20, (94)
когда они это затевали - во-первых, надо было быстро очень неудобно жить вообще, пох. (?), 11:21 , 15-Янв-20, (144) //

Делается прототип если взлетел, и понятно, что надолго - переписывается на что-, Vkni (ok), 18:22 , 15-Янв-20, (236) –1

начать переводить на ветку 3 6 или какая она там стала в 2009м, внезапно-снова-н, Аноним (4), 07:28 , 15-Янв-20, (103) +1

Очень правильные слова Это настолько болезненно - переходить с питона 2 на пито, Аноним (10), 23:32 , 14-Янв-20, (10) +3 //

Да уже который год говорю, где обманывают посмотрите на то, в каком состоянии , freehck (ok), 23:43 , 14-Янв-20, (16) +1 //

Не мертвый, а стабильный И это прекрасно, потому что предсказуемо , Аноним (32), 00:30 , 15-Янв-20, (32) +6 //

Именно Ну вон прога на C89 До сих пор компилится и работает При желании ее да, Аноним (-), 07:02 , 15-Янв-20, (95) +3

Хочешь расскажу где лежат исходники CPython 2 2, например Вот прикинь, если те, myhand (ok), 13:15 , 15-Янв-20, (186) –3

хочешь я расскажу тебе страшное и чтобы скомпилировать ту прогу на C89 - вовсе , пох. (?), 14:13 , 15-Янв-20, (213) +1

Ну да, бедные разработчики тянут весь зоопарк стандартов Только нормальные ср , myhand (ok), 16:08 , 15-Янв-20, (228) –1

бедняжечки Как же это оказывается сложно - просто держать шаловилвые ручонки , пох. (?), 20:24 , 15-Янв-20, (245)

Ну вообще-то - это сложно Приходится не просто не трогать , а обставлять все , myhand (ok), 21:39 , 15-Янв-20, (252) –1

При том в последнее время достигают в этом определенных успехов Оплот пихтонрас, Аноним (-), 02:00 , 18-Янв-20, (313) –1

Новые стандарты в массе своей - superset старых За редким исключением А так чт, Аноним (-), 14:46 , 18-Янв-20, (321)

Тем не менее, быват, быват Гениальные дизайнеры языка, планирующие наполвека в, myhand (ok), 17:50 , 18-Янв-20, (334)

Конкретные примеры Я вот целый _1_ могу с наскока вспомнить Крайне специфичный, Аноним (332), 19:47 , 18-Янв-20, (346) –1

Ну соберите мне третьекеды на современной системе, что ли Да куда там кеды, тут , анонн (ok), 20:39 , 18-Янв-20, (353)

Проект TDE занимается как раз этим самым И в каком месте зацитированное вообще, Аноним (-), 18:19 , 20-Янв-20, (370) –1
И Хотите сказать, что раз целый отдельный проект занимается этим, то это однозн, анонн. (?), 20:35 , 20-Янв-20, (375)
Я хочу сказать что проблемы третьекедов вытекают не из компилеров и сей А из 1 , Аноним (-), 22:55 , 20-Янв-20, (377) –1

Да берете стандарт и просто делаете поиск В С11, например, gets удалена Или , myhand (ok), 20:55 , 18-Янв-20, (354)

Как inherently dangerous function И тем не менее, C89 код таки соберется В р, Аноним (-), 18:58 , 20-Янв-20, (372) –1
Да, детка Вы начинаете понимать принцип Ну типа того Как максимум компиле, myhand (ok), 09:57 , 21-Янв-20, (380)
Ну так в результате я могу юзать вон тот древний код с вот этим свежим компилеро, Аноним (395), 23:22 , 24-Янв-20, (395) –1
То, что это может быть любой компилер, если этот компилер - не слишком свежий g, Аноним (398), 15:04 , 25-Янв-20, (398)
Совсем забыл Помимо того, что сам аргумент перевода стрелок на знакомых , без к, Аноним (398), 15:29 , 25-Янв-20, (399)
Так и на питоне это можно И это по-идее, тоже можно Хотя к чести питона, до си, myhand (ok), 11:11 , 26-Янв-20, (404)
gt оверквотинг удален Ну, вообще говоря, если вы пишете программу под конкретн, Anonymoustus (ok), 18:54 , 23-Янв-20, (383)
Я вам тут не ассемблерщик я прогал на нескольких асмах, но - надоело , и таки и, Аноним (-), 22:12 , 24-Янв-20, (394)

Зачем мне это После пары жирных обломов жизнь научила меня что закладываться на, Аноним (-), 01:59 , 18-Янв-20, (312)

А мне почем знать зачем ты плакался по поддержке старых версий интерпретатора , myhand (ok), 10:48 , 18-Янв-20, (319)

Ну наверное не для того чтобы за гвидо его факапы разгребать Хотя если liquidat, Аноним (-), 20:17 , 18-Янв-20, (352)

А не надо писать на Питоне вещи, которые стоит поддерживать Это отличный инстру, Vkni (ok), 02:16 , 15-Янв-20, (74) –5 //

Кому мало можно посмотреть на историю успеха редхата, которые за наверное 20 л, Аноним (-), 07:06 , 15-Янв-20, (96) +2

простите, но унести с собой БД он не может - у него ее нет Индексы репо - не бд, Аноним (4), 07:32 , 15-Янв-20, (106)

А почему при OOM усе улетает с жоским стэктрейсом и при следующих попытках что-л, Аноним (-), 07:51 , 15-Янв-20, (113) –1

а почему у тебя при установке пакетов - oom У меня вот нет никаких oom, а если , пох. (?), 11:09 , 15-Янв-20, (140) –1

Где у FreeBSD yaml , Dimon (??), 11:28 , 15-Янв-20, (149) –1

Скрыто модератором, пох. (?), 11:36 , 15-Янв-20, (159) –2

Скрыто модератором, Аноним (183), 11:41 , 15-Янв-20, (163)

Скрыто модератором, пох. (?), 11:47 , 15-Янв-20, (165) –3
Скрыто модератором, Аноним (398), 13:53 , 15-Янв-20, (209) –1

Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случа, Аноним (398), 13:47 , 15-Янв-20, (204)

вы уж определитесь, мущина - туда либо сюда Если вам понадобилось их человекочи, пох. (?), 14:14 , 15-Янв-20, (214) –1

Только после того, как вы раскроете тайну просачивания пробела в автоматически, Аноним (398), 14:57 , 15-Янв-20, (222) –1

Абсолютно XML одинаково хреново парсится и человеками и машинами , Аноним (-), 17:23 , 18-Янв-20, (329)

Как показали эксперименты, Дебиан в тех же конфигурациях ведет себя культурно М, Аноним (-), 17:18 , 18-Янв-20, (328)

Недавно я по глупости запустил yum update из сеанса ssh, работающего через VPN , Аноним (183), 11:59 , 15-Янв-20, (169) –1

Дарю идею у дебиана нормальный пакетный менеджер И следующие 5 лет с 10-м деби, Аноним (-), 14:54 , 18-Янв-20, (322)

Только если раскатывать из образа каким-нибудь dd Установить актуальный Debian , Anonymoustus (ok), 18:57 , 23-Янв-20, (384)

Ну как бы 128 у меня бывает только на виртуалках И cp --reflink template new, Аноним (-), 00:24 , 25-Янв-20, (396) –1

Причём он отличный в каждой минорной версии , Led (ok), 15:07 , 15-Янв-20, (225) +20

Совершенно верно И профессионал должен это знать, и не должен использовать инст, Vkni (ok), 18:06 , 15-Янв-20, (231) –17

расскажите же, о гуру - чем же назначение пихона 3 5 отличалось от назначения пи, пох. (?), 20:26 , 15-Янв-20, (246)

Практически ни в чём Ключевое тут - меняется от версии к версии Очевидно, что , Vkni (ok), 23:45 , 15-Янв-20, (261) –6

в 2005м году, видимо, было еще далеко не очевидно Надо было быть не профессионал, пох. (?), 19:14 , 17-Янв-20, (298)

Извините, но вся около-питоновская культура - это менять и не бояться выбрасыва, Vkni (ok), 20:55 , 17-Янв-20, (299) –2

первый релиз NumPy - 2006 первый релиз IPython - 2001 matplotlib - 2003 pan, myhand (ok), 10:42 , 18-Янв-20, (317)

Эти библиотеки просты как валенки, плюс туда вливаются совершенно сумасшедшие ср, Vkni (ok), 16:43 , 18-Янв-20, (324)

Эм Крестик или трусы Ну, во-первых, там не только вычматовские А во-вторых,, myhand (ok), 18:05 , 18-Янв-20, (338) –1
Поддерживаю по каждому пункту, Vkni увы, модеры не могут ставить плюсики, так ч, freehck (ok), 19:53 , 23-Янв-20, (388)
Т е вы тоже считаете, что на питоне нельзя строить что-либодолгосрочное, несмот, myhand (ok), 10:12 , 24-Янв-20, (389)
Можно, но это потребует значительно больших вложений сил Всё это тьюринг-полные, Vkni (ok), 22:44 , 25-Янв-20, (400)
Отлично Флаг вам в руки объясняйте почему есть куча проектов,не ленящихся исп, myhand (ok), 11:15 , 26-Янв-20, (405)
Потому что в ряде случаев субъект, выбирающий язык, ориентируется на что-то внеш, Vkni (ok), 20:40 , 26-Янв-20, (409)
Ну что вы, кроме пользователей OCaml ведь все - мазохисты А вот это как раз ра, myhand (ok), 11:30 , 27-Янв-20, (410)
У меня давно сложилось впечатление, что - ставят боты или люди с примерно той ж, Vkni (ok), 22:51 , 25-Янв-20, (402) –1
Если комментарий многабукав, причем сильно заминусованный или реже наоборот - , myhand (ok), 11:18 , 26-Янв-20, (406)
Имхо, - есть в некотором смысле показатель солидарности со мнением Чем писать , freehck (ok), 19:12 , 26-Янв-20, (407)
Ну странный какой-то показатель Вот у меня в практически всех комментах здесь м, Vkni (ok), 20:34 , 26-Янв-20, (408)
Ну так откуда-то оттуда змий и полез И вот там это и правда никому не создает п, Аноним (397), 00:28 , 25-Янв-20, (397)
Более того, там это очень полезно Например, текст в значительной части Wolfram , Vkni (ok), 22:50 , 25-Янв-20, (401)

А чего, с прохвессионалов-разработчиков не требуют более навыков чтения Эта ст, myhand (ok), 10:34 , 18-Янв-20, (315) –1

вот лохи и повелись А оно херак, и в полете - переобулось Оказывается все таки , пох. (?), 10:39 , 18-Янв-20, (316)

the first ever intentionally backwards incompatible Python releaseМне делается с, myhand (ok), 10:45 , 18-Янв-20, (318) –1

Interviewed Friday morning, foundation representative David Goodger said We fix, пох. (?), 16:36 , 18-Янв-20, (323)

А библиотеки вы вообще не учитываете Основная проблема же в том, что библиотеки, Vkni (ok), 16:46 , 18-Янв-20, (325)

Ты сделал мой день, Led Аж слеза навернулась , freehck (ok), 15:10 , 16-Янв-20, (289) +1

Редчайший случай, когда он написал что-то умное, а не просто наследил в коммента, Anonymoustus (ok), 19:35 , 23-Янв-20, (385)

Пожалуйста, ребята, не ссорьтесь , freehck (ok), 19:45 , 23-Янв-20, (387)

Посмотрите на гражданина, до сих пор не умеющего в читать документацию Прям можн, myhand (ok), 13:04 , 15-Янв-20, (181) –3 //

А еще этот негодяй наверное миноискатель дома забыл, так что если ему кто на пут, Аноним (373), 19:07 , 20-Янв-20, (373)

Хорошая документация - это растяжка , myhand (ok), 08:56 , 21-Янв-20, (378) –1

Если в нее после каждой минорной версии вштыривать надо - пожалуй что да , Аноним (413), 22:20 , 17-Фев-20, (413)

В последнее время, Python че-то не туда шагнул То все эти асинхронные фишки ско, menangen (?), 23:52 , 14-Янв-20, (19) //

Место BDFL всё ещё вакантно Не упусти свой шанс решать, куда шагать python уВид, kai3341 (ok), 00:22 , 15-Янв-20, (29) –2 //

Зря ты это затеял 8212 объяснять не-программистам всякие технические кишки О, Аноним (48), 01:23 , 15-Янв-20, (66) +2 //

Бро, каникулы скоро закончатся, и можно будет спокойно продолжать о технических , kai3341 (ok), 01:32 , 15-Янв-20, (68)
Зелен виноград , Аноним (133), 10:55 , 15-Янв-20, (133) +1

Срочно разыскиватеся диктатор с мазохистичными наклонностями А, погодите, может, Аноним (97), 07:13 , 15-Янв-20, (97) +1 //

Посмотрим на Go2 Как бы они пытаются сломать как можно меньше, но проблема в то, Java (?), 07:54 , 15-Янв-20, (114)

Хипстерам вообще полезны иногда отрезвляющие клизмы с патефонными иголками , Аноним (-), 08:12 , 15-Янв-20, (120)

А где же тот чувачок, который несовместимая 3-я версия это лучшее что случил, Аноним (21), 00:09 , 15-Янв-20, (21) +2 //

А разве обсуждаемая новость как-то опровергает его слова , Аноним (48), 01:19 , 15-Янв-20, (65) +6

Я бы им посоветовал переписать всё на I стабильном I языке 8212 на Перле, , Anonymoustus (ok), 00:11 , 15-Янв-20, (25) +5 //

На COBOL 60 Куда уж стабильнее , Аноним (30), 00:38 , 15-Янв-20, (36) –2 //

Если бы ты понимал, зачем был создан КОБОЛ и почему он такой, тебе бы не казалас, Anonymoustus (ok), 00:40 , 15-Янв-20, (37) +4 //

И для чего же, по вашему мнению Неужели для написания DVCS К COBOL-у как так, Аноним (30), 00:56 , 15-Янв-20, (49) –2

Люто плюсую Желать что-то долговечное на Пистоне моветон , псевдонимус (?), 03:44 , 15-Янв-20, (80) //

Вот люди и взорвались на мине замедленного действия , Anonymoustus (ok), 19:36 , 23-Янв-20, (386)

ССЗБ , Аноним (34), 00:21 , 15-Янв-20, (28) –3
Держать годами техдолг - сами виноваты Перешли бы раньше - отладили бы раньше Я, Аноним (34), 00:29 , 15-Янв-20, (31) –2 //

Какие смузи пьёшь Обтягивающие джинсы кровоток перекрывают Нравится все ново-м, Аноним (55), 01:01 , 15-Янв-20, (55) +3 //

Если я правильно понял, он сказал, что сидел на тупиковом овне мамонта 5 лет чт, Аноним (69), 01:43 , 15-Янв-20, (69) //

На самом деле я на 2 вообще не сидел Я просто в 2013 начал на питоне кодить, та, Аноним (34), 02:23 , 15-Янв-20, (76) –3

Да что там, кеды жмут , Аноним (-), 08:01 , 15-Янв-20, (116) //

Тогда надо на гном переходить , Аноним (183), 11:38 , 15-Янв-20, (161) +1

пью джинсы с подваротами смузи кровоток не перекрывают все норм чтяднт , еукеекнмсч (?), 22:34 , 15-Янв-20, (258)

Пофиксил , Аноним (-), 07:16 , 15-Янв-20, (98) +1 //

Поделил на ноль , Аноним (183), 12:59 , 15-Янв-20, (178) –3 //

Ну, э, блин, если инноваторы тебе фирмвару твоему гироскутеру на пихоне накатают, Аноним (-), 17:57 , 18-Янв-20, (335)

- Может Да они оптимисты, впрочем, никогда не было и вот опять , Аноним (79), 03:10 , 15-Янв-20, (79) +4
Я не питонист, но неужели эти языки питон 2 и питон 3 ведут себя настолько по-, Аноним (83), 05:49 , 15-Янв-20, (83) //

Более того - взяв произвольный скрипт на допустим 2 4 на более актуальном сейчас, Аноним (105), 07:27 , 15-Янв-20, (102) //

вообще-то ровно наоборот - это - скорее всего заработает Не заработает 2 7 код н, Аноним (4), 07:46 , 15-Янв-20, (111) –1 //

Мой опыт ровно обратный Ну это уже какая-то экзотика, обычно в системе версии со, Аноним (-), 08:05 , 15-Янв-20, (117) –1

По Net прусы будет , Anonymqwe (?), 10:01 , 15-Янв-20, (130) //

Лично видел как при выпуске очередного дотнета померла шикарная жирная энтерпрай, Аноним (-), 17:59 , 18-Янв-20, (336)

А на следующее утро отошел, и понял, что алкоголь не стояло мешать с грибами, а , Ононимко (?), 14:38 , 19-Янв-20, (363) –1

Не алкоголь а кофе, и не я а прогеры и сапорты, очешуевшие пахать сверхурочно , Аноним (413), 22:22 , 17-Фев-20, (414)

читай оригинал новости надеюсь, нипихианист может в английский Да, настолько , Аноним (4), 07:36 , 15-Янв-20, (107)
Буква 171 B 187 в слове 171 Python 187 означает 171 Backward compatibi, Anonymoustus (ok), 07:48 , 15-Янв-20, (112) +6 //

Кстати, где эта буква в слове C , Аноним (183), 13:01 , 15-Янв-20, (179) //

В книжке K R , Anonymoustus (ok), 13:02 , 15-Янв-20, (180)

Тогда для питона 8212 ищите её в Dive into Python , Аноним (183), 13:12 , 15-Янв-20, (184) –1

Что же там пишут про обратную совместимость, аноним Почему релизы третьей ветки, Anonymoustus (ok), 13:14 , 15-Янв-20, (185)

Можно пример , myhand (ok), 13:16 , 15-Янв-20, (187)

print 3 2Сойдёт за пример , Аноним (183), 13:25 , 15-Янв-20, (193)

SyntaxError Missing parentheses in call to print Did you mean print 3 2 Мож, myhand (ok), 18:40 , 15-Янв-20, (237)

у него - 3 5, где так - было еще можно, хотя уже нельзя , Аноним (4), 19:55 , 15-Янв-20, (243)

Пишут что проще утонуть, Аноним (255), 22:05 , 15-Янв-20, (255) +1

Уже весь мир перешел на python3, а быдлокодеры из меркуриал продолжают всем дока, Аноним (84), 05:53 , 15-Янв-20, (84) –2 //

ты-то не быдлокодер, ты бы за пять минут все переписал А, не, ты вообще не умее, Аноним (4), 07:43 , 15-Янв-20, (110) //

Я же не из меркуриал-тим, чтобы переписывать за пять минут, у меня на это было б, Аноним (115), 07:56 , 15-Янв-20, (115) //

у тебя на это была бы - вечность, каждый год - снова с нуля переписывать А работ, Аноним (4), 08:10 , 15-Янв-20, (118) +1
- Эй, чуваки, у нас тут корабль тонет Все к насосам - Я вам тут не матрос вод, Аноним (-), 08:14 , 15-Янв-20, (122) +1

Скорее Врагу не сдаётся наш гордый Варяг, пощады никто не желает , Аноним (183), 12:02 , 15-Янв-20, (171) +1

Одному мне кажется, что подавляющему количеству пользователей Mercurial неумение, йкЛще (?), 09:18 , 15-Янв-20, (125) +1 //

Им пох Нам вот с результатами их неумения жить приходится - это да, некстати Н, пох. (?), 10:58 , 15-Янв-20, (135) –1

Нужно было похоронить проект python 2 и переименновать его во что то другое при , Аноним (85), 05:57 , 15-Янв-20, (85) –1 //

они так и сделали Но умирающий язык - это язык на котором не ведут и не поддер, Аноним (4), 07:40 , 15-Янв-20, (109) +2 //

На PHP 4 вообще-то очень много чего успели понаписать, от форумных движков до ph, PereresusNeVlezaetBuggy (ok), 00:04 , 16-Фев-20, (411)

Весь Питон в этой фразе В нём без дебагера дальше хелоуворда не уйти , Аноним (99), 07:18 , 15-Янв-20, (99) +6
Проект опенсорсный бесплатный программистам не заплатили за него И вот чем , Адекват (ok), 08:11 , 15-Янв-20, (119) –8 //

Даже какой-нибудь дропбокс, который таки мог оплачивать программистов, с питона , Аноним (-), 08:15 , 15-Янв-20, (123) //

потому что проблем с ними все-таки много Поправил вашу малозаметную опечатку,, Аноним (4), 19:52 , 15-Янв-20, (242)

Кхм, мне чота кажется, что оплаченность труда слабо коррелирует с наличием пробл, йкЛще (?), 09:20 , 15-Янв-20, (126) +5
Просто у них не было передовой партии , Ю.Т. (?), 11:03 , 15-Янв-20, (138)

Всё-таки не зря я года 4 назад перешёл на git Правда осталось репов 8 на hg , FSA (??), 08:43 , 15-Янв-20, (124) –2
Никто их не вынуждал поддерживать Python 2 Я все свои проекты перевел на 3 и вс, mumu (ok), 09:26 , 15-Янв-20, (128) –3 //

И твои проекты конечно сравнимы с меркуриалом по сложности и значимости , Аноним (133), 11:00 , 15-Янв-20, (136) +2 //

В мире, где полностью победил git, любой студенческий hello world сравним с Merc, Аноним (183), 11:34 , 15-Янв-20, (157) –1 //

главное - верь, студент Что все эти меркуриалы и прочие ненужные тебе поделки и, пох. (?), 11:14 , 16-Янв-20, (283)

Учитывая что сабж выкинула даже битовая мусорка - он походу прав , Аноним (412), 02:15 , 16-Фев-20, (412)

Важен процесс Процесса не было, mumu (ok), 16:11 , 19-Янв-20, (364)

Надо было писать на Java , Аноним (129), 09:47 , 15-Янв-20, (129) –1
Кому-то надо ещё объяснять, что динамические языки и пестон в часности - г но , Аноним (131), 10:26 , 15-Янв-20, (131) –2 //

Проблемность пихтона заключается отнюдь не в отступах А в Фортране 77 отступы,, Anonymoustus (ok), 10:32 , 15-Янв-20, (132) +2 //

Что-то не видел я там такого рояля удовольствия соблюдать отступы фортрана в т, Ю.Т. (?), 11:05 , 15-Янв-20, (139) //

Они структурируют программу и являются неотъемлемой частью её логики, всегда вид, Anonymoustus (ok), 11:21 , 15-Янв-20, (145)

чтоб тебе колоду непронумерованных рассыпать на лестнице P S по йолкам их разве, пох. (?), 14:30 , 15-Янв-20, (219) +1

А нефиг носить голые перфокарты по лестнице Потом этими же руками ешь В тележк, Anonymoustus (ok), 23:42 , 15-Янв-20, (260)

тогда не было направляющих для инвалидов Вы, похоже, таки опоздали родиться Про, пох. (?), 11:27 , 16-Янв-20, (284)

И что интересно, Хэмминг и ко - небось подревнее вас будут , Аноним (337), 18:05 , 18-Янв-20, (337)
Тебе бы отдыхать от опеннета, пох, ты уже в простой человеческий юмор не врубаеш, Anonymoustus (ok), 18:20 , 23-Янв-20, (382)

шестая позиция не имела в фортране семантического смысла - только синтаксический, пох. (?), 11:15 , 15-Янв-20, (142)
Между прочим, библиотеки на 77-м и даже более ранних Фортране компилируются до, Scriptor (ok), 12:25 , 15-Янв-20, (172) //

ну вам там выше написали, как одним шаловливым движением хвоста можно все взять , пох. (?), 13:47 , 15-Янв-20, (206) //

Почему не жалко-то , Scriptor (ok), 15:32 , 15-Янв-20, (227)

потому что красиво но феерически бесполезно в реальной жизни , пох. (?), 20:31 , 15-Янв-20, (247)

Define реальная жизнь , Scriptor (ok), 20:42 , 15-Янв-20, (249)

ну вот давай ты на нем запустишь пресловутый hg - с минимальным набором дополнен, пох. (?), 16:52 , 18-Янв-20, (327)

Ну да, подколол, подколол -- сами разрабы пишут, что не сработает нормально из-з, Scriptor (ok), 13:02 , 24-Янв-20, (390)

заметим, я эту писанину не читал - Просто предположил, что хрена там что запус, пох. (?), 13:40 , 24-Янв-20, (392)

потому что разрабатывать большие проекты на динамическом нефункциональном языке , Аноним (160), 11:37 , 15-Янв-20, (160)
они бы за 12 лет его с нуля на ассемблер переписали под все платформы, а за 5 ле, Аноним (164), 11:45 , 15-Янв-20, (164) //

почему же ты еще этого не сделал А, ну да, ты ж не умеешь кодить , пох. (?), 11:59 , 15-Янв-20, (168) +1 //

Те, кто умеют, в этот тред не заходят Потому что тут их обзовут вебмакаками и н, Аноним (183), 13:32 , 15-Янв-20, (197) –1 //

ну, в штанину пусть спрячут, что-ли И какие-нибудь модные сапожки, чтоб кисточк, пох. (?), 13:49 , 15-Янв-20, (207) +1
Те, кто умеют, прежде всего знают цену словам 171 надо переписать на 187 , PereresusNeVlezaetBuggy (ok), 00:08 , 16-Янв-20, (263) +1

А зачем, если есть git , Vkni (ok), 18:08 , 15-Янв-20, (234) –1

Вполне можно было взять компилируемый Питон, ака Ocaml И наваять примерно за то, Vkni (ok), 18:08 , 15-Янв-20, (233) //

много проектов схожего размера уже наваяли-то , пох. (?), 20:32 , 15-Янв-20, (248) //

Чай вас в гугеле не забанили Или вы даже названия INRIA не знаете , Vkni (ok), 07:06 , 16-Янв-20, (274) –2

Лет 15 назад, когда у меня был большой по тем временам почтовый трафик пришлось, Zulu (?), 02:59 , 19-Янв-20, (360) +1 //

Насколько я понимаю, это что-то там внутри List map Мы над этим работаем - наде, Vkni (ok), 03:14 , 19-Янв-20, (361)

пятнадцать лет работаете Потом они удивляются, что экзотический язычок что-то т, пох. (?), 10:24 , 19-Янв-20, (362) +1

Я не удивляюсь, т к прекрасно знаю, что движет индустрией - Но если писать д, Vkni (ok), 17:13 , 19-Янв-20, (365)

До сих пор используем в проде 2 3 2 То что было на 2 7 - снабдили from __future, economist (?), 13:20 , 15-Янв-20, (190) –1 //

Ну вод представьте, что у проекта три с половиной разработчика, да и тем работаю, Аноним (183), 13:37 , 15-Янв-20, (201) //

там их не то чтобы три, но им действительно было чем и без того заниматься - про, пох. (?), 13:50 , 15-Янв-20, (208)

Выйдет скоро Python 4 и все эти портирование и переписывание коту под хвост , Аноним (250), 20:54 , 15-Янв-20, (250) //

ну нет, так не делается Сначала-то, безусловно, 3 9Потом, возможно - 3 99А когда, пох. (?), 22:02 , 15-Янв-20, (253)

Питон - он такой Сначала написали, потом подумали , Онаним (?), 21:17 , 15-Янв-20, (251) //

неее, мы не такие Мы потом еще раз написали - и еще раз подумали А потом и еще,, Гвидо Опоссум (?), 22:03 , 15-Янв-20, (254) +1

мухаха нет тестов - просто смиритесь и умрите Git решал, решает и продолжит ре, Аноним (270), 02:01 , 16-Янв-20, (270) –3
Вот нахрена Взяли бы и начали писать следующую мажорную версию полностью на Pyt, Аноним (294), 15:23 , 17-Янв-20, (294) //

потому что любители модного-молодежного все сломать, а потом незнамосколько пис, пох. (?), 16:50 , 18-Янв-20, (326)
Может, потому что когда ты уже написал нечто работаюшее, кодить это с ноля еще р, Аноним (337), 18:06 , 18-Янв-20, (339)

Носятся с этим Гвидобейсиком, как с торбой расписной А торба-то худая много лет, iZEN (ok), 11:05 , 20-Янв-20, (366) //

Дожили, - устами iZEN а глаголет истина , Аноним (373), 19:10 , 20-Янв-20, (374) +1

Сообщения [Сортировка по времени | RSS]

16. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +1 +/–

Сообщение от freehck (ok), 14-Янв-20, 23:43

> ощущение будто тебя обманывают
> проще переписать программу на каком-то другом языке, чем
Да уже который год говорю, где обманывают: посмотрите на то, в каком состоянии "готовности" находятся стандартные библиотеки. За тридцать-то лет языка они, небось, должны быть совсем в ином состоянии. =/
И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне. Даже пресловутый мёртвый перл5 заставлял меня в своё время удивляться на порядки меньше, нежели питон2.
Но ладно. Я сейчас опять ведь начну питоносpач... А так надоели фанаты оного... Короче, ребята, давайте сразу засчитывайте мне слив, ибо я спорить не намерен в этот раз. Все несогласные -- лесом. =/

Ответить | Правка | Наверх | Cообщить модератору

32. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +6 +/–

Сообщение от Аноним (32), 15-Янв-20, 00:30

> мёртвый перл5
Не мертвый, а стабильный.)))
И это прекрасно, потому что предсказуемо.

Ответить | Правка | Наверх | Cообщить модератору

95. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +3 +/–

Сообщение от Аноним (-), 15-Янв-20, 07:02

> Не мертвый, а стабильный.)))
Именно. Ну вон прога на C89. До сих пор компилится и работает. При желании ее даже можно менять если надо. И никто не орет что C89 - deprecated, дескать. Более того - требование все резко переписать... ну... а вы сможете грамотно переписать какое-нибудь крипто, или допустим рида-соломона? Для того чтобы не накосячить надо знать пару специфичных разделов математики, однако. Иначе потом переписанное будет глючным или даже уязвимым.
> И это прекрасно, потому что предсказуемо.
Некоторым нравится закинуть гранату в проект и посмотреть что будет :). Будет примерно вон то.

Ответить | Правка | Наверх | Cообщить модератору

186. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –3 +/–

Сообщение от myhand (ok), 15-Янв-20, 13:15

> Именно. Ну вон прога на C89. До сих пор компилится и работает.
Хочешь расскажу где лежат исходники CPython 2.2, например?  Вот прикинь, если тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять и использовать ее.
Так можно!  Без разрешения Папы Римского!  Не упустите свой шанс!

Ответить | Правка | Наверх | Cообщить модератору

213. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +1 +/–

Сообщение от пох. (?), 15-Янв-20, 14:13

>> Именно. Ну вон прога на C89. До сих пор компилится и работает.
> Хочешь расскажу где лежат исходники CPython 2.2, например?  Вот прикинь, если
хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89 - вовсе не надо искать в несуществующих архивах 89го года именно ту версию компилятора и героически ее ставить на любую систему, включая те на которые не очень ставится.
В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от хипстаподелок.

Ответить | Правка | Наверх | Cообщить модератору

228. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 15-Янв-20, 16:08

> хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89
> - вовсе не надо искать в несуществующих архивах 89го года именно
> ту версию компилятора
Ну да, бедные разработчики тянут весь зоопарк стандартов...
> В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от
> хипстаподелок.
Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.

Ответить | Правка | Наверх | Cообщить модератору

245. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от пох. (?), 15-Янв-20, 20:24

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

Ответить | Правка | Наверх | Cообщить модератору

252. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 15-Янв-20, 21:39

>> Ну да, бедные разработчики тянут весь зоопарк стандартов...
> бедняжечки... Как же это оказывается сложно - просто держать шаловилвые ручонки -
> в опе, и ничего работающего ими не трогать за пределами того, что необходимо.
Ну вообще-то - это сложно.  Приходится не просто "не трогать", а обставлять все больше мест
специальными костылями, пропорционально количеству поддерживаемых стандартов.
Иной раз вы производите впечатление неглупого человека, а порой...
> Но зато их разработка, пожалуй, проживет еще пол-века
Ну, из стандартов C тоже кой-что выкидывают.  В _этом_ смысле - язык точно
не проживет еще пол-века.
> а пихон - выкинут набижавшие новые поколения любителей все поломать
Пайтон хоронят уже лет тридцать.  "Stop! This is silly."

Ответить | Правка | Наверх | Cообщить модератору

313. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 18-Янв-20, 02:00

> Пайтон хоронят уже лет тридцать.  "Stop! This is silly."
При том в последнее время достигают в этом определенных успехов. Оплот пихтонрастов в виде гуголя и нескольких иных нагруженных сайтов что-то go полюбили.

Ответить | Правка | Наверх | Cообщить модератору

321. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 14:46

> Ну да, бедные разработчики тянут весь зоопарк стандартов...
Новые стандарты в массе своей - superset старых. За редким исключением. А так чтобы именно deprecate, с жестким вынесением совместимости - в сях и плюсах почти не практикуется. В отличие от.
> Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
Типа, интерпретеры питона сильно лучше? :)

Ответить | Правка | К родителю #228 | Наверх | Cообщить модератору

334. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 18-Янв-20, 17:50

> А так чтобы именно deprecate, с жестким вынесением совместимости - в сях
> и плюсах почти не практикуется.
Тем не менее, быват, быват.  Гениальные дизайнеры языка, планирующие на
полвека вперед - они на кисельных берегах сидят, молочных рек...
>> Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
> Типа, интерпретеры питона сильно лучше? :)
В любом большом проекте без поллитры не разберешься.  Но не настолько все плохо.

Ответить | Правка | Наверх | Cообщить модератору

346. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (332), 18-Янв-20, 19:47

> Тем не менее, быват, быват.
Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный и потому ни разу не встречавшийся мне в диком виде. В отличие от скриптов которые на каждом углу.
Поэтому с практической точки зрения - старые программы и собираются и работают. Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить. А можно и забить, если экскурсия в код не была частью планов. С питоном так не катит - там скорее грохнется с адским стэктрейсом на полпути к финишу. И это неудобно - потому что довольно трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть. Именно тогда когда это очень некстати.
> Гениальные дизайнеры языка, планирующие на
> полвека вперед - они на кисельных берегах сидят, молочных рек...
Ну так питонисты сперва делают, потом думают. Не все же такие.
> В любом большом проекте без поллитры не разберешься.
Вот то-то и оно.
> Но не настолько все плохо.
Типа, BDFL от хорошей жизни сбежал? :)

Ответить | Правка | Наверх | Cообщить модератору

353. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от анонн (ok), 18-Янв-20, 20:39

> Поэтому с практической точки зрения - старые программы и собираются и работают.
Ну соберите мне третьекеды на современной системе, что ли.
Да куда там кеды, тут уже и VirtualBox не самой свежей версии (5.2.6) - и тот не собирается без бубна. Еще ему gcc версии от 4 до 7 подавай, аналогично с LLVM для новых версий в 5 ветке (5.2.34+) "ваша версия LLVM слишком новая! C 8 и 9 проблемы в рантайме!"

# Check for gcc with version >= 3.2.
# We depend on a working gcc, if we fail terminate in every case.
...
log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x"
Про сборку его морды с Qt4, который отовсюду выкинули - не заикаюсь. Так ведь даже код для _Qt5_ придется править, тот же
#include <QButtonGroup>
вставлять, иначе компиляция завалится с "invalid use of incomplete type ‘class QButtonGroup’".
В общем, если вы с наскока припоминаете только 1 пример, то в контексте обсуждения это просто говорит не в вашу пользу …

Ответить | Правка | Наверх | Cообщить модератору

370. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 20-Янв-20, 18:19

> Ну соберите мне третьекеды на современной системе, что ли.
Проект TDE занимается как раз этим самым :)
> # Check for gcc with version >= 3.2.
> # We depend on a working gcc, if we fail terminate in every case.
И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что сказано, но при чем тут си это все-таки не поясняет.
> Так ведь даже код для _Qt5_ придется править, тот же
> #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid
> use of incomplete type ‘class QButtonGroup’".
По сравнению с питоном - один инкоюд это не так уж плохо. Ну и вообще, это отдельная жирная сторонняя либа - к сям и плюсам это само по себе отношения не имеет. Поменять интерфейс компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в либы/компоненты вроде.
> В общем, если вы с наскока припоминаете только 1 пример, то в
> контексте обсуждения это просто говорит не в вашу пользу …
А может не в мою? Мне кажется, кто-то не разобрался в технологиях, но мнение уже имеет.

Ответить | Правка | Наверх | Cообщить модератору

375. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от анонн. (?), 20-Янв-20, 20:35

>> Ну соберите мне третьекеды на современной системе, что ли.
> Проект TDE занимается как раз этим самым :)
И? Хотите сказать, что раз целый отдельный проект занимается этим, то это однозначное доказательство "старые программы собираются и работают" в действии? Как-то не очень убедительно.
Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет)
>> # Check for gcc with version >= 3.2.
>> # We depend on a working gcc, if we fail terminate in every case.
> И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так
> в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что
> сказано, но при чем тут си это все-таки не поясняет.
До этого там было:
https://github.com/svn2github/virtualbox/commit/b05888fae993...

-        log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x, gcc 5.x or gcc 6.x"
+        log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x"

Видимо, написали просто так, из любви к искусству, а не потому что постоянно что-то ломается в билде, по типу:
https://www.virtualbox.org/ticket/18624

>> Так ведь даже код для _Qt5_ придется править, тот же
>> #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid
>> use of incomplete type ‘class QButtonGroup’".
> По сравнению с питоном - один инкоюд это не так уж плохо.
> Ну и вообще, это отдельная жирная сторонняя либа - к сям
> и плюсам это само по себе отношения не имеет. Поменять интерфейс
> компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в
> либы/компоненты вроде.
Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали!
Что совой о пень, что пнем о сову - результат вообще-то не сильно отличается для конечного пользователя. Это притом что VBox 5.2.6 вышел в 2018 году.
Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку старых пакетов в более современном окружении.
>> В общем, если вы с наскока припоминаете только 1 пример, то в
>> контексте обсуждения это просто говорит не в вашу пользу …
> А может не в мою? Мне кажется, кто-то не разобрался в технологиях,
> но мнение уже имеет.
А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул не особо подумав и теперь пустился в демагогию.
Потому что по существу вопроса тут 0 целых крен десятых, лишь передерг да оправдывания "по сравнению с питоном не страшно!".

Ответить | Правка | Наверх | Cообщить модератору

377. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 20-Янв-20, 22:55

> И? Хотите сказать, что раз целый отдельный проект занимается этим, то это
> однозначное доказательство "старые программы собираются и работают" в действии?
Я хочу сказать что проблемы третьекедов вытекают не из компилеров и сей. А из
1) Того что на майнтенанс оных технологий подзабили.
2) Некоторые технологии кедов 3 стали несколько иррелевантны (e.g. dcop vs dbus) и это вообще не по линии ЯП.
3) Взаимодействие с либами на которые они завязаны и поддержка всего этого. К самим по себе сям чье-то там (не)желание вечно поддерживать третий куть не относится никак.
Собственно сабжи откопали и перекомпилили стюардессу. А зачем откапывать? Все остальные на эту версию забили - только поэтому.
> Как-то не очень убедительно.Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет)
Если они и завалятся то явно не по линии ЯП и компилеров. Скорее по зависимостям от внешних компонентов, что к ЯП и компилерам не относится чуть менее чем никак, это взаимодействие компонентов. Тем не менее, прошареные некромансеры периодически такое собирают. И таки да, можно это сделать современным компилером - вот новый компилер этому как правило не мешает вообще совсем никак. Разве что варнингами активнее трындит. Какие-то исключения возможны наверное, но их немного и я никак не могу вспомнить - где надо перепахивать всю прогу по всей площади, как в питоне?
> постоянно что-то ломается в билде, по типу:
> https://www.virtualbox.org/ticket/18624
При том опять же к ЯП и компилеру это относится довольно сбоку - это новомодные оптимизации странно играют с их чудесами. "As expected, the problem is with PCH -- Workaround: VBOX_WITHOUT_PRECOMPILED_HEADERS := 1".
> Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали!
Если сям и плюсам считать все кути и прочие - тогда питону посчитаем всякие Zope'ы, во! :)
> сильно отличается для конечного пользователя.
А зачем пользователю вообще что-то собирать, программить и прочее? Не понимаю. И тем не менее, сборка древних кед - это больше вообще по линии майнтенанса и интеграции чем програмизма, ЯП и компилеров. Потому что сам по себе яп и компилеры там как правило и не мешают особо.
> Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку
> старых пакетов в более современном окружении.
Вообще странноватое сочетание, свежий gcc с старым пакетом. Но это где-то на грани бага на самом деле. Правда я не очень в курсе чьего именно, мне от vbox ничего не надо по счастью, так что простите великодушно что я в его начинке копаться не буду.
> А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул
> не особо подумав и теперь пустился в демагогию.
Интересно же посмотреть чего высосут из пальца вебманки? Вот тут притащили за уши сторонние либы и даже раскопали какое-то чудесатое взаимодействие с гцц.
> да оправдывания "по сравнению с питоном не страшно!".
А я виноват что примерно так оно и обстоит? Во всяком случае я почему-то смог собрать ряд весьма античных штук без перепиливания половины кода. С питоном так не катит. И переводы стрелок на сторонние либы - как-то не комильфо, тогда давайте и питону всякие zope'ы считать, вот уж мало не покажется.

Ответить | Правка | К родителю #375 | Наверх | Cообщить модератору

354. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 18-Янв-20, 20:55

>> Тем не менее, быват, быват.
> Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный
> и потому ни разу не встречавшийся мне в диком виде.
Да берете стандарт и просто делаете поиск.  В С11, например, gets удалена.  Или вот,
в C99 добавили ключевое слово restrict.
> В отличие от скриптов которые на каждом углу.
Ну прям так на каждом?  Используйте нужный вам интерпретатор - и все будет
работать до морковкина заговенья.
Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
больше чем libc.  И что будет если взглянуть как обстоит дело с обратной
совместимости в 100500 сторонних сишных либах?
> Поэтому с практической точки зрения - старые программы и собираются и работают.
Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
80-х прошлого века.
> Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А
> дальше уже по ситуации, если хочется, можно и исправить.
Да нет.  "int restrict = 1;" - и усе, просто не соберется.
> С питоном так не катит - там скорее грохнется с адским стэктрейсом
> на полпути к финишу. И это неудобно - потому что довольно
> трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть.
Во-первых, это уже из области "динамические языки - это плохо".  А с обратной совместимостью
в питон приблизительно также как и том же C.  Да, чаще ломают (что неудивительно,
поскольку возможности искаропки несравнимы), но никогда ВНЕЗАПНО.  Что-то
объявляется устаревшим, а уж потом в следующих релизах выкидывается.
Везде так.  Никто серебряной пули не придумал.
>> Гениальные дизайнеры языка, планирующие на
>> полвека вперед - они на кисельных берегах сидят, молочных рек...
> Ну так питонисты сперва делают, потом думают. Не все же такие.
Где не такие - я только что написал выше.  Удачи попасть в Воображляндию.
>> Но не настолько все плохо.
> Типа, BDFL от хорошей жизни сбежал? :)
Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет
подобной собачьей должности...

Ответить | Правка | К родителю #346 | Наверх | Cообщить модератору

372. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 20-Янв-20, 18:58

> В С11, например, gets удалена.
Как "inherently dangerous function". И тем не менее, C89 код таки соберется. В режиме C89, разумеется. А я разве обещал что C89 код по мановению волшебной палочки станет C11? :)
Более того - в C89 и коменты с // нельзя начинать и в режиме C89 без расширений компилер имеет полное право завернуть такой код.
> Или вот, в C99 добавили ключевое слово restrict.
Но вот C89 проги как собирались так и собираются. А хотя-бы и в режиме C89 - потому что C99 отличается не только, блин, названием. И там даже типы лучше использовать другие - менее долбанутые чем в изначальном си. Потому что int something - это достаточно абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы и компилера. В C99 это исправили, сделав куда более разумные типы - потому что писать на именно C89 без расширений код... какая-нибудь мелкая букашка типа pic может иметь свое мнение о том что такое int. Ну или у некоторых DSP например char 16-битный. Формально это валидно, фигли. А реально - поэтому и придумали C99 с явно озвученным числом битов на тип, так куда пресказуемее.
> Ну прям так на каждом?  Используйте нужный вам интерпретатор - и
> все будет работать до морковкина заговенья.
Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается террариум какой-то развести. Почувствуйте разницу.
> Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
> больше чем libc.  И что будет если взглянуть как обстоит дело
> с обратной совместимости в 100500 сторонних сишных либах?
Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться? Я конечно понимаю что очень круто запихнуть весь глобус в стандартную библиотеку, но жабисты говорят что с этим потом бывают некоторые нюансы...
> Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
> 80-х прошлого века.
Ну так пока у народа есть этот код и его работа народу требуется - его и таскают. А все сломать и потребовать всех с ножом к горлу переписать модно, молодежно ... э, блин, а кто вон тому поезду колеса крутить будет? Ну не ты же, хипстер, фирмварь на питончике быстро перенакорябаешь? С такой фирмварью он с рельсов улетит или спалит ящик силовой электроники, стоящей больше чем твоя зарплата за год. Вот и таскают.
> Да нет.  "int restrict = 1;" - и усе, просто не соберется.
Так никто и не обещал что любой код C89 собирается как C99. Иначе какой смысл вообще называть это новым стандартом? Можно и дальше говорить что это C89, разве не логично? :) Значит придется этот код как C89 билдить. У сишников так можно, в отличие от.
> Во-первых, это уже из области "динамические языки - это плохо".
И таки я считаю что это плохо.
1) Потому что гарантирует жоские проблемы с перфомансом.
2) Потому что статический анализ кода идет псу под хвост.
По поводу чего начинаются ужимки с урезанными subset'ами которые типа не совсем питон, зато нет такие тормозливые. Но переписывать тонны гуано на это всем лениво - и они где-то там, влачат существование.
> А с обратной совместимостью в питон приблизительно также как и том же C.
Да вот не так же - у меня в системе только одна версия libc, одна версия компилера и проч. А компилить может и C11 и C89 и чего там еще. В случае с питоном же мне рассказывают что террариум - так и задумано. А ну его в пень такие задумки!
>  Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы),
Ну насчет возможностей можно и поспорить. Я вот сишным кодом могу себе проц забутявить. Даже по сути без асма, без внешних рантаймов. А попробуйте так одним питоном, куле? :)
Ну и да, зачем вообще все переть в стандартную либу? Чтобы показать что муки жабистов при выпуске новой явы - еще не предел? Ну спасибо, это кажется удалось :)
> Везде так.  Никто серебряной пули не придумал.
Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон тот C89 код. Здесь и сейчас. А то что у меня компилер довольно новый - ну да, и чего?
> в Воображляндию.
Я бы сказал что с питоном светит только геморройлэнд и багодромы.
> Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет
> подобной собачьей должности...
Ножичком? Кого? Тех кто его творениями пользуется? Лучше гранату в этот обезьянник подбросить.

Ответить | Правка | Наверх | Cообщить модератору

380. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 21-Янв-20, 09:57

>> В С11, например, gets удалена.
> Как "inherently dangerous function". И тем не менее, C89 код таки соберется.
> В режиме C89, разумеется.
Да, детка.  Вы начинаете понимать принцип...
> А я разве обещал что C89 код
> по мановению волшебной палочки станет C11? :)
Ну типа того: " Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."
> Более того - в C89 и коменты с // нельзя начинать и
> в режиме C89 без расширений компилер имеет полное право завернуть такой код.
Тоже неплохой пример.
>> Или вот, в C99 добавили ключевое слово restrict.
> Но вот C89 проги как собирались так и собираются.
Пока вам достаточно стандартной библиотеки...
Ну так и конкретная версия интерпретатора пайтона - будет работать с
вашими скриптами как угодно долго.
>> Ну прям так на каждом?  Используйте нужный вам интерпретатор - и
>> все будет работать до морковкина заговенья.
> Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается
> террариум какой-то развести. Почувствуйте разницу.
Во-первых, причем тут gcc?  Аналогия, скорее, между стандартом языка и
версией интерпретатора.  gcc - тащит несколько версий стандартов, интерпретатор
питона, грубо говоря - один (хотя пару релизов старые скрипты будут работать
с гарантией, разве что добавив в выхлоп предупреждений).
Про gcc вам уже ответили граждане.  То что вам достаточно жить ровно с одной версией
компилятора - говорит только о скудости опыта (хотя я бы уже рискнул сделать
более суровое обобщение).
>> Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько
>> больше чем libc.  И что будет если взглянуть как обстоит дело
>> с обратной совместимости в 100500 сторонних сишных либах?
> Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться?
Так куда не запихни - получатся те же яйца.
>> Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца
>> 80-х прошлого века.
> Ну так пока у народа есть этот код и его работа народу
> требуется - его и таскают.
Его таскают, в основном, из любви к закрытому коду корпорастов.
От них же и идут основные стоны про то как часто в питон что-то "ломают".  Потому что
принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
В мире FOSS - совершенно другая картина.  Большинство востребованных проектов на
питон - давно сумели свинтить на третий питон без стонов вроде сабжа.
> А все сломать и потребовать всех
> с ножом к горлу переписать модно, молодежно ... э, блин, а
> кто вон тому поезду колеса крутить будет?
На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
использующий какой-нибудь античный C89.  Подавляющая часть адаптирована до
такой степени, что код как минимум собирается на наиболее современном стандарте.
>> Да нет.  "int restrict = 1;" - и усе, просто не соберется.
> Так никто и не обещал что любой код C89 собирается как C99.
> Иначе какой смысл вообще называть это новым стандартом?
Ну кое-кто - обещал, см. выше.  Конечно, я подозревал, что вы будете
юлить "я это не имел в виду, я это введу..."
> У сишников так можно, в отличие от.
Мне вам что, картинки нарисовать как можно запускать скрипты с нужной
вам версией интерпретатора питон?
>> Во-первых, это уже из области "динамические языки - это плохо".
> И таки я считаю что это плохо.
Вам никто не запрещает так считать.  Просто непонятно почему это мнение кого-то должно волновать?
>> А с обратной совместимостью в питон приблизительно также как и том же C.
> Да вот не так же - у меня в системе только одна
> версия libc, одна версия компилера и проч.
Я вас поздравляю и даже немного завидую.  Значит у вас все впереди!  Может однажды поучаствуете
в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах...  ПТУ^WУниверситет там закончите или что там у вас.
>>  Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы),
> Ну насчет возможностей можно и поспорить.
Ну об чем тут можно спорить?  Что можно запилить поддержку json на C?  Очереди
с приоритетом?  Можно, конечно.  Но мало кому в XXI веке уже интересно стругать
себе в 100500 раз инструменты из палок и г-на, есть масса более других задач.
> Я вот сишным кодом могу себе проц забутявить.
Не уверен, что я понял вашу мову.  Видимо, речь об использовании питона
для низкоуровневого программирования.  В принципе, можно, только зачем?
> Ну и да, зачем вообще все переть в стандартную либу?
Речь шла немного о другом: что вы сравниваете несравнимое.  Т.е. чтобы быть
совсем уж честным при сравнении совместимости - вам надо посмотреть как обстоит
дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
с питоновской стандартной библиотекой.
>> Везде так.  Никто серебряной пули не придумал.
> Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон
> тот C89 код. Здесь и сейчас.
Так и скрипт на питоне можно запустить нужной версией интерпретатора.

Ответить | Правка | Наверх | Cообщить модератору

395. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (395), 24-Янв-20, 23:22

> Да, детка.  Вы начинаете понимать принцип...
Ну так в результате я могу юзать вон тот древний код с вот этим свежим компилером. Не патча полпланеты лично. Более того - можно даже сделать программу из разных по версии сей, это ни к чему такому не ведет.
> Ну типа того: " Как максимум компилер из-за улучшения статического анализа может
> варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."
В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :)
> Тоже неплохой пример.
Ну дык. Однако те кто кодил под C89 и не юзали такие каменты. А если кто хотел фичу нового стандарта - ну вот тут придется проапгрейдить код уже. Но вот это - опционально. Можно забить, обойдясь без новых фич в этом файле.
> Пока вам достаточно стандартной библиотеки...
И иногда у меня даже и стандартной библиотеки нет. А где я на МК с простой как тапок фирмварой файловую систему возьму? :) А так расписываться за действия вообще всех програмеров и их либ - занятие провальное. Вон там zope, кстати, в соседней новости жжот, не к ночи будь поманут :)
> Ну так и конкретная версия интерпретатора пайтона - будет работать с
> вашими скриптами как угодно долго.
А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта".
> Во-первых, причем тут gcc?  Аналогия, скорее, между стандартом языка и
> версией интерпретатора.
Ну и вот с этим как бы грабли. Мне достаточно поставить 1 "системный" компилер из репов - и он прожует что у меня есть. А с питоном - фигвам, так не катит.
А если б мне надо было таскать по версии компилера на стандарт, да еще чтоб из проги на C99 хрен поюзаешь алгоритм на C89 - блин я б тогда наверное си "любил" так же как и питон.
> Про gcc вам уже ответили граждане.  То что вам достаточно жить
> ровно с одной версией компилятора - говорит только о скудости опыта
Булшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.
Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит.
> Так куда не запихни - получатся те же яйца.
А вот не те же. Если в стандартную либу пхать, отвалится у большего числа народа. А опциональная либа - там во первых програмеры дважды подумают до того как апи менять, под угрозой что их либу все перестанут юзать, а во вторых - половина обнаружит что им и без этой либы можно обойтись.
> Его таскают, в основном, из любви к закрытому коду корпорастов.
Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?!
> принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один.

> В мире FOSS - совершенно другая картина.
Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не для того чтобы улучшить а потому что на их бошку новая версия свалилась.
> На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
> использующий какой-нибудь античный C89.
А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной вот алгоритмике. И он был достаточно щедр для того чтобы оформить частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89.
> Подавляющая часть адаптирована до такой степени, что код как минимум
> собирается на наиболее современном стандарте.
Да зачем? Они и как C89 прекрасно юзабельны. В том числе и проектами чей собственный код соответствует последним стандартам.
> Ну кое-кто - обещал, см. выше.
Цитату обещаний плз?
> Мне вам что, картинки нарисовать как можно запускать скрипты с нужной
> вам версией интерпретатора питон?
Спасибо, но мне как-то по жизни оказалось проще найти аналоги на чем-нибудь другом. Поэтому на данный момент я уже не имею таких проблем.
> Просто непонятно почему это мнение кого-то должно волновать?
Ага, я за ним столько бежала, чтобы сказать ему что он мне пофиг... %)))
> в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах...
>  ПТУ^WУниверситет там закончите или что там у вас.
Дык участвую. Но естественно не в пихоносрани с вебмакаками. Мне такой крап просто не интересен.
> Ну об чем тут можно спорить?  Что можно запилить поддержку json на C?
>  Очереди с приоритетом? [...]
...поэтому сишники просто цепанут библиотеку - и дело в шляпе. Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались постоянно переписывать. У сишников библ - на все оказии. И таки к счастью не в стандартной блин либе. Ну вот накулкуа мне там какой-нибудь куть?
> Не уверен, что я понял вашу мову.  Видимо, речь об использовании
> питона для низкоуровневого программирования.  В принципе, можно,
> только зачем?
Это ответ на реверанс что на питоне дескать можно все, бла-бла. И таки некоторые вещи на именно питоне без костылей на других ЯП - да удачи.
> дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
> с питоновской стандартной библиотекой.
И в результате получаем помесь явы с кутями, только еще хуже, когда после выпуска очередной версии наступает вешалка. Я вот как раз очень рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю. И не имею стало быть проблем с ними и их развалом. Более того - чрезмерно ломкие либы постепенно отсеиваются. А если прямо стандартная либа изгадилась - как это отсеивать?! :D
> Так и скрипт на питоне можно запустить нужной версией интерпретатора.
Ну так в результате требуется устраивать террариум, да к тому же в репах дистра этого нет, что гарантирует кучу дурной камасутры на ровном месте. А таки удобно когда компилер можно прям из реп 1-2 командами, и потом все просто работает...

Ответить | Правка | К родителю #380 | Наверх | Cообщить модератору

398. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (398), 25-Янв-20, 15:04

> А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта".
> много бла ни о чем
> Булшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.
> Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит.
То, что "это может быть любой компилер, если этот компилер - не слишком свежий gcc" - вы опять забыли упомянуть из скромности, из-за специфично-выборочного восприятия, незнания или банального склероза?
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/erla...
А вот тут вот штатный компилер вообще-то шланг:
https://www.freshports.org/lang/gcc9/

gcc9
This port is required by:
for Build
archivers/R-cran-zip
astro/R-cran-maptools
astro/nightfall
astro/wcslib
audio/calf-lv2
audio/gsequencer
audio/lsp-plugins-lv2
Expand this list (620 items / 613 hidden)
Причем, список сильно сократился за последние пару лет, по мере наращивания шлангом компатибельности с gcc.

Ответить | Правка | К родителю #395 | Наверх | Cообщить модератору

399. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (398), 25-Янв-20, 15:29

Совсем забыл:
> Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и
> мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все.
Помимо того, что сам аргумент перевода стрелок на "знакомых", без конкретных отсылок, разве что детсад^W лулзовый - мне просто интересно, как выглядел вопрос о кол. или версиях используемых компилеров? "Слышь, ты сколько компилеров используешь? Как все правильные пацаны, одну версию?"
В общем, хотите использовать аргумент "авторитета" - давайте проверяемый отссылки на пару более-менее серьезных кодеров.
А то и тут, если чуть копнуть, как-то не очень в вашу пользу выглядит:
https://lkml.org/lkml/2013/2/5/873
> All gcc versions tested (4.[4567]) emit calls to __bswap[sd]i2 when
> optimizing for size, so we add the !CC_OPTIMIZE_FOR_SIZE check.
https://lkml.org/lkml/2018/3/21/775
> I tried putting the below ugly test code through various gcc versions.
https://lkml.org/lkml/2019/8/7/55
> > I see the same warnings building linux-5.2.0 with gcc9. However, I don't see the warnings building linux-5.2.0 with the
> the 20190705 of gcc8.

Ответить | Правка | К родителю #395 | Наверх | Cообщить модератору

404. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 26-Янв-20, 11:11

>> Да, детка.  Вы начинаете понимать принцип...
> Ну так в результате я могу юзать вон тот древний код с
> вот этим свежим компилером. Не патча полпланеты лично.
Так и на питоне это можно.
> Более того -
> можно даже сделать программу из разных по версии сей, это ни
> к чему такому не ведет.
И это по-идее, тоже можно.  Хотя к чести питона, до сих пор подобных
гениев разработки мне встречать не довелось.
>> Ну типа того: " Как максимум компилер из-за улучшения статического анализа может
>> варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить."
> В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :)
Послушайте, в "я имел в виду не то, я то введу" - играть с вами я не намерян.
> А если кто хотел фичу нового стандарта - ну вот
> тут придется проапгрейдить код уже.
Угу, иначе register все подорвет...   Т.е. с совместимостью обстоит
плюс-минус лапоть также как в питоне: мы объявляем что-то устаревшим,
чтобы в следующих стандартах удалить, мы вводим новый синтаксис, который
ломает нам старый код (кстати, примеров подобного как-то сходу не могу
придумать в питон, в отличие от)...
>> Пока вам достаточно стандартной библиотеки...
> И иногда у меня даже и стандартной библиотеки нет. А где я
> на МК с простой как тапок фирмварой файловую систему возьму? :)
> А так расписываться за действия вообще всех програмеров и их либ
> - занятие провальное.
Это вы все порываетесь расписываться, а я лишь констатировал факт.  В стандартной
библиотеке даже нет большей части типовых структур данных.  STL.  Одна из причин
того, почему такая мерзкая гадость как C++ не сдохла в колыбели...
>> Ну так и конкретная версия интерпретатора пайтона - будет работать с
>> вашими скриптами как угодно долго.
> А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование
> чем "конкретная версия стандарта".
Почему?  Это одно и то же.  Или вам неприменно надо одобрямс чинуш из
ISO?  Ну так тогда последний стандарт схемы - что-то типа r3rs...
>> Во-первых, причем тут gcc?  Аналогия, скорее, между стандартом языка и
>> версией интерпретатора.
> Ну и вот с этим как бы грабли. Мне достаточно поставить 1
> "системный" компилер из репов - и он прожует что у меня есть.
Ну так проблема в том, что это _вам_ достаточно.  А вот в дистрибутивах почему-то
держат несколько.  И львиная доля проблем - это именно "мы заменили gcc на gcc, ПАМАЖИТЕ
ПАЖАЛУСТА!"  Другой сценарий: какая-нибудь libxml2 поменяла версию.
> А с питоном - фигвам, так не катит.
Почему?  У меня ровно один системный интерпретатор.
> Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке
> - тем который в репах лежит.
Это смотря в каком дистре.  А то в Debian вот почему-то gcc-7 и gcc-8...  Шланг
тоже рядом лежит.
>> Так куда не запихни - получатся те же яйца.
> А вот не те же. Если в стандартную либу пхать, отвалится у
> большего числа народа.
Если вы не пользуетесь - что у вас может отвалиться?
> А опциональная либа - там во первых програмеры
> дважды подумают до того как апи менять, под угрозой что их
> либу все перестанут юзать, а во вторых - половина обнаружит что
> им и без этой либы можно обойтись.
Вообще-то куда шустрее всякие libxml2 сишные апи меняют чем что-то
обратно-несовместимое в стандартной библиотеке питона сотворят...
>> Его таскают, в основном, из любви к закрытому коду корпорастов.
> Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?!
Можете сразу рассказать как из-за одной из его 100500-й утилитки
в компайлерах держат кучу стандартов.
>> принцип остается прежний: "разработка" заключается в том, что слепили - и забыли.
> Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной
> необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один.
Да не один он такой.  Поматросил и бросил - типичная картина при
интырпрайз-разработке.  А у автора кумыла просто с детства чвс чешется,
вот он и плодит новые мертворожденные проекты.  Код для статьи.
Не вспоминайте про DJB при тех, кто с его поделиями сталкивался в промышленном
применении.  Могут и ногами побить.
>> В мире FOSS - совершенно другая картина.
> Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не
> для того чтобы улучшить а потому что на их бошку новая версия свалилась.
Ну а чего еще вы не видели?  Тех кто пишет тесты?
>> На самом деле, вы не сможете найти мало-мальски серьезный открытый проект,
>> использующий какой-нибудь античный C89.
> А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической
> области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной
> вот алгоритмике. И он был достаточно щедр для того чтобы оформить
> частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89.
Проект настолько серьезен, что даже викимусорка его не упоминает,
пишущи про подобную "алгоритмику".
Нет, проектов на манер DJB (запилю вам POC, "открою" под "хочите
менять - форкайте на всю катушку") - найти, наверно, можно.  Хотя как раз
сишные проекты все меньше в этом плане заметны: тут именно Python удобнее.
Я не про "открыл и забыл", а про проекты, у которых есть багтрекер,
хотя бы несколько разработчиков, сформировавшееся сообщество пользователей вокруг.
>> Подавляющая часть адаптирована до такой степени, что код как минимум
>> собирается на наиболее современном стандарте.
> Да зачем? Они и как C89 прекрасно юзабельны. В том числе и
> проектами чей собственный код соответствует последним стандартам.
Да все за тем же.  Чтобы проект не подох в итоге.  Никому не интересно
обучать вновь приходящих разработчиков ANSI C, например.
>> Ну кое-кто - обещал, см. выше.
> Цитату обещаний плз?
Я цитировал.  См. выше, вы там в шкаф залезли "я это не введу, я введу другое"...
>> в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах...
>>  ПТУ^WУниверситет там закончите или что там у вас.
> Дык участвую. Но естественно не в пихоносрани с вебмакаками.
Веб-проекты, мягко говоря, далеко не самая типичная область применения питона.
>> Ну об чем тут можно спорить?  Что можно запилить поддержку json на C?
>>  Очереди с приоритетом? [...]
> ...поэтому сишники просто цепанут библиотеку - и дело в шляпе.
А потом просто цепанут ее немножко по-другому.  Потому что тут АПИ
менять можно хоть каждый год - не стандарт.  Же!
> Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались
> постоянно переписывать.
Давайте вы хоть что-то попробуете доказать.  Благо, это не C, где код
лежит где попало и как попало.  Все более-менее запаковано одинаково
и есть pypi, который уже не-веб-макака должна суметь за час распросить
про статистику.  Дерзайте.  Может даже вам для дипломной работы сгодится...
>> дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый
>> с питоновской стандартной библиотекой.
> И в результате получаем помесь явы с кутями, только еще хуже, когда
> после выпуска очередной версии наступает вешалка. Я вот как раз очень
> рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю.
Если вы их не юзаете - то каким образом ожидаете от них "вешалку"?
> А если прямо стандартная либа изгадилась - как это отсеивать?! :D
А что мешает сделать нестандартную либу?  Следовательно, вы доказали
только то, что стандартная либа "не изгадилась", с совместимостью
там все хорошо.
>> Так и скрипт на питоне можно запустить нужной версией интерпретатора.
> Ну так в результате требуется устраивать террариум, да к тому же в
> репах дистра этого нет
Почему это террариум, а куча стандартов в компиляторе - не террариум?
И почему это в репах дистра "нет"?  Как правило, все есть - для
самого актуального случая (py2 vs py3).

Ответить | Правка | К родителю #395 | Наверх | Cообщить модератору

383. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Anonymoustus (ok), 23-Янв-20, 18:54

>[оверквотинг удален]
> в режиме C89 - потому что C99 отличается не только, блин,
> названием. И там даже типы лучше использовать другие - менее долбанутые
> чем в изначальном си. Потому что int something - это достаточно
> абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы
> и компилера. В C99 это исправили, сделав куда более разумные типы
> - потому что писать на именно C89 без расширений код... какая-нибудь
> мелкая букашка типа pic может иметь свое мнение о том что
> такое int. Ну или у некоторых DSP например char 16-битный. Формально
> это валидно, фигли. А реально - поэтому и придумали C99 с
> явно озвученным числом битов на тип, так куда пресказуемее.
Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то вы точно знаете его характеристики, следовательно — эта особенность С89 не является для вас проблемой. А если пишете её для нескольких разных архитектур, то, скорее всего, вы тоже точно знаете их свойства и умеете делать так, чтобы различия не стали проблемой. Си, как ни крути, ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают.

Ответить | Правка | Наверх | Cообщить модератору

394. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 24-Янв-20, 22:12

> Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то
> вы точно знаете его характеристики,
Я вам тут не ассемблерщик (я прогал на нескольких асмах, но - надоело), и таки использую много довольно разного железа. И со своей стороны считаю портабельность сей весьма и весьма жирным плюсом. По поводу чего предпочитаю скорее C99. Порой несколько уменьшенный subset - для МК.
> следовательно — эта особенность С89 не является для вас проблемой.
Мне виднее и мои приоритеты и что является для меня проблемой. Поэтому для себя я решил оперировать C99 (без VLA, кроме случая когда есть очень крутая причина и это не мешает иным вещам). Ну и posix как апи если это еще к оси интерфейсить надо. И писать максимально портабельно при условии что это ничего не нагибает.
А хотя-бы потому что например удобно на стороне компа какой-нибудь алгоритм или кус логики прозвонить, в том числе под мощными тулсами типа asan/ubsan до того как его на мк допустим пускать.
На микроконтроле ... пакость типа avr вообще будет как яваскрипт, всепофиг, продолжаем работать, хоть там чо. Cortex, конечно, hardfault пульнет но понять от чего он вылез в урезанном окружении - канительнее и неудобнее. Справедливости ради, мне приходится вручную левый доступ к памяти делать чтобы вообще проверить что handler срабатывает, но все-же.
> делать так, чтобы различия не стали проблемой. Си, как ни крути,
> ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают.
Ну и с этой точки зрения - если я знаю что вон те данные будут 32 бита, мне логично и заказать им uint32_t, а не какой-то абстрактный int с риском поиметь грабли если на какой-то платформе int окажется вдруг не столько.
Если так заметить, именно профессионалы тоже эти типы не лю и часто делают typedef с более вменяемыми типами и кучей кослылепроверок ifdef/sizeof. Мне так поганить код впадлу и я просто юзаю C99.

Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

312. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 01:59

> Хочешь расскажу где лежат исходники CPython 2.2, например?  Вот прикинь, если
> тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять
> и использовать ее.
Зачем мне это? После пары жирных обломов жизнь научила меня что закладываться на продукты жизнедеятельности вбемакак - чревато.
> Так можно!  Без разрешения Папы Римского!  Не упустите свой шанс!
Блин, а ты можешь собачье г@вно с тротуара убрать. Впрочем за гвидо убирать хуже, во всяком случае ему даже лавры BDFL-я уже не по кайфу, сбежал даже так.

Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

319. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 18-Янв-20, 10:48

> Зачем мне это?
А мне почем знать зачем ты плакался по поддержке старых версий интерпретатора?

Ответить | Правка | Наверх | Cообщить модератору

352. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 20:17

Ну наверное не для того чтобы за гвидо его факапы разгребать. Хотя если liquidation manager'ом позовут - я подумаю над этим...

Ответить | Правка | Наверх | Cообщить модератору

74. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –5 +/–

Сообщение от Vkni (ok), 15-Янв-20, 02:16

> И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне.
А не надо писать на Питоне вещи, которые стоит поддерживать. Это отличный инструмент для своей области, а вылезать из неё не стоит.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

96. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +2 +/–

Сообщение от Аноним (-), 15-Янв-20, 07:06

Кому мало можно посмотреть на историю "успеха" редхата, которые за наверное 20 лет так и не смогли сделать вменяемый пакетный менеджер, вместо этого тщетно пытаясь окультурить свой картонный макет. В результате этот картонный макет жрет море ресурсов, глючит, падает, унося за собой БД и потом система остается как после ядерного взрыва. Под бойкие рассуждения о транзакциях и прочей расовой верноте. Какие, к дьяволу, транзакции, когда пакетный менеджер встает в позу когда он ни бе, ни ме, ни кукареку?!

Ответить | Правка | Наверх | Cообщить модератору

106. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (4), 15-Янв-20, 07:32

простите, но унести с собой БД он не может - у него ее нет.
Индексы репо - не бд и могут в любой момент быть сгенерены заново.
А если у вас проблема с rpmdb - так угадайте, в какой несчастливый год и на каком вполне академичном языке толпа студентов решила переписать на гранты то ли орацла то ли не помню - до того - совершенно беспроблемный код? Приятно отметить, что ответочка прилетела грантодателю - в соплярисе у них, не поверите, те же проблемы ровно из того же источника ;-)
Выкинуть и переписать на sqlite - это не к редхатовцам, они двадцать лет боятся трогать даже обертку вокруг него. А если перепишут - сделают "как в орацле - орацле нашел способ обмазаться навозом - и мы найдем!"

Ответить | Правка | Наверх | Cообщить модератору

113. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 15-Янв-20, 07:51

> простите, но унести с собой БД он не может - у него ее нет.
А почему при OOM усе улетает с жоским стэктрейсом и при следующих попытках что-либо делать оно вопит "database corrupt"? И дальше вообще ни вперед, ни назад.
При том это тупо единственный пакетный менеджер который я знаю который настолько жоска ломается и потом хренподымешь. Ну например в дебиане в такой ситуации как максимум надо еще раз запустить инсталл, пакетник даже команду подскажет.
> Индексы репо - не бд и могут в любой момент быть сгенерены заново.
При том изначально эти *МАКАКИ* напихали туда аж XML. Потом оказалось что это жирное и дико тормозит - давайте дескать будем скулайтные базы сгружать?! Еще один пример когда сперва сделали, потом подумали. Уровень инженерии в этой поделке так и прет из всех щелей.
Даже у какой-нибудь фрибзды на фоне этого позора пакетный менеджер лучше, хахаха.
> до того - совершенно беспроблемный код? Приятно отметить, что ответочка прилетела
> грантодателю - в соплярисе у них, не поверите, те же проблемы
> ровно из того же источника ;-)
Уж не знаю когда оно там было совершенно беспроблемным. Во времена up2date чтоли?
> Выкинуть и переписать на sqlite -
Ну для начала - на си, чтоли. Почему-то это смогли даже фрибсдшники, лол. А, да, с скулайтом вроде. Типа кучка академбомжей может а редхат нет? :)

Ответить | Правка | Наверх | Cообщить модератору

140. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от пох. (?), 15-Янв-20, 11:09

> А почему при OOM усе улетает с жоским стэктрейсом
а почему у тебя при установке пакетов - oom? У меня вот нет никаких oom, а если  на системе творится чорти-что и сейчас кончится память - самое последнее что мне придет в голову, вместо чистки начать там еще что-то устанавливать.
> При том изначально эти *МАКАКИ* напихали туда аж XML.
что не так с xml в качестве структурированных данных? Конечно же yaml, как у freebsd, гораздо круче, и так занятно ломается об лишний невидимый символ?
> Даже у какой-нибудь фрибзды на фоне этого позора пакетный менеджер лучше, хахаха.
пакетный менеджер, не умеющий нормальных версий пакетов - конечно лучше, хахаха
> Ну для начала - на си, чтоли.
пишите. Полагаю, выйдет еще хуже и ненадежнее, а вполне вероятно - и медленнее.
Поскольку те операции, которые требуют затрат времени - они там и так  на си (поскольку это rpmlib)

Ответить | Правка | Наверх | Cообщить модератору

149. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Dimon (??), 15-Янв-20, 11:28

Где у FreeBSD yaml?

Ответить | Правка | Наверх | Cообщить модератору

159. Скрыто модератором –2 +/–

Сообщение от пох. (?), 15-Янв-20, 11:36

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

Ответить | Правка | Наверх | Cообщить модератору

163. Скрыто модератором +/–

Сообщение от Аноним (183), 15-Янв-20, 11:41

Настоящий бсдшник пользуется исключительно виндой. Поэтому извольте объясниться.

Ответить | Правка | Наверх | Cообщить модератору

165. Скрыто модератором –3 +/–

Сообщение от пох. (?), 15-Янв-20, 11:47

ааа, блин, действительно, откуда им знать.
manifests = "packagesite.yaml";
filesite = "filesite.yaml";

Ответить | Правка | Наверх | Cообщить модератору

209. Скрыто модератором –1 +/–

Сообщение от Аноним (398), 15-Янв-20, 13:53

> Настоящий бсдшник пользуется исключительно виндой.
А линухоиды, судя по комментариям в соседних новостях, предпочитают мак?

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

204. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (398), 15-Янв-20, 13:47

>> При том изначально эти *МАКАКИ* напихали туда аж XML.
> что не так с xml в качестве структурированных данных? Конечно же yaml,
> как у freebsd, гораздо круче, и так занятно ломается об лишний
> невидимый символ?
Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсем не нужно.

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

214. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от пох. (?), 15-Янв-20, 14:14

> Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае
> нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсем
вы уж определитесь, мущина - туда либо сюда? Если вам понадобилось их человекочитать - вы уже открыли их в нотпаде. Возможно, потому что лишний пробельчик-то уже просочился, и все паламалася? ;-)

Если бы было нужно только роботом парсить - было бы совершенно похрену, читаемы они или нет.

Ответить | Правка | Наверх | Cообщить модератору

222. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (398), 15-Янв-20, 14:57

>> Наверное тем, что _автоматически генерируемые_ списки и описания в yaml, в случае
>> нужды, человекочитаемее? И лезть туда с нотпадом что-то править обычно совсем
> вы уж определитесь, мущина - туда либо сюда? Если вам понадобилось их
> человекочитать - вы уже открыли их в нотпаде. Возможно, потому что
> лишний пробельчик-то уже просочился, и все паламалася? ;-)
Только после того, как вы раскроете тайну "просачивания" пробела в автоматически сгенерированный файл ;-)
Файл(ы), которые даже собирая свои собственные или сильно модифицированные пакеты для своей, локальной репы, можно годами ни разу не видеть и не открывать.
А то ведь читая вас можно подумать что приходится править YAML-манифесты нужно чуть ли не раз в полчаса.
И да:

{
  "name": "qt5-network",
  "origin": "net/qt5-network",
  "version": "5.13.2",
  "comment": "Qt network module",
  "maintainer": "kde@FreeBSD.org",
  "www": "https://www.qt.io/",
  "abi": "FreeBSD:12:amd64",
  "arch": "freebsd:12:x86:64",
  "prefix": "/usr/local",
  "sum": "14700af2b1d09fb9f49a9c14787f9e278ffbb77ef9b47c196c5c2006d046129c",
  "flatsize": 2523395,
  "path": "All/qt5-network-5.13.2.txz",
  "repopath": "All/qt5-network-5.13.2.txz",
  "licenselogic": "single",
  "licenses": [
    "LGPL21"
  ],
  "pkgsize": 568828,
  "desc": "Qt is a cross-platform application and UI framework for developers\nusing C++>
  "deps": {
    "ca_root_nss": {
      "origin": "security/ca_root_nss",
      "version": "3.48"
    },

читается приятнее, чем нагромождения тегов, еще и неплохо обрабатывается при (гипотетической) надобности с помощью grep/awk/jq.

Ответить | Правка | Наверх | Cообщить модератору

329. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 17:23

> надобности с помощью grep/awk/jq.
Абсолютно. XML одинаково хреново парсится и человеками и машинами.

Ответить | Правка | Наверх | Cообщить модератору

328. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 17:18

> сейчас кончится память - самое последнее что мне придет в голову,
> вместо чистки начать там еще что-то устанавливать.
Как показали эксперименты, Дебиан в тех же конфигурациях ведет себя культурно. Мне что, покупать более дорогие виртуалки спецом под эпизодический запуск пакетного менеджера?
> что не так с xml в качестве структурированных данных?
Крайне избыточный по возможностям (e.g. XSLT). Это гарантирует что либа парсинга - жирный тормозной монстр, с кучей уязвимостей и стремным апи, решающим совсем не те задачи и лопающие RAM оптом. В результате софт который это использует обречен иметь все минусы энтерпрайзного г@вн@. А попробуй парсить XML на 50К пакетов, узнаешь почему шляпа в скулайт кешировать стала. Так то да, пока там 100 записей, и XML - "типа база".
> Конечно же yaml, как у freebsd, гораздо круче,
Vs XML? Masterpiece of engineering!
> и так занятно ломается об лишний невидимый символ?
Вообще наполовину фича - детектирует левые данные. Чего ради это вообще в *тексте* должно быть? Это либо факап майнтайнеров либо атака mitm-а. В любом случае это должно быть убрано в темпе вальса.
> пакетный менеджер, не умеющий нормальных версий пакетов - конечно лучше, хахаха
Это дело наживное. А питонокрап вместо пакетного менеджера у редхата уже чуть 20 лет, и воз и ныне там. С какими-то голимыми полумерами типа dnf. На фоне обычного дебиановского апта это просто трэш и ад.
> пишите. Полагаю, выйдет еще хуже и ненадежнее, а вполне вероятно - и медленнее.
У дебианщиков нормально получилось. И надежно и шустро. Без всяких многолетних тантрических экспериментов и полунедохакофиксов.
> Поскольку те операции, которые требуют затрат времени - они там и так на си (поскольку это rpmlib)
А по нему и не скажешь - тупил в разы сильнее apt'а. Что за порно они там с dnf сделали я не следил, ибо гумно вместо пакетного менеджера задолбало раньше. Я считаю что 1 раз за 20 лет пакетный менеджер можно и нормально написать, а не левой пяткой вебмккак.

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

169. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (183), 15-Янв-20, 11:59

> А почему при OOM усе улетает с жоским стэктрейсом и при следующих попытках что-либо делать оно вопит "database corrupt"? И дальше вообще ни вперед, ни назад.
Недавно я по глупости запустил yum update из сеанса ssh, работающего через VPN. Совершенно случайно прилетело обновление VPN-демона... в общем, тоже "database corrupt". И дальше вообще ни вперед, ни назад.
Правда, через пару минут нашлась официальная инструкция от редхата, как перегенерировать базу данных. И — вы не поверите — волосы вновь стали мягкими и шелковистыми.
Да, я с редхатами имею дело редко. А вы, похоже, вообще с администрированием не связаны, раз искать информацию не умеете.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

322. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (-), 18-Янв-20, 14:54

> И дальше вообще ни вперед, ни назад.
Дарю идею: у дебиана нормальный пакетный менеджер. И следующие 5 лет с 10-м дебианом можно спать спокойно. А редхат... он имеет смысл если у вас подписка на саппорт, чтоли.
И, кстати, дебиану вообще и его пакетному менеджеру в частности нормалек даже на самом тощем vm с 128 оперативки. Без свопа. На минуточку, это ВЧЕТВЕРО меньше минимальных требований RHEL.
> мягкими и шелковистыми.
Ну его нафиг такой шелк...
> А вы, похоже, вообще с администрированием не связаны, раз искать информацию не умеете.
Я, по счастью, упомянутым маршрутом отправился - и теперь мне это просто неактуально. А чисто по человечески - вот на таких вещах и ощущаешь "сделано людьми, для людей" и "сделано индусами, на продажу". Блин, ну вот зачем мне софт выпиленый лобзиком индусами? Он мне такой даже бесплатно ни к чему - кошмарный слишком.

Ответить | Правка | Наверх | Cообщить модератору

384. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Anonymoustus (ok), 23-Янв-20, 18:57

> И, кстати, дебиану вообще и его пакетному менеджеру в частности нормалек даже
> на самом тощем vm с 128 оперативки. Без свопа. На минуточку,
> это ВЧЕТВЕРО меньше минимальных требований RHEL.
Только если раскатывать из образа каким-нибудь dd. Установить актуальный Debian штатным порядком на машину со 128 МБ ОЗУ сегодня уже не получится. А работать будет, да.

Ответить | Правка | Наверх | Cообщить модератору

396. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Аноним (-), 25-Янв-20, 00:24

> Только если раскатывать из образа каким-нибудь dd. Установить актуальный Debian штатным
> порядком на машину со 128 МБ ОЗУ сегодня уже не получится.
Ну как бы 128 у меня бывает только на виртуалках. И cp --reflink <template> <new_VM> неизмеримо быстрее чем час жевать сопли каким там еще дебиан-инсталлером.
А образ сделан обычным debootstrap'ом, где ничего лишнего. И я таки вижу разницу между затратами времени в секунду и в час. Это отличает меня от фанатов setup.exe :)
> А работать будет, да.
И работает. Хорошенько минимизированная VM даже и с 64 живет, по крайней мере "armhf". Но медленно, на кэш нифига не остается.

Ответить | Правка | Наверх | Cообщить модератору

225. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +20 +/–

Сообщение от Led (ok), 15-Янв-20, 15:07

> Это отличный инструмент
Причём он отличный в каждой минорной версии.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

231. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –17 +/–

Сообщение от Vkni (ok), 15-Янв-20, 18:06

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

Ответить | Правка | Наверх | Cообщить модератору

246. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от пох. (?), 15-Янв-20, 20:26

>> Причём он отличный в каждой минорной версии.
> Совершенно верно. И профессионал должен это знать, и не должен использовать инструмент
> не по назначению
расскажите же, о гуру - чем же назначение пихона 3.5 отличалось от назначения пихона 3.6 ?

Ответить | Правка | Наверх | Cообщить модератору

261. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –6 +/–

Сообщение от Vkni (ok), 15-Янв-20, 23:45

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

Ответить | Правка | Наверх | Cообщить модератору

298. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от пох. (?), 17-Янв-20, 19:14

> Практически ни в чём. Ключевое тут - меняется от версии к версии.
> Очевидно, что если вы используете этот язык для долгоживущего продукта, проблемы
> обеспечены.
в 2005м году, видимо, было еще далеко не очевидно.
Надо было быть не профессионалом-разработчиком, а профессионалом оккультных наук, чтобы предугадать "python3 это не новая версия, это другой йазык!", с последующим переобуванием в полете, и категорическим отказом от поддержки другого язы...простите, немодной мамонтово-кальной версии того же самого (причем с мутнейшей лицензией, не позволяющей никому занять вакантное место - см. пункт 7 последней версии).

Ответить | Правка | Наверх | Cообщить модератору

299. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –2 +/–

Сообщение от Vkni (ok), 17-Янв-20, 20:55

Извините, но вся около-питоновская культура - это "менять и не бояться выбрасывать старое". Типичный пример optparse vs argparse - разницы между ними почти нет, а та, что есть, совершенно не перекрывает геморрой от миграции и тестирования. Ocaml, например, уже лет 30 живёт с модулем https://caml.inria.fr/pub/docs/manual-ocaml/libref/Arg.html (для желающих что-то серьёзнее есть другие модули, а этот не меняется и не устаревает).
Я в 2005 за Питоном особенно не следил. Разве что видел, что строить на нём сложные GUI программы очень тяжело - они постоянно вылетали. Но я полагаю, что культура сообщества разработчиков тогда была примерно той же - "легко менять и легко выбрасывать старое".
А с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное:
"… пока противник рисует карты наступления, мы меняем ландшафты, причем в ручную. Когда приходит время атаки противник, теряется на незнакомой местности и проходит в полную не боеготовность. В этом смысл. В этом наша стратегия…"

Ответить | Правка | Наверх | Cообщить модератору

317. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 18-Янв-20, 10:42

> А с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное:
* первый релиз NumPy - 2006
* первый релиз IPython - 2001
* matplotlib - 2003
* pandas - 2008

PS: Для справки, OCaml - это 1996 год.

Ответить | Правка | Наверх | Cообщить модератору

324. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 18-Янв-20, 16:43

Эти библиотеки просты как валенки, плюс туда вливаются совершенно сумасшедшие средства и силы. И, кстати, API этих библиотек тоже не сказать, что стабилен.
А мы про Mercurial говорим, которому всё это вычматовское библиотечное до лампочки. Это совершенно разные области применения:
Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию Питона: быстро напиши, получи результат и выбрось. Никаких проблем с поддержкой совместимости и т.д. Поэтому здесь он выступает на 5+. Ну поломали вы numpy, ну следующий notebook будете писать на новом API.
Mercurial - это жесточайшая обратная совместимость (за невозможность читать старые репозитарии сделают Матумбу), неограниченная жизнь кода, большие тексты с огромным количеством ветвлений.

Ответить | Правка | Наверх | Cообщить модератору

338. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 18-Янв-20, 18:05

> Эти библиотеки просты как валенки
Эм?!
> плюс туда вливаются совершенно сумасшедшие средства и силы.
Крестик или трусы?
> А мы про Mercurial говорим, которому всё это вычматовское библиотечное до лампочки.
Ну, во-первых, там не только "вычматовские".  А во-вторых, вы писали
что "с таким вечно меняющимся фундаментом нельзя строить что-то долгосрочное" (ц)
Вот вам пожалуйста - таки можно.  А то, что нет второго hg, ну так извиняйте,
и первый не слишком взлетел.  Возможно это и связано с языком, а возможно дело
в танцорах.  Потому что другим ни поддерживать Python 3 ни делать
долгосрочные проекты - язык, очевидно, никак не мешает.
> Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию
> Питона: быстро напиши, получи результат и выбрось. Никаких проблем с поддержкой
> совместимости и т.д. Поэтому здесь он выступает на 5+. Ну поломали
> вы numpy, ну следующий notebook будете писать на новом API.
Data science - это модная фигня, не имеющая прямого отношения к собственно
science, помимо названия.  А в той science, за которую Нобелевские премии
дают - к совместимости отношение куда более трепетное, поскольку "получить
результат" мало.  Надо еще чтобы коллеги могли воспроизвести твое чудо.
> Mercurial - это жесточайшая обратная совместимость (за невозможность читать старые репозитарии
> сделают Матумбу), неограниченная жизнь кода, большие тексты с огромным количеством ветвлений.
Вы думаете, что .hdf5 можно читать каждый раз как-то "творчески"?

Ответить | Правка | Наверх | Cообщить модератору

388. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от freehck (ok), 23-Янв-20, 19:53

Поддерживаю по каждому пункту, Vkni (увы, модеры не могут ставить плюсики, так что приходится писать комментарии одобрения).
Хочу также заметить, что диалог с мыхандом есть монолог, но всё равно желаю Вам успехов! =)

Ответить | Правка | К родителю #324 | Наверх | Cообщить модератору

389. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 24-Янв-20, 10:12

> Поддерживаю по каждому пункту, Vkni
Т.е. вы тоже считаете, что на питоне нельзя строить что-либо
долгосрочное, несмотря на кучу предъявленных примеров обратного?
(Чу, или мне показалось как некто хвалился тем, что умеет
слышать аргументы оппонента?)
> модеры не могут ставить плюсики
Божечки, да школиe с хабра за вас уж натренировано - расставят
все как надо, контроль плюсометной моторики у них уже натренирован,
до головного мозгу дело не доходит...
PS: Модеры зато могут удалять то что им не понравится по желанию левой пятки.

Ответить | Правка | Наверх | Cообщить модератору

400. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 25-Янв-20, 22:44

> Т.е. вы тоже считаете, что на питоне нельзя строить что-либо
> долгосрочное, несмотря на кучу предъявленных примеров обратного?
Можно, но это потребует значительно больших вложений сил. Всё это тьюринг-полные языки, то есть, в достаточно широких рамках их в принципе можно заменить друг на друга.
Вопрос же в том, сколько сил придётся вложить в поддержку и разработку.

Ответить | Правка | К родителю #389 | Наверх | Cообщить модератору

405. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 26-Янв-20, 11:15

>> Т.е. вы тоже считаете, что на питоне нельзя строить что-либо
>> долгосрочное, несмотря на кучу предъявленных примеров обратного?
> Можно, но это потребует значительно больших вложений сил.
Отлично.  Флаг вам в руки: объясняйте почему есть куча проектов,
не ленящихся использовать питон, несмотря на необходимость энтих "сил",
а на OCaml есть в лучшем случае один Coq (и у меня, скажем так, есть
серьезные подозрения почему он на нем есть).

Ответить | Правка | К родителю #400 | Наверх | Cообщить модератору

409. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 26-Янв-20, 20:40

> Отлично.  Флаг вам в руки: объясняйте почему есть куча проектов,
> не ленящихся использовать питон, несмотря на необходимость энтих "сил",
Потому что в ряде случаев субъект, выбирающий язык, ориентируется на что-то внешнее:
1. Лёгкость набора кодеров под язык.
2. Зарплату кодеров.
3. Моду.
4. Уже имеющуюся экосистему.
> а на OCaml есть в лучшем случае один Coq
Это не так - есть та же Jane Street, вполне себе пилящая всякое своё.

Ответить | Правка | К родителю #405 | Наверх | Cообщить модератору

410. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 27-Янв-20, 11:30

>> Отлично.  Флаг вам в руки: объясняйте почему есть куча проектов,
>> не ленящихся использовать питон, несмотря на необходимость энтих "сил",
> Потому что в ряде случаев субъект, выбирающий язык, ориентируется на что-то внешнее:
Ну что вы, кроме пользователей OCaml ведь все - мазохисты...
> 1. Лёгкость набора кодеров под язык.
А вот это как раз разумное требование.  Особенно если учитывать, что (сюрприз,
сюрприз!) значительная доля ПО создается прикладниками, а вовсе не программистами.
>> а на OCaml есть в лучшем случае один Coq
> Это не так - есть та же Jane Street, вполне себе пилящая всякое своё.
Да нет, пожалуй это ровно один значимый FOSS проект на OCaml.  Еще что-то есть,
но это разная фигня вроде p2p клиентов (mldonkey?).

Ответить | Правка | К родителю #409 | Наверх | Cообщить модератору

402. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от Vkni (ok), 25-Янв-20, 22:51

> модеры не могут ставить плюсики
У меня давно сложилось впечатление, что +- ставят боты или люди с примерно той же программой поведения, поэтому я их игнорирую.

Ответить | Правка | Наверх | Cообщить модератору

406. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от myhand (ok), 26-Янв-20, 11:18

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

Ответить | Правка | К родителю #402 | Наверх | Cообщить модератору

407. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от freehck (ok), 26-Янв-20, 19:12

>> модеры не могут ставить плюсики
> У меня давно сложилось впечатление, что +- ставят боты или люди с
> примерно той же программой поведения, поэтому я их игнорирую.
Имхо, +- есть в некотором смысле показатель солидарности со мнением. Чем писать 100 комментов вида "поддерживаю", "согласен", и т.п. -- куда разумнее воспользоваться системой рейтинга.
Разумеется, рейтинг нужен не для тебя или меня. Рейтинг есть направляющая для новопришедших, которые ещё не знают, как тут ориентироваться, что хорошо, что плохо.  И наш рейтинг вроде бы корректно пока отражает действительность, в отличие от, скажем, хабрахабровского.

Ответить | Правка | К родителю #402 | Наверх | Cообщить модератору

408. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 26-Янв-20, 20:34

Ну странный какой-то показатель. Вот у меня в практически всех комментах здесь мысль одна - "язык, это инструмент, который надо применять в соответствующей области". И почему-то один из этих комментов имеет -15, а остальные - что-то в районе нуля. Хотя какая разница?

Ответить | Правка | К родителю #407 | Наверх | Cообщить модератору

397. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (397), 25-Янв-20, 00:28

> Data science, aka automated statistics - это штука, прекрасно ложащаяся в идеологию
> Питона: быстро напиши, получи результат и выбрось.
Ну так откуда-то оттуда змий и полез. И вот там это и правда никому не создает проблем - половина такого софта вполне себе одноразовый лабораторный макет. Никому же не приходит в бошку требовать от лабораторной установки гламурный корпус и хороший юзеринтерфейс, те кто с ней возятся и так разберутся.

Ответить | Правка | К родителю #324 | Наверх | Cообщить модератору

401. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 25-Янв-20, 22:50

> И вот там это и правда никому не создает проблем - половина такого софта вполне себе одноразовый лабораторный макет.
Более того, там это очень полезно. Например, текст в значительной части Wolfram Notebook или Jupyter Notebook совершенно не обязан быть корректной программой (там могут быть какие-то обрезки кода, сложенные внизу впрок). При этом система, которая будет настаивать на обязательной компилируемости этого Notebook, будет только мешать (это я как опытный пользователь пишу).

Ответить | Правка | Наверх | Cообщить модератору

315. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 18-Янв-20, 10:34

> Надо было быть не профессионалом-разработчиком, а профессионалом оккультных наук, чтобы
> предугадать "python3 это не новая версия, это другой йазык!"
А чего, с прохвессионалов-разработчиков не требуют более навыков чтения?  Эта страшная
тайна ведь была в whatsnew написана прям тогда.

Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

316. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от пох. (?), 18-Янв-20, 10:39

вот лохи и повелись.
А оно херак, и в полете - переобулось. Оказывается все таки не новый язык, а новая версия интерпретатора, а "этот ваш мамонтовый кал" - нинунанинуна.
И registered trademark вишенкой на тортике, чтобы те кому нужно для тех кому нужно - все равно не сумели сделать надежно.

Ответить | Правка | Наверх | Cообщить модератору

318. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 18-Янв-20, 10:45

> А оно херак, и в полете - переобулось. Оказывается все таки не
> новый язык, а новая версия интерпретатора
the first ever intentionally backwards incompatible Python release
Мне делается страшно за ваше здоровье от наблюдений за тем как вы ковыряетесь в носу.  Пожалуйста, перестаньте.

Ответить | Правка | Наверх | Cообщить модератору

323. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от пох. (?), 18-Янв-20, 16:36

Interviewed Friday morning, foundation representative David Goodger said "We fixed problems so we can go forward and add features more easily in the future without having to work around previous bad decisions."
A transitional release toward the 3.0 platform, Python 2.6, was released in October and updated with bug fixes in Python 2.6.1 this week. A Python 2.7 release also is planned, and the foundation anticipates most people will stick with the Python 2 line for years, Goodger said.
что вас удивляет в том, что лохи и повелись?

Ответить | Правка | Наверх | Cообщить модератору

325. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Vkni (ok), 18-Янв-20, 16:46

> А оно херак, и в полете - переобулось. Оказывается все таки не
> новый язык, а новая версия интерпретатора, а "этот ваш мамонтовый кал"
> - нинунанинуна.
А библиотеки вы вообще не учитываете? Основная проблема же в том, что библиотеки меняются.

Ответить | Правка | К родителю #316 | Наверх | Cообщить модератору

289. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +1 +/–

Сообщение от freehck (ok), 16-Янв-20, 15:10

>> Это отличный инструмент
> Причём он отличный в каждой минорной версии.
Ты сделал мой день, Led! Аж слеза навернулась! =)

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

385. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Anonymoustus (ok), 23-Янв-20, 19:35

>>> Это отличный инструмент
>> Причём он отличный в каждой минорной версии.
> Ты сделал мой день, Led! Аж слеза навернулась! =)
Редчайший случай, когда он написал что-то умное, а не просто наследил в комментариях.

Ответить | Правка | Наверх | Cообщить модератору

387. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от freehck (ok), 23-Янв-20, 19:45

> Редчайший случай, когда он написал что-то умное, а не просто наследил в комментариях.
Пожалуйста, ребята, не ссорьтесь. =)

Ответить | Правка | Наверх | Cообщить модератору

181. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –3 +/–

Сообщение от myhand (ok), 15-Янв-20, 13:04

> посмотрите на то, в каком состоянии "готовности" находятся стандартные библиотеки.
Посмотрите на гражданина, до сих пор не умеющего в читать документацию.
> За тридцать-то лет языка они, небось, должны быть совсем в ином состоянии.
Прям можно подумать, что у какого-то языка есть сравнимая по функционалу стандартная библиотека.
Собственно, в количестве батареек и находится большая часть проблемы.  Оно вот это
все действительно нужно там?  Вроде потихоньку начинают выковыривать.
> И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне.
Вы просто не писали нечего дальше скриптиков на 1kLOC.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

373. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (373), 20-Янв-20, 19:07

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

Ответить | Правка | Наверх | Cообщить модератору

378. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." –1 +/–

Сообщение от myhand (ok), 21-Янв-20, 08:56

Хорошая документация - это растяжка?

Ответить | Правка | Наверх | Cообщить модератору

413. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..." +/–

Сообщение от Аноним (413), 17-Фев-20, 22:20

> Хорошая документация - это растяжка?
Если в нее после каждой минорной версии вштыривать надо - пожалуй что да.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	16. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+1 +/–
	Сообщение от freehck (ok), 14-Янв-20, 23:43
	> ощущение будто тебя обманывают > проще переписать программу на каком-то другом языке, чем Да уже который год говорю, где обманывают: посмотрите на то, в каком состоянии "готовности" находятся стандартные библиотеки. За тридцать-то лет языка они, небось, должны быть совсем в ином состоянии. =/ И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне. Даже пресловутый мёртвый перл5 заставлял меня в своё время удивляться на порядки меньше, нежели питон2. Но ладно. Я сейчас опять ведь начну питоносpач... А так надоели фанаты оного... Короче, ребята, давайте сразу засчитывайте мне слив, ибо я спорить не намерен в этот раз. Все несогласные -- лесом. =/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+6 +/–
	Сообщение от Аноним (32), 15-Янв-20, 00:30
	> мёртвый перл5 Не мертвый, а стабильный.))) И это прекрасно, потому что предсказуемо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+3 +/–
	Сообщение от Аноним (-), 15-Янв-20, 07:02
	> Не мертвый, а стабильный.))) Именно. Ну вон прога на C89. До сих пор компилится и работает. При желании ее даже можно менять если надо. И никто не орет что C89 - deprecated, дескать. Более того - требование все резко переписать... ну... а вы сможете грамотно переписать какое-нибудь крипто, или допустим рида-соломона? Для того чтобы не накосячить надо знать пару специфичных разделов математики, однако. Иначе потом переписанное будет глючным или даже уязвимым. > И это прекрасно, потому что предсказуемо. Некоторым нравится закинуть гранату в проект и посмотреть что будет :). Будет примерно вон то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	186. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–3 +/–
	Сообщение от myhand (ok), 15-Янв-20, 13:15
	> Именно. Ну вон прога на C89. До сих пор компилится и работает. Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, если тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять и использовать ее. Так можно! Без разрешения Папы Римского! Не упустите свой шанс!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	213. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+1 +/–
	Сообщение от пох. (?), 15-Янв-20, 14:13
	>> Именно. Ну вон прога на C89. До сих пор компилится и работает. > Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, если хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89 - вовсе не надо искать в несуществующих архивах 89го года именно ту версию компилятора и героически ее ставить на любую систему, включая те на которые не очень ставится. В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от хипстаподелок.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	228. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от myhand (ok), 15-Янв-20, 16:08
	> хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89 > - вовсе не надо искать в несуществующих архивах 89го года именно > ту версию компилятора Ну да, бедные разработчики тянут весь зоопарк стандартов... > В этом, собственно, и отличие пока еще сохранившихся нормальных средств разработчика от > хипстаподелок. Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	245. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от пох. (?), 15-Янв-20, 20:24
	>> хочешь я расскажу тебе страшное: и чтобы скомпилировать ту прогу на C89 >> - вовсе не надо искать в несуществующих архивах 89го года именно >> ту версию компилятора > Ну да, бедные разработчики тянут весь зоопарк стандартов... бедняжечки... Как же это оказывается сложно - просто держать шаловилвые ручонки - в опе, и ничего работающего ими не трогать за пределами того, что необходимо. Но зато их разработка, пожалуй, проживет еще пол-века, а пихон - выкинут набижавшие новые поколения любителей все поломать и ничего путного не построить. В пользу еще какого-нибудь фуфла.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	252. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от myhand (ok), 15-Янв-20, 21:39
	>> Ну да, бедные разработчики тянут весь зоопарк стандартов... > бедняжечки... Как же это оказывается сложно - просто держать шаловилвые ручонки - > в опе, и ничего работающего ими не трогать за пределами того, что необходимо. Ну вообще-то - это сложно. Приходится не просто "не трогать", а обставлять все больше мест специальными костылями, пропорционально количеству поддерживаемых стандартов. Иной раз вы производите впечатление неглупого человека, а порой... > Но зато их разработка, пожалуй, проживет еще пол-века Ну, из стандартов C тоже кой-что выкидывают. В _этом_ смысле - язык точно не проживет еще пол-века. > а пихон - выкинут набижавшие новые поколения любителей все поломать Пайтон хоронят уже лет тридцать. "Stop! This is silly."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	313. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (-), 18-Янв-20, 02:00
	> Пайтон хоронят уже лет тридцать. "Stop! This is silly." При том в последнее время достигают в этом определенных успехов. Оплот пихтонрастов в виде гуголя и нескольких иных нагруженных сайтов что-то go полюбили.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	321. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (-), 18-Янв-20, 14:46
	> Ну да, бедные разработчики тянут весь зоопарк стандартов... Новые стандарты в массе своей - superset старых. За редким исключением. А так чтобы именно deprecate, с жестким вынесением совместимости - в сях и плюсах почти не практикуется. В отличие от. > Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса. Типа, интерпретеры питона сильно лучше? :)
	Ответить \| Правка \| К родителю #228 \| Наверх \| Cообщить модератору


	334. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от myhand (ok), 18-Янв-20, 17:50
	> А так чтобы именно deprecate, с жестким вынесением совместимости - в сях > и плюсах почти не практикуется. Тем не менее, быват, быват. Гениальные дизайнеры языка, планирующие на полвека вперед - они на кисельных берегах сидят, молочных рек... >> Только нормальные ср^W^Wконпиляторы давно уже можно в финал IOCCC приглашать вне конкурса. > Типа, интерпретеры питона сильно лучше? :) В любом большом проекте без поллитры не разберешься. Но не настолько все плохо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	346. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (332), 18-Янв-20, 19:47
	> Тем не менее, быват, быват. Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный и потому ни разу не встречавшийся мне в диком виде. В отличие от скриптов которые на каждом углу. Поэтому с практической точки зрения - старые программы и собираются и работают. Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить. А можно и забить, если экскурсия в код не была частью планов. С питоном так не катит - там скорее грохнется с адским стэктрейсом на полпути к финишу. И это неудобно - потому что довольно трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть. Именно тогда когда это очень некстати. > Гениальные дизайнеры языка, планирующие на > полвека вперед - они на кисельных берегах сидят, молочных рек... Ну так питонисты сперва делают, потом думают. Не все же такие. > В любом большом проекте без поллитры не разберешься. Вот то-то и оно. > Но не настолько все плохо. Типа, BDFL от хорошей жизни сбежал? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	353. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от анонн (ok), 18-Янв-20, 20:39
	> Поэтому с практической точки зрения - старые программы и собираются и работают. Ну соберите мне третьекеды на современной системе, что ли. Да куда там кеды, тут уже и VirtualBox не самой свежей версии (5.2.6) - и тот не собирается без бубна. Еще ему gcc версии от 4 до 7 подавай, аналогично с LLVM для новых версий в 5 ветке (5.2.34+) "ваша версия LLVM слишком новая! C 8 и 9 проблемы в рантайме!" # Check for gcc with version >= 3.2. # We depend on a working gcc, if we fail terminate in every case. ... log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x" Про сборку его морды с Qt4, который отовсюду выкинули - не заикаюсь. Так ведь даже код для _Qt5_ придется править, тот же #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid use of incomplete type ‘class QButtonGroup’". В общем, если вы с наскока припоминаете только 1 пример, то в контексте обсуждения это просто говорит не в вашу пользу …
	Ответить \| Правка \| Наверх \| Cообщить модератору


	370. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (-), 20-Янв-20, 18:19
	> Ну соберите мне третьекеды на современной системе, что ли. Проект TDE занимается как раз этим самым :) > # Check for gcc with version >= 3.2. > # We depend on a working gcc, if we fail terminate in every case. И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что сказано, но при чем тут си это все-таки не поясняет. > Так ведь даже код для _Qt5_ придется править, тот же > #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid > use of incomplete type ‘class QButtonGroup’". По сравнению с питоном - один инкоюд это не так уж плохо. Ну и вообще, это отдельная жирная сторонняя либа - к сям и плюсам это само по себе отношения не имеет. Поменять интерфейс компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в либы/компоненты вроде. > В общем, если вы с наскока припоминаете только 1 пример, то в > контексте обсуждения это просто говорит не в вашу пользу … А может не в мою? Мне кажется, кто-то не разобрался в технологиях, но мнение уже имеет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	375. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от анонн. (?), 20-Янв-20, 20:35
	>> Ну соберите мне третьекеды на современной системе, что ли. > Проект TDE занимается как раз этим самым :) И? Хотите сказать, что раз целый отдельный проект занимается этим, то это однозначное доказательство "старые программы собираются и работают" в действии? Как-то не очень убедительно. Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет) >> # Check for gcc with version >= 3.2. >> # We depend on a working gcc, if we fail terminate in every case. > И в каком месте зацитированное вообще является сями? Это вроде кус билдсистемы какой-то. И то что его как-то странно сделали - ну так > в билдсистеме можно что угодно написать. Билдсистема проверит и сделает что > сказано, но при чем тут си это все-таки не поясняет. До этого там было: https://github.com/svn2github/virtualbox/commit/b05888fae993... - log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x, gcc 5.x or gcc 6.x" + log_failure "gcc version $cc_maj.$cc_min found, expected gcc 4.x...7.x" Видимо, написали просто так, из любви к искусству, а не потому что постоянно что-то ломается в билде, по типу: https://www.virtualbox.org/ticket/18624 >> Так ведь даже код для _Qt5_ придется править, тот же >> #include <QButtonGroup> вставлять, иначе компиляция завалится с "invalid >> use of incomplete type ‘class QButtonGroup’". > По сравнению с питоном - один инкоюд это не так уж плохо. > Ну и вообще, это отдельная жирная сторонняя либа - к сям > и плюсам это само по себе отношения не имеет. Поменять интерфейс > компонента несовместимо с прошлыми версиями можно на любом ЯП умеющем в > либы/компоненты вроде. Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали! Что совой о пень, что пнем о сову - результат вообще-то не сильно отличается для конечного пользователя. Это притом что VBox 5.2.6 вышел в 2018 году. Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку старых пакетов в более современном окружении. >> В общем, если вы с наскока припоминаете только 1 пример, то в >> контексте обсуждения это просто говорит не в вашу пользу … > А может не в мою? Мне кажется, кто-то не разобрался в технологиях, > но мнение уже имеет. А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул не особо подумав и теперь пустился в демагогию. Потому что по существу вопроса тут 0 целых крен десятых, лишь передерг да оправдывания "по сравнению с питоном не страшно!".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	377. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (-), 20-Янв-20, 22:55
	> И? Хотите сказать, что раз целый отдельный проект занимается этим, то это > однозначное доказательство "старые программы собираются и работают" в действии? Я хочу сказать что проблемы третьекедов вытекают не из компилеров и сей. А из 1) Того что на майнтенанс оных технологий подзабили. 2) Некоторые технологии кедов 3 стали несколько иррелевантны (e.g. dcop vs dbus) и это вообще не по линии ЯП. 3) Взаимодействие с либами на которые они завязаны и поддержка всего этого. К самим по себе сям чье-то там (не)желание вечно поддерживать третий куть не относится никак. Собственно сабжи откопали и перекомпилили стюардессу. А зачем откапывать? Все остальные на эту версию забили - только поэтому. > Как-то не очень убедительно.Неужто KDE1 и Qt1/2/3 тоже наверное влет соберуться? (нет) Если они и завалятся то явно не по линии ЯП и компилеров. Скорее по зависимостям от внешних компонентов, что к ЯП и компилерам не относится чуть менее чем никак, это взаимодействие компонентов. Тем не менее, прошареные некромансеры периодически такое собирают. И таки да, можно это сделать современным компилером - вот новый компилер этому как правило не мешает вообще совсем никак. Разве что варнингами активнее трындит. Какие-то исключения возможны наверное, но их немного и я никак не могу вспомнить - где надо перепахивать всю прогу по всей площади, как в питоне? > постоянно что-то ломается в билде, по типу: > https://www.virtualbox.org/ticket/18624 При том опять же к ЯП и компилеру это относится довольно сбоку - это новомодные оптимизации странно играют с их чудесами. "As expected, the problem is with PCH -- Workaround: VBOX_WITHOUT_PRECOMPILED_HEADERS := 1". > Угум, угум. Тум считаем, там не считаем, а вот тут вот - рыбу заворачивали! Если сям и плюсам считать все кути и прочие - тогда питону посчитаем всякие Zope'ы, во! :) > сильно отличается для конечного пользователя. А зачем пользователю вообще что-то собирать, программить и прочее? Не понимаю. И тем не менее, сборка древних кед - это больше вообще по линии майнтенанса и интеграции чем програмизма, ЯП и компилеров. Потому что сам по себе яп и компилеры там как правило и не мешают особо. > Впрочем, ничего нового или удивительного для тех, кто ментейнил или ментейнит парочку > старых пакетов в более современном окружении. Вообще странноватое сочетание, свежий gcc с старым пакетом. Но это где-то на грани бага на самом деле. Правда я не очень в курсе чьего именно, мне от vbox ничего не надо по счастью, так что простите великодушно что я в его начинке копаться не буду. > А мне кажется, кто-то почти-совсем-не-трехсотоанонимный, как частенько с ним бывает, ляпнул > не особо подумав и теперь пустился в демагогию. Интересно же посмотреть чего высосут из пальца вебманки? Вот тут притащили за уши сторонние либы и даже раскопали какое-то чудесатое взаимодействие с гцц. > да оправдывания "по сравнению с питоном не страшно!". А я виноват что примерно так оно и обстоит? Во всяком случае я почему-то смог собрать ряд весьма античных штук без перепиливания половины кода. С питоном так не катит. И переводы стрелок на сторонние либы - как-то не комильфо, тогда давайте и питону всякие zope'ы считать, вот уж мало не покажется.
	Ответить \| Правка \| К родителю #375 \| Наверх \| Cообщить модератору


	354. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от myhand (ok), 18-Янв-20, 20:55
	>> Тем не менее, быват, быват. > Конкретные примеры? Я вот целый _1_ могу с наскока вспомнить. Крайне специфичный > и потому ни разу не встречавшийся мне в диком виде. Да берете стандарт и просто делаете поиск. В С11, например, gets удалена. Или вот, в C99 добавили ключевое слово restrict. > В отличие от скриптов которые на каждом углу. Ну прям так на каждом? Используйте нужный вам интерпретатор - и все будет работать до морковкина заговенья. Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько больше чем libc. И что будет если взглянуть как обстоит дело с обратной совместимости в 100500 сторонних сишных либах? > Поэтому с практической точки зрения - старые программы и собираются и работают. Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца 80-х прошлого века. > Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А > дальше уже по ситуации, если хочется, можно и исправить. Да нет. "int restrict = 1;" - и усе, просто не соберется. > С питоном так не катит - там скорее грохнется с адским стэктрейсом > на полпути к финишу. И это неудобно - потому что довольно > трудно понять сколько вокруг летающих роялей, пытающихся на тебя ВНЕЗАПНО упасть. Во-первых, это уже из области "динамические языки - это плохо". А с обратной совместимостью в питон приблизительно также как и том же C. Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы), но никогда ВНЕЗАПНО. Что-то объявляется устаревшим, а уж потом в следующих релизах выкидывается. Везде так. Никто серебряной пули не придумал. >> Гениальные дизайнеры языка, планирующие на >> полвека вперед - они на кисельных берегах сидят, молочных рек... > Ну так питонисты сперва делают, потом думают. Не все же такие. Где не такие - я только что написал выше. Удачи попасть в Воображляндию. >> Но не настолько все плохо. > Типа, BDFL от хорошей жизни сбежал? :) Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет подобной собачьей должности...
	Ответить \| Правка \| К родителю #346 \| Наверх \| Cообщить модератору


	372. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (-), 20-Янв-20, 18:58
	> В С11, например, gets удалена. Как "inherently dangerous function". И тем не менее, C89 код таки соберется. В режиме C89, разумеется. А я разве обещал что C89 код по мановению волшебной палочки станет C11? :) Более того - в C89 и коменты с // нельзя начинать и в режиме C89 без расширений компилер имеет полное право завернуть такой код. > Или вот, в C99 добавили ключевое слово restrict. Но вот C89 проги как собирались так и собираются. А хотя-бы и в режиме C89 - потому что C99 отличается не только, блин, названием. И там даже типы лучше использовать другие - менее долбанутые чем в изначальном си. Потому что int something - это достаточно абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы и компилера. В C99 это исправили, сделав куда более разумные типы - потому что писать на именно C89 без расширений код... какая-нибудь мелкая букашка типа pic может иметь свое мнение о том что такое int. Ну или у некоторых DSP например char 16-битный. Формально это валидно, фигли. А реально - поэтому и придумали C99 с явно озвученным числом битов на тип, так куда пресказуемее. > Ну прям так на каждом? Используйте нужный вам интерпретатор - и > все будет работать до морковкина заговенья. Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается террариум какой-то развести. Почувствуйте разницу. > Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько > больше чем libc. И что будет если взглянуть как обстоит дело > с обратной совместимости в 100500 сторонних сишных либах? Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться? Я конечно понимаю что очень круто запихнуть весь глобус в стандартную библиотеку, но жабисты говорят что с этим потом бывают некоторые нюансы... > Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца > 80-х прошлого века. Ну так пока у народа есть этот код и его работа народу требуется - его и таскают. А все сломать и потребовать всех с ножом к горлу переписать модно, молодежно ... э, блин, а кто вон тому поезду колеса крутить будет? Ну не ты же, хипстер, фирмварь на питончике быстро перенакорябаешь? С такой фирмварью он с рельсов улетит или спалит ящик силовой электроники, стоящей больше чем твоя зарплата за год. Вот и таскают. > Да нет. "int restrict = 1;" - и усе, просто не соберется. Так никто и не обещал что любой код C89 собирается как C99. Иначе какой смысл вообще называть это новым стандартом? Можно и дальше говорить что это C89, разве не логично? :) Значит придется этот код как C89 билдить. У сишников так можно, в отличие от. > Во-первых, это уже из области "динамические языки - это плохо". И таки я считаю что это плохо. 1) Потому что гарантирует жоские проблемы с перфомансом. 2) Потому что статический анализ кода идет псу под хвост. По поводу чего начинаются ужимки с урезанными subset'ами которые типа не совсем питон, зато нет такие тормозливые. Но переписывать тонны гуано на это всем лениво - и они где-то там, влачат существование. > А с обратной совместимостью в питон приблизительно также как и том же C. Да вот не так же - у меня в системе только одна версия libc, одна версия компилера и проч. А компилить может и C11 и C89 и чего там еще. В случае с питоном же мне рассказывают что террариум - так и задумано. А ну его в пень такие задумки! > Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы), Ну насчет возможностей можно и поспорить. Я вот сишным кодом могу себе проц забутявить. Даже по сути без асма, без внешних рантаймов. А попробуйте так одним питоном, куле? :) Ну и да, зачем вообще все переть в стандартную либу? Чтобы показать что муки жабистов при выпуске новой явы - еще не предел? Ну спасибо, это кажется удалось :) > Везде так. Никто серебряной пули не придумал. Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон тот C89 код. Здесь и сейчас. А то что у меня компилер довольно новый - ну да, и чего? > в Воображляндию. Я бы сказал что с питоном светит только геморройлэнд и багодромы. > Хорошо что просто сбежал, а мог бы и ножичком, после стольких-то лет > подобной собачьей должности... Ножичком? Кого? Тех кто его творениями пользуется? Лучше гранату в этот обезьянник подбросить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	380. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от myhand (ok), 21-Янв-20, 09:57
	>> В С11, например, gets удалена. > Как "inherently dangerous function". И тем не менее, C89 код таки соберется. > В режиме C89, разумеется. Да, детка. Вы начинаете понимать принцип... > А я разве обещал что C89 код > по мановению волшебной палочки станет C11? :) Ну типа того: " Как максимум компилер из-за улучшения статического анализа может варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить." > Более того - в C89 и коменты с // нельзя начинать и > в режиме C89 без расширений компилер имеет полное право завернуть такой код. Тоже неплохой пример. >> Или вот, в C99 добавили ключевое слово restrict. > Но вот C89 проги как собирались так и собираются. Пока вам достаточно стандартной библиотеки... Ну так и конкретная версия интерпретатора пайтона - будет работать с вашими скриптами как угодно долго. >> Ну прям так на каждом? Используйте нужный вам интерпретатор - и >> все будет работать до морковкина заговенья. > Gcc мне почему-то одной версии достаточно на все оказии, а тут предлагается > террариум какой-то развести. Почувствуйте разницу. Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и версией интерпретатора. gcc - тащит несколько версий стандартов, интерпретатор питона, грубо говоря - один (хотя пару релизов старые скрипты будут работать с гарантией, разве что добавив в выхлоп предупреждений). Про gcc вам уже ответили граждане. То что вам достаточно жить ровно с одной версией компилятора - говорит только о скудости опыта (хотя я бы уже рискнул сделать более суровое обобщение). >> Чаще всего меняется что-то в стандартной библиотеке, которая умеет несколько >> больше чем libc. И что будет если взглянуть как обстоит дело >> с обратной совместимости в 100500 сторонних сишных либах? > Ну так может быть с стандартной библиотекой тоже надо уметь вовремя угомониться? Так куда не запихни - получатся те же яйца. >> Да, покуда компиляторы тащат с собой поддержку стандартов языка ажно из конца >> 80-х прошлого века. > Ну так пока у народа есть этот код и его работа народу > требуется - его и таскают. Его таскают, в основном, из любви к закрытому коду корпорастов. От них же и идут основные стоны про то как часто в питон что-то "ломают". Потому что принцип остается прежний: "разработка" заключается в том, что слепили - и забыли. В мире FOSS - совершенно другая картина. Большинство востребованных проектов на питон - давно сумели свинтить на третий питон без стонов вроде сабжа. > А все сломать и потребовать всех > с ножом к горлу переписать модно, молодежно ... э, блин, а > кто вон тому поезду колеса крутить будет? На самом деле, вы не сможете найти мало-мальски серьезный открытый проект, использующий какой-нибудь античный C89. Подавляющая часть адаптирована до такой степени, что код как минимум собирается на наиболее современном стандарте. >> Да нет. "int restrict = 1;" - и усе, просто не соберется. > Так никто и не обещал что любой код C89 собирается как C99. > Иначе какой смысл вообще называть это новым стандартом? Ну кое-кто - обещал, см. выше. Конечно, я подозревал, что вы будете юлить "я это не имел в виду, я это введу..." > У сишников так можно, в отличие от. Мне вам что, картинки нарисовать как можно запускать скрипты с нужной вам версией интерпретатора питон? >> Во-первых, это уже из области "динамические языки - это плохо". > И таки я считаю что это плохо. Вам никто не запрещает так считать. Просто непонятно почему это мнение кого-то должно волновать? >> А с обратной совместимостью в питон приблизительно также как и том же C. > Да вот не так же - у меня в системе только одна > версия libc, одна версия компилера и проч. Я вас поздравляю и даже немного завидую. Значит у вас все впереди! Может однажды поучаствуете в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах... ПТУ^WУниверситет там закончите или что там у вас. >> Да, чаще ломают (что неудивительно, поскольку возможности искаропки несравнимы), > Ну насчет возможностей можно и поспорить. Ну об чем тут можно спорить? Что можно запилить поддержку json на C? Очереди с приоритетом? Можно, конечно. Но мало кому в XXI веке уже интересно стругать себе в 100500 раз инструменты из палок и г-на, есть масса более других задач. > Я вот сишным кодом могу себе проц забутявить. Не уверен, что я понял вашу мову. Видимо, речь об использовании питона для низкоуровневого программирования. В принципе, можно, только зачем? > Ну и да, зачем вообще все переть в стандартную либу? Речь шла немного о другом: что вы сравниваете несравнимое. Т.е. чтобы быть совсем уж честным при сравнении совместимости - вам надо посмотреть как обстоит дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый с питоновской стандартной библиотекой. >> Везде так. Никто серебряной пули не придумал. > Не, вот пардон, я таки настаиваю что могу скомпилить и поюзать вон > тот C89 код. Здесь и сейчас. Так и скрипт на питоне можно запустить нужной версией интерпретатора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	395. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–1 +/–
	Сообщение от Аноним (395), 24-Янв-20, 23:22
	> Да, детка. Вы начинаете понимать принцип... Ну так в результате я могу юзать вон тот древний код с вот этим свежим компилером. Не патча полпланеты лично. Более того - можно даже сделать программу из разных по версии сей, это ни к чему такому не ведет. > Ну типа того: " Как максимум компилер из-за улучшения статического анализа может > варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить." В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :) > Тоже неплохой пример. Ну дык. Однако те кто кодил под C89 и не юзали такие каменты. А если кто хотел фичу нового стандарта - ну вот тут придется проапгрейдить код уже. Но вот это - опционально. Можно забить, обойдясь без новых фич в этом файле. > Пока вам достаточно стандартной библиотеки... И иногда у меня даже и стандартной библиотеки нет. А где я на МК с простой как тапок фирмварой файловую систему возьму? :) А так расписываться за действия вообще всех програмеров и их либ - занятие провальное. Вон там zope, кстати, в соседней новости жжот, не к ночи будь поманут :) > Ну так и конкретная версия интерпретатора пайтона - будет работать с > вашими скриптами как угодно долго. А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта". > Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и > версией интерпретатора. Ну и вот с этим как бы грабли. Мне достаточно поставить 1 "системный" компилер из репов - и он прожует что у меня есть. А с питоном - фигвам, так не катит. А если б мне надо было таскать по версии компилера на стандарт, да еще чтоб из проги на C99 хрен поюзаешь алгоритм на C89 - блин я б тогда наверное си "любил" так же как и питон. > Про gcc вам уже ответили граждане. То что вам достаточно жить > ровно с одной версией компилятора - говорит только о скудости опыта Булшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все. Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит. > Так куда не запихни - получатся те же яйца. А вот не те же. Если в стандартную либу пхать, отвалится у большего числа народа. А опциональная либа - там во первых програмеры дважды подумают до того как апи менять, под угрозой что их либу все перестанут юзать, а во вторых - половина обнаружит что им и без этой либы можно обойтись. > Его таскают, в основном, из любви к закрытому коду корпорастов. Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?! > принцип остается прежний: "разработка" заключается в том, что слепили - и забыли. Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один. > В мире FOSS - совершенно другая картина. Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не для того чтобы улучшить а потому что на их бошку новая версия свалилась. > На самом деле, вы не сможете найти мало-мальски серьезный открытый проект, > использующий какой-нибудь античный C89. А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной вот алгоритмике. И он был достаточно щедр для того чтобы оформить частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89. > Подавляющая часть адаптирована до такой степени, что код как минимум > собирается на наиболее современном стандарте. Да зачем? Они и как C89 прекрасно юзабельны. В том числе и проектами чей собственный код соответствует последним стандартам. > Ну кое-кто - обещал, см. выше. Цитату обещаний плз? > Мне вам что, картинки нарисовать как можно запускать скрипты с нужной > вам версией интерпретатора питон? Спасибо, но мне как-то по жизни оказалось проще найти аналоги на чем-нибудь другом. Поэтому на данный момент я уже не имею таких проблем. > Просто непонятно почему это мнение кого-то должно волновать? Ага, я за ним столько бежала, чтобы сказать ему что он мне пофиг... %))) > в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах... > ПТУ^WУниверситет там закончите или что там у вас. Дык участвую. Но естественно не в пихоносрани с вебмакаками. Мне такой крап просто не интересен. > Ну об чем тут можно спорить? Что можно запилить поддержку json на C? > Очереди с приоритетом? [...] ...поэтому сишники просто цепанут библиотеку - и дело в шляпе. Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались постоянно переписывать. У сишников библ - на все оказии. И таки к счастью не в стандартной блин либе. Ну вот накулкуа мне там какой-нибудь куть? > Не уверен, что я понял вашу мову. Видимо, речь об использовании > питона для низкоуровневого программирования. В принципе, можно, > только зачем? Это ответ на реверанс что на питоне дескать можно все, бла-бла. И таки некоторые вещи на именно питоне без костылей на других ЯП - да удачи. > дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый > с питоновской стандартной библиотекой. И в результате получаем помесь явы с кутями, только еще хуже, когда после выпуска очередной версии наступает вешалка. Я вот как раз очень рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю. И не имею стало быть проблем с ними и их развалом. Более того - чрезмерно ломкие либы постепенно отсеиваются. А если прямо стандартная либа изгадилась - как это отсеивать?! :D > Так и скрипт на питоне можно запустить нужной версией интерпретатора. Ну так в результате требуется устраивать террариум, да к тому же в репах дистра этого нет, что гарантирует кучу дурной камасутры на ровном месте. А таки удобно когда компилер можно прям из реп 1-2 командами, и потом все просто работает...
	Ответить \| Правка \| К родителю #380 \| Наверх \| Cообщить модератору


	398. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (398), 25-Янв-20, 15:04
	> А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование чем "конкретная версия стандарта". > много бла ни о чем > Булшит бинго. Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все. > Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке - тем который в репах лежит. То, что "это может быть любой компилер, если этот компилер - не слишком свежий gcc" - вы опять забыли упомянуть из скромности, из-за специфично-выборочного восприятия, незнания или банального склероза? https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/erla... А вот тут вот штатный компилер вообще-то шланг: https://www.freshports.org/lang/gcc9/ gcc9 This port is required by: for Build archivers/R-cran-zip astro/R-cran-maptools astro/nightfall astro/wcslib audio/calf-lv2 audio/gsequencer audio/lsp-plugins-lv2 Expand this list (620 items / 613 hidden) Причем, список сильно сократился за последние пару лет, по мере наращивания шлангом компатибельности с gcc.
	Ответить \| Правка \| К родителю #395 \| Наверх \| Cообщить модератору


	399. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (398), 25-Янв-20, 15:29
	Совсем забыл: > Никто из моих знакомых убер-гуру, вплоть до крутых игроделов и > мощных алгоритмистов, не держит у себя зоопарк сишных компилеров. Одна версия на все. Помимо того, что сам аргумент перевода стрелок на "знакомых", без конкретных отсылок, разве что детсад^W лулзовый - мне просто интересно, как выглядел вопрос о кол. или версиях используемых компилеров? "Слышь, ты сколько компилеров используешь? Как все правильные пацаны, одну версию?" В общем, хотите использовать аргумент "авторитета" - давайте проверяемый отссылки на пару более-менее серьезных кодеров. А то и тут, если чуть копнуть, как-то не очень в вашу пользу выглядит: https://lkml.org/lkml/2013/2/5/873 > All gcc versions tested (4.[4567]) emit calls to __bswap[sd]i2 when > optimizing for size, so we add the !CC_OPTIMIZE_FOR_SIZE check. https://lkml.org/lkml/2018/3/21/775 > I tried putting the below ugly test code through various gcc versions. https://lkml.org/lkml/2019/8/7/55 > > I see the same warnings building linux-5.2.0 with gcc9. However, I don't see the warnings building linux-5.2.0 with the > the 20190705 of gcc8.
	Ответить \| Правка \| К родителю #395 \| Наверх \| Cообщить модератору


	404. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от myhand (ok), 26-Янв-20, 11:11
	>> Да, детка. Вы начинаете понимать принцип... > Ну так в результате я могу юзать вон тот древний код с > вот этим свежим компилером. Не патча полпланеты лично. Так и на питоне это можно. > Более того - > можно даже сделать программу из разных по версии сей, это ни > к чему такому не ведет. И это по-идее, тоже можно. Хотя к чести питона, до сих пор подобных гениев разработки мне встречать не довелось. >> Ну типа того: " Как максимум компилер из-за улучшения статического анализа может >> варнингов накинуть. А дальше уже по ситуации, если хочется, можно и исправить." > В каком месте здесь было обещание заапгрейдить соответствие кода стандартам? :) Послушайте, в "я имел в виду не то, я то введу" - играть с вами я не намерян. > А если кто хотел фичу нового стандарта - ну вот > тут придется проапгрейдить код уже. Угу, иначе register все подорвет... Т.е. с совместимостью обстоит плюс-минус лапоть также как в питоне: мы объявляем что-то устаревшим, чтобы в следующих стандартах удалить, мы вводим новый синтаксис, который ломает нам старый код (кстати, примеров подобного как-то сходу не могу придумать в питон, в отличие от)... >> Пока вам достаточно стандартной библиотеки... > И иногда у меня даже и стандартной библиотеки нет. А где я > на МК с простой как тапок фирмварой файловую систему возьму? :) > А так расписываться за действия вообще всех програмеров и их либ > - занятие провальное. Это вы все порываетесь расписываться, а я лишь констатировал факт. В стандартной библиотеке даже нет большей части типовых структур данных. STL. Одна из причин того, почему такая мерзкая гадость как C++ не сдохла в колыбели... >> Ну так и конкретная версия интерпретатора пайтона - будет работать с >> вашими скриптами как угодно долго. > А вот "конкретная версия интерпретатора" (или компилера) - намного менее удобное требование > чем "конкретная версия стандарта". Почему? Это одно и то же. Или вам неприменно надо одобрямс чинуш из ISO? Ну так тогда последний стандарт схемы - что-то типа r3rs... >> Во-первых, причем тут gcc? Аналогия, скорее, между стандартом языка и >> версией интерпретатора. > Ну и вот с этим как бы грабли. Мне достаточно поставить 1 > "системный" компилер из репов - и он прожует что у меня есть. Ну так проблема в том, что это _вам_ достаточно. А вот в дистрибутивах почему-то держат несколько. И львиная доля проблем - это именно "мы заменили gcc на gcc, ПАМАЖИТЕ ПАЖАЛУСТА!" Другой сценарий: какая-нибудь libxml2 поменяла версию. > А с питоном - фигвам, так не катит. Почему? У меня ровно один системный интерпретатор. > Более того - майнтайнеры в дистре, внезапно, билдят одним компилером. По задумке > - тем который в репах лежит. Это смотря в каком дистре. А то в Debian вот почему-то gcc-7 и gcc-8... Шланг тоже рядом лежит. >> Так куда не запихни - получатся те же яйца. > А вот не те же. Если в стандартную либу пхать, отвалится у > большего числа народа. Если вы не пользуетесь - что у вас может отвалиться? > А опциональная либа - там во первых програмеры > дважды подумают до того как апи менять, под угрозой что их > либу все перестанут юзать, а во вторых - половина обнаружит что > им и без этой либы можно обойтись. Вообще-то куда шустрее всякие libxml2 сишные апи меняют чем что-то обратно-несовместимое в стандартной библиотеке питона сотворят... >> Его таскают, в основном, из любви к закрытому коду корпорастов. > Расскажем DJB что его tweetnacl - "закрытый код корпорастов"?! Можете сразу рассказать как из-за одной из его 100500-й утилитки в компайлерах держат кучу стандартов. >> принцип остается прежний: "разработка" заключается в том, что слепили - и забыли. > Я бы вот предпочел не совать свои лапки в tweetnacl без серьезной > необходимости. Это довольно чревато в крипто и я не ощущаю себя DJB - он такой один. Да не один он такой. Поматросил и бросил - типичная картина при интырпрайз-разработке. А у автора кумыла просто с детства чвс чешется, вот он и плодит новые мертворожденные проекты. Код для статьи. Не вспоминайте про DJB при тех, кто с его поделиями сталкивался в промышленном применении. Могут и ногами побить. >> В мире FOSS - совершенно другая картина. > Как-то не видел программистов которые с энтузиазмом бы рвались переписывать код не > для того чтобы улучшить а потому что на их бошку новая версия свалилась. Ну а чего еще вы не видели? Тех кто пишет тесты? >> На самом деле, вы не сможете найти мало-мальски серьезный открытый проект, >> использующий какой-нибудь античный C89. > А как насчет кода рида-соломона от Phil Karn? Он легенда в тематической > области - вернул к жизни полудохлый КА, своими мега-знаниями в подобной > вот алгоритмике. И он был достаточно щедр для того чтобы оформить > частицу знания в либу рида-соломона. Которую разрбрали на цитаты. И которая таки C89. Проект настолько серьезен, что даже викимусорка его не упоминает, пишущи про подобную "алгоритмику". Нет, проектов на манер DJB (запилю вам POC, "открою" под "хочите менять - форкайте на всю катушку") - найти, наверно, можно. Хотя как раз сишные проекты все меньше в этом плане заметны: тут именно Python удобнее. Я не про "открыл и забыл", а про проекты, у которых есть багтрекер, хотя бы несколько разработчиков, сформировавшееся сообщество пользователей вокруг. >> Подавляющая часть адаптирована до такой степени, что код как минимум >> собирается на наиболее современном стандарте. > Да зачем? Они и как C89 прекрасно юзабельны. В том числе и > проектами чей собственный код соответствует последним стандартам. Да все за тем же. Чтобы проект не подох в итоге. Никому не интересно обучать вновь приходящих разработчиков ANSI C, например. >> Ну кое-кто - обещал, см. выше. > Цитату обещаний плз? Я цитировал. См. выше, вы там в шкаф залезли "я это не введу, я введу другое"... >> в разработке к-л свободного дистрибутива, а может даже в более серьезных вещах... >> ПТУ^WУниверситет там закончите или что там у вас. > Дык участвую. Но естественно не в пихоносрани с вебмакаками. Веб-проекты, мягко говоря, далеко не самая типичная область применения питона. >> Ну об чем тут можно спорить? Что можно запилить поддержку json на C? >> Очереди с приоритетом? [...] > ...поэтому сишники просто цепанут библиотеку - и дело в шляпе. А потом просто цепанут ее немножко по-другому. Потому что тут АПИ менять можно хоть каждый год - не стандарт. Же! > Это ж не питон, где код в массе своей вымер, т.к. афтыри заколебались > постоянно переписывать. Давайте вы хоть что-то попробуете доказать. Благо, это не C, где код лежит где попало и как попало. Все более-менее запаковано одинаково и есть pypi, который уже не-веб-макака должна суметь за час распросить про статистику. Дерзайте. Может даже вам для дипломной работы сгодится... >> дело со всей кучей либ, которые обеспечивают для C функционал, сопоставимый >> с питоновской стандартной библиотекой. > И в результате получаем помесь явы с кутями, только еще хуже, когда > после выпуска очередной версии наступает вешалка. Я вот как раз очень > рад что те либы опциональные. Хочу - юзаю их, не хочу - не юзаю. Если вы их не юзаете - то каким образом ожидаете от них "вешалку"? > А если прямо стандартная либа изгадилась - как это отсеивать?! :D А что мешает сделать нестандартную либу? Следовательно, вы доказали только то, что стандартная либа "не изгадилась", с совместимостью там все хорошо. >> Так и скрипт на питоне можно запустить нужной версией интерпретатора. > Ну так в результате требуется устраивать террариум, да к тому же в > репах дистра этого нет Почему это террариум, а куча стандартов в компиляторе - не террариум? И почему это в репах дистра "нет"? Как правило, все есть - для самого актуального случая (py2 vs py3).
	Ответить \| Правка \| К родителю #395 \| Наверх \| Cообщить модератору


	383. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Anonymoustus (ok), 23-Янв-20, 18:54
	>[оверквотинг удален] > в режиме C89 - потому что C99 отличается не только, блин, > названием. И там даже типы лучше использовать другие - менее долбанутые > чем в изначальном си. Потому что int something - это достаточно > абстрактно, int бывают разными по возможностям, в зависимости от чудачеств платформы > и компилера. В C99 это исправили, сделав куда более разумные типы > - потому что писать на именно C89 без расширений код... какая-нибудь > мелкая букашка типа pic может иметь свое мнение о том что > такое int. Ну или у некоторых DSP например char 16-битный. Формально > это валидно, фигли. А реально - поэтому и придумали C99 с > явно озвученным числом битов на тип, так куда пресказуемее. Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то вы точно знаете его характеристики, следовательно — эта особенность С89 не является для вас проблемой. А если пишете её для нескольких разных архитектур, то, скорее всего, вы тоже точно знаете их свойства и умеете делать так, чтобы различия не стали проблемой. Си, как ни крути, ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	394. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (-), 24-Янв-20, 22:12
	> Ну, вообще говоря, если вы пишете программу под конкретное известное железо, то > вы точно знаете его характеристики, Я вам тут не ассемблерщик (я прогал на нескольких асмах, но - надоело), и таки использую много довольно разного железа. И со своей стороны считаю портабельность сей весьма и весьма жирным плюсом. По поводу чего предпочитаю скорее C99. Порой несколько уменьшенный subset - для МК. > следовательно — эта особенность С89 не является для вас проблемой. Мне виднее и мои приоритеты и что является для меня проблемой. Поэтому для себя я решил оперировать C99 (без VLA, кроме случая когда есть очень крутая причина и это не мешает иным вещам). Ну и posix как апи если это еще к оси интерфейсить надо. И писать максимально портабельно при условии что это ничего не нагибает. А хотя-бы потому что например удобно на стороне компа какой-нибудь алгоритм или кус логики прозвонить, в том числе под мощными тулсами типа asan/ubsan до того как его на мк допустим пускать. На микроконтроле ... пакость типа avr вообще будет как яваскрипт, всепофиг, продолжаем работать, хоть там чо. Cortex, конечно, hardfault пульнет но понять от чего он вылез в урезанном окружении - канительнее и неудобнее. Справедливости ради, мне приходится вручную левый доступ к памяти делать чтобы вообще проверить что handler срабатывает, но все-же. > делать так, чтобы различия не стали проблемой. Си, как ни крути, > ЯП не для дураков, а для профессионалов, чётко понимающих, что и как они делают. Ну и с этой точки зрения - если я знаю что вон те данные будут 32 бита, мне логично и заказать им uint32_t, а не какой-то абстрактный int с риском поиметь грабли если на какой-то платформе int окажется вдруг не столько. Если так заметить, именно профессионалы тоже эти типы не лю и часто делают typedef с более вменяемыми типами и кучей кослылепроверок ifdef/sizeof. Мне так поганить код впадлу и я просто юзаю C99.
	Ответить \| Правка \| К родителю #383 \| Наверх \| Cообщить модератору


	312. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (-), 18-Янв-20, 01:59
	> Хочешь расскажу где лежат исходники CPython 2.2, например? Вот прикинь, если > тебе кровьизносу надо конкретную версию интерпретатора - я тебе разрешаю взять > и использовать ее. Зачем мне это? После пары жирных обломов жизнь научила меня что закладываться на продукты жизнедеятельности вбемакак - чревато. > Так можно! Без разрешения Папы Римского! Не упустите свой шанс! Блин, а ты можешь собачье г@вно с тротуара убрать. Впрочем за гвидо убирать хуже, во всяком случае ему даже лавры BDFL-я уже не по кайфу, сбежал даже так.
	Ответить \| Правка \| К родителю #186 \| Наверх \| Cообщить модератору


	319. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от myhand (ok), 18-Янв-20, 10:48
	> Зачем мне это? А мне почем знать зачем ты плакался по поддержке старых версий интерпретатора?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	352. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+/–
	Сообщение от Аноним (-), 18-Янв-20, 20:17
	Ну наверное не для того чтобы за гвидо его факапы разгребать. Хотя если liquidation manager'ом позовут - я подумаю над этим...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	–5 +/–
	Сообщение от Vkni (ok), 15-Янв-20, 02:16
	> И таки да: проще переписать на другом языке, чем пытаться поддерживать что-либо на питоне. А не надо писать на Питоне вещи, которые стоит поддерживать. Это отличный инструмент для своей области, а вылезать из неё не стоит.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	96. "Ценой перевода Mercurial на Python 3 может стать шлейф непре..."	+2 +/–
	Сообщение от Аноним (-), 15-Янв-20, 07:06
	Кому мало можно посмотреть на историю "успеха" редхата, которые за наверное 20 лет так и не смогли сделать вменяемый пакетный менеджер, вместо этого тщетно пытаясь окультурить свой картонный макет. В результате этот картонный макет жрет море ресурсов, глючит, падает, унося за собой БД и потом система остается как после ядерного взрыва. Под бойкие рассуждения о транзакциях и прочей расовой верноте. Какие, к дьяволу, транзакции, когда пакетный менеджер встает в позу когда он ни бе, ни ме, ни кукареку?!
	Ответить \| Правка \| Наверх \| Cообщить модератору