Изменения к gtkhtml

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

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

Пока не применены мои изменения относительно замены функции получения кода спецсимвола по его имени через автоматически сгенерированную hash функцию(gperf) и замена ранее указанного перемещения(сдвига памяти) на использование 2 буферов.

В дальнейшем gtkhtml в evolution(по планам) будет заменен на WebKit и если планы не изменяться, то развитие проекта будет прекращено. А пока я подправил также и свой миниброузер ради которого и были сделаны эти изменения.

WebOs

Заготовка к 3 выступлению, которая не понадобилась.
Глубокие исследования не проводились,
только в теории.

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

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

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

Основными требованиями к данному хранилищу является:

1. простота добавления новых документов с локального компьютера и возможность добавления с общедоступных сервером минуя стадию копирования файла на локальный диск, файл загружается с ресурса в глобальное хранилище автоматически;
2. защищенность сеансов связи и использование аутентификации пользователя;
3. экономия трафика системы - загрузка по запросу (с использованием логики пред-загрузки для файлов к которым происходит частое обращение в прошлых сеансах), реализация загрузки только отличий файлов.

Все существующее методы обеспечения и реализации удаленного рабочего стола обладают некоторыми недостатками:

1. во время работы в такой среде требуется, чтобы на удаленном компьютере уже стояли полностью настроенные браузеры с установленными java и flash плагинами- что не во всех случаях доступно конечному пользователю.
2. требование поддержки данными браузерами определенных технологий(javascript), что приводит к невозможности использования некоторых браузеров, если на них не было изначально рассчитано приложение.
3. некоторые системы требуют установки дополнительных компонентов, контролировать работу которых сложно.
4. большой объем пересылаемой информации на сервер, так как некоторые функции выполнить на локальном компьютере через браузер сложно;
5. закрытость архитектуры – что, зачем, и куда отсылается;
6. закрытость процедуры аутентификации, невозможно проверить ее надежность.
7. не полная поддержка функций требующихся обычному пользователю (отсутствие интеграции компонентов и не полнота функций), например, существует: календарь, internet messenger, редактор текстов и изображений и почта, с возможность использования как хранилище документов, но они организованы как web-портал c упрощением многих функций. Это хорошо для возможности доступа с любой точки земного шара, но для постоянной работы не подходит;
8. отсутствие гарантий конфиденциальности и неразглашения информации;
9. реализация на основе систем удаленного рабочего стола, приводит к передаче больших объемов информации (действия пользователя + изображение с сервера), хоть и выполняется после сжатия и шифрования, представляют существенный объем, и не позволяют передавать звук и мультимедиа информацию;
10. не реализована возможность работы при утере связи.

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

Динамический пользовательский интерфейс

Продолжение поста относительно URI-based interface. Непосредственно использование динамического пользовательского интерфейса в приложении не обязательно требует использования ранее указанного интерфейса управления и обеспечения работы с данными и их зависимостями при хранении и передаче, но у меня использовалась и подразумевается именно эта комбинация. Но это так пояснение общей структуры приложения...

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

Причиной почему был выбран XML было простота реализации рекурсивного описания компонентов внутри формочек и возможность в случае чего без редактора этих форм - руками подправить ошибки. Из этого XML формировался классы(C#) для упрощения дальнейшей обработки структуры и эти классы в дальнейшем передавались компоненту который по классам формировал элементы с нужной вложенностью и структурой.

В описание любого компонента содержало:

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

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

При потребности смены отображения - система проходилась по существующим блокам и скрывала лишние(так как большинство форм использовало одинаковые блоки элементов и именно их скрывали) и запрашивало визуализацию нужных элементов. Для этой логики форма делилась на блоки с именами и к этим именам привязывалась структура элементов. Как следствие формировалась видимость смены окон - без реального создания нового окна. Если нужно было что-то открыть в новом окне по интерфейсу(URI-based interface.) передавалось сообщение расположенному выше по иерархии контроллеру, который следил за открытыми окнами и мог создать или закрыть окно, сообщение о том что нужно создать новое окно(или закрыть) с параметрами, какую инициализацию в этом окне выполнить (обычно имя формы и какое событие в ней вызвать и с какими параметрами - имя событие всегда совпадает с тегом элемента(кнопки например)).

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

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

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

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

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

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

Проектирование

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

Тест Тьюринга

Недавно исполнилось 71 год машине Тьюринга на которой в основном строятся все современные вычислительные машины.

Мои идеи к реализации решения этого теста методом Китайской комнаты. Решение которой только свидетельствует интеллекте создателя, а не машины.

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

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

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

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

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

4 встреча IT-talk

Побывал на 4 встрече It-talk. Опять не все смогли кто собирался прийти смогли прийти. Но те кто все-таки дошли остались довольны. Оба доклада были достаточно интересными. Особо понравилась идея из второго доклада: документация должна быть понятна всем без исключений.

Единственное, что омрачало это народу пришло много и не всем сразу нашлось место - не рассчитали...

Попугаи и Виста

Пояснение относительно попугаев: все помнят или не очень помнят мультик в котором проверяли сколько попугаев вмещается в одном удаве. Так вот похоже и в Висте производительность тоже меряется в попугаях (это во вкладке система в панели управления). После обновления версии BIOS на ноутбуке производительность рабочего стола Aero резко скакнула с 2.4 -> 3.0(20%). Что довольно таки необычно, так как в BIOS только инициализирует с минимальными работоспособными настройками видеокарту, и как я понимаю и для стандартных обновлений тайминги не должны резко изменяться. И как следствие в принципе на производительность должны в большей степени влиять обновления драйверов на видеокарту, так как они обновляются чаще и могут перенастроить видеокарту при запуске OC. Но с обновление драйверов производительность не изменялась, а как я думаю эта оценка достаточно нелинейна, чтобы немного подсластить переход на более новые версии аппаратуры(а значит немного более дорогие) - так как очень часто при серьёзной разнице в архитектуре - разница в производительности в некритичные моменты не очень отличается. Или что тоже возможно в биосе была какая-то досадная ошибка, что и приводила к не очень эффективной работе.

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

Ещё одно решение заключается в том что архитектура у моего ноута выглядит довольно неэффективно: видеокарта не имеет памяти на борту и берет её откусывая от системной . Поэтому так как в Висте(в отличии от XP) и Линуксе драйвера в теории уже могут сами перенастраивать распределение памяти для видеокарты, то я поставил минимально доступный объем в 32 метра(по умолчанию ставиться 256), чтобы операционная система сама могла решать сколько памяти нужно и столько при потребности откусить. Но мне кажется память на видокарте хотя бы в виде кеша все таки есть - то без неё получается ZX-Specrum - где памяти под видео отдельно как таковой не было и с синхроимпульсом останавливался процессор и из памяти бралась значение цвета для точки. Что не особо положительно влияло на производительность, но зато дёшево. При этом в отличие от выше указанной архитектуры довольно популярной для интегрированных видеокарт, тут есть маленькая особенность: у всех процессоров с интегрированным контроллером памяти в процессоре получается, что для того чтобы получить доступ к памяти, нужно попросить у процессора её переслать, так как непосредственно доступ к памяти получить не удастся, как это было при работе через северный мост.

В общем архитектура UMA во всех своей красе. Зато хорошо подходит для маркетинга - так как через PCIE можно получать доступ к памяти, можно сказать, что у видокарты нет непосредственных ограничений на объем памяти. В AGP, как я помню, можно было получить не более 256 метров и только под текструры. На аппаратном уровне я думаю это решалось достаточно просто скрывая при работе от процессора некоторый объем памяти и на все запросы от интегрированной видеокарты давать доступ к этому участку. Во общем все хорошо - но гонять данные при выводе картинки через процессор звучит не очень хорошо, поэтому думаю что есть все таки маленький кеш в котором и кешируються данные под вывод(framebuffer). В версиях описания архитектуры к более поздним моделям(общей архитектуры системы, а не видиокарты) там было под эти нужды 512Мбит. И этого объема вполне хватит на отрисовку и хранение. Более точных данных я не нашёл.

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