» CudaText

CudaText 0.3.5, нашел некоторые недороботки, [more=подробнее]1) В истории изменений написано:
Код: 0.2.0
+supports user.json with comments

Цитата:

когда каретки доходят до первого символа в строке, то

это ок. Так надо. кажется, специально так делалось
(Synwrite -same)


Цитата:

плюс удалится еще один лишний

Bksp так специально делает
Где не так.
ST3? NP++?


Цитата:

перенос слов

почему это неверно?

Цитата:

Bksp так специально делает
Где не так. ST3? NP++?

везде, включая SynWrite, но даже если есть редактор где так, то этот редактор какой-то не правильный.

по поводу переноса слов, ни разу не пользовался такими переносами, поэтому ни мог понять как они работают, оказалось все логично.

Bksp--will fix. согласен что некорректно

Диалог Библиотека лексеров. Можно было-бы сделать фильтр\поиск, и если делать фильтр, то еще чтоб можно было по расширениям отфильтровывать (допустим, написали h, и остались только те лексеры, которые связанны с расширением h). Также можно сделать так чтоб можно было выделить несколько лексеров, в таком случаи можно выделенные разом - удалить\отключить\включить, экспортировать в отдельную библиотеку и т.д.

диалог лучше пусть простой. Не хочу воротить. И выделение многих.
импорт будет НЕ через диалог.

Цитата:

импорт будет НЕ через диалог

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

Цитата:

distortion
сольный проект или коллаборация приветствуется?

Alextpp
потом приветствуется, все будет опенсрс, да.

license.txt
Код: This version of CudaText is freeware. Even for commercial usage.
You can copy it freely.
Source code: closed.
Next versions may change to shareware.
Copyright (c) 2015 Alexey Torgashin, UVViewSoft.com

Версия 0.4.4, сделал Deb installer

репорт в веткке Synwrite: открыли файл, закрыли, открыли, закрыли, память кончается... Попробую это исправить, баг

Alextpp
Проблема с утечкой вроде решена.

Осталось еще несколько проблем.
Проблема с долгим сохранением файла:
Я открыл Процесс Хакер статистика такая: Скорость ввода/вываода очень низкая у Cuda.
Она колеблется в пределах 1-3Мб против 80-120МБ у Notepad++. Можете проверить.

Причина долгого открытия похоже аналогичная.
Т.е. явно напрашивается вывод что тут это связано с многопотоковым чтением и записью данных. Разность скорости впечатляет.
Мне кажется, что это связано с правами или приоритетом на такого рода действия. Хотя возможен вариант что это дело надо самому организовывать. Права и прочее не проверял. Займусь коли не найдете решение.



Добавлено:
Открыл вкладку Потоки в Процесс Хакер. У вас только один поток. В Notepad++ два Npp потока, а также еще 4 других со стартовым адресом типа ntdll.dll!RtlRegisterThreadWithCsrss+0x197.
В общем чтоб разобраться надо не иметь плагинов Npp. А отключать неохота. Лучше уж вы.

Мне почему то кажется что вы решите этот вопрос на раз. После этого останется лишь долгое время после-загрузки процессора (после казалось бы выполненного действия). Настолько долгое что можно и не дождаться состояния 0%

Ну и кроме того очень, просто супер большой Рабочий набор и Выделенная виртуальная память. Это все надо тоже уменьшить.
Не то это будет второй Скайп.
-----------
Все мои рецензии касаются режима без Лексера. Т.е. Лексер = None. Файл 56Мб. с короткими (20-25 символов) строками 2млн. штук.

Память. уменьшать не буду, уже проверил, да, жрет память, потому что mem struc такая, она навороченная, зачем? затем чтобы скролл плавный. при даже 100М файле. чтобы wrap не тормозил.
тормозил меньше.

56М файл нетипичный.

Alextpp
А зачем тогда вообще городить огород с другой прогой?
У этой типа лучше движок.
Смысл городить в том чтобы это был нормальный текстовый редактор на который мы все переползем уж поверьте. Все - это все пользователи Npp во всем мире.
-----------
Посмотрите на ультраЭдит - она открывает большие файлы и быстро. Скрол колесом там супер плавный.
Памяти прибавляет на мой файл вместо 500 МБ всего 7МБ.
-----------
Что самое интересное почти того же самого результата для вашей проги я могу добиться вручную.
Т.е. она будет иметь рабочий набор в районе 10 МБ и работать плавно. Без каких либо проблем. Виртуальную выделенную память я сбросить не могу.
Чтобы убедиться в этом просто откройте процесс Хакер/Сведения о системе/Память/Больше (кнопка)/Очистить рабочие наборы.
Добавил: Сброс Рабочих наборов переводит эту память в список ожидания. Но я могу сбросить и список ожидания. И все будет всё равно тип-топ.

Вам решать. С этой "очисткой" Хакера не всё однозначно, но в целом это именно так как я написал. Не нужно столько памяти проге вообще.
---------

А так это монстр, который кушает и больше Верда, и больше Npp в два раза. Ни о каком масштабном использовании не может быть и речи. Я открываю обычно не менее 10 файлов. И в сумме это могут быть 50МБ. Это нормально.

Не нормально то что 500МБ оперативки даже не пытаются уменьшиться. Поясню:
Злополучный скайп, который клянут за прожорливость жрет тоже много. Но грузани систему хоть к примеру вашей прогой и Скайп сократит свою прожорливость. А у вас этого не наблюдается.
-----------
И не забудьте ваша прога еще не наворочена, а УльтраЭдит - под завязку.

DmitryFedorov
Как сказал Спольски -- скоро в лаке будет больше 2-х ГБ, т.е. ресурсы надо использовать все что есть, лижбы программа работала как надо, и даже если их сейчас не хватает, то через несколько лет точно хватит.
Посмотри, например, на продукты JetBrains.

Джефри Рихтер, вообще выдвинул теорию, что процессор должен постоянно напрягаться на 100%.

И я с ними согласен, но это вовсе не означает что надо плохо кодить...

Я вот взял и закинул тот же самый файл в вашу прогу SynWrite
Результат:
Открытие 3 секунды вместо 40 (т.е. быстрее чем в Npp и быстрее чем ультраЭдит)
Виртуальная память = физической = 145МБ вместо 500
Скорость ввода вывода трудно заметить, но проскальзывает большое значение
Скорость ввода 10 enter-ов 2.5 секунды вместо 15. (хуже чем у Npp)
Время сохранения файла при изменении 3-4сек вместо 12
Прога находится в том виде как распаковал
----------------
Спрашивается чем SynWrite хуже в таком случае?

SynWrite использует компоненты ЕКонтрол, и если их надо менять, то после обновления ЕКонтрол, придется синхронизировать правки, и это я думаю большая проблема. может возникнуть вопрос -- А чего там менять?, ну например обработку длинных строк, или действие при двойном щелчке и перетаскивании курсора. Думаю много чего еще надо менять.

Я считаю, Alextpp, правильно сделал что отказался от этих компонент, потому-что можно делать что хочешь, и не зависеть от кого там.

И я не понимаю твои претензии, всем ясно что медленно, и думаю автор с этим согласен, и попытается исправить. Но ведь не выйдет сделать все сразу. В общем - я верю, что со временем Cuda будет становиться только лучше, и в определенный момент, NPP и все остальные уже не нужны будут.

Не верю я после этого в слова, что движок Syn хуже.
Просто недопилена прога кое-где. Причем в элементарном недопилена в азах, судя по реакции автора типа "А вот не буду! и всё тут".
Стоит чуть-чуть поискать, подумать, поэкспериментировать и не будет задержек у SynWrite.

Daniyar91
Я считаю твой пост флудом, а по-русски словоблудием. "кодить" - очень некрасиво звучит, единственное спасение читать это слово как "шкодить"

Добавлено:
Для информации открытие за 3 секунды в SynWrite произошло только один раз. Но это было. Уж не знаю что этому помогло. Значит могёт. Может то помогло что она висела без работы почти сутки.

OSX x32 -- Beta

На Винде ничего не поменялась. Скорость ввода вывода (при загрузке файла) как была маленькой так и осталась. Фиксируется значение около 4МБ в сек. Закидывается в память 9 номинальных размеров файла. Показ файла начинается с 400МБ, потом размер доходит до 535МБ.

Расчет грубый 400/4=100 сек. Значит где то временами скорость выше. Потому что через 40 секунд видно.
У Npp показывается через 5 сек. Скорость ввода вывода там в соответственно в 8-10 раз выше. Происходит потому что организация потоков другая. Их несколько. И это не только Npp-поток.

Добавлено:
Откройте Process Hacker он бесплатный и портабельный.
На вкладке Быстродействие для вашего процесса будут графики.

У CudaText есть вначале пик ввода-вывода 60-80МБ в сек., затем стабильное значение в районе 3МБ Поэтому малые файлы прога открывает на раз.

Размер памяти там тоже показывается графически. У CudaText он в 2,5 раза больше чем у Npp и в 10 раз больше чем у Sublime_text

На вкладке Потоки для процесса всё расписано тоже. Можно сравнить и сделать выводы. У Sublime_text например 8 потоков. Ну часть из них что-то делает другое чем загрузка. Но это видно по активности потока.
У вас поток всего один.

Апдейт. Смотрим что нового в history.

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

ntdll.dll!RtlIsCriticalSectionLockedByThread+0x99e
ntdll.dll!RtlRegisterThreadWithCsrss+0x197

При загрузке секунду-полторы идет большая скорость ввода-вывода 50-60Мб/сек потом максимум 3.5МБ/с еще 30-40 сек. Если бы скорость не ограничивалась прога была бы супер шустрой. Быстрее всех других.

При сохранении файла скорость ввода-вывода тоже малая, но без пика.

не вижу малой скорочти сохр.-загрузки. По моему, все нормально, я юзаю обычный ввод вывод и ничего особенного

Добавлено:
один поток это ОК.
Загрузка часто почти везде-- 1 поток

Alextpp
Если выделить какой-либо текст, а потом сдвигать его по TAB, то выделение работает не правильно.

Daniyar91
выделение просто остается как было без учета что двигали. Тоже нормально, как его менять? число строк то же.

Ну тогда надо чтобы настраивалось, либо так как сейчас, либо так как в остальных редакторах.

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

Daniyar91
можно сделать как Synwrite, при инденте выделять весь блок, или может как в GEdit, todo.

про 2. Пока не знаю что поделать.

Второй синий горб снизу - это загрузка ввод-вывод. Его пик 60МБ/сек.
Третий (розовый) горбик снизу - это сохранение. Как видите долго и скорость без пика и малая скорость 3МБ.
Сделал в Процесс Эксплорер, хотя давно им не пользуюсь. Типа он распространенней.
------
Такие улучшенные показатели лишь благодаря тому что я переименовал F:\p_soft\CudaText\data\___________lexlib
Не то было бы еще хуже. В 1.5 раза. (на второй картинке видно - память как обрезана. Это 300МБ, но с лексерами это было бы 520МБ). Еще бы пришлось ждать.
Ну что тут сказать. Надо сделать сначала сам движок.
Ключ к оценке движка время загрузки, время сохранения, объем физической памяти.
А сейчас что?
НА один файл! используется памяти почти в 10 раз больше его номинала.
Да еще при такой скорости записи.
Пока не запишется - картинку не увидишь.
---------
Физическая память в графиках процесса не показывается.
Сложно ее подсчитать. Понятие абстрактное. Разве что Рабочий набор показать.
Но на вкладке процессов видно по цифрам, что она всегда у вас равна виртуальной.
И изменяется абсолютно синхронно.

Добавлено:
Alextpp

Цитата:

не вижу малой скорочти сохр.-загрузки. По моему, все нормально

Вы ее не видите пока работаете с малыми файлами.
Посмотрите график. Эти малые файлы, думаю до 4МБ попадают в область пика ввода-вывода.

А прога должна быть всеядной. Чтобы я мог при случае посмотреть файл, екзешку там, dll-ку, наконец какой-нить файл большой. Не буду же я его в Верде смотреть. И это как раз файлы начиная с 4-5МБ.

прога не предназначена для бинарников. (dll, exe...)

Update 0.5.5

Цитата:

прога не предназначена для бинарников. (dll, exe...)

Это отговорка. Я бинарник открываю в текстовом виде.
В этом виде там часто выложены ресурсы для копирования и другое.

Ну что ж. Раз считаете что прога будет худо-бедно работать как SynWrite или будет лучше, но не будет текстовым редактором, значит так тому и быть.
Значит у проги будет очень ограниченное применение и такой же ограниченный круг пользователей.
А жаль.
А я губы блин раскатал. Типа движок свой. Автор доработает и будет прога лучше всех остальных.
Ан нет. В этот раз даже и проверять не буду. Уверен будут те же грабли.