The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз Parrot 2.10.0, виртуальной машины для Perl 6

17.11.2010 11:17

Вышел релиз виртуальной машины для динамических языков программирования Parrot 2.10.0, в первую очередь используемой в проекте Rakudo Perl 6. Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, APL.

Начиная с данного выпуска для разработки Parrot теперь используется система управления исходными текстами Git и сервис GitHub. Скрипты конфигурации, сборки и тестирования модифицированы с целью улучшения поддержки Git. Подготовлено небольшое руководство, в котором изложен типовой процесс работы с Parrot в Git.

Из других изменений можно отметить:

  • обновление версии nqp-rx;
  • корректировка обработки ошибок ввода/вывода;
  • устранение утечек памяти и оптимизация работы сборщика мусора;
  • поддержка определения IPv6 в скрипте сборочного конфигурирования;
  • увеличена область действия String, FixedBooleanArray, PMCProxy, LexPad;
  • Для Fedora подготовлен пакет с реализацией модуля PL/Parrot (postgresql-plparrot), предназначенного для написания встроенных процедур для PostgreSQL на языках PIR или Rakudo Perl 6;


  1. Главная ссылка к новости (http://www.parrot.org/news/201...)
  2. OpenNews: Релиз Parrot 2.5.0, виртуальной машины для Perl 6
  3. OpenNews: Релиз Parrot 2.2.0, виртуальной машины для Perl 6
  4. OpenNews: Релиз Parrot 2.0.0, виртуальной машины для Perl 6
  5. OpenNews: Увидел свет Rakudo Star, первый готовый к использованию дистрибутив Perl 6
  6. OpenNews: Выпуск Parrot 1.0, виртуальной машины для Perl 6
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/28682-Parrot
Ключевые слова: Parrot, perl, perl6
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, dq0s4y71 (??), 12:09, 17/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, APL.

    У всех этих языков есть собственные виртуальные машины. Интересно, зачем может понадобиться прикручивать Пэррот, например, к Луа?

     
     
  • 2.2, Аноним (-), 12:31, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное чтобы даже при зоопарке языков не было зоопарка виртуальных машин, все равно суть у всех одна.
     
     
  • 3.5, JL2001 (ok), 12:47, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Наверное чтобы даже при зоопарке языков не было зоопарка виртуальных машин, все
    > равно суть у всех одна.

    а почему не llvm например ?

     
     
  • 4.12, Crazy Alex (??), 15:26, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что он не рассчитан на динамические языки, AFAIK.
     
     
  • 5.19, ы (?), 20:08, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А это чё?
    Python LLVM Unladen Swallow
     
     
  • 6.26, Crazy Alex (??), 16:39, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Извратиться вездме можно. Вопрос в сложности и кривости решения
     
  • 3.7, dq0s4y71 (??), 13:46, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Суть-то одна, но, как говорится, дьявол кроется в деталях. Взять к примеру тот же Луа. Это легковесный язык для встроенных систем, который я могу легко прикрутить к своему приложению, увеличив при этом его размер не более чем на 200К. Одновременно я имею легковесную виртуальную машину, специально разработанную для этого языка. Спрашивается: нафига мне тащить туда Пэррот? Только ради того, чтобы "не было зоопарка виртуальных машин"?

    Нет, я не хочу таким образом сказать, что Пэррот не нужен. Мне действительно интересно узнать какие _практические_ цели можно преследовать, используя Пэррот с языками, для которых уже есть "родные" виртальные машины?

     
     
  • 4.9, Aleksey (??), 14:10, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хотите вы например из Perl заюзать библиотеку на Java. Компилите Java код в код виртуальной машины и все - изайте в перле. Это в идеале конечно.
     
     
  • 5.13, Crazy Alex (??), 15:27, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    см. Java VM  с кучей языков, интегрирующихся между собой за счёт единой VM
     
  • 4.10, ABC (??), 14:15, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Например:

    1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных на разных языках. При этом взаимодействие между разными частями из каждого кусочка будет, как с "родным".

    2) Если вам надо прикрутить скриптинг к своей системе, то может иметь смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку сразу пачки языков.

     
     
  • 5.11, dq0s4y71 (??), 14:47, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Например:
    > 1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных
    > на разных языках. При этом взаимодействие между разными частями из каждого
    > кусочка будет, как с "родным".

    Я могу понять зачем использовать Си в связке с ассемблером или даже Делфи в связке с Си, но зачем использовать PHP в связке, например, с Scheme - выше моего понимания. Можно удивить всех, скрестив ежа с ужом, но практическая польза от этого мне не вполне ясна.

    > 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
    > смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
    > сразу пачки языков.

    Может быть. Но если я, допустим, пишу игруху, движок которой управляется скриптом на Луа, зачем мне нужна возможность сделать то же самое еще на десяти языках, когда мне достаточно реализовать это на _одном_ языке, но что бы оно работало? :)

    Впрочем, не спорю. Тут говорили о возможности сделать общую для них все платформу. Любопытно было бы взглянуть на такую платформу...

     
     
  • 6.14, Crazy Alex (??), 15:28, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Смотрите - Java VM. Но для динамических языков она не особо годится
     
  • 6.24, Ytch (?), 22:29, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
    >> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
    >> сразу пачки языков.
    >Может быть. Но если я, допустим, пишу игруху, движок которой управляется скриптом на Луа,
    >зачем мне нужна возможность сделать то же самое еще на десяти языках, когда мне достаточно
    >реализовать это на _одном_ языке, но что бы оно работало? :)

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

     
  • 5.21, ы (?), 20:33, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Например:
    > 1) Используя одну ВМ, вы можете скомпоновать програмный комплекс из частей написаных
    > на разных языках. При этом взаимодействие между разными частями из каждого
    > кусочка будет, как с "родным".

    На практике это выглядит так, приходишь к заказчику у которого зоопарк из тысячи другой машин (самая типичная ситуация),  и вместо автоматической установки приложения начинается квест с ручной установкой нужных версий VM (узнали .net) и ручного разрешения зависимостей, и прыганьем с одной машины на другую, итого вместо минуты, уходит неделя.

    > 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
    > смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
    > сразу пачки языков.

    Ну да, а потом сидит "Вася эникейщик", матерится изучает одновремено lua,perl,python,php и пытается понять где у него приложение сбоит.  

     
     
  • 6.27, Crazy Alex (??), 16:45, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > На практике это выглядит так, приходишь к заказчику у которого зоопарк из
    > тысячи другой машин (самая типичная ситуация),  и вместо автоматической установки
    > приложения начинается квест с ручной установкой нужных версий VM (узнали .net)
    > и ручного разрешения зависимостей, и прыганьем с одной машины на другую,
    > итого вместо минуты, уходит неделя.
    >> 2) Если вам надо прикрутить скриптинг к своей системе, то может иметь
    >> смысл не ограничивать пользователей одним Lua. С попугаем вы получите поддержку
    >> сразу пачки языков.
    > Ну да, а потом сидит "Вася эникейщик", матерится изучает одновремено lua,perl,python,php
    > и пытается понять где у него приложение сбоит.

    В вашем варианте сидит Петя-эникейщик и думает: какого хрена я должен осваивать очередной луа и искать либы, чтобы написать логику этого поделия это поделие, хотя на питоне у меня всё есть...

    Но проблема Васи не возникает, если есть вменяемая policy (в которой указывается: "в рамках нашей конторы расширения пишутся на таком-то языке, и их вход/выход специфицируется так и проверяется этак"), а проблема Пети решается только напрягом Пети.

     
  • 2.3, Аноним (-), 12:33, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, что бы использовать общие библиотеки и друг-друга.
     
     
  • 3.8, dq0s4y71 (??), 14:03, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Очевидно, что бы использовать общие библиотеки и друг-друга.

    Ну, может быть. Не совсем, правда, очевидны преимущества использования общих библиотек в данном случае. Все эти языки самодостаточны и используются в разных, слабо пересекающихся областях. Какая нужда может заставить, например, PHP, применяемый для сайтостроения, использовать код, написанный на Луа, применяемый во встроенных приложениях и игрухах? И для того и для другого языка есть масса собственных библиотек, которые покрывают нужды каждого из них с лихвой.

     
     
  • 4.15, Crazy Alex (??), 15:33, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    1) чтобы и дальше не плодить идентичные библитеки для разных языков
    2) чтобы использовать существуюзщие библиотеки для того языка, для которого они есть
    3) чтобы использовать в разных частях проекта языки, которые больше всего подходят к текущей задаче и не маяться с обеспечением взаимодействия.

    Сейчас самый яркий пример - Java VM, где можно часть кода писать на яве, часть - на Scala, к примеру. Parrot будет выгоден тем же, но в основном заточен под динамику/"скриптовые" языки, и dynamic typing, к примеру, в нём делается вполне прямо.

    Хотя как по мне - развесистая VM подразумевает использование в больших проектах, а там скриптовым языкам не место ни разу.

     
     
  • 5.22, ы (?), 20:46, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) чтобы и дальше не плодить идентичные библитеки для разных языков

    Что это дает? Отбирает самостоятельное эволюционное развитие языков, но что дает?  

    > 2) чтобы использовать существуюзщие библиотеки для того языка, для которого они есть

    Причем тут VM, язык использует свои библиотеки и без VM

    > 3) чтобы использовать в разных частях проекта языки, которые больше всего подходят
    > к текущей задаче и не маяться с обеспечением взаимодействия.

    Ох примерчик бы такого проекта, где бы было бы php,perl,python,lua и показан был выигрыш от такого взаимодействия.

    > Сейчас самый яркий пример - Java VM, где можно часть кода писать
    > на яве, часть - на Scala, к примеру. Parrot будет выгоден
    > тем же, но в основном заточен под динамику/"скриптовые" языки, и dynamic
    > typing, к примеру, в нём делается вполне прямо.

    Это не то, Scala без платформы Java не существует, здесь идет речь о самодостаточных языках занимающие давно и успешно свои ниши, и имеющие полный набор библиотек закрывающие любые самые изощренные потребности.

    > Хотя как по мне - развесистая VM подразумевает использование в больших проектах,
    > а там скриптовым языкам не место ни разу.

    Если проект действительно большой, то там без скриптования не обойдешься.

     
     
  • 6.30, ABC (??), 17:41, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Коммерческая рентабельность обратно пропорциональна времени, потраченного на выпуск продукта. Разные языки имееют разные преимущества в разных предметных областях за счет синтаксиса и наличия библиотек. Поэтому, возможность комбинировать несколько языков - выгодна.
     
  • 6.32, Crazy Alex (??), 19:14, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Уже и без меня ответили, но дополню - даёт возможность использовать ЧУЖИЕ библиотеки. То есть в lua использовать питоновские, к примеру. Получаем возможность отдельно выбирать язык, подходящий для данного случая, а отдельно - библиотеки, независимо от языка.

    А все языки сразу использовать никто и не предлагает. Выбирается тот набор, который нужен в данном проекте.

    Скриптование в большом проекте - это одно. Оно используется для кастомизации, как правило. А глупости вроде написания графического редактора на Питоне - другое.

     
  • 2.4, Аноним (-), 12:44, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы довести общую платформу до совершенства, например.
     
  • 2.6, vle (ok), 13:12, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Parrot поддерживает выполнение универсального байткода, в который могут быть скомпилированы программы на таких языках, как Perl 6, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, APL.
    > У всех этих языков есть собственные виртуальные машины. Интересно, зачем может понадобиться
    > прикручивать Пэррот, например, к Луа?

    http://www.dict.org/bin/Dict?Form=Dict2&Database=jargon&Query=%27Zawinsk

    Это немного шутка.

    Серьезно. Про общие библиотеки уже сказали.
    Именно этим и хорош мелкомягкий .NET.
    Под UNIX-ы аналога по сути нет.

     
     
  • 3.16, Аноним (-), 15:38, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Именно этим и хорош мелкомягкий .NET. Под UNIX-ы аналога по сути нет.

    http://www.mono-project.com/Main_Page - самая обыкновенная _родная_ UNIX-овая штука
    и пожалуйста, не надо говорить что это не аналог
    фактически это может быть даже заменой в частных случаях

     
     
  • 4.18, vle (ok), 18:07, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Именно этим и хорош мелкомягкий .NET. Под UNIX-ы аналога по сути нет.
    > http://www.mono-project.com/Main_Page - самая обыкновенная _родная_ UNIX-овая штука
    > и пожалуйста, не надо говорить что это не аналог

    Ну, во-первых, все-таки не аналог, а во-вторых, двигаясь
    в этом направлении, UNIX-комьюнити ВСЕГДА будет позади M$
    на несколько шагов, потому что источником идей и направления развития
    является как бы Microsoft.

     
  • 3.20, ы (?), 20:20, 17/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Серьезно. Про общие библиотеки уже сказали.
    > Именно этим и хорош мелкомягкий .NET.

      А что, взять к пример python,  на ironpython уже можно пользоваться джангой, скайпи, твистет, кьютом, алхимией и еще парой тысяч библиотек/фреймворков python?

    Или за исключением примерно одинакового синтаксиса с python ничего общего? И все равно все пишут на одном и том  же C#, ну иногда ASP и VB, первое спецом для веба, второе для администрирования?

    > Под UNIX-ы аналога по сути нет.

    Не дай бог.

     
     
  • 4.29, Crazy Alex (??), 16:49, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Серьезно. Про общие библиотеки уже сказали.
    >> Именно этим и хорош мелкомягкий .NET.
    >   А что, взять к пример python,  на ironpython уже
    > можно пользоваться джангой, скайпи, твистет, кьютом, алхимией и еще парой тысяч
    > библиотек/фреймворков python?
    > Или за исключением примерно одинакового синтаксиса с python ничего общего? И все
    > равно все пишут на одном и том  же C#, ну
    > иногда ASP и VB, первое спецом для веба, второе для администрирования?

    Даже если либы под платформу придётся писать заново - они всё равно будут доступня для всех языков на платформе.


    >> Под UNIX-ы аналога по сути нет.
    > Не дай бог.

    Для юниксов такая общая платформа - native + C API. Понимают все :-)

     

  • 1.25, szh (ok), 14:24, 18/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мда, скомпилировал perl6 , запустил,
    use strict;
    use warnings;
    он не понимает, нет такого модуля

    дальше споткнулся о первые строки моего perl5 кода.

    perl6 -e ' my $h = { default =>[5,34] }; print $h->{"default"} '

    в такой строке он не понимает 2 вещи в синтаксисе - (default без кавычек, и ->)

    мертворожденный он. Поддержали бы perl5 хоть на слабом уровне, можно было бы пользоватся.


    3 года мечтал скомпилировать свой код в пасм/пир, но мечты разрушились, еще 5 лет ждать я не могу.

     
     
  • 2.28, Crazy Alex (??), 16:48, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > он не понимает, нет такого модуля
    > дальше споткнулся о первые строки моего perl5 кода.
    > perl6 -e ' my $h = { default =>[5,34] }; print $h->{"default"}
    > '
    > в такой строке он не понимает 2 вещи в синтаксисе - (default
    > без кавычек, и ->)
    > мертворожденный он. Поддержали бы perl5 хоть на слабом уровне, можно было бы
    > пользоватся.
    > 3 года мечтал скомпилировать свой код в пасм/пир, но мечты разрушились, еще
    > 5 лет ждать я не могу.

    Если бы кго назвали не Perl, а XYZ - вам было бы легче? Это другой язык, вообще-то.

     
     
  • 3.34, szh (ok), 20:21, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы кго назвали не Perl, а XYZ - вам было бы легче? Это другой язык, вообще-то.

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

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

    Я надеялся что с perl6 смогу не переписывая все на свете получить доступ к байткоду. А так мне лично perl6 не нужен, а perl5 не достаточен, хоть и очень нравится.

     
     
  • 4.35, Аноним (-), 20:33, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне было бы легче если бы перл 5 развивали в эту сторону,

    Кто вам мешает, вместо Perl6 поверх Parrot, использовать Perl5 поверх Parrot ? См. https://github.com/jnthn/blizkost/

     
     
  • 5.37, szh (ok), 21:51, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо!
    скомпилировал, вроде работают скрипты,
    только не понял как байткод сгенерить, документации по blizkost нема.
     
  • 2.31, ABC (??), 18:18, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Поддержали бы perl5 хоть на слабом уровне, можно было бы
    > пользоватся.

    В гугле забанили, да?

     
  • 2.33, Sugar (ok), 19:39, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • +/

    > в такой строке он не понимает 2 вещи в синтаксисе - (default
    > без кавычек, и ->)

    Выше не зря сказали, что это другой язык. Где-то читал (гугл тут поможет), что оператор "стрелка", он же "->", остутствует в перл6.

     
     
  • 3.36, szh (ok), 20:36, 18/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> в такой строке он не понимает 2 вещи в синтаксисе - (default
    >> без кавычек, и ->)
    > Выше не зря сказали, что это другой язык. Где-то читал (гугл тут
    > поможет), что оператор "стрелка", он же "->", остутствует в перл6.

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

    выгоды от изменения синтаксиса я не вижу никакой - одни убытки

     
     
  • 4.38, sugar (?), 16:59, 21/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот из-за того что базовые конструкции изменили, нет возможности с небольшими переделками
    > плавно перейти на этот новый язык ради вожделенной фичи. Таким образом
    > новый язык мне и многим оказывается не нужен.
    > выгоды от изменения синтаксиса я не вижу никакой - одни убытки

    Тут и не поспоришь.
    Вот если бы попугай перл5 осиливал, это было гуд - и стары проекты работают, и CPAN, и perl6 под рукой. Прям сказка! =)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру