Отладка программы

← →
Германн © (2010-01-20 01:44) [0]

Ищу простой способ отладки программы на двух рабочих местах. Одно место в офисе, другое дома. Места отличаются одно от другого наличием или отсутствием железа, с которым должна работать программа.
Можете посоветовать простой способ переноса проекта с одного компьютера на другой? Естественно, что на домашнем компьютере требуется отладка только тех функций, которые не обращаются к железу. Но на домашнем компьютере требуется запретить вызов функций работающих с железом.

P.S. Проверка наличия железа исключена. Понимаю что это высказывание слишком неприглядно смотрится, но желающим понять, готов объяснить почему исключена. Только это довольно долгое повествование.

P.P.S. Пробовал многое, но всё сохраняется в файле проекта. Следовательно простой перенос исключается или я чего-то не знаю.

← →
@!!ex © (2010-01-20 01:53) [1]

Эмуляция драйвера самый просто вариант. Благо dll(в общем случае) под такое дело пишется за 15 минут.

← →
Германн © (2010-01-20 02:24) [2]

> @!!ex © (20.01.10 01:53) [1]
>
> Эмуляция драйвера самый просто вариант.

Все "эмуляции" железа исключены полностью. Объяснить почему - могу. Если потребуешь.
Да и не в том суть.
Тут нет "драйвера" как единственной сущности. Тут целая система.

← →
Кто б сомневался © (2010-01-20 02:27) [3]

На новую работу устроился что-ли? :)
По вопросу ежедневно в течении 4 дней.

← →
Германн © (2010-01-20 02:44) [4]

> Кто б сомневался © (20.01.10 02:27) [3]
>
> На новую работу устроился что-ли? :)
> По вопросу ежедневно в течении 4 дней.

Устроился. В конце августа прошлого года. Об чём и доложился своевременно сообчеству ДМ.

Серьёзно?
Вот так сложилось, что сейчас наступила пора "сложных" проблем.
Сложных - не тождественно - важных. Подчищаю ныне проект, чтобы "сдать его с концами" если вдруг!

Скорее всего "вдруг" не наступит. Но...

← →
Bob (2010-01-20 08:20) [5]

> Германн ©
> ... требуется запретить вызов функций работающих с железом.

А {IFDEF ...} не годится для этих целей?

> Все "эмуляции" железа исключены полностью.

Может все-таки намекнете почему ?

← →
Сергей М. © (2010-01-20 08:38) [6]

> Германн

Дома приличный доступ в Тырнет есть ?
Удаленный доступ к рабочему АРМ возможен ?
Тогда все до безобразия просто : в руки берется Borland Remote Debugger - и вперед с песней !)

← →
turbouser © (2010-01-20 09:06) [7]

Если
> Удаленный доступ к рабочему АРМ возможен

то, возможно, вполне хватит и RDP

← →
Сергей М. © (2010-01-20 09:57) [8]

> вполне хватит и RDP

А не жирно будет гонять туда-сюда графику ради такого удовольствия ?
Хамачи на оба конца - и всех делов)

← →
Skyle © (2010-01-20 10:03) [9]

> Сергей М. © (20.01.10 09:57) [8]

Работал я по терминалу. 20 Мб в рабочий день не такая уж и графика.

← →
Дмитрий С © (2010-01-20 10:12) [10]

Дома работать - зло.

← →
@!!ex © (2010-01-20 10:13) [11]

> [2] Германн © (20.01.10 02:24)

Было бы интересно почему.

← →
Сергей М. © (2010-01-20 10:18) [12]

> Skyle © (20.01.10 10:03) [9]

Гонять графику без явной на то нужды по меньшей мере неразумно.

← →
Сергей М. © (2010-01-20 10:28) [13]

По кр.мере я чувствовал себя вполне комфортно, организовав удал.отладку на связке Хамачи + BRD, в условиях при ширине канала на обоих концах до 1 мбод.
Хамачи при этом хорошо помог: админ сети на удал.стороне встал в неприличную позу, наотрез отказавшись пробрасывать порт доступа к удаленному BRD-сервису

← →
KSergey © (2010-01-20 11:32) [14]

Из всего исходного поста я так и не понял в чем именно проблема.
И что значит "Но на домашнем компьютере требуется запретить вызов функций работающих с железом"? Не понятно.
Вот есть функция в программе

function RabotaemSGelezom(AParam: Integer): Boolean;
begin
...
end;

Что означает "запретить вызов"? Она не должна вызваться из других мест программы? Или при вызове должно взорваться (exception)?

По описанию впечатление, что {IFDEF ...} самое оно, только надо само условие положить в стороне от файлов проекта, чтоыб копировать было удобнее: не приходилось каждый раз перенастраивать дом/работа после копирования.

А секрета раскрывать не надо, пожалуйста. Так интереснее.

← →
Skyle © (2010-01-20 12:16) [15]

> Сергей М. © (20.01.10 10:18) [12]
> > Skyle © (20.01.10 10:03) [9]
> Гонять графику без явной на то нужды по меньшей мере неразумно.

Зато если внезапно терминал отвалился - ты ничего не теряешь. Зашёл повторно, всё на месте, все на бряках стоят.

← →
Anatoly Podgoretsky © (2010-01-20 12:27) [16]

> Германн (20.01.2010 01:44:00) [0]

if Можно then зовем функцию, иначе пошли на фиг

← →
Германн © (2010-01-20 13:13) [17]

> Сергей М. © (20.01.10 08:38) [6]

Это просто не нужно нифига. Несколько месяцев назад Eraser уже предлагал свой софт и поддержку. Но жизнь показала, что отладка именно железа и работы с ним успешно осуществляется в редкие дни приезда в офис.

← →
Германн © (2010-01-20 13:23) [18]

> @!!ex © (20.01.10 10:13) [11]
>
> > [2] Германн © (20.01.10 02:24)
>
> Было бы интересно почему.
>

Потому что я работаю с железом не напрямую. А через довольно сложное ПО от производителя.

← →
Германн © (2010-01-20 13:24) [19]

> KSergey © (20.01.10 11:32) [14]
>
> Из всего исходного поста я так и не понял в чем именно проблема.
>
> И что значит "Но на домашнем компьютере требуется запретить
> вызов функций работающих с железом"? Не понятно.
> Вот есть функция в программе
>
> function RabotaemSGelezom(AParam: Integer): Boolean;
> begin
> ...
> end;
>
> Что означает "запретить вызов"? Она не должна вызваться
> из других мест программы? Или при вызове должно взорваться
> (exception)?
>
> По описанию впечатление, что {IFDEF ...} самое оно, только
> надо само условие положить в стороне от файлов проекта,
> чтоыб копировать было удобнее: не приходилось каждый раз
> перенастраивать дом/работа после копирования.

Вот это самое то. Вот только не знаю как условие положить в стороне?

← →
@!!ex © (2010-01-20 13:25) [20]

> [18] Германн © (20.01.10 13:23)

Доступ к этому "сложному ПО" осуществляется как?
через dll. делаем врапер, в котором все железчяный вызовы заменяем на:
begin
//здесь тупо возвращение дефолтного результата
end;

dll помещаем в system32 на домашнем компе.
вызовов к железку на домашнем компе будет возвращать дефолтное значение. Будто железка есть.

← →
clickmaker © (2010-01-20 13:25) [21]

> Но на домашнем компьютере требуется запретить вызов функций
> работающих с железом

if (ComputerName <> "MyHomeComp") then

← →
@!!ex © (2010-01-20 13:26) [22]

> Вот это самое то. Вот только не знаю как условие положить
> в стороне?

UseHardware:boolean; begin UseHardware:=FileExists("C:\UseHardware"); end; function RabotaemSGelezom(AParam: Integer): Boolean; begin if not useHardware then Exit; end;

← →
Германн © (2010-01-20 13:30) [23]

> clickmaker © (20.01.10 13:25) [21]

Как вариант да.

← →
Германн © (2010-01-20 13:31) [24]

> @!!ex © (20.01.10 13:26) [22]
>
> > Вот это самое то. Вот только не знаю как условие положить
> > в стороне?
>
> UseHardware:boolean;
>
> begin
> UseHardware:=FileExists("C:\UseHardware");
> end;

Тоже вариант.

← →
Германн © (2010-01-20 13:35) [25]

> Вот только не знаю как условие положить в стороне?
>

Блин. Ясен пень как. {$I C:\defines.inc}
Туплю уже. :(

← →
clickmaker © (2010-01-20 13:35) [26]

> [23] Германн © (20.01.10 13:30)
>
> > clickmaker © (20.01.10 13:25) [21]
>
> Как вариант да.

но лучше все-таки условная компиляция.
лишние проверки строк и файлов - они как-то ни к чему в релизе

← →
KSergey © (2010-01-20 14:08) [27]

> Германн © (20.01.10 13:35) [25]
>
> > Вот только не знаю как условие положить в стороне?
> >
>
> Блин. Ясен пень как. {$I C:\defines.inc}

Ура!!! :)
именно это и имел ввиду
Правда c:\ - не красиво, а вот ..\..\includes\defines.inc - самое то.

← →
Германн © (2010-01-20 14:11) [28]

> KSergey © (20.01.10 14:08) [27]
>
>
> > Германн © (20.01.10 13:35) [25]
> >
> > > Вот только не знаю как условие положить в стороне?
> > >
> >
> > Блин. Ясен пень как. {$I C:\defines.inc}
>
> Ура!!! :)
> именно это и имел ввиду
> Правда c:\ - не красиво, а вот ..\..\includes\defines.inc
> - самое то.

..\..\includes\defines.inc не удобно. В этом случае файл попадет в архив с исходниками, который таскается с компа на комп.

← →
@!!ex © (2010-01-20 14:23) [29]

> [28] Германн © (20.01.10 14:11)
..\..\includes\defines.inc не удобно. В этом случае файл попадет в архив с исходниками, который таскается с компа на комп.

Значит "..\" должно быть столько, чтобы не попал.

← →
Германн © (2010-01-21 02:02) [30]

> @!!ex © (20.01.10 14:23) [29]
>
> > [28] Германн © (20.01.10 14:11)
> ..\..\includes\defines.inc не удобно. В этом случае файл
> попадет в архив с исходниками, который таскается с компа
> на комп.
>
> Значит "..\" должно быть столько, чтобы не попал.

А хрен его знает, где мне придётся положить сей проект в будущем!

← →
Игорь Шевченко © (2010-01-21 02:21) [31]

Правильные разработчики используют ключи командной строки или переменные окружения. Второе удобнее для дома - выставил один раз и при каждой перезагрузке значение всегда с тобой. Первое удобно, когда потребуется сменить режим в процессе очередного отладочного запуска.

> Игорь Шевченко © (21.01.10 02:21) [31]
>
> Правильные разработчики используют ключи командной строки
> или переменные окружения.

Ключи командной строки сразу отметаем. Они переносятся вместе с проектом.

Переменные окружения. Уже интересно. Что имеется в виду?

тебе код можно менять ?
или ты таскаешь собранный чужим дядей бинарник, который тебе надо "отлаживать" либо с железом на работе, либо без железа дома ?

http://ln.com.ua/~openxs/articles/smart-questions-ru.html

Кстати, тут начал пользовать www.dropbox.com - даже таскать ничего не нужно, до 2 Гб дискового пространства бесплатно.

> Германн (21.01.2010 02:30:32) [32]

Параметры запуска проекта. Задаешь дома свой параметр, в коде анализируешь.

> Германн © (21.01.10 02:02) [30]
> > Значит "..\" должно быть столько, чтобы не попал.
> А хрен его знает, где мне придётся положить сей проект в будущем!

В каком будущем?! что за бред??

> Естественно, что на домашнем компьютере требуется отладка
> только тех функций, которые не обращаются к железу. Но на
> домашнем компьютере требуется запретить вызов функций работающих
> с железом.

Ну так и отлаживай.
Зачем запрещать то, что можно не трогать?
Или у тебя отладка функции а затрагивает функцию b?

> Anatoly Podgoretsky © (21.01.10 09:51) [35]
>
> > Германн (21.01.2010 02:30:32) [32]
>
> Параметры запуска проекта. Задаешь дома свой параметр, в
> коде анализируешь.
>

А потом вместе с файлом project.dproj приносишь этот параметр на работу.

> Германн (21.01.2010 21:32:38) [38]

А ты не носи этот файл, а в случае ошибки восстановление параметра это же пара секунд.

> Anatoly Podgoretsky © (21.01.10 21:45) [39]
>
> > Германн (21.01.2010 21:32:38) [38]
>
> А ты не носи этот файл

Ну да. Сначала не носи этот файл, потом носи тот файл и т.д. и т.п.
Вариант [25] меня абсолютно устраивает.
{$IFDEF DEBUG}
{$I C:\defines.inc}
{$ENDIF}

> KSergey © (21.01.10 10:32) [36]
>
> > Германн © (21.01.10 02:02) [30]
> > > Значит "..\" должно быть столько, чтобы не попал.
> > А хрен его знает, где мне придётся положить сей проект
> в будущем!
>
> В каком будущем?! что за бред??
>

Бред - это моя нынешняя работа. Бред - это данная задача. Хотя лет эдак через N данная задача может перестать быть бредом. ХЗ.
Но!
"Мы рождены, чтоб сказку сделать былью!
Преодолеть..." :)

> Игорь Шевченко © (21.01.10 02:21) [31]
>
> Правильные разработчики используют ключи командной строки
> или переменные окружения. Второе удобнее для дома - выставил
> один раз и при каждой перезагрузке значение всегда с тобой.
> Первое удобно, когда потребуется сменить режим в процессе
> очередного отладочного запуска.
>

Всё таки очень интересно, что ты, Игорь, подразумевал под "вторым"?

> Скрытая реклама?

Нет, просто удобно. Я работаю сейчас на нескольких объектах, спецификации и планы веду с любого из них или из дома. И не парюсь насчет актуальности данных. Если у тебя есть Интернет и на работе и дома, то для синхронизации этот сервис - самое оно.

Хотя есть в этом решении и недостатки, но пока мне очень нравится.

> Германн (22.01.2010 01:11:40) [40]

Вот DEBUG и надо использовать в качестве параметров.

Отладка программы Найти похожие ветки