есть желание написать что то вроде make но для нормальной работы с кириллицей и корректной работой с файлами конфигурации на русском языке
какие есть предложения, мнения?
может детали спецификации?
make - спецификация
Страница: 1
Сообщений 1 страница 20 из 20
Поделиться12017-01-13 04:01:05
Поделиться22017-01-13 10:43:00
Если ты хочешь на базе XML-подобного языка, то сначала нужно придумать этот XML-подобный язык, а потом поверх него синтаксис make-подобной утилиты.
Я считаю, что в make-системах применение XML-подобного стандарта даёт преимущества по сравнению с исходным make.
Кроме того, в правилах make надо будет писать команды командного процессора, а к нему тоже нужно придумать русский синтаксис.
Можно, конечно, обойтись без XML-подобного языка, а синтаксис командного процессора оставить как упражнение читателям,
синтаксис зависимостей сделать как в portage, например (одна цель - один файл, в котором зависимости от других целей + инструкции).
Но выглядеть это будет как Кумир (то есть не дотягивать по возможностям до английских систем).
Итого, нужно минимум 4 спецификации:
1) на описание синтаксисов
2) на XML-подобный язык
3) на синтаксис командного процессора
4) на синтаксис описания зависимостей (make)
Поделиться32017-01-13 18:44:16
Есть ant с XML-подобным синтаксисом. Он абсолютно отвратителен.
В Яре планируется кое-что по системе сборки,
Модули
Библиотеки
потому что без системы сборки жить нельзя.
Поделиться42017-01-13 20:06:12
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
budden
А чем вы справку генерируете?
По поводу модулей.
1) У меня есть 2 модуля. 2 объекта тесно связанных.
TCompiler.Lexer
TLexer.Compiler
Лексер вызывает компилятор что-бы вывести сообщение о ошибке.
А компилятор обращается к лексеру что-бы получить позицию парсера. - она совпадает с позицией ошибки.
Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).
Delphi и другие паскали не могут разрешить данную задачу.
Вы как-то думали это разрешать?
2) Проблема совместимости. Когда имена библиотек или модулей или классов совпадают.
К примеру есть 2 каркаса и у них есть по библиотеке LCompress но каждая содержит пусть классы с одинаковыми именами TCompress но совершенно разными интерфейсами а потому не совместимы.
Как каждый каркас поймёт что это его библиотека?
Есть какой-то аналог namespace?
3) Проблема версионности. Пусть одной библиотеке нужен модуль с версией 1 а другой такой же модуль но версии 2. Заменить модуль 1 на 2 невозможно так как они не совпадают на 50%. Или исходники закрыты так как протараторенные.
Т.е. нужно одновременная работы нескольких версий и так что-бы они не мешали.
Как думаете это разрешить?
Поделиться52017-01-14 00:33:31
Глобальная структура генерируется вот этим проектом . Локальные кусочки - в формате markdown, генерируем их showdown-ом (в Яре имеется реализация JavaScript, написанная на лисп, поэтому не нужно вызывать для этого стороннюю программу).
Поделиться62017-01-14 00:52:24
Спасибо за хорошие вопросы.
> TCompiler.Lexer
> TLexer.Compiler
Если я помню, то в одном модуле Дельфи это разрешает - пишем
Код:
type TLexer = class TCompiler = class Lexer : TLexer; end; TLexer = class Compiler: TCompiler; end; end
Если они в разных модулях, то нельзя.
В лиспе по барабану, когда определены классы, хоть послезавтра. Реально ссылка разрешается в рантайме. Если до момента обращения класс не создан, тогда уже
будет неприятность. Я хочу сделать более строго, но, честно сказать, над этим вопросом не думал. Если я над чем-то не думал - я это возьму из лиспа и оно будет работать.
Но ничто не мешает потребовать, чтобы было написано
Код:
декларировать-класс Лексер модуль лексер;
о.класс Компилятор
поля
Лекс -- Лексер
кнп
кнкЭто следует добавить в стандарт. Равно как и синтаксис определения класса тоже я не придумал.
Поделиться72017-01-14 11:57:07
2) Проблема совместимости. Когда имена библиотек или модулей или классов совпадают.
К примеру есть 2 каркаса и у них есть по библиотеке LCompress но каждая содержит пусть классы с одинаковыми именами TCompress но совершенно разными интерфейсами а потому не совместимы.
Не знаю, что вы понимаете под каркасами. У нас система строится из библиотек, библиотеки состоят из модулей, модули из файлов.
Библиотека - это, грубо говоря, инсталлятор, который куда-то поставили, с метаданными, к-рые его описывают. Скажем, Qt.
Модуль - это единица сборки. Грубо - юнит в Pascal или один файл *.c в Си.
Файл - это просто файл 
Пр-ва имён есть, иерархические.
В целом идентификатор пишется в исходном коде так:
Код:
Кличка-библиотеки;Пр.во.имён:Имя
кличка б-ки и пр-во имён необязательны.
Цитирую описание:
Кличка позволяет в вызывающей библиотеке обращаться к вызываемой по сокращённому имени. Например, жена зовёт человека "солнце" или "тупица", а в библиотеке "коллега" локальной кличкой этого же человека является "шеф" или "лысый". То есть, кличка зависит и от того, кого зовут, и от того, кто зовёт.
Клички собраны в файле (или файлах) адресной книги, которая даёт ответ на вопрос, что именно библиотека А подразумевает под кличкой библиотеки "Б". Библиотека А1 может в качестве "Б" понимать Qt.3, а библиотека А2 - в качестве "Б" может понимать Qt.4.
Пространства имён примерно соответствуют модулям и структуре директорий внутри библиотеки, но это правило можно нарушить.
В данной системе библиотек решена проблема версионности и одноимённости, насколько её вообще можно решить.
Поделиться82017-01-14 11:58:46
А вообще, если Lexer в TCOmpiler объявить как TOBject и сделать ф-ю TLexer.НайдиМеня(Компилятор:TCompiler), То проблема практически исчезает.
Поделиться92017-01-14 14:19:27
Павиа написал(а):
Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).
Delphi и другие паскали не могут разрешить данную задачу.
Нет такой проблемы ни в паскалях ни в других полноценных языках.
А есть неверное проектирование.
TCompiler.Lexer
TLexer.Compiler
Делфи разрешает видимость переменных модулей с помощью uses в разделе реализации, поэтому включение в классы друг друга для одиночных объектов бессмысленно.
Обычно же в духе ООП класс (например, TLexer) описывается с частично нереализованными методами, которые уточняются после наследования в создающем реальный объект модуле со всеми зависимостями. Но есть uses после implementation и это на фиг никому не надо, пока переменные будут создаваться в единственном экземпляре.
Отредактировано MihalNik (2017-01-14 14:29:09)
Поделиться102017-01-14 14:47:26
Кто назвал это неверным и на каком основании? Для себя подумайте, откуда у вас такое убеждение и есть ли под ним реальные основания. Я для себя этот вопрос решил - я считаю, что такая конструкция соответствует природе вещей. В Яре такая возможность будет. Кто считает её не нужной, может не пользоваться. Есть она и в Си (C++).
Код:
struct кЛексер;
struct кПарсер;
struct кЛексер
{ кПарсер *Парсер;
};
struct кПарсер
{ кЛексер *Лексер;
};Поделиться112017-01-14 15:12:22
budden написал(а):
Кто назвал это неверным и на каком основании?
Выше всё написано:
Павиа написал(а):
По поводу модулей<...>
Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).
budden написал(а):
struct кЛексер;
struct кПарсер;struct кЛексер
{ кПарсер *Парсер;
};struct кПарсер
{ кЛексер *Лексер;
};
Могу ещё раз написать: если объекты - одиночные, то это явно избыточный код. В некоторых языках могут быть особенности, заставляющие такое писать, но я бы и на С/++ не стал так делать. В Делфи такой нужды нет.
Отредактировано MihalNik (2017-01-14 15:23:25)
Поделиться122017-01-14 17:19:31
Я примерно понимаю, сколько времени можно потратить на такой спор, и в результате все останутся "при своих", поэтому давайте не будем.
Поделиться132017-01-15 02:06:49
я честно говоря не вижу смысла спорить. ничего концептуально нового в компиляторах русских языков программирования на данный момент не обсуждается.
удобства и синтаксис относительны. это как цвет галстука - сколько не спорь, а у некоторых все равно будет бабочка
Поделиться142017-03-18 00:01:26
- Администратор
- Сообщений: 227
- Пол: Мужской
- Провел на форуме:
10 дней 22 часа - Последний визит:
2022-06-13 12:20:54
WebAssembly, или wasm — это экспериментальный эффективный низкоуровневый язык программирования, выполняющийся в браузере, который в данный момент находится в разработке.
Первоначальной целью языка является поддержка С/С++, тем не менее, также предполагается поддержка других языков.
WebAssemblу представляет собой переносимое абстрактное синтаксическое дерево, обеспечивающее как более быстрый парсинг, так и более быстрое выполнение кода, чем JavaScript. (подробнее - по ссылке)
- Вот бы его сразу на русском языке сделать... (исходники на хабе есть)))
Поделиться152017-03-18 02:03:42
- Активный участник
- Сообщений: 124
- Провел на форуме:
1 день 7 часов - Последний визит:
2017-05-17 13:39:02
Мне кажется, или тут администрация намеренно зафлуживает темы? Озаглавлено "make - спецификация", начали за здравие, потом перешли на XML, на ООП, а теперь еще и wasm приплели. Думается, это всё же разные темы, не стоит валить их в кучу.
Поделиться162017-03-18 02:14:18
согласен.
но как часто бывает возьмешься с другом партейку другую в шахматы - а на рассвете уже и о чем только не заходит разговор.
было бы не плохо если бы был человек трезво оценивающий ситуацию и имеющий волю вовремя сделать замечание.
Поделиться172017-03-18 14:47:58
- Активный участник
- Сообщений: 124
- Провел на форуме:
1 день 7 часов - Последний визит:
2017-05-17 13:39:02
Возвращаемся к теме.
Яр написал(а):
есть желание написать что то вроде make но для нормальной работы с кириллицей и корректной работой с файлами конфигурации на русском языке
Если речь о системах сборки для компилируемых языков, то сама идея make и makefile глубоко порочна, поскольку копирует американский подход. Такова американская культура производства: делать ущербные программы, а потом при помощи костылей заставлять их работать друг с другом. Необходимость "договариваться" -- тоже важная часть культуры, а makefile -- это тексты "договоров".
Одновременно с этим за пределами США существует нормальная модульность, и костыли ей не нужны. Все необходимые настройки и зависимости задаются входным языком (Delphi, FASM) -- всякие {$DYNAMICBASE ON} и FORMAT PE GUI пишутся в исходном тексте программы. Мне кажется, что в наших разработках надо следовать именно этой культуре.
Поделиться182017-03-21 13:51:51
на вкус и цвет как говорится. лазить по исходникам если нужно включить исключить файл для сборки. или выставлять дерективы компеляции для меня выглядит как возвращение в каменный век. получается что исходник жестко связан с ситемой сборки и знает не только про обекты и переменные но еще и понимает как ему нужно собираться
система сборки типа make имеет свои недостатки и свои преимущества.
Поделиться192017-03-21 18:20:46
- Активный участник
- Сообщений: 355
- Провел на форуме:
18 дней 8 часов - Последний визит:
2020-11-06 19:50:25
Сегодня полдня убил, что бы сделать установочный deb пакет из исходников.
Так вот убедился что makefile ненужны. Вместо готового автомобиля вам предлагают скриптовый язык. Не ведитесь на это. Таких языков 100 000 и изучать каждый вместо нажатия пары кнопок это издевательство.
Недостатки make устраняют auotomake и cmake, и qmake , dh. Но они не решают всех проблем вам понадобиться dpkg и rpm А проблемы dpkg устраняет tcl и checkinstall.
Слава богу последняя программа вменяемая.
Но всё равно для устранения проблем вам понадобится ещё и другие программы как то autoinstall. И не удивлюсь если появится configureinstall.
На самом деле эти горе пакеты решают маленькую проблему и несут ещё больше проблем чем решают. У каждой этой утилиты свой собой язык. На котором кому-то придётся кодить. Но в них либо нет нужных функций либо нет проверок или нет описания и так далее.
Корочи это болото.
А всё потому, что неработают обратные связи. Вместо устранения недостатков все делают подпорки.
Поделиться202017-03-21 19:25:44
Яр написал(а):
получается что исходник жестко связан с ситемой сборки и знает не только про обекты и переменные но еще и понимает как ему нужно собираться
Ну иначе получается какой-то костыльный язык, на котором явно нельзя реализовать даже его самого.
Павиа написал(а):
На самом деле эти горе пакеты решают маленькую проблему и несут ещё больше проблем чем решают.
На самом деле эти пакеты решают проблемы текстового редактора, являясь его расширением.
Отредактировано MihalNik (2017-03-21 19:30:20)
Страница: 1