Сообщение 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._ должна работать из коробки. Вроде это довольно просто.
_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.
Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.
_>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы 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._ должна работать из коробки.
_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.
Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.
_>О, действительно интересно. Прямо на первой же странице все примеры демонстрируют именно то, о необходимости наличия чего я уже писал в этой теме. А именно: данные на стеке, работа с указателями, прямое выделение памяти, прозрачные вызовы C библиотек, бэкенд через LLVM. Правда при этом у них указано, что сам язык управляемый — интересно как это там внутри всё сочетается.
Дедушка без управляемости это уже бабушка, как справедливо заметил Wolfhound. Scala native это 100% Скала. В смысле там только бэкенд другой, фронтенды взяты из jvm версий [Нитра не нужна! ]. "ФронтендЫ" потому что их сейчас два: scalac (прод) и dotty (новый). Все нативные плюшки сделаны через обычные механизмы (аннотации и т.д.).
В данный момент для ГЦ традиционно используют Boehm, потом собираются менять. Это не отменяет конечно, что можно прямо звать malloc, etc, то есть "гибридный" подход в терминологии Влада.
_>Кстати, у них там видно одно интересное решение, про которое я уже тоже тут говорил, как про полезную временную меру. Они не стали страдать с разработкой своей стандартной библиотеки, а просто взяли готовую библиотеку C. Поэтому у них там во всех примерах сплошные printf и т.п.
Не совсем. Они хотят иметь совместимость до уровня работоспособности чистых Scala-библиотек типа Акка/Spark. Для этого они ограничено портируют явовские нэймспейсы на нативную Скалу ручками. Автор говорит, что это довольно просто. Если уровень поддержки достаточный, то какой-нибудь scala.collection._ должна работать из коробки.
_>Да, но вот с вопросами документации у данных товарищей всё крайне печально. Вообще полная пустота.
Проект новый, документация вроде в разработке. Посмотри на тытруба, там вроде в отдельном брэнче что-то валяется.