Не так давно компания Нвидиа включила в свой драйвер поддержку прайм. https://download.nvidia.com/XFree86/Linux-x86_64/435.21/README/primerenderoff... https://wiki.archlinux.org/index.php/NVIDIA_Optimus_(Русский) По этому поводу, что у меня получилось и некоторые вопросы, я снял видос: https://www.youtube.com/watch?v=rjh8VeVbo7Y&t=225s Хочу отметить сразу, тестирую и сейчас, прирост производительности в играх и нет ТИРИНГА! Протестировал, настроил всё это дело в Арч Линукс.

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

#include <iostream>

using namespace std;

class A {
    int i_ = 555;

    friend void f0(A& a) { 
        cout << a.i_ << endl; 
    }

    friend void f1() {
        A a;
        cout << a.i_ << endl;
    }
};

// Если не указать эту строку, 
// то дальнейший вызов f1() не удастся
void f1();

int main() {
    A a;

    f0(a);

    // Здесь будет ошибка, если выше
    // нет объявления f1() вне класса
    f1();  

    return 0;
}

void f(Matrix& m) {
    invert(m); // invert() - друг класса Matrix
}

namespace Chrono {
    class Date{ /*...*/};
    boot operator==(const Date&, const std::string&);
    std::string format(const Date&); // выдать строковое представление
    // ...
}

void f(Chrono::Date d, int i) {
    std::string s = format(d); // Chrono::format()
    std::string t = format(i); // error: нет format() в области видимости
}

Думаю многие кто пользуется KDE читали темы о том как KDE дергает (гуглить по запросу kde flickering). Можно даже ролики на youtube посмотреть.

Одно из решений проблемы мерцания это включение в настройках Display and Monitor > Compositor > Xrandr вместо OpenGL. Но тогда начнется tearing (разрывы изображения при быстрой смене картинок). Это потому что в OpenGL вертикальная синхронизация (VSync) убирала этот тиринг.

Решение проблемы tearing при Xrandr это включение Tear Free технологии видеокарт. По умолчанию в Ubuntu (Kubuntu в этом случае) она отключена. Включается правкой Xorg.conf файла.

Как вариант вместо правки Xorg.conf можно создать отдельные файлы /etc/X11/xorg.conf.d/20-intel.conf для intel или /etc/X11/xorg.conf.d/20-radeon.conf для AMD (radeon драйвер, для дрйвера amdgpu файл другой).

Содержание файл настроек 20-intel.conf:

Section "Device"
 Identifier  "Intel Graphics"
 Driver      "intel"
 Option      "AccelMethod"  "sna"
 Option      "TearFree"    "true"
EndSection

Полный список «скрытых» опций видео драйверов: для intel и для amd и для amd (amdgpu)

Тут начинается другая проблема KDE не видит дискретную видеокарту, если в файле Xorg.conf есть какие-то опции для интегрированной видеокарты. Это связано с особенностями инициализации оборудования. Чтобы дискретную видеокарту система стала использовать нужно помимо настроек TearFree для интегрированной видеокарты вручную дописать настройки для дискретной (файл /etc/X11/xorg.conf.d/20-radeon.conf):

Section "Device"
 Identifier "Radeon"
 Driver "radeon"
 Option "DRI" "3"
EndSection

Мы подошли к сути, причине. Долгое время я думал, что такие мерцания случайны. Потому что они проявлялись не всегда. И вот я наконец понял в чем причина конкретно у меня. При установке Steam он устанавливает x32 (32 битную) версию mesa драйвера. И вот после этого начинаются все проблемы. Причем даже после установки x32 mesa драйвера такие мерцания проявляются не всегда (поэтому и не было понятно, что виноват он). Уверенности в том, что причина в драйвере, а не в том что Steam делает что-то еще у меня нет. Но в том, что виноват Steam я уверен.

Кто хочет эксперементов с включение TearFree можете почитать вики archlinux.

Это больше информативное сообщение. Я очень долго искал информацию по решению проблемы в англ. сегменте, никакого решения для intel + amd не нашел. Но если кто-то что-то знает, то я был бы благодарен, если напишите совет.

Выложил на сайт бета-версию поддержки разметки Markdown.

Пока что она доступна только модераторам пользователям с 5 звездами и корректорам; после будет доступна более широкому кругу пользователей.

Работает вся стандартная разметка, за исключением вставки картинок. По аналогии с lorcode параграфы текста отделяются друг от друга пустой строкой, одиночные переводы строк игнорируются.

Кроме стандартной разметки должны работать блоки кода как на github, ссылки на пользователей вида @ maxcom (maxcom) и таблицы. Внешний вид таблиц будет поправлен, пока они выводятся без рамок и отступов.

Да, спасибо bvn13 за идею и merge request, на базе которого была сделана реализация.

Обновление 19 декабря: изменена верстка упоминаний пользователя; добавлена возможность выбирать режим в настройках

Обновление 21 декабря: markdown доступен пользователям с 5* и корректорам.

Обновление 25 декабря: поправлена верстка блоков кода, добавилен typography extension и markdown доступен пользователям с 4*.

Обновление 6 января: добавлен аналог [cut] и markdown доступен пользователям с 3*.

Обновление 10 января: добавлена справка по разметке.

Обновление 14 января: добавлены отступы и рамки у таблиц.

Обновление 17 января: markdown доступен пользователям с 2*.

Обновление 22 января: markdown доступен пользователям с 1*.

Обновление 30 января: markdown доступен пользователям с score >= 50.

Обновление 11 февраля: markdown доступен всем

Только начинаю с с++. Написал скрипт в Qt начал запускать отладку и тут выходит две проблемы:

19:55:06: Выполняются этапы для проекта modulinter... 19:55:06: Настройки не изменились, этап qmake пропускается. 19:55:06: Запускается: «/usr/bin/make» g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../Qt/5.12.0/gcc_64/include -I../../Qt/5.12.0/gcc_64/include/QtWidgets -I../../Qt/5.12.0/gcc_64/include/QtGui -I../../Qt/5.12.0/gcc_64/include/QtCore -I. -isystem /usr/include/libdrm -I. -I../../Qt/5.12.0/gcc_64/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-rpath,/home/egor/Qt/5.12.0/gcc_64/lib -o modulinter main.o mainwindow.o moc_mainwindow.o -L/home/egor/Qt/5.12.0/gcc_64/lib -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread /usr/bin/ld: cannot find -lGL Makefile:261: recipe for target 'modulinter' failed collect2: error: ld returned 1 exit status make: *** [modulinter] Error 1 19:55:10: Процесс «/usr/bin/make» завершился с кодом 2. Ошибка при сборке/установке проекта modulinter (комплект: Desktop Qt 5.12.0 GCC 64bit) Во время выполнения этапа «Сборка» 19:55:10: Прошло времени: 00:04.

и это

19:55:06: Выполняются этапы для проекта modulinter... 19:55:06: Настройки не изменились, этап qmake пропускается. 19:55:06: Запускается: «/usr/bin/make» g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../Qt/5.12.0/gcc_64/include -I../../Qt/5.12.0/gcc_64/include/QtWidgets -I../../Qt/5.12.0/gcc_64/include/QtGui -I../../Qt/5.12.0/gcc_64/include/QtCore -I. -isystem /usr/include/libdrm -I. -I../../Qt/5.12.0/gcc_64/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-rpath,/home/egor/Qt/5.12.0/gcc_64/lib -o modulinter main.o mainwindow.o moc_mainwindow.o -L/home/egor/Qt/5.12.0/gcc_64/lib -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread /usr/bin/ld: cannot find -lGL Makefile:261: recipe for target 'modulinter' failed collect2: error: ld returned 1 exit status make: *** [modulinter] Error 1 19:55:10: Процесс «/usr/bin/make» завершился с кодом 2. Ошибка при сборке/установке проекта modulinter (комплект: Desktop Qt 5.12.0 GCC 64bit) Во время выполнения этапа «Сборка» 19:55:10: Прошло времени: 00:04.

Привет. Так вышло, что пришлось основательно разобраться в теме и пока память свежа изложил всё в виде небольшой памятки. Удобно по прошествии некоторого времени освежить память прочитав небольшой конспект. Вообще, по-хорошему, блог что ли какой завести )). Просьба - не флудить, ссылки/комментарии/дополнения по теме приветствуются. ЗЫ: подразумевается, что либы -fpic

1. Утилиты readelf, objdump. Читать man elf, man ld.so. N в именах структор
   подразумевает 32 или 64.
2. Структура ELF файла:
   1. заголовок (смещение 0, struct ElfN_Ehdr). Readelf::ELF Header
   2. program header table (массив struct ElfN_Phdr). Содержит информацию о том
      как отображать секции в память процесса. Readelf::Program Headers
   3. section header table (массив struct ElfN_Shdr). Readelf::Section Headers
3. link_map   
3.1. Загруженные в память модули попадают в список (массив) из struct link_map.
     Списков может быть много, каждый список - "пространство имён". Для
     загрузки модулей в неглобальный список (создание нового) используется
     dlmopen().
3.1. Получать link_map модуля через dlinfo() или dladdr1():
     [--code--]
     #define _GNU_SOURCE
     #include <link.h>
     #include <dlfcn.h>
     #include <stdio.h>
     int main()
     {
        static char addr_in_mod;
        Dl_info __info;
        struct link_map *lm;
        if(dladdr1(&addr_in_mod, &__info, (void*)&lm, RTLD_DL_LINKMAP) != 0) {
           printf("link_map:\n");
           struct link_map *i = lm;
           for(; i->l_prev != NULL; i = i->l_prev);
           for (; i != NULL; i = i->l_next)
              printf("addr diff=%p  name=%s%s",(void*)i->l_addr,  i->l_name, i==lm?"  <--cur\n":"\n");
        }
     }
     //output:
     //link_map:
     //addr diff=0x41f000  name=  <--current module
     //addr diff=0xb7fc4000  name=linux-gate.so.1
     //addr diff=0xb7fa3000  name=/lib/libdl.so.2
     //addr diff=0xb7dc5000  name=/lib/libc.so.6
     //addr diff=0xb7fc6000  name=/lib/ld-linux.so.2
     [/--code--]
3.2. Во время переразмещений символ ищется в модулях указанных в link_map
     списке начиная от начала списка т.е. порядок важен, "gcc -ls1 -ls2"
     libs1.so находится в списке раньше, чем libs2.so.
3.3. При добавлении библиотеки через LD_PRELOAD, она попадает перед остальными
     разделяемыми библиотеками в глобальном link_map списке.
3.4. Опция RTLD_DEEPBIND для dlopen - собственные символы модуля приоритетнее
     символов из вышестоящих в link_map списке модулей.
     Собственные символы загружаемой библиотеки содержат:
      1. символы из самой загружаемой библиотеке
      2. символы из библиотек, которые были слинкованы с загружаемой из
         командной строки (у первых приоритет выше).
3.5. При загрузки через dlopen, библиотеки добавленные с флагом RTLD_GLOBAL
     имеют приоритет над RTLD_LOCAL, не смотря на то, что находятся в link_map
     списке позже (не относится к получению void f() через dlsym()). Например:
     [--code--]
     // предоставляет void f(), ссылается на void f().
     dlopen("lib1.so", RTLD_LOCAL);
     // предоставляет void f().
     dlopen("lib2.so", RTLD_GLOBAL);
     // при ленивом переразмещении, lib1.so будет ссылаться на lib2.so::f().
     [/--code--]
4. RTLD_GLOBAL - символы из загруженного модуля будут участвовать в
   переразмещениях для заргуженных в дальнейшем библиотек. RTLD_LOCAL - не будут.
   Если lib2.so линкуется с lib1.so через командную строку
   "gcc -fpic -shared -l2 s.c -o lib1.so", то видимость символов из lib2.so
   наследуется от видимости символов из lib1.so:
   [--code--]
   dlopen("./lib1.so", RTLD_LAZY|RTLD_GLOBAL);    // символы из lib2.so глобальные
   dlopen("./lib1.so", RTLD_LAZY|RTLD_LOCAL);     // символы из lib2.so локальные
   [/--code--]
   Если lib2.so подгружается из lib1.so через dlopen(), то видимость символов
   из lib2.so контролируется флагом dlopen() при загрузке lib2.so. Способ
   загрузки (через командную строку или dlopen) и флаг для dlopen при
   загрузки lib1.so значения не имеет.
5. Переразмещение (relocation).
5.1. Переразмещение - процесс соединения символьной ссылки с символьным
     определением.
     Переразмещение: ленивое - загрузчик вызывается при ссылке на символ, и
     ненеленивое - переразмещение при загрузке. Переразмещение переменных всегда
     неленивое.
5.2. Символы, требующие переразмещения, содержатся в .rel... секциях. В них
     находятся ElfN_Rel структуры.
     [--code--]
     typedef struct {
         Elf32_Addr r_offset;    \\ адрес внесения правки (адрес в GOT, например. readelf::Offset).
         uint32_t   r_info;      \\ содержит тип переразмещения и индекс в таблице символов (массив Elf32_Sym[]).
     } Elf32_Rel;
     typedef struct {
         uint32_t      st_name;   \\ индекс в таблице строк. Т.е. сопостовляет символ с Си строкой.
         Elf32_Addr    st_value;  \\ адрес символа в текущем модуле (readelf::Sym.Value).
         uint32_t      st_size;
         unsigned char st_info;
         unsigned char st_other;
         uint16_t      st_shndx;
     } Elf32_Sym;
     [/--code--]
5.3. Механизм обращения к переменным (требующим переразмещений):
     1. линкер на старте правит .got секцию, она начинает указывать на нужные
        данные.
     2. ссылка на переменную в коде (в .text секции):
          [--code--]
          call   44c <__x86.get_pc_thunk.ax>  # получаем в eax адрес следующей инструкции
          add    $0x1bcb,%eax                 # в eax адрес .got секции
          mov    0x14(%eax),%edx              # отступ от края .got на адрес переменной,
                                              # разыменовываем в edx
          [/--code--]
5.4. Механизм обращения к функциям, для пример - exfn():
     1. ссылка на exfn() в коде (в .text секции)
     2. переход на "трамплин" в .plt секции - plt@exfn()
     3. переход на разыменованный указатель из .got.plt, если переразмещение
        уже было произведено, то попадаем на exfn(), иначе:
        3.1. возврат в plt@exfn(), в стек кладётся смещение в .rel.plt
             секции Elf32_Rel структуры и указатель на link_map список
        3.2. вызов ld.so, правится указатель в .got.plt
        3.3. переход на exfn().
6. .dynamic секция может быть прочитана из программы через массив _DYNAMIC[],
   который содержит struct ElfN_Dyn, автоматически заполняется линкером.
7. Экспортируемые символы из elf модуля указываются в .dynsym секции.
8. -rdynamic опция линкера (для исполняемого ELF) - символы из exe, которые не
   были востребованы библиотеками, указанными в командной строке, не
   экспортируются (не указываются в .dynsym секции) и не участвуют в
   переразмещениях в библиотеках, которые подргружаются через dlopen. Данная
   опция заставляет линкер помещать в таблицу все функции.
9. Управление экспортом из модуля
   * Управление экспортом по умолчанию:
     gcc -fvisibility=default
     -fvisibility=hidden
     -fvisibility=internal
     -fvisibility=protected
   * Управление экспортом посимвольно:
     __attribute__ ((visibility ("hidden")));
     __attribute__ ((visibility ("hidden")))
   * Для группы:
     #pragma GCC visibility push(hidden)
     ...
     #pragma GCC visibility pop
   * static и анонимные namespace
   * Управление эспортом через export map, через опцию --version-script

Почему то на LORе еще не обсуждают

http://www.opennet.ru/opennews/art.shtml?num=48696

https://habr.com/post/413067/

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

1.  include / -include - включить Makefile, дупускаются shell
    шаблоны. С / без ошибки при отсутствии файла. После прочтения всего
    Makefile, имена файлов, которые указаны  директиве, проверяются на
    возможность обновления рецептами. В случае обновления включаются
    заново (основа для автоматической генерации зависимостей).

2.  Secondary expansion - после чтения Makefile и перед фазой
    обновления целей, производится второй проход по списку
    пререквизитов. Доступны автоматические переменные.
        .SECONDEXPANSION:
        main_OBJS := main.o try.o test.o
        lib_OBJS := lib.o api.o
        main lib: $$($$@_OBJS)

3.  Order-only пререквизиты - цель не будет считаться устаревшей при
    выполнении рецепта такого пререквизита
        targets : normal_prereq | order_only_prereq.

4.  Переменная VPATH - пути поиска всего. Директива vpath - пути поиска
    для определённого класса файлов.

5.  .PHONY : target - цель target всегда устаревшая. Для target не
    производится поиск неявных правил.

6.  Если в качестве пререквизита -lname, то поиск библиотеки в
    следующих местах: в текущей директории, vpath и VPATH, /lib,
    /usr/lib, prefix/lib.

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

8.  Если существуют несколько правил с двумя двоеточием для одной цели,
    то каждое правило независимо от другого. Каждое правило может иметь
    свой рецепт иначе поиск среди неявных правил. Могут выполниться все
    рецепты, ни одного не выполниться, выполниться лишь часть рецептов.

9.  target : ; пустой рецепт, не будет производиться поиск неявного
    правила.

10. Static pattern rule
       targets : target-pattern : prereq-pattern
            recipe
       ${objects} : %.o : %.c
    Часть имени соответствующая % - stem.

11. Каждая строка рецепта исполняется в своей shell (в одной есле
    .ONESHELL). Shell, которая используется, хранится в SHELL, опции в
    .SHELLFLAGS. Значение SHELL не наследуется из окружения make.
    Exit-status shell, выполняющей команду, содержится в .SHELLSTATUS.

12. В рецепте (в начале строки):
       @ - отключает печать команды (-n и --just-print всё равно
           печатают такие команды);
       + - выполнить даже если заданы -n или --just-print;
       - - игнорировать ошибки при исполнении команды.

13. В рецепте: обращение к make переменной ${var}, к shell переменной
    $${var}.

14. При рекурсивном вызове make использовать переменную ${MAKE}
       $(MAKE) -C subdir

15. [override] undefine var - удалить переменную.

16. export / unexport var [=val] - экспортировать / не экспортировать
    переменную в sub-make. Одинокий export / unexport - экспортировать
    / не экспортировать все переменные.

17. var = val - ссылка;
    var := val - обычная переменная;
    var += val - ссылка ли, зависит от типа val;
    var ?= val - присвоить значение если var не объявлена;
    var != cmd - выполнить cmd в shell;
    ${foo:.o=.c} - заменить .o в конце слов на .c;
    ${foo:%.o=%.c}

18. Иерархия переменных:
       1. объявлянные внутри Makefile с override (дальнейшая
          модификация возможно только с override);
       2. переданные через командную строку;
       3. объявленные внутри Makefile без override;
       4. из окружения, где запускается make.
    Экспортируются переменные в sub-make:
       1. из окружения, где запускается make (редактирование внутри
          Makefile не влияет);
       2. переданные через командную строку (если Makefile редактирует
          с override, то в sub-make приходит значение из командной
          строки);
       3. объявленные внутри Makefile с export.

19. MAKEFLAGS - содержит флаги переданные при запуске make +
    переменные со значениями переданными через командрую строку, но не
    содержит цели. В переменную можно добавить флаги внутри Makefile
    или в окружении, в котором запускается make).

20. MAKELEVEL - содержит целое число, которое указывает на глубину
    рекурсии. 0 для главного make.

21. MAKECMDGOALS - содержит цели заданные при запуске make.

22. Target-specific переменные
       prog : [private] CFLAGS=-g
       prog : prog.o foo.o bar.o
           recipe
     задаёт CFLAGS в рецептах для prog, prog.o, foo.o, bar.o. Если
     private стоит, то пререквизиты не наследуют CFLAGS. Если
     переменная объявлена private на глобальном уровне, то она не
     будет видна ни в одно рецепте.

23. Pattern-specific переменные
       %.o : CFLAGS=-g

24. Match-anything pattern rule (цель одинокий %). Бывают:
      1. терминальные (%::pregeq) - prereq должен существовать, не
         может быть создан посредством другого правила.
      2. иначе - правило будет рассмотрено только если нет других
         неявных правил , чья цель совпадает с искомой.

25. Last-resort default rule
      1. %::
      2. .DEFAULT:      # если рецепт не указан, то текущее правило
                          будет удалено

26. Отмена неявного правила
       %.o:%.s
    указать ту же цель и те же пререквизиты, рецепт не указывать.
    
27. Архивы:
      1. при использовании нотации со скобками ( libname(objs) ) не
         допускать параллельного запуска make (-j опция).
      2. внутри архива содержится таблица символов (__.SYMDEF), ranlib
         lib.a её обновляет. GNU ar не требует запуска вручную,
         запускает её автоматически.

28. Договорённости:
      * Каждый Makefile должен содержать
          SHELL = /bin/sh
        для избежания проблем на системах, где SHELL может быть
        унаследована из окружения.
        
      * Не плохо задать суффиксы для которых будет производиться поиск
        неявных правил
           .SUFFIXES:             # удаляет все раннее установленные
           .SUFFIXES: .c .o
           
      * ar bison cc flex install ld ldconfig lex make makeinfo ranlib
        texi2dvi yacc chgrp chmod chown mknod - вызывать через
        переменные ${AR}, ... . Для каждой переменной-команды
        переменная с опциями образуется добавлением FLAGS к имени
        (исключение - CFLAGS, YFLAGS, LFLAGS).

       * команды, которые следует использовать напраямую (без
         переменных): awk cat cmp cp diff echo egrep expr false grep
         install-info ln ls mkdir mv printf pwd rm rmdir sed sleep
         sort tar test touch tr true gzip.

       * каждый Makefile должен задавать переменные: INSTALL,
         INSTALL_PROGRAM (дефолтно ${INSTALL}), INSTALL_DATA (дефолтно
         ${INSTALL} -m 644).

       * staged install - для целей install и uninstall поддерживать
         переменную DESTDIR
            $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
            $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a

       * установка info и man страниц в цели install.

       * Разбивка install на $(PRE_INSTALL), $(POST_INSTALL),
         $(NORMAL_INSTALL). Разбивка uninstall на $(PRE_UNINSTALL),
         $(POST_UNINSTALL), $(NORMAL_UNINSTALL).

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

Есть какое-то исчерпывающее, но краткое чтиво? Стандарт читать грустно и долго.

Принцип работы:

• Пользователь добавляет биткоин адрес в свой профиль: [bitlor]36Ks7J2a1qihJgJeJX21dNMez2BebxWzpA[/bitlor].
• После каждого подтверждёния новости (вне зависимости от её типа) на указанный адрес отправляется 2% от текущего объёма средств.
• Пользователи, желающие поддержать инициативу, могут отправить свои пожертвования в BTC на адрес 1FBuz8WST5GMqUbghPHBPba9995cDrxa6u.

Особенности:

• Реализация полностью «навесная», администрация ресурса не имеет никакого отношения ни к данному проекту, ни к кошельку для донейтов.
• Все правовые особенности использования BTC вы берете на себя. Так что не забудьте заплатить налоги, если ваша страна требует и позволяет это сделать.
• Оплата не является гарантированной. Разработчик не несет ответственность за ваши опечатки в адресе, программные ошибки и прочие подобные проблемы.

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

Если у вас нет биткоинов, то вы можете воспользоваться биржами вроде localbitcoins. Создать кошелёк очень просто с помощью Electrum.

Подробности

Да, я слоупок: более 5 лет пользуюсь линуксом, даже программист вроде как, и только сейчас обнаружил эти отличные опции для `/etc/sysctl.conf`:

vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Перегрузил опции командой `sudo sysctl --system` и попал прямо в райские кущи. Можно открыть браузер, три IDE и запустить виртуалку Virtual Box - и результатом станет не зависание системы намертво с необходимостью делать hard reset, а просто ошибка в Virtual Box (работа виртуальной машины прервана).

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

А как вы боретесь с традиционным для Linux зависанием намертво при нехватке памяти?

P.S. для справки, настройку выполнял согласно этому былинному посту: http://avz.org.ua/wp/2011/04/24/overcommit-memory/

Мы обновили свою легковесную C++14 библиотеку для встраивания HTTP-входа в C++ приложения до версии 0.4.3.

Основные изменения в RESTinio со времени последнего анонса:

• новые варианты restinio::run(), позволяющие задать внешний asio::io_context для RESTinio;
• добавлена поддержка sendfile (https://stiffstream.com/en/docs/restinio/0.4/sendfile.html);
• request_id теперь доступен внутри обработчика входящего HTTP-запроса;
• плюс несколько мелких изменений и улучшений в коде самого RESTinio.

Библиотека живет на bitbucket-е (https://bitbucket.org/sobjectizerteam/restinio-0.4) c зеркалом на github-е (https://github.com/Stiffstream/restinio), документация доступна у нас на сайте (https://stiffstream.com/en/docs/restinio/0.4/). Распространяется под BSD-3-CLAUSE лицензией.

Мы создавали RESTinio для того, чтобы иметь возможность асинхронной обработки входящих запросов в случаях, когда для формирования ответа нужно обратиться к медленно отвечающему стороннему сервису. Иногда обращения к таким сторонним сервисам нужно делать посредством HTTP. Для таких целей широко используется Си-шная библиотека libcurl. Подружить асинхронную обработку входящих запросов посредством RESTinio с асинхронной обработкой исходящих запросов посредством libcurl можно несколькими способами. Подробнее эту тему мой коллега раскрыл в небольшой серии статей: часть 1, часть 2, часть 3.

Развитие RESTinio продолжается. У нас есть свои идеи о том, что можно было бы добавить в следующих версиях библиотеки. Но нам было бы очень интересно услышать пожелания от тех, кто смотрел на RESTinio, но еще не начал её использовать:

• что бы вам хотелось увидеть в RESTinio?
• чего не хотелось бы видеть?
• что останавливает вас от использования RESTinio?

int main() {
  int a[10], b[10];
  a = b;
}

https://ideone.com/BdUzkI

prog.cpp: In function ‘int main()’:
prog.cpp:3:7: error: invalid array assignment
   a = b;
       ^

Почему компилятор выдаёт эту ошибку? Стандарт говорит:

http://eel.is/c++draft/expr.ass#1

The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand;

Может, тут не modifiable lvalue? Да вроде нет:

http://eel.is/c++draft/basic.lval#def:modifiable

An lvalue is modifiable unless its type is const-qualified or is a function type.

Так в чём проблема? Почему компилятор выдаёт ошибку, а не делает то, что велит стандарт:

http://eel.is/c++draft/expr.ass#2

In simple assignment (=), the value of the expression replaces that of the object referred to by the left operand.

Как так то. И что с этим делать.

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

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

Тут ещё есть RSS, на который можно подписываться.

При переполнении будет создана новая тема. Старые темы:

1. http://www.linux.org.ru/forum/talks/3150621;
2. https://www.linux.org.ru/forum/talks/5156881.

Можете, пожалуйста, помочь? Я хочу чтобы команды прописывались cgroups отдельно для каждого пользователя! А список пользователей брало например из списка папок в директории /home и прописало для каждого пользователя например:

sudo cgcreate -a (пользователь) -g memory,cpu,net_cls,net_prio,cpuacct,blkio:(пользователь)

echo 1000000 > /sys/fs/cgroup/cpu,cpuacct/(пользователь)/cpu.cfs_period_us

echo 400000 > /sys/fs/cgroup/cpu,cpuacct/(пользователь)/cpu.cfs_quota_us

echo 335544320 > /sys/fs/cgroup/memory/(пользователь)/memory.limit_in_bytes

echo 335544320 > /sys/fs/cgroup/memory/(пользователь)/memory.memsw.limit_in_bytes

echo «100:0 10485760» > /sys/fs/cgroup/blkio/(пользователь)/blkio.throttle.read_bps_device

и также прописывало файл /etc/cgrules.conf (главное чтобы повторений в данном файле не было)

@(пользователь) cpu,cpuacct,memory,blkio,net_cls,net_prio (пользователь)

опреционная система centos7 ! желательно чтобы был sh скрипт! заранее спасибо!

RESTinio - это header-only, кросс-платформенный инструмент для встраивания HTTP сервера с удобным express-like маршрутизатором и вебсокетами. Главная задачей RESTinio является упрощение асинхронной обработки запросов. Чтобы, грубо говоря, обработчик спокойно мог потратить 15 секунд на формирование ответа, но это бы не влияло на параллельные запросы.

RESTinio с самого начала создавался так, чтобы его с одной стороны было удобно использовать, а с другой, чтобы он был производительным и масштабируемым. RESTinio с самого начала написан с использованием C++14.

Вот как будет выглядеть простейший http-сервер, который отвечает на все запросы hello-world сообщением:

#include <restinio/all.hpp>

int main()
{
  restinio::run(
    restinio::on_this_thread()
      .port(8080)
      .address("localhost")
      .request_handler([](auto req) {
        return req->create_response().set_body("Hello, World!").done();
      }));

  return 0;
}

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

Возможности:

• Асинхронная обработка запросов. В случаях, когда данные для ответа на запрос не могут быть получены сразу (или почти сразу), то можно сохранить хэндл запроса для дальнейшей обработки (например, в другом контексте исполнения) и вернуться к этому запросу, когда все данные будут готовы.
• HTTP pipelining. Хорошо работает в связке с асинхронной обработкой запросов.
• Контроль за таймаутами. RESTinio может помочь в обработке “плохих” соединений, например из которых приходит «GET /», а затем они просто висят.
• Построители ответов. Например, если нужно тело chunked-encoding, то в RESTinio есть и такой билдер.
• Express-like маршрутизатор. Нужно создать нетривиальное REST API со множеством маршрутов, в которых к тому же заключены параметры? Просто возьмите RESTinio с express-like маршрутизатором, который создан по мотивам известного js-фрэймворка.
• Поддержка TLS (HTTPS).
• Базовая поддержка websocket. При помощи restinio::websocket::basic::upgrade() можно начать websocket сессию используя соединение, в котором был получен исходный upgrade-запрос.
• Может быть запущен на стороннем asio::io_context. RESTinio отделен от контекста исполнения, что, например, позволяет запустить 2 сервера используя один asio::io_context или встраивать RESTinio в существующее приложение построенное на ASIO и для этого не потребуется отдельный io_context.
• Некоторые настройки для оптимизации. Можно задать дополнительные опции для акцептора и сокета. Если RESTinio работает на пуле, то можно задать чтобы соединения принимались параллельно и/или создание внутренних объектов для работы с соединением создавались отдельно, это позволит быстрее принимать новые соединения.

RESTinio для своей работы использует standalone версию ASIO, а также ряд других хорошо известных open-source библиотек (nodejs/http-parser и fmtlib), а также catch2 для тестов.

RESTinio-0.4 можно рассматривать как стабильную бета версию.

Репозиторий проекта: https://bitbucket.org/sobjectizerteam/restinio-0.4

Документация: https://stiffstream.com/en/docs/restinio/0.4

Взгляд со стороны, пожелания, предложения и конструктивная критика приветствуются!

Случайно наткнулся на то, что в clang-овой реализации libc++ (по крайней мере в MacOS) при работе с русской юникодной строкой в wstring ее метод substr ничего не выдает. Меняем текст на английский во всем том же юникоде - substr работает:

#include <iostream>

int main() {
    ::setlocale(LC_ALL, "");
    std::wstring s1(L"test");
    std::wstring s2(L"тест");
    std::wcout << s1.substr(2, 1); // s
    std::wcout << s2.substr(2, 1); // <пусто>
}

Компилируем пример в gcc: выдается sс

Прочитал старый срач по поводу реализации юникода в C++ Есть ли жизнь на lua (комментарий) , но сути проблем работы substr с wstring так и не понял.

Понятно, что есть библиотека ICU, но хотелось бы понять из-за чего это может происходить?

Приветствую! Хотелось бы привлечь внимание общественности к данному проекту.

Автор David Torrejon Vaquerizas, уже около года не развивает и не поддерживает проект, на попытки его попинать «Project is dead?», автор отвечает что пользователи мало донатят, поэтому он не будет ничего делать и вообще устал. Возможно здесь найдутся люди знающие перл, которые захотят поддерживать проект. Так же стоит рассмотреть вариант переписать весь проект на другом ЯП.

Например:

• Python3 + PyGOobject(GTK3)
• Python3 + PyQt
• C++ + Qt
• C++ + GTK3

PAC на github

PAC на sourceforge