• Автоопределение кодировки текста
    0

    попробуйте https://github.com/google/compact_enc_det, у нас неплохо для ласов работает =).


    А вообще эта задачка идеальна для нейросетей.

  • Панель корреляции на QtQML/Quick
    0

    для чего контрол написали: Widgets или QML/Quick?

  • Панель корреляции на QtQML/Quick
    0

    личный опыт тоже для нефтянки? )

  • Панель корреляции на QtQML/Quick
    0

    сейчас прочитал и вспомнил — из-за перечисленных там ограничений и не взяли.


    в статье я среди плюсов упоминаю, что кривые можно мешать с контролами. Допустим нужен TextInput в слое определённого графика, но как ребёнок Scene — с этим велосипедом это возможно. Если соберёте самый первый черновой сэмпл graph — там на сцене как раз такая ситуация.


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


    Сразу ограничивать себя мы не стали.

  • Панель корреляции на QtQML/Quick
    0

    в списке возможных альтернатив у нас он мелькал, но если мне не изменяет память, он тоже рисует (или рисовал тогда) на CPU.

  • Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву…
    +3
    • team-lead, РОДЖИИ Европа
  • NASA объявило о новом полете на Луну
    0

    CMake засветился в ролике

  • Андрей Филиппенко из РАЕН изобрёл технологию дыхания в жидкости из фторуглерода
    +3
    я ожидал увидеть это в комментариях — youtu.be/9MdlyM7w8PM?t=34
  • Начинается тестирование российских SSL-сертификатов на сайте госуслуг
    0
  • Начинается тестирование российских SSL-сертификатов на сайте госуслуг
    –2
    я знаю, что заминусуете, но очень уж хочется высказать свою точку зрения.

    Во-первых, все, абсолютно все комментарии сведены к «долой ГэБню! Пора заводить трактор! Когда они пришли за мной...» и прочий эмоциональный выброс. Не надо так.

    Во-вторых, хоть кто-нибудь может объяснить, чем данные действия со стороны гос-ва плохи? Ведь от того, что в доверенных корневых сертификатах появится российский, остальные корневые не будут удалены, не перестанут работать и вообще, воображаемый МИТМ со стороны ФСБ не повлияет на каналы передачи, созданные с теми, «забугорными», сертификатами. Да, МИТМ это плохо; да, лично я не хочу, чтобы мои данные видели третьи люди, но, блин, два пункта: (1) только что описанное, что МИТМ с «русским» сертификатом на означает слива ВСЕГО потока данных с вашего компьютера, да и сеть не ограничивается лишь только рунетом и (2) а кто вам сказал (или даже гарантирует), что всякие там GoDaddy, DigiCert, Etcert не сливают данные? Ну вот кто? И что та же ФСБ у них не покупает слив.

    В-третьих да, я надеюсь, что Гугл и Мозила выкинут данный корневой, как только появятся подтверждения МИТМа.

    В целом новость грустная, конечно же, т.к. те же СберБанк Онлайны обяжут ставить российский сертификат, но есть и микроположительное. Много всяких гос. шараг со своими веб-сайтам (Госулуги в первую очередь), которые да, покупают сертификаты за бугром из наших налогов (ну ещё нефти/газа, да, но вроде как общее достояние).
  • Как Сбербанк Онлайн сливает данные пользователей
    0
    так ведь ещё и flash висит
  • 2038: остался всего 21 год
    –2

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


    Первое — это вопрос "откуда вообще проблема возникает"? Может она
    надумана? Нет, не надумана и виноваты в ней в первую очередь говнокодеры:
    в подавляющем большинстве объект типа time_t преобразуется в int/long
    и рассматривается как количество секунд, пройденных с начала эпохи. Почему
    же я, такой надменный, смею называть этих лапшаделов негативным словом?
    Просто в силу того, что в документации сказано, что внутренее строение
    типа time_t
    не задано! [http://en.cppreference.com/w/c/chrono/time_t]
    Раз не задано, то и работать с ним напрямую нельзя, только
    с использованием специального API:


    1. time;
    2. localtime;
    3. gmtime;
    4. mktime;
    5. difftime — из-за чего, собственно, и преобразовывают к целому:
      чтобы вычислить период времени, измеряемый в секундах. Да, раньше 89/90го
      стандарта этой функции не было, но её возможно реализовать через
      предыдущие, но это же сложнее!

    Во вторую очередь — это само API является кривым. Даже если бы все
    работали с объектами time_t "правильно", то решить проблему 2038го года
    получилось бы костыльно:


    1. текущее АПИ предполагает, что объекты копируются по значению.
      Это мешает сделать простое using time_t = std::uint64_t;
    2. нет функций по созданию и удалению объектов типа time_t. Это
      означает, что при попытке сохранять в time_t индекс объекта в некой
      таблице, придётся либо выделить память процессу сразу под всё
      возможное их количество, либо выделять по мере необходимости — вызов
      mktime; и освобождать весь этот массив по завершении процесса.

    В-третьих, как должно выглядеть нормальное АПИ. Оно должно выглядеть
    также, как и CreateFile/CloseHandle из WinAPI:


    Заголовок спойлера
    /* да, для красоты можно и сказать, что есть некий тип, но
            его кишки вам смотреть запрещено!
    
            struct TimeType;
            using time_t = TimeType *;
        */
        using time_t = void *;
        const auto INVALID_TIMET_VALUE = /* ... */;
    
        time_t create_time(/* some arguments */);
    
        /* код ошибки - на всякий случай */
        int free_time(time_t time_);
    
        int mktime(struct tm * time_, time_t outTime_);
    
        /* sample */
        time_t currentTime = create_time(/* ... */);
        if (INVALID_TIMET_VALUE == currentTime)
        {
            fprintf(stderr, "create_time failed; errno = %d\n", errno);
            return;
        }
    
        const auto result = mktime(anotherTimeRepresentation, currentTime);
        if (0 != result)
        {
            fprintf(stderr, "mktime failed; errno = %d\n", errno);
            return;
        }
    
        /* работаем с currentTime */
    
        const auto freeResult = free_time(currentTime);

    И естественно, что эти функции должны быть экспортируемыми из
    разделяемой библиотеки (dll, so, dylib, etclib).
    Вот только при таком подходе замена нижележащей реализации не сломала
    бы текущие скомпилированные программы.


    Я понимаю, что всё это для user-space, однако и для ядрёных программ
    бы подошло, но тут возникают вопросы производительности. Также ещё
    можно подискутировать, сильным ли ограничением в ядре является 32х
    битность представления диапазона времени.


    А в-четвёртых — байка! Произошло это не непосредственно со мной, а
    с моим другом по работе и горело за соседним столом так, что аж я учуял.
    Понадобилось ребятам в json сериализовать время — то ли промежуток,
    то ли прямо метку времени, не сильно важно. Важно то, что диалог был
    примерно таким:


    • Предлагаем хранить время прямо в строком представлении.
    • А что, зачем, почему? Давайте прям time_t запишем, там же инт
      и количество секунд с бороды 1970х...
    • Лёша, как бы это implementation defined! 2038й год там, все дела...
    • Да пофигу, я к тому времени уже на пенсии буду.

    (На одной стороне передачи был C++-ный код, с другой — Java. Работало
    всё лишь только потому, что повезло.)
    Рукалицо в общем и занавес. Между собой мы всегда вспоминаем с улыбкой, но
    друг ещё добавляет: "Вот это не наши! Хоть бы в следующем обновлении
    студии/стандартной либы/етс изменили нижележащий тип и у них всё накрылось!
    Чтобы до конца пенсии поминали!!1 "


    Не знаю, серьёзно уж или нет, но ПО для торговли на бирже.

  • Трехмерная графика в вебе
    +1

    вот на примере буфера: https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteBuffer


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


    Конечно, если речь идёт о какой-нибудь демке, то там всё равно, вызывать дилит объектам или нет — при закрытии вкладки/обозревателя ОС всё подчистит — кстати также, как и при закрытии родного приложения.
    Однако для долгоиграющих приложений (игры, 2Д/3Д-редакторы графики, редакторы видео, ПО для моделирования) это должно учитываться. И выглядеть этот код будет один-в-один, как на C++. =)


    И для каждого GL-ного объекта такая пара методов есть:


    1. текстуры — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteTexture
    2. шейдеры — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteShader, https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteProgram
    3. буфер отображения — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteRenderbuffer
    4. буфер кадра — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteFramebuffer

    Развивая тему, хотелось бы отметить, что это не проблема JavaScript/WebGL в частности. Это вообще проблема сборщиков мусора — все думают, что они могут всё и ни за чем следить не нужно. Самое большое заблуждение! В общем случае приходится управлять ресурсами (память же — лишь частный её случай) и тут сборщики мусора никак не облегчают задачу, но даже мешают.

  • Трехмерная графика в вебе
    +1
    не требует установки специализированных расширений или библиотек


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

    втоматическое управление памятью. В отличие от OpenGL, в WebGL не надо выполнять специальные действия для выделения и очистки памяти.


    если прошлое замечание больше похоже на придирку, то в этом случае всё серьёзно — это уже откровенная ложь. Лучше уберите этот пункт. Все данные, которые будут отображаться с помощью WebGL выделяются в памяти видеокарты. Соответственно, их также надо вручную освобождать, никакой сборщик мусора не поможет.
  • В логове Белого Дракона
    +1
    и поэтому нужны такие люди, как популяризаторы науки. В качестве примера — Я. И. Перельман, чьи «Занимательная Х» оказали на меня лично большое влияние.

    В идеале — каждый учёный должен быть одновременно и популяризатором, но, видимо, не каждому дано, а может быть не каждый и хочет.
  • Запускаем Yocto Linux на виртуальной машине
    0
    да
  • man!( C => D )
    0
    отличная шпаргалка!
  • Да, я пишу десктопные приложения под Windows
    +8
    Здравствуйте, меня зовут Георгий, я тоже разработчик десктопных приложений под Windows… Мак и Линукс и я шлю Вам лучи добра и поддержки! :)
  • Мотивирующая сказка для инди разработчиков игр
    0
    Простите меня конечно, но я не понял, как в неё играть =)

    Может быть есть видео игрового процесса?
  • Передача сохраненных аргументов в функцию
    –1
    ещё один вариант — Parameter Object design pattern.

    У данного подхода большой плюс — не зависит от языка программирования.
  • Почему индийский аутсортинг обречен
    +20
    Многопоточный и потокобезопасный?
  • Интернет-дроны от Facebook размером с Boeing 747 будут находиться в воздухе месяцами
    0
    атомолёты?
  • Почему Skype заставляет нас всех обновлять ПО?
    0
    Slackware64
    skype 4.2.0.11, был загружен со skype.com

    изменение версии на 4.3.х.х помогло
  • Почему Ваза утонул, а С++ всё ещё на плаву
    +3
    С++, и Си, НЕСТРОГО типизируемые языки, в всего лишь со статической типизацией — habrahabr.ru/post/161205/. Вот это и грустно (
  • Безопасность магазина в рознице: основные атаки
    +1
    Господа, платите картами.
  • Вышел Skype 4.3 для Linux
    0
    Мне это не нужно.

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

    Проигрыватель (использую VLC) крутит свою громкость, не затрагивая других. Мне этого более, чем достаточно.
  • Вышел Skype 4.3 для Linux
    0
    лично мне, как пользователю, он не нравится потому, что не добавляет ничего нового по сравнению с алсой.

    Кроме того, в слаке 14.0 пульсы нет (ну либо я не заметил).
  • Вышел Skype 4.3 для Linux
    +2
    +1

    Добавить больше нечего. Печаль-тоска (
    Обновлять не буду.
  • Reverse-инжиниринг Caesar III (часть 2, Рисование города)
    0
    А тайлы? Они ведь тоже должны меняться.

    Я спрашиваю потому, что в статье не нашёл упоминания о том, что текстуры объектов есть для разных ракурсов. Возможно пропустил.
  • Reverse-инжиниринг Caesar III (часть 2, Рисование города)
    0
    Я предполагаю, что оно может решить две проблемы:
    1) сортировка тайлов. Если всю карту загнать в квад-дерево, то потом меняя порядок отрисовки детишек изменится сортировка тайлов.

    Поясню на примере. Возьмём картинку из статьи
    image

    Пусть на глазок дерево будет построено так, как прочерчены красные линии (для корневого элемента), и для top-left ребёнка — как зелёные.

    Тогда следующий псевдокод отрисовки:
    void QuadTree::render()
    {
        mTopLeft->render();
        // порядок следующих двух строк не важен
        mTopRight->render();
        mBottomLeft->render();
        mBottomRight->render();
    }
    


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

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

    2) эффективное удаление скрытых объектов. Думаю, тут и так понятно.

    Кстати, в связи с этим вспомнил одну вещь. В меню справа есть же стрелочки под картой? Они ведь поворачивают карту? Реализована ли подобная функциональность в римейке? Если да — то каким образом?
  • Reverse-инжиниринг Caesar III (часть 2, Рисование города)
    0
    используется ли Quad-дерево для отображения карты?
  • Сравнение Rust и С++ на примерах
    0
    После того, как Мейерс выступил на ДиКонф 2014, появилась вот такая интерпретация его выступления:
    he-the-great.livejournal.com/52333.html
  • Про компоновку, dependency hell и обратную совместимость
    0
    Т.е. все намного проще и удобнее, чем в других ОС, на самом деле.

    С этим согласен полностью.

    К manifest«ам это не относится. Пока писал статью, я понял, что в Windows изначально был механизм (который Вы описали и который является two-level namespace по сути), чтобы не допустить dependency hell: мы бы имели в папке system32, к примеру, два файла comctl32-5.0.2.dll и comctl32-6.3.1.dll. Почему инженеры из Microsoft не сделали этого изначально? Я не знаю.

    Лично мне механизм с манифестами кажется избыточным.
  • Про компоновку, dependency hell и обратную совместимость
    0
    случайно отправил комментарий.

    Теперь, при сборке самой version.dll будет использован version.script для символов vesion::list<version::window> внутри самой библиотеки. liba и другие при компиляции не получат тело шаблона version::list, что заставит компоновщик требовать его при связывании. Таким образом, все получат в зависимостях версионированный шаблонный класс. Эта техника разделения шаблона описана тут: http://www.parashift.com/c++-faq/templates-defn-vs-decl.html.

    Начиная с Си++11 можно заставить компилятор не инстанцировать шаблон даже для хедер-онли шаблонов с помощью extern. Например, для std::unique_ptr:
    // MyTypePtr.hpp
    #include <memory>
    
    namespace mylib
    {
    
    class MyType;
    
    } // namespace mylib
    
    extern template class std::unique_ptr<mylib::MyType>;
    
    namespace mylib
    {
    
    using MyTypePtr = std::unique_ptr<mylib::MyType>;
    
    } // namespace mylib
    
    
    // MyTypePtr.cpp
    
    #include "MyTypePtr.hpp"
    
    #include "MyType.hpp"
    
    template class std::unique_ptr<mylib::MyType>;
    


    Такая техника позволит экспортировать даже классы, сгенеренные из хедер-онли шаблонов, и применить для этих классов version.script. Стоит отметить, что extern уже давно использовался как расширение Си++ в msvc: http://support.microsoft.com/kb/168958/en-us.

    К сожалению, с помощью extern не получится экспортировать контейнер перемещаемых объектов: http://stackoverflow.com/questions/22381685/extern-template-class-stdcontainer-of-movable-objects.

    Теперь вернёмся к первому случаю, когда экспортируются только шаблоны. Как видим, эти шаблоны должны быть грамотно оформлены )). С точки зрения version, это проблема других, как они используют эти шаблоны. Если высовывают их наружу – это первый случай, только с позиции уже другой либы. Если используют для внутренних нужд – то с помощью того же version.script они должны быть помечены как local.
  • Про компоновку, dependency hell и обратную совместимость
    0
    Вы задали очень хороший вопрос. Я сейчас пробежался по статье и, действительно, как-то упустил из виду Си++.

    Я думаю, что можно. Попробую аргументировать свою позицию.

    Есть несколько вариантов:
    1) version экспортирует только шаблоны, т.е. никаких сгенерированных классов наружу не торчит;
    2) version экспортирует шаблоны, а также некоторые классы, сгенерированные с помощью этих шаблонов.

    Сначала разберу второй случай. Проблема здесь заключается в том, что когда liba включит version-1.0.h
    // ...
    typedef version::list<version::window> windows_list;
    // ...
    

    к себе в исходный текст, то дальнейшее развитие событий зависит от того, как оформлен шаблон version::list. Если он – хедер-онли, то всё плохо:
    1) во-первых, в самой version.dll будет присутствовать сгенерировнный класс version::list<version::window>;
    2) когда будет компилироваться сама либа а, то в той единице трансляции, в которую был включен version.h, также будет сгенерирован класс version::list<version::window>. Он будет скомпилирован, в лучшем случае бинарно совместим с классом в version.dll, и все ссылки на него будут не undefined (что заставило бы загрузчик искать эти символы во время загрузки), а определены и указывать на сущности внутри а (в терминах nm – T либо t).

    Даже если класс version::list<version::window> и был версионирован в version.dll, он окажется в непонятном состоянии в liba. (Тут, кстати, стоит отметить, что именно по этой причине некоторые люди используют AddRef/Release семантику для экспортируемых классов, а также, не экспортируют stl-классы: нагенерреные классы внутри самой либе и её пользователе отличаются бинарно даже в случае Debug/Release )) ).

    Чтобы решить эту проблему для C++03 и выше, шаблон надо разделить на объявление и определение: version_list.h, version_list_impl.h. Внутри самой либы в файле реализации version_windows_list.cpp будет примерно так:
    #include "version_windows_list.hpp"
    
    // подключаем тело шаблона
    #include "version_list_impl.h"
    
    // явно инстанцируем шаблон
    template class version::list<version::window>;
    
  • Про компоновку, dependency hell и обратную совместимость
    +2
    +1. Этим вообще грешат многие: как сами разработчики либ, так и создатели различных ОС с ядром Линукс и другие.

    С Вашей подачи забью камень в огород гугла:
    $ objdump -x chrome|grep NEEDED|grep nss3
      NEEDED               libnss3.so
    $ ./chrome
    ./chrome: /usr/lib64/seamonkey/libnss3.so: version 'NSS_3.14.3' not found (required by ./chrome)
    $ objdump -x /usr/lib64/seamonkey/libnss3.so |grep SONAME
      SONAME               libnss3.so
    

    У меня slackware64-14.0. Я же просто скачал хром с сайта гугла (google-chrome-stable_current_amd64.deb), т.к. хромиум мне ой как не хотелось компилировать. Как видите, меня ждал сюрприз. Решить его я могу только с помощью LD_LIBRARY_PATH, устанавливая первыми пути с нужными библиотеками, т.к. R(UN)PATH тоже не был предусмотрен (в противном случае я бы просто прокинул нужные ссылки в заданное место):
    $ objdump -x chrome|egrep 'R(\|UN)PATH'
    $ 
    


    Ссылки вида libX.so → libX.x.y.z.so – это вообще анахронизм, т.к. нужны только компоновщику во время связывания, чтобы явно не писать имя файла библиотеки, а просто указать -lx. Новый gcc & ld умеет прямо компоновать с нужным файлом: -l:x.so.3.2.1. Разве что на Маке я не нашёл такой возможности. (Дурацкий префикс 'lib' тоже не нужен).

    Это – пол беды. Задавать SONAME тоже никто не хочет (посмотрите выше на nss3 в слакваре): т.е. даже если целевой файл будет скомпонован с нужной версией либы, в его зависимостях будет просто libx.so (см. выше вывод для хрома).

    Ещё хочу упомянуть про pkgconfig. Для nss3 на моей системе файлик выглядит так:
    prefix=/usr
    exec_prefix=${prefix}
    libdir=/usr/lib64
    includedir=${prefix}/include/nss
    
    Name: NSS
    Description: Network Security Services
    Version: 3.13.5
    Requires: nspr >= 4.9.1 sqlite3
    Libs: -L${libdir} -lnss3 -lsmime3 -lssl3 -lsoftokn3  -lnssutil3
    Cflags: -I${includedir}
    

    а называется он nss.pc. Если кто-то воспользуется услугами pkgconfig для nss3, то с какой версией ssl3, smime3, softokn3, nssutil3 будут скомпонованы библиотеки?