$ cat /etc/resolv.conf | sed '1 d' | awk '{print $2}'
DO
192.168.1.1

Всё нормально:)

top -n 1 -b | grep «load average:» | awk '{print $10 $11 $12}'
loadaverage:0,27,

Всё идёт по плану…

Midori (тот, который на чистом вебките, не хромом) — работает без проблем.

А как насчёт PEG? У неё вроде возможности шире. Хотелось бы что-то практичное почитать по теме таких выражений, а то PCRE уже избиты вдоль и поперёк.

На примере Хромиума: каталог third_party содержит несколько гигабайт кода (это его состояние несколько 6 лет назад, сейчас там творится просто кошмар), надёрганного их OpenSource проектов, что превышает объём кода самого Хромиума. С такими методами разработки проект растёт очень быстро.

В некоторых случаях в такие проекты не только шарперов на пушечный выстрел не подпускают, но и плюсовиков.

В режиме x86 оптимизатор полностью выкинул сортировку для std::array, поэтому получилось 0. В реальности работает чуть быстрее, чем C-style массив за счет отсутствия аллокаций.

asm volatile("");

А вообще следует закругляться со сравнением языков X vs Y на тривиальных задачах, особенно сравнивая C++ с Язык Y (всегда найдётся человек, который перепишет ваш код на SSE4.2+OMP, и сравнение завершится не в пользу последнего). Не верите — посмотрите на очень забавный сайт, где участники буквально соревнуются в искусном владении машинным кодом. Сейчас всех волнует не столько скорость, сколько потребление ресурсов и отзывчивость, если уж C++-разработчики добиваются весьма впечатлительных результатов, было бы любопытно посмотреть на языки с автоматическим управлением памятью в аналогичных условиях…

Для рядового пользователя была бы полезна такая штука: отслеживаем в реальном времени все процессы, если какой-то из них начинает забирать слишком много памяти (например, более 3 ГБ) в течение короткого времени, ставим такой процесс на паузу (SIGSTOP), а через notification daemon отправляем пользователю уведомление — что делать с таким процессом: прибить или отпустить (SIGCONT). Может неплохо защитить от png-бомбы на 140 гигабайт, просто утечки памяти в GIMP (с ним такое нередко бывает) или просто своей кривой программы, которую программист имел неосторожность запустить на рабочей машине.

Вкладка с GMail и так жрет по 300-500 МБ, так что заслуга невелика. Лучше бы сам GMail оптимизировали — было бы эффективнее, а так получается разработчики хрома исправляют косяки разработчиков гмейла.

Странный подход к подсчёту трудоёмкости — решение может занимать 100 строк кода, но на то, чтобы их получить в конечном виде, может потребоваться несколько лет вдумчивой разработки и тестирования. А можно просто набросать копипастой 1000 строк за 10 минут.

Приведу пример. «Простые» на первый взгляд функции стандартной библиотеки Си вроде strcmp, strstr разрабатывают в glibc уже двадцать лет, и до сих пор совершенствуются.

После таких «счетоводов» поставят всем процессоры в 10 раз медленнее и удивятся, почему работа встала. Или речь не о разработчиках? Мне бы не хотелось бы работать на атоме с БП на 60 ватт:)

В документации так и написано, что это overkill feature. Кроме того, авторы языка не очень поощряют наследование:

In particular, preferring composition over inheritance is often the better design.
Composition (has-a relation) is often preferable to inheritance (is-a relation) for simple code reuse. Since objects are value types in Nim, composition is as efficient as inheritance.

Правда, примеров не густо.

Можно посмотреть, как выкрутились в модуле json — банальные object variants, как в сишном GLib. Это для простых случаев. Если же заморачиваться, то решение — дерево объектов и методы. Я взял пример с сайта и чуть переделал:

type
  A = ref object of RootObj
  B = ref object of A
    x: int
  C = ref object of A
    s: string

method `$`(v: A): string =
  quit "to override!"

method `$`(v: B): string = $v.x
method `$`(v: C): string = v.s

var a: seq[A] = @[B(x:4), C(s:"Hello")]

for v in a:
  echo v

Сгенерированный сишный код для этого примера особенно хорош.

На обычном велосипеде в Москве? У нас каждое второе грузовое (и не только грузовое) ТС дымит вот так:

Как раз в сторону тротуара.

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

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

Велодорожки в центре Москвы уже появились. А вот как скоро у нас появятся на улицах такие велосипеды по цене Жигулей?

Дело не в провайдерах — эта вики создана быть локальной (правда, бекапы растут в геометрической прогрессии — каждый по 2 МБ). Дело в том, что новая версия откровенно тормоз (я ещё учитываю андроид и ноутбуки). Для меня основная суть базы знаний — наличие хорошего поиска. А в TW5 его просто нет, то что они там сделали — поиском назвать сложно. Последний гвоздь в крышку гроба — сложность хакинга. Для 5 версии вон, пришлось целую статью написать, а под 2.х.х просто тонны плагинов придумано, потому что порог вхождения минимальный, у меня пару-тройку вечеров ушло на то, чтобы переделать там поиск, русифицировать, выкинуть поддержку древних браузеров, добавить свою разметку по вкусу и поправить некоторые косяки.

P.S. Если у сообщества появится интерес к развитию 2 ветки — можно сделать полноценный форк с тестами и сборкой.

Всё же 1.5 МБ для пустой вики, в которой поиск работает криво — это перебор. И это они ещё jQuery выкинули!

Если интересует, у меня есть форк ветки 2.8 с некоторыми изменениями в части разделения движка на составные части (стиль и скрипт отдельными файлами, допилил до удобства использования под Android, а также пытаюсь выбросить зависимость jQuery), быстрый поиск с подсветкой и подсчётом релевантности, улучшенная разметка, CSS3 и т.п. Она пока проходит обкатку, но через некоторое время это можно будет выложить на github.

Хорошим gzip-ом эти 2.345 МБ ужимаются в 122 кб, кроме того, css надо грузить всего 1 раз, после чего он осядет в кэше. Проблема в том, что многие разработчики этого не делают. Даже за примером ходить далеко не надо — даже известный Битрикс мало того, что выдаёт несжатые неминимизированные js-скрипты по 500 кб, так ещё и заставляет браузер каждый раз их перезагружать, отправляя 200 в заголовках.

Сам спросил, сам нашёл:)
Переделать на \letter+ и дело в шляпе. Интересный язык, этот nim.

Предложу также сравнить с Bash:

grep -oP '\w+' $@ | sort | uniq -c

Штуки шутками, но этот вариант не сильно медленнее, учитывает русские слова и выдаёт человеческую сортировку (без учёта регистра). Nim, в частности, не учитывает русские слова и не умеет человечную сортировку. Такие мелочи как отсутствие русского языка огорчают. Как можно переписать код, чтобы \w в nim понимал UTF-8?

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