Информация об изменениях

Сообщение Re[17]: Портирование нитры. от 08.02.2017 19:09

Изменено 08.02.2017 19:13 novitk

Re[17]: Портирование нитры.
Здравствуйте, alex_public, Вы писали:

_>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.

Дедушка без управляемости это уже бабушка, как справедливо заметил Wolfhound. Scala native это 100% Скала. В смысле там только бэкенд другой, фронтенды взяты из jvm версий [Нитра не нужна! ]. "ФронтендЫ" потому что их сейчас два: scalac (прод) и dotty (новый). Все нативные плюшки сделаны через обычные механизмы (аннотации и т.д.).

В данный момент для ГЦ традиционно используют Boehm, потом собираются менять. Это не отменяет конечно, что можно прямо звать malloc, etc, то есть "гибридный" подход в терминологии Влада.

_>Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п.

Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки. Вроде это довольно просто.

_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.

Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.
Re[17]: Портирование нитры.
Здравствуйте, alex_public, Вы писали:

_>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.

Дедушка без управляемости это уже бабушка, как справедливо заметил Wolfhound. Scala native это 100% Скала. В смысле там только бэкенд другой, фронтенды взяты из jvm версий [Нитра не нужна! ]. "ФронтендЫ" потому что их сейчас два: scalac (прод) и dotty (новый). Все нативные плюшки сделаны через обычные механизмы (аннотации и т.д.).

В данный момент для ГЦ традиционно используют Boehm, потом собираются менять. Это не отменяет конечно, что можно прямо звать malloc, etc, то есть "гибридный" подход в терминологии Влада.

_>Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п.

Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Автор говорит, что это довольно просто. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки.

_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.

Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.