Страница 2 из 19 ПерваяПервая 12345678912 ... ПоследняяПоследняя
Показано с 16 по 30 из 280
  1. #16
    Very High Power Аватар для R8TX
    Регистрация
    20.04.2005
    Адрес
    Оренбург, Россия
    Возраст
    58
    Сообщений
    3,390
    Поблагодарили
    614
    Поблагодарил
    119
    Только когда будете выкладывать, делайте еще и deb-пакеты, очень не хочется захламливать систему установленным помимо менеджера пакетов.

  2. #17
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    Ну если буду участвовать, то deb пакеты могу на себя взять.
    Я только не понимаю все-таки зачем там БД?
    Если все оформитье в Perl при обработке теста то на размерах, не думаю что больше 10000 QSO, работа с текстовым файлмо не особо медленнее чем с БД, а одним костылем меньше...
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

  3. #18
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    Цитата Сообщение от RN9RQ Посмотреть сообщение
    Ну если буду участвовать, то deb пакеты могу на себя взять.
    Я только не понимаю все-таки зачем там БД?
    Роман, я думаю (хотя это сугубо моё мнение), что когда в контесте работает не один оператор, а организована сетка, то лучше иметь всё же базу данных, чем писать всё в файлы. Иначе как-то кривовато. По deb пакетам - это хорошо, что ты можешь ими заняться.

    Я сегодня сравнил всё же на работе (в свободное время) две базы SQLite и Firebird. SQLite будет полегче конечно, проще конфигурится, но не имеет хранимых процедур, что есть минус. С ними привычнее как-то. Firebird поддерживает в полной мере хранимые процедуры и UDF. Кроме того регулярные выражения на уровне самой базы. Плюсов больше.

    Ко всем:

    Теперь по концепту и функциональности, вернёмся к началу. Надо решить, от какой печки мы будем танцевать. Стоит ли брать что-то за основу? И если да, то что и в какой мере? Давайте составим сначала список того, что мы хотим видеть и получить от лога, включая и функциональность конечно. Затем раскинем по задачам и по roadmap. И начнём, помолясь, перед дальней дорогой...

    Касательно реализации самого интерфейса есть, как видно из постов два направления: Qt Widgets (+ Custom) и TCL/TK. Оба направления имеют право на жизнь. Кто за какое? Только давайте чётко обосновывать, чтобы сделать выбор. Мой выбор останавливается на Qt в силу а) более удобного способа расширения б) наличия массы готовых графических библиотек и контролей в) то, что это хорошо интегрируется с кодом на С++ и с Perl. Слушаем остальных.

    ПС Как лучше нам предварительную спецификацию оформить? В виде UML диаграммы классов/модулей или есть другие мысли?

  4. #19
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    даже когда работает сетка, нет настоящего распределения, все вполне легко реализуется обычными текстовыми фалами. Это ИМХО задача не для БД.
    А по поводу реализаций интерфеса это не сейчас надо решать, главное грамотно проработать концепцию.
    Изначально предлагаю клиент серверный вариант даже в режиме синглоп.
    Это избавит от лишнего кода в итоге

    Добавлено через 1 минуту
    Предлагаю начать с проработки разных алгоритмов сетеого протокола, чтобы предусмотреть все варианты.
    Последний раз редактировалось RN9RQ; 31.03.2009 в 00:45. Причина: Добавлено сообщение
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

  5. #20
    Standart Power Аватар для US6IQ
    Регистрация
    15.09.2007
    Адрес
    Мариуполь
    Возраст
    53
    Сообщений
    452
    Поблагодарили
    64
    Поблагодарил
    14
    Если предусматривается архитектура клиент-сервер, то выбор DB не сильно важен. Я бы обратил внимание на BerkleyDB, есть везде и ставить дополнительно, как правило не надо. Над сетевым функционалом могу принять участие, интерфейс пасс - нет архитектурного видения. С перлом на ядро идея неплохая.

  6. #21
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    И все-таки я не виду целесообразность применения базы данных.
    Тут надо хорошо подумать. Лишний костыль всегда в итоге проблемами всплывет, если есть возможность обойтись без него то так и стоит сделать, ну а нет, дак придется реализовывать.
    Последний раз редактировалось RN9RQ; 31.03.2009 в 01:30.
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

  7. #22
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    RN9RQ:
    Роман, насчёт текстовых файлов - для прототипа можно их использовать, согласен. Но есть просто опыт, когда даже при трёх клиентах всё становится медленно. Кроме того, надо реализовывать диспетчер запросов к файлам, а в условиях контеста (практически real-time) - не всё так просто, как кажется. Файл открыть, закрыть, сделать нормальную нотификацию. Также вопрос с извлечением нового номера для связи - есть свои подводные камни. Но попробовать можно и на файлах, может и получится без базы.

    Есть в связи с форматом текстовых файлов предложение - посмотреть в сторону XDIF. Формат XML, если от него "отгрызть" заголовок - будет в чистом виде ADIF. Формат уже предложен американцами и продвигается. Если нам его использовать и расширить, думаю, "западники" тоже подтянутся.

    Вариант с одним оператором для начальной стадии принимаю тоже - меньше заморочек в самом начале. Потом добавить всегда можно.
    Не совсем понятно, что ты имеешь в виду под сетевым протоколом? Имелось в виду использовать стандартный паттерн publish-subscribe и делать всё на сокетах. Проще и понятнее. Listener и рublisher на основе нормальной модели и через events. Тут мудрить даже особо не надо. Имеются наработки на эту тему, правда на С++, но разницы не вижу и для других языков. Одно и то же.

    Роман, к тебе теперь вопрос: займешься самым главным? Написанием парсера по позывным с хорошим быстродействием? У меня есть свой, написанный на Perl, но оптимизацией кода так и не занимался, хотя парсит все возможные ситуации. Так вроде бы и быстро работает, но всегда есть потенциал. Или ты предпочитаешь написать его с нуля?

    US7IQZ:
    Сергей, про BerkleyDB да. Стоит везде, во всех ядрах идет по умолчанию. Есть смысл подумать.
    Интерфейсом займемся в самую последнюю очередь. Нам надо сначала создать функциональный документ. Где отразим все модули, архитектуру, сетевой уровень, а затем и интефейс выплывет сам.

    Насчет ядра на Perl тоже согласен. Мне он тоже по душе, опыт написания на нем есть и немалый (хотя люблю С++ больше).

    ПС Что будет в качестве среды разработки - тоже немаловажный вопрос. Какие мысли? Komodo IDE (лекарство правда, надо), Eclipse и т.д.?

    Зaвтра (сегодня не успел) открою репозиторий на sourceforge - Free Contest Log - дам всем доступ, дальше регистритесь уже сами в группе разработки.

  8. #23
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    Парсер как раз не самое главное.
    там по сути проверка на последовательные условия.
    Проблема в грамотно выбранных функциональной и структурной схемах, чтобы не попать в ограничение архитектуры.
    А по сети старые добрые сокеты ИМХО надежнее, но об этом можно позже поговорить.
    На счет среды разработки, я думаю не стоит их использовать вообще.
    Старые добрые vim и emacs спасут отца русской демократии, выбор по вкусу.
    Главное не завязываться ни на что лишнее.
    про утилиту make я думаю вы уже почитали.
    По поводу синглоп вы меня не поняли, я предлагаю изначально создавать клиент-серверную архитектуру, а не как сейчас у всех конетст логов. Т.е. если вы один решили в тесте поработать вы запускаете сервер и один клиент который к серверу на localhost и подключится к серверу.
    В таком варианте по сути с файлами будет работать одно приложение, которое в данном случае будет выполнять роль диспетчера для клиентов.
    Вопрос в правильном логически протоколе.
    А по формату файла а можует ну его? ермак чуть расширить да прямо в нем и хранить.
    Я этой моды XML не одобряю, все хорошо а своем месте.
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

  9. #24
    Standart Power Аватар для RN6LIQ
    Регистрация
    12.12.2006
    Адрес
    Ростов-на-Дону
    Возраст
    56
    Сообщений
    354
    Поблагодарили
    44
    Поблагодарил
    46
    Родной язык Linux Си, поэтому программы на этом языке под Линуху самые органичные. Родной язык Qt С++. Если использовать Qt для интерфейса, то и писать надо на C++. Кстати Qt не только занимается интерфейсом. И работа со строками там мощная. Да и с сокетами и с базами. Правда стоит уточнить о какой версии Qt мы говорим. Если вторая и третья версия еще похожи, то четвертая уже разительно отличается от них. любую задачу можно усложнить до предела лишними библиотеками и наворотами. Если писать под Linux, то надо выбирать родные для этой операционной системы инструментарии.
    Хотел бы проголосовать за C++ и Qt. Мне приходилось писать проект одновременно под Linux и Windows. Я использовал вышеупомянутый язык и библиотеку. Версии Qt только отличались. Но я ничего такого особенного не писал (в области картографии), поэтому мне хватало стандартных возможностей Qt2 под Windows и Qt3 под Linux. Было очень легко переносить проект с одной платформы на другую. Если где то мне не нравилась Qt реализация чего либо, и я слишком увлекался простым Cи, то и это была не проблема, поскольку этот язык переносится также легко.
    По поводу Баз данных.
    Не видел еще ни одной задачи (кроме глобальных) где нельзя было бы обойтись без базы данных. Я имею ввиду обычную стандартную базу данных концепцию которой изучают во всех соответствующих учебных заведениях. Как только начинают эту базу натягивать на проблему, сразу возникает множество других проблем. Начинается как лучше,
    - легче продумать концепцию конечного результата,
    - облегчить совместный труд программистов.
    А заканчивается жуткими тормозами построенной системы и невозможностью комфортно работать конечному пользователю. Потом выясняется, что база должна быть специфическая, под конкретную оригинальную задачу. И начинаются дополнительные разработки. Картография храниться в специальных форматах, а ведь это и есть база данных, но заточенная под особенности картографии. В системах реального времени оказывается так же не подходит обычная база данных (вот те что перечислялись выше) и начинают придумывать свою реализацию хранения больших потоков данных, причем поступающих с большими скоростями.
    Может сначала взвесить все за и против. Разложить по полочкам проблему.
    Ну и напоследок, мое жизненное наблюдение. Так ради шутки. Обычно базами у нас оперировали системные аналитики и продвинутые начальники. Особенно нравилось всем показывать на примере Microsoft Access. Так сказать разложить проблему по полочкам. Потом все дико удивлялись, почему их такая хорошая концепция, продуманная, разжеванная и красиво донесенная как задача, на практике не получилось красиво.
    Сам я с базами данных не имел дело (не считая специфических, заточенных под конкретику), но много раз наблюдал за своими несчастными коллегами.

  10. #25
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    RN9RQ:
    Роман, про синглоп теперь я понял, что ты имел в виду. В принципе, я в голове тоже держал клиент-серверную архитектуру. Без нее никак нельзя в нашем случае. Касательно формата файла для хранения данных. Я категорически против чего-то нестандартного. Делать, так делать на стандартах. Тут как раз XML хорошо вписывается в концепцию. И парсить проще и validation до кучи, на основе схемы. Кроме того, это уже де-факто стандарт для обмена и хранения данных. Ермак - лишь частный случай. Cabrillo тоже, так как производная от основного формата, да и попросту текстовый файл.

    По сокетам - да тут все ясно, другой альтернативы нет. Насчет среды - ну ты еще Notepad++ предложи... Уж если делать, так делать. Хотя кому что нравится, тут дело вкуса.

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

    Kolotusha:
    Про органичность С++ для Линукса - ну кто бы спорил... Я с самого начала стоял и стою вообщем-то на нем. Но если есть варианты писать на Perl, почему нет? Хотя, если использовать связку с Qt, то С++ предпочтительнее. Опять-таки из-за широких возможностей работы со всем, что надо.
    Если уж брать Qt, то 4.5, вместе с QtCreator. Без базы можно обойтись, существует множество реализаций под in-memory структуры. Тут весь вопрос в диспетчеризации запросов, что в принципе не такая уж и проблема. Для пост-процессинга надо подумать, какую структуру выбрать, имеется в виду формат данный, полей.

    Выбор языка для ядра - дело тоже обсуждаемое, иначе зачем мы тут собрались. Вот кстати еще один плюс в сторому С++. По идее можно сделать смесь, из С++ и Perl, но не более. Иначе, кто-то скажет, типа Python, Ruby рулят и опять обсуждение надолго затянется.

    Почему я за Qt? Да интегрируется он с чем хочешь. Хочешь сидит разработчик в Eclipse, в QtCreator, даже поддержка Visual Studio есть. Широкий выбор. В плане TCL/TK есть свои ограничения. Например, не столь богатая палитра контролей, надо все самому расширять. Вообщем мое (личное, просьба не пинать) предпочтение - писать с использованием Qt или на него ориентироваться в плане интерфейса. Когда дело дойдет до визуализации.

  11. #26
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    На самом деле визуализация это дело десятое и отдаленное.
    По языкам я свое предложение готов обьяснить.
    Почему Perl - да потому, что большая часть работы - работа над текстами, регулярные выражения, а перл лучший инструмент для этого. Вариантов тут нет.
    Ну и скорость разработки.
    Почему Си? Да чтобы в сервере не терять память. Интегрируются Си и Перл очень удачно.
    Симбиоз - демон на си, в случае чего вызывающий куски кода перла и после действия вычищающий их из памяти.
    ООП я лично не приемлю, просто немогу понять зачем он нужен в 90% случаях.
    Здесь его приложение только графическое оформление, и то под вопросом.
    По поводу формата- в случае со своим форматом мы просто выкинем лишнее функциональное преобразование.
    Хороший пример Xlog посмотрите его формат внутренний.
    По поводу среды - привязки в проинципе даже самой малой быть не должно.
    Кому что нравится тот тот и использует.
    Хотя меня в институте переучили с всяких там сред на emacs который у меня не пошел, а вот вим - песня для меня, я просто благодарен за это, себя пересилить стоит, поверьте
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

  12. #27
    Very High Power Аватар для RX1AL
    Регистрация
    12.03.2007
    Адрес
    Грац, Австрия - Санкт-Петербург, Россия
    Возраст
    60
    Сообщений
    1,749
    Поблагодарили
    374
    Поблагодарил
    160
    Роман, визуализация действительно дело десятое, хотя и не столь отдалённое. Визуализация зависит напрямую от тех данных, которые будут заложены. Поверь, я на этом уже собаку съел и не одни зубы стёр. Причем в области именно серьёзной визуализации real time данных. Но суть не в этом.

    По языкам твоё решение справедливо. Я уже тоже выше писал, что ничего не имею против связки С++ и Perl, тем более они прекрасно уживаются. С моей точки зрения рационально писать на Perl весь текстовый процессор, парсер и все операции по перелопачиванию именно текстовых данных и операций с ними. С++ оставить часть для работы с сетевыми протоколами, диспетчеризацию запросов, весь интерфейс ну и доступ к файлам и, если потребуется к базе данных. Вот так где-то. Детали самой архитектуры пока открыты ещё. Надо требования обозначить. Главные требования, а потом заниматься деталями. Не знаю, стоит ли думать о модульности в архитектуре - имеется в виду подключаемые контест модули - а) для контестов на КВ б) контестов УКВ или делать все вместе? Тут тоже стоит подумать. Не всем пользователям нужно все, можно сделать легко настраиваемой архитектурой - думается, так удобнее.

    Формат надо определить сразу, равно как и поля. Иначе потом будем все переделывать сто раз, а не хотелось бы.
    То, что ты не приемлешь ООП и ООД - не есть хорошо, но с этим можно мириться... Я лично всегда за UML обеими руками, также и за sequence diagram, иначе запутаться можно.

    Относительно XLog - именно его и изучаю сейчас... Кроме того смотрю на архитектуру CQRLog, тоже есть рациональные вещи.
    Привязки к среде программирования и нет в принципе - любая годится, которая под GNU С++, далее хоть gcc, make собирай... дело вкуса.
    Мне лично нравится Eclipse и VS - ну привык я к ним давно... а стиль и привычки не меняют, как перчатки. Тебе нравится vim - разве кто против? Лишь бы код работал, как надо...

    Ладно, все с лирикой закончили. Какие будут предложения по архитектуре? Или сначала обсудим требования для постановки задачи. Только не кидайте сразу много - надо основное определить, то, что в ядро заложим и как - это более важно, чем всякие фичи. Фичи придут позднее.

  13. #28
    Standart Power Аватар для RN6LIQ
    Регистрация
    12.12.2006
    Адрес
    Ростов-на-Дону
    Возраст
    56
    Сообщений
    354
    Поблагодарили
    44
    Поблагодарил
    46
    Цитата Сообщение от RN9RQ Посмотреть сообщение
    ООП я лично не приемлю, просто немогу понять зачем он нужен в 90% случаях.
    Здесь его приложение только графическое оформление, и то под вопросом.
    Пример из области связи. Коммутация проводов, что может быть проще. Соединил два провода и готово. Но если их соединять тысячи, начинаются проблемы. В первую очередь в понимании что же происходит. Qt полностью Объектно Ориентированный. Сначала после Win API немного даже напрягает. Но потом понимаешь всю красоту и удобство в нем. GTK является конкурентом Qt. Между ними давно идет соперничество. Но если не брать во внимание под какой лицензией они выходят, то для программиста главное отличие в том, что они оба написаны как ООП. Но Gtk на чистом СИ, который не является ОО языком, а Qt на C++ который уже ОО язык. В результате что бы писать на Gtk надо быть первоклассным программистом, и держать в памяти все проблемные вопросы. В Qt за тебя это будет делать сам компилятор. И предупредит и ругнется и не захочет компилиться. Когда проблема разрастается то приходится упорядочивать мысли и действия. Поэтому и Gtk и Qt написаны в ОО стиле. Чистые Х-иксы я не беру во внимание. Это классика. Минимальный набор средств. Motif который делал ему окна, тоже примитивен. А писать под Motif одно мучение. Пока опишешь простенькую кнопку, устанешь по клавишам бить. В Qt же несколько строк, и у тебя программа. В конечном итоге окажется что самое сложное дело это много много окошек, а не тот алгоритм что будет заложен в программу. И опираться в этом деле надо на надежного помощника. А это Qt. Но я согласен с Вами что для многих программ это лишнее. Алгоритм пустяковый, а тащит за собой мегабайтные библиотеки графических отображений.

  14. #29
    Very High Power Аватар для VE3EUT
    Регистрация
    21.11.2002
    Адрес
    East Gwillimbury, Ontario, CANADA
    Возраст
    52
    Сообщений
    2,281
    Поблагодарили
    260
    Поблагодарил
    228
    Цитата Сообщение от RU2FM Посмотреть сообщение
    Гибкости подстройки "под себя", ну и соответственно всего, что из этого вытекает...

    QRP is FUN !!!!
    А по-конкретнее ? Настройки оборудования навалом, все работает через hamlib и сделано неплохо как мне кажется.

    Или под настройкой "под себя" подразумевается разнести несколько окошек на 2 монитора ?

    Добавлено через 2 часа 20 минут
    Цитата Сообщение от RX1AL Посмотреть сообщение
    Ладно, все с лирикой закончили. Какие будут предложения по архитектуре? Или сначала обсудим требования для постановки задачи. Только не кидайте сразу много - надо основное определить, то, что в ядро заложим и как - это более важно, чем всякие фичи. Фичи придут позднее.
    Рискну вставить своих 5 копеек. Прежде чем говорить об архитектуре, несформулировано самое главное - vision statement(project character если тут есть любители терминологии PMI), а именно очень краткое описание цели предстоящей работы которая показывает необходимость софта и его назначение.
    Пока же эта цель совершенно мутная, не видно главного, а именно чем новый лог должен быть лучше tlf или других контестновых логеров, причем я лично разделил бы эти особенности на функциональные и нефункциональные что бы было проще.
    Последний раз редактировалось VE3EUT; 01.04.2009 в 07:51. Причина: Добавлено сообщение
    Life's too short for QRP!
    73, Артур VE3EUT, EW1CK

  15. #30
    Very High Power Аватар для RN9RQ
    Регистрация
    25.08.2006
    Адрес
    Шадринск, Курганская обл., Россия
    Возраст
    36
    Сообщений
    1,866
    Поблагодарили
    175
    Поблагодарил
    278
    Так, я сюда выложу несколько СВОИХ цитат из моих писем.
    Это конечно все из нескольо другой оперы, но, думаю, пара рациональных зернышек в ней есть.
    ЕРМАК ведь можно развивать по тихоньку, платформа ведь позволяет.
    Сначала я бы ввел жесткое описание колонок в шапке отчета (отпадет необходимость корректировки столбцов если что + можно просто будет выбрасывать лишние колонки), это фактически конфигуратор парсера, чего плохого, если он будет основным типом лога и для хранения данных а не только для отчета, этовполне возможно. И сетевые расширения можно реализовать стандарт, группа ведь собрана? В принипе я могу оказать в этом направлении посильную помощь.
    В этом же формате можно попробовать организовать создание универсального ядра для судейских программ, по сути это парсер на perl и анализатор БД, сделать гибкую систему вполне возможно. Потом наверное придется реализовать (если развитие формата пойдет дальше в сторону от кабрилло) конвертеры erm2cbr и cbr2erm это то уж не сложно будет.
    Главное все ведь реализуемо, и группа собрана как я понимаю удачно.
    de RA9QCE
    Можно сделать не таким жестким количество колонок число знакомест в них и расстояние между ними, Читабельность для человека не изменится, а парсер сможет по этим данным подстроиться под этот именно конфиг. За счет этого можно и повседеневные связи хранить в этом формате, и под специфические тесты подогнать и т.д. желающие думаю быстрой найдутся, скажем та же служебная информация при работае логгера в сети, еще что-то что для судейства в принципе не важно но для человека представляет интерес.
    Имел в виду что параллелно с форматом отчетов под стандарт привести протоколы в сети логгеров, чтобы в итоге можно было тот же tr4w и aatest или n1mm использовать одновременно в одной сети, если для храненния они будут использовать один формат отчета и использовать один и тот же сетевой протокол это не проблема.
    Все упроститься если сделать готовые заготовки общими усилиями, надо парсер - юзай стандартный. надо сеть прикрутить - вот она уже готова реализация. Кто-то сейчас xml-евский паресер сам пишет?
    А путь этот в итоге может привести к online судейству, тоесть ты уже по ходу работы видишь кто тебя обгоняет и на сколько, и результаты (во всяком случае предварительные) будут известны фактически сразу после теста
    И по тестам попробуй ввести частоту 1296 МГц
    ......
    Ок понял, на счет блокировки. А по частоте ну вот Соревнования полевой день на УКВ , частота на диапазоне 23 см 1296,505 МГц, как ты эту частоту впишешь в отчет кабрилло или ЕРМАК ?
    Добавлено через 9 минут
    Думаю, правда более логичным свой формат переименовать, поскольку, судя по переписке, группа по разработке ЕРМАК планирует двигаться в несколько другом направлении...
    Последний раз редактировалось RN9RQ; 01.04.2009 в 10:22. Причина: Добавлено сообщение
    Для человека с молотком любая проблема кажется гвоздем.
    Слава богу, теперь уже БЫВШИЙ член СРР, 73!

Похожие темы

  1. Разработка open-source SDR
    от RELAYER в разделе SDR техника
    Ответов: 66
    Последнее сообщение: 19.03.2011, 09:12
  2. LZ open contest
    от 4L6QC в разделе Соревнования
    Ответов: 5
    Последнее сообщение: 17.01.2009, 23:57
  3. ОС Open Solaris
    от Кирилл в разделе Программное обеспечение
    Ответов: 8
    Последнее сообщение: 14.10.2008, 15:18
  4. Антенны Open Sleeve
    от UN7GCE в разделе Антенны КВ
    Ответов: 4
    Последнее сообщение: 19.10.2006, 08:02
  5. LZ Open
    от adani в разделе Соревнования
    Ответов: 4
    Последнее сообщение: 16.01.2006, 19:10

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Похоже, что вы используете блокировщик рекламы :(
Форум QRZ.RU существует только за счет рекламы, поэтому мы были бы Вам благодарны если Вы внесете сайт в список исключений!
как отключить
×
Рейтинг@Mail.ru
eXTReMe Tracker


Похоже, что вы используете блокировщик рекламы :(
Форум QRZ.RU существует только за счет рекламы, поэтому мы были бы Вам благодарны если Вы внесете сайт в список исключений!
как отключить
×