Друзья, вы не поверите чем я был занят всю последнюю неделю, нет, разумеется, не вообще, но только что касается практического программирования. Так вот, будете смеяться, - изучал принципы работы с блоками! Убил на это дело, ну, думаю, ни много ни мало, часов десять! В общем, достиг приличных результатов, теперь я умею создавать, удалять, редактировать, мэппировать, копировать, перемещать и т.п., короче, производить все необходимые манипуляции с блоками. Зачем, спросите вы, когда на сегодняшний день блоки считаются пережитком далёкой архаики? Что же, с ответом затрудняюсь, но у меня отчего-то возникло стойкое убеждение, что я обязан научиться работать с блоками, в противном случае я бы перестал себя уважать! Да, в наше время многие Форты вообще лишены средств поддержки блоков, некоторые же, в том числе и мой любимый Swift, имеют такую функцию исключительно опционально, чтобы сохранять совместимость с совсем уж малочисленным классом блок-ориентированных Фортов. Кстати, нынешние со-осные (работающие из-под ОС) Форты, даже если и позволяют производить операции с блоками, то подразумевается уже совершенно иной, в корне отличный от оригинального механизм. Суть в том, что такие, со-осные, Форты, при работе с блоками, конечно же, работают с памятью накопителя вовсе не напрямую, но создают специальный файл, причём он, файл, может содержать от одного, до... не знаю точно до скольких, но сотнями число точно не ограничивается, блоков.
Ага! Вам наверняка не терпится узнать, по какой такой причине я столь проникся обожанием СвифтФорта? Да потому что именно он, Свифт, избавил меня от страха перед документацией! Ещё бы, а вы как думали, откуда я располагаю до того обширными сведениями относительно работы с блоками?! Теперь я не боюсь обращаться к докам, наоборот, считаю их великолепным воспомоществованием, и это не какие-нибудь ламерские доки по девайсу, это, блин, серьёзные доки! Фуф, ну ладно.
Кстати, ещё пару слов о блоках, вы, случаем, не знаете, как положить вновь созданный файл (да, тут может возникнуть путаница, но я имею в виду обычную запись, в общем, информацию, а путаница возникает оттого, что при ходе вещей, который я описал выше, получается чёрт знает что, так как на самом деле гипотетический блок кладётся в файл, а не наоборот) в блок по конкретному адресату? Проблема в том, что по дефолту новый файл автоматически падает в блок 0, что дико неудобно, потому что с этим блоком постоянно происходят какие-нибудь чудеса, я даже загрузить его не могу. Нет, понятно, если создать файл на два блока, то можно воспринимать второй как первый, он будет числится под №1 (1 LIST), но хотелось бы всё-таки уточнить. Должно быть, следует также отметить, что в со-осных Фортах, и Свифт в частности, не знаю как дело обстоит с блок-ориентированными, нельзя вывести или отредактировать блок, который не находится в "материнском" файле, то есть, вы не можете взять произвольный блок, и распечатать или заполнить его, если он "пуст" (держите в уме вышеописанную схему?). Я пробовал создать новый файл по заданному адресату массой способов, например так:
Код:
1 MAPS 1 NEWFILE somefile 1 MODIFY
Эта строка, по моему разумению, должна создавать разметку под номером 1 (PART), в которую падает новый файл somefile.src (расширение добавляется автоматически) размером в один блок (на самом деле это файл содержащий один блок) и MODIFY открывает его в первом блоке в режиме читки и записи (только для читки применяется слово READONLY, что логично), однако, на самом деле всякий раз происходят разнообразные конфузы; даже когда .MAP выводит карту, и в ней значится блок и адрес файла, его размер показан как 0, чего, понятно, быть не должно и не может, и редактировать его нельзя. Кстати, если говорить не о создании, а о загрузке, то данная строка выполняется абсолютно корректно, естественно, заместо "1 NEWFILE somfile" должен быть указан путь до файла. В принципе, эта та единственная проблема, которую я не смог решить, больше вопросов по этому, блокам, поводу, вроде бы, не осталось.
Ах да, чуть не забыл, я пробовал создать сырец "блочного формата" с помощью обычного редактора (тот же gedit), и задать ему расширение .src, но в таком случае, при загрузке, файл выводится криво, строки не соблюдены, и весь блок заполнен какими-то квадратиками с единичками и ноликами внутри, впрочем, я и сам догадываюсь о причине такого поведения, видимо, это происходит потому, что такой файл не содержит информации о количестве содержащихся в нём блоков и ещё какой-нибудь, плюс к тому, Броуди говорит:
Цитата:
With current Forths, disk memory resides in OS files. There are ways to attach specific OS files to the "Forth disk." Due to the special 16 by 64 format of Forth blocks, OS utilities consider them as binary data and cannot generally print, list, filter or edit them. Forth systems have standardized facilities to handle some of these tasks by themselves.
Но, хах, к счастью я блестяще наловчился пользоваться встроенным в Свифт редактором (знаете, там, find и insert буферы, команды F I U P X M S R и пр.). Мне любопытно, существуют ли самостоятельные блоковые редакторы, которые не привязаны к Форту?
И последнее, ребята, скажите, как вы считаете, можно ли на Форте сделать ОС аналогичную, допустим,
MenuetOS? Я знаю, у этой поделки масса критиков, но я всё равно считаю автора настоящим виртуозом. Система имеет полноценный ГИП (GUI), целиком написана на азме и умещается на дискету. Я так прикинул, и мне показалось, что если её же переписать на Форте, то она, пожалуй, не потеряет ни одной из своих фич, причём, в размерах, как мне кажется, тоже не сильно прибавит (то есть, и на дискету поместится). Понятно, что только идиот будет этим заниматься (хотя один сумасшедший лиспер и взялся переписывать, вроде бы, WOW), но мне всё же хочется послушать ваши мнения, согласитесь, вопрос интересный.
зы
Господа, ещё раз прошу прощения, как вы помните, я уже упоминал о припадках косноязычия, теперь их природа открылась. Последнее время мне очень часто приходится "скакать" по языкам, их целых три, так что я иногда могу нести жуткую околесицу по причине того, что не могу по щелчку перестроить... способ мышления.
Благодарю за понимание.