Войти
ФлеймФорумПроЭкты

Ü (Programmiersprache) (74 стр)

Страницы: 171 72 73 74 75 76 Следующая »
#1095
21:43, 10 фев 2022

Panzerschrek[CN]
> Нема у Ü IDE
на лазарусе написать!

#1096
21:44, 10 фев 2022

Panzerschrek[CN]
> Отчасти проблема чинится строгой типизацией
Ну будет vector<size_t>...

#1097
22:00, 10 фев 2022

skalogryz
> на лазарусе написать!
Раз уж речь о IDE зашла.

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

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

Кроме проблем общего характера есть ещё частности. Разных IDE много, нужно под каждую популярную свой плагин заводить. А ещё есть разные версии одной и той же IDE. Плагин для QtCreator я забросил, ибо задолбался его изменять в связи с изменениями API плагинов этой IDE.

Короче, задача создания IDE практически возможна, но фактически сейчас для меня одного неподъёмна.

#1098
12:16, 13 фев 2022

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

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

Думаю так же запретить специальным методам быть не public, по тем же причинам.

#1099
14:12, 16 фев 2022

Panzerschrek[CN]
> Раз уж речь о IDE зашла.

Очевидное решение - запилить LSP-сервер на Ü. Будет искаропки работать в вскоде и прочих редакторах типа вима, емакса, саблайма етц. Но для этого по-хорошему компилятор надо изначально проектировать как набор библиотек и параллельно с ним разрабатывать LSP-сервер, систему сборки и репозиторий пакетов. Более-менее новые языки типа го и раста так и делают. Классический компилятор без тулинга аля GCC - это прошлый век, если не позапрошлый.

> Разных IDE много, нужно под каждую популярную свой плагин заводить.

Это в идеале, если в запасе есть лишний десяток человеко-лет. Большинство непопсовых языков сейчас ограничиваются максимум LSP и плагином к вскоду, ибо наиболее подъемное и кроссплатформенное решение. Делать под остальные IDE - ну такое. Студия вантуз-онли. Под жыдбрейнс IDE плагины надо писать на джаве или прочих JVM-базед языках.

#1100
15:47, 16 фев 2022

std::noob
Уже много раз про VS Code говорили. Панзершрек не переносит VS Code по религиозным причинам))

#1101
16:17, 16 фев 2022

std::noob
> чевидное решение - запилить LSP-сервер
А вот это интересно. Надо глянуть в эту сторону.

Vlad2001_MFS
> Панзершрек не переносит VS Code
Вроде это поделие не нужно. Language Server вроде поддерживается в QtCreator.

#1102
17:54, 16 фев 2022

Vlad2001_MFS
> Панзершрек не переносит VS Code по религиозным причинам))
Электроноговно кукарек говносборщик кококо. Ну да, ну да, религиозный фанатизм он такой :)

Panzerschrek[CN]
> А вот это интересно. Надо глянуть в эту сторону.
Посмотри еще clangd. Пользуюсь им уже пару лет, когда надо что-то писать на С++, полет нормальный. Но, повторюсь, для этого фронтенд компилятора надо структурировать в виде библиотеки и строить LSP-сервер поверх нее, как это сделано в шланге. Все это в идеале должно идти в комплекте с системой сборки. Например стандартная установка Go включает систему сборки go, LSP-сервер gopls и пачку вспомогательных утилит. Примерно как-то так и должен выглядеть тулинг для современных языков, на который можно ориентироваться.

#1103
17:55, 16 фев 2022

std::noob
> говносборщик кококо
Но эта срань и правда любит на минуту подвисать.

#1104
18:06, 16 фев 2022

1 frag / 2 deaths
> Но эта срань и правда любит на минуту подвисать
VS Code или ты в общем про gc'шки? У меня VS Code никогда и не зависал, хотя я уже не один год им пользуюсь как основной IDE. У меня даже на Intel N5030 он нормально работает с rust-analyzer(вот ему уже туговато прям)

#1105
18:09, 16 фев 2022

std::noob
> clangd
А QtCreator он вроде есть. Может  не он, но точно что-то на основе clang.

std::noob
> Примерно как-то так и должен выглядеть тулинг для современных языков, на
> который можно ориентироваться.
Проблема всех этих систем сборки - каждая считает себя исключительной. Из-за этого сборка химерной программы (на более чем одном языке) превращается в небольшой кошмар.

#1106
20:04, 16 фев 2022

Panzerschrek[CN]
> Короче, задача создания IDE практически возможна, но фактически сейчас для меня
> одного неподъёмна.
У меня VS то нормально не работет, осообено когда используются макросы в коде, рас целая корпорация не осилила, то и у тебя нет шансов))

#1107
22:23, 16 фев 2022

1 frag / 2 deaths
> Но эта срань и правда любит на минуту подвисать.
Тарас, ну камон, ты на 600-й целерон вернулся что ли?)

Panzerschrek[CN]
> Из-за этого сборка химерной программы (на более чем одном языке) превращается в
> небольшой кошмар.
Если один из этих языков С/C++, то да. Сборка превращается в небольшой кошмар. Охотно верю. Но что не так с системами сборки в нормальных языках? Они и зависимости автоматически подтянут, и проект соберут по несложному декларативному манифесту. Под системами сборки я естественно подразумеваю и пакетный менеджер тоже. Ну то есть как практически везде делают в 21-м веке.

#1108
22:26, 16 фев 2022

std::noob
> Но что не так с системами сборки в нормальных языках?
Попробуй собрать через Cargo программу с частями на C++ и Go. Задача будет не из простых.
Свой то код каждая система соберёт. А вот что-то окромя прикручиваться будет со скрипом.

#1109
(Правка: 22:39) 22:39, 16 фев 2022

std::noob
> Тарас, ну камон, ты на 600-й целерон вернулся что ли?)
Нет. Кора 3500. 4 гига оперативы. Что, этого мало уже? Говнокодерам давно рожи не били что ли?

Страницы: 171 72 73 74 75 76 Следующая »
ФлеймФорумПроЭкты