[inline][i]][/inline] даёт лишнюю квадратную скобку: [i]]
Баг проявляется с любым парным тегом внутри блока.
Вместе с inline, этому же подвержен и code. Пример.

Перемещено leave из linux-org-ru

В связи с всё возрастающим потоком тупняка в Science & Engineering, предлагаю ввести новое правило о запрете пропаганды лженауки. Отдельные личности заполоняют всё пространство своими оскорблениями в сторону научного сообщества, распространением псевдонаучных теорий и тотальным невежеством, выражающимся в неприятии основ экспериментальной и теоретической физики, а так же математики.

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

Я, равно как и многие пользователи, абсолютно не согласны с текущим положением дел, справедливо не желая дальнейшего превращения пока ещё годного форума в очередную помойку. Все более-менее серьёзные научные форумы проходят через это, и я считаю, настал черёд и нашего Science & Engineering. За основу можно взять аналогичный пункт из списка нарушений на dxdy.ru. Запрещается:

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

maxcom

В этом треде мы помогаем лоровцам получше понять и разобраться во всяких интересных математических концепциях. Кто-то до сих пор не понимает почему на ноль делить таки нельзя; кому-то нравятся аналогии «на пальцах» вида детерминант — ориентированный объём, ковектор — (n-1)-мерная плоскость; кому-то будет интересно узнать, что из алгебраической топологии, интеграл это всего-навсего произведение цепи на коцепь. А кто-то до сих пор не знает что такое тензор; возможно, не всем известно, что механику, электродинамику, теорию относительности и квантовую теорию поля можно локально вывести из наикрасивейшего лагранжева формализма; зачем нужны алгебры Ли; что такое ковариантная производная; в чём отличии гомологий от гомотопий, ну и так далее.

Заметьте, это не тред ответов на вопросы вида «почему небо голубое» — за этим идите в гугл; это не тред выполнения за вас домашних заданий — решайте сами; это не тред споров с фриками — игнорируйте их; это тред добра и просвещения. Однако в идеале вы уже должны иметь представление о математике и физике хотя бы на уровне первого-второго курса. Здесь так же можно просить и рекомендовать литературу, можно посылать в английскую википедию, можно и нужно объяснять как можно проще и доступнее (пускай и совсем неформально). Главное, чтобы у зашедшего лоровца появился интерес и желание учиться.

http://www.opennet.ru/opennews/art.shtml?num=40408
Для Ъ:

• Поддержка автоматического определения типа, возвращаемого любой функцией, в которой используется несколько выражений return, содержащих значение одного типа. В С++ определение типов было ограничено лямбда-функциями, содержащими только один вызов return;
• Реализован дополнительный синтаксис определения типа - decltype(auto), который можно использовать для определения результирующего типа возвращаемого функцией значения (например, «string lookup1(); decltype(auto) look_up_a_string_1() { return lookup1(); }»);
• Поддержка захвата переменных лямбда-функций с возможностью захватывать переменные с перемещением значения и объявлять произвольные локальные переменные в лямбда-объекте;
• Возможность указания типа «auto» для лямбда-выражений, позволяющего вынести определение типа на плечи компилятора по аналогии с вычислением типов переменных, объявленных с указанием ключевого слова «auto»;
• Поддержка задания шаблонов для переменных, в дополнение к ранее поддерживаемым шаблонам для функций и классов;
• Расширение числа возможностей, которые можно использовать внутри функций constexpr. В частности, C++14 позволяет объявлять локальные переменные и использовать выражения if, switch, for, while, do-while, допускает мутацию объектов;
• Добавлен атрибут "[[deprecated]]", при помощи которого можно пометить элемент устаревшим, после чего останется возможность использования этого элемента, но будут выводиться предупреждения, что в будущем его поддержка может быть прекращена.
• Поддержка разделяемых мьютексов (shared_mutex) и разделяемых блокировок (shared_lock);
• Добавлены псевдонимы «*_t» для трансформации типов, позволяющие уйти от использования многословных объявлений c typename (remove_reference_t вместо «typename remove_reference», make_unsigned_t вместо typename make_unsigned и т.п.);
• Возможности обращения к элементам кортежа по типу, при условии, что в кортеже содержится только один элемент данного типа.

Не думал, что когда-нибудь это скажу, но С++ потихоньку нет-нет да становится годным.

• Себестоимость производства копии книги, фильма, программы etc. не зависит линейно от себестоимости создания оригинала. Но на прилавке книги десятилетней давности по 4000 рублей и цифровые копии 36 минут музыки по 700 рублей.
• Любые ограничения, связанные с интеллектуальной собственностью: по созданию, распространению и пользованию — суть тормоз прогресса. В их числе. Патенты: на программное обеспечение, на API, на скруглённые уголки, на фотографирование на белом фоне etc. Запреты: на копирование защищённой информации, на реверс-инжиниринг, на право полного распоряжения продуктом (айфон, штеуд, любое ПО). Софтварные лицензии: любые проприетарные (отсутствует возможность даже в перспективе произвести верификацию) и прочие анально огороженые, в том числе вирусная GPL.
• Любые запреты, связанные с ограничением распространения информации — суть зло, абсолютное и беспощадное. И не важно кого и что попирает эта информация: детей, моралфагов, патриотизм, религию или что-то ещё. Свободу слова и свободу распространения никто не отменял (другой вопрос, вы не обязаны это читать, и вашу информацию не обязаны хранить). Цензура в любом виде недопустима. С другой стороны, приватная информация (пароли, явки, номера кредиток etc.) является собственностью пользователя, поэтому не может быть никого доверия сторонним сервисам, потенциально записывающим и сливающим каждый шаг.
• Остро необходимо создание открытой, формально верифицируемой, распределённой системы, предоставляющей гарантию цифровой анонимности (а-ля i2p), децентрализованное хранилище (а-ля freenet) и поддержку распределённых fake-tolerance сервисов (аналогов нет, отдалённый пример: distcc), поверх всего биткоин и система сборов, донейтов и краудфандинга.

Просто не мог не запостить. IMHO, лучший референс по хаскелу: http://dev.stephendiehl.com/hask/

We have reached zero P1 regressions today (and < 100 important regressions) and the branches/gcc-4_9-branch has been created today and GCC 4.9.0-rc1 built and announced.

• Support for a number of older systems and recently unmaintained or untested target ports of GCC has been declared obsolete in GCC 4.9. Unless there is activity to revive them, the next release of GCC will have their sources permanently removed.
• AddressSanitizer, a fast memory error detector, is now available on ARM.
• UndefinedBehaviorSanitizer (ubsan), a fast undefined behavior detector, has been added and can be enabled via -fsanitize=undefined. Various computations will be instrumented to detect undefined behavior at runtime. UndefinedBehaviorSanitizer is currently available for the C and C++ languages.
• Major Link-time optimization (LTO) improvements. Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds.
• Version 4.0 of the OpenMP specification is now supported for the C and C++ compilers. The new -fopenmp-simd option can be used to enable OpenMP's SIMD directives, while ignoring other OpenMP directives. The new -fsimd-cost-model= option permits to tune the vectorization cost model for loops annotated with OpenMP and Cilk Plus simd directives; -Wopenmp-simd warns when the current costmodel overrides simd directives set by the user.
• Support for colorizing diagnostics emitted by GCC has been added. The -fdiagnostics-color=auto will enable it when outputting to terminals, -fdiagnostics-color=always unconditionally. The GCC_COLORS environment variable can be used to customize the colors or disable coloring.
• ISO C11 atomics, thread-local storage, generic selections are now supported.
• A new C extension __auto_type provides a subset of the functionality of C++11 auto in GNU C.
• G++ supports C++1y lambda capture initializers, polymorphic lambdas, variable length arrays, and digit separators.
• Improved support for C++11, improved experimental support for the upcoming ISO C++ standard, C++14.
• GCC 4.9 provides a complete implementation of the Go 1.2.1 release.
• A number of infrastructural changes have been made to both the ARM and AArch64 backends to facilitate improved code-generation.
• Intel AVX-512 support was added to GCC. That includes inline assembly support, new registers and extending existing ones, new intrinsics (covered by corresponding testsuite), and basic autovectorization. AVX-512 instructions are available via the following GCC switches: AVX-512 foundation instructions: -mavx512f, AVX-512 prefetch instructions: -mavx512pf, AVX-512 exponential and reciprocal instructions: -mavx512er, AVX-512 conflict detection instructions: -mavx512cd.
• Better inlining of memcpy and memset that is aware of value ranges and produces shorter alignment prologues.
• GCC now supports the new Intel microarchitecture named Silvermont through -march=silvermont, Broadwell through -march=broadwell, optimizing for other Intel microarchitectures have been renamed to -march=nehalem, westmere, sandybridge, ivybridge, haswell, bonnell.

>>> Status Report
>>> Changes, New Features, and Fixes

Хочу написать небольшой source-to-source транслятор с лиспа в некий другой язык. Могу ли я каким-либо образом переопределить специальные операторы, сохраняя возможность обращения к ним? Например, сделать полностью свой let, при этом оставив для макросов какой-нибудь LET или sb-kernel:let. Я знаю, что в схеме для этого есть няшный define-syntax, но как с этим обстоит дело в CL? Правкой readtable? Или как-то ещё? Да, я хочу именно let, lambda, а не my-let etc. Спасибо.

Кто-нибудь слышал про существование хороших документальных фильмов уровнем повыше обывательского научпопа, но пониже университетских лекций? Согласитесь, раздражет видеть то, как 60% экранного времени нас заставляют любоваться на, пускай и красочную, компьютерную графику, а ещё 20% неустанно повторяют одну и ту же мысль, и хорошо, если разными словами. Хотелось бы показать желающим учиться людям нечто более интересное.

Вот умели же снимать в своё время учебные фильмы в СССР, по физике, скажем, про гироскопы, транзисторы или взаимодействие элементарных частиц: что такое, за счёт чего работает, пара формул и куча примеров-демонстраций. Или основы квантовой механики: думаю, многие видели практически гениальный «Физика в половине десятого». Да всё было, даже про устройство локомотивов.

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

В общем, я перечитал Грина, Пенроуза и Ландафшица и теперь тщетно пытаюсь найти достойную экранизацию их творений. Пример не очень хороших, на мой взгляд, фильмов: всякие «Сквозь червоточину с Морганом Фрименом», цикл видео Discovery и National Geographic, да даже «Элегантная вселенная» того же Грина. Не очень хороших именно по причине того, что как для детей — много спецэффектов, мало смысла; для детей уже не хочется, хочется для взрослых, причём не для себя. Примеры хороших фильмов: «Механическая вселенная», но там 1985 год и цикл видео ПостНауки, но там формат немного не тот.

Линукс здесь при том, что русские физики выбирают Slackware.

Решил намедни углубить свои знания по плюсам, чувствуя, что скоро нехило так потребуются по работе. Теперь сижу, обмазываюсь тут всякими трупами страусов, Скоттом Майерсом и другими. Г-пди, как же можно на этом писать, особенно после знания божественных лиспов, хаскелей и прочих матанских агд (sic!). Это какая-то пытка, честное слово, мне натурально мерзко и противно читать как люди пытаются вырезать гланды через задний проход да ещё и хвалятся этим, поглядите, мол, как это круто. Такое ощущение, будто плюсисты все поголовно латентные мазохисты.

template <typename T>
class Rational
{
    public:
    ...
    friend const Rational operator*(const Rational& lhs, const Rational& rhs)
    {
        return Rational(lhs.numerator() * rhs.numerator(), // same impl
            lhs.denominator() * rhs.denominator()); // as in Item 24
    }
}

An interesting observation about this technique is that the use of friendship has nothing to do with a need to access non-public parts of the class. In order to make type conversions possible on all arguments, we need a non-member function (Item 24 still applies); and in order to have the proper function automatically instantiated, we need to declare the function inside the class. The only way to declare a non-member function inside a class is to make it a friend. So that's what we do. Unconventional? Yes. Effective? Without a doubt.

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

Перемещено mono из talks

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

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

Сервис использует стойкие методы стеганографии для сокрытия самого факта сокрытия информации вместе со стойкими методами криптографии для защиты данных, передаваемых по открытым каналам, от компрометации (факта доступа посторонних лиц). Исходные тексты проекта распространяются в рамках лицензии MIT.

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

• Использование SHA3 для генерации ключей;
  
• Симметричное шифрование AES-256;
  
• JPEG (DCT LSB) стеганография;
  
• Поддержка RarJPEG и двойного сокрытия;
  
• Подбор случайного контейнера;
  
• Вычисления без участия сервера;
  
• Гарантия полной конфиденциальности.
  

Ссылка проекта: http://darkjpeg.github.io
Ссылка на github: https://github.com/darkjpeg/darkjpeg.github.io

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

В общем, хочется очень хорошо и в деталях понимать как работают TOR, I2P, всякие там Netsukuku и прочие Perfect Dark (или похожие), отдельно сильно интересует Bitcoin.

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

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

Собираюсь прикупить мыльницу, сейчас смотрю многие идут с Li-ion аккумуляторами. Вопрос владельцам: все ли подобные девайсы умеют заряжаться по USB? В качестве основного источника энергии будет использоваться прикуриватель автомобиля (через переходник). В связном говорят, что так могут все, в евросети меня девочка уверяла, что только самсунги. Кому верить?

Задача: разработать кроссплатформенное клиент-серверное приложение под Windows/Linux на С++ (boost, ace, etc.), клиент построчно считывает с консольки введёные числа, отправляет на сервер, сервер в ответ плюёт разложением чисел на простые множители. Стандартное тестовое задание, ничего интересного.

Ну что же, собрался духом, за вечер родил чуть около пол тысячи строк, чтоб всё как положено: асинхронность, многопоточность, все дела. Такое ощущение, коллеги, будто накормили грязью, кресты не умеют ни в замыкания, ни в нормальную асинхронность, ни в управление памятью, они вообще ничего не умеют. Вроде бы, написано 5 строк, а на деле почти не фига не делают, код раздут, абсолютно невыразителен, я уж не представляю что с ним будет, если его ещё раскидать на десяток классов, как это обожают делать отдельные особо одарённые личности.

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

class server
{
public:
  server(boost::asio::io_service& io_service, short port)
    : io_service_(io_service),
      acceptor_(io_service, tcp::endpoint(tcp::v4(), port))
  {
    session* new_session = new session(io_service_);
    acceptor_.async_accept(new_session->socket(),
        boost::bind(&server::handle_accept, this, new_session,
          boost::asio::placeholders::error));
  }
  .......

Смеха ради, да и чтоб не вырвало от такого кода, накидал за полчаса решение на Haskell.
Что получилось:

• Разбор параметров командной строки
• Клиент-серверная архитектура
• Полностью асинхронный многопоточный tcp-сервер
• Поддержка unicode, IPv6 и BigInteger из коробки
• Мемоизация (благодаря ленивости) из коробки
• Полная кроссплатформенность (*nix, Mac OS, Windows etc.)
• Правильность тривиально доказывается мат. индукцией по коду
• Исходник чуть больше 60 строк (в 8 раз меньше, чем на крестах)

Если поднатужиться (я не стал) и заменить алгоритм нахождения простых чисел/простых множителей на более оптимальный, то ко всему прочему получаем автоматическую распараллелизацию алгоритмов из коробки (см. Data Parallel Haskell) и произодительность на уровне чистого Си/Фортрана.

Кто там пищал, что хаскель сугубо академический язык, что ничего реальго на нём написать невозможно? Кто там кукарекал про С++? Как вы с ним вообще работаете? Это же мазохизм в чистом виде (см. мыши и кактус)

Pure - динамически типизированный функциональный язык программирования с моделью исполнения, основанной на идее «term rewriting».

• Синтаксис, бликий к Haskell (включая карринг, срезы, лямбды, сопоставление с образцом, list comprehensions и «as» patterns);
• Поддерживает модель ленивости, основанную на продолжениях и заимствованную из Alice ML;
• Допускает функции с побочными эффектами, опциональную аннотацию типов, интерфейсные типы
• Поддержка рациональных, комплексных чисел, встроенный RegEx;
• Содержит спектр встроенных структур данных, таких как: списки, туплы, векторы, матрицы и ленивые последовательности;
• Интеграция с GSL;
• Поддерживает полноценную систему гигиенических макросов;
• Лёгкий FFI с сишными библиотеками;
• Реализация под LLVM под GNU/Linux, Mac OS X, FreeBSD и Windows;
• Из коробки поддержка компиляции в нативный код;
• В комплекте идёт набор батареек для разнообразных нужд.

Про производительность заявляется следующее:

The Pure interpreter is able to achieve very good performance, offering execution speeds in the same ballpark as good Lisp interpreters. It seems to be one of the fastest implementations of term rewriting as a programming language right now, and is certainly good enough for most programming tasks except maybe the most demanding number crunching applications (and even these can be tackled by interfacing to Fortran or C).

Язык активно развивается, последняя версия документации датирована 8 января, автор постоянно пилит своё детище, активно идёт на контакт и охотно принимает и рассматривает любые предложения.

Ссылка на страницу проекта: http://code.google.com/p/pure-lang/
Ссылка на документацию (pdf): http://docs.pure-lang.googlecode.com/hg/puredoc.pdf
Ссылка на пример полной реализации АВЛ-деревьев: http://pure-lang.googlecode.com/hg/pure/examples/avltree.pure
Репозиторий (лицензия LGPLv3): hg clone https://code.google.com/p/pure-lang/

Реально ли имея две видеоплаты (интегрированный штеуд и nVidia с двумя видеовыходами) запустить xorg сразу на трёх мониторах?

Что имеем: при создании перечислений в латехе получается:

    а) --- -- - -- - --
       - - - -- - -- -:
        1) - - - - -- -
           - - -- - -- -;
        2) - --- - - - -
           - - -- - -- -.
    б) -- - - -- - - -- 
       -- -- - -- - -- .

    a) -- - -- - - -- -
- - -- - - -- - -- - --:
        1) - - -- - - -
    - - -- - -- - - ---;
        2) - - -- - - -
    - - -- - -- -- - --.
    б) - - -- - -- - - 
- - -- - -- - -- - -- -.

Итак, задача: имеется неориентированный граф, в котором присутствует некое количество источников и стоков (A и B соотв.), каждый источник может поставить a_i элементов и каждый сток принять b_i элементов. Требуется рассчитать сколько элементов и по каким путям (веса ребёр одинаковы) необходимо пустить, чтобы заполнить стоки (частично, полностью или даже переполнить — не имеет значения). Естественно, оптимальности никто не требует, достаточно хорошего приближения.

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

Вот всё никак не могу понять, зачем вообще нужны эти выкидыши SGML?
Куда ни плюнь: сайты на HTML, всякие RDF, RSS, SVG, XMPP (он же Jabber), огромное количество конфигов программ на XML, в C# вовсю вкручивают его нативную поддержку (а уж комментарии на XML это просто нечто), даже новый RT Fact с главной страницы и тот юзает (кто бы мог подумать) XML3D. Вопрос: почему?
Он же крайне избыточен, неоднозначен, сложно парсится как программами, так и (ещё более сложнее) людьми, а его мифическая гибкость никому не сдалась и в одном проценте софта, его использующего.
Есть же намного более удобные YAML, JSON, sexp`ы, наконец. FFUUU~