варим Эль

там все достаточно прозаично - переопределяешь bgerror,

Спасибо, видимо, придётся пока так обходиться. В принципе, окошко со стеком вываливается и найти ошибку можно.

Как думает сообщество - имеет ли смысл разбить IDE на множество независимых инструментов, каждый из которых запускается в отдельном wish и имеет свой соответствующий (отдельный) набор лисповых тредов?

Со многих точек зрения это кажется довольно привлекательным. Во-первых, проще. Во-вторых, разные инструменты можно разрабатывать отдельно и они слабо связаны между собой.

Так устроен в одном из вариантов Lispworks - на каждый «tool» (редактор, листенер, поиск по файлам) запускается свой тред или набор тредов. Каждому тулу соответствует своё окно со своим Menu Bar-ом.

не понимаю вашего фи в сторону оной.

Память. Там где MS VS ест всего 300-500 МБ, поделия от JetBrains требуют раз в 10, а то и 30 больше.

Но это ладно, память всегда можно докупить. А вот быстродействие — нет. IDE от JetBrains имеют привычку тормозить даже на конфигурациях i7 + 32 GB RAM. После того, как пересаживаешься на них с реактивных MS VS и Qt Creator, чувствуешь себя слоупоком. Только нервы портятся при таких подвисаниях и общей нерасторопности.

Имею ввиду CLion и Android Studio. Может сама ванильная IDEA и поприличнее себя ведёт, но поделия обозначенные выше — в топку.

Концепция опять поменялась - я нашёл консоль с редактором, написанную на tcl/tk ( http://tkcon.sourceforge.net/ ). Она также умеет открывать файлы в отдельных окнах, как мне нравится. Теперь впиливаю в неё поддержку для CL (при этом ломается поддержка tcl, но что поделать...). На сегодня она уже научилась коннектиться к серверу SWANK и отправлять туда выражения для вычисления, а оттуда приходит ответ, к-рый печатается. В ближайшее время планирую сделать поиск определения и completion. А дальше посмотрим.

Репозиторий тут: https://bitbucket.org/budden/clcon

Пока вот что:

http://ic.pics.livejournal.com/budden73/16984381/5604/5604_900.png

Комплишен для символов и имён файлов, поиск определения, история команд.

Но конечно, всё это ещё просто прототип. Например, не понимает смену пакетов.

Процесс идёт. tcl/tk - прекрасная вещь (во всяком случае, пока). Лисп, конечно же, тоже прекрасен. Вот такие картиночки имеются:

http://budden73.livejournal.com/15633.html

Говно какое-то из 80х

Говно какое-то из 80х

А что у Вас является «неговном»?

Atom

Atom

Смешная шутка.

Атом красивый. И уже не так и тормозит. Хотя регулярно пользоваться им я бы не смог.

Атом красивый.

У меня емакс красивше.

И уже не так и тормозит.

емакс всегда будет быстрее и менее требователен, чем это недаразумение

Хотя регулярно пользоваться им я бы не смог.

а я о чем?

Говно какое-то из 80х

Моё мнение состоит в том, что говно - это как раз «современные» интерфейсы для тех, кто не осилил клавиатуру а умеет только пальцем фотографии на смартфоне перелистывать. Но не о них моя забота.

Ну и что плохого в 80-х? Именно тогда были написаны все самые интересные и полезные программы. А сейчас индустрия производит в основном одни веб-страницы. Скукота!

Придумал слоган для атома: «Атом научит ваш Core i7 тормозить так, как IBM PC XT с 256 кб оперативы и редактором MultiEdit не умел в 1993 году». Мы живём в свободном мире, пользуйтесь атомом, кому он нравится.

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

Кстати, нашёл, что на tcl/tk написан гуй для https://ru.wikipedia.org/wiki/BRL-CAD

Про ANSYS я уже раньше писал.

вы опять распетушились

порадовал тэг «энергетика» :)

Это просто был единственный когда-либо использованный тег в моём ЖЖ. На всякий случай поставил теги на две последние записи.

Сделал вики на сайте проекта.

Я вот вдруг подумал, а не из веба ли взялось словосочетание «на районе»?

Потому что хотел написать «На проекте». Хотя «на проекте» - это ещё и «дом 2».

На Яндексе. Хотя нет. В ЖЖ, ВКОнтакте. Но на ЛОРе.

Спать пора уже, глючить начинает :) Нет, вещества я не употребляю.

Вики здесь. Просто раньше я не знал, как на битоведро картинки залить, поэтому и писал в ЖЖ. Теперь скриншоты будут лежать на своём законном месте.

https://bitbucket.org/budden/clcon/wiki/Home

Процесс идёт. Сделал другую часть заготовки просмотровщика ошибок. Не ту, что достаёт гиперссылки, а ту, что будет отрисовывать. Код: https://bitbucket.org/budden/clcon/src/e9e92b083c952e80939128a64d32b08cc4acde...

Скриншот: https://bitbucket.org/budden/clcon/wiki/Home

Переписал руководство по инсталляции. Ща пойду проситься в quicklisp.

Не пойду пока - там нужно ещё заполнить кое-что для порядка. Потом.

Вопрос к публике - кто-нибудь хочет попробовать сабж под виндой? Имеет ли смысл заняться изготовлением portable версии в виде архива? Говорю сразу - пока поделие не юзабельно - работает до первой ошибки в лисповом коде, после этого диалог с лиспом прекращается.

Чувак, Common Lisp для программистов, а не для домохозяек. Программисты используют emacs или vi(m). Использование того или другого определяется какой-то хромосомой или еще какой хренотенью. Для обоих (неудивительно) уже есть SLIME и SLIMV. Если чувак не использует ни emacs ни vim, то он не программист. PERIOD. Тогда ни ему Common Lisp не нужен, ни он Common Lispу. END OF PROOF.

Расскажи это любому программисту на 1С, у которого такая зарплата, которая тебе и не снилась.

Сегодня немного продвинулся с просмотровщиком ошибок. Процесс сильно замедлился почему-то. Однако просмотровщик ошибок приемлемо заработал. Можно делать команду «Скомпилировать и загрузить файл».

Раньше каждый открываемый файл создавал новое окно редактора. Это было очень плохо. Теперь все файлы открываются в одном окне. Для переключения между открытыми файлами сделан «buffer list», похожий не емаксовский. Надо бы конечно сделать фильтрацию по буквам, как в iswitchb, и табы, как в файрфоксе, но пока и так сойдёт: по сравнению с отсутствием команды Save это, право, мелочи.

Пополнил страничку со скришнотами: https://bitbucket.org/budden/clcon/wiki/Screenshots . Заодно там теперь можно видеть настоящий просмотровщик ошибок с реальными ошибками, а не макет.

Процесс идёт, хотя как-то медленно. Скиллы по tcl/tk постепенно растут. Жаль, что приходится редактор с нуля писать - не смог подобрать подходящий.

Момент создания дебаггера близится... близится... близится...

Написал опасную функцию, которая позволяет с сервера выполнять произвольный код в IDE. Это аналог переменной slime-enable-evaluate-in-emacs . Если происходит вход из IDE на SWANK, расположенный в удалённой системе, получаем уязвимость. Ничего, потом можно будет поправить. «Сначала сделай, чтобы работало»

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

Приступил к дебаггеру. Пока не очень страшно. Научил его показывать condition, заголовки кадров стека и вызывать рестарты.

Это приятно. Раньше при появлении исключения просто исчезала подсказка и надо было переподключаться к SWANK-у. Теперь процесс работы в REPL становится более нормальным.

Вот картинка https://bitbucket.org/repo/E4aRar/images/3487089019-debugger1.png

Мне нравится (сам себя не похвалишь - никто не похвалит).

Всё движется очень медленно. Мучаюсь с поиском. treeview - это Зло. text-based интерфейсы - это Наше Всё. Потому что дерево без поиска - это не дерево, а Злое Зло. Вот и приходится придумывать, как встроить нормальный поиск в дерево. И там возникают разные нюансы.

Однако наконец-то получился работающий поиск по дереву и по тексту. Более-менее сносно.

Дебаггер уже почти умеет показывать локальные переменные, но это он давно научился.

Наконец написал на заглавной странице цели проекта:

1. IDE для встраивания лиспа в качестве скриптового языка в приложения.

2. Простая, устанавливаемая за одну команду среда разработки в CL для начинающих.

Цели эти несколько разные. Интересует мнение сообщества - какая цель более актуальна? Думается, цель 2 более жизненна - вроде лисп ещё в некоторых ВУЗах преподают.

по-моему, вторая цель важнее именно для начинающих, на замену lispbox. самые упорные и emacs/SLIME осилят.

вроде лисп ещё в некоторых ВУЗах преподают

например, вот эта книга: на основе lispbox + PCL Питера Сейбеля.

вообще, замечательный пример, я считаю:

1. для гуманитариев-историков !!! (начинается книжка так: качайте lispbox, там емакс, читайте PCL и вливайтесь)

2. эпиграфы в тему, хотя иногда довольно повёрнутый программистский юмор. для компьютерных археологов-фольклористов, наверное :)

3. практичный характер: авторы просто не мудрствуя лукаво напихали в контент книжки 10500 упражнений (наверное, специально для тех, кому язык программирования лисп покажется непрактичным непонятно чем. как же, вот у нас 10500 часов практики)

если что-то типа такого вот, только с ABLE,tcl/tk вместо lispbox — ящитаю, отлично будет.

1. IDE для встраивания лиспа в качестве скриптового языка в приложения.

тут не очень понятно зачем надо, ИМХО. я думал на такую тему — как ни крути, емакс получается. или лисп более упрощённый (scheme или emact/openlisp), или что-то типа (S)XEmacs + FFI.

emacs box, в общем. хотя потыкать tcl/tk сразу — интересная цель, но ИМХО и через SLIME+quicklisp несложно (всё равно он уже как правило настроен).

хотя что-то типа tcl/tk + lispbox в виде самодостаточного портабельного бинарника с флешки, например — тоже интересно.

text-based интерфейсы - это Наше Всё. Потому что дерево без поиска - это не дерево, а Злое Зло.

ага, в лисповых модах в окне настроек моды именно поэтому модальных диалогов и нет, модальность — зло :))

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

типа инкрементального поиска со скрытием/подсветкой совпадений по узлам дерева ??

aга, в лисповых модах в окне настроек моды именно поэтому модальных диалогов и нет

... в емаксе, разумеется.

вообще, если бы я писал какую-нибудь лисп-книжку, интересно было бы писать по образу и подобию emacs-starter-kit + комментарии от Eric Schulte у него на гитхабе, на основе Emacs org-mode babel.

в духе Literate Programming.

таким образом можно и целый емакс на tcl/tk написать, если разогнаться как следует :-)))

а в списке рассылки picolisp какую-то EmacsOS PilOS пилят

Ого, мне тут пишут. Не понял, почему уведомления не приходят.

Что скажу: дебаггер доделал до состояния, когда в него уже можно поиграться. Готовлюсь к чему-то вроде «релиза», хочу сделать один архив, к-рый открываешь и запускаешь (наверное, под офтопик). Собираю мнения о том, что в него включать, а что не включать. На полноценное IDE для начинающих он не потянет, но хотелось бы получить обратную связь. В нём точно будет quicklisp.

А вот описок опций, которые все не потяну. Из них нужно выбрать, скажем, три:

1. табы для листания окон в редакторе (нормальные не знаю как сделать, кое-какие можно)

2. интеграция со справкой (CLHS, docstring, quickdocs)

3. slime-who-calls и т.п.

4. grep

5. размещение окон по экрану

6. автоотступы

Жду от вас деклараций вида: «если будут фичи N1,N2 и N3, то я готов буду посмотреть твою поделку».

типа инкрементального поиска со скрытием/подсветкой совпадений по узлам дерева ??

Слишком жирно. По Ctrl-F открывается окошко, жмём на кнопку Find next - находится следующий элемент. F3 нету пока что. Множественную подсветку я не люблю.

только с ABLE

ABLE я уже «уделал» вусмерть, не считая автоотступов. У меня настоящий поиск определений, настоящий отладчик и инспектор. В ABLE нет ничего из перечисленного. Надо посмотреть, можно ли из ABLE автоотступы спереть.

тут не очень понятно зачем надо,

Значит, цель конкретизирована - IDE для начинающих.

но ИМХО и через SLIME+quicklisp несложно

Смотри:

- Alt-. работает в Русской раскладке
- Поиск по Ctrl-F, открывается диалог с галками «match case» и «up/down».
- продолжение поиска по F3 (пока только в тексте)
- В инспекторе хождение по истории: Alt-влево, Alt-вправо. 
- В инспекторе обновить - F5. Открыть ссылку - одинарный щелчок.
- В дебаггере переход на исходник и инспектор для переменной - двойной щелчёк. 
- Открыть скрытые подробности кадра стека - 
стрелка вправо, плюс, щелчёк на треугольнике
- Большинство команд доступны через меню по подчёркнутым цифрам. 
- Закрыть любой инструмент - крестик (закрыть окно)

Т.е. очень простые и общечеловеческие сочетания клавиш на всё. Думаю, что по сравнению с емаксом это будет просто рай для новичка.

tcl/tk

Эдак инфраструктура Common Lisp никогда не двинется в лучшую сторону. Серьезно, tk страшен, как смертный грех.

Спасибо за твоё мнение. Проходи :)

А что ты используешь? LTK или CL-TK или что? :-)

А что ты используешь? LTK или CL-TK или что? :-)

Зри сюда: https://bitbucket.org/budden/clcon/src/default/doc/client-server.md

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

Также посмотрел на некоторые фичи из списка.

фича 1 - окно с закладками. Пример резиновых закладок - здесь: http://wiki.tcl.tk/20057

Плохо в них то, что при нажатии Ctrl-Tab на краю оно не листает за предел экрана, а возвращается к началу. Для листания нужно нажать на кнопочку мышью. Уродство, конечно, ломает привычную логику файрфокса, но для показухи сойдёт. Можно сделать по-другому. Разместить на одну закладку список буферов и пометить его "..." . Тасовать буферы по MRU, а "..." всегда ставить слева. Когда закладки не помещаются на экране - то просто пусть не помещаются. Хотя наверняка не всем понравится тасовка по MRU.

Также посмотрел на фичу 6 - автоотступы. Надо дербанить ABLE, пока до конца не разобрался. Видимо, сработает идея о том, что нужно отлавливать все события работы с текстом, отправлять изменения в лисп, на стороне лиспа собирать такую же строку, всю работу делать с этой строкой, а потом в tcl уже отправлять результат. Отлавливать все события работы с текстом я вроде уже умею, хотя надо посмотреть, как будет оно работать. Всё же проблема временного лага между отправкой события и возвратом результата доставляет.

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

Тему завёл: clcon - новая IDE для Common Lisp. Выбираем фичи для пре-альфа-релиза

Посмотрел, как able делает автоиндент. Функция able::indent-current-line обращается к родовой функции ltk:text . Для неё написан метод, который тупо запрашивает у tcl _весь_ текст файла из буфера редактирования.

Мощно! Но как ни странно, он более-менее успевает делать indent даже в середине 4-мегабайтного файла. Конечно, лагает, но в принципе, наверное, можно работать. Другое дело, что отступ он как-то неправильно предложил делать, а потом упал в дебаггер и пришлось применить kill, но это уже нюансы. Причём раскраска этого же файла шла очень долго, а автоиндент приемлемо.

Видимо, придётся пока что сделать такое же уродство, т.е. качать через сокет весь файл целиком на каждый чих. Потом ускорим.

Посмотрел снова на одуванчик (бывшая цикута). Там есть липовая мода со всем этим паредитом. И плюс к тому, правильная, хоть и тормозная, раскраска. Она даже раскрашивает желтеньким квазицитаты, а в них черненьким подстановки. Это очень правильно и полезно.

Поскольку у нас IDE для начинающих, то будем считать, что гигантские файлы размером в мегабайты не будут открываться. swank.lisp размером 142 кб открывается и раскрашивается за секунду-другую - приемлемо.

Значит, теперь у нас страшная задача - подменить бекенд. Вместо лиспового бекенда подсунуть ctext. У меня уже всё дрожит внутри от ужаса.

А какие, в общем-то, проблемы сделать автоиндент? Даже для ЯП с более сложным, чем у скобочного лиспа, синтаксисом он тривиально довольно делается, тот же питон взять.

Придумал два варианта, оба плохие. Чем-то напоминает игру в «морской бой» (интересно, современные люди вообще меня поймут с этой аналогией?). В обоих вариантах нужно будет поддерживать идентичные копии текста на клиентской и на серверной стороне. Вопрос в том, кто стреляет и кто вообще капитан.

1. Вариант, основанный на лиспе. В этом случае фактически редактирование происходит в лиспе. Текст read-only. События клавиатуры и мыши пересылаются в лисп, там обрабатываются в невидимом буфере, все изменения буфера отправляются обратно в tcl/tk, где и применяются реально. Например, нажали букву ё. Отправляется в лисп событие «нажата ё». Лисп думает, как покрасить букву ё и когда надумал, отправляет в tcl команду «вставь букву ё, строка такая-то, колонка такая-то, и покрась зелёным». Вариант плох не столько тем, что это может тормозить. Сколько тем, что редактор по сути придётся писать с нуля. Или опять получится емакс. Впрочем, на так уж страшен емакс - собственно редактирование текста в нём вполне приемлемо работает.

2. Основанный на tk. Здесь всё редактирование происходит в tcl-ном виджете text и мы лишь в отдельных случаях отправляем запрос в лисп. В каких это отдельных случаях? Например, когда надо покрасить. Пусть пользователь нажал «ё». text выполняет это, вызывая команду insert. К команде insert приделана тележка, которая отправляет в лисп событие «вагон 45434, вставлена буква ё, строка 25, колонка 8».

Дальше опять вопрос, будет ли tk ждать ответа на это событие или продолжать работать асинхронно. Вопрос не праздный. Пусть потом букву сразу стёрли, а лисп тем временем написал «В ответ на исх.N 45434 - раскрась текст в строке 25, колонке 8 в зелёный цвет».

Раскрась-раскрась, а чё раскрашивать-то? Нечего уже раскрашивать. Значит, тут нужен алгоритм, чем-то похожий на слияние веток в системе контроля версий. Ничего себе! Мы все знаем, что этот алгоритм не всегда работает. Короче, тупик здесь с асинхронщиной. Либо нужно жить по принципу семян дерева - порождать события раскраски в избытке. Каждое событие раскраски будет передавать «точку неизменности». Если за время раскраски отредактировали текст до точки неизменности - нужно начинать раскраску сначала. Это чем-то похоже на алгоритмы, виденные мною в clojure и раньше я уже что-то подобное пытался измыслить.

В XXI веке я стараюсь по возможности не «делать», а «интегрировать». Так дела делаются гораздо быстрее, порядка на 2. Соответственно, не только автоиндент, а всё, что прилагается к парсеру: раскраска, определение, в какой функции мы находимся, подсветка парных скобок, жонглирование s-выражениями. В одуванчике лисп-мода занимает 1800 строк кода.

В XXI веке ты используешь в качестве аналогии игру в «морской бой». Но, допустим, я понял, что имелось в виду.

Я, кстати, заинтересован попробовать твой редактор-IDE, пусть и без особого энтузиазма.

Угу. В общем, план на ближайшее время - делаем редактор и релиз потом. Делать редактор - потянет, наверное, на пару недель. Пока рабочий вариант 1 - командует лисп.

2.

Пусть потом букву сразу стёрли, а лисп тем временем написал «В ответ на исх.N 45434 - раскрась текст в строке 25, колонке 8 в зелёный цвет».

Добавь проверку на стороне tk: если после того, как «тележка» отправила событие, в текущем редактируемом «регионе» произошло новое изменение (или вообще при любом изменении текста), то игнорировать ответ лиспа, и посылать ему новое событие. Я не припоминаю, чтобы где-то была абсолютно умная и корректная инкрементальная раскраска, правильно срабатывающая на изменение величиной в один символ.

Спасибо за советы. Текущий план будет по п.1. У меня есть собирающийся, запускающийся и работающий oduvanchik с X бэкендом. Думал, я зря его ковырял, а вот теперь пригодится он. Нужно сделать две вещи:

а) эхо из одуванчика в clcon. На каждое изменение текста в одуванчике делаем такое же изменение в текстовом виджете (отправляем сообщения из лиспа в tcl).

б) обработку абсолютно всех команд, свойственных виджету text. Для это text делаем readonly (это я уже умею), все события перехватываем и в одуванчик отправляем достаточную информацию для воспроизведения этих событий на стороне лиспа.

По успешному завершению пп а) и б) должна создаться иллюзия, что мы работаем в tcl. Вопрос только в том, какой из них более рискованный. Тогда с него и надо начать. Думаю, что это пункт б.

Это я к тому написал, что в одуванчике есть уже раскраска. Может быть, там уже сделан какой-нибудь толковый алгоритм на эту тему. И по ходу выполнения п.(а) этот вопрос как-нибудь сам рассосётся.

Кривой он всё-таки. Надо как-то по-другому.