Почти каждый программист, который хоть немного любит свою работу и не привязан к конкретному языку программирования, рано или поздно придет к использованию Emacs… или vim… или STE… или еще к одному из множества текстовых редакторов.
Собственно, почему именно Emacs? Причина первая и самая главная — он мне нравится, за причинами же менее вескими, но более объективными добро пожаловать под кат.
1. Особенности работы с переменными и литералами в Perl6
2. Perl6 — Операции над переменными, анонимные блоки
3. Perl6 — Условные операторы, циклы
4. Perl6 — Работа с функциями
5. Perl6 — Классы
6. Perl6 — Ввод-вывод, модули
7. Perl6 — Комментарии, пробельные символы, скобки
8. Perl6 — Перегрузка операторов
9. Perl6 — Работа с типами данных
10. Perl6 — Обработка исключений
В прошлой статье мы говорили об отлове исключений, что происходило в специальном вложенном блоке CATCH. На самом деле этот блок является особой разновидностью — Phasers (я просто не могу перевести это слово). Phasers — это специальные вложенные блоки, которые выполняются при определенных условиях. С чем же их готовить увидите под катом.
Читать полностью »
-regulyarnyh-vyrajeniyah.jpg "Парсер CSS для .NET, написанный на C# (зачёркнуто) регулярных выражениях")
Понадобилось мне однажды распарсить CSS, чтобы вынуть @import, url(). Но для .NET были только разной степени кривоты поделки. Лучшей библиотекой была ExCSS, но она загибалась на таких тривиальных вещах, как медиа-запросы. Поэтому я решил заполнить пробел.
Были варианты: расковырять Chrome, расковырять Firefox, расковырять левую библиотеку. Нужно было гарантированное качество и регулярное обновление, поэтому последний вариант отпадал. В Chrome парсинг CSS и HTML генерировался на основе грамматик, и беглое изучение разнообразия инструментов для .NET повергло в уныние, что уж говорить о совместимости инструментов, поэтому Chrome отпал. Остался Firefox с вручную написанными парсерами.
И здесь начинается интересное: дабы сохранить хоть какую-то возможность обновлять код при выходе новых версий файрфокса, я решил не единожды переписать сорцы, а натравливать на плюсовые сорцы тонны регулярных выражений, и добиваться компилируемости плюсового кода только регулярками.
Я вижу косые взгляды. У кого-то уже тянется рука набирать 03…
В прошлый раз я предложил заглянуть в код MRI, чтобы разобраться с реализацией GIL и ответить на оставшиеся вопросы. Что мы сегодня и сделаем.
Черновая версия этой статьи изобиловала кусками кода на C, однако, из-за этого суть терялась в деталях. В финальной версии почти нет кода, а для любителей поковыряться в исходниках я оставил ссылки на функции, которые упоминал.
После первой части остались два вопроса:
array << nil атомарной операцией?
На первый вопрос можно ответив, взглянув на реализацию, поэтому начнем с него.
Читать полностью »
В 1997 году с появлением Ultima Online игры стали гораздо крупнее. В 1999 масштаб игр опять существенно увеличился после выхода Everquest. Стало возможным строить сложные социальные отношения в виртуальном пространстве и даже иметь виртуальную работу, дающую больший доход чем «реальная» (Это я, «Lee», в статье 2000 года).
Затем верхняя граница снова взлетела до небес с выходом двух игр в 2003 году: EVE Online от CCP и World of Warcraft от Blizzard Entertainment. Обе эти игры стали эталоном «Большой» игры в нашей индустрии, и они всё продолжали становиться больше. Но потом произошла странная вещь.
Ничего не произошло.
Арена «больших» игр превратилась в настоящую Аллею Проклятых, устланную претендентами, потерпевшими фиаско. Миллионы долларов улетели в трубу в этой битве, и инвесторы запаниковали. Было лишь несколько исключений, которые сумели удержаться на плаву, такие как City of Heroes от Cryptic Studio (NCSoft) и Final Fantasy XI от Square Enix. Претендентов, считающих, что их игра должна быть ещё больше, ещё крупнее, ждала жуткая и страшная смерть на рынке. Я мог бы назвать имена, но не думаю, что несколько страниц, испещрённых перечислением потерянных миллиардов инвестиций, будут здесь уместны.
Я лучше расскажу вам секрет, который я храню уже несколько лет. Дело не в масштабе.
Дело в Капитале.
Читать полностью »
Хаскель получает много нелестных отзывов, потому что в нём нет встроенного инструментария для работы с изменениями и состояниями. Поэтому, если мы хотим испечь полный состояний яблочный пирог, нам необходимо для начала создать целую вселенную операторов для работы с состояниями. Однако за это уже заплачено с лихвой и это уже пройденный этап, и сейчас программисты на Хаскеле наслаждаются более элегантным, лаконичным и мощным императивным кодом, чем даже то, что вы можете найти в само-описывающих императивных языках. Впрочем, вы и сами сможете в этом убедится.
Ваш билет к элегантному коду — это библиотека линз (lens). Читать полностью »
Ludum Dare это конкурс разработки игр, в котором люди со всего мира уже более десяти лет собираются, чтобы сделать кучу игр всего за пару дней. Тем, кто сетует на неоригинальность современных игр настоятельно советую приглядеться к данному событию.
Правила конкурса очень просты:
Прямо сейчас идёт выбор темы Ludum Dare 27, уже начался второй раунд голосования.
Читать полностью »
Пять из четырех разработчиков признают, что многопоточное программирование понять непросто.
Большую часть времени, что я провел в Ruby-сообществе, печально известная GIL оставалась для меня темной лошадкой. В этой статье я расскажу о том, как наконец познакомился с GIL поближе.
Первое, что я услышал о GIL, никак не было связано с тем, как она работает или для чего нужна. Все, что я услышал — что GIL — это плохо, поскольку ограничивает параллелизм, или то, что это хорошо, потому что делает код потокобезопасным. Пришло время, я приноровился к многопоточному программированию и понял, что на самом деле все сложнее.
Я хотел знать, как работает GIL с технической точки зрения. На GIL нет ни спецификации, ни документации. По сути, это особенность MRI (Matz's Ruby Implementation). Команда разработчиков MRI ничего не говорит по поводу того, как GIL работает и что гарантирует.
Впрочем, я забегаю вперед.
Читать полностью »
Я обожаю программирование графики! Мы все совершаем ошибки в процессе проектирования и написания кода. Иногда это ошибки логики (когда алгоритм продуман неточно или не до конца), иногда ошибки, возникающие по невнимательности, и ещё много-много вариантов. И что происходит в обычном рабочем процессе? — В списках нет необходимых записей, какие-то числа считаются неверно, вываливаются сообщения об ошибках и прочее. В программировании графики всё немного веселее, ведь часто мы получаем результат, который просто не соответствует ожидаемому. В своём небольшом проекте я решил сохранять такие “результаты” на протяжении всего процесса разработки и хотел бы поделиться ими с Вами.
Всех, кто не любит Android, Live Wallpaper, Minecraft, велосипеды, поток сознания, который слабо привязан к теме и всё около того, хочу сразу предупредить, что их может огорчить содержание этого поста, поэтому продолжайте чтение на свой страх и риск. Оставлю тут также и предупреждение для пользователей мобильного или просто небезлимитного интернета: дальше последует довольно много картинок.
Читать полностью »
1. Введение.
2. Объекты. Начало
Продолжаем разбираться во внутренностях Питона. В прошлый раз мы узнали, как Питон переваривает простую программу. Сегодня начнём изучение устройства его объектной системы.
Как я и писал в предыдущем эпизоде (который, кстати, оказался успешным; спасибо всем, ваши просмотры и комментарии буквально заставляют меня двигаться дальше!) – сегодняшний пост посвящён реализации объектов в Python 3.x. Поначалу я думал, что это простая тема. Но даже когда я прочитал весь код, который нужно было прочитать перед тем, как написать пост, я с трудом могу сказать, что объектная система Питона… гхм, «простая» (и точно не могу сказать, что до конца разобрался в ней). Но я ещё больше убедился, что реализация объектов — хорошая тема для начала. В следующих постах мы увидим, насколько она важна. В то же время, я подозреваю, мало кто, даже среди ветеранов Питона, в полной мере в ней разбирается. Объекты слабо связаны со всем остальным Питоном (при написании поста я мало заглядывал в ./Python и больше изучал ./Objects и ./Include). Мне показалось проще рассматривать реализацию объектов так, будто она вообще не связана со всем остальным. Так, будто это универсальный API на языке C для создания объектных подсистем. Возможно, вам тоже будет проще мыслить таким образом: запомните, всё это всего лишь набор структур и функций для управления этими структурами.
Читать полностью »