Обновлённый список проектов

jobbox
Описание: программа для запуска приложений в задании (job). Запускается как служба и создаёт pipe(канал). К pipe подключаются клиенты и посылают запрос на запуск какой-либо программы с нужными ограничениями.
Текущие возможности: на данный момент программа обеспечивает подключение одного клиента. После запуска указанного клиентом приложения с ограничениями, останавливается до завершения его работы (запущенного приложения). После закрытия приложения переходит в режим ожидания подключения нового клиента.
Состояние: разрабатывается.
Язык: C++
Лицензия: GPLv2
Исходники:
архив: https://sourceforge.net/projects/jobbox/
Git: https://github.com/marat-ab/jobbox
Документация: - 

TuringMachine
Описание: эмулятор машины Тьюринга.
Текущие возможности: программа позволяет сконфигурировать требуемую машину Тьюринга и посмотреть на результат её работы для заданной ленты.
Состояние: разрабатывается.
Язык: C#
Лицензия: GPLv2
Исходники:
архив: https://sourceforge.net/projects/turingmachinee/
Git: https://github.com/marat-ab/TuringMachine
Документация: - 

ProcessWatcher
Описание: мониторинг за процессами MS Windows.
Текущие возможности: позволяет просматривать список процессов и их модулей. Следит за открывающимися и закрывающимися процессами и выводит соответствующую информацию
Состояние: разработка временно остановлена.
Язык: C++
Лицензия: GPLv2
Исходники:
архив: https://sourceforge.net/projects/processwatcher/
Документация: http://attempts-to-see.blogspot.ru/search/label/ProcessWatcher


Notes
Описание: создание заметок.
Текущие возможности: позволяет создавать заметки. Есть возможность изменять окно отображения заметок.
Состояние: разработка временно остановлена.
Язык: C#
Лицензия: -
Исходники: -
Исполняемый файл: https://sourceforge.net/projects/notessoft/
Документация: http://attempts-to-see.blogspot.ru/search/label/Notes

О вычислениях, машинах Тьюринга и других интересных вещах. Part 3

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

Основными её компонентами являются лента бесконечная в обоих направлениях (хотя на практике часто используют ленту ограниченную с одного конца) и считывающая головка.

Идеи навеянные изучением конечных и бесконечных машин и квантовой электродинамики (КЭД). Part 1.

Возникло несколько идей, которые можно попробовать применить в программировании.

Идея № 1.

Начнём с КЭД. Если кому-то интересна эта тема, советую прочитать книжку Ричарда Фейнмана "КЭД - странная теория света и вещества". В КЭД свет описывается как поток частиц и все различные волновые свойства света, такие как дифракция, интерференция, отражение света, фокусировка с помощью линз, объясняются с этой точки зрения.

Не переключайтесь! Будет интересно!.

О вычислениях, машинах Тьюринга и других интересных вещах. Part 2

По материалам Марвина Мински “Вычисления и автоматы”.

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

Пойдём дальше. Наверное, не очень удобно собирать для каждой задачи свою МТ. А можно ли составить такую МТ, которая в качестве входных данных получает описание другой МТ и данные для неё?

О вычислениях, машинах Тьюринга и других интересных вещах. Part 1

Хотелось немного просвещать вопросы, связанные с вычислениями, машинами Тьюринга и т.п. На абсолютную корректность того, что излагаю, не претендую, это просто различные выдержки из книг, журналов и других источников, прошедшие через мою голову. За правки и комментарии буду очень благодарен.

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

Если какую-либо процедуру мы можем вычислить механически (т.е. на какой-то машине, или просто вручную), то такую процедуру будем называть эффективной. И обратно, если процедуру мы называем эффективной, то её можно реализовать механически. А каким требованиям отвечает “эффективная процедура”?

Эквивалентность конечного автомата "нейронной сети"

В книге Марвина Минского «Вычисления и автоматы» наткнулся на одну интересную теорему: «всякая конечная машина эквивалентна некоторой нейронной сети и может быть «смоделирована» ею». Суть заключается в том, что для любой конечной машины можно составить эквивалентную ей нейронную сеть, но это не самое замечательное. Интерес представляет универсальный метод построения нейронной сети по автомату!

Рассмотрим данную задачу на примере. Для начала определимся с терминологией. Раз за основу взята книжка Минского, то воспользуемся определениями из неё. Конечные автоматы это такие машины, которые переходят чётко разграниченными шагами из одного состояния в другое, причём оба этих набора принадлежат к некоторому конечному набору. Конечный автомат можно рассматривать как «чёрный ящик», который характеризуется определённой величиной (обобщённое состояние), Это обобщённое состояние изменяется в соответствии с предыдущими состояниями и входным сигналом (т.е. средой). С другой стороны данную машину можно представить как структуру, состоящую из отдельных элементов. Зная логику работы и связи между элементами, мы можем сказать, как эта система будет работать.

Интерпретаторы и компиляторы. Part 3.

В этой части мы сосредоточимся на грамматиках и иерархии Хомского.

Грамматику, по Хантеру, можно рассмотреть как следующую структуру:

(V_T, V_N, P, S)

V_T – алфавит терминалов,

V_N – алфавит нетерминалов,

Необходимо отметить, что множества V_T и V_N не пересекаются, а их объединение будем обозначать V.

P – множество правил. Каждое правило состоит из левой и правой частей и записывается так: q → r.

S – аксиома грамматики. С неё начинается генерация строк языка с данной грамматикой.

Теперь мне бы хотелось процитировать Хантера: “Грамматика используется для генерации последовательностей символов составляющих строки языка, начиная с аксиомы и последовательно заменяя её с помощью одного из порождений грамматики”.

Интерпретаторы и компиляторы. Part 2.

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

Поговорим немного о синтаксических конструкциях.

ProcessWatcher. Part 3.

      Ну а теперь я предлагаю кратко рассмотреть программный код. Хочу сразу предупредить: код писался примерно с такой же скоростью, с какой мысли, по поводу того, что и как я хочу видеть в окошке консоли, у меня появлялись. Т.е. другими словами никакого предварительного планирования архитектуры не производилось и к правомерности использования тех или иных функций должного внимания уделено не было. Через некоторое время стало ясно, что list - скорее всего был не лучший вариант, нужно будет немного подумать и переписать, если лень не сделает свое дело)). Ну и сам набор методов можно было спроектировать по другому, более универсально. Но всё это дело недалёкого будущего, пока у нас есть некоторая база, с ней и будем работать.

ProcessWatcher. Part 2.

      Хотя официальной Part 1 не было, в дальнейшем я буду так именовать странички посвященные той или иной теме. Всякий лишний трёп буду стараться от сюда убирать и говорить только по теме. Ну так вот, продолжаю своё славное дело - работу над ProcessWatcher. Вчера меня эта идея серьёзно зацепила, поэтому сегодня решил немного поработать в этом же направлении. Просто хочется отдохнуть от той рутины, которой приходится заниматься ежедневно.

   Сегодня довольно жуткий день.
   Вместо того, что бы ехать на горячие источники, я заболел и торчу дома ((( !!!!
   Но! Как говориться нет худа без добра! У меня наконец таки появился свободный вечерок, а следовательно возможность пореализовывать свои разные странные идеи.

   Недавно наткнулся в интернете на лекции по физике Ричарда Фейнмана. Вещь просто потрясающая! Очень советую посмотреть! Найти можно на rutracker.org, там есть лекции которые Фейнман читал в Корнелльском университете. Говорит он естественно на английском, но есть субтитры, что очень радует. Всего лекций 4, и все они проходят под единым названием: "The character of physical low".

   Не отпускает меня всё таки идея про создание собственного интерпретатора.

   Ну вот опять в голове созрела, а точнее выкристаллизовалась определённая мысль!

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

   Попробую забыть всё и построить заново.

   Итак!

   Цель: создать ядро интерпретатора языка "Basic" (простите, пока пусть будет он, может быть в будущем сделаю реализации, чего-нибудь более интересного) на языке C. Почему только ядро и почему на C? Ответ достаточно просто: чтобы его можно было использовать во встраиваемых системах (Embedded systems).

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

   На сегодняшний день написано достаточно много книг по компиляторам и интерпретаторам, перечислять их пока не буду. Наверно среди них достаточно достойных и таких, которые в руки вообще брать не стоит. На первом этапе этого творческого пути я буду опираться на "Основные концепции компиляторов" Робина Хантера. Непривычно тонкая книга (зато удобно таскать), но коротко и по делу излагает материал.

   По сути компилятор состоит из двух больших частей. Первая реализует функцию анализа, вторая - синтеза. Для наших целей синтез в принципе не нужен. Это конечно очень интересная тема, но, я думаю буду касаться её довольно редко. Разве что, если будут появляться интересные идеи, и информация, которой захочется поделиться.   

   Как понятно из названия на этапе анализа производится анализ исходного кода программы, а на этапе синтеза - генерация машинного кода целевой системы. Давайте пока поговорим о более общей теме - компиляции.

   Эх эта тяга ко всеобщей унификации и упрощению! У меня кстати тоже присутствует, но только чисто из практических соображений. А в принципе очень хочется всегда сделать, что-нибудь своё, уникальное и неповторимое. НО! в унификации и упрощении (смотря с какой конечно стороны смотреть) есть свои плюсы. Плюсы будем рассматривать чисто со своих эгоистичных позиций. Первый плюс:с точки зрения исследователя задача создания универсальной системы очень интересная. Она заставляет подниматься на более высокий уровень и охватывать проблему целиком. Второй плюс: люди тебе скажут спасибо, если они без лишних телодвижений смогут работать с твоим творением. Третий плюс: в будущем тебе будет проще поддерживать существующие наработки и создавать новое.

  В компиляции по видимому унификация и упрощение - вопросы волнующие не одну светлую голову. Ну так вот, среди мне наиболее интересными кажутся идеи:

1. Универсального промежуточного языка. Суть в том, что мы все известные языки транслируем в один универсальный, а дальше уже его перерабатываем в код целевого процессора. Так, если у нас есть p языков и q платформ, нам нужно "всего лишь" реализовать p*q программных систем.

2. Компилятор компиляторов. Эта идея сильно перекликается с предыдущей. Суть в том, что есть программа, на вход ей подаём описание языка и целевой платформы (напр. x86, ARM и т.п.), а на выходе получаем компилятор с данного языка в нужный машинный код. КРАСОТИЩА!

   Ну пока на сегодня хватит, закругляюсь)))