Безусловно, задумка имеет все права на жизнь и даже реализацию. Только это не серебряная пуля.Сообщение от vinxru
---------- Post added at 12:53 ---------- Previous post was at 12:52 ----------
Да. Не припомню ни одной законченной реализации задачи от тебя. Максимум- перечисление ассемблерных команд для использования.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Это лучший из обсуждаемых здесь способов, с точки зрения:
1) Заметных для пользователя тормозов.
2) Рационального использования ОЗУ.
3) Простоты алгоритма.
Для случая перемещений на короткие дистанции. Тормоза при переходе в начало текста могут вызвать вопросы.
В смысле отсутствие накладных расходов на индексы-указатели? Классический способ точно так же рационален.
Он сложнее классического. Такова цена за п.1
1. Что считать "классическим способом" может это тот редактор который в zxspeccy ROM? когда мы в буфер редактирования копируем строчку которую хотим отредактировать? Если да, то это бесполезное копирование строчки ПЕРЕД редактированием и ПОСЛЕ редактирования + надо ж как-то с размером разобраться, так как старая и новая строчки явно разные по размеру. Ну а если это сдвигание раздвигание всего текста при нажатии каждой кнопки то это вообще мракобесие особенно для файлов гигабайтного размера.
2. Навигация по тексту в режиме read only и спец-режим "редактирование" (например в редакторе EX он же VI) решает вопрос с ненужным копированием строк при простом перемещении курсора по строчкам (возможно зделать это и неявно, скажем создавать этот буфер тогда когда юзверь нажал кнопку которая должна изменить строку).
3. По поводу БОЛЬШИХ файлов я так и не понял что с ними делать, вот у меня есть логи на работе размерами по 1GB ни один из редакторов под linux c ними нормально не работает (помнится под DOS были редакторы которые и по 10Mb логи смотрели без проблем). Это конечно другая задача НО все же, как создать swap file и как его использовать эфективно?
это можно пременить к большим файлам, но смысла нет,
эт скорее схема для экономии памяти
но все-же,
собственно этому методу в памяти "нужно" держать только то что сейчас на экране
все что вне экрана спокойно может быть в "свопе"
и догружаться в память по надобности.
а гигабайтный логи в редактор грузить - имхо изврат редкий
их же не нужно редактировать, их нужно смотреть, другая задача ...
Последний раз редактировалось esl; 02.04.2013 в 19:17.
Почему же? Идея вполне имеет право на существование. Логи разные бывают. Например, если софт, который сохраняет логи, содержит баг, что приводит к нечитаемости логов другим софтом. С помощью редактора иногда можно подправить лог, чтобы он читался как надо. Когда пишешь и отлаживаешь свою программу, сохраняющую логи, такая ситуация может встречаться часто.
Ну и потом, что гигабайты на современных компах - то сотни килобайт на Speccy. Подход тот же самый. Прочитать или записать 300кБ с дискеты занимает примерно то же время, а в стандартную память такой файл не влезает.
Как приспособить эту схему к редактированию файлов, которые не влезают в память - пока не могу придумать. Но для работы с файлами в памяти она подходит очень хорошо.
не, эт неправильно, логи парсить надо не редакторм а скриптом на ruby/perl/python
они на это заточены, и ворочают ими с сумашедшими скоростями
сколько раз уж делал такие "фиксеры"
java мир ух как любит многопоточные логи ....
Я может бы за тебя всю программу написал, но мне не нравится твой стиль общения. Ты каждое свое сообщение строишь так, что мне приходится оправдываться. Ни под одним моим сообщением ты не нажал - спасибо.
---------- Post added at 12:06 ---------- Previous post was at 12:03 ----------
Нет. Я написал это уже много раз. Перерисовка экрана происходит значительно дольше.
Потому что шрифт 6 пикселей, а в байте 8 пикселей. Шрифт надо сдвигать и накладывать через AND OR на исходное изображение дважды, так как символ может быть на границе байта. (Само собой, этонадо делать лишь когда перемещение происходит дальше 25 строк.)
---------- Post added at 12:07 ---------- Previous post was at 12:06 ----------
Всмысле того, что буфер для редактирования строки не нужен.
Последний раз редактировалось vinxru; 02.04.2013 в 13:10.
Я вытаскиваю важную и интересную для себя информацию. Поскольку пока ничего нового для себя не встретил, спасибо говорить не за что. Плюс мне тоже не нравится твой стиль общения- "это и так все знают, ты тоже знаешь, но делаешь вид что нет- ты тролль". Если я знаю что-то по этому вопросу (использование SIMD), так это то, что я слишком мало знаю чтоб делать выводы на основе неполных данных.
Ну это не повод делать операцию еще дольше.
А вот это зря. Буфер редактирования- очень полезная штука. В частности, можно легко сделать undo.
господа, флеймить давайте во флейме!
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
