LLVM (Low Level Virtual Machine) — это универсальная система анализа, трансформации и оптимизации программ или, как её называют разработчики, «compiler infrastucture».

LLVM — не просто очередной академический проект. Его история началась в 2000 году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии как Apple и Adobe. В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple.

В основе LLVM лежит промежуточное представление кода (intermediate representation, IR), над которым можно производить трансформации во время компиляции, компоновки (linking) и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.

LLVM написана на C++ и портирована на большинство *nix-систем и Windows. Система имеет модульную структуру и может расширяться дополнительными алгоритмами трансформации (compiler passes) и кодогенераторами для новых аппаратных платформ. Пользовательский фронтенд, как правило, линкуется с LLVM и использует C++ API для генерации кода и его преобразований. Однако LLVM включает в себя и standalone утилиты.

Для тех, кто не без оснований считает C++ не лучшим языком для написания компиляторов, с недавних пор в LLVM включена обертка API для OCaml.

Чтобы понять, что можно сделать с помощью LLVM, и на каком уровне придётся работать, давайте разберёмся,

LLVM — это набор «кирпичиков» для построения компиляторов, а clang — новый компилятор C++ на его основе. По сравнению с gcc — обеспечивается большая скорость компиляции при сравнимом качестве кода, более человеко-понятные исходники т.к. они не несут десятилетия жесточайшей C-only разработки как в gcc.

Помимо этого, Clang и llvm распространяются под лицензией BSD, в отличии от GPLv3 у GCC. BSD позволяет не открывать исходники при распространении исполняемых файлов компилятора.

С LLVM+CLang будет интересно поиграть любому кто когда-либо хотел написать свой компилятор, или считает, что компилятор собранный своими руками дает более теплый бинарный код.

БОльшая часть часть разработчиков llvm/clang используют его под Linux/MacOS — и там его сборка/установка не вызывает каких либо проблем, путь основательно протоптан. А вот в случае windows ситуация несколько осложняется — об обходе нескольких граблей при сборке, о том, что связывает clang и gcc, и какие баги придется фиксить в релизе — под катом.

Как часто вам присылают подобные отчеты об ошибке?

Traceback (most recent call last):
...
  File "...", line ..., in ...
    process(lst[index])
IndexError: list index out of range

Ох, если бы только узнать значение lst и index на тот момент...

python-catcher — автоматическая генерация HTML-трейсбеков с локальными переменными и исходниками, + загрузка в интернет — пользуйтесь на здоровье.

Здравствуй, хабрасообщество.
Идея данной темы для обсуждения пришла ко мне довольно давно, но поводом, толкнувшим к собственно тому, чтобы открыть редактор и написать текст, послужило недавнее собеседование. Но обо всём по порядку.

Введение

В 2009–2011 гг. я вёл проект системы управления знаниями (СУЗ) для одной довольно крупной компании. Собственно, этот проект сам по себе является поводом если не цикла статей, то уж двух-трёх точно. Именно в ходе реализации этого проекта я в полный рост столкнулся с одной огромной проблемой — мифологизации информационных технологий. Самое страшное то, что ей подвержены вроде бы взрослые люди, и даже временами выходцы из этой отрасли.

Все более или менее знающие Python разработчики знают про такую жуткую вещь как GIL. Глобальный блокировщик всего процесса до тех пор пока Python выполняется в одном из потоков. Он даёт потоко-защищённость методами сравнимыми с садизмом, поскольку любая неявная блокировка в многопоточном приложении смерти подобна, всё что опиралось на параллельное выполнение, умирает в мучениях, раз за разом натыкаясь на блокировку GIL.
Известно что по сей день из-за этого скорбного факта программисты на C++ используют Python-обёртки по большей части лишь в однопоточных приложениях, а программисты на Python пытаются всех убедить, что им и так неплохо живётся.
Казалось бы, если поток порождён в C++, он не знает ни о каком GIL, используй Python без блокировок и радуйся. Радость разработчика однако закончится уже на втором потоке запросившем область глобальных переменных без блокировки.
Однако есть путь ведущий к светлому будущему!
Этот путь был изначально в таком языке как Perl, он же поддерживается в Си-API языка Python и я ума не приложу почему подобный механизм не включен в один из стандартных модулей Python! Способ по сути сводит использование различных под-интерпретаторов Python в разных потоках, причём используя свой GIL для каждого(!!!) без всякого шаманства и магии, просто последовательно вызвав несколько функций и стандартного набора Си-API языка Python!

Привет хабр!

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

Начну по порядку.

Существует теория диффузии инноваций. Это теория, призванная своим существованием объяснить как, почему и с какой скоростью новые идеи и технологии распространяются в обществе. Главную суть теории, пожалуй, можно выразить одним графиком.


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

Начать, видимо, следует с того, что речь пойдет об интерпретаторе CPython версии 2.7.x (примеры проверялись на версии 2.7.3).

На официальном сайте имеются описания инструкции import и модулей в Python:

• docs.python.org/2/reference/simple_stmts.html#import
• docs.python.org/2/tutorial/modules.html

Из них следует, что в Python имеются пакеты (package), модули (module) и имена, определенные в модулях (names). Также следует отметить, что в некоторых частях документации модули называются подмодулями (submodule), если они размещены внутри пакета.

В языке Python инструкция import позволяет импортировать пакеты, модули и имена в пространство имен, в котором инструкция import выполняется. При это существует две интересные особенности:

1. Из синтаксиса инструкции import не всегда явно следует, что именно должно быть импортированно: пакет, модуль или имя
2. Синтаксисом инструкции import невозможно явно указать, что путь к модулю является абсолютным путем (хотя явно указать, что путь является относительным можно, а также возможно изменение семантики инструкции, в части использования абсолютного пути по умолчанию, см. www.python.org/dev/peps/pep-0328 )

Из этих двух особенностей следуют такие неоднозначности для записи import abcd:

1. Импортировать ПАКЕТ abcd, либо импортировать МОДУЛЬ abcd
2. Импортировать пакет/модуль abcd из ТЕКУЩЕГО ПАКЕТА (из пакета того модуля, в котором исполняется import abcd), либо ИЗ ПАКЕТА в соответствии с перечнем каталогов, указанных в sys.path

Еще примеры неоднозначностей:

• from abcd import defg: (импортировать модуль defg из пакета abcd, либо импортировать пакет defg из пакета abcd, либо импортировать имя defg из пакета abcd, либо импортировать имя defg из модуля abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)
• import abcd.defg: (импортировать пакет defg из пакета abcd, импортировать модуль defg из пакета abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)

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

С тех пор, как один из основателей PayPal, известный инвестор Питер Тиль возмутился, что «вместо обещанных летающих машин мы получили 140 символов», и до недавних жалоб основателя TechCrunch Майкла Аррингтона на сегодняшние инновации, вгоняющие его в тоску, количество разочарованных в инновационном потенциале Силиконовой долины серьезно выросло. Пока основное аппаратное обеспечение, микропроцессоры, инфраструктура и технологии вывода изображения продолжают осваивать новые горизонты, инновации в сфере интернет-продуктов и услуг можно справедливо назвать вторичными и не вызывающими восторга.



Перевод выполнен компанией-локализатором Alconost.

Предыдущая статья носила несколько теоретический характер и породила у читателей массу вопросов.

Что нам дает знание «языка», на котором общается работник с менеджером или менеджер с руководителем? Как это применять на практике? Кому это нужно?

Начнем, пожалуй, с последнего вопроса.

Кому это нужно?

Всем.

Работники хотят показывать начальству свою эффективность, чтобы лучше монетизировать свой труд. Они хотят спокойно трудиться, без авралов, без показательных раздач оплеух, в здоровой атмосфере. Такая себе творческая рабочая нирвана.

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

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

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

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

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

Спец по project management успешно применил принципы PMbok для подготовки к восхождению на Эверест. Это доказывает что PMbok годится не только для ИТ-бизнеса но «нам строить и жить помогает».

Собственно сабж, без ката.

Осторожно! Видео графоманское — почти 2 часа, так что для любителей.

---

МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание

Сущность научной работы — в борьбе с нежеланием работать. [ И. П. Павлов]

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

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

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

На хабре про Udacity уже писали: 1, 2, 3

Пояснение для тех, кто не знает что это такое. Университет Udacity был основан после успешного проекта online курсов, организованных Стэнфордским Университетом. После этих курсов, которые успешно прошли несколько тысяч человек, Себастьян Тран уже не смог вернуться к обычной преподавательской деятельности и обучать 100 человек в аудитории Стенфордского университета, когда есть возможность вести курс для десятка тысяч по всему миру.

Университет открылся 20 февраля 2012 года двумя семинедельными курсами:
CS101: Building a Search Engine
CS373: Programming a Robotic Car

16 апреля запустились ещё 4 курса:
CS212: Design of Computer Programs
CS253: Web Application Engineering
CS262: Programming Languages
CS387: Applied Cryptography

На этой неделе как раз идет final exam. И вот сегодня должна появится новость о запуске 5 новых курсов:
CS215: Algorithms
CS221: Logic & Discrete Mathematics
CS258: Software Testing
PH100: Landmarks in Physics
ST101: Introduction to Statistics

Под катом их описание

UPD Курсы начнутся 25 июня 2012 года
Официальное объявление: udacity.blogspot.com/2012/05/udacity-expands-course-offerings-five.html

Вы уже слышали про Flame? Присаживайтесь поудобнее, сейчас мы предоставим вам все подробности.

Вирусы Duqu и Stuxnet повысили градус кибервойны на Ближнем Востоке, однако недавно мы обнаружили, пожалуй, самое изощренное кибероружие на сегодняшний день. Червь Flame, созданный для кибершпионажа, попал в поле зрения экспертов «Лаборатории Касперского» при проведении исследования по запросу Международного союза электросвязи (МСЭ), обратившегося к нам за содействием в поиске неизвестной вредоносной программы, которая удаляла конфиденциальные данные с компьютеров, расположенных в странах Ближнего Востока. В процессе поиска этой программы, получившей название Wiper, мы обнаружили новый образец вредоносного ПО, который был назван Worm.Win32.Flame.


Семь стран, подвергшихся наибольшему количеству атак

«Лаборатория Касперского» продолжает охоту на вредоносные программы. 28 мая в своем блоге они сообщили, что обнаружили вирус нового вида, который уже около 5 лет сканирует и собирает конфиденциальную информацию с компьютеров по всему Ближнему Востоку.


Фрагмент исходного кода Flame. Изображение с сайта securelist.com

Пост написан из-за появления вчерашних новостей о вирусе-шпионе (например, вот). как ни странно, но проблема защиты промышленных объектов в РФ ставится не так остро, как должна бы… в СМИ очень часто можно услышать про законы о персональных данных, а вот защитой АСУ ТП(системы управления технологическими процессами), похоже, никто особо не занимался (защита критически важных объектов регламентирована документами ФСТЭК, но они имеют гриф и не доступны простым смертным). Для тех же компаний, которые не попали в список этих самых «критически важных», существует только стандарт Газпрома… и все, больше никаких документов и рекомендаций в области защиты АСУ ТП нет.
В США дело обстоит в корне наоборот, и американский US CERT выкладывает в свободный доступ свои рекомендации по защите АСУ ТП. Желающих ознакомиться прошу под кат.

На Хабре множество раз обсуждалась тема декораторов, однако, на мой взгляд, данная статья (выросшая из одного вопроса на stackoverflow) описывает данную тему наиболее понятно и, что немаловажно, является «пошаговым руководством» по использованию декораторов, позволяющим новичку овладеть этой техникой сразу на достойном уровне.

Итак, что же такое «декоратор»?

Впереди достаточно длинная статья, так что, если кто-то спешит — вот пример того, как работают декораторы:

def makebold(fn):
    def wrapped():
        return "<b>" + fn() + "</b>"
    return wrapped
 
def makeitalic(fn):
    def wrapped():
        return "<i>" + fn() + "</i>"
    return wrapped
 
@makebold
@makeitalic
def hello():
    return "hello habr"
 
print hello() ## выведет <b><i>hello habr</i></b>

Про Unsafe в Java не слышал только ленивый, однако это не единственный магический класс в Sun/Oracle JDK, стирающий границы Java платформы и открывающий тропинки, не нанесенные на карту публичного API. Я расскажу про некоторые из них, принесшие пользу в реальных проектах. Но помните: недокументированные возможности лишают ваше приложение переносимости на другие Java платформы и, кроме того, являются потенциальным источником нетривиальных ошибок. Я даже зря написал слово «приложение». Лучше сказать, что описанные ниже классы вовсе не годятся для приложений! Скорее, они представляют интерес лишь для системного ПО и для любознательных программистов, т.е. для вас :)

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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