Сложно в это поверить, но современный процессор является самым сложным готовым продуктом на Земле – а ведь, казалось бы, чего сложного в этом куске железа?



Как и обещал – подробный рассказ о том, как делают процессоры… начиная с песка. Все, что вы хотели знать, но боялись спросить )

Добрый день. Хотелось бы поделиться с Вами очень интересным вариантом ненормального прграммирования — составлением нормальных алгоритмов Маркова. Этот вариант программирования может служить великолепным умственным отдыхом от привычных языков и сред программирования.
Студенты, которых я имею возможность учить, кричат криком, что это сложно, но только до первого собственными руками сделанного рабочего алгоритма, потом это перетекает в очень интересные алгоритмические задачки.
Собственно, к теме этого поста: наша задача написать нормальный алгоритм Маркова для деления двух целых чисел с точностью 4 знака после запятой(для задания чисел пользуемся унарной системой исчисления). Например, вход: |/||||, выход: 0.25.
При этом у нас есть только одна операция — замена одной подстроки в исходной строке на другую. Кому интересно что это такое и как это работает — добро пожаловать под кат.

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

Грубо говоря, проблема в том, что в браузере работает javascript, а на сервере его нет. Нужно либо писать интерпретатор js на одном из серверных языков (jParser и jTokenizer), либо ставить на сервер браузер, посылать в него запросы и вытаскивать итоговое dom-дерево.

В древности в таких случаях мы строили свой велосипед: на отдельной машине запускали браузер, в нем js, который постоянно стучался на сервер и получал от него задания (джобы), сам сайт грузился в iframe, а скрипт извне отправлял dom-дерево ифрейма обратно на сервер.

Сейчас появились более продвинутые средства — xulrunner (crowbar) и watir. Первый — безголовый firefox. У crowbar есть даже ff-плагин для визуального выделения нужных данных, который генерит специальный парсер-js-код, однако там не поддерживаются cookies, а допиливать неохота. Watir позиционируется разработчиками как средство отладки, но мы будем его использовать по прямому назначению и в качестве примера вытащим какие-нибудь данные с сайта travelocity.com.

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

В первую очередь для всех имеющихся у нас окислительно-восстановительных реакций мы стали показывать соответствующие полуреакции.
Например, вот так:

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

Мне кажется правильным начать этот блог с темы, которая вдохновила меня в первую очередь. Не так давно я наткнулся на статью Jamey Pittman «Pac-Man Dossier», в которой приводилось очень детальное описание механики игры Pac-Man. Она показалась мне очень интересной, поэтому этот сайт — попытка собрать такую же детальную информацию об остальных играх. Но в дань уважения я все же начну с Pac-Man, а в частности, с описания алгоритма поведения привидений. Это очень интересная тема и, надеюсь, мое объяснение будет немного более понятным и доступным, чем у Джейми, потому что я сосредоточусь лишь на поведении.

Об игре:

«В то время все доступные игры были очень жестокими — игры о войне и космических захватчиках. Не было ни одной игры для всех сразу, а особенно, которые понравились бы девушкам. Я хотел придумать «комическую» игру, которой могли бы наслаждаться даже девушки»
— Toru Iwatani, создатель Pac-Man

[прим. пер.: продолжение перевода. первая часть, вторая часть]

Связные списки

В OCaml, так же как в Perl, есть встроенная на уровне языка поддержка списков. Все элементы списка должны быть одного типа. Для определения типа используется выражение:

[1; 2; 3]

Обратите внимание: точка с запятой, а не запятая.

[] означает пустой список.

У списка есть голова (первый элемент) и хвост (остальные элементы, кроме головы). Голова — элемент. Хвост — список. В вышеприведённом примере голова — целое число 1, а хвост — список [2; 3].

Альтернативной формой записи является использование оператора конструирования (cons) в форме head :: tail. Нижеприведённые строки полностью эквивалентны друг другу.

[1; 2; 3]
1 :: [2; 3]
1 :: 2 :: [3]
1 :: 2 :: 3 :: []

Зачем мы упомянули оператор конструирования? Он полезен когда мы начинаем сопоставление с образцом для списков, мы обсудим это чуть позже.

Тип данных для связного списка

Тип данных для связного списка целых будет int list; общий тип для связного списка объектов типа foo будет foo list.

VS

Как я посмотрел, на Хабре уже несколько раз поднималась тема «Федеральный Закон №152 и социальная сеть „Вконтакте“. Но я добавлю ещё пару копеек, ибо считаю это достаточно важным замечанием, которое, быть может, заставит кого-то задуматься.

Здравствуйте!

В свое время я не без удовольствия прочитал замечательную статью «Гитаризм для линуксоида — why not?». И решил написать небольшое продолжение этой статьи и рассказать о некоторых вещах более практического плана, а именно создать небольшое руководство для тех, кто, скажем, неожиданно решил увековечить свое творчество путем записи относительно непростого гитарного произведения. :)
Итак, поехали.

Нечем заняться? тогда может быть просто написать 3D Console Software Rendering?
Добро пожаловать под кат!

Пару месяцев назад нами (2Товарища и Антон Исайкин) была обнаружена уязвимость, присущая в основном большим интернет-проектам (вроде Рамблера, Мейла, Яндекса, Оперы и пр.). Удалось получить доступ к файловым структурам известнейших сайтов (в общей сложности 3320 сайтов) и в ряде случаев их полные исходные коды.

Перед тем, как перейти собственно к возможностям Stackless и Concurrence, рассмотрим самый простой способ написать сетевое приложение, обрабатывающее несколько одновременных соединений:

socket()
bind()
listen()
accept()
fork() ->
    read()
    write()
    ...
    close()

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

Проблема: При настройке переключения раскладок на ctrl+shift горячие клавиши вида ctrl+shift+ отказываются работать.
Оказывается совсем недавно (буквально месяц назад) Илья Муравьев написал патч, исправляющий данное недоразумение. Суть сводится к тому что переключение языка после патча срабатывает не на нажатие, а на отпускание кнопок ctrl+shift.

Тема про баг четырехлетней давности на лаунчпаде и на фридесктоп.орг. Сам патч.