Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - valexey

Страницы: [1] 2 3 ... 9
1
Отсюда: http://forum.oberoncore.ru/viewtopic.php?f=5&t=4083
Цитата: Дмитрий Дагаев
Выложил свой проект - коммуникационное ПО для Оберона/BlackBox и С на
http://sourceforge.net/projects/ta1/.

1. TA позволяет строить распределенные системы на основе моделей клиент-сервер и издатель-подписчик, а также системы обмена сообщений низкого уровня. TA может заменить клиент-серверные технологии CORBA, DCOM и DDS-технологию издатель-подписчик.

2. TA построена исключительно на неблокирующем режиме сетевого взаимодействия, поэтому не страдает подвисаниями, характерными для COM (да и CORBA) и не требует отдельных тредов, блокируемых во время ожидание прихода данных.

3. TA имеет тип протокола обмена SRPS для локальных сетей и SOAP/HTTP - для глобальных. На физическом уровне в локальных сетях возможно использование протоколов: UDP multicast, UDP, TCP, ICMP, Shared Memory. Возможен обмен через DLL, а в C-Unix версии - через SO, Unix Domain Sockets и MSGQ. Множество поддерживаемых протоколов может расширяться.

4. TA - пилотный проект. Есть 2 варианта: TA для BlackBox и TA для C. Первая протестирована для Винды, хотя частично работает и в Wine. Вторая - тестироваана и для Linux.

5. TA распространяется в исходных текстах по лицензии LGPL.

У кого есть желание/время гляньте что там и как. А то я пока не могу полноценно это посмотреть.

2
Общий раздел / Про парсер и лексер.
« : Сентябрь 09, 2012, 06:22:23 pm »
Я не поленился и нашел этот шедевр:
...
Я как-то писал здесь http://forum.oberoncore.ru/viewtopic.php?p=69811#p69811 про смесь из лексического и синтаксического разбора
Цитировать
Мне многократно приходилось писать "наколеночные" решения для разбора каких-нибудь данных. Почти всегда возникал соблазн схалтурить, не делать отдельный лексический разбор. В 100% случаев это приводило к тому, что в итоге получалась какая-то дрянь.

"Шестиветочный цикл" Info21 - прекрасная иллюстрация.

Я тоже думал об этом. Ну и немного шишек понабивал самостоятельно, так что подтверждаю.

Galkov, помнится очень хорошо объяснял почему требуется разделять парсер и лексер (за что был неоднократно гнобим на оборонкоре) - они банально работают по разным принципам. Обычный LL(с)-парсер не сможет разбить входной поток на лексемы. Какой-нибудь LALR - тоже. Я подозреваю что с задачей сможет справиться GLR и/или GLL парсер, но это будет не эффективно (ну и не факт что получится - я еще не прорабатывал эту тему).

PS. Справится/не справится - имеется ввиду, что это честный парсер, работающий по полностью формализованной грамматике и ничего кроме нее не знающий. А не так как работает например виртовский парсер Оберона.

3
Общий раздел / Про Turbo Pascal и обучение
« : Сентябрь 08, 2012, 01:00:02 pm »
На хабре появилась статейка в тему: http://habrahabr.ru/post/151088/

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

Из полезного для себя вынес, что оказывается PascalABC имеет веб-морду (работать можно прямо из браузера): http://pascalabc.net/WDE/

Ну и обсуждение там тоже достаточно любопытное.

4
Вот тут появился готовый рецептик который широко применяется при обучении в ВУЗах страны:
Цитата: Валерий Лаптев
Будучи программистом, восторгался множеством возможностей языков и сред. Ставши преподавателем, понял, что язык должен обеспечивать "правильные" способы программирования. А среда должна "бить по рукам" при малейшем отступлении от правил. Никакие увещевания и разговоры, как делать правильно, не помогают. "Что с человеком ни делай - он упорно ползет на кладбище"(с) Жванецкий.
Поэтому управление обучение должно быть институциональным, то есть принудительным. И только по мере обучения "вожжи" можно отпускать.

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

5
Общий раздел / Про x86
« : Август 26, 2012, 09:03:36 pm »
Отсюда: http://habrahabr.ru/post/150255/
Цитировать
x86 — это архитектура которая состоит из костылей и legacy мусора от и до, она вызвает стойкое отвращение у всех, кто вынужден писать под неё как ядра операционных систем, так и компиляторы/декомпиляторы, ассемблеры/дизассемблеры, системы для инструментализации машинного кода и прочие низкоуровневые вещи. Я искренне желаю провала инициативе Intel-а, если x86 захватит ещё и рынок мобильных платформ — это станет невыносимым ударом для инженерно-технического чувства прекрасного многих людей.
В общем, поддерживаю реплику сию.

6
Общий раздел / О качестве.
« : Август 24, 2012, 04:28:52 pm »
По моему, это достойно отдельной темы.

Оберон, совершенный код, всё такое... проще надо быть...

Когда быть хорошим плохо
Цитировать
Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.

Добавлю цитатку из текста статьи:
Цитировать
Иногда быть хорошим, это плохо, потому что это мешает и парализует нас. Я обнаружил, что гораздо больше вещей делается исполнителями, а не мыслителями.

Не давайте своим знаниям «ремесла» разработки ПО быть помехой вашей производительности, или вы будете вынуждены наблюдать как те, у кого меньше навыков и знаний, постоянно превосходят вас, пока вы гневно и резко критикуете их со стороны.
Это вообще очень-очень точно характеризует то, что происходит с Обероном и, особенно, в Оберонкоре.

Между прочим, я лично тоже подвержен этой болезни. Причем достаточно сильно. Но я таки борюсь и стараюсь таки меньше думать и больше делать и вроде бы начало получаться. :-). А то студенты/стажеры меня зачастую превосходят в продуктивности (пока я думаю, они 10 раз сделают, переделают и доведут программу до вменяемого состояния).

Да, помнится был на одной конференции, там один товарищ (автор популярного поискового сервера Sphinx Андрей Аксенов) был с докладом "Как прекратить писать", где рассказывал о видах программистов и проблемах отрасли (черт, звучит как-то пафосно, в отличае от самого доклада). Кстати, крайне рекомендую посмотреть видео выступления: http://www.addconf.ru/event.sdf/ru/add_2010/authors/andrewAksenow/stopWriting

Так вот, он в частности говорил что на самом то деле программисты делятся на две категории: Ффтыкатели и, пардон, но из песни слов не выкинешь, Хуяторы. Первые соответственно не пишут а долго-долго ффтыкают как лучше написать, а товарищи из группы Х фигачат код и перефигачивают его. И что лучше быть в группе Х нежели в группе Ф (ибо Х действительно делают а не рассуждают).

7
Общий раздел / Про goto.
« : Август 21, 2012, 08:38:39 am »
По моему следует уточнить из за чего goto (то, старое goto которое было в 70-х) было плохо и почему с ним боролись.

goto - это был неклассифицированный переход (или нетипизированный). То есть видя goto не ясно что оно означает в данном конкретном контексте. Оно было сильно контекстно зависимо. Это примерно как если в языке с динамической типизацией переиспользовать одну и ту же переменную в разных кусках кода (или вооще через строчку) храня там то double, то int, то string, то вообще DOM. Разобраться во всем этом решительно невозможно (при достаточных размерах программы).

Что имеем сейчас?

return из "середины" - это четко классифицированный переход с четкой се мантикой. Известно что произойдет и где окажемся. И зачем оно используется.

throw (исключение) - тоже ясно зачем когда и куда. четкая классификация.

Собственно даже goto в современных языках (вроде С++ или того же Go) жестко ограничен, и уже не является неведомой фигней которая может кинуть нас вообще куда угодно (например за пределы текущей функции он не выкинет, также он не может перешагнуть через объявления переменных, то есть свобода маневра очень урезана).

Таким образом я не вижу ничего страшного в использовании return'ов и throw в современных языках (там где это уместно). И даже goto иногда позволяет сделать код программы существенно читабельней. К нечитаемости программы goto уже не приводит (чтобы привело нужно специально постараться это сделать, обычный быдлокодер это не осилит, ибо регулярно будет получать ошибки компиляции).

8
Общий раздел / Реализация КП на C#.
« : Август 20, 2012, 09:44:42 am »
Дружными усилиями в конференции откопали компилятор Компонентного Паскаля писанный на C#, генерирует код для 8051. Опенсорс естественно.

Цитировать
Cross compiler for a dialect of Component Pascal programming language targetting at the Intel 8051-like CPUs (and support tools for such a compiler).

Парсер там писан посредством antlr. Кодогенератор конечно же свой. Имеется внутреннее промежуточное представление в виде дерева, которое, в принципе, можно использовать для своего кодогенератора (скажем в .net байткод или куда-то там еще). Написано вроде достаточно аккуратно.

http://sourceforge.net/projects/ob51/

9
Общий раздел / Высоконагруженный веб.
« : Август 15, 2012, 03:46:22 pm »
Смысл в proof of concept (на базе составного документа фейс для изначально чисто вебного форума). А технического совершенства добиваться уже потом, возможно посредством других инструментов.
У меня мозги как-то иначе резонируют на подобную задачку. В первую очередь когда я думаю о программе "Форум", то возникает схема из нескольких модулей (смотри вложение), а уж чего там в гуе будет, как-то не интересно.

Во вложении набросок системы типа "Форум" а-ля микро-одноклассники или нано-фэйсбук. На полноценный фэйсбук (сто миллионов соединений) не потянет, а на 100-200 тысяч одновременных соединений -- запросто.

Кстати, вот тут пишут что node.js тянет до миллиона одновременных соединений. Без балансеров и прочего. На одной машине. И это, черт возьми, голимый js! (хотя, справедливости ради, этот голимый js в подобном тесте является тонкой надстройкой над pure low level C либой). Впрочем, со сборщиком мусора там все равно проблемы начинаются на миллионе соединений, приходится немного иначе работать.

10
Общий раздел / Проверка на не логику.
« : Август 14, 2012, 09:46:27 am »
На хабре появилась статья про то как на собеседованиях (на php программиста, но это не важно) проверяют людей на умение думать и на логику.

Цитировать
Как известно, большинство тонкостей логически выводятся из понимания более общих вещей. Я считаю, что хорошего программиста от плохенького кодера отличает желание и умение применять логику. Именно поэтому меня не так сильно интересует, знает ли кандидат ответ на мой вопрос. Меня больше впечатляет его умение вывести правильный ответ логически или логически объяснить то, что он знает.

Посыл хороший, но вот как это выглядит на практике:
Цитировать
Первый вопрос

— Можем ли мы отнаследоваться от абстрактного класса и не реализовать некоторые из его абстрактных методов?

Кажется, ответ лежит на поверхности. Но тем не менее, правильный ответ мы получаем очень редко, поэтому за вопросом обычно следуют наводящие вопросы:
— Давайте рассмотрим родительский класс, из чего он состоит?
— Свойства, реализация методов, абстрактные методы.
— Правильно, теперь представим, что в дочернем классе мы не реализовали какие-то из абстрактных методов. Из чего он состоит?
— Мы не можем этого сделать.
— Давайте представим, что можем. Тем более, я уверяю Вас, что мы можем.
— Из свойств, реализации методов и… Нет, здесь будет ошибка.
— Дочерний класс отнаследует абстрактные методы родительского, но не реализует их. Значит, какие это будут методы?
— Абстрактные.
— Правильно. Значит, дочерний класс у нас какой?
— Будет ошибка.

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

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

Цитировать
Второй вопрос

— Можем ли мы в классе реализовать интерфейс и не реализовать какие-то из описанных в нём методов?

Как ни странно, чаще всего ситуация повторяется. И снова следуют наводящие вопросы:
— Давайте вспомним прошлый вопрос.
— Так с интерфейсами всё по-другому.
— Почему?
— Мы не можем это сделать, потому что они не классы и мы изначально говорим, что мы их реализуем. Будет ошибка.
— Давайте представим, что можем. Тем более, я уверяю Вас, что мы можем.
— Я Вас не понимаю.

Вторая проверка работы логики заканчивается провалом.
Внимание вопрос - где тут та самая логическая цепочка по которой можно было бы вывести, что не реализовав один из методов мы обязаны объявить класс как абстрактный? Ну вот возьмем ObjC - там это делать не нужно. Smalltalk? Аналогично. typeclass'ы в haskell'e? Или реализуешь все, или ничего (хотя могу ошибаться, давно хаскеля в руках не держал).

Ну и третий вопрос:
Цитировать
— Класс синглтон. Сможете сходу сказать, какие элементы должен содержать класс, чтобы мы могли его считать синглтоном?

Тут часто отвечают правильно про то, что нужен метод получения экземпляра класса, переменная, в которую мы будем сохранять этот экземпляр и содержимое которой мы будем проверять при попытке получить экземпляр класса. При этом безбожно путают статические методы и свойства и методы и свойства объекта. Но сейчас не об этом.

— Хорошо, таким образом мы предоставляем возможность получать один и тот же экземпляр класса из любого места в приложении. Теперь нам нужно убедиться, что экземпляр класса будет только один.
— Ммм.
— Проще говоря, нам нужно убедиться, что экземпляр класса будут получать только через этот метод. Что нам нужно для этого сделать?
— В смысле?
— Какие у нас есть способы создания объекта?
— New.
— Правильно, а ещё?
— Не знаю.
— Ну ладно, не суть важно, ещё существует клонирование объектов.
— Что-то слышал, но не использовал.
— Так что нам нужно сделать, чтобы мы не могли создавать объект в обход статического метода получения экземпляра?
— Это Вы сейчас new имеете ввиду?
— Да, именно его.
— Нужно в конструкторе вызывать статический метод получения класса.

Дальше идёт такая каша, что до модификаторов доступа на конструктор и магический метод клонирования добраться удаётся не всегда. И эта проверка работы логики также не увенчалась успехом.
Как логически тут можно вывести эти знания? Это ведь нужно ЗНАТЬ, что конструктор можно запихнуть в приватную секцию, что есть понятие клонирования объекта и как его запретить.

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

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

Да, а оригинал статьи тут: http://habrahabr.ru/post/148509/

11
Общий раздел / CPIde
« : Август 13, 2012, 03:17:15 pm »
Если вдруг кому интересно: у той же конторы, что делает Astrobe есть еще один продукт - CPIde: это IDE под винду для Компонентного Паскаля: http://www.cfbsoftware.com/cpide/cpide.aspx

В качестве компилятора, как я понимаю, используется gpcp. Последний релиз - конец 2011 года.


12
Общий раздел / Oberon & Flash/ROM
« : Август 10, 2012, 05:37:50 pm »
Это из мира программирования под микроконтроллеры (в основном, хотя и на PC такой код есть).

Итак, рассмотрим какой-нибудь типичный микроконтроллер, ну например msp430g2452. У него ОЗУ (RAM) 256 байт, замечу что в эта RAM на все - и на стек тоже, и на глобальные переменные (которые можно менять) и на кучу. На все. При этом у этого микроконтроллера аж целых 8 Кб Flash (1024*8 = МНОГО!). Flash во время работы писать нельзя (точнее можно, но это о-очень медленно и flash от этого быстро сдохнет), зато можно читать на той же скорости что и RAM, также у микроконтроллера плоское адресное пространство - и RAM и этот Flash лежат в едином адресном пространстве (и кто где кончается и начинается определить, по сути нельзя, не попытавшись туда что-то записать).

Собственно программа пишется во Flash и прямо оттуда исполняется, в ОЗУ она не грузится.

Очень часто возникает необходимость иметь довольно большие (сотни байт) массивы и другие структуры данных содержимое которых полностью известно на этапе компиляции (простейший пример с которым я сталкивался лично - массив коэффициентов для FIR-фильтра (FIR == КИХ)) и во время исполнение программы их модификация не требуется. В RAM это все пихать глупо, да и не поместится. Им самое место во Flash'e.

Внимание вопрос - как такие структуры данных оформить в Обероне?
В Си и С++ с этим проблем нет (я знаю как), а как в Обероне - не знаю.

13
Общий раздел / Oberon & GCless modules
« : Август 09, 2012, 01:05:21 pm »
У Си (не С++) есть очень приятная особенность: если ты видишь что в юните нет инклюда #include <stdlib.h>, то и память там никто в куче (скорее всего! ибо манипуляция адресами как хочешь не запрещена) не выделяет.

В Обероне же когда смотришь на модуль не ясно использует он динамическую память (NEW) или же нет. А это иногда бывает важно. Например пишешь ты некий сервер, причем пишешь так, чтобы он работал гарантированно без сборщика мусора (и сборщик мусора для этого отключаешь возможно даже) - все либо на стеке, либо глобально. И используешь стороннюю либу, которой из самых общих соображений нет причин использовать динамическую память. А тут бац, в одном модуле внезапно кто-то использует. И все. Либо тормоза, либо память кончится.

Или же скажем программирование под мелкоконтроллеры - памяти там скажем 512 Байт (а может быть конечно и 8 Кб). Ясно что динамическая память и тем более сборщик мусора там противопоказан. Но, тем не менее, иногда хочется повторно использовать там хорошо зарекомендовавшие себя модули с больших систем. И неплохо бы изначально убедиться что они не используют динамическую память.

Я тут вижу три варианта решения проблемы:
1) Модификация языка, такая, что для использования NEW было необходимо скажем импортировать модуль MemManager.
2) Решение на уровне компилятора - при специальном ключике компилятора он отрубит сборщик мусора и динамическую память вообще, и на NEW будет ругаться плохими словами.
3) Сторонняя тулза которая прошерстит исходники даденых модулей и скажет если вдруг кто-то динамической памятью там пользуется (хм. можно просто сделать grep * NEW).

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

14
Общий раздел / А про Оберон таки пишут.
« : Июль 30, 2012, 12:23:19 pm »
Сегодня пока искал в интернетах материал никак не связанный с обероном, внезапно наткнулся на ЭТО: http://incoder.tumblr.com/post/7380052577

Это ж надо как у человека в черепушке насрано… Похоже серия статей на хабре про Оберон все же нужна. Нормальная серия статей не рекламного характера, где объективно и интересно было бы описана история Оберона, а также его преимущества и недостатки, без фанатизма.

На всякий случай продублирую текст что был выше по ссылке:
Цитировать
Долой виртуальные машины

Я думаю что виртуальные машины типа Simula 67, Oberon (Black Box), Java и .NET плохая идея. Они были разработаны чтобы избежать ошибок возникающих при ручном управлении памятью и адресной арифметикой. Т.е. идея создать язык который сможет ограничить программиста от допущения ошибок, хотя бы от типичных. Т.е. снизить требования к квалификации программиста, времени потребной на его подготовку и как следствие цену полученного ПО.
Что получили в итоге - Simula67 и Oberon изначально выдавали низко производительные программы которые медленно работали и потребляли много памяти. На момент их создания компьютер занимал отдельное помещение типа цеха, и машинное время стоило очень дорого. Итог языки в промышленном масштабе не применялись. И дело не в маркетинговой составляющей, да языки изобретены в Европе - а компьютеры делали в Америке. Паскаль создан Никлаусом Виртом - он же создал и Oberon, но этот язык нашел широкое применение в том числе и в США.
На производительность программ Java долгое время не обращали внимание, потому что в 1995-м задержка в линиях передачи данных с лихвой перекрывали время потребное для работы сервелета. Апплеты и прикладные приложения написанные на Java так и не получили большого распространения, исключения оставляют только IDE все для той-же Java и Vuze. К тому же нагрузки на сервера были во множество раз ниже современных.
Что имеем сейчас - проблемы с производительностью Java программ. При современной скорости передачи данных задержка на сервере имеет значение. К тому-же нагрузки увеличились многократно. Особенно остро они стоят с программами написанными начинающими программистами из индии. Следствие - или потери клиентов, не желающих мерится с низкой производительность - или огромная стоимость серверов потребных для работы таких программ. Конечно хорошие программисты все равно стоят дороже чем хорошие серверы, но обслуживание хороших серверов (админы, и датацентры) стоит дороже чем хорошие программисты. Т.е. JVM решительно не удешевляет разработку ПО, а только создает дополнительные проблемы. Проще говоря не сработало.
Для любителей подискутировать на тему - “ну вот больше я не вижу 0x000005 общая защита памяти”.  Чем NullPointerException от этого отличается? Это все та же общая защита памяти, но только не средствами операционной системы - а средствами интерпретатора виртуальной машины. Какая разница пользователю по какой причине программа отказала?
У .NET дела конечно обстоят много лучше, технология была разработана спустя пять лет после выхода Java с учетом всех ошибок допущенных в Java т.е. JIT, Security Management и JNI. Система отлично подходит для прикладных программ, но не очень для серверных. Ядро Windows NT в принципе разработано для персональных компьютеров, а не для серверов к тому-же стоит больших денег. Т.е. тоже не работает, цена на софт с лихвой перекрывает все выгоды.
Вывод - виртуальные машины плохая идея. Он ни в коей мере ничего не удешевляют, а наоборот требуют дополнительных затрат.
Что делать ? Пока что я вижу выход в Fast CGI и С++/Objective C. Возможно на их смену может прийти Google Go или D-2.

15
Общий раздел / Задачка коварная.
« : Июль 27, 2012, 03:03:58 pm »
Давненько у нас задачек интересных не было.

Итак, дана java. И даны два числа (double). Необходимо написать функцию которая пользуясь только арифметическими действиями (без логических операций, без ветвлений и так далее) вернет 0.0 если a < b, и 1.0 если a>=b. Можно считать что a>0 и b>0.

То есть написать функцию double compare(double a, double b);
В функции не должно быть приведений типов, нельзя использовать тернарный оператор (?:) и так далее. Все что там должно быть - return с выражением.

Какие именно арифметические операторы/функции можно использовать:
+       Additive operator (also used
        for String concatenation)
-       Subtraction operator
*       Multiplication operator
/       Division operator
%       Remainder operator

double pow(double a, double b) // Returns the value of the first argument raised to the power of the second argument.

Замечу для прожженых сишников - в java оператор взятия остатка от деления (%) РАЗРЕШЕН для плавающей точки (double/float). Это не привычно, но это так.

И нет, в решении не обязательно использовать ВСЕ операторы/функции разрешенные. Эта задача не синтетическая, это реальная задача с производства (тамошний интерпретатор формул умеет ровно это, потому и такой набор операций).

И да, задача имеет решение.

Страницы: [1] 2 3 ... 9