Даже для блочного ввода-вывода?Цитата:
Сообщение от alone
Вид для печати
Даже для блочного ввода-вывода?Цитата:
Сообщение от alone
от задачи зависит. блоки же не только занимаются, но и освобождаются. Несколько свободных подряд - автоматом склеиваются в один большой.Цитата:
Сообщение от vinxru
ну это у меня было так. Но я не редактор писал.)
Это будет гуляние по списку, копирование в буфер плюс постоянное ожидание оборотов диска. А идеал - один-два системных вызова (в ACEdit именно так, даже для Merge).Цитата:
Сообщение от Vitamin
Это к чему?Цитата:
Сообщение от alone
Ты сказал, что хранение текста в разделенном по курсору виде не требует дополнительных действий при сохранении на диск. У меня возникли сомнения по поводу этого заявления применительно к блочному вводу-выводу.
вроде бились за каждый байт, а теперь циклы разворачиваем ;PЦитата:
Сообщение от alone
хотя конечно этот вариант крут
а потом еще 16(стек)+хвост(этот) ...
по поводу записи, перед записью надо будет "перейти в конец текста"
но при записи эт будет не заметно ;)
и еще, речь то идет о старых машинах (в оригинале Специалист)
а для запись на мафон надо всё иметь одним блоком....
---------- Post added at 15:50 ---------- Previous post was at 15:50 ----------
тогда уж на Троль ++Цитата:
Сообщение от vinxru
Что конкретно ты не понял в моём ответе?Цитата:
Сообщение от Vitamin
Вот из этой цитаты:Цитата:
Сообщение от alone
я сделал вывод, что фраза (следующая за предыдущим предложением):Цитата:
Сообщение от alone
относится к предлагаемому методу хранения текста в виде двух частей, разделенных по курсору редактирования.Цитата:
Сообщение от alone
С учетом того, что разделение делается в произвольном месте, а ввод-вывод у нас блочный, над стыком таки потребуется дополнительная обработка. И она будет сложнее, если свободное окно между кусками меньше размера блока. Я в чем-то ошибся? Если да, то в чем?
Это не проблема. Перед сохранением, перемещаем курсор в конец текста. Это один вызов уже существующей в редакторе функции. Это объединяет текст в один блок.Цитата:
Сообщение от Vitamin
P.S. А потом обратно переместим. Либо можно сохранять двумя кусками, если ОС это позволит. Эти способы по любому проще сохранения из кучи.
Но ведь это уже обработка. Конечно, ее можно минимизировать, вычислив оптимальную сторону куда прыгать (в начало или в конец), но в общем случае она есть.Цитата:
Сообщение от vinxru
Понятное дело.Цитата:
Сообщение от vinxru
Кстати, была мысль при укорачивании строк не уплотнять весь текст, а оставлять окно, пометив его какими-нибудь кодами. Потом при поиске свободного места можно в обе стороны бегать уплотняя построчно.
Пипец задрот, одно дело из кучи собирать в буфер и записывать (а каждый очередной кусок может выходить за пределы буфера и это дополнительный танец), то ли переместить курсор в хвост, и сохранить одним кускомЦитата:
Сообщение от Vitamin
Пипец умнюк, одно дело собирать из двух кусков, другое дело одним куском записать и не париться.Цитата:
Сообщение от ZEK
Для неврубающихся: лично я хранение текста построчно в куче даже и не рассматриваю.
собрать это написать процедурину?Цитата:
Сообщение от Vitamin
Нет. Выполнить некую процедуру по преобразованию текста из внутреннего формата в пригодный для последовательного сохранения на блочном носителе.Цитата:
Сообщение от ZEK
Если ты говоришь о необходимости писать специальный код для этого преобразования, то ситуация следующая.
Для классического варианта преобразования не требуется.
В альтернативных вариантах преобразование делается имеющимся функционалом. Для хранения текста в виде двух частей- временным переходом на границу текста, для хранения текста в куче- последовательным проходом. Эта функциональность тоже необходима (хотя бы для навигации по тексту).
То, что второй вариант на порядок сложнее- и ежу понятно.
То есть делаем вывод, различие вариантов когда текст уже плоский и вариант когда он состоит из двух кусков состоит из вызова из одной процедуры, следовательно как критерий упрощения записи вариант с плоских хранением очень сомнителен, выигрыш в длительности операции записи, но на фоне операций IO это не заметно, и тут стоит склоняться к варианту где работа в типовых операциях менее накладная и отзывчивая со стороны UI
В худшем случае копируется 255=размер_блока-1 байт (если окно меньше, то два раза). Кстати, никто не заставляет сохранять, если свободное окно между кусками меньше размера блока. Например, ACEdit может редактировать 65535 байт, но он не сохранит, если больше 65280.Цитата:
Сообщение от Vitamin
А тут уже расходятся мнения что считать "типовой операцией"- навигацию или редактирование.Цитата:
Сообщение от ZEK
Вот накидал оценки затрат:
M - размер текста
N- средний размер строки
K- размер экрана в строках
Учтены разумные оптимизации (например, известный конец текста).
Умножаем веса для каждой из операций на матрицу и получаем трудоемкости для каждого из методов.Код:\Метод| Plain | Twopart | Fragmented
Операция\ | text | text | text
-------------------------------------------
Home | O(1) | O(M) | O(1)
End | O(N*K) | O(M) | O(1)
LineUp | O(N) | O(N) | O(1)
LineDn | O(N) | O(N) | O(1)
PgUp | O(N*K) | O(N*K) | O(K)
PgDn | O(N*K) | O(N*K) | O(K)
Edit | O(M+N) | O(N) | O(N)
Мог чего не учесть, прошу поправлять:)
оценивать только время работы с текстом в отрыве от юзер интерфейса мало смысла !
не стоит забывать что за компом сидит юзер, и этот юзер имеет некие ожидания скорости ответа компьютера
типа:
вставка/удаление символа : "Мгновенно" (он совершенно спокойно может набирать в слепую)
переход на строку вверх/вниз "Мгновенно", (он смотрит на экран, помнит его содержимое, новые данные анализировать не надо)
Страница ввер/низ : "быстро" (на экране новая инфомация, надо потратить время на ее анализ)
Начало/Конец текста "достаточно быстро" (контекст сильно изменяется, нужно только в специальны случаях)
сервисные операции (запись/поиск/etc) "желательно быстро" операции тяжелые, сложные, можно и подождать)
т.е. например пауза в 1/3 секунды при вооде символа вообще не приемлема
пауза в пару секунд при записи - терпимо
и по посту, а разве для Two part - Edit не O(1) ?
причем в любом случае, это скорость ВСЕГО редактора, с отрисовкой и прочим.
голая математика тут мало подходит, это комплекс решений ....
Вообще-то те алгоритмы что доступны для 8bit процов спокойно могут быть реализованны практически на ВСЕХ компах. Одним блоком желательно иметь ВСЕГДА И ВЕЗДЕ и любые данные. К тому же описанный метод своего рода "замена" классических одно-двухсвязных списков которая даст им фору по памяти и по сложности обслуживающих алгоритмов.Цитата:
Сообщение от esl
Использование буфера. Оно же поможет с автоформатированием.Цитата:
Сообщение от esl
Про конец соглашусь, про начало- нет. Переход на начало чисто психологически должен быть мгновенным.Цитата:
Сообщение от esl
О! Кстати о поиске. Для него накладные расходы вообще должны отсутствовать.Цитата:
Сообщение от esl
С чего это? Данные разве не надо положить?Цитата:
Сообщение от esl
Отредактировал оценку перехода на конец для plain text. Таки это надо отсчитать строки от конца.
Да, могут сказаться опущенные в "о большое" коэффициенты. Только узнать это можно одним способом- взять и сделать. Так что не слушай никого, бери и пробуй:)Цитата:
Сообщение от esl
а с того что надо что надо спросить у пользователя что искать, etc, etc,Цитата:
Сообщение от Vitamin
есть дополнительное взаимодействие ...
есть указатель на "Курсор"Цитата:
Сообщение от Vitamin
в него поместили байт
увеличели X и указатель
все
Поскольку многопоточности нет, то незаметные задержки на спрашивания будут перемежаться с заметными задержками на перетасовку.Цитата:
Сообщение от esl
Т.е. начинаем искать в хвостовой части текста, как только нашли, все от начала хвоста до позиции поиска надо перекинуть.
У тебя редактируются строки из одного символа?Цитата:
Сообщение от esl
просто сейчас это уже не имеет такого смыслаЦитата:
Сообщение от bigral
когда размер сектора на диске 8к
и сейчас быстрее/надежнее сделать на хорошо известных структурах
редактор это в жизни много больше чем просто набор текста
и сложные структуры дают свои огромные плюсы.
я вообще в курсе, зачем и описал тут этот метод ;)Цитата:
Сообщение от bigral
---------- Post added at 21:50 ---------- Previous post was at 21:47 ----------
заметные, заметные, процесс то интерактивныйЦитата:
Сообщение от Vitamin
отрисовать диалог, спросить, отреагировать на результат поиска
зачем тягать при поиске ????
только когда нашли и надо отрисовать ;)
нет конечно, но метод позволяет не использовать дополнительный буфер для редактирования строки ;)Цитата:
Сообщение от Vitamin
правее курсора - свободное место ;)
А я что написал?Цитата:
Сообщение от esl
Цитата:
Сообщение от Vitamin
И сколько таки нужно операций для редактирования строки размером в N символов?Цитата:
Сообщение от esl
Напиши прототип. Увидишь и плюсы и минусы, может идеи какие гениальные придут. На форуме обсасывать можно до бесконечности.
гм, я начал с того что сказал что работал с редакторами которые по этой схеме были сделаны ;)Цитата:
Сообщение от Vitamin
так что в отличии от есть некий опыт ;)
Бгг. Почему-то думал, что ты топикстартер:)Цитата:
Сообщение от esl
Топикастер VINXRU- маг и волшебник кода и паяльникаЦитата:
Сообщение от Vitamin
Home, End, PgUp и PgDn везде как минимум O(N*K), потому что надо перепечатать весь экран.Цитата:
Сообщение от Vitamin
LineUp и LineDn на границе экрана требуют сдвига и вывода новой строки, так что оценка O(1) не имеет смысла.
Перепечатка экрана- отдельная тема. Оценка исключительно для операций над текстом.Цитата:
Сообщение от alone
Вчера ночью набросал первую версию программы, что бы оценить скорость. Скорость удовлетворительная. Реакция на Enter и Backspace (в начале строки) быстрее, чем я обычно печатаю.
http://s017.radikal.ru/i417/1304/10/e06873d7cc9a.png
Добавил строку состояния. Обновление чисел в строке состояния происходит при каждом нажатии клавиши (деление 16 битного числа и рисование), при этом тормозов так же нет.
http://s017.radikal.ru/i442/1304/32/3d701fed9067.png
круто, вот еще бы круче было если бы этот проект лежал открыто на каком-нибудь "google code" и вставки на асме были бы в отдельном каталоге /arch/specialist (типа чтоб легче было портировать)
Это пока первые-первые наброски. Потом так и сделаю.Цитата:
Сообщение от bigral
Я вчера добавил вертикальный скролл. Еще буфер обмена добавлю и всё.
---------- Post added at 10:37 ---------- Previous post was at 10:19 ----------
Это будет редактор в комплекте с SD-контроллером, который я все таки планирую портировать на многие 8080 компы. На 86РК, Мирошу, Апогей в том числе.
Он нужен, что бы прямо с компьютера редактировать файл autoexec.bat и файл привязки к расширениями. То есть при запуске BAS файла, запустить бейсик. При запуске SCR запустить просмотрщик и т.п.
Еще интересно разобрать I/O интерфейс редактора. Какие функции нужны будут? В стандартной stdio нету нужных функций типа "вклеить кусок в средину файла начиная с нужного смещения от начала". Еще есть такой момент, такие функции типа как truncate() доступны токо в более поздних системах и не хотелось бы зависеть от таких вещей. Или stdio вообще не планируется использовать (тогда вопрос портирования усложнится серьезно)?
Редактор будет вызывать функциюЦитата:
Сообщение от bigral
saveFile(char* fileName, void* buf, int len);
А в ней делайте что хотите. На первых порах у меня там будет вызов BIOS для сохранения на магнитофон.
кстати, тут искали лог вьювер под винду
вот попалось на глаза
http://www.uvviewsoft.com/logviewer/
Цитата:
Fast scrolling, eats low memory
Supports any file size (4 Gb and larger)
Multitabbed interface
Log auto-refreshing
"Follow tail" mode
Highlighting of lines matching a RegEx
Support for lot of encodings: ANSI, OEM, UTF-8, Unicode LE/BE etc.
File search (both forward and backward)
File printing
Line wrapping, configurable tab size and line spacing
Line numbers (for log beginning)
"Create filtered log" command
Unicode filenames support
and more.
Ха, я свой редактор тоже на этом тексте тестил в далеком 2001 году :)Цитата:
Сообщение от vinxru
конечно некропост, и винкс покинул эту тему, но
этот метод оказывается имеет название - Gap Buffer.
вот целая статья про это, там еще есть всякие полезные ссылки в обсуждении.
http://habrahabr.ru/post/197650/
А еще там в коментах есть человек из Челябинска утверждающий что он писал текстовый редактор на Спектруме.Цитата:
Сообщение от esl
Кто-нибудь может с ним связаться?
Triumph Word?
Статью написал я, почерпнув основную идею из этой темы и лишь впоследствии откопав название "Gap Buffer" с помощью поиска в интернете. Именно из твоего, esl, поста, я впервые узнал об этой структуре данных. Если хочешь - добавлю в статью ссылку на тебя. Имя только скажи настоящее или, если есть аккаунт на хабре - также и хабровский ник.Цитата:
Сообщение от esl