Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 337 сообщений
Cообщения с меткой

ядро - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Dropbox объяснил, почему внедряется в ядро операционной системы

Четверг, 26 Мая 2016 г. 13:08 (ссылка)






Ровно месяц назад Dropbox анонсировал Dropbox Infinite — «революционно новый способ доступа к вашим файлам», как писала компания в корпоративном блоге. В демонстрационном видео показали, что десктопный клиент Dropbox предоставляет прямой доступ к облачному хранилищу файлов на уровне файловой системы, без необходимости запускать браузер. Локальный диск «увеличивается» на размер облачного хранилища, файлы доступны напрямую. Облачное хранилище может быть больше по размеру, чем локальный диск. Сейчас компания раскрыла технические подробности, как работает эта функция.



Сразу после первого анонса эксперты высказали опасения, что Project Infinite откроет доступ в систему посторонним, если они найдут уязвимости в клиенте Dropbox. Собственное расширение ядра от Dropbox станет тогда своеобразным бэкдором в системе.

Читать дальше →

https://habrahabr.ru/post/301826/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Анатомия драйвера

Среда, 27 Апреля 2016 г. 16:56 (ссылка)

Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.



Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.



Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.



С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).



В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.



Цикл жизни драйвера, в целом, может быть описан так:




  • Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)

  • Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы

  • Активация — драйвер начинает работу

  • Появление/пропадание устройств, если это уместно. См. тот же USB.

  • Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.

  • Деактивация драйвера — обслуживание запросов прекращается

  • Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.





(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)



Мне известны три модели построения драйвера:




  • Поллинг

  • Прерывания

  • Нити (threads)





Драйвер на основе поллинга (циклического опроса) устройства



Такие драйвера применяются только с большого горя или по большой необходимости. Или если это простая встроенная микроконтроллерная система, в которой и есть-то всего два драйвера. Например, конвертор интерфейсов serial port <-> TCP, в котором сеть работает по прерываниям, работу с последовательным портом может, в принципе, выполнять и поллингом. Если не жалко избытка тепла и затрат энергии.



Есть и ещё одна причина: такие драйвера практически неубиваемы. Поэтому, например, в ОС Фантом отладочная выдача ядра в последовательный порт сделана именно так.



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



#define PORT 0x3F8

int dbg_baud_rate = 115200;

void debug_console_putc(int c)
{
while(! (inb(PORT+5) & 0x20) )
;

if( c == '\n' ) outb(PORT, '\r' );
outb(PORT, c);
}

void arch_debug_console_init(void)
{
short divisor = 115200 / dbg_baud_rate;

outb( PORT+3, 0x80 ); /* set up to load divisor latch */
outb( PORT, divisor & 0xf ); /* LSB */
outb( PORT+1, divisor >> 8 ); /* MSB */
outb( PORT+3, 3 ); /* 8N1 */
}




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



    while(! (inb(PORT+5) & 0x20) )
yield(); // отдать процессор другим нитям, пока наше устройство не готово




Но, конечно, в целом это никуда не годная (кроме вышеприведённого случая:) модель.



Драйвер на основе прерываний



Общая структура такого драйвера выглядит вот как:




strauct device_state dev;

dev_write( buf )
{
dev.buf = buf;
if( dev.started ) dev_start();
cond_wait( &dev.ready );
}

dev_interrupt()
{
dev_output();
}

dev_start()
{
dev.started = 1;
dev_enable_interrups( &dev_interrupt );
dev_output();
}

dev_output()
{
if( buffer_empty() || (!dev.started) )
{
dev.started = 0;
dev_disable_interrupts();
cond_signal( &dev.ready ); // done
return;
}

// send to device next byte from buffer
out( DEV_REGISTER, *dev.buf++ );
}




Фактически, такой драйвер порождает для себя псевдо-нить: поток управления, который живёт только на поступлении прерываний от устройства.



Как только драйвер получает очередной запрос на запись, он включает прерывания и «вручную» инициирует отправку в устройство первого байта данных. После чего входящая нить засыпает, ожидая конца передачи. А может и вернуться, если нужна асинхронная работа. Теперь драйвер будет ждать прерывания от устройства. Когда устройство «прожуёт» полученный байт, оно сгенерирует прерывание, при обслуживании которого драйвер или отправит очередной байт (и будет ждать очередного прерывания), или закончит работу, выключит прерывания и «отпустит» ждущую внутри dev_write() нить.



Что забыто



Прежде чем мы перейдём к последней модели драйвера, перечислим вещи, которые я (намеренно) пропустил в предыдущем повествовании.



Обработка ошибок


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



Таймауты


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



Смерть запроса


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



Синхронизация


Для простоты я указываю в качестве примитива синхронизации cond. В реальном драйвере это невозможно — cond требует объемлющего mutex в точке синхронизации, а в прерывании какой уж mutex — нельзя! Вот в последней модели, драйвере с собственной нитью, можно применять cond как средство синхронизации нити пользователя и нити драйвера. А вот синхронизация с прерыванием — только spinlock и семафор, причём реализация семафора должна быть готова к возможности активировать (открыть) семафор из прерывания. (В Фантоме это так и есть)



Драйвер на основе нити



От предыдущего он отличается тем, что имеет собственную нить, которая выполняет ввод-вывод.




dev_thread()
{
while(dev.active)
{
while(!dev_buffer_empty())
cond_wait(&dev.have_data);

while( /* device busy */ )
cond_wait(&dev.interrupt);

dev_enable_interrupts();
// send to device next byte from buffer
out( DEV_REGISTER, *dev.buf++ );
}
}

dev_interrupt()
{
dev_disable_interrupts();
cond_signal(&dev.interrupt);
}




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



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



Блочный ввод-вывод, сортировка и заборы



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



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



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



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



Кроме того, плохая идея переставлять местами запрос на запись блока N и запрос на чтение того же блока. Впрочем, это вопрос договорённостей.



Original source: habrahabr.ru.

https://habrahabr.ru/post/282564/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kiev2376393

DCM как ядро платформы Doubleclick: интеграция с DBM и другими инструментами

Пятница, 23 Апреля 2016 г. 00:51 (ссылка)

24 марта в Москве прошла профессиональная конференция по онлайн-аналитике Go Analytics! 2016. Мероприятие уже третий год собирает ведущих экспертов и лидеров отрасли.
В рамках конференции Андрей Липатов (Google) представил доклад на тему: «DCM

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kiev2376393

Применение Google Analytics для расширения семантического ядра (на примере Price.ru)

Пятница, 23 Апреля 2016 г. 00:40 (ссылка)

Автор: Александр Егоров , директор по развитию Alytics





Сбор качественного семантического ядра - задача нетривиальная. Особенно, если все очевидные запросы уже давно в работе, синонимы подобраны, Wordstat пропарсен, а SpyWords и KeyCollector

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Совет1

Как узнать 32-битный или 64-битный режим ядра

Суббота, 05 Марта 2016 г. 13:03 (ссылка)

Для Windows XP существует только 2 способа как узнать 32 или 64 версии установлены на компьютере...Далее

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Совет1

Как установить Ubuntu без помех для работы

Понедельник, 28 Декабря 2015 г. 22:25 (ссылка)

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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Hot-Play

Обновление PlayStation 4 (PS4) дает больше возможностей для разработчиков / ИгроБлог

Среда, 02 Декабря 2015 г. 08:49 (ссылка)
hotplay.com.ua/publ/obnovle.../1-1-0-670


Последнее обновление для консоли PlayStation 4 (PS4) даст разработчикам больше технических возможностей



Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Вопросы для нового интервью с Эдуардом Шишкиным

Вторник, 17 Ноября 2015 г. 21:07 (ссылка)

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



В комментариях можно оставлять свои вопросы. Само интервью будет опубликовано мной здесь, на Хабре.



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/271077/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
leovik7

ИНТЕРЕСНЫЕ ФАКТЫ О ЗЕМЛЕ!

Пятница, 13 Ноября 2015 г. 18:55 (ссылка)




fakti_29 (700x647, 211Kb)



Эти факты о Земле могут вас удивить:





1. Самое сухое местом на планете – это Сухие долины Мак-Мердо (Dry Valleys). Там не было дождя последние 2 миллиона лет.



2. Ежегодно ветром переносится 40 миллионов тонн пыли из Сахары в районы Амазонки.



3. Температура ядра Земли находится на уровне 5500 градусов Цельсия, что равняется температуре поверхности Солнца.



4. В ядре Земли находится 99% золотого запаса планеты.



5. Земля - единственная планета во всей солнечной системе, на которой происходит тектоническое движение плит. Без этих процессов углекислый газ не перерабатывался бы, и наша планета перегрелась бы, как Венера, уничтожив все живое.



6. Большинство вулканов Земли (90%) находятся под водой.



7. Литр соленой морской воды содержит в себе 1/13000000000 грамм золота.



8. 97 процентов всей воды Земли – это соленая вода.



9. Из этих 3% оставшейся воды – 70% приходится на ледяные шапки планеты.



10. Из оставшихся 30% - снова порядка 70% является либо почвенной влагой, либо расположена глубоко в земле, в малодоступных водоносных слоях.



11. 20% пресной воды, находящейся в озерах и реках, находится в одном месте – в России, озеро Байкал.



12. Ежедневно на нашей планете происходит порядка 8,6 миллионов ударов молний.



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



14. На высоте в 19 километров наблюдается явление, известное как Линия Армстронга (Armstrong Limit). Именно достигнув эту высоту человек должен быть в скафандре, иначе он умрет. На этой высоте давление настолько низкое, что вода способна закипеть при температуре человеческого тела.



15. Земная орбита загрязнена более чем 38 тысячами антропогенными объектами.



16. Размер 22 тысяч из них более 10 метров в длину.



17. Ежедневно, по крайней мере, один из антропогенных объектов падает на Землю.



18. Звездные сутки длятся 23 часа 56 минут и 4 секунды. Именно столько времени требуется нашей планете для того, чтобы сделать оборот вокруг своей оси.



19. На самом деле, Великую Китайскую стену из космоса не видно. Однако, из космоса можно увидеть смог, нависший над Китаем. Также из космоса видно Большой Барьерный Риф.



20. Самая удаленная фотография голубой планеты была сделана с расстояния 183 миллионов километров с американской станции Messenger. Фото называется «Pale Blue Dot», что переводится как «бледная голубая точка». На фото видно не только Землю, но и луну.



21. Озоновая дыра уменьшается. В 2012 году был зафиксирован наименьший размер за последние 10 лет.



22. Пластиком, который применяется людьми чуть более 100 лет, наиболее загрязнен мировой океан. Доля пластика среди мусора в толще воды составляет 90%.



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



24. Из-за данной аномалии в некоторых регионах планеты сила притяжения больше, либо меньше, чем в противоположных. Одно из таких мест – Гудзонский залив (Hudson Bay) в Канаде. Однако, разница в притяжении очень мала, и различие в весе составляет всего 0.005%.



25. Мы знаем о нашей Вселенной намного больше, чем о ядре Земли и даже океанах. Более того, не исследовано и 95% территории мирового океана.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Stepan_Sikora

Смерть планеты: Ученые сообщили, когда замерзнет ядро Земли

Четверг, 08 Октября 2015 г. 18:16 (ссылка)
fenixslovo.com/ru/society/science/8704

Ядро остывает сейчас гораздо медленнее, чем предполагали ученые, что дает человечеству и прочей жизни на Земле больше времени для существования. Брита...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Бослав

Недюжинный талант и твёрдая позиция...

Пятница, 11 Сентября 2015 г. 17:25 (ссылка)

Это цитата сообщения Цветок_грез_Танюша Оригинальное сообщение

Шестидесятники. Юнна Мориц











Напомнит что душа -

...Не мера, а избыток,

...И что талант - не смесь

...Всего, что любят люди,

...А худшее, что есть,

...И лучшее, что будет . . .

Юнна Мориц





Юнна Мориц — одна из ярких представителей поколения советской интеллигенции «Шестидесятники». Как и другие представители этого времени у нее было военное детство, которое по-своему сформировало мировоззрение и творческий путь юной писательницы.



СЕБЕ



Держи удар, дистанцию и слово.

Держи святую воду и перо.

Держи картошки полное ведро

И ожерелья лука золотого.

Они – твоё несметное добро,

Защита – от любого духа злого.



Держи свой путь, а не по ветру нос.

Держи любовь – бессмертно, тайнозримо,

Чтоб не держать ни краски для волос,

Ни туши для ресниц, ни щёк для грима,

На это есть всегда огромный спрос, –

Но подлинника страсть неповторима.



Держи улыбку, не оскалив пасть,

Как демонстранты кафеля зубного.

Держи себя, чтоб в лапы не попасть

Общественности, рвущейся во власть –

Кроить страну, как ножницы портного!

Держи удар, дистанцию и слово.



Ядро поэтики – атлетики ядро,

Держи ядро атлетики поэтской.

Ядрёный дух держи природы детской.

Держи картошки полное ведро.

Держи святую воду и перо.

Они – твоё несметное добро.



***



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



Читаем далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Ядерные технологии в CAD

Пятница, 07 Августа 2015 г. 08:10 (ссылка)

image

В этой статье я предлагаю краткий обзор библиотек геометрического моделирования с точки зрения разработчика специализированной CAD системы и делюсь опытом интеграции ядра C3D.



Если рынок «больших» программ проектирования давно поделен между несколькими крупными игроками вроде AutoCAD, SolidWorks, NX, Creo Elements и CATIA и т.п., то рынок специализированных программ проектирования всего и вся – окон и лестниц, корпусной и мягкой мебели, трубопроводов и корпусов весьма широк и динамичен. Причин для этого, на мой взгляд, две: во-первых, это высокая стоимость покупки крупной САПР и сотрудника, умеющего в ней эффективно работать. А, во-вторых, отсутствие адаптации для проектирования конкретных изделий в крупной САПР приводит к тому, что скорость проектирования специализированных изделий в них низкая.



Специализированные САПР являются ответом на указанные проблемы и перед программистом стоят два пути их создания. Первый – доработка крупной САПР с использованием предоставляемых API, плагинов и всевозможных скриптов. Этот подход не всегда оправдан, т.к. в результате стоимость САПР возрастает для пользователя (нужно платить как за большую САПР, так и за адаптацию), а требуемая квалификация инженера (а, следовательно, и затраты на его обучение и содержание) для работы с таким комбайном достаточно высоки. Второй путь – создание системы «с нуля». Этот путь, несомненно, значительно сложнее, т.к. огромный функционал нужно разработать с самого начала. Но несмотря на это он может оказаться значительно дешевле и удобнее в использовании для конечного пользователя, который и определяет успех продукта.



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



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



С прикладной точки зрения в CAD все решения геометрического моделирования можно разделить на три группы – использующие полигональное, воксельное и граничное представление. Полигональное моделирование объектов — это генерация объектов в виде набора полигонов, как правило, треугольников, которые в дальнейшем визуализируются с помощью графических API вроде OpenGL или DirectX. Этот способ наиболее прост в реализации. Создание полигональных тел и конструктивные операции с ними можно написать самостоятельно или воспользоваться открытыми библиотеками, например, CGAL. Мы использовали такую самописную реализацию много лет и она вполне себя оправдывала: дешево и сердито. Таким образом, мы довольно долго моделировали достаточно сложные мебельные изделия, например гнутые фасады, без особых хлопот. Однако полигональное представление имеет существенные недостатки, которые в итоге и вынудили искать альтернативные решения. Недостатки эти следующие: в полигональных моделях нет информации об ограничивающих тела кривых (дуг, окружностей, сплайнов) на поверхностях, а это существенно осложняет работу конструктора, затрудняя точные построения от неплоских поверхностей (например цилиндрических, конусных, сферических, парабалоидных), снижается качество геометрии при конструктивных CSG операциях, делает невозможным создание корректных чертежей спроектированных объектов, расчет точных площадей поверхностей, объемов тел и т.п. Воксельное моделирование также достаточно специфично и не предназначено для решения типичных задач конструирования.



Альтернативным решением является моделирование объектов с помощью граничного представления BREP. BREP это представление трехмерных тел, которое описывает границу этих тел в виде набора связанных граней, а каждая грань является контуром на поверхности (например плоской, цилиндрической, сферической, конической или NURBS). image Этот способ свободен от недостатков полигональных моделей (хотя использует полигональные модели как промежуточный этап для визуализации или расчетов) и именно он используется в абсолютном большинстве CAD систем. Однако математический аппарат для такого моделирования несоизмеримо сложнее, и выбор библиотек достаточно ограничен. Большинство из них написаны на С++ и некоторые имеют врапперы для использования в других языках.



Лидеры в этой области – ядра Parasolid и ACIS. Они используются в подавляющем большинстве CAD. Наряду с ними известны CGM и Granite, компоненты крупных САПР Catia и Creo Elements, которые сравнительно недавно стали доступны для лицензирования. Все они обладают мощнейшей функциональностью, хорошо оттестированы и оптимизированы. Единственный их недостаток для нашего брата – цена. Очень внушительные ежегодные выплаты вкупе с большими процентными отчислениями от каждой продажи делают создание небольших CAD на их основе дорогостоящим мероприятием.



Solids++ и SMLib – две не очень известные коммерческие библиотеки и мне не удалось найти информацию о CAD системах, построенных на их основе. Согласно описаниям на их сайтах обе они реализуют типичные для геометрических ядер операции. Насколько стабильно и надежно они работают – вопрос открытый. SMLib обладает весьма весомым преимуществом – в отличие от всех остальных коммерческих библиотек, она продается вместе с исходными текстами.



Единственная на тот момент доступная отечественная разработка – ядро C3D, разработанное в АСКОН для Компаса. В момент выбора оно только выходило на рынок и заинтересовало сбалансированным для нас соотношением цены и функционала. В момент выбора ядра на горизонте также появился RGK – амбициозный отечественный проект, статьи о котором уже появлялись на хабре http://habrahabr.ru/post/180455/ и http://habrahabr.ru/post/180707/, однако спустя несколько лет никаких данных о нем невозможно получить даже на официальном сайте. А официальная почта не отвечает на письма.



Последнее рассматриваемое ядро – OpenCASCADE – единственное бесплатное решение. На его основе создан известный пакет FreeCAD. Ядро, несомненно, обладает развитым функционалом и, на мой взгляд, достаточно удобным API, но, к сожалению, и достаточно большим количеством недоработок, которые при тестировании часто происходили в операциях вычитания тел с и генерации проекций деталей. Однако не стоит забывать, что это открытый проект, в котором при возможности вы можете поправить ошибки самостоятельно. Это ядро можно использовать в коммерческих продуктах совершенно бесплатно, но не стоит забывать, что, дополнительные модули (http://www.opencascade.org/support/products) и техническая поддержка будут платные.



Полноценно сравнить вышеприведенные пакеты, конечно, невозможно без кропотливой работы с каждой из них, однако примерное представление об их функционале можно получить по CAD системам, сделанных на их основе. Исходя из наших финансовых возможностей, у нас выбор был между либо бесплатным OpenCASCADe, либо отечественным C3D. Выбор был сделан в пользу C3D по причине большей стабильности, которая была крайне важна, т.к. требовалось корректно импортировать огромное количество моделей созданных на своем движке. И по первому взгляду на OpenCASCADE сложно предсказать, сколько времени придется повозиться над исправлением его багов. Немаловажным было и наличие импорта/экспорта DXF и стабильных алгоритмов генераций проекций и силуэтов в ядре C3D. Однако, если бы наши задачи были менее специфичны, то, возможно, OpenCASCADE оказался бы более выгодным решением.



В результате мы решились на внедрение ядра от АСКОН, которое заняло у нас немалое время и я хочу поделиться с читателями этим опытом. Ядро C3D представляет набор C++ классов описывающих BREP модели, вспомогательные классы и набор алгоритмов оформленных в виде глобальных функций. На первом этапе внедрения надо было решить, как вообще подключить С++ ядро к программе, которая, по историческим причинам, написана на Delphi. Написание С-интерфейса для всех необходимых функций казалось утомительным и негибким подходом. Выход нашелся довольно быстро – написать промежуточную «интерфейсную» DLL на С++ с использованием чисто абстрактных классов, которые можно напрямую использовать в Delphi, т.к. они содержат внутри себя указатель на VMT, формат которой, к нашему счастью, у компиляторов от MS и Embarcadero полностью совпадает. В результате я написал DLL-прослойку, которая предоставляет необходимый функционал в ООП стиле и экспортирует одну лишь функцию из DLL – получение основного интерфейса.



Следующий этап – построение всех необходимых тел в ядре C3D по исходным данным, их триангуляция и получение триангуляции обратно для визуализации. В этой части не было никаких сложностей. На основе функций построения ExtrusionSolid, EvolutionSolid тела строятся, а с помощью функций BooleanResult они комбинируются друг с другом путем вычитания, сложения и пересечения. На выходе у них образуются тела MbSolid которые и содержат данные BREP – грани MbFace, ребра MbEdge и т.п. Все казалось замечательно, пока не начал тестировать более-менее сложные модели – стоить огромное количество объектов без кеширования оказалось не очень быстрым – скорость по сравнению с самописным подходом упала раз в 10, что нас категорически не устраивало. Тут нужно отдать должное ТП у C3D – они помогли переписать функции построения наиболее распространенных тел «вручную», т.е. мы стали строить некоторые тела самостоятельно создавая каждую грань тела и описывая все ребра на них и связывая их друг с другом, получая на выходе корректное замкнутое тело.



Следующий этапом была визуализация – подхватить триангуляцию из C3D и отрисовывать её. Казалось задача проста (учитывая имеющийся рендер на OpenGL), однако обнаружилась неожиданная загвоздка: нам крайне важна визуализация объектов с текстурами, а явной поддержки текстурных координат в ядре C3D нет (видимо потому, что их нет в Компасе 3D). Пришлось выкручиваться следующим образом: ядро позволяет генерировать для треугольников так называемые параметрические координаты и для каждой грани можно подсчитать коэффициенты масштабирования, которые позволят наложить текстуру более-менее реалистично. Однако этот способ не позволяет рассчитать текстурные координаты связано для нескольких граней. Пришлось написать дополнительные «костыли» и с помощью атрибутов связывать координаты текстуры на гранях друг с другом. Кроме того, для визуализации и редактирования моделей нужно передавать различные данные, которые мне также рекомендовали сохранять с помощью атрибутов, представляющие собой массивы (имя-значение), которые можно назначать на тела, грани и рёбра.



Самой сложной частью интеграции стало моделирование тел гнутых фасадов.

image

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

Завершающим этапом интеграции стали различные операции экспорта/импорта (STEP, DXF), анализа взаимного расположения тел и тому подобное. Отдельное слово хочу сказать об отладке в ходе которой в ядре было выявлено значительное количество ошибок, которые к счастью более-менее оперативно решались разработчиками. Тут я хочу суммировать основные проблемы с которыми мы столкнулись:

1. Недостаточно удобное и структурированное API с множеством легаси-кода, разделение всех типов на 2D/3D и неудобные и неединообразные функции в 2D, cамописные типы и структуры, повторяющие STL, но значительно менее удобные

2. Недокументированные механизмы формирования имен всем элементам построения и необходимость их передавать даже если они не используются

3. Необходимость приводить все данные к точности порядка 1e-6, отсутствие управления точностью и различные ошибки, происходящие при её несоблюдении

4. Отсутствие операций построения пути фрезерования и деформации тел



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

1. Экономия значительного объёма времени (потраченного на создание и поддержание собственного решения)

2. Улучшено качество создаваемой геометрии, правильное построение криволинейных поверхностей и границ

3. Получение качественных чертежей с удалением невидимых линий

4. Экспорт/импорт в «сапровские» 3d форматы (STEP, SAT, XT, DXF)



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

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/264243/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Что мы знаем о MODX 3 на данный момент?

Воскресенье, 31 Мая 2015 г. 15:37 (ссылка)


MODX*
Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?



Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.



Почему нам все равно нужен MODX 3?



Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.



Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.



Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.



В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.



Синдром «это придумали не мы»



Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.



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



Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:




  • Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.

  • Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.

  • Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.





Это только самые первые вещи, которые приходят на ум, когда мы говорим о повторном использовании готового внешнего кода.



Что такое Slim и зачем его использовать?



Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.



Вот что нам нужно знать о Slim:




  • Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).

  • Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.

  • Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.





Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.



Что насчет Менеджера и ExtJS?



Если вы спросите случайную группу MODX-разработчиков об их самой любимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.



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



Но что же мы знаем?



Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.



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



Что дальше?



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



На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/259197/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<ядро - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda