> сгеренерёный рисукок

очень непонятная фраза

По оформлению - как-то странно писать "что-то" (ссылка) почему бы это "что-то" не сделать ссылкой.

По стилю - почему так неакадемично. Не знаю может сейчас модно писать задание в стиле "Поцаны, набыдлокодьте мне на сишке лабы по бырому. Какой-нить парсер мегадоки", но как-то уж глаза режет.

ЗЫ: По смыслу претензий нет, так как ниасилил

> КР. Исходные данные. Спецификация протокола SMTP(RFC 2821), средства разработки GNU, POSIX-совместимая система, библиотека libevent.

1. убрать отсюда libevent нафик. практического смысла ровно ноль, а детские души калечит. не давая при этом никакого понимания и практического навыка о том, как собственно устроено POSIX API в этой области. выкинуть.

// wbr

> (под вопросом) Использовать doxygen (?).

1. это не под вопросом - это просто must have. если семинарист этого не понимает, то это хреновый семинарист.

// wbr

> В качестве языка програмирования используется С стандарта С98.

Чего-чего 98? C89 знаю, C99 знаю, C98 не знаю. Восполните пробел, пожалуйста.

> # Исходный код КР должен быть доступен через svn или cvs (публичный или собственный). ДЗ может быть представлено в виде тарбола. Все исходные тексты должны использовать кодировку UTF-8.

это ещё нахрена? за "исходный текст в UTF-8" нужно расстреливать на месте без суда и следствия. рожают блин на потоке инвалидов умственного труда, которые и двух слов связать не могут на английском а мнят себя при этом "девелуперами" :-/ в сад, учиться.

короче, задание на тройку. "смешались в кучу кони люди" (c)..

// wbr

> 1. убрать отсюда libevent нафик. практического смысла ровно ноль, а детские души калечит. не давая при этом никакого понимания и практического навыка о том, как собственно устроено POSIX API в этой области. выкинуть.

POSIX API они уже немного освоили до этой работы.

> за "исходный текст в UTF-8" нужно расстреливать на месте без суда и следствия.

1) Я не собираюсь их учить ещё и английскому (тем более, мой письменный английский не блестящий).

2) *.tex и псевдокод --- относятся к исходным текстам работы. РПЗ всё равно д.б. на русском.

> Чего-чего 98? C89 знаю, C99 знаю, C98 не знаю. Восполните пробел, пожалуйста.

Спасибо за найденный косяк.

> > (под вопросом) Использовать doxygen (?).

> 1. это не под вопросом - это просто must have. если семинарист этого не понимает, то это хреновый семинарист.

Семинарист это понимает, но есть пара вопросов.

Хорошо, doxygen требуем для всего несгенеренного кода, а libevent выбрасываем для экономии времени учащихся.

> По стилю - почему так неакадемично.

Как оформлю PDF с заголовком "методические указания" -- будет академично, а пока возможен эклетичный стиль (хотя он и не предполагался).

> 1) Я не собираюсь их учить ещё и английскому (тем более, мой письменный английский не блестящий).
> 2) *.tex и псевдокод --- относятся к исходным текстам работы. РПЗ всё равно д.б. на русском.

срочно в сад на переподготовку!

*сперва* учится английский и только *потом* C/POSIX/что угодно. именно в таком порядке. инженер, который не в состоянии написать статью или руководство на английском - это нонсенс. это нехорошее слово а не инженер. не говоря уже о научных работниках.

в противном случае, я категорически не понимаю, как они будут осваивать RFC821/1939 и что они будут делать в будущем на практике без вменяемого знания базового языка :-/

// wbr

> 1) Я не собираюсь их учить ещё и английскому (тем более, мой письменный английский не блестящий).

"не знаю", "не хочу", "не моё" - это всё гнилые отмазки. вы или готовите специалистов или нет. если действительно готовите - будьте любезны соответствовать по полной программе.

// wbr

опять же не понятно, зачем для реализации куцего подмножества POP3/SMTP может понадобиться lex или yacc? то, что вы желаете получить в конечном итоге по ТЗ прекрасно [и гораздо проще] реализуется руками без привлечения лексических анализаторов и парсеров.

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

// wbr

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

// wbr

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

Я с вами полностью согласен. Что дальше? Если стану ректором -- учту ваше замечание. Пока что у нас английский положен в размере "чтение со словарём".

> в противном случае, я категорически не понимаю, как они будут осваивать RFC821/1939 и что они будут делать в будущем на практике без вменяемого знания базового языка :-/

Между "читать" и "писать" -- дистанция *огромного* размера.

> я уж не говорю о том, что использование в данном случае латеха для документирования - это, мягко говоря, требование, притянутое за уши. видимо из соображений "лишь бы куда впендюрить". 1) Вы разницу между документацией и РПЗ чувствуете? РПЗ --- это *не* документация. Это объяснение студента, что он понял и что он сделал.

> Я с вами полностью согласен. Что дальше? Если стану ректором -- учту ваше замечание. Пока что у нас английский положен в размере "чтение со словарём".

требовать от студентов написание документации на английском языке. как минимум это касается вменяемых комментариев в коде [это вообще не обсуждается] и man-ов. пусть как могут так и пишут. если вдруг не могут - глядишь, и английский пропускать станут меньше. по крайней мере будет хоть какой то подкреплённый конкретными требованиями стимул туда ходить.

// wbr

> "не знаю", "не хочу", "не моё" - это всё гнилые отмазки. вы или готовите специалистов или нет. если действительно готовите - будьте любезны соответствовать по полной программе.

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

> как минимум это касается вменяемых комментариев в коде

Ладно, будем делать правильно. Документацию из doxygen можно и в РПЗ не включать, в принципе.

> Вы разницу между документацией и РПЗ чувствуете? РПЗ --- это *не* документация. Это объяснение студента, что он понял и что он сделал.

в таком случае, выдвигать требование по использованию конкретного пакета - это некорректно. пусть хоть в ворде пишет - не проблема. главное, чтобы действительно вменяемо написал, что же как и зачем он сделал. для упражнений же в любимом латехе это IMHO надуманный случай. он повлечет за собой лишь то, что человек бОльшую часть времени будет думать как, именно оформить десять предложений нежели об их содержании.

вот когда будет необходимость писать дипломную работу на сотни страниц, тогда и поупражняется вдоволь в латехе. там он вполне уместен.

// wbr

> опять же не понятно, зачем для реализации куцего подмножества POP3/SMTP может понадобиться lex или yacc?

Только для SMTP. RCPT TO:...

> то, что вы желаете получить в конечном итоге по ТЗ прекрасно [и гораздо проще] реализуется руками без привлечения лексических анализаторов и парсеров.

В RFC уже задана грамматика. Реализовывать её разбор руками --- в учебном задании нонсенс. Мои личные воспоминания о ручном парсинге RCPT TO: остались самые неприятные, кстати.

> или вам некуда приткнуть практикум по лексическому анализу?

Ни в кое случае, у них уже был этот курс. То есть это полагается (и является) вполне изученным материалом. Курс включал как ручное создание собственного LR-парсера, так и использование имеющейся системы кодогенерации парсера по грамматике.

> разбор простых как пробка протоколов ему в этом ни чем не поможет.

Грамматика есть? Вроде есть. Что с неё следует сделать инженеру в учебном задании. На моё взгляд: создать её парсер штатными средствами.

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

Да вы шо? Там же сплошные (грубо говоря): \input{автомат/tikz}

\input{BNF.text}

\input{RE.c}

\input{Makefile}

\input{graph.cflow}

...

И зачем тут ворд? И как тут *вообще* применить ворд?

> вот когда будет необходимость писать дипломную работу на сотни страниц, тогда и поупражняется вдоволь в латехе. там он вполне уместен.

Вот там они все (ладно, 90%) будут писать в ворде.

Уж лучше unicode, чем cp1251 или koi-8.

> Уж лучше unicode, чем cp1251 или koi-8.

Речь, конечно же, не о них, а об ascii. Я уже внёс изменения.

Продолжаем критику, не стесняемся!

> Уж лучше unicode, чем cp1251 или koi-8.

вопрос отнюдь не в конкретной кодировке но в языке. программная документация базово пишется на английском. в редких случаях - на русском. комментарии в коне пишутся *только* на английском. в любом для любых нужд.

// wbr

Кто бы мне такие курсовые давал :(

по формальному описанию конесного автомата
s/конесного/конечного

> выполненние, вхолдить

о, моя языка!

Ну и глобально:
1. Не указано, сколькипоточным должен быть сервер и должен ли он обрабатывать более одного соединения за раз.
2. Слишком ограничен круг используемых инструментов. Например, вместо того же libevent можно и select/poll/alert использовать. возможно, даже select/poll и покрасивее окажутся.

Время начала треда посмотрите :(

В любом случае, через неделю будет культурный черновик метод. указаний.

> 1. Не указано, сколькипоточным должен быть сервер и должен ли он обрабатывать более одного соединения за раз.

Резонно.

> 2. Слишком ограничен круг используемых инструментов. Например, вместо того же libevent можно и select/poll/alert использовать. возможно, даже select/poll и покрасивее окажутся.

Хорошо, в КР можно будет использовать любой из вариантов. В ДЗ, думаю, можно перебиться и без select. Или не стоит?

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

Какой ужас "у меня нет на вас время чтобы писать документацию на двух языках - учите то на чем говорит весь мир". Берите пример с немцев - не надо быть ущербной нацией.

Re^2: Поругайте учебное задание

>> 1. Не указано, сколькипоточным должен быть сервер и должен ли он обрабатывать более одного соединения за раз.

> Резонно.

>> 2. Слишком ограничен круг используемых инструментов. Например, вместо того же libevent можно и select/poll/alert использовать. возможно, даже select/poll и покрасивее окажутся.

> Хорошо, в КР можно будет использовать любой из вариантов. В ДЗ, думаю, можно перебиться и без select. Или не стоит?

КР -- курсовая работа, а ДЗ -- домашнее задание? Или как?

Кстати, а зачем вообще там select нужен? В каждом потоке(или процессе) вешаться на свой сокет и работать с ним в блокирующем режиме.

Я читал несколько конспектов лекций (если так можно назвать опус на 300 страниц) из Испании и Германии по CS. И на каком они были языке? На естественном для CS.

Все претензии к Совету Министров СССР (и стоявшем за ним ВПК и ВС), зарезавшем CS и EE в пользу воровства у IBM.

> Кстати, а зачем вообще там select нужен? В каждом потоке(или процессе) вешаться на свой сокет и работать с ним в блокирующем режиме.

Для того и нужен, чтобы развести понятия "соединение" и "единица шедулера ОС" :)

Re^4: Поругайте учебное задание

>> Кстати, а зачем вообще там select нужен? В каждом потоке(или процессе) вешаться на свой сокет и работать с ним в блокирующем режиме.

> Для того и нужен, чтобы развести понятия "соединение" и "единица шедулера ОС" :)

Усложнив тем самым реализацию задачи. Ведь чтобы оно не блокировало, надо будет и парсер асинхронный писать. А это, насколько мне известно, лексом с бизоном не нагенеришь.

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

> Усложнив тем самым реализацию задачи.

"Тяжело в учении -- легко в бою". Как проще -- не нужно, нужно -- полезнее для расширения создания.

> Ведь чтобы оно не блокировало, надо будет и парсер асинхронный писать.

А зачем? Ведь парсится только конкретная полученная команда.

Это диверсия! От реализации протокола SMTP люди становятся пидарасами. Нельзя так со студентами обращаться.

doxygen как говно работает с plain C.

Всё ты правильно говоришь, только одного не учитываешь - а что если какое либо дитя гор, или насмотревшийся американских сериалов русский студент пойдет и в суд подаст, за то, что учат не на гарантированном конституцией государственном языке?

> Между "читать" и "писать" -- дистанция *огромного* размера.

+1

Кроме того, это же студенты. 99.999% этой братии не умеет писать и на родном языке - в школах сочинения отменили (суки, убью!), в ВУЗах пишут мало и херню всякую, так что начинают учиться писать только уже на первых своих научных публикациях (не на дипломе даже, его все пишут как говно).

Вот когда научатся на родном языке писать, мысль четко формулировать, тогда пусть начинают учиться писать на иностранных языках, это уже легко будет, все те же навыки применить можно.

Не гони волну. Тех. документацию в ворде пишут только пидарасы. От latex-а же один шаг до literate programming, которому научить надо обязательно и непременно.

Только вот ненецкий софт становится известным в остальном мире только после полного перевода на английский. На фиг, на фиг, национальные языки нужны чтобы стишки писать, и кляузы в национальные суды. А язык науки и технологий - английский. Раньше все, как миленькие, учили латынь и древнегреческий, потом - французский с немецким в обязательном порядке, теперь английский. Хоть рылом тресни, хоть на патриотизьм с говном изойди, а lingua franca будет всегда.

Re^6: Поругайте учебное задание

>> Усложнив тем самым реализацию задачи.

> "Тяжело в учении -- легко в бою". Как проще -- не нужно, нужно -- полезнее для расширения создания.

Луше расширять сознание барбитуратами^W соответствующей задачей. А так получается как будто лабу "сложить а и б" на брейнфаке выдал :)

>> Ведь чтобы оно не блокировало, надо будет и парсер асинхронный писать.

> А зачем? Ведь парсится только конкретная полученная команда.

А если придёт только HELO, а имя домена за ней отправится только через час?

> Для тестирования релизации протокола в целом могут использоваться сценарии командного интерпретатора (для соединения может использоваться программа netcat)

telnet-ом тоже можно

> или программа на языке Python.

Что за языковой фашизм? ;)

>Только вот ненецкий софт становится известным в остальном мире только после полного перевода на английский.

Хороший софт известен не переводом на английский :)

>На фиг, на фиг, национальные языки нужны чтобы стишки писать, и кляузы в национальные суды. А язык науки и технологий - английский.

Немцы дорожат своим языком и не пускают в него иностранные термины (для примера посмотри на объемы немецких технических словарей - у них в любой отрасли все термины на своем языке) - у нас язык засорен латинизмом по самое нехачу. Документация на родном языке у них есть всегда. Да что там немцы - по некоторым вопросам электроники удается найти информацию только на китайском языке.

Весь код должен быть на английском, комментарии - тоже на английском, документация - на английском, переписка между российскими программистами - тоже на английском. Это не обсуждается, это аксиома. У пощу я это не ради дискуссии, а ради того чтобы закрыть этот топик засим.

> Весь код должен быть на английском, комментарии - тоже на английском,

с этим согласен.

> документация - на английском,

документация.. начнём с базовой предпосылки: "документация должна быть". далеко не все команды в состоянии справиться даже с этим. если упрощение в виде ведения документации на понятном для группы языке способствует её написанию - его нужно вводить. черт с ним, пусть будет хоть на корейском - но пусть будет!

> переписка между российскими программистами - тоже на английском.

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

// wbr

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

Так что же ты тогда все это по-русски написал ?

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

хотя бывает что и наоборот. мне иногда проще написать описание дизайна ПО на английском чем на русском. банально исходя из того, что при его разработке использовалась преимущественно англоязычная терминология и написание документации на русском автоматически предполагает качественный перевод.

// wbr

>хотя бывает что и наоборот. мне иногда проще написать описание дизайна ПО на английском чем на русском. банально исходя из того, что при его разработке использовалась преимущественно англоязычная терминология и написание документации на русском автоматически предполагает качественный перевод.

Я об этом и говорю - следуя псевдостандарту использования английского языка довело до того что для некоторых понятий русского варианта вообще нет а те что есть настолько малоупотребимы что тебя просто никто не поймет.

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

Это началось далеко не сегодня и даже не вчера.

Да и легче транслитеровать слово exception, если ты его постоянно пишешь в коде, нежели вспоминать туманный термин "исключение". И понять слово "эксчепшн" будет гораздо легче, т.к. при обратном переводе можно "исключение" понять как "excluding".

> Это не обсуждается, это аксиома.

Это не аксиома, мой Absurd`ный друг. Это исторически сложившаяся реальность. Завтра она будет другой.

Для международного общения, существует эсперанто, специально для этого разработанный.