LINUX.ORG.RU

Новая (возможно) концепция универсального редактора ждет критики

 ,


0

3

Пришла такая идея: пишем оболочку редактора, которая обладает рабочей областью, механизмом масштабирования, панелью инструментов слева, деревом объектов справа, классической панелью инструментов сверху. Ну что-то типа корела какого-нибудь.

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

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

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

Все бы было хорошо, но я вижу одну очень страшную проблему - вирусы (ну или вредоносное ПО) и как принципиально все спроектировать чтоб свести эту проблему на нет - я не придумал. Ну можно завести под редактора отдельного пользователя и урезать в правах, можно chroot, можно виртуалку вообще, но это все не то. Вот, выкинул концепцию сюда, вдруг кто что годное придумал...

ЗЫ: все это пьянство никто не мешает сделать кроссплатформенным, это тоже стоит учитывать. К тому же важным преимуществом является независимость от Сети, что срезает возможность централизованной борьбы с вредоносным ПО.

★★★★★

Последнее исправление: ymn (всего исправлений: 1)

Ответ на: комментарий от pihter

Прям все?

По крайней мере в охулиард раз больше чем в твоем редакторе когда-либо в *принципе* будет.

anonymous
()
Ответ на: комментарий от yoghurt

Они здесь тоже ни к селу

А кто тогда ? :)

Компиляция на Си подразумевает наличие на компьютере пользователя компилятора, заголовочных файлов, библиотек и прочей требухи

Это да. Но сложно (это имхо) сейчас найти линуксятника, у которого их нет. (MinGW - тоже ниче страшного)

это внешний и довольно затратный процесс.

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

Настоящие динамические библиотеки - удел Си и Си++. Т.о. написание расширений сводится до этих не самых высокоуровневых языков.

Чем плох фри паскаль? Что мешает один раз написать динамическую библиотеку, которая позволит описать логику на любом скриптовом языке? ЛЮБОМ

Банально - вложенный в документ сценарий на питоне/руби/луа, который расширяет редактор при загрузке документа нужными сущностями/командами/etc.

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

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

не прав. Сишечка потому и умеет Over9000 платформ, потому-что она РАЗНАЯ

хорошо, gcc-шная сишечка тоже везде разная? сколько платформ умеет gcc?

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

При условии, что в динамической библиотеке нет платформозависимого когда.

угу. Насмешил.

И чего смешного? Вполне себе работает. Правда я не на си пробовал, а на фри паскале, но не вижу принципиальной разницы, в данном случае.

pihter ★★★★★
() автор топика

Это называется операционной системой.

anonymous
()
Ответ на: комментарий от pihter

gcc-шная сишечка тоже везде разная?

Да.

сколько платформ умеет gcc?

Много. Но, с учетом вышесказанного, это неважно.

feofan ★★★★★
()
Ответ на: комментарий от buddhist

емакс изобрел?

нет, только собираюсь, отговаривают :)

молодец

я знаю, че уж там :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

gcc-шная сишечка тоже везде разная?

да.

сколько платформ умеет gcc?

Over9000. И везде по-разному. Это не баг, а фича сишечки. Никогда не знаешь, что получится из твоего кода. Об этом лучше даже не думать. Если хочешь написать if(x == 0), так и пиши, НИКАК ИНАЧЕ! Если это можно сделать лучше, компилятор САМ сделает лучше. Ему виднее.

emulek
()
Ответ на: комментарий от pihter

Однако описанный мной подход позволяет заиметь скорость

Ну да, открытие компиляцией такое быстрое...

экономию памяти, которую может дать (грубо) только си

Особенно при ношении исходников в каждом файле и их компиляции. Осиль какой-нибудь скриптовый язык. Тот же Lua за счет jit'а в некоторых случаях быстрее C. Отпадет нужда в компиляторах и компиляции.

feofan ★★★★★
()
Ответ на: комментарий от feofan

При условии, что в динамической библиотеке нет платформозависимого когда.

Такой код в реальной жизни встречается чуть реже, чем всегда.

Ну, если описывая ЛОГИКУ, писать платформо-зависимый код, тогда да - не взлетит. Однако на сишечке вполне можно писать и работу вычислительную нехилую, без зависимости от платформы. (это я так думаю: писал только на паскале)

Репы давно изобретены.

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

pihter ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Любой «расширяемый» редактор обречен на провал, если его автор считает, что писать расширения это как два пальца об асфальт.

Я напишу его, как минимум, для себя.

// Да, шишка хорошая и до сих пор болит.

Не страшно :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Отнацполился и прибежал редактор писать?

Я там еще не закончил! :)

Похвально!

Стараюсь :)

ЯТОЖЕ вижу проблему

Выкладывай!

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Ну, если описывая ЛОГИКУ, писать платформо-зависимый код, тогда да - не взлетит. Однако на сишечке вполне можно писать и работу вычислительную нехилую, без зависимости от платформы.

Как тебе уже сказали, сишечка для этого слишком низкоуровневая. Для этого есть более удобные инструменты. Думаешь, просто так Столлман не стал делать расширения emacs'а на сишечке, а написал для этого на этой сишечке лисп?

feofan ★★★★★
()
Ответ на: комментарий от emulek

я про *.so файлы

Ты считаешь что динамические библиотеки не нужны?! о_О

Тебе тут правильно сказали, что это всё C/C++, а там никакой кросплатформенности не будет.

Вот есть zlib, написанная на С. Покажи мне платформу, где ее не используют?

И даже кросстулкитовости

Будет, если написать два отдельных редактора. На формате тулкит никак не отразится.

И не надейся, что это кто-то осилит переделать

И не надеюсь :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Репы не подходят в общем случае, ибо я хочу автономности

Emacs ставит расширения из своих реп, копирование в новый хомяк ~/.emacs и ~/.emacs.d обеспечит тебя всеми теми плагинами и настройками, которые у тебя были установлены.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: комментарий от feofan

Тогда как там?

Осиль матчасть.

Так я и без тебя знаю :)

текстовый редактор

Отличное решение

Да, но не для разработки печатной платы или дизайна уровня для игрушки.

А если файлов нужно обработать тысячи?

В таком случае мы получим тысячи текстовых файлов, некоторая часть которых один в один будет одинаковой у всех. Не так и страшно: архиватор порадуется.

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

И не надейся, что это кто-то осилит переделать

И не надеюсь :)

Готовься, что для тех полутора форматов документов, которые будет поддерживать твой чудо-агрегат, единственный пользователь сможет нажать кнопочку и всё заработает. Только сначала нужно будет это всё написать.

feofan ★★★★★
()
Ответ на: комментарий от emulek

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

Ну. Дак как это повлияет на либу, описывающую логику, запихнутую в файл?

При чем тут вообще тулкит? Он никак не пересекается с описанной мной идеей.

Заметит юзер, когда у него кнопки будут НЕ ТАМ и нажиматься НЕ ТАК.

И че теперь, вообще программы не писать? Как это с моей идеей-то связано?

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Да, но не для разработки печатной платы или дизайна уровня для игрушки.

Для этого уже существуют удобные инструменты. Комбайн не нужен. Зачем тебе гибрид ужа с ежом?

В таком случае мы получим тысячи текстовых файлов, некоторая часть которых один в один будет одинаковой у всех. Не так и страшно: архиватор порадуется.

А при скачивании этих тысяч из интернета по dialup архиватор когда порадуется? Через месяц?

feofan ★★★★★
()
Ответ на: комментарий от anonymous

Твой редактор взлетит только в одном случае

Кто сказал что мне так важно чтоб он взлетел? Я его для себя напишу, если кому-то еще пригодится - хорошо: я не зря жил, нет - тоже хорошо: забот меньше.

Если он будет свистеть и пердеть громче саблима. Как это ни странно, но даже вимеры и емаксеры на это ведутся.

Не будет.

Визуальная требуха в ущерб функциональности — тренд последнего времени, начатый айфоном. А тем временем, там ни одной нормальной читалки так и не появилось. Это печально.

Печально, моя концепция тут при чем?

А ты пытаешься об архитектуре рассуждать

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

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

даже намного больше

Это я в курсе. Я про описанную мной фичу вопрошаю.

pihter ★★★★★
() автор топика
Ответ на: комментарий от anonymous

По крайней мере в охулиард раз больше чем в твоем редакторе когда-либо в *принципе* будет.

Либо тебя Ричард зовут, либо ты гордиться емаксом имеешь не больше права, чем я, не?

pihter ★★★★★
() автор топика
Ответ на: комментарий от feofan

gcc-шная сишечка тоже везде разная?

Да.

Эм... не знаю. был уверен в обратном. А почему?

FreePascal?

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

gcc-шная сишечка тоже везде разная?

да.

Этого я не знал. Поясни. Разве она не одной и той же логикой компилируется?

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

А почему?

Потому, что пляшет от железа. Концепция языка такая — максимальное быстродействие. А регистры в разных камешках разного размера, например.

feofan ★★★★★
()
Ответ на: комментарий от feofan

Однако описанный мной подход позволяет заиметь скорость

Ну да, открытие компиляцией такое быстрое...

Во-первых, единократное. Во-вторых, не подменяй понятия, я не про открытие говорю, а про работу.

экономию памяти, которую может дать (грубо) только си

Особенно при ношении исходников в каждом файле и их компиляции

Воу воу воу! Я про оперативную память. В скриптовых языках, с нестрогой типизацией и гарбаж коллектором с памятью прям на порядки не та картина, что в си.

Осиль какой-нибудь скриптовый язык. Тот же Lua за счет jit'а в некоторых случаях быстрее C

Не понимаю как это возможно. И не очень верю, если честно.

Еще раз, концепция, которую я предлагаю, никоим образом не отрицает lua. И so-шку каждый раз для него компилировать нужны нет.

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

ты ЗНАЕШЬ как он работает.

капец.. как так? си так непредсказуем? я вот паскалю иногда потихоньку и таких проблем ни разу не возникало...

pihter ★★★★★
() автор топика
Ответ на: комментарий от feofan

Как тебе уже сказали, сишечка для этого слишком низкоуровневая. Для этого есть более удобные инструменты

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

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Ты считаешь что динамические библиотеки не нужны?!

нет, нужны. Просто они криво встают во всякие пхп/луа.

Вот есть zlib, написанная на С. Покажи мне платформу, где ее не используют?

используют, но через Over9000 обёрток.

Будет, если написать два отдельных редактора. На формате тулкит никак не отразится.

что спорить-то?

emulek
()
Ответ на: комментарий от pihter

потому-что всё === неюзабельное говно, по сравнению с VIm'ом.

аргументированно

что вижу — то пою.

emulek
()
Ответ на: комментарий от feofan

Emacs ставит расширения из своих реп, копирование в новый хомяк ~/.emacs и ~/.emacs.d обеспечит тебя всеми теми плагинами и настройками, которые у тебя были установлены.

Однако, если тебе принесли файл, использующий какое-то расширение, и у тебя нет интернета - не прокатит. Ровно как и с древними расширениями, на которые все давно забили (не знаю бывает ли такое в емаксе)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

А какой формат файлов в принципе будет то? Это что будет какой-то новый формат? Опиши структуру этого формата.

xmikex ★★★★
()
Ответ на: комментарий от feofan

Да, но не для разработки печатной платы или дизайна уровня для игрушки.

Для этого уже существуют удобные инструменты. Комбайн не нужен. Зачем тебе гибрид ужа с ежом?

Да это не комбайн вовсе, а просто универсальный интерфейс. Каждый редактор - по прежнему отдельная программа.

Зачем тебе гибрид ужа с ежом?

Преимущества я уже не раз описал и по прежнему в них убежден.

По безопасности, в общем, тоже посоветовали...

А при скачивании этих тысяч из интернета по dialup архиватор когда порадуется? Через месяц?

Здесь недостаток моего концепта неоспорим, да.

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

сделаю, подскажи как с безопасностью

на этапе идеи ИМХО про безопасность думать рановато. Но сразу скажу, что so на сишечке == дыра. Ты её никак не проконтролируешь. Вот скрипт — может и не дыра, если ему всё позапрещать.

emulek
()
Ответ на: комментарий от pihter

Этого я не знал. Поясни. Разве она не одной и той же логикой компилируется?

нет. Разной. Архитектура-то разная. Ну и логика разная.

emulek
()
Ответ на: комментарий от feofan

Потому, что пляшет от железа. Концепция языка такая — максимальное быстродействие. А регистры в разных камешках разного размера, например.

Ясно. А вот есть фри паскаль, чем плох в этом вопросе? И шустр, почти как С и платформ поддерживает - много, и язык стабильный и типизация строгая и память протечь очень сложно и динамические библиотеки умеет отлично.

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

используют, но через Over9000 обёрток.

тем не менее.

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Как в песочнице? Есть кроссплатформенные (хотя бы вин/лин) решения? Лицензия?

Для native кода - google native client. Для многих интерпретируемых языков есть возможность делать песочницу, например JavaScript. Для многих компилируемых в байткод языков есть возможность делать песочницу, например Java. Но конкретно в джаве очень много багов в этой песочнице, рекомендовать бы её я не стал.

Проблемы в устаревании кода, обратной совместимости.

Вот этой проблемы как раз нет в принципе: каждый документ несет в себе необходимый для его обработки код. То есть документ гарантированно сработает в этом редакторе, не смотря на версии. Такого не может предложить не один редактор из известных мне. (не знаю как там в емаксе, поправьте, если что)

Проблема устаревания кода например в том, что в исполняемой части документа могут быть баги. Ты их можешь пофиксить, но документ уже ушёл и разошёлся по интернету.

Проблема обратной совместимости в том, что ты никак вообще не сможешь изменить однажды зарелизенное API, даже если оно впоследствии оказалось неудачным. В случае плагинной архитектуры можно делать deprecated функции, давая время авторам плагинов на переписывание.

Ну парочку преимуществ я уже описал: гарантированная работоспособность документа, даже если он более поздней версии редактора

Это реализуется продуманным расширяемым форматом документа.

присутствие отсутствия необходимости в поиске, установке и настройке соответствующего плагина

Это всё при желании автоматизируется.

Legioner ★★★★★
()
Ответ на: комментарий от pihter

Такую концепцию я придумал

С концепцией всё нормально IMHO. Вопрос в use case-е; в то время, как человечество бороздит путь в облака и прочие ?aasы, неустановленный софт проблемой являться не должен.

А если у него там винда?

Уже все научились картинки прокачивать.

А если файл гиговый? А если их таких у меня полторы тыщи?

Тем более, нужно на месте обрабатывать, а не таскать туда/сюда.

откопал я у ся на харде столетний файл

И кто нынче надеется на то, что удастся придумать неустаревающий интерфейс для плагинов?

Кстати, можно прицеплять к файлу не обработчик, а урлу. Можно в виде шапки «#!твойредактор --plugin=урл». И пусть код оттуда тащут. Места сэкономишь, и обновления бесплатные.

DonkeyHot ★★★★★
()
Ответ на: комментарий от xmikex

какой формат файлов в принципе будет то?

Сие обдумывается :)

Это что будет какой-то новый формат?

Да.

Опиши структуру этого формата.

Пока так: текстовый файл, в котором:

1. Указана версия самого редактора.

2. в текстовом виде - любые данные, которые «плагин» захочет сохранить.

3. Информация о версии динамических библиотек, используемых при подготовки этого документа.

4. информация о необходимых компиляторах.

5. исходный код библиотек, используемых в качестве «плагинов» при подготовке докумнета.

все это ужато gzip'ом сверху

КРИТИКУЙТЕ

pihter ★★★★★
() автор топика
Последнее исправление: pihter (всего исправлений: 1)
Ответ на: комментарий от emulek

на этапе идеи ИМХО про безопасность думать рановато

А вот я подумал, почему бы и нет, если есть возможность продумать еще до начала реализации?

pihter ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.