На фоне нынешних рассуждений о том, «справится ли мой телефон/калькулятор/часы с проигрыванием HD-видео» отошел на задний план интересный исторический факт: немногим более 10 лет назад проблемой была даже не скорость декодирования видео (теплый ламповый MPEG декодировался тогда отдельными аппаратными декодерами; остальные перебивались возможностями имеющегося ЦП), а скорость его вывода на экран. Многоэкранная среда убивает на корню идею переноса блока памяти с декодированным изображением в видеопамять, ведь окна могут перекрывать друг друга самым причудливым образом.

Проблему решили аппаратно. Приложение, которое должно выводить видео на экран, выводило теперь лишь фон определенного цвета (как правило, очень темный пурпурный), а «впечатыванием» видео занималась видеокарта. При составлении изображения она заменяла пикселы фона на соответствующие пикселы декодированного кадра. Приложение же теперь имело в своем распоряжении область памяти, в которую можно было очень быстро копировать кадры из видео. Технологию назвали hardware overlay и очень быстро внедрили ее во все потребительские и профессиональные видеокарты.

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

Введение

Статья посвящена работе с MVVM и WPF. В ней описывается процесс разработки twitter client. Процесс разработки разбит на шаги. В конце каждого шага читатель параллельно пишущий приложение должен иметь работающее приложение. Каждый последующий шаг добавляет какую-то функциональность к написанному на предыдущем шаге. Используется thirdparty библиотека TweetSharp. Ссылку на исходный код, а так же оригинал статьи, написанный мной на английском, можно найти тут.
Статья рассчитана на новичков в WPF разработке. Но предполагается, что читатель имеет некоторый начальный опыт работы с WPF, в частности освоил data binding.
Я не буду писать зачем нужно использовать MVVM – считаю, что об этом хорошо написано в статье “Приложения WPF с шаблоном проектирования модель-представление-модель представления” от Джоша Смита. Если вы не хотите читать эту статью – просто поверьте мне – неверное спроектированное GUI в случае с WPF превращается в большую головную боль.

Здравствуйте, хабражители. Думаю, многие из вас слышали о программируемых калькуляторах (а некоторые даже использовали их). Как ни странно, здесь я не нашел ни одной статьи, рассказывающей о такой интересной вещи, и поэтому решил восполнить этот пробел и рассказать об основах программирования на калькуляторах.

Некоторое время назад я нашел у себя в кладовке старый «Электроника МК-61», принадлежавший моему папе. Естественно, я не мог упустить такой шанс освоить не совсем «стандартное» программирование на калькуляторе. (В случае, если у вас нет программируемого калькулятора, вы можете скачать эмулятор здесь)

«В скором будущем стоимость аппаратной части компьютеров, необходимой для запуска и работы программы будет ничтожно мала по сравнению со стоимостью труда программиста, поэтому имеет смысл развивать языки программирования, которые, хоть и более требовательны к ресурсам компьютера, зато позволяют минимизировать количество кода», — примерно так рассуждал доктор Джим Браун, возглавлявший группу APL девелоперов IBM в середине 80х. Что ж, его прогнозы оправдались лишь отчасти. Сейчас APL применяется, и вполне успешно для программирования финансовых и научных расчетов, входит в состав .NET платформы и в TIOBE Index на ноябрь 2010 занимает 33 место (рейтинг 0,366%).

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

Основы

Комментарии

Комментарии в OCaml обозначаются символами (* и *), примерно так:
(* Это однострочный комментарий *)

(* Это комментарий
   на несколько
   строк.
*)

Другими словами, комментарии в OCaml очень похожи на комментарии в Си (/* ... */).

В настоящий момент нет однострочных комментариев (как #... в Перле или // ... в C99/C++/Java). Когда-то обсуждалась возможность использовать ## ..., и я весьма рекомендую окамловским товарищам в будущем добавить эту возможность (однако, хорошие редакторы открывают возможность использования однострочных комментариев даже сейчас).

Комментарии в OCaml вложенные, это позволяет очень просто комментировать куски кода с комментариями:
(* This code is broken ...

(* Primality test. *)
let is_prime n =
(* note to self: ask about this on the mailing lists *) XXX;;

*)


Вызов функций

Допустим, вы написали функцию, назовём её repeated, которая берёт исходную строку s, число n и возвращает новую строку, состоящую из n раз повторённой строки s.

В большинстве С-подобных языков вызов функции будет выглядеть так:
repeated ("hello", 3) /* this is C code */

Это означает «вызвать функцию repeated с двумя аргументами, первый аргумент — строка hello, второй аргумент — число 3».

Подобно остальным функциональным языкам программирования, в OCaml, запись вызовов функций и использование скобок существенно отличается, что приводит к множеству ошибок. Вот пример того же самого вызова, записанного на OCaml: repeated "hello" 3 (* this is OCaml code *).

Обратите внимание — нет скобок, нет запятых между аргументами.

Оптимизация сборки — одна из основных прелестей Gentoo, однако все описанное применимо к любому случаю компиляции ПО из исходных кодов. Все параметры сборки в Gentoo задаются в файле make.conf.
По сути нас интересует лишь переменная CFLAGS. CXXFLAGS должна быть равна CXXFLAGS="${CFLAGS}", а в MAKEOPTS лишь указывается число параллельно запускаемых процессов компиляции (обычно задают общее число ядер процессоров + 1).

Эта статья была написана под влиянием впечатлений, полученных автором в ходе одной дискуссии на Хабре, и представляет небольшую серию переводов материалов из свободных источников об истории объектно-ориентированного программирования, основным из которых является Википедия, плюс абсолютно предвзятые выводы автора из прочитанного материала.

Если вам интересно узнать, какой язык в действительности был первым ООП-языком на свете, могут ли Java и C# называться чистыми ООП-языками, а также проникнуться некоторыми другими деталями, приглашаю вас под кат…

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

Что нового в октябрьском рейтинге? В первую очередь это быстро набирающий обороты Objective-C от Apple, который набрал 2.54% за год, и стремится стать языком 2010 года. Появление в первой двадцатке языка Go уже было в начале этого года. И не просто появление — он стал языком 2009 года по версии TIOBE. Сейчас он сместился с 13 места (данные на январь 2010) на 20 место, но продолжает активно собирать последователей.

Помимо языков от Google и Apple в 2009 высокого уровня достигли C# от Microsoft и Actionscript от Adobe. Что касается Java, то он по прежнему остался на первой строчке, хотя его популярность продолжает падать, а Си снова медленно, но верно идёт к первому месту.

Интересно также неожиданное падение популярности PHP, и JavaScript. Если ситуация с PHP еще более-менее понятна, то что касается повсеместно используемого JavaScript — непонятно откуда такое падение рейтинга.

Пожалуй, самое удивительное — появление в двадцатке легендарного военного американского языка Ada, интерес к которому вознёс его аж на 17 строчку рейтинга (по сравнению с 29 местом год назад).

Прочитав про IP-стэк twIP, который помещается в размер твита и отвечает на пинги, корейский программист Канг Сеонгхун (Kang Seonghoon) решил создать нечто такое же миниатюрное и при этом работоспособное. И он создал самый маленький интерпретатор Brainfuck на C размером всего 160 байт.

s[99],*r=s,*d,c;main(a,b){char*v=1[d=b];for(;c=*v++%93;)for(b=c&2,b=c%7?a&&(c&17?c&1?(*r+=b-1):(r+=b-1):syscall(4-!b,b,r,1),0):v;b&&c|a**r;v=d)main(!c,&a);d=v;}

..it is true that asking regexes to parse arbitrary HTML is like asking Paris Hilton to write an operating system..

Последние версии языка Nemerle включают в состав библиотеку для разбора языков, грамматика которых принадлежит классу PEG.

Что такое PEG?

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

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

Перевод третьей лекции из курса «Структура интерпретация компьютерных программ».

Это самый известный курс по программированию за последние 25 лет; с 1980г читается в MIT, а с недавних пор что-то подобное читается и в Беркли.

Курс сменил преподавателей и даже язык программирования Scheme на Python(на мой взгляд совершенно зря) и тем не менее информация, которая дается в этом курсе остается архи актуальной в любое время. Я бы сравнил этот курс с чем-то очень фундаментальным и важным для программистов, типа математики или теории алгоритмов.

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

Приятного просмотра!

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

Далее в посте:

1. Оптимизация «в глазок»
2. Стандартные функции
3. Вывод в ELF
4. Как это работает?
5. Что получилось?

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

Далее в посте:

1. Выбор кода
2. Загрузчик
3. Изменения в п-коде
4. Генерация
5. Что получилось?

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

В качестве эксперимента выкладываю перевод первой из 20 лекций. Если это получит должный отклик, буду переводить дальше.

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

Далее в посте:

1. Починка бага
2. Чистка копирований
3. Что получилось?
4. Сворачивание констант
5. Реализация

В этой статье рассмотрим работу с тайловой графикой, прерываниями, сенсорным экраном и клавиатурой. На основе этого напишем всем с детства известную игру — «пятнашка».
Для начала поподробнее разберём работу с видеоконтроллером DS.

Инициализация видеоконтроллера

Практически все видеорежимы используют «многослойную» структуру организации вывода на экран, то есть одновременно мы можем отображать до 4-х планов (background). _{Не знаю хорошенько какой термин лучше использовать, пусть будет «план» — «задний план».}

Всего имеется 6 типов задних планов:

• framebuffer — Самый простой тип заднего плана. Каждое слово (16бит) в видеопамяти отображается в виде пикселя на экране. (Использовался в прошлом примере);
• 3D — Картинка на экране формируется OpenGL-подобными командами;
• text — Текстовый задний план (он же тайловый) разделён на блоки 8х8 пикселей, в каждом из которых отображается один из тайлов;
• rotation — Тайловый план с возможнотью вращения и масштабирования;
• extended rotation — Тоже что и фреймбуфер, но ещё позволяет отображать глубину цвета 8 бит на пиксель, а также поддерживает скроллинг, масштабирование и вращение, кроме того может использовать альфа-бит;
• large bitmap — Большие 512х1024 или 1024х512 изображения с 8 битами на пиксель.

В статье рассматриваются основы разработки программного обеспечения для Nintendo DS под Linux. Впрочем все используемые инструменты кроссплатформенные и не должно быть больших отличий для других ОС.

Для начала разберёмся, что же вообще из себя представляет эта игровая консоль. Вот, что нам говорит википедия:
* Процессор: ARM946E-S — 67 Мгц, сопроцессор ARM7TDMI — 33 МГц
* Память: 4 МБ, 656 КБ видео памяти, 512КБ памяти для текстур
* Экран: два отдельных ЖК-дисплея, диагональ 77 мм (3 дюйма), разрешение 256х192 пикселей, до 260 тысяч цветов. Расстояние между экранами — примерно 21 мм, что эквивалентно 92 «скрытым» строкам.
* Видеосистема: Поддержка 2D и 3D (T&L, преобразование координат текстур, маппинг текстур, альфа-смешивание, сглаживание, цел-шейдинг и Z-буферизация), теоретически позволяет отрисовывать 120 000 полигонов в сек (однако, имеет ограничение на отрисовку 6144 вершин или 2048 треугольников за один кадр).
* Звук: Стерео, 16-канальный ADPCM/PCM
* Накопители: 1 слот для собственных катриджей Nintendo DS, 2 слот для катриджей Nintendo Gameboy Advance
* Связь: IEEE 802.11 (Wi-Fi), для соединения используется собственный формат Nintendo. Радиус локальной сети от 10 до 30 метров в зависимости от условий.
* Управление: сенсорный экран, встроенный микрофон для голосовой идентификации, A/B/X/Y кнопки, D-Pad, шифты L/R, кнопки Start и Select
* Время работы: 6-10 часов
* Вес: 275 грамм
* Размеры: 148,7 × 84,7 × 28,9 мм

В серии статей от tyomitch «Компиляция» (тут, тут, тут, тут, тут и здесь) было рассмотрено построение транслятора игрушечного языка jsk, описанного в 4 части.
В качестве back-end для этого транслятора tyomitch предложил реализацию байт-кода и интерпретатор этого байт-кода.

На мой взгляд, более разумным подходом было бы использование существующих решений для backend, например llvm, и следуя принципу «Критика без конкретных предложений — критиканство», я предлагаю вариант реализации этого маленького языка jsk с llvm.

Что это даст для jsk? Настоящую компиляцию, то есть результатом будет исполняемый файл, который не зависит ни от каких runtime, возможность серьезной оптимизации, профилирования кода и автоматически получим документацию по back-end (что облегчит сопровождение).

Приветствую хабраюзеров, в этой статье пойдет речь о внутреннем устройстве компилятора LLVM. О том, что LLVM вообще такое, можно прочитать здесь или на llvm.org. Как известно, LLVM (условно) состоит из трех частей — байткода, стратегии компиляции и окружения aka LLVM infrastructure. Я рассмотрю последнее.

Содержание:

• Сборка LLVM
• Привязка к Eclipse
• Архитектура окружения
• LLVM API
• Оптимизация Hello, World!

File names are infinite in length, where infinity is set to 255 characters.
--Peter Collinson: The Unix File System

Итак, у нас есть программа на п-коде, и в её распоряжении неограниченное количество регистров (т.е. 255). Число регистров у реального процессора куда меньше (предположим, четыре). Что будем делать?

Далее в посте:

1. Разбор п-кода
2. Время жизни
3. Реализация
4. Простые оптимизации
5. Расщепление версий
6. Работа с памятью
7. Что получилось?