Logo

31 мая 2020 г.

Переход на Git

Для хранения исходного кода в «Канторовых системах» до недавнего времени использовалась система контроля версий Subversion (SVN). Среди современных разработчиков она считается устаревшей, но в некоторых популярных проектах продолжает использоваться по историческим причинам. Та же причина была и в «Канторовых системах». Когда в 2007 году начиналась разработка, Git не был так популярен, еще не было GitHub. SVN же был хорошо освоен и оказался весьма пригоден для отслеживания версий кода. Подкупала его легкость.

Возможный переход осознавался давно. Пару лет назад изучался вопрос использования Mercurial и Fossil, некоторое внимание привлекала малопопулярная система Pijul. Для облегчения перехода была перестроена историческая часть дерева исходников на соответствующую классической для SVN branches/tags/trunk.

Препятствиями использования Git были:
  • Раздутый дистрибутив со встроенным Perl и MinGW, пытающийся превратить Windows в Linux. 
  • Необходимость использования собственного терминала Git.
  • Отсутствие адекватной графической оболочки, удобной настолько же, как RapidSVN для SVN.
Со временем все препятствия были преодолены разработчиками Git и инструментов под него. Теперь Git не содержит встроенного Perl, давая возможность установить собственный, используемый вне Git. Perl иногда нужен для сборки некоторых открытых библиотек, так что лучше устанавливать его отдельно. Мной используется StrawberryPerl. Есть теперь и возможность вызывать Git из командной строки Windows или любого консольного приложения.

Адекватным графическим интерфейсом для Git оказался GitKraken. Он выводит всё на вкладках, а не в одном большом окне. Лицензия позволяет бесплатно использовать GitKraken в частных проектах с некоторыми ограничениями, некритичными для «Канторовых систем».

Тем самым ситуация 2020 года оказалась похожа на 2007-й, но для Git. Он хорошо освоен, есть графический интерфейс, также освоенный. Что еще надо?

Преимущества Git для «Канторовых систем» следующие:
  • Возможность дополнять коммиты.
  • Возможность переставлять коммиты, менять их порядок.
  • Быстрая работа в сравнении с Mercurial.
  • Популярность среди разработчиков.
В настоящий момент в проекте один разработчик, так что распределенные возможности Git фактически не востребованы. Останутся заделом на будущее.

Для публичного хранилища после некоторых колебаний был выбран GitHub, с расчетом придать больше социальности «Канторовым системам». Посмотрим, как оно окажется на самом деле. Присылайте свои запросы на слияние (pull request) для CoreLite и PE Tool.

5 марта 2017 г.

Обрезка программ при помощи PE Tool

Когда Windows только освоила 32-битную платформу, все программы в ней грузились по одному виртуальному адресу. В Windows 2000 появилась возможность грузить программу по любому адресу, но он по-прежнему оставался фиксированным. А вот в ядре Windows Vista была реализована новая фишка — формирование адресного пространства программы случайным образом (ASLR), для реализации которой система научилась перемещать и программы тоже.

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

1 июля 2015 г.

«Hello, world!» из объектно-ориентированной ОС

Язык программирования Кантор назван в честь немецкого математика Георга Кантора, родившегося в Петербурге. Георг Кантор разработал теорию неперечислимых множеств — математическую основу фракталов. Объектная модель в языке Кантор также является фрактальной — это попытка переосмыслить принципы SOLID, чтобы создать объектно-ориентированную ОС.

Кантор разрабатывается как компилируемый язык и язык системного программирования, но основан на функциональной и объектно-ориентированной парадигмах. Цель — создать новые направления системного программирования: функциональное системное программирование и объектно-ориентированное системное программирование, а затем разработать перспективную ОС, которая не будет копией уже имеющихся.

Далее речь пойдет об альфа-версии Кантора, разрабатываемого на Delphi как интерпретатор — это первый шаг к самораскрутке компилятора. Со временем Кантор будет переписан на Канторе и научится собирать сам себя.

Уже на этапе альфа-версии важно проработать ключевые понятия чистой объектно-ориентированной среды, поскольку на первых порах роль объектно-ориентированной ОС будет выполнять сам Кантор. Для этого всем выбранным теориям нужно найти практическое воплощение, попутно переосмысливая привычные понятия ОС.

13 февраля 2015 г.

Неоднозначность разбора и возможный возврат elsif

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

Неоднозначность

Без elsif при синтаксическом разборе всегда возникает неоднозначность, поскольку на момент входа в оператор еще не известно, единственный он во вложенном блоке или нет. Все последующие блоки также под вопросом, поскольку теперь не понятно, какой end какой блок завершает:
if условие1 then
операторы;
else if условие2 then
операторы;
end;
операторы;
end; /* это лишний end или завершение предыдущего if,
не единственного в блоке? */
С привычными отступами выглядит понятней:
if условие1 then
операторы;
else
if условие2 then
операторы;
end;
операторы;
end;
Проблема характерна для любого языка с блочными операторами ветвления и свободной записью: SQL, Модула-2, частично Ада.

В Канторе я вижу два выхода:
  • Вернуть elsif и получить тонны ненависти от программистов, не любящих это ключевое слово.
  • Не бояться «лишних» end при разборе. Тут нужен дополнительный анализ — что делать с возможными неоднозначностями. В любом случае это усложнит компилятор и затруднит проверку синтаксиса.
Возвращение elsif, если случится, может быть частичным, — только для алгоритмических блоков. В выражениях с if/case вполне может остаться принудительное совмещение.

Принудительное совмещение в выражениях

В выражениях с if/case внутри веток могут стоять только одиночные значения или кортежи, поэтому принудительное совмещение не приводит к неоднозначности и elsif не нужен:
a = if условие1 then
значение1 // в выражениях точка с запятой не ставится
else if условие1 then
значение2
// из-за отсутствия точки с запятой никакие другие операторы
// тут недопустимы
end;
Пример с кортежем отличается только числом значений:
a, b, c = if условие1 then
значение1, значение2, значение3 // точка с запятой опять не ставится
else if условие2 then
значение4, значение5, значение6
end;

1 января 2015 г.

Отказ от ключевого слова elsif

Синтаксис Кантора вновь подвергся небольшому пересмотру: исключено ключевое слово elsif. Спасибо коллеге Zealint за наводку. На смену elsif приходит совмещение блоков, не требующее отдельного end. Это означает, что теперь вместо elsif нужно писать else case или else if, и ничего за это не будет.

Совмещение блоков

Совмещение блоков — синтаксический механизм в языке Кантор, позволяющий совмещать идущие друг за другом или вложенные блочные операторы с целью завершения их одним end.
В данный момент совмещение работает для блочных объявлений с of, блоков where all и where any, а теперь еще и для else case и else if.