|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/219.27 21 Jun 2001 09:56:46
To : Vlad Foltz
Subject : Re: Программить графику под линукс - как?
--------------------------------------------------------------------------------
From: vitus@wagner.rinet.ru (Victor Wagner)
Vlad Foltz <Vlad_Foltz@p8.f1015.n5030.z2.fidonet.org> wrote:
VF> Пpивет, Vladimir !
VF> Вс Июн 17 2001 23:33 по московскомy вpемени Vladimir
VF> Mosgalin написал к Vlad Foltz:
VF>>> Тут "начальству" в голову ударило... типа, а давайте
VF>>> писать под линукс
VM>> :) Хорошее начальство, прогрессивное.
VF> Да вот, наслушалось где-то :)
VF> [-=чик-чик=-]
VF>>> :-\ Задача сугубо графическая (графики рисовать в
VF>>> большом колчестве)
VM>> gnuplot?
VF> Да вобщем специализированные библиотеки для построения
VF> графиков меня не интересуют - все равно задача слишком
VF> специфическая и рисовать все надо будет ручками.
gnuplot - не библиотека, а приложение. И прежде чем заявлять
о специфичности задачи, я бы все-таки на него посмотрел.
Ибо он может ну очень много.
Рисовать ручками, это извините, все равно посредством какой-либо
библиотеки. Либо среднеуровневой типа plotlib либо низкоуровневой,
попиксельно. Сначала надо еще понять, куда ты будешь рисовать.
Вот здесь gnuplot крайне полезная штука на поиграться, так как
поддерживает почти все устройства и файловые форматы, которые бывают.
VM>> Hу, интерфейсов тут много всяких
VF> В том то и проблема ;) Хотелось бы знать "что сейчас модно"
VF> и куда смотреть.
В смысле - узнать, что "модно" и смотреть куда угодно, только
не туда? Тогда gtk и Qt.
Или узнать что позволяет наиболее легко решить твою задачу?
tcl/tk+blt при условии, что данные из usb уже как-то вытащены.
Соответственно задача разбивается на две части - работа с USB
драйвером посредством простейшей програмки которая читает команды
устройству со stdin и пишет циферки на stdout
и интерфейсная прибамбасина на tcl.
VM>> Как usb - не знаю... В смысле он поддерживается, и работа
VM>> с ним по идее не должна отличаться от всего другого.
VF> Hе знаю. В виндах, например, нет общего механизма (я не
VF> нашел) для работы с USB (например, как с COM-портом).
В виндах, это в виндах. Купи книжку Стивенса. И Кернигана и Пайка тоже
не помешает. В юниксах любое устройство есть файл и работают с ним
посредством read/write/ioctl.
VF> Я сейчас вижу _основной_ трабл в том, что я не знаю ни
VF> одного нормального средства разработки софта под эхотаг. В
VF> смысле я когда-то видел gdb - вспоминаю и содрагаюсь, как
С каких это пор дебаггеры стали средствами разработки?
Системы регрессионного тестирования типа DejaGNU - это я еще понимаю.
А дебаггер суть средство исследования кода. При этом исследование
своего собственного кода суть признак непрофессионализма.
Вообще gdb, как и многие другие средства в Unix делает одну
задачу - копаться в потрохах программы, и делает это хорошо.
Общаться с юзером - не его задача, он и не пытается это делать - он
принимает со stdin команды и выдает на stdout информацию.
Для того чтобы с этим работать предназначены разнообразные фронтэнды
типа ddd. (который, кстати умеет работать и с другими отладчиками.
Ведь отлаживать можно не только бинарник на уровне команд ассемблера/C)
VF> такое кто-то юзает... Есть еще Kylix - но это немного из
VF> другой оперы. Только не надо меня парить про то, что
VF> настоящие программеры не используют отладчики, нет круче
VF> редактора чем vi и т.п. Или лучше сразу мылом ;)
Круче редактора чем vim действительно нет. Потому что emacs не редактор,
а эмулятор Lisp-системы под Unix.
Да, непривычен. Hо ни в одном другом редакторе кроме Emacs, ты не
найдешь такого количества различных способов перемещения по тексту,
способов его изменения, легкости прицепления внешних прибамбасов,
типа искалок по документации, гибкости completion, и т.д.
Hе говоря уж о количестве языков программирования, про которые он знает.
VF> Может знаешь, когда макросы в офисе набиваешь, там по ходу
VF> такие подсказочки всплывают по методам объектов, аргументам
VF> функций и т.п. Очень удобно. Так вот, все это просто
VF> детство по сравнению с VisualAssist'ом - ну очень удобная
Hу ну. А Visual Assist - просто детство по сравнению с ^X
в виме. Ибо не настраивается под себя.
VF> вещь для набивания исходников. Словами не описать, это надо
VF> видеть :) BoundsChecker - приблуда, которая засекает утечки
VF> памяти, неправильные аргументы при вызове системных функций
VF> и т.п. - бывает полезно.
Сделай поиск в google на слова malloc debugging - найдешь десяток
подобных фиговин. Я в свое время, когда был маленький и глупый, и не
умел писать программы, пользовался Electric Fence. Просто потому
что первая на эту тему под руку попалась. В моем дистрибутиве.
Потом стал большой и умный и перестал писать программы, которые
нуждаются в подобных костылях для обучения ходить.
VF>>> кайфа. Все. Соответсвенно, если я хочу программить под
VF>>> эхотаг, то ...?
VM>> Заходишь в электронный магазин, заказываешь любимый
VM>> дистрибутив
VF> Любимый это какой?
Любой. Главное чтобы полный
VF>>> 3) Интересуют ссылки на доки и т.п. касающиеся данной
VF>>> задачи (только что-нибудь поконкретнее, чем linux.org).
VF>>> А-ля программирование
VM>> :) man *, info *, less /usr/doc/*. В дистрибутиве все
VM>> будет, если будет желание читать и понимать - все
VM>> найдешь.
VF> Там будет много чего не по делу. В идеале хотелось бы
VF> пообщаться с людьми, которые решали такие задачи...
А для этого тебе потребуется сделать так, чтобы этим людям было
о чем с тобой общаться. Hет, все-таки не пожалей $80 на
Advanced programming in Unix Environment by Steevens.
--
Предпоследний из могикан часто убивает последнего, чтобы стать им.
--- С.Е. Лец
--- ifmail v.2.14.os-p7
* Origin: Where is your mouse [/dev/Wagner's home (2:5020/219.27@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
