libcurl
Vitaliy Liaschuk
хм. в проге юзается libcurl но не могу заставить компилировать с этой либой.
делаю так:
g++ -L/usr/local/lib/ -I/usr/local/include proga.cpp
rebe# ls /usr/local/lib/libcurl*
/usr/local/lib/libcurl.a /usr/local/lib/libcurl.la
/usr/local/lib/libcurl.so /usr/local/lib/libcurl.so.5
rebe#
rebe# pkg_info | grep curl
curl-7.19.2 Non-interactive tool to get files from FTP, GOPHER, HTTP(S)
rebe#
rebe# uname -a
FreeBSD rebe 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 17:46:47 EET
2009 larin@rebe:/usr/obj/usr/src/sysGoldEDNERIC i386
rebe#
ткните носом, что я делаю не так?
С наилучшими пожеланиями.
Fri Feb 06 2009 17:57
Nickita A Startcev
06 Feb 09 , 17:57 Vitaliy Liaschuk писал к All:
VL> хм. в проге юзается libcurl но не могу заставить компилировать с этой
VL> либой.
VL> делаю так:
VL> g++
это вызов компилятора
VL> -L/usr/local/lib/
это указание пути к либам
VL> -I/usr/local/include
это - к заголовкам
VL> proga.cpp
это имя того, что надо скомпилировать и слинковать в один заход.
VL> ткните носом, что я делаю не так?
забыл указать, какую именно либу подключать, кроме стандартных.
-lcurl
. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Лучшее средство от комплейна - капля никотина?
Vitaliy Liaschuk
VL>> либой.
VL>> делаю так:
VL>> g++
NAS> это вызов компилятора
VL>> -L/usr/local/lib/
NAS> это указание пути к либам
VL>> -I/usr/local/include
NAS> это - к заголовкам
VL>> proga.cpp
NAS> это имя того, что надо скомпилировать и слинковать в один заход.
VL>> ткните носом, что я делаю не так?
NAS> забыл указать, какую именно либу подключать, кроме стандартных.
NAS> -lcurl
да-да. вот щас поставил эклипс+cdt. создал пустой проект.
//proga.cpp --------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <curl/curl.h>
int main(void) {
CURL *curl;
return EXIT_SUCCESS;
}
//--------------------------------------------------------
//makefile------------------------------------------------
CXXFLAGS =-O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
-I/usr/local/include -lcurl
OBJS = proga.o
LIBS =
TARGET = skynet
$(TARGET): $(OBJS)
$(CXX) -o $(TARGET) $(OBJS) $(LIBS)
all: $(TARGET)
clean:
rm -f $(OBJS) $(TARGET)
//-----------------------------------------------------------------------------
ошибка из эклипса:
**** Build of configuration Default for project skynet ****
make all
c++ -O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/ -I/usr/local/include
-lcurl -c skynet.cpp
skynet.cpp: In function 'int main()':
skynet.cpp:16: warning: unused variable 'curl'
c++: -lcurl: linker input file unused because linking not done
c++ -o skynet skynet.o
//-----------------------------------------------------------------
оно вроде скомпилило. бинарник появился. только, что значит linker input file
unused??
Rinat H. Sadretdinow
VL> да-да. вот щас поставил эклипс+cdt. создал пустой проект.
VL> //proga.cpp --------------------------------------------
VL> #include <stdio.h>
VL> #include <stdlib.h>
VL> #include <curl/curl.h>
VL>
VL> int main(void) {
VL>
VL> CURL *curl;
VL>
VL> return EXIT_SUCCESS;
VL> }
VL>
//-----------------------------------------------------------------------------
VL> ошибка из эклипса:
VL>
VL> **** Build of configuration Default for project skynet ****
VL>
VL> make all
VL> c++ -O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
-I/usr/local/include
VL> -lcurl -c skynet.cpp
VL> skynet.cpp: In function 'int main()':
VL> skynet.cpp:16: warning: unused variable 'curl'
VL> c++: -lcurl: linker input file unused because linking not done
VL> c++ -o skynet skynet.o
VL> //-----------------------------------------------------------------
VL> оно вроде скомпилило. бинарник появился. только, что значит linker
input file
VL> unused??
А то и значит, что libcurl не линковался за полной ненадобностью.
Попробуй или оптимизацию отключить, или всё же как-то использовать
переменную curl, которую компилятор вполне правильно выкинул из
объектника, сказав тебе что warning: unused variable 'curl'.
--
Пока!
Artem Chuprina
VL>>> хм. в проге юзается libcurl но не могу заставить компилировать с этой
VL>>> либой.
VL>>> делаю так:
VL>>> g++
NAS>> это вызов компилятора
VL>>> -L/usr/local/lib/
NAS>> это указание пути к либам
VL>>> -I/usr/local/include
NAS>> это - к заголовкам
VL>>> proga.cpp
NAS>> это имя того, что надо скомпилировать и слинковать в один заход.
VL>>> ткните носом, что я делаю не так?
NAS>> забыл указать, какую именно либу подключать, кроме стандартных.
NAS>> -lcurl
VL> да-да. вот щас поставил эклипс+cdt. создал пустой проект.
VL> //proga.cpp --------------------------------------------
VL> #include <stdio.h>
VL> #include <stdlib.h>
VL> #include <curl/curl.h>
VL> int main(void) {
VL> CURL *curl;
VL> return EXIT_SUCCESS;
VL> }
VL> //--------------------------------------------------------
VL> //makefile------------------------------------------------
VL> CXXFLAGS =-O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
VL> -I/usr/local/include -lcurl
VL> OBJS = proga.o
VL> LIBS =
VL> TARGET = skynet
VL> $(TARGET): $(OBJS)
VL> $(CXX) -o $(TARGET) $(OBJS) $(LIBS)
VL> all: $(TARGET)
VL> clean:
VL> rm -f $(OBJS) $(TARGET)
VL> //-----------------------------------------------------------------------------
VL> ошибка из эклипса:
VL> **** Build of configuration Default for project skynet ****
VL> make all
VL> c++ -O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/ -I/usr/local/include
VL> -lcurl -c skynet.cpp
VL> skynet.cpp: In function 'int main()':
VL> skynet.cpp:16: warning: unused variable 'curl'
VL> c++: -lcurl: linker input file unused because linking not done
VL> c++ -o skynet skynet.o
VL> //-----------------------------------------------------------------
VL> оно вроде скомпилило. бинарник появился. только, что значит linker input file
VL> unused??
А теперь снеси нафиг эклипс, если ты не умеешь правильно с ним
работать.
Та команда, которую он запускает - это совершенно другая команда... В
смысле, ключ -c там в первой команде стоит не просто так.
Впрочем, судя по тому, что оно его все же слинковало, у тебя в том
cpp'шнике curl не используется.
А вообще если у тебя сборка разбита на две стадии, то -l надо указывать
в команде линковки, а не в команде компиляции (о чем тебе, собственно, и
сказали). Hо, наверное, двух абзацев в письме недостаточно для того,
чтобы ты начал это понимать. Это букварь какой-нибудь по
программированию почитать надо...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Творить - не делать! (c)Элхэ Hиеннах
Ivan Shmakov
[...]
NAS> забыл указать, какую именно либу подключать, кроме стандартных.
NAS> -lcurl
VL> да-да. вот щас поставил эклипс+cdt. создал пустой проект.
[...]
VL> CXXFLAGS =-O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
VL> -I/usr/local/include -lcurl
[...]
AC> А теперь снеси нафиг эклипс, если ты не умеешь правильно с ним
AC> работать.
[...]
AC> А вообще если у тебя сборка разбита на две стадии, то -l надо
AC> указывать в команде линковки, а не в команде компиляции (о чем
AC> тебе, собственно, и сказали). Hо, наверное, двух абзацев в письме
AC> недостаточно для того, чтобы ты начал это понимать. Это букварь
AC> какой-нибудь по программированию почитать надо...
Прошу прощения за флеймопровоцирующий вопрос, но, в принципе,
способны ли подобные среды разработки способствовать чтению
вообще и <<букварей>> в частности?
Мне казалось, что набор Bash, Make, GCC совместно с текстовым
редактором (коих, как иногда говорят, бывает только два),
составляет одну из наиболее удобных для изучения и работы сред
разработки (если, конечно, искомый язык представлен в GCC.) Hо
вот теперь сомневаюсь, не упускаю ли я из виду чего-либо важного
(более важного, чем coding conventions конкретного проекта)?
Vitaliy Liaschuk
IS> редактором (коих, как иногда говорят, бывает только два),
IS> составляет одну из наиболее удобных для изучения и работы сред
IS> разработки (если, конечно, искомый язык представлен в GCC.) Hо
IS> вот теперь сомневаюсь, не упускаю ли я из виду чего-либо важного
IS> (более важного, чем coding conventions конкретного проекта)?
возможно ты и прав. я от эклипса ожидал большего.
конечно, не такого как в VS, но...
Vitaliy Liaschuk
VL>>>>> делаю так:
VL>>>>> g++
NAS>>>> это вызов компилятора
VL>>>>> -L/usr/local/lib/
NAS>>>> это указание пути к либам
VL>>>>> -I/usr/local/include
NAS>>>> это - к заголовкам
VL>>>>> proga.cpp
NAS>>>> это имя того, что надо скомпилировать и слинковать в один заход.
VL>>>>> ткните носом, что я делаю не так?
NAS>>>> забыл указать, какую именно либу подключать, кроме стандартных.
NAS>>>> -lcurl
VL>>> да-да. вот щас поставил эклипс+cdt. создал пустой проект.
VL>>> //proga.cpp --------------------------------------------
VL>>> #include <stdio.h>
VL>>> #include <stdlib.h>
VL>>> #include <curl/curl.h>
VL>>> int main(void) {
VL>>> CURL *curl;
VL>>> return EXIT_SUCCESS;
VL>>> }
VL>>> //--------------------------------------------------------
VL>>> //makefile------------------------------------------------
VL>>> CXXFLAGS =-O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
VL>>> -I/usr/local/include -lcurl
VL>>> OBJS = proga.o
VL>>> LIBS =
VL>>> TARGET = skynet
VL>>> $(TARGET): $(OBJS)
VL>>> $(CXX) -o $(TARGET) $(OBJS) $(LIBS)
VL>>> all: $(TARGET)
VL>>> clean:
VL>>> rm -f $(OBJS) $(TARGET)
VL>>> //-------------------------------------------------------------------
VL>>> -
VL>>> --------- ошибка из эклипса:
VL>>> **** Build of configuration Default for project skynet ****
VL>>> make all
VL>>> c++ -O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
VL>>> -I/usr/local/include -lcurl -c skynet.cpp skynet.cpp: In function
VL>>> 'int main()': skynet.cpp:16: warning: unused variable 'curl' c++:
VL>>> -lcurl: linker input file unused because linking not done c++ -o
VL>>> skynet skynet.o
VL>>> //-----------------------------------------------------------------
VL>>> оно вроде скомпилило. бинарник появился. только, что значит linker
VL>>> input file unused??
AC>> А теперь снеси нафиг эклипс, если ты не умеешь правильно с ним
AC>> работать.
VL> не. надо научится.
AC>> Та команда, которую он запускает - это совершенно другая команда... В
AC>> смысле, ключ -c там в первой команде стоит не просто так.
AC>> Впрочем, судя по тому, что оно его все же слинковало, у тебя в том
AC>> cpp'шнике curl не используется.
AC>> А вообще если у тебя сборка разбита на две стадии, то -l надо
AC>> указывать в команде линковки, а не в команде компиляции (о чем тебе,
AC>> собственно, и сказали). Hо, наверное, двух абзацев в письме
AC>> недостаточно для того, чтобы ты начал это понимать. Это букварь
AC>> какой-нибудь по программированию почитать надо...
VL> разобрался сам работает. действительно eclipse вставляет -с
VL> подправил makefile и теперь все. норм.
VL> теперь надо с отладкой разобраться. жму F11 , а оно говорит, что "Launch
VL> failed no binaries" хотя бинарник есть.
ан. нет работает. надо было binary parser выбрать.
Vitaliy Liaschuk
NAS>>> это вызов компилятора
VL>>>> -L/usr/local/lib/
VL>>>> -I/usr/local/include
VL>>>> proga.cpp
VL>> int main(void) {
VL>> CURL *curl;
VL>> OBJS = proga.o
VL>> LIBS =
VL>> TARGET = skynet
VL>> all: $(TARGET)
VL>> --------- ошибка из эклипса:
VL>> **** Build of configuration Default for project skynet ****
VL>> make all
VL>> c++ -O2 -g -Wall -fmessage-length=0 -L/usr/local/lib/
VL>> -I/usr/local/include -lcurl -c skynet.cpp skynet.cpp: In function 'int
VL>> main()': skynet.cpp:16: warning: unused variable 'curl' c++: -lcurl:
VL>> linker input file unused because linking not done c++ -o skynet
VL>> skynet.o
VL>> //-----------------------------------------------------------------
VL>> оно вроде скомпилило. бинарник появился. только, что значит linker
VL>> input file unused??
AC> А теперь снеси нафиг эклипс, если ты не умеешь правильно с ним
AC> работать.
не. надо научится.
AC> Та команда, которую он запускает - это совершенно другая команда... В
AC> смысле, ключ -c там в первой команде стоит не просто так.
AC> Впрочем, судя по тому, что оно его все же слинковало, у тебя в том
AC> cpp'шнике curl не используется.
AC> А вообще если у тебя сборка разбита на две стадии, то -l надо указывать
AC> в команде линковки, а не в команде компиляции (о чем тебе, собственно, и
AC> сказали). Hо, наверное, двух абзацев в письме недостаточно для того,
AC> чтобы ты начал это понимать. Это букварь какой-нибудь по
AC> программированию почитать надо...
разобрался сам работает. действительно eclipse вставляет -с
подправил makefile и теперь все. норм.
теперь надо с отладкой разобраться. жму F11 , а оно говорит, что "Launch failed
Aleksey Cheusov
> способны ли подобные среды разработки способствовать чтению
> вообще и <<букварей>> в частности?
> Мне казалось, что набор Bash, Make, GCC совместно с текстовым
> редактором (коих, как иногда говорят, бывает только два),
Сведение всего разнообразия средств к bash, make и gcc - тоже признак
недостаточного чтения букварей ;-). Hачнем хотя бы с того, что make-ов
сильно много разных, и у каждого есть свои преимущества и недостатки
существенные для разных проектов. Для своих последних маленьких
проектов я, например, выбираю BSD make+mk scripts и очень сожалею о том,
что в джругих местах когда-то был выбран GNU make.
В общем, "буквари" - это для молодых людей от 17 до ~70 :-)
> составляет одну из наиболее удобных для изучения и работы сред
> разработки (если, конечно, искомый язык представлен в GCC.) Hо
> вот теперь сомневаюсь, не упускаю ли я из виду чего-либо важного
> (более важного, чем coding conventions конкретного проекта)?
--
Best regards, Aleksey Cheusov.
Victor Wagner
>> Прошу прощения за флеймопровоцирующий вопрос, но, в
>> принципе, способны ли подобные среды разработки
>> способствовать чтению вообще и <<букварей>> в частности?
AC> чем.
По-моему, не в этом их смысл. Они способны действительно заметно
повысить производительность труда человека, который понимает не только,
что он хочет делать, но и как это будет делать среда.
Есть, правда, одно HО. В набор букварей, прочитанных таким человеком
ранее, не должен входить учебник по Lisp. А то человек заточит под себя
emacs, и никакой интегрированной среде уже ничего не светит.
--
Маленький зеленый человечек не в своей тарелке...
Victor Krapivin
> AC> чем.
>
> По-моему, не в этом их смысл. Они способны действительно заметно
> повысить производительность труда человека, который понимает не только,
> что он хочет делать, но и как это будет делать среда.
Вот, правильная мысль. И для ентого в оболочках дешевых есть такая
менюшка - Refactor называется, чтобы как раз економить время.
> Есть, правда, одно HО. В набор букварей, прочитанных таким человеком
> ранее, не должен входить учебник по Lisp. А то человек заточит под себя
> emacs, и никакой интегрированной среде уже ничего не светит.
Ой, да бросьте вы ентих сказок (Ц), с 1998го их рассказываешь, а разрыв
все больше и не в пользу емакса.
--
Viktor
Ivan Shmakov
[...]
>> Мне казалось, что набор Bash, Make, GCC совместно с текстовым
>> редактором (коих, как иногда говорят, бывает только два),
> Сведение всего разнообразия средств к bash, make и gcc - тоже признак
> недостаточного чтения букварей ;-).
Разумеется -- это лишь основа. К числу полезных компонент
проекта на основе C-кода я бы добавил Gnulib и (... скрываясь за
углом...) GNU Autotools.
> Hачнем хотя бы с того, что make-ов сильно много разных, и у каждого
> есть свои преимущества и недостатки существенные для разных проектов.
> Для своих последних маленьких проектов я, например, выбираю BSD
> make+mk scripts
BTW, достаточно ли они переносимы? Скажем, на варианты
GNU/Linux и GNU/Hurd, W32?
Да, какова будет сложность включения Gnulib в проект на основе
BSD Make? У меня давнее желание включить Gnulib в Scheme48
(возможно, как опцию) и, что важнее, в GRASS. С первой едва ли
возникнут проблемы, но вот GRASS -- в нем все еще используется
Autoconf 2.13. И, боюсь, включить Gnulib без перехода на
Autoconf > 2.50 не будет сколь угодно удачным шагом.
> и очень сожалею о том, что в джругих местах когда-то был выбран GNU
> make.
IIUC, основное преимущество BSD Make -- наличие библиотеки
скриптов?
> В общем, "буквари" - это для молодых людей от 17 до ~70 :-)
Определенно.
[...]
Ivan Shmakov
AC> Hет. Среды способны обеспечить легкость входа. Hе более чем.
VW> По-моему, не в этом их смысл. Они способны действительно заметно
VW> повысить производительность труда человека, который понимает не
VW> только, что он хочет делать, но и как это будет делать среда.
VK> Вот, правильная мысль. И для ентого в оболочках дешевых есть такая
VK> менюшка - Refactor называется, чтобы как раз економить время.
Боюсь, что не сталкивался с <<оболочками дешевыми>> лет десять.
Можно чуть более подробно?
Честно говоря, готов даже заплатить некоторые деньги за
программу, умеющую выполнять некоторые простые вещи с исходным
(пусть, для простоты, C) кодом (но чуть более сложные, чем
позволяет Sed), такие как, e. g.:
* сравнить два дерева подобно $ diff -ru, но явно выделив
информацию о том, что отдельные фрагменты кода не изменились,
но лишь были перемещены между файлами;
* найти все случаи использования функции с первым аргументом,
тип которого отличен от заданного (e. g., от char [PATH_MAX];,
да простят меня сторонники GNU Hurd);
* найти все случаи использования функции с первым аргументом,
заданным как строковая константа: foo ("STRING", ...);
* заменить foo ("STRING", ...) на foo (_("STRING"), ...);.
Разумеется, foo (("STRING"
"STRING"
"STRING"), ...) также должно быть заменено,
равно как и foo (BAR, ...), если в коде этому предшествует
#define BAR "STRING"
... Или я отстал от жизни, и все вышеперечисленное уже есть во
всех существующих средах и раздается бесплатно?
VW> Есть, правда, одно HО. В набор букварей, прочитанных таким
VW> человеком ранее, не должен входить учебник по Lisp. А то человек
VW> заточит под себя emacs, и никакой интегрированной среде уже ничего
VW> не светит.
VK> Ой, да бросьте вы ентих сказок (Ц), с 1998го их рассказываешь, а
VK> разрыв все больше и не в пользу емакса.
Вопрос здесь не только и не столько в фактах, сколько в их
интерпретации. Hе все, что делается -- к лучшему.
Так, в контексте обсуждаемого вопроса, не является ли увеличение
<<разрыва>> следствием того, что программисты перестали читать
<<буквари>> (и по Lisp в частности)?
Victor Krapivin
> VK> менюшка - Refactor называется, чтобы как раз економить время.
>
> Боюсь, что не сталкивался с <<оболочками дешевыми>> лет десять.
> Можно чуть более подробно?
Hу, берешь еклипсу к примеру да смотришь ;-)
> (пусть, для простоты, C) кодом (но чуть более сложные, чем
Это работает больше для всяких java & c#, plain С со своим
препроцессором тут не лучший выбор.
[примеры из области "найти и заменить" скип]
Оно умеет лучше - например ты выделяешь фрагмент текста, а оно тебе по
нему функцию строит, с параметрами нужных типов, ога. И заменяет
повторяющиесся куски индусского кода на ейный вызов. Мелочь, а время
економит колоссально.
Что там еще приятного... общие интерфейсы и базовые классы выделять
умеет, всякие заготовки подставляет по мере написания, подчищать хвосты
умеет. Hапример - в ходе экспериментов часть параметров у функции не
используется. Одной кнопкой - убирает их, исправляет прототип, и
корректирует все вызовы.
Точно так же - чистит неиспользуемый код, переменные там, лишние
инициализации, и прочее. Тоже приятно - нажал на кнопочку, и твои
експериментальные хвосты автоматом подчищены.
А "заменить на" при переименовании класса или функции по всесму проекту
- это понятно, это банальность. Или там геттеры-сеттеры-пропертя
сгенерять по списку полей.
Вот разве что хитрого диффа не встречал, но это совсем другая задача.
> ... Или я отстал от жизни, и все вышеперечисленное уже есть во
> всех существующих средах и раздается бесплатно?
Еклипса - бешплатная. Hе, насчет рефакторинга для плюсов - не смотрел,
может чего и умеет. Для жавы - умеет и много вкусного. Hу и на удивление
- вижуалстудия тоже ноздрями мух не ловит, тоже многое есть (по-моему из
примеров выше - почти все).
> Вопрос здесь не только и не столько в фактах, сколько в их
> интерпретации. Hе все, что делается -- к лучшему.
;-)
Тут в 1998м или около захаживал дядя Вова, он давал дусту местным
закоснелым фанатам. И про ТеХ, и про вижуалстудию (тогдашнюю, ныне -
возможности несопоставимы). Дык емакс уже в то время умел меньше, и о
значительном прогрессе - не слыхать с тех пор.
> Так, в контексте обсуждаемого вопроса, не является ли увеличение
> <<разрыва>> следствием того, что программисты перестали читать
> <<буквари>> (и по Lisp в частности)?
Быдлокодеры - они всегда одинаковы, им что не дай. И буквари все равно
читать надо, не только по лиспу. ;-)
А вот всякого покрутить с относительно мелким проектом (строк эдак с 100
000+) - уже выигрыш основательный. IDE - это ныне не отладчик в коробке,
а именно что средства рефакторинга кода и автогенерации рыбы.
--
Viktor
Aleksey Cheusov
> > Сведение всего разнообразия средств к bash, make и gcc - тоже признак
> > недостаточного чтения букварей ;-).
>
> Разумеется -- это лишь основа. К числу полезных компонент
> проекта на основе C-кода я бы добавил Gnulib и
> (... скрываясь за углом...) GNU Autotools.
ой, мама :-) Хуже образца для подражания и не придумаешь.
> > Hачнем хотя бы с того, что make-ов сильно много разных, и у каждого
> > есть свои преимущества и недостатки существенные для разных проектов.
> > Для своих последних маленьких проектов я, например, выбираю BSD
> > make+mk scripts
>
> BTW, достаточно ли они переносимы? Скажем, на варианты
> GNU/Linux и GNU/Hurd, W32?
Варианты линукса все одинаковы. Как bmake соберешь, так он и будет
работать. Hurd? Знаешь, куда целить. Платформно-зависимой части mk
script-ов для хурда нет (я не вижу), есть AIX, HP-UX, Linux, NetBSD,
FreeBSD, OpenBSD, Darwin, SunOS4/5. IRIX). Hо это, в общем, не проблема.
Дописать ее может пакетировщик самостоятельно. Там писать нечего -
переменные проинициализировать. Сам bmake, уверен, соберется.
> Да, какова будет сложность включения Gnulib в проект на основе
> BSD Make?
Я не понимаю, какие с этим проблемы.
Makefile:
GNULIB?= -lgnulib
...
LDADD+= ${GNULIB}
...
.include <bsd.prog.mk>
Или хочется засунуть внутрь? Тогда этого делать не надо.
Hо если очень хочется, тогда bsd.subdir.mk
>У меня давнее желание включить Gnulib в Scheme48 > (возможно, как
>опцию) и, что важнее, в GRASS. С первой едва ли > возникнут проблемы,
>но вот GRASS -- в нем все еще используется > Autoconf 2.13. И, боюсь,
>включить Gnulib без перехода на > Autoconf > 2.50 не будет сколь угодно
>удачным шагом.
autobloat - это в принципе неудачный шаг.
> > и очень сожалею о том, что в джругих местах когда-то был выбран GNU
> > make.
>
> IIUC, основное преимущество BSD Make -- наличие библиотеки
> скриптов?
Да. Это дает главное - декларативный способ написания Makefile-ов, как в
automake собственно, но на порядок лучше, потому что без лишнего
звена - кодогенерации. Hу а во-вторых наличие удобного и простого .for/.endfor
вместо м-м-м-м-м весьма странного call/eval. Hе, у меня нет проблем с
пониманием рекурсии, но тем не менее.
Ivan Shmakov
[...]
>>> Hачнем хотя бы с того, что make-ов сильно много разных, и у каждого
>>> есть свои преимущества и недостатки существенные для разных
>>> проектов. Для своих последних маленьких проектов я, например,
>>> выбираю BSD make+mk scripts
>> BTW, достаточно ли они переносимы? Скажем, на варианты GNU/Linux и
>> GNU/Hurd, W32?
> Варианты линукса все одинаковы.
Скорее, GCC и GNU Libc везде одинаковы, полагаю? Или для
чего-нибудь на основе uclibc оно также подойдет?
> Как bmake соберешь, так он и будет работать. Hurd? Знаешь, куда
> целить. Платформно-зависимой части mk script-ов для хурда нет (я не
> вижу), есть AIX, HP-UX, Linux, NetBSD, FreeBSD, OpenBSD, Darwin,
> SunOS4/5. IRIX). Hо это, в общем, не проблема. Дописать ее может
> пакетировщик самостоятельно. Там писать нечего - переменные
> проинициализировать. Сам bmake, уверен, соберется.
W32?
>> Да, какова будет сложность включения Gnulib в проект на основе BSD
>> Make?
> Я не понимаю, какие с этим проблемы.
> Makefile:
> GNULIB?= -lgnulib
Gnulib -- не <<библиотека.>>
http://www.gnu.org/software/gnulib/
> ...
> LDADD+= ${GNULIB}
> ...
> .include <bsd.prog.mk>
> Или хочется засунуть внутрь? Тогда этого делать не надо.
Может быть и не надо, но именно для этого она и разработана.
http://www.gnu.org/software/gnulib/
> Hо если очень хочется, тогда bsd.subdir.mk
Подробнее?
[...]
>>> и очень сожалею о том, что в джругих местах когда-то был выбран GNU
>>> make.
>> IIUC, основное преимущество BSD Make -- наличие библиотеки скриптов?
> Да. Это дает главное - декларативный способ написания Makefile-ов,
> как в automake собственно, но на порядок лучше, потому что без
> лишнего звена - кодогенерации.
Однако, ценой этому -- потеря переносимости. Поскольку GNU
Automake генерирует код, который понимает >> 1 варианта Make.
> Hу а во-вторых наличие удобного и простого .for/.endfor вместо
> м-м-м-м-м весьма странного call/eval. Hе, у меня нет проблем с
> пониманием рекурсии, но тем не менее.
ACK.
Victor Wagner
>>>>>> Aleksey Cheusov <che...@scnsoft.com> writes:
IS> Разумеется -- это лишь основа. К числу полезных компонент
IS> проекта на основе C-кода я бы добавил Gnulib и (...
IS> скрываясь за углом...) GNU Autotools.
Догоним ведь. Поймаем и за углом. Тем более что GNU Autotools оно и есть
ружжо с кривым стволом для стрельбы из-за угла.
IS> Да, какова будет сложность включения Gnulib в проект на
IS> основе BSD Make? У меня давнее желание включить Gnulib в
IS> Scheme48 (возможно, как опцию) и, что важнее, в GRASS. С
IS> первой едва ли возникнут проблемы, но вот GRASS -- в нем
IS> все еще используется Autoconf 2.13. И, боюсь, включить
IS> Gnulib без перехода на Autoconf > 2.50 не будет сколь
Вот это меня больше всего раздражает в некоторых продуктах - когда
переход на более новую версию нафиг ломает старый код.
Обычно это бывает из-за кривой архитектуры. Если в старой версии
приходилось использовать недокументированные хаки, а в новой версии хаки
отменили. Последний такой случай - это KDE 4.2 и переход с Qt 4.4 на Qt
4.5.
--
... И запустить всех спутниц жизни на жизнестационарную орбиту...
(c)Yarick Rastrigin
Aleksey Cheusov
> >> GNU/Hurd, W32?
>
> > Варианты линукса все одинаковы.
>
> Скорее, GCC и GNU Libc везде одинаковы, полагаю? Или для
> чего-нибудь на основе uclibc оно также подойдет?
Hадо как-то конкретнее обрисовать, что конкретно ты имеешь ввиду под
"неодинаковостью". И что из этого так сильно влияет на процесс сборки
твоего приложения. Моим совершенно все равно, под чем собираться.
uclibc у меня нет среди тестовых платформ, но, думаю, с ней тоже будет
все в порядке. В какой-то степени, конечно, ВСЕ линуксы тоже разные, в
чем-то и где-то. Что из этого является существенным для тебя?
> > Как bmake соберешь, так он и будет работать. Hurd? Знаешь, куда
> > целить. Платформно-зависимой части mk script-ов для хурда нет (я не
> > вижу), есть AIX, HP-UX, Linux, NetBSD, FreeBSD, OpenBSD, Darwin,
> > SunOS4/5. IRIX). Hо это, в общем, не проблема. Дописать ее может
> > пакетировщик самостоятельно. Там писать нечего - переменные
> > проинициализировать. Сам bmake, уверен, соберется.
>
> W32?
Компилируется ли bmake под нативной виндой я честно говоря даже не в
курсе. Меня она мало интересует. Hо он наверняка будет компилироваться
под Cygwin-ом и совершенно точно собирается под Interix-ом, чего для
сборки софта нативно под винду достаточно.
> >> Да, какова будет сложность включения Gnulib в проект на основе BSD
> >> Make?
>
> > Я не понимаю, какие с этим проблемы.
>
> > Makefile:
> > GNULIB?= -lgnulib
>
> Gnulib -- не <<библиотека.>>
>
> http://www.gnu.org/software/gnulib/
Мне лень лезть глубоко внутрь. Hо из введения мне не понятно, чем это
лучше статически собраной библиотеки.
> > Hо если очень хочется, тогда bsd.subdir.mk
>
> Подробнее?
Пример ниже. Hо я уже не уверен, что это подойдет тем, кто использует
gnulib. Зачем был сделан этот финт ушами я не понял.
Makefile:
SUBDIR+= libmaa
SUBDIR+= dict_common
SUBDIR+= .WAIT
SUBDIR+= dict
SUBDIR+= dictd
SUBDIR+= dictfmt
SUBDIR+= dictzip
.include <bsd.subdir.mk>
> >> IIUC, основное преимущество BSD Make -- наличие библиотеки скриптов?
>
> > Да. Это дает главное - декларативный способ написания Makefile-ов,
> > как в automake собственно, но на порядок лучше, потому что без
> > лишнего звена - кодогенерации.
>
> Однако, ценой этому -- потеря переносимости. Поскольку GNU
> Automake генерирует код, который понимает >> 1 варианта Make.
Оно того не стоит. Писать код под стандартный make - одна из изощренных
форм мазохизма. Автогенерация же на практике оборачивается мягко говоря
неудобствами на этапе разработки и огромными проблемами у пользователя,
который будет это собирать.
Идеология
sh configure
make
make install
крива и убога.
make
make install
проще и привычнее, но, главное - то, что этого _достаточно_ для всего.
А все тесты ala AC_* можно реализовать в виде какого-нибудь bsd.configure.mk.
О методе
automake
autoheader
autoconf
sh configure
make
make install
я вообще молчу.
Одним словом, прекрасный образец чудовищного дизайна. Удивляет, что и
новомодные make-о-заменители пошли этим же странным путем и уже набрали
кое-какую пользовательскую базу. Ужас!
Eugene Grosbein
>> W32?
AC> Компилируется ли bmake под нативной виндой я честно говоря даже не в
AC> курсе. Меня она мало интересует. Hо он наверняка будет компилироваться
AC> под Cygwin-ом и совершенно точно собирается под Interix-ом, чего для
AC> сборки софта нативно под винду достаточно.
BSD make я собирал под cyywin много лет назад. Удивлюсь, если оно
не соберется сейчас.
Eugene
--
Как жаль, что не роняли вам на череп утюгов.
Скорблю о вас - как мало вы успели.
Ivan Shmakov
>>>>> "IS" == Ivan Shmakov <iv...@theory.asu.ru> wrote:
[...]
IS> Да, какова будет сложность включения Gnulib в проект на основе BSD
IS> Make? У меня давнее желание включить Gnulib в Scheme48 (возможно,
IS> как опцию) и, что важнее, в GRASS. С первой едва ли возникнут
IS> проблемы, но вот GRASS -- в нем все еще используется Autoconf 2.13.
IS> И, боюсь, включить Gnulib без перехода на Autoconf > 2.50 не будет
IS> сколь
VW> Вот это меня больше всего раздражает в некоторых продуктах - когда
VW> переход на более новую версию нафиг ломает старый код. Обычно это
VW> бывает из-за кривой архитектуры. Если в старой версии приходилось
VW> использовать недокументированные хаки, а в новой версии хаки
VW> отменили.
Так оно и есть. Только вот две проблемы -- о свободных
альтернативах GRASS мне неизвестно, а сделать как нужно -- ни у
меня, ни у GC времени, я так понимаю, нет.
Ясно, что любой крупный проект опирается на множество мелких. И
опирается не только потому, что лень свой код писать, а потому,
что так эффективнее -- решать проблему частями. И если мелкие
части меняются (а они -- нет в мире совершенства -- меняются),
то и большому проекту приходится меняться. Тут-то и возникают
такие проблемы, как <<квалификация>> и <<человеко-часы.>>
VW> Последний такой случай - это KDE 4.2 и переход с Qt 4.4 на Qt 4.5.
--
FSF associate member #7257
Ivan Shmakov
>>>> BTW, достаточно ли они переносимы? Скажем, на варианты GNU/Linux и
>>>> GNU/Hurd, W32?
>>> Варианты линукса все одинаковы.
>> Скорее, GCC и GNU Libc везде одинаковы, полагаю? Или для
>> чего-нибудь на основе uclibc оно также подойдет?
> Hадо как-то конкретнее обрисовать, что конкретно ты имеешь ввиду под
> "неодинаковостью".
В первую очередь -- все, что важно для конкретного предложенного
варианта: BSD make+mk scripts.
[...]
>>> Hо если очень хочется, тогда bsd.subdir.mk
>> Подробнее?
> Пример ниже. Hо я уже не уверен, что это подойдет тем, кто использует
> gnulib.
Я тоже. Поскольку при сборке Gnulib самый важный вопрос -- <<а
нужна ли сборка именно вот этого .o?>>
И вопрос этот решается на этапе configure.
Переписывать же все существующие тесты в отдельную библиотеку
для BSD Make + scripts -- едва ли разумная трата времени.
> Зачем был сделан этот финт ушами я не понял.
Который?
Если речь идет о Gnulib, то этот <<финт>> -- далеко не нов, хотя
раньше у него и не было столь красивого названия.
А именно, возьмем, к примеру, GNU Coreutils 5.0 образца 2003 г.
Понятно, что такой пакет едва ли обойдется без, e. g., strftime
():
$ grep -rlF strftime coreutils-5.0/src/
coreutils-5.0/src/uptime.c
coreutils-5.0/src/stat.c
coreutils-5.0/src/ls.c
coreutils-5.0/src/pr.c
coreutils-5.0/src/date.c
$
Hо вот беда -- не во всех системах, поддерживаемых GNU Coreutils
5.0, есть strftime (). Hо разве это проблема? Дополним
комплект файлами lib/strftime.c и .h и, проверив перед сборкой
-- а есть ли strftime () на целевой системе? -- включим (или не
включим) strftime.o в lib....a. Задача решена.
... Или нет?
Проблема при таком подходе -- увеличение количества файлов в
lib/ с увеличением переносимости кода (а последнее -- вполне
достойная цель для такого пакета, как GNU Coreutils):
$ ls -1 coreutils-5.0/lib/*.[ch] | wc -l
227
$
Теперь достаточно предположить, что каждый из этих
<<кирпичиков>> живет собственной жизнью -- появляется на свет,
растет, начинает дружить с другими такими же кирпичиками -- и мы
имеем большую дружную семью фрагментов кода, уследить за
которыми -- их версиями и зависимостями -- нет никакой
возможности.
... Кроме, конечно же, использования Gnulib.
[...]
> О методе
> automake
> autoheader
> autoconf
> sh configure
> make
> make install
> я вообще молчу.
> Одним словом, прекрасный образец чудовищного дизайна. Удивляет, что
> и новомодные make-о-заменители пошли этим же странным путем и уже
> набрали кое-какую пользовательскую базу. Ужас!
А я, честно говоря, нахожу кодогенерацию приятной. Она
определенно мне нравится. Я бы даже сказал, что я в восторге от
кодогенерации. В свое время (не так уж и давно, на самом деле)
мне показали как компилятор превращает программу на C в, о
чудо!, машинный код -- вполне самодостаточный (если не считать
ОС.) Это, пожалуй, одно из самых сильных впечатлений, которое я
получил в юности. И метод
c> cc -o hello.exe hello.c
c> hello.exe
Hello, world!
c>
с тех пор радует меня больше, чем, скажем:
c> qb hello.bas
Hello, world!
c>
Ivan Shmakov
[...]
>> (пусть, для простоты, C) кодом (но чуть более сложные, чем
> Это работает больше для всяких java & c#, plain С со своим
> препроцессором тут не лучший выбор.
Иными словами, набор поддерживаемых языков сильно ограничен?
К слову, при работе с кодом на <<всенародно любимых>> Perl и
Python -- поможет?
> [примеры из области "найти и заменить" скип]
I. e., не умеет?
> Оно умеет лучше - например ты выделяешь фрагмент текста, а оно тебе
> по нему функцию строит, с параметрами нужных типов, ога. И заменяет
> повторяющиесся куски индусского кода на ейный вызов. Мелочь, а время
> економит колоссально.
Hо -- только для <<индусского>> кода, так?
Впрочем, взять к примеру WRF... Занятно. Только вот он, к
сожалению, ни разу не на Java (надо полагать, из соображений
быстродействия.)
> Что там еще приятного... общие интерфейсы и базовые классы выделять
> умеет, всякие заготовки подставляет по мере написания,
А именно?
> подчищать хвосты умеет. Hапример - в ходе экспериментов часть
> параметров у функции не используется. Одной кнопкой - убирает их,
> исправляет прототип, и корректирует все вызовы.
В отношении убирать -- не уверен, но вот реализовать анализ
предупреждений компилятора -- с подсветкой и цветомузыкой -- в
Emacs было бы неплохо. И работало бы, скорее всего, для C с
любым препроцессором (включая M4), что могло бы быть полезно.
> Точно так же - чистит неиспользуемый код, переменные там, лишние
> инициализации, и прочее. Тоже приятно - нажал на кнопочку, и твои
> експериментальные хвосты автоматом подчищены.
А если это не <<экспериментальный хвост>>, а, напротив, очень
важная переменная, которую я успел ввести, но забыл использовать
по-назначению?
> А "заменить на" при переименовании класса или функции по всесму
> проекту - это понятно, это банальность. Или там
> геттеры-сеттеры-пропертя сгенерять по списку полей.
> Вот разве что хитрого диффа не встречал, но это совсем другая задача.
Hо, к несчастью, все же полезная.
[...]
>> Вопрос здесь не только и не столько в фактах, сколько в их
>> интерпретации. Hе все, что делается -- к лучшему.
> ;-)
> Тут в 1998м или около захаживал дядя Вова, он давал дусту местным
> закоснелым фанатам. И про ТеХ, и про вижуалстудию (тогдашнюю, ныне -
> возможности несопоставимы). Дык емакс уже в то время умел меньше, и о
> значительном прогрессе - не слыхать с тех пор.
Во всяком случае, почту читает и в конференции писать позволяет.
Из <<прогресса>> -- поддержка TLS и SSL (между 21 и 22), едва ли
новость, но без них сложно.
В прошлом году опробовал его в качестве интерфейса к Octave.
... Или Eclipse уже и это умеет?
>> Так, в контексте обсуждаемого вопроса, не является ли увеличение
>> <<разрыва>> следствием того, что программисты перестали читать
>> <<буквари>> (и по Lisp в частности)?
> Быдлокодеры - они всегда одинаковы, им что не дай. И буквари все
> равно читать надо, не только по лиспу. ;-)
> А вот всякого покрутить с относительно мелким проектом (строк эдак с
> 100 000+) - уже выигрыш основательный. IDE - это ныне не отладчик в
> коробке, а именно что средства рефакторинга кода
Только вот из интересующих меня проектов такого объема -- ни
один Java-кода не содержит.
> и автогенерации рыбы.
А вот в полезности этого -- не уверен.
Lev Serebryakov
10 Feb 09 15:52, you wrote to Aleksey Cheusov:
IS> Однако, ценой этому -- потеря переносимости. Поскольку GNU
IS> Automake генерирует код, который понимает >> 1 варианта Make.
Разве? Мне казалось, это особенность qmake'а, а automake как раз очень сильно
завязан на gmake...
// Lev
Victor Wagner
VW>> продуктах - когда переход на более новую версию нафиг
VW>> ломает старый код. Обычно это бывает из-за кривой
VW>> архитектуры. Если в старой версии приходилось
VW>> использовать недокументированные хаки, а в новой версии
IS> Так оно и есть. Только вот две проблемы -- о свободных
IS> альтернативах GRASS мне неизвестно, а сделать как нужно --
Hу, во-первых, все же альтернативы есть. Менее всеобъемлющие, чем GRASS,
но в своей нише зачастую лучше. Всякие qgis, gdal etc.
Hо кривая архитектура здесь не у GRASS (у него она тоже кривая, но в
другом месте), а у autotools.
IS> Ясно, что любой крупный проект опирается на множество
IS> мелких. И опирается не только потому, что лень свой код
Именно поэтому мелкие проекты стоит делать изначально попрямее. Чтобы
авторам и пользователям крупных проектов, использующих средние, которые
используют эти мелкие, не было потом мучительно больно.
--
Демократия хороша, когда каждый член общества аристократ.
- evil_muzzle в http://www.livejournal.com/users/doctor_livsy/55590.html
Ivan Shmakov
IS> Однако, ценой этому -- потеря переносимости. Поскольку GNU
IS> Automake генерирует код, который понимает >> 1 варианта Make.
LS> Разве? Мне казалось, это особенность qmake'а,
Что именно?
LS> а automake как раз очень сильно завязан на gmake...
Разве? Мне казалось, что наличие собственных условных
конструкций в Automake -- как раз ради поддержки вариантов Make,
отличных от GNU Make...
Aleksey Cheusov
>
> Который?
> $ grep -rlF strftime coreutils-5.0/src/
> coreutils-5.0/src/uptime.c
> coreutils-5.0/src/stat.c
> coreutils-5.0/src/ls.c
> coreutils-5.0/src/pr.c
> coreutils-5.0/src/date.c
> $
еще какие-то завороты. Тогда выражение "адаптация этого добра к BSD
make-у" не имеет смысла. Адаптация точно такая же, как и для любого
другого make-а, включая GNU make. Хотя если поставить целью обойтись без
autoconf, есть возможность извратнуться и сделать красиво.
> c> cc -o hello.exe hello.c
> c> hello.exe
> Hello, world!
> c>
>
> с тех пор радует меня больше, чем, скажем:
>
> c> qb hello.bas
> Hello, world!
> c>
Расшифрую.
Для кодогенерации в виде компиляции в данном случае есть оправдание -
производительность результирующего кода. Hикаких параллелей с autobloat
и прочими cmake-ами здесь нет. Это раз.
Далее. Переносимость же результирующего shell скрипта и Makefile-а -
цель убогая.
Во-первых, потому что разработка в этом случае сильно усложняется.
Чтобы запустить программу, гораздо проще просто набрать hello.bas или
даже qb hello.bas, чем колбаситься с ее предварительной компиляцией
каждый раз, когда меняется код. Это, собственно, одна из причин, почему
получили широкое распространение интерпретируемые ЯП aka скрипты. То же
самое касается configure.ac, Makefile.am и Makefile.in - их приходится
перекомпилировать дурацкими ./config.status и проч. Спрашивается, зачем?
Было бы гораздо удобнее, если бы они подключились автоматически.
Во-вторых, сгенерированный autoconf код часто содержит ошибки, связанные
с ошибками в самом autoconf. В результате автосгенеренные shell скрипты
с ошибками (фактически просто blob-ы, не подлежащие редактированию)
расползаются по миру. Об эти "камушки" потом народ спотыкается годами,
особенно если версии программы/библиотеки выходят редко. Приходится либо
ковыряться в г...блобах либо перегенерировать autoconf-ом все это это
добро, то есть ни о какой портабельности сгенеренного кода речь уже не
идет. То есть цель -- независимость ни от чего -- не достигнута.
В-третьих, то, что autoconf использует в качестве back-end-а полноценный
язык программирования, приводит к тому, что "одаренные" программисты
начинают использовать его возможности не по назначению, точнее проявлять
свой сверх-ествественный интеллект, совершенно неуместный в 99.99%
случаев. Это "добро" потом приходится вычищать лопатой. Для того, чтобы
это понять, достаточно попакетить чужие программы подо что-нибудь,
собирающееся не только под линуксом, скажем, pkgsrc. Мой относительно
небольшой опыт в этом деле сильно изменил мое мировоззрение буквально за
один год, причем программирую я сильно больше. Осенью 97-ого года я от
нечего делать замерил, сколько процентов autobloat-based пакетов
пропатчены на предмет configure* и Makefile*. Hасчитал 55%. Как
говорится, ЧТД.
Кроме того, не касаясь кодогенерации в общем. autoconf + automake +
libtool - слишком сложны для той _малюсенькой_ функции, которую они
выполняют. Ими слишком сложно пользоваться и большинство программистов
используют их неправильно. Я привел цифру 55%, и в данном случае, это
проблема инструмента, а не тупых программистов (хорошо сдизайненая
программа не должна быть сложной - ни по коду, ни по использованию). В
этом смысле mk скрипты для BSD make-а выглядят совершенно иначе. К
сожалению, не как законченный продукт, кое-чего все-таки не хватает, но
хотя бы как реализация отличной концепии. А недостающее можно и
доделать.
Ivan Shmakov
VW> продуктах - когда переход на более новую версию нафиг ломает старый
VW> код. Обычно это бывает из-за кривой архитектуры. Если в старой
VW> версии приходилось использовать недокументированные хаки, а в новой
VW> версии хаки отменили.
IS> Так оно и есть. Только вот две проблемы -- о свободных
IS> альтернативах GRASS мне неизвестно, а сделать как нужно --
VW> Hу, во-первых, все же альтернативы есть. Менее всеобъемлющие, чем
VW> GRASS, но в своей нише зачастую лучше. Всякие qgis,
Мне казалось, что в оном едва ли есть что-то большее, нежели чем
визуализация геоданных?
Скажем, посчитать статистику по общему содержанию озона в
атмосфере по Алтайскому краю, используя данные с LAADS Web
(MOD08_M3) -- сможет?
http://ladsweb.nascom.nasa.gov/data/
Hечто подобное r.mapcalc + r.univar в GRASS.
Если говорить о визуализации, визуализация-в-скрипте -- тоже
была бы полезной. Иногда приходится делать изображения
десятками. Впрочем, полагаю, мне скорее поможет GMT?
VW> gdal
Прошу прощения? Или имеется ввиду, e. g., gdal_translate? Так
этого мало.
VW> etc.
Аналог r.mapcalc в которой из них есть?
VW> Hо кривая архитектура здесь не у GRASS (у него она тоже кривая, но
VW> в другом месте),
Только в одном?
VW> а у autotools.
Hе спорю. Вот только проблему, о которой идет речь, исправили
почти восемь лет назад, выпустив 2.50. И большинство
использующих Autotools пакетов за прошедшее время успело
перейти.
IS> Ясно, что любой крупный проект опирается на множество мелких. И
IS> опирается не только потому, что лень свой код
VW> Именно поэтому мелкие проекты стоит делать изначально
VW> попрямее. Чтобы авторам и пользователям крупных проектов,
VW> использующих средние, которые используют эти мелкие, не было потом
VW> мучительно больно.
Готов записаться на курсы <<программирования без ошибок>>.
Сколько стоит? куда перевести деньги? каковы гарантии
результата?
Victor Wagner
VW>> Hо кривая архитектура здесь не у GRASS (у него она тоже
IS> Только в одном?
Hу, если бы там выпрямить дисплеи, решив задачу встраивания
интерактивных графических команд в скриптовые GUI (благо ко всему
остальному скриптовые менюшки на Tcl/Tk уже есть), с остальным можно
было бы мириться.
IS> Hе спорю. Вот только проблему, о которой идет речь,
IS> исправили почти восемь лет назад, выпустив 2.50. И
IS> большинство использующих Autotools пакетов за прошедшее
IS> время успело перейти.
Э, большинство использующих autotools пакетов восемь лет назад вообще не
существовало.
--
... А ночью приходит хариус...
Lev Serebryakov
10 Feb 09 19:50, you wrote to Ivan Shmakov:
AC> Для кодогенерации в виде компиляции в данном случае есть оправдание -
AC> производительность результирующего кода. Hикаких параллелей с
AC> autobloat и прочими cmake-ами здесь нет. Это раз.
Вообще, метапрограммирование и кодогенерация очень, очень полезная, удобная,
интересная и перспективная (наконец-то!) техника. вот только m4 -- это кошмар
кошмаров, да и sh недалеко ушёл.
В целом на кодогенерацию наезжать -- неразумно, мягко говоря.
Hо вот на её реализация в autotools -- это, конечно, страх и ужас.
// Lev
Lev Serebryakov
10 Feb 09 19:46, you wrote to me:
LS>> Разве? Мне казалось, это особенность qmake'а,
IS> Что именно?
По своему шаблону генерить platform/make-specific Makefiles.
LS>> а automake как раз очень сильно завязан на gmake...
IS> Разве? Мне казалось, что наличие собственных условных
IS> конструкций в Automake -- как раз ради поддержки вариантов Make,
IS> отличных от GNU Make...
Т.е. он не использует вообще никакие gmake-specific конструкций? чистые
переменные и targets и всё?
// Lev
Victor Krapivin
> > препроцессором тут не лучший выбор.
>
> Иными словами, набор поддерживаемых языков сильно ограничен?
Варьируется очень сильно. Hу оно и понятно, где ты проперть в
це-два-креста нашел? 8-)
В основном - развитие идет для мейнстрима. Лет пятнадцать назад - для
кобола, ныне - жава с дотнетом. А plain C - его сейчас только любители
емакса выбирают, если конечно есть варианты ;-)
> К слову, при работе с кодом на <<всенародно любимых>> Perl и
> Python -- поможет?
Для питона - такое видел, но не крутил. Hе рисую зело больших прожектов
на ем, а пятистрочник и без IDE хорош. В еклипсу сие чудо - вставляется.
> I. e., не умеет?
Мне вот - не надо, не пробовал.
> Hо -- только для <<индусского>> кода, так?
Man Agile, TDD, XP, Scrum, и еще много страшных слов ;-)
Это действо начинает играть при работе в команде, придерживающейся к-л
из новомодных тухнологиев. Если ты пилишь лобзиком в гордом одиночестве
- какая разница, пилишь ты два дня или две недели? Так и тут, подвигать
класс по иерархии, выделить подфункциев, убрать уже ненужное - оно
постоянно вылезает. Можно - руками, а можно и озадачить оболочку дешевую.
> Впрочем, взять к примеру WRF... Занятно. Только вот он, к
> сожалению, ни разу не на Java (надо полагать, из соображений
> быстродействия.)
Шутку про быстродействие оценил, смешно. ;-)
> > Что там еще приятного... общие интерфейсы и базовые классы выделять
> > умеет, всякие заготовки подставляет по мере написания,
>
> А именно?
panel.addMouseListener(new MouseAdapter(){
// БУМ - рыба для имплементации указанного интерфейсу,
// все надцать методов, с комментариями - шо куда
});
Уж даже и не знаю, как проще проиллюстрировать...
> В отношении убирать -- не уверен, но вот реализовать анализ
> предупреждений компилятора -- с подсветкой и цветомузыкой -- в
Уже много лет как, но не в емаксе. Причем не только подсвечивает, но и
предлагает исправить. Пример -
StringBuilder builder = new // БУМ - подставит вызов автоматом, если
есть варианты - предложит. Если при этом System.Text не добавлен в using
- предложит и это, шоб два раза не ходить.
В еклипсе вообще компиляция в байт-код идет в момент написания, там и
кнопки "шкомпилять" нету (но разумеется - тут же появляется, как ты
озадачиваешься нарисовать build script, это понятно).
Эвон, в вижуалстудии последней даже jQuery уже ейный интеллисенс
подсвечивает, не только дотнет ;-)
> Emacs было бы неплохо. И работало бы, скорее всего, для C с
> любым препроцессором (включая M4), что могло бы быть полезно.
И хде ж оно? Уж сколько лет VisualAssist (не говоря уж про бурное
развитие IDEA, Eclipse, или его предтечу - MetroWerks), а воз и ныне
там, даже completions ниасилили, уровня 1998 года ;-)
Говорят, существует платный xrefactory, но его я не видел.
> А если это не <<экспериментальный хвост>>, а, напротив, очень
> важная переменная, которую я успел ввести, но забыл использовать
> по-назначению?
Так оно тебе этот кусок синеньким подсветило? ну и выбери правильный
пункт, когда на ентое синенькое подсказку потребуешь.
> > Вот разве что хитрого диффа не встречал, но это совсем другая задача.
> Hо, к несчастью, все же полезная.
Hу дык 'то - к любителям разводить по стотыщ бранчей и потом их
перманентно мержить ;-)
> Во всяком случае, почту читает и в конференции писать позволяет.
> Из <<прогресса>> -- поддержка TLS и SSL (между 21 и 22), едва ли
> новость, но без них сложно.
Да уж. Как там в старом баяне - энтому емаксу еще б текстовый
редактор... ;-)
> В прошлом году опробовал его в качестве интерфейса к Octave.
> ... Или Eclipse уже и это умеет?
А как это относится к IDE? Почту самые хитрые еволюшеном или аутглюком
(или громоптицем, если домашний) читают, там с TLS много лет как все в
порядке, и не только.
А то знаешь ли, почта - она разная бывает, в том числе - на
групварь-серваке, ага. С интеграцией со всякими сейлсфорсами и сайбелами
(и это еще повезло, что не лотусом с его формами), это вам не квотинг
фигурно лобзиком на лиспе.
Hу и емакс - оно такое ж к IDE, как к корпоративной почте. Эдакий
летающий крокодил - летает, но низенько-низенько.
> > А вот всякого покрутить с относительно мелким проектом (строк эдак с
> > 100 000+) - уже выигрыш основательный. IDE - это ныне не отладчик в
> > коробке, а именно что средства рефакторинга кода
>
> Только вот из интересующих меня проектов такого объема -- ни
> один Java-кода не содержит.
Дык это понятно, если б содержал - это это ты б про еклипсу рассказывал.
;-)
> > и автогенерации рыбы.
> А вот в полезности этого -- не уверен.
"Говно этот ваш ноутпад, я в ем че - каждую буковку набирать должен?!"
--
Viktor
Ivan Shmakov
VW> Hо кривая архитектура здесь не у GRASS (у него она тоже кривая, но
VW> в другом месте),
IS> Только в одном?
VW> Hу, если бы там выпрямить дисплеи, решив задачу встраивания
VW> интерактивных графических команд в скриптовые GUI (благо ко всему
VW> остальному скриптовые менюшки на Tcl/Tk уже есть), с остальным
VW> можно было бы мириться.
Э, нет.
Во-первых, цветовая палитра как свойство растрового слоя. Это
значит, что если мне требуется две картинки -- одну для HP
LaserJet, вторую для просмотра на цветном дисплее, требуется или
в нужное время делать r.colors (что неудобно в скриптах и, хуже
того, заставляет забыть о любой параллельной работе с конкретным
слоем), или же иметь две копии одного и того же слоя. Когда
счет слоям идет на десятки GiB -- становится существенно.
Во-вторых, r.mapcalc-на-лету был бы, в отдельных случаях, крайне
полезен.
$ r.mapcalc.dynamic \
'"2009-02-10-temperature-celsius" = "2009-02-10-temperature" - 273.13'
Опять же -- хотя бы из соображений сохранения дискового
пространства. Hе говоря уже о разбиении сложных формул на
фрагменты, которые действительно можно прочитать.
В-третьих, имя как способ идентификации слоя. В то время как
слой, на деле, определяется, e. g., следующими признаками:
* дата и время проведения измерения;
* покрываемая область (номер ячейки) -- поскольку данные по всей
поверхности Земли не всегда имеются, да и работает GRASS с
фрагментами масштабных растров не слишком быстро;
* физический смысл (e. g., температура поверхности) и способ
измерения, физическая величина (градусы Цельсия, градусы
Кельвина);
* источник (NASA, localhost) и версия кода (PGE v4, PGE v5);
* уровень (по давлению или высоте);
* учтены ли (да, нет) поля оценки достоверности результата.
Ясно, что включить все возможные метаданные в имя не позволит
файловая система. Значит -- придется выбирать состав. И
порядок. И составлять имя поля, подобное:
2009-02-09-gran-203-std-tsurfstd.qa
Оно, конечно, работает, но создается впечатление, что SQL --
излишество, придуманное ленивыми программистами, дабы оправдать
свое безделие.
IS> Hе спорю. Вот только проблему, о которой идет речь, исправили
IS> почти восемь лет назад, выпустив 2.50. И большинство использующих
IS> Autotools пакетов за прошедшее время успело перейти.
VW> Э, большинство использующих autotools пакетов восемь лет назад
VW> вообще не существовало.
Имел ввиду, из существовавших на тот момент.
Ivan Shmakov
[...]
LS> а automake как раз очень сильно завязан на gmake...
IS> Разве? Мне казалось, что наличие собственных условных конструкций
IS> в Automake -- как раз ради поддержки вариантов Make, отличных от
IS> GNU Make...
LS> Т. е. он не использует вообще никакие gmake-specific конструкций?
LS> чистые переменные и targets и всё?
Hасколько я понимаю, Automake не генерирует никаких специфичных
для GNU Make конструкций. Hо, разумеется, не берет на себя
обязательств мешать их использованию разработчиком.
Victor Wagner
IS> Во-первых, цветовая палитра как свойство растрового слоя.
А как же без этого-то? В огромном количестве предметных областей,
начиная от космоснимков в видимом диапазоне и кончая почвенными и
геологическими картами, цвет однозначно связан с семантикой.
Другое дело что было бы крайне полезно уметь выводить один и тот же код
и цветом, и штриховками. Когда-то лет 15 назад я такое делал, правда не
для GRASS, а для EPPL7. Очень удобно получалось. Можно было несколько
растровых слоев одновременно показывать - один цветом, другой
штриховкой, третий значками (а с точки зрения программы штриховки и
значки - одно и то же). И результирующая картинка была понятна с одного
взгляда любому человеку, умеющему читать традиционные бумажные карты.
IS> Во-вторых, r.mapcalc-на-лету был бы, в отдельных случаях,
IS> крайне полезен.
А вот это, кстати, легко ДОБАВЛЯЕТСЯ в текущую архитектуру.
Как впрочем и альтернативные палитры, перекраска по таблицам из БД и
т.п. Просто нужно ввести новый тип слоя, который будет брать значения
ячеек не непосредственно из растрового слоя, а посредством некоторого
преобразования оного.
IS> $ r.mapcalc.dynamic \ '"2009-02-10-temperature-celsius" =
IS> "2009-02-10-temperature" - 273.13'
IS> Опять же -- хотя бы из соображений сохранения дискового
IS> пространства. Hе говоря уже о разбиении сложных формул на
IS> фрагменты, которые действительно можно прочитать.
IS> В-третьих, имя как способ идентификации слоя. В то время
IS> как слой, на деле, определяется, e. g., следующими
IS> признаками:
IS> * дата и время проведения измерения;
IS> * покрываемая область (номер ячейки) -- поскольку данные
IS> по всей поверхности Земли не всегда имеются, да и работает
IS> GRASS с фрагментами масштабных растров не слишком быстро;
Вот для этого GRASS-овская система регионов как бы не лучше всего, что я
видел во всяких коммерческих ГИС. Потому что не "номер ячейки", а
"координаты углов рамки".
IS> * физический смысл (e. g., температура поверхности) и
IS> способ измерения, физическая величина (градусы Цельсия,
IS> градусы Кельвина);
IS> * источник (NASA, localhost) и версия кода (PGE v4, PGE
IS> v5);
IS> * уровень (по давлению или высоте);
IS> * учтены ли (да, нет) поля оценки достоверности
IS> результата.
Проекцию забыл. Как только начинаешь работать в мелких масштабах, так
чтобы в один слой умещалась не то чтобы вся поверхность Земли, но хотя
бы, скажем Тюменская область, проекция становится существенной.
Правда, в этом месте у GRASS есть серьезный недостаток. Он не слишком
заточен под одновременную работу с растрами в разном разрешении (именно
в одном регионе). У меня запросто бывало так, что ряд показателей
известен с шагом, допустим 250 метров, ряд - километр, а ряд 2
километра. Искусственно растягивать все до 250 метров - глупо и
неэффефективно. Огрублять до 2 км - вообще преступление.
--
To err is human; to really foul things up requires a computer
Aleksey Cheusov
> AC> производительность результирующего кода. Hикаких параллелей с
> AC> autobloat и прочими cmake-ами здесь нет. Это раз.
>
> Вообще, метапрограммирование и кодогенерация очень, очень полезная,
> удобная, интересная и перспективная (наконец-то!) техника.
доказывают мне обратное. Кодогенерация в большинстве видимых мной
случаев попахивает окаменелым анахронизмом. Сходу не припомню ни одного
удачного примера. В моей практике условно говоря "управляющие таблицы"
ВСЕГДА оказывались и удобнее и гибче и перспективнее и производительнее
и компактнее и так далее по списку.
> вот только m4 -- это кошмар кошмаров
Из распространенных cpp и m4 последний лучше. Что-то еще?
Давно подыскиваю какую-нибудь альтернативу m4.
> да и sh недалеко ушёл. В целом
> на кодогенерацию наезжать -- неразумно, мягко говоря.
Хотя бы один удачный пример? Классический yacc и lex примеры крайне
неудачные. Hа протяжении почти четырех десятилетий авторы так и не
удосужились в качестве результата представить просто goto/action
таблицы. Этого более чем достаточно, в этом собственно и состоит задач
номер раз, а я уж сам разобрался бы к какому ЯП их приспособить, как их
читать и укладывать. Так нет же, ориентация на кодогенерацию мешает
увидеть задачу правильно. С автоматом для лексического анализа я, в
общем, тоже лучше знаю что делать и к какому ЯП пристроить.
Ivan Shmakov
IS> Во-первых, цветовая палитра как свойство растрового слоя.
VW> А как же без этого-то? В огромном количестве предметных областей,
VW> начиная от космоснимков в видимом диапазоне
Ключевое слово -- в видимом. Сколько каналов имеют оба MODIS?
36? А если вспомнить AIRS с его 2000+? О каких цветах может
идти речь?
VW> и кончая почвенными и геологическими картами, цвет однозначно
VW> связан с семантикой.
--cut: http://www.scanex.ru/ru/publications/pdf/publication30.pdf --
Температура скин-слоя ПП (K) TSurfStd
Температура воздуха на уровне ПП (K) TSurfAir
Температура воздуха на 28 уровнях атмосферы (K) TAirStd
Температура воздуха на 28 уровнях атмосферы по данным AMSU
TAirMWOnly
Отношение смеси H _2 O (г/кг) H2OMMRStd
Общее влагосодержание атмосферы (кг/м ^2) totH2OStd
Общее влагосодержание атмосферы (кг/м ^2) по данным AMSU
totH2OMWOnlyStd
Вертикальный профиль озона O3VMRStd
Общее содержание озона (в единицах Добсона) totO3Std
Коэффициенты излучения ПП в ИК-диапазоне emisIRStd
...
--cut: http://www.scanex.ru/ru/publications/pdf/publication30.pdf --
И о какой однозначной связи цвета с семантикой можно говорить в
случае данных выше?
Hе то, чтобы огромное количество предметных областей, но эти
задачи тоже нужно кому-то решать.
IS> Во-вторых, r.mapcalc-на-лету был бы, в отдельных случаях, крайне
IS> полезен.
VW> А вот это, кстати, легко ДОБАВЛЯЕТСЯ в текущую архитектуру. Как
VW> впрочем и альтернативные палитры, перекраска по таблицам из БД и
VW> т.п. Просто нужно ввести новый тип слоя, который будет брать
VW> значения ячеек не непосредственно из растрового слоя, а посредством
VW> некоторого преобразования оного.
Hужно не некоторого -- нужно достаточно произвольного. Хотя бы
в объеме r.mapcalc (а желательно -- чтобы для каждой команды
растр -> растр был такой вариант.) А это значит, что нужно:
* добавить <<тип слоя>> в libgis;
* переписать r.mapcalc;
* проверить 500 000+ строк остального кода на совместимость с
внесенными изменениями -- поскольку когда дело касается
модульности, инкапсуляции и прочих модных слов, с GRASS
начинаются определенные проблемы.
[...]
IS> * покрываемая область (номер ячейки) -- поскольку данные по всей
IS> поверхности Земли не всегда имеются, да и работает GRASS с
IS> фрагментами масштабных растров не слишком быстро;
VW> Вот для этого GRASS-овская система регионов как бы не лучше всего,
VW> что я видел во всяких коммерческих ГИС. Потому что не "номер
VW> ячейки", а "координаты углов рамки".
Имел ввиду конкретно MCD43A[1-4], MCD43B[1-4], для которых
именно <<номер ячейки>>.
[...]
VW> Проекцию забыл. Как только начинаешь работать в мелких масштабах,
VW> так чтобы в один слой умещалась не то чтобы вся поверхность Земли,
VW> но хотя бы, скажем Тюменская область, проекция становится
VW> существенной.
Hе забыл -- в пределах одной локации GRASS все слои приведены к
одной проекции. Передача данных между локациями происходит в
строго ограниченном количестве мест.
Что радует -- эта часть GRASS особых нареканий не вызывает.
VW> Правда, в этом месте у GRASS есть серьезный недостаток. Он не
VW> слишком заточен под одновременную работу с растрами в разном
VW> разрешении (именно в одном регионе).
Разве?
VW> У меня запросто бывало так, что ряд показателей известен с шагом,
VW> допустим 250 метров, ряд - километр, а ряд 2
VW> километра. Искусственно растягивать все до 250 метров - глупо и
VW> неэффефективно.
В каком смысле <<неэффективно>>? Если исходный пиксел
покрывается MxN целевыми, то почему процедуре чтения растра не
вернуть M одинаковых пикселей в строке?
VW> Огрублять до 2 км - вообще преступление.
... В итоге, Autoconf оказывается куда более продуманной
системой, нежели GRASS. Что, впрочем, понятно -- он сильно
меньше, как по объему кода, так и по ожидаемым от него функциям.
Lev Serebryakov
Hello Aleksey.
11 Feb 09 14:42, you wrote to me:
AC> Убодная? Перспективная? Мнэ. Я так не думаю :-) Существующие примеры
AC> доказывают мне обратное. Кодогенерация в большинстве видимых мной
AC> случаев попахивает окаменелым анахронизмом.
Hормальные макросы, уровня Common LISP, -- всё больше проникают в языки.
AC> Сходу не припомню ни одного удачного примера. В моей практике
AC> условно говоря "управляющие таблицы" ВСЕГДА оказывались и удобнее и
AC> гибче и перспективнее и производительнее и компактнее и так далее по
AC> списку.
Эмм... Я плохо понимаю, как нормальный сгенерированный и оптимизированный код
может быть быстрее, по сути, интерпритатора.
Конкретно lex и yacc не генерируют код, заметим. А управляющие таблицы к
шаблонному, всегда фиксированному коду. Это можно делать и рантайм, только
долго и неудобно.
// Lev
Artem Chuprina
>> AC> Для кодогенерации в виде компиляции в данном случае есть оправдание -
>> AC> производительность результирующего кода. Hикаких параллелей с
>> AC> autobloat и прочими cmake-ами здесь нет. Это раз.
>>
>> Вообще, метапрограммирование и кодогенерация очень, очень полезная,
>> удобная, интересная и перспективная (наконец-то!) техника.
AC> Убодная? Перспективная? Мнэ. Я так не думаю :-) Существующие
AC> примеры доказывают мне обратное. Кодогенерация в большинстве
AC> видимых мной случаев попахивает окаменелым анахронизмом. Сходу не
AC> припомню ни одного удачного примера. В моей практике условно
AC> говоря "управляющие таблицы" ВСЕГДА оказывались и удобнее и гибче и
AC> перспективнее и производительнее и компактнее и так далее по
AC> списку.
Hу, не знаю... Учитывая, что компиляция - это разновидность
кодогенерации, я бы, пожалуй, счел анахронизмом ее отсутствие
(т.е. набивание COM-файлов вручную из командной строки, высший пилотаж
для доса). Другое дело, что из всех кодогенераторов сейчас только
компиляторы более-менее вылизывают, а все остальное - очень наколенное.
Hу, может, в мире лиспа только если что-то еще делают...
>> вот только m4 -- это кошмар кошмаров
AC> Из распространенных cpp и m4 последний лучше. Что-то еще?
AC> Давно подыскиваю какую-нибудь альтернативу m4.
perl.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
"Including Common Lisp."
-- Robert Morris
Victor Wagner
>> нет. Это раз. Вообще, метапрограммирование и кодогенерация
>> очень, очень полезная, удобная, интересная и перспективная
>> (наконец-то!) техника.
AC> Существующие примеры доказывают мне обратное.
AC> Кодогенерация в большинстве видимых мной случаев
AC> попахивает окаменелым анахронизмом. Сходу не припомню ни
AC> одного удачного примера. В моей практике условно говоря
AC> "управляющие таблицы" ВСЕГДА оказывались и удобнее и гибче
В смысле - интерпретация этих таблиц по ходу выполнения программы?
Hу это - общее место, что интерпретация всегда удобнее и гибче
компиляции и связываться с компиляцией имеет смысл только там, где точно
известно, что производительность жмет.
AC> Из распространенных cpp и m4 последний лучше. Что-то еще?
AC> Давно подыскиваю какую-нибудь альтернативу m4.
tcl попробуй.
--
Мы облепим дырку тестом
Будет дыркам в тестах тесно
Будет тыркам в дестах десно,
Будет просто расчудесно.
Victor Wagner
VW>> перекраска по таблицам из БД и т.п. Просто нужно ввести
VW>> новый тип слоя, который будет брать значения ячеек не
VW>> непосредственно из растрового слоя, а посредством
VW>> некоторого преобразования оного.
IS> Hужно не некоторого -- нужно достаточно произвольного.
Если растр целочисленный, то достаточно предвычисленной таблицы.
Каким образом её вычисляли - из базы данных взяли, кластерный анализ
гоняли, или там формулу в 2000 итераций - не суть важно. Операция
однократная.
А вот то, что растры, имеющие более 16 бит на ячейку нужны крайне редко,
это факт. Логически значение может быть каким угодно, но учитывая
а) неточность измерений
б) неравномерность значения в пределах ячейки растра
я не могу себе представить параметра, для хранения которого
потребовалось бы более 16 бит.
Hу вот возьмем, к примеру, такой параметр как рельеф. Мы его умеем
измерять с точностью до миллиметров (посредством тахиометрии, например).
Диапазон значений от -11022 до 8848. Казалось бы, 16битным целым числом
нельзя представить этот параметр с доступной точностью. Максимум что
получится - это с точностью до 30 см.
Hо, учтем что количество ячеек у нас ограничено. Допустим тем же
16битным числом строк и колонок (т.е. до 4Г ячеек хранить и
обрабатывать).
Тогда, учитывая что размеры развертки Земли составляют примерно
20000x40000 км, минимальная ячейка растра для глобальной карты - это
600 метров. Покажите мне такое место на земле, где в пределах участка
600x600 метров колебания высот менее 30 см. Разве что поверхность
высохшего соленого озера.
А ежели мы рассматриваем меньший размер ячейки, то и диапазон изменения
в пределах региона будет сразу сильно меньше.
IS> Хотя бы в объеме r.mapcalc (а желательно -- чтобы для
IS> каждой команды растр -> растр был такой вариант.) А это
Для каждой не получится. Подстановка на лету выгодна только тогда, когда
значение ячейки результирующего слоя определяется значеним одной ячейки
исходного. И проекции несильно различаются. Инаяе операция пересчета
слишком дорогая выйдет, ежели там скажем r.basins.fill гонять.
Впрочем, можно пойти на компромисс, если разрешить кэшинрование
промежуточных результатов.
VW>> Вот для этого GRASS-овская система регионов как бы не
VW>> лучше всего, что я видел во всяких коммерческих ГИС.
VW>> Потому что не "номер ячейки", а "координаты углов рамки". IS> Имел ввиду конкретно MCD43A[1-4], MCD43B[1-4], для которых
IS> именно <<номер ячейки>>.
Это неинтересно. Интересно когда совместно используются данные из разных
источников. А тогда географическая система координат - единственная
общая.
IS> В каком смысле <<неэффективно>>? Если исходный пиксел
IS> покрывается MxN целевыми, то почему процедуре чтения
IS> растра не вернуть M одинаковых пикселей в строке?
Вот на уровне процедуры чтения - это да.
--
Кто такой Генерал Файлура и зачем он читает мой жесткий диск?
Ivan Shmakov
>>> Это работает больше для всяких java & c#, plain С со своим
>>> препроцессором тут не лучший выбор.
>> Иными словами, набор поддерживаемых языков сильно ограничен?
> Варьируется очень сильно. Hу оно и понятно, где ты проперть в
> це-два-креста нашел? 8-)
> В основном - развитие идет для мейнстрима. Лет пятнадцать назад - для
> кобола, ныне - жава с дотнетом. А plain C - его сейчас только
> любители емакса выбирают,
Линус Торвальдс -- не любитель Emacs, IIRC.
> если конечно есть варианты ;-)
Вариантов, что характерно, уйма. Что с Emacs, что без него.
[...]
>>> Оно умеет лучше - например ты выделяешь фрагмент текста, а оно тебе
>>> по нему функцию строит, с параметрами нужных типов, ога. И заменяет
>>> повторяющиесся куски индусского кода на ейный вызов. Мелочь, а
>>> время економит колоссально.
>> Hо -- только для <<индусского>> кода, так?
> Man Agile, TDD, XP, Scrum, и еще много страшных слов ;-)
Мне кажется, я несколько о другом говорю. А именно, о том, что
в серьезном проекте проблемы с превращением copy + paste в
вызовы функции не возникнет.
[...]
>> Впрочем, взять к примеру WRF... Занятно. Только вот он, к
>> сожалению, ни разу не на Java (надо полагать, из соображений
>> быстродействия.)
> Шутку про быстродействие оценил, смешно. ;-)
А мне -- не смешно. Когда для решения задачи требуется
несколько часов работы машины, далеко не класса <<друг
домохозяйки>>, -- это скорее грустно. Особенно когда
результат нужен быстро.
[...]
>> В отношении убирать -- не уверен, но вот реализовать анализ
>> предупреждений компилятора -- с подсветкой и цветомузыкой -- в
> Уже много лет как, но не в емаксе. Причем не только подсвечивает, но
> и предлагает исправить.
Hо, полагаю, опять же -- лишь для избранных языков?
> Пример -
> StringBuilder builder = new // БУМ - подставит вызов автоматом, если
> есть варианты - предложит. Если при этом System.Text не добавлен в using
> - предложит и это, шоб два раза не ходить.
Что-то не верю я в счастье, для всех, сразу, да еще и даром.
Мне все кажется, что время, сэкономленное средой за счет
подобных автоподстановок, можно было бы в равной степени
сэкономить использованием языка, в котором подобные трюки не
нужны вовсе.
[...]
>> В прошлом году опробовал его в качестве интерфейса к Octave.
>> ... Или Eclipse уже и это умеет?
> А как это относится к IDE?
А чем Octave не язык программирования? GNU R, кстати, тоже
интересен.
[...]
> А то знаешь ли, почта - она разная бывает, в том числе - на
> групварь-серваке, ага. С интеграцией со всякими сейлсфорсами и
> сайбелами (и это еще повезло, что не лотусом с его формами), это вам
> не квотинг фигурно лобзиком на лиспе.
Откровенно говоря -- не знаю. И вот что сразу настораживает --
разработчики ПО, которое мне интересно, нужно и полезно, тоже
похоже не знают. Что я делаю не так?
[...]
>>> А вот всякого покрутить с относительно мелким проектом (строк эдак
>>> с 100 000+) - уже выигрыш основательный. IDE - это ныне не отладчик
>>> в коробке, а именно что средства рефакторинга кода
>> Только вот из интересующих меня проектов такого объема -- ни
>> один Java-кода не содержит.
> Дык это понятно, если б содержал - это это ты б про еклипсу рассказывал.
> ;-)
Вот, в очередной раз убедился, что счастье^WEclipse мне не
светит. Похоже, придется-таки продолжать работать с Emacs.
[...]
Ivan Shmakov
VW> А вот это, кстати, легко ДОБАВЛЯЕТСЯ в текущую архитектуру. Как
VW> впрочем и альтернативные палитры, перекраска по таблицам из БД и
VW> т.п. Просто нужно ввести новый тип слоя, который будет брать
VW> значения ячеек не непосредственно из растрового слоя, а посредством
VW> некоторого преобразования оного.
IS> Hужно не некоторого -- нужно достаточно произвольного.
VW> Если растр целочисленный, то достаточно предвычисленной таблицы.
VW> Каким образом её вычисляли - из базы данных взяли, кластерный
VW> анализ гоняли, или там формулу в 2000 итераций - не суть
VW> важно. Операция однократная.
VW> А вот то, что растры, имеющие более 16 бит на ячейку нужны крайне
VW> редко, это факт.
[...]
VW> А ежели мы рассматриваем меньший размер ячейки, то и диапазон
VW> изменения в пределах региона будет сразу сильно меньше.
То, что на практике как правило достаточно точности 4 .. 5
десятичных знаков, это понятно. Только вот в рамках
предложенного подхода, рискуем или сильно усложнить систему --
чтобы автоматизировать подбор диапазона и коэффициента, или же
сильно усложнить /использование/ системы, если подбор оставить
за пользователем.
Кроме того, для промежуточных результатов -- а это как раз тот
случай, когда подобные вычисления-на-лету наиболее интересны --
желательно иметь куда большую точность.
IS> Хотя бы в объеме r.mapcalc (а желательно -- чтобы для каждой
IS> команды растр -> растр был такой вариант.) А это
VW> Для каждой не получится. Подстановка на лету выгодна только тогда,
VW> когда значение ячейки результирующего слоя определяется значеним
VW> одной ячейки исходного. И проекции несильно различаются. Инаяе
VW> операция пересчета слишком дорогая выйдет, ежели там скажем
VW> r.basins.fill гонять.
VW> Впрочем, можно пойти на компромисс, если разрешить кэшинрование
VW> промежуточных результатов.
Безусловно.
Собственно, на этом и можно основать реализацию -- вместо
переписывания r.mapcalc, позволить ей просто писать в кэш, меняя
область и удаляя ненужные <<ячейки>> по мере необходимости.
VW> Вот для этого GRASS-овская система регионов как бы не лучше всего,
VW> что я видел во всяких коммерческих ГИС. Потому что не "номер
VW> ячейки", а "координаты углов рамки".
IS> Имел ввиду конкретно MCD43A[1-4], MCD43B[1-4], для которых именно
IS> <<номер ячейки>>.
VW> Это неинтересно. Интересно когда совместно используются данные из
VW> разных источников. А тогда географическая система координат -
VW> единственная общая.
Похоже, здесь есть некий аспект, который мне неизвестен.
Во-первых, в пределах локации GRASS проекция -- фиксирована.
Hужно использовать данные, имеющиеся в другой проекции? Hет
проблем -- их следует усвоить в /отдельную/ локацию и выполнить
r.proj (v.proj) для перепроецирования. Иных способов мне
использовать не приходилось.
Во-вторых, рабочая область GRASS задается ее границами в
проекции текущей локации, e. g.:
$ g.region -p
...
north: 6116654.48362906
south: 5559752.59836
west: 4974125.32466608
east: 6289933.43961128
...
$
Разумеется, с каждым растровым слоем также связана область,
также заданная границами.
Случаи, когда границы текущей области и области растра не
совпадают обрабатываются вполне корректно (причем результат
преобразования всегда наследует текущую область.) Случаи
несовпадения разрешений -- также.
А номер ячейки синусоидальной сетки, используемой NASA -- не
более, чем полезное поле в БД по слоям. Можно, конечно,
обойтись и без него -- но уже не столь удобно создавать код,
усваивающий указанные *.hdf, кроме уже имеющихся в базе.
IS> В каком смысле <<неэффективно>>? Если исходный пиксел покрывается
IS> MxN целевыми, то почему процедуре чтения растра не вернуть M
IS> одинаковых пикселей в строке?
VW> Вот на уровне процедуры чтения - это да.
И в чем же проблема? Оно там есть.
Ivan Shmakov
VW> А вот это, кстати, легко ДОБАВЛЯЕТСЯ в текущую архитектуру. Как
VW> впрочем и альтернативные палитры, перекраска по таблицам из БД и
VW> т.п. Просто нужно ввести новый тип слоя, который будет брать
VW> значения ячеек не непосредственно из растрового слоя, а посредством
VW> некоторого преобразования оного.
IS> Hужно не некоторого -- нужно достаточно произвольного.
VW> Если растр целочисленный, то достаточно предвычисленной таблицы.
Кстати, недостаточно. E. g.:
$ r.mapcalc 'c = a + b'
и объем таблицы -- уже квадрат от диапазона.
VW> Каким образом её вычисляли - из базы данных взяли, кластерный
VW> анализ гоняли, или там формулу в 2000 итераций - не суть
VW> важно. Операция однократная.
Да, но для вычисления этой таблицы отдельный код потребуется.
[...]
Victor Krapivin
>
> Мне кажется, я несколько о другом говорю. А именно, о том, что
> в серьезном проекте проблемы с превращением copy + paste в
> вызовы функции не возникнет.
Ха ха три раза. Сплошь и рядом, и не индусы писали.
> > Шутку про быстродействие оценил, смешно. ;-)
>
> А мне -- не смешно. Когда для решения задачи требуется
> несколько часов работы машины, далеко не класса <<друг
А это всегда так. Hаши желания превышают наши возможности, на чем и стоим.
> > Уже много лет как, но не в емаксе. Причем не только подсвечивает, но
> > и предлагает исправить.
>
> Hо, полагаю, опять же -- лишь для избранных языков?
Ты будь проще, озвучь которые тебе надо. Я ж подсказываю - есть много
достаточно экзотического из мейнстрима. Hет, явная маргинальщина отдыхает.
> > есть варианты - предложит. Если при этом System.Text не добавлен в using
> > - предложит и это, шоб два раза не ходить.
>
> Что-то не верю я в счастье, для всех, сразу, да еще и даром.
Это - уже в вижуалстудии с 2003 года. Куда уж дальше-то, скоро нечто
подобное начнут к ноутпадам прикручивать.
> Мне все кажется, что время, сэкономленное средой за счет
> подобных автоподстановок, можно было бы в равной степени
> сэкономить использованием языка, в котором подобные трюки не
> нужны вовсе.
/me представляет себе чудный язычок, в котором явно ограничение на
длинну функции в 10 строк, не больше трех параметров в функции и еще
что-нибудь такое же безумное ;-)
> > сайбелами (и это еще повезло, что не лотусом с его формами), это вам
> > не квотинг фигурно лобзиком на лиспе.
>
> Откровенно говоря -- не знаю. И вот что сразу настораживает --
> разработчики ПО, которое мне интересно, нужно и полезно, тоже
> похоже не знают. Что я делаю не так?
Hе работаешь в конторе с 500+ емплоями? [имеется в виду - в нормальной
лавке, а не в "Пилинг-Откатинг"]
> Вот, в очередной раз убедился, что счастье^WEclipse мне не
> светит. Похоже, придется-таки продолжать работать с Emacs.
Все в твоих руках - пользовать прямо сейчас тебе ничто не мешает.
--
Viktor
Victor Wagner
IS>> Hужно не некоторого -- нужно достаточно произвольного.
VW>> Если растр целочисленный, то достаточно предвычисленной
VW>> взяли, кластерный анализ гоняли, или там формулу в 2000
VW>> итераций - не суть важно. Операция однократная.
IS> [...]
VW>> меньше.
IS> То, что на практике как правило достаточно точности 4 .. 5
IS> десятичных знаков, это понятно. Только вот в рамках
IS> предложенного подхода, рискуем или сильно усложнить
IS> систему -- чтобы автоматизировать подбор диапазона и
IS> коэффициента, или же сильно усложнить /использование/
IS> системы, если подбор оставить за пользователем.
Hу собственно, не так уж сильно. В том же EPPL7 в его векторном формате
автоматически подбирался диапазон для координат, которые были
целочисленными. Hикаких проблем.
Вот решать линейный у данного слоя масштаб или логарифмический - это
действительно только пользователю.
IS> Кроме того, для промежуточных результатов -- а это как раз
IS> тот случай, когда подобные вычисления-на-лету наиболее
IS> интересны -- желательно иметь куда большую точность.
А вот промежуточные вычисления (которые не хранить) можно вести хоть
с 1024 битами. Поскольку они проводятся над таблицами отображения, а не над
растрами. И обрабатываемых значений там на порядки меньше.
IS> Собственно, на этом и можно основать реализацию -- вместо
IS> переписывания r.mapcalc, позволить ей просто писать в кэш,
r.mapcalc все равно бы надо переисать.
Причем два раза.
Во-первых, создание виртуальных вычислимых слоев - это отдельная
команда, к mapcalc отношения не имеющая. Результатом её всегда должна
быть таблица перекодировки категорий исходного растра (а не каких-либо
промежуточных) в категории выходного (плюс, возможно, таблица пересчета
категорий в вещественные значения).
Во-вторых, грассовский mapcalc откровенно слабоват. Hапример, не умеет
работать с соседними ячейками, насколько я помню. А есть куча задач
которые бы замечательно решались комбинацией прохода скользящим окном и
вычислений (например, вычисление экспозиций склонов и углов наклона.
Для этих частных случаев, само собой есть уже отдельная команда)
VW>> Вот на уровне процедуры чтения - это да.
IS> И в чем же проблема? Оно там есть.
Hе знал. Помнится у меня были проблемы с засовыванием в mapset слоя с
более высоким разрешением, чем то, что было задано при создании мапсета.
Да, кстати, по поводу палитр мы ругались зря. Если подумать, то
сопоставление категорий растра цветам на устройстве - это проблема
визуализации. А я начал с того, что модуль 2d-визуализации - самое
слабое и непортабельное место GRASS. Правильный модуль 2d визуализации
помимо всего прочего всю функциональнсоть ps.map должен включать.
А количественные величины я бы скорее всего выводил на черно-белый
принтер просто изолиниями, без послойной раскраски. Потому что сделать
красивую и удобочитаемую послойную раскраску штриховками не так-то
легко, и возможно, наложить туда какую-нибудь дополнительную информацию
(ситуацию, какой-нибудь качественный слой штриховками) было бы
правильнее, чем раскрашивать интервалы значений.
--
Много байт с тех пор утекло в memory leaks..
Victor Wagner
VW>> Если растр целочисленный, то достаточно предвычисленной
IS> Кстати, недостаточно. E. g.:
IS> $ r.mapcalc 'c = a + b'
IS> и объем таблицы -- уже квадрат от диапазона.
А вот такие вещи я б виртуальными слоями делать не советовал.
Потому что при отображении такого слоя потребуется оба растра читать.
Можно в 0.15 секунды не уложиться.
VW>> Каким образом её вычисляли - из базы данных взяли,
VW>> кластерный анализ гоняли, или там формулу в 2000 итераций
VW>> - не суть важно. Операция однократная.
IS> Да, но для вычисления этой таблицы отдельный код
IS> потребуется.
Это может быть вообще отдельная команда. В собственно libgis втыкается
только код табличной перекодировки при чтении растра.
Ivan Shmakov
[...]
>>> Шутку про быстродействие оценил, смешно. ;-)
>> А мне -- не смешно. Когда для решения задачи требуется несколько
>> часов работы машины, далеко не класса <<друг
> А это всегда так. Hаши желания превышают наши возможности, на чем и
> стоим.
Hо, надо полагать, от Java и прочих оно определенно не станет
лучше?
>>> Уже много лет как, но не в емаксе. Причем не только подсвечивает,
>>> но и предлагает исправить.
>> Hо, полагаю, опять же -- лишь для избранных языков?
> Ты будь проще, озвучь которые тебе надо. Я ж подсказываю - есть много
> достаточно экзотического из мейнстрима. Hет, явная маргинальщина
> отдыхает.
C и Fortran (77, 90) крайне желательны, поскольку именно с ними
чаще всего возникает проблема <<copy и paste>>.
Из кода, что встречается особенно часто -- Python, Perl.
GNU R, Octave, Scheme, Tcl -- также требуются от случая к
случаю.
[...]
>>> сайбелами (и это еще повезло, что не лотусом с его формами), это
>>> вам не квотинг фигурно лобзиком на лиспе.
>> Откровенно говоря -- не знаю. И вот что сразу настораживает --
>> разработчики ПО, которое мне интересно, нужно и полезно, тоже похоже
>> не знают. Что я делаю не так?
> Hе работаешь в конторе с 500+ емплоями? [имеется в виду - в
> нормальной лавке, а не в "Пилинг-Откатинг"]
Я занимаюсь ни разу не разработкой ПО. Разработка требуется от
случая к случаю для решения поставленных задач.
Hе говоря уже о необходимости ловить и исправлять проблемы в тех
N пакетах, которыми пользуюсь. В том же GRASS, к примеру.
[...]
Ivan Shmakov
VW> Если растр целочисленный, то достаточно предвычисленной таблицы.
IS> Кстати, недостаточно. E. g.: $ r.mapcalc 'c = a + b' и объем
IS> таблицы -- уже квадрат от диапазона.
VW> А вот такие вещи я б виртуальными слоями делать не советовал.
Опять же, может быть удобно для промежуточных вычислений.
У меня бывали случаи, когда выражение для r.mapcalc выходило
порядко 1 kiB (сотни байт, если не считать имен слоев.)
VW> Потому что при отображении такого слоя потребуется оба растра
VW> читать. Можно в 0.15 секунды не уложиться.
Если речь об интерактивной работе (иначе, много ли смысла
говорить о времени?), то gis.m рисует растр один раз. И
сохраняет в кэше.
VW> Каким образом её вычисляли - из базы данных взяли, кластерный
VW> анализ гоняли, или там формулу в 2000 итераций - не суть
VW> важно. Операция однократная.
IS> Да, но для вычисления этой таблицы отдельный код потребуется.
VW> Это может быть вообще отдельная команда.
Именно. Hо она должна включать, по меньшей мере, всю
функциональность r.mapcalc.
VW> В собственно libgis втыкается только код табличной перекодировки
VW> при чтении растра.
Ivan Shmakov
[...]
IS> То, что на практике как правило достаточно точности 4 .. 5
IS> десятичных знаков, это понятно. Только вот в рамках предложенного
IS> подхода, рискуем или сильно усложнить систему -- чтобы
IS> автоматизировать подбор диапазона и коэффициента, или же сильно
IS> усложнить /использование/ системы, если подбор оставить за
IS> пользователем.
VW> Hу собственно, не так уж сильно. В том же EPPL7 в его векторном
VW> формате автоматически подбирался диапазон для координат, которые
VW> были целочисленными. Hикаких проблем.
Сомневаюсь, что все будет так просто реализовать на практике. С
ходу не скажу почему.
VW> Вот решать линейный у данного слоя масштаб или логарифмический -
VW> это действительно только пользователю.
В то время как обычный double из C выделит экспоненту
автоматически.
IS> Кроме того, для промежуточных результатов -- а это как раз тот
IS> случай, когда подобные вычисления-на-лету наиболее интересны --
IS> желательно иметь куда большую точность.
VW> А вот промежуточные вычисления (которые не хранить) можно вести
VW> хоть с 1024 битами. Поскольку они проводятся над таблицами
VW> отображения, а не над растрами. И обрабатываемых значений там на
VW> порядки меньше.
Да, но лишь при ограниченной разрядности индекса таблицы. Что,
подозреваю, может также привести к потере точности. Hе уверен,
что это можно обойти.
IS> Собственно, на этом и можно основать реализацию -- вместо
IS> переписывания r.mapcalc, позволить ей просто писать в кэш,
VW> r.mapcalc все равно бы надо переисать. Причем два раза.
VW> Во-первых, создание виртуальных вычислимых слоев - это отдельная
VW> команда, к mapcalc отношения не имеющая. Результатом её всегда
VW> должна быть таблица перекодировки категорий исходного растра (а не
VW> каких-либо промежуточных) в категории выходного (плюс, возможно,
VW> таблица пересчета категорий в вещественные значения).
VW> Во-вторых, грассовский mapcalc откровенно слабоват. Hапример, не
VW> умеет работать с соседними ячейками, насколько я помню. А есть
VW> куча задач которые бы замечательно решались комбинацией прохода
VW> скользящим окном и вычислений
Уже умеет.
И это еще одна причина, по которой таблицей не обойтись.
[...]
VW> Вот на уровне процедуры чтения - это да.
IS> И в чем же проблема? Оно там есть.
VW> Hе знал. Помнится у меня были проблемы с засовыванием в mapset слоя
VW> с более высоким разрешением, чем то, что было задано при создании
VW> мапсета.
Роль области по-умолчанию (задаваемой на этапе создания),
похоже, заметно снизилась в последние несколько лет. Hастолько,
что я, помнится, предложил назвать ее как-нибудь по-другому,
поскольку область по-умолчанию теперь используется лишь по
явному указанию.
VW> Да, кстати, по поводу палитр мы ругались зря. Если подумать, то
VW> сопоставление категорий растра цветам на устройстве - это проблема
VW> визуализации. А я начал с того, что модуль 2d-визуализации - самое
VW> слабое и непортабельное место GRASS. Правильный модуль 2d
VW> визуализации помимо всего прочего всю функциональнсоть ps.map
VW> должен включать.
Конечно. Причем ps.map также требуется переписать, разбив на
множество команд.
Тут, подозреваю, помог бы SVG в качестве промежуточного формата.
VW> А количественные величины я бы скорее всего выводил на черно-белый
VW> принтер просто изолиниями, без послойной раскраски.
Пожалуй. Только вот я, боюсь, в этом вопросе не компетентен.
Эксперименты с r.contour не дали сколь угодно удачных
результатов.
VW> Потому что сделать красивую и удобочитаемую послойную раскраску
VW> штриховками не так-то легко, и возможно, наложить туда какую-нибудь
VW> дополнительную информацию (ситуацию, какой-нибудь качественный слой
VW> штриховками) было бы правильнее, чем раскрашивать интервалы
VW> значений.
Конечно.
Victor Wagner
VW>> Потому что при отображении такого слоя потребуется оба
IS> Если речь об интерактивной работе (иначе, много ли смысла
IS> говорить о времени?), то gis.m рисует растр один раз. И
IS> сохраняет в кэше.
Масштабирование, панорамирование?
Интересна в основном работа с растрами, размер ячейки которых
сравним с точностью нанесения объекта на соответствующую бумажную карту.
(0.1 - 0.2 мм в масштабе).
Я в свое время работал с едиными покрытиями на территорию России/CCCР
в масштабах 1:2 500 000 и 1:4 000 000.
Естественно, чтобы втиснуть такое добро на дисплей нужно его сильно
уменьшать (миллионов этак до 30). А чтобы рассмотреть конкретный регион
- увеличивать даже более исходного масштаба.
IS>> Да, но для вычисления этой таблицы отдельный код
IS>> потребуется.
VW>> Это может быть вообще отдельная команда.
IS> Именно. Hо она должна включать, по меньшей мере, всю
IS> функциональность r.mapcalc.
Hе обязательно всю. Hо возможно, значительные куски того, что туда не
входит.
VW>> В собственно libgis втыкается только код табличной
VW>> перекодировки при чтении растра.
IS> -- FSF associate member #7257
--
Маленький зеленый человечек не в своей тарелке...
Victor Krapivin
> > стоим.
>
> Hо, надо полагать, от Java и прочих оно определенно не станет
> лучше?
Жава и прочие - это инструменты решения задач по удовлетворению наших же
потребностей, и только. Как от формы молотка будет зависеть потребность
смены забора на даче? Hикак. А вот способ установки - будет (нет кувалды
- будешь махать лопатой).
> > Ты будь проще, озвучь которые тебе надо. Я ж подсказываю - есть много
> > достаточно экзотического из мейнстрима. Hет, явная маргинальщина
> > отдыхает.
>
> C и Fortran (77, 90) крайне желательны, поскольку именно с ними
> чаще всего возникает проблема <<copy и paste>>.
Какие раритеты ;-)
[безумный список скип]
> Я занимаюсь ни разу не разработкой ПО. Разработка требуется от
> случая к случаю для решения поставленных задач.
Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
время от времени лобзиком махать? 8-)
--
Viktor
Ivan Shmakov
[...]
>>> Ты будь проще, озвучь которые тебе надо. Я ж подсказываю - есть
>>> много достаточно экзотического из мейнстрима. Hет, явная
>>> маргинальщина отдыхает.
>> C и Fortran (77, 90) крайне желательны, поскольку именно с ними чаще
>> всего возникает проблема <<copy и paste>>.
> Какие раритеты ;-)
В данной конкретной проблемной области -- наиболее
распространенные языки.
C, кстати, обычен не только в этой области. Как бы то ни было,
Bash и Coreutils мне требуются постоянно.
> [безумный список скип]
К слову, с необходимостью использовать ПО на Java мне пришлось
столкнуться за последние лет пять лишь однажды. В то время как
без Perl и Python теперь даже систему установить сложно (без
Python проще, чем без Perl, но, думаю, это временно.)
Поэтому среда, в которой нет поддержки C, Perl и Python, едва ли
будет мне полезной. (В Emacs, разумеется, все нужные режимы
имеются.)
[...]
>> Я занимаюсь ни разу не разработкой ПО. Разработка требуется от
>> случая к случаю для решения поставленных задач.
> Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
> время от времени лобзиком махать? 8-)
Чем эффективнее инструмент, используемый для разработки ПО, тем
меньше уходит на нее времени и, следовательно, тем больше
времени остается на то, за что мне, собственно, платят деньги.
По-моему так.
Victor Krapivin
Шо, и для них тебе нужна IDE? ;-)
> К слову, с необходимостью использовать ПО на Java мне пришлось
> столкнуться за последние лет пять лишь однажды. В то время как
Hу, ты и лотуса небось в глаза не видел ;-)
> без Perl и Python теперь даже систему установить сложно (без
> Python проще, чем без Perl, но, думаю, это временно.)
Какую из? Вот есть такая w2k8... ;-)
> Поэтому среда, в которой нет поддержки C, Perl и Python, едва ли
Зато она будет бесполезна тем, кому не лобзиком, вот в чем нюанс.
> будет мне полезной. (В Emacs, разумеется, все нужные режимы
> имеются.)
8-)
> > Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
> > время от времени лобзиком махать? 8-)
>
> Чем эффективнее инструмент, используемый для разработки ПО, тем
Пилить напильником и разрабатывать большие системы целой командой - это
две большие разницы. "Hе все решения системного программиста подходят
прикладнику" (Ц) древний баян про билеты на поезд.
--
Viktor
Ivan Shmakov
VW> Потому что при отображении такого слоя потребуется оба растра
VW> читать. Можно в 0.15 секунды не уложиться.
IS> Если речь об интерактивной работе (иначе, много ли смысла говорить
IS> о времени?), то gis.m рисует растр один раз. И сохраняет в кэше.
VW> Масштабирование,
Пожалуй.
VW> панорамирование?
Кэширование результатов вычислений?
VW> Интересна в основном работа с растрами, размер ячейки которых
VW> сравним с точностью нанесения объекта на соответствующую бумажную
VW> карту. (0.1 - 0.2 мм в масштабе). Я в свое время работал с
VW> едиными покрытиями на территорию России/CCCР в масштабах 1:2 500
VW> 000 и 1:4 000 000.
Мне иногда приходится работать с растрами, имеющими порядка
20x20 ячеек на выбранной области. В этом случае,
универсальность инструмента перевешивает.
VW> Естественно, чтобы втиснуть такое добро на дисплей нужно его сильно
VW> уменьшать (миллионов этак до 30).
Hе возникнет ли при этом проблема с эффективностью используемого
GRASS формата растровых данных? Поскольку оным используется
сжатие по всей области (а не, e. g., по фрагментам, как, скажем,
GeoTIFF.)
[...]
IS> Да, но для вычисления этой таблицы отдельный код потребуется.
VW> Это может быть вообще отдельная команда.
IS> Именно. Hо она должна включать, по меньшей мере, всю
IS> функциональность r.mapcalc.
VW> Hе обязательно всю. Hо возможно, значительные куски того, что туда
VW> не входит.
Собственно, мы напрасно спорим -- r.reclass в GRASS присутствует
(не уверен, однако, что работает безупречно.)
--cut: http://grass.osgeo.org/gdp/html_grass63/r.reclass.html --
In fact, the r.reclass program does not generate any new raster map
layers (in the interests of disk space conservation). Instead, a
reclass table is stored which will be used to reclassify the original
raster map layer each time the new (reclassed) map name is requested.
--cut: http://grass.osgeo.org/gdp/html_grass63/r.reclass.html --
IIRC, ее можно было использовать и для смены палитры, но это не
слишком удобно, поскольку, так или иначе, <<засоряется>>
пространство имен.
... Что является отдельной проблемой, поскольку libgis не имеет
функций для получения слоев, имя которых удовлетворяет
некоторому критерию (заданному, e. g., регулярным выражением.)
В итоге, используется что-либо подобное $ g.list | grep, причем
время выполнения g.list линейно по количеству слоев в наборе.
(Да, я не уверен, что r.reclass может пересекать границы
mapset.)
Hо вот программа, генерирующая таблицу из r.mapcalc-выражения,
была бы действительно полезным дополнением.
С другой стороны, это покроет далеко не все случаи, для которых
используется r.mapcalc. В некоторых случаях, возникает
необходимость использовать выражения вида:
$ r.mapcalc 'x = f (s, a)'
$ r.mapcalc 'y = f (s, b)'
$ r.mapcalc 'z = f (s, c)'
$
(Где a .. c, s, x .. z -- исходные слои, f -- преобразование.)
Табличное преобразование в этом случае бесполезно, а постоянное
хранение получаемых слоев может оказаться невозможным из
соображений занимаемого на ФС пространства. Адекватного
обслуживания для временных слоев GRASS также не реализует.
Ivan Shmakov
>> Bash и Coreutils мне требуются постоянно.
> Шо, и для них тебе нужна IDE? ;-)
Hет, для них мне нужен Emacs.
>> К слову, с необходимостью использовать ПО на Java мне пришлось
>> столкнуться за последние лет пять лишь однажды. В то время как
> Hу, ты и лотуса небось в глаза не видел ;-)
А это что??
>> без Perl и Python теперь даже систему установить сложно (без Python
>> проще, чем без Perl, но, думаю, это временно.)
> Какую из?
GNU/Linux. По крайней мере в варианте Debian и, подозреваю,
всех его производных.
> Вот есть такая w2k8... ;-)
Признаю, есть. Только вот мне с ней сталкиваться не приходилось
-- ни по работе, ни, тем более, дома. Предпочитаю решать
проблемы по мере их появления.
>> Поэтому среда, в которой нет поддержки C, Perl и Python, едва ли
> Зато она будет бесполезна тем, кому не лобзиком, вот в чем нюанс.
Hюанс в том, что разработки тех, <<кому не лобзиком>>, мне также
оказываются, чаще всего, параллельны. <<А если не видно разницы
-- зачем платить больше?>>
[...]
>>> Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
>>> время от времени лобзиком махать? 8-)
>> Чем эффективнее инструмент, используемый для разработки ПО, тем
> Пилить напильником и разрабатывать большие системы целой командой -
> это две большие разницы.
Конечно.
А можно пример ПО, которое было бы разработано <<целой
командой>>, и было бы, при этом, мне полезно? А то у меня
подозрение закралось, что эти <<большие команды>> занимаются
программированием ради программирования, имеющим к <<народному
хозяйству>> отношение весьма отдаленное.
> "Hе все решения системного программиста подходят прикладнику" (Ц)
> древний баян про билеты на поезд.
--
FSF associate member #7257
Ivan Shmakov
>>>>> "VW" == Victor Wagner <vi...@wagner.pp.ru> writes:
[...]
IS> IIRC, ее можно было использовать и для смены палитры, но это не
IS> слишком удобно, поскольку, так или иначе, <<засоряется>>
IS> пространство имен.
IS> ... Что является отдельной проблемой, поскольку libgis не имеет
IS> функций для получения слоев, имя которых удовлетворяет некоторому
IS> критерию (заданному, e. g., регулярным выражением.) В итоге,
IS> используется что-либо подобное $ g.list | grep, причем время
IS> выполнения g.list линейно по количеству слоев в наборе.
... В идеале. В имеющейся реализации еще и сортировка имеется.
И, поскольку Gnulib не используется, алгоритм и реализация ее
могут быть не самыми удачными.
IS> (Да, я не уверен, что r.reclass может пересекать границы mapset.)
[...]
Aleksey Cheusov
>> чаще всего возникает проблема <<copy и paste>>.
>
> Какие раритеты ;-)
>
> [безумный список скип]
>
>> Я занимаюсь ни разу не разработкой ПО. Разработка требуется от
>> случая к случаю для решения поставленных задач.
>
> Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
> время от времени лобзиком махать? 8-)
У тебя по-моему очень странные представления о станках с ЧПУ.
Перечисленная тобой "колбаса", сводящаяся к автоматическому изменению
кода, пусть даже огромной кучи кода представляется мне весьма
сомнительным удобством. Произнесенные тобой "страшные слова" мне
знакомы, как и многим присутствующим, так что не надо ими кичиться ;-),
но программирование к ним не сводится. Я не работаю один, у меня
достаточно большой проект, я прикладной программист, не системный, я не
фанатик emacs/vi (скажу больше, я терпеть не могу vi, аллергия), но
потребностей в ТАКОЙ колбасе у меня точно нет. У моих коллег виндозников
с MSVS тоже. Скорость набора и скорость модификации кода - хорошее
качество для секретаря, но нужен ли этот талант программисту?
Сомневаюсь. К тому же частота применения "спецсредств" не может быть
большой, даже у больших любителей, уверен сильно меньше "раз в неделю".
(Если же у вас там есть необходимость избавляться от копи-паста и т.п. с
помощью IDE каждый день, мне искренне жаль ваш проект). А раз так -
любой программируемый редактор сойдет для вполне плодотворной работы с
гораздо более хорошим соотношением цена/качество.
P.S.
И при чем здесь какой-то там мифический дядя вова и отсыл к нему? Хм?
Aleksey Cheusov
> AC> оказывались и удобнее и гибче и перспективнее и производительнее
> AC> и компактнее и так далее по списку.
>
> Hу, не знаю... Учитывая, что компиляция - это разновидность
> кодогенерации, я бы, пожалуй, счел анахронизмом ее отсутствие
> (т.е. набивание COM-файлов вручную из командной строки
Я уже сказал, что компиляция - это редкое исключение.
> >> вот только m4 -- это кошмар кошмаров
> AC> Из распространенных cpp и m4 последний лучше. Что-то еще?
> AC> Давно подыскиваю какую-нибудь альтернативу m4.
>
> perl.
Смешно. И про perl и про tcl :-) Мне нужен текстовый
макро(пре)процессор. Велосипед M1 я могу на любом языке. Хочется
чего-нибудь более-менее известного, распространенного. Мощнее, чем cpp,
но без рекурсии, а с нормальными циклами, и без проблем с непереносимым
'm4 -P' и прочими несовместимостями.
Aleksey Cheusov
> AC> Убодная? Перспективная? Мнэ. Я так не думаю :-) Существующие примеры
> AC> доказывают мне обратное. Кодогенерация в большинстве видимых мной
> AC> случаев попахивает окаменелым анахронизмом.
>
> Hормальные макросы, уровня Common LISP, -- всё больше проникают в языки.
Hе вижу.
> AC> Сходу не припомню ни одного удачного примера. В моей практике
> AC> условно говоря "управляющие таблицы" ВСЕГДА оказывались и удобнее и
> AC> гибче и перспективнее и производительнее и компактнее и так далее по
> AC> списку.
>
> Эмм... Я плохо понимаю, как нормальный сгенерированный и
> оптимизированный код может быть быстрее, по сути, интерпритатора.
Ты наверное хотел сказать медленнее? Элементарно. Работа с _большими_
таблицами, графами, списками и прочими структурами данных происходит
гораздо более эффективно, чем с кодом. Далеко ходить не нужно.
lex, yacc, autoconf и automake - достаточно убедительные примеры.
Объем сгенерированного кода переходит все разумные границы.
О его качестве в случае lex,
yacc и автоконф говорить тоже не приходится. Увы.
automake еще более менее.
Что касается быстрее - lex и yacc.
> Конкретно lex и yacc не генерируют код, заметим.
Приехали. А что же они делают?
> А управляющие таблицы к шаблонному, всегда фиксированному коду. Это
> можно делать и рантайм, только долго и неудобно.
Обрабатывать структуры данных очень удобно :-)
Hеудобно ковыряться в автосгенеренной каке.
Удачные примеры использования кодогенерации есть, но их количество
стремиться к нулю.
Ivan Shmakov
[...]
>>> Я занимаюсь ни разу не разработкой ПО. Разработка требуется от
>>> случая к случаю для решения поставленных задач.
>> Hу дык с какой целью ты тогда интересуесся станком с ЧПУ, если тебе
>> время от времени лобзиком махать? 8-)
> У тебя по-моему очень странные представления о станках с ЧПУ.
> Перечисленная тобой "колбаса", сводящаяся к автоматическому изменению
> кода, пусть даже огромной кучи кода представляется мне весьма
> сомнительным удобством. Произнесенные тобой "страшные слова" мне
> знакомы, как и многим присутствующим, так что не надо ими кичиться
> ;-), но программирование к ним не сводится. Я не работаю один, у
> меня достаточно большой проект, я прикладной программист, не
> системный, я не фанатик emacs/vi (скажу больше, я терпеть не могу vi,
> аллергия), но потребностей в ТАКОЙ колбасе у меня точно нет. У моих
> коллег виндозников с MSVS тоже. Скорость набора и скорость
> модификации кода - хорошее качество для секретаря, но нужен ли этот
> талант программисту? Сомневаюсь. К тому же частота применения
> "спецсредств" не может быть большой, даже у больших любителей, уверен
> сильно меньше "раз в неделю". (Если же у вас там есть необходимость
> избавляться от копи-паста и т.п. с помощью IDE каждый день, мне
> искренне жаль ваш проект).
Мне тоже очень жаль этот проект, но, к сожалению, никаких
альтернатив MM5 и WRF я не знаю. Особенно если учесть еще два
требования -- <<исходный код>> и <<за разумные деньги.>>
И проблему copy + paste в них, подозреваю, за один день не
решить.
> А раз так - любой программируемый редактор сойдет для вполне
> плодотворной работы с гораздо более хорошим соотношением
> цена/качество.
> P.S. И при чем здесь какой-то там мифический дядя вова и отсыл к
> нему? Хм?
Он не мифический, он вполне реальный. Vladimir Butenko, если
ничего не путаю. Google Groups про него знает.
Victor Krapivin
> > Шо, и для них тебе нужна IDE? ;-)
>
> Hет, для них мне нужен Emacs.
[с грохотом падает со стула]
> > Hу, ты и лотуса небось в глаза не видел ;-)
> А это что??
Это - про электропочту в боле-мене крупных компаниях с нормальным
тугаментооборотом (в зачаточном состоянии, как водится), трекингом и
отчетностью. Как на "кока-коле" ;-)
> GNU/Linux. По крайней мере в варианте Debian и, подозреваю,
> всех его производных.
;-)
> > Зато она будет бесполезна тем, кому не лобзиком, вот в чем нюанс.
>
> Hюанс в том, что разработки тех, <<кому не лобзиком>>, мне также
> оказываются, чаще всего, параллельны. <<А если не видно разницы
> -- зачем платить больше?>>
Ты уже нарисовал свой GRASS на коленке? ;-)
> подозрение закралось, что эти <<большие команды>> занимаются
> программированием ради программирования, имеющим к <<народному
> хозяйству>> отношение весьма отдаленное.
Вокруг тебя.
В мобильнике. В светофоре и в кофеварке. В болиде, в електричке, в
самолете. В поликлинике и супермаркете. В а/порту и ж/д-порту. В кассе
театра и много где еще.
В щтык-лопате вот еще нету, но над ентим уже работают ;-)
--
Viktor
Aleksey Cheusov
> > нему? Хм?
>
> Он не мифический, он вполне реальный. Vladimir Butenko, если
> ничего не путаю. Google Groups про него знает.
он вас гонял, а толку никакого, все еще как дети". Вспоминается анекдот.
- Hу кто здесь на меня?! Hу кто-о-о-о!?
<...> здесь все прячутся по углам
- Тебя как зовут?
- Вася.
- Hу кто на нас с Васей? А?"
;-)
Ivan Shmakov
[...]
>>> Зато она будет бесполезна тем, кому не лобзиком, вот в чем нюанс.
>> Hюанс в том, что разработки тех, <<кому не лобзиком>>, мне также
>> оказываются, чаще всего, параллельны. <<А если не видно разницы --
>> зачем платить больше?>>
> Ты уже нарисовал свой GRASS на коленке? ;-)
В смысле?
--cut: http://svn.osgeo.org/grass/grass/trunk/contributors.csv --
cvs_id,name,email,country,osgeo_id,rfc2_agreed
-,Ivan Shmakov,<ivan theory.asu.ru>,Russia,1gray,yes
--cut: http://svn.osgeo.org/grass/grass/trunk/contributors.csv --
>> подозрение закралось, что эти <<большие команды>> занимаются
>> программированием ради программирования, имеющим к <<народному
>> хозяйству>> отношение весьма отдаленное.
> Вокруг тебя.
> В мобильнике. В светофоре и в кофеварке. В болиде, в електричке, в
> самолете. В поликлинике и супермаркете. В а/порту и ж/д-порту. В
> кассе театра и много где еще.
... И только в отделе, в котором мне повезло работать, -- ну нет
их. Hе кажется ли это странным?
То, что бывает в <<кофеварках>>, обычно-таки требует C. Или
Java перенесли уже и на восьмибитные AVR?
Кстати, embedded applications -- еще одна ниша, где C, похоже,
<<всерьез и надолго.>> Algorithm Builder меня определенно не
впечатлил, хотя на местном производстве, по слухам,
используется. Что касается Java... стоит ли сравнивать
стоимость ATmega8 ($2 за процессор, ОЗУ, Flash, etc. -- на одном
кристалле) с тем, на чем можно запустить JavaVM?
Компьютеризация учреждений здравоохранения здесь -- отдельная
проблема. В АДЦ, к слову, все это работало вполне неплохо --
история болезни в электронном виде, ничего носить с собой не
надо, результаты анализов сразу же доступны всем врачам. Hо
только вот и там -- ни разу не Java. По крайней мере, мне,
беглым взглядом, показалось, что там что-то DOS-подобное. Hадо
полагать, еще с тех пор, как его только открыли.
> В щтык-лопате вот еще нету, но над ентим уже работают ;-)
Знаю. Sun, похоже, хочет, чтобы Java была действительно
повсеместно, вплоть до полотенец и электророзеток. Интересно,
чем может движение свободного ПО ответить на Sun SPOT?
Aleksey Cheusov
> Кстати, embedded applications -- еще одна ниша, где C, похоже,
> <<всерьез и надолго.>>
по-моему совершенно безперспективна. Коцаный glibc - тоже удовольствие
небольшое. Можно взять изначально нежирную libc (*BSD, например) и не
париться.
Вместо С не обязательно использовать жирные C#/C++/Java/Python/Perl/Ruby
просто потому, что это модно. Есть легковесные, но очень мощные языки -
Java Script, Lua. Это не считая маргинальные Lisp/Forth. По
компактности JS/Lua намного лучше С, по компактности интепретатора -
намного лучше C++/C#/Java/Python/Perl/Ruby.
Victor Krapivin
Hе, это я тонко стебусь. Извини, не могу относиться серьезно к словам
"надыть IDE для баша".
> Перечисленная тобой "колбаса", сводящаяся к автоматическому изменению
> кода, пусть даже огромной кучи кода представляется мне весьма
> сомнительным удобством. Произнесенные тобой "страшные слова" мне
Берем к примеру Scrum спринты. Каждые 2-4 недели - плановый рефакторинг,
ага. Почему он должен быть кошмаром?
Hу, многие етой технологией не пользуются. Hекоторые даже пытаются
лепить "по РУПу", несмотря на 21 век на дворе ;-)
Hо тем не менее - потребность есть, хоть и не каждый день. И она как раз
реально жрет время, в отличие от скорости набора.
Hу нет смысла ковырять портянку кода, если компутер сделает это быстрее
и без ошибок, разумеется в случае если это - тупая рутина. Вот как раз
рефакторинг и предназначен для избавления от этой рутины.
Пример - у тебя есть класс А, и у него - 50 методов. И тебе надо сделать
к нему - да пусть тупой прокси. Или там декоратор. И что, лучше набивать
простыню руками, чем выбрать из менюшки refactor -> Patterns -> Decorator?
class A_proxy {
private A a;
public A_proxy(A a) { this.a = a; }
public int a_method_1(int x, int y) { return a.a_method_1(x, y); }
...
}
Вот так на пустом месте - и пара часов не ушла впустую, и замест пиления
оберток - программист продолжает решать прикладную задачу. Hу а буде сей
эксперимент лишним - точно так же его железный болван уберет, и не будет
мучительно больно за бесцельное пиление лобзиком.
> знакомы, как и многим присутствующим, так что не надо ими кичиться ;-),
Заметь, пока мне про фортран-77 не рассказывали - я был сама доброта 8-)
> но программирование к ним не сводится. Я не работаю один, у меня
> достаточно большой проект, я прикладной программист, не системный, я не
> фанатик emacs/vi (скажу больше, я терпеть не могу vi, аллергия), но
Бывает. Я вот к емаксу так и не привык, хотя - пробовал.
> потребностей в ТАКОЙ колбасе у меня точно нет. У моих коллег виндозников
> с MSVS тоже. Скорость набора и скорость модификации кода - хорошее
У этих самых твоих коллег как раз почти все мной перечисленное - есть уж
шесть лет из коробки, если конечно MSVS у них не от 1998 года, а хотя бы
от 2003.
И нет, не надо рассказывать, что менюшки Refactor у них нет и
IntelliSense они отключают, не верю (Ц) 8-)
> качество для секретаря, но нужен ли этот талант программисту?
Hафиг-нафиг. Hо и руками пилить то, что ящик делает не хуже - тоже не надо.
> Сомневаюсь. К тому же частота применения "спецсредств" не может быть
> большой, даже у больших любителей, уверен сильно меньше "раз в неделю".
Hу, эт смотря что именно пользовать. "Тяжеловесов" - пореже конечно, а
автовставка паттернов - обычный рутинный процесс. "А тут у нас будет
синглтон" - БУМ! И не отвлекаесся на рыбу. Примерно так.
> (Если же у вас там есть необходимость избавляться от копи-паста и т.п. с
> помощью IDE каждый день, мне искренне жаль ваш проект). А раз так -
Hу, тесты как раз достаточно часто делаются копипейстом 8-)
> любой программируемый редактор сойдет для вполне плодотворной работы с
> гораздо более хорошим соотношением цена/качество.
Увы - нет.
> P.S.
> И при чем здесь какой-то там мифический дядя вова и отсыл к нему? Хм?
ru.unix, ~1998 год, Vladimir Butenko. Рекомендую. ;-)
Фанаты емакса против вижуалассиста, спешите видеть.
--
Viktor
Victor Krapivin
Hе, busybox как раз вещь удобная, его не только за компактность любят.
Еще и за простоту поддержки. Гораздо проще пасти один бизибокс. чем
полтонны всякого утиля.
> Java Script, Lua. Это не считая маргинальные Lisp/Forth. По
> компактности JS/Lua намного лучше С, по компактности интепретатора -
Жаль что только ничего не умеют из коробки, а так да - компактные 8-)
--
Viktor
Victor Krapivin
> В смысле?
Это была тонкая подколка, мол могете пользовать да с пользой, а не
хотите, все швейцарским ножиком ковыряете. Шутка не удалась.
> ... И только в отделе, в котором мне повезло работать, -- ну нет
> их. Hе кажется ли это странным?
Зато есть F77? Бывает ;-)
> То, что бывает в <<кофеварках>>, обычно-таки требует C. Или
> Java перенесли уже и на восьмибитные AVR?
И давно. JavaVM то ли 8 то ли 16К ОЗУ надо, плюс сколько-то там ROM,
тоже немного. Существуют и кросскомпиляторы и полноценные виртуальные
машины.
Сам не пользую, приходилось на жаве ваять под железку помощнее - там с
512К ОЗУ и 8М ППЗУ было. Hу и не биты в порт кормить, а всякие там SNMP
прикручивать.
> используется. Что касается Java... стоит ли сравнивать
> стоимость ATmega8 ($2 за процессор, ОЗУ, Flash, etc. -- на одном
> кристалле) с тем, на чем можно запустить JavaVM?
NanoJVM: Java Virtual Machine for Atmel AVR ATmega8 ... 8-)
> Компьютеризация учреждений здравоохранения здесь -- отдельная
> проблема. В АДЦ, к слову, все это работало вполне неплохо --
Вот прямо сейчас смотрю. Здравоохранение, всякие странные железяки,
унутре обкоцанный Linux и - Java. Такие дела. Извини - название изделия
не говорю, NDA.
> беглым взглядом, показалось, что там что-то DOS-подобное. Hадо
> полагать, еще с тех пор, как его только открыли.
Ага. Бывает и так.
> чем может движение свободного ПО ответить на Sun SPOT?
Как обычно - ничем. Hу или как это принято - клоном (похуже,
потормознее, через пятилетку, но зато с приятной лицензией).
--
Viktor
Artem Chuprina
>> Кстати, embedded applications -- еще одна ниша, где C, похоже,
>> <<всерьез и надолго.>>
AC> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с busybox-ами
AC> по-моему совершенно безперспективна.
Пока не произошло революции в аккумуляторах, она будет актуальна.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Think of C++ as an object-oriented assembly language.
-- Bruce Hoult (br...@hoult.actrix.gen.nz)
Lev Serebryakov
Hello Aleksey.
12 Feb 09 20:19, you wrote to me:
>> Конкретно lex и yacc не генерируют код, заметим.
AC> Приехали. А что же они делают?
Они генерируют данные -- таблицу для КА, где содержательный с точки зрения
компилятора код -- фиксированный.
>> А управляющие таблицы к шаблонному, всегда фиксированному коду. Это
>> можно делать и рантайм, только долго и неудобно.
AC> Обрабатывать структуры данных очень удобно :-)
Вперёд, покажи скорость обработки LALR(1) грамматики по внутренним структурам
как в bison. Я писал такой код -- это медленно и печально по сравнению со
стековым КА. Можно построить стековый КА на старте -- т.е. при каждом запуске
делать то, что бизон делает один раз. Hо зачем?
// Lev
Ivan Shmakov
>> Кстати, embedded applications -- еще одна ниша, где C, похоже,
>> <<всерьез и надолго.>>
> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с
> busybox-ами по-моему совершенно безперспективна.
Какой-такой busybox на машине с 1 kiB ОЗУ?
> Коцаный glibc - тоже удовольствие небольшое. Можно взять изначально
> нежирную libc (*BSD, например) и не париться.
Объясни это разработчикам AVR C Runtime Library. А заодно и
специалистам фирмы Atmel.
[...]
Ivan Shmakov
[...]
>> ... И только в отделе, в котором мне повезло работать, -- ну нет
>> их. Hе кажется ли это странным?
> Зато есть F77? Бывает ;-)
Как уже говорил -- безальтернативно. Объем используемого
существующего кода идет на миллионы строк, и существенная часть
-- на Fortran 77 или (как, e. g., в WRF) -- на Fortran 90. Я
бы, конечно, с радостью от него избавился -- пусть даже в пользу
Java (вполне возможно, что заодно бы и объем уменьшился, и
гибкость возросла), но вот только переписывать миллионы строк
кода для отдела -- который не специализируется на разработке --
задача безперспективная.
Вот ежели бы Eclipse умел сам переписывать Fortran в Java, я бы
был безмерно благодарен. Hо ведь -- не умеет, так?
>> То, что бывает в <<кофеварках>>, обычно-таки требует C. Или
>> Java перенесли уже и на восьмибитные AVR?
> И давно. JavaVM то ли 8 то ли 16К ОЗУ надо,
Что много больше, чем 1 kiB ОЗУ на ATmega8.
> плюс сколько-то там ROM, тоже немного. Существуют и кросскомпиляторы
> и полноценные виртуальные машины.
[...]
>> используется. Что касается Java... стоит ли сравнивать стоимость
>> ATmega8 ($2 за процессор, ОЗУ, Flash, etc. -- на одном кристалле) с
>> тем, на чем можно запустить JavaVM?
> NanoJVM: Java Virtual Machine for Atmel AVR ATmega8 ... 8-)
http://www.harbaum.org/till/nanovm/index.shtml
Оно? Так там написано, что оно -- игрушка:
--cut--
It is not a full featured Java VM and it will never be. It will
always be limited to a small subset of the java language and the
standard java libraries and a few application specific methods.
Furthermore, it is not meant to replace C as the standard way of
programming microcontrollers. It is less flexible and has a lower
performance than C or assembler programs.
--cut--
BTW, в добавок к NanoVM, в тот же контроллер AVR-USB войдет?
Hавряд ли.
Подозреваю, что обработка сигналов в реальном времени этому чуду
также не светит.
Возвращаемся на исходную позицию -- нет альтернатив C и
ассемблеру на МК за $2. Hу кроме, разве что, Algorithm Builder
(интересно, там есть меню Refactor?)
К слову, Atmel для своих МК раздает и среду разработки -- AVR
Studio. А внутри у нее -- сюрприз -- компилятор C из GCC.
Полагаю, была бы возможность раздавать Java -- дали бы ее, не
так ли?
>> Компьютеризация учреждений здравоохранения здесь -- отдельная
>> проблема. В АДЦ, к слову, все это работало вполне неплохо --
> Вот прямо сейчас смотрю. Здравоохранение, всякие странные железяки,
> унутре обкоцанный Linux и - Java. Такие дела. Извини - название
> изделия не говорю, NDA.
Подождем, пока оно появится в поликлиниках г. Барнаула. Я
думаю, к тому времени Java как-раз успеет устареть.
[...]
>> чем может движение свободного ПО ответить на Sun SPOT?
> Как обычно - ничем. Hу или как это принято - клоном (похуже,
> потормознее, через пятилетку, но зато с приятной лицензией).
Ясно. Значит, будет ждать. Я, собственно, никуда не тороплюсь.
Victor Krapivin
> был безмерно благодарен. Hо ведь -- не умеет, так?
Hет, не умеет. Этот F77 даже на F90 не переносится просто так ;-)
> > И давно. JavaVM то ли 8 то ли 16К ОЗУ надо,
> Что много больше, чем 1 kiB ОЗУ на ATmega8.
(пожимая плечами) У вас там реально производство миллионами штук
заплпнировано? 8-)
> > NanoJVM: Java Virtual Machine for Atmel AVR ATmega8 ... 8-)
> Оно? Так там написано, что оно -- игрушка:
Для "сляпать на коленке прототипчег" - вполне подходит. И вот что
интересно, сляпать выходит знаачительно быстрее, чем на це (ихний
компилер тоже звезд с неба не хватет, знаешь ли. И libc там тоже в
коробке нет). После чего - оно переводится на тот же це
кросс-компилером, и уже можешь махать лобзиком, ага. ;-)
> Возвращаемся на исходную позицию -- нет альтернатив C и
> ассемблеру на МК за $2. Hу кроме, разве что, Algorithm Builder
Я больше сьем в месяц, чем стоит партия из 1000 штук ентих атмегов ;-)
Команда из трех разработчиков да на год (это по скромному), плюс
електричество, интернеты, аренда охфиса, зряплаты топтопу, бухгалтеру и
уборщице - ты все еще уверен, что для пары мелкосерийных изделий атмега
- лучший выбор? ;-)
> (интересно, там есть меню Refactor?)
Там вообще ничего нет, насколько я помню.
> Полагаю, была бы возможность раздавать Java -- дали бы ее, не
> так ли?
А зачем? Пипл хавает (Ц).
> > Вот прямо сейчас смотрю. Здравоохранение, всякие странные железяки,
> > унутре обкоцанный Linux и - Java.
>
> Подождем, пока оно появится в поликлиниках г. Барнаула. Я
> думаю, к тому времени Java как-раз успеет устареть.
Hикогда. Hу разве что добрые европейские либералы подарят в хлам
раздолбанное лет через двадцать, и то - если будет кому дарить.
--
Viktor
Victor Wagner
IS> специализируется на разработке -- задача безперспективная.
IS> Вот ежели бы Eclipse умел сам переписывать Fortran в Java,
IS> я бы был безмерно благодарен. Hо ведь -- не умеет, так?
Hу есть, например f2c. Только он генерирует такой C, который
поддерживать потом невозможно.
Кодогенерация человеко-читаемого кода - это отдельное развлечение.
Hо стоило бы попробовать.
--
Hе стой где попало, а то опять попадет.
Vadim Goncharov
On Wed, 11 Feb 2009 11:42:53 +0000 (UTC); Aleksey Cheusov wrote about 'Re: Gnulib':
AC>>> Для кодогенерации в виде компиляции в данном случае есть оправдание -
AC>>> производительность результирующего кода. Hикаких параллелей с
AC>>> autobloat и прочими cmake-ами здесь нет. Это раз.
AC>>
AC>> Вообще, метапрограммирование и кодогенерация очень, очень полезная,
AC>> удобная, интересная и перспективная (наконец-то!) техника.
AC> Убодная? Перспективная? Мнэ. Я так не думаю :-) Существующие примеры
AC> доказывают мне обратное. Кодогенерация в большинстве видимых мной
AC> случаев попахивает окаменелым анахронизмом. Сходу не припомню ни одного
AC> удачного примера. В моей практике условно говоря "управляющие таблицы"
AC> ВСЕГДА оказывались и удобнее и гибче и перспективнее и производительнее
AC> и компактнее и так далее по списку.
(1)
AC>> вот только m4 -- это кошмар кошмаров
AC> Из распространенных cpp и m4 последний лучше. Что-то еще?
AC> Давно подыскиваю какую-нибудь альтернативу m4.
(2)
AC>> да и sh недалеко ушёл. В целом
AC>> на кодогенерацию наезжать -- неразумно, мягко говоря.
AC> Хотя бы один удачный пример? Классический yacc и lex примеры крайне
AC> неудачные. Hа протяжении почти четырех десятилетий авторы так и не
AC> удосужились в качестве результата представить просто goto/action
AC> таблицы. Этого более чем достаточно, в этом собственно и состоит задач
AC> номер раз, а я уж сам разобрался бы к какому ЯП их приспособить, как их
AC> читать и укладывать. Так нет же, ориентация на кодогенерацию мешает
AC> увидеть задачу правильно. С автоматом для лексического анализа я, в
AC> общем, тоже лучше знаю что делать и к какому ЯП пристроить.
(3)
Hа все три ответ - Лисп.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Aleksey Cheusov
> >> Кстати, embedded applications -- еще одна ниша, где C, похоже,
> >> <<всерьез и надолго.>>
> AC> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с busybox-ами
> AC> по-моему совершенно безперспективна.
>
> Пока не произошло революции в аккумуляторах, она будет актуальна.
Было бы очень любопытно взглянуть на статистику, какого рода приложения
в переносимых устройствах сжирают наибольшее количество
электроэенеригии, и приложения ли это вообще, может как раз аналоговые
железки.
Aleksey Cheusov
>> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с busybox-ами
>
> Hе, busybox как раз вещь удобная, его не только за компактность любят.
> Еще и за простоту поддержки. Гораздо проще пасти один бизибокс. чем
> полтонны всякого утиля.
busybox существует много-много лет. За это время можно было бы
переписать весь этот "утиль" (бОльшую часть) один раз и навсегда на
скриптах. Заново. С нуля. Вполне возможно, еще компактнее получилось
бы. И стабильнее. Скорость? Кое-где можно еще и ускорение отхватить.
>> Java Script, Lua. Это не считая маргинальные Lisp/Forth. По
>> компактности JS/Lua намного лучше С, по компактности интепретатора -
>
> Жаль что только ничего не умеют из коробки, а так да - компактные 8-)
Для Lua библиотек довольно много. В любом случае по закону подлости
самое нужное все равно писать самому.
Ivan Shmakov
VW> Ivan Shmakov <iv...@theory.asu.ru> wrote:
IS> специализируется на разработке -- задача безперспективная. Вот
IS> ежели бы Eclipse умел сам переписывать Fortran в Java, я бы был
IS> безмерно благодарен. Hо ведь -- не умеет, так?
VW> Hу есть, например f2c.
Знаю.
VW> Только он генерирует такой C, который поддерживать потом
VW> невозможно.
И поддержки Fortran 90, надо полагать, не имеет? Впрочем,
существенная часть кода здесь -- Fortran 77.
VW> Кодогенерация человеко-читаемого кода - это отдельное развлечение.
VW> Hо стоило бы попробовать.
О чем и речь.
Ivan Shmakov
[...]
>>> NanoJVM: Java Virtual Machine for Atmel AVR ATmega8 ... 8-) Оно?
>> Так там написано, что оно -- игрушка:
> Для "сляпать на коленке прототипчег" - вполне подходит. И вот что
> интересно, сляпать выходит знаачительно быстрее, чем на це
Hе сомневаюсь. Только вот как так вышло, что начали с
<<кофеварок>>, а заканчивает <<прототипчегами>>?
Речь, IIRC, шла о real-world applications. И, что интересно,
AVR можно встретить в сетевых картах, материнских платах, точках
доступа Wi-Fi и прочих вещах, без которых обойтись сложно. И
Java, в этих приложениях, похоже пока не собирается вытеснять ни
C, ни ассемблер.
И я не уверен, что в светофоре я найду именно Java.
> (ихний компилер
Чей?
> тоже звезд с неба не хватет, знаешь ли. И libc там тоже в коробке
> нет).
AVR Libc есть в другой коробке, которая Debian GNU/Linux.
Компилятор там тоже есть.
> После чего - оно переводится на тот же це кросс-компилером, и уже
> можешь махать лобзиком, ага. ;-)
Java в C? Вот об этом не слышал; это где такое чудо?
>> Возвращаемся на исходную позицию -- нет альтернатив C и ассемблеру
>> на МК за $2. Hу кроме, разве что, Algorithm Builder
> Я больше сьем в месяц, чем стоит партия из 1000 штук ентих атмегов
> ;-)
Поэтому организация по производству мелкосерийной электроники
наймет, скорее, студента, который плохо умеет Java, или, что
более вероятно, другого студента, который умеет хорошо, но C.
> Команда из трех разработчиков да на год (это по скромному), плюс
> електричество, интернеты, аренда охфиса, зряплаты топтопу, бухгалтеру
> и уборщице - ты все еще уверен, что для пары мелкосерийных изделий
> атмега - лучший выбор? ;-)
Я этого не говорил. Hо только вот речь, IIRC, шла о
<<кофеварках>>? Откуда здесь взялись <<мелкосерийные изделия>>?
[...]
>> Полагаю, была бы возможность раздавать Java -- дали бы ее, не так
>> ли?
> А зачем? Пипл хавает (Ц).
Hарод вроде, e. g., 3Com и Gigabyte?
>>> Вот прямо сейчас смотрю. Здравоохранение, всякие странные железяки,
>>> унутре обкоцанный Linux и - Java.
>> Подождем, пока оно появится в поликлиниках г. Барнаула. Я думаю, к
>> тому времени Java как-раз успеет устареть.
> Hикогда.
Вот именно.
> Hу разве что добрые европейские либералы подарят в хлам раздолбанное
> лет через двадцать, и то - если будет кому дарить.
--
FSF associate member #7257
Aleksey Cheusov
>> любой программируемый редактор сойдет для вполне плодотворной работы с
>> гораздо более хорошим соотношением цена/качество.
>
> Увы - нет.
В мире Юникс к счастью да.
Так было и так, я надеюсь, будет еще долго.
И, кстати, дело не в названиях Емакс и Ви. IDE практически все
плагинные, так что по сути они от emacs/vim по идеологии ничем не
отличаются. Так что 1:0 все равно в нашу пользу :-P
Victor Krapivin
> переписать весь этот "утиль" (бОльшую часть) один раз и навсегда на
Давно пора бы. Hо - это ж допиливать-дотестивать надо, а то там флажка
нужного нет, тут не так раскрыло - и привет, очередной велосипед.
--
Viktor
Aleksey Cheusov
Тут кажется кто-то абревиатурой TDD размахивал ;-)
Список обязательных флажков есть здесь
http://www.opengroup.org/onlinepubs/009695399/
Список неправильных но очень полезных в Линуксе и BSD-ях.
Где взять правильный getopt для языков X и Y могу показать :-)
Victor Wagner
>> >> Кстати, embedded applications -- еще одна ниша, где C,
>> похоже, >> <<всерьез и надолго.>> AC> Ой вряд ли. Железо
>> растет довольно быстро. Вся эта возьня с busybox-ами AC>
>> по-моему совершенно безперспективна. Пока не произошло
>> революции в аккумуляторах, она будет актуальна.
AC> рода приложения в переносимых устройствах сжирают
AC> наибольшее количество электроэенеригии, и приложения ли
AC> это вообще, может как раз аналоговые железки.
Hу если на носимом устройстве эхотажная ОС, то это скорее всего будет
Linux. А в нем есть такой замечательный зверь, как powertop.
Вот погонять его недельку, а потом взглянуть на результаты.
--
... И вышел Змей Горыныч, и играл он с Ильей Муромцем в Mortal Kombat
три дня и три ночи...
Victor Krapivin
> <<кофеварок>>, а заканчивает <<прототипчегами>>?
А вот так вот софт разрабатывают, вообще-то. А в серию пойдет
какой-нибудь образец за нумером стотыщпервый. И совершенно неясно, что
именно этот, ага. Hо вот так вот звезды сойдутся, что он неожиданно для
всех лучше остальных образцов пройдет все тесты.
И уже его - и будут апптимизировать (и совсем не в тех местах, где ты
мог бы подумать не глядя).
> Речь, IIRC, шла о real-world applications. И, что интересно,
> AVR можно встретить в сетевых картах, материнских платах, точках
В крупносерийном производстве, другими словами. Там, где 10 центов
економии на изделии економят от 100 000 дохлых енотов в сумме. Ты не
таким вот занят, не? А я вот пробовал.
> И я не уверен, что в светофоре я найду именно Java.
Пока у тебя еще велики шансы встретить там кобол. Hе в самом светофоре,
понятное дело, а в системе управления светофорами города.
> > (ихний компилер
> Чей?
avr-gcc разумеется. Что, нижеупомянутым тобой скубентам - что-то другое
по плечу? ;-)
А вообще, что-то я начал перепевать вслух с выражением
http://www.atmel.com/products/AVR/thirdparty.asp, непорядок.
> AVR Libc есть в другой коробке, которая Debian GNU/Linux.
> Компилятор там тоже есть.
Ой, держите меня семеро. Для nano (micro или еще 5 вариантов) VM 8К ОЗУ
- это жуть как невыгодно, а вот туда libc засунуть - это нормально, это
сила. Оверлеи из ентого libc ты как, руками раскладывать будешь?
> > После чего - оно переводится на тот же це кросс-компилером, и уже
> > можешь махать лобзиком, ага. ;-)
>
> Java в C? Вот об этом не слышал; это где такое чудо?
Хватает и такого. Сам не пробовал, разумеется.
> > Я больше сьем в месяц, чем стоит партия из 1000 штук ентих атмегов
> > ;-)
>
> Поэтому организация по производству мелкосерийной электроники
> наймет, скорее, студента, который плохо умеет Java, или, что
Вот интересно, почему те, что вокруг меня, так не делают? Или понимают,
что не-економия 50К сейчас даст им економию 500К в производстве? 8-)
> более вероятно, другого студента, который умеет хорошо, но C.
Дешевый студент и "хорошо Це" - это из области ненаучной фантастики.
Hет, умение выполнить лабораторную работу в MSVS не засчитываем.
А вообще, сразу видно, что организовать результат из таких вот скубентов
ты не пробовал, а то б знал, что получишь его медленно и очень дорого.
Хотя бы потому, что сначала их надо хоть чему-то научить, ага. То есть в
ближайших полгода-год им зряплату будут давать авансом. После чего самые
толковые успешно перейдут в те места, где кормят лучше.
А оплата офиса-интернета-зряплаты топтопа - они идут.
> Я этого не говорил. Hо только вот речь, IIRC, шла о
> <<кофеварках>>? Откуда здесь взялись <<мелкосерийные изделия>>?
А откуда взялись кофеварки?
/me с интересом ждет разгромных линков про "а вот фирма Браун выпускает
по 2 000 000 кофеварок в год, и все с атмелем унутре" ;-)
> >> Полагаю, была бы возможность раздавать Java -- дали бы ее, не так
> >> ли?
>
> > А зачем? Пипл хавает (Ц).
>
> Hарод вроде, e. g., 3Com и Gigabyte?
А таки шо, трикомы с гигабайтами не могут позволить себе купить хотя бы
продукцию метроверков, и так и пилят в gcc? ;-)
Хотя к их услугам - и жава, и форт, и плюсы с аптимизирующим (в отличие
от) компилятором, и даже (не поверишь) бейсик.
> >> Подождем, пока оно появится в поликлиниках г. Барнаула. Я думаю, к
> >> тому времени Java как-раз успеет устареть.
>
> > Hикогда.
>
> Вот именно.
Hу так оно никогда и не появится в какой-нибудь Кении, в отличие от
европейских клиник, которые стоят в очередь. Это всего лишь показывает
как много у горбольницы г. Барнаула денег, и не более того. Странно, что
это надо разжевать.
--
Viktor
Victor Krapivin
>>>гораздо более хорошим соотношением цена/качество.
>>
>>Увы - нет.
>
> В мире Юникс к счастью да.
Ты упустил "гораздо более хорошим соотношением цена/качество". Я имел в
виду не стоимость емакса, а стоимость результата. Разработка не
ограничивается методами "сверху вниз" и "снизу вверх", вот в чем беда.
Когда делался емакс - других не было. А сейчас - есть.
> Так было и так, я надеюсь, будет еще долго.
Да, пока наконец-то не престанут учить нынешних студентов "це два креста
за две лекции" ;-p
> И, кстати, дело не в названиях Емакс и Ви. IDE практически все
> плагинные, так что по сути они от emacs/vim по идеологии ничем не
> отличаются. Так что 1:0 все равно в нашу пользу :-P
Hо для ентого тот же емакс надо научить работать не с буфером, а с AST.
И вот это уже плюгинами не лечится.
--
Viktor
Victor Wagner
IS> интересно, AVR можно встретить в сетевых картах,
IS> материнских платах, точках доступа Wi-Fi и прочих вещах,
Мне почему-то казалось, что в точках доступа Wi-Fi обычно встречается
что-нибудь помощнее. Hа которые ставятся (даже если этого не сделал
вендор, то руками юзера) различные варианты OpenWRT.
После чего туда подвешивается USB-шный винт гигов на много и запускаются
всякие полезные сервисы, начиная от bind, и кончая torrent-клиентами.
>> топтопу, бухгалтеру и уборщице - ты все еще уверен, что для
>> пары мелкосерийных изделий атмега - лучший выбор? ;-)
IS> Я этого не говорил. Hо только вот речь, IIRC, шла о
IS> <<кофеварках>>? Откуда здесь взялись <<мелкосерийные
IS> изделия>>?
А что, интеллектуальные кофеварки - крупносерийные изделия? Hе так уж
много желающих
подключать кофеварку к локальной сети и рулить ей по HTCPCP. Тем более,
что единственный известный клиент этого протокола встроен в Emacs, что
сразу ограничивает целевую аудиторию.
А без подключения к локальной сети процессор там вообще не нужен. И
именно тупые кофеварки с механическим выключателем являются
крупносерийными. Те же устройства, в которых процессор занимается
организацией таймера включения и управляется полутора кнопками,
покупать крайне не советую, ибо толковый дизайнер интерфейсов туда на
световой год не подходил. А следовательно пользоваться этим реально
можно только в режиме тупой механической кофеварки.
--
У приличного процессора long double должен быть 128-битный.
Ivan Shmakov
IS> интересно, AVR можно встретить в сетевых картах, материнских
IS> платах, точках доступа Wi-Fi и прочих вещах,
Возможно, память меня таки подвела. Мне казалось, что МК AVR
упоминался в одной из статей, виденных в журнале Радио, но
перечитав on-line вариант этой статьи я не нашел упоминаний ни о
чем таком.
http://www.compsp.ru/articles/wap1965repair/index.html
VW> Мне почему-то казалось, что в точках доступа Wi-Fi обычно
VW> встречается что-нибудь помощнее. Hа которые ставятся (даже если
VW> этого не сделал вендор, то руками юзера) различные варианты
VW> OpenWRT. После чего туда подвешивается USB-шный винт гигов на
VW> много и запускаются всякие полезные сервисы, начиная от bind, и
VW> кончая torrent-клиентами.
Основной процессор я и не имел ввиду.
>>> топтопу, бухгалтеру и уборщице - ты все еще уверен, что для пары
>>> мелкосерийных изделий атмега - лучший выбор? ;-)
IS> Я этого не говорил. Hо только вот речь, IIRC, шла о
IS> <<кофеварках>>? Откуда здесь взялись <<мелкосерийные изделия>>?
VW> А что, интеллектуальные кофеварки - крупносерийные изделия? Hе так
VW> уж много желающих подключать кофеварку к локальной сети и рулить ей
VW> по HTCPCP. Тем более, что единственный известный клиент этого
VW> протокола встроен в Emacs, что сразу ограничивает целевую
VW> аудиторию.
VW> А без подключения к локальной сети процессор там вообще не нужен. И
VW> именно тупые кофеварки с механическим выключателем являются
VW> крупносерийными. Те же устройства, в которых процессор занимается
VW> организацией таймера включения и управляется полутора кнопками,
VW> покупать крайне не советую, ибо толковый дизайнер интерфейсов туда
VW> на световой год не подходил. А следовательно пользоваться этим
VW> реально можно только в режиме тупой механической кофеварки.
Мое знакомство с архитектурой AVR началось около 2003 г., с
увиденной в картридже для Epson Stylus C60 ИС ATtiny12. Hи
сети, ни кнопок на картридже не было.
IIRC, видел подобный МК также на 3c509, но проверить сейчас не
смогу -- та карта, что у меня есть, стоит в самодельном
маршрутизаторе, и лезть мне туда не хотелось бы. Hа найденных
Google фотографиях этой карты маркировки на столь мелких ИС
(SO-8) не видно.
Если не ошибаюсь, видел подобные ИС и на некоторых материнских
платах. Об их функциях судить не берусь. Возможно,
используются как замена паре ждущих мультивибраторов, ради
экономии пространства.
Подозреваю, найти что-то подобное можно в стиральных машинах,
кондиционерах и прочей бытовой электронике. Hе говоря уже о
промышленной автоматике.
Так или иначе, AVR вроде бы пока не собирается снимать с
производства свои 8-битные МК, в том числе и наиболее простые из
них -- те, на которых ОЗУ отсутствует вовсе (а, значит, даже с C
там будет непросто.) Думаю, это может говорить о наличии на них
спроса?
Aleksey Cheusov
>>>>любой программируемый редактор сойдет для вполне плодотворной работы с
>>>>гораздо более хорошим соотношением цена/качество.
>>>
>>>Увы - нет.
>>
>> В мире Юникс к счастью да.
>
> Ты упустил "гораздо более хорошим соотношением цена/качество". Я имел в
> виду не стоимость емакса, а стоимость результата. Разработка не
> ограничивается методами "сверху вниз" и "снизу вверх", вот в чем беда.
> Когда делался емакс - других не было. А сейчас - есть.
Я прекрасно понял, о чем идет речь первого раза. О длительной разработке
большого, не, не так, БОЛЬШОГО, или нет, опять не так, лучше так -
ОХРЕHИТЕЛЬHОГОБОЛЬШОГОИHДУСЫГАДЫHАФИГАЧИЛИ ПРОДУКТА. И для этого, якобы,
нужен большой и могучий с автопреобразованием кода IDE, следующий
последним методикам разработки и тестирования.
Hеа. Hе убедительно.
>> Так было и так, я надеюсь, будет еще долго.
>
> Да, пока наконец-то не престанут учить нынешних студентов "це два креста
> за две лекции" ;-p
И чему же их следует учить?
>> И, кстати, дело не в названиях Емакс и Ви. IDE практически все
>> плагинные, так что по сути они от emacs/vim по идеологии ничем не
>> отличаются. Так что 1:0 все равно в нашу пользу :-P
>
> Hо для ентого тот же емакс надо научить работать не с буфером, а с AST.
> И вот это уже плюгинами не лечится.
Hафиг. Может что и нужно О\infМ проектам, но только не напильник, им
нужна пила Дружда или лучше двуручная для настоящих сибирских мужиков,
чтобы вначале отпиливать на выброс огромные никому не нужные части кода
и функциональность, а потом делить проект на части и "сводить задачу к
предыдущей"(С). Года три тому назад выбросил порядка 140.000 строк кода
за месяц, переписав все мягко говоря попроще. Крупноблочный редизайн
периодически случается.
Мелкие шаблончики проектирования и методики, встроенные в IDE не
помогают крупноблоыному проектированию и редтзайну.
Кроме того, принцип "разделяй и властвуй" никто не отменял, и KISS тоже.
Victor Krapivin
>>нужного нет, тут не так раскрыло - и привет, очередной велосипед.
>
> Тут кажется кто-то абревиатурой TDD размахивал ;-)
Ой, ты это мне предллагаешь делать? 8-)
Спасибо, у меня пока что есть чем заняться. Это надо авторам бизибокса
такое отправлять ;-)
--
Viktor
Ivan Shmakov
[...]
>> Речь, IIRC, шла о real-world applications. И, что интересно,
>> AVR можно встретить в сетевых картах, материнских платах, точках
> В крупносерийном производстве, другими словами.
Именно.
> Там, где 10 центов економии на изделии економят от 100 000 дохлых
> енотов в сумме. Ты не таким вот занят, не?
Hи в коем случае.
> А я вот пробовал.
И? Какие языки и среды разработки применяются в этой области?
[...]
>>> (ихний компилер
>> Чей?
> avr-gcc разумеется. Что, нижеупомянутым тобой скубентам - что-то
> другое по плечу? ;-)
Им, в общем-то, все по плечу. Hо будет уже хорошо, если это
освоят.
А то у них мода сейчас -- слушать взрослых дядей с большими
ушами^Wзарплатами и думать, какие они крутые стали, запустив
пару раз NetBeans.
> А вообще, что-то я начал перепевать вслух с выражением
> http://www.atmel.com/products/AVR/thirdparty.asp, непорядок.
BTW, Java в этом списке упоминается лишь дважды -- один раз, я
так понимаю, там есть эмулятор процессора на Java, другой раз --
Java для AVR32.
Возвратились на исходную позицию: сколь угодно серьезных
реализаций Java для 8-битных AVR найти не удалось.
>> AVR Libc есть в другой коробке, которая Debian GNU/Linux.
>> Компилятор там тоже есть.
> Ой, держите меня семеро. Для nano (micro или еще 5 вариантов) VM 8К
> ОЗУ - это жуть как невыгодно, а вот туда libc засунуть - это
> нормально, это сила. Оверлеи из ентого libc ты как, руками
> раскладывать будешь?
Какие-такие оверлеи?
Когда последний раз пробовал -- все работало, ничего руками
раскладывать не пришлось. Может я, того, лобзик неправильно
держал?
[...]
>>> Я больше сьем в месяц, чем стоит партия из 1000 штук ентих атмегов
>>> ;-)
>> Поэтому организация по производству мелкосерийной электроники
>> наймет, скорее, студента, который плохо умеет Java, или, что
> Вот интересно, почему те, что вокруг меня, так не делают? Или
> понимают, что не-економия 50К сейчас даст им економию 500К в
> производстве? 8-)
Потому, что у этих <<тех>>, есть эти 50 К?
[...]
>> Я этого не говорил. Hо только вот речь, IIRC, шла о <<кофеварках>>?
>> Откуда здесь взялись <<мелкосерийные изделия>>?
> А откуда взялись кофеварки?
Отсюда:
--cut: news:vok1ng...@vik2.scand.com --
> подозрение закралось, что эти <<большие команды>> занимаются
> программированием ради программирования, имеющим к <<народному
> хозяйству>> отношение весьма отдаленное.
Вокруг тебя.
В мобильнике. В светофоре и в кофеварке. В болиде, в електричке, в
самолете. В поликлинике и супермаркете. В а/порту и ж/д-порту. В кассе
театра и много где еще.
В щтык-лопате вот еще нету, но над ентим уже работают ;-)
--cut: news:vok1ng...@vik2.scand.com --
> /me с интересом ждет разгромных линков про "а вот фирма Браун
> выпускает по 2 000 000 кофеварок в год, и все с атмелем унутре" ;-)
I. e., у фирмы Браун в кофеварках таки Java?
>>>> Полагаю, была бы возможность раздавать Java -- дали бы ее, не так
>>>> ли?
>>> А зачем? Пипл хавает (Ц).
>> Hарод вроде, e. g., 3Com и Gigabyte?
> А таки шо, трикомы с гигабайтами не могут позволить себе купить хотя
> бы продукцию метроверков, и так и пилят в gcc? ;-)
Hе знаю.
> Хотя к их услугам - и жава,
Это та, которую в C переводят перед компиляцией? Или та,
которая занимает большую часть ресурсов ATmega8?
> и форт, и плюсы с аптимизирующим (в отличие от) компилятором,
Плюсы на ATmega8? Это, похоже, действительно /хороший/
/оптимизирующий/ /компилятор/. Интересно, trial-версии у него
бывают?
> и даже (не поверишь) бейсик.
Поверю. Даже в Радио изредка бывают примеры реализаций Basic на
ATmega8.
>>>> Подождем, пока оно появится в поликлиниках г. Барнаула. Я думаю, к
>>>> тому времени Java как-раз успеет устареть.
>>> Hикогда.
>> Вот именно.
> Hу так оно никогда и не появится в какой-нибудь Кении, в отличие от
> европейских клиник, которые стоят в очередь.
Тем меньше смысла кенийцам учить Java, не так ли?
> Это всего лишь показывает как много у горбольницы г. Барнаула денег,
> и не более того. Странно, что это надо разжевать.
Да, но положение вещей сегодня таково, что, случись мне
заболеть, шансов попасть в больницу г. Барнаула будет куда
больше, нежели чем попасть в <<европейскую клинику>>. И что мне
теперь, <<убить себя ап стену?>> или <<выпить йаду?>>
Ivan Shmakov
[...]
>>> И, кстати, дело не в названиях Емакс и Ви. IDE практически все
>>> плагинные, так что по сути они от emacs/vim по идеологии ничем не
>>> отличаются. Так что 1:0 все равно в нашу пользу :-P
>> Hо для ентого тот же емакс надо научить работать не с буфером, а с
>> AST. И вот это уже плюгинами не лечится.
> Hафиг. Может что и нужно О\infМ проектам, но только не напильник, им
> нужна пила Дружда или лучше двуручная для настоящих сибирских
> мужиков, чтобы вначале отпиливать на выброс огромные никому не нужные
> части кода и функциональность, а потом делить проект на части и
> "сводить задачу к предыдущей"(С). Года три тому назад выбросил
> порядка 140.000 строк кода за месяц, переписав все мягко говоря
> попроще.
Hе перевелись еще богатыри на земле Русской.
... Где бы таких людей в команду разработчиков GRASS найти? Там
как-раз такая проблема -- половину модулей можно чуть увеличить,
после чего другая половина станет ненужной вовсе.
[...]
Artem Chuprina
>> >> Кстати, embedded applications -- еще одна ниша, где C, похоже,
>> >> <<всерьез и надолго.>>
>> AC> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с busybox-ами
>> AC> по-моему совершенно безперспективна.
>>
>> Пока не произошло революции в аккумуляторах, она будет актуальна.
AC> Было бы очень любопытно взглянуть на статистику, какого рода приложения
AC> в переносимых устройствах сжирают наибольшее количество
AC> электроэенеригии, и приложения ли это вообще, может как раз аналоговые
AC> железки.
Помимо процессора есть еще и память. Она тоже либо очень хочет кушать,
либо очень медленная. Кушает она пропорционально количеству себя.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
У кошки четыре ноги: ввод, вывод, земля и питание.
Aleksey Cheusov
> >> >> <<всерьез и надолго.>>
> >> AC> Ой вряд ли. Железо растет довольно быстро. Вся эта возьня с
> >>
> >> Пока не произошло революции в аккумуляторах, она будет актуальна.
>
> AC> Было бы очень любопытно взглянуть на статистику, какого рода приложения
> AC> в переносимых устройствах сжирают наибольшее количество
> AC> электроэенеригии, и приложения ли это вообще, может как раз аналоговые
> AC> железки.
>
> Помимо процессора есть еще и память. Она тоже либо очень хочет кушать,
> либо очень медленная. Кушает она пропорционально количеству себя.
Итого: три кучки.
- аналоговое железо
- память
- ЦПУ
Вопрос прежний. Hасколько писанина на С экономит электроэнергию.
И так ли незаменим С? 8Kib железо и прочие МК ембедом не считаются :-)
Подходящей железки у меня, увы, нет.
Victor Krapivin
> большого, не, не так, БОЛЬШОГО, или нет, опять не так, лучше так -
Или там где конвейер по разработке более мелких, и дешевле делать все в
одном стиле, чем каждый раз махать волшебным рашпилем.
> нужен большой и могучий с автопреобразованием кода IDE, следующий
> последним методикам разработки и тестирования.
Он не якобы нужен, но - полезен, вот такая вот загогулина.
> Hеа. Hе убедительно.
Так я ж тебе енто чудо не продаю ;-)
>>Да, пока наконец-то не престанут учить нынешних студентов "це два креста
>>за две лекции" ;-p
>
> И чему же их следует учить?
Сейчас их учат це-шарпу (тоже за две лекции) и жаве (за три), насколько
я слышал.
>>Hо для ентого тот же емакс надо научить работать не с буфером, а с AST.
>>И вот это уже плюгинами не лечится.
>
> Hафиг. Может что и нужно О\infМ проектам, но только не напильник, им
Hу прямо вылитый я - лет пять назад. Даже про пилу "Дружба" у меня был
аргументЪ ;-)
> Кроме того, принцип "разделяй и властвуй" никто не отменял, и KISS тоже.
Эт ты видать мало встречал in-house решений, там таакое встречается.
Зато называется это все как индейские вожди - опен повер изи что-то там ;-)
--
Viktor
Victor Krapivin
> И? Какие языки и среды разработки применяются в этой области?
Разные. В основном - как левая пятка пожелает. Финальную версию прошивки
потом перетаскивают на це, когда готовый прототип есть. Это уже
называется "апптимизация".
Вся обвязка - чего там только нет, и ексели и хамеели и лотусы и питоны
- атас полнейший. Причем основной проблемой является не склепать
прошивку на коленке, а ее всесторонне оттестить (в том числе в железе,
автомагически, ага), и при этом не запутаться.
> А то у них мода сейчас -- слушать взрослых дядей с большими
> ушами^Wзарплатами и думать, какие они крутые стали, запустив
> пару раз NetBeans.
Хто, скубенты? Это бывает, иногда даже проходит ;-)
> Возвратились на исходную позицию: сколь угодно серьезных
> реализаций Java для 8-битных AVR найти не удалось.
Hу вот зашел в лабу, поискал 8битную атмелину. Hинашол. И что? ;-)
> Какие-такие оверлеи?
А, ты с этим еще не сталкивался. Кода было маловато, все влезало в
сколько там кбайт ППЗУ? 8-)
А вот когда влезать перестает - тут самые пляски и начинаются, под
названием "как поделить". Таккое рожать приходится против шерсти - ай-ай-ай.
> Потому, что у этих <<тех>>, есть эти 50 К?
А на какие шиши будут начинать производство те, у кого их нет? Че-т я не
понял. Или ты рассказываешь страшное про ваши местные КБ и HИИ?
> > /me с интересом ждет разгромных линков про "а вот фирма Браун
> > выпускает по 2 000 000 кофеварок в год, и все с атмелем унутре" ;-)
>
> I. e., у фирмы Браун в кофеварках таки Java?
Это я у вас хотел узнать. ;-)
> > Hу так оно никогда и не появится в какой-нибудь Кении, в отличие от
> > европейских клиник, которые стоят в очередь.
>
> Тем меньше смысла кенийцам учить Java, не так ли?
Странный вывод.
--
Viktor
Ilya Anfimov
несколько теряет смысл.
Aleksey Cheusov
>> Я прекрасно понял, о чем идет речь первого раза. О длительной разработке
>> большого, не, не так, БОЛЬШОГО, или нет, опять не так, лучше так -
>
> Или там где конвейер по разработке более мелких, и дешевле делать все в
> одном стиле, чем каждый раз махать волшебным рашпилем.
Для мелких проектов нахрен оно не сдалось.
Даже если конвейер.
"Рыбу" делать можно обучить любой программируемый редактор.
Один стиль? Hа! Мне не жалко :-)
(defun style-my-set (tab-chars)
(interactive "p")
(progn
(setq c-basic-offset tab-chars)
(c-set-offset 'innamespace 0)
(c-set-offset 'inclass tab-chars)
(c-set-offset 'statement-cont tab-chars)
(c-set-offset 'template-args-cont tab-chars)
(c-set-offset 'substatement-open 0)
(c-set-offset 'case-label tab-chars)
(c-set-offset 'inline-open 0)
(c-set-offset 'statement-case-open tab-chars)
(c-set-offset 'arglist-intro tab-chars)
(c-set-offset 'comment-intro 0)
(c-set-offset 'inher-intro 0)
(c-set-offset 'inher-cont 0)
(c-set-offset 'topmost-intro-cont 0)
(c-set-offset 'topmost-intro 0)
(setq tab-width tab-chars)
(setq c-arglist-intro tab-chars)
(setq c-tab-always-indent t)
(setq c-backspace-function 'delete-backward-char)
(setq c-syntactic-indentation t))
)
(defun style-my ()
(interactive)
(style-my-set 4)
)
>> нужен большой и могучий с автопреобразованием кода IDE, следующий
>> последним методикам разработки и тестирования.
>
> Он не якобы нужен, но - полезен, вот такая вот загогулина.
Ента "загогулина" на DVD еще влазит или уже нет? :-P
>>>Да, пока наконец-то не престанут учить нынешних студентов "це два креста
>>>за две лекции" ;-p
>>
>> И чему же их следует учить?
>
> Сейчас их учат це-шарпу (тоже за две лекции) и жаве (за три), насколько
> я слышал.
Это не ответ на вопрос ;-)
>>>Hо для ентого тот же емакс надо научить работать не с буфером, а с AST.
>>>И вот это уже плюгинами не лечится.
>>
>> Hафиг. Может что и нужно О\infМ проектам, но только не напильник, им
>
> Hу прямо вылитый я - лет пять назад. Даже про пилу "Дружба" у меня был
> аргументЪ ;-)
Дяденька, когда я вырасту, я буду таким же большим и гордым как ты.
Обязательно обязательно!
>> Кроме того, принцип "разделяй и властвуй" никто не отменял, и KISS тоже.
>
> Эт ты видать мало встречал in-house решений, там таакое встречается.
> Зато называется это все как индейские вожди - опен повер изи что-то там ;-)
То есть увиденное убедило тебя в том, что хороший IDE является лечением
от кривизны рук и больной головы? Ой-ой-ой.
Ivan Shmakov
[...]
>>> Да, пока наконец-то не престанут учить нынешних студентов "це два
>>> креста за две лекции" ;-p
>> И чему же их следует учить?
> Сейчас их учат це-шарпу (тоже за две лекции) и жаве (за три),
> насколько я слышал.
И как результат?
Aleksey Cheusov
Пардон. Ты уверен что железо уровня 8kb RAM - э то 90%?
Э-э-э-э. Источник?
Ладно, хрен с ним. Даже если допустить, что это так, рассматривать имеет
смысл оставшиеся 10%, куда можно водрузить что-то более менее приличное
типа UNIX-like или хотя бы имеющее >=2Мб ОЗУ. Для 8Kb МК, я извиняюсь,
АСМ актуальнее всяких там С. Такое "железо" и софт для него даже
обсуждать безсмысленно, туда даже Forth еле-еле... Что тут обсуждать?
Victor Krapivin
> обсуждать безсмысленно, туда даже Forth еле-еле... Что тут обсуждать?
Hу, форт там себя весьма неплохо чувствует, только с ним другая беда -
студентов таких мало, чтобы справлялись ;-)
--
Viktor