OberonCore

А, кстати, анализатор висел всегда на Shift+Ctrl+K... Или это у нас уже внутренняя фича сложилась, даже не знаю.

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

В Блэкбоксе красиво, что можно налету подключить файловую систему в RAM. Проводить все манипуляции, а диск будет не тронут

А вот в ББ сейчас можно написать
MODULE Views; END Views.
нажать ^K, и все прекрасно. Только в журнале подозрительно много текста.
Потом выйти-войти - точнее, не войти. Без всякого автосохранения.
Хорошо, если ББ 2.0 запущен с трехъярусной файловой системой (и даже в этом случае - головняк ковыряться в путях и файлах, и новичку это не по силам), а если нет?
Мне это кажется небезопасным и заставляет думать о том, что надо что-то изменять, так чтобы оставалось просто, стало неубиваемо, но при этом не ограничило профессионала.

версионная псевдо-фс. даёт прозрачные точки отката, как для всей системы, так и отдельно для файлов. эта же механика может работать как система управления версиями. джинн думает. люди забыли про версионные фс, а они рулят. с ней — делается элементарно: при каждом успешном запуске среды создаётся именованый чекпоинт. если потом при запуске среда упала — то она это заметит, и предложит взлететь из чекпоинта.

реализовать, понятно, несложно, но надо продумать интеграцию в систему, чтобы оно не мешало, и вообще ощущалось как: «да всегда тут было! как это 'не было'?!» пока что ещё подумаю, а потом просто напишу и посмотрю, где выпирает.

Раньше результат писался в отдельные папки Code Sym в корне ББ, их можно было удалить в случае чего. И ББ продолжал работать. Для школьной сборки лучше упаковать многие модули в исполняемый файл, чтобы их нельзя было повредить. А для профессионалов, помниться, мы решили так, что при современной скорости интернета не проблема скачать свежий дистрибутив и заменить повреждённые файлы.
Это намного лучше с позиций сохранения простоты фреймворка, чем создание точек и т.п. В 2.0, которую публикую, постараюсь стремиться к простоте, стабильности и преемственности. Да в ущерб много чему, но таков Путь

2.0 уже не совместим с кодом для прошлых версий без правок. отличный момент, чтобы добавить ещё полезного (к тому же чекпоинты сами по себе вообще не влияют на совместимость, как и любая правильно сделаная installable FS по идеологии EthOS).

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

конечно, всегда можно возразить, что никто не мешает делать сборки. но это, по-моему, не лучший путь: и так уже довольно сложно выяснить, что же именно ставить: 1.7 от центра? 1.8 от ocore? 2.0? а если поверх этого будет ещё 100500 сборок, то будет вообще непонятно даже с поллитрой. и прелесть попытки найти нужную сборку, надеясь, что в ней есть всё, что надо, не добавит человеку желания пользоваться системой.

2.0 сейчас в отличной позиции для того, чтобы превратить BBCB из системы, которой будет очень удобно пользоваться, если предварительно долго-долго обрабатывать её напильником, в систему, которой удобно пользоваться сразу после установки.

Сейчас цель сделать стабильный выпуск без нововведений. Их и так более чем достаточно. А если вы будете отрабатывать какие-то очень классные вещи на будущее, то это же замечательно! Но это не приближает стабильный выпуск

а. я вас понял так, что вы в принципе против добавления чего-либо. если идея: «сначала стабильный, а потом его расширим» — то приношу извинения, зря спорить начал, тут не с чем спорить. ;-)

Так я вот попробовал внедрить, и возник вопрос. Если модуля вообще нет на диске, то его всё же не надо сохранять может? Может это просто тестик небольшой. И человек хочет откомпилировать, а сохранять модуль даже не собирается. Что тогда? Или всё же принуждать к сохранению?

мне кажется, что лучше принуждать. BBCB, конечно, stable as rock, но бережённого, так сказать… а если человек уже достаточно поднаторел, чтобы понимать, чем чревато пробование без сохранений — то он уже и менюшку себе починить может. думаю, так.

Я вообще не понимаю смысл сего действия. Почему именно перед копиляцией?

я так понял потому, что добавление полноценного механизма автосохранения требует много кода, а этот частный случай — просто лёгкой правки меню. beta than nothing, так сказать.

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

Постоянное автосохранение нужно для глючных сред, которые падают постоянно. Блэкбокс таким никогда не считался. Так что надо его вернуть в это замечательное стабильное состояние массовым тестированием и предложением исправлений. Я сейчас занимаюсь тем, что все изменения отличия от 1.7.2 помечаю зелёным цветом, а то, что удалили, возвращаю в комментариях, с попыткой объяснить, почему это было удалено. Документацию по изменениям фиксирую тут https://wiki.oberon.org/blackbox20

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

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

Очевидно вы рассматриваете документы Блэкбокса только в контексте текстовых файлов, когда проводите такие размышления, но это ведь только частное применение!

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

А вот что если пользователь не хочет сохранять изменение в исходнике? Он быстро попробовал что-то на коленке, изменив готовый исходник, даже не собираясь это сохранять? Я, кстати, часто так делаю.

Нет. "Сохранить" нужно. Не надо делать из пользователя дурака. Хочет сохранить - сохранит сам.

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


А ещё, например, запустил компиляцию, а там ошибки. И у нас новый сохраненный текст и старый код, от которого и исходника уже нет.

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