LINUX.ORG.RU

Rakudo Star 2016.11

 ,


0

2

Rakudo Star — дистрибутив Perl 6 — новой версии Perl, которая из-за огромного числа изменений зачастую рассматривается как самостоятельный язык программирования.

Важные отличия Perl 6 от предыдущих версий:

  • Впервые за всю историю Perl разработка новой версии была начата с написания спецификаций, претерпевающих изменения по сей день. Фактически можно говорить о новом языке, имеющем с предыдущей версией Perl общие корни, но не совместимом с ней, хотя в спецификациях предполагался режим совместимости.
  • В Perl 6, так же, как и в Perl 5, используется динамическая типизация, однако добавлены статические типы для улучшения производительности.
  • Вместо интерпретатора теперь используется компилятор Rakudo, а для исполнения байткода — виртуальная машина MoarVM. Также существует бекенд для JVM, но он пока менее развит и не поддерживает все функции.
  • Значительные изменения претерпел синтаксис языка, с отличиями можно ознакомиться в документации.

Основные изменения в Rakudo Star 2016.11:

  • Различные улучшения в выводе предупреждений и сообщений об ошибках.
  • Исправлены функции acotan(num), asinh(num) и acosh(num), которые ранее могли давать неверный результат.
  • MoarVM теперь корректно компилируется на любой версии macOS.
  • Значительная улучшена производительность: ускорена работа функций slip(@a), Str.match, Str.Comb(Regex), Str.subst/subst-mutate и Match.Str|prematch|postmatch; динамическая типизация стала быстрее; заметно увеличилась скорость работы при использовании хешей; массивы теперь копируются в 10-20 раз быстрее, а время доступа к элементам двумерных и трёхмерных массивов уменьшилось в 7 раз.

>>> Подробности

Perl 5 лучше. Perl 6 слишком жирный и заточен целиком и полностью под UTF-8, ничего не зная про KOI8-R.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Ему и не надо об этом знать, это же язык для 20-х годов 21 века, а не 90-х 20-го. На кои уже даже ГОСТ отменили, заканчивай с наркотиками.

inchallah ()
Ответ на: комментарий от inchallah

Никто ничего не отменял. Более того, есть RFC 1489, а упоминание KOI8-R продолжает активно встречаться в исходниках:

perl-5.25.4/cpan/Encode/lib/Encode/Supported.pod:

KOI8 - De Facto Standard for the Cyrillic world

linux-4.7/fs/nls/Kconfig:

Note that the charset KOI8-R is preferred in Russia.

glibc-2.24/manual/charset.texi

In other words,
if a project is expected to be used in only, say, Russia it is fine to use
KOI8-R or a similar character set.  But if at the same time people from,
say, Greece are participating one should use a character set that allows
all people to collaborate.
И т.д.

В общем, KOI8-R живее всех живых, и с ней прекрасно работает Perl 5.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

В общем, KOI8-R живее всех живых

Самое главное — почаще себе это повторять!

theNamelessOne ★★★★★ ()
Ответ на: комментарий от theNamelessOne

Констатация факта не меняет ничего кроме того, что незнающие об этом люди могут об этом узнать. По дефолту во многим дистрибутивах, конечно, UTF-8, с этим никто не спорит. Но, это только дефолт. Всегда можно перенастроить локаль на KOI8-R. А многие не любят перенастраивать (особенно без мотивации). Отсюда и мифы о смерти всех других локалей.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

По дефолту во многим дистрибутивах, конечно, UTF-8, с этим никто не спорит. Но, это только дефолт. Всегда можно перенастроить локаль на KOI8-R. А многие не любят перенастраивать (особенно без мотивации).

Это и называется умер

loz ★★★★★ ()
Ответ на: комментарий от loz

Нет, «умер» - это когда или совсем не настраивается/не запускается, или настраивается/запускается, но 0 юзеров. А если настраивается/запускается и юзеров больше чем 0 - не менее живо чем самые популярные инструменты.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

когда или совсем не настраивается/не запускается, или настраивается/запускается, но 0 юзеров

Пока может и так, но никто специально не думает о поддержке KOI8-R при написании новых программ, утилит и тд, пользователей все меньше а процесс не остановить. Я думаю и пятидюймовыми дискетами еще пользуются где-то, но разве это называется живо?

loz ★★★★★ ()
Ответ на: комментарий от loz

KOI8-R и другие однобайтные кодировки поддерживаются на уровне glibc и ядра. Пока из них специально не выпилят всё будет работать (кроме тех редких моментов, когда внутри нужно перекодировать строки (например, для сетевого протокола), а автор этого не делает). А это будет совсем не скоро.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

С такой логикой и латинский язык жив, юзеров-то не ноль koi8r сейчас только у активных пользователей криокамер

anonymous ()
Ответ на: комментарий от anonymous

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

KOI8-R у всех желающих. Но, в основном, да, это те, кто пришли до того как в дистрибутивах появились продвинутые TTF шрифты и UTF-8 стал дефолтом. Чтобы что-то менять нужна мотивация.

Я пришёл в 2003-ем году. В те годы у нас были Debian Woody и Red Hat 7.2. Локализацию настраивал по мануалам, которые описывали настройку для KOI8-R. Про UTF-8 в качестве локали тогда мало кто думал.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

Всё правильно сделали. А то, понимаешь, понапишут софта по учебникам двадцати-тридцатилетней давности (где написано, что машинное слово — два байта, а символ — один байт), а он либо валится от русских символов, либо крякозябры показывает.

te111011010 ()
Ответ на: комментарий от loz

Вообще новые программы должны работать с koi8, если она задана в системе. Это для однобайтных кодировок читать системную локаль не всегда обязательно. А в программе, заточенной под юникод, это делать нужно (либо стандартная библиотека сделает это за тебя), так что ей не будет важно, какая у пользователя кодировка.

te111011010 ()
Ответ на: комментарий от te111011010

Perl 5 умеет работать в т.ч. и с юникодом, а не только с однобайтными кодировками.

а он либо валится от русских символов, либо крякозябры показывает.

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

А вот при обработке строк, конечно, возможно появление кракозябров.

This. Ещё, если нужно определение длины строки, то тоже она будет неправильной.

te111011010 ()
Ответ на: комментарий от te111011010

К обработке строк надо присматриваться. А вот при сборке nqp-m вызывается с "--encoding=utf8" (замена utf8 на другие варианты приводит к тому, что оно не собирается; там вообще список поддерживаемых внутренних кодировок маленький), системные сообщения он выводит в юникоде и в самих исходниках та же KOI8-R вообще не упоминается. А в исходниках Perl 5 упоминается.

saahriktu ★★★★★ ()
Ответ на: комментарий от te111011010

Ещё, если нужно определение длины строки, то тоже она будет неправильной.

Но, к переполнениям буферов это недолжно приводить. Софту всё равно какие символы в строках, имеют они для кого какой смысл в языках или нет. И он просто посчитает эту строку за строку в однобайтной кодировке. И всё. А вот строки в однобайтных кодировках юникодный софт может и не распарсить.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

А вот строки в однобайтных кодировках юникодный софт может и не распарсить.

Распарсит. Юникодный софт не прибит гвоздями к юникоду, тем более есть несколько вариантов представления юникода. Он считывает системную кодировку и обрабатывает символы согласно ней.

te111011010 ()
Ответ на: комментарий от te111011010

Он считывает системную кодировку и обрабатывает символы согласно ней.

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)

Никак руки не дойдут багрепорт накатать: не пашет DESTDIR в системе сборки.

Deleted ()
Ответ на: комментарий от saahriktu

Прости анониму личный вопрос, saahriktu, но сколько тебе лет?

anonymous ()
Ответ на: комментарий от saahriktu

Латынь мертва. Не путай отдельные наименования и обозначения с диалектом. А то при таком подходе и старорусский можно назвать живым, потому что используются отдельные его символы. https://ru.wikipedia.org/wiki/Латинский_язык тут написано что не смотря на официальный статус в Ватикане она таки считается официально же мёртвым языком, потому что на ней никто не разговаривает. Тут перечень мертвичины https://ru.wikipedia.org/wiki/Мёртвый_язык , и латынь тут лежит в ящике.

cheshire_cat ★★ ()

весёлая, наверное, тема - 25 из 28 сообщений в игноре

по теме - он уже готов для семилетних девочек?

buratino ★★★★★ ()

некроморфы не пройдут!

anonymous ()
Ответ на: комментарий от anonymous

Текстовый терминал VT100, который эмулируется моей ядерной консолью, старше меня на 5 лет и 8 месяцев. А когда в 10 лет я захотел стать программистом и начал читать книжки про IT, программирование, килобайт в 1024 байта, однобайтные кодировки,... и т.д. - UTF-8 было всего 2 годика.

saahriktu ★★★★★ ()
Ответ на: комментарий от inchallah

Ему и не надо об этом знать, это же язык для 20-х годов 21 века, а не 90-х 20-го. На кои уже даже ГОСТ отменили, заканчивай с наркотиками.

Удваиваю тебя.

Консоле-адепты должны страдать под напором времени.

bookman900 ★★★★★ ()
Ответ на: комментарий от saahriktu

и в самих исходниках та же KOI8-R вообще не упоминается. А в исходниках Perl 5 упоминается.

Ну и сиди в прошлом веке.

bookman900 ★★★★★ ()
Ответ на: комментарий от bookman900

Мы не страдаем. Мы просто юзаем юзабельное. А такого ещё много, очень много.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

Могу поддержать в том плане, что большинство текстов на естественных языках - двуязычные, и один из языков - английский, а второй - национальный. Если просто использовать для кодирования таких текстов однобайтовые кодировки - можно сократить расход памяти на их хранение и промежуточную обработку в 1.5-2 раза (если английской части и однобайтовых знаков типа пробела мало по объёму относительно «национального» текста). Т.е. неплохой такой способ сжатия получается: берём текст в UTF-8, конвертим в национальную кодировку - и вуаля, получаем кратную экономию памяти. Скорость считывания процессором символов однобайтовой кодировки тоже должна быть выше - хотя бы за счёт того, что здесь длина символа всегда фиксирована и равна 1 байту, а не как Бог на душу положит (в UTF-8 от 1-го до 3-х байт на символ).

Но конечно текст со смесью языков (русский, английский, китайский, например) однобайтово никак не представишь... если не учитывать конечно того неоспоримого факта, что абсолютное большинство текстов передаются и хранятся не в plain-виде, так что переключение кодировки можно было бы учитывать в мерзких XML-тегах и атрибутах JSON-объектов, например.

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

в UTF-8 от 1-го до 3-х байт на символ

Даже до 6-ти.

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

Это да. Но, не всем оно нужно, да.

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

Это какие-то очень уникальные случаи для которых надо, чтобы в совремённом мире люди из разных стран имели достаточно хорошее гуманитарное образование, (которое само по себе подразумевает знание хотя бы пары иностранных языков) но при этом взаимно не знали ни английского, ни какого-то ещё сильно распространённого.

anonymous_incognito ★★★★★ ()
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Какая мотивация может заставить человека использовать KOI8-R?

falafel ()
Ответ на: комментарий от falafel

Необходимость экономить на памяти, в некоторых случаях увеличение быстродействия.

Всё это довольно специфические ситуации, хотя я и сам нарочно использовал на работе cp1251 (как тоже однобайтовую) для одной программки обработки текста, потому что utf8 не годился, перевод в utf-32 слишком много памяти начинал требовать, а чего-то кроме русского и английского в тексте не подразумевалось.

anonymous_incognito ★★★★★ ()
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от falafel

Например, 256 символов в шрифте и архитектурная простота однобайтовых кодировок.

saahriktu ★★★★★ ()

ТС, а давно ты на перле пишешь? )

Harald ★★★★★ ()
Ответ на: комментарий от saahriktu

Надо же, ровестник, а таким ретроградством занимаешься.

bitfroster ★★ ()
Ответ на: комментарий от inchallah

Судя по новостям, у тебя прям разносторонние интересы

Harald ★★★★★ ()
Ответ на: комментарий от saahriktu

Любитель подбирать кодировку к текстовым файлам? Может пора уже унифицировать?

LinuxDebian ★★★★ ()
Последнее исправление: LinuxDebian (всего исправлений: 1)

Это ведь тред про кодировки, да?

Мне не нравится сложность обработки UTF-8. Мне нравится простота и понятность однобайтовых кодировок.

К сожалению, однобайтовые кодировки плохо соместимы с окружающим миром. Вот перейдём всем миром на латиницу, тогда уж заживём. А пока, если я хочу в одном текстовом файле (или в именах файлов) видеть, скажем, английский и русский текст вперемешку, например, с греческими символами (не говоря уж про иероглифы), UTF-8 неизбежен.

anonymous ()
Ответ на: комментарий от saahriktu

Что тебе дают 256 символов в шрифте и архитектурная простота кодировки, если ты пишешь на перле?

falafel ()
Ответ на: комментарий от falafel

В каком-то смысле, конечно, может быть всё равно в какой кодировке писать скрипты. Но, при обработке строк и выводе неанглийских скриптовых сообщений может быть важно с какой кодировкой работает скрипт. И тут удобнее если это кодировка локали. А 256 символов в шрифте и архитектурная простота KOI8-R мотивируют на выбор именно её в качестве локали.

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от LinuxDebian

подбирать кодировку к текстовым файлам

Во-первых, есть enca. Во-вторых, многое можно автоматически конвертировать в KOI8-R при получении, а своё и подавно сразу создаётся в KOI8-R. В-третьих, чаще всего встречаются cp1251 и UTF-8, которые можно распознать на первый взгляд:

ОНДАХПЮРЭ ЙНДХПНБЙС Й РЕЙЯРНБШЛ ТЮИКЮЛ - cp1251
п©п╬п╢п╠п╦я─п╟я┌я▄ п╨п╬п╢п╦я─п╬п╡п╨я┐ п╨ я┌п╣п╨я│я┌п╬п╡я▀п╪ я└п╟п╧п╩п╟п╪ - UTF-8

saahriktu ★★★★★ ()

Вопрос - оно уже готово к Ынтерпрайзу или так же - на потыкать, полить слезы и продолжить писать на С/C++/Python/Java/JS?

silver-bullet-bfg ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.