| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
итератора: типа получил имя, получил значение, получил следующее имя... Но
дополнительный аргумент — всё равно: для предсказуемости.
Ну что-ж, с этим уже можно работать. Работаем. Сделано.
И, да: шаблоны — простейшие, как у операционной системы: ? (вопросительный
знак) заменяет собою один любой символ, а * (звёздочка) — любое их количество,
в том числе ни одного. А повторное обращение к итератору — только и
исключитеьно с текстовой константой: FSUBr("") или FO("") но никак не FO(:7)
даже если седьмой регистр — пуст: предсказуемость!...
И еще одна проблемка: мы же хотели разделить кодировки с упаковками...
Ну ё, когда же это закончится?! Всего-то и хотел — исправить безобразную
ошибку, обнаруженную в механизме перекодировок... В общем волевым решением
объявляю... Антракт, техническую паузу или ну не знаю как это назвать.
И выкладываю то, что получилось к текущему моменту, как есть. А то, знаю я,
сейчас это будет модернизация функции FCHr, коей потребуется какое-то средство
управлять упаковками (входной и выходной отдельно). Для чего напрашиваются
спецпеременные, от которых я тоже шарахался как черт от ладана, вот даже и не
упоминал... А там оно потянет за собой какую ни будь китайщину. В ихних
кодировках тоже есть русские буквы. И греческие. И они тоже расширение ASCII...
...в общем АНТРАКТ...
* * *
А вот далее уже будет ЧАСТЬ ТРЕТЬЯ — чистой воды фантастика и выдумки.
* * *
...А исчо есть у нас такой аккумулятор А3 — чего это он, спрашивается,
бьёт баклуши, можно сказать почти без дела болтается? Пусть пользу приносит!
(Ну чем мы хуже кота Матроскина?!)
В туалете на военной кафедре разговаривают два студента:
— знаешь, чем майор Пронин отличается от обезьяны?
И тут заходит майор Пронин:
— ну и чем же я отличаюсь от обезьяны?
— Ни-Чем, товарищ майор!
— то-то у меня!
Ну так чем же мы хуже кота Матроскина — тем, что нас не показывают по
телевизору? Первое апреля, однако!...
Однако, пошутили и хватит. А и в самом деле: для чего такого полезного,
из того, что нам не хватает, можно пристроить аккумулятор, куда попадают
объекты ввода/вывода? И чего, кстати, нам не хватает? Графики? Да!
Ну графика, это вопрос отдельный, завязанный на образование "коллекций"
из графических примитивов, каждая из которых исходно — один график, а в
перспективе — изображение. Так, чтобы она могла выступать деталью других
изображений. То есть чтобы на неё можно было сослаться как на единое целое,
вызвать как подпрограмму. С параметрами, естественно... С параметрами? Ну
предположим... Но у нас же уже есть подпрограммы — самые обыкновенные. Можно
же написать такую, которая рисует нечто графическое... Но это — писать надо.
А коллекция — нечто другое, что само по себе в процессе (чего ни будь)
собирается. И параметры для неё это типа переместить, повернуть и
отмасштабировать... Перекрасить в другой цвет? Да. Коллекция же типа на цвет
завязана: это же исходно один из графиков, коих несколько штук мы строим в
общих осях, а значит — разными цветами. И собирается она вот как раз по мере
рассчета точек этого графика. А хранить её предполагается в виде одной из
групп программных строк. Но тут вылезает необходимость автонумерации. (А может
быть и псевдонимов из Фокала-2?) В отличии от подпрограммы, где строк, а вернее
операторов — умеренно, в графике какой ни будь функции этих самых отдельных
точек могут быть многие тысячи. И считать каждую из них оператором (типа:
Viz Точка X,Y; который её и нарисует), то на одних буквах V раззоришься! Да и
метки там нужны сильно не каждому. А только например когда хотим замкнуть
"полигон"...
Или таки лучше делать это в терминах "вершины — фаски" как в 3-Д моделях?
Подумаем... Вот вершине — аналогу точки, каждой нужна собственная метка, чтобы
фаски — аналоги полигонов на них могли ссылаться. Но их там тоже могут быть
многие тысячи. И хотя у нас сейчас номер строки в группе уже не две цифры, а до
четырёх, всё равно, боюсь, номеров не напасешься... Да и с построением графика
по точкам оно как-то не очень...
В общем тут еще думать и думать надо. (В процессе чего надо бы с языком
ПостСкрипт и с Х-терминалом познакомиться...)
Так что — нет, не графика...
Тогда может быть устройства? Вот например ком-порт... Ком-порт то у нас
якобы есть (под псевдонимом Ц) — ДОС`ом по умолчанию предоставляемый... Но
во-первых в машине их у меня два. Во-вторых: а как на счет скорости передачи,
да и прочих параметров? А в-третьих не только отдельные байтики, но и пакеты
оттедова хочется. Например вполне конкретные, имени одного моего знакомого...
Или есть изернетовский адаптер — тоже со своими пакетами.
Или вот USB...
Или канал азбуки морзе... Пока что она только встроенным динамиком пикает.
(И то засада со скоростями: надо переходить на другой таймер — который 1000 Гц,
а не системный — 18 с копейками. Его конешно тоже можно перепрограммировать, но
что будет с часами?!...) Но ведь можно и вывести на любой свободный вывод того
же ком-порта, или принтерного. И, кстати, ввести... Но там еще надо решить
проблему QLF так до сих пор и не решенную. (Что мол оператор работает на ключе
левой пяткою!...) Или подсмотреть у кого... Но вывод то можно сделать уже
сейчас...
Теплее, теплее... Но всё же еще не то.
А вот есть у нас еще такая проблемка — "навигация"...
Сейчас с точки зрения Фокала внешний мир это коллекция текстовых файлов.
Разложенных, правда, по каталогам... Но с каталогами Фокал работает, обращаясь
к ОС с помощью оператора ! (восклицательный знак). И, например, перебраться в
другой каталог под ДОС`ом с помощью команды CD у него вполне получается.
(Потому что процесс — один общий. Под UNIX`ом, полагаю, не получится.) А ищет
он файлы с помощью отдельного средства (FTEll("имя_файла")) никак с остальной
подсистемой ввода/вывода (почти) не связанного...
Правда файлы встречаются еще и "бинарные", с которыми Фокал испокон веку
работает с помощью спецфункции FCHR, таская ею байты поштучно. (А мы в части
второй еще кое-что к этому добавили.) Но чтобы сделать с бинарным файлом
что-то разумное, надо точно знать как именно он устроен — его формат.
А форматов этих нынче развелось — как собак нерезанных...
Но вот, полагаю, настало время (и/или появилась возможность) резко
облегчить работу с некоторыми из них. На примете: .dbf .wav .html вернее .xml
А еще и ком-порт, из коего приходят не отдельные байтики, а пакеты имени одного
моего знакомого... (Лично им в моём присутствии изобретенные. И с тех пор
используемые как минимум в трёх изделиях...)
Этот самый пакет — последовательность байтов, состоящая из "преамбулы",
заголовка, тела пакета, содержащего полезную информацию и контрольной суммы.
Преамбула (FF FF 00) должна показывать что информационный мусор, сыплющийся из
линии связи, закончился и начался вот этот вот пакет. (Коллега малость
перестраховался...) Заголовок — 4 байта: общая длина пакета, код его типа,
адреса отправителя и получателя. Контрольная сумма — один байт: просто сумма
всех остальных байтов пакета (не включая преамбулу). Содержимое — в
зависимости от типа. В смысле о чем договорились, как правило сами с собой.
Подобное изобретают все, кому не лень; этот конкретный — исключительно
ради конкретики.
Ага.
Этот самый файл типа .dbf известный как "реляционная база данных", хотя и
не совсем типичный их представитель. Но давно и широко используется, можно
сказать, стал уже стандартом де-факто... От типичной отличается тем, что
самодостаточный, "самоопределяемый" — содержит внутри себя описание своих
собственных полей — вложенный мини-файл... Впрочем, по порядку.
Эта самая реляционная база данных — всегда коллекция файлов. Разных, но
организованных на одном и том же принципе. Каждый файл — последовательность не
отдельных байтиков, а "записей" одинаковой длины. Каждая из которых состоит из
одних и тех же "полей". Где каждое поле содержит одно элементарное (для данной
базы данных) значение.
А наш механизм табулостопов это случайно не средство разделить текстовую
строку вот на такие поля? Да. Но есть и существенные отличия:
— во-первых поля — именованные
— во-вторых границы полей — "непроницаемы"
— и главное: поля — типизированные. (И этих типов — три вида...)
А у нас все поля пока что безымянные и все одного типа: "фрагмент строки".
Разумеется, в разных файлах и длина записи и набор составляющих её полей
могут быть очень даже разными. Поэтому в оной коллекции есть как минимум один
специальный файл, содержащий "метаинформацию" обо всех остальных: список их
полей с их типом и размерами. Описание каждого поля — одна запись, собственные
поля которой — фиксированные. А у файла типа .dbf перед последовательностью
записей, есть еще и заголовок, где среди прочего и содержится его
метаинформация.
Вопрос: является ли вышеописанный пакет частным случаем записи, бо он тоже
состоит из полей? (Если например откинуть преамбулу и контрольную сумму.)
Подумаем...
Этот самый файл типа .wav якобы содержащий вопли чьей то жены (ибо по
аглицки произносится совершенно так же), заставшей мужа... (опустим
подробности) оказывается, представитель целого семейства одинаково
организованных файлов, содержащих в себе потоки. Вон в файловой системе NTFS
эти самые потоки реализованы на уровне ФС, но в других-то ФС ничего подобного
нет, вот и приходится... Фрагмент потока (жаргонное название которого как-то
связано со свиньёй/чушкой из юго-восточной Азии) представляет собою запись
переменной длины, или, если хотите, очень простой пакет, заголовок которого
(8 байт) содержит только идентификатор (4 байта) указывающий его тип, и длину
тела. Но если она нечетная, то тело дополняется нулевым байтом.
Собственно весь файл — это один вот такой пакет. Но два типа потоков "RIFF"
и "LIST" содержат в себе вложенные потоки, организованные в точности так же.
(Но первые 4 байта — тоже идентификатор, указывающий что всё это такое.) Так
что в один файл можно запихать не только два канала с разными именами (чтобы
был стереоэффект) но и текстовое сообщение, что именно взбешенная супруга
хотела всем этим сказать. И еще массу полезной (или вредной) информации...
(Вообще-то стерео и даже квадроэффект достигается как-то по-другому: не
два отдельных канала, а в один — пары или даже чеверки отсчетов... Вроде бы.)
Вопрос: а еще у нас потоки есть? А как-же! Вот например содержимое самого
обыкновенного файла вне зависимости от его типа. Да и тело пакета пожалуй что
можно считать потоком. Вложенным или "встроенным". Хотя конешно в самую первую
очередь поток это то, что на нас валится из линии связи, включая отдельные
байтики и затесавшиеся меж ними пакеты, вот как вышеописанный.
А из файла, который лежит себе спокойно и никого не трогает, поток
организуется с помощью движущегося по нему указателя чтения/записи! Но его то
хотя бы переставить можно...
Этот самый файл типа .html или лучше всётаки .xml это тоже если хотите
поток потоков... Или пакетов... Но вообще-то он — типа текстовый.
Текстовый файл можно считать потоком не байтов а строк. Тоже, как и пакет,
переменной длины. В разных ФС это организуется по-разному. Например в начале
каждой строки — её длина... Но чаще всего конец строки (и начало следущей)
указывается символом-разделителем строк. Который внутри строки не встречается.
(Вернее как встретился — значит это и есть конец строки.) В кодировках на
основе ASCII это команда ПС (перевод строки, он же 'n') или пара ВК ПС. И еще
текстовый файл по-возможности не содержит "слепых" (непечатных) символов — не
имеющих изображений. (Раньше не имевших — сейчас то картинки сопоставили всем.)
Но вот сейчас в винде вишь взяли моду делать строку размером с целый
абзац — что де программное обеспечение само разобьёт это на строки — по
размеру окна, который может запросто измениться в любой момент по прихоти
пользователя... Запустившие эту моду мелкомягкие недоумки вишь не знали, что
для этих целей на нулевой странице ASCII среди управляющих символов есть
специально для этого предназначенный символ-разделитель групп записей, ну или
абзацев текста. Или и знать не хотели, а хотели воспользоваться тем, что уже
есть — создали всем остальным проблему на ровном месте...
Файлы типа .html и .xml впринципе тоже текстовые, но только в том смысле,
что состоят из печатных символов. (А к разбиению на строчки там относятся
примерно так же, если не хуже.) Разбиение на что-то (вот на такие же "пакеты")
там с помощью своего рода скобок — "тегов". (Тег — "ярлык".) Именованных.
Открывающая и закрывающая скобки выглядит как <имя> и и между ними -
тело пакета, где может быть как текст, так среди него и такие-же вот скобочки.
Скобочки впринципе должны быть сбалансированы, но в .html с этим — бардак.
Потому что по исходному замыслу это команды форматирования текста. При чем в
виде скобок — только некоторые из них: типа выводить вот таким шрифтом не всё
нижеследующее (пока на другой шрифт не переключат), а только заключенное в оные
скобочки. За сим в .xml сделали: <имя/> — пакет без тела; скобка разом
открывающая и закрывающая. И придумали .xhtml — где бардака поменьше.
Внутри открывающей скобки (заголовка пакета) могут быть дополнительные
поля — тоже именованные. Вида: имя="значение".
У .xml все эти имена — какие сами выдумаем. И смысл у них такой, о котором
сами с собою договоримся. А вот у других файлов этого семейства — типа уже
договорились. В частности у .fb2 это элементы оформления книги: автор,
название, разные виды заголовков, деление на главы и абзацы... У .html это
команды управления просмотрщиком. Который сперва был совсем простеньким — умел
выводить текст разного вида, размера и цвета (например курсив: текст
(i потому что "итальянский")), но главное — умел переходить по ссылке:
текст_изображающий_ссылку (если конечно ткнуть в эту
ссылку мышкою) в результате чего и получается "гипертекст": несколько
связанных вот такими ссылками файлов. Лежащих как на одной машине, так и на
разных. И тогда этот не просто имя файла, а сетевой адрес. (Который тоже
"путь", но сначала по сети, а потом уже по тамошней файловой системе.)
А вот форматирование текста как изначально было дурацкое, так и осталось:
штатных средств сделать по-человечески — чтобы абзац начинался с красной
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
| Следующая глава |
