8-900-374-94-44
Previous Entry | Next Entry
Статья на тему различных методов установки wxWidgets на разных платформах откладывается на неопределённое время. Вместо неё решил пока написать коротенькую заметку о том, как быстро подготовить компьютер с ОС Windows для программирования с использованием wx (на альтернативных операционках всё проще, например во FreeBSD достаточно дать команду cd /usr/ports/devel/codeblocks/ && make install clean и подождать, пока соберётся CodeBlocks, wxWidgets, GTK+, X11 и так далее =)).
| October 2018 | ||||||
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
[+1]Powered by LiveJournal.com
Rich Turner
15 ноября 2018 г. 1 0
В этом посте мы обсудим улучшения, которые мы вносим во внутренний текстовый буфер консоли Windows, позволяя ему лучше хранить и обрабатывать текст Unicode и UTF-8.
Этот список будет обновляться по мере публикации новых сообщений:
[Источник: Дэвид Фаррелл, «Создание кодировщика UTF-8 в Perl»]
Наиболее заметным аспектом терминала командной строки является то, что он отображает текст, выдаваемый вашей оболочкой и/или инструментами командной строки.
и приложения в сетке моноширинных ячеек — по одной ячейке на символ/символ/глиф. Отлично, это просто. Как это может быть сложно, ведь это всего лишь буквы? Неееет! Читай дальше!
Текст есть текст есть текст. Или это?
Если вы говорите на языке, возникшем в Западной Европе (например, на английском, французском, немецком, испанском и т. д.), скорее всего, ваш письменный алфавит довольно однороден — 10 цифр, 26 отдельных букв — заглавные и строчные. case = всего 62 символа. Теперь добавьте около 30 символов пунктуации, всего вам понадобится около 95 символов. Но если вы из Восточной Азии (например, китайцы, японцы, корейцы, вьетнамцы и т. д.), вы, скорее всего, будете читать и писать текст с еще несколькими символами… всего более 7000!
Учитывая эту сложность, как компьютеры представляют, определяют, хранят, обмениваются/передают и отображают эти различные формы текста эффективным и стандартизированным/обычно понятным способом?
На заре современных цифровых вычислений централизация была сосредоточена вокруг Великобритании и США, поэтому английский язык был преобладающим языком и используемым алфавитом.
Как мы видели выше, ~95 символов английского алфавита (и необходимая пунктуация) могут быть индивидуально представлены с использованием 7-битных значений (0-127), с оставленным местом для дополнительных невидимых управляющих кодов.
В 1963 году Американский национальный институт стандартов (ANSI) опубликовал стандарт X3.4-1963 для Американского стандартного кода для обмена информацией (ASCII), который стал основой того, что мы сейчас знаем как стандарт ASCII.
… и у Microsoft плохая репутация из-за названий вещей 😉 Первоначальный стандарт X3.4-1963 оставил 28 значений неопределенными и зарезервированными для использования в будущем. Воспользовавшись случаем, Международный консультативный комитет по телеграфу и телефону (CCITT, от французского: Comité Consultatif International Téléphonique et Télégraphique) предложил изменить раскладку ANSI, из-за которой символы нижнего регистра отличались по битовому шаблону от символов верхнего регистра на всего один бит.
Это упрощенное определение/сопоставление регистра символов и конструкция клавиатур и принтеров.
Со временем в некоторые символы и управляющие коды были внесены дополнительные изменения, пока мы не пришли к хорошо зарекомендовавшей себя таблице символов ASCII, которая поддерживается практически всеми используемыми сегодня вычислительными устройствами.
]4 7-битная таблица ASCII
Однако быстрое распространение компьютеров в Европе поставило новую задачу: как представить текст на языках, отличных от английского. Например, как должны быть представлены буквы с диакритическими знаками, умлауты и дополнительные символы?
Для этого таблица ASCII была расширена за счет добавления дополнительного бита, что сделало символы 8-битными, добавив 127 «расширенных символов»:
]5 Расширенные 8-битные символы ASCII
по-прежнему не предоставлял достаточно места для представления всех символов, глифов и символов, необходимых пользователям компьютеров по всему миру, многим из которых необходимо было представлять и отображать дополнительные символы / глифы.
Итак, кодовые страницы были введены.
Кодовые страницы определяют наборы символов для «расширенных символов» от 0x80 до 0xff (и, в некоторых случаях, несколько не отображаемых символов между 0x00 и 0x19). Выбрав другую кодовую страницу, Терминал может отображать дополнительные глифы для европейских языков и некоторые блочные символы (см. выше), текст CJK, вьетнамский текст и т. д.
любой стандартизации кодовых страниц в целом усложнил обработку и рендеринг текста, привел к ошибкам и создал серьезные проблемы взаимодействия и взаимодействия с пользователем.
Еще хуже то, что 128 дополнительных глифов даже близко не обеспечивают достаточное количество символов для представления некоторых языков: например, в китайском языке средней школы используется 2200 идеограмм, еще несколько сотен используются в повседневной жизни, и более 7000 идеограмм в общий.
Очевидно, что кодовые страницы — дополнительные наборы из 128 символов — не являются масштабируемым решением этой проблемы.
16 — 1 == 65 535 символов. Однако, несмотря на попытки стандартизировать японскую кодировку Shift JIS и кодировку EUC-JP, совместимую с ASCII переменной длины, кодировки кодовых страниц DBCS часто были пронизаны проблемами и не давали универсального решения проблемы кодирования текста.
Что нам действительно было нужно, так это универсальный код для текстовых данных.
Разработка Unicode началась в 1987 году инженерами Xerox и Apple. Первоначальная спецификация Unicode-88 была опубликована в феврале 1988 года и с тех пор постоянно совершенствовалась и обновлялась, добавляя новые представления символов, дополнительную языковую поддержку и даже эмодзи 😊
.Чтобы узнать больше об истории Unicode, прочтите это! Сегодня Unicode поддерживает до 1 112 064 допустимых «кодовых точек», каждая из которых представляет один символ / символ / глиф / идеограмму / и т.
«1,2 миллиона кодовых точек должно быть достаточно для всех» — источник: Rich Turner, октябрь 2018 г. Текстовые данные Unicode могут быть закодированы разными способами, каждый из которых имеет свои сильные и слабые стороны:
| Кодировка | Примечания | # Байтов на кодовую точку | Плюсы | Минусы |
| UTF-32 | Каждое допустимое 32-битное значение является прямым индексом для отдельной кодовой точки Unicode. | 4 | Не требуется декодирование | Потребляет много места |
| UTF-16 | Кодирование переменной длины, требующее одного или двух 16-битных значений для представления каждой кодовой точки. | 2/4 | Простое декодирование | Занимает 2 байта даже для текста ASCII. Может быстро закончиться необходимостью 4 байта |
| УКС-2 | Предшественник UTF-16. 16-битная кодировка фиксированной длины, используемая внутри Windows, Java и JavaScript. | 2 | Простое декодирование | Занимает 2 байта даже для текста ASCII. Невозможно представить некоторые кодовые точки |
| UTF-8 | Кодирование переменной длины. Требуется от одного до четырех байтов для представления всех кодовых точек Unicode. | 1-4 | Требования к эффективному, детализированному хранилищу | Умеренная стоимость декодирования |
| Другие | Существуют и другие кодировки, но они не получили широкого распространения. | Н/Д | Н/Д | Н/Д |
Во многом благодаря своей гибкости и эффективности хранения/передачи UTF-8 стал преобладающим механизмом кодирования текста в Интернете: на сегодняшний день (октябрь 2018 г.
) 92,4% всех веб-страниц закодированы в UTF-8!
]16 Популярность кодировки UTF-8 для веб-страниц (источник: Википедия)
Следовательно, все, что обрабатывает текст,0025 не менее иметь возможность поддерживать текст UTF-8.
Чтобы узнать больше о кодировании текста и Unicode, прочитайте замечательную статью Джоэла Спольски здесь: Абсолютный минимум, который каждый разработчик программного обеспечения обязательно должен знать о Unicode и наборах символов (без оправданий!)
Увы, консоль Windows (в настоящее время) не может поддерживать текст UTF-8!
Консоль Windows была создана еще на заре Windows, еще до того, как появился сам Unicode! Тогда было принято решение представлять каждый текстовый символ как 16-битное значение фиксированной длины (UCS-2). Таким образом, текстовый буфер консоли содержит 2 байта wchar_t значений на ячейку сетки, размер x столбцов на y строк.
Несмотря на то, что этот дизайн поддерживает консоль более 25 лет, быстрое внедрение UTF-8 начало вызывать проблемы:
кодировке, он не может представлять все кодовые точки Unicode.
Еще одна связанная, но отдельная проблема с консолью Windows заключается в том, что, поскольку GDI используется для рендеринга текста консоли, а GDI не поддерживает возврат шрифта, консоль не может отображать глифы для кодовых точек, которые не существуют в выбранном в данный момент шрифте!
Font-fallback — это возможность динамического поиска и загрузки шрифта, похожего на текущий выбранный шрифт, но содержащего глиф, отсутствующий в текущем выбранном шрифте. Эти объединенные проблемы являются причиной того, что консоль Windows не может (в настоящее время) отображать многие сложные китайские идеограммы и не может отображать смайлики.
Смайлик? СРОЧНО? На первый взгляд это может показаться тривиальным, но это проблема, поскольку некоторые инструменты теперь генерируют эмодзи, например, для обозначения результатов теста, а исходный код некоторых языков программирования поддерживает/требует Unicode, включая эмодзи!
[Источник: вы можете использовать символы эмодзи в именах переменных, констант, функций и классов Swift]
Но я отвлекся…
цвет переднего плана и фона, а также любую другую необходимую информацию о каждой ячейке.
Эти атрибуты должны храниться эффективно и быстро — нет необходимости хранить фоновую и основную информацию для каждой ячейки отдельно, тем более что большинство консольных приложений/инструментов выводят довольно однородно окрашенный текст, но сохранение и извлечение атрибутов не должно излишне снижать производительность рендеринга.
Давайте покопаемся и выясним, как со всем этим справляется Консоль! 😊
Как обсуждалось в предыдущем посте этой серии, команда консоли была занята капитальным ремонтом внутренних компонентов консоли Windows для последних нескольких выпусков Win10, тщательно модернизируя, объединяя в модули, упрощая и улучшая код и функции консоли… при этом не жертвуя заметно производительность, а не изменение текущего поведения.
Для каждого серьезного изменения мы оцениваем и прототипируем несколько подходов, а также измеряем производительность консоли, объем используемой памяти, энергопотребление и т. д., чтобы найти лучшее реальное решение.
Мы использовали тот же подход для работы по улучшению буфера, которая была начата до выпуска 1803 и продолжается после 1809..
Основная проблема, которую необходимо решить, заключалась в том, что консоль ранее сохраняла текстовые данные каждой ячейки в виде 2-байтовых значений фиксированной длины UCS-2 wchar_t .
Для полной поддержки всех символов Unicode нам требовался более гибкий подход, не добавляющий заметных затрат на обработку или память в общем случае, но способный динамически обрабатывать дополнительные байты текстовых данных для ячеек, содержащих многобайтовые символы Unicode.
Мы рассмотрели несколько подходов, создали прототипы и измерили некоторые из них, что помогло нам исключить некоторые потенциальные подходы, которые оказались неэффективными в реальных условиях.
В итоге мы пришли к следующей архитектуре:
]21 Архитектура текстового буфера консоли
Сверху (синие прямоугольники исходного буфера):
д., и содержит TextBufferНесколько ключевых изменений были внесены в реализацию буфера консоли (обозначены оранжевым на схеме выше), в том числе:
Это упрощенное определение/сопоставление регистра символов и конструкция клавиатур и принтеров.
д. Это должно обеспечить множество адресуемых кодовых точек в будущем, особенно с учетом того, что «Юникод 11 в настоящее время определяет 137 439 кодовых точек».символов, охватывающих 146 современных и исторических шрифтов, а также несколько наборов символов и эмодзи» [источник: Википедия, октябрь 2018 г.] CharRowCell::DbcsAttribute хранит информацию о форматировании о том, насколько широкими являются текстовые данные для символов DBCS. Не все биты использовались, поэтому был добавлен дополнительный флаг , чтобы указать, превышает ли длина текстовых данных для ячейки один 16-битный wchar_t .
Если этот флаг установлен, консоль будет извлекать текстовые данные из UnicodeStorage . Добавлен UnicodeStorage , который содержит карту координат {строка:столбец} для набора 16-битных wchar значений. Это позволяет буферу хранить произвольное количество значений wchar для каждой отдельной ячейки в консоли, которая должна хранить дополнительные текстовые данные Unicode, гарантируя, что консоль останется невосприимчивой к расширению до области и диапазона текстовых данных Unicode в будущем. . А поскольку UnicodeStorage — это карта, затраты на поиск текста переполнения постоянны и быстры! Итак, представьте, если ячейке нужно отобразить смайлик улыбающегося лица Unicode: 😀 Представление этого смайлика в байтах (с прямым порядком байтов): 0xF0 0x9F 0x98 0x80 , или прописью: 0x9FF0 0x8098 . Ясно, что этот глиф эмодзи не помещается в один 2-байтовый wchar_t .
Таким образом, в новом буфере будет установлен флаг «переполнения» DbcsAttribute CharRowCell, указывающий, что консоль должна искать данные в кодировке UTF-16 для этого {row:col} , хранящегося в контейнере карты UnicodeStorage.
Ключевой момент, который следует отметить в отношении этого подхода, заключается в том, что нам не нужно дополнительное хранилище, если символ может быть представлен как одно 8/16-битное значение: нам нужно хранить дополнительный «переполненный» текст только тогда, когда это необходимо. Это гарантирует, что в наиболее распространенном случае — при хранении символов ASCII и более простых символов Unicode — мы не увеличиваем объем потребляемых данных и не снижаем производительность.
Если вы используете Windows 10 October 2018 Update (сборка 1809), вы уже используете этот новый буфер!
Мы протестировали новый буфер, прежде чем незаметно включить его в сборки Insider за несколько месяцев до выпуска 1809, и внесли некоторые ключевые улучшения до выпуска 1809.
Не совсем так!
Мы также работаем над дальнейшим улучшением реализации буфера в последующих обновлениях ОС (и с помощью инсайдерских сборок, предшествующих каждому выпуску ОС).
Указанные выше изменения позволяют хранить только одну кодовую точку на CharRowCell . Более сложные глифы, для которых требуется несколько кодовых точек, пока не поддерживаются, но мы работаем над добавлением этой возможности в будущем выпуске ОС.
Текущие изменения также не охватывают то, что требуется для нашего «режим обработанного ввода», который представляет редактируемую строку ввода для таких приложений, как CMD.exe. Мы планируем и активно обновляем код для всплывающих окон, псевдонимов команд, истории команд и самой редактируемой строки ввода, чтобы также поддерживать полную поддержку Unicode.
И пока не пытайтесь отображать эмодзи — для этого требуется новый движок рендеринга, который поддерживает возврат шрифта — возможность динамически находить, загружать и отображать глифы из шрифтов, отличных от текущего выбранного шрифта.
И это тема целого поста в другой раз 😉.
Оставайтесь с нами, скоро появятся новые сообщения!
Мы с нетерпением ждем ваших мыслей — не стесняйтесь выключать звук ниже или пинговать Рича в Твиттере.
LaTeX широко используется в науке, и программирование стало важным аспектом в нескольких областях науки, отсюда и потребность в инструменте, правильно отображающем код. В этой статье объясняется, как использовать стандартную среду verbatim , а также листинги пакета , которые предоставляют более продвинутые функции форматирования кода.
В этой отдельной статье обсуждается пакет minted , который выполняет подсветку синтаксиса с помощью Python 9.0213 pygmentize библиотека .
Инструментом по умолчанию для отображения кода в LaTeX является verbatim , который генерирует вывод моноширинным шрифтом.
\begin{verbatim}
Текст заключен внутри окружения \texttt{verbatim}
печатается напрямую
и все команды \LaTeX{} игнорируются.
\end{дословно}
Открыть этот пример на обратной стороне
Приведенный выше код выдает следующий результат:
Как и в примере во введении, весь текст печатается с разрывами строк и пробелами. Существует версия этой команды со звездочкой, вывод которой немного отличается.
\начать{дословно*}
Текст заключен внутри окружения \texttt{verbatim}
печатается напрямую
и все команды \LaTeX{} игнорируются.
\end{дословно*}
Открыть этот пример на обратной стороне
Приведенный выше код выдает следующий результат:
В этом случае пробелы выделяются специальным символом «видимый пробел»: ␣ .
Текст, подобный Verbatim, также может быть использован в абзаце с помощью \verb 9Команда 0214.
В каталоге \verb|C:\Windows\system32| можно найти много окон системные приложения. Команда \verb+\ldots+ создает \ldots
Открыть этот пример на обратной стороне
Приведенный выше код выдает следующий результат:
Команда \verb|C:\Windows\system32| печатает текст внутри разделителей | в дословном формате. В качестве разделителя можно использовать любой символ, кроме букв и * . Например \verb+\ldots+ использует + в качестве разделителя.
Чтобы использовать среду lstlisting , вы должны добавить следующую строку в преамбулу вашего документа:
\usepackage{списки}
Вот пример использования среды lstlisting из пакета listings :
\begin{lstlisting}
импортировать numpy как np
def incmatrix(genl1,genl2):
м = len(genl1)
n = длина (genl2)
M = None # чтобы стать матрицей инцидентности
VT = np. zeros((n*m,1), int) #фиктивная переменная
# вычислить побитовую матрицу xor
M1 = битовая матрица (genl1)
M2 = np.triu (bitxormatrix (genl2), 1)
для я в диапазоне (м-1):
для j в диапазоне (i+1, m):
[r,c] = np.where(M2 == M1[i,j])
для k в диапазоне (len (r)):
VT[(i)*n + r[k]] = 1;
VT[(i)*n + c[k]] = 1;
VT[(j)*n + r[k]] = 1;
VT[(j)*n + c[k]] = 1;
если M равно None:
M = np.copy(VT)
еще:
M = np.concatenate ((M, VT), 1)
VT = np.zeros ((n * m, 1), целое число)
вернуть М
\end{список}
Откройте пример объявлений на обратной стороне
Приведенный выше код выдает следующий результат:
В этом примере выходные данные игнорируют все команды LaTeX, а текст печатается с сохранением всех разрывов строк и пробелов.
Давайте посмотрим второй пример:
zeros((n*m,1), int) #фиктивная переменная
# вычислить побитовую матрицу xor
M1 = битовая матрица (genl1)
M2 = np.triu (bitxormatrix (genl2), 1)
для я в диапазоне (м-1):
для j в диапазоне (i+1, m):
[r,c] = np.where(M2 == M1[i,j])
для k в диапазоне (len (r)):
VT[(i)*n + r[k]] = 1;
VT[(i)*n + c[k]] = 1;
VT[(j)*n + r[k]] = 1;
VT[(j)*n + c[k]] = 1;
если M равно None:
M = np.copy(VT)
еще:
M = np.concatenate ((M, VT), 1)
VT = np.zeros ((n * m, 1), целое число)
вернуть М
\end{список}
\begin{lstlisting}[язык=Python]
импортировать numpy как np
def incmatrix(genl1,genl2):
м = len(genl1)
n = длина (genl2)
M = None # чтобы стать матрицей инцидентности
VT = np.zeros((n*m,1), int) #фиктивная переменная
# вычислить побитовую матрицу xor
M1 = битовая матрица (genl1)
M2 = np.triu (bitxormatrix (genl2), 1)
для я в диапазоне (м-1):
для j в диапазоне (i+1, m):
[r,c] = np.where(M2 == M1[i,j])
для k в диапазоне (len (r)):
VT[(i)*n + r[k]] = 1;
VT[(i)*n + c[k]] = 1;
VT[(j)*n + r[k]] = 1;
VT[(j)*n + c[k]] = 1;
если M равно None:
M = np.copy(VT)
еще:
M = np.concatenate ((M, VT), 1)
VT = np.zeros ((n * m, 1), целое число)
вернуть М
\end{список}
Откройте пример объявлений на обратной стороне
Приведенный выше код выдает следующий результат:
Дополнительный параметр в скобках [language=Python] включает подсветку кода для данного конкретного языка программирования (Python), специальные слова выделены жирным шрифтом, а комментарии выделены курсивом.
Полный список поддерживаемых языков программирования см. в справочном руководстве.
Код обычно хранится в исходном файле, поэтому команда, которая автоматически извлекает код из файла, становится очень удобной.
Следующий код будет напрямую импортирован из файла
\lstinputlisting[language=Octave]{BitXorMatrix.m}
Команда \lstinputlisting[language=Octave]{BitXorMatrix.m} импортирует код из файла BitXorMatrix.m , дополнительный параметр в скобках включает подсветку языка для языка программирования Octave. Если вам нужно импортировать только часть файла, вы можете указать два параметра через запятую внутри скобок. Например, чтобы импортировать код из строки 2 в строку 12, предыдущая команда становится
\lstinputlisting[language=Octave, firstline=2, lastline=12]{BitXorMatrix.m}
Если первая строка или последняя строка опущены, предполагается, что значения находятся в начале или в конце файла соответственно.
Форматирование кода с помощью пакета listing имеет широкие возможности настройки. Давайте посмотрим на пример
\documentclass{статья}
\usepackage{списки}
\usepackage{xcolor}
\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0,5,0,5,0,5}
\definecolor{codepurple}{rgb}{0,58,0,0,82}
\definecolor{backcolor}{rgb}{0,95,0,95,0,92}
\lstdefinestyle{мой стиль}{
backgroundcolor=\color{backcolor},
комментарий стиль = \ цвет {codegreen},
ключевой стиль=\цвет{пурпурный},
numberstyle=\tiny\color{codegray},
stringstyle=\color{codepurple},
базовый стиль=\ttfamily\размер сноски,
breakatwhitespace=ложь,
линии разрыва = истина,
заголовокпоз=б,
keepspaces=true,
числа = слева,
цифрыep=5pt,
выставочные пространства = ложь,
showstringspaces=false,
шоутабс=ложь,
вкладка = 2
}
\lstset{стиль=мой стиль}
\начать{документ}
Следующий код будет напрямую импортирован из файла
\lstinputlisting[language=Octave]{BitXorMatrix. m}
\конец{документ}
Приведенный выше код выдает следующий результат:
Как видите, цветовая гамма и стиль кода значительно улучшают читабельность.
В этом примере импортируется пакет xcolor , а затем используется команда \definecolor{}{}{} для определения новых цветов в формате rgb, которые будут использоваться позже. Для получения дополнительной информации см.: использование цветов в LaTeX.
По сути, есть две команды, которые генерируют стиль для этого примера:
m}
\конец{документ}
\lstdefinestyle{mystyle}{...} \lstset{style=mystyle} 
Как и в случае с плавающими элементами (таблицы и рисунки), к списку можно добавлять подписи для более наглядного представления.
\begin{lstlisting}[language=Python, caption=пример Python]
импортировать numpy как np
def incmatrix(genl1,genl2):
м = len(genl1)
n = длина (genl2)
M = None # чтобы стать матрицей инцидентности
VT = np.zeros((n*m,1), int) #фиктивная переменная
# вычислить побитовую матрицу xor
M1 = битовая матрица (genl1)
M2 = np.triu (bitxormatrix (genl2), 1)
для я в диапазоне (м-1):
для j в диапазоне (i+1, m):
[r,c] = np.where(M2 == M1[i,j])
для k в диапазоне (len (r)):
VT[(i)*n + r[k]] = 1;
VT[(i)*n + c[k]] = 1;
VT[(j)*n + r[k]] = 1;
VT[(j)*n + c[k]] = 1;
если M равно None:
M = np.copy(VT)
еще:
M = np. concatenate ((M, VT), 1)
VT = np.zeros ((n * m, 1), целое число)
вернуть М
\end{список}
Откройте пример объявлений на обратной стороне
Приведенный выше код выдает следующий результат:
Добавление разделенного запятыми параметра caption=Python example внутри скобок включает заголовок. Эта подпись может быть позже использована в списке объявлений.
\lstlistoflistings
Откройте эту ссылку, чтобы попробовать пример пакета списков на Overleaf.
поддерживаемые языки (и их диалекты, если возможно, диалекты указаны в скобках, а диалекты по умолчанию выделены курсивом):
| ABAP (R/2 4.3, R/2 5.0, R/3 3.1, R/3 4.6C, R/3 6.10 ) | АСЛ |
| Ада ( 2005 , 83, 95) | Алгол (60, 68 ) |
| Муравей | Ассемблер(Motorola68k, x86masm) |
| Awk ( gnu , POSIX) | баш |
| Базовый (визуальный) | C ( ANSI , Гендель, объектив, острый) |
| C++ (ANSI, GNU, ISO , Visual) | Caml ( свет , объектив) |
| КИЛ | Чистый |
| Кобол (1974, 1985 , IBM) | Комал 80 |
command. com ( WinXP ) | Комсол |
| кш | Делфи |
| Эйфель | Элан |
| Эрланг | Эйфория |
| Фортран (77, 90, 95 ) | ГКЛ |
| Гнуплот | Хаскелл |
| HTML | IDL (пусто, CORBA) |
| сообщить | Java (пусто, AspectJ) |
| JVMIS | кш |
| Языкознание | Лисп (пусто, Авто) |
| Логотип | сделать (пусто, гну) |
| Mathematica (1.0, 3.0, 5.2 ) | Матлаб |
| Меркурий | МетаПост |
| Миранда | Мицар |
| МЛ | Модуль-2 |
| МуПАД | НАСТРАН |
| Оберон-2 | OCL (декоративная, OMG ) |
| Октава | унций |
| Паскаль (Borland6, Стандарт , XSC) | Перл |
| PHP | PL/I |
| Плазма | Постскриптум |
| POV | Пролог |
| Промела | PSTриксы |
| Питон | Р |
| Уменьшить | Рекс |
| РГБ | Рубин |
| S (пустой, ПЛЮС) | САС |
| Scilab | ш |
| ШЕЛXL | Simula ( 67 , CII, DEC, IBM) |
| СПАРКЛ | SQL |
| ткл (пустой, тк) | TeX (AlLaTeX, обычный, LaTeX, простой , примитивный) |
| VBScript | Верилог |
| VHDL (пустой, AMS) | ВРМЛ ( 97 ) |
| XML | XSLT |
concatenate ((M, VT), 1)
VT = np.zeros ((n * m, 1), целое число)
вернуть М
\end{список}