Предполагается, что шкала будет щёлкать на основе генератора ПСП. Ну, сдёрнуть её программно можно в любой момент. Но если у нас есть устойчивое слежение за фазой дальномерного кода, я предполагаю, что она будет чётко завязана на эпохи кода. По-идее, если сигнальное время вдруг перестанет соответствовать фазе кода, то это должно приводить к срыву слежения.
Конечно, если система символьной синхронизации выяснит, что появилось смещение, то можно шкалу сдёрнуть. Но это будет происходить лишь в случае сбоев в символьной синхронизации - либо в момент начальной инициализации, либо в момент, когда "вдруг" система символьной синхронизации решит перестроиться на позицию. В излучаемом сигнале скачков во взаимосвязи между фазой кода и символами быть не может, в предлагаемой структуре шкалы времени такие скачки тоже не предполагаются - она для этого и нужна.
Счетчики инициализируются один раз? А потом шкала запускается и начинает щелкать непрерывно и без скачков? Или же подстраивается, если вдруг система символьной синхронизации перестроится на одну позицию и т.п.? Иначе говоря: дергает ли её кто-нибудь, она отражает текущее измерение сигнального времени или синхронизируется только один раз, а дальше щелкает на основе только генератора ПСП?
И ещё, хочу отметить. Я тут попутно имитатор делаю, там особенно жизнь упрощается от единого формата времени. Единственное - счётчик символов данных добавить надо, но это специфично для имитатора, поэтому я сюда не включил.
>> Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
В очередной раз подтверждается тезис, что время системы должно быть непрерывным. Как разработчики ГЛОНАСС об этом не думают? Я пытался донести эту мысль до Поваляева - но ГЛОНАСС уже не исправить.
Общесистемную шкалу я предлагаю привязывать к UTC/GPS (в моментах секунд они совпадают).
Шкалу времени каждого из каналов я предлагаю привязывать к времени канала. Т.е., для сигналов GPS к времени GPS данного канала - чтобы из регистров канала буквально считывалось GPS time.
Теперь по счётчику недель. Я предполагал, что шкала времени будет аппаратно реализована в каждом из каналов. Интервал времени, на котором желательно однозначно определять время, равен периоду обновления эфемерид, +-2 часа для GPS, как я помню. Поэтому я решил, что времени в пределах недели, как наиболее крупной единицы времени, хватит. Что касается переходов через номер недели - это решается легко. Текущая неделя известна. Если мы находимся на границе недель, то в счётчике секунд будет либо малое число, значит, новая неделя началась, либо большое число, немного менее 604800 с - значит в канале ещё старая неделя. Разрешить это вполне возможно. А тащить номер недели в регистры каждого из каналов мне кажется не нужным. Секуду лучше тащить. Тут всё завязано больше на возможный период пропадания сигнала. Он может быть несколько секунд, несколько минут, но никак не неделю, это бессмысленно.
Моя идея заключалась в едином представлении времени и для системы, и для каналов. Т.е. я ставил задачу как раз объединить сигнальное и системное время в едином формате, чтобы максимально легко их друг с другом сводить.
С точки зрения системы нужны секунды.
С точки зрения канала - там уже есть эпохи (специфичные для сигнала, но в секунде их целое число).
Вот чтобы всё это соединить вместе, я и написал данный материал.
Почему не совсем время GPS? Всё, что выше секунды - полностью совместимо с временем GPS. Так что можно считать, что это время GPS. Всё, что ниже секунды (эпохи и чипы) - специфично для сигнала. Секунда - точка объединения.
Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ
для всех расчетов берется время GPS.
1. Номер недели всё-таки нужен, чтобы правильно учитывать эфемериды на границе смены недели, и иметь возможность пользоваться старыми альманахами. Вот только ошибок GPS повторять не надо - номер недели должен быть как минимум 16-битным.
2. Представление сигнального времени в канале - это одно, а представление общесистемного времени в приемнике - это всё-таки другое. Для того, чтобы свести все системы нам абсолютно вредно думать об эпохах и чипах ПСП - нам нужны недели, секунды и время внутри секунды.
3. Посему предлагаю общесистемную шкалу времени формировать на основе времени GPS в формате недели-секунды-доли секунды.
Но дальше встает вопрос - мы будем корректировать общесистемное время в приемнике, подстраивая его под время GPS в реальном времени, или же зафиксируем некоторое абстрактное общесистемное время, а в алгоритмах везде будем тащить оценки сдвига шкал? Если грубо, то будем ли мы привязывать метку времени к GPS/UTC или нет?
"Захват сигнала без поиска по известным эфемеридам (или альманахам), что есть в любом нормальном софте, мы даже никогда не делали, а ведь в случае наличия универсального времени это довольно просто." </br> </br>
Это как раз у меня был этот хитрый алгоритм, он сейчас заложен в Альпаку. Оценки выше приведены для сигнала GPS C/A, для ВТ всё будет пропорционально хуже.
Памяти 1 Мб немного, требуемый объём памяти можно разменять на время поиска.
Ограничения вызваны обработкой в процессоре. В ПЛИС можно делать быстрее, но нужна куча ресурсов, это одна из причин, по которой нужно делать новую Альпаку.
Из скидок у меня только простота сигналов - С/А и СТ.
Помнится у Саши был какой-то хитрый алгоритм поиска в программном приемнике, основанный на перемножении спектров.
Эти ограничения - десятки минут, они вызваны возможностями процессора? Или связки какой-то аппаратный поиск в ПЛИС + дополнительная обработка процессором? Как эти цифры привязать к чисто программному поиску?
Вот поэтому я не верю в программный поиск.
Кстати, про Альпаку, возможно, написано неверно - я тут недавно подкрутил поиск, и он стал искать в несколько раз быстрее. Надо померять. Но это всё равно будут десятки минут.
Ты поясни, они там что, программно в ARM быстрый поиск устроить хотят?
Сразу предупреждаю, я тут прикинул, текущая реализация блока поиска в Альпаке для обеспечения требуемых характеристик будет искать, видимо, 3 часа. У тебя ресурсы существенно скромнее.
Поиск в микросхеме Шувалова должен быть намного быстрее - 320 с.
Поиск в нынешнем SiRF'е - 2.5 с, но это, скорее всего, не так.
А, он хитрый. Этот график демонстрирует выигрыш от некогерентного накопления для разных длительностей когерентного накопления. При малом отношении сигнал/шум на интервале когерентного накопления график начинает загибаться.
Ответы на вопросы Ильи.
1. Вероятность 0.1 - на весь поиск, а не на одну ячейку.
2. Доплер - +-DopMax.
3. Коэффициент умножается на теоретический порог.
4. Поле поиска разбито на половину символа по задержке и 1/T по частоте.
5. На последнем графике по оси абсцисс двоичный логарифм от количества некогерентных накоплений.
Проблема, на самом деле, кроется в том, что проект нужен коммерческий, более того, с "существенными конкуретными преимуществами перед мировыми аналогами". Вот тут просто идеей не обойтись, нужна ИДЕЯ. Её у нас нет. Ну, и в коммерческой области никто вертеться не умеет.
PS. Списки требований очень напоминают требования к госконтактам ;) - и это не удивительно, затея примерно такая же, но с другим масштабом. В принципе, я понимаю деятелей от государства, которые это затеяли (я не в плане распила средств) - нужно толкать общество вперёд. Но увы, мне кажется, у них нет для этого методов кроме выделения денег под громкие лозунги. Можно этим, конечно, пользоваться по прямому назначению, т.е. сделать на госденьги что-то коммерчески успешное, но я пока не знаю, как.
Ну, стадия 0 - это когда совсем ничего нет. Т.е., только идея. Ну, и амбиции, конечно.
Идей у нас, правда, подходящих нет пока, но идею можно придумать.
Я считаю, что если туда лезть не ради просто галочки, то лезть нужно в стадию 1, где выше требования. Иначе это просто бесполезное занятие. А насчёт требований - цель нужно ставить и соответствующие пункты закрывать. Так, по "ИТ" нужнен работающий прототип, это сделать можно.
Не думаю, что такая проверка на плагиат будет эффективна. Ведь наша задача - не получить от них правильные координаты, а проверить знания каждого. А так все они пропустят замерянные данные через одну и ту же программу, (написанную два года назад на Python) и с точки зрения цифр плагиата ни у кого не будет - измерения-то все сами делают в аудитории и под контролем.
1) Глонасс дописал
2) ИНС будет в статике, судя по всему
3) Горячий старт нужен: придется делать методику и ставить эксперименты
4) Про замену усреднения на наихудший вариант в итоге забыли(
5) Пять минут установлены генеральским решением
6) Военный приемник придется искать в закромах Родины
7) Сроки Вальсета остались в прежних пределах, характеристики в рамках работы
ps Надо сделать уведомление по почте о комментировании
Оформление в процессе? "Проблемы с Глонассом" пока не полностью, похоже..
Про "карму" сильно, оценил. =)
-Короленко не спрашивали, как с ИНСом, катая в машине приемник и, соответственно, работая по реальным сигналам, измерять их уровень?
Холодный и горячий старт.. Нам нужно оговорить, что приемник стартует нахолодную, или горячие исследования тоже проводить? Ему надо оно?
Про 3D, отсутствие сбоя - хорошо. 5 повторов - тоже хорошо. По пяти повторам отсеивать выбросы? брать нижний не-выброс? Кусочек метролога, который во мне остался после Скачкова, негодует..
-"За Сбой навигационного решения считать отсутствие 3D-решения в течение 10 секунд (верхний предел горячего старта) и более. " - не понял, можно пояснить? При чем здесь предел старта?
-Поиск пять минут - значит куролесица с TTFF идет лесом? А как же требование универсальности методики?
-Военный приемник нам, я так понимаю, дадут? =)
И последнее, просьбы снять характеристики, это ведь не к Вальсету? Сроки..
Считать, конечно можно. Только проще отключить 2D-решение и не считать его за решение. В СН-4706 это можно, а в u-blox разве нельзя?
Надо бы это 3D/2D обсудить с Короленко.
Измерение Кш у В102 прямыми методами (с шумовой головкой) дали цифру 2,2 дБ для GPS и 2 дБ для ГЛОНАСС.
Есть мнение, что формулы неверные, а измерения не точные. Например, не учтен Кш самого анализатора, который равен 24 дБ (!!!)
[ Иерархический вид ]Комментарии
Предполагается, что шкала будет щёлкать на основе генератора ПСП. Ну, сдёрнуть её программно можно в любой момент. Но если у нас есть устойчивое слежение за фазой дальномерного кода, я предполагаю, что она будет чётко завязана на эпохи кода. По-идее, если сигнальное время вдруг перестанет соответствовать фазе кода, то это должно приводить к срыву слежения. Конечно, если система символьной синхронизации выяснит, что появилось смещение, то можно шкалу сдёрнуть. Но это будет происходить лишь в случае сбоев в символьной синхронизации - либо в момент начальной инициализации, либо в момент, когда "вдруг" система символьной синхронизации решит перестроиться на позицию. В излучаемом сигнале скачков во взаимосвязи между фазой кода и символами быть не может, в предлагаемой структуре шкалы времени такие скачки тоже не предполагаются - она для этого и нужна.
У меня тоже все замечания снялись, но в разделе "Государственный контракт->Этапы НИР" в графе "Акт" по-прежнесу стоит что акта нет :(
При выкидыше ГОСТОв я поскупился на эмоциональные комментарии их содержимого. Исправляюсь.
1. В ГОСТах встречаются просто ВОПИЮЩИЕ ошибки. НАП, сделанная по этим ГОСТам, работать не будет никогда.
2. НИ с кем из моих знакомых разработчиков эти ГОСТы согласованы не были - вопрос: кто и для кого их писал?
Так что джентльмены, если надо заткнуть рот нормативщикам и приверженцам ГОСТов - вот хороший пример.
Отлично, ждём подписанный акт...
Сделано
Счетчики инициализируются один раз? А потом шкала запускается и начинает щелкать непрерывно и без скачков? Или же подстраивается, если вдруг система символьной синхронизации перестроится на одну позицию и т.п.? Иначе говоря: дергает ли её кто-нибудь, она отражает текущее измерение сигнального времени или синхронизируется только один раз, а дальше щелкает на основе только генератора ПСП?
Может быть, перенести сюда наше обсуждение по почте? А то потеряется...
И ещё, хочу отметить. Я тут попутно имитатор делаю, там особенно жизнь упрощается от единого формата времени. Единственное - счётчик символов данных добавить надо, но это специфично для имитатора, поэтому я сюда не включил.
>> Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
В очередной раз подтверждается тезис, что время системы должно быть непрерывным. Как разработчики ГЛОНАСС об этом не думают? Я пытался донести эту мысль до Поваляева - но ГЛОНАСС уже не исправить.
Общесистемную шкалу я предлагаю привязывать к UTC/GPS (в моментах секунд они совпадают). Шкалу времени каждого из каналов я предлагаю привязывать к времени канала. Т.е., для сигналов GPS к времени GPS данного канала - чтобы из регистров канала буквально считывалось GPS time.
Теперь по счётчику недель. Я предполагал, что шкала времени будет аппаратно реализована в каждом из каналов. Интервал времени, на котором желательно однозначно определять время, равен периоду обновления эфемерид, +-2 часа для GPS, как я помню. Поэтому я решил, что времени в пределах недели, как наиболее крупной единицы времени, хватит. Что касается переходов через номер недели - это решается легко. Текущая неделя известна. Если мы находимся на границе недель, то в счётчике секунд будет либо малое число, значит, новая неделя началась, либо большое число, немного менее 604800 с - значит в канале ещё старая неделя. Разрешить это вполне возможно. А тащить номер недели в регистры каждого из каналов мне кажется не нужным. Секуду лучше тащить. Тут всё завязано больше на возможный период пропадания сигнала. Он может быть несколько секунд, несколько минут, но никак не неделю, это бессмысленно.
Моя идея заключалась в едином представлении времени и для системы, и для каналов. Т.е. я ставил задачу как раз объединить сигнальное и системное время в едином формате, чтобы максимально легко их друг с другом сводить.
С точки зрения системы нужны секунды.
С точки зрения канала - там уже есть эпохи (специфичные для сигнала, но в секунде их целое число).
Вот чтобы всё это соединить вместе, я и написал данный материал. Почему не совсем время GPS? Всё, что выше секунды - полностью совместимо с временем GPS. Так что можно считать, что это время GPS. Всё, что ниже секунды (эпохи и чипы) - специфично для сигнала. Секунда - точка объединения.
Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
1. Номер недели всё-таки нужен, чтобы правильно учитывать эфемериды на границе смены недели, и иметь возможность пользоваться старыми альманахами. Вот только ошибок GPS повторять не надо - номер недели должен быть как минимум 16-битным.
2. Представление сигнального времени в канале - это одно, а представление общесистемного времени в приемнике - это всё-таки другое. Для того, чтобы свести все системы нам абсолютно вредно думать об эпохах и чипах ПСП - нам нужны недели, секунды и время внутри секунды.
3. Посему предлагаю общесистемную шкалу времени формировать на основе времени GPS в формате недели-секунды-доли секунды.
Но дальше встает вопрос - мы будем корректировать общесистемное время в приемнике, подстраивая его под время GPS в реальном времени, или же зафиксируем некоторое абстрактное общесистемное время, а в алгоритмах везде будем тащить оценки сдвига шкал? Если грубо, то будем ли мы привязывать метку времени к GPS/UTC или нет?
Ну, собственно, разговор не об этом.
"Захват сигнала без поиска по известным эфемеридам (или альманахам), что есть в любом нормальном софте, мы даже никогда не делали, а ведь в случае наличия универсального времени это довольно просто." </br> </br>
Я делал в программном приемнике - даже работало.
Это как раз у меня был этот хитрый алгоритм, он сейчас заложен в Альпаку. Оценки выше приведены для сигнала GPS C/A, для ВТ всё будет пропорционально хуже. Памяти 1 Мб немного, требуемый объём памяти можно разменять на время поиска. Ограничения вызваны обработкой в процессоре. В ПЛИС можно делать быстрее, но нужна куча ресурсов, это одна из причин, по которой нужно делать новую Альпаку.
В поиске всё вообще всегда в ресурсы упирается.
Из скидок у меня только простота сигналов - С/А и СТ.
Помнится у Саши был какой-то хитрый алгоритм поиска в программном приемнике, основанный на перемножении спектров.
Эти ограничения - десятки минут, они вызваны возможностями процессора? Или связки какой-то аппаратный поиск в ПЛИС + дополнительная обработка процессором? Как эти цифры привязать к чисто программному поиску?
Вот поэтому я не верю в программный поиск. Кстати, про Альпаку, возможно, написано неверно - я тут недавно подкрутил поиск, и он стал искать в несколько раз быстрее. Надо померять. Но это всё равно будут десятки минут.
Ты абсолютно прав.
Ты поясни, они там что, программно в ARM быстрый поиск устроить хотят? Сразу предупреждаю, я тут прикинул, текущая реализация блока поиска в Альпаке для обеспечения требуемых характеристик будет искать, видимо, 3 часа. У тебя ресурсы существенно скромнее. Поиск в микросхеме Шувалова должен быть намного быстрее - 320 с. Поиск в нынешнем SiRF'е - 2.5 с, но это, скорее всего, не так.
А, он хитрый. Этот график демонстрирует выигрыш от некогерентного накопления для разных длительностей когерентного накопления. При малом отношении сигнал/шум на интервале когерентного накопления график начинает загибаться.
Да, Жень. И так как мне не хочется изобретать велосипед, надеюсь у тебя проконсультироваться на эту тему. Дооформлю тут всё и пришлю тебе письмо.
Спасибо, сейчас подкорректирую. Правда смысловую нагрузку последнего графика так и не осознал.
Ответы на вопросы Ильи. 1. Вероятность 0.1 - на весь поиск, а не на одну ячейку. 2. Доплер - +-DopMax. 3. Коэффициент умножается на теоретический порог. 4. Поле поиска разбито на половину символа по задержке и 1/T по частоте. 5. На последнем графике по оси абсцисс двоичный логарифм от количества некогерентных накоплений.
К чему это? В НИИ КП задание дали?
Остальные службы не ответили?
Да, расстояние C-A выбивается среди прочих ... надо перемерять лазерным дальномером ещё раз.
А, да, я никак в отпуск не уйду.
Проблема, на самом деле, кроется в том, что проект нужен коммерческий, более того, с "существенными конкуретными преимуществами перед мировыми аналогами". Вот тут просто идеей не обойтись, нужна ИДЕЯ. Её у нас нет. Ну, и в коммерческой области никто вертеться не умеет.
PS. Списки требований очень напоминают требования к госконтактам ;) - и это не удивительно, затея примерно такая же, но с другим масштабом. В принципе, я понимаю деятелей от государства, которые это затеяли (я не в плане распила средств) - нужно толкать общество вперёд. Но увы, мне кажется, у них нет для этого методов кроме выделения денег под громкие лозунги. Можно этим, конечно, пользоваться по прямому назначению, т.е. сделать на госденьги что-то коммерчески успешное, но я пока не знаю, как.
Ну, стадия 0 - это когда совсем ничего нет. Т.е., только идея. Ну, и амбиции, конечно. Идей у нас, правда, подходящих нет пока, но идею можно придумать.
Я считаю, что если туда лезть не ради просто галочки, то лезть нужно в стадию 1, где выше требования. Иначе это просто бесполезное занятие. А насчёт требований - цель нужно ставить и соответствующие пункты закрывать. Так, по "ИТ" нужнен работающий прототип, это сделать можно.
Весело отпуск проводишь))
Не думаю, что такая проверка на плагиат будет эффективна. Ведь наша задача - не получить от них правильные координаты, а проверить знания каждого. А так все они пропустят замерянные данные через одну и ту же программу, (написанную два года назад на Python) и с точки зрения цифр плагиата ни у кого не будет - измерения-то все сами делают в аудитории и под контролем.
http://www.webupd8.org/2010/12/install-virtualbox-40-stable-in-ubuntu.html
Ну вы (Женя с Сашей) на почте флуд развели =)
Есть же комменты - и ящик ничей кондрашка не хватит..
Заглавную страницу перекосило, но дело оказалось не в этой заметке
bug is fixed
Ссылка на картинку не работает :(
Ну вот, запостить не успел, а уже кто-то правит.. =)
Подумаю
3D/2D с Короленко обсудили. Он 2D за полноценное не считает. В u-blox'e не находил команды на отключение 2D решения.
1) Глонасс дописал 2) ИНС будет в статике, судя по всему 3) Горячий старт нужен: придется делать методику и ставить эксперименты 4) Про замену усреднения на наихудший вариант в итоге забыли( 5) Пять минут установлены генеральским решением 6) Военный приемник придется искать в закромах Родины 7) Сроки Вальсета остались в прежних пределах, характеристики в рамках работы
ps Надо сделать уведомление по почте о комментировании
Оформление в процессе? "Проблемы с Глонассом" пока не полностью, похоже..
Про "карму" сильно, оценил. =)
-Короленко не спрашивали, как с ИНСом, катая в машине приемник и, соответственно, работая по реальным сигналам, измерять их уровень?
Холодный и горячий старт.. Нам нужно оговорить, что приемник стартует нахолодную, или горячие исследования тоже проводить? Ему надо оно?
Про 3D, отсутствие сбоя - хорошо. 5 повторов - тоже хорошо. По пяти повторам отсеивать выбросы? брать нижний не-выброс? Кусочек метролога, который во мне остался после Скачкова, негодует..
-"За Сбой навигационного решения считать отсутствие 3D-решения в течение 10 секунд (верхний предел горячего старта) и более. " - не понял, можно пояснить? При чем здесь предел старта?
-Поиск пять минут - значит куролесица с TTFF идет лесом? А как же требование универсальности методики?
-Военный приемник нам, я так понимаю, дадут? =)
И последнее, просьбы снять характеристики, это ведь не к Вальсету? Сроки..
Считать, конечно можно. Только проще отключить 2D-решение и не считать его за решение. В СН-4706 это можно, а в u-blox разве нельзя? Надо бы это 3D/2D обсудить с Короленко.
По оси X лучше сделать логарифмический масштаб, так нагляднее.
Измерение Кш у В102 прямыми методами (с шумовой головкой) дали цифру 2,2 дБ для GPS и 2 дБ для ГЛОНАСС. Есть мнение, что формулы неверные, а измерения не точные. Например, не учтен Кш самого анализатора, который равен 24 дБ (!!!)
Подсветка кода Geshi не переваривается
Указан неподдерживаемый язык.
Вы должны указать язык следующим образом: <source lang="html4strict">...</source>
Поддерживаемые языки:
4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, asm, asp, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, oobas, oracle11, oracle8, oxygene, oz, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, python, q, qbasic, rails, rebol, reg, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, uscript, vala, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic
Ответ на коммент
Комментарий номер раз
Войдите, чтобы комментировать.