Rust 0.7
3 июля было объявлено о выходе очередной версии Rust — языка программирования, разрабатываемого Mozilla. Новая версия включает в себя около 2000 изменений и исправлений ошибок.
( читать дальше... )
>>> Подробности
3 июля было объявлено о выходе очередной версии Rust — языка программирования, разрабатываемого Mozilla. Новая версия включает в себя около 2000 изменений и исправлений ошибок.
( читать дальше... )
>>> Подробности
21 апреля вышло минорное обновление GHC 7.6.3 — одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell, который разрабатывается свободной рабочей группой из многочисленных разработчиков, собранных по всему миру и координируемых из лаборатории университета Глазго. Релиз включает в себя только исправления багов.
Вчера вышло минорное обновление GHC 7.6.2 — одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell, который разрабатывается свободной рабочей группой из многочисленных разработчиков, собранных по всему миру и координируемых из лаборатории университета Глазго.
31.12.2012 вышла новая версия Steel Bank Common Lisp, свободной реализации языка программирования Common Lisp.
Основные изменения:
SourceForge:
git clone git://sbcl.git.sourceforge.net/gitroot/sbcl/sbcl.git
>>> Подробности
Наткнулся тут на статью:
Профессор Тошиюки Накагаки (Toshiyuki Nakagaki), биолог и физик из университета Хоккайдо (Япония), взял крошечный кусочек жёлтого плесневого гриба и положил его у входа небольшого лабиринта – 30-ти сантиметровой копии лабиринта, применяющегося обычно для проверки интеллекта и памяти мышей. В другом конце лабиринта он поместил кубик сахара.
Обычно грибы растут вокруг круглой и симметричной сети паутинок, но желтоватый грибок Physarum polycephalum, растущий в природных условиях на листьях и камнях, вёл себя совершенно иначе. Он как будто издалека почувствовал запах сахара и начал посылать на его поиски свои ростки. Паутинки гриба раздваивались на каждом перекрёстке лабиринта и те из них, кто попадал в тупик, разворачивались и начинали искать путь в других направлениях. В течение нескольких часов грибные паутинки заполнили проходы лабиринта и к концу того же дня одна из их них нашла дорогу к сахару.
После этого Тошиюки и группа его исследователей взяли маленький кусочек паутинки гриба, участвовавшей в первом опыте, положили его у входа точной и пустой копии того же лабиринта, также с кубиком сахара на другом его конце. То, что произошло дальше, не мог бы предсказать никто. В первое же мгновение паутинка разветвилась на две: один тонкий и точный отросток проложил свой путь прямо к сахару без единого лишнего поворота. Второй отросток паутинки вскарабкался на стену лабиринта и пересёк лабиринт по прямой линии, по потолку, прямо к цели. Грибная паутинка не только запомнила дорогу, но и изменила правила игры. Опыт повторяли снова и снова и с разными лабиринтами. В одном из опытов учёные положили два кубика сахара – по одному у каждого из двух выходов из лабиринта. Паутине хватило одного опыта, чтобы узнать, на каком перекрёстке разветвиться и кратчайшим путём добраться до сахарных кубиков.
«Я впервые подумал об этом опыте в тот момент, когда мысленно осмелился сопротивляться естественной склонности относиться к этим созданиям как к растениям,» – говорит Тошиюки в своём телефонном интервью изданию «Мосаф калкалист» – «После того, как ты занимаешься исследованиями грибов в течение нескольких лет, ты обращаешь внимание на две вещи. Первое это то, что грибы ближе к животному миру, чем это кажется. Второе, что их поведение иногда выглядит как результат сознательного решения, а не как проявление просто инстинкта. Я подумал, что грибам стоит дать возможность попробовать решить загадки, чтобы лучше понять что происходит.»
Это исследование удостоилось резонанса в мировом масштабе, было опубликовано в самом известном в мире научном журнале «Природа» («Nature»), а его участники даже удостоились приза Игнобель – «за исследования, которые сначала заставляют смеяться, а потом - задуматься» – за 2008 год. В прошлом году Тошиюки вторично удостоился приза Игнобель, на этот раз за исследование, обнаружившее, что грибы могут планировать транспортные маршруты не хуже инженеров-профессионалов, но намного быстрее последних. Тошиюки взял карту Японии и поместил кусочки пищи в местах, соответствующих большим городам страны. Грибы он положил «на Токио» и подождал 23 часа – время, необходимое грибам, чтобы построить линейную сеть паутинок ко всем кусочкам пищи. В результате получилась почти точная копия железнодорожной сети вокруг Токио. «Надо понимать, что это не так уж сложно - соединить несколько десятков точек; а вот соединить их эффективно и наиболее экономно – это уже совсем не просто,» – хвалит грибы Тошиюки. Когда провели подобные эксперименты на картах Англии и Испании, то получили точные модели сетей шоссейных дорог, существующих в этих странах, включая, в некоторых случаях, расширения и изменения, сделанные в последнее время из-за неоптимального изначального планирования. В эти дни в университете Хоккайдо пробуют перенести эту удивительную способность гриба на компьютерную модель. «Я верю, что то, что мы изучаем сейчас, поможет в будущем не только понять, как строить инфраструктуру с улучшенную архитектурой, но и как строить более эффективные и быстрые информационные сети,» – говорит Тошиюки.
Источник: http://xn--b1adef0ban2h.com.ua/popularly/266-griby-kollektivnyj-razum
Дискасс.
R5RS, 7.1.1 Lexical structure:
<identifier> --> <initial> <subsequent>* | <peculiar identifier>
<initial> --> <letter> | <special initial>
<letter> --> a | b | c | ... | z
<special initial> --> ! | $ | % | & | * | / | : | < | = | > | ? | ^ | _ | ~
<subsequent> --> <initial> | <digit> | <special subsequent>
<digit> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<special subsequent> --> + | - | . | @
<peculiar identifier> --> + | - | ...
<syntactic keyword> --> <expression keyword>
| else | => | define
| unquote | unquote-splicing
<expression keyword> --> quote | lambda | if
| set! | begin | cond | and | or | case
| let | let* | letrec | do | delay
| quasiquote
Наткнулся на дарксайде на следующую информацию: 3 декабря в Минске выступают вместе Morbid Angel, Kreator и Nile. Отлично. Однако от стоимости билетов мне поплохело, стоимость билетов на концерт каждой группы по отдельности будет раз в 50 меньше (в Москве). Теперь главный вопрос: откуда такие цены?
Представлен очередной релиз языка Ceylon M4 «Analytical Engine». Ceylon — это JVM-язык, предназначенный для написания бизнес-приложений и разрабатываемый компанией RedHat. На текущий момент спецификация языка реализована почти полностью для виртуальных машин Java и JavaScript. Новые модули доступны в репозитории Ceylon Herd. Основные изменения:
Следующие языковые возможности не поддерживаются в M4:
Также доступна новая версия Ceylon IDE M4, представляющая собой plugin для Eclipse.
>>> Подробности
ITER (ИТЭР) — проект международного экспериментального термоядерного реактора. Задача ИТЭР заключается в демонстрации возможности коммерческого использования термоядерного реактора и решении физических и технологических проблем, которые могут встретиться на этом пути. Проектирование реактора полностью закончено и выбрано место для его строительства — исследовательский центр Кадараш (фр. Cadarache) на юге Франции, в 60 км от Марселя. В настоящее время (по состоянию на март 2012 г.) близятся к завершению работы по созданию железобетонного фундамента под реактор и возведению стен в котловане. Стройку, стоимость которой первоначально оценивалась в 5 миллиардов евро, первоначально планировалось закончить в 2016 году, однако постепенно предполагаемая сумма расходов выросла вдвое, и затем срок начала экспериментов сдвинулся к 2020 году.
Взлетит или нет?
В связи с недавним посещением выступления Behemoth возник вопрос: почему в чорном митоле распространена замена «of» на «ov»? Например песни у Behemoth: «Ov fire and the void», «The reign ov Shemsu-Hor». Или псевдоним бывшего басиста Gorgoroth - «King ov Hell». Беглое гугление ничего внятного не выдает, но я верю что местные специалисты знают ответ и на этот вопрос.
Привет ЛОР. Дело в том что есть один системный блок и у него проблемы с запуском. Т.е. вечером я нажимаю кнопку запуска и запуск происходит через 5-10 минут (и этот промежуток постепенно увеличивается). За 1-2 месяца до начала симптомов сменил процессор с Core2Duo E7200 на CoreQuad Q6600. В какую сторону копать?
Автор C++, Страуструп сотоварищи, пишет в соавторстве статью о новой библиотеке для диспетчеризации по типам с помощью внешней интроспекции. Написано на шаблонах C++11 и оформлено в виде библиотеки. Называется Mach7. Выглядит в итоге как-то так:
int eval (const Expr& e)
{
Match(e)
Case(const Value& x) return x.value;
Case(const Plus& x) return eval (x. e1)+eval(x. e2);
Case(const Minus& x) return eval(x. e1)−eval(x. e2);
Case(const Times& x) return eval(x. e1)∗eval(x. e2);
Case(const Divide& x) return eval(x. e1)/eval(x. e2);
EndMatch
}
Теперь о том, что заинтересовало меня. В статье есть периодические отсылки к функциональному программированию.
Нет, не так. Давайте с начала. В объектно-ориентированном языке без прямой поддержки алгебраических типов данных, тип, представляющий дерево выражения какого-то языка, обычно будет написан как абстрактный класс, с производными классами, реализующими более конкретные варианты.
struct Expr { virtual int eval () = 0; };
struct Value : Expr { ⋯ int eval (); int value ; };
struct Plus : Expr { ⋯ Expr& e1; Expr& e2; };
Ну, то есть, хотим-то мы, наверное, как раз открытый подход, который подсмотрели из функционального программирования с его сопоставлением с образцом, но он слишком дорог с точки зрения CPU, если делать в лоб. Поэтому сделали Mach7, вот эту самую библиотеку на шаблонах, которая реализует открытый подход, но при этом не страдает по производительности, как если бы использовался тест на принадлежность к классу.
Насколько быстро теперь работает? Говорят, примерно как OCaml или Haskell: Библиотека реализована как стандартный C++11 код с шаблонным мета-программированием и несколькими макросами. Оно работает примерно также быстро, как эквиваленты на OCaml или Haskell, и даже иногда приближается по быстродействию или даже становится быстрее написанного руками C++ кода, который использует Visitor дизайн-паттерн.
Ну это хорошо, что так быстро, как OCaml или Haskell. Вопрос, зачем при таком раскладе использовать C++, замнём для ясности.
Но дальше вообще прелесть идёт: критика паттерна Visitor! Библиотека Mach7 и идеи в ней были мотивирована нашим неудовлетворительным опытом работы с различными C++-ными фронт-эндами и фреймворками для анализа программ. Проблема была не с самими фреймворками, но с фактом, что мы должны были использовать шаблон проектирования Visitor для того, чтобы смотреть, обходить и обогощать абстрактные синтаксические деревья целевых языков. Мы нашли Visitor-шаблоны неподходящими для прямого выражения логики приложения, удивительно сложными для обучения студентов, и часто более медленными, чем решения для обхода, написанные вручную. Вместо них, пользователи опирались на динамические приведения типов во многих местах, часто многоуровневые, таким образом предпочитая более короткий, более ясный, и более прямой код, нежели чем Visitor'ы. Соответствующий проигрыш в производительности был обычно незамечаем до более поздних стадий кодирования, когда уже было поздно что-то менять.
Ну можно поздравить C++, теперь можно на нём отдельные вещи писать почти так же коротко, ясно и почти так же быстро, как на OCaml.
Кроме функциональщины, в посте есть отсылка к лиспу, к Duff's device, и вообще, хорошая статья, надо студентам давать. C++ — это очень большой, огромный джип, и эта статья — неплохая иллюстрация.
Вышла новая версия GHC 7.6.1 — одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell, который разрабатывается свободной рабочей группой из многочисленных разработчиков, собранных по всему миру и координируемых из лаборатории университета Глазго.
Основные изменения:
>>> Подробности
host encyrtid # emerge -av qemulator
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N *] app-emulation/qemulator-0.5 752 kB
Total: 1 package (1 new), Size of downloads: 752 kB
The following keyword changes are necessary to proceed:
#required by qemulator (argument)
=app-emulation/qemulator-0.5 **
NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.
Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
Что он хочет от меня?
Возможно ли в tilda сменить дефолтные сочетания клавиш для управления табами? А то я что-то не нашел.
Кто ездил? ITT делимся впечатлениями, ругаем/хвалим организаторов, вбрасываем на тему ненужности и т.д.
Как это было:
http://imglink.ru/show-image.php?id=a8dfaef7fbacbdaa37dc83b94a4204fd
http://imglink.ru/show-image.php?id=6db35ab1288cafffba1a260a2b82570f
http://imglink.ru/show-image.php?id=18610673d7e0a36eed505b776b4898af
http://imglink.ru/show-image.php?id=856ac2580eeea9d498d4929d45b2f1a8
http://imglink.ru/show-image.php?id=4feb029addb9a1a54135e512166e2662
http://imglink.ru/show-image.php?id=1bbab0561d42609c2c937990cec3605f
http://imglink.ru/show-image.php?id=4d1bea11074668bc05a7d55c697db984
Вышла новая версия GHC 7.4.2 — одного из самых мощных и развитых на сегодняшний день компиляторов функционального языка программирования Haskell, который разрабатывается свободной рабочей группой из многочисленных разработчиков, собранных по всему миру и координируемых из лаборатории университета Глазго.
7.4.2 — bugfix-релиз, исправлено более 30 различных ошибок в компиляторе, интерпретаторе и библиотеках.
>>> Подробности
Попробовал собрать pypy, сборка падает с сообщением:
localhost encyrtid # emerge -v --oneshot pypy
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/pypy-1.9 USE="bzip2 jit ssl xml -doc -examples -ncurses -sandbox -shadowstack -sqlite" 13,151 kB
Total: 1 package (1 new), Size of downloads: 13,151 kB
>>> Verifying ebuild manifests
>>> Running pre-merge checks for dev-python/pypy-1.9
* Checking for at least 4 gibibytes RAM ... [ !! ]
* There is NOT at least 4 gibibytes RAM
*
* Space constrains set in the ebuild were not met!
* The build will most probably fail, you should enhance the space
* as per failed tests.
*
* ERROR: dev-python/pypy-1.9 failed (pretend phase):
* Build requirements not met!
*
* Call stack:
* ebuild.sh, line 85: Called pkg_pretend
* pypy-1.9.ebuild, line 36: Called check-reqs_pkg_pretend
* check-reqs.eclass, line 104: Called check-reqs_pkg_setup
* check-reqs.eclass, line 95: Called check-reqs_output
* check-reqs.eclass, line 236: Called die
* The specific snippet of code:
* [[ ${EBUILD_PHASE} == "pretend" && -z ${I_KNOW_WHAT_I_AM_DOING} ]] && \
* die "Build requirements not met!"
*
* If you need support, post the output of `emerge --info '=dev-python/pypy-1.9'`,
* the complete build log and the output of `emerge -pqv '=dev-python/pypy-1.9'`.
* The complete build log is located at '/var/tmp/portage/dev-python/pypy-1.9/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-python/pypy-1.9/temp/die.env'.
* Working directory: '/var/tmp/portage/dev-python/pypy-1.9'
* S: '/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9'
* Messages for package dev-python/pypy-1.9:
* There is NOT at least 4 gibibytes RAM
*
* Space constrains set in the ebuild were not met!
* The build will most probably fail, you should enhance the space
* as per failed tests.
*
* ERROR: dev-python/pypy-1.9 failed (pretend phase):
* Build requirements not met!
*
* Call stack:
* ebuild.sh, line 85: Called pkg_pretend
* pypy-1.9.ebuild, line 36: Called check-reqs_pkg_pretend
* check-reqs.eclass, line 104: Called check-reqs_pkg_setup
* check-reqs.eclass, line 95: Called check-reqs_output
* check-reqs.eclass, line 236: Called die
* The specific snippet of code:
* [[ ${EBUILD_PHASE} == "pretend" && -z ${I_KNOW_WHAT_I_AM_DOING} ]] && \
* die "Build requirements not met!"
*
* If you need support, post the output of `emerge --info '=dev-python/pypy-1.9'`,
* the complete build log and the output of `emerge -pqv '=dev-python/pypy-1.9'`.
* The complete build log is located at '/var/tmp/portage/dev-python/pypy-1.9/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-python/pypy-1.9/temp/die.env'.
* Working directory: '/var/tmp/portage/dev-python/pypy-1.9'
* S: '/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9'
← предыдущие | следующие → |