Издание на SBCL 2.3.11, реализация на езика Common Lisp

Публикуван е выпуск на SBCL 2.3.11 (Steel Bank Common Lisp), свободна реализация на езика за програмиране Common Lisp. Кодът на проекта е написан на езиците Common Lisp и C и се разпространява под лиценз BSD. В новия выпуск:

• Малки несъответствия:
  • Потоковете с параметър external-format, зададен с помощта на «:REPLACEMENT», ще прилагат данните за заместване на информацията един път в потока, което води до грешки при декодирането (а не както в някои случаи, един път за последователността от байтове, всеки от които не е допустима начална позиция на символ за този external-format).
  • Определителите на external-format при използването на неподдържани или неразпознати варианти сега ще сигнализират за грешка.
• Подобрения:
  • В процеса на разпределяне на обобщени функции, използващи стандартен или кратък метод на комбиниране, при отсъствие на основни приложими методи системата ще извика обобщената функция SB-PCL:NO-PRIMARY-METHOD, чийто стандартен поведение е да сигнализира за грешка. Потребителите могат да определят методи за тази обобщена функция.
  • Външните формати вече поддържат варианти на нов ред за еднобайтови и utf-8 кодировки.
  • Декодирането и кодираното на символи, сигнализирано от функциите на потоците или октетите, сега поддържа USE-VALUE рестартиране за обработчици, предоставящи замествания за вход или изход.
  • READ-SEQUENCE и WRITE-SEQUENCE поддържат последователности, определяни от потребителите; стандартната реализация обработва елемент по елемент, четейки или записвайки един байт или символ от/в потока съответно.
• Оптимизации:
  • Външните формати с :REPLACEMENT вече не свързват обработчици за грешки на функциите за конвертиране, което трябва да намали броя на cons-операциите и да увеличи производителността.
  • Ако :EXTERNAL-FORMAT е аргумент за STRING-TO-OCTETS или OCTETS-TO-STRING и е константа по време на компилация, то външният формат се разрешава по време на зареждане, а не при всеки повик.
  • Компилаторът може да ограничи типовете аргументи за някои функции на база изведен или предполагаем тип на стойността, която тази функция връща.
  • Компилаторът намалява броя на излишните проверки на типовете в функции, подобни на ASSOC и GETF.
• Корекции на грешки:
  • OCTETS-TO-STRING коректно сигнализира или прилага замени при използване на еднобайтови външни формати за нешироко разпространени кодировки (например, iso-8859-3), а не взема битовете от адрес NIL и не конвертира тези битове в символи.
  • FILE-STRING-LENGTH вече връща NIL, ако входните стойности не са кодирани във външния поток.
  • Табличните многобайтови външни формати (EUC-JP, Shift-JIS, GBK) вече отчитат заместващия символ (във външен формат или чрез повторно стартиране) при кодиране в октети.
  • Конвертирането от октети с помощта на външни формати UCS-2, UCS-4 и UTF-32 вече не чете края на масива от октети с нецяло число от две или четирибайтови единици.
  • Конвертирането от октети с помощта на външни формати UCS-2, UCS-4 и UTF-32 вече връща обикновен низ, както изисква определението за типа OCTETS-TO-STRING.
  • Прилагането на неправилен външен формат на аргумента за OPEN или WITH-OPEN-FILE (или вътрешно MAKE-FD-STREAM) вече не води до изтичане на файлов дескриптор.
  • SB-ROTATE-BYTE определя спецификациите на BYTE извън допустимия диапазон преди изпълнението на cons много големи цели числа за използване на маски и смени.
  • Поправка на извода на типа при компилиране на формите SB-ROTATE-BYTE с ненулево POSITION в определението за байт.
  • Поправка на множество грешки в асемблера при компилиране на MAKE-ARRAY, MAKE-STRING и други с голям постоянен размер.
  • Поправка на вътрешна грешка при компилиране (SETF-SBIT) с голям постоянен индекс.
  • Поправка на вътрешна грешка на компилатора за лямбда-функция с неправилен списък от параметри в LABELS.
  • Поправка на вътрешна грешка на компилатора при компилиране на някои безкрайно рекурсивни форми на LABELS.
  • Поправка на вътрешна грешка на компилатора при опит за вграждане на преход към вече изтрит етикет.
  • FILL-POINTER никога не трябва да е отрицателен.

Източник: opennet.ru