The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

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

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


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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру