Возможно сильно не в теме, да и вопрос не совсем четкий.

А есть ли изложение функционального программирования «в духе Дьердя Пойа», как например в его «Математике и правдоподобных рассуждениях»?

В качестве примера такого изложения (правда пример тоже математический) - введение в теорию Галуа: http://arxiv.org/pdf/0804.4357

Начинается с простых ясных задач, которые просто доказываются на «школьном языке», но которые легко могут быть переформулированы на языке теории Галуа. Мне кажется - это идеальное объяснение. Интересно, есть ли подобное по ФП.

Впрочем, смотря что считать подобным. «High-order Perl» мне, например, очень нравится, но я это считаю другим способом изложения. Хотя какие-то моменты, безусловно, похожи.

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

Каждый пользователь Qt очень часто в своей жизни сталкивается с подобным кодом:

int main( int argc, char** argv)
{
    QApplication app( argc, argv);
    int result = app.exec();
    return result;
}

Этот тривиальный пример стал настолько близким и родным каждому, кто пишет код на C++/Qt, что вопросов по его работе не возникает ни у кого. Но давайте попробуем окунуться немного глубже и рассмотрим вот такой пример:

QApplication* createApplication( int argc, char** argv)
{
    QApplication* result = new QApplication( argc, argv);
    return result;
}

int main( int argc, char** argv)
{
    QApplication* app = createApplication( argc, argv);
    int result = app->exec();
    delete app;
    return result;
}

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

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

Итак, ждем нашего победителя.

---

Наш победитель: slovazap

Осторожно, ниже в треде есть ответы. Если вы хотите сами найти решение - не читайте тред до конца.

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

http://libcello.org

Для Ъ, пример кода на сишечке:

/* Another Example Cello Program */

#include "Cello.h"

int main(int argc, char** argv) {

  /* Tables require "Eq" and "Hash" on key type */
  var prices = new(Table, String, Int);
  put(prices, $(String, "Apple"),  $(Int, 12)); 
  put(prices, $(String, "Banana"), $(Int,  6)); 
  put(prices, $(String, "Pear"),   $(Int, 55));

  /* Tables also supports iteration */
  foreach (key in prices) {
    var price = get(prices, key);
    print("Price of %$ is %$\n", key, price);
  }

  /* "with" automatically closes file at end of scope. */
  with (file in open($(File, NULL), "prices.bin", "wb")) {

    /* First class function object */
    lambda(write_pair, args) {

      /* Run time type-checking with "cast" */
      var key = cast(at(args, 0), String);
      var val = cast(get(prices, key), Int);

      try {
        print_to(file, 0, "%$ :: %$\n", key, val);
      } catch (e in IOError) {
        println("Could not write to file - got %$", e);
      }

      return None;
    };

    /* Higher order functions */
    map(prices, write_pair);
  }

  delete(prices);
}

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

Что получает мой наниматель:
1. 4 часа рабочего времени в день
2. большой опыт написания проектов на С++/Qt
3. опыт работы с системами контроля версий
4. опыт разработки кроссплатформенных проектов (Win/Lin/Mac)
5. опыт разработки под различные мобильные ОС (Android, iOS, MeeGo)
6. OpenGL/OGLES, но это вряд ли будет кому-нибудь интересно

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

Чего хочется мне:
1. заработать денег
2. расширить свой профессиональный опыт (интересуют проекты с активным использованием stl и/или boost)
3. познакомиться с другими профессионалами

Связаться со мной можно по почте txgames <на> yandex.ru
Так же я доступен в джаббере (см. профиль).

На личные сообщения на сайте по понятным причинам не отвечаю.

P.S. Готов обсудить реализацию проектов на ObjC/Java.

P.P.S. Если у вас есть проект, который вы хотите быстро и успешно завершить - просто напишите письмо с темой «4 часа» на адрес txgames <на> yandex.ru
Это будет верный шаг к вашему грандиозному успеху!

P.P.P.S. Работодатели из города-героя Ленинграда и ближайших окресностей кроме все прочего получают уникальную возможность познакомится со мной лично.

Посоветуйте легкую либу для парсинга XML. Требования:

• 1. ООП интерфейс (либа на плюсах)
• 2. Переносимость (Windows, BSD, Mac, Linux)
• 3. Желательно чтобы была достаточно популярна (в идеале в большинстве дистров)
• 4. Как можно меньше зависимостей, т.к. будет использоваться в очень легкой негуевой проге.

Запилил тут сервачок с eJabberd и ищу для него web междумордие. Потому как хочется чтобы народ из рабочей локалки (локалка через vpn) общался с начальством не покидая любимый браузер. Кто и что может подсказать? От междумордия требуется адекватность и функционал не менее Psi. Про голосовую связь я скромно промолчу, но чат и прочие плюшки должны работать.

https://github.com/i-rinat/libvdpau-va-gl/releases

В двух словах, это VDPAU драйвер, который использует OpenGL для рисования и VA-API для декодирования видео.

VDPAU это открытый интерфейс, который подразумевает единую точку входа (libvdpau) и подключаемые драйверы; API не замкнуто накоротко на nVidia. Выбор конкретного драйвера осуществляется либо через переменную окружения VDPAU_DRIVER, либо спрашивается у X-сервера. Если так или иначе получить имя не удалось, считается, что оно есть «nvidia». Драйвер представляет собой разделяемую библиотеку с именем вида libvdpau_<drivername>.so.1. Программы линкуются с libvdpau, а она в свою очередь загружает нужный драйвер.

Чтобы использовать, нужно собрать, положить библиотеку в директорию, где её сможет найти компоновщик, и добавить в окружение переменную VDPAU_DRIVER=va_gl. Проверить, что драйвер работает, можно запустив vdpauinfo. А vainfo покажет, работает ли драйвер VA-API.

На видеокартах AMD по чудаковатым причинам происходят падения внутри XCloseDisplay. Чтобы обойти проблему, нужно в переменную VDPAU_QUIRKS добавить строку XCloseDisplay. Элементы в VDPAU_QUIRKS перечисляются через запятую, слитно, без пробелов и служат для тонкой настройки поведения драйвера. Кроме XCloseDisplay, есть ещё параметр ShowWatermark, включающий отображение строки va_gl в правом нижнем углу. Полный список можно найти в README.md.

Начиная с версии 2.99.908 xf86-video-intel сообщает переходнику libvdpau.so имя VDPAU драйвера. Символьных ссылок
libvdpau_i965.so.1 → libvdpau_va_gl.so.1
libvdpau_i915.so.1 → libvdpau_va_gl.so.1
достаточно для загрузки, и необходимости в использовании VDPAU_DRIVER больше нет.

Я просто решил оставить тут несколько фактов о принципах работы wayland и их применимости на android.

И прежде всего я обращаю внимание на тот факт, что ровно две конторы решили сделать мобильные ОС поверх драйверов android: Canonical и Mozilla. Обе перед этим разрабатывали софт под андроид, ubuntu for android и firefox for android соответственно. В ходе разработки они столкнулись с одними и теми же проблемами и интересными решениями от команды разработчиков из Google. Разумность этих решений и побудила их к тому, что они делают.

Часть I, или wayland — не дисплейный сервер

Wayland — название протокола, описанного в XML файле. Из файла генерируется документация к протоколу и код на C, позволяющий общаться посредством этого протокола (libwayland). Если кто-то из разработчиков вейланда говорит вам, что «в вейланде явно не специфицируется то-то и то-то», его слова следует просто игнорировать: протокол-то не специфицирует, но реализация у него была и есть одна — weston — а он как раз специфицирует многие вещи; кроме того, попробуйте-ка заставить авторов тулкитов и mesa вот так взять и добавить поддержку особенностей альтернативной реализации протокола wayland (а таковой в будущем мог бы стать даже mir). С вас шкуру спустят, за то что опять фрагментируете бедное комьюнити своими забагованными альтернативными реализациями.

Часть II, pixmap <-> texture

На многих устройствах с android стоит относительно слабый процессор, и даже его мощность следует максимально беречь из-за батарейки (например, один из смартфонов самсунга имеет два ядра на 1,3 и 1,9 ГГц, но в нормальном режиме работает только слабое ядро), ОЗУ надо беречь из-за батарейки. Также на устройствах есть интеграшка вместо видеокарты и большой экран (у Samsung S3 он больше, чем у iPad без ретины). Увеличение размера экрана в n раз увеличивает число пикселей в n² раз. Как мы все уже знаем, современные тулкиты рисуют готовую картинку и отправляют её серверу, но делать это можно четырьмя способами

1. Выделять места в памяти, рисовать там картинки, отправлять серверу. Это всегда даёт оверхед на ОЗУ, даёт оверхед на передачу данных по шине для дискретных видеокарт и оверхед на копирование памяти для интеграшек. OpenGL использовать нельзя, аппаратного ускорения нет. В начале своего пути Wayland умел только так.
2. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, забирать оттуда пиксели с помощью glReadPixels, а потом способ №1; про его оверхед уже сказано. Хотите я вас обрадую? У драйверов android есть баги, например, на видеокартах Qualcomm иногда пиксели из фреймбуфера читаются некорректно, потому что они оптимизировали вывод графики и потребление ресурсов с помощью тайлинга (разбиения фреймбуфера на квадраты 16x16, которые обрабатываются отдельно) и теперь не гарантируют, что весь фреймбуфер целиком может быть нормально разобран на пиксели. Отдельные баги, может быть, исправлены в android 4.2, но кто исправит их в android 4.1, на котором и основан cyanogen mode? Конкретные проблемы и сопутствующий оверхед можно пофиксить путём использования способа №4.
3. Выделять OpenGL framebuffer, рисовать туда командами OpenGL, отдавать дисплейному серверу. Используется в weston и mir. Кстати, в обоих случаях используется библиотека EGL, которая выступает связующим звеном между объектами OpenGL/OpenGLES/OpenVG и знакомыми всем программистам понятиями из мира программной отрисовки, такими как pixmap, surface, и так далее. В обоих случаях надо попросить weston или mir создать окно, потом попросить libEGL о создании EGLSurface из полученного окна, а дальше уже средствами чистого EGL создать контекст OpenGL и другие ништяки. Недостаток — невозможность использовать частично программную отрисовку, всё только через GPU.
4. В реальных устройствах на андроиде все карты — интеграшки, и выделенной памяти у них нет. Просим у драйвера видеокарты область оперативной памяти в виде EGLImage (у EGL для android есть такое нестандартное расширение), связываем его с текстурой либо фреймбуфером, рисуем в картинку софтварно и/или через OpenGL и используем дальше как текстуру. Это — идеал, именно он используется внутри андроида, но недоступен прямо через NDK или java: [1], [2], [3]. Нулевой оверхед на копирование, нулевой оверхед на ОЗУ. Поддерживают ли этот способ тулкиты на вейланде? Поддерживает ли его Weston? Зато есть заявления о работоспособности Weston под android и непонимание, зачем нужен Mir.

Впрочем, замечу, что Jolla пытается накостылить поддержку способа №4 в Weston [4].

Часть III, server allocated buffers

Wayland нам абсолютно неинтересен. Смотреть надо на Weston, и он действует так: клиент просит у видеодрайвера буфер, рисует в него что-то, а затем передаёт этот буфер и время, когда он был отрисован, для Weston через протокол Wayland с просьбой нарисовать. В Mir сделано иначе: клиент просит у Mir буфер, затем пишет в него что-то, затем просит другой буфер и одновременно передаёт имеющийся буфер для отображения на экране. Клиент работает через библиотеку mir-toolkit и не зависит от того, какие именно данные идут от него по сокету.

Преимущество подхода mir в том, что mir может воровать буферы у неактивных приложений и тем самым давать огромную экономию памяти [5]. Именно так сейчас поступает android, и, насколько известно, ios [6] [7].

Часть IV, ввод

Акселерометры, множественные касания, виртуальная клавиатура и аппаратная клавиатура, геймпады, датчики роботов — всё это уже сейчас работает в android. Mir просто взял эту часть гугловского surface flinger и перенёс к себе, отделив его от остального кода и подключив boost, добавил трансляцию в API Mir. Трансляция прямая, например, тип события мыши или касания напрямую кастуется в соответствующий enum из библиотеки mir-toolkit, и дальше передаётся клиенту (и тут же поправлюсь: 4 июля 2013 года кастования типа убрали для ещё большей совместимости с android, потому что иногда приходящее от Surface Flinger значение не укладывается в enum). Как результат, Mir поддерживает абсолютно все фичи ввода, доступные андроиду.

Тем временем в Weston всё ещё продумывают каждую мелкую деталь событий ввода в протоколе wayland. Это прекрасная работа и отличный задел на будущее, но полноценной обработки ввода на weston под android не будет в ближайшие 5-10 лет. Но тут есть выход: если в дисплейный сервер Mir будет добавлена поддержка протокола wayland, то он сможет транслировать события ввода андроида в протокол wayland и потребует для этого гораздо меньше отладки, чем Weston, потому что код mir уже покрыт тестами и может хостить Qt-шные приложения для андроида неотличимо от Surface Flinger.

Часть V, client-side decorations

Каждый тулкит рисует client-side decorations по-своему. Ниже будет список нюансов CSD, для которых должна быть поддержка со стороны каждого из тулкитов — и это очень грустная ситуация, потому что число тулкитов, способных написать и отладить весь этот код со всеми нюансами, резко сокращается. Уже сейчас только Qt5, gtk3 и EFL более-менее поддерживают последние решения вейланда. Итак, нюансы:

• Wayland не заставляет использовать клиент-серверные декорации, но мы уже знаем, что надо смотреть на Weston. Weston в общем и в целом заставляет, если не считать инициативу мейнтейнера kwin.
• Для тайлинга, полноэкранных окон и окон на пол-экрана CSD надо частично отключить. Wayland в лице его основателя предлагает [8] давать окнам подсказки, какие именно стороны окна должны быть без декораций. Кстати, именно так kwin может добиться серверных декораций — просто отключив CSD для всех четырёх сторон окна. На андроиде CSD не нужны, как и на любых устройствах с маленьким физическим размером экрана.
• Заголовок окна не рисуется для развёрнутых на весь экран окон в Unity, KDE Plasma Netbook [9] и, насколько я знаю, в GNOME. Wayland никак об этом не сообщает, но можно использовать тот же механизм, что для глобального меню.
• Порт Qt на wayland получает оверхед из-за CSD, и поэтому в Qt оставлен флаг для отключения CSD. Скорее всего, у других тулкитов будут те же трудности. Тем более CSD создают очевидный оверхед по оперативной памяти из-за того, что каждое приложение само собирает и хранит в памяти копию всей графики (растровой или векторной), необходимой для декораций.

Напоследок процитирую слова Мартина Грэсслина:

Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

GNOME уже не раз убирал из своих приложений и из GTK фичи, непосредственно нужные другим DE. Например, автора Transmission попросили выкинуть что-то из уведомлений [10], причём багу присвоен тип «Улучшение» ☺. Дальше диалог развивался так:

Removing it altogether, as you suggest, will hurt XFCE users. I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.

Ответ:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

Никогда у вас не будет нормальных клиентских декораций в официальном GTK 3. Забудьте об этом. Могут помочь те, кто патчит GTK в своём дистрибутиве — но пока конкретно этот тулкит более-менее патчит только Canonical.

Не хочет работать bluetoth в ubuntu 12.10 x64. lspci | egrep 'Ather' Atheros Communications Inc. AR9462 Wireless Network Adapter (rev 01) dmesg | egrep 'ath3|ar3|Bluet' [ 11.801597] Bluetooth: Core ver 2.16 [ 11.801619] Bluetooth: HCI device and connection manager initialized [ 11.801621] Bluetooth: HCI socket layer initialized [ 11.801623] Bluetooth: L2CAP socket layer initialized [ 11.801629] Bluetooth: SCO socket layer initialized [ 14.349464] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 14.349469] Bluetooth: BNEP filters: protocol multicast [ 14.350876] Bluetooth: RFCOMM TTY layer initialized [ 14.350882] Bluetooth: RFCOMM socket layer initialized [ 14.350884] Bluetooth: RFCOMM ver 1.11 [ 68.635492] usbcore: registered new interface driver ath3k

не хочет находить другие устройства по bluetooth

Подскажите философа/философов размышлявших о следующей идее:

«Любовь создает семью, страх формирует общество»

Здравствуйте.

Подскажите, пожалуйста, какой-нибудь аналог почившего Яндекс.Склонятор или библиотеку (желательно на cpp) для склонения русских имён собственных (фамилии, имени, отчества).

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

Привет. Есть вот такая вот связка:

-----------------------------      socket          ---------                  ----------
| shared library (API)      |  < ---------- >     | daemon |      < --- >     | device |
-----------------------------                      ---------                  ----------

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

Мне пока видится несколько варинтов:

• Использовать конфигурационный файл для демона и запускать по треду на устройство.
• Вообще отказаться от демона (не сильно представляю его нужность), поскольку демон чисто дополнительная прослойка между API и устройством, и интегрировать часть для общения с устройством в библиотеку. (upd. как я понял, преимущество демона будет видно, когда несколько приложений будут обращаться к одному устройству)
• Как-то ещё?

Спасибо.

Есть сервак во внутренней сети. Сеть с интернетами не связани и связана никогда не будет (требования безопасности).

Как обеспечить точное время на сервере? Желательно не особенно дорогим способом.

Сейчас в качестве возможного решения проблемы рассматриваю использования GPS/GLONASS приемника.

http://i43.tinypic.com/5arsm1.png

Это намек?

Доброе время суток.

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

Это возможно или мне сразу вешаться?

Есть интерфейс плагина, например:

class Embeddable
{
public:
    enum { TypeA, TypeB, TypeC };

    virtual void embed() = 0;
};

Если в будущем я добавлю новые энумераторы в enum, то сломается ли ABI данного класса? И если сломается, то единственный выход - это сделать сейчас

enum { TypeA, TypeB, TypeC, Reserved1, Reserved2, Reserved3 };

?

Доброго времени суток! Необходимо разработать небольшое приложение на Qt, которое бы отображало данные из Open Street Map. Установил себе PostgreSQL, установил расширение postgis для работы с OSM. С помощью imposm переконвертировал OSM в Postgre-БД. Все работает. Проблема встала с получением этих данных. Таблицы дорог, городов, рек содержат поле geomerty вида «010200002031BF0D00340000004BB16D3........DF0F7B45C41». Не совсем понятно, как извлекать из этого точки, линии, окружности.

Может кто уже сталкивался с подобной проблемой?

Огромное спасибо!

Привет.
Кто что юзает\юзал\знает из хороших обверток для андроида и айос над sqlite3, т.е. «это что-то» должно быть на С++.
Нашел только что https://github.com/pmed/sqlitepp, но пока не пробовал.
Спасибо.