Сайт stolyarov.info переехал на новый сервер (см. stolyarov.info). Версия, которую вы видите, оставлена работать на неопределённое (но вряд ли продолжительное) время на случай выявления ошибок при переносе контента.
Если вы видите ЭТО по адресу stolyarov.info или www.stolyarov.info — это значит, что ваш DNS-сервер всё ещё отдаёт старую информацию по этим адресам.
Математика, трудоустройство
Доброго времени суток, Андрей Викторович!
С Вашим творчеством познакомился около полугода назад и был очень впечатлен — отдельное спасибо Вам за труды, и отдельное за мировозренческую позицию. В какой-то момент я стал разочаровываться не столько в людях, сколько в себе — в наши лихие времена, когда людей интересуют только деньги как самоцель, ни больше ни меньше, начинаешь сомневаться, а может это я не в том направлении думаю? А, нет. Я просто вижу не все. В общем, спасибо!
Некоторые вопросы, которые возникали и возникают во время обучения, отпадают сами собой. Ответы на некоторые можно найти покопавшись в архивах гостевой книги. Но некоторые вопросы остались для меня неразрешенными и я бы хотел задать их здесь.
Математика:
Уже неоднократно Вам задавали вопросы на эту тему. Постараюсь быть конкретным: я столкнулся с таким явлением (и сопутствующим ему сайтом) как МГУ teach-in, где есть записи лекций, а также текстовые материалы (конспекты, презентации, пособия) с разных факультетов, в том числе с родного для Вас факультета ВМК. Записи лекций это не очень удобно, а тексовые материалы, к сожалению, соответствуют не всем видео-материалам. Тем не менее, очень радует что есть структура повествования. Вопрос к Вам, как к человеку, мягко говоря, вовлеченному :-) в жизнь ВМК — как на этом факультете обстоят дела с математикой? Стоит ли ознакамливаться с материалами доступными на озвученном сайте? Может стоит обратить внимание на лекции с других факультетов, например, мехмата?
И на ту же тему вопрос касательно книги Дональда Кнута «Конкретная математика» — если Вы знакомы с данным трудом, как Вам кажется, подойдет ли она для самостоятельного изучения математики, с учетом того что в школе у меня с этим делом, кажется, все обстояло довольно неплохо (впрочем, какая разница что было в школе?) но вот университет я закончил по специальности философия? :-)
Трудоустройство:
Ну и пара чисто практических вопросов. Когда, по Вашему мнению, можно начинать объединять приятное с полезным и начинать искать работу без рисков получить травму мозга, несовместимую с дальнейшим развитием в сфере программирования? Несколько туманный вопрос, переформулирую: достаточно ли освоения первых двух томов для первичного трудоустройства с паралельным продолжением изучения материалов третьего тома? Или лучше было бы освоить все три тома до устройства на первую работу? В качестве профессионального инструмента я рассматриваю язык Си — да насколько я понимаю, писать-то больше и не на чем, во всяком случае из того что востребованно на рынке. Вопрос имеет определенную остроту, поскольку университет я уже закончил и вроде как пора бы и честь знать. И какие направления в работе лучше рассматривать для развития себя как программиста? (Параллельно с написанием вопроса заглянул на ресурсы по поиску работы. Стало немного грустно.)
Как-то многовато букаф вышло — заранее благодарю за уделенное время!
Жуть :)
Ну поехали по порядку.
Видеолекции — туфта вне всякой зависимости от того, на каком факультете их записали. Намного правильнее и эффективнее читать книги. Вот, к сожалению, с выбором книг по математике я вам вряд ли помогу, не совсем моя область.
Про Кнута и компанию с их "Конкретной математикой" могу сказать только одно: мне (на минуточку, кандидату физ.-мат. наук) эту книгу было читать тяжело, как и все книги Кнута. Возможно, это субъективно.
Что касается трудоустройства, программистом на чистом Си можно устроиться разве что во всякий embedded, и этот рынок довольно компактный. Кроме того, пожалуй, человек без опыта работы и с дипломом философа может у потенциальных работодателей вызвать достаточно предвзятое отношение.
Вообще если уж хотите моего совета, то рискну вам таковой выдать. Коль скоро вы освоили первые два тома моего учебника (речь ведь идёт об освоении, а не о "прочтении"?), то уж с чем у вас категорически не может быть проблем — это с командной строкой Юникса (включая Linux). Попробуйте для начала куда-нибудь устроиться сисадмином, только ни в коем случае не виндовозным, а именно на всякие юниксы; на такие места работодателю с удовольствием людей берут и без дипломов (это вообще работа, не требующая в/о, если уж честно), и без опыта, в ряде случаев вполне достаточно продемонстрировать, что вы командной строки не боитесь и обращаться с ней умеете; лучше, конечно, уметь ещё и простейшие сетки настраивать, но это вроде не так трудно. За время работы сисадмином можно попробовать что-нибудь сваять opensource'ное на том же Си, и опыт наберёте, и портфолио (в резюме ссылка на опубликованную оpensource'ную программу весьма способствует). Если даже и нет, всё равно полтора-два года опыта работы сисадмином поднимет вашу привлекательность в качестве кандидата в программисты. Да и третий том за это время осилите :-)
Здравствуйте. А
Здравствуйте. А что порекомендуете почитать, чтобы научиться простейшие сктки настраивать? И как вы относитесь к книге "Unix и Linux руководство системного администратора" Немет, Снайдер, Хейн, Уэйли, Макин?
Когда я всему
Когда я всему этому учился, книг на эту тему практически не было. Сейчас они для меня неактуальны, порекомендовать ничего не могу. К конкретной книге никак не отношусь, как можно "относиться" к книге, которой в глаза не видел?
Игрушки
Спасибо! :-)
С огромным аппетитом смотрю на второй том, но пока рано — забавляюсь с написанием игрушек на Паскале. Ну и раз уж речь зашла рискну спросить вот еще что: еще до освоения указателей захотелось написать клон старого доброго Pong-а. Написал. Запустил. И тут же на почту стали поступать сообщения на хинди — я не эксперт, но кажется речь шла о предложении устроиться в какую-то индийскую IT компанию… «Тревожный звоночек» — подумал я и решил отложить работу с этой игрушкой дабы в голове всё немного улеглось. Ну, а если кроме шуток, то написал действительно плохо и вот на днях все переписал с нуля. Выглядеть и ощущаться стало лучше, но есть одно но, о котором позже.
По мере усвоения указателей хочется написать что-то еще более веселое и динамичное, например, клон Space Invaders. Еще всерьёз не думал о том как это дело будет выглядеть изнутри, но одну проблему я уже чувствую: движение управляемого игроком объекта когда клавиша нажата и остановка, когда клавиша отпущена. Это как раз то «но» с которым я столкнулся в Понге, но там, в принципе, некое коспромисное решение удалось найти — нажимает игрок клавишу «j» и платформа предсказуемо плавно движется вниз экрана, пока не упрется в границу; нажимает «k» и тоже самое происходит в обратную сторону. Главное вовремя задавать направление движения, дабы платфома успела соприкоснуться с мячиком и «отбить» его. Пытался написать как-то иначе, но решения получались не вполне красивыми и совершенно неэффективными — если получалось сделать так, чтобы платформа останавливалась в момент отпускания клавиши, то уже начало движения происходило с ощутимой задержкой (что еще хуже). В итоге оставил как есть, с плавными предсказуемыми движениями до пределов окна терминала. Есть, правда, возможность остановить платформу игрока нажав на какую-то другую клавишу, кроме клавиш отвечающих за движение — но это скорее недокументированная возможность, чем полноценная механика. Останавиливать платформу отдельной клавишей в динамичной игре это как минимум неудобно. Но то, что в Понге ощущается пусть немного непривычно, но, по крайней мере, можно сказать что это «не баг а фича», в Захватчиках будет вызывать только негативные эмоции — вместо того чтобы переместиться на нужное количество знакомест и выстрелить в космического супостата, фигурка игрока будет беспомощно мотаться из угла в угол, пока не попадет под вражеский огонь.
Есть мысль написать еще одну игрушку, но там тоже, по задумке, должна присутствовать такая механика. Короче, куда ни кинь — везде клин.
Вопрос: в каком направлении можно подумать, чтобы адекватно реализовать остановку по отпусканию клавиши в динамичных играх? Или пока стоит написать чего «попроще», а вернее того, где такая проблема не стоит вовсе, как, например, в Змейке, где остановок вообще не предусмотрено?
Во вы меня
Во вы меня озадачили :-)
Конечно, юниксовый терминал как объект (хоть тысячу раз абстрактный и виртуальный) работать на уровне клавиатурных событий (вида "такая-то клавиша нажата", "такая-то клавиша отпущена") не умеет, у него вообще нет клавиатуры как таковой, вместо неё линия связи (воображаемая, но от этого не легче), из которой высыпаются готовые символы, а не события клавиатуры. Работа на уровне событий клавиатуры в юниксе возможна (X-сервер же как-то это делает), но я с ходу не знаю, как, а лезть искать мне прямо сейчас некогда, тем более что вам это всё равно не поможет — во Free Pascal'е доступа к такой низухе точно нет.
Но обхитрить систему всё равно можно. Только придётся привязаться к системным часам. Общая идея такая: если у вас есть какой-то подвижный объект, и он должен при нажатой соответствующей клавише двигаться со скоростью N движений в секунду, то надо:
Отдельный вопрос, как привязаться ко времени. Я не знаю, что курили те из создателей Free Pascal, которые придумали соответствующие процедуры из модуля sysutils, в команде FP, судя по всему, вообще злоупотребляют какими-то веществами. Но, в общем, сухой остаток такой — если подключить sysutils (добавить его в директиву uses) и написать вот такую функцию:
то она будет возвращать количество миллисекунд, прошедшее с начала нашей эры (вот прямо с 1 января 0001 года). Загадочный тип comp — это вроде бы синоним Int64. Ну в общем эти comp'ы, по крайней мере, можно вычитать :-) что нам и требуется.
Дальше возникнет проблема с тем, что, когда пользователь нажимает клавишу, терминал сначала получает одно её нажатие, потом делается пауза, и только после паузы клавиатурный драйвер начинает "автоповторять" нажатую клавишу. Но мы же уже умеем привязываться ко времени :-) Следовательно, прекращать движение можно не тогда, когда KeyPressed говорит, что ничего не нажато, а тогда, когда ничего не было нажато, например, в течение последних 200 миллисекунд (1/5 секунды). Если задержка между отпусканием клавиши и остановкой объекта будет 1/5 секунды, пользователь её не заметит.
В общем, добиться того эффекта, который вам нужен, возможно, направление я вам показал, а дальше вы уже сами :-)
Системное время
можно так:
Огромное спасибо! :-)
Огромное спасибо! :-)
Направление мысли уловил, буду разбираться!
Здравствуйте!
Здравствуйте! Может ли человек быть хорошим программистом без знаний из третьего тома?
Думаю, что нет.
Думаю, что нет. На одном императивно-процедурном программировании далеко не уедешь.
Здравствуйте.
Здравствуйте. Хотелось бы для себя выяснить, может проблема во мне и я не могу стать программистом. Не могу себе представить общий вид программы, чуть больший, чем тривиальная/простого уровня. Поясню на условной карточной игре. Изначально я займусь декомпозицией, то есть выясню какие функции(у кого больше очков) и сущности(карта)нужны для программы. Пишу код, если надо дебажу - работает.
Естественно карточные игры это не потолок моих желаний, хочется написать реальную программу. Например, оконник или bar (lemonbar/polybar etc). Я примерно понимаю X11, но задачу декомпозировать не могу, просто не за что ухватиться. То есть нет понимания как реализовать (что реализовывать?) каркас программы, который можно было бы обвешивать "фичами". Пытаясь понять код уже готовых программ(dwm), после некоторого времени теряется логическая цепочка что за что отвечает и т.д. Если это не проблема во мне, то как выработать этот навык, чтобы при задаче "любой" сложности было понимание что делать? У вас читал первые два тома, спасибо.
Вы бы ещё за
Вы бы ещё за операционную систему сразу схватились.
В принципе оконник — не так чтобы совсем суперсложная программа, но уж точно это не для того периода, когда человек ещё сам для себя не понял, может ли он быть программистом (кстати, в вашем случае скорее всего всё в порядке, вы просто слишком спешите).
В частности, термин "декомпозиция" вы поняли, мягко говоря, не совсем верно. Сразу спроектировать всю программу в декомпозированном виде — это принципиально превышает возможности человека, то есть это просто невозможно. Основная декомпозиция происходит на стадии кодирования, а не первоначального обдумывания. Но чтобы это понять, нужен опыт, а с этим у вас напряжёнка. Причём пугаться этой "напряжёнки" не надо, опыт (в отличие от мозгов, которые у вас похоже что всё-таки есть, а вот у кого другого их может и не быть) — дело наживное.
Ну а рекомендация тут будет очень простая: вернитесь к первому тому, к части про Паскаль, и для начала на Паскале (!) напишите что-то такое, чем станет пользоваться (причём добровольно) кто-то кроме вас. В процессе как раз наберёте опыт простейшего кодинга.
Что до оконника — первое, что приходит в голову, это сделать какой-нибудь бесполезный, но работающий оконник, например, чтобы он вообще вокруг окошек ничего не рисовал, любое окошко появлялось изначально в середине экрана (полностью игнорируя другие окна), и чтобы это появившееся окошко можно было двигать, например, клавишами F9--F12. Потом постепенно обращивать полученный скелет новым мясом, несколько раз наверняка придётся переписать с нуля (когда код начнёт от рук отбиваться), но это нормально. Только не делайте этого прямо сейчас!. Что делать сейчас — см. выше.
П-Р-О-С-Т-Р-А-Ц-И-Я
Здравствуйте! Добежал до параграфа 2.10 и темы "односвязный список". Возникли проблемы в том, что очень трудно начало изучаться тема, стал какой-то нервный, и ощущение будто в голову уже эти знания с указателями не лезут. Сталкиваюсь с этим впервые, поэтому попрошу помощи...
А порисовать?
Попробуйте порисовать картинки. которые есть в книге. Шаг за шагом. Некоторым (и мне тоже) проще понять (например какой-нибудь) алгоритм просто рисуя его на бумаге, шаг за шагом его выполнение.
Можете поискать в интернете визуализации односвязного списка, таких полно, может вам такой способ поможет понять.
Ну а вообще - не стоит на одном параграфе "висеть" долго. Не получилось - идите дальше, потом вернитесь (только обязательно вернитесь, так как в будущем (в "Си") без них никак).
> Ну а вообще -
> Ну а вообще - не стоит на одном параграфе "висеть" долго. Не получилось - идите дальше
Я бы такое не советовал. По-мне, все-таки правильнее будет стараться добиваться понимания каждой главы, и только после этого идти дальше. А главу про указатели, по-моему, ни в коем случае нельзя оставлять на "потом".
Как раз
Как раз таки-нет. Если указатели долго не "идут", нужно попробовать пописать программы без них. Поставить ограничения, вместо очереди использовать кольцевой буфер, и т.д., да много впринципе задач в которые хорошо вписываются ограничения. Можно попробовать писать на ассемблере, поиграв с косвенной адресацией через регистры. Так можно и полноценно "пощупать" указатели, понять почему мелкие структуры данных лучше копировать, чем брать от них адреса (передавать через var-параметры). Случай когда нельзя оставлять это на потом это - изучение Си, это да, тот самый случай.
Помощь
Да имхо подход как и везде - перечитывать несколько раз, пока не уляжется, картинки рисовать, чтоб разобраться. Не получается - пойти погулять, а потом еще раз. И так до победного.
Если вы станете программистом, то такие штуки будут сопровождать вас всю жизнь (сейчас указатели, потом надо будет освоить какую-нибудь новую парадигму, потом какую-нибудь особо заковыристую библиотеку, по которой документацию три калеки писали), так что привыкайте.
С одной
С одной стороны, а чего вы хотели, это один из самых высоких барьеров на входе в программирование. Не вы первый, не вы последний.
С другой — мне даже интересно, как вы себе представляете "помощь", которую тут решили попросить. Особенно с учётом того, что вы никаких конкретных вопросов не задаёте, просто констатируете факт, что вам стало тяжело. Ну так никто же и не обещал, что будет легко, не?
Список
А мне вот, честно сказать, саму идею понять было несложно. А вот именно тот код который вы привели — его да, несколько раз перечитывал и думал. Но в общем мне оказалось проще самому написать код по своему пониманию, и вот только после этого стал понятен ваш.
Как думаете, это нормально?
А вот от идеи написать не рекурсивный обход дерева я вообще отказался — слишком сложно.
Вообще-то в
Вообще-то в книге как раз и предлагается сначала попытаться самостоятельно написать пару задач на списки, и только потом смотреть решение. Так что это не просто нормально — это то, как всё и должно быть. Технику работы со списками надо изобрести самостоятельно, тогда она уже никуда не денется.
Про дерево не напрягайтесь, это реально сложная штука. Пусть полгодика пройдёт, шок уляжется, мозг к указателям привыкнет -- окажется всё просто :-)
Деревья
> Про дерево не напрягайтесь, это реально сложная штука. Пусть полгодика пройдёт, шок уляжется, мозг к указателям привыкнет -- окажется всё просто :-)
Да не, если с рекурсией — это не особо сложно. Я бинарные деревья даже в игре robozzle проходил. Мне сложно именно не рекурсивно, точнее вообще не понятно как в принципе что-то такое сделать. Я так думаю, что там придётся всё равно использовать рекурсию, просто замаскированную, например взять односвязный список и использовать его для хранения текущей позиции в дереве, то есть фактически реализовать ту же рекурсию, используя свой стек-костыль вместо аппаратного стека вызовов.
Или всё-таки можно обойтись только статическими структурами данных, не считая само дерево?
реализовать ту
реализовать ту же рекурсию, используя свой стек-костыль вместо аппаратного стека вызовов.
Аппаратный стек вызовов есть не во всех современных ЭВМ.
Мммм... есть
Мммм... есть кое-какие догадки на сей счёт, но в целом очень интересно, какие конкретно архитектуры вы тут имеете в виду.
Про стек вы
Про стек вы совершенно правы, там нужен будет стек, сформированный вручную, и хранящий ровно ту информацию, которую при рекурсивном решении хранят стековые фреймы рекурсивной подпрограммы. Ну, если, конечно, у вас в дереве не предусмотрена "обратная связность" -- в каждом узле указатель на родительский узел; но такого обычно всё-таки не делают.
Но использование стека не делает решение рекурсивным, рекурсия -- это такая схема вызовов подпрограмм, а не подход к структурам данных.
Здравствуйте,
Здравствуйте, стало интересно посмотреть вашу реализацию строк, которая Script Plus Plus, и вместе с исходным текстом библиотеки должен был быть еще файлик scrtest.cpp, но его не оказалось в архиве. Я что-то упускаю?
В данном случае
В данном случае скорее я что-то упускаю, точнее, упустил столько лет назад, сколько прошло с публикации версии 0.3.10. scrtest — это файл с юнит-тестами, то есть на функционирование библиотеки он никак не влияет, но, конечно, в архиве он вроде бы должен быть.
Прошу прощения, но прямо сейчас это исправлять не буду, постараюсь в ближайшее время выложить версию посвежее (только сам себя убедю, что она более-менее рабочая, и тут же выложу)
Здравствуйте,
Здравствуйте, решил попробовать написать более-менее нетривиальную программу. Понадобилась хэш-таблица для одной из подсистем. Реализовал хэш-таблицу вручную с использованием односвязных списков для разрешения коллизий. С этим особых проблем не возникло, работает как и требуется. Спустя какое-то время в другой подсистеме появилась аналогичная нужда в хэш-таблице. И вот возник вопрос- как поступить? Реализовать еще раз таблицу, но тогда будет много повторяющегося кода. STL я даже не рассматриваю как вариант. Писать свой шаблон для хэш-таблицы, тоже, вроде как, не хочется (а, вдруг, потом все-таки нужно будет модифицировать особым образом хэш-таблицу для одной из подсистем). В общем, не знаю как будет правильнее. Как вы обычно поступаете в такой ситуации?
Из
Из повторяющихся кусков кода там разве что вычисление хеш-функции будет. Вообще на мой взгляд универсальные (в смысле generic) структуры данных — это скорее городская легенда, чем что-то ещё, наверняка по итогам реализации окажется, что там отличий больше, чем общего, если, конечно, не копипастить оптом весь код.
Если бы таблица у вас была классическая, без списков в каждом слоте, то там хотя бы есть нетривиальные алгоритмы, например, удаление элемента там довольно хитро делается. Со списками и того не будет.
Раньше как-то
Раньше как-то видел в www.croro.net страницу "с красивыми картинками (картами)", это не про игру loosy_crocodile? Вы участвовали в одном контесте вроде-бы.. Как в неё поиграть? И ещё не могу найти ту страницу. Скиньте пожалуйсто :)
Брррррр, вы про
Брррррр, вы про это? http://www.intelib.org/icfp2002-contest.html Я не уверен, что в это можно "поиграть", Loosy Alligator — это название моей программы, поданной на конкурс и бесславно провалившейся из-за дебильного бага. Сама программа валяется на ftp до сих пор, с той страницы ссылка есть. Но чтобы в это играть, нужен ещё сервер от организаторов контеста, и что-то сдаётся мне, его уже не найти. Почти 20 лет прошло, как-никак.
Коди
Андрей, приветствую. В какой кодировке книги? Как ctrl+c - то прожать, чтоб оно в крокозябру не превратилось?
Сто раз уже
Сто раз уже сказано -- никак, ибо это не баг, а фича. Текстовый слой в этих PDFах сломан намеренно. Я уже даже в FAQ это вынес, сколько можно одно и то же спрашивать?!
Здравствуйте,
Здравствуйте, можете подсказать какие зниния необходимы, чтобы написать игру жизнь.
Это очень
Это очень сильно зависит от того, какие требования вы сами предъявляете к своей реализации. Если вас устраивает рассмотрение этого автомата на каком-то поле фиксированного размера, то вам хватит материала первого тома до главы про полноэкранные программы включительно. А вот если фиксированное поле не устраивает, то потребуются динамические массивы, Free Pascal их поддерживает, но я их намеренно не рассматриваю в книге, чтобы не лишать читателя стимула осваивать указатели и списки; да и вообще, чтобы понять, почему они такие "странные", нужно знать Си :-) (они оттуда импортированы, причём довольно кривенько). Ну и вообще, как, например, задавать исходную колонию? Будет ли ваша реализация позволять сохранять конфигурацию в файле и считывать из файла? Будет ли предусмотрен какой-то интерактивный редактор или пользователю придётся, скажем, самому в текстовои файле рисовать эту колонию звёздочками или ещё чем? Будет ли размер поля совпадать с размером экрана или вы позволите колонии разрастаться на большем поле, а для просмотра прикрутите всякий скроллинг? Всё это влияет на сложность реализации.
Но простейший вариант можно сделать сразу после изучения модуля crt :-)
Спасибо за
Спасибо за ответ, начну с малого.
Можно и
Можно и неинтерактивную программу сделать, как только научились читать исходное положение с input и пошагово выводить эволюцию колонии в output.
Можно, конечно,
Можно, конечно, только я сомневаюсь, что такой вариант принесёт своему автору достаточно творческого удовлетворения, чтобы быть написанным.
Допустимо
Допустимо использовать на одном компьютере, но на разных дисках, два Линукс дистрибутива, одну чтобы протестить?
Видимо имеются
Видимо имеются проблемы с поиском информации :-)
Я за минуту нашёл вот-такую pdf'ку. Осталось только попробовать.
Вообще не обязательно даже читать эту pdf'ку. Достаточно оставить свободное место на диске при установке первого дистрибутива, и второй (сколько угодно) ставить на это свободное место, к тому же можно на разных OS использовать один swap раздел, "даже" один /home и "даже" настроить общие разделы (у меня это /public). И одной update-grub точно хватить.
Я у cебя второй системой держу FreeBSD, загружаю её с GRUB. Там плясок побольше, но всё возможно.
Бггг. А что,
Бггг. А что, по-вашему, может этому помешать?
Intel ME
Доброго времени суток! Хотелось бы узнать ваше мнение насчёт системы Intel ME, так или иначе участвующей в работе компьютеров с чипами Intel. Это ведь целый ЦПУ (Intel quark) внутри системы со своей флеш-памятью и ОС Minix, имеющей доступ к системе на уровне выше всех "колец". Даже пакеты, поступающие через Ethernet, проходят "сквозь него". Как вам кажется, может ли Intel таким образом логировать действия пользователей, или ещё что похуже? И понимает ли это наше правительство, пуская на гос. предприятия системы, хоть и обзывающиеся "допущенные по СТ-1", но, по-факту, содержащие потенциально враждебные возможности?
Наше
Наше правительство вообще ничего не понимает. По поводу остального — честно говоря, надоело пережёвывать эту тему. Да, это, как говорят, алес капут. Ну хотя вообще-то не совсем, поскольку роутеры у нас обычно на ARMах, а на ARMах пока что вроде такого не замечено (хотя я мог отстать от жизни), так что, по крайней мере, вполне можно посниффить пакеты, которые предположительно исходят от IntelME (например, поместить за роутером несколько выключенных, но запитанных компов, и ни одного включённого, и посмотреть на трафик). Что обнадёживает — это что такого, естественно, только ленивый не делал, и что-то ничего на эту тему в инете не находится, т.е., возможно, IntelME в его нынешних версиях ничего никуда не посылает.
Вот тут есть неплохой обзор на тему "что можно сделать" (рекомендую выключить js, текст на странице доступен без него) https://security.stackexchange.com/questions/142947/what-can-i-do-about-...
Самый простой из советов — не пользоваться набортным эзером. Там, правда, советуют usb ether, а это не очень хорошая идея, поскольку в линуксе с драйверами для usb ether'ов полная задница. Можно ли использовать просто сетевую карту, вставленную в PCI-слот, и умеет ли ME ими пользоваться — я не понял.
Ну и такой момент, что пользователям маков, Windows и смартфонов, по-видимому, можно не беспокоиться насчёт IntelME, т.к. количество бекдоров и прочих анальных зондов в их операционных системах заведомо превышает на порядки то, что может прятаться в недрах IntelME.
роутеры у нас
роутеры у нас обычно на ARMахНа MIPSах тоже попадались.
Увы
> Что обнадёживает — это что такого, естественно, только ленивый не делал, и что-то ничего на эту тему в инете не находится, т.е., возможно, IntelME в его нынешних версиях ничего никуда не посылает.
Ни в коем случае. Если на стену вешают ружьё, значит оно выстрелит.
Одна из главных правил разведки - агент по умолчанию вообще не должен проявлять инициативу. Потому что он не обладает всей полнотой информации и может попасть под наблюдение. Именно этим агентурная разведка отличается от фронтовой, где больше ценится скорость, а не скрытность.
То же самое относится и к компьютерным шпионам. Если IntelME в момент проверки ничего никуда не шлёт, то 99% - это потому что ему просто не дана команда за вами следить, и лишь 1% - технические средства конспирации. Здесь есть и элементарная практичность: если бы все машины слали данные инициативно, их бы просто негде было хранить.
Сдаётся мне, вы
Сдаётся мне, вы тут кое-что упускаете. Когда машина находится за NAT'ом, ей нельзя "дать команду следить", если только она сама не слазит "куда надо" и не спросит, нет ли для неё каких указаний. Отсутствие трафика означает, что машина НЕ пытается ниоткуда получить никакие команды — а значит, она их и не получит. Хотя, конечно, "это не точно", поскольку, как тут кто-то уже написал, она вполне может свой (весьма незначительный) трафик маскировать, включаясь только тогда, когда пользователь активно что-то качает.
Со слов
Со слов человека, которого я попросил это протестить: "За 4 дня "наблюдений" прошел 1 пинг в 8.8.8.8. Стоит отметить, что подключены были 3 машины, на одной присутствует vPro, если это важно." Но! Если может пройти пакет, значит вполне себе реально реализовать (особенно с нынешними вычислительными мощностями quark-ов (после D2000 в 2015 intel давненько про них не заикались, но, подозреваю, что современным IMEI управляет уже далеко не 1 ядро в 32nm на 400Mhz) и фактом того, что ME - это unix) код, проверяющий, чего там у пользователя запущено и "под шумок браузера"(особенно, если приходит большой массив данных, например, человек
ест дерьмопользуется платформой YouTube, или чем-то подобным) отправлять хоть логи действий, хоть изображение с веб-камеры (маловероятно, конечно, но все же). Тем более, что Minix - полноценная система (сомневаюсь, что инженеры из Intel реализовали все необходимые функции в рамках микроядра, сильно много насиловать клавиатуру пришлось бы), а значит, скорее всего часть функций системы лежит на "приложениях" -> возможности для компрометации пользователя стремятся в бесконечность. Кстати, насколько известно из официальной документации, код платформы зашифрован (понятно, что обфусцирован) и "декодирование" происходит на аппаратном уровне. Но, если есть декодирование, значит есть и участок, где код представляет собой вполне обычные x86 команды -> его можно считать (в случае с обфускацией на уровне вставки кучи мусора - наблюдать за некоторыми аспектами выполнения и пустые конструкции отсеивать, думаю, алгоритм такой можно реализовать). Не очень верю, что кто-то такое когда-нибудь сделает, но сам факт наличия шанса весьма обнадеживает>Самый простой
>Самый простой из советов
Купить процессоры, которые выпускали до изобретения ME/PSP :)
Это, кстати,
Это, кстати, правильный совет. Только сначала надо всех вебщиков перестрелять к чёртовой бабушке, поскольку браузеры и "современный" веб на таких машинах не работают. Остальное работает нормально, у меня до сих пор eeepc901 в эксплуатации.
Я вас умоляю
Мой FX-4300, выпущенный в 12 году преспокойно выдерживает 2 браузера и приложение на Electron, еще и остается. Я уж молчу, что его разогнать можно.
А AMD PSP выпущен в 2013 году. Intel ME сильно раньше, но это проблемы пользователей Intel.
FX-4300,
FX-4300, выпущенный в 12 году
Да, в общем, и с Phenom II X4 840 особо не бедствую :) Но вот ноутбуку на Core 2 Duo T6600 грустновато, это да...
Вообще AMD до 2012
Вообще AMD до 2012 года выпуска включительно -- это может быть вполне себе решение.
Насчёт веба -
Насчёт веба - полностью согласен. IBM Thinkpad x31 (ноутбук - чуть старше меня, Pentium M + 512M RAM под капотом) - полет нормальный. Вполне хватает как для чтения книг, так и для любой другой повседневной работы. Браузеры, правда, кроме Links / NetSurf не работают, но в вебе я не настолько нуждаюсь, что бы испытывать от этого сколь бы то ни было серьезные неудобства. Только вот, видимо, рано или поздно придется завести карту в банке, а их сайты из-под NetSurf открываться отказываются.
ME cleaner
Есть утилиты которые позволяют просто из ME региона удалить всё кроме компонентов, без которых компьютер не загрузится вообще. Я думаю, такой кастрированный ME особо не навредит.
Интересно, есть ли подобное для AMD PSP?
Указатели
Здравствуйте, Андрей Викторович. Позавчера я начал изучение указателей на языке Паскаль и пока не могу сообразить, как решить две предложенные вами задачи на стр. 411 второго издания МАКСпрес. Что вы можете посоветовать, подумать ещё или отложить изучение указателей?
P.S. Смысл записи first^.next^.next я понял. Дальше этих двух задачь текст не читал, только на картинку два раза как говорится, по-диагонали, взглянул, хотя искушение начать читать объяснение задачь велико.
В книжке всё
В книжке всё написано — все мои рекомендации и прочие соображения по поводу этих двух задач. А решать в любом случае вам.
Ваших
Ваших читателей, оказывается, уже в "секту" записывают. Разговаривал с одним сотрудником НГТУ, так он мне пол часа доказывал, какую вы "секту свидетелей Столярова" создаете и как "мозги людям туманите, что бы люди с linux мучались".
>НГТУЭто
>НГТУ
Это Нижегородский или Новосибирский? В Нижегородском моя информатичка училась :)
Новосибирский
Новосибирский
Да какая
Да какая разница, думаете в МГУ таких нет?
Просто
Просто интересно, кто моих учителей учил
Гм, "секта
Гм, "секта свидетелей Столярова" — ну а что, звучит :-)
Вообще это ожидаемо, и не только это, смею вас заверить. Своими книжками, особенно текстом предисловий, я совершенно откровенно заявил, что примерно 97% преподавателей программирования, если не больше — халтурщики. Я вполне отдаю себе отчёт, какое количество врагов я себе при этом нажил, и их число будет только увеличиваться по мере роста популярности моих книг. Понимаете, в этой игре такие правила. "Они" вам будут доказывать что угодно и сколько угодно времени — просто потому, что признать себя халтурщиком никто никогда не захочет и не согласится.
Ну а ценность аргумента, что, мол, людям придётся с линуксом "мучиться", можете оценить вполне объективно: вот лично я что, так похож на мазохиста? Совершенно очевидно, что, когда припрёт, с мелкомягким дерьмищем я справляюсь (что после этого руки трясутся и хочется кого-нибудь убить — это второй вопрос). Ну то есть вот лично я могу работать и с Windows, и с Linux. Могу, разумеется, под Linux'ом работать и с Desktop Environments, и с командной строкой. Умею, не поверите! Точнее, вы-то поверите, да и любой другой человек, если подумает, вряд ли поверит, что я не умею тыкать мышкой в иконки. Не люблю — это факт, но понятно, что умею. И из всего этого сборища альтернатив, разумеется, выбираю именно что командную строку для всего, кроме разве что сортировки фоток (там предметная область такая — превьюшки удобны).
А вот виндузятники работать к командной строкой не умеют. И с этим тоже обычно никто не спорит, потому что просто никто в обратное не поверит. И если я, умея и то и другое, выбираю командную строку, и не просто выбираю, а только с ней фактически и работаю вот уже больше четверти века — значит, (surprize!) она просто удобна. А мучаются не те, кто с работают с линуксом, а те, кто до полной ус$$чки, пардон, боятся сделать шаг в сторону от мейнстрима, и продолжают гонять отвратительные в своей контр-эргономичности GUI. Вот они — да, мучаются. Большинство соверменных людей проводят за компьютером много часов в день, можно было бы и потратить чуть-чуть времени, чтобы научиться с компьютерами работать нормально, т.е. грамотно и эффективно, а не так, как тридцать с лишним лет назад приучили весь мир поганцы-маркетоиды.
Удобство относительно?
А может быть командная строка удобна именно вам потому что у вас в мозгу уже сформировались нужные нейронные связи.
Другими способами работать вы можете, но при этом нет того автоматизма, поэтому они воспринимаются как менее удобные.
Кстати кроме гуи и команд есть и другие варианты, например nc/mc/far. Некоторые как привыкли пользоваться нортоном, так до сих пор сидят за его клонами и искренне считают, что это удобнее как командного интерфейса, так и GUI, тогда как я вообще не очень понимаю зачем этот mc нужен и не пользуюсь.
> А может быть
> А может быть командная строка удобна именно вам потому что у вас в мозгу уже сформировались нужные нейронные связи.
> Другими способами работать вы можете, но при этом нет того автоматизма, поэтому они воспринимаются как менее удобные.
Я своему малому на лаптоп установил Линукс и Виндовс (для школы). У него еще точно никакие нейронные связи не успели выработаться к тому времени. На Линуксе у него - i3wm. Спустя некоторое время сравнений этих двух систем, он выбрал Линукс с i3wm, и если бы не школа, снес бы Виндовс давно.
Слушайте, ну
Слушайте, ну что за аргументы, ей-богу?! Вот это ваше "в мозгу уже сформировались нужные нейронные связи" можно сказать намного проще: да, блин, я умею пользоваться командной строкой. А они — не умеют. Я это сам сказал, заметим. Т.е. вы переформулировали моё собственное утверждение, использовав наукообразную лексику, и что, от этого поменялось что-то?
Вы что думаете, я на форточках никогда не сидел? Сидел-сидел. Правда, давно дело было, последней активно использовавшейся у меня дома версией оказалась в своё время Windows-95, следующую (Win98) поставить не успел, т.к. в самом начале 1998 года окончательно ушел из-под винды. Но до неё была Win-3.11, а ещё раньше — разумеется, MS-DOS с тем самым нортоном. Так что эти ваши "нейронные связи" у меня имели место под каждый из вариантов. И это мне никак не помешало.
В итоге приходим к тому же, с чего начали: эти люди не умеют грамотно работать к компьютером и предпочитают продолжать каждый день растрачивать впустую своё время и силы, лишь бы только не пришлось изучать ничего нового.
А сравнивать удобство инструмента, с которым работать не умеешь, с удобством того, к которому привык — это, пардон, полная ерунда. Разумеется, тот, к которому привык, будет казаться более удобным. Ключевое слово "казаться".
Использование компьютера
> Т.е. вы переформулировали моё собственное утверждение, использовав наукообразную лексику
Не совсем, если без наукообразной лексики, то вы умеете пользоваться всем, но вот конкретно к консоли привыкли больше. Поэтому она воспринимается как более удобная.
Кроме того, в винде вам постоянно придётся что-то вспоминать или искать, а опытный виндузятник мышкой реактивно ведёт к нужному пункту меню, потому что у него уже есть мышечная память.
> Вы что думаете, я на форточках никогда не сидел?
Так я тоже сидел, но когда это было? А сейчас мне форточками неудобно пользоваться, как потому, что они ломают мои привычки (например я там время от времени набираю ls и только потом стираю, и набираю уже dir), так и потому что некоторые возможности там просто отсутствуют. Ну и по выше перечисленным причинам тоже — я только примерно знаю что там и где искать.
Кстати насчёт командной строки, а вы знаете, что в Windows есть Power Shell, который представляет собой оболочку с набором команд и вроде бы довольно мощным? Вот вы им не владеете, а bash владеете, поэтому в bash вам проще работать. Я, кстати, тоже PoSh не владею, да и из знакомых виндузятников им почему-то никто не пользуется.
> Разумеется, тот, к которому привык, будет казаться более удобным. Ключевое слово "казаться".
Так я это и говорил, собственно.
> В итоге приходим к тому же, с чего начали: эти люди не умеют грамотно работать к компьютером и предпочитают продолжать каждый день растрачивать впустую своё время и силы, лишь бы только не пришлось изучать ничего нового.
Не всё так однозначно. Ну то есть да, такое тоже есть. Но можно ли прямо однозначно утверждать, что все кто не работают в юниксовом терминале, просто не умеют грамотно пользоваться компьютерами?
Есть же те же топовые программисты из микрософта какого-нибудь, или вон разработчик fasm, который этот fasm разрабатывает из-под Windows 10, хотя у него есть компьютеры с другими ОС, даже с DOS на котором он регулярно этот fasm тестирует. Неужто они умеют пользоваться компьютером хуже нас с вами?
< опытный
< опытный виндузятник мышкой реактивно ведёт к нужному пункту меню, потому что у него уже есть мышечная память >
Не-не-не :D Я вот сижу на Win10 чуть больше года, и за это время некоторые (многие) кнопочки в Параметрах меняли расположение аж ТРИ раза. К счастью, искать их не приходится - там есть поиск, а многое запускаю сразу из командной строки. А виндузятник я опытный.
Power Shell желания овладеть им не вызывает. Админы его юзают, но он и создан-то именно для администрирования. Дотнетчикам в нём удобно, ведь можно использовать классы .Net - это как сишарп с другим синтаксисом.
Bash в использовании приятнее, хотя я лично столкнулся с ним сильно позже, чем с PS.
Насчёт программистов Микрософта - их первой осью был Xenix, и все версии DOS, а так же винда вплоть до какой-то там версии NT писалась под ней. В консольном vi. И что-то мне подсказывает, что на NT они переползли потом лишь из-за того, что железо новое, да и с отладкой проще. Скрипты сборки винды написаны на cmd, и переписывать их на PS они даже не планируют. PS вообще слабо пригоден для скриптования из-за слабой предсказуемости - одна и та же команда норм работает интерактивно, а в скрипте делает абы что в тех же условиях. Скрипт превращается в море костылей. И это не детская болезнь - языку уже полтора десятка лет.
Нарыл, кстати, лаунчер для Андроида - командная строка вместо рабочего стола. Поюзал, вполне удобно. Набрать "flash" у меня получается быстрее, чем опустить "шторку" и найти там глазами иконку фонарика. Но смешно - на линуксе запустить Java-машину, в которой запустить монструозный гуй, в котором будет рисоваться линуксовая консоль на весь экран. Хочу теперь смарт, где такая консоль будет нативной, а то нынешний вариант плохо интегрирован с железом - звонить неудобно.
> Параметрах
> Параметрах меняли расположение аж ТРИ раза.
Ну да продолжайте сидеть с автообновлениями, глядите что-то серьезнее ещё пришлют.
> сишарп
Вообще жду когда подохнет эта "технология", слишком уж она меня выводит из себя. И буду с улыбкой смотреть на то как дотнетчики начнут переучиватся на новый фреймфорк через лет так 1.5-2.
> PS вообще слабо пригоден для скриптования из-за слабой предсказуемости - одна и та же команда норм работает интерактивно, а в скрипте делает абы что в тех же условиях.
Удивляюсь тому, какие обезьяны там сидят. Это же надо было так! На глаза "топовость" тамошних погромистов.
> Нарыл, кстати, лаунчер для Андроида - командная строка вместо рабочего стола
А можно название?
< продолжайте
< продолжайте сидеть с автообновлениями >
Так и сделаю. Насмотрелся уже за годы работы в сервисе, во что превращается "десятка" у отключаторов обновлений. Их невозможно выключить, не сломав систему.
< жду когда подохнет эта "технология", слишком уж она меня выводит из себя >
У неё нет ни одной причины умирать в ближайшее время. Так же, как и у вас, я полагаю, нет ни одной причины обращать внимание на то, что она существует.
< А можно название? >
T-UI Launcher. Он же Linux CLI Launcher.
Ужас
Господи. В данный момент работаю сисадмином в не-IT компании, везде на рабочих станциях стоят Win8.1 и Win10. Осенью незаметно прилетели обновления системы, которые прошли мимо меня и поломали сетевую печать у тех, чьи системы успели обновиться. Было очень больно, т.к. компов немало, автообновления не отключаемы, обновления снова прилетают
Не пробовали
Не пробовали весь мелкософт зафильтровать на роутере на уровне IP? По идее должно помочь.
Там главная
Там главная проблема в том, что важное сетевое оборудование находится под контролем другого человека (так исторически ещё до меня сложилось), которого n раз попроси что-нибудь сделать -- в любом случае жди полгода.
Мечтаю устроиться туда, где с виндой вообще не надо будет контактировать. Only POSIX-compliant OS's
Windows NT
Windows NT формально POSIX-compliant
Я не знаю, как
Я не знаю, как там насчёт "формально", зато точно знаю, что select там умеет работать только с сокетами. Если ЭТО ещё и compliant, то с этим долбаным позиксом-хренозиксом всё даже ещё хуже, чем я думал.
"Compilant" была
"Compilant" была только POSIX-подсистема. На Win32(GUI&CUI), OS/2 и 16-разрядные приложения эта "совместимость" на распространялась, и, разумеется, на внутренние No-UI процессы Windows NT.
С сетью в виндовом пазиксе было ещё смешнее.
Так не надо
Так не надо мечтать, устраивайтесь :-) Могу разве что предостеречь от термина POSIX-compliant. Ибо POSIX — это не более чем комитетский бастард. И, к сожалению, не менее чем (в том смысле что вреда от него ничуть не меньше, чем от других порождений комитетского мышления).
Насколько я понимаю, вашим устремлениям лучше отвечает термин "Unix-like OSes".
Спасибо, принял
Спасибо, принял к сведению)
Их невозможно
Их невозможно выключить, не сломав систему.
Из этого следует, что данная система непригодна ни для чего, никогда и ни в каком виде, а все её пользователи представляют опасность для окружающих наравне с буйными душевнобольными.
> Вообще жду
> Вообще жду когда подохнет эта "технология"
> через лет так 1.5-2
.NET уже лет 20 живёт и для того, чтобы такие предположения строить, нужно иметь серьёзные причины. Не поделитесь? :)
> На глаза "топовость" тамошних погромистов
Вообще да, говорят, что в корпорации зла более менее адекватных людей не очень любят. И даже специально отфильтровывают.
> Не
> Не поделитесь?
Ну я про виртуальность этой штуки. Сидели бы и дальше на винде, а не шли бы в линукс со своим mono :P.
Mono придумали
Mono придумали линуксоиды хрен пойми зачем. Микрософт выкатил .Net Core. Не путайте их, у Mono нет планов захватить мир.
Это не только в
Это не только в мелкософте. В том же гугле то же самое, есть некая немногочисленная группа программистов, занявших верхние позиции, и там никто новый не требуется, а кто ярусом ниже — там серьёзные люди не нужны.
По поводу
По поводу расположения кнопок мне вообще интересно, как это так — кто-то где-то прнимает решение за пользователя, как ему, пользователю, будет лучше, а пользователь вынужден под это всё прогибаться, потому что, видимо, не понимает, что может быть как-то иначе.
Вот для контраста — мой старый, где-то даже древний оконник fvwm2. Его дефолтные настройки со временем меняются, но я этого не замечаю, потому что с машины на машину, с системы на систему перетаскиваю свой, аккуратно под собственные предпочтения заточенный конфиг. За вот уже больше четверти века у меня на основной машине ни разу не менялся внешний вид графической среды, все рамочки того же цвета, все кнопочки на прежнем месте, все шорткаты как были, так и есть, только новые добавляются иногда по мере появления потребностей.
Вообще что-то мне сдаётся, что примерно так и должно быть: это пользователь должен принимать решение, как будет выглядеть экран его компьютера, а не кто-то там за него. То же самое, если подумать, и с вебом: дайте информацию, а как конкретно она будет выглядеть — не ваше собачье дело, пользователь сам решит.
Так нет же, причём сразу везде "нет же", даже в мире линукса плодятся моральные уроды, которых хлебом не корми — дай влезть куда не звали: последнее новшество — гномеры, чьи "приложения" вторглись в зону ответственности оконного менеджера. "Никакой свободы выбора для пользователя, ибо вот ещё чего!" Позорище проклятое.
С виндой, впрочем, не сравнить, до винды с её безальтернативным гуём даже гномерам пока что как до луны пешком.
Это UI-дизайнеры
Это UI-дизайнеры решают как я слышал. Как обычно под дудку маркетологов, которые следят за "трендами" (или их задают?). Впрочем пока вся эта орава "специалистов" не дойдёт до командной строки и конфиг файлов все их труды - это
бесполезная трата времениопаснейшая деятельность.Кстати про веб. Тяжелый случай - это адаптивная вёрстка. Заходил на один сайт, а на этом сайте у меня мало информации размещалось на один экран. Я не мог так листать страницу, поэтому решил поиграть с масштабом. Ничего не получилось. Потом до меня дошло, что можно менять размер окошка браузера. Так я довел его до соотношения 1:4 (смартфона), и "вдруг" у меня на экране поместилось столько информации сколько я хотел.
> вебом: дайте информацию, а как конкретно она будет выглядеть
Такой браузер где я могу написать 1 css на все сайты интернета и +выборочно? Нет, я даже за!
в винде вам
в винде вам постоянно придётся что-то вспоминать или искать
Как показывает мой опыт. мне это там приходится делать даже реже, чем в линуксе.
Power Shell
Насколько я понимаю, он только-только появился, но дело не в этом. Покажите мне виндузятника, который всё — ну, как минимум все действия с файлами — выполняет в этом power shell'е.
Я к тому, что даже на маках много раз видел, как открывают терминал и в нём фигачат, но вот чтоб на винде окошко с power shell'ом открыл кто-то отличный от профессионального админа, пасущего сетку на сотню машин — не видел ни разу.
топовые программисты из микрософта
Не смешите мои тапочки.
разработчик fasm, который этот fasm разрабатывает из-под Windows 10
Ну значит правильно я nasm выбрал в своё время. Что-то интуитивно мне этот fasm не понравился.
Неужто они умеют пользоваться компьютером хуже нас с вами?
По-моему, это несомненно.
Выбор ассемблера
значит правильно я nasm выбрал в своё время.
Почему тогда не bunutils, если с nasm всё равно без них не обойтись при сборке линуксовых бинарников? Вроде бы as из GNU binutils больше похож на юниксовый.
Из каких-то педагогических соображений? Или повлияли предпочтения со времён MS-DOS?
Подробный
Подробный ответ на вопрос, почему для обучения следует использовать синтаксис Intel, имеется в предисловии к третьей части книги (см. текст между заголовком части и началом главы 3.1).
Как известно, GNU
Как известно, GNU as тоже понимает синтаксис intel-microsoft:
или с помощью документированных директив
.intel_syntax noprefix
https://sourceware.org/binutils/docs-2.37/as/i386_002dVariations.html
Microsoft тут
Microsoft тут вообще ни при чём, есть синтаксис Intel, есть синтаксис AT&T, называются они так. Intel в официальной документации использует именно свой синтаксис, что вполне естественно; и для данной конкретной системы команд этот синтаксис выглядит естественнее, чем AT&T (ну да, если бы курс был ориентирован на PDP-11, даже я бы взял синтаксис AT&T).
Конкретно про gas можно сказать проще: он мне не нравится. Ощущение от него таково, что он никогда не предназначался для ручного программирования, только для трансляции всего того, что выплюнут компиляторы Си и прочих ЯВУ. Могу ошибаться (в том смысле, что авторы gas могли не иметь такого намерения), но ощущение такое есть. Он какой-то нечеловеческий.
Впрочем, когда я в 2007 году искал, какой взять ассемблер (условием был именно синтаксис Intel), я с ходу нашёл nasm и fasm, а про то, что gas тоже его поддерживает, информации не нашёл — то ли тогда такой поддержки не было, то ли просто не попались соответствующие тексты. Переделывать в любом случае не буду :-P
если бы курс
если бы курс был ориентирован на PDP-11, даже я бы взял синтаксис AT&T
DEC не использовала синтаксис, придуманный Кеном для юниксового ассемблера PDP-11, ни в документации, ни в MACRO-11.
# и @ уже использовались в UNIX для исправления напечатанного текста. А ; Кен решил разделять инструкции, записанные в одной строке: в интерактивных системах разделения времени уже не было причин кодировать каждую инструкцию или директиву на отдельной перфокарте. Правда этой возможностью он не злоупотреблял, чаще всего через ; перечислялись параметры системных вызовов или содержимое коротких массивов и структур.
Для отделения комментария в конце строки Кен выбрал /, как в DECовских ассемблерах для более ранних машин.
>>Неужто они
>>Неужто они умеют пользоваться компьютером хуже нас с вами?
> По-моему, это несомненно.
Ну не знаю. Я бы что-то подобное fasm написать бы не смог, например. Явно же, что для написания полноценного макроассемблера, к тому же на этом же ассемблере требуется намного более высокий уровень понимания компьютеров, чем у меня.
Кстати, линуксовая версия даже libc не использует, файл статический, дёргающий системные вызовы, а для выделения и освобождения памяти автор написал собственный упрощённый аналог malloc/free, который на 64-битной системе выделаяет адреса в пределах первых 4 гигабайтов, чтобы остальной код, использующий 32-битные указатели мог работать.
> Ну значит правильно я nasm выбрал в своё время. Что-то интуитивно мне этот fasm не понравился.
У обоих есть свои плюсы и минусы. На мой взгляд, из них для вашей задачи наиболее релевантно то, что nasm умеет добавлять отладочную информацию в формате, понимаемом gdb, а fasm её дампит в отдельный файл в своём собственном формате.
> Я бы что-то
> Я бы что-то подобное fasm написать бы не смог, например.
Я для себя проблемы в этом не вижу, кроме времени, которого у меня на подобные этюды нет и не предвидится.
Впрочем, моё "несомненно" относилось в основном к "топовым программистам майкрософта". Полагаю, что WinAPI (со всеми этими функциями о двенадцати параметрах, восемь из которых всегда нулевые) проектировали как раз те, кого там считают "топовыми". И это всё, что нужно знать про их квалификацию.
Что характерно, "рядовые" (в смысле, совсем даже не топовые) программисты там попадаются вполне вменяемые, но, если мои сведенья верны, надолго они там не задерживаются.
> линуксовая версия даже libc не использует
А почему "даже", если он написан сам на себе, т.е. на ассемблере? Нахрена ассемблерной программе libc? Точнее, даже не так — если всё равно использовать libc, то на кой же ляд вообще писать на асме? (впрочем, вопрос "накой ляд писать на асме" в любом случае имеет только один валидный ответ: для демонстрации собственной крутизны).
> А почему
> А почему "даже", если он написан сам на себе, т.е. на ассемблере? Нахрена ассемблерной программе libc?
Ну, у fasm есть "ядро" и несколько интерфейсов. Один из них для libc, его предполагется использовать на всяких юникс-подобных ОС вроде BSD, но и на линукс должно работать. Собирается это в объектный файл который потом ещё надо линкером превратить в исполнимый.
Кроме fasm, ещё есть fasmg, который появился сравнительно недавно. Ключевое отличие что это уже больше чем просто ассемблер: теперь даже команды x86 — это тоже макросы, за счёт этого становится возможным ассемблировать произвольные двоичные файлы, а не только исполнимый код для x86. Правда он сам всё равно написан в командах x86 и на arm-компе будет только через qemu-user или что-то подобное запускаться.
Вот в этом fasmg почему-то линуксовая версия дёргала из /lib/ld-linux.so.2 функции malloc, calloc, realloc и free. Но недавно это убрали и теперь она дёргает только системные вызовы и использует свой менеджер памяти. Версия для libc тоже есть, она дёргает ещё и файловые функции типа fread, fwrite, fseek, ftell, write (последнее для того чтобы писать не буферизовано на stdin/out).
> то на кой же ляд вообще писать на асме?
1) Компиляторы ЯП принято писать на них самих почему-то.
2) Видимо автору проще писать на ассемблере, чем на каком-то другом языке. Или может доставляет больше удовольтсвия?
1) Компиляторы
1) Компиляторы ЯП принято писать на них самих почему-то.
В общем случае это сомнительный принцип. Мало кто пишет компоновщики на их входных языках. Хотя технически это, несомненно, возможно.
Ну это я
Ну это я всё-таки не стал бы сравнивать, входной язык компоновщика — это DSL до мозга костей, он из рук вон плохо подходит для чего-то кроме управления компоновкой (уже готовых частей).
А, скажем, интерпретатор на его собственном языке написать вообще проще пареной репы в большинстве случаев, но практического смысла в этом — никакого от слова "совсем". Ну и что?
Вообще как я это вижу, пионеры Юникса хотели сделать Си единственным компилируемым языком в своей системе, поэтому его сам на себе и реализовали. А фанаты Паскаля, подозреваю, просто хотели показать, что они ничем не хуже и тоже так умеют. Но и всё, собственно. Если Си и Паскаль "вынести за скобки", мы обнаружим, что компиляторы, написанные "сами на себе", встречаются не так уж часто (хотя, несомненно, есть).
> Компиляторы
> Компиляторы ЯП принято писать на них самих почему-то
Важное уточнение: высокоуровневых языков :) Тот же FreePascal сначала на Си был написан (небольшое подмножество), а потом допиливался на самом Паскале. Ещё
сектантылюбители Рефала так часто делают свои реализации.Рефалистов я в
Рефалистов я в этом не заметил. Единственная сколько-нибудь вменяемая реализация Рефала — Refal5 — написана на чистом Си, как и предшествующий refal2 (но его вменяемым называть невозможно). Из последовавшего я много чего видел, даже на джаве, но не на самом рефале.
Про FreePascal для меня это новость, я был почему-то уверен, что они начинали с TurboPascal в качестве компилятора для их компилятора.
На счёт FreePascal
На счёт FreePascal был неправ: в интернете пишут, что его первые версии были сделаны в Турбо Паскале 7.0. Видимо, я FreePascal с каким-то другим диалектом перепутал.
На счёт рефала: некоторые реализации созданы при помощи раскрутки компилятора. Причём, некоторые из них раскручивали "сами себя", а некоторые требуют стороннего компилятора (например, Refal 5 lambda). Но вообще, второй вариант кажется немного бредовым :)
Во-первых, ни
Во-первых, ни фига это не "принято", с ходу припоминается толпа компайлеров, которые совершенно не self-hosted или как это там называется. Во-вторых, ассемблер — это НЕ компилятор ЯП, это именно ассемблер, программа совершенно отдельного класса. В-третьих, не знаю, что там принято, но вот чего не принято — так это боевого программирования на ассемблере.
А вот насчёт "доставляет больше удовольствия" я совершенно запросто готов поверить :-)
В защиту fasm
Трудно сравнивать с nasm'ом, т.к. никогда им не пользовался. А вот fasm плотно использовал, перешел на него когда-то с tasm'а. Очень мне понравилось экономия нескольких байт на условные переходы вперед, tasm изначально не знал на сколько далек прыжок и сразу рассчитывал его как дальний и если предсказание не оказывалось ложным то он подставлял туда ближний переход, а оставшиеся байты заменял nop'ами. Fasm, за счет его много проходности, устраняет этот недостаток.
Что касается автора nasm'а (Simon Tatham), серию своих игр-головоломок, которые мне очень нравятся, он портировал на js, WebAssembly, Java. Сам автор, кстати, не гнушается использовать Windows.
> Что касается
> Что касается автора nasm'а (Simon Tatham), серию своих игр-головоломок, которые мне очень нравятся, он портировал на js, WebAssembly, Java. Сам автор, кстати, не гнушается использовать Windows.
Разрабатывать под Виндовс не значит пользоваться Виндовс! Вот, уважаемый автор сайта тоже писал под Виндовс, но это не делает его пользователем сей ОС. Так, между прочим...
> Разрабатывать
> Разрабатывать под Виндовс не значит пользоваться Виндовс!
В данном случае и разрабатывает и пользуется.
...I was also annoyed that every time I found a good game on (say) Unix, it wasn't available the next time I was sitting at a Windows machine, or vice versa; so I arranged that everything in my personal puzzle collection will happily run on both those platforms and more.
Simon Tatham's Portable Puzzle Collection
Только не подумайте, что я являюсь фанатом Windows.
Я тоже иногда
Я тоже иногда оказываюсь за компом с виндой — редко, но чаще, чем мне бы хотелось. И чо? :-)
Судя по тому, что этого Саймона анноит отсутствие конкретной игрушки под Unix, он не виндузятник. А что виндой явно не брезгует (в отличие, например, от меня) — ну так извращенцы всякие бывают :-)
За подобные
За подобные вольности авторам ассемблеров нужно руки отрывать. Ассеблер должен генерировать те инструкции, которые прописаны в исходнике, строго, и никакие иные. На то он и ассемблер, а не ЯВУ. Для условных переходов — если нет слова near, генерить short; для безусловных — если нет слова short, генерить near. Всё остальное — непрошенная самодеятельность. Хочешь "оптимальный" прыжок — не поленись написать short, если выдаст ошибку — убери слово short.
Варианты машинных команд
> Ассеблер должен генерировать те инструкции, которые прописаны в исходнике, строго, и никакие иные.
Только вот не получится это сделать так запросто. Соответствие между возможными машинными кодами и возможными записями инструкций не взаимо однозначное: одна и та же ассемблерная инструкция может кодироваться более чем одним способом, например mov между двумя регистрами.
Кстати, в fasmg он и этим вопросом занимался, вроде как есть набор макросов, расширяющих синтаксис ассемблера так, чтобы была возмоность выбрать конкретный способ кодирования любой инструкции.
Что плохого в том, чтобы ассемблер сам выбирал оптимальный способ кодирования конкретной инструкции, если программист не указал конкретный вариант?
mov между двумя
mov между двумя регистрами, насколько я знаю, как раз кодируется совершенно однозначно. Несколько хуже с исполнительным адресом, в котором присутствует константа, для константы явно не указана разрядность, а сама константа умещается в один байт. Здесь, опять же, решается всё очень просто: по умолчанию используется форма машинного кода с наименьшей возможной разрядностью константы, но если её разрядность указать — то именно она и используется.
Ответ на вопрос "что плохого" очень простой: это не его собачье дело. Например, код, поданный на вход ассемблеру, может не быть написан руками, и вообще-то он может уже быть результатом работы оптимизатора — в этой ситуации самодеятельность ассемблера может только навредить; но дело, как водится, даже не в этом, а в том, что каждый должен заниматься своим делом и не делать ничего такого, о чём его не просили. Ещё раз: ассемблер — это не компилятор, это программа совершенно иного класса, если угодно, просто такой генератор образа памяти, и именно таковым он и должен быть. Оптимизация в его зону ответственности не входит.
У ассемблера
У ассемблера могут быть какие-то предпочтения по кодированию, или на платформе могут быть какие-нибудь соглашения о "каноническом" варианте кодирования инструкции, но для процессора нет разницы, как именно закодирован
mov
:ndisasm movalcl
Кстати, не знал,
Кстати, не знал, спасибо. В общем всё сходится, если сюда вот посмотреть http://www.logix.cz/michal/doc/i386/app-a.htm ; 88 -- это "mov Eb,Gb", тогда как 8A - это "mov Gb,Eb", но при этом Gb может представлять собой только регистр (байтовый), тогда как Eb -- или регистровый операнд, или "память". Соответственно между двумя регистрами можно и так и эдак.
В принципе это означает, что используемая мнемонизация неадекватна системе команд, поскольку это разные машинные команды, а мнемоники не позволяют эту разницу показать.
fasmg
Вот! А в fasmg как раз ввели новый экспериментальный синтаксис для возможности указать конкретный вариант кодирования. Но, так как, там все инструкции x86 не ассемблируются непосредственно, а заданы макросами, то для этой штуки кроме самого fasmg ещё нужны макросы, которые скачиваются отдельно. По умолчанию в дистрибутиве fasmg, вроде, этого ещё нет.
Как раз в той теме я и прочитал, что mov между регистрами неоднозначен.
В общем на tasm'е
В общем на tasm'е так и делал -- явно указывал short. Вообще borland пытался в него ООП добавить, выглядело это, правда, немного жутковато )
Power Shell
Power Shell существует уже лет 15, наверно, и гораздо удобнее, чем cmd.exe, но до командной строки в линуксе, мягко говоря, не дотягивает. Хотя, например, дополнение при помощи Ctrl-Space иногда оказывается очень удобным.
Скорость виндовых оболочек
> Power Shell существует уже лет 15, наверно, и гораздо удобнее, чем cmd.exe
Но зато медленней. Я сравнивал скорость исполнения аналогичных команд (которые делали одно и то же) в cmd и в PoSh и разница был в разы и не в пользу PoSh.
Из-за такой вот тормознутости, cmd всё-таки оказывается предпочтительней для большинства задач, где не нужны особо хитровывернутые управляющие конструкции.
А ещё почему-то поиск файла по известному имени по NTFS из-под Windows оказывается медленней чем если перезагрузиться в линукс и применить find. Хотя казалось бы в Linux медленный FUSE ntfs-3g, работающий в юзерспейсе, а в винде нативная работа на уровне ядра.
< поиск файла ...
< поиск файла ... NTFS из-под Windows оказывается медленней чем если перезагрузиться в линукс >
Права доступа. Винда их чекает чуть реже, чем постоянно, а под линуксом они игнорируются - NTFS права несовместимы с никсовыми.
PoSh нифига не удобен, особенно в интерактивном сеансе. Он будто считает своим долгом сделать так, чтобы я курил онлайн-документацию при каждой попытке что-либо сделать в командной строке, и к каждой команде пририсовывал кучу мишуры только чтобы доказать, что я хочу сделать именно то, что написал. Дошло до того, что я установил WSL2 и пользуюсь башем оттуда. Удобнее значительно, хотя башем почти не владею.
PowerShell
> PoSh нифига не удобен, особенно в интерактивном сеансе. Он будто считает своим долгом сделать так, чтобы я курил онлайн-документацию при каждой попытке что-либо сделать в командной строке, и к каждой команде пририсовывал кучу мишуры только чтобы доказать, что я хочу сделать именно то, что написал.
А почему вы пользуетесь онлайн-документацией, если есть
Get-Help
?Мне не понравились вот такие длинные названия команд через дефисы. Как будто, с Help можно сделать что-то другое, кроме как Get.
А вместо ls у них вообще
Get-Child-ItemGet-ChildItem
... Да чем они упоролись, почему у них между первыми двумя словами дефис, а между вторыми CamelCase?Вот когда слышу про WSL так и подмывает спросить — а зачем эмулятор с виртуалкой, если можно поставить нативно? А винду можно наоборот в виртуалку засунуть. Заодно можно запретить ей доступ на всякие левые ресурсы, чтобы рекламу на рабочий стол не могла подгружать и не обновлялась, когда не надо.
Get-Help не особо
Get-Help не особо удобен.
В Get-Help написано, что Help можно Save и Update.
Упоролись они командлетами, и эти дефисы с верблюдами как раз самая понятная и логичная (к.м.к.) часть PoSh.
Я удовольствием переселюсь на свободную ОС, если появится виртуалка, за две секунды запускающая огрызок винды, достаточный для работы прошивочных и диагностических драйверов всех г*девайсов и их же сервисного софта, и дающая винде полный доступ к указанным портам без глюков и лагов. Или когда всё это нативно появится не только под винду. Ну или когда сменю род занятий. Последнее наиболее вероятно.
Рекламу на рабстол винда не суёт. Обновляться по своему желанию уже разучилась, и загруженное обновление можно откладывать месяцами. А для перечисленных выше задач сеть ей можно вообще отрубить.
Не, ну с cmd-то
Не, ну с cmd-то сравнивать как-то даже нелепо, не? :-) Это как взять какой-нибудь паровой автомобиль на дровяной тяге и сравнить его с другим, от которого колёса отвалились.
>Я к тому, что
>Я к тому, что даже на маках много раз видел, как открывают терминал и в нём фигачат, но вот чтоб на винде окошко с power shell'ом открыл кто-то отличный от профессионального админа, пасущего сетку на сотню машин — не видел ни разу.
Дотнетчики таким занимаются, сам видел
С одной
С одной стороны, это всё-таки профессиональные программисты, а с другой — что, реально они, скажем, файлы с флешки таким способом сливают?
Знаю я одного
Знаю я одного человека, который, как вы говорите, "до полной ус$$чки" находил на мои агрументы "За" использование Linux свои контраргументы. И там фигурировали такие, что ну домохозяйки же ну не поймут как использовать. Не помню какие я ему примеры приводил, но там точно был такой: у Unix драйверва out of the box. Знаете, что он мне ответил? Говорит, мол, десятые форточки тоже. Ага, подгружая их без моего на то ведома из сети. Просто facepalm.
Уж не знаю, чем ему так Unix насолил. Но очевидно, что так на форточках и останется. После того разговора про драйвера, о Unix я решил с ним больше не говорить. Только продолжал меня подкалывать на учебной практике: "Опять ты со своим Linux. Уйдёшь -- удалю его с твоего компа".
FAQ
Вообще неплохо было бы иметь на сайте ещё и поиск как в linux.org.ru
Меня выручает гугл, но для некоторых это неочевидно, да и он может коряво индексировать
Сайт же не
Сайт же не такой большой на самом деле.
Наверное, можно написать для себя программу, которая выкачивает весь сайт в файловую систему (например, парся html главной страницы, а далее рекурсивно бегая по всем ссылкам, не ведущим за пределы сайта, и составляя таким образом граф-карту сайта). Результатом будет набор HTML-страничек в папочках.
А дальше grep в руки и вперед)
всему вас, молодёжь, учить надо
1) откройте для себя wget -m
2) ПАПКИ — В ШКАФУ!!!
Спасибо
1) За это спасибо, не знал.
2) За "папки" прошу простить - я понимаю, что объекты файловой системы называются, вообще говоря, каталогами или директориями (а папки - понятия графических интерфейсов), но на мой взгляд, слова "каталог" или "директория" уж как-то официозом отдают в речи, приближенной к разговорной.
Это вам так
Это вам так кажется, а мне вот кажется, что слово "папка" в любом контексте, имеющем отношение к компьютерам, "отдаёт" ламерством.
Вот это не
Вот это не получится, извиняйте. Движок сайта в состоянии EOL уже лет десять по меньшей мере.
С вашей новой
С вашей новой CMS, все поменяется? :) Хотя бы с PHP-кодом Drupal больше ну будете связыватся.
Кстати вы наверное знаете такие ссылки как guestbook/archive/*#comment-* с новой страницой гостевой становятся битыми. Можно было бы именовать архивы c нуля - самая старая, и дальше...
Я не уверен, что
Я не уверен, что стану этот сайт переносить на новый движок. Рассматриваю такой вариант, но не уверен. В любом случае поиск по сайту я не рассматриваю в качестве приоритетной задачи, поиск вообще штука сомнительная.
А архивы гостевой так и нумеруются, только с единицы. Раньше комменты на отдельные страницы разносились, сейчас этого нет. Так что бьются ссылки только при переносе очередной страницы гостевой книги в архив.
Анонс xmpp-чатика
Приглашаем всех в xmpp-чатик, созданный для взаимопомощи при проблемах, связанных с изучением программирования
xmpp:newbie_unix_prog@e2e.chat?join
Извините, а как
Извините, а как туда присоединится? Я пока зелёный, прошу не бить :)
Скачиваете
Скачиваете XMPP-клиент. (Я пользуюсь Gajim, он на питончике. Можете попробовать Psi plus, он на С++. Если нужен еще и IRC, попробуйте Pidgin). Находите себе сервер (я пользуюсь e2e.ee), там регистрируеетсь, потом авторизуйтесь в клиенте, там находите кнопочку Join Conference, вводите
newbie_unix_prog@e2e.chat
И готово. Если непонятно, могу запилить инструкцию с картинками
Рекомендую
Рекомендую попробовать консольный клиент irssi в связке с плагином irssi-xmpp.
Про PGP,
Про PGP, специально не рассказали, или оставили на "приятный" сюрприз?
Я им не
Я им не пользуюсь, слава OMEMO. Так что учить тому, чего не знаю, не буду.
> на "приятный"
> на "приятный" сюрприз?
Почему НА? Писал же КАК. Исправляюсь.
>слава OMEMO
Начнем с того, что не все программы его поддерживают и поддерживают хорошо, может сейчас с этим дела обстоят лучше. А PGP есть вот везде.
Те реализации программ в которых ОМЕМО идет по умолчанию грешат самодеятельностью. Вот буквально берет и само обменивается ключами с контактами. Само собой можно ключи вбить ручками, здесь философия в отсутствии понимания самой таковой возможности у ньюфагов.
Иногда такая самодеятельность выдает подобную ржомбу: https://www.linux.org.ru/forum/general/14876559
>А PGP есть вот
>А PGP есть вот везде.
Если я буду выбирать ПО по популярности, то я буду общаться из под винды на фейсбуке.
А зачем вам OMEMO,
А зачем вам OMEMO, PGP, GPG? Чатик шифруется?
я пока зеленый, прошу не бить :-)
>Чатик
>Чатик шифруется
Мне кажется бесмысленным шифровать открытую информацию, так что нет.
Вроде
Вроде разобрался,правда, подключится не могу, необходимо имя комнаты
Имя комнаты:
Имя комнаты: newbie_unix_prog
Имя сервера: e2e.chat
В зависимости от клиента это может быть два разных поля (у Gajim, что был под руками так, например)
Имя комнаты
UPD: хотя вообще-то чёрт разберёт, мне pidgin заявил, что это не является допустимым именем комнаты, так что хз
Возможно, у
Возможно, у вас пробелы до или после имени комнаты при копировании захватились.
Кстати, как ни
Кстати, как ни странно, похоже на правду — вбил всё руками и тут же всё сработало.
Тактично умолчим об умственных качествах разработчиков pidgin, не озаботившихся удалением пробельных символов из начала и конца.
В некоторых
В некоторых клиентах нужно имя и сервер писать в два отдельных поля, а собаку вообще не писать, в некоторых полностью всё имя комнаты.
Вы таки
Вы таки думаете, что я не в курсе, да? :-)))
Стало, кстати, интересно, с каких пор я пользуюсь джаббером. Порылся в старых архивах, обнаружил логи за 2004 год. Похоже на правду.
Странно. В
Странно. В чатике людей много, а Fairball даже с Pidgin сидит, все работает.
EDIT: попробовал сам, зашло со второй попытки.
Видимо, что-то
Видимо, что-то не так с моим клиентом. Ну и пёс с ним.
https://www.opennet.ru/openne
https://www.opennet.ru/opennews/art.shtml?num=56479 как показательно...
Вот вы смеетесь
Вот вы смеетесь
над убогими, а они вон целый установщик системы на джавапитон переписали!https://www.opennet.ru/opennews/art.shtml?num=56494
Господи, зачем
Господи, зачем они это делают (рукалицо)...
Всякие веб-интерфейсы и гуи нужны для пользователей, чтоб им проще с компухтерами жилось, но ведь дистрибутивы линукса априори используются более продвинутыми пользователями/программистами/админами (которые и консольные шаманства осилят). Зачем тогда нужен инсталлятор с красивостями, который все равно будет запущен ровно один раз?
Вы
Вы категорически неверно воспринимаете действительность, и желательно это осознать. Веб-интерфейсы и гуи нужны не для пользователей, а для рекламно-маркетоидской мрази, и не чтобы использовать компьютеры, а чтобы впаривать пользователям то, что им не нужно (впарить нечто красиво разрисованное намного проще, чем функциональное). При обучении реально с нуля командная строка, текстовые файлы и интерактивные интерфейсы на кейстроках осваиваются быстрее и проще, чем гуи. А линукс используется, быть может, реально более продвинутыми, но продвинутыми не в компьютерах, а в отношении к окружающей действительности — людьми, способными осознать пагубность тупого следования мейнстриму.
Ну и самое главное: никакого "шаманства" работа с консолью не содержит. Шаманство — это мышкой в иконки тыкать.
Установщик на макакинг-"технологиях"
установщик системы
Вангую, что не за горами время, когда эти альтернативно-одарённые начнут в установщик встраивать рекламу. На фоне подобного мракобесия, дистрибутивы без установщика начинают выглядеть всё более адекватно.
При чём тут
При чём тут "убогие"? Убогие обычно безвредны, а эти — настоящая боевая агрессивная безмозглая жопорукая мразь. И главный лозунг — если у нас руки из жопы, то всем остальным тоже необходимо незамедлительно трансплантировать руки на жопу.
Fedora, RHEL и CentOS можно окончательно списывать в убыток. Впрочем, для RHEL и федоры это уже давно понятно.
Fedora, RHEL и CentOS
Fedora, RHEL и CentOS можно окончательно списывать в убыток. Впрочем, для RHEL и федоры это уже давно понятно.
У меня ещё во времена моего первого знакомства с линуксом в конце 90-х, уже не помню по каким конкретным причинам, сложилось отрицательно-подозрительное отношение к дистрибутивам на основе RPM. Ну вот оно так до сих пор и держится.
Да ладно, вон в
Да ладно, вон в Openwall Linux тоже rpm :-) Правда, там несколько проще: репозиториев нет, ставится сразу всё, благо этого "всего" совсем немного. Но вообще, конечно, rpm'овские спеки — это какой-то ад кромешный, я под тот же Openwall делал пакеты, опыт имею.
А, простите,
А, простите, зачем там тогда rpm? Если "репозиториев нет, ставится сразу всё" и "rpm'овские спеки — это какой-то ад кромешный", то не проще ли было бы взять банальный tgz?
Тут на самом
Тут на самом деле не один вопрос, а два. Первый — зачем там вообще пакетный менеджер. Это как раз понятно — чтобы бардака не было, чтобы, например, версии софтин менять аккуратно, а не "по живому", чтобы деинсталлировать софтину можно было корректно. Поэтому, когда команда Openwall занималась удалённым администрением (сейчас вроде перестали, но довольно долго этим промышляли), считалось, что любую софтину нужно не просто configure/make/make install, а обязательно опакетить и rpm -Uvh.
Второй вопрос — почему именно rpm. Вот на этот вопрос ответа не знаю, решение не я принимал.
Странная
Странная какая-то новость.
Зависимости - это, безусловно, зло, но тут получается какое-то зло во плоти, дышащее адским жаром. Разработчик изменил коды какой-то библиотеки, выложил их в репозиторий, и куча систем в мире, зависящих от данной библиотеки, сразу сломалась? Значит, разработчики этих систем те еще молодцы: получается, у них была зависимость не от конкретной версии библиотеки, а от последней актуальной.
Не могу я поверить, что можно быть настолько неаккуратными (радостно качать самую последнюю версию библиотеки, веря, что разработчик библиотеки в этой версии не наделает фигни), хотелось бы думать, что проблема в чем-то другом.
Зависимости
Значит, разработчики этих систем те еще молодцы: получается, у них была зависимость не от конкретной версии библиотеки, а от последней актуальной.
Ну так во все помойках типа npm и аналогичных лежат последнии версии, вроде как. Пакетные менеджеры для скриптовых язычков - это то ещё поделие. Макаки обычно, не думая, закачивают все зависимости в свои "проекты" при деплое. Версии библиотек? Куда там. Типовой макакинг-проект - это по сути декларативное описание зависимостей. Они не подбирают библиотеки в зависимости от функционала, они, не думая, тянут последнее актуальное дерьмо из репозитория своего скриптового язычка. Это чем-то напоминает пакетные менеждеры дистрибутивов, только там всё в разы хуже. Программирующие пользователи, одним словом.
Вы всё ещё
Вы всё ещё верите в человечество? Прекращайте :-)
Насколько я понимаю, дело именно в том, что там толпа автоматизированных скриптов для деплоинга чего-то там (всякого разного) использовала рецепт, начинающийся с git clone --submodules или как там это называется (сам я никогда субмодули не использовал, так что не помню).
В действительности так (по аналогичному принципу) живут вообще все "экосистемы". Так что то ли ещё будет.
Между прочим, git вообще-то система контроля версий, и это значит, что она хранит всю историю изменений и позволяет на любой срез откатиться. То есть если бы у всех людей в мире было хоть немножечко мозгов, ни к какой катастрофе действия обсуждаемого персонажа привести бы не могли. Вот такие штуки и показывают, как у публики в действительности туго с мозгами.
Серверные js-макаки
Такими темпами серверные js-макаки самоликвидируются собственными силами. А там, глядишь, и браузерные последуют примеру.
Гм... только мне
Гм... только мне кажется, что это один настоящий боевой джаваскриптный моральный урод разом нагнул целую толпу безмозглых джаваскриптных мартышек?
(а вот было бы здорово, если б они все там друг дружку перестреляли нахрен, а? насколько мир стал бы чище)
Организовать
>Организовать
>Организовать сплочённую группу революционно настроенных разработчиков.
Поменяйте на купить и все проблемы исчезнут
Ну да, все
Ну да, все исчезнут, останется одна: где взять столько денег.
Сохранить в
Сохранить в этом процессе здоровый разум
С этим будут проблемы. Лучше уж вечный двигатель изобретать, проще как-то.
Поганый GitHub'ик
Ещё одно подтверждение почему нельзя использовать GitHub.
В ответ на совершённые действия GitHub заблокировал доступ Марака к своим репозиториям (90 публичных + несколько приватных), а NPM откатил проблемную версию пакета. При этом законность действий GitHub вызывает вопросы, так как удаление разработчиком кода из одного из своих репозиториев не может рассматриваться как нарушение правил сервиса. Более того, в тексте лицензии на пакеты colors и faker явно обозначено отсутствие любых гарантий и обязательств в отношении работоспособности кода.
Кстати в одной статье встретил подход одного разработчика к командной работе идентичную вашей, но все равно использующей GitHub. Он предлагал использовать BitBucket, чтобы не портить репозиторий "на главном GitHub'овском" и не потерять код при отказе GitHub'а. :-P. Удивляюсь человеческому идиотизму, хотя он даже оказался умнее некоторых обезьянок ;)
Тут виноват не
Тут виноват не гитхабчик, а то, что некая организация этим гитхабчиком владеет и может по своему велению творить на нем что угодно.
Впрочем, Git - система распределенная, и перейти с гитхаба на что-нибудь другое несложно. Ну потеряются там всякие сугубо гитхабовские сведения о пулл-реквестах и заведенных задачах, история кода все равно же есть.
> Тут виноват не
> Тут виноват не гитхабчик, а то, что некая организация
Свято место пусто не бывает. Как только появляется сайт такого рода — появление того, кто на него наложит грязную лапу, становится вопросом времени.
> Git - система распределенная
Вы не поверите, сколько людей вообще не понимают, что с git'ом можно работать без всяких гитхабов и прочих гитлабов. Вот то есть не понимают, хоть ты тресни.
Если вас это удивляет, я вам тогда скажу, что эти ещё ничего. Есть такие люди, которые не понимают, что кнопочки на экране нарисованы и на самом деле ничего никуда не нажимается. Я реально таких людей видел. Правда, они всё-таки были не программисты :-)
Есть и те, кто
Есть и те, кто думают, что Линус Торвальдс создал GitHub
А ещё до сих пор
А ещё до сих пор существует, проводит исследования и пишет статьи International Flat Earth Research Society.
Если уж "можно"
Если уж "можно" верить в бога, и, мало того, верить в то, что этому богу для общения с людьми нужны посредники в виде всевозможных жрецов — то в плоскую землю тем более можно. По мне так этот вариант и по степени маразматичности, и по опасности для окружающих существенно мягче любой сколько-нибудь известной религии.
А есть и те, кто
А есть и те, кто считает, что мелкомягкие купили git
У меня, кстати,
У меня, кстати, есть слабая надежда, что другие js-макаки обидятся на гитхаб за такое поведение и тоже начнут гадить в своих репах.
И не только
И не только js-макаки. Есть же некоторое количество разработчиков (разной степени макаковости), которые планируют уйти с гитхаба (или уже ушли, но старый код там ещё лежит). Можно им подкинуть идею испортить перед уходом ту версию кода, которая лежит на гитхабе. Если такое явление приобретёт хоть какую-то массовость, то это может здорово насолить гитхабу.
Яндекс Практикум
Самостоятельно изучать программирование, не имея опыта в этом ранее и товарища, который подскажет, довольно не просто. Когда я впервые взял в руки книгу по изучению - это был ад. По причине того, что натыкался на термины и объяснения которых не понимал. Когда находил ответ на свой вопрос, то получал оплеуху, потому что мне не хватало знаний чтобы его понять. Такая неприятная рекурсия.
Книга Андрея Викторовича стала отличным способом погрузиться в мир программирования. В совокупности с задачником она станет прекрасным учебником. Вместе с тем, проблемы при изучении остаются. Не такие, которые помешают изучению, но замедлят его точно. Они зачастую неочевидны для тех, кто освоил профессию давно и у кого были наставники в свое время. Об этом можно много сказать, но не будем ) Часто возникают затруднения, связанные с освоением материала, задачей или нужен совет. И опыт получения обратной связи я получил, проходя бесплатную часть курса от яндекса. Сразу хочу закрыть тему и сказать, что курс не порекомендую никому - подача материала мне не понравилась, вебинары шлак, а заниматься в тренажере - это вообще боль. Дело в том, что нужно не результат правильный выдать, а написать код так же, как задумали его создатели тренажера. Речь о буквальном написании идентичного кода. Половину времени занимает подбор возможных вариантов записи чтобы удовлетворить желанию бездушной программы.
Но приятно удивила возможность задать вопрос в чат поддержки и сразу получить ответ. Работает этот сервис в любое время и быстро. Качество ответов посредственное, на той стороне не всегда внимательно читают вопрос, но это не страшно. Так вот я думаю, что для изучения учебника "Программирование: введение в профессию" идеально иметь помимо его самого, задачник, который ожидаем в ближайшее время и поддержку в виде чата с преподавателем. Пусть не круглосуточно, а хотя бы по вечерам или всю вторую половину дня и вечер без выходных.
Я хочу спросить мнения здесь, одному мне интересно платить за возможность получать оперативно ответы или вы тоже считаете организацию такой схемы хорошей идеей?
Можете писать
Можете писать мне :). У меня есть сайт http://bimzhanovt.net/ , а там мой email, пишите я только рад. Правда сайт пока сырой, но, что точно, что через некоторое время там появится контент.
Вот даже змейку можно забрать для изучения git clone git://git.bimzhanovt.net/quetzalcoatl.git :D, на паскале CRT, но она не коммитилась уже как месяц и явно годится для переделки (не судите строго).
Мне непонятна зачем вы заходили на эту помойку Яндекс Практикум, где ваши ответы даже не пытаются до конца читать. Интернет вам в помощь: гугл, книги, статьи, форумы и т.д., не ответили в одном месте, потролили: идете в другое место и т.д.
Могу посоветовать одного хорошего товарища, зовут его Unix. Используете его для всего, что может сделать компьютер, а он вам изо дня в день будет подавать задачки, что времени на решение всех задач уже не будет хватать. Задачник с таким другом вообще не нужен.
===
Кстати, Андрей Викторович работает ли у обычных юзеров форма контакта? По крайней мере я открыл O_o
Про формы
Про формы контактов -- вроде бы это настройками не запрещено, хотя можно и запретить
> Когда я
> Когда я впервые взял в руки книгу по изучению - это был ад. По причине того, что натыкался на термины и объяснения которых не понимал. Когда находил ответ на свой вопрос, то получал оплеуху, потому что мне не хватало знаний чтобы его понять.
А что, когда Вам кто-то начнет обьяснять термин "в живую", Вы его лучше поймете, чем тогда, если найдете на другом ресурсе в Интернете ответ? По-мне, так проще перелопатить Интернет, чтоб понять что-то, что не понятно. Лично я не вижу проблем с этим вообще.
> Часто возникают затруднения, связанные с освоением материала, задачей или нужен совет.
Интернет - полон советов! Серьезно!
> Качество ответов посредственное, на той стороне не всегда внимательно читают вопрос, но это не страшно.
А тогда какой смысл имеет наличие чата, в котором якобы можно получить ответ на свой вопрос, при этом зная, что качество ответов - так себе, и не факт, что на той стороне чата правильно вообще поняли Ваш вопрос?!
> Я хочу спросить мнения здесь, одному мне интересно платить за возможность получать оперативно ответы или вы тоже считаете организацию такой схемы хорошей идеей?
Лично я такое не считают нужным по двум причинам. 1) Интернет - полон ответов на самые разные вопросы что в печатном, что в видео формате. 2) Программирование - это та профессия, где навык поиска и нахождения нужной информации в Интернете имеет оргомную роль. Ну это - мое мнение. Потому по-мне лучше развивать в себе это уже заблаговременно, чем получать готовый ответ в чате, а когда надо будет самому найти что-то, появятся проблемы. Кроме того, такой регулярный поиск ответов может улучшить знания английского языка, что для программирования в частности и ИТ вообще - очень важно!
С интернетом
С интернетом есть одна проблема: вредных советов намного больше, чем полезных, а фильтровать умеют не все. Хотя, конечно, в целом оно так, да.
Для этого
Для этого вообще тут давным-давно предлагали xmpp-чатик сделать, но не срослось. А имхо, но он вот прям нужен.
Ну, сделать
Ну, сделать можно что угодно, но официальным такой чатик не будет, т.е. я не стану его рассматривать как что-то моё и вряд ли там буду появляться.
Из этого
Из этого вытекает закономерный вопрос, почему бы не сделать официальный чатик (у вас же вроде свой jabber-сервер?).
И не обязательно даже вручную его там модерировать, слава ботам.
А когда жить,
А когда жить, извините? Работа, книги, личный сайт, если к всему этому добавится чат - на личную жизнь времени не останется вообще, имхо.
Ну, в моем
Ну, в моем понимании, это должна была быть автономная структура
Автономную
Автономную структуру можно создать без моего участия и даже без моего разрешения. Все люди вольны создавать собственные информационные ресурсы. Ну а я — см. выше :-)
Да я бы даже
Да я бы даже создал, вы же мне тут не разрешите ее рекламировать, а другого способа собрать вашу аудиторию я не вижу.
Если это будет
Если это будет "комната" в xmpp, можете её анонсировать в гостевой, я анонс раскрою. Ну а придёт туда кто или не придёт — вопрос второй :)
Ну вот примерно
Ну вот примерно так, да :-) Точнее, в моём случае времени скорее не останется на работу, поскольку личную жизнь я всегда рассматривал как священную корову, не подлежащую "подселениям и уплотнениям" (tm). Но если отказываться от работы, надо как-то монетизировать то, что её вытеснило :-)
почему бы не
почему бы не сделать
И на этот вопрос есть закономерный ответ: потому что не хочу.
у вас же вроде свой jabber-сервер?
Как ни странно, нет. Другим ставил, себе так и не сподобился. А сейчас ещё и обнаружилось, что сколько-нибудь вменяемые реализации такового все discontinued, так что его и не на чем толком ставить.
Ощущение такое, что XMPP со всеми его расширениями и прочими примочками не выдержал собственного веса.
И не обязательно даже вручную его там модерировать, слава ботам.
В отличие от форумов на сайтах, чаты "модерации" не поддаются. А любая дискуссионная площадка, которую я считаю своей, должна быть на ПРЕмодерации, от любых других подходов я давно отказался.
У меня в своё
У меня в своё время не было никакого наставника. И книжки такой не было, как мы понимаем. И даже компьютера не было, приходилось где-то как-то добывать урывками машинное время. Мало того, тогда ещё и Интернета не было — во всяком случае, в нынешнем его понимании, со всеми этими сайтами, форумами, поисковиками и прочим. И ничего, как видим. Так что всё возможно.
По поводу платной "поддержки" в принципе идея может быть рассмотрена. До недавнего времени я старался отвечать на вопросы, которые мне задавали по email'у (в том числе через форму на сайте), но эту лавочку (во всяком случае, бесплатную) придётся прикрыть, поскольку с ростом популярности книжки растёт и трафик, а моё время не резиновое, на всё (и на всех) его, увы, не хватит. Альтернативой может послужить некий платный сервис, если, конечно, на него будут желающие в сколько-нибудь заметном количестве.
У меня в
У меня в какой-то момент появился Спектрум. С ним в комплекте была "книжка" -- тоненькая брошюрка с описанием встроенного бейсика.
А паскаль я изучал по публикациям в журнале "Наука и жизнь". И никакого доступа к компилятору не было, совсем. Ну, то есть, на одной из моих пиратских спектрумовских кассет был какой-то компилятор паскаля, но совсем какой-то несерьёзный. Так что программы на паскале я первое время писал в тетрадке. Только через пару лет, когда в моей школе обновили компьютерный класс, удалось наконец дорваться до Турбо-Паскаля.
Ну и да, с литературой в целом было трудно. Помню, как будучи с отцом в Москве проездом, зашли в книжный магазин. Смотрю, стоит на полке книжечка по языку Лого. А у меня на той же кассете был Лого, только что с ним делать было ну совершенно непонятно. А тут книжка. Счастью моему не было предела.
Вообще, конечно, всё это сильно напоминает известный текст Сергея Сечива, хорошо запомнившийся многим по фразе "пешком, через весь город, 5 километров в ледяную гору, зимой".
> платный
> платный сервис, если, конечно, на него будут желающие в сколько-нибудь заметном количестве.
Необязательно делать фиксированную цену, её можно например повышать понижать опираясь на уровень вашей загруженности или на спрос.
Но почему-то мне кажется, что сама возможность покупать помощь может вызвать негативные эмоции у некоторой части вашей аудитории.
Пусть вызывает
Пусть вызывает сколько хочет, тут дело не в том, что там какую вызывает реакцию, а исключительно в том, соответствует ли что-то моим собственным принципам. Как я уже неоднократно говорил, есть ровно две вещи, которые имеют право стоить денег: материальные объекты и время, потраченное по конкретному заказу конкретного заказчика. Так что здесь всё чисто, а если кому что не понравится, то это не мои проблемы.
Вопрос здесь исключительно в том, найдутся ли желающие платить деньги, де-факто, за возможность задавать вопросы по электронной почте и получать на них ответы. Конечно, если что-то такое будет, то это будет не только вопрос-ответ, скорее некий вариант заочного обучения по индивидуальному плану. Но дёшево это не будет совершенно точно, моё время — штука достаточно дорогая.
Парадигма консольных программ
Решил сравнить разные ассемблеры. Обнаружил вот такое различие:
nasm при успешной компиляции не выводит абсолютно ничего, как и ld, а fasm выводит свою версию, сколько он взял памяти, сколько проходов и какого размера получился файл.
Так вот, как вы думаете, а как правильнее? Предположим, вы сами бы писали компилятор, не важно, какого языка, как бы вы сделали?
Кроме того, это сообщение идёт на stdout, а не stderr. Куда правильнее сообщения вроде этого кидать, если это не сообщение об ошибке, по вашему?
Есть какие-то общие рекомендации, что кидать на stdout, а что на stderr? Где-то это очевидно, но бывает, что есть сомнения.
Правильнее --
Правильнее -- если программа не интерактивная, то не говорить ничего, пока об этом не попросили (или пока не "вынудили", сделав ошибку -- об ошибке нужно сообщать).
Что касается stderr, то тут всё одновременно и просто, и непросто. Штатную выдачу консольной программы пользователь может захотеть перенаправить куда-нибудь и там что-то с ней сделать, в том числе в автоматическом режиме. На stderr следует сыпать всё, что предназначено для самого пользователя, даже если он перенаправил вывод. В частности, все эти версии и прочее, о чём пользователь в явном виде не просил, кидать на stdout — это уже просто совсем моветон.
Разница между DOS и Linux
А это соглашения именно из UNIX или вообще для всех консольных программ?
Вроде бы fasm был изначально написан для DOS как заменитель TASM, поскольку автору что-то там в нем не нравилось и уже позже портирован на Windows, Linux, и libc. Кстати, а DOS stderr был?
Я поискал скриншоты TASM, оказалось, что он тоже выводил свою версию, количество памяти и проходов. А потом ещё turbo link писал, что он turbo link какой-то там версии.
Выхлоп ассемблеров и компоновщиков
как правильнее? Предположим, вы сами бы писали компилятор, не важно, какого языка, как бы вы сделали?
Кроме того, это сообщение идёт на stdout, а не stderr. Куда правильнее сообщения вроде этого кидать
Вы бы сравнили ещё "стандартный" для UNIX ассемблер as.
Имя выходного объектного файла "a.out" было тупо зашито в исходниках ещё тогда, когда у UNIX и названия не было.
А дескриптор 2 и его использование для диагностических сообщений постепенно стало стандартным в ходе эксплуатации и развития Шестого издания, судя по дошедшим до нас исходникам.
Ср., напр., 6.1 Standard I/O из двух разных редакций классической The UNIX Time-Sharing System:
более ранней ( https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf )
и более поздней ( https://www.bell-labs.com/usr/dmr/www/cacm.pdf ):
Programs executed by the shell, however, start off with three open files with file descriptors 0, 1, and 2. As such a program begins execution, file 1 is open for writing, and is best understood as the standard output f
ile. Except under circumstances indicated below, this file is the user’s terminal.
causes source to be assembled, with diagnostic output going to output;
В 5-м издании
perror()
это ещё простоprintf()
заготовленного сообщения об ошибке:https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s4/perror.c
В 6-м
perror()
уже выводит сообщение в #2https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s5/perror.c
MS-DOS stderr
https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSCALL.txt#...
https://github.com/FDOS/kernel/blob/master/kernel/main.c#L409
stdin, stdout, stderr, stdaux и stdprn были в MS-DOS 2.0 для удобства портирования программ, написанных на Си для XENIX и подобных систем.
Есть они и в "современных" клонах DOS.
Ага, а теперь
Ага, а теперь объясните публике, при чём тут MSDOS. Точнее, попытайтесь нам растолковать, какое отношение несколько глобальных переменных, описанных в стандартной библиотеке Си, приложенной к отдельно взятому компилятору, имеют к собственно этой "системе" (скорее недосистеме).
FASM
Автор написал FASM не для MSDOS, а в первую очередь для себя, для своих экспериментов с загрузчиками, прошивками и т.п.
Генерируемый бинарник не должен зависеть от особенностей используемого парсера командной строки, других компоновщиков ассемблеров и прочих утилит. Основной способ управления генерацией - директивы в исходниках программы.
FASM версии x.yz, выполняющийся на разных платформах по одинаковым исходникам, должен в идеале выдавать идентичный бинарник. Байт-в-байт. Если же среда или платформа, на коиорой выполнялся FASM, повлияла на результат многопроходной компоновки, то программисту важно знать, удастся ли его разместить в выделенных секторах дискеты или микросхемах ПЗУ.
В MSDOS не было
В MSDOS не было аналога stderr, какие к ещё чёрту соглашения. Мне, честно говоря, не вполне понятно, зачем вспоминать эту, как бы это выразиться, и не платформу, и не систему, а недоразумение дебильное, которое к тому же скоро тридцать лет как окончательно вымерло.
Это даже не недоразумение =)
Про мелкомягкий DOS есть один прекрасный факт -- это продолжение купленной ими Наспех и Грязно сделанной Операционной Системы (Quick and Dirty Operating System) -- название как бы намекает, что создатели даже не пытались. =)
stdin/stdout
> В частности, все эти версии и прочее, о чём пользователь в явном виде не просил, кидать на stdout — это уже просто совсем моветон.
Ну для программ, которые кидают вывод на stdout, действительно смешивать полезную инфу со служебной — моветон.
Но fasm по умолчанию пишет данные в выходной файл. Так важно ли, куда он пихает служебную инфу об успешной компиляции?
Здесь важен
Здесь важен общий принцип, точнее даже сразу два: (1) не просили говорить — молчи и (2) если программа не интерактивная, то сообщения, предзназначенные человеку — в поток диагностики.
Ошибки и ошибки
А вот ещё я странную фигню обнаружил:
Segmentation fault просачивается каким-то образом на терминал даже после
&> /dev/null
. Если нужно его всё равно замаскировать, помогает взятие пайпа в круглые скобки и&>/dev/null
после них.Полагаю, что дело в том, что это сообщение выводит не сама программа, а что-то другое (ядро?) и оно не идёт в её дескрипторы, ни в 1, ни в 2.
> Штатную выдачу консольной программы пользователь может захотеть перенаправить куда-нибудь и там что-то с ней сделать, в том числе в автоматическом режиме.
Но ведь у fasm это как раз штатная выдача, раз он выдаёт её всегда. Хотя я согласен, что было бы правильнее её не выдавать пока юзер не попросит с помощью флага -v, --verbose или подобного. То есть получается что он всё-таки правильно делает, что выдаёт её на stdout?
С другой стороны. вряд ли конечно, но всё-таки юзер может захотеть бинарные данные выбросить на stdout для дальнейшей обработки, в этом случае сообщения о количестве проходов и тд будут мешать:
> В частности, все эти версии и прочее, о чём пользователь в явном виде не просил, кидать на stdout
Но ведь у компилятора стандартный вывод в штатной ситуации вообще не используется. Тогда логично как раз таки служебные сообщения компилятора отправлять всё-таки на stdout, так как именно их может понадобится фильтровать, в том числе сообщения об ошибках и проблемах в исходном коде (error и warning), а вот сообщения о проблемах именно самого компилятора — их уже на stderr, например, если не хватило памяти, файл с исходником не читается, файл с объектным кодом не пишется и... вроде всё.
Тогда и версию компилятора и прочую ерунду тоже можно отправить на stdout, если её вообще выводить, но лучше не выводить без ключика вроде -v. Может пользователь захочет многократно что-то компилировать и сравнивать время компиляции и будет как раз эту статистику использовать потом для обработки grep-ом, sed-ом и тд.
С другой стороны, если штатной выдачей компилятора считать всё-таки бинарник, то вполне возможно, что пользователь захочет отправить его на stdout для дальнейшей обработки, в таком случае правильнее вообще все сообщения пихать на stderr — и сообщения об ошибках и предупреждениях и сообщения об ошибках компилятора.
В общем, по-моему не всё так однозначно. Автор программы не всегда может предсказать, какую часть вывода программы пользователь захочешь перенаправить, а какую посмотреть.
-----
А вообще у меня такое ощущение, что при работе с консольной программой, можно сразу отличить, была она изначально написана под Unix-подобные ОС или была перенесена с DOS / Windows. Я думаю, вы пользовались консольной версией 7zip? Вот там видно, что она была изначально для Windows. Например при нормальной успешной распаковке на stdout всё равно сыплются сообщения.
-----
А как вы считаете, должны ли все (по крайней мере, новые) консольные программы стараться использовать соглашение GNU: короткие ключи должны быть с одним дефисом и одним символом, причём под одним дефисом можно объединять несколько ключей, длинные ключи под двумя дефисами, и слова разделяются одним дефисом (e.g. --ignore-whitespaces), а -- означает терминатор ключей и дефисы в последующих аргументах игнорируются?
Segmentation fault
Segmentation fault просачивается
Вообще-то можно было бы догадаться, что Segmentation fault выдаёт не та программа, которая свалилась (она уже всё, свалилась, сдохла, выдать она больше уже ничего не может), а запускавший её командный интерпретатор — по итогам анализа того, что там ему выдал wait.
Но ведь у компилятора стандартный вывод в штатной ситуации вообще не используется
Значит, он должен быть пустым.
Автор программы не всегда может предсказать, какую часть вывода программы пользователь захочешь перенаправить, а какую посмотреть.
А это и не требуется. Зато автор точно знает, подразумевал ли он сам возможность автоматизированной обработки выдаваемой информации.
соглашение GNU:
Этим "соглашениям" намного больше лет, чем самому GNU.
Лично я "длинные" ключи (которые с двумя дефисами), по-моему, не использовал ни в одной своей программе, во всяком случае не помню за собой такого. По-моему они неудобны.
А почему вот
А почему вот такой код не компилируется?
Получается, что фигурные скобки вокруг тела функции — это не то же самое, что в других местах?
Иными словами, выходит, это синтаксические омонимы, как end после begin и end после record в паскале или () в инфиксном выражении и () вокруг названия типа для каста.
Используется ли такая омонимия для чего-то или введена просто так? В частности, может ли что-то быть между закрывающей круглой скобкой и открывающей фигурной в декларации функции, кроме пробела?
А почему вот
А почему вот такой код не компилируется?
Потому что язык Си так устроен
Получается, что фигурные скобки вокруг тела функции — это не то же самое, что в других местах?
Как ни странно — ни фига. Есть в Си такое понятие — составной оператор, он же блок. Так вот телом сложного оператора (цикла или ветвления) может быть любой оператор, в том числе блок, ведь это тоже оператор; а телом функции можно быть только блок.
может ли что-то быть между закрывающей круглой скобкой и открывающей фигурной в декларации функции
Рекомендую погуглить, какой синтаксис всего этого безобразия был предложен изначально (так называемый K&R C). Между прочим, прекрасно поддерживается компиляторами до сих пор.
Если синтаксис K&R проигнорировать как артефакт доисторической эпохи, то в чистом Си вроде бы между заголовком и блоком ничего быть не должно. А вот в Си++ — сколько угодно.
Но омонимия с этими злосчастными скобками вообще-то присутствует, только не там, где вы её ожидаете. В операторе switch фигурные скобки обязательны и при этом они не являются блоком — там нельзя описывать локальные переменные.UPD: тут я оказался неправ, память иногда выделывает странные штуки.> там нельзя
> там нельзя описывать локальные переменные
У меня простыня ниже компилируется (с 2-мя предупреждениями) даже с флагами -ansi и -pedantic. Правда в case 1 переменная var будет содержать мусор, т.к. она объявлена, но до инициализации дело не дошло (из-за этого оба предупреждения). Или имелось ввиду что-то другое?
PS: А вот в описаниях структур и enum'ов эта омонимия точно есть :)
PSS: чертов HTML, угловые скобки даже внутри тега <pre> пропадают.
Да, вы правы.
Да, вы правы. Интересно, откуда я это взял.
По поводу структур и enum'ов — это ещё ладно, а вот в инициализаторах... :)
> Интересно,
> Интересно, откуда я это взял.
Возможно, это из-за того, что в switch нельзя объявлять переменные сразу после метки (вне зависимости от флагов компилятора) и если в блоке встретился хотя-бы один оператор (если использовать флаг -ansi).
gcc для var1 выдаёт такую диагностику:
на var не ругается, а вот на var2 выдаёт ошибку только с флагами -ansi -pedantic -pedantic-errors. Так что тут всё ещё интереснее :)
PS: извините за очередную простыню :D
Ну кстати это
Ну кстати это логично. Объявление переменной — это выделение памяти в секции .data
Каким образом вообще это может быть внутри условного выражения любого типа? Ну ладно, для функций локальные переменные объявлять можно на стеке, но ведь и они формируются один раз при вызове функции. Как можно их выделить или не выделить условно?
Объявление
Объявление переменной — это выделение памяти в секции .data
А вот и нет :-P
Как можно их выделить или не выделить условно?
Запросто.
В тех же switch'ах я часто ветки заключал в отдельные фигурные скобки исключительно с целью описания локальных переменных. Иной вопрос, что вот если этого не делать, то локальные переменные внутри switch'а, но без локализации во вложенных блоках выглядят довольно странно.
Кстати, настоятельно рекомендую разобраться с терминологией. Объявление и описание — совершенно разные вещи, лучше с ними не путаться.
локальные переменные в блоке
Что такое выражение возможно я понимаю, конечно. Вопрос в том как это работает?
Есть переменные в секции исполнимого файла (не обязательно .data), о них должно быть известно на этапе компиляции. Есть переменные в стеке, о них как я понимаю, тоже должно быть известно на этапе компиляции.
Вопрос — что в этом случае должен делать компилятор? Выделять место для a в любом случае, но вне блока выдавать ошибку при попытке доступа?
Локальные
Локальные переменные на то и локальные, что видны только внутри блока, в котором описаны. Вне блока при попытке к такой переменной обратиться будет ровно та же ошибка, что и при попытке обратиться к переменной, которая вообще нигде не введена.
Наиболее "лобовая" реализация переменных, локализованных в блоке — это при входе в блок смещать указатель стека, чтобы отвести место под локальные переменные этого блока, а при выходе — смещать его обратно. Но можно без таких "туда-сюда" обойтись, изначально выделив во фрейме подпрограммы достаточно места под любые варианты наборов локальных переменных, возникающих в сколь угодно глубоко вложенных блоках данной конкретной подпрограммы. Скажем, если в одной ветке if'а описана переменная типа int, а в другой — две переменные типа long long, то достаточно предусмотреть 16 байт, и их хватит и на ту ветку, и на другую.
Всё становится намного интереснее в Си++, где в картину могут вмешаться ещё вызовы конструкторов и деструкторов, но по-моему ваш вопрос не об этом :-)
> вызовы
> вызовы конструкторов и деструкторов
А как они могут повлиять на ситуацию? Насколько я понимаю, у объекта на протяжении всего времени жизни размер (поля самого объекта + поля предков + vmtp) не меняется.
Да нет, на
Да нет, на размер-то не повлияют. Просто безобидные с виду фигурные скобки благодаря конструкторам и деструкторам локальных объектов превращаются (потенциально) в целые простыни кода. И если при компиляции чистого Си я бы как минимум попытался обойтись без модификации [ER]SP на входе и выходе вложенного блока, то в программе, написанной на Си++, это может оказаться просто неактуально :-)
Чёрт,
Чёрт, процитировал комментарий, а то, что первое же слово в цитате является ключевым, не заметил. Спасибо за объяснения :)
PS: я сам некоторое время из-за опасений, что значение в esp/rsp будет "мотать туда-сюда" (особенно, в циклах) в программах на Си все переменные старался описывать в начале функций. Но потом стал догадываться, что мои опасения напрасны :)
Ага, теперь
Ага, теперь понятно. Мне просто никогда не приходило в голову написать что-то внутри switch, но раньше первой метки. А после меток да, начинается катавасия.
Стало
Стало интересно, откуда такое ограничение для switch-case-меток взялось и есть ли оно для goto-меток. Оказывается, после любых меток нельзя описывать переменные, причём вне зависимости от "стандарта". Видимо, варвары-стандартизаторы до этого момента не добрались.
> В тех же switch'ах я часто ветки заключал в отдельные фигурные скобки исключительно с целью описания локальных переменных
Один раз сделал то же самое, но скобки у вложенных блоков случайно оставил на том же уровне, что и закрывающая скобка у switch. Может, кстати, об этой проблеме 3-ем издании в $4.8.2 стоит упомянуть?
Размер стека
Вот вы писали, что
> после появления в Unix-системах легковесных процессов (тредов) на размер стека было наложено довольно жёсткое ограничение: 8 MB.
А что если моей программе требуется больше стека? Будет ли нормально взять системный вызов malloc и создать себе область памяти на гигабайт, скажем, а затем поместить её конец в esp?
На самом деле 8
На самом деле 8 MB хватит с головой, вон в MacOS X размер стека 512 KB. Судите сами, даже в большой программе будет не больше 10ти стековых фреймов, если пустить рекурсию на дерево высотой 20 (что уже дофига, 2^20-1~1'000'000) будет ну 30 максимум. Если не хватает, вы явно что-то неправильно делаете, всё.
UPD: как у вас malloc в системный вызов превратился :-) ?
malloc
Я просто не помню наизусть системные вызовы и привык что обычно они называются так же, как и аналогичные функции из C, поэтому и написал malloc, имея ввиду тот системный вызов, который просит у ядра дать программе новый регион памяти заданного размера. Видимо это должен быть mmap.
А их и не нужно
А их и не нужно помнить наизусть.
Вот здесь, например содержатся системные вызовы для ядра линукса версии 2.2 (их номера и параметры): https://montcs.bloomu.edu/Information/Linux/linux-system-calls.html
Или можно скачать исходные тексты ядра. Я скачал версию 2.2, оно достаточно маленькое (~150'000 строк), тогда не было 64-битных процессоров, что облегчает работу.
Пожалуй glibc тоже будет хорошим вариантом.
---
brk оказался совсем прост: вся его работа это установка конца сегмента данных своему аргументу. Т.е. вернуть можно. Главное запомнить конец сегмента данных, а потом его скормить brk.
Полез в glibc. Там оказалась глобальная переменная __curbrk, инициализированная значением 0. Так ешё в библиотеках оказалась функция sbrk, она увеличивает сегмент данных на свой аргумент.
Если её использовать со значением 0, функция вернет адрес конца сегмента данных, но и здесь нет магии, возвращается значение находящееся в __curbrk.
Если использовать её с ненулевым значением она возвращает старое значение конца сегмента данных и использует brk для работы с кучей.
Обе можно и самому на асме да написать. Ещё как я понял придётся самому создавать таблицы свободной и занятой памяти и как-то хитро с ними работать.
---
Заголовок mmap меня, что-то пугает...
---
Кстати, какие спецификации по Unix'ам лучше читать. SUS и POSIX только мозги искалечат, нет?
А их и не нужно
А их и не нужно помнить наизусть.
Вот здесь, например содержатся системные вызовы для ядра линукса версии 2.2 (их номера и параметры): https://montcs.bloomu.edu/Information/Linux/linux-system-calls.html
Или можно скачать исходные тексты ядра.
Не уверен, конечно, насчёт линукса, но в системах, где маны поддерживаются в актуальном состоянии, список системных вызовов всегда можно получить элементарным
UPD: пардон, вы
UPD: пардон, вы про список системных вызовов, а я же давал информацию про то как попробовать системные вызовы на асме. Топикстартера ведь интересовала информация, как нужно выделять 1GB памяти под стек. Пусть разбирается с mmap следуя моим подсказкам :^)
Сейчас его,
Сейчас его, чувствую, плохому таки научат.
Ага, щас. Эти
Ага, щас. Эти системные вызовы у человека скорее всего будут для 64-битной ОС. А номера системных вызовов для 64-битной и 32-битной систем (асм в 1томе, ведь для 32-битной ОС, верно?) различаются (1), и в этих ваших манах не расписываются значения номеров (2) и констант (3) их-то ученику и придется для программирования на асме да раздобыть.
Номера системных вызовов я беру из ссылки выше, а константы grep'аю либо из /usr/include, либо из исходных текстов ядра версии 2.2.
Но man'ы конечно не помешают, как и исходники glibc (предпочтительнее, конечно версия постарее, так как она будет меньшего размера, чем более новые), чтобы понимать как эти системные вызовы работают (a), как их следовало бы реализовать самому (б).
Если у ученика не линукс (скажем BSD), процедура впринципе будет скорее всего такая же.
Читайте man :-)
Читайте man :-) Комитетские поделья слишком уверены в собственной непогрешимости, а в man'ах бывает даже сравнительный анализ разных спецификаций.
Если это будет
Если это будет BSD-система, то mmap, если Linux — то brk (но для вашей задачи увеличения стека brk не слишком подходит, как ни странно). Разница между malloc и теми системными вызовами, через которые она реализована — это, я бы сказал, штука фундаментальная, настоятельно рекомендую разобраться. Это тот самый случай, когда игнорировать детали недопустимо.
Память
Я так понимаю, что разница в том, что malloc/free хранят список свободных и занятых регионов памяти и если свободных достаточно, то системный вызов не совершается, а память выделяется из уже использованной и потом освобождённой. А системный вызов позволяет только взять регион памяти, но не позволяет его отдать.
Если не brk, то какой? У меня всё-таки линукс.
Ну почти
Я так понимаю, что разница в том, что malloc/free хранят список свободных и занятых регионов памяти и если свободных достаточно, то системный вызов не совершается, а память выделяется из уже использованной и потом освобождённой.
Есть ещё такой момент, что malloc у системы память запрашивает сразу большими блоками. Это чтобы сэкономить на системных вызовах, они зело дорогие. И блоки эти кратны страницам, потому что система по-другому не умеет.
А системный вызов позволяет только взять регион памяти, но не позволяет его отдать.
Очень даже позволяет. Во всяком случае, mmap точно позволяет, спецификацию brk не помню на эту тему, но, кажется, тоже позволяет. Вот только free никогда память системе не возвращает — только помечает как свободную, и всё. Это тоже стоит учитывать. Если какую-то большую область памяти хочется выделить, но потом себе не оставлять — иногда есть самый прямой смысл использовать mmap.
Если не brk, то какой? У меня всё-таки линукс.
mmap, больше никаких нет. Просто в BSD-системах brk извели под корень, там только mmap и остался, а в линуксе они оба по-прежнему есть и активно используются.
Иной вопрос, что в контексте нашего обсуждения (как подменить стек, чтоб он стал побольше) правильный ответ — «никакой», причём вне зависимости от используемой системы.
Просто в
Просто в BSD-системах brk извели под корень, там только mmap и остался
В OpenBSD есть brk(2). Правда, не знаю, насколько активно он тут используется, но, по крайней мере, присутствует.
а что покажет
а что покажет truss, если его натравить на программу, активно работающую с динамической памятью?
вдогонку
Собственно, OpenBSD'шный код malloc вот тут: https://cvsweb.openbsd.org/src/lib/libc/stdlib/malloc.c?rev=1.272&conten...
И, насколько я вижу, вызовов brk (в отличие от mmap) там действительно нет. В какой степени это отвечает на вопрос об "изведении под корень brk"?
Вполне
Вполне отвечает. brk в BSD-системах почему-то сильно не в почёте.
Дык нету такой
Дык нету такой утилиты в OpenBSD. Не говоря уже о том, что я, честно говоря, ненастоящий
сварщиксистемный программист. Но если разобъясните, то готов попробовать, самому интересно.ktrace(1) подойдёт?
на программу, активно работающую с динамической памятью?
Это, например, какая? Может просто чучелко изобразить, которое будет malloc -> sleep -> free делать в цикле?
ktrace не
ktrace не пробовал, не знаю. Про чучелко -- такое не будет к системе обращаться, зачем ему, оно будет одну и ту же (от системы давно полученную) память помечать как занятую, потом снова как свободную. Хотя если то же самое, но без free и без sleep :-) -- ну то есть тупо malloc в цикле -- то да, подойдёт.
И блоки эти
И блоки эти кратны страницам, потому что система по-другому не умеет.
Разве нельзя некратными странице (4 kB) размерами спрашивать? Вроде позволяет.
А в конце стоит отдавать всю запрошенную память с помощью brk или система сама справится?
Разве нельзя
Разве нельзя некратными странице
mmap не позволяет, про brk не помню
А в конце стоит отдавать всю запрошенную память
зачем?! чтобы лишний раз прыгнуть в ядро и обратно? Тут просто нужно чуть-чуть здравого смысла: а куда денется память, если при окончании процесса система её не вернёт себе?
(ну хотя... увы, объекты ядра, порождаемые процессами, но остающиеся в ядре, если их не грохнуть в явном виде, таки существуют, чёрт бы побрал тех, кто придумал System V IPC; но это вроде единственное исключение из общего правила, и крайне мерзкое).
Вы уверены?
> mmap не позволяет, про brk не помню.
По меньшей мере на Linux 5.9 mmap позволяет просить блоки некратного размера.
Сейчас сложно в
Сейчас сложно в чём-то быть уверенным, к сожалению. Но вообще все спецификации mmap, которые я видел, упоминают системный вызов getpagesize и/или значение sysconf(_SC_PAGESIZE).
Господи, ну
Господи, ну malloc-то зачем? Вы же не собираетесь потом этот кусок памяти возвращать в кучу? Тот самый случай, когда правильнее вызвать напрямую mmap, если уж совсем припёрло. А ещё нужно будет озаботиться, чтобы та функция, в которой вы всё это непотребство провернули, никогда не пошла дальше и никогда не вернула управление.
Хотя правильнее тут скорее провести с самим собой сеанс психотерапии. Ну, например, ответить самому себе на вопросы, а почему не хватает стека? а почему 8MB не хватает, а 1GB точно хватит? а не жирно ли 1GB? а по каким таким причинам тянет на всё большое, может причина не в программах? и, может быть, компенсировать собственные комплексы как-то по-другому, ну там купить себе джип побольше и пострашнее?
Если серьёзно, то не должно такого быть, чтобы стека не хватило. Если его не хватает — вы просто делаете что-то не то.
Non-ASCII в документации
А как вы думаете, насколько приемлемо использование не-ASCII символов в документации? Причём, так как документация, которую я видел, была на английском языке, эти символы использовались только для рисования таблиц с красивыми рамочками. Думаю, что даже если бы они отобразились кракозябрами, таблицы остались бы читаемыми, но у меня без всякой настройки сразу отобразились именно рамочки.
Документация
Документация — это текст на естественном языке. Не вижу проблем, документация вообще не обязана быть просто текстом, она может быть в другом формате. Хотя, конечно, те же RFC обходятся чистым текстом и алфавитом ASCII, и это правильно.
Целевая аудитория
Доброго времени суток.
Как я понял, Ваши книги предназначаены для правильного формирования мышления и действительно нужным навыкам true-программиста. А есть ли какие-либо рекомендации тем, кто программистом быть не собирается, но по работе требуют знания SQL или питон? Они вряд ли хотят тратить своё время на Паскаль, ассемблер, итд по списку.
Думая и т.д.
Думая и т.д. можно закончить на изучении Си и устройства ОС. Получается не очень-то и долго: 1-1.5 года плотного изучения при наличии желания.
А "непрограммисту" Си++ с лиспами и не нужен. На выходе он/она сможет SQL и Python за 2 вечера с документацией и узучить.
Что-то я
Что-то я сомневаюсь, что человек, потративший полтора года на плотное изучение программирования, захочет остановиться.
SQL
SQL — это не язык программирования, это язык запросов.
Изначально он предназначался не для программистов, а для пользователей базы данных. Если требуется прямо отличное его знание с пониманием нюансов разных СУБД — это странно.
А Python — ну если его требуют, значит им требуется программист всё-таки, верно? А тогда и образование должно быть соответствующее.
И ещё вопрос какой уровень знания Python вообще требуется. Если просто прочитать готовые скрипты и изредка что-то поправить — это одно, а если прямо писать новый код на этом языке — другое.
Вспоминается
Вспоминается байка про секретарш, работавших в доисторические времена в какой-то околоайтишной конторе, а может в учебном заведении. Так вот, эти секретарши испытывали священный трепет при слове "программирование", но при этом набирали текст в емаксе (ну а чо, времена были такие) и пописывали скрипты на е-лиспе для автоматизации своей работы.
Язык запросов, говорите?
А знаете, что бывает, когда "почтипрограммист" хватается за SQL?
В оригинальном тексте это ещё было завёрнуто в строковый литерал на втором уровне вложенности в perl-скрипте, так что добавьте мысленно, во-первых, две табуляции в начало каждой строки, и во-вторых то, что сверху и снизу (на перле). К сожалению, я целиком скрипт не видел, только этот фрагмент. Человек, который это цитировал (насколько я понимаю, как раз вполне программист), собственно говоря, показал сей запрос, чтобы объяснить, почему они там всё никак не могут отразить в коде маааааахонькое изменение правил подсчёта этого вот пресловутого score. "Попробуйте сами там что-нибудь поменять и не сломать".
Я это к тому, что программирование надо изучать всерьёз — или не трогать совсем. А SQL — это тоже программирование, только намного хуже.
SQL — это тоже
SQL — это тоже программирование
Андрей Викторович, а почему Путон -- это скриптинг, а SQL -- программирование?
Во-первых, если
Во-первых, если бы питон использовался только для скриптинга, я бы не был таким противником питона. Проблема именно в том, что на этом откровенно скриптовом (и интерпретируемом) языке очень часто пишут отнюдь не скрипты.
Во-вторых, SQL, конечно, не программирование. Я же говорю — "хуже". Можно даже сказать так: если запросы на SQL превратить в программирование, как это часто делают (и как это сделано в примере выше), получается полная хрень. Скрипты, впрочем, тоже программы, только маленькие. А скриптинг — ну да, тоже программирование, только хуже.
Вообще и питон, и перл, и даже SQL иллюстрируют одно и то же: когда недопрограммисты пытаются решать программистские задачи и для этого хватаются за инструменты, которые якобы проще в освоении и не требуют становиться программистом, то результат получается опасный для окружающих.
И, кстати, в интернете сайтов всяких дофига, чего обязательно сюда-то припираться?
на этом
на этом откровенно скриптовом (и интерпретируемом) языке очень часто пишут отнюдь не скрипты
Если пишут, значит им так удобно? И конечный пользователь разницы не замечает. Главное же получать удовольствие от процесса, ведь всех нас объединяет любовь к компухтерам.
Заметка
Заметка майнтейнера Portage и вообще поддержки Python в дистрибутиве Gentoo: The future of Python build systems and Gentoo.
Небольшая цитата из заметки:
Unfortunately, this is all happening without much of a concern for backwards compatibility or feature parity. The Python developers are focused on building their own packaging infrastructure and have no interest in providing a single good workflow for distribution packagers. It is really unfortunate given that many of them rely on our work to build the environments they use to work.
Интересная
Интересная картинка оттуда, не одни мы не любим стандарты :^)
https://imgs.xkcd.com/comics/standards.png
Как раз эта
Как раз эта картинка скорее не про стандарты. И лично я глубоко убеждён, что 15 конкурирующих
стандартовспецификаций — это лучше чем 14, поскольку их вообще чем больше, тем лучше.Питонисты на
Питонисты на лапах разносят заразу.
Питониста увидев, уволь его сразу.
В "уволь" всего
В "уволь" всего два слога, а в ритмический рисунок тут лучше ложится слово из трёх слогов, например "задуши", "пристрели", "утопи", ну и так далее.
Да как бы
Да как бы уголовный кодекс не велит. Не так чтоб лично я был прям такой законопослушный, но эти персонажи, если их обещать душить, топить и стрелять, будут чувствовать себя под защитой УК, а это довольно серьёзная крыша :-)
А вот уволить обычно проблем не составляет.
Макакинг, бессмысленный и беспощадный
Если пишут, значит им так удобно?
Ну да. Манкикодерам главное, чтобы было удобно им. То, что их поделка оказывается по факту неюзабельной, это их не интересует. Пропаганда питона - признак слабоумия.
конечный пользователь разницы не замечает
Это при том, что питоноподелка несовместима между своими версиями) Я уже молчу про то, что она может быть вообше не установлена в системе.
Мда
Я эту вещь объяснял своему однокласснику в третьем классе, когда он получил двойку по русскому.
Есть простая и понятная концепция человеко-часов. Нельзя для экономии получеловекочаса создателя тратить человекогоды потребителей. Это и есть причина, почему существует вообще в языках правила, почему писать всегда сложнее, чем читать.
Если посчитать, сколько времени пользователей потратили "программисты" на Питоне, то это тянет на натуральный геноцид.
Кража времени пользователей
Если посчитать, сколько времени пользователей потратили "программисты" на Питоне, то это тянет на натуральный геноцид.
Создатели systemd в этом плане догнали и перегнали питоняш.
Если пишут,
Если пишут, значит им так удобно?
Разумеется, ничего не знать, ничего не уметь, но при этом всерьёз мнить себя программистом — это удобно.
И конечный пользователь разницы не замечает.
Это тебе, макака позорная, кто такую чушь сказал? В действительности любая зависимость времени исполнения — откровенное хамство в отношении не только конечных пользователей, но и майнтейнеров. А уж зависимость программы от всей экосистемы этого вонючего питона — это за гранью добра и зла; всех питонистов, считающих возможным свои недопрограммы кому бы то ни было передавать, следует лишить права профессиональной деятельности в области IT, причём пожизненно. Вред, который вся эта недоученная мразота наносит цивилизации, я даже затрудняюсь оценить, но это, пожалуй, ещё хуже, чем всякие форточки и прочая проприетарщина.
Главное же получать удовольствие от процесса
А давай я тебя пристрелю? Не представляешь, какое я от этого получу удовольствие.
ведь всех нас объединяет
Лично меня с питономакаками не объединяет ничего. Вообще. И вон с моего сайта, мразь.
С обезьянами
С обезьянами общатся просто бесмысслено общатся, такое ощущение будто в черепной коробке ничего и нет, все аргументы заходят в одно ухо, а выходят из другого. Остаётся только отстреливать, что греха таить.
Сколько же пришлось с этими поделками провозится, то ей версия выше нужна, то новая библиотека выпустилась, а самое смешное, что они первые за эти контейнеры схватились и объявили это своим "наше все".
Системное ПО на языке с GC (docker), это как будто первоапрельская штука, а ведь реально существует и не сон!
Docker
Системное ПО на языке с GC (docker), это как будто первоапрельская штука, а ведь реально существует и не сон!
На этом Goвне в последнее время стало появляться что-то слишком много "софта". PHP-макаки активно мигрируют на этот, т.н. "стек" со всеми вытекающмими, как говорится.
А docker этот - это вообще лакмусовая бумажка состояния "современной" IT-"индустрии".
На этом Goвне в
На этом Goвне в последнее время стало появляться что-то слишком много "софта".
Вообще говоря, если те, кто пишут "софт" на том же, например, Python, перейдут на Go, то я, как пользователь и майнтейнер этого "софта", буду только рад. Как язык мне Go совершенно не нравится, сам я на нём писать не буду и другим не посоветую. Но вот изначально заданное в Go'шной инфраструктуре стремление к минимуму зависимостей у откомпилированной программы совершенно правильное.
PS. Ну а сама идея доскера и подобного -- это, конечно, позор индустрии, на каком бы языке оно не было написано.
Данная
Данная конкретная обезьяна на моём сайте больше ничего не напишет, естественно. Просто захотелось, как ни странно, продемонстрировать образчик мышления этих мерзких недоучек. Конечные пользователи у него, видите ли, разницы не замечают.
Если от вас
Если от вас требуеют знание какой-то непрофильной технологии, подразумевается, что она настолько проста, что вы ее поймете за пару вечеров с документацией. Если же вы нуждаетесь в том, чтобы вас такой технологии обучали, то либо вам стоит бросить работу, поскольку от вас требуют слишком много, либо заняться прокачкой мозгов, поскольку вы не в состоянии освоить простую технологию.
Конечно, есть:
Конечно, есть: немедленно сменить работу. И свой мозг целее будет, и окружающему миру вреда не нанесёте.
Длинные команды
У меня есть этюд, который написан так, что правильно отрабатывает на небольших числах, но на больших вываливается.
Для того, чтобы узнать, сколько чисел текущая версия программы может обработать (и оценить сработала ли оптимизация кода), я использую шелл-скрипт. Предположим, на миллионе программа заведомо вываливается, а на одном числе заведомо работает:
Вопрос. Вот вы говорите, что больше 80 символов в одну строку лепить нельзя, а эта команда длиной чуть более 100 символов.
При этом, лично меня эта команда устраивает. Да, терминал её переносит на вторую строку, но это не мешает мне её читать и редактировать. Но всё-таки, а как бы вы решили такую задачу, какой командой и что бы с ней сделали, чтобы она влезла в 80 символов?
Да, запятая в условии while — формально не очень хорошо, но изначально было две пары двойных скобок, а так можно обойтись одной и сократить длину команды без особого ущерба понятности.
А вы хранение
А вы хранение ЭТОГО готовы доверить файлу .bash_history? А не стрёмно? А ну как потеряется, не задолбаетесь воспроизводить?
Если же хранить, как положено, в файле, то получается
И это я ещё не начал ваши нагромождения выражений расписывать по-человечески.
Файл даже скриптом объявлять не обязательно и бит x навешивать, достаточно его "втянуть" через точку:
А теперь как это должно выглядеть на самом деле:
NB: пока я вашу гениальную команду не превратил мысленно вот в это, до меня не доходило, как она вообще должна работать. Так что не обольщайтесь, такие заклинания нечитаемы. Вообще, совсем нечитаемы. И отнюдь не только из-за выхода за 80-ю колонку, хотя это тоже свою лепту вносит.
Файл даже
Файл даже скриптом объявлять не обязательно и бит x навешивать, достаточно его "втянуть" через точку:
Данный конкретный "скрипт", раз уж он всё равно в отдельном файлике, лучше всё же, наверное, запускать через sh (ну или там bash):
Для этого тоже не нужно объявлять его скриптом и навешивать бит выполнения.
Вот если такому недоделанному псевдо-скрипту нужен доступ к кишкам (например, к неэкспортированным переменным) вызывающего шелла, тогда придётся втягивать через точку, да.
Да пофиг,
Да пофиг, допустимо и то и то, надо только помнить про разницу между ними. Например, набор функций и alias'ов нужно именно "втягивать" (хотя этого вашего "доступа к кишкам" при этом вроде не надо), или если хочется, чтобы задействованные в псевдоскрипте переменные остались в доступе. С другой стороны, если получилось достаточно развесисто и хочется, наоборот, среду исполнения ЭТОГО хотя бы чуть-чуть изолировать — то да, sh вполне правилен. Но тогда уже даже я, несмотря на свои вредные советы, сделал бы нормальный скрипт :-)
Скрипты
> А ну как потеряется, не задолбаетесь воспроизводить?
Да вроде нет, я просто написал эту штуку как только она понадобилась за две минуты примерно. Вспоминать имя файла я наверное буду не намного меньше времени.
Да и скрипт придётся писать параметрический, например ./foo надо будет заменить на "$1", и конкретные начальные значения a и b тоже надо задавать через командную строку. Да и именно seq я не всегда использую. Параметрический скрипт уже требует больше усилий, чем одноразовая команда, делающая то же самое.
Не факт, что написать скрипт один раз окажется лучше чем каждый раз набирать эту команду с нуля.
Хотя может и оформлю в скрипт... потом как-нибудь.
Вот что за бред
Вот что за бред я только что прочитал?!
Вспоминать имя файла я наверное буду не намного меньше времени.
Это означает, что у вас бардак в файловой системе.
Да и скрипт
А вы это не рассматривайте как скрипт, считайте это просто текстовым файлом, в котором записана команда, чтобы её не забыть.
придётся писать параметрический
"Придётся"? Мне всегда в таких случаях хочется спросить: "а не то — что?"
./foo надо будет
Кому "надо"? Вот вам лично — надо? По-моему прямо сейчас — не надо, а потом всегда успеете, файлик на полэкрана поправить несложно. В смысле, вот когда понадобится, тогда и сделаете.
Не факт, что написать скрипт один раз
А вы не пишите скрипт. Пишите ту же самую одноразовую команду, просто сделайте это не в командной строке (что неудобно, блинский фиг, ну неудобно же!!!), а в текстовом редакторе.
окажется лучше чем каждый раз набирать эту команду с нуля.
Вообще-то её и в командной строке можно записать в несколько строчек, делать one-liner никто не заставляет, а обратный слэш перед enter'ом никто не отменял (хотя он тут в большинстве случаев не нужен, shell умный, незаконченные конструкции он сам предложит закончить). Иной вопрос, что в редакторе это делать заведомо и многократно удобнее.
Вообще, тут можно сказать совершенно определённо: если вы считаете, что сочинить зверский нечитаемый oneliner, пользуясь для этого только возможностями Readline, по каким бы то ни было причинам и в какой бы то ни было ситуации может быть проще, быстрее или в каком-либо ещё смысле лучше, нежели записать тот же набор команд в текстовом редакторе — то вы заблуждаетесь. Точка.
Вообще-то её и в
Вообще-то её и в командной строке можно записать в несколько строчек, делать one-liner никто не заставляет
Можно же даже проще, нажать C-X C-E откроется $EDITOR, после этого файл по желанию сохранить. Часто бывает удобно, чтобы переделывать скрипты из интернета.
А вы это не
А вы это не рассматривайте как скрипт, считайте это просто текстовым файлом, в котором записана команда, чтобы её не забыть.
Кому "надо"? Вот вам лично — надо? По-моему прямо сейчас — не надо, а потом всегда успеете, файлик на полэкрана поправить несложно. В смысле, вот когда понадобится, тогда и сделаете.
А вы не пишите скрипт. Пишите ту же самую одноразовую команду, просто сделайте это не в командной строке (что неудобно, блинский фиг, ну неудобно же!!!), а в текстовом редакторе.
Кстати, спасибо!
Я тоже пишу длинные one-liner'ы и храню их в истории команд, что действительно далеко не всегда удобно. И у меня тоже есть эта установка, что "если уж писать скрипт, то надо оформлять его нормально".
Ваши слова помогают взглянуть на проблему под другим углом и немного "расслабиться" что ли. Заведу, пожалуй, прямо сейчас директорию ~/scripts и буду туда скидывать такие файлики (а для нормально оформленных скриптов и прочих выполнимых файлов у меня есть ~/bin, который добавлен в PATH).
Между прочим,
Между прочим, можно всякие такие заклинания, которые иначе были бы ванлайнерами, раскидать по нескольким файлам (ну там по областям применения сгруппировать), не создавая под каждый из них отдельный файл. Для этого удобны шелл-функции вроде вот такой:
У меня толпа таких функций живёт в ~/.bash_profile :-) Ну, типа, где alias'а не хватает из-за отсутствия у него параметров, можно вот такое вот задействовать. Потом файлик "всосать" в текущий shell с помощью всё той же точки, и названия функций будут даже автодополняться, что тоже не так чтоб неважно.
Когда я пишу на
Когда я пишу на паскале, read и write спокойно читают и пишут переменные любого типа, в частности Byte, Integer, LongInt, Int64 и тд.
Но в языке C нужно дублировать размер типа данных в вызове printf/scanf в форматной строке и в описании переменной.
Но в форматной строке я вижу для целых только %d и производные %ld, %lld и так далее. Но в C кроме обычных char, short, int, long и long long ещё есть специальные типы из stdint.h, имеющие фиксированный размер и наоборот переменный размер, например int64_t и uintptr_t. С одной стороны, для многих задач это удобнее, например если вы парсите файл или сетевой протокол. С другой, эти типы получается невозможно нормально напечатать через printf или я чего-то не знаю?
Ну точнее, можно макросы препроцессора применить какие-нибудь, но это всё выглядит громоздко и сложно и некрасиво по сравнению с паскалем в аналогичной ситуации.
Слушайте, как
Слушайте, как это вообще можно сравнивать? В Паскале write забит ржавыми гвоздями в ядро языка (это там даже вообще не процедура, оно компилируется в последовательность вызовов процедур для печати конкретных типов), тогда как в Си в самом языке вообще нет ввода-вывода, так что printf не знает (ну не может знать, это же не джава какая-нибудь с рефлексией во всю ивановскую), какой тип ей подсунули и что с ним делать. Приходится ей рассказывать.
Ну а stdint.h — это, как и всякий комитетский бастард, сущность дебильная, рушащая концептуальную целостность Си.
stdint.h
> Приходится ей рассказывать.
Это-то как раз всё понятно, хотя gcc вон ругается, если применить не тот тип в форматной строке. Я просто хотел сказать, что по этой причине простые программы с вводом-выводом на паскале приятнее писать чем на C, если не требуется лезть в дебри системы.
> Ну а stdint.h — это, как и всякий комитетский бастард, сущность дебильная, рушащая концептуальную целостность Си.
Предлагаете каждый раз писать какие-нибудь хитрые макросы, если нужен фиксированный тип данных? Например разбор файлов известных форматов.
Ещё могут быть нужны типы данных вроде целого, которое занимает 4 байта на 32-битной системе и 8 байт на 64-битной.
Так что, писать макросы или всё-таки подключать stdint.h допустимо?
в идеале конечно в языке должно быть столько же форматных спецификаторов, сколько и типов данных.
Предлагаете
Предлагаете каждый раз писать какие-нибудь хитрые макросы,
Зачем хитрые макросы, просто ввести те же typedef'ы в соответствии с потребностями решаемой задачи. А когда потребуется перенос на другие платформы, добавить #ifdef'ы. Собственно, stdint.h именно это и делает, только он никак не сообразуется с потребностями задачи.
Ещё могут быть нужны типы данных вроде целого, которое занимает 4 байта на 32-битной системе и 8 байт на 64-битной.
Он есть и называется
long
. Если найдёте компилятор, на которомlong
ведёт себя как-то иначе — расскажите мне.или всё-таки подключать stdint.h допустимо?
Смотря с какой точки зрения "допустимо".
в идеале конечно в языке должно быть столько же форматных спецификаторов, сколько и типов данных.
В языке, ещё раз подчёркиваю, нет и не может быть (и не должно быть) ни одного форматного спецификатора. Что до библиотечных функций форматированного вывода, то в них как раз столько спецификаторов, чтобы поддержать все типы данных, какие ЕСТЬ в языке. Те типы (точнее, typedef'ы), которые вводятся в stdint.h, в язык не входят.
Макросы
> Он есть и называется long. Если найдёте компилятор, на котором long ведёт себя как-то иначе — расскажите мне.
Тогда нужно в файл вставить что-то вроде:
assert(sizeof(long)==sizeof(void*));
Подобная штука, которая бы вычислялась при компиляции и прерывала её, если что-то не сходится, в Си есть?
> чтобы поддержать все типы данных, какие ЕСТЬ в языке
А вот со 128-битными целыми не работает. Как объявить такую переменную я нашел, но присвоить ей значение напрямую не выходит, приходится это делать умножением двух чисел, которые влезают в int64, вывести на stdout тоже не получается за один раз, приходится городить конструкцию из двух или даже трёх спецификаторов, чтобы вывести по кусочкам.
В общем, я хотел сказать, что если городить макросы для переименования типов, то придётся ещё делать парные макросы для форматных строки. Терминологию подобрал неудачно, да.
Тогда нужно в
Тогда нужно в файл вставить что-то вроде:
Нет, не нужно. На всех существующих компиляторах разрядности типа long достаточно для преобразования в него адресов без потери информации. Не уподобляйтесь комитетским моральным уродам и не пытайтесь поддержать "то, чего нет, но вдруг появится". Когда появится — поддержите.
Подобная штука, которая бы вычислялась при компиляции и прерывала её, если что-то не сходится, в Си есть?
Нет и не надо. В библиотеках — есть, но это совершенно другое.
А вот со 128-битными целыми не работает.
Вы что, издеваетесь или реально не понимаете разницы? Никаких 128-битных в Си нет, никогда не было и я очень надеюсь, что никогда не будет. Если вы где-то нашли библиотеку, которая что-то подобное позволяет делать, то все вопросы — к авторам этой библиотеки.
что если городить макросы для переименования типов
Вынужден повторить ещё раз: макросы тут ни при чём от слова совсем. И такой вещи, как "переименование типа", в Си нет. Есть директива typedef, которая не имеет отношения ни к макросам, ни к ПЕРЕименованиям.
придётся ещё делать парные макросы
Это только в случае, если задача такого требует (далеко не во всякой задаче число, извлечённое, например, из бинарного файла, нужно непременно печатать), и только при условии, что введённое вами имя типа совпадает с каким-то встроенным. Выглядеть результат в любом случае будет чёрт знает как.
В реальных задачах обычно можно из общих соображений прикинуть, какова будет разрядность нужного числа — точнее, какого из встроенных целых хватит для его размещения. Соответственно преобразовать, чтобы компилятор с ума не сходил, и печатать. Придуманная вами проблема высосана из пальца.
Есть, но не надо
>> Подобная штука, которая бы вычислялась при компиляции и прерывала её, если что-то не сходится, в Си есть?
> Нет и не надо. В библиотеках — есть, но это совершенно другое.
Вообще-то есть трюк (это же Си!) для "сильных духом":
static char assert_long_size_is_pointer_size[sizeof(long) == sizeof(void *)];
128 бит
> На всех существующих компиляторах разрядности типа long достаточно для преобразования в него адресов без потери информации.
Мне требуется, чтобы было точно равно, не больше и не меньше. Кроме того, у MSVC таки long даже на 64-битной платформе 32 бита. Конечно можно сказать "просто не используйте этот компилятор", но по-моему лучше, чтобы компиляция сразу падала с ошибкой, что сразу подскажет тому кто возьмётся за MSVC, что это была плохая идея, чем чтобы программа молча давала неправильные результаты.
> Никаких 128-битных в Си нет, никогда не было и я очень надеюсь, что никогда не будет.
Вот эксперимент по использованию 128-битных целых. Судя по всему, каким-то образом это работает, хотя литерал такой длины не компилируется и приходится формировать число в два этапа. Кстати это компилируется и в gcc и в clang, хотя в последнем нужно небольшое исправление.
> Нет и не надо. В библиотеках — есть, но это совершенно другое.
Так библиотечная возможность по идее на этапе компиляции не должна работать?
Вам реально 16
Вам реально 16 байтные целые нужны? Может ещё и на килобайт тоже? А что вдруг кому-то захочется нужно же непременно ввести.
При виде 128 битного целого, создателя этой штуки захотелось изолировать от общества.
Вы не уяснили самую главную прелесть Си. Си нужно рассматривать как высокоуровневый ассемблер, это его уникальное свойство, за которое мы его так любим.
Где вы 128 битное целое видели, под капотом у железа?
Конечно ваш пассаж про то, что printf является частью языка дал понять, что книга в вас толком и не влезла, не рано ли за Си взялись?
В принципе они
В принципе они и на килобайт бывают, реализаций длинной арифметики имеется в достатке, в том числе и для чистого Си. Но вообще если такое потребовалось — в большинстве случаев это значит, что используются средства решения, не адекватные поставленной задаче.
И что? Вы ещё
И что? Вы ещё скажите, что в Си есть вложенные функции (ну а что, gcc же допускает). А MSVC вообще не Си, он не умеет чистый Си, только C++.
Мне вот что интересно, вы вообще что сказать хотите? Или вы тут просто решили байты посотрясать вхолостую? Ну так пойдите ещё где-нибудь посотрясайте, у меня есть более интересные занятия.
Благодарность
Андрей Викторович, спасибо Вам за ваши изумительные книги!
(просто +1 к числу благодарных читателей)
Пытаться или не пытаться, вот в чем вопрос...
Доброго времени суток. В этом учебном году сдаю ЕГЭ. Лет так с 13-14 хотел на ФИИТ МГУ, но, видя проходные баллы, понимаю: задача поступления весьма сложна. Даже пробники ЕГЭ: математика - 87б., информатика - 100б., русский язык - 60б. не особо внушают уверенность. Прекрасно понимаю, что в родном Новосибирске пройду на бюджет любого НГТУ и ему подобного что называется, со свистом. Хотел бы узнать ваше мнение, стоит ли оно того - пытаться пройти на данный факультет, может быть год - два подряд, каждый раз пересдавая ЕГЭ, или расслабиться и сосредоточиться на самообразовании? Недавно закончил изучать ваше "Введение в профессию" и чувствую, что самообразование - штука весьма прикольная и гораздо более интересная, чем выслушивание преподавателя в УЗ
Тут вопрос, что
Тут вопрос, что вы теряете от попытки. Вроде подаваться одновременно в разные места никто не запрещает.
Хотя, конечно, на ФИИТ поступать не надо, поступайте на основное отделение, и потом постарайтесь не попасть на первый поток — там из вас обезьяну делать будут.
Тем не менее
Тем не менее обезьяну из вас сделать попытаются в любом случае на старших курсах ВМК.
Нам уже второй год семья Березиных читает курс по .NET. На третьем курсе они нас учили рисовать окошки и программировать мышкой под Windows Presentation Foundation.
Сейчас (на 4-м курсе) мы программируем в браузере на JavaScript. При этом в кажом семестре для зачёта нужно сдать 3-5 домашних заданий.
Самое удивительное, что зам.декана по учебной работе пытается выдать этот курс как преимущество своей кафедры и при этом в самом деле считает, что ВМК готовит <<научную элиту>>, а не <<быдлокодеров>> (как он сам выразился).
А им никто не
А им никто не пробовал говорить, что изучать микрософтовские "технологии" бесполезно? Даже если забить на всё СПО и то что оно не работает под линуксом и BSD.
Вот представьте что вы учились на 4-м курсе лет 10 назад и изучали там Silverlight. Изучили, достигли мастерства, знаете каждый класс и метод, написали помимо лабораторок несколько полезных/интересных приложений.
А если вы учились 5 лет назад и была там разработка под Windows Phone — новую "перспективную" мобильную платформу от самой великой Microsoft?
Вот сейчас вы изучаете WPF, а сможетеле ли вы через 5-10 лет хотя бы просто запустить программу на этой фигне на актуальной на тот момент версии Windows? Далеко не факт.
А вот программы, написанные на C даже 30 лет назад до сих пор работают.
Написанное на Turbo Pascal 25 лет назад — думаю под FPC скомпилируется без проблем.
Я сам играл в игрушку, исходники которой последний раз изменяли в 2000 году или около того — скомпилировалась и запустилась. Правда пришлось ещё пропатчить пару файлов, чтобы разрешение экрана добавить для игры в полноэкранном режиме.
Слушайте, ну
Слушайте, ну что вы тут как вчера на свет родились? Разумеется, "пробовали". Больше того, вы предисловия к моему первому тому видели? Вот эти люди тоже видели, смею вас заверить. Прочитали или нет — вопрос второй. Но "краткое содержание" заведомо известно всему факультету.
11 лет назад я пытался объяснить, по какой причине нельзя переводить первый курс на Си. Я не услышал ни одного возражения по существу. Вообще. Никто даже не попытался ничего возразить на мои аргументы. И кончилось всё примерно так, как я и говорил. И они, тем не менее, продолжают на этом пресловутом первом потоке уродовать мозги первокурсникам.
Понимаете, это так не работает. Чтобы остановить очередной маразм, совершенно никак не достаточно привести аргументы. Их просто проигнорируют.
Во-первых,
Во-первых, кафедру надо выбирать :-) Между прочим, вы удивитесь, если узнаете, какое количество ваших однокурсников считает, что лучше уж изучать JavaScript, чем Лисп и Пролог; так что тут каждому своё.
Во-вторых, на старших курсах намного тяжелее превратить человека в обезьяну. На первом курсе это делается лёгким щелчком пальцев, увы.
Чет мне
Чет мне кажется, что легче поступить на около-программисткую специальность. Прикладная математика, например. И математике худо-бедно научат, и программирование не сильно трогают.
Прикладная математика
Прикладная математика, например. И математике худо-бедно научат, и программирование не сильно трогают.
Не знаю как сейчас, но в начале нулевых "Прикладная математика" считалась одной из лучших специальностей. Инженерные специальности по сравнению с ней вообще не котировались ) Математике там можно обучиться очень даже качественно (при наличии инициативы со стороны обучающегося, естественно). Плюс к этому, эта специальность даёт реально широкий кругозор. Инженерные же специальности - это что-то среднее между образованием университета и техникума (колледжа).
Не знал,
Не знал, спасибо.
Я вообще почему на нее внимание обратил -- там написано "математика" и проходные баллы сильно поменьше чем на распиаренную прикладную математику и информатику
Вполне вариант.
Вполне вариант. Ну то есть если моё мнение интересует, то я скажу, что наилучший вариант — либо просто математика, либо какая-то из естественных наук, физика там, химия, астрономия, да хоть биология (только учтите, мышку лабораторную там прирезать таки придётся минимум один раз). Мозги на выходе будут наиболее прокачаны именно после естественнонаучного факультета.
Но вот если рассматривать как вариант специальность инженерную (любую), то тогда уж лучше "программистская", не так противно будет.
Добрый день.
Является ли побочным эффектом передача var-параметра в процедуру?
Ну например, мы поработали с переменной в главной части программы, потом передаем эту переменную как var-параметр в процедуру, в процедуре мы делаем множество вещей с этим параметром, в том числе и: write, read и т.д. Потом после этого мы используем этот var-параметр в главной части. Будет ли считаться такое действия за побочный эффект?
Попробую
Попробую объяснить.
Побочные эффекты - контринтуитивны. От фукнции или выражения мы ожидаем, что оно вычислится и всего."Побочный" в "побочном эффекте" означает, что кроме вычислений производятся "побочные эффекты" прямо как от лекарств, вы думали, что эта волшебная таблетка вас вылечит от гриппа, а через час оказывается, что у вас на нее аллергия и вас уже везут в ближайшую больницу из-за анафилактического шока.
То есть вас буквально обманули! Читая свой код, можно этого не замечать, мы-то обычно знаем свой код наизусть, правда если он ещё свежий, а вот с чужим всё плохо. Допустим вы взяли какую-нибудь либу, применили оттуда функцию, а оказалось, что она возвращает указатель выделенной ей памяти, и вы не зная об этом начали применять её везде где только можно, в заголовках условных выражений, циклов, в качестве параметра для процедур, а в итоге оказывается что у вас утекает память. Часто попадаются такое и программистов, которые это писали хочется поставить к стенке за лишнее время проведенное за отладкой, в особых случаях пристрелить.
А все модифицирующие действия следует вынести из функций в процедуры. Оттуда за ними легче следить. Но только модифицирующие, вычислени нужно с удвольствием отправлять в функции, так у них расширяются границы применения.
Ведь мы знаем, что процедуры не имеют побочных эффектов по умолчанию, их модифицирующие действия, это и есть цель для их создания. Как если бы вы специально пробовали вызвать у себя анафилактический шок... Здесь нет непредсказуемостей.
К тому же есть приём когда фунции с побочными эффектами изолируются в отдельную процедуру, чтобы об их "фирменных эффектах" можно было забыть.
Прекрасный пример это ReadKey из модуля CRT. На странице 371, 1 тома показано как её изолировали в процедуру GetKey. GetKey в разы удобнее пользоваться нежели ReadKey, ведь при использовании ReadKey каждый раз при желании обработать пользовательский ввод мы должны помнить, что она может вернуть доп. код и её обязательно нужно вызвать второй раз.
Посмотрите на замечательный кусок кода key := ReadKey, прогуливаясь по коду можно даже не заметить, что здесь символы изымаются из потока ввода, ведь здесь переменной присваивается значение, мы ожидаем только присваивание, а на выходе из буфера изчезла клавиша.
Бывают побочные эффекты в вызовах подпрограмм. Возьмем абстрактную в воздухе подпрограмму f(f1(x), f2(x, y), f3(x, y, z)), и каждая из f1, f2, f3 имеют побочные эффекты, одна добустим изменяем x, и печатает его значение, другая тоже пытается изменить x, у третьей тоже есть свои приколы. Вопрос в каком порядке исполняться побочные эффекты? Измениться ли поведение если включить оптимизации? Хорошо пусть порядок вычислений прямой, теперь попробуйте разгадать в этом случае поведение программы. Хорошо если на это уйдет минут 15.
Вот почему.
Короче говоря функции следует рассматривать, только как функции в математическом смысле (с некоторыми исключениями), а для всего остального есть процедуры.
Передача не является побочным эффектом
Дополню ответ Андрея Викторовича:
Сама по себе передача по ссылке (var) не является побочным эффектом, даже если вы используете такую передачу не в процедуре, а в функции. Побочным эффектом являлось бы, например, изменение внутри функции параметра переданного по ссылке, но никак не сама передача.
Поясню на примере: довольно часто по ссылке передаются массивы или структуры -- при этом они могут передаваться в функции. Делается это для экономии времени на копирование, ведь в случае сложных данных оно может занимать очень много времени. Итак, скажем, передаём нуль-терминированный массив по ссылке в функцию, считающую его длину -- в таком случае эта функция не будет иметь побочного эффекта, ведь она не изменяет массив, а только просматривает его.
А вот если бы функция принимала по ссылке числовую переменную и считывала в неё ввод, возвращая показатель успешности считывания (часто подобным образом устроены функции в Си) -- она бы уже имела побочный эффект, но совсем не по причине передачи переменной по ссылке, но по причине изменения этой переменной и изменения состояния ввода (считали его очередной кусок).
Надеюсь теперь стало понятней. =)
"Побочным
"Побочным эффектом являлось бы, например, изменение внутри функции параметра переданного по ссылке, но никак не сама передача."
Это касается только функции или процедуры это тоже касается?
Что, читать не
Что, читать не умеем? Пойдите ещё куда-нибудь, в интернете очень много разных сайтов.
To aversey: ну, что я говорил?
Правильно говорили =)
И правда, понятнее не стало...
/dev/null, я же начинаю свой ответ с того, что "дополню ответ Андрея Викторовича". Дальше я продолжаю -- "... не является побочным эффектом, даже если ... не в процедуре".
Давайте попробуем сказать, что все действия, изменяющие состояние программы являются побочными эффектами. Теперь задумаемся что это для нас значит -- например, мы хотим сказать, что побочные эффекты в программе не стоит использовать -- но что мы видим? -- эффект присваивания состоит только из побочного эффекта! То есть в программе не должно быть присваиваний? Более того, процедура не может ничего возвращать, весь её эффект так же выражается в побочных эффектах в таком определении.
Итого -- такое определение побочных эффектов сразу же уводит нас в функциональное программирование, в том определении, что все функции математические, объекты неизменяемы, а программа сама по себе так же является математической функцией.
Но как в таком случае делать ввод-вывод и взаимодействовать с внешним миром? Есть два известных мне ответа -- первый: сузить всё взаимодействие с внешним миром до заранее заданного ввода программы (а это в большей части случаев дорого, неэффективно и неудобно или даже невозможно); а второй -- построить модель в духе Хаскеля, где взаимодействия накапливаются (по факту этого может не происходить, но логически устроено всё именно так), например в монаде, что бы затем быть применёнными к реальному миру. Монады же -- буквально -- штуки в которые можно оборачивать значения, и имея функцию из типа А в тип Б обернутый в монаду (А -> М Б), можно взять значение типа А в монаде (М А) и получить Б в монаде (т.е. определена функция: М А -> (А -> М Б) -> М Б) -- монада таким образом играет роль контекста, то есть состояния программы -- в итоге мы вновь имеем своего рода императивное программирование, пускай формально и выраженное в виде функционального!
Это я всё к чему -- прошлое определение побочных эффектов вырождается в противоречие самому себе (пускай и не формально) -- и если есть адекватное определение побочных эффектов, оно должно это учитывать. Вот мы и можем сформулировать, что конструкции, сутью своей работы ставящие изменение состояния являются вполне законными, и их эффект нисколько не побочный, а самый что ни на есть основной; а вот в случае, когда вычисляются выражения, и мы и так уже получаем результат в виде сконструированного значения -- разбираться с дополнительными эффектами бы не хотелось -- поэтому мы и называем их побочными. Ещё плюс такого определения -- оно хорошо работает в императивном программировании, где первое его просто отрицает.
В общем, я попробовал сформулировать и аргументировать тут позицию по побочным эффектам несколько иначе -- может так будет понятней.
Насколько я
Насколько я могу судить, этим понятнее не станет. Когда мозги подчистую разъедены пост-сишной терминологией (где реально побочный эффект и модифицирующее действие суть одно и то же, и теперь чуть менее чем вся публика уверена, что это всегда так), тут вообще сложно что-то сделать.
Проблема тут не в том, что человек в "передаче" пытается найти побочный эффект, а в том, что он пытается найти побочный эффект за пределами вычисления выражения, т.е. там, где кроме этого "эффекта" нет вообще ничего.
Повторяю для
Повторяю для особо непонятливых: побочный эффект по определению бывает только у арифметического выражения. У процедуры его быть не может. Вообще. В принципе. Никак. Любые действия процедуры — это просто действия, они не могут называться побочным эффектом, хоть она переменную присвой, хоть она атомную бомбу взорви.
Если мы в процедуру передаём переменную, то в документации к процедуре должно быть сказано, что конкретно она с этой переменной делает. Это действие никак принципиально не отличается от любого другого, в том числе от изменений в глобально доступных структурах данных, от ввода-вывода и т.п. В отличие от функций, процедура предназначена, чтобы выполнять модифицирующие действия, она больше ни для чего не нужна. Вы вообще понимаете смысл слова "побочный", вне зависимости от программистской лексики?
Добрый день,
Добрый день, Андрей Викторович! Я недавно установил Линукс и меня стали интересовать вопросы. Есть ли необходимость в антивирусе на Линуксе? На что способны вирусы в Линуксе? Сидев на Виндовс мне часто приходилось переустанавливать её именно из-за них.
Антивирус
Я считаю, что антивирус не нужен даже под Windows, не только под Linux. Работа антивируса в фоне очень сильно замедляет все операции с файлами, но при этом он всё равно не гарантирует отсутствие вирусов.
Вирусы под линукс теоретически существуют, но в дикой природе наблюдаются лишь в единичных случаях. Если соблюдать простые меры предосторожности, то вы с ними не столкнётесь. Если не соблюдать — скорее всего тоже нет, но гарантии я вам не дам.
Вирусы для линукса.
Теоретически что-то вроде вирусов для линукса существует.
Практически, я думаю, это реально подхватить, если выставить SSH на дефолтном порту со слабым паролем, особенно если разрешен логин от рута.
Ещё я слышал о случаях когда пользователи хватали что-то такое, устанавливая темы оформления с сомнительных сайтов, так как там содержались какие-то исполняемые скрипты.
В общем, простейшие правила информационной безопасности и можете не беспокоиться:
Если не нужен SSH — отключите демон sshd, если нужен, настройте авторизацию по ключу без пароля или установите сложный пароль. Не помешает перевесить на недефолтный порт, но не обязательно.
Программы старайтесь ставить только из репозитория своего дистрибутива. Если требуется поставить что-то, чего там нет, лучше всего собрать из исходников самому. Если где-то предлагают для установки запустить что-то вроде curl http://something | bash — не делайте этого.
Не выполняйте команды, которые вы увидели на каких-то сомнительных сайтах с инструкциями по линуксу, не изучив команду и каждый параметр командной строки (используйте команду man), правда тут более вероятно не намеренно вредное что-то, а просто написанное неграмотным пользователем, который не учитывает какие-то последствия команды.
С осторожностью копируйте команды с веб-страниц в терминал, а лучше вообще так не делайте и набирайте их вручную, даже если вы вроде понимаете эти команды.
Не всякое
Не всякое нарушение безопасности следует считать вирусом. Вирус — это термин, обозначающий программу, которая сама себя размножает. Советы про ssh и не выполнять что попало — это элементарные меры осторожности, которые нужно принимать вне зависимости от наличия или отсутствия вирусов как таковых.
качал вирусов
качал вирусов себе на линух.
Распаковал.
Поставил под root.
Не завелись. Два часа гуглил, оказалось, вместо /usr/local/bin вирусы стали в папку /usr/bin на которую у юзера malware нет прав на запись, поэтому вирус не может создать файл процесса. Нашел на китайском сайте патченый .configure и .make, пересобрал, переустановил.
Вирус заявил, что ему необходима библиотека cmalw-lib-2.0. Оказалось cmalw-lib-2.0 идет под CentOS, а под убунту ее не было. Гуглил два часа, нашел инструкцию как собрать .deb пакет либы из исходников. Собрал, поставил, вирус радостно запустился, пискнул в спикер и сделал core dump.
Час чтения syslog показал, что вирус думал, что у меня ext4 и вызывал ее api для шифрования диска. В btrfs это api deprecated поэтому линукс, заметив это непотребство, перевел раздел в рид-онли.
В сердцах открыл исходники вируса, grep'нул bitcoin кошелек, отправил туда $5 из жалости и пошел спать...
в папкуокошки
в папку
окошки это неизлечимый диагноз :)
Излечимый-излечимый
Излечимый-излечимый. Просто не сразу лечится.
У меня это
У меня это преинтереснейшим образом мутировало. Когда я сижу в терминале, для меня это директории. Когда я сижу в графическом файловом менеджере это папки.
Есть такое
Есть такое мнение, что формально folder — это как раз и есть элемент графического интерфейса, такое окно, в котором подписанные пиктограммы. Иной вопрос, что "папка" в этом смысле совершенно не обязана соответствовать объектам файловой системы на диске.
Но вообще с файловым менеджером стоит уже завязывать. Если он когда и нужен — разве что сортировать фотки (для этого даже я иконочное что-то запускаю, в последнее время обычно konqueror).
mc
> Но вообще с файловым менеджером стоит уже завязывать
Ох, в случае с midnight commander сложно согласиться, уж больно он удобный. Так быстро, как правильно вызванная команда cp он, конечно, кучу файлов не скопирует, но для мелочей им пользоваться самое то.
mc может быть
mc может быть полезен, по-моему, только в одном случае: разгрести файлопомойку. Если же таковую помойку не создавать и по чужим не лазать, то никакой реальной пользы от консольных файловых менеджеров нет.
Во времена DOS необходимость nc, vc, dn и прочих оправдывалось явной убогостью command.com. Помню, что попробовав тогда заменить command.com на что-то более приличное (кажется это был 4dos), я через непродолжительное время практически перестал запускать nc/vc/что-то ещё. Так что, к тому времени, как у меня появился первый линукс (а дело происходило на трёшке, поэтому я линукс в то время юзал без иксов, в голой консоли), привычки начинать сеанс работы с запуска клона nc у меня уже не было. Ну а никакой новой потребности запускать mc с тех пор так и не появлялось.
Ни фига он не
Ни фига он не удобный. Точнее, удобный, если сравнивать с папочно-иконочными удолбищами, но и только.
Вот смотрите, я с Linux работаю с 1994 года, mc тогда уже существовал, мне его показали сразу же (прямо вместе с Linux'ом), как им пользоваться — было очевидно, это же очередной клон Norton Commander'а, а эпоха MSDOS тогда ещё не кончилась, хотя и клонилась к закату, ну в общем Norton Commander тогда был прямо-таки "наше всё".
Так вот, для определённых задач я даже иконочками пользуюсь — точнее, ровно для одной задачи, фотки сортировать. А вот mc я не использовал никогда, хотя о его существовании всегда знал. Sapienti sat.
>Но вообще с
>Но вообще с файловым менеджером стоит уже завязывать
Он нужен, когда некоторые товарищи присылают директории и файлы с названиями на русском языке
Патология,
Патология, несомненно, тяжёлая, но я как-то всегда с этим в командной строке справлялся, в чём проблемы-то?
Честно?
Честно? Настраивать лень :)
Я попытался когда-то и бросил, у меня так и остались кракозябры и при вводе, и при выводе. Поставил графический файловый мендежер и графический текстовый редактор, настроенный на виндовую кодировку. Так что все, что мне присылают пользователи винды, там и открываю.
На каждую
На каждую хитрую кракозябру найдётся свой iconv; в некоторых особо запущенных случаях можно по количеству символов :-) А адекватно настроить кодировку в графической приблуде, по-моему, уж точно ничуть не проще, чем в терминале.
> ничуть не
> ничуть не проще, чем в терминале
Только узнал оказывается, что в моем xfce4-terminal в настройках есть опция encoding, буду этим пользоватся когда виндузянтики файл в cp???? пришлют
К сожалению,
К сожалению, всё не так просто. Если бы когда-то "улучшатели" и поборники "прогресса" не придумали локали, эта опция работала бы именно так, как вы от неё ожидаете. А вот в сочетании с локалями... э... ну, в общем, сами увидите.
*LOL* читаю и
*LOL* читаю и плАчу
Работая с Linux (в
Работая с Linux (в вообще, скажем так, с нормальными системами) с 1994 года, я ни разу не видел ничего даже отдалённо напоминающего вирус. Отказавшись от мелкомягких пародий на операционки, можете про вирусы забыть. И про антивирусы (которые не более чем развод на бабки) тоже.
Есть мнение,
Есть мнение, что вирусов под Linux нет потому, что он гораздо менее популярен на домашних PC, чем тот же Шиндовс
Вирусы
Есть мнение, что вирусов под Linux нет потому, что он гораздо менее популярен на домашних PC, чем тот же Шиндовс
Не только. Количество дистрибутивов, мягко говоря, немалое, а Шиндовс - один-единственный.
Мнение столь же
Мнение столь же хорошо известное, сколь и очевидно бредовое. Во-первых, программистов-любителей, имеющих хакерские склонности, под Linux намного больше, просто потому что с такими склонностями жить под Linux многократно приятнее. Во-вторых, я лично знаю людей, которые сейчас, может, уже остепенились, а лет пятнадцать-двадцать назад душу бы продали за то, чтобы стать "Первым, Кто" написал реально размножающийся вирус для Linux. И я этих людей знаю в достаточной степени, чтобы понимать, что если бы это было возможно — они бы это сделали, квалификации у них с запасом, чтобы и из компьютера, и из любой системы выжать всё, что вообще хоть как-то можно выжать. Смею заверить, сейчас такие люди тоже есть и их даже стало больше, просто я никого не знаю из хакеров следующего поколения. Остался бы в своё время в интернет-провайдинге — наверное, знал бы и этих.
Роутеры
Так есть же, есть. Размножаются они правда не на десктопах, а на сетевых роутерах, принтерах, камерах и тд, где в половине и более случаев из интернета можно зайти с дефолтным логином и паролем, если они вообще смотрят в интернет, а где нельзя, там можно зайти через дырявый проприетарный веб-интерфейс.
Можно ли это вирусом считать, не знаю, но таки роутеры почти все под линукс.
Кстати,
Кстати, интересно — ни разу не подхватывал такого, но у меня в хозяйстве "коробочные" роутеры крайне редко появляются, и если появляются, то всегда за NAT'ом (и пароль дефолтный я всегда меняю, естественно, будь оно хоть за десятью natами).
В принципе я слышал, что бывают под убунтой червяки — пользуются тем, что там sudo по умолчанию с ALL=ALL. Сам, опять же, ни разу не видел, но, опять-таки, у меня всегда первое действие после установки дебианоподобной системы — снести sudo к чертям.
Хотел узнать,
Хотел узнать, как обходиться без sudo в системе, но решил покопаться в архивах гостевой книги, и сам нашел ответ на свой вопрос:
http://stolyarov.info/guestbook/archive/2#comment-2037
Публикую это здесь, вдруг, кому-то тоже будет интересно узнать.
Спасибо вам, Андрей Викторович, за книги, сайт и видеоблог!
совсем не очевидные вещи
> http://stolyarov.info/guestbook/archive/2#comment-2037
Спасибо за ссылку. Я до таких дебрей ещё не добирался. Очень интересно и что самое важное -- полезно.
И, если честно, Андрей Викторович, эти вещи про IDE (комменты про IDE были выше обсуждения sudo), sudo и ИБ лично для меня, человека, который пришёл с форточек, не были ни капли не очевидны. Составлю для себя специально список "Как надо и как НЕ НАДО". Как говориться лучше поздно, чем никогда.
А вы, Андрей Викторович, обо всех этих методах ИБ узнали на собственном опыте или где-то когда-то откуда-то вычитали или вас кто-то этому научил/рассказал?
P.S. Мне, после того, как попробовал обычный текстовый редактор (это vim. emacs мне показался неудобным. может потому что просто к vim-у привык), возврвщяться к IDE и графическим редакторам текстов нет никакого желания.
P.P.S. Для создания/удаления и всяческого манипулирования пользователями так и напрашиваются bash-скрипты, аж руки чешутся.
вас кто-то
вас кто-то этому научил/рассказал?
О, с наставником в этой области мне просто несказанно повезло: это был SolarDiz; в самом конце прошлого века мы с ним работали в одной конторе. По правде говоря, у меня тупо не хватило мозгов воспринять всё, что он на меня готов был вывалить, но и так неплохо получилось.
возврвщяться к IDE и графическим редакторам текстов нет никакого желания.
Так и должно быть. Vim просто удобнее. Emacs, говорят, тоже, но у меня с ним что-то не заладились отношения.
Для создания/удаления и всяческого манипулирования пользователями так и напрашиваются bash-скрипты, аж руки чешутся.
Чтоб было куда стремиться, расскажу одну историю :-) В одном из филиалов МГУ надо было студентов обеспечить доступом к Unix-серверу, чтоб было на чём делать задания. Ну так я там поставил Linux, а для генерации учёток сваял скриптик, который и пользователей заводил (по заданному списку), и генерил LaTeX'овый документ, из которого получался PDF, чтобы печатать пользовательские карточки (с логинами, паролями и памяткой), которые потом раздавали студентам. Возможности командной строки неисчерпаемы :-)
> печатать
> печатать пользовательские карточки (с логинами, паролями и памяткой), которые потом раздавали студентам
Андрей Викторович, а разве можно сообщать пароли? Я вычитал в гостевой книге*, что это плохая практика
http://www.stolyarov.info/books/asm_unix#comment-968
> Разумеется, сообщать пароль рута нельзя никому, пароли вообще никогда никто и никому сообщать не должен. Вообще, понимаете? Никогда, никто, никому. Человек сам себе ставит пароли и никогда их никому не говорит
Конечно, нельзя
Конечно, нельзя сообщать пароли. Даже не вопрос. Когда кому-то предоставляется доступ по паролю, нужно подвинуть ему клавиатуру, сказать "набирай свой новый пароль" и демонстративно отвернуться.
А теперь представьте себе, как вы это делаете... э... что-то около двухсот раз подряд (если мне память не изменяет, карточек пришлось как раз столько напечатать), причём студенты же такие дисциплинированные, вы ж понимаете — к назначенному времени никто не придёт, будут ползти по одному с интервалом минут в 15, да ещё за время командировки (а дело было на выезде) хорошо если половина доползёт.
Но эта проблема была решена довольно просто: в памятке первым пунктом рассказывалось, как поменять пароль, и было сказано, что это должно быть первым действием после получения карточки.
вообще
вообще "покопаться в гостевой" можно при помощи гугла. в поисковой строке вбить site:stolyarov.info "что хочешь найти?"
Вот здесь ещё
Вот здесь ещё тред был про sudo: http://stolyarov.info/books/asm_unix#comment-937
Здравствуйте!
Здравствуйте! Андрей Викторович, а где грань между пропагандистом и не пропагандистом?
Ровно там же,
Ровно там же, где грань между обычной коммуникацией и информационным насилием: в наличии или отсутствии факта навязывания коммуникации. Скажем, книга или сайт сами по себе пропагандой быть не могут, а вот рекламные баннеры, ведущие на сайт, посвящённый некой политической, этической, философской и т.п. точке зрения — это, несомненно, пропаганда; точно так же когда сектанты на улицах раздают свои книженции — это тоже, несомненно, пропаганда (хотя сами по себе книженции и сам по себе сайт как таковой — нет).
А что, это всё не очевидно?
Например,
Например, блогер kamikadzedead называет себя пропагандистом, ставит себя на один уровень с телевизионными пропагандистами. Если вы на него подписаны в тюбике, значит не считаете его таковым? Поэтому и спросил, где грань, а то запутаться можно
Я не уверен, что
Я не уверен, что всё знаю про kamikadzedead и про то, как он в начале своей ютюбиковской деятельности раскручивал свой канал. Вообще почему-то мне кажется, что он свой канал нигде не рекламировал, тогда он, конечно, никакой не пропагандист. Тут есть одна нехорошая шероховатость — тюбиковская рекомендательная система, которая зрителям роликов подсовывает анонсы других роликов; с учётом этого можно считать всех, чьи ролики попадают в эти анонсы, таки да, пропагандистами.
А ещё есть такой момент, что на войне, как известно, убийцы перестают быть убийцами и превращаются в героических солдат. Оголтелая пропаганда, которую ведёт наше замечательное государство — это, собственно, информационная война против собственного народа, и считать ли тех, кто пропагандирует противоположные точки зрения, однозначно нехорошими редисками — вопрос дискуссионный. То есть тут не так всё однозначно. Например, вся предвыборная агитация (вся! без исключения!) — это совершенно очевидное информационное насилие, но я не стану требовать от оппозиции прекратить агитацию. Её можно прекращать только всю сразу, точно так же, как на войне можно заключить мир, но просто отказаться стрелять в одностороннем порядке и позволить себя убить — ну, такое себе.
А, да, ещё вообще-то совершенно пофигу, на кого я подписан на тюбике. На моей основной рабочей машине тюбик уже примерно год как не работает (и это едва ли не единственный сайт в мире, который на ней не работает, Гугл в этом плане впереди планеты всей), так что на youtube я уже давно не хожу. Вообще. Когда мне нужно посмотреть конкретное видео, я для этого использую Invidiou (см. https://solmu.org/pub/misc/invidio.html) либо youtube-dl, но ни там, ни там подписки никак не работают. Машина достаточной мощности, на которой вполне себе можно смотреть тюбик, у меня в хозяйстве есть, но она не основная (бралась когда-то под видеомонтаж) и за неё я сажусь довольно редко.
youtube-dlКстати,
youtube-dl
Кстати, если сейчас она у вас подводит с скоростью её можно поменять на форк yt-dlp (такая же питон поделка), youtube-dl'шики перестали обращать внимание на pull request'ы с замечаниями о замедлении скорости или как оно там на гитхабе называется.
Не могу понять почему runtime error 216.
В общем, решил я сделать самую первую задачку с односвязным списком. Она вроде как работает, но получаю такую штуку, перед этим была версии 3.0.0, там пришлось два раза CTRL+D, оно считывало 0, потом выдавало список в обратном порядке.Версию обновил, результат такой же
Результат:
2
5
6
7
8
0
8
7
6
5
2
Runtime error 216 at $0000000000401204
$0000000000401204
$00000000004012DA
$00000000004230BC
Исходный код:
Ещё вот так
Ещё вот так можно проверять булевские переменные:
Это легендарный индусский код, если что. Особенно последнее else впечатляет.
Да ладно...
Да ладно... честно говоря, в сравнении с тем, что делает в своём коде топикстартер — в качестве локальной переменной вводит параметр подпрограммы, а начальное значение ему задаёт при вызове (т.е. в коде вызывающего) — этот ваш индокод выглядит даже слегка прикольно :)
1. У вас какой-то
1. У вас какой-то супер странный стиль выбирать идентификаторы, читать сложно.
1) В паскале приняты идентификаторы, где слова набраны с заглавных букв алфавита и без знаков подчеркиваний. Например, first_element следовало бы переписать как FirstElement, а current_element, как CurrentElement. Из Print_All_Numbers_Backwards убрать знаки подчеркиваний, и стало бы PrintAllNumbersBackwards, хотя я бы выбрал другой идентификатор (скажем PrintNumbersInRev(erse)Order), но впринципе придираться не к чему. И дальше.
2) И допустим для вас нормально использовать стиль с подчеркиваниями, тогда почему бы тогда не сохранять единый для них стиль: не current_state, element_ptr и Print_All_Numbers_Backwards, а скажем Current_State, Element_Ptr, Print_All_Numbers_Backwards или всё в нижнем регистре сurrent_state, element_ptr и print_all_numbers_backwards.
current_state = true?
Хочу вас разочаровать, но можно сделать просто и элегантно if current_state then, ещё одна придирка возможно, что current_state здесь выглядит очень странно, может вы бы не стали бы сравнивать логическое выражение (!) (переменную current_state: boolean) с true если бы название было бы более подходящее.
19 строка: {не делать ничего}
Нет нельзя (категорический!) использовать символы не из ASCII в тексте программы, даже в комментариях.
Эм.., вы вообще рабочий код скинули?
74 second := nil;
75 begin
76 first := Read_And_Insert(first, second);
Про строку 76, я вот долго не мог понять, что она делает и пожалуй не стану дальше догадыватся, что вы хотели здесь сделать. Ужаснейшая функция здесь имеет побочный эффект (выделяет память), её нужно немедленно переписать в процедуру и кстати вам самому не кажется, что first передаётся и как параметр для функции (да блин, именно), так ещё и после этого ей, что-то ещё присваивают.
Мой вам скромный совет, вернитесь на эту страницу, только когда в тылу будет подчищено. То есть предыдущие части нужно бы с карандашом перечитать. У вас пробелы в самых базовых вещах.
Что, не
Что, не выдержали? Я вот тоже не удержался, в итоге два с лишним часа потратил на разбор этого шедевра. Надо было его так в очереди на премод и оставить.
Прямо даже и не знаю
Тут непонятно, с какого конца начинать комментировать. Ну то есть написан, конечно, совершенно махровый бред, но вас ведь это замечание не удовлетворит. Вообще, похоже, вы в глубине души уверены, что ошибка где-то не у вас, типа, я всё правильно делаю, а тут какая-то сволочь мне runtime error с непонятным номером. Ну так я вас сейчас разочарую.
Начну с самого главного: в процедуре Is_Your_Data_Correct самым грубейшим образом нарушена расстановка структурных отступов, причём нарушена так, что с первого совсем расфокусированного взгляда даже не видно, в чём косяк. Всё остальное можно как-то там объяснить недостатком понимания происходящего, отсутствием опыта и т.п., но когда оператор if (и вообще любой оператор) пишется с крайней левой позиции — это ничем, кроме абсолютной безалаберности, объяснить нельзя. Да плюс там ещё кириллица в тексте программы, комментарий написан по-русски; это уже вообще полный беспредел. Ну то есть здесь есть ровно два варианта: либо менять своё отношение к происходящему, либо бросать изучение программирования. Выбирайте, что больше нравится.
А ещё — зачем вон те вон begin и end в головной программе? Не те, которые обозначают начало и конец главной части, а те, что внутри, begin после присваиваний, end перед финальным end'ом. Они, конечно, ровно ничего не меняют в происходящем, но зачем они написаны? Чтобы читателя программы взбесить?
Далее по оформлению: вон директива {$I-} у вас стоит так, как будто она имеет отношение только к всё той же процедуре. А это не так, если бы её действие распространялось только на эту одну процедуру, от неё толку бы не было никакого, поскольку, чтобы перехватить обработку ошибок на себя, нужно, чтобы в режиме $I- был откомпилирован оператор read (а не последующая проверка). К счастью, директива-то действует на весь последующий текст, если только её не отменить (не написать {$I+}), так что операторы read у вас скомпилировались именно в том режиме, в каком надо, но вопрос здесь не в этом — вопрос в том, зачем вы её разместили внутри процедуры. "Чтоб никто не догадался"? Или как?
Чтобы завершить обсуждение этой (крайне странной) процедуры, задам ещё один риторический вопрос: а зачем нужен if с пустой (!) веткой then? Что, противоположное условие записать не справились? Ну так, на всякий случай, в Паскале есть операция "не равно", обозначается так: <>. Но если даже этого не знать, то есть ещё операция not, которая любое логическое выражение превращает в его противоположность.
Потом эти ваши идентификаторы. Есть такой стиль, при котором каждое слово пишут с большой буквы. Есть такой стиль, при котором слова отделяют друг от друга подчёркиванием. Но накой чёрт использовать оба механизма сразу? Чтобы читалось труднее?
Дальше вот имя переменной current_state — ну охренеть какое информативное. В голову тут может прийти что угодно, но только не то, что у вас там в действительности (чётность количества элементов, внесённых в список... ан нет, наоборот: НЕчётность). Самое интересное, что у вас ведь даже нет начального состояния, то есть вот "состояние" какое-то есть, и, значит, должен быть, наверное, какой-то конечный автомат, меняющий состояния, но с какого состояния он начинает работу — не определено. Кстати, это ваше "состояние" может так и остаться неопределённым, если пользователь попадётся вредный и не введёт ни одного числа, сразу нажмёт Ctrl-D. Или на ввод вам подаст файл из одних пробелов. Или вообще пустой. В вашей программе, впрочем, это "пофигу", поскольку тогда будет сугубо всё равно, какой из ваших first/second возвращать, они оба так и будут nil, вот только чтобы об этом догадаться, надо ещё посмотреть, как конкретно у вас эта ваша функция Read_And_Insert вызывается. Т.е. чтобы понять, как будет работать вызываемый, нужно знать устройство вызывающего. Декомпозиция такая декомпозиция.
Кстати, коль скоро обратили внимание на этот if, давайте посмотрим и на его заголовок. Что, очень трудно догадаться, что current_state = true есть всегда то же самое, что просто current_state? Ведь специально же в книге эта бредятина разобрана, см. параграф 2.2.9 (ближе к концу), и даже указана причина — неудачное имя логической переменной. Вот прямо ровно ваш случай. Понятно, конечно, что не вы первый, не вы последний, некоторых персонажей приходится пинать весь их первый курс, чтоб они так не делали, а кому-то не хватает и приходится продолжать их пинать на втором курсе. Потому и в книге на этом специально внимание акцентируется (и, кстати, сильно больше, чем в одном месте!) Но нет, куда там, нам же обязательно надо, чтоб нас в это ткнули.
Ну и, чтобы завершить обзор стилистических косяков: с какого бодуна у нас Read_And_Insert оформлена как функция? Что, нравится писать по-сишному с побочными эффектами? То есть вам нравится ровно то, с чем я всю книжку пытаюсь бороться (см. для начала параграф 2.3.6)? Может, тогда какую-нибудь другую книжку почитать?
Ах, да, и почему Read_And_Insert так называется? Ну, читать-то она, положим, читает, а куда она чего ВСТАВЛЯЕТ? Она там внутри себя вообще-то (по смыслу) строит список целиком, а не в какую-то уже готовую сущность что-то там "вставляет". Очередное "чтоб никто не догадался".
Теперь плавненько подбираемся к сути, но именно что плавненько. А вот скажите, зачем у этой вашей функции Read_And_Insert аж целых два параметра, если всё равно они оба всегда при её вызове равны nil, и иначе быть не может просто по смыслу? Такими вещами вы запутываете сами себя, и в данном случае, как это скоро станет ясно, запутали вы себя вполне успешно. А всё почему? А всё потому, что не задались вопросом "что делает Read_And_Insert". А это, между прочим, очень важный вопрос, и ответ на него должен состоять из одной простой фразы, и из этой фразы должно быть очевидно, зачем нужны все параметры. Функция эта у вас читает числа и формирует из них список; ради всего святого, накой чёрт для этого нужно — ещё прежде, чем начнём работу — знать адреса аж двух элементов такого списка?!!! Список ещё не сформирован, мы его формировать даже не начинали, а адреса двух его элементов нам вынь да положь? Это вообще как? Это вообще куда?
Теперь поглядим на ваш цикл чтения. Проверили SeekEof, убедились, что "там что-то ещё есть", то есть вроде бы есть что читать. После чего читаем сначала одно число, а потом сразу же другое без всяких проверок. А кто вам сказал, что там два числа есть? Может, там было только одно число и после него больше ничего?
Ну то есть вы числа читаете парами — и без вариантов, хотя сами себя (и читателя программы) тщательно пытаетесь убедить в противоположном. Даже ввели эту вашу current_state, и даже проверяете её. Вот только на выходе из цикла она ни при каких условиях не может оказаться истинной. Внутри цикла — некоторое время истинной остаётся, но потом неизбежно и неотвратимо ей снова присваивают false. Ах да, ещё она может оказаться неопределённой, если цикл ни разу не прокрутится (тот самый случай пустого файла). И в этом случае она совершенно случайно может оказаться истинной (но с тем же успехом может оказаться и ложной, это зависит от того, какой конкретно мусор лежал в стеке до того, как была вызвана ваша функция). А вот если в файле хоть что-то было, то ложь без вариантов. Так что для случая нечётного количества чисел ваша функция работать будет заведомо неправильно.
Самое интересное, что список-то она при этом сформирует. Чтобы понять, что это реально происходит и даже "почти правильно", мне потребовалось минут десять разбираться в вашем теле цикла. Первое впечатление было, что этот сумбур работать не может в принципе. Но нет, оказалось — может. Как-то там. Во всяком случае, в памяти выстраивается односвязный список, в конце таки да — nil, правда в первом элементе может быть ноль, не имеющий отношения к задаче (это если чисел было нечётное количество). Отсюда же, кстати, и необходимость второй раз давить Ctrl-D: первый конец файла у вас read "употребил", а чтобы SeekEof, наконец, false выдал, приходится ещё раз устроить Ctrl-D. Ну да ладно.
Давайте теперь посмотрим, что с этим списком будет происходить дальше. Для начала посмотрим на головную программу. В first будет адрес начала списка. В second так и останется nil вне всякой зависимости от того, что с одноимёнными переменными происходило внутри Read_And_Insert (это же совсем другие переменные, просто имена зачем-то одинаковые — наверное, чтоб читателя программы ещё и тут ввести в заблуждение; впрочем, "перехитрили"-то вы в итоге сами себя).
Ну и добираемся, наконец, до того места, где программа валится с runtime error. Это у нас процедура (спасибо, хоть не функция) Print_All_Numbers_Backwards. Правильный ответ на вопрос "что она делает" должен был бы, наверное, быть таким: "она распечатывает числа из списка". Ффффсё. Никаких "backwards", ведь числа она вообще-то печатает ровно в том порядке, в котором они расположены в списке. И — ещё важнее — для этого ну вот просто ни в какое место не упёрлись ДВА адреса элементов.
Лезем внутрь процедуры. И наблюдаем для начала интересную картину: параметр second вообще никак не используется. Вот вообще. Совсем. На первой же итерации цикла он получает значение, отличное от того, которое было передано, ДО того, как переданное значение будет хоть как-то использовано. Вопрос, зачем тогда передавать параметр (который к тому же взрывает мозг читателя программы вопросом, зачем он нужен).
Дальше — больше: элементы списка печатаются парами. Эй, а вдруг там нечётное количество элементов, тогда как? Впрочем, да, тут эффект чётной ошибки: функция, которая список строит, построить список из нечётного количества элементов не может в принципе. Но если её исправить так, чтобы она всё-таки работала правильно, а не как попало, то она, конечно, будет строить список из такого количества элеметов, сколько пользователь вколотил чисел. И тогда мы тут с этой "печатью парами" пролетим, как фанера над парижем.
Но падает-то она не поэтому. Падает она, потому что так сформулировано условие цикла. Цикл при таком условном выражении будет продолжаться, пока хотя бы один из двух указателей (этих вот first, second) не равен nil. А выйти из цикла программа, соответственно, должна при противоположном условии, то есть когда? Когда ОБА указателя СРАЗУ окажутся нулевыми. Ну так не успеет этого случиться, вот в чём проблема. Сначала получится так, что first уже нулевой, а second пока что нет. Вот тут она и трапнется. Это и есть ответ на вопрос, почему ваша программа вылетает с runtime error 216. Самое занятное, что ЭТО как раз исправить проще пареной репы: в условии оставить только проверку first, и дело сделано. Валиться она после этого перестанет.
А теперь оцените объём получившегося у меня текста, сравните с размером предыдущего абзаца, который отвечает на заданный вами вопрос "чего это она валится", и подумайте, станет ли ваша программа правильной, если вы заставите её больше не валиться. Я бы сказал, что из всего, чего вы тут навертели, вот эта вот мелкая ошибочка, формально приводящая к аварии — это прямо-таки мелочь, не заслуживающая внимания.
UPD: Ваша простыня под заголовком "Так лучше?" раскрыта не будет. Нет, так не лучше, бред как бред, местами, наоборот, хуже стало, причём сильно — вы, по ходу, читать не умеете. И вы уже злоупотребляете моим временем; всё, ваш лимит исчерпан.
А, надо было списком, ну тогда...
Кстати, не компилируйте эту программу с -O2 и выше, а то сломается.
Чур меня 8-()
Чур меня 8-()
Ну, что так делать не надо — это вроде и так понятно, да и списков тут никаких нет, мне вот другое интересно: что нужно сотворить с собственным мозгом, чтоб такие вещи в голову приходили. То есть как ОНО работает, я понимаю (ибо, в отличие от читателей паскалевской части, я-то знаю, как стековый фрейм устроен), но... эээ... из какой дремучей части ноосферы приходят такие идеи?
Заодно, кстати, век живи, век RTFM: я не знал, что в FP можно нетипизированные указатели вычитать.
UPD: насчёт отсутствия списков беру свои слова назад: тут в каждом стековом фрейме содержится указатель на реперную точку предыдущего фрейма (в роли реперной точки, конечно, не то, что обычно, а адрес параметра p, но суть та же). То есть тут выстроен прямо-таки честный односвязный список, только вместо записей -- фреймы.
Боже, только не мой мозг!
Хотите увидеть немного магии?
По-моему, такой вариант даже интереснее.
Да вам свой
Да вам свой задачник выпускать надо. Разумеется, с ответами :)
Что-то подобное
Что-то подобное я видел, но сейчас с ходу не смог вспомнить, как книжка называлась и кто автор. Точнее, автор вроде тот российский хакер, который в америку переехал и там расшибся при прыжке с парашютом, но и его фамилию я исхитрился забыть, и прямо сейчас нет времени искать.
Крис Касперски?
Автор скорее всего он. Довольно известный персонаж.
Но вот библиографию я посмотрел и ничего похожего на задачник не увидел.
Я совершенно не
Я совершенно не уверен, что это был именно он. Давно дело было, не помню, где видел, увы.
Наверное автор
Наверное автор Крис Касперски. Интересно, не находите ли сходства между вами и тем хакером? Неужели программистам так скучно жить чтобы для этого понадобилось прыгать с парашютом?
Точно, Крис Касперски
Насколько я помню, это псевдоним, но не суть.
Сходство у нас разве что в том, что я тоже прыгал, пока ногу не сломал. Программистам не "скучно" жить, программистам, знаете ли, тяжело жить. Мозги требуют проветривания. Прыжки в этом плане очень способствуют — на пару дней на аэродром заехать, раз десять за эти два дня сигануть, и рекреационный эффект, пожалуй, заметно сильнее, чем от двух недель на пляже. Да даже и от двух месяцев. Пляжный отдых на самом деле не шибко восстанавливает.
Ну а что разбиться можно насмерть, как это доблестно исполнил Крис Касперски — такая смерть уж точно лучше, чем от старости. Больше того, она заведомо лучше, чем смерть при многих других вариантах экстремальщины. Я вон сейчас активно по рекам сплавляюсь, там фаталити очень так себе (но тоже лучше, чем от старости). А при прыжке с парашютом в большинстве случаев человек и понять ничего не успевает.
Вы это...
Вы это... что-нибудь полезное делать не пробовали?
Должен, впрочем, сказать, что здесь я уже не понимаю, как это работает. Точнее, не смог понять без карандаша и бумаги, а за ними не пойду, смысла не вижу.
Карандаш и бумага
А зачем вам карандаш и бумага? Я при попытке разобраться в программах ими не пользуюсь и слабо представляю что там в принципе можно написать или нарисовать, что в этом могло бы помочь.
Мне кажется, что конкретно в этом случае они не помогли бы вам разобраться в этом коде. Логика тут довольно проста, но дело не в ней, а в особой уличной магии.
Конкретно
Конкретно здесь мне не хватило краткосрочной памяти, чтобы представить, куда какое смещение приводит. А в чём тут, собственно, магия?
Магия
Да что там сложного-то? Тут всего две строки с арифметикой указателей, которые изменяются на +1 и -1 и всё.
А магия в том, что программа очень простая, не содержащая никакой замудрённой логики, но понять как она работает вряд ли у кого-то получится. Ну а если всё-таки получится, то он поймёт, что я подразумеваю под магией в этой области, где казалось бы магии нет места.
> Да что там
> Да что там сложного-то?
Издеваетесь? :-)
UPD: Ну хорошо, признаю, вы таки взяли меня на слабо, так что пришлось взглянуть на текст внимательнее. Вот это вот
n := (pptruint(@n)+1)^;
заносит вn
численное значение сохранённого EBP, которое указывает на аналогичное место предыдущего стекового фрейма. Т.е. здесь вы не стали строить список из фреймов, воспользовавшись тем, что этот список уже построен в ходе создания самих фреймов при вызовахrecurse
. При вызовахuncurse
её параметр пробегает адреса реперных точек всех фреймов, т.е. тех их мест, где сохранён EBP. Чтобы напечатать из соответствующего фрейма нужное число, делается шаг в обратную сторону (единичка из адреса вычитается). Я только не понял, откуда там в конце этого «списка» берётсяnil
, на наличие которого ваша программа вроде бы полагается — но, видимо, это какая-то особенность FPC.Внутри
uncurse
ещё и применён обратный ход рекурсии, так что числа выводятся в прямом порядке, но это уже мелочи.В принципе да, ничего сверхсложного нет, просто надо знать, как устроен стековый фрейм, и верить в то, что никто не включит местный аналог -fomit-frame-pointers или как его там :-)
Если совсем честно, спасибо за эту пару головоломок, свою дозу кайфа я получил. Впрочем, воля ваша, но магией я бы это не называл. Как устроен стековый фрейм, написано в том же первом томе, где и Паскаль излагается, только в следующей части. По правде говоря, про адресную арифметику в FP я даже не упоминаю, предпочитаю поберечь мозги новичка — это уже во втором томе всё, в части про Си; но догадаться можно. Ещё нужно догадаться, что за зверь такой
ptruint
и что это вовсе не указатель, а целое достаточной разрядности.В общем, нормальный системщик расковыряет. Новичок, конечно, вряд ли.
Разгадка
Цепочка указателей идёт на один шаг дальше, чем нужно, поэтому вместо
p
используетсяpptrint(p^)
. Почему она вообще кончается нулём — не знаю, я просто увидел это в отладчике.Возможно, EBP при запуске программы обнуляется или самой системой или стандарной библиотекоЙ?
ptruint нужен был, чтобы в n хватило место для сохранения указателя в ветке else и чтобы +1 к указателю срабатывал правильно.
По-моему в понимании арифметики указателей главная проблема в том, что она работает не так как с числами. Например +1 в этой программе прибавляет к численному значению указателя не единицу, а 4 или 8.
Магией я это назвал потому, что этот код выходит за рамки паскаля как языка, то есть обладает некоей "трансцедентностью". Иными словами, разгадка этого кода не содержится в самом коде.
А теперь вопрос — а вы эту программу запускали под отладчиком или догадались, глядя только на её текст?
Нет, под
Нет, под отладчиком я её не запускал. Откровенно говоря, я не помню, как в gdb смотреть регистры :-) Просто вы мне заявили, что карандаш и бумага не нужны, вот и пришлось вспмонить, что там в следующем "слоте", а там оказалось saved_ebp (стек-то растёт в сторону убывания адресов, а n — первая (и единственная, но это неважно) локальная переменная. Дальше всё сложилось, кроме этого nil (ну есть значит есть).
С арифметикой адресов проблемы могут быть разве что с непривычки, она ведь импортирована из Си, а там она — вместо массивов, т.е. операция индексирования представляет собой комбинацию из сложения и разыменования. И там совершенно очевидно, почему численное значение адреса должно увеличиваться именно на размер указуемого типа, а уж если врубиться в указатели на массивы (которые там есть, невзирая на фактическое отсутствие самих массивов), то правило прибавления единицы к адресу отпечатывается на подкорке так, что фиг сотрёшь.
Стек
> Откровенно говоря, я не помню, как в gdb смотреть регистры
Я только бинарный дамп стека смотрел, уже после того как рекурсия поглотила ввод. Вот как правильно это делать я не знаю — я в другой вкладке смотрю PID, потом /proc/$PID/maps и там вижу адрес стека, ну а затем примерно так:
x/128000xa 0x7fffffffca00
Вот сейчас посмотрел статьи про стек, пишут что в функции main регистр EBP должен быть равен нулю — так что это не особенность паскаля, а скорее особенность Linux. Ну или обоих стандартных либ. Надо потестить на nostdlib-программе на Си.
Стек изначальный в x64
gdb -q -ex starti -ex 'i r' -ex 'x (size_t*)$rsp'\
-ex 'x /5s ((char**)$rsp)[1]' --args /bin/ls one two three
Где-то в SysV ABI должно быть описано начальное состояние процесса.
Стек
Забавная команда. Ничего сверхестественного, конечно, но ведь можно этим и не ограничиваться.
Если ввести вот такую команду:
x /128xa $rsp
Видно, что в стеке после argv лежит ещё множество адресов, указывающих на переменные окружения, но между этими адресами и началом строки argv[0] лежит ещё примерно 400 байт с какими-то данными.
Что там лежит
Что там лежит вся командная строка и всё окружение, а на самом верху (вот прямо начиная с [rsp]) сначала argc, потом все элементы argv, так что сам стек представляет собой массив argv — это хорошо известно, для 32-битного случая см. в первом томе пар. 3.6.8, во втором — гл. 4.12 и пар. 5.3.3. Чего я не знал — так это что ebp/rbp при старте будет нулевым.
> в функции main
> в функции main регистр EBP должен быть равен нулю
Что-то мне это сомнительно, у неё же тоже есть и параметры, и локальные переменные, как она будет с ними работать? Может быть, это у _start нет полноценного фрейма, и потому EBP нулевой будет?
EBP
Я запустил программу на C собранну с -g и сделал gdb / break ... / info registers. В rbp находится адрес какой-то, ведущий в стек, по этому адресу 0x0. Если сделать один шаг и дать войти в функцию, то этот указатель сохраняется в стек и указывает всё ещё на этот 0x0.
А, ну ровно это
А, ну ровно это я и предположил, там следующим шагом будет, скорее всего, mov rbp, rsp (следуя классике).
Ещё можно вот
Ещё можно вот так делать:
type
CalcInt = int64;
CalcIntPointer = ^CalcInt;
...
token = record
kind: TokenKind;
data: pointer;
end;
в дебрях одной процедуры:
new(CalcIntPointer(t.data));
CalcIntPointer(t.data)^ := ResData
Нет предела
Нет предела человеческому идиотизму.
Перед сном
Перед сном увидел это, взбодрило лучше чем кофе.
Что-то совсем
Что-то совсем бред. Зачем такое нужно, ещё можно понять — ну там посмотреть, как система себя поведёт, когда память кончится, всё такое. Но нафига goto, какая религия не позволяет написать
for(;;)
? Да даже и с goto не справились толком, там же не нужна точка с запятой после метки, оператор и так есть (собственно вызов malloc).Честно говоря, не понимаю, откуда вы тут такой бодрящий эффект нашли.
for or while?
А почему вы советуете for(;;) а не while(1)?
И почему пустое условие у for не является синтаксической ошибкой? Тогда и пустые скобки у while() тоже будут работать?
for(;;)
for(;;) — это традиционная идиома Си, есть даже традиция читать её как forever; см. параграф 4.3.6, там это есть. Почему не является ошибкой — потому что так устроен язык Си; в описании сишного for в явном виде сказано, что любое из трёх выражений в заголовке можно опустить. Про while этого не сказано, и там опустить выражение нельзя. Подозреваю, что прикол с forever придумали исходные авторы языка, для этого и разрешили опускать условие.
tail /dev/zero
Зачем что-то придумывать? Ещё можно форк-бомбу, но от неё избавиться сложно, а tail /dev/zero прибьёт само ядро через OOM.
Помню я в баше
Помню я в баше насоздавал пингов в итоге роутер выключился на пять минут, думал сгорел, оказалось что нет. Повторять процедуру не стал.
Это ещё
Это ещё сообразить надо :-)
при
при разыменовании учитывается член kind, так что segfault не будет по определению, иначе пришлось бы держать вместо одного data:pointer, DataInteger, DataFloat, DataOperation, DataBrackets, ...
Вариантные
Вариантные записи? Не, не слышал
А так лучше?
*LOL*
*LOL*
Честно говоря, мне сложно оценить, что тут "лучше": когда пытаются решить поставленную задачу (а задача там, как мы понимаем, на списки, то есть целью является освоение списков) и получают на выходе полную х-ню, поскольку не понимают, что такое параметры подпрограмм и что такое локальные переменные; либо же когда вместо списков применяют обратный ход рекурсии, а чтоб напечатать два раза, на верхушке рекурсивных вызовов берут и "раздваиваются" (пофиг нам ваш паскаль со списками, смотрите, как клёво можно обращаться с юниксом). Нет, конечно, в боевых условиях за такое руки отрывать, но тут автор программы, скорее всего, квалифицирован в достаточной степени, чтобы в боевых условиях такого не делать. Так что да, видимо, так всё же лучше :-)
Библиотека виджетов
Здравствуйте, в книге вы пишите, что библиотек виджетов много, но по тем или иным причинам они для первоначального обучения не подходят. А какая библиотека виджетов вам кажется наиболее адекватной, если не учитывать аспект первоначального обучения?
Скажем так, из
Скажем так, из ныне поддерживаемых библиотек виджетов я умею работать с двумя — FLTK и WxWidgets. После освоения FLTK я к WxWidgets не имею желания прикасаться. Т.е. если вас интересует, на чём я буду писать GUI, когда в очередной раз придётся это делать, то ответ однозначный: да, на FLTK. Просто при этом я, пожалуй, всё же не стану утверждать, что все остальные библиотеки виджетов вот прямо совсем ни на что не годны. Просто лично я на них писать не буду, но я не скажу, что каждый, кто пишет, скажем, на Qt, прям сразу круглый дурак.
А вот для обучения — тут, извините, без вариантов, учить больше не на чем, все остальные мозг изуродуют.
Есть ещё весьма
Есть ещё весьма симпатичная и простая в освоении IUP. Написана на Си, заточена под использование с ним же, но на сайте есть небольшой гайд по сдруживанию с плюсами при надобности.
Цитата из
Цитата из раздела "availability":
> UNIX (FreeBSD and Linux) using GTK+ (since 3.0)
ну вот зачем они это сделали, а? Лично я даже смотреть дальше не буду, хотя, конечно, с этим не все согласятся.
Возвращаясь к исходному вопросу — нет, для обучения по моей программе оно в качестве замены FLTK не годится. Чтобы сгодилось, сначала вокруг неё нужно навертеть плюсовых классов, причём не абы как, а так, чтобы выстроилась логичная иерархия. Должен сказать, кстати, что и FLTK в этом качестве подходит довольно условно, поскольку ООП там вроде и используется, а вроде и не совсем (какие к дьяволу callback functions в ООП, ёлки-бутылки).
Зачем нужна многопоточность
Наткнулся на статью https://gregoryszorc.com/blog/2021/04/06/surprisingly-slow/
Оказывается, что в Windows, если включен антивирусный сканер (windows defender), CloseHandle (закрытие файла) выполняется несколько десятков миллисекунд.
В итоге разработчики некоторого софта придумали решение — выносить закрытие файлов в отдельный поток, после чего приложения начинали работать намного быстрее, если там требовалось многократное открытие/закрытие файлов — например системы контроля версий, архиваторы, инсталляторы.
Хотя пример под Windows, но не исключено что и в других ОС подобные затыки есть.
Когда всё таки
Когда всё таки нужна многопоточность: Dataflow architecture.Недавно у бороды вышло интервью с создателем Эльбруса. Борис Арташесович Бабаян говорит, что сегодня многопоточность неэффективна, цитата из интервью "нужно, чтобы само существо задачи в паралелле внутри работало".
Правда меня напугало вот это "Dataflow architectures have no program counter, in concept: the executability and execution of instructions is solely determined based on the availability of input arguments to the instructions,[1] so that the order of instruction execution is unpredictable, i.e., behavior is nondeterministic.".
Быстро посмотреть там оно на 51:50.
Все слова Андрея Викторовича подтверждены, и сам создатель процессоров говорит о неэффективности малтитрединга.
Таки
Таки докатились до недетерминированных компьютеров. Пора запасаться (1) средствами радиоэлектронного подавления и (2) бронебойными базуками, на случай если номер 1 не сработает.
Что-то я
Что-то я вспомнил Unabomber'а. Все настолько плохо?
Кстати читали Why the Future Doesn't Need Us Билла Джоя https://www.wired.com/2000/04/joy-2/ ?
Всё не
Всё не настолько плохо, всё намного хуже.
Зачем не нужна многопоточность
Перефразирую ваше сообщение -- многопоточность нужна для скорости -- тут я скажу, что единственная хоть сколько-то разумная причина использовать столь запутанный механизм -- ради увелечения скорости, хотя даже с этим пунктом не все согласны. Есть такие персонажи, считающие что параллелизм удобен и позволяет лучше описывать различные процессы или действия -- скажем обращения к БД. При этом, например, тьюринговский лауреат Эдсгер Дейкстра впервые ознакомившись с исключениями на год ушёл о них думать в полном ужасе от незнания того, как это вообще контролировать. Неужели столько программистов умней Дейкстры?..
Но даже для скорости, надо помнить, насколько это сложный механизм -- ведь даже "обычное", последовательное программирование уже весьма трудная деятельность -- и уж тем более на порядки сложней параллельное программирование. И мало этого, так ещё что бы говорить о скорости надо очень хорошо понимать свою программу -- что для параллельных трудней -- в результате на практике наблюдаем кучу распараллеливающих "улучшений" программ, которые лишь замедляют свои жертвы.
Более того, скорость не является самым важным качеством программы -- самое важное качество программы это работоспособность, то есть реальное выполнение поставленных задач. В погоне за скоростью же очень часто программы наводняют ошибки из-за безгранично увеличивающейся сложности -- и нетрудно понять, по какую сторону баррикад тут параллелизм головного мозга.
Ну и последний момент -- если создание отдельного процесса хотя бы как то позволяет разделить созданную программу и ту, из которой она была получена, образование нового потока позволяет ему влиять на основную программу почти без ограничений, миллионами способов. Как следствие, написать правильно работающую программу в многопоточной парадигме -- ещё сложней, чем просто (ха-ха) параллельную.
Обобщая: многопоточность не нужна вообще ни для чего.
P.S. Я не говорю при этом что параллелизм вообще не нужен -- он может и имеет место, только использовать его надо крайне осторожно -- но многопоточность не параллелизм, и вот у неё шансов, кажется, вообще нет.
Вы что,
Вы что, издеваетесь?
Во-первых, под Windows крайне затруднена манипуляция полновесными процессами, там только мультитрединг фактически и есть (и это не повод его использовать, это повод никогда не писать ничего серьёзного для Windows). Во-вторых, я не в курсе виндовой конкретики (когда я последний раз писал под Win/*, это была ещё "платформа" Win16, больше четверти века назад), но в системе обязана существовать штатная возможность избежать подобных "пауз" — сначала заказать исполнение действия, потом через какое-то время проверить, завершилось оно или нет, и в нормальных системах такая возможность, разумеется, всегда есть. Если конкретно под виндой её нет — я не слишком удивлюсь, под виндой вообще много чего нет.
Во-вторых, "решение" такой проблемы через треды только выглядит простым (как, собственно, и всё, что связано с тредами). Между прочим, еле нашёл нужное место в тексте по вашей ссылке, там собственно самого этого решения нет, есть только ссылка на его описание "как это сделано в mercurial", ну я mercurial никогда не использовал и, надеюсь, никогда не буду, поскольку, когда людям приходят в голову такие "решения", их софт становится просто опасен. И не вполне понятно, считает ли автор статьи такое решение допустимым.
Зато в статье по вашей ссылке есть одна интересная фраза — последняя. Вот она:
Please don't cargo cult my advice without measuring and applying critical thinking first.
Вообще довольно сложно понять, тот же это аноним написал коммент, что и предыдущие комменты про треды, но если тот же (а по стилю похоже), то вам какое слово непонятно во фразе "вон с моего сайта"?
> в системе
> в системе обязана существовать штатная возможность избежать подобных "пауз"
Справедливости ради, в Linux до очень и очень недавнего времени не существовало неблокирующего чтения/записи из обычных файлов: ядро всегда рапортует их "готовность" в select и компании, а сами вызовы весело блокируются. AIO не считается хотя бы потому, что не было толком реализовано.
Ну да, ожидание
Ну да, ожидание дискового обмена в линуксе за блокировку не считают, и это даже где-то логично: откачка-подкачка ведь тоже дисковые обмены. AIO, несомненно, не в счёт, тот костыль, который есть в glibc, сделан как раз на тредах — спасибо, я лучше пешком постою.
А что изменилось в "очень недавнем времени"? Я, по ходу, не в курсе.
Async IO
Кроме posix-aio, который как раз на тредах, был/есть ещё так называемый linux-aio (io_getevents etc.), но он адекватно работал только c O_DIRECT. А вот совсем недавно[1] появился интерфейс io_uring[2]: зубодробительный, конечно, но с более широкой областью применения.
1. https://lwn.net/Articles/810414/
2. https://kernel.dk/io_uring.pdf
Нет, там не я
Нет, там не я был. Я тот диалог ранее не читал, просто отвечал на главу из книги.
> но в системе обязана существовать штатная возможность избежать подобных "пауз" — сначала заказать исполнение действия, потом через какое-то время проверить, завершилось оно или нет, и в нормальных системах такая возможность, разумеется, всегда есть.
А в винде она кстати есть, только даже при асинхронном закрытии "рукоятки", если включен антивирус, то всё равно программа тормозит. В той же статье и написано, что с этого и начинали. Ну ладно, не в той а в этой: https://habr.com/ru/company/vdsina/blog/544218/ , но я так понял, что там был перевод и дал ссылку сразу на оригинал.
> просто
> просто отвечал на главу из книги
По-видимому, у вас тоже имеются проблемы с чтением. Ещё раз: малтитрединг недопустим, и, следовательно, вопроса, зачем он "может быть нужен", просто не стоит.
> А в винде она кстати есть, только даже при асинхронном закрытии "рукоятки", если включен антивирус, то всё равно программа тормозит.
Ну так не пишите под винду.
Здравствуйте,
Здравствуйте, что думаете по поводу PascalABC.NET?
PascalABC.net
Уже обсуждали его в гостевой, могли бы воспользоваться поиском. Может быть надо пролиснуть на архив.
В общем, я его пробовал — фигня:
1. Написано на .NET и в линуксе работает через пень-колоду. Никаких дополительных модулей нет, только консольный ввод-вывод. IDE вообще не работает.
2. Следует из 1: криво реализованы указатели. Поддерживаются не все операции, какие поддерживаются могут работать неправильно.
3. Плохая совместимость с полноценным паскалем. Например нету ReadStr.
4. Хоть код и открытый, но он кривой, завязанный на MS Visual Studio и прочую проприетарщину.
В общем выкиньте каку и возьмите хотя бы Free Pascal. Тоже не супер-идеал, но хотя бы работает и достаточно неплохо.
Соглашусь,
Соглашусь, пожалуй, про указатели, но и только.
Прежде всего: создан специально как учебное пособие, создатели (что бы они ни говорили по этому поводу) не предполагали возможности "боевого" использования (например, для коммерческого программирования). Не так чтобы это было совсем недопустимо, в некоторых безнадёжных случаях можно и так, но случай с Паскалем совсем не безнадёжный — есть ведь тот же FreePascal.
Дальше, создан он специально для винды (и не надо мне рассказывать про переносимость .NET, вся эта переносимость если и существует, то тоже лишь от полной безнадёги, создатели платформы никакой переносимости не планировали). Винду использовать для обучения нельзя — вообще, совсем, никак, точка, все свободны. Кто пытается учить людей программированию под виндой — либо халтурщики, либо просто вредители.
Опять-таки, IDE. Все описания PascalABC, что я видел, практически сразу (максимум — во втором абзаце) расписывают, какая там замечательная IDE. Ну так IDE вообще нельзя использовать ни для чего, а для обучения — тем более, они скрывают как раз то, что обучаемый должен видеть.
Следующий момент — таки да, указатели. Я в своём курсе трачу время на Паскаль всего по двум причинам, и полноценное, но при этом не-шоковое освоение указателей — из двух причин, пожалуй, всё же главная. При этом, насколько я понимаю, .NET сам по себе garbage collected, таким же стал и PascalABC, а при наличии сборки мусора никакой речи быть не может о полноценном освоении указателей. В таком виде Паскаль вообще не имеет смысла включать в программу обучения. Больше того, там имеется толпа мерзости, пришедшей из "современных" "стандартов" C++, вроде автоматическго вывода типа переменной при описании, да и готовые динамические структуры данных тоже (и попробуйте при их наличии объяснить обучаемому, зачем вообще нужны эти ваши указатели). Короче говоря, на ЭТОМ можно обучить только очередную макаку.
Ну и так далее. Далее везде.
Вообще я бы сказал, что за использование этой дряни для обучения программированию следует к стенке ставить. Ну а ни для чего, кроме обучения, эту мерзость никто и не использует, собственно говоря.
Ах да, и это всё — уже не говоря о том, что ни винду как таковую, ни "платформы", предполагающие компиляцию в промежуточное представление, которое потом выполняется некой виртуальной машиной — этакое полуинтерпретируемое исполнение, что .NET, что Джава — не должны вообще-то использоваться никогда, никем, нигде, ни для чего и ни при каких условиях. Абсолютно дебильные "технологии", все их якобы-достоинства существуют только в воображении их апологетов, зато из фатальных недостатков это всё практически состоит.
Ну так IDE вообще
Ну так IDE вообще нельзя использовать ни для чего, а для обучения — тем более, они скрывают как раз то, что обучаемый должен видеть.
С обучением всё понятно, но почему опытному программисту нельзя использовать IDE?
Потому что
Потому что контрпродуктивно. Компилятор и редактор текстов — это в достаточной степени не имеющие ничего общего между собой программы, они не должны быть ни одним целым, ни комплектом.
А в чём
А в чём собственно принципиальное отличие IDE и текстового редактора у которого есть функция запустить внешнюю команду, где прописан или может быть прописан компилятор (а это любой текстовый редактор кроме самых примитивных)? А если он ещё и умеет перехватить вывод компилятора и при ошибке перемотать окно с кодом к строчке, в которой возникла эта ошибка?
Ещё раз, и
Ещё раз, и медленно: обычный редактор вы выбираете сами, а IDE отличается тем, что редактор за вас выбрали создатели компилятора. Всё, точка.
А навигацию в коде по ошибкам компилятора умеет любой программистский редактор. Вот я, например, vim использую, он с этим прекрасно справляется.
И вот что, вы сюда явно по ошибке забрели. В Интернете много других сайтов, пойдите куда-нибудь ещё.
Ну вот KDevelop
Ну вот KDevelop позиционируется как IDE, но с компилятором, насколько я знаю, не связана. Какой есть в системе, тот и использует. Qt Creator тоже вроде ни на какой конкретный компилятор не завязан.
То есть если IDE поставляется отдельно от компилятора и позволяет в настройках задать любой, то тогда использовать можно?
Что за манера всё валить в кучу?
> есть если IDE поставляется отдельно от компилятора и позволяет в настройках задать любой, то
... то это, для начала, не IDE. А то вы так, чего доброго, и vim в IDE запишете.
Если интересует моё мнение, то KDevelop (а равно и eclipse, и CodeBlocks, и kate, мало ли их там), разумеется, тоже использовать нельзя, но уже по совершенно другим причинам. Если программа может быть консольной, она должна быть консольной, GUI всегда контрпродуктивны; консольные редакторы текстов для программирования существуют, и это означает, что использование для той же цели монструозных оконных приложений попросту глупо. Это если говорить именно о текстовых редакторах.
Что касается Qt Creator, то его использовать нельзя принципиально в силу, опять-таки, совершенно иных причин. Начать с того, что Qt использовать нельзя (вообще). Далее, если основной целью софтины является рисование формочек, то тот редактор текстов, который там "в комплекте", использовать нельзя по той же самой причине, по которой нельзя использовать "комплект" из редактора и компилятора: это разные программы и их нельзя скрещивать. Ну и, наконец, "визуальный" подход к рисованию формочек с последующей генерацией части кода, предполагающей дописывание "в туда" чего-то ещё своего, тоже недопустим (и вот это уже просто категорически; такие действия — признак профнепригодности).
Заметим, тут три совершенно разные причины, и каждая из них в отдельности заведомо достаточна, чтобы и разговора быть не могло про Qt Creator. При том, что оно, формально говоря, не IDE.
UPD: У меня есть более интересные идеи, как потратить своё время, так что дальнейшие ваши бредни здесь премод не пройдут. Интернет, напоминаю, большой, а пойти куда-нибудь ещё я вам ещё два коммента назад предлагал.
А как вы
А как вы думаете, нужно ли в школе обучение всякой фиготени вроде линейных алгоритмов, ветвлений, циклов, массивов и тд, при условии что до указателей дело не доходит вообще?
И есть ли в этом случае разница, какой будет использоваться язык?
А что насчёт части информатики, которая на самом деле математика — двоичная система счисления, способы кодирования информации? Ну то есть то что часто вообще без компьютеров рассказывается.
Элементы
Элементы дискретной математики (ага, системы счисления, логика, кусочки теории графов, совсем уж базовые штучки из теории кодирования) в школе, несомненно, нужны; мне только не вполне понятно, почему это всё называют "информатикой", но в конце концов пофигу, как оно называется, лишь бы дали.
С программированием несколько хуже. В принципе понятно, что базовые понятия структурного программирования — вот как раз эти прямые следования и ветвления с циклами — это такая штука, мимо которой пройти в любом случае не выйдет, то есть начинать, разумеется, всё равно придётся с этого, а что до указателей не успели дойти — ну, не все же программистами будут, это всё-таки общеобразовательная школа, а не специальное образование.
Но есть, к сожалению, другой момент. Учителя в школе нынче такие, что сколько-нибудь адекватно преподать программирование они не могут. Вообще. А все их потуги приводят к результатам, которые потом приходится исправлять, и с очень большим трудом: переучивать всегда труднее, чем учить с нуля.
Так что тут, увы, плохо и так, и эдак тоже плохо. Ответа на вопрос "что делать" у меня нет.
А можно узнать,
А можно узнать, что конкретно не так делают в школе, что приходится исправлять?
Имеется ввиду что-то уже упомянутое типа привычки ставить пустой readline в конце программы и тд или что-то другое?
Я вот довольно смутно помню, чем я занимался на информатике в школе. Ну код на паскале в тетради был, но это я уже позже находил эту тетрадь.
Паразитный
Паразитный оператор ввода в конце каждой программы исправляется как раз без малейших трудностей: студентам показывается, как надо правильно работать (естественно, уже в юниксе) и одновременно объясняется, за каким лядом они всю жизнь ставили этот вот оператор. Дальше примерно треть группы от души ржёт, и на этом исправление кончается.
Что в школе делают неправильно: пишут под винду, пишут в IDE, пишут чёрт знает на чём (питон, C++, чего там только нет), пишут как попало (а попадает, естественно, совершенно не так, как надо). На выходе мозги полны больших и жирных тараканов. Вообще у меня встречный вопрос, вы предисловие к этому читали? Если нет, то см. "Предисловие второе, методическое". Естественно, расположено в начале первого тома. Может, вопросов меньше станет.
Предисловие читал.
1. Использование Windows как таковое негативно влияет на мозг, даже если не программировать, это так. Но что такого именно в программировании, от чего потом приходится переучиваться, если брать именно школьную программу (то есть точно такие же консольные программы на паскале как в вашей книге до указателей)? На ум приходит упомянутое восприятие программ для консоли как неполноценных, но это по идее должно лечиться просто показом полноценных консольных программ?
2. А так ли важно какой язык в рамках школьной программы? Вроде ветвления, циклы и линейное исполнение есть в любом из изучаемых в школе языках, даже в Python и QBasic, разве нет? Вроде как школьники и не должны доходить до того места, где различие между языками становится заметным.
3. Пишут как попало — это да, я тоже писал как попало не смотря на то что учителя говорили про структурные отступы и прочее. Потом как-то всё-таки начал оформлять более тщательно, но это было уже на стадии самостоятельного изучения. А в школе все эти требования к оформлению вызывали наоборот раздражение, причём не только в случае с кодом.
"Ну вот какое дело учителю русского, что я дату написал цифрами на полях, почему надо обязательно «Шестнадцатое декабря 2021 года» на отдельной строке по центру? Почему обязательно надо чертить чертежи карандашом на геометрии? Я и ручкой могу начертить. Почему на физике надо дано, решение и ответ отчёркивать? Почему при решении столбиком надо карандашом проводить линию между слагаемыми/сомножителями и результатом?" и вот все эти отступы так же воспринимались. Но за них вроде оценки не снижались, если код работал, просто ругались, поэтому прокатывало.
Так так ли важно, что по-началу пишут как попало, если позже ученики на своём опыте всё равно поймут, почему надо писать, соблюдая стандарты оформления?
> Предисловие
> Предисловие читал.
Похоже, это из серии "смотрю в книгу, вижу фигу". Вас в этой вашей школе хотя бы читать-то научили, не?
> (то есть точно такие же консольные программы на паскале как в вашей книге до указателей)
Кроме вопроса "как", есть ещё и вопрос "зачем". Никакое обучение не может быть сведено к тупой передаче информации, учить чему бы то ни было принципиально невозможно без учёта того, что будет происходить в голове обучаемого. Кроме всего прочего, обучаемый должен иметь хотя бы какое-то понимание целей, к которым его ведут. Когда его "учат" писать программы, которые, насколько он может видеть, заведомо бессмысленны, потому что все программы, с которыми он имеет дело каждый день, выглядят совсем не так — неизбежно возникает два вопроса: "нафиг это всё надо" и "как сделать по-нормальному". Как ни странно, при таком обучении информатике, как в школе, второй вопрос даже опаснее: достаточно продвинутый ученик, что вполне естественно, пойдёт искать ответ самостоятельно, и какой-нибудь добрый инфоцыган его обязательно "научит" либо жабаскрипту в браузере, либо какому-нибудь дельфи с рисованием окошек. Впрочем, и вопрос "нафиг надо" тоже так себе, но это, надо сказать, проблема не только информатики: в школе ухитряются привить отвращение и к математике, и к физике, ну вот с информатикой то же самое начинает получаться.
> по идее должно лечиться просто показом полноценных консольных программ
И где вы их возьмёте под Windows? И кто из школьных учителей это делает? Это я уж не говорю о том, что преодолеть уже сложившееся отношение к консольным программам как к чему-то неполноценному намного (на порядки) сложнее, чем изначально сформировать правильное отношение.
> Вроде ветвления, циклы и линейное исполнение есть в любом из изучаемых в школе языках, даже в Python и QBasic, разве нет?
И что? Программирование не заканчивается на ветвлениях. Конечно, тем, для кого "изучение программирования" даже не дойдёт до понимания вложенных циклов (а таких в школе всегда будет большинство), сугубо всё равно, на чём их будут учить, этот контингент испортить нельзя, там портить нечего. Вот только любой общеобразовательный предмет, чтобы от него был хотя бы какой-то смысл, должен ориентироваться не на тех, кто его "пройдёт мимо", а на тех (да, меньшинство!), кого предмет зацепит. А для этих людей ранняя привычка полагаться на бригаду добрых гномиков — это как раз то, чем плохо программирование "на чём попало".
Между прочим, в тех же предисловиях, которые вы якобы читали, всё это есть, и подробно.
> учителя говорили про структурные отступы
Учителя в большинстве своём сами не понимают, как их расставлять. Существуют учебники информатики, имеющие минобровский гриф, где отступы накиданы сугубо хаотично.
> ученики на своём опыте всё равно поймут
А кто вам сказал, что они поймут? Я каждый год на втором курсе вынужден буквально запинывать примерно половину контингента, чтобы их программы начали выглядеть как программы, а не как каракули. NB: это люди, которые поступили в МГУ на "программистский" факультет и уже один курс отучились, то есть это уже совсем не "кто попало", мой контингент — результат тщательного отбора. И вот их приходится пинать самым жёстким образом минимум полсеместра.
"на своём опыте поймут", ага. Три раза хаха.
> стандарты оформления
Кстати, за слово "стандарт", произнесённое в этом контексте, надо морду бить. Отступы следует соблюдать уж точно не потому, что какая-нибудь очередная кодла моральных уродов приняла какой-нибудь ещё "стандарт".
А что, не
А что, не очевидно, что именно я по поводу этого дерьма могу думать и по каким конкретно причинам?
Добрый день
Хочу закончить изучать программирование. Какие последние шаги нужно сделать?
Инструкция.
Я предлагаю следующие шаги:
После этих простых шагов изучение программирования будет для вас закончено навсегда, ведь создав подобную идеальную программу столь изящным образом ни единой причины или желания вновь возвращаться к программированию уже не будет.
P.S. Самое страшное, что смотря на этот список я понимаю, что таки в этом мире есть люди, которые подобным и правда занимаются.
Чем плохо тестирование?
показать, что полученная программа не имеет ошибок, лучшим методом известным человечеству -- путём всестороннего её тестирования
Чем плохо тестирование? Слишком медленно?
Говоря о
Говоря о тестировании, всегда нужно твёрдо помнить следующее: тестирование нужно, чтобы показать наличие ошибок. Для того, чтобы показать отсутствие ошибок, тестирование непригодно.
Вообще-то оно
Вообще-то оно не "слишком медленно", оно невозможно. Принципиально. Никакое сколь бы то ни было тщательное тестирование не может гарантировать отсутствия ошибок. Соответственно словосочетание "всестороннее тестирование" — это что-то вроде вечного двигателя: оно невозможно, и все это знают.
> Установить
> Установить винду последней версии и использовать для программирования только её;
На ней запустить Chrome, в котором будет новейшая™ ОС от Google на WASM, где запустить Chrome. Намертво привязать программу к такой системе, поскольку если это используете вы -- должны использовать и другие
последними шагами не занимаюсь
С этим вопросом вам куда-то сюда.
Программирование
То есть, вы считаете, что программирование — это как мафия: выйти можно только вперёд ногами?
Я бы сказал, что
Я бы сказал, что программирование — это диагноз, и он не лечится. Результат, впрочем, тот же.
Добрый день.
Добрый день. Хочу начать изучать программирование. Подскажите какие первые шаги нужно сделать?
Подробный
Подробный ответ на этот вопрос содержится в третьем ("напутственном") предисловии в первом томе книги Программирование: введение в профессию.
Доброго
Доброго времени суток. Читая "Программирование. Введение в профессию", возник вопрос: имеет ли смысл внутри функций заботиться о именовании переменных (например, прописывать в имени то, что переменная - такой-то счетчик, а не просто i и т.д.). А то я раньше, писав код, абсолютно как-то не задумывался о том, что по-сути, занимаюсь написанием говнокода. Заранее благодарю за ответ
Читая
Читая "Программирование. Введение в профессию", возник вопрос
"Подъезжая к станции, с меня слетела шляпа". См., например, тут. Аккуратнее с деепричастными оборотами.
По существу вопроса: см. Оформление программного кода, во втором издании это пар. 1.2.1 (стр.10 в книжке, 12-я в pdf-файле).
gnu coreutils
Я в попытках читать код лучших и найти примеры для подражания (даже если вообще ничего не понимаю в их коде), скачивал разные исходники и случайно попал сюда ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.24.tar.xz,
там есть функции на 10 параматеров (конкретно в src/copy.c extent_copy), гм.. я озодачился это получается иногда так можно (у меня прямо ступор) и не понимаю как они это вообще используют.
Подражание коду
Мне кажется искать код для подражания не очень разумно -- хорошего кода мало, особенно в больших проектах -- и что хуже, подражанием дело не решить. Можно следовать разным правилам оформления кода, но это не является само по себе признаком хорошего кода -- скорее плохое оформление сильно намекает что и код будет не очень.
А вот чтобы хорошо писать программы надо хорошо программировать (тавтология, ага), но научиться этому простым повторением и подражанием нельзя. Пишите свои программы и думайте о них -- удачи вам!
P.S. Конечно и просматривать чужой код тоже очень полезно, но не в целях подражания для развития своего стиля или навыка написания программ, а в целях развития навыков чтения кода.
P.P.S. Ещё отмечу, что в самом начале обучения программированию подражание примерам (простым и маленьким!) разумно -- вот только если вы способны читать гнутый код (совсем не простой и не маленький), то этот этап уже давно пройден. (Если не способны -- и не надо его читать, не торопитесь и решайте небольшие задачи.)
Да, плохое
Да, плохое слово я выбрал "подражание", просто процитирую Андрея Викторовича в "Оформлении программного кода", 1.6 Эстетика кода "если одни программы кажутся вам красивыми, а другие -- некрасивыми, постарайтесь развить этот аспект своего восприятия."
Пытаюсь найти проекты на которые можно было бы сослаться кому-нибудь и сказать "эти люди пишут хороший код, попытайся вникнуть в их трюки, меня они будоражат". Пока ни одного не нашел :-).
> в целях развития навыков чтения кода
чужой г#внокод тоже нужно уметь читать ^^. Я в гну полез просто из интереса (каждый день же использую), и узнал например, что у них все операции копирования/удаления и т.п. это отдельные модули, т.е. например всякие bash'и возможно просто цепляют этот модуль себе и вот у нас уже есть shell builtin :-).
Да и не только в целях развития навыков чтения, ещё и изменения, можно учится по одной из лучших практик : собрать у себя gentoo, в процессе и с большим количеством арсенала программистов разберетесь, и наверняка возникнет охота, что-то пересобрать под себя или дописать любимый софт.
Насчет безопасников, я бы "true безопасниками" считал тех, кто умеет находить ошибки в чужих программах и/или исправлять их. А вот здесь необходимо бы иметь нехилый такой experience в программировании.
> попытайся
> попытайся вникнуть в их трюки,
Хороший код и трюки — понятия взаимоисключающие.
> "true безопасниками"
Там не совсем так. Обычные программисты под ошибкой понимают нечто такое, что, если его обнаружить, выглядит как ошибка и оказывается понятно, как это исправить. Хакеры в программах ищут не такие ошибки, совсем другие: в большинстве случаев даже автору программы невозможно объяснить, почему вот тут вот в его программе дыра — он может просто не понимать, как устроены техники взлома.
Лет 10 назад
Лет 10 назад устроился на работу в небольшую контору по объявлению. В объявлении требовалось знание ассемблера. Как потом оказалось ребята занимались безопасностью лишь условно, т.е. по факту весь создаваемый инструментарий использовался не только в благих целях. Большую часть времени пришлось заниматься написанием и отладкой эксплоитов под Win XP SP1 в отладчике SoftICE (на SP2 и выше он уже не работал).
Как вы правильно отметили, здесь требуется очень специфическое мышление, если программисты - не совсем нормальные люди, то "хакеры" тем более.
В итоге с этой работы я ушел, т.к. начал чувствовать изменения в психике. С другой стороны некоторые техники, с которыми пришлось познакомиться, до сих пор вызывают у меня уважение к их авторам.
PS: Когда читаешь где нибудь на opennet о том что кто-то подменил js библиотеку в npm возникает мысль - как всё деградировало.
Код от GNU --
Код от GNU -- далеко не лучший пример для подражания. Да и вообще, говнокода (вполне рабочего, и даже от известных людей/проектов) в опенсорсе более чем достаточно, так что примеры для подражания нужно выбирать очень осторожно.
К совету посмотреть код от OpenBSD присоединяюсь, кстати.
В качестве
В качестве примера для подражания могу посоветовать проект OpenBSD.
Беглым
Беглым взглядом прошелся по "NetBSD source code style guide": OpenBSD стиль похож на NetBSD, что и не удивительно, ведь, на сколько я понимаю, OpenBSD пошел из NetBSD.
Фиг знает, не
Фиг знает, не видел. В принципе я не удивлюсь, если там действительно код достаточно внятный.
Что касается
Что касается оформления исходников, кстати, у них есть короткий стайлгайд прямо в манах: https://man.openbsd.org/man9/style.9
> Enumeration values are all
> Enumeration values are all uppercase.
> enum enumtype { ONE, TWO } et;
тьфу...
я понимаю, что "так все делают", но от этого не легче
Prototypes should not have
Prototypes should not have variable names associated with the types; i.e.,
void function(int);
not:
void function(int a);
А это хороший совет?
Отвратительный.
Отвратительный. Заставляет писать комментарии там, где можно было бы обойтись самопоясняющими идентификаторами.
Код OpenBSD
Стиль кода у них действительно сомнительный, хотя объясняется чисто исторически -- BSD же, куча кода уже написана и переписывать в новом стиле им видится слишком затратно.
А вот что касается самого кода -- то тут ситуация одна из лучших. Например, только у них я видел нормальный strlen. Сравните с кошмаром из glibc, схожим ужасом из FreeBSD и вот таким ребусом из musl. =)
Из любопытства
Из любопытства и для полноты картины решил посмотреть на strlen в DragonFlyBSD и NetBSD. Они там оказались тоже весьма лаконичными и почти идентичными OpenBSD'шному:
https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/lib/libc/...
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/common/lib/libc/strin...
Дальнейшее любопытство позволило узнать, что у FreeBSD когда-то тоже был простой strlen (что неудивительно, учитывая общего предка у всех упомянутых систем), но в какой-то момент они решили пойти по пути усложнения. В логах хорошо видно приход некоего любителя оптимизаций, одним коммитом резко усложнившего код.
Спасибо
Не видел до этого код DragonFlyBSD и NetBSD -- но да, то что вижу идентично и хорошо. Спасибо, буду знать. =) В целом пример strlen тут не столь принципиален, просто у меня сложилось довольно хорошее впечатление о коде опёнка в сравнении с остальными ОСями.
Теперь аккуратно скажу, что оптимизаторство головного мозга мне кажется более опасным чем излишняя паранойя безопасников. Опята тоже порой делают плохой код, но кажется стараются поддерживать его в каком-никаком порядке, так как признают, что иначе их поглотят ошибки. При этом у большинства ОСей линия партии как раз в эффективности -- Линукс, фряха, DragonFly, ... (про окошки и яблочки тактично умолчу =) ) NetBSD тут немного отличается -- у них упор на портативность, не знаю как такую установку оценить в плане влияния на качество кода.
Поясню почему "аккуратно" -- потому что порой безопасники создают высеры (простите, другого слова нет) вроде Rust, которые приносят всё во имя воображаемой (и именно так!) безопасности.
Вот-вот, aversey,
Вот-вот, aversey, где блин статья про раст?
А можете
А можете подробнее объяснить почему Rust плох? Я пока являюсь больше противником языка, хоть и не использовал его ни для чего. Отталкивает он меня своим агрессивным маркетингом (или как это правильно назвать, когда отовсюду различные эксперты призывают к переписыванию всего на Rust, а то небезопасно). Но всё-таки, хочу услышать мнение тех, кто проводил какое-то (пусть даже поверхностное) исследование языка.
Статья про Rust
Я делал однажды доклад про Rust на спецсеминаре, где анализировал его устройство -- по итогам наметилась публицистическая статья, которую я писал примерно в то же время, что и совместно с Никитой Орловым довольно нашумевшую статью про Си. Сейчас статья проходит финальные правки и в ближайшее время (вероятно сегодня) будет опубликована. Надеюсь ответить на ваши и не только ваши вопросы о проблемах Rust.
Спасибо за интерес, жду отзыва о статье когда она выйдет. =)
UPD: статья вышла.
Статья хорошая,
Статья хорошая, спасибо.
В общем понятно зачем этот язык активно в ядро линукса пропихивают. Без ядра его ждет забвение и смерть, а сообщество - как было маргинальным, так таким и останется. Понятно, что без помощи корпораций, на них никто бы даже внимания не обратил.
Недавно кратко пересказывали какую-то фэнтезю, где один из главных демонов наложил заклятье на одну из их каст. Суть заклятья заключалась в том, что они полюбили жрать говно. Ну и так как они считали это уж сильной вкусняшкой, то предлагали его всем, вроде бы даже местами навязывали. Их как-то со временем начали сторониться...
Переписывальщики на Rust
почему Rust плох?
Rust впустую расходует процессорное время за счёт необходимости исполнения в рантайме машинного кода, который занимается подтиранием соплей за представителями "тяп-ляп, вчера веб-макака, сегодня системный программист".
различные эксперты призывают к переписыванию всего на Rust, а то небезопасно
Эти "эксперты" только на переписывание и способны. Ничего толкового на этом хрусте до сих пор не выкатили, что как бы неудивительно. Этот хруст похож в этом плане на D - одно время тоже из каждого утюга вещалось об этом "улучшенном С++". А самое весёлое, это т.н. "коммьюнити" раста - вчерашние js-макаки. Отсюда куча веб-фрейворков на этом поделии, нужность которых меньше нуля. Так ладно бы копошились в своей веб-песочнице со своим хрустом, так нет же - каждый веб-павиан считает своит долгом накатать "публикацию" о применении этой поделки для разработки под МК.
Я уже промолчу насчёт переписывания утилит командной строки на этом недоразумении (так как же и на golang).
Ну а "инициатива" по использования хруста в ядре - это вообще клиника. После такого адептов хруста всерьёз воспринимать невозможно.
порой
порой безопасники создают высеры (простите, другого слова нет) вроде Rust
Rust создали в Mozilla же. А человек, работающий в Mozilla, вообще не имеет морального права рассуждать о безопасности программ и их пользователей, по моему скромному мнению.
Не говоря уже о том, что у меня лично слово "безопасники" ассоциируется в основном с суровыми людьми, которые всем всё запрещают и всех всё время подозревают. В том числе я сталкивался со специалистами по информационной безопасности, и мне показалось, что к программированию они прямого отношения не имеют.
Полагаю, это
Полагаю, это были не специалисты по информационной безопасности, а такие персонажи, которые называют себя специалистами по информационной безопасности.
Реальных специалистов по инфобезопасности изрядно меньше, чем чуваков, которые имеют наглость себя так называть. Меньше — раз этак в десять тысяч.
Полагаю, это
Полагаю, это были не специалисты по информационной безопасности, а такие персонажи, которые называют себя специалистами по информационной безопасности.
Они были "специалистами по информационной безопасности" в том смысле, что закончили (некоторые были ещё в процессе) Бауманку по этой специальности. И вот общаясь с ними со всеми, я пришёл к выводу, что их специальность "информационная безопасность" имеет отношение скорее к исследованию уже созданных программ, чем к созданию новых или даже доработке существующих.
Таким
Таким специалистам стоит задать один простой вопрос: "а ты сам эксплойты писать умеешь?" И посмотреть на реакцию.
У нас на кой-то
У нас на кой-то черт существуют 2 крайне разных специальности -- компьютерная и информационная безопасность.
Компьютерная безопасность это именно то, про что вы говорите.
А информационная безопасность это про установку сложных паролей сотрудникам, вход по пропускам, заполнении 200 бумажек-отчетов и прочее.
Ага, на входе
Ага, на входе 100500 ритуальных приседаний, а потом посреди open space на сто человек стоит выключенный комп, за которым никто не сидит и за которым никто не следит, и из него гордо торчит флешка с Самым Главным Секретным Ключом.
Не читал всю
Не читал всю ветку выше, просто листал гостевую книгу и случайно глазом зацепился :)
Захотелось поделиться.
Являюсь как раз таким "специалистом по информационной безопасности". Закончил универ по профилю ИБ, программированию учили только на модном питоне и С++. Нифига не понял тогда, хотя в школе с Паскалем проблем не было. Спустя несколько лет работы в должности "специалиста по защите информации" (бумагомарателя-эникейщика) понял что путь в никуда, а развития без знания программирования нет.
Сижу теперь после работы изучаю Ваши книги и тихонько грущу от того что не попались они мне раньше.
Хотя программистом полностью становиться я и не намерен, но хочется сказать большое спасибо за книги. Мне кажется я за первый том с паскалем и ассемблером узнал о программировании гораздо больше чем за 2 года в университете.
Не видел до
Не видел до этого код DragonFlyBSD и NetBSD -- но да, то что вижу идентично и хорошо.
С NetBSD всё оказалось не так очевидно при более пристальном рассмотрении, я написал об этом дополнительный комментарий.
излишняя паранойя безопасников
Паранойя -- это хорошо и правильно же. :)
А если совсем серьёзно, то стремление к безопасному коду ведёт, в том числе, к простому и понятному коду, поскольку делать сколько-нибудь разумные суждения о безопасности сложного и запутанного кода практически невозможно. И разработчики OpenBSD это, как мне кажется, прекрасно понимают.
При этом у большинства ОСей линия партии как раз в эффективности
Неумное стремление человеков к сиюминутной эффективности в ущерб всему остальному очень удручает, конечно. (И не только в IT, кстати, проблема в целом глобальнее.)
Ассемблер и паранойя
Да, видел ваш комментарий про NetBSD -- низкоуровневые оптимизации на ассемблере мне кажутся нормальными, более того их ассемблерный код не плох, как по мне. =) Ну и речь шла про код на Си -- а к нему у меня претензий нет, он идентичен DragonFlyBSD и OpenBSD.
И разработчики OpenBSD это, как мне кажется, прекрасно понимают.
Мне тоже, но это было пояснение к слову "аккуратно" -- потому что хотя паранойя это явно не худшее, и даже пожалуй полезное свойство программиста, но и оно иногда приводит к плохим решениям. Конкретно OpenBSD например вводили такое -- а именно рандомизацию выделения памяти программам. Не скажу что это прям ужасно, но это усложнение, при том не являющееся неизбежным для выполнения ОС своих функций. Думаю подход "улучшение безопасности любой ценой" у них имеет место -- и это плохо! -- но как и сказал изначально, их код в целом мне кажется одним из самых адекватных и понятных.
Так
Так рандомизация адресов есть сейчас везде, в линуксе её уж лет двадцать как запилили. Честно говоря, не вижу, чем это плохо, вот то есть совсем не вижу.
А я отчасти вижу =)
Ну, то что что-то есть везде, как мы все понимаем, не показатель. =)
Конкретно рандомизация адресов действительно не особо страшна, но как я и написал, это не необходимое усложнение. И мысль в том, что в OpenBSD такие изменения очень любят и их очень много, и в каждом таком небольшом усложнении можно допустить ошибку, а кроме того сам код становится при их накоплении капля по капле менее ясным. В общем, мне не столько не нравится конкретно этот механизм, сколько в целом подход -- я от него ожидаю провалов.
Может я тут не прав, но мне так кажется. Как вам известно я OpenBSD несмотря на это очень люблю, просто как и они тоже стремлюсь быть осторожным. =)
Хотя насчёт NetBSD
Хотя насчёт NetBSD не совсем понятно.
В коммите к FreeBSD'шной оптимизации strlen есть такой комментарий:
The idea is taken from J.T. Conklin's x86_64 optimized version of strlen(3) for NetBSD, and reimplemented in C by me.
А в NetBSD есть ассемблерный файлик src/common/lib/libc/arch/x86_64/string/strlen.S
Так что, может быть strlen в NetBSD реализован и вовсе на асме (по крайней мере для архитектуры x86_64).
Что-с? Это
Что-с? Это гнутые-то "код лучших и примеры для подражания"? Вы видели, как они исходники оформляют, пардон? Они бы мне не просто зачёт не сдали, там всё хуже: я обычно, видя безграмотное оформление кода, отказываюсь этот код обсуждать в принципе; ну так вот любой гнушник — во всяком случае, такой, который в этом кодингстайле реально пишет, а не конвертирует в него исходники программами вроде indent — на моём зачёте засыпался бы ровно на этой стадии.
Хотел спросить:
Хотел спросить: пишу свою консольную игру на асме. Перепрограммировать терминал научился, но хотел бы ещё узнать как исполнять подпрограмму при получении например сигнала SIGINT. С SIGKILL такое получится провернуть? Нужно для того, чтобы восстанавливать настройки терминала, иначе получается не очень. Нужно именно на асме, есть ли для этого системный вызов или это возможности библиотеки?
Кстати хотел ещё узнать как работает isatty, залез в glibc 2.20:
в sysdeps/posix/isatty.c:
int
__isatty (fd)
int fd;
{
struct termios term;
return __tcgetattr (fd, &term) == 0;
}
Интересно, что не работает по fstat, как вы писали во втором томе. Может вопрос требует дополнительного изучения, или это гнутые не могут нормально программировать unix?
а в sysdeps/unix/sysv/linux/tcgetattr.c:
Может это информация будет для вас полезна :-)
Диспозиция для
Диспозиция для сигналов SIGKILL и SIGSTOP не может быть изменена, это их (и только их двоих) фирменная особенность. Иной вопрос, что если юзер вашу программу пришиб по SIGKILL, то он сам себе злой баклан, здесь ваша программа уже не может нести ответственность за испорченный терминал.
С isatty в принципе всё правильно. На самом деле в книге имеет место ошибка, fstat вообще не позволяет узнать, терминал это или нет, он только позволяет узнать, что дескриптор связан с символьным устройством.
К слову
Таненбаум тоже говорил, что Торвальдс ему зачет по операционкам не сдал бы. :)
Можно замкнуть
Можно замкнуть круг: Торвальдс в одном из своих текстов предлагал GNU coding style guide распечатать на принтере, после чего сжечь не читая.
Здравствуйте!
Здравствуйте! Раньше задавал вопрос по Паскалю (а именно про то, как fpc формирует машинный код и используется ли при этом ассемблер), теперь же стало интересно узнать про "полноэкранные программы".
Каким образом crt может управлять консолью, системные вызовы которой, по-сути, написаны на Си (неужели получилось связать Си-шные функции с Паскалевскими процедурами)?
Заранее спасибо.
Что у вас за
Что у вас за бардак в голове?! Какие ещё "системные вызовы" у консоли, какая разница, на чём они написаны (вообще-то ни на чём, никаких таких системных вызовов не существует в природе, но если бы они даже существовали и были бы написаны на Си, это ничему бы не мешало).
Формальный ответ на ваш вопрос дать несложно, вот только он вам ничем не поможет, увы — слишком глубока степень непонимания реальности.
Кстати, вот это ваше "неужели получилось" впечатляет особенно. Free Pascal предусматривает линковку с модулями, написанными на других языках, и вызовы подпрограмм в соответствии с разными конвенциями, в том числе, таки да, и с сишной тоже, то есть взять модуль, написанный на Си, включить в сборку паскалевской программы и вызывать из неё функции, в том модуле описанные — это абсолютно штатная возможность, присутствовавшая во Free Pascal с самого начала (и, насколько я помню, в Turbo Pascal она тоже была). UPD: если интересно см. https://www.freepascal.org/docs-html/prog/progsu46.html - тут пример, как целиком библиотеку подцепить, есть ещё директива
{$L}
— она цепляет отдельный объектник; функция описывается и используется точно так же.Но и это здесь к делу не относится — если я только правильно понимаю, как устроено это чудище внутри, использования кода на языках, отличных от Паскаля, авторы FP избегают. В общем, нет там ни сишного кода, ни обращений к таковому.
Для системных вызовов (настоящих, блин, реальных, а не выдуманных вами) у FP RTL есть свои собственные обёртки, выполненные, естественно, в виде ассемблерных вставок — точно так, как это сделано и в libc. Сие обстоятельство никакого отношения не имеет к реализации именно модуля crt, поскольку любая программа, работающая под управлением ОС, вынуждена общаться с внешним миром именно через ОС, т.е. через те самые системные вызовы. Любая, понимаете? Даже просто чтобы корректно завершиться, нужен системный вызов. Самая короткая программа на Паскале, как известно, вот такая: «
begin end.
» — никаким модулем crt тут и не пахнет, а системный вызов — да, нужен, прямо-таки необходим.Ну а экран управляется esc-последовательностями. Тут всё совсем просто.
Вы правы - в
Вы правы - в голове у меня бардак. Скорее это связано с тем, что ранее узнал о termios и о различных её функциях - т.е. просто залез не туда, куда на данный момент можно.
Но вопрос (возможно глупый) теперь в другом: как программа узнаёт, например, размер экрана? Я на 90% уверен, что для этого нужен какой-никакой системный вызов (как терминал может хранить данные?).
P.S. Только сейчас вспомнил про WhereX и WhereY и появились мысли по этому поводу:
1. Терминал всё же может хранить данные (как тогда обратиться к эти данным, например, на ассемблере?);
2. Crt где-то у себя хранит эту информацию, а данные эти он получает (тоже интересно - как?).
> как программа
> как программа узнаёт, например, размер экрана?
Через вызов ioctl с параметром TIOCGWINSZ. Полегчало? (tm)
> Я на 90% уверен, что для этого нужен какой-никакой системный вызов
Без системных вызовов программа может только менять данные в отведённой ей памяти. Любое (любое!!!) взаимодействие с внешним миром происходит через операционную систему с помощью системных вызовов.
> (как терминал может хранить данные?).
Кстати, вполне может, и даже где-то обязан. Исходно терминал — это вполне реально существующее электронное устройство, в котором есть свой, пусть и очень слабенький, процессор, и своя прошивка, и, разумеется, своя память. Ну, там, настройки знакогенератора где-то надо держать, да и текущее содержимое экрана тоже.
Разумеется, нам (нашей программе) всё это великолепие недоступно. Терминал может быть сколь угодно сложен внутри, но с точки зрения компьютера это "какая-то штука по ту сторону ком-порта", не более того.
> 1. Терминал всё же может хранить данные (как тогда обратиться к эти данным, например, на ассемблере?);
Вот уж тут совершенно неважно, на чём (в смысле, на чём написана программа). К драйверу терминала и параметрам дисциплины линии можно обратиться через ioctl, через этот системный вызов вообще делаются все операции с драйверами устройств, не сводящиеся к чтению и записи. Например, "открыть лоток DVD-привода" делается через него же. С самим терминалом можно общаться через Esc-последовательности — что, собственно, делает команда resize — она сначала посылает терминалу последовательность "запомни позицию курсора", потом последовательность "позиционирование курсора" с координатами (999,999), потом последовательность "скажи, где твой курсор", на что уже терминал отвечает, опять же, esc-последовательностью, содержащей координаты. Дальше resize отправляет терминалу последовательность "восстанови сохранённую позицию", а драйверу терминала опять же через ioctl сообщает, какой теперь у экрана размер. Изначально, насколько я понимаю, драйвер считает, что размер 24x80 и именно его отдаёт на соответствующие запросы (которые тоже делаются через ioctl). Когда терминал не физический, а нарисованный, xterm как программа знает, когда пользователь меняет размер его окошка (X-протокол предусматривает передачу этой информации) и сам дёргает соответствующим образом драйвер терминала.
Ну и нафига вам это всё сейчас? Чуть позже вы достигли бы уровня, на котором можно без проблем найти всю эту (замечу, сугубо техническую) информацию самостоятельно.
COM-порт
А вот кстати, когда терминал физически по другую сторону com-порта, с ресайзом всё время какие-то проблемы. Например less или nano занимают не весь экран изначально и приходится какие-то команды вводить, чтобы сообщить размер окна системе на другой стороне.
Например это происходит когда роутер или одноплатник настраиваешь по UART, когда там сеть ещё не поднята для ssh.
У меня такого
У меня такого ни разу не было, но тут, возможно, дело в том, что я почти никогда не меняю размер xterm'а — он как открывается в классическом 24x80, так и остаётся. Всё это полностью подтверждает сказанное выше: драйвер serial'а вместе с дисциплиной линии не знают, каков размер терминала по ту сторону, и за неимением лучшего предполагают, что это 24x80. Должно быть достаточно одной команды resize.
Мне удобнее
Мне удобнее окно терминала разворачивать во весь экран.
Команды resize может быть достаточно, но это если она есть, а она есть не всегда и не везде.
Мне удобнее
Мне удобнее окно терминала разворачивать во весь экран.
Это означает, что вы не умеете пользоваться терминалом. В норме терминал можно развернуть на всю высоту экрана, но его никогда нельзя делать шире 80 колонок. Единственное исключение — когда какой-нибудь моральный урод прислал нам что-то текстовое (чаще всего URL), которое больше 80 символов, но которое нужно зачем-то скопировать как единую строку; после исполнения такой операции терминал следует немедленно пристрелить и открыть новый, т.к. это быстрее, чем попадать обратно в 80 колонок.
Текст шире 75 колонок заведомо контрэргономичен, и книгопечатникам это известно уже лет триста. Пять накидываем на рамки, нумерацию строк и всё такое прочее.
она есть не всегда и не везде.
Может, у вас ещё и ls не всегда есть?
>Ну и нафига вам
>Ну и нафига вам это всё сейчас?
Просто было интересно узнать (для полноты картины), каким образом программа может повлиять на терминал (оказывается есть системный вызов ioctl - он, в свою очередь, делает за нас всё работу с escape-последовательностями).
В общем, порядок в моей голове вы навели одним предложением: "Любое (любое!!!) взаимодействие с внешним миром происходит через операционную систему с помощью системных вызовов." (постараюсь впредь этого не забывать).
Большое вам спасибо за потраченные на меня время и силы!
> ioctl - он, в свою
> ioctl - он, в свою очередь, делает за нас всё работу с escape-последовательностями
Даже близко такого нет. Драйвер ничего не знает про esc-последовательности. Драйвер — это часть ядра, а ядро вообще обычно не делает ничего такого, что программы могут сделать сами. Сформировать esc-последовательность программа может (и должна) сама, отправить на терминал — обычной операцией записи в поток (т.е. это системный вызов write, и он тоже, разумеется, ничего не знает ни про какие последовательности, ему что сказали, то он и отправит). Роль драйвера тут в том, что он помнит два целых числа — ширину и высоту. Одни программы ему через ioctl эти два числа сообщают, другие через тот же ioctl (только с другим параметром) у него эти два числа запрашивают. Ну, ещё, если не ошибаюсь, драйвер терминала при изменении размера окна отправляет активной (текущей, нефоновой) группе процессов сигнал SIGWINCH, если, конечно, активная группа вообще есть. То есть ему некий добрый дядя сообщает, что размер экрана изменился, и он не только запоминает новый размер, но и рассказывает выполняющимся программам, что размер поменялся и пора запросить новый размер. Но о том, что размер поменялся, драйвер не сам узнаёт, ему об этом сообщают. И новый размер он не сам узнаёт, ему его говорят.
> Любое (любое!!!) взаимодействие
Если бы вы чуть внимательнее читали книгу, то уже знали бы это. Во вводной части в параграфах 1.1.2 и 1.1.6 говорится, что программа может только ковыряться в собственной памяти и всё, а всё остальное должна делать через операционную систему, хотя в явном виде термин "системный вызов" не употребляется. Но откуда-то вы ведь этот термин взяли. Так вот, если бы вы его взяли из книги, то впервые он упоминается в параграфе 3.1.2 — и вот там уже это не просто "есть", а выделено жирным шрифтом. И вообще в "ассемблерной" (третьей) части системные вызовы упоминаются то и дело, в том числе подробно рассказывается, как они делаются.
> вызывать из
> вызывать из неё функции, в том модуле описанные — это абсолютно штатная возможность, присутствовавшая во Free Pascal с самого начала (и, насколько я помню, в Turbo Pascal она тоже была).
Также в реализациях Паскаля полувековой свежести были директивы вроде EXTERNAL или FORTRAN с примерно теми же целями.
Написал
Написал программу. Откомпилировал. Сегфолт. Дебаггером нахожу фрагмент кода, который передает очень странный адрес (0x55f0000000a), заместо нормального адреса структуры. Т.к. мне нужна не вся структура, а лишь одно из ее полей, решаюсь передавать адрес нужного поля. Компиляция. Все работает. Негодую. Адрес ВСЕЙ структуры не передает (подставляет тот странный адрес), а вот поле - пожалуйста. С выражением лица "А чо бы и нет" возвращаю все как было. Компиляция.
...
Все работает просто замечательно.
Почему? :)
Есть ли какие-нибудь еще инструменты разработки? Я ума не приложу, как находить такие ошибки, которые появляются откуда не возьмись
Дайте-ка
Дайте-ка угадаю... программа многомодульная? :-)
Вы угадали :)
Вы угадали :)
Такое обычно
Такое обычно бывает, когда пересобраны не все модули, зависящие от изменившегося заголовочника. Рекомендую второй том, приложение 3 :-) и потратить уже десять минут, чтобы разобраться с автоматическим отслеживанием зависимостей.
Спасибо!!!
Спасибо!!!
Есть ли у вас
Есть ли у вас статистика, сколько раз люди запрашивали видео-интервью с вашего сайта?
Просто интересно, сколько предпочли ютубчик прямому видео.
Есть, и не
Есть, и не радует совершенно. Всего было 548 скачиваний, из них успешных (читай -- до конца файла) всего 104, остальные 444 обрывались раньше. Это всё суммарно по всем трём выложенным файлам.
Придётся, видимо, расстаться с остатками веры в человечество.
Человечество
Человечество хочет смотреть видосике на телеке, а не скачивать с ftp.
Gopher у Вас, кстати, есть?
>скачивать с
>скачивать с ftp
Любой нормальный плеер видео (vlc/mpv например) умеет в потоковое воспроизведение. А если еще подзаморочиться youtube-dl, можно будет даже качество выбирать.
Видосики с ютуба
смотреть видосике на телеке
С рекламой через каждые 5 минут. Из серии "мышки плакали, но продолжали жрать кактус".
Вот я и говорю,
Вот я и говорю, верь после этого в человечество. Чел-овечество.
Гофера нет, а надо?
Есть PeerTube -
Есть PeerTube - децентрализованный, федеративный видеохостинг с открытым исходным кодом. Все видео хранятся на вашем собственном сервере. Последнее время набирает популярность, как альтернатива ютубу. Рекомендую! Ваши видео там удобнее было бы смотреть.
Глянул. Эта
Глянул. Эта мерзость написана почти целиком на TypeScript, сайт там даже не делает вид, что может работать с отключённым JS.
Создателей подобного софта надо изолировать, они опасны для окружающих.
Так Peertube
Так Peertube изначально появился на технологии WebTorrent. Мертворожденный, в общем.
Возможно. Но в
Возможно. Но в любом случае, во вселенной децентрализованных сервисов (она же Fediverse) что-нибудь интересное еще появится. Это прекрасная альтернатива сервисам от компаний (ну не все из них, конечно, но вектор правильный)
PS: капча у вас на сайте ядрёная, хрен пройдешь.
Между прочим,
Между прочим, не факт, что что-то появится. Эти моральные уроды, состряпавшие PeerTube, заняли нишу — точнее, создали видимость того, что ниша занята. Это качественно снижает мотивацию возможных альтернативных разработчиков.
Есть
Есть исправленные версии приложения (без рекламы). Даже т.н. интеграция автоматически перематывается.
Что касается видео об информационном насилии, то я, например, их слушал (скачал аудиодорожки с помощью бота в телеграме). А на Ютуб зашёл, кажется, ради лишь одного момента про отписку из мэрии.
Отдельное спасибо за данные минилекции, они скорректировали мои взгляды.
Есть, да вот
Есть, да вот только на телефоне. Там да, и ютубовской и спонсорской рекламы нет.
Только вот одно но -- на компе так может либо браузер, либо FreeTube (на электроне, читай браузер)
Разрешение направления завимости модулей
Есть два типа переменных, одна герой, другая это арена и они находятся в разных модулях.
Арена содержит в себе всех героев.
Так как при движении героя его нужно отрисовывать в новом месте терминала, а арена на экране терминала чуть-чуть сдвинута относительно краев и в переменной арены хранится это смещение, мне пришла в голову мысль держать в переменной героя указатель на арену (считай что арена родитель героя), чтобы например он вызывал процедуру отрисовки символа со смещением арены.
Но так не получается сделать, оно и понятно неизбежно возникает зависимость в интерфесах по кругу и ничего не скомпилируется.
До этого я брал тупо весь экран терминала, и избегал страшной crt'шной нижней строки, но захотелось оформить чутка игру, создать окна туда-сюда.
Как бы вы поступили в этой ситуации? Решение в лоб это засунуть всех героев и арену в один модуль но оно мне не нравится, есть ещё решение каждому герою присвоить смещение, чтобы он сам как-то без помощи процедур родителя отрисовывал себя, но так получится дублирование кода :(
Так-с... у меня
Так-с... у меня возник вопрос, вы понимаете, что модуль может зависеть от другого на уровне интерфейса, а может — на уровне реализации? Перекрёстная зависимость на уровне интерфейсов невозможна (то самое "не скомпилируется"), но зависеть крест-накрест на уровне реализаций модули могут, имеют право, никак это компиляции не мешает. На Паскале это uses в секции implementation (не interface!), на Си это #include из файла реализации (но не из хидера). Не так чтоб это было хорошо и правильно, но предметные области сплошь и рядом заставляют так делать, и никто пока не умер.
> крест-накрест
> крест-накрест на уровне реализаций
Я правда решил это пока вы ещё не написали этак через час после коммента.
В модуле арены держится обычный герой, а в герое нетипизированный указатель на арену, и зависимость в интерфейсах героя переходит в реализацию. Решение оказалось не тривиальным, пришлось переписать подпрограммы арены, вместо var-параметров брать указатель на арену и о чудо работает!
Вы в главе про указатели говорили, что нетип. ук. могут понадобится в сложных программах с нетривиальными структурами данных. Видимо у меня та самая ситуация.
==
Мне кажется у меня появилась идея, как реализовать окошки в паскале. Например, какой-нибудь виджет при нажатии на него посылает сигнал (какую-нибудь переменную перечеслимого типа, вызвав vidget.parent^ и подпрограмму родителя, не обязательно даже окна, GUI же бывает многоуровневый) родителю, и например он меняет активный виджет на другой или выполняет предписанные действия, открывает файл, выходит из игры, сохраняет прогресс и т.п.
Это считается за ООП, ну или мышление в терминах объектов и сообщений.
Честно говоря,
Честно говоря, вообще ни черта не понял из вашего текста. Правильно вы архитектуру сделали или нет — узнаете, когда через полгода к этому коду вернётесь :-)
Новый язык.
Вопрос не содержит иронии/ издёвки.
Если C++ ужасен, но ему нет альтернатив и вообще cmustdie, то пытались(етесь) ли Вы создать собственный язык? С пониманием дела, разрабатывая не "на коленке" можно было бы сотворить нечто достойное, лишённое многих недостатков нынешних языков.
модули cppm
https://habr.com/ru/company/otus/blog/575954/
Очередной удачный теракт
Вот вроде и
Вот вроде и ясно уже всё с этим, но — по-прежнему удивляюсь, ну как можно быть ТАКОЙ мразью? Как этих недолюдей земля носит?
Мне кажется,
Мне кажется, что я понимаю, как этот новый язык должен выглядеть; некоторые соображения на эту тему можно прочитать в последней главе третьего тома Введения в профессию. К сожалению, я совершенно не уверен, что смогу состряпать сколько-нибудь пристойный компилятор за сколько-нибудь приемлемое время.
Вот кстати,
Вот кстати, насчет вашего видения языка более-менее уяснил из книги, однако что вы думаете о существующей архитектуре системы на физическом уровне? Может быть, там стоит искать "корень всех бед"?
Ну, допустим,
Ну, допустим, частностей вроде IntelME, проприетарных прошивок периферийных устройств, которые устройство не может на себе хранить, и всего прочего подобного — хватает, но чтоб прямо корень всех бед? Я думаю, корень всех бед вообще находится за пределами IT.
> проприетарных
> проприетарных прошивок периферийных устройств, которые устройство не может на себе хранить
Ну, RMS их не любит, конечно, но зачем устройству впаивать лишний чип памяти, если драйвер может прошивку в него загружать каждый раз при подключении устройства? К тому же, такая архитектура облегчает замену прошивки, если каким-то чудом появится свободная альтернатива.
Пока чип впаян,
Пока чип впаян, во-первых, прошивка уже там и никто не пытается нам рассказывать, можно её копировать/распространять или нельзя и на каких условиях. Во-вторых, её при этом в большинстве случаев нельзя поменять без программатора, а это значит, что её можно воспринимать как часть железяки, а не как софтину. Плохо, конечно, но не смертельно.
Когда этот треклятый блоб становится отдельной сущностью, ещё и закопирайченной, его уже как часть железа воспринимать нельзя, это именно что самостоятельная сущность со всеми вытекающими.
А этот язык
А этот язык будет супер-переносимым на любую платформу как Си? Вон с Rust'ом, который пытается на такую роль претендовать, не получится, язык слишком перегружен. Чтобы, например было как с Си, когда его компилятор могут написать студенты с хорошим уровнем знаний (вон сколько компиляторов на том же гитхабе сделанных just for fun).
Переносимость
Переносимость на "любую" платформу — это довольно вредный миф: я бы посмотрел на тех, кто попытается портировать Си с его побитовыми операциями, скажем, на троичную (!) Сетунь (или на её эмулятор, или на её реинкарнацию в железе, которую вроде грозятся выкатить).
Больше того, кто-то когда-то где-то видел процессор, на котором сложение и вычитание знаковых целых при переполнении генерит прерывание, и на этом основании в Си формально a+b с участием знаковых считается UB. Убил бы тех, кто это придумал.
Исходя из опыта, я бы, пожалуй, наложил определённые ограничения: арифметика должна быть двоичной, байт должен быть восьмибитным, сложения и вычитания происходят по модулю, вот это вот всё.
А компилятор — да, должен быть прост как валенок. Вся сложность должна быть вытеснена в библиотеки.
Есть только одна маленькая проблемка: "этого языка", скорее всего, не будет.
А
А "стильное-модное-молодежное", появившееся в последнее время, например Zig или Odin, может, на ваш взгляд, развиться во что-то дельное? С GC и прочим понятно, здесь вопросов нет, но вот эти языки предлагают прозрачную работу с памятью, для Zig существуют bare metal программы (Odin до такого, как я понимаю, пока не дорос).
Конкретно эти
Конкретно эти два — нет, не могут. Zig уже обзавёлся "стандартной библиотекой", в которой контейнеры, треды, чего там только нет; напоминает boost в паре с STLем. А Odin, честно говоря, расхотелось дальше смотреть после предложения "Join the Odin community on Discord." Люди, которые такое предлагают, ничего хорошего породить принципиально не способны.
Zig уже
Zig уже обзавёлся "стандартной библиотекой"
Но ведь она явно импортируется при необходимости - в библиотеке Си тоже есть треды, в C++ - исключения, динамическая память и RTTI, что не мешает использовать эти языки для тех же микроконтроллеров, если не "распускать руки" и не использовать лишнего. Разве проблема в этом "фарше", если нам не нужно платить (быстродействием, уползанием в рантайм) за то, что мы не используем?
> в библиотеке
> в библиотеке Си тоже есть треды,
В стандартной -- нет. Только не надо про C14 и вообще про всё, что было начиная с C99 -- это уже к Си никакого отношения не имеет.
> в C++ - исключения, динамическая память и RTTI
Давайте не подменять обсуждаемый предмет, исключения и RTTI в Си++ не являются библиотечной возможностью, это раз, и они безнадёжно уродуют язык, это два. К счастью, компиляторы умеют их отключать.
С динамической памятью в Си++ ещё хуже, конструкция, включённая в язык, зависит от библиотеки. Но я, собственно, и не говорю, что Си++ хороший язык. Си++ де-факто мёртв, писать на нём приходится просто потому, что больше не на чем, просто от полной безысходности. К тому же мы вроде не Си++ обсуждаем, не?
> если не "распускать руки"
Чтобы программисты не распускали руки, стандартной библиотеки не должно быть вообще. Вообще, совсем, никакой. Никакая библиотека не должна называться стандартной. А ещё должно быть запрещено делать сборку зависимой от чего бы то ни было внешнего. Следствием этого станет необходимость включения любой библиотеки в дерево исходников разрабатываемой программы. Вот тогда, есть шанс, хоть кто-то думать начнёт головой, прежде чем подключить очередную библиотеку.
А уж контейнеры и треды в стандартной библиотеке -- это приговор. И я даже не знаю, что хуже. И то, и другое ипользовать нельзя вообще, ни из стандартной библиотеки, ни из какой-то другой, ни самописные, никакие. Хотя и по совершенно разным причинам.
Так или иначе, любая возможность, включённая в язык или в его "стандартную" библиотеку, обрекает людей, понимающих, что можно и что нельзя (а таких, заметим, очень мало) на постоянную трату времени и нервов, чтобы объяснять обезьянкам, по каким таким конкретным причинам вот это и вот то нельзя применять. Объяснения при этом ещё и не достигают цели.
Должен быть хотя бы невысокий, но всё же барьер между обезьянами и обезьяньими игрушками. Включние таких игрушек в язык этот барьер убирает. Что касается стандартной библиотеки, что само её понятие, сам этот термин существовать не должен, это следствие мании величия тех, кто её сотворил: они всерьёз полагают, что их высер есть идеал идеалов и никто не может сделать то же самое лучше.
Почему вы
Почему вы считаете, что треды нельзя использовать вообще? Нельзя даже в ситуациях, где фактически нет работы с разделяемыми данными и выигрыш от использования многопоточности дает ощутимый пользователем прирост производительности? Да, такие ситуации редки, но все же есть области, где они бывают.
Нельзя никогда.
Нельзя никогда. Потому что треды выглядят слишком просто, тогда как в действительности работа с ними требует не просто высокой, а феерически высокой квалификации, при этом люди, которые такой квалификацией обладают, треды использовать просто не станут сами. Иначе говоря, все, кто используют треды, для этого заведомо недостаточно квалифицированы.
фактически нет работы с разделяемыми данными
А тогда зачем треды? Кроме того, в многопоточной программе вообще-то вся память разделяемая, чем треды и кошмарны, хотя отнюдь не только этим.
выигрыш от использования многопоточности дает ощутимый пользователем прирост производительности
Такого никогда не бывает в реальной жизни, т.е. вот чего я никогда не видел — это чтобы сначала было показано на однопоточной программе, что она работает слишком медленно. Вообще-то потом должна быть сделана попытка загрузить параллельные процессоры обычными процессами (не тредами), причём чтобы эти процессы общались через пайпы или сокеты; затем, если будет убедительно (на практике! никаких умозрительных соображений!) показано, что в решаемой задаче слишком высок оверхед от системных вызовов (что вообще, на мой взгляд, нереально), можно ещё попробовать разделяемую память, созданную через mmap (на практике до этого не дойдёт никогда). И вот уже после этого (т.е. после никогда) можно было бы подумать про многопоточность — можно, но не нужно, поскольку существующие её реализации слишком во многом уступают модели с полновесными процессами, при этом ни в чём не выигрывают.
Подчёркиваю, на практике предварительного исследования быстродействия не делает никто и никогда; все случаи применения тредов, которые я до сей поры видел — не ответ на слишком медленную работу программы, а результат вопиющей безграмотности программистов (как правило, тупого неумения работать в терминах явных состояний, либо, что ещё хуже, обезьяньей самонадеянности типа "я не знаю, чем треды плохи — значит, они ничем не плохи").
> А тогда зачем
> А тогда зачем треды?
Ну вот, например: программе для 3д-моделирования нужно провести предварительную обработку большого количества файлов (3d-моделей) и потом использовать получившуюся информацию для отрисовки. Если использовать треды, то можно при загрузки сцены каждому треду назначить файл или несколько файлов и выделить кусочек памяти, где он будет сохранять результат этой обработки. Эти кусочки памяти не будут между собой пересекаться. После обработки треды завершаются (остается только главный поток). Возможно, при использовании процессов, разница в скорости была бы незаметна, но я не очень понимаю, зачем в такой ситуации пытаться использовать полновесные процессы через пайпы, какие приемущества это может дать или от каких опасностей тредов это может уберечь? Хотя, например, в случае какого-нибудь http-сервера, я бы точно выбрал программирование в терминах явных состояний и полноценные процессы.
Что, читать не
Что, читать не умеем, да? Вон с моего сайта, я тут древообработкой заниматься не собираюсь.
К счастью,
К счастью, компиляторы умеют их отключать
Ну, в общем, да, про это и шла речь. Хотя могут и пытаться включать возможности "стандартной" библиотеки даже при явном запрете - не так давно писал максимально простую прошивку под контроллер на ARM'е, так банальнейший код типа забивания секции .bss нулями в цикле и копирования .data из флеш-памяти в оперативку при старте gcc-шный компилятор изо всех сил пытался заменить на вызов memset и memcpy (естественно, роняя линковщик из-за -nostdlib). Пришлось изрядно обвесить его ключами, чтобы пресечь подобные попытки.
А вообще я, наверно, слишком высокого мнения о "программистах, не распускающих руки" и об их количестве на фоне всех прочих.
Здесь есть и ещё момент - язык, потенциально способный к работе на голом железе, едва ли будет "слишком высокоуровневым", да и вряд ли "нефоннеймановским". А после обстригания чего-то высокоуровневого до необходимого для bare metal уровня мы, отложив ножницы, с удивлением обнаружим, что опять получился Си...
"Высокоуровневость"
язык, потенциально способный к работе на голом железе, едва ли будет "слишком высокоуровневым", да и вряд ли "нефоннеймановским".
Почему? Главное, чтобы язык обладал свойсвом zero runtime. А понятие "высокоуровневости" относительно. Любой язык, за исключением языка ассемблера - формально высокоуровневый. При оценке возможности использования языка для разработки на "голом железе", более важным критерием будет являться не "степень высокоуровневости", а умение компилятора генерить машинный код без явного оверхэда.
после обстригания чего-то высокоуровневого до необходимого для bare metal уровня мы, отложив ножницы, с удивлением обнаружим, что опять получился Си
Для bare metal по-хорошему не С нужен, а ассемблер с крайне развитым макропроцессором, хотя бы. В принципе, никто не мешает генерить ассемблерные листинги даже с помощью какого-нибудь OCaml. Но логичнее, конечно, идти "от низкого уровня к высокому", а для это как раз и нужен язык, который даёт возможность создавать свои собственные абстракции. При таком подходе понятие "уровня языка" вообще становится несущественным. Формально язык, конечно, является низкоуровневым, но возможность нафигачить абстрации нужной сложности позволяет, по сути, создать DSL.
с удивлением
с удивлением обнаружим, что опять получился Си...
Вот уж ни фига подобного. Даже если применять традиционный подход с фиксацией в компиляторе всего, чего только можно, и даже если не думать о высокоуровневых абстракциях и их построении библиотечными средствами (естественно, именно библиотечными, а не средствами компилятора) — то даже в чистом Си есть что исправить: во-первых, ввести массивы как самостоятельную сущность, во-вторых, описания сделать линейными, т.е. читаемыми слева направо, а не как сейчас, да и много чего ещё. В первую очередь — ссылки, это из всего Си++ настоящий семантический бриллиант.
Останавливаться на этом никто не заставляет, следует ввести (хотя бы для структур) конструкторы с деструкторами и переопределение операций (да хотя бы даже присваивания), и вот тут нужно вовремя затормозить, поскольку виртуальность — это уже механизм достаточно сложный, чтобы в языке ему было не место. Дальше очевидным образом возникает некая операция вызова виртуального метода (в отличие от обычного), а её определение отдаётся на откуп библиотекам, то есть построение _vmt и вот это вот всё — должно быть там, а не здесь, и библиотек таких должно быть больше одной, хотя бы даже для того, чтобы множественное наследование можно было поддерживать или не поддерживать. Такой язык УЖЕ будет лучше, чем Си и Си++ (даже вместе взятые, пожалуй).
Следующий шаг — осознание того, что с перегрузкой операций нужно разбираться целиком во время компиляции, следовательно — перегруженные операции не должны быть функциями, они должны быть макросами, и конструкторы, кстати, тоже; отсюда следует, что макропроцессор должен быть не такой, разумеется, как в Си/Си++, а нормальный, работающий не до компиляции, а во время таковой, т.е. имеющий доступ к идентификаторам, их категориям, к системе типов и т.п. — вообще ко всей информации, какая есть у компилятора. Заодно избавляемся от манглинга. А ещё (ну это уже мелочь) this должен быть ссылкой, а не указателем.
Пока не ушли далеко от нижнего уровня, можно (и нужно) реифицировать (сделать доступным на уровне конструкций языка) стек — вот буквально снабдить язык возможностью напрямую работать со стековыми фреймами. Чтобы с каждой функцией был связан как-то там называющийся тип вроде структурного, соответствующий её стековому фрейму со всеми локальными переменными. Это чтобы фреймы можно было помечать — если кому-то потребуются исключения, то пусть они будут библиотечной возможностью, а не частью языка.
Следующий шаг — понять, что вообще-то не должно быть такого дебильного понятия, как "ключевое слово". Например, все слова, введённые компилятором, могут начинаться с какого-нибудь знака доллара. Или вообще с обратного слэша, как в TeX'е. Дальше — что вообще-то набор операций и их приоритеты компилятором фиксировать не надо, достаточно на уровне компилятора предусмотреть некое «применение функции/псевдофункции (читай — макроса) к кортежу параметров» и средства для построения этого кортежа, а с остальным справятся макросы, введённые библиотекой. Такие слова, как if, while и прочее, можно вводить как имена макросов. В итоге тот "язык", который видит программист, будет сформирован целиком библиотеками макросов, и таких вариантов будет много, но компилятор будет для всех один и объектные модули будут одного и того же вида, без всяких, естественно, сложностей с их линковкой и взаимными обращениями. А "уровень" тут будет доступен абсолютно любой, от почти ассемблера до почти питона (с точностью до стратегии исполнения, всё-таки питон интерпретируемый, а тут будет, естественно, чистая компиляция).
Здесь я бы, пожалуй, остановился, хотя можно и дальше пройти.
Я это всё к тому, что сугубо низкоуровневый язык может, во-первых, совершенно не быть "новым Си", а во-вторых, может содержать в себе не сами высокоуровневые абстракции, а средства для их создания. Собственно, Си++ подавал на это надежды, причём всерьёз. Примерно до того момента, как за него Степанов принялся.
Если очень
Если очень коротко - нас бы спас "Си с шаблонами" как одно из подмножеств C++? Работа с типами, метапрограммирование, вот это вот всё, да ещё и тьюринг-полное, да ещё и на этапе компиляции?
Если коротко
Если коротко — нет. А подробно описано выше.
Если даже учить
Если даже учить С++ по второму изданию Страуструпа, то чем и как компилить? Без шуток, gcc 2.95 выкачен в 1999, после первого стандарта.
9 из 10 нанимателей на хедхантере предлагают зп от $2K и хотят 11/14/17/STL/boost. Я правильно понимаю, что таким сразу "давай до свидания", т.к. там проблем будет больше чем на два килобакса. И не учить же их на собеседовании, как свой софт делать.
Компилить
Компилить можно чем угодно, здесь вопрос не в том, чем компилить, а в том, какие средства использовать. С обратной совместимостью пока вроде бы всё более-менее нормально, только throw в заголовках функций в какой-то момент "депрекейтнули" (предупреждения выдаются), но его и так никто толком не использовал.
Ну а 2K за C++ — просто смешно вне всякой зависимости от используемого диалекта. И да, если хотят C++14 и выше — туда лучше и на пять килобаксов не ходить.
О.Хре.Неть
Блин, спасибо, что не пожалели времени на такое развернутое объяснение!
Вот уж ни фига подобного
Эх, неужели это она, та самая сишность моего межушного ганглия?..
Сишность мозга,
Сишность мозга, во всяком случае, как я её для себя определяю, заключается в другом. Собственно говоря, в книгах, начиная с предисловий, это подробно расписано.
Очень жаль.
А что порождает неуверенность? Идеализм? Так нам достаточно языка, который не будут характеризовать как нечто ужасное или необходимое зло.
Мне кажется, на такую работу можно было бы собрать достаточную сумму посредством краудфандинга. По крайней мере, я бы поддержал.
В конце концов пора начинать войну со стандартизаторами, майкрософтом, гуглом и прочими террористами, мракобесами да вредителями. Если победить их и возможно, то только качественной работой, которая им не свойственна.
Какой ещё
Какой ещё идеализм, наоборот — самый что ни на есть реализм. Приличный компилятор — это серьёзно. А на войне с корпорациями есть более важные задачи, чем новый язык, писать пока что можно и на C++, если при этом отличать допустимое от недопустимого.
Приличный компилятор компиляторов
А LLVM -- приличная система построения компиляторов?
Нет. Во всяком
Нет. Во всяком случае, на ЭТОМ нельзя реализовать язык, который я задумал.
А дракончик,
А дракончик, точнее Compilers: Principles, Techniques, and Tools, хорошая книга? Хочу создать простой компилятор, но боюсь подходить к синтаксическому анализу. Что бы посоветовали?
Если я только
Если я только правильно понимаю, кто такой "дракончик", то это Ахо-Лам-Сети-Ульман, так? Если да, то это не то чтобы "хорошая" книга, просто других нет :-) NB: я новые издания не смотрел, у меня есть перевод первого издания, которое ещё писали Ахо с Ульманом вдвоём. Ну, типа, классика и всё такое.
Иной вопрос, что вот конкретно для синтаксического анализа можно всю книгу не грызть, вам хватит рекурсивного спуска. Лучше язык чуток подрезать, но загнать грамматику в нужные условия, нежели использовать потом какой-то другой метод разбора.
Да тот
Да тот самый.
Нашел ещё "Построение компиляторов" Вирта, правда там Оберон-0. Можно узнать почему вы перестали Вирта воспринимать всерьез после Оберона?
Классика CS
Ещё одна классическая книга
The Design of an Optimizing Compiler (1973)
https://kilthub.cmu.edu/ndownloader/files/12102674
Нашел ещё
Нашел ещё "Построение компиляторов" Вирта
Вирт писал аналогичные работы по каждому из изобретённых им языков.
В последних главах А+СД=П есть пример разработки процессора простого языка с использованием рекурсивного спуска.
Первые трансляторы арифметических формул использовали правила переписывания "в лоб". Фактически получался наивный восходящий анализатор.
Когда Ахо и Ульман писали свою книгу, уже работали синтаксически управляемые трансляторы. Да и Д.Кнут приступил к своим так и недописанным глыбам под впечатлением.
В учебниках упрощённо описываются достижения прошлых лет. Вас же ничто не заставляет использовать те извращения, к которым прибегают разработчики промышленных компиляторов.
Чтобы компилятор получился простым, простым должен быть сам язык и его смысл. Математически простейший язык - пустой язык, в нашем случае это язык, в котором никакая исходная программа не является синтаксически корректной. "Компиляция" любых исходников должна завершаться неуспешно с выдачей соответствующего диагностического сообщения. Если мы вставим в Makefile правило для нашего компилятора, и цель будет зависеть от исходников на нашем языке, то сборка цели должна завершиться неуспешно. Такой компилятор - неплохой фундамент для дальнейшей работы. Как бы мы не расширяли наш язык до разумных пределов, всегда нужно будет сигнализировать о неуспехе вызывающей программе и сообщать программисту об ошибке.
Чуть более сложный язык - язык, в котором корректна только одна программа - пустая программа ( пустой исходный файл, или файл, в котором нет ни одного символа и ни одной строчки ). Результатом сборки такой программы может быть, например, пустой или минимальный допустимый на целевой платформе исполняемый объектный модуль, корректно завершающий свою работу без ошибок. А если мы предполагаем раздельную трансляцию для последующей компоновки с модулями на нашем или других языках, то в результате должен получиться пустой или минимальный объектный модуль, который понравится компоновщику, но не содержит каких-либо данных или инструкций, которые должны попасть в скомпонованную программу. Пустая программа допустима в Си только как "единица трансляции", а в большинстве реализаций Паскаля недопустима вообще: без точки в конце Паскаль - не Паскаль. Затем допускаем программы, состоящие из последовательностей пробельных символов, например, из " \t\n\v\f\r", с таким же результатом трансляции.
Далее можно перейти к описанию синтаксиса и смысла языковых конструкций, не допускающих бесконечной вложенности. Например, конструкциям, позволяющим программисту определить константные символы с идентификаторами и присвоить им значения выражений, в которых используются числовые литералы, арифметические операторы с обычными приоритетами и уже определённые символы. Скобок в выражениях мы пока не разрешаем. Для синтаксического разбора такого языка не нужны ни рекурсия, ни восходящие методы, использующие стек. Должно быть достаточно конечного автомата. Определённые символы в объектном файле становятся отладочными символами, если компилятор об этом попросили соответствующим параметром командной строки. Можно также разрешить определять символы для использования в модулях, написанных на других языках.
И так далее.
Признаюсь
Признаюсь ничего не понял из вашего комментария, попытаюсь к ниму вернуться позже :-). Вообще, когда я начинал моей первой книжкой по которой я попытался изучить программирование была Программирование. Принципы и практика использования C++, Страуструпа. Книга в целом, теперь на мой взгляд нацелена исключительно на создание дресированной макаки, но вот одна глава там у меня отлажилась в сознании очень сильно. В 6 главе он описывал создание калькулятора объяснил лексемы, то как создать грамматику, как превратить грамматику в программу и все это написал и показал с использованием одного класса token_stream и показал весь процесс разработки со всеми ошибками проектирования в начале. Тогда я не смог эту главу понять, да и всю книгу впринципе, какой c++ для начинающих, но сейчас надо вернуться.
> В последних главах А+СД=П есть пример
Спасибо, не знал, что там в конце есть это. Надо будет её догрызть до конца, там изложение очень интересное.
Этюдик так
Этюдик так сделать можно, и даже очень полезно для общего развития. Сделать в таком режиме язык программирования, который сможет заменить Си и Си++, а заодно поставить отчётливый крест на мракобесии вроде D, Go, Rust и вот этого вот всего — заведомо не получится, к этой задаче нужно подходить с противоположной стороны.
Если что, лично я прекрасно знаю, как делать лексический и синтаксический анализ, и как объектный код сгенерить и записать в elf object file — тоже представляю, мне с этой низухой разбираться уже не нужно. Проблемы у меня, несомненно, есть, но уж точно не здесь.
Куча мелочей кроме разбора
Низуху можно поручить студентам-аспирантам.
Или тем, кто опасается приступать к синтаксическому анализу.
Низуху можно
Низуху можно поручить студентам-аспирантам.
За свою жизнь я отруководил больше полусотни дипломных работ, курсовые вообще не считал. Так вот, нет, студентам-аспирантам ничего поручить нельзя. Код, который они после себя оставляют, даже если как-то работает, поддержке не поддаётся и годится только на то, чтобы его выбросить. За всю, подчеркну, довольно обширную практику у меня был только один случай, когда код, написанный в ходе работы над т.н. "магистерской диссертацией", условно "остался жить" (в недрах библиотеки InteLib), и то я сильно сомневаюсь, что смогу, если что, этот код адекватно поддержать — а если не смогу, придётся откатить. Это при том, что код создавался практически в четыре руки, то есть с моим непосредственным участием.
Впрочем, проблема, ещё раз говорю, не здесь. Всю низуху я могу сделать и сам, рекурсивный спуск прост как валенок, на таком кодировании мозги отдыхают, это как, ну, не знаю, надеть кроссовки и пробежаться по парку — вроде и нагрузка, но не такая, которая утомляет.
>
> студентам-аспирантам ничего поручить нельзя
А что мешает аспирантам писать хороший код, мало опыта написания программ из-за учебы, которая отнимает все время, или чтобы писать хороший код нужно "побывать в мастерской" и не вариться только в университете?
Мой пост был не
Мой пост был не про аспирантов, аспирантам ничего поручать нельзя по совершенно другой причине — у них и так забот достаточно. Да и нет у меня сейчас аспирантов, и теперь уже вряд ли появятся. Из моих четверых аспирантов не защитился ни один, так что я в какой-то момент решил больше аспирантов не брать, во всяком случае, пока не буду твёрдо уверен, что могу человека допинать до диссертации. Толковых дипломников, имеющих потенциал для кандидатской, после диплома "сдаю" коллегам по кафедре.
А со студентами всё намного проще: у них есть "час икс", про который достоверно известно, что всё, что они делают, им (лично) после этого часа икс не понадобится. Час икс — это дата защиты диплома.
Очевидно же, не?
Очевидно же, не? Потому что фоннеймановское программирование и сборка мусора — сущности взаимоисключающие.
Несколько раз
Несколько раз видел ваши утверждения что фоннеймановское программирование не сочетается со сборкой мусора, но так нигде и не нашел подробностей.
Не могли бы вы подробнее объяснить, почему это так? Или отослать к предыдущим ответам, если такой вопрос уже здесь задавали?
Мне ответ
Мне ответ представляется очевидным. Фоннеймановский стиль программирования исходно противоестественный, все эти присваивания с циклами кажутся простыми только тем, кто к ним привык. Существование фоннеймановского стиля оправдано только одним: машиной фон Неймана (ну, с точностью до ряда оговорок, но тем не менее) является тот базовый вычислитель (т.е., попросту говоря, компьютер), для которого мы пишем программы.
Если мы готовы отойти от возможностей базового вычислителя настолько далеко, что нас перестаёт смущать даже сборщик мусора, то тащить за собой адреса, присваивания, циклы, вообще все прелести (на самом деле, просто извращения), продиктованные машиной фон Неймана, нет никакого смысла, нужно брать в руки другие инструменты — языки высокого уровня, тот же Лисп, или Пролог, или какой-нибудь Haskell, Scala, мало ли их. Конечно, мы из компьютера больше десяти процентов его возможностей при этом не выжмем, но на языках со сборкой мусора — тоже не выжмем.
NB: лично я не считаю, что нефоннеймановское программирование — это "правильно"; я предпочитаю не забывать, что текст, который я пишу — это не абстрактный полёт мысли, а программа для вполне конкретно устроенной железки. На этой железке сборки мусора нет. Точка. Но это по моему мнению — точка; есть много сторонников мантры "люди дороже компьютеров", и в некоторых случаях эта мантра имеет смысл даже для меня — например, если программа предназначена для двух-трёх запусков, а то и вообще одного. Или когда эффективность заведомо не нужна — скриптинг ведь тоже никто не отменял. Ну и вообще, взять и в одночасье ликвидировать все нефоннеймановские языки, разумеется, невозможно, да и не нужно — напротив, хорошо иметь опыт работы с ними, чтобы, во-первых, мозги не утрачивали эластичности, а во-вторых, даже для того, чтобы понимать, как не надо (хотя, увы, это сильно не для всех).
Но тут уж или крестик снимите, или трусы наденьте. Если вас устраивает сборка мусора, то не делайте вид, что вы занимаетесь фоннеймановским программированием. Выглядит это совершенно несуразно.
Хм, получается,
Хм, получается, что "прикладному программированию" не лишено смысла сразу учить на нефоннеймановской основе. (Уж точно лучше, чем впихивать в непрограммистов какой-нибудь Python.)
Вероятно, это как раз была одна из задач, которую ставили перед собой авторы SICP.
Я своими
Я своими глазами наблюдал случаи, когда людям не давалась императивщина (вплоть до непонимания, как работают вложенные циклы — т.е. выглядело как безнадёжный алгоритмический кретинизм), а потом внезапно всё начинало получаться с чем-нибудь рекурсивным, с тем же Прологом или Лиспом, и после этого оказывалось намного проще оттуда прыгнуть в императивщину.
Но про SICP я бы поостерёгся восторгаться. Из вошедших в программирование по SICP'у потом вполне получаются всякие джависты и питонисты, серьёзные программисты тоже бывают, но скорее не благодаря SICP'у, а вопреки. Увы. Нельзя при обучении программированию игнорировать компьютер, иначе результатом обучения станет очередная обезьянка.
Нельзя при
Нельзя при обучении программированию игнорировать компьютер, иначе результатом обучения станет очередная обезьянка.
Но и игнорировать нефоннеймановские подходы тоже, получается, нельзя. Иначе получаем кучу фоннеймановских языков со сборкой мусора, спроектированных при попытке создать прикладной/скриптовый язык теми (или для тех), кто ничего кроме фоннеймановской парадигмы не знает.
Но и
Но и игнорировать нефоннеймановские подходы тоже, получается, нельзя.
Разумеется, нельзя. Ну так, на всякий случай — обратите внимание на третий том моего трёхтомника. Хотя бы на его название, а лучше — на оглавление.
Иначе получаем
Вообще-то "иначе" мы получаем безмозглого кнопкодава, это серьёзнее. А императивные (но уже в большинстве своём не фоннеймановские) языки со сборкой мусора мы "получили" уж точно не в результате попытки создать скриптовый язык, и явно не потому, что их создатели не знали умели кроме фоннеймановской парадигмы, тем паче что они и её, похоже, толком не умели.
...потому будем
...потому будем писать на Си :)
Здравствуйте!
Здравствуйте! На счёт кнопочных телефонов из недавнего интервью с Вами. Честно говоря, даже им сейчас веры нет, после статей вроде: https://habr.com/ru/post/575626/
Судя по всему, там примерно такая же ОС и приложения, как и в смартфонах, только больше ограничений для пользователя. А в плане слежки всё то же самое. :(
Нет там никаких
Нет там никаких приложений, приложения на смартфоны ставит сам пользователь, на кнопочниках нет соответствующей опции.
Разница в любом случае есть: тут это очевидно троянские закладки, скандал, кому-то прилетит по шее (на самом деле, если я правильно понимаю, там уже прилетело), обновления они на себя ставить не умеют (да, это очень важно, это прямо-таки крайне важно), и -- главное -- их неуклюжие попытки контрабандой собирать сведения представляют собой именно нарушение, притом очевидное, тогда как смартфоны нынче часто просто чтобы активировать, нужно предоставить хренову прорву собственных данных. Опять же, здесь бекдор может быть вшит только на фабрике, тогда как на смартфон бекдоры пользователи радостно устанавливают сами.
Короче говоря, это просто другой порядок риска.
Но вообще-то да, вон Столлман вообще мобильной связью не пользуется исключительно из соображений паранойи, и совершенно правильно делает, если между нами.
>на кнопочниках
>на кнопочниках нет соответствующей опции.
Здрасте, я однокласснику зачем закачивал игры на Java?
Кнопочник, 2015 год.
Ещё и игры по
Ещё и игры по смс. Я до этого думал что это был такой прикол для дурачков (существования мошенников не отменяю), проверил оказывается реально так можно было поставить, прилетала ссылка и скачивался исполняемый файл.
Игры
прилетала ссылка и скачивался исполняемый файл
Всмысле исполняемый? На телефонах же вроде был предустановлен рантайм для запуска байткода жабы. Такого прям, чтобы бинарники прилетали, небыло, вроде. Хотя, конечно, невыпиливаемый рантайм для жабы - это дичь, безусловно. Т.е. уже 15 лет назад начинали закидываться удочки на тему возможности установки на телефоны всякого непонятного ражна.
Уххх, вы прям
Уххх, вы прям такие воспоминания вызвали в моей голове. Да, на последних страницах газет-журналов середины нулевых кучу всяких картинок, популярной музыки и игрушек предлагалось скачать, отправив код на короткий номер. И ме-е-елким таким шрифтом внизу про цены и всякие отказы от ответственности. Бывало, под доброй половиной этих картинок один и тот же код был написан...
Ну а по java-игрушкам на кнопочниках просто сходила с ума детвора того времени, это да. Конечно, тогда никто особо не заморачивался на тему безопасности всего того зоопарка, который на переменах друг другу по блютузам да ик-портам скидывали ("Да не шевели ты мобилу, щас вырубится всё!"), но, всё же, в сравнении с нынешним смартфонным мракобесием, это было гораздо меньшим злом. J2ME, на которой писался такой софт, основывалась на Java 1.3 без модных приколюх, которыми сейчас оброс этот язык, байткод был действительно байт-кодом весьма компактных размеров, API был примитивнейшим, а жизненный цикл приложения был именно что циклом, который выходил из спячки раз в сотню миллисекунд, пинал метод для обновления и проверял какой-нибудь boolean-флажок, позволявший вывалиться из цикла и вызвать destroyApp(). Всё! И ведь в пару десятков килобайт запихивали какие-нибудь пошаговые стратежки, в которые залипали часами, всякие псевдо-3D на процах без "аппаратной плавучки". И ведь работало, и шустро! А сейчас куча слоёв абстракции, электрон (ВМ внутри ВМ внутри ВМ, а хули), приложения по полгига, да у тебя ж смарт прошлогодний, как ему не тормозить, вот это вот всё. Так что зря закопали J2ME, зря. Сейчас и кнопочников-то с ней если и найдёшь, то с кастрированной и ни на что не годной, да и что запускать-то?. Говорят, jabber J2ME-шный, вроде, существует в природе, а так заглохло всё стараниями Неназываемых...
Говорят, jabber
Говорят, jabber J2ME-шный, вроде, существует в природе
Напомнили, я себе как раз где-то в 2000-х покупал Nokia 6820, такую специфичную раскладушку с относительно полноценной клавиатурой, специально под jabber J2ME-шный.
Чертовщина
Чертовщина какая-то. Интересно, остались ли ещё в продаже кнопочники, не несущие на себе ip-стек.
А вот это уже
А вот это уже хуже, да. Просто отвратительно.
Имя массива = адрес его начала
Здравствуйте! Перечитываю второй том, и вернулся к теме многомерных массивов. Но вопрос связан не с ними. На странице 223 вы пишете что во всех случаях кроме применения sizeof и еще двух экзотических ситуаций, имя массива есть адрес его начала. Но об этих двух ситуациях ничего не сказано. Не могли бы вы рассказать о них здесь?
Вот за каким
Вот за каким дьяволом вам это надо, а? Бывают такие знания, от которых вреда, может, и нет, но уж пользы точно никакой. Я совершенно не случайно эти случаи не стал описывать в книге.
Раз уж спросили, случаев, когда массив НЕ преобразуется к адресу своего первого элемента, формально "стандарты" вводят три: если он выступает аргументом sizeof, если к нему применена операция взятия адреса (результатом становится адрес типа "указатель на массив"; не спрашивайте меня, зачем это нужно, и что курили авторы "стандартов" — я тоже не знаю) и строковый литерал в инициализаторе массива char'ов, вроде вот такого:
(здесь ещё догадаться надо, какой конкретно массив "не преобразуется" -- имеется в виду тот, что справа от знака равенства, то есть именно строковый литерал, а не что-то иное).
Дальше прямо как в том анекдоте: "и что, полегчало?"
> здесь ещё
> здесь ещё догадаться надо, какой конкретно массив "не преобразуется"
Справедливости ради, не так это и сложно. Достаточно помнить, что записи
эквивалентны друг другу. А воспринимать конструкцию в фигурных скобках как что-то, что сводится к "адресу первого элемента", как-то трудновато.
Массивы
записи
эквивалентны друг другу
В s1[] терминирующий нуль будет конечным элементом.
воспринимать конструкцию в фигурных скобках как что-то, что сводится к "адресу первого элемента", как-то трудновато
Да вроде вполне логично. Как раз таки набор символов явно намекает на расположение в ячейках памяти. Строка как раз с такого угла зрения хуже воспринимается. Хотя и тут '\0' как бы намекает на набор байтов.
Да, забыл 0
Да, забыл 0 добавить :( Ох уж этот синтаксический сахар...
> Как раз таки набор символов явно намекает на расположение в ячейках памяти.
Так-то да, этот набор и лежит где-то в памяти (м.б., в .text или .rodata), но дело немного о другом. Когда мы содержимым этой области памяти заполняем массив символов, созданный, например, на стеке, то вряд ли будем думать об адресе этой области, скорее уж об её содержимом. В добавок ко всему, конструкцию в фигурных скобках нельзя, например, в фукцию передать или присвоить указателю на const char (т.е. адресной переменной), а строковый литерал как раз можно.
Знакомьтесь, Си
Драсте. Ну значит-с занялся я изучением второго тома. Уже прошел часть про Си. И очень им заинтересовался, поскольку: "ВАу! На нем написана целая ОСь которой я пользуюсь! ВАу!". У меня возникло два вопроса.
1) В вашем томе, я так понял, описаны почти все возможности языка Си (их правда мало, чувствуется связь с ассемблером). Я хочу продвинуться дальше. И поглядываю на разного рода библиотеки. То бишь, на моем, получается, начале пути, не будет ли вредно пользоваться готовым решением др. программистов? (библиотек и всего прочего). А также, на что обращать внимание при выборе литературы? Куда ни глянь, везде так и пестрят C98, ANSI C, т.е. стандарты, которые я тоже недолюбливаю.
2) Отсюда вытекает второй вопрос. Вот вы сказали, что рисование окошек вредит мышлению. Не имею ничего против, хотя свистоперделки именно делать очень нравится (и я уже как-то у вас спрашивал и вы ответили, что если сам напишешь библиотеку всех этих "менюшек и окошек", то это будет полезно. Попробовал - абсолютно согласен. Правда времени ушло много и все что я получил... Да.). Но, напротив этого, вы же приводите целый параграф изучения ncurses, и в конце упомянули menu, panel, cdk. Т.е., как я понял, готовые библиотеки для рисования окошек, менюшек, и даже (!) целых виджетов наподобие кнопок. Неужели к этому моменту я должен постигнуть таких высот, чтобы не париться об этом? :)
P.s. Хочу отметить, что когда я начал изучать про ncurses, я начал думать, дескать: "как бы выглядела моя программа? Мм, да, вот тут окошко, здесь вылезающая менюшка...". Это и есть нечто плохое?
Так-с, ну прежде
Так-с, ну прежде всего: "продвинуться дальше" и "поглядывать на библиотеки" — это противоречащие друг другу тезисы. Если хотите продвинуться в программировании, надо учиться своё писать, а не чужое пользовать.
ncurses я в книжку включил по достаточно простой причине: в псскалевской части есть crt, как бы нехорошо при переходе на Си понижать множество доступных возможностей. А самостоятельно сделать аналог ncurses довольно сложно, слишком многое нужно учитывать (например, базу данных по возможностям различных терминалов, известную под именем termcap — тут ещё такая сложность, что её тупо не на чем проверять, где вы сейчас какой-нибудь VT52 найдёте).
По поводу выбора литератувры конкретно по Си нужно обращать внимание, очевидно, на год издания. Всё, что после 1999 года, как правило, ориентировано на C99 (и более поздние так называемые "стандарты"), а это уже не Си, это коллективный бред стада агрессивных дебилов. Книги, подобные моей — изданные после 1999 года, но C99 не рассматривающие — возможно, встречаются, но мне не попадались. Впрочем, я сомневаюсь, что вам нужна литература именно по Си, этот язык во втором томе рассмотрен достаточно подробно. Вот по языкам из третьего тома, если их профессионально осваивать, дополнительная литература потребуется, это без вариантов.
И да, к моменту, когда вы начнёте использование библиотек виджетов текстового режима, крайне желательно уже обрести уверенность в собственной способности их реализовать ручками.
Ну а продумывать вид рабочего экрана, разумеется, рано или поздно придётся, если вообще предполагать использование полноэкранного интерфейса. Вопрос не в том, какие мысли, вопрос в том, когда, то есть на каком этапе они начинают приходить в голову. Когда функциональность программы более-менее определена (с точностью до файлов и их форматов, например, а также всяких используемых сетевых протоколов и прочего), и автор программы, например, понимает, как должна выглядеть эта программа, если полноэкранного интерфейса к ней не будет (например, будет какая-нибудь командная строка типа gdb'шной или что-то ещё), то да, продумывать внешний вид интерфейса уже можно начинать. Если же мы ещё толком не поняли, что программа должна делать, но уже начинаем думать про окошки и менюшки — ну, это плохо. Это вообще ужасно.
сделать аналог
сделать аналог ncurses довольно сложно, слишком многое нужно учитывать (например, базу данных по возможностям различных терминалов, известную под именем termcap — тут ещё такая сложность, что её тупо не на чем проверять, где вы сейчас какой-нибудь VT52 найдёте).Но сделать аналог crt или минимального подмножества curses не сложно, если cпециально не усложнять.
У нас нет сейчас острой необходимости повторять хитрости авторов vi, curses и EMACS, чтобы обновлять экран кратчайшей последовательностью команд, используя особенности терминала прошлого тысячелетия, который нам никогда и не встретится, если мы не займёмся археологией.
Достаточно использовать в программе только необходимое минимальное количество команд из ECMA-48, на обработку которых можно настроить любой используемый эмулятор терминала. Например, для вывода это могут быть
С автоматическим определением размеров окна эмулятора чуть сложнее, но это и curses в свое время не умела, так как пользователи не могли произвольно изменять физические размеры CRT терминалов подобно тому, как это стали делать позже пользователи программ, подобных xterm.
Для ТС: скачать ненавистный стандарт можно бесплатно без регистрации на официальном сайте
https://www.ecma-international.org/publications-and-standards/standards/...
Стандарт стандартом, главное - тестирование понимания и поведения существующих реализаций.
Доброго
Доброго времени суток! Честно, не люблю задавать вопросы, так как считаю, что в интернете есть все, но в этом случае я просто запутался. В данном случае экспериментировал с многомерным массивом после прочтения части по си. Если руководствоваться примером из книги (варианта в 4 томах), то создаю указатель на массив я правильно, с передачей его, как параметра, пришлось уже потанцевать. Неужели эта функция может работать только с такой "шириной" и написать ее в более общем виде нельзя? Заранее извиняюсь, если вопрос глупый. Честно говоря, не успел еще освоиться в си.
На практике
На практике указатели на массивы в явном виде применяются крайне редко — я не случайно в книжке написал, что всей этой машинерией не владеет каждый второй профессиональный сишник. Обычно функции такого рода пишут как работающие с одномерным массивом, а координаты (строка,столбец) переводят в расстояние от начала массива "руками", это проще, чем вот эти вот все "танцы".
Плюс доступ к
Плюс доступ к многомерному массиву, вытянутому по строкам в памяти, будет быстрее - элементы такого массива лежат в памяти рядом, и если в цикле бегать по массиву с правильным порядком измерений (сначала по первому измерению, потом по второму и так далее), то есть бОльшая вероятность, что соседние элементы массива поместятся в одну кэш-линию процессора, и фактических чтений из памяти будет меньше.
А если массив реализован в виде "массив указателей, каждый элемент которого указатель на массив с указателями и так далее", то он будет в памяти уже по разным местам разбросан, и скорость доступа будет меньше.
У меня, когда я
У меня, когда я подобное слышу, автоматически возникает вопрос: понимаете ли вы, что двумерные (и вообще многомерные) массивы в Си реализованы без каких бы то ни было намёков на массивы указателей? Ну то есть хорошо ли вы понимаете, что, если я описываю
-- то это у меня в памяти будет 200 интов по 4 байта каждый, и, чёрт подери, ни одного грёбаного указателя, если, конечно, указатель рассматривать именно как переменную (т.е. область памяти), хранящую адрес?
Да, я понимаю,
Да, я понимаю, что обычный многомерный массив - это просто последовательность байт, лежащих впритык друг к другу в памяти без намека на какие-либо указатели (ну кроме указателя на первый элемент, конечно).
Я просто подумал, что человек, задавший вопрос, почему-то захотел пользоваться двумерным массивом, реализованным именно как массив указателей на массивы - так ведь тоже можно сделать (объявив массив по-другому), и синтаксис обращения к элементу, насколько я помню, останется таким же: a[2][2] (компилятор, кажется, в разные конструкции это преобразует - для обычного двумерного массива в *(a + 2 * n_cols + 2), а для массива указателей в *(*(a + 2) + 2) ).
В С массивов нет
Я просто подумал, что человек, задавший вопрос, почему-то захотел пользоваться двумерным массивом, реализованным именно как массив указателей на массивы
Скорее всего человек уже испортил себе мозг какой-нибудь жабой и теперь усложняет реализации. Ну вот нет никаких массивов на уровне железа, есть последовательность байт. Из этой последовательности можно лепить что нужно. И какой массив будет по размерности - это дело десятое. Это вот стремление к манипуляциям массивами (которых, внезапно, в С нет) "целиком" - явное следствие разработки на ЯП со встроенной структурой данных "массив", жабой там, или, не дай бог, пайтоном.
Ойдаладно. На
Ойдаладно. На уровне железа и ветвлений с циклами нет, одни переходы. И процедур с функциями тоже нет, только куски кода и адреса. Что ж теперь, удавиться с горя?
Массив — абстракция вполне себе годная, как, впрочем, и запись/структура/кортеж, как его/её ни называй. И что в Си их нет — уж точно не достоинство Си, а наоборот.
Массив - дело тонкое
С одной стороны, таки да - полноценных массивов в С хочется.
А вот с другой- как только мы хотим в языке иметь полноценные массивы возникают такие вопросы как:
1)А как мы будем их передавать в функции/процедуры/подпрограммы? По ссылке или по значению? И если по ссылке, то что будет с консистентностью семантики?
2)Какие у нас будут языковые возможности по работе с этими массивами как с сущностями - размер узнать можно? а под-массив можно выделить? и т.д.
3)А что делать с массивами размеры которых при компиляции неизвестны - как именно с ними работать можно будет? Пусть даже, как в С, сама аллокация и вынесена в библиотеку - описывать-то такие сущности (или их пререквизиты) как-то надо.
Понятно, что на все эти вопросы ответить можно, но ответы будут влиять на runtime library, семантику и синтаксис. В результате имеем на одном конце "шкалы" С c его недомассивами и семантическим монстриком из простыни в примере, а на другом-нет, даже не python (причем в python массивов-то вообще-то нет. Они там появляются если поставить и подключить соответствующие модули), а относительно современный (начиная с 90-го) Fortran
в котором можно написать зверя вида:
Но во что именно оно при компиляции превратиться (и когда какой компилятор на ней переклинит) - лучше не думать.
Впрочем можно даже и на уровне F77. Конструкции вида
уже делает работу с массивами (для компиляции и runtime) сравнительно трудоемкой.
Я не сказал бы,
Я не сказал бы, что в наши дни стоит всерьёз опасаться этих вопросов. Есть пример версий Паскаля от Borland (позже -- от Embarcadero), где вполне себе уживаются классические паскалевские массивы, размер которых зашит в их типе, динамические массивы, размер которых можно менять встроенными процедурами, и адресная арифметика прямо-таки в сишном виде. Получилось, возможно, не очень красиво, но по мне так это, как водится, из-за груза совместимости с предыдущими версиями.
А что будет с zero runtime?
И это всё не требует поддержки runtime библиотеки? Что-то я в сомнениях. Особенно в части динамические массивы, размер которых можно менять встроенными процедурами
Мы же разговор начали с С, а не с поддержки массивов вообще.
Т.е. можно ли было бы добавить в С полноценные массивы, сохранив его достоинства?
Нединамические
Нединамические массивы с границами, неизвестными во время компиляции были ещё в Алгол-60
Динамические в этом языке более неуклюжи.begin integer n, m;
n := get_n; m := get_m;
begin
array a, b, c [7:n, 2:m], s [-2:10];
comment real по умолчанию;
В gcc с давних времён было аналогичное расширение.
Насколько я
Насколько я понимаю, это ровно то, что в C99 и более поздних "стандартах" называется VLA. Для меня это основная причина недопустимости применения C99 и всего, что за ним последовало.
Вообще говоря, вопросы работы с уже готовыми массивами и вопрос, в какой момент и в какой памяти массив расположить — это разные предметы.
Динамические
Динамические массивы в поздних версиях Turbo/Borland Pascal представляли собой откровенную полумеру, полноценная адресная арифметика, если я правильно это помню, появилась то ли в 7.0, то ли вообще уже в Delphi. Если изначально считать, что адресная арифметика должна присутствовать, то без этой полумеры (да, несомненно требующей поддержки от runtime, ибо там нужна динамическая память) можно вполне обойтись.
Что до адресной арифметики в сочетании с полноценными массивами, то я тут вообще никакой проблемы не вижу. Адресная арифметика вводится точно так же, как сейчас в Си, и объявления массивов — точно так же, как в существующем Си (ну, с точностью до того, что, наверное, "сложные описания" стоит сделать всегда идущими слева направо, но это уже другой вопрос), просто имя массива остаётся именем массива и к адресу первого элемента приводится только явно. Или можно даже разрешить неявно, но только тогда, когда "припрёт" -- например, при присваивании указателю соответствующего типа. Квадратные скобки станут чуть более полиморфными, но они и сейчас полиморфные (в смысле, работают с разными типами по-разному).
обычный
обычный многомерный массив - это просто последовательность байт, лежащих впритык друг к другу Может быть и не совсем впритык, а с выравниванием и заполнением.
Это вы путаете
Это вы путаете со структурами.
А вот кстати,
А вот кстати, вопрос.
Предположим, у нас есть структура с 3 полями типа char, int и short. В 90 процентов случаев эти поля будут занимать в памяти соответсвтенно 1, 4 и 2 байта, и компилятор, скорее всего, расположит элементы в порядке "int-short-char", добавит структуре лишний байт для округления (чтоб было 8, а не 7), и будет следить, чтобы вся структура всегда лежала в памяти по адресу, кратному 4 (чтоб процессору легче было из структуры инты выдирать).
А если рассмотреть массив (без разницы, какой размерности) таких структур, то могу ли я сказать, что компилятору придется и массив разместить в памяти так, чтобы первый его элемент (а значит, и каждый) обязательно располагался по адресу, кратному 4? То есть, получается, выравнивание по расположению в памяти и для массивов верно?
Sizeof всегда
Sizeof всегда кратен выравниванию в Си. Для нарушения правил выравнивания в компиляторе могут быть прагмы или ещё какие-то хитрости, но тогда и выравнивание всей структуры может получиться более мелкое.
Таким образом, байтовые "дырки", как уже было отмечено, с точки зрения Си располагаются "внутри" элементов массива, а не "между" ними.
Тут вот это вот
Тут вот это вот "кратен выравниванию" допускает разные толкования. Насколько я понимаю, он кратен наибольшей величине выравнивания, применённой в данной конкретной структуре. Например, если в структуре все поля типа char, то её sizeof вполне может быть вообще нечётным, то есть никакого выравнивания не будет — но для char'ов оно и не нужно.
Если мне
Если мне склероз не изменяет, компилятор не переставляет поля местами, он только имеет право вставлять неиспользуемые байты для выравнивания. А ещё там действует какое-то хитрое правило, что размер структуры целиком, если в ней есть хотя бы один int, будет кратен sizeof(int), и то же самое для short, вот для long'ов не уверен.
Короче говоря, в итоге паддинг для массивов оказывается не нужен, с задачей справляется паддинг самих структур.
компилятор не
компилятор не переставляет поля местами
Сишный -- нет, но, кстати говоря, есть языки, где может переставлять для экономии памяти, если явно не запретить. Zig, в частности.
Судя по
Судя по простыне кода, которую он сюда запостил, ему зачем-то захотелось всенепременнейшим образом задействовать сишного семантического монстрика, именуемого указателем на массив (не на первый элемент массива, а именно вот указатель на массив, такая штука есть, да :) )
Впрочем, простыня вообще производит удручающее впечатление. С одной стороны, целочисленные константы вводятся олдскульно макропроцессором, а с другой — описание переменной цикла в заголовке цикла, я себе такого даже в плюсах не позволяю, откуда это изначально пришло, а уж в чистом си такое писать... гм... вот прямо на канделябр нарываться. Я даже не уверен, что это новомодные стандарты позволяют, по-моему это gnu extension.
Мне кажется,
Мне кажется, чтобы начинающий сишник понял, в чём здесь дело, ему нужно вернуться «в начало» - осознать, что таки в Си нет массивов, они эмулируются указателями, и что конструкция x[i] - это в точности вот что: *(x+i)
Соответственно, x[i][j] - это в точности вот что: *(x[i]+j), или, раскрывая дальше, *(*(x+i)+j)
Далее надо вспомнить, что выражение вида a+b, где a - указатель, b - целое, это не адрес следующей ячейки памяти, а указатель на следующий элемент последовательности, на которую указывает a, т. е. если a имеет тип int *, то в плоской модели памяти на 32-битном процессоре a+1 будет указывать на ячейку памяти на расстоянии 4 байта от a, а если b имеет тип char, то (b+1) будет указывать на ячейку памяти на расстоянии 1 байт от b.
Соответственно, если x имеет тип "указатель на массив длиной в десять int" - то x+1 будет указывать на ячейку на расстоянии 10*4=40 байт от x.
Именно поэтому автор исходного вопроса прав — без WIDTH никак не обойтись, ни предложенным им способом, ни переводя вручную.
В книжке это
В книжке это параграф 4.9.1, там всё это есть, и ТС его наверняка читал, иначе вряд ли догадался бы, что этот монстр в Си вообще присутствует. Проблема, подозреваю, не в этом.
Спасибо всем, кто ответил!
Некоторые уже похоже даже поставили крест на моем успешном освоении языка в будущем xd
Хотел оправдаться по поводу использования макроопределений для объявления целочисленных констант, это было сделано в качестве некой тренировки. Стараюсь при всех экспериментах применять некоторые инструменты, которые описаны в книге, даже если они не особо нужны. Причины, по которым следует использовать перечислимый тип, мне оказались вполне ясны.
По поводу описания переменной цикла, действительно никогда не обращал внимания, когда то увидел такое и пользовался вплоть до вашего замечания. Не могли бы вы прояснить, по какой причине плохо использовать данную возможность? Обратив внимание на то, как делают это другие, заметил, что один небезызвестный на просторах ютуба преподаватель мфти использует данную возможность в языке си. Получается, его ученики могут писать код несколько грубовато. Но я "нарываться" пока более не планирую xd
По поводу массивов. Что важнее. Поигрался несколько дней с ними. Я планировал найти удобоваримое представление для своих элементов двумерного поля. Конечно, я вполне отдаю себе отчет в том, когда элементы лежат подряд. И даже понимаю, почему нам нужна "ширина" для работы с двумерным массивом. Почему бы мне просто не создать указатель и не выделить память вручную, вместо того, чтобы использовать одномерный массив и положить в него двумерный массив, что уже с самого начала порождает нелогичность.(: Керниган и Ритчи в своей книге вообще по-моему по приколу написали про multi-dimensional arrays. Точнее про передачу их в функцию. Что это за функция будет такая, которая работает с массивом только одной ширины, но разной длинны.
по поводу
по поводу использования макроопределений
В действительности всё не столь однозначно. Во-первых, enum'ы предназначены не для этого, так что получается очередной хак (ну хотя Си из хаков практически состоит, так что одним больше, одним меньше, не шибко большая разница). Во-вторых, константы бывают не только целочисленные, и для всех остальных по-любому придётся использовать макросы, так что я вполне понял бы программиста, предпочитающего макросы использовать для любых констант, в том числе и целых, просто из соображений единообразия. Ну и в-третьих: вы использовали технику, которая довольно широко применяется — если символ не определён, определить его неким значением по умолчанию, а вот если определён, то пусть так и будет. Это, как мы понимаем, позволяет, не меняя исходник, поменять значения констант в получаемой откомпилированной программе, задав соответствующие значения в командной строке компилятора. На enum'ах такого не сделать.
по какой причине плохо использовать данную возможность?
По такой, что в языке Си этой "возможности" нет. А C99 — это уже не Си, это бастард. Если допустить из него хоть что-то, будет крайне сложно объяснить, например, партнёрам по проекту, почему нельзя применять те же VLA.
один небезызвестный
Я таких только лично знаю не один десяток (хотя конкретно этого вашего ютьюбера лично не знаю), и что теперь, пойти утопиться?
Керниган и Ритчи в своей книге вообще по-моему по приколу написали про multi-dimensional arrays
Сущность "указатель на массив" появилась вполне логично, многомерные массивы как-то надо было заставить работать, и я бы даже сказал, что по-своему эта штука весьма красива — всё-таки удачно выкрутились, ничего не скажешь. Но да, применение указателей на массивы в явном виде — это крайне экзотическая штука, мне, например, не удалось придумать реальную задачу, в которой такое могло бы потребоваться. Но написали-то они не так чтобы по приколу, им надо было объяснить публике, что за фигня получилась, вот и объяснили.
по-моему это gnu
по-моему это gnu extension
Увы, C99 и новее...
?! ну в C11 я бы
?! ну в C11 я бы поверил
Нет, это С99.
Нет, это С99. Здесь (пункт 2), например, можно посмотреть. Вроде это даже тут где-то обсуждалось.
А здесь можно вещи похлеще найти.
Конечные пользователи
Если моим модулем для работы с терминалом (со скроллингом, несколькими образами терминалов, средствами для дебага через ключи компиляции и другими разными ништяками) пользуется мой друг программист, можно ли считать, что я получил конечного пользователя или это обязательно должен быть человек не связанный с компьютерами? И почему именно про таких пользователей вы говорите в книге и здесь? Вопрос животрепещущий.
Я думаю, можно
Я думаю, можно — уж если программисты могут использовать ваши библиотеки, то за конечным пользователем дело не станет.
Devuan
Здравствуйте, какой devuan лучше поставить: первую jessie(LTS) или последнюю версию chimaera.
TL;DR Если нужен
TL;DR Если нужен именно Девуан, то лучше ставить Beowulf и не обновлять его до Chimaera.
Недавно пытался поставить server-редакцию Химеры (4.0), установщик даже не загрузился, у него не получилось создать/открыть какой-то файл и он ушёл в цикл, пытаясь его открыть/создать. Бэовульф (3.0) спокойно загрузился и поставился, затем я обновил его до Химеры. Весь мой мир ужаснулся, когда я увидел ЧТО лезет из репозиториев при попытке поставить OpenSSH (я делал минимальную установку, поэтому в меню при установке не выбрал OpenSSH). Он на серьёзных щщах тянул за собой в зависимостях пакеты adwaita-icon-theme и всякое *-gnome. На сервере без иксов, где только голая консоль. Я не стал об этом репортить (не знаю как это делать, да и после шока не было желания) и пошёл поставил другой Линукс-дистрибутив.
Вообще, я уже не в первый раз замечаю такие проблемы с зависимостями у не очень популярных дистрибутивов. Поэтому хотел бы попросить обращать внимание на то, что packet manager тянет в зависимостях.
Жёстко.
Жёстко. Интересно, у Дебиана аналогичной версии такая же хрень творится? Вроде пакетная база у них почти общая.
Я поставил
Я поставил Дебиан 11, тоже без OpenSSH. Там в зависимостях всё нормально оказалось, специально проверил. У меня ощущение сложилось, будто мейнтейнеры Девуана просто по ошибке что-то куда-то не туда в конфигах сборки/зависимостей написали
Зависимости
Зависимости пакета прописываются в спеке самого пакета, это его составная часть. Я сильно сомневаюсь, что девуановской команде хватает времени переписывать все дебиановские спеки, скорее всего они там перепахивают только те пакеты, которые повязаны на systemd.
Но что openssh за собой гнома потянул — это где же так накосячить-то надо было, а?...
Вы меня
Вы меня заинтересовали :-)
Скачал я файл Sources.gz по ссылке http://deb.devuan.org/merged/dists/chimaera/main/source/
Там есть такие строки:
Package: openssh
Binary: openssh-client, openssh-server, openssh-sftp-server, openssh-tests, ssh, ssh-askpass-gnome, openssh-client-udeb, openssh-server-udeb
Пошёл сюда: https://packages.debian.org/stable/gnome/ssh-askpass-gnome
Там такая строка:
Этот пакет был отделён от основного пакета openssh-client для того, чтобы openssh-client не зависел от GTK+.
В дебиане, кстати, openssh зависит от systemd (даже в отрыве от гномозависимостей, во прикол): https://packages.debian.org/stable/openssh-server
dep: libsystemd0
библиотека утилит systemd
Так что, видимо, всё таки спеку они меняли
Потому и
Потому и меняли, ага. Так а это что получается, openssh сам по себе превращается в метапакет, который ставит их все сразу? То есть можно поставить отдельно openssh-server и сам ssh, тогда всё будет нормально, но это же ещё знать надо...
Beowulf будет в
Beowulf будет в самый раз. В Chimaera sudo идет из коробки, каких ещё "сюрпризов" ожидать от него непонятно. Жалею, что установил четвертую версию.
sudo по-моему во
sudo по-моему во всех из коробки, не? apt-get remove спасёт гиганта мысли.
jessie, я бы
jessie, я бы сказал, старовата. Странно, что нет более поздних LTSок.
Ребёнок и компьютер
Решил тут поделиться родительской мыслью.
Ребёнок очень любит комп, но т.к. я на работе весь день и следить за его времяпрепровождением не могу, то просто блокировал комп и все с ним действия ребёнок мог производить лишь когда я дома.
А ребёнок-то постоянно у меня допытывался, Папа - какой у тебя пароль-то? Ну какой?
И я решил, так заведу просто сыну учётку, без прав на запуск иксов и прочего, пускай себе в консольке сидит. Сказано - сделано. Учётку создал, пароль он сам установил на неё.
И там есть парочка консольных игрух, типа ctris, cavezofphear и freepascal. И сегодня ушёл на работу, а сам поглядываю - зашёл или нет? Что запустил. Так ведь зашёл малец, сперва понятно игрухи видимо поиграл, но сильно долго-то в них всё равно надоест, и пошёл он в fp. Понимаю, что IDE - зло, но пока показал ему так. Более того, у меня книги ваши лежат на столе и значит первый том он взял, я ему показал там парочку листингов (простейших, где writeln'ы только), что типа вот по этой книге паскалю можно отлично научиться.
И вижу что в домашнем каталоге появляются .pas файлы, со всякими там writeln'ами и выражениями.
Т.е. реализуется схема вида: Ребёнок остался один на один с консолью и книжкой и интересом чего-то поделать и в остальном с полной свободой действий :)
Поглядим что будет получаться. Буду приходить и появившиеся за день вопросы и непонятки объяснять и какие-то базовые понятия связанные с ОС и консолью разъяснять.
Блин, дайте в 6
Блин, дайте в 6 лет ребенку быть ребенком! Вот у меня у самого ростет ребенок 6-ти лет. Ну блин, ребенок ведь! Не надо обирать детство из-за каких-то своих амибиций. Ему в жизни хватит еще всего этого!
Крайне несогласен
Вот у меня в детстве самая ненавистная фраза была "Тебе еще рано". И физику мне рано, и писать научиться мне рано.
Хватит делать из детей непонятно что. Хочет ребенок и занимается.
Никто не спорит
Никто не спорит с тем, что ребенку надо давать делать то, что он желает. И ничего не рано, если ребенок сам хочет! Но в конкретном случае я вижу желание папы (само желание не есть плохое) посадить ребенка в 6 лет за комп именно для того, чтоб освоить, например, консоль. А ребенок хочет играть! Потому тут я вижу амбицию папы, а ни желание ребенка. А это не есть правильно. Так можно получить результат противоположенный желаемому: у ребенка эта ситуация осядет в памяти, он запомнит, как хотел играть а вместо этого папа его посадил за консоль, и потом в жизни из-за принципа будет сидеть на Виндовс.
Уж лучше тогда подыскать игру, которая ребенку будет нравится и при этом развивает определенные навыки: вот от этого пользы будет заметно больше! И купить в придачу конструкторов несколько. Можно и разных. Пускай делает из них, что ему придет в голову!
А еще этот возвраст хорош для того, чтоб ребенок по мультикам начал освоение английского языка. Вот что пригодится в любом случае! Мультики детям нравятся, можно и не сомневаться в этом. Так почему же не использовать это и не включать ребенку мульты на английском?! Я своему малому в основном именно на английском включаю мультики, так когдя мы смотрим эти мульты вместе, он мне фразы переводит, и уже говорит не много на английском.
Как-то так...
Да вот нету тут
Да вот нету тут никакой амбиции папы. Ну то есть она, может, и есть, но ребёнку этого не видно: он же в комп, в эту самую командную строку, лазит тайком от папы, пока папа на работе!
Кстати да, у
Кстати да, у меня в целом та же фигня, поэтому я тут спорить полез. Хотя у меня ещё и дополнительное пикантное обстоятельство: фразу "тебе ещё рано" и её аналоги я слышал только от бабушки, остальные взрослые, окружавшие меня в детстве, оказались более адекватными. А бабушка умела офигенно вкусно готовить, но этим её достоинства исчерпывались.
Что значит быть ребёнком?
Oliver, все дети разные! Что делать, если у ребёнка не вполне получается быть ребёнком?
Конечно, если дать здоровому 6-летнему игрушку, то он с ней и будет играть. Будь это шашки, комп или бабушкины бигуди. Не следует только слишком серьёзно относится к любым занятиям в детстве.
В упор не вижу,
В упор не вижу, где тут у ребёнка "не получается быть ребёнком". Очень даже получается. Да и как это вообще может "не получиться" быть ребёнком?
Вот когда не дают быть ребёнком — это да, такое бывает. Когда заставляют делать не то, к чему ребёнок сам тянется, а то, что взрослым кажется "нужным и полезным". Но ключевое слово тут "заставляют". Или из-под палки, или всякими вознаграждениями вроде "пойдёшь в секцию -- игрушку куплю, в соревнованиях победишь -- куплю ещё одну". Но в рассматриваемом случае ничего похожего не наблюдается.
Какие нахрен
Какие нахрен амбиции, ребёнка тут что, кто-то заставлял в компьютер лезть? Ни фига, он сам полез, и не просто добровольно, а когда папы дома нет.
Я бы сказал, что тут ребёнку позволяется быть ребёнком намного больше, чем тем деткам, которых в детском саду грузят цифрой три.
Что означает
Что означает "грузят цифрой три"?
Ну типа вот тут
Ну типа вот тут топикстартер упоминал, что его ребёнку в детском садике скучно среди сверстников, потому что им там про цифру три рассказывают (а он-то, по-видимому, и три, и триста тридцать три уже и так знает, благо это как раз несложно, надо только с ребёнком иногда заниматься).
Мой 6-ти летний
Мой 6-ти летний малой тоже у компа проводит некое время. Сегодня время провождение времени за компом у ребенка - не есть новость. Сегодня куда труднее ребенка от этого самого компа оттащить! :)
Оттаскивать,
Оттаскивать, насколько я могу судить, бесполезно. В обсуждаемой ситуации получилось намного лучше: вместо того, чтобы гонять всякие стрелялки, ребёнок развивает собственные мозги. Причём, что характерно, сам развивает, добровольно, даже слегка "тайком от папы". Я бы сказал, epic win.
Когда надоест
Когда надоест комп, пусть попросит Деда Мороза принести пару макеток, батареек, мешок транзисторов и светодиодов
, а также техническое описание PDP-8А сколько ему
А сколько ему лет? Я просто представляю 6 летнего ребёнка, и как он в консоли сидит.. Классно, что вы его знакомство с компьютерами начали с консоли. Тех кто не знаком с GUI намного легче пересадить на консоль, иначе начинаются претензии, что мол на дворе XXI век.
Я в дестве, мог разобрать компьютер, и прочую быт. технику и как-то остался жив и не умер от того, что меня несколько раз ударило током, я один раз игрался рядом с бензином вместе со спичками, и так далее, вам как родителю о тех приколах, что я вытворял лучше не знать. Но это не потому, что родители плохо следили, а потому что я был очень хитрым и любознательным ребенком. Дали бы мне тогда консоль, этот конструктор (Unix) я бы освоил в совершенстве.
А вы не пытались ему показывать, исходники программ, в которые он играет, т.е. что вы написали или из интернета скачали. Типа смотри, вот в то, что ты играешь можно сделать самому. Меня когда-то мысль, что можно вообще-то ОС, и вот это вот всё в компьютере самому написать просто взорвала мозг, вот прямо градус интузиазма на этом месте повысился до температуры солнца.
Правильная консоль?
> представляю 6 летнего ребёнка, и как он в консоли сидит.. Классно, что вы его знакомство с компьютерами начали с консоли.
6-летнему ребёнку может быть интереснее и полезнее консоль из лампочек, проводочков и кнопочек, а не эмулятор терминала на фреймбуфере.
Может, и да. А
Может, и да. А может, и нет. Пока что точно известно, что консоль его заинтересовала. Заинтересуют ли его лампочки и кнопочки — можно проверить только одним способом: подсунуть эти самые лампочки с кнопочками и посмотреть на результат.
Ламповая консоль
Если на третьем бите заскучает, то цифровую электронику можно отложить на 3-4 года.
> Я в дестве, мог
> Я в дестве, мог разобрать компьютер, и прочую быт. технику и как-то остался жив и не умер от того, что меня несколько раз ударило током, я один раз игрался рядом с бензином вместе со спичками, и так далее...
Вам крупно повезло, что не получили тяжелые травмы! Тут кичиться абсолютно нечем! Не всем детям так везет
Знаете у меня
Знаете у меня это получалось даже вопроки воле родителей, как бы они не старались. Если бы меня запирали вообще я бы тоже что-то нашел бы, а меня часто запирали))), чаще вместе с сестрой, "чтобы скучно не было". И могу сказать сейчас благодаря моему характеру и склонностям, и тем интересам, которые возникли "тогда", мне никогда не бывает скучно, вот прямо вообще, я могу из камней знания вытащить, что говорит про компьютер...
От гиперопеки в современном мире нужно избавляться, имхо. Я вообще убежден, что детей нельзя растить в городе. Только в селе, только хардкор, чтобы и имунитет укреплялся, и чтобы к природе и к животным привык, а не то, что я вижу у своих взрослых братьев и сестер, которые живут в городе. Человек радовался! Радовался, что есть в многоэтажке площадка для игр. Я бы в таком доме не то, чтобы не жил и растил детей, я бы ни за какие пряники бы туда не пошел. Иначе начинается, вот он в грязи повалялся, теперь микробов нахватается, давайте сейчас его укутаем на зиму, так чтобы ему жизнь сахаром не казалось и т.д. Если что я с 8 класса живу в городе по учебе и сейчас 2 курс, я у себя дома код пишу в 2 раза быстрее, потому что нет такой информационной нагрузки, всяких баннеров, звуков машин, рекламы на каждом сантиметре, спасают только горы в выходные
Ага, а потом мы
Ага, а потом мы наблюдаем зрелище вида "ничего не интересно, не знаем, чего хотим, не понимаем, куда движемся, да и не хотим никуда двигаться". Обычный результат родительской гиперопеки.
Да, для развития полноценной личности необходим определённый риск в детстве, тут никуда не денешься. Иначе медуза аморфная вырастет.
Разумеется, все
Разумеется, все должно быть в меру, в том числе и родительская опека, но вот когда ребенок со спичками играет возле бензина, это - уже недоопека!
Проблема, к
Проблема, к сожалению, именно в том, что отследить возникновение такой ситуации, которая уже за гранью, без гиперопеки невозможно. Ну то есть стоит, несомненно, объяснить, что легковоспламеняющиеся жидкости — это несколько опаснее, чем может показаться по их внешнему виду, и даже, пожалуй, продемонстрировать -- ну там взять баночку из-под паштета, налить в неё грамм 50 бензина и где-нибудь в безопасной обстановке показать, как оно вспыхивает, как горит, что будет, если тушить водой, как надо тушить правильно, что будет, если разольётся, ну чтобы растущая личность не переоценивала свои возможности в укрощении стихии. Но полностью исключить ситуации, которые (да, согласен) уже на грани криминала, можно только одним способом — следить за каждым шагом. А это и есть гиперопека, увы.
Есть такая
Есть такая мысль, что современная гиперопека -- это следствие сокращения среднего количества детей в семье до одного-двух. Когда детей больше пяти-шести, то гибель одного даже для родителей не становится непереносимой трагедией, а уж для общества в целом и подавно. Ну и отбор работает, выживают, в среднем, более приспособленные. А также приспосабливаются в процессе выживания.
Откуда она
Откуда она взялась — понятно, меня больше волнует, к чему она приводит. Да ещё государство со своими дебильными законами её, опеку эту, всячески стимулирует.
Парадигмы надо менять, иначе вокруг будут одни медузы.
6 лет, из кода -
6 лет, из кода - мы с ним залезли в исходники консольного тетриса ctris, я конечно залез, но с ним вместе смотрели, я ему показал где задержка и как она формируется и сделали её чуть больше с целью чтобы тетрис не был таким хардкорным :)
А мне рассказывать, я же тоже из диких СССР'овских времён, когда дети проводили детство на улице, не уткнувшись в смартфон. Так что тоже являюсь представителем тех что выжил вопреки своей любознательности :)
Вот нафига
Вот нафига IDEшку-то показали? Если он так лихо справляется с консолью, то что же, с каким-нибудь nano и запуском компилятора не справится?
Да справится
Да справится конечно, разберёмся с IDE-шкой. Более того, учитывая, что там дикие сложности в простейшими "вырезать строку", закрыть "окно", т.к. всякие сочетания которые в IDE для этого указаны - обрабатываются консолью, я думаю довольно скоро перейдём в обычный текстовый редактор.
А вообще играть
А вообще играть Ваш ребёнок любит? С чем-нибудь кроме компьютера?
Играть любит
Играть любит конечно. В запоминалки (50 карточек попарных), шашки, шахматы. В игры с бумагой и ручкой. Охоты на лис там, морской бой и прочие крестики нолики.
Но в плане социального общения наблюдаются некоторые трудности, с детьми во дворе не очень находит общий язык.
Т.е. объективно конечно есть перекос в плане общения со сверстниками. Сыну не очень интересны беганья с другими детьми, и хотя общается с другими легко, но вот общего языка с другими детьми не всегда получается найти.
С вопросом обычной детской деятельности - наблюдаю, и в идеале видимо в какой-то коллектив детей, которые в своём дошкольном возрасте умеют уже хотя бы читать/писать, а с детьми с которыми сейчас в группе садиковой (он сейчас в старшей группе) и им рассказывают на занятиях про условно "цифру три", сколько это и как это посчитать - ну видимо сложно с общими интересами.
А так сам по себе весёлый и забавный ребёнок.
Если в садике скучновато
с детьми с которыми сейчас в группе садиковой (он сейчас в старшей группе) и им рассказывают на занятиях про условно "цифру три", сколько это и как это посчитать - ну видимо сложно с общими интересами.
А в школу в этом году не отдали, потому что ещё не было шести лет на первое сентября?
В таком
В таком возрасте больше пользы от собственноручной работы с конструкторами и пластилином, чем от общения с интерпретатором текстовых команд.
А коллектив из двух десятков сверстников - не совсем естественный. 2-3 года разницы (+/- в школьном возрасте) оптимально, если есть общее дело и интересы (условынй детский хор).
> В таком
> В таком возрасте больше пользы от собственноручной работы с конструкторами и пластилином, чем от общения с интерпретатором текстовых команд.
Я тоже уверен в том, что больше пользы будет от всяких разных комплектов Лего самой разной степени сложности! От того, что ребенок от нечего делать куда-то там залез, еще не значит, что это ему интересно и что он все это поймет.
Мой старшый все годы, наверное начиная с лет 4, очень много собрал разных Лего конструкторов, самой разной степени сложности. Сначала собирал то, что в инструкции показано, а потом из вкучу смешанных деталей собирал сам свое. С лет 10-11 ему начал рассказывать про Линукс и программирование, а не давно совсем обьяснял указатели на Паскале: вроде понял. Допускаю, что его опыт с Лего позитивно сказался на понимании тех же указателй.
лего
С лего есть довольно большая опасность в том, что лего формирует "квадратно-гнездовой" способ мышления, сильно оторванный от реальности. Из конструкторов те же клоны Meccano, например, на развитие конструкторского мышления влияют гораздо лучше. Речь, конечно, не о том, что играть в лего нельзя, но о том, что не стоит фанатично зацикливаться только на нём. К сожалению, идея лего кажется настолько яркой и привлекательной, что многие таки "фанатично зацикливаются".
А в программировании, кстати, устоявшийся "квадратно-гнездовой" способ мышления приводит к типичному макакингу.
> С лего есть
> С лего есть довольно большая опасность в том, что лего формирует "квадратно-гнездовой" способ мышления
Очень сомнительное утверждение.
Зря, кстати,
Зря, кстати, сомневаетесь. Такая проблема реально существует, и не только с лего, вообще с любыми конструкторами, где детали могут скрепляться между собой только фиксированными способами, условно говоря, где все углы прямые, а если не прямые — то только потому, что так задумано (в смысле, задумано создателями конструктора). Это тоже своего рода парадигма: есть некто, который "так задумал", и мы делаем так, как "он" задумал, а сами ничего задумать не можем.
Конкретно ЛЕГО
Конкретно ЛЕГО (оригинальное) вещь великолепная -- там детальки так устроены, что их можно и под углами ставить и я этим часто пользовался.
Вот есть Lego Duplo, вот это да, такое себе
Классический
Классический лего, т.е. детали с пупырышками сверху и отверстиями снизу, всё же имеет значительную степень "квадратности" и пространственной ориентированности всей конструкции пупырышками в одну сторону.
Но вот когда пошли все эти новые (ну как, новые - больше 20 лет точно...) "лего техник", где в основе конструкции балки и оси с отверстиями и без пупырышек вообще, здесь квадратно-гнездовая парадигма исчезает. При этом, что гениально, сохранается совместимость деталей с деталями классического лего!
Не даром говорят, что лего - лучшая игрушка в мире. Там и для программирования место нашлось: лего-роботс и его блок управления, для которого надо писать программу.
лего-роботс и
лего-роботс и его блок управления, для которого надо писать программу.Т.е. натаскивать программу из готовых кубиков?
Дети разные
Дети разные бывают. В в 10-11 уже кое-что ставить поздновато, например, если к этому времени не сформировалось понимание "что такое умножение", то и не сформируется.
Про указатели это ваше "кажется понял" ничего не будет стоить, пока он сам какую-нибудь "змейку" не напишет, где требуется список. Я такое вижу постоянно, пардон: тот, кто пытался учить, заявляет, что "вроде поняли", а в действительности там что-нибудь вроде "указатель -- это на столбе табличка такая".
Да и вообще "рассказывать" бесполезно в большинстве случаев. Нужно, чтоб сам захотел узнать, но при этом рассказывать не требуется, требуется только отвечать на вопросы и подсовывать нужные источники информации.
Разумеется,
Разумеется, время покажет, понял он их на самом деле. И разумеется, дети - разные. Моя мысль заключается в том, чтоб ребенку давать то, что будет разивать его мышление, что потом в жизни ему очень поможет понимать самые разные вещи. Любому ребенку. Как-то так...
Вот только не
Вот только не говорите, что от программирования и консольной работы с компом мышление не развивается. А с этим "давать" есть одна проблема: а ну как не возьмёт? В большинстве случаев после этого хоть тушкой, хоть чучелом -- но всучивают. И по-моему таки зря.
Развитие мышления
От работы с компом тем или иным способом замечательно развивается умение работать с компом этим способом.
С таким же
С таким же успехом можно заявить, что от игры в прятки развивается только умение играть в прятки. Это ложное утверждение.
off-topic
А что развивает игра в прятки?
Да до чёрта
Да до чёрта всего. Как и любая коллективная игра — навыки социального взаимодействия. Потом, естественно, умение быстро бегать. Умение оценивать свои силы и чужие возможности (вот добегу я сейчас до выручалочки или меня водящий заметит и успеет быстрее?) Наверняка специалисты ещё что-нибудь отметят.
Польза
Польза — понятие относительное. У меня в детстве были и конструкторы, и пластилин. Чего я никогда не делал — это не собирал из конструкторов ничего такого, что предлагалось в прилагаемой к конструктору книжке. Вот то есть я вообще не понимал, как это так — собирать то, что "надо", это же мой конструктор, что хочу, то и делаю; получались всегда исключительно бесформенные и дебильные хаотические соединения деталей. И из пластилина я никогда не лепил "что-то", просто зачем-то мял его в руках, получались всякие шарики, колбаски, блинчики, в целом "непойми что".
Не знаю, может, на мелкую моторику это как-то и влияло, но в целом полезность всей этой деятельности мне кажется сомнительной.
Assembler и дальнейшее обучение
Учусь по трехтомнику ("Программирование: введение в профессию"). До изучения ассемблера было очень интересно учиться, однако после.. После стало как-то не так, единственное что интересует сейчас - разобраться с сетями; есть ещё идея перейти на программирование микроконтроллеров (там ассемблер, + хочу разобраться с электрическими цепями и т.д.). Вопросы: могу ли я прочитать главу по сетям ( просто для саморазвития) и "программист ли я на самом деле" (Из предисловия - программированием заниматься можно только тогда, когда это "в кайф"; у меня же пропало желание этим заниматься, хотя оно было)?
Также хочу выделить пункт про микроконтроллеры - (если я всё же программист) можно ли залезть в ардуино (на первое время) или надо сразу перейти к низкому уровню (т.е. голые мк)?
Микроконтроллеры и ассемблер
есть ещё идея перейти на программирование микроконтроллеров (там ассемблер
Дался вам этот ассемблер ) Не надо на нём так циклиться - это просто ЯП. Разрабатывая под микроконтроллеры отличается в основном только необходимостью знания его микроархитектуры. И ассемблер там необходим только в роли "моста" между микроархитектурой и вашим ПО. Писать на нём стоит только в учебных целях.
хочу разобраться с электрическими цепями
Микроконтроллеры в этом особо не помогут. Хотя, конечно, зависит от того, что вы понимаете под "разобраться". Точнее на каком уровне.
[ZANUDA_MODE
[ZANUDA_MODE ON]
микроархитектурой
Таки архитектурой, микроархитектура подразумевает наличие внеархитектурного "программно-невидимого" состояния, к которому нет доступа ни из ассемблера, ни из Си, ни откуда-либо ещё.
[ZANUDA_MODE OFF]
Подходы к разработке
С точки зрения подходов к разработке для больших машин, разработка под МК фактически идёт на уровне микроархитектуры, т.к. здесь запросто может использоваться какая-нибудь маршрутизация запросов между контроллерами DMA и периферией. И вот с точки зрения "большой машины" это будет происходить именно на уровне микроархитектуры, т.к. здесь будет юзаться мультиплексор DMA. Но с точки зрения микроконтроллера это уровень архитектуры, да.
микроархитектура подразумевает наличие внеархитектурного "программно-невидимого" состояния, к которому нет доступа ни из ассемблера, ни из Си, ни откуда-либо ещё
Ну как бы да, но для общего развития знать микроархитектуту ядра МК знать полезно.
До того, как
До того, как взялись за трехтомник, у вас было вообще какое-то представление о работе программиста? Просто здесь есть, как минимум, два варианта - "слышал, что это круто, но посмотрел и, как говорят, 'ниасилил' или разочаровался, не совпали ожидания с реальностью" (хотя, раз духу хватило на ассемблер, это вряд ли подходит) и "нет желания подниматься уровнем выше, хочется остаться поближе к железу" (раз уж всплыли МК). Первый вариант комментировать вряд ли стоит, можно лишь сказать, что вовремя поняли, чем не хотите заниматься, что само по себе важно (тут неоднократно обсуждали, что надо быть тем ещё маньяком, чтобы от этого получать удовольствие). Если вариант второй, то нужно понимать, что, как и программирование "вообще", программирование микроконтроллеров и "электрические цепи" - очень обширное понятие. В любом случае, человеку, знакомому с программированием, "въехать" в МК проще - обычно переход (ну, по крайней мере, до засилия Arduino и шумихи вокруг IoT) происходит в обратном направлении, когда "железячник" решает влезть в программирование, у него, чаще всего, нет представления ни об архитектуре программ, ни об "управлении сложностью", если так можно выразиться, поэтому порождаются весьма причудливые и монструозные конструкции. Что до ассемблера, тут поддержу Андрея Викторовича - и в МК для него места немного осталось. Сейчас нет необходимости жёсткой экономии каждого байта, тем более, что сейчас более популярны МК на ARM, а тамошний ассемблер с бесчисленными префиксами-суффиксами у команд, вообще, имхо, больше ориентирован на машинную обработку, чем на запись человеком. Да и задачи, решаемые на МК, бывают сильно разными. Можно посоветовать тех же Харрисов, "Цифровая схемотехника и архитектура компьютера", если есть желание покопаться в железе. Там, в конечном счете, тоже дело доходит до ассемблера и Си в минимальном изложении, но "с другой стороны". Если уж так тянет в ассемблер для AVR - есть книги Ревича, например, или широко известный учебный курс тов. DI HALT, свободно доступный как в виде цикла статей, так и в виде pdf-ки. Arduino лучше не трогать на начальном этапе - опасное это дело, как говорится.
Огромное
Огромное спасибо за книги - обязательно почитаю.
> "До того, как взялись за трехтомник, у вас было вообще какое-то представление о работе программиста?"
Представлений не было, однако:
До этого использовал С# под юнити и под консольные приложения - это, естественно, было на ОС виндовс (причём я уже чувствовал, что что-то тут не то (ничего не понимал - от этого было не так уж интересно)); спустя какое-то время решил самостоятельно освоить С++ - вскоре обнаружил, что сети там (под Windows) использовать очень сложно, после узнал о трехтомнике (спасибо автору за то, что показал и рассказал всё эти тонкости работы системы в 1 томе - я про представление данных на ПК, асм и в принципе администрировании системы).
Сейчас попробую снова изучить Си - до сетей так и не дошёл, а сервер написать хочется)
Просто интересно
А что именно показалось непонятным в C#?
В Windows консоль сильно отличается от нормального терминала, там это скорее матрица с символами. Из-за её архитектуры, нормальный удалённый доступ к этой консоли практически невозможен, тогда как нормальный терминал запросто работает по проводу.
>А что именно
>А что именно показалось непонятным в C#?
Скорее не в языке дело - все ютуберы, разные сайты по типу "C# для чайников" так и не объясняли, например, почему мы должны использовать enum и константы вместо простых чисел. А работа с движком Unity сводилась к банальному копированию кода; я уже тогда понимал, что такими темпами ничего самостоятельно написать не смогу - придётся лезть на форумы и искать решение.
Ну да, когда
Ну да, когда обезьяны пытаются кому-то рассказывать про программирование, на выходе не может получиться ничего более интересного, чем новые обезьяны.
Вообще какой нахрен сишарп для начинающих? Там ООП, а чтобы просто понять, о чём идёт речь при рассказе про ООП, нужно иметь опыт самостоятельного написания программ в 2-3 тысячи строк. Тем, у кого такого опыта нет, ООП объяснять бесполезно.
>Вообще какой
>Вообще какой нахрен сишарп для начинающих? Там ООП, а чтобы просто понять, о чём идёт речь при рассказе про ООП, нужно иметь опыт самостоятельного написания программ в 2-3 тысячи строк.
Для новичков, желающих создать игру, выбор ограничивается двумя движками - Unreal Engine 4 и Unity (с языками C++ и C# соответственно). Рассказы про то, какой C++ сложный, вынуждают многих выбирать C# как первый язык для обучения.
Или есть другой, более ужасный вариант - под влиянием таких людей как ХаYди Х0 и одного из преподавателей МФТИ (преподаёт первокурсникам Python) огромное количество людей, ещё не видевших хотя бы Паскаль, спешат освоить питон.
То есть и в первом варианте ООП, и во втором варианте ООП - я очень сомневаюсь, что до серьёзной и правильной литературы (такой как "Программирование: введение в профессию") подростки, хотя бы лет до 16, дойдут, ни разу не услышав об, повторюсь, ООП.
>Тем, у кого такого опыта нет, ООП объяснять бесполезно.
Это то да, только вот деньги за просмотры у ютуберов никто не отменял. Сюда же можно отнести авторов курсов по программированию "С++ за 3 месяца" (иногда с "гарантией трудоустройства") и тому подобное.
Для новичков,
Для новичков, желающих создать игру
"Ничего не знаю, ничего не умею, но хочу быть круче всех". Ну да ну да.
C# как первый язык для обучения
Хрен редьки ни разу не слаще, в данном случае даже хуже, пожалуй.
ни разу не услышав об, повторюсь, ООП.
Слышать они могут что угодно о чём угодно, например, что программисты все как один ничего не делают и бабки не знают куда девать. Что толку-то? Про ООП бесполезно и даже вредно "слышать", его надо или уметь, или изучать, чтобы потом уметь, или не трогать вообще.
деньги за просмотры у ютуберов
Инфоцыганство как оно есть, чо. Вообще, подозреваю, народ скоро выработает иммунитет против этих самозваных гуру.
>Вообще,
>Вообще, подозреваю, народ скоро выработает иммунитет против этих самозваных гуру.
Пока в ютубе не будет адекватных роликов, все пользователи ютуба будут смотреть инфоцыган.
Пролема уж
Пролема уж точно не в отсутствии адекватных роликов, поскольку их там вообще-то есть. А инфоцыгане — явление, возникшее задолго до ютубовской эпохи. Скажем, у Майка Науменко есть такая песня, называется "Песня Гуру". Как раз про такого персонажа, которых сейчас называют инфоцыганами. Если не ошибаюсь, это самое начало 1980-х, то есть песне-то вообще-то сорок лет.
Ничего не знаю,
Ничего не знаю, ничего не умею, но хочу быть круче всех
Ну так юношеский максимализм же, так его растак. Мне кажется, подавляющее большинство "начинающих программистов" грезит о двух вещах — своей игре (непременно в 3D с умопомрачительным графонием) и своей операционной системе. Я, например, где-то ко 2 курсу универа (ни разу не программистская специальность, химик) увлекся JavaScript'ом (как говорится, гусары, молчать) и, когда начался семестровый (всего лишь) курс программирования с одной парой в неделю и гордым названием "Вычислительные методы в химии", по договоренности с преподавателем носил ДЗ не в Lazarus, вокруг которого строился курс (ага, программки с гуём и одной процедуркой, запускавшейся по нажатию кнопки в окошке), а в виде страничек с JS-ным кодом (ну вот скучно мне было решать квадратные уравнения в заботливо сконструированном кем-то окошке, а вот нарисовать в браузере график интерполирующего полинома для заданного набора точек, имея в распоряжении только методы для рисования точки и прямой - самое то, причем это было не по заданию, а так, "для души"). Заодно увлеченно рассказывал преподавателю о грандиозных планах по написанию своей оси на JS. Но надо сказать, что я, в отличие от упоминавшихся здесь некоторых "питоняшек" понимал, что на голом JS этого не сделать, и рассказывал ей о необходимости написания своего интерпретатора JS, который бы мог работать с bare metal (ну вот восхищала меня тогда идея, что "программу" можно написать в одном Блокноте, безо всяких там компиляторов, да-да). Сейчас-то я понимаю, почему она так улыбалась... А вот вопросом безопасности такой полностью интерпретируемой ОС ей удалось меня поставить в тупик, это да. Так что максимализм, он такой.
упоминавшихся
упоминавшихся здесь некоторых "питоняшек"
О нет, я не думал что такие существуют, то есть я мог предположить, но вот, что реально есть ОС, о нет. Вот
https://github.com/joshiemoore/snakeware
Где ОС-то? :) Там
Где ОС-то? :) Там Linux, а питоновый только юзерспейс. Честно говоря, при виде этого возникло ощущение, что обезьяны начали строить для себя подходящий обезьянник.
"Начинающие программисты"
большинство "начинающих программистов" грезит о двух вещах — своей игре (непременно в 3D с умопомрачительным графонием) и своей операционной системе
Ага. На каком-нибудь хрусте или плюсах. Повторяя заученную глупость про "C древний и устарел".
Да ну как бы
Да ну как бы "чистым Си" неофиту черепушку вскрыть можно ничуть не хуже, чем этими языками. Вот что "немодное и несовременное" по их глубочайшему убеждению (и почитаемых ими гуру) - это Паскаль. Вот просто есть такая железобетонная уверенность, что он - школьная игрушка, а вот где-то есть большое программирование, где все совсем не так.
Неофиты
Да ну как бы "чистым Си" неофиту черепушку вскрыть можно ничуть не хуже, чем этими языками.
А что такого сверхсложного в чистом С? По мне так чем ближе к железу - тем проще. Не, ну хрустом вскрыть можно - это недоразумение создано спецом для параноиков. С++ (если без стандартной библиотеки) - врят ли. Но если нет опыта с чистыми сями, то удобства С++ окажутся непонятны (в смысле человек не поймёт для чего нужно усложнение в виде ООП). Хотя, в принципе, может оказаться и так, что С++ просто окажется не нужен и человек останется на чистых сях (например, если выберет профессией эмбеддинг). Про С++ с STL лучше вообще умолчать - если кто-то "обучится" этому (STL-макакингу) с нуля (при этом можно реально травмировать мозг), то получится аналог питоняши, по недоразумению называющей себя "С++ - программистом".
например, если
например, если выберет профессией эмбеддинг
Nelson, а вы, вообще, эмбеддингом занимаетесь, как я понимаю? Если да, можете в двух словах рассказать, насколько охотно в эту сферу берут людей без профильного образования, и реально ли это вообще? Просто сплошь попадаются только вакансии с обязательным требованием физмат/технические науки.
Эмбеддинг
Nelson, а вы, вообще, эмбеддингом занимаетесь, как я понимаю?
Приходится ) Но я скорее "железячник", нежели программист.
можете в двух словах рассказать, насколько охотно в эту сферу берут людей без профильного образования, и реально ли это вообще?
Сложный вопрос на самом деле. Тут всё больше зависит от ваших целей. Если вам нужен "карьерный рост и вот это вот всё", то высшее образование, скорее всего, понадобится. С другой стороны, толковых специалистов в этой сфере катастрофически не хватает, поэтому главным критерием при приёме на работу всё же будут фактические навыки, а ещё лучше какие-то реализованные проекты.
Конечно, профильное образование не помешает, но тут, правда, тоже не всё так просто. Обычно в эмбеддинг приходят либо с чисто программистстским образованеим либо с техническим по типу "Радиотехника", "Промышленная электроника" и т.д. Какое из них более подходит для сферы эмбеддинга - фиг его знает ) В идеале 50/50, наверное. Так что самобразование в этой сфере однозначно решает, т.к. чисто программистских знаний либо чисто "знаний по электронике" недостаточно. С другой стороны в сфере есть немало людей без высшего образования, которые вполне себе грамотные специалисты.
Также стоит быть готовым к тому, что очень часто от эмбеддера при устройстве его на работу в наших реалиях будут требовать не совсе адекватные вакансии навыки и опыт: опыт в разработке аналогой электроники, проектироваие печатных плат и т.д., что как бы не совсем правильно, мягко говоря, т.к. это отдельные профессии, причём требующие основательной подготовки и опыта. Многие работодатели не понимают, что эмбеддер - это всё таки программист, а не схемотехник, инженер-проектировщик и конструктор, который может также ещё при необходимости разработать прошивку в одном лице. Но это, наверное, уже больше к вопросу о правильном позиционировании себя как специалиста.
От себя могу сказать, что нужно прежде всего определится, насчёт того, что вам ближе: программирование или электроника.
Если интересно именно программирование, то в эмбеддинг лучше не идти, потому что как программист вы в этом случае будете стагнировать. Писать прошивки - это не такая прям сложная наука, как это часто пытаются представить. В "большом программировании" решаются намного более сложные задачи.
Если же подойти к эмбеддингу чисто "с точки зрения железа", то можно обнаружить, что, внезапно, никакой разработки тут нет. Эмбеддер разве что должен разобраться с набором периферии микроконтроллера. Хорошо, конечно, если человек сумеет развести ещё и плату, но такое наблюдается редко, если дело касается не совсем банальных устройств.
Короче, если нет явного интереса к электронике, то идите в программисты ) Я бы сказал, что эмбеддинг - это всё же для тех, кто в первую очередь электронщик (хотя толковому электронщику идти в эмбеддинг также вовсе необязательно, но это уже другая история) по натуре (который при необходимости может написать прощивку).
Ну и также нужно учитывать, что найти работу "программистом больших машин" всё же проще - этот момент нужно обязательно учитывать.
P.S. Сорри за простыню, вопрос крайне обширный.
По мне так чем
По мне так чем ближе к железу - тем проще.
В целом, конечно, соглашусь с вами. Но вот учить Си как первому языку - крайне неблагодарное и, вероятнее всего, не сильно обреченное на успех мероприятие. Ну не тот это язык, с которого надо начинать: во-первых, указатели прям "с порога", во-вторых, побочные эффекты как само собой разумеющееся. Ну и в целом Си едва ли приучит к культуре программирования, это откровенно "хакерский" (разумеется, не в этом смысле) инструмент, который никогда и не претендовал на образовательную нишу. Вообще, всё это довольно долго и подробно здесь уже мусолилось, и не раз.
Назначение языков
учить Си как первому языку - крайне неблагодарное и, вероятнее всего, не сильно обреченное на успех мероприятие
Так с этим никто не спорит. Я имел в виду непонимание целевого назначения языков в контексте возможности их применения. Я вообще сильно сомневаюсь, что "молодые илоны маски" будут С изучать. Им ведь мозги растишкой промыли, точнее тем "утверждением", что это "заменитель сей".
Плюсую
Плюсую, ОС хотел писать ещё когда начинал с питона. Юношеский максимализм как он есть. "Исполнил мечту", на паскале после того, как прочитал Just for Fun Торвальдса, Линукс же начинался вообще как эмулятор терминала, потому что Линуса выбесил Minix'овский. Сделал простой эмулятор терминала в терминала, а программы сделал подпрограммами. Ещё впринципе "мечты" зависят от человека, а степень "странности" и "нереализуемости" растёт с повышением выбранного стека технологий юного ума.
"Стало как-то не
"Стало как-то не так" — это когда, ещё на самом асме или уже на Си? Впрочем, тут в любом случае пытаться что-то определённое выдать — это примерно как диагноз по фотографии.
могу ли я прочитать главу по сетям
А что, вам это кто-то может запретить?
можно ли залезть в ардуино
Я не схемотехник, но если я что-то в чём-то понимаю, то это примерно как программировать начинать с питона. Там же и останетесь, по-настоящему предмет не освоите.
Кстати, я с 2008 года активно пишу под AVR, а тамошнего ассемблера не знаю и от этого не страдаю. Ну так, на всякий случай, чтобы не возникало странного ощущения, что для МК пишут на асме.
Есть
Есть предположение, что желание пропало из-за малого количества практики и небольших проектов ранее - попробую снова освоить Си (до процессов и услуг ОС не дошёл, внезапно это стало интересно).
> "Кстати, я с 2008 года активно пишу под AVR, а тамошнего ассемблера не знаю и от этого не страдаю. Ну так, на всякий случай, чтобы не возникало странного ощущения, что для МК пишут на асме."
То есть вы используете Си? Меня скорее интересует ассемблер (смотрел видео одного человека на YouTube - он берёт Intel 8008 (иногда связку таких) и делает на основе этого сумматор, вычислитель чисел Фибоначчи и т.п. - в общем, интересные схемы с использованием асма - по-моему, очень даже интересно).
>"Я не схемотехник, но если я что-то в чём-то понимаю, то это примерно как программировать начинать с питона. Там же и останетесь, по-настоящему предмет не освоите. "
Понял, а взять отдельно от туда процессор могу? Из описания, это процессор ATMEL (ATMEGA) - тоже, если не ошибаюсь, из семейства AVR.
То есть вы
То есть вы используете Си?
Естественно. На чём ещё писать под "голое железо"? Альтернативы, увы, нет — и, судя по тому, какие бастарды появляются нынче в роли "новых языков программирования", такой альтернативы ещё очень долго не будет.
скорее интересует ассемблер
Жизнь слишком коротка, чтобы тратить её на ассемблерное программирование. На Си то же самое получается в разы быстрее, плюс часть кода можно перен