|
vmusulainen |
|
|
Кто-нибудь работал из pharo с последовательным портом?
У меня ситуация такая, что я шлю на внешний микроконтроллер команду и слушаю ответ. Потоки записи (отправки команды) и чтения (ожидания ответа) - два разных потока. Задержки, примерно, по 300 мс в каждом после каждого цикла записи/ чтения. Так вот, чтение из порта временами возвращает пустую строку, теряет данные, хотя сниффер COM-порта показывает, что данные с микроконтроллера поступают. Например, это лог чтения порта в pharo 02:51:05 distance: 76 02:51:05 distance: 76 02:51:05 distance: 75 02:51:06 distance: 75 02:51:06 distance: 75 02:51:06 distance: 76 02:51:18 distance: 77 Последний ответ принят позже предпоследнего на 12 сек. Хотя предыдущие ответы читаются по три в секунду. После приема ответа в 18 секунд больше ничего из порта не прочитали. А это лог сниффера, по нему видно, что данные на порт приходили. 34985 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 34991 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 34997 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35003 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35009 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35015 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35021 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35027 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35033 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35039 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35045 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35051 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35057 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35063 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35069 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35081 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35087 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35093 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35099 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35105 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35111 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35117 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35123 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35129 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35135 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35141 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35147 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35153 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35159 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35165 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35171 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35177 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35183 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35189 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35195 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35201 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35207 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35213 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a distance: 75.. 35219 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a distance: 76.. 35225 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. 35231 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. 35237 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. 35243 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. 35249 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. 35255 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a distance: 77.. По баг-треккерам Cog VM особо про последовательный порт не говориться. Понятно, что направление неприоритетное... -- http://groups.google.ru/group/sugr |
|
|
А как вы ответ получаете? Ставите опрос на цикл?
--
http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
работает вот так
initialize readProcess := [ [ self readFromSerialPort ] repeat ] fork. readFromSerialPort | read | (Delay forMilliseconds: 100) wait. read := serial readString. read do: [ :each | each ~= Character cr ifTrue: [ readBuffer nextPut: each ] ifFalse: [ | answer | self addRoboAnswer: readBuffer contents. readBuffer reset ] ] Приведенная мною реализация вроде работает стабильнее, чем та, для которой я приводил логи, но тоже временами случается съедание ответов... Причем по ощущениям, чем чаще я читаю с порта данные, тем больше шансов, что они пропадут. On Oct 24, 5:08 pm, kirand <[hidden email]> wrote: > А как вы ответ получаете? Ставите опрос на цикл? -- http://groups.google.ru/group/sugr |
|
|
http://forum.world.st/serial-port-access-td108547.html
в последнем абзаце кое-что написано как правильно организовать считывание через #readInto:startingAt:. может поможет...
-- http://groups.google.ru/group/sugr |
|
Борис Беркгаут |
|
|
In reply to this post by vmusulainen
Я очень извиняюсь за глупый вопрос, а зачем нужна задержка?
On Oct 24, 5:20 pm, Владимир Мусулайнен <[hidden email]> wrote: > работает вот так > > initialize > readProcess := [ [ self readFromSerialPort ] repeat ] fork. > > readFromSerialPort > | read | > (Delay forMilliseconds: 100) wait. > read := serial readString. > read > do: [ :each | > each ~= Character cr > ifTrue: [ readBuffer nextPut: each ] > ifFalse: [ > | answer | > self addRoboAnswer: readBuffer contents. > readBuffer reset ] ] > > Приведенная мною реализация вроде работает стабильнее, чем та, для > которой я приводил логи, но тоже временами случается съедание > ответов... > Причем по ощущениям, чем чаще я читаю с порта данные, тем больше > шансов, что они пропадут. > > On Oct 24, 5:08 pm, kirand <[hidden email]> wrote: > > > > > > > > > А как вы ответ получаете? Ставите опрос на цикл? -- http://groups.google.ru/group/sugr |
|
|
очевидно, для того, чтобы программа не занимала все процессорное время?
--
http://groups.google.ru/group/sugr |
|
Борис Беркгаут |
|
|
Правильно ли я понял, что readString неблокирующий, т.е. он вычитывает
сколько есть в буфере (в частности, пустую строку) и сразу возвращается? On Oct 25, 5:16 pm, kirand <[hidden email]> wrote: > очевидно, для того, чтобы программа не занимала все процессорное время? -- http://groups.google.ru/group/sugr |
|
|
ну да. читает все, что доступно из порта и выдает в виде aString
--
http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
In reply to this post by Борис Беркгаут
On 25 окт, 17:02, Борис Беркгаут <[hidden email]> wrote: > Я очень извиняюсь за глупый вопрос, а зачем нужна задержка? > Ну да, если я постоянно буду долбать порт запросами на чтение, то: 1. А кто будет заниматься другими полезными вещами, типа следить за вводом с клавиатуры, мыши, обновлением экрана и т.п.... 2. Так часто долбать порт не имеет смысла, так как редко когда внешний девайс лупит данные на порт с такой скоростью. Обычно данные на порт идет не чаще раз в несколько десятков миллисекунд. -- http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
In reply to this post by Борис Беркгаут
Кстати, да, он неблокирующий. В виндах winAPI предлагает блокирующую
функцию с задаваемой величиной timeout (причем видов таймаута там несколько - общий таймаут, таймаут после поступления очередного байта - насколько я помню). В Pharo работа с SerialPort попроще. On 25 окт, 18:00, Борис Беркгаут <[hidden email]> wrote: > Правильно ли я понял, что readString неблокирующий, т.е. он вычитывает > сколько есть в буфере (в частности, пустую строку) и сразу > возвращается? > > On Oct 25, 5:16 pm, kirand <[hidden email]> wrote: > > > > > > > > > очевидно, для того, чтобы программа не занимала все процессорное время? -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by vmusulainen
У вас что-то получилось/решилось с проблемой?
--
http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
Код который я привел в 3 посте этого треда работает относительно
стабильно. Общие задержки перед очередным вычитыванием составляют 500 мс. Если задержки уменьшать начинаются проблемы. Код, на который который вы дали, делает примерно тоже самое. В коде у них кстати ошибка, есть ;). Точнее, недочет сильный. но это ладно... Резюмируя: проблема пока отступила, но что-то там не так чисто. Я еще буду её исследовать подробнее. On 25 окт, 20:29, kirand <[hidden email]> wrote: > У вас что-то получилось/решилось с проблемой? -- http://groups.google.ru/group/sugr |
|
Борис Беркгаут |
|
|
Мне кажется, стоит задаться вопросом, насколько хорошо работает
буферизация при вычитывании из последовательного порта. Потому что если ОС ничего не буферизует и VM ничего не буферизует, то вот и объяснение: данные просто дропаются, ибо аппаратный буфер у последовательного порта крохотный (16 байт). Объяснить, почему чем чаще опрашивается порт, тем больше данных теряется, я не могу. On Oct 25, 10:03 pm, Владимир Мусулайнен <[hidden email]> wrote: > Код который я привел в 3 посте этого треда работает относительно > стабильно. Общие задержки перед очередным вычитыванием составляют 500 > мс. > Если задержки уменьшать начинаются проблемы. > Код, на который который вы дали, делает примерно тоже самое. В коде у > них кстати ошибка, есть ;). Точнее, недочет сильный. но это ладно... > > Резюмируя: проблема пока отступила, но что-то там не так чисто. Я еще > буду её исследовать подробнее. > > On 25 окт, 20:29, kirand <[hidden email]> wrote: > > > > > > > > > У вас что-то получилось/решилось с проблемой? -- http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
In reply to this post by vmusulainen
Я еще раз наткнулся с проблему работы Pharo с последовательным портом.
На этот раз уже с другим устройством (ультразвуковой радар URM37). Вот описание проблемы: Есть устройство, подключается к виртуальному последовательному порту. Устройство в ответ на запрос отвечает после некоторой паузы (десятки миллисекунд) некие данные размером 4 байта. Данные имеют следующий вид 1 байт - тип данных. 2 и 3 байты - полезные данные 4 байт - сумма предыдущих трех байт. Я реализовывал два алгоритма работы с устройством в pharo. Вариант А. 1. Отправляем запрос на устройство. 2. Ждем 200 миллисекунд. 3. Читаем ответ с порта методом readString. 4. Отправляем следущий запрос Результат: ответ всегда в pharo получаем верным. То есть размер ответа равен четырем байтам и он есть всегда. Вариант Б. 1. Отправляем запрос на устройство. 2. В цикле (но не более 500 мс) читаем с порта данные методом readString, пока размер считанных данных не станет больше или равным 4 байтам. То есть если в течении 500 мс мы так и не прочитали с порта данных на 4 или более байт, то отправляем следующий запрос. Задержки между запросами данных с порта нет. 3. Отправляем следущий запрос. Результат: данные читаются неустойчиво. Иногда мы можем с порта прочитать 5 байт. Иногда 0 байт. Наиболее показателен получение 5 байт. Устройство отвечает по 4 байта. Предыдущий ответ мы вычитали полностью (все 4 байта). Делаем следующий запрос и тут к нам прилетело 5 байт. Откуда?! Итог: нельзя постоянно дергать в Pharo последовательный порт запросами на чтение. Портировал алгоритм Б на VisualWorks 7.7 Использовал пакет NTOSSupportApp. Там есть класс который оборачивает вызовы WinApi. Читает все отлично. Все приходит верно, по 4 байта. Вывод: SerialPortPlugin в pharo имеет огрехи в работе. Я пока не готов писать свой плагин дла Cog VM. Вероятно, реализую обертку вызовов WinAPI через FFI. Вот как-то так. On 24 окт, 03:12, Владимир Мусулайнен <[hidden email]> wrote: > Кто-нибудь работал из pharo с последовательным портом? > > У меня ситуация такая, что я шлю на внешний микроконтроллер команду и > слушаю ответ. > Потоки записи (отправки команды) и чтения (ожидания ответа) - два > разных потока. > Задержки, примерно, по 300 мс в каждом после каждого цикла записи/ > чтения. > > Так вот, чтение из порта временами возвращает пустую строку, теряет > данные, хотя сниффер COM-порта показывает, что данные с > микроконтроллера поступают. > Например, это лог чтения порта в pharo > > 02:51:05 > distance: 76 > 02:51:05 > distance: 76 > 02:51:05 > distance: 75 > 02:51:06 > distance: 75 > 02:51:06 > distance: 75 > 02:51:06 > distance: 76 > 02:51:18 > distance: 77 > > Последний ответ принят позже предпоследнего на 12 сек. Хотя > предыдущие ответы читаются по три в секунду. После приема ответа в 18 > секунд больше ничего из порта не прочитали. > А это лог сниффера, по нему видно, что данные на порт приходили. > > 34985 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 34991 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 34997 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35003 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35009 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35015 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35021 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35027 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35033 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35039 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35045 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35051 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35057 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35063 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35069 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35081 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35087 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35093 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35099 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35105 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35111 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35117 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35123 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35129 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35135 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35141 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35147 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35153 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35159 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35165 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35171 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35177 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35183 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35189 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35195 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35201 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35207 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35213 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a > distance: 75.. > 35219 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a > distance: 76.. > 35225 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > 35231 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > 35237 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > 35243 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > 35249 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > 35255 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a > distance: 77.. > > По баг-треккерам Cog VM особо про последовательный порт не говориться. > Понятно, что направление неприоритетное... -- http://groups.google.ru/group/sugr |
|
Dennis Schetinin |
|
|
Очень полезные и основательные наблюдения. Очевидно, нужно проинформировать фаро-сообщество.
10 ноября 2011 г. 0:24 пользователь Владимир Мусулайнен <[hidden email]> написал: Я еще раз наткнулся с проблему работы Pharo с последовательным портом. Dennis Schetinin -- http://groups.google.ru/group/sugr |
|
vmusulainen |
|
|
Было бы неплохо еще хотя бы примерно обозначить проблему в плагине. Я
думаю, в этом случае, быстрее и исправят. On 10 ноя, 06:00, Dennis Schetinin <[hidden email]> wrote: > Очень полезные и основательные наблюдения. Очевидно, нужно проинформировать > фаро-сообщество. > -- http://groups.google.ru/group/sugr |
|
Denis Kudriashov |
|
|
Да, очень интересно.
Хорошо, что я в свое время не стал заморачиваться с ком портом в фаре, отдали задачи сишнику, а я уже использовал его длл-и 10 ноября 2011 г. 6:21 пользователь Владимир Мусулайнен <[hidden email]> написал: Было бы неплохо еще хотя бы примерно обозначить проблему в плагине. Я -- http://groups.google.ru/group/sugr |
| Powered by Nabble | See how NAML generates this page |