Обсуждение развития MSEide + MSEgui

[m_guest]

>а что есть zeos ?
ZEOSDBO здесь

[debi12345]

а что есть zeos ?
=============
Опенсорсная библиотека компонентов для доступа к платным (и бесплатным тоже) серверам - Oracle, M$SQL, ASA, MSAccess,..

Статус в MSE*: соединения с БД используются как родные, Мартин пишет "no problems are found up to now".

[Alexander]

Теперь МСЕ не работает с FPC 2.0.4 и требует версии 2.2.0.

[Attid]

Alexander
о пропащие появились =)


требует то требует но работать будет и с 2,0,4 .
а может уже и нет =) но точно помню недавно в ридми было добавление что "теперь мсе работает и с 2,0,4" может опять убрал ..

ЗЫ ну что органайзер сделал ?

[Alexander]

о пропащие появились =)

Были очень серьёзные проблемы со здоровьем мамы.

ну что органайзер сделал ?

Не до органайзера было.
Потихоньку его делаю когда время позволяет.
Пока воюю с записной книжкой. Продумал
более менее формат файлов и организацию
работы. Обойдусь без баз данных, уж очень
муторно и не в тему, простые текстовые файлы в utf8.
Борьба всё ещё предстоит с деревом МСЕ.
Да и с сетками тоже. Сейчас вот буду ФПК новый
качать и собирать

[debi12345]

Обойдусь без баз данных, уж очень
муторно и не в тему, простые текстовые файлы в utf8.
--------------
А я бы SQlite3 использовал - потому что автоматом предоставит и сжатие, и группировку на SQl-запросах, и локальные индексы + поиск....

ПС:
Парни из M$ ведь не дураки, что для хранения писем в Outlook выбрали БД = DBF.

[Alexander]

А в каком виде с тз файловой системы и формата файла(ов) SQlite3
хранит данные ?

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

Впрочем выложу в тему органайзера рабочий вариант формата.
Думаю программа могла бы заинтересовать многих.

Парни из M$ ведь не дураки, что для хранения писем в Outlook выбрали БД = DBF.

Я в Линуксе Клаусом пользуюсь. Так он каждое письмо в отдельном
файле хранит. А Оутлук выкинул быстро (заменил Бэтом) после знакомства
с ним в 2000 году. Вирусы собирает, ящики не сохраняет, глючит.
И криптографию не поддерживает.

[debi12345]

А в каком виде с тз файловой системы и формата файла(ов) SQlite3
хранит данные ?

Есть несколько фундаментальных ( disk storage ) типов - INTEGER2/4/8, TEXT, FLOAT и BLOB. Остальные типы - композитные (из может быть сколь угодно много ), то есть записываются в поля соответствующих фундаментальных, с определенными соглашениями о формате и опознавательными признаками. Так появились типы VARCHAR, DATE, DATETIME, NUMERIC... Текст хранится строго в UTF8-кодировке. NUMERIC, LARGEINT => INTEGER8. BOOLEAN => INTEGER2. Многостраничный текст, музыка и фото => BLOB, работает на "ура", и чтение, и запись.

Файлы - самые обычные, из заголовка и данных. После удаления записей файлы по умолчанию не уменьшаются (но есть VACUUM или опция "autovacuum" ). Одну или несколько таблиц можно вынести в отдельный файл БД, а потом все эти файлы их объединить в одну виртуальную (на время сеанса ) БД командой ATTACH (за что я сразу ухватился и сделал проект на этой фиче - ROZNITSA называется ).

Режим доступа - настоятельно рекомендуется через SQL, практически неотличимо от PostgreSQL/FireBird. Поэтому о формате файлов можно не задумываться.

ПС:

1) категорически запрещается пользоваться сторонними утиллитами типа SQliteAdmin - создают нестандартный форм полей, запарывают "чужие" БД.

2) за деталями реализации можете посмотреть рабочий вышеупомянутый проект ROZNITSA из реaльной жизни ( лежит в "public.binaries" ветке конференции )

[Attid]

1) категорически запрещается пользоваться сторонними утиллитами типа SQliteAdmin - создают нестандартный форм полей, запарывают "чужие" БД.

кста былоб не плохо прям в МСЕ сделать создание БД в SQLite через гуи.

можно внести в список полезных прог на сайте =) только у на сайте в МСЕ всего 3 человека видно.

[Alexander]

debi12345, спасибо !

Обновился до ФПК 2.2.0. "Экзешники" стали крупнее (ну всегда так).
МСЕ собрался нормально. Но make действительно не работает,
только build. Это баг ФПК ? Он известен разработчикам ? Если нет
надо сообщить.

[debi12345]

кста былоб не плохо прям в МСЕ сделать создание БД в SQLite через гуи.

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

Лично я - не особый сторонник этой тулзы, потому что манипуляции с БД через SQL-скрипты гибче ( и безопаснее ), ИМХО.

обновился до ФПК 2.2.0. "Экзешники" стали крупнее (ну всегда так).

Причина резкого увеличения экзешников - включение всех возможных модулей в USES - чтобы не нужно было искать, какой модуль включить для компиляции некоего "EVENT HANDLER". Это я "удружил" - скрипт написал для генерации "UNIT GROUPs", сканирующий RTTI и узнающий, какие модули могут быть ПОТЕНЦИАЛЬНО задействованы.
Лечится только релизной сборкой ( смартлинк, выкидывание отладочной информации ). Кстати, FPC 2.2 пока не даст сделать смартлинк.

Но make действительно не работает,

Работает, но только после выравнивания дат файлов ( делаемом при BUILD ).

[Alexander]

Мартин поднимал тему раскрутки МСЕ.
Думаю, что без х вещей массовый пользователь к МСЕ не потянется.

1. Документация.
2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.
3. Отсутствует механизм компонентов. Сейчас для установки
компонента надо менять вручную содержимое файла.

Без этого МСЕ будем пользовать только мы, круг посвящённых

Но если о 3п должен подумать Мартин, то над первыми двумя и мы должны.

У меня есть пара мыслей насчёт документирования.

[Attid]

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

[debi12345]

2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.

Народ - понятие растяжимое. Лично я не вижу в нем особого смысла. Нынешний незакрываемый popup намного удобнее - лазишь в нем, варианты смотришь.

3. Отсутствует механизм компонентов. Сейчас для установки
компонента надо менять вручную содержимое файла.

Это не от Мартина зависит, а от FPC. Делать суррогатные псевдо-компоненты по типу Лазаруса - нет смысла, потому что нет наработанных компонент, которые нужно срочно импортировать.

1. Документация.

В точку ! Это - ЕДИНСТВЕННОЕ препятствие для новичков.

У меня есть пара мыслей насчёт документирования.

Это какие ?: Приказать по-военному "Дока, напи-шИсь!" ?
Лично я считаю, что без финансового поощрения ( в рамках наших умеренных цен и зарплат ) это процесс будет крайне медленным ( по себе знаю - невероятно адский и ненужный для пишущего это труд, и нужно уйму свободного времени, с которым у профессионалов всегда напряг, а непрофессионал такую систему не разложит по полочкам ). Я, увы, не профессионал ( они все в Москве ) - но держу в качеств ориентира.
Кстати, Мартин случайно не миллионер ?

[Alexander]

Не совсем.
Есть путь документирования исходников в них самих - pasdoc.
Этот путь удобен для программиста (создателя программы).
Другой путь - просто документировать, а потом тоже лазить, искать.
Этот путь удобен для писателя документации - не программиста.
Третий путь - как в Делфи - автодополнение и контекстная справка.
Этот путь наиболее удобен для пользователя. Но ещё не позволяет
пользователю участвовать в процессе.

На мой взгляд должно быть что то вроде базы данных с уникальными
вхождениями "путей" (функций записей типов констант классов итд.)
А возможно, наоборот, не база, а к каждому файлу исходников
файл(ы) доки.

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

Например написал название функции нажал на что то и получил
справку по ней. Или нажал правой кнопкой мыши на поле в
object inspector и получил справку по нему. А нет - разобрался и написал.
Такая база могла бы быть полезной не только для МСЕ.

Лично я не вижу в нем особого смысла. Нынешний незакрываемый popup намного удобнее - лазишь в нем, варианты смотришь.

Мне автодополнение в Делфи и ВБ помогало в изучении языка и
заметно ускоряло написание программ. Это могучая вещь.
Но если физически возможно реализовать вышеуказанную систему
помощи, можно относительно несложными средствами реализовать
и автодополнение, которого в Делфи не снилость - с описанием.

Вот.