Випадково помітив:

POSIX Shell		C++98/03		C++11		Haskell
#!/bin/sh for i in {1..4} do echo $i done		#include <iostream> int main() { int arr[] = {1, 2, 3, 4}; for (size_t i = 0; i < sizeof(arr) / sizeof(arr[0]); ++i) std::cout << arr[i] << "\n"; return 0; } _Winnie C++ Colorizer		#include <iostream> int main() { for (auto i : {1, 2, 3, 4}) std::cout << i << "\n"; return 0; } _Winnie C++ Colorizer		module Main where main = mapM_ print [1..4]
6 LOC		9 LOC		8 LOC		3 LOC

Для чого це потрібно? Іноді буває необхідно проітеруватись по enumeration. Не городити ж для цього масив, в кінці кінців...
PS: ага, і Shell, і плюсовий код теж можна в один рядок записати. Але ж читабельність...

Викочував апдейти на сервер і випадково глянув у лог PostgreSQL.
В результаті оптимізував два запити, один у 1500 разів, інший майже у 3000 (з близько 1 сек до 0.9 мс і 0.3 мс відповідно). У другому випадку довелось трішки змінити код, заодно поприбирав catch який раніше імпортувався із Prelude.

Bartosz Milewski підняв цікаву тему: як функтори, аплікативні функтори і монади допомагають боротися з інверсією управління при використанні асинхронного API (в контексті C++).
Відео: „Вступ і про функтори“, „Аплікативні функтори“, „Монади“.
Слайди: https://www.fpcomplete.com/wp-content/uploads/2012/09/Functional-Patterns.pdf
( Read more... )

Є одна кльова софтинка, яку я давно використовую. Але мене задовбували у ній два дуже неприємних баги: хтозна-чого вона жерла CPU як не в себе, і її вікно іноді ховалось під інші вікна (хоча завжди повинне бути on top).

Спочатку я думав пофіксити швиденько баги (у мене були ідеї щодо high CPU consumption) і відправити патчі автору, але коли я глянув код... Коротше кажучи, простіше було її тупо переписати. Тому я форкнув її (GPL v. 3) і почав корячити. Відучити її жерти проц було нескладно, мої підозри підтвердились (колись давно я таке саме робив для Psi). І здавалось що і ховання під іншими вікнами вдалось виправити. Я „причесав“ код, трохи відрефакторив, зробив єбілд у локальному оверлеї і почав радіти життю.

Але виявилось що бага з хованням під вікнами так і залишилась. При чому я ніяк не міг визначити що саме викликає цю багу: одразу після старту все працює як треба, і тільки з часом вікно починає „ховатись“ — неначе соромиться... Я витратив купу часу намагаючись побороти цей баг, але марно. Тоді у мене закралась підозра що проблема у віконному менеджері — XMonad.
( Якщо вам не страшний код на Haskell можете зазирнути під кат )

read виявився вельми небезпечним. На ньому "лажає" строга типізація.

Prelude> (read "1.0") :: Double
1.0
Prelude> (read "1.0") :: Maybe Double
*** Exception: Prelude.read: no parse

Логічно, в принципі. Але фіг відловиш таку помилку. А через таку дрібничку більше доби не працював сервіс :(

PS: Зате зробив нормальне журналювання.

Сьогодні після чергового незначного допилювання xmonad.hs він при компіляції показав мені смачну і велику дулю: Could not find module: `XMonad.Prompt.AppendFile'.
Solution: haskell-updater --all. Чомусь -u не допоміг.
Відкрив для себе tabbed layout. Правда, поки не придумав де його можна застосувати. Мабуть для full-screen applications тіпа firefox чи okular.

Вчора осилив Parsec. Після Boost.Spirit такі штуки мене вже більше не дивують. Вражає лише лаконічність коду: BNF перекладається майже без проблем. Із ghci дуже зручно тестувати парсери і їх комбінації (вихлоп g++ при помилках у Boost.Spirit мене досі лякає).
Коротше кажучи, приємна і зручна у користуванні бібліотека.
Цікаво те що і Parsec і Boost.Spirit у мене випливли в одному й тому ж проекті. Сам проект на C++, а одну маленьку утиліту вирішив спробувати написати на Haskell (отримавши натхнення від статті Дмитра Астапова "Давно не брал я в руки шашек"). Низхідне проектування майже вийшло, тільки в кінці на одній функції застряг. Треба буде пошукати як прийнято у Haskell обробляти помилки.

http://blog.sigfpe.com - цікаво чувак пише.

Рекомендую:
What's all this E8 stuff about then? Part 1.
What's all this E8 stuff about then? Part 2.
What's all this E8 stuff about then? Part 3.

The Three Projections of Doctor Futamura

Пише дуже простою мовою, наводить ілюстрації.

Glasgow Haskell Compiler написано на Haskell. Таким чином для того щоб зібрати GHC потрібно зібрати GHC, зібраний за допомогою GHC... І ніяк не вирватись із цього порочного круга!
А все просто насправді:

$ ls -l /usr/portage/distfiles/ghc-*
-rw-rw-r-- 1 portage portage  7072545 лис 14 10:46 /usr/portage/distfiles/ghc-6.8.2-src.tar.bz2
-rw-rw-r-- 1 portage portage 30872949 лис 14 10:51 /usr/portage/distfiles/ghc-bin-6.8.2-x86.tbz2
-rw-rw-r-- 1 portage portage   940742 лис 14 10:51 /usr/portage/distfiles/ghc-bundled-readline-5.2_p13-x86.tbz2