Ранее, выше я уже писал о непростой судьбе интерпретируемых языков Python, Ruby и сложности реализации эффективных JIT компиляторов для этих языков, что ограничивает их развитие и применение, во многом из их динамической природы и концепций, основанных на динамизме типов данных.
Сложности в дальнейшем развитии проекта Pyston это лишний раз подтверждают.

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

Переданный параметр может быть указателем на код функции и тогда это first class function, и если это указатель на вложенную функцию, которая возвращает данные в эту же функцию, то это closure/замыкание.
Либо параметр может иметь указатель на код функции, возвращающей другой кадр стэка и соответственно контекст в эту же функцию, или даже вызывать другую функцию, возвращая ей этот контекст, которая в свою очередь уже возвращает стэк/контекст вызова или уже финальные данные в эту начальную функцию.
Такая передача контекстов через параметры функций называется continuation passing style, а передающие контекст функции называются продолжениями (continuations).
Таким образом происходит вызов функций по цепочке с сохранением контекста каждого вызова.
В цепочку вызовов функций (рутин, routine) с сохранением контекста раскладываются вложенные и рекурсивные вызовы функций и вызовы сопрограмм (корутин, coroutine).
Это и происходит на низком уровне при вызове сопрограмм - итераторов, генераторов, горутин, файберов, потоков/нитей, etc., т.е. многопоточных и асинхронных высокоуровневых конструкций, которые переводятся в итоге на низком уровне в сопрограммы.
Это увеличивает сложность компилятора, потому что требуется отследить все вызовы, чтобы выстроить всю цепочку вызовов и отследить время существания всех кадров стэка и контекстов вызова для последующего освобождения памяти.
Сложность рекурсивного вызова выше чем вложенного.
Рекурсивный циклический вызов может быть бесконечным и его цепочку отследить сложнее.
Для этого компилятор должен уметь выполнять оптимизацию циклов и оптимизацию хвостовой рекурсии (tail recursion optimization), т.е. оптимизацию вызовов при возврате из одной функции и передаче контекста вызова в другую.
В итоге стэк может быть переполнен, т.к. заранее неизвестно сколько памяти нужно выделить под стэк, потому что неизвестно сколько циклов вызовов будет прежде, чем произойдёт возврат данных в начальную функцию, т.е. количество вызовов и длина всей цепочки вызовов изначально неизвестна компилятору.
Также учитывая многосвязность вызовов через указатели и кадров стэка, хранящих контекст вызова, очевидно, что структура данных типа стэк (буфер first-in last-out) уже не подходит для хранения контекста всех вызовов, т.к. такая многосвязность множественных кадров стэка через указатели порождает структуру данных cactus stack (parent pointer tree) типа in-tree дерево или многосвязный граф, для хранения которого используется структура данных типа куча (binary heap), под которую происходит динамическое выделение памяти ядром ОС уже в более медленной основной RAM, тогда как для выделения стэка, благодаря его заранее известному и ограниченному размеру, используются регистры процессора и более быстрая регистровая кэш память процессора.
Плюс структура данных типа стэк, благодаря своей упорядоченности, проще и быстрее в работе, обработке и обращении с ней
Это и есть проблема funarg, аргументов/параметров функций, которая сводится в итоге к фундаментальным ограничениям машинной архитектуры и задержкам динамической оперативной памяти.

#сложновато

Evan Shaw в интервью весьма верно отметил, что компилятор Go и его GC достаточно умно спроектированы, чтобы в зависимости от ситуации выбрать размещение контекста гоурутин и функций в стэке или в куче и грядущий релиз Go 1.8 с субмиллисекундными! задержками работы GC с памятью прекрасно это доказывает. (1)
При каждом обращении к куче увеличиваются задержки из-за её размещения в более медленной RAM памяти.
Задержка может происходить при размещении контекста вызова в куче либо при извлечении контекста вызова из неё, отсюда различают проблему восходящих и низходящих аргументов/параметров функций (funarg).

Недавно нашёл толковое и простое определение проблемы funarg:

Nested functions may in certain situations (and languages) lead to the creation of a closure. If it is possible for the nested function to escape the enclosing function, for example if functions are first class objects and a nested function is passed to another function or returned from the enclosing function, then a closure is created and calls to this function can access the environment of the original function. The frame of the immediately enclosing function must continue to be alive until the last referencing closure dies and non-local automatic variables referenced in closures can therefore not be stack allocated. This is known as the funarg problem and is a key reason why nested functions was not implemented in some simpler languages as it significantly complicates code generation and analysis, especially when functions are nested to various levels, sharing different parts of their environment.

Funarg problem

Continuation

Continuation-passing style (CPS)

Call with current continuation (call/cc)

Parent pointer tree

Основной репозиторий Python и разработку эталонного интерпретатора CPython полностью перенесли на Git и хостинг проектов GitHub.
Решение было принято 1 января 2017 года, однако обсуждение предложения о миграции кодовой базы проекта происходило с ноября 2014 года.
Ранее в 2009 году разработка была переведена с репозитория Subversion на систему управления версиями Mercurial, которая в свою очередь реализована на языке Python.
Тесты производительности и эффективности хранения регулярно показывают превосходство Git над другими распределенными системами управления исходными текстами, Mercurial и Bazaar.
Перенос основного репозитория Python на GitHub также поможет вовлечь большую аудиторию в разработку CPython.

Пуск! 🚀🛰

Красивая визуализация того, как распространяется "синапс" между "нейронами" разных слоёв нейросети во время её обучения. Разноцветные многоуровневые графы с миллионами вершин и связей, очень красиво. Если вы что-нибудь слышали про слои, нейроны и обучение нейросетей, смотреть эти картинки ещё интереснее. И тем более читать описания 🤓

http://www.wired.co.uk/gallery/machine-learning-graphcore-pictures-inside-ai

Здесь ещё картинки и больше текста:
https://www.graphcore.ai/blog/what-does-machine-learning-look-like

В мессенджере Signal, с упором на приватность и безопасность обмена информацией, сделали видеозвонки

https://whispersystems.org/blog/signal-video-calls-beta/

https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms

Ждём приватных аудио и видеозвонков с потоковым шифрованием в Telegram.

Трансляция TensorFlow Developer Summit 2017

Live Stream:
https://youtu.be/LqLyrl-agOw

https://events.withgoogle.com/tensorflow-dev-summit/

Сегодня состоялся релиз версии 1.0 библиотеки для глубокого машинного обучения TensorFlow:

https://github.com/tensorflow/tensorflow/releases/tag/v1.0.0

#tfdevsummit
#tensorflow

Плэйлист с нарезкой видео из вчерашней трансляции TensorFlow Developer Summit 2017

https://www.youtube.com/playlist?list=PLOU2XLYxmsIKGc_NBoIhTn2Qhraji53cv

Две самые годные книги по шаблонам проектирования, которые применимы не только для JavaScript:

Стоян Стефанов, JavaScript - Шаблоны проектирования

Эдди Османи, Learning JavaScript Design Patterns

После прочтения этих книг могу только одно сказать - не будьте пленниками шаблонного мышления! Каждый проект уникален по своему! Изучайте архитектурные парадигмы и концепции языков! Процессы тестирования и обеспечение качества! Это самый верный способ писать лучший код!

#books

Создатель языка Rust Грейдон Хоар (Graydon Hoare), работавший в Mozilla и передавший ещё в конце августа 2013-го года управление развитием Rust Брайану Андерсону, недавно обнаружил себя в мэйл рассылке разработчиков Swift работая уже в Apple. 😳

Интересная перестановка, учитывая что автор Swift Крис Лэттнер покинул Apple и теперь управляет разработкой софта автопилотов в Tesla Motors.

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170123/003899.html

https://mail.mozilla.org/pipermail/rust-dev/2013-August/005426.html


https://keybase.io/graydon

https://twitter.com/graydon_pub

https://twitter.com/graydon2

https://github.com/graydon


https://github.com/brson


https://twitter.com/clattner_llvm

https://github.com/lattner


#greatminds

28 ноября 2017 года с релизом Firefox 57 из браузера удалят движок XUL Runner и поддержку XUL расширений.
Всё из-за того, что XUL Runner старый и не поддерживает многопоточность.
Свой многопоточный движок для исполнения JS кода расширений разрабатывать накладно и Mozilla просто взяли код WebExtensions из Chrome, тем более он открытый - Google одобряет! 😁

Движок расширений на базе WebExtensions сделают совместимым с компонентами движка Servo, используемыми для проекта Quantum - нового компонентного движка браузера Firefox, построенного вокруг основного движка рендеринга HTML страниц Gecko layout engine.

Судя по количеству названий компонентов и движков - в Mozilla уже точно знают каким будет будущий Firefox. 😁

https://wiki.mozilla.org/Quantum

https://opennet.ru/opennews/art.shtml?num=46060

#ломатьдестроить

Сегодня состоялся официальный релиз Go 1.8.

https://blog.golang.org/go1.8

https://golang.org/doc/go1.8

https://github.com/golang/go/tree/release-branch.go1.8

Как я уже писал выше - серьёзно улучшен Garbage Collector в runtime компилятора за счёт упрощения его алгоритмов, благодаря удалению логики множественных циклов обхода стэка, вызывающих блокирующие операции процессора, и внедрению гибридной write barrier логики операций записи и освобождения стэка (https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md).
При этом задержки освобождения и выделения памяти теперь лежат в пределах от 10 до 100 микросекунд (10^-6 секунды).
Но авторы говорят, что пространство для улучшений ещё есть и предстоит ещё много над чем поработать в GC к релизу 1.9.

https://golang.org/doc/go1.8#gc

Об остальных измененях в языке и стандартной библиотеке можно прочитать в Release Notes.

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

Плюс визуальное представление доступнее для понимания, чем просто сухое изложение словами, описанное в книге.

http://cs.usfca.edu/~galles/visualization/Algorithms.html

Вслед за Firefox в репозитории Debian вернули Thunderbird

https://opennet.ru/opennews/art.shtml?num=46070