DMZ

Point-to-Point Protocol (PPP)

Point-to-Point Protocol (PPP)

Stephen M Blackburn

Perry Cheng

Kathryn S McKinley

Myths and Realities: The Performance Impact of Garbage Collection

sha1: bc5e29e236d5f2c4bcba838c72a0bb353fd2c3ea

A Unified Theory of Garbage Collection

David F. Bacon

Perry Cheng

V.T. Rajan

A Unified Theory of Garbage Collection

sha1: 91dca25f8cb407fc68218f7d5adb912e7db35e81

The quick and dirty fix for STM32_F105-07_F2xx_USB-Host-Device_Lib_V2.0.0 block offset overflow is here: https://gist.github.com/2202952 A bit ugly, but the whole library is ugly enough to ignore this. Hopefully, you will able to find this record with search engines

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

https://github.com/voidlizard/hwshow

Words extracting tool

Usage
-----

hwshow file offset le|be w8|w16|w32|w64 hex|dec|bin

    file        ---  filename to extract the word
    offset      ---  the offset to extract from
    le|be       ---  little endian / big endian
    wXX         ---  word size (8/16/32/64)
    hex|dec|bin ---  output format

Example:

$:~/hwshow$ ./hwshow ./hwshow 12340 le w32 b
111011100010101010010010111000110

С хорошими универсальными системами сборки сейчас дела обстоят неважно. Если для отдельных языков есть неплохие системы, то универсальных, language agnostic, немного, и они несколько далеки от идеала. На мой взгляд, ближе всего к нему пока что находится Make, как ни странно.

С другой стороны, что такое хорошая система сборки? Для меня список требований к ней выглядит примерно следующим образом:

1) Проста в освоении. Не сложнее, чем Make

Требующая читать документации не больше, чем требует Make.

2) Имеет разумные умолчания, позволяющие собирать простые проекты или сделать заготовку для проекта с нуля, ничего еще о этой системе не зная.

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

Примеры подобных систем есть, например, ocamlbuild. Может быть, он не столь хорош в прочих аспектах, но в этом — вполне.

3) Создает минимум мусора

Не заставляет создавать много файлов в дереве проекта. Модульность должна быть, но при этом добровольная. Генерируемые системой файлы, необходимые для ее работы, идут в специальный каталог, например, .build/. Туда же отправляются файлы, создаваемые при сборке —- объектные, предкомпилированные заголовки, файлы зависимостей, и прочие. Как внутри устроен этот .build/ — личное дело системы, главное что бы по дереву проекта автоматически генерируемый мусор не распространялся без явно предпринятых мер к этому.

Иногда это требование создает проблемы: например, объектные файлы, получаемые их разных файлов с одинаковыми именами — это проблема.

В случае Make это легко решается введением явных правил, которые переименовывают объектные файлы. Обычно я такие файлы просто копирую в .build с добавлением уникального суффикса, и считаю их автоматически сгенерированными. Make достаточно гибок, что бы позволить легко справиться с этой ситуацией.

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

4) Имеет (может быть, опционально) Make в качестве бэкенда

Предпосылки здесь следующие:

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

• Make обычно есть в системах

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

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

Сделать это сложно, но можно — наибольшей проблемой тут являются странные не-POSIX системы, типа Windows, где по умолчанию практически отсутствуют системные утилиты и средства для скриптования. Выходом тут видится разработка отдельной опциональной утилиты, типа busybox, которая будет реализовывать нужные команды, отсутствующие в Windows. Хотя, наверное, при наличии MSYS можно эту задачу надолго отложить ну или вообще оставить тем, кому нужно собирать что-то под Windows.

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

5) Является Language-aware и Toolchain-aware

Хороший Language-agnostic инструмент у нас есть, это Make. Сделать language-agnostic инструмент лучше —— задача почти нереализуемая (discuss!).

Разумеется, различные тулчейны должны подключаться.

Начать имеет смысл в первую очередь с тулчейнов для C и C++, так как, как ни странно, ситуация со средствами для их сборки ситуация на текущий момент самая плачевная. Остальные языки имеют достаточно умные компиляторы, собственные неплохие инструменты для сборки, может, не идеальные, но вполне сносные.

6) Осуществляет трекинг зависимостей. Как следует из предыдущего пункта, поскольку система знает о применяемых тулчейнах, то и трекинг вполне может осуществлять при их помощи.

7) Является многопоточной

В случае использования Make-бэкенда это достигается.

8) Обладает мощным, простым, лаконичным, человекопонятным декларативным языком описания процесса сборки.

Разработчики систем сборки с XML в качестве языка конфигурирования в этом месте могут начинать делать сеппуку. XML — исключен! YAML —- теоретически возможен, хотя сомнительно.

9) Позволяет управлять конфигурациями

Слишком очевидно, что бы останавливаться на этом.

10) Обладает минимальными зависимостями

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

Workflow работы над проектом при помощи описываемой системы выглядит так:

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

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

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

Как-то так.

Linear Scan Register Allocation

sha1: 5846668/6f7872145c09b4ed49ff91202842d57f06b1cd46

letits asked: Доброго времени суток. Видел некоторые посты у вас в блоге касающихся ML языков, хотелось бы спросить имели ли вы дело с Caml light и есди имели выгодно ли он отличается от OCaml и прочих ML языков?

Caml Light видел, но дел с ним не имел. под ML-языками имею вввиду в первую очередь SML и всякие диалекты типа Embedded ML, mincaml и т.п —- в общем, различной сложности и проработанности языки, имеющие общую базу. Даже в Haskell прослеживается кое-что от ML, хотя ушел он от них достаточно далеко