LINUX.ORG.RU

Вышел GNU Guile 2.0.7

 , , ,


1

3

Вышла новая версия реализации языка Scheme — GNU Guile 2.0.7. Несмотря на незначительное изменение номера версии, появились несколько интересных нововведений, а именно:

  • Полная поддержка инфиксных выражений (curly-infix-expressions). Теперь вместо (* a (+ b c)) можно писать {a * {b + c}}.
  • Поддержка разных опции чтения (read option) для разных портов.
  • Поддержка вложенных директив future.
  • Специальный синтаксис для добавления путей в переменные окружения GUILE_LOAD_PATH и GUILE_LOAD_COMPILED_PATH в конец списка путей, а не в начало.
  • Исправлен недочет в функции load-in-vicinity, которая не сканировала директории, установленные в переменной %load-compiled-path.
  • Исправлен порядок поиска расширений. Теперь Guile не изменяет для этого переменную окружения LD_LIBRARY_PATH.
  • Функция make-vtable-vtable помечена устаревшей, рекомендуется использовать make-vtable и <standard-vtable>.
  • Оптимизированы вызовы equal? и eqv? для случаев, когда один из аргументов — константа.
  • Новые предупреждения компилятора -Wduplicate-case-datum и -Wbad-case-datum.
  • Многочисленные незначительные улучшения и исправления ошибок.

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

★★★★★

Проверено: tazhate ()
Последнее исправление: maxcom (всего исправлений: 4)
Ответ на: комментарий от rtvd

То, что кто-то решил выпендриться и вручную через FFI дёргать GMP - его личные половые проблемы.

Да не выпендривался никто, просто решение с нативными функциями будет медленнее, вот и все.

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

Самое время уйти, когда тебя накормили говном.

Вот-вот. Говно - это лучшее, что могут предложить свиньи. :-)

Ни разума, ни внимательности, ни тем более профессионализма или этики от них не дождаться. И этот тред тому подтверждение.

Так что больше на вас я тратить время не буду. :-)

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

А ffmpeg, по-твоему, с помощью чего собирается?

Да и это жутко неудобно, а всё из-за C99.

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

Офигительный объем подготовительной работы: подцепить ELF, найти в нём функцию и нацелить на неё указатель. Умора.

Могу подтвердить, что вызовы FFI в Racket характеризуются оверхедом.

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

Один из анонимов вам уже объяснил, почему FFI вынужден делать много работы на каждом вызове — нужно предусмотреть возможные действия подключаемого кода, семантика которого рантайму и компилятору не известна; нужно распаковать/запаковать значения аргументов и результатов. Это вам не Haskell какой-нибудь.

Кроме того, в реализации используется libffi, который сам по себе даёт оверхед, ощутимый при вызове очень маленьких, быстрых функций. Конкретно сейчас в Racket сделать через FFI вызов внешней функции за 3 или даже за 30 наносекунд никак не получится (хотя есть простор для улучшений, работа над этим регулярно ведётся).

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

Если вам жизненно важно иметь возможность быстро вызывать маленькие функции, предлагаю подключать их вручную через API рантайма: http://docs.racket-lang.org/inside/index.html.

Да, геморрой (примерно как в OCaml). Да, несложно ошибку допустить (особенно с новым точным GC). Но для пары функций можно потерпеть? Или вам на практике приходится работать с большим количеством таких функций, на вызовы которых приходилась бы значительная часть времени выполнения?

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

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

Могу подтвердить, что вызовы FFI в Racket характеризуются оверхедом.

Да даже и не ffi вызовы характеризуются оверхедом (из-за той самой семантики), но товарищ никак не может этого понять:

> (define (yoba) (x) 1) ; единица в конце, чтобы не было TCO и можно было определить конец ф-и по RET
> (yoba) ; чтобы заджитилось
x: undefined;
 cannot reference an identifier before its definition
> (decompile yoba)
00000000  8B4804            mov ecx,[eax+0x4]

00000003  894BFC            mov [ebx-0x4],ecx

00000006  8B4808            mov ecx,[eax+0x8]

00000009  894BF8            mov [ebx-0x8],ecx

0000000C  83C3F8            add ebx,byte -0x8

0000000F  8D9768040000      lea edx,[edi+0x468]

00000015  8B12              mov edx,[edx]

00000017  83C202            add edx,byte +0x2

0000001A  899768040000      mov [edi+0x468],edx

00000020  8D9764040000      lea edx,[edi+0x464]

00000026  8B12              mov edx,[edx]

00000028  8955F0            mov [ebp-0x10],edx

0000002B  8B13              mov edx,[ebx]

0000002D  8B521C            mov edx,[edx+0x1c]

00000030  8B4204            mov eax,[edx+0x4]

00000033  85C0              test eax,eax

00000035  0F8470FAD0DE      jz dword 0xded0faab

0000003B  89C6              mov esi,eax

0000003D  E8161F4FE4        call dword 0xe44f1f58

00000042  8B55F0            mov edx,[ebp-0x10]

00000045  899764040000      mov [edi+0x464],edx

0000004B  8D9768040000      lea edx,[edi+0x468]

00000051  8B12              mov edx,[edx]

00000053  83C2FE            add edx,byte -0x2

00000056  899768040000      mov [edi+0x468],edx

0000005C  B803000000        mov eax,0x3

00000061  83C41C            add esp,byte +0x1c

00000064  5F                pop edi

00000065  5E                pop esi

00000066  5B                pop ebx

00000067  5D                pop ebp

00000068  C3                ret
никто, конечно, и не спорит, что это все можно сделать быстрее, но «чтоб как в сишке» - этого никак не будет. Даже близко не будет.

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

Кстати, типы, которые статически выводятся в Type Racket, для ускорения работы программ практически не используются (на практике ускорение совсем небольшое получается) и FFI про эту статическую информацию ничего не знает.

Ну тут дело просто в том, что никто и не делал Typed Racket с прицелом именно на оптимизацию, то есть оптимайзер тут это просто костылик, который сделали потому что а почему бы и нет?

Единственно когда он эффективно работает - это в случае кода с флонумами, т.к. там расставляются хинты для джита и джит потом генерит код, избегая боксинга/анбоксинга, там проиводительность может и на порядок отличаться, а то и на два. Сейчас, кстати, хотят расширить этот протокол - тогда Typed Racket сможет расставлять хинты для джита и в других случаях..

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

вот еще кстати код лупа:

(define (f n)
  (if (unsafe-fx> n 0) (f (unsafe-fx- n 1)) 1))
> (decompile f #:size 350)
00000000  8B4804            mov ecx,[eax+0x4]
00000003  894BFC            mov [ebx-0x4],ecx
00000006  8B4808            mov ecx,[eax+0x8]
00000009  894BF8            mov [ebx-0x8],ecx
0000000C  83C3F8            add ebx,byte -0x8
0000000F  8B4308            mov eax,[ebx+0x8]
00000012  81F801000000      cmp eax,0x1
00000018  0F8E0F010000      jng dword 0x12d
0000001E  83C0FE            add eax,byte -0x2
00000021  8943FC            mov [ebx-0x4],eax
00000024  83C3FC            add ebx,byte -0x4
00000027  81F801000000      cmp eax,0x1
0000002D  0F8EF0000000      jng dword 0x123
00000033  83C0FE            add eax,byte -0x2
00000036  8943FC            mov [ebx-0x4],eax
00000039  83C3FC            add ebx,byte -0x4
0000003C  81F801000000      cmp eax,0x1
00000042  0F8ED1000000      jng dword 0x119
00000048  83C0FE            add eax,byte -0x2
0000004B  8943FC            mov [ebx-0x4],eax
0000004E  83C3FC            add ebx,byte -0x4
00000051  81F801000000      cmp eax,0x1
00000057  0F8EB2000000      jng dword 0x10f
0000005D  83C0FE            add eax,byte -0x2
00000060  8943FC            mov [ebx-0x4],eax
00000063  83C3FC            add ebx,byte -0x4
00000066  81F801000000      cmp eax,0x1
0000006C  0F8E93000000      jng dword 0x105
00000072  895BFC            mov [ebx-0x4],ebx
00000075  8B03              mov eax,[ebx]
00000077  83C0FE            add eax,byte -0x2
0000007A  83C3FC            add ebx,byte -0x4
0000007D  8D576C            lea edx,[edi+0x6c]
00000080  8B12              mov edx,[edx]
00000082  81FA00000000      cmp edx,0x0
00000088  7E10              jng 0x9a
0000008A  8B55E4            mov edx,[ebp-0x1c]
0000008D  83C2F4            add edx,byte -0xc
00000090  894208            mov [edx+0x8],eax
00000093  89D3              mov ebx,edx
00000095  E975FFFFFF        jmp dword 0xf
0000009A  89874C040000      mov [edi+0x44c],eax
000000A0  51                push ecx
000000A1  52                push edx
000000A2  50                push eax
000000A3  50                push eax
000000A4  8D4778            lea eax,[edi+0x78]
000000A7  8B00              mov eax,[eax]
000000A9  81F800000000      cmp eax,0x0
000000AF  0F8F19000000      jg dword 0xce
000000B5  58                pop eax
000000B6  58                pop eax
000000B7  5A                pop edx
000000B8  8D874C040000      lea eax,[edi+0x44c]
000000BE  8B00              mov eax,[eax]
000000C0  31C9              xor ecx,ecx
000000C2  898F4C040000      mov [edi+0x44c],ecx
000000C8  59                pop ecx
000000C9  E927000000        jmp dword 0xf5
000000CE  899F60040000      mov [edi+0x460],ebx
000000D4  E8AC63553C        call dword 0x3c556485
000000D9  83C400            add esp,byte +0x0
000000DC  58                pop eax
000000DD  58                pop eax
000000DE  5A                pop edx
000000DF  8D874C040000      lea eax,[edi+0x44c]
000000E5  8B00              mov eax,[eax]
000000E7  31C9              xor ecx,ecx
000000E9  898F4C040000      mov [edi+0x44c],ecx
000000EF  59                pop ecx
000000F0  E988FFFFFF        jmp dword 0x7d
000000F5  8903              mov [ebx],eax
000000F7  8B5314            mov edx,[ebx+0x14]
000000FA  8B521C            mov edx,[edx+0x1c]
000000FD  8B7204            mov esi,[edx+0x4]
00000100  E940004FE0        jmp dword 0xe04f0145
00000105  B803000000        mov eax,0x3
0000010A  E905000000        jmp dword 0x114
0000010F  B803000000        mov eax,0x3
00000114  E905000000        jmp dword 0x11e
00000119  B803000000        mov eax,0x3
0000011E  E905000000        jmp dword 0x128
00000123  B803000000        mov eax,0x3
00000128  E905000000        jmp dword 0x132
0000012D  B803000000        mov eax,0x3
00000132  83C41C            add esp,byte +0x1c
00000135  5F                pop edi
00000136  5E                pop esi
00000137  5B                pop ebx
00000138  5D                pop ebp
00000139  C3                ret

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

Ну тут дело просто в том, что никто и не делал Typed Racket с прицелом именно на оптимизацию

А вот зря. Догнать ghc было бы интересно.

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

Проблема в том, что байткод сам по себе нетипизирован (он же делался тогда, когда никаких Typed Racket да и джитов еще и в проекте не было). Так что кроме хинтов джиту в «удачных» местах тут ничего не сделаешь.

А вообще, там джит еще весьма хуевый. Полагаю если тупо заменить на какой-нибудь пошустрее (типа libjit) уже будет значительный выигрыш.

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

Догнать ghc было бы интересно.

Как трогательно! Инвалид на костылях догоняет ползущего безногого. Паралимпиада какая-то получается.

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

что, правда? а как же

И где в этом коде «for»? mov - вижу. jmp - вижу. call, add, cmp, jle - вижу. for - не вижу. Так на какой архитектуре мне исполнять for?

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

Как трогательно! Глупый чернокожий раб, работающий на поле, гордится, что он может бегать быстрее своего господина!

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

Нет. Ты сказал «еще». Предполагая, что это можно исправить. Прошу занести в протокол - исправить этот адский кошмар не смогут никогда.

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

в данном случае я имел ввиду «еще» = «вдобавок к вышесказанному», а не «на данный момент». Понятно, что исправлять джит не надо - надо выкидывать lightning и делать на libjit.

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

так у него хаскиль, sbcl, етц. - это все инвалиды. потмоу что медленнее сишки.

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

А где про ISA этого байткода прочитать можно?

Я даже не знаю, если честно, это надо на маиллисте спрашивать. Была paper на тему семантики ВМ и байткода, но там не все (в частности те же хинты для джита там не описаны).

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

ты уже раздражать начинаешь.

Только сейчас? Старею, надо срочно работать над техникой.

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

Там байткод ничего общего с ISA какой-либо виртуальной машины не имеет. Он деревянный, а не плоский. Не уверен, что это умно. Скорее наоборот.

psikh
()

BTW, Guile — самая популярная имплементация Scheme / Lisp на десктоп-линуксах:
на нем реализованы все пасьянсы в наборе Aisleriot из GNOME Games ;)

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

Вообще, там стековая машина. Для нее «деревянный» код вполне ок.

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

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

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

Это я знаю. Но компенсирует ли всё это то что текст программы читать очень трудно?

Даже в Guile собираются реализовать Lua, это при том что наверно невозможно сделать лучше чем референсная реализация Lua.

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

Но компенсирует ли всё это то что текст программы читать очень трудно?

Ее легко читать. Синтаксис проще - человеку не приходитсяв уме выполнять работу парсера, смысл кода воспринимается быстрее.

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

Ну я не знаю, считать ли чай и сигареты за 30 рублей веществами, но я что на java писал под этими «веществами», что Scheme изучал под ними же.

Может все дело действительно в неосиляторстве?

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

Чай я завариваю. Курю я как раз сигареты.

Ежели для вас кажется нормой курить чай и заваривать сигареты - может именно в этом причина невозможности прочитать код на Lisp?

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

Это что же, сами лисперы считают что без скобок красивее?

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

Получается что код в итоге, после проверки скобок, становится отформатированным как в Python например, но скобки при этом остаются в тексте.

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

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

Все дело в привычке. Длю _любого_ нового синтаксиса ты не сможешь сразу увидеть структуру вложенности.

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

Получается что код в итоге, после проверки скобок, становится отформатированным как в Python например, но скобки при этом остаются в тексте.

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

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

Вот и я думаю, что лучше изучать новичку: Common List или Phyton...

Если спрашиваете, скорее всего, python. CL - это, скорее религия :) Хотя, внезапно, за бугром он значительно популярнее, чем у нас, и, даже, потихоньку набирает позиции. Не знаю, даже, почему. Для отечественного програмиста - это, скорее, способ расширить кругозор.

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

Можно, конечно, и электричество назвать религией. Только, вот, атеисты жили, живут и не особо жалуются. А без электричества уже тяжеловато :)

С питоном то же самое. Его сейчас везде пихают, и обучиться ему для «налячкать скриптик» - весьма неплохая идея, особенно, учитывая, что там есть куча уже готовых библиотек (у cl с этим не всегда складывается). Плюс, всегда найдется работа, если изучать серьезно. А CL - это уже опционально. И «порог вхождения» там довольно высок. Но, снова же, выше порог вхождения - потом выше уровень. Плюс, например, нормальная мультипарадигменность и еще много «пиченек» присутствует только в common lisp. Во всем остальном - либо вообще нет, либо прикручивается сбоку от основного функционала.

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

Только, вот, атеисты жили, живут и не особо жалуются.

о, эт ты лоровские религиесрачи не видел) Полны подштаники возмущений и негодования :D

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

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

А скажи мне по секрету, в чём фишка DSWM? В чём основные отличия от старого доброго stumpwm? Я с 2009-го его юзаю, а до этого сидел под FWVM, с конфигом, практически не изменившимся с начала нулевых. Когда-то игрался со SCWM, но он, к сожалению, давно мёртв...

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

то, что это питон - это не круто, наверное.

А что нынче круто (клёво, модно, ...)?

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

А что не устраивает в питоне?

всё устраивает :) Думал нечто новое попробовать, также наслышан о больших возможностях дающих при использовании лиспа. А мне не мешало бы использовать инструментарии понавороченее, и подтянуть возможности разностороннего программирования.

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

А скажи мне по секрету, в чём фишка DSWM?

Если коротко, фич в нем больше. Начиная от scratchpad-а в духе ion/notion заканчивая возможностью снапшота десктопа (дамп всех груп, их разбивки и размещения в них окон). Скоро должна быть поддержка подобия пакетного менеджера для модулей (можно будет грузить из инета с резолвом зависимостей, сторонними либсами и т.п.). Когда-то должен стать более юзер-френдли. Если интересуют подробности - пиши в личку :)

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

А с авторами оригинального stumpwm не пробовал связываться по поводу включения фич в мейнстрим? Будет время, я сам погляжу. Спасибо.

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