Немного радости

Сегодня вышел Rust 0.7. С учетом того, что на один релиз уходит около 3-х месяцев, можно предположить что в следующем году выйдет Rust 1.0, что вообще прекрасно! Ну а пока, можно собрать новую версию этого замечательного компилятора и поглядеть на изменения, написать что-либо интересное и полезное.

Сюрприз от Installd

Вчера мне Installd сюрприз сделал. Конечно, можно сказать что нужно внимательнее читать документацию, но, всей документации не перечитаешь, поэтому сюрпризы не избежны. А суть сюрприза вот в чем.
Возникла задача следующего плана: надо взять приложение A, выпилить из него часть функций, воткнуть новые и в результате получить приложение B. Причем, приложения A и B должны уметь работать параллельно. Каждое из приложений содержит в себе драйвера, демоны и кучу других системных компонентов. Таким образом, на диске, получаем приблизительно такую структуру:

/-- Library
    +--Application Suport
        +-- Company Name
            +--Product A
            +--Product B

Где Product B – директория с системными файлами нового приложения. С учетом того, что инсталляторы в Mac OS X воспринимаются исключительно как автоматизированное средство для копирования файлов, решение было предельно простым: взять уже имеющийся инсталлятор и поменять в нем “Product A” на “Product B”, не забыв поправить конфигурирующие скрипты. Но не тут то было.
Если попытаться установить два продукта параллельно, то начиналась магия: установка продукта A деинсталлировала продукт B и vice versa. Перерыл все логи инсталлятора, греша на pred- и post- install скрипты – ни малейшего намека на то, кто удаляет продукт. Хотел уже было браться за DTrace, но тут коллеги напомнили о fs_usage… Нашелся виновник: installd. Но, казалось бы, причем тут Installd?! А вот при том, что инсталлятор не только распаковывает файлы в нужные директории, но еще и делает “обновление” для пакетов с одинаковыми идентификаторами!

Ментальные карты

При работе над требованиями к новому проекту, при работе над какой-то относительно большой заметкой или статьей или какой-то другой структурированной информацией я одно время активно использовал Mindjet. По большому счету, приложение ну просто всем хорошо кроме своей цены. В стародавние времена лицензия на это приложение стоила порядка 250 долларов, что, конечно, не мало, но оно того стоило. Потом, долгое время я не работал ни над чем таким, где могли бы потребоваться ментальные карты, но на днях необходимость возникла и я полез на сайт производителя, что бы узнать, сколько сейчас стоит эта радость. Ну что сказать, цена меня не обрадовала, так как теперь купить приложение и пользоваться им неограниченное количество времени нельзя, дело в том, что авторы перешли на систему подписок и в год набегает порядка 300 долларов.
Да, само собой, я пишу это не для того что бы порекомендовать покупать столь дорогущее приложения, а для рекламы его аналога – XMind! XMind, как впрочем и Mindjet, является кроссплатформенным приложением и отлично запустился как на моем домашнем Mac OS X, так и на рабочей Ubuntu. С учетом того, что XMind базируется на Eclipse, то он очень прожорлив, но за его “цену”, это очень легко простить, а создаваемы в нем ментальные карты не на много хуже того, что получалось в Mindjet.

Rust 0.3

Вышла новая версия языка Rust с номером 0.3. Несмотря на то, что говорить о каком бы то ни было коммерческом использовании языка рано, он обретает все более и более четкие формы, появляется понимание куда же он движется. Continue reading

Сборка Rust из репозитория

Очень часто, особенно в случае с рабочими машинами, доступ в интернет довольно жестко ограничен и почти все протоколы за исключением HTTP(S) заблокированы. Именно с такой проблемой я и столкнулся пытаясь собрать Rust. Все дело в том, что кроме основного модуля кодовой базы, который можно загрузить по HTTPS, у проекта есть два дополнительных подмодуля, для которых жестко заданна работа через протокол Git. В результате, в процессе сборки, я столкнулся с ошибкой:

configure: git: submodule status
-1170ffba3ac5191930b40c897d4569a9d8a296a3 src/libuv
-3a57b672f89adcb2d2d06adc564dc15ca4e276d6 src/llvm
configure: git: submodule update
fatal: unable to connect to github.com:
github.com[0: 207.97.227.239]: errno=Connection timed out

Continue reading

Clear Case –> Git

Во время работы в ЛК мне казалось, что Perforce это одно из воплощений Песца на земле. Ну что сказать, я сильно ошибался, и теперь, видимо в наказание за мои заблуждения, мне приходится работать с Clear Case. Причем, типичная тут схема работы это основная машина на Венде, на которой разработчик все пишет и сборочная машина на Linux. Доступ к исходникам осуществляется посредством шареных сетевых папок. В целом схема рабочая, но, во-первых, сборка идет довольно медленно, во-вторых, сборку приходится периодически перезапускать из-за сетевых ошибок, таких как broken pipe, input/output error.
Вдоволь намучившись с подобной работой я решил что так дальше жить нельзя и надо что-то делать. Самым лучшим вариантом, пришедшим мне в голову, оказалось использование Git для собственного контроля версий в процессе разработки.
Continue reading

В поисках альтернатив C++

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

Если говорить про Java, то с быстрым прототипированием тут все нормально, в то время как скорость разработки приложений приблизительно такая же•• как и в случае с C++, ну может на 10% быстрее. При этом язык крайне ограниченный, практически до убогости, что после 10 лет разработки на C++ вызывает довольно ощутимое отторжение.

Понимая, что так дело не пойдет, я взялся за поиск приличной альтернативы C++. Изначально подумывал про Erlang, ведь в основном я пишу что-то сетевое, но в итоге от этого варианта решил отказаться, потому как за пределами сетей Erlang мягко говоря бесполезен, а в самих сетях, зачастую, ограничен в плане набора доступных библиотек. В результате довольно долгих поисков выбор остановился на JVM, ведь JVM — это действительно кроссплатформенное решение (в отличие от того же CLR) с большой базой библиотек под нормальными лицензиями (MIT, BSD и, в худшем случае, LGPL). Плюс, в JDK, начиная с 7-й версии, появилась поддержка асинхронного ввода/вывода, т.е. возникла вполне реальная возможность писать не тормозящие где попало сетевые приложения.

К основным языкам базирующимся на JVM, само собой за исключением самой Java, относятся Clojure, Groovy и Scala. Clojure — Lisp-подобный язык, так что отмел его сразу. Да, я к Lisp отношусь хорошо, но вот куча народу вокруг — нет, так что никакой возможности реально использовать что-то Lisp-подобное я не вижу. Groovy — хороший язык, но без чего-то действительно цепляющего. А вот Scala… Да, Scala — это язык с довольно крутой кривой вхождения, при этом богатым синтаксисом и отличными возможностями.

У всех разные способы оценить пригодность языка для своих нужд. Кто-то первым делом реализует быструю сортировку, кто-то пишет Hello World. А я, обычно, пишу Echo-сервер с клиентом. Continue reading

Vim + Cscope

Уже не помню, как я перешел с ctags на cscope, но он реально крайне удобен и всеяден. Небольшой скриптик для автоматического построения/обновления тагов начиная с текущей директории. Работает на редкость шустро.

function! UpdateCscopeDb()
    let extensions = [""*.cpp"", ""*.h"", ""*.hpp"", ""*.inl"", ""*.c"", ""*.java""]
    let update_file_list = "find . -name " . join(extensions, " -o -name ") . " > ./cscope.files"
    echo update_file_list
    echo system(update_file_list)
    echo system("cscope -b")
    cscope kill 0
    cscope add .
endfunction

nmap <F12> :call UpdateCscopeDb()<cr>
vmap <F12> <esc>:call UpdateCscopeDb()<cr>
imap <F12> <esc>:call UpdateCscopeDb()<cr>