subject:"Re\: Среды разработки"

18.10.2012 00:16, Alexander Danilov пишет:
On 17.10.2012 22:22, Артём Н. wrote:
16.10.2012 23:21, Alexander Danilov пишет:
что после этого всякого,
утверждающего что C++ - это просто, а Haskell - это сложно, считаю
умственно
неполноценным родственником Джорджа Буша младшего, на котором природа не
то, что
отдохнула, она даже и не напрягалась.
Ну, по-моему, никто не говорит о простоте.
Полуркайте, Как выучить C++ за 21 день. ;-)

Есть, тут другой RAD.
Первый RAD с которым я познакомился в Unix - shell+coreutils(тогда это
была
большая куча пакетов).
Второй RAD - perl+CPAN.
Были и другие.
Это не RAD. Это компоненты.
Это RAD - rapid application development, именно так. Именно с помощью этих
средств очень быстро разрабатываются приложения, я куски сишного кода менял
на
вызовы system(awk ...), и кода становилось значитально меньше и работал он
значительно лучше и сопровождать было значительно проще, rapid - быстрее
просто
некуда!
В плане обработки текста.
Но минусы:
1. Кроссплатформенность хромает.
Каким образом она хромает? Все инструменты кросcплатформенные дальше некуда.
2. Скорость падает.
Как бы не наоборот. Скорость разработки точно возрастает, надёжность софта
точно, да и на Си написать то, что перл умеет лучше всего, да ещё чтоб и
работало быстрее, чем перл, это надо быть сишником среднего уровня и выше,
что в
наши дни большая редкость.
Это где редкость? o.O Не знаю, что вы подразумеваете под средним уровнем, но,
по-идее C - простой язык.

3. Связь между awk и C-шным кодом через костыли.
Стандартные системные IPC - костыли? Не согласен
Просто не самая лучшая идея встраивать awk через системные вызовы: я бы встроил
тогда уж что-то наподобие Lua (ну awk тоже неплохо, только, если встраивать
по-человечески, как библиотеку, если такое имеется).

вот писать формирование
отчётов на Си - это не просто костыли, это [*** ну тут такой нехороший эпитет
***]. Ибо сегфолты и коры дампы постоянно по причине кривости
пользовательского
ввода и трудности проверки его сишными средствами.
Да ладно. Пишут же на C компиляторы и всякие там awk?
Я тут тоже занялся полезной работой и, больше ради повторения, написал парсер,
который производит разбор в соответствии с метаданными, загруженными из INI
(взял парсер иника из интернетов), но в INI я добавил условия типа if, elif и
else (однопроходный анализатор с построением дерева), плюс разбор выражений в
C-стиле (без построения дерева) и построение списка полей на основе метаданных.
И ничего: это чуть сложнее, чем обычный пользовательский ввод, но работает без
сегфолтов и компилируется на 32-х и 64-х разрядной системе нормально.
Правда писать что-то на C я теперь зарёкся. :-) Да и рекурсивный анализатор вряд
ли уже когда-то писать буду: прочитаю всё-таки Книгу дракона и стану
пользоваться генераторами.

Re: Среды разработки

18.10.2012 11:41, Alexander Galanin пишет:
 On Wed, 17 Oct 2012 23:18:04 +0400
 Артём Н. artio...@yandex.ru wrote:
 
 17.10.2012 10:22, Alexander Galanin пишет:
 On Tue, 16 Oct 2012 22:57:29 +0400
 Артём Н. artio...@yandex.ru wrote:

 С чего б статически собранный бинарник весил меньше? Они обычно ой какие
 пухлые.
 В сравнении с tclkit. Там где-то говорили про мегабайты. Для D-7 мин. 
 бинарник
 весил около 300К. Для BCB аналогично. Для MSVS, меньше.
 Взял простенькую программу, сделанную в билдере, с библиотеками, которых ей 
 не
 хватало в системе. Оно правда при статической линковке меньше занимает?
 total 3,5M
 Меньше чего?
 
 Меньше 3.5 Мб.
 
 Про размеры я выше сказал.
 К тому же, не помню точно, но, вроде, он линкует не все функции bpl в
 исполняемый файл, а только то, что необходимо: слинкуйте, да посмотрите 
 размер,
 что гадать?
 Я билдером не пользуюсь, потому и спрашиваю. И я не понимаю, откуда может
 взяться _статический_ бинарник в 300 кб, если одна только cc3260mt.dll 
 занимает
 полтора мегабайта.
Ну не знаю меньше ли, чем 1.5. Я-то писал про простейшее приложение Delphi. А вы
нашли простенькое многопоточное.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50801599.5000...@yandex.ru

Re: Среды разработки

On 2012-10-15, Артём Н. wrote:

KDevelop - это сплошные плагины. Не падает ли так же часто, как Plasma?

Откройте для себя понятия компонент и модульной архитектуры.

Начать можно с

http://wiki.apidesign.org/wiki/Main_Page

Вместо того что бы тролить в листе выполните пару поисковых запросов на
StackOverflow, для примера:

http://stackoverflow.com/search?q=ide
http://stackoverflow.com/search?q=emacs+project
http://stackoverflow.com/search?q=vim+ide

почитайте и походите по ссылкам.

Еще магическая строка:

ide comparison list

Вставте в гуугл. Читаем топ-20, ходим по ссылкам. Еще магические строки:

top java ide
best c++ ide

- эти слова встречаются в high rate блогах и девелоперских порталах.

Обязательно по любой теме ищите в английской вики сравнение продуктов, в нашем
случае:

http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments

Там всегда список поддерживаемых платформ и сравнение ключевых фич. И как
всегда ссылки - ходим, читаем.

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

--
Best regards!

Re: Среды разработки

On 2012-10-15, Sciko Good wrote:
 Eclipse страшно тормозит. Именно после него я поверил, что Java тормозит.

Не более чем в 2 раза:

  http://shootout.alioth.debian.org/u64q/java.php

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vb3a9hi@gavenkoa.example.com

Re: Среды разработки

Начать можно с
http://wiki.apidesign.org/wiki/Main_Page
Любопытный сайтик. Спасибо.

Вместо того что бы тролить в листе выполните пару поисковых запросов на
StackOverflow, для примера:
Да я, вроде, не троллил. Кое-что почитал, хоть и не на stackoverflow. А отзывы
тех, кто пользуется лучше, чем куча разрозненных статей, в каждой из которых
говорится противоположное (и лучше, чем выискивание отзывов фиг знает где).

Re: Среды разработки

On 2012-10-16, Victor Wagner wrote:

 А проектировать?

 А для этого существует понятия mind mapping и сoncept mapping.

Может для презентаций и подойдет, а вот ручку и листочек (фломастер и доску)
никто не отменял.

Порисовали, договорились, сфотографирывали, написали спецификацию,
согласовали, реализовали эскизный проект (proof of concept).

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nlra96s@gavenkoa.example.com

Re: Среды разработки

On 2012-10-16, Alexander Danilov wrote:

 Да, это должна быть весьма извращённая фантазия. :-) Проще взять cygwin.

 А пробовали брать? Я пробовал, пользуюсь mingw только когда долго в винде
 приходится сидеть, а так проще какой-нибудь однофайловый интерпретатор
 взять.

А какие проблемы - не можем запустить setup.exe?

Или трудности с английским: http://cygwin.com/cygwin-ug-net.html ??

К тому же в комплекте 2 кросскомпилятора: Mingw и свежий W64 (который для i686
и AMD64). По ABI оба совместимы с вендором.

И к тому же make/cmake, perl/python, apache/lighttpd, emacs/vim  - все из
коробки. Мало - Cygwin ports:

  ftp://sourceware.org/pub/cygwinports/portslist.txt

Мало - cygport:

  git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqyn8u8w@gavenkoa.example.com

Re: Среды разработки

On 2012-10-16, Артём Н. wrote:
Кстати, он из под Linux может создавать виндовые инсталляторы (я почему-то
думал, что под Linux - только для Linux)?
Ему нужен MinGW?

Он то только для Windows и создает...

Которые не нужны нафиг. Потому что, среда всё обеспечивает сама. Особенно
такая
монструозная фигня, как MSVS 2012, которая поддерживает всё, что навыпускал
микрософт (в плане языков и библиотек), содержит встроенную поддержку VCS,
работу с СУБД и какую-то фигню для взаимодействия в команде (я в ней особо
не
разбирался, просто чуть потыкал) и кучу ещё лишнего.
Какие, нафиг, make и консольные компиляторы?

Вы работили над крупными, долгосрочными проектами в команде??

Еще очень полезно знать что стандартный виндовый интерпетатор команд
cmd.exe не такой убогий, как обычно считают а практически представляет
собой полноценный c-shell со встроенным awk. Синтаксис, конечно
кривоватый и неудобный, но возможности есть.
Как-бы, вы в будущем?
На данный момент (в win-7, поскольку о 8 я не знаю), стандартный cmd.exe от
Awk
не имеет НИЧЕГО.
Если вы имеете ввиду расширения команды set, то подстановки не дотягивают даже
до уровня csh, не говоря уж о Bash.

Зато работает с DOS времен, кажется в Win2000 было расширение комманд. Я
активно использую расширеный режим.

Другое дело, что есть нехило навороченный PowerShell, который в плане
навороченности (судя по сравнению в вики) обгоняет даже *nix оболочки.

Нету, например, в WinXP.

--
Best regards!

Re: Среды разработки

18.10.2012 23:24, Oleksandr Gavenko пишет:
On 2012-10-16, Артём Н. wrote:
Кстати, он из под Linux может создавать виндовые инсталляторы (я почему-то
думал, что под Linux - только для Linux)?
Ему нужен MinGW?
Он то только для Windows и создает...
Мда...

Другое дело, что есть нехило навороченный PowerShell, который в плане
навороченности (судя по сравнению в вики) обгоняет даже *nix оболочки.
Нету, например, в WinXP.
С него уже потихоньку слезают.

Re: Среды разработки

On 2012-10-16, Артём Н. wrote:

 Да, есть. Использую Valgrind. Показывает не самые внятные сообщения.

 Потом приходится бегать по километровому логу, периодически переключаясь
 между ним и редактором.

А в Emacs это не проблема...

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87objz8ttt@gavenkoa.example.com

Re: Среды разработки

16.10.2012 21:56, Alexander Danilov пишет:
On 16.10.2012 21:30, Артём Н. wrote:
16.10.2012 21:18, Alexander Danilov пишет:
On 16.10.2012 18:41, Sciko Good wrote:
16 октября 2012 г., 11:24 пользователь Victor Wagner
vi...@wagner.pp.ru написал:
Еще очень полезно знать что стандартный виндовый интерпетатор команд
cmd.exe не такой убогий, как обычно считают а практически представляет
собой полноценный c-shell со встроенным awk. Синтаксис, конечно
кривоватый и неудобный, но возможности есть.

в cmd.exe кое-что есть, и сделать при должной фантазии кое-что можно,
но за это время дешевле поискать awk, tcl или lua, они и для dos есть.
Зато потом поддерживать будет проще.
Да, это должна быть весьма извращённая фантазия. :-)
Проще взять cygwin.
А пробовали брать? Я пробовал, пользуюсь mingw только когда долго в винде
приходится сидеть,
а так проще какой-нибудь однофайловый интерпретатор взять.
Он стоит на виртуалке. И давным давно на XP стоял. Нормально.

Re: Среды разработки

On 2012-10-16, Артём Н. wrote:

 Неужели в c++11 добавили автоматические управление памятью? Каюсь, не
 нашёл. По крайней мере сборки мусора там нет точно.
 Зато есть библиотеки с умными указателями, коллекциями и прочим. И классы, в
 которых очистку возможно произвести в деструкторе. В отличие от C, где нет
 вообще ничего.

http://harmful.cat-v.org/software/c++/linus
http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
http://harmful.cat-v.org/software/c++/rms

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3un8tjq@gavenkoa.example.com

Re: Среды разработки

18.10.2012 23:26, Oleksandr Gavenko пишет:
 On 2012-10-16, Артём Н. wrote:
 
 Да, есть. Использую Valgrind. Показывает не самые внятные сообщения.
 
 Потом приходится бегать по километровому логу, периодически переключаясь
 между ним и редактором.
 
 А в Emacs это не проблема...
Ну да. И психиатр в Emacs тоже встроен. Только я пользуюсь vim.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50805a61.4040...@yandex.ru

Re: Среды разработки

On 2012-10-16, Артём Н. wrote:

 Есть факт: C++ считается необходимым языком, как бы вы к нему не относились.
 Написано на нём всего дохрена.

Есть факт - новые софтверные комерческие проекты в вебе. Там нет места C++.

http://ru.wikipedia.org/wiki/Проблема_2038_года будет не из-за COBOL, а из-за
C++.

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fw5b8tas@gavenkoa.example.com

Re: Среды разработки

18.10.2012 23:38, Oleksandr Gavenko пишет:
 On 2012-10-16, Артём Н. wrote:
 
 Есть факт: C++ считается необходимым языком, как бы вы к нему не относились.
 Написано на нём всего дохрена.
 Есть факт - новые софтверные комерческие проекты в вебе. Там нет места C++.
Ну вы сравнили. C++ для web разработки, когда есть куча других языков,
ориентированных на это и считающихся стандартом (или хотя бы имеющие кучу
специфичных библиотек, фреймворков, готовых систем и наработок). Факт широкого
использования это как-то отменяет?

 http://ru.wikipedia.org/wiki/Проблема_2038_года будет не из-за COBOL, а из-за
 C++.
C++ причём? Проблема из-за сохранения времени в 32-х битном значении. Какое
отношение она имеет _исключительно_ к C++?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50805c74.2090...@yandex.ru

Re: Среды разработки

Кстати, есть ObjectC.
При первом знакомстве мне очень даже понравился.
Весьма элегантный язык.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50805ca6.9010...@yandex.ru

Re: Среды разработки

18.10.2012 11:39, Alexander Galanin пишет:
On Wed, 17 Oct 2012 23:15:36 +0400
Артём Н. artio...@yandex.ru wrote:

17.10.2012 00:37, Alexander Galanin пишет:
On Tue, 16 Oct 2012 23:01:43 +0400
Артём Н. artio...@yandex.ru wrote:

В чём проблема написать скрипт или скопировать файл, а потом его
отредактировать? Будто IDE с умолчательными настройками всегда создаёт ровно
то, что нужно.
Проблема в том, что:
1. Его надо будет каждый раз редактировать.
2. Он будет работать на Linux. Он не един (хотя, в принципе, есть cygwin, тут
вопрос спорный).
3. Его надо написать. Когда уже есть готовое. И, к тому же, надо серьёзно
подумать над его написанием (там же не просто вызов программ требуется, но ещё и
всякие интеграции с редактором и прочее).

Re: Среды разработки

On 2012-10-15, Артём Н. wrote:

Есть Cygwin в Windows.
Это в крайнем случае. Хотелось бы приложение, которое не тащит никаких лишних
DLL за собой и не завязано на Cygwin.

Про кросскомпиляторы отписался тут:

http://permalink.gmane.org/gmane.linux.debian.user.russian/114398

Смотрим на http://mingw-w64.sourceforge.net/

И вообще:

$ sudo apt-get install mingw-w64-dev # W64

$ sudo apt-get install mingw32-runtime # старый MinGW

Если нужно что бы Emacs понимал пути в стиле Windows, но хочется утилиты GNU
-
нативный Emacs + cygwin-mount.el:
Я пользуюсь Vim.

Я пользуюсь обоими (врага нужно знать в лицо :).

http://www.gnu.org/fun/jokes/ed.msg.html

и мои любимые:

http://www.dina.dk/~abraham/religion/vi-tutorial.html
http://www.dina.dk/~abraham/religion/editors-101.html

А еще Eclipse, NetBeans, MSVC, и десятком других (проприетарных) по долгу
службы.

В 2012 заметен тренд любви к:

http://www.sublimetext.com/

Я даже посмотрел мастер-классы по Sublime на Youtube:

http://www.youtube.com/results?search_query=sublime+editor

Вдруг Emacs чего то не может чего есть в Sublime?

--
Best regards!

Re: Среды разработки

On 2012-10-18, Артём Н. wrote:

http://wiki.apidesign.org/wiki/Environment
http://wiki.apidesign.org/wiki/LibraryWithoutImplicitExportIsPolynomial
http://wiki.apidesign.org/wiki/LibraryReExportIsNPComplete

Начать можно с
http://wiki.apidesign.org/wiki/Main_Page
Любопытный сайтик. Спасибо.

Да, вики в поддержку одноименной книги. Автор - сооснователь проекта NetBeans,
он как раз разрабатывал модульную архитектуру.

Вместо того что бы тролить в листе выполните пару поисковых запросов на
StackOverflow, для примера:
Да я, вроде, не троллил. Кое-что почитал, хоть и не на stackoverflow. А отзывы
тех, кто пользуется лучше, чем куча разрозненных статей, в каждой из которых
говорится противоположное (и лучше, чем выискивание отзывов фиг знает где).

Хорошо. Знаете ли Вы что Eclipse, NetBeans, Mozilla - это платформы
(контейнеры с кучей модулей)?

https://developer.mozilla.org/en-US/docs/The_Mozilla_platform
http://www.eclipse.org/platform/
http://netbeans.org/features/platform/

В этих контенерах за множество лет появились модули с отточеными интерфейсами.
Они действительно pluggable. Как и в случае Emacs, просто допилите поддержку
нехватающего вам языка.

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

Сейчас возможности шире - можно посмотреть скринкаст и понять все в действии:

http://vimcasts.org/episodes/archive
http://emacswiki.org/emacs/EmacsScreencasts
http://netbeans.org/kb/docs/intro-screencasts.html

Просто гугли:

git screencast
debian screencast

Я просмотрел кучу обзоров IDE. Читаю release notes к major релизам основных
продуктов. Как говорится

Ну, а _здесь_, знаешь ли, приходится бежать _со всех ног_, чтобы только
остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно
бежать по меньшей мере вдвое быстрее !

--
Best regards!

Re: Среды разработки

2012-10-18 Пенетрантность Vladimir Zhbanov

On 2012-10-18, Артём Н. wrote:

18.10.2012 23:38, Oleksandr Gavenko пишет:
On 2012-10-16, Артём Н. wrote:

Есть факт: C++ считается необходимым языком, как бы вы к нему не относились.
Написано на нём всего дохрена.
Есть факт - новые софтверные комерческие проекты в вебе. Там нет места C++.
Ну вы сравнили. C++ для web разработки, когда есть куча других языков,
ориентированных на это и считающихся стандартом (или хотя бы имеющие кучу
специфичных библиотек, фреймворков, готовых систем и наработок). Факт широкого
использования это как-то отменяет?

Нужно понимать это так:

С++ только для поддержки старых проектов. Новые проекты не будут на С++
(нужны весские доводы).

К тому у С++ отсутствует бинарная совместимость между вендорами и между
версиями у одного вендора. Т.е. библиотеками и фреймворками особо не
поторгуешь, только конечные приложения.

Т.е. С++ как COBOL. О чем собственно ниже:

http://ru.wikipedia.org/wiki/Проблема_2038_года будет не из-за COBOL, а из-за
C++.
C++ причём? Проблема из-за сохранения времени в 32-х битном значении. Какое
отношение она имеет _исключительно_ к C++?

Это сарказм.

--
Best regards!

Re: Среды разработки

On Thu, Oct 18, 2012 at 10:32:57PM +0300, Oleksandr Gavenko wrote:
...
 http://harmful.cat-v.org/software/c++/linus
 http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
 http://harmful.cat-v.org/software/c++/rms

Первая история понятна.

Вторая интересна, но сильно надуманна, по-моему. Если Страуструп
действительно говорил бы такое, то, думаю, он был бы гениальным
шутником, филантропом, даже филопрограммером (заботившимся исключительно
о сирых и убогих выпускниках мехмата МГУ, в умопомрачении отправившихся
в колхоз Телелюй вместо ждавшей их с распростёртыми объятьями
силиконовой долины). Особенно понравилась сложность и запутанность иксов
как вдохновляющая идея и побудительный мотив. Иксы, тем не менее, как и
Юних, продолжают вдохновлять общественность на подвиги.

Что касается третьего, то его позиция особенно интересна в связи с тем,
что он также очень не любил (почти ненавидел) один довольно громко
восхваляемый (а некоторыми чуть прямо не проклинаемый) здесь скриптовый
язык (не к ночи будет упомянут, а то возгорятся вновь страсти) и
воспевал другой, скобколюбивый. Но тут же вспоминается, что кроме него
были и лица, которые даже и знаменитый Си вместе с Юниксом хотели бы
видеть преданными забвению (находя в нём сплошь пороки да изъяны), и
видели исключительно лишь один наипрекраснейший круглоскобковый язык как
панацею от всех бед. И это навевает... 

Не, я не в коей мере не за плюс-плюсы (я с ними практичто не знаком).
Однако, сцылки показательные.

-- 
http://vzhbanov.byethost33.com


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121018212820.GB3939@localhost.localdomain

Re: Среды разработки

2012-10-17 Пенетрантность Alexander Galanin

On Tue, 16 Oct 2012 22:57:29 +0400
Артём Н. artio...@yandex.ru wrote:

  С чего б статически собранный бинарник весил меньше? Они обычно ой какие
  пухлые.
 В сравнении с tclkit. Там где-то говорили про мегабайты. Для D-7 мин. бинарник
 весил около 300К. Для BCB аналогично. Для MSVS, меньше.

Взял простенькую программу, сделанную в билдере, с библиотеками, которых ей не
хватало в системе. Оно правда при статической линковке меньше занимает?

total 3,5M
-rwxrwxrwx  1 galanin 0  65K 2012-08-26 16:32 program.exe
-rw-rw-rw-  1 galanin 0  22K 2012-10-15 12:43 borlndmm.dll
-rw-rw-rw-  1 galanin 0 1,5M 2003-01-30 06:04 cc3260mt.dll
-rw-rw-rw-  1 galanin 0 669K 2003-01-30 06:04 rtl60.bpl
-rw-rw-rw-  1 galanin 0 1,3M 2002-02-01 17:00 vcl60.bpl

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121017102232.0e8f6e622256ba35421e0...@galanin.nnov.ru

Re: Среды разработки

16.10.2012 23:21, Alexander Danilov пишет:
что после этого всякого,
утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно
неполноценным родственником Джорджа Буша младшего, на котором природа не
то, что
отдохнула, она даже и не напрягалась.
Ну, по-моему, никто не говорит о простоте.
Полуркайте, Как выучить C++ за 21 день. ;-)

Я вас нах... не посылал, так что тоже будьте вежливы.
Я вас, вроде, тоже не посылал. А баяна этого вы, похоже, не знаете...

Немного извращённо: лучше уж perl взять.
Хотя, идея любопытная.
Хоть и не имеет прямого отношения к RAD.

А perl так вообще позволял и количество system(...) в разы сократить. И
ничего
быстрее ещё пока не придумали. Другое дело, что перловый код после написания
ещё
и читать бывает надо, но тут уж c++/pascal от него не отстаёт, одна строчка
перлового кода заменяет 10-20 c++/pascal, перл тяжелее читать, а c++/pascal
дольше читать, ибо кода больше.
Зависит от того, как написано.

Но вопрос был не про языки, а про IDE.

Re: Среды разработки

17.10.2012 02:36, Alexander Danilov пишет:
 Если не использовать одну из основных фишек перла - высокую плотность кода, то
 тогда лучше на перле не писать вообще, я так и поступил - у меня уже давно 
 язык
 для скриптов по умолчанию Tcl,
 редко Python - когда есть готовый модуль, которого нет для Tcl. Надо бы
 переходить на MosML или Hugs, но как-то всё по случается об это вовремя
 вспомнить - руки начинают набирать тиклевый код ещё до того, как вспоминаешь о
 том, что надо бы что-то ещё попробовать.
o.O На Tcl правда возможно программировать по пьяни? :-)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507ef7af.70...@yandex.ru

Re: Среды разработки

17.10.2012 01:57, Sciko Good пишет:
16 октября 2012 г., 22:22 пользователь Alexander Danilov
alexander.a.dani...@gmail.com написал:
On 16.10.2012 22:06, Артём Н. wrote:
Да какая разница, я на С++ с шаблонами такое видел, что после этого всякого,
утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно
неполноценным родственником Джорджа Буша младшего, на котором природа не то,
что отдохнула, она даже и не напрягалась.
+1 Считаю лучшим способом агитации против C++ дать прочитать книгу
Александреску, а потом учебник Lisp или Haskell.
Я не агитирую за.
Есть плюсы в C++.
Минусов больше, чем два.

16 октября 2012 г., 22:27 пользователь Alexander Galanin
a...@galanin.nnov.ru написал:
При правке из отладчика рассматриваемый контекст ограничен одной
функцией, потому годится для совсем очевидных ошибок. В других же
случаях решает ошибку долгая медитация над кодом, по сравнению с которой
10 секунд на запуск gdb роли не играют.
Буквально вчера потратил полчаса на поиск ошибки возникающей очень
редко. И это при том, что я даже в C стараюсь писать исключительно
чистые (в смысле ФП) функции. Но пока я эту функцию локализовал и
медитировал над казалось бы уже 100 раз выверенным кодом...
Какая ошибка?
А средства автоматизации для отлова есть?

16 октября 2012 г., 22:55 пользователь Артём Н. artio...@yandex.ru
написал:
16.10.2012 22:27, Alexander Galanin пишет:
On Tue, 16 Oct 2012 21:53:38 +0400
Артём Н. artio...@yandex.ru wrote:
Мне надо:
1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс.
Хороший текстовый редактор. А их всего два.
Вероятно.
Тогда такой вопрос.
Есть ли в Vim подстановка блоков кода: я пишу for, а весь цикл со скобками и
переменной внутри мне подставляется автоматически?
Юзайте clang_comlete
Плагин?

Насчёт двух, вы утрируете. Scite и прочее?
Даже близко не стоит.
Помню, в Scite много чего было, включая регэкспы, подсветки и дополнения.
Он, конечно, не так наворочен, как Vim (в котором мне ещё разбираться и
разбираться), но весьма серьёзный редактор.
Помнится был Tea (и ещё спец. редакторы для HTML, например), да и Emacs далеко
не один есть.

2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
добавлении модуля).
А этот пункт?
Правильно написанный Makefile не требует переписывания в таких случаях.
Но его надо писать. И это непросто. Чем плоха автоматизация его создания?

6. Проверить модуль с разными наборами данных.
Unit testing.
Само собой.
И в IDE. Абсолютно тот же самый.
Разница лишь в том, что вызывает его IDE, а не пользователь.
Да? И как оно догадывается, что нужен unit test? Неужели через astral.dll?
В плане того, что есть библиотеки, встроенные в IDE. :-) И простой интерфейс для
модульного тестирования. Я не разбирался с этим, если честно, но видел пункт,
что оно есть.

И управляет им IDE.
Управлять юнит-тестом? Это что-то новенькое! А на фига?
Вызовом тестов, созданием отладочной версии, созданием релиза.

3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а
не на
warning).
Команда :номер-строки в виме. При компиляции из самого вима оно
перескакивает автоматом.
Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока
что, пишу в нём, поскольку на той машине данные возможно разные получать) он
перескакивает на всякие варнинги.
Варнинги вообще-то тоже ошибки. И если они так не нравятся, то может
проще их отключить совсем?
Например, я передаю константный аргумент функции (указатель на первый элемент
списка). В функции инициализирую значение указателя этим аргументом. Старый
компилятор орёт, что я могу поменять через этот указатель неизменяемую область
памяти.
1. Это ошибка, если я ничего не меняю, а просто хожу по списку и, например,
печатаю элементы?
2. Не помню какая pragma это выключает.
3. В идеале хотелось бы окно снизу, в котором отображаются ошибки:
кликнул/выбрал - перешёл. Это удобно.

А мне нужно, чтобы я набрал make, и он остался
в том же файле.
Это настраивается.
Как?

А ошибку, желательно, вообще открыл в другом окне.
И это тоже.
Как?

5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
дизассемблерный листинг.
Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
не прижился он у меня из-за неиспользуемости.
Да, а в IDE, я всё это вижу в том же редакторе.
И сильно это помогает? Правильные ответ: нисколько.
Это помогает не переключаться между отладчиком и редактором. И позволяет не
разбрасывать внимание. Это удобно.

При правке из отладчика рассматриваемый контекст ограничен одной
функцией, потому годится для совсем очевидных ошибок. В других же
случаях решает ошибку долгая медитация над кодом, по сравнению с которой
10 секунд на запуск gdb роли не играют.
Облегчить процесс поиска может watch. Да, в gdb есть, но как-то...
В gdb очень хороший watch. А в комплекте с print, вообще песня.

Плюс, есть false-positives, особенно, при использовании глобальных

Re: Среды разработки

17.10.2012 00:27, Sciko Good пишет:
16 октября 2012 г., 18:56 пользователь Артём Н. artio...@yandex.ru
написал:
16.10.2012 00:51, Sciko Good пишет:
Я пишу в основном расчётные консольные приложения, а когда к ним нужна
графическая морда, использую GTK, т.к. считаю Qt фактически является
одной большой библиотекой, да и последние тенденции к превращению её
во фрейморк для JavaScript не радуют.
Не слежу. Не знаю. В смысле?
Посмотрите на последние версии Qt -- там интерфейс пишется на
JavaScript, а создание интерфейса с помощью С++ уже помечено как
устаревшее. Nokia писала, что в Qt5 вообще интерфейс будет писаться
только на JavaScript.
Разве это плохо? При наличии вменяемого движка JS, конечно? На их месте, мне
кажется, я бы тоже к этому пришёл: хочу скриптовый интерфейс и маленький
настраиваемый движок, выполняющий основные функции.

Code::Blocks вообще ужасен.
Вот здесь возможно сильно подробнее?
Текстовый редактор на уровне блокнота, нет интеграции с DVCS, make не
создаёт, а каждый раз собирает проект сама, нет поддержки других
языков кроме C++. Разве уже это не повод не использовать эту поделку?
О, увидел после того, как ответил. :-)
Спасибо.
А вы про какую версию?
Я почитал, она была описана, как весьма перспективная среда. И редактор там со
всеми подсветками и прочими плюшками.
Да, если нет поддержки ничего другого, кроме C++, - не вариант. Но, может, есть
плагины?

Netbeans требует таких плясок с бубуном, что убивает
всё желение с ним работать.
Что там не так?
Чтобы что-то там заработало, надо настраивать всю среду. Причём долго
и весьма неочевидными способами.

Eclipse страшно тормозит. Именно после него я поверил, что Java тормозит.
Серьёзно? Eclipse, вроде бы, не на Java написан? И не исключительно для Java?
А почему у неё сырцы сплошь джавовские?
Не читал. Понятно.

Где тормозит? На какой системе?
Debian, Ubuntu, AltLinux, Fedora, CentOS, Mandriva, Rosa, openSUSE,
SLE -- тормозит везде. В других на пробовал.
В смысле, на какой машине? Какие характеристики железа?

Lazarus представляет из себя копию Delphi со всеми его минусами.
И плюсами.
Фактически единственный сомнительный плюс Dephi -- его преподают в
школах и вузах.
Там действительно простое написание кода от интерфейса. RAD.

А их хватает, ведь не зря Dephi называют принцем быдлокодерских IDE.
Штамп. RAD и разработка от интерфейса позволяют быстро наклепать прототип.
Вот именно это и является штампом .Быстро наклепать прототип позволяет
python, perl, lisp, haskell и т.п., но не Dephi, т.к. изначально
паскаль разрабатывался вовсе не для быстрой разработки и не содержит
даже банального синтаксического сахара.
Так Delphi - не Pascal. Там сахара хватает.

Быстро нарисовать интерфейс
позволяют такие программы как Glade, причём без какой-либо привязки к
языку.
Кросс? Но Glade - только GTK...

Причём, в виде скомпилированной программы. Это делает низким порог вхождения.
У интерпретируемых языков порог вхождения ещё ниже.
Зависит от языка.

И не надо тратить время на компиляцию.
Зато, не повышается ЧСВ, пишущего. :-)

И среднее качество кода, считается, гораздо ниже, чем у MSVS (которая
считается
сложной в освоении).
Кстати, королём быдлокодерских IDE называют именно MSVS ^_^
Вы недавно про Delphi говорили тоже самое. Определитесь. ;-) Хотя, с появлением
C#, акценты наверняка сместились...

В данном случае я хочу
оптимизировать работу там, где вижу возможность оптимизации. Смена
редактора кода реально мне может помочь в плане производительности.
Понятно.
Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
Переключиться между cpp и h я могу через Ctrl+F6.
А в vim?
А в vim ставите скрипт a.vim и получаете этот функционал. Можно
привесить на любое сочетание клавиш.
Честно говоря, не очень въезжаю, как это сделать, в общем случае (когда .c и .h
могут иметь разные названия), не прибегая к сложному разбору текста.

Как оно вообще используется и где,
Что там под windows?
Рисуешь интерфейс в редакторе, подключаешь в коде библиотеку,
описываешь какой сигнал связать с вызовом какой функции, отрисовываешь
окно.
Плюс в RAD - обработчик проще найти.

Жаль, скриншотов под Linux нет.
Запустите Synaptic. Он тоже использует Glade.
Ну, типичный GTK интерфейс.
Честно говоря, GTK меня раздражает.

16 октября 2012 г., 19:11 пользователь Артём Н. artio...@yandex.ru
написал:
16.10.2012 18:41, Sciko Good пишет:
Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.
Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.
Вы удивитесь, как много на нём всего понаписали и продолжают писать.
Не удивлюсь. Знаю, что пишут.

C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а
спрашивать про его поддержку какими-либо средами, думаю не стоит).
.NET использует фактически один вантуз. В остальных ОС с ним будут
весьма большие проблемы. И в GNU/Linux его не любят. Почему? Читайте
RMS.
Да и меня как-то

Re: Среды разработки

17.10.2012 00:35, Alexander Galanin пишет:
On Tue, 16 Oct 2012 22:55:25 +0400
Артём Н. artio...@yandex.ru wrote:

Но, при сложной форме, в текстовом описании интерфейса ещё проще
запутаться.
Разбивай построение интерфейса на отдельные небольшие функции с внятными
названиями. Рисовалка такой возможностив принципе не предоставляет.
Ну, думаю, предполагается, что пользователь может удержать не очень большое
число элементов в фокусе внимания. И надо создавать интерфейс так, чтобы
он не
был перегружен. Он сам разбивается на отдельные компоненты.
То ты говоришь про сложную форму, то говоришь, что они не нужны.
Определись.
Сложная может состоять из групп блоков.
А блок — это что? CGroupBox с накиданными на него виджетами или что-то
иное?
Любой группирующий логически элемент. Самый простой - групбокс или панель.

Наоборот, IDE предназначено для того, чтобы уменьшить расход ресурсов на
непроизводительные действия (и автоматизировать выполнение требуемых
действий).
О чём и спрашиваю.
Надо чётко понимать, какие действия автоматизируются, чем за это
приходится платить и каков получается полезный выход. Ниже я написал,
что оптимизация в одном месте даёт проигрыш в другом.
Я и пытаюсь понять.

Есть ли в Vim подстановка блоков кода: я пишу for, а весь цикл со скобками и
переменной внутри мне подставляется автоматически?
Необходимость вбивать постоянно одни и те же куски кода говорит только о
том, что язык программирования под задачу выбран неправильно.
Так почти на любом нормальном языке возможно построить код так, что вбивать не
придётся. Вопрос в сложности кода.

Подходящий
язык лаконичен и не требует длинных конструкций вида «public Borsch
borsch = new Borsch();» с кучей повторяющихся слов.
Подходящий для чего?
Ada - не подходящий?

2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
добавлении модуля).
А этот пункт?
Это к юнит-тестам. Ах, да, makefile может генериться каким-нибудь cmake.
Из чего генериться (не копал CMake)?

6. Проверить модуль с разными наборами данных.
Unit testing.
Само собой. И в IDE. Абсолютно тот же самый. Разница лишь в том, что
вызывает его IDE, а не пользователь. И управляет им IDE.
А что там делает IDE? Выводит дерево с тестами и с него позволяет
перепругнуть на код теста? Ну да, удобно, но не критично.
Не критично. Но удобно. Так из маленьких удобно всё и складывается: соль в
деталях...

3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а
не на
warning).
Команда «:номер-строки» в виме. При компиляции из самого вима оно
перескакивает автоматом.
Почему-то у меня сейчас в старом Vim (очень старый на старом Linux, но, пока
что, пишу в нём, поскольку на той машине данные возможно разные получать) он
перескакивает на всякие варнинги. А мне нужно, чтобы я набрал make, и он
остался
в том же файле. А ошибку, желательно, вообще открыл в другом окне.
И?
Так настрой инструмент, если знаешь, что тебе от него нужно. Например,
не говори компилятору -Wall.
Я хочу видеть все варнинги. Но я не хочу, чтобы редактор автоматически на них
переходил. В IDE, например, возможно выбрать в окне снизу и перейти. Это удобно.

4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто
Segmentation fault).
Нету.
Где нет? В gdb есть. В clewn в том числе и гламурные всплывающие окошки
с значением переменной показываются.
А что вам в clewn не понравилось?
Раньше я не слышал о нём.
Посмотрю, может поставлю.

5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
дизассемблерный листинг.
Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но
не прижился он у меня из-за неиспользуемости.
Да, а в IDE, я всё это вижу в том же редакторе.
Не в том же редакторе, а в соседнем окне. Ровно так же, в соседнем окне,
можно смотреть на gdb в терминале.
Я могу выделить мышкой нужный кусок или просто кликнуть в конт. меню
Disassemble и увидеть то, что нужно.
Как это сделать в GDB?

Кстати, очень грустно выглядит программист, который в отладчике ловит
ошибку, проявляющуюся не ранее 135-й итерации цикла. Столько лишних
нажатий на клавиши.
Кажется, даже в старом GDB есть условные брэкпоинты?
Ну вот смотри, тебе надо знать три разных приёма работы:
1. ставить обычный breakpoint
2. ставить условный (как показывает практика, дети IDE этим долго не
могут научиться пользоваться)
Почему? Во всех нормальных IDE есть условные брейки.

3. делать отладочную печать на случай, когда условие останова
сформулировать сложно или надо

Re: Среды разработки

17.10.2012 00:37, Alexander Galanin пишет:
 On Tue, 16 Oct 2012 23:01:43 +0400
 Артём Н. artio...@yandex.ru wrote:
 
 И главный вопрос: как всё это интегрировать, чтобы оно каждый раз запускалось
 автоматически, и не приходилось всё перенастраивать для каждого проекта?
 Что именно перенастроить? Свою голову, в которой лежит знание о том,
 какие действия делаются каким инструментом?
Перенастроить сценарий или мэйкфайл, который вызывает инструменты автоматически.
Или каждый раз вызывать всё вручную?
Упорно набирать в консоли каждую команду?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507f03d8.8070...@yandex.ru

Re: Среды разработки

2012-10-17 Пенетрантность Alexander Danilov

17.10.2012 10:22, Alexander Galanin пишет:
 On Tue, 16 Oct 2012 22:57:29 +0400
 Артём Н. artio...@yandex.ru wrote:
 
 С чего б статически собранный бинарник весил меньше? Они обычно ой какие
 пухлые.
 В сравнении с tclkit. Там где-то говорили про мегабайты. Для D-7 мин. 
 бинарник
 весил около 300К. Для BCB аналогично. Для MSVS, меньше.
 
 Взял простенькую программу, сделанную в билдере, с библиотеками, которых ей не
 хватало в системе. Оно правда при статической линковке меньше занимает?
 total 3,5M
 -rwxrwxrwx  1 galanin 0  65K 2012-08-26 16:32 program.exe
 -rw-rw-rw-  1 galanin 0  22K 2012-10-15 12:43 borlndmm.dll
 -rw-rw-rw-  1 galanin 0 1,5M 2003-01-30 06:04 cc3260mt.dll
 -rw-rw-rw-  1 galanin 0 669K 2003-01-30 06:04 rtl60.bpl
 -rw-rw-rw-  1 galanin 0 1,3M 2002-02-01 17:00 vcl60.bpl
Меньше чего?
Про размеры я выше сказал.
К тому же, не помню точно, но, вроде, он линкует не все функции bpl в
исполняемый файл, а только то, что необходимо: слинкуйте, да посмотрите размер,
что гадать?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507f046c.8000...@yandex.ru

Re: Среды разработки

On 17.10.2012 22:22, Артём Н. wrote:

16.10.2012 23:21, Alexander Danilov пишет:

что после этого всякого,
утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно
неполноценным родственником Джорджа Буша младшего, на котором природа не то, что
отдохнула, она даже и не напрягалась.

Ну, по-моему, никто не говорит о простоте.
Полуркайте, Как выучить C++ за 21 день. ;-)

Я вас нах... не посылал, так что тоже будьте вежливы.

Я вас, вроде, тоже не посылал. А баяна этого вы, похоже, не знаете...

Как выучить C++ за 21 день - я про это, такое только умственно отсталым
предлагают :)

Это не RAD. Это компоненты.

В плане обработки текста.
Но минусы:
1. Кроссплатформенность хромает.

Каким образом она хромает? Все инструменты кросcплатформенные дальше некуда.

2. Скорость падает.
Как бы не наоборот. Скорость разработки точно возрастает, надёжность софта точно, да и на Си
написать то, что перл умеет лучше всего, да ещё чтоб и работало быстрее, чем перл, это надо быть
сишником среднего уровня и выше, что в наши дни большая редкость.

3. Связь между awk и C-шным кодом через костыли.

Стандартные системные IPC - костыли? Не согласен, вот писать формирование отчётов на Си - это не
просто костыли, это [*** ну тут такой нехороший эпитет ***]. Ибо сегфолты и коры дампы постоянно по
причине кривости пользовательского ввода и трудности проверки его сишными средствами.

Немного извращённо: лучше уж perl взять.
Хотя, идея любопытная.
Хоть и не имеет прямого отношения к RAD.

Имеет, ибо Unix и есть RAD.

А perl так вообще позволял и количество system(...) в разы сократить. И ничего
быстрее ещё пока не придумали. Другое дело, что перловый код после написания ещё
и читать бывает надо, но тут уж c++/pascal от него не отстаёт, одна строчка
перлового кода заменяет 10-20 c++/pascal, перл тяжелее читать, а c++/pascal
дольше читать, ибо кода больше.

Зависит от того, как написано.

Но вопрос был не про языки, а про IDE.

Re: Среды разработки

2012-10-17 Пенетрантность Alexander Danilov


On 17.10.2012 22:23, Артём Н. wrote:

17.10.2012 02:36, Alexander Danilov пишет:

Если не использовать одну из основных фишек перла - высокую плотность кода, то
тогда лучше на перле не писать вообще, я так и поступил - у меня уже давно язык
для скриптов по умолчанию Tcl,
редко Python - когда есть готовый модуль, которого нет для Tcl. Надо бы
переходить на MosML или Hugs, но как-то всё по случается об это вовремя
вспомнить - руки начинают набирать тиклевый код ещё до того, как вспоминаешь о
том, что надо бы что-то ещё попробовать.

o.O На Tcl правда возможно программировать по пьяни? :-)




Можно, но не забывайте предохраняться :)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507f130b.1040...@gmail.com

Re: Среды разработки

2012-10-16 Пенетрантность Victor Wagner

On 2012.10.15 at 20:58:20 +0400, Артём Н. wrote:

15.10.2012 00:35, Dmitry Fedorov пишет:
15 октября 2012 г., 2:07 пользователь Артём Н. написал:
Расскажите про среды разработки в Linux, которыми пользуетесь.

Краткое знакомство с тем, что есть, показало наличие нормальных сред.

Обычной (нормальной) средой разработки в UNIX
является набор следующих компонент:
оболочка пользователя, make, gcc, редактор текстов для программистов, SCM.
Мда?
А под windows компилировать, используя MinGw?

Да, используя пакет mingw32 в Debian. Потому что разрабтаывать софт для
кофеварок можно, но использовать кофеварку в качестве рабочего места
программиста - глупо. Кстати, в Debian есть еще пакет nsis, который
позволяет создавать полнокровыне виндовые инсталляторы.

А интерфейсы писать?

А интерфейсы надо именно писать. Язык выраженный в виде plain text -
существенно более мощный инструмент, чем любая рисовалка. Потому что
язык позволяет оперировать в терминах если ... то .. иначе и повторять
... до ..., не говоря уж о рекурсии и функциональной декомпозиции, а
рисовалки - нет.

А проектировать?

А для этого существует понятия mind mapping и сoncept mapping.

Re: Среды разработки

2012-10-16 Пенетрантность Sciko Good

16 октября 2012 г., 8:31 пользователь Ivan Shmakov
oneing...@gmail.com написал:
 Для несложных GUI я бы использовал Tk для Perl.

А у него есть аналог Glade? Просто моих коллег, использующих вантуз, я
заставляю на нём рисовать желаемый GUI. Мне остаётся проверить и
прикрутить его к коду. Как бонус, нет проблем с претензиями типа Куда
ты засунул эту очень нужную опцию? и при желании можно быстро
переделать GUI без пересборки.

 (Впрочем, не
 вполне ясно, какого рода GUI может потребоваться расчетному
 коду?)

Не в качестве рекламы, но гляньте вот эту ссылку:
http://linecross.ru/linemech.htm (мы уже работаем по созданию
свободного аналога, но увы без финансирования дело движется медленно).
Примерно вот так выглядит интерфейс половины программ.

Re: Среды разработки

16.10.2012 00:54, Alexander Danilov пишет:
Итог: занимает мало места, можно уложить на usb (при необходимости), на
выходе
один бинарник под нужную платформу + файлы данных или упакованный
инсталлятор.
Но с Tk интерфейсом.

К тому же, что понимается под кроссплатформенным бинарником?
Скомпилированный в машинный код файл или виртуальная машина для Tcl и
скрипт/байт-код, на ней выполняемый?

Под кросплатформенным понимается то, что можно собрать под win32, linux и тд
из
одного дерева исходников:
make win = soft.exe
make linux = soft.elf
make all = make win32 linux
Что соберётся в итоге?
Насколько я понял, кроссплатформенность, в случае с tclkit, обеспечивается
каким-то подобием виртуальной машины?
Так проще под cygwin собрать, и скорость выше будет.

К тому же, небольшое отступление: я писал, что C++ - обязателен.

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.
GUI не причём. Просто C++ используется везде, где ни попадя, поэтому привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И GUI
тут не при чём.

Если уж сильно приспичит, то можно использовать ffidl - расширение для tcl,
загружающее произвольную разделяемую библиотеку и вызывающую все нужные
функции,
или самостоятельно написать расширение на c/c++ и вызывать из tcl. А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
времени нет.
На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.

Re: Среды разработки

16.10.2012 00:40, Alexander Danilov пишет:
 Для меня там главные преимущества - всё в одном файле, остальное работает как
 надо и вопросов не возникает. Ставить в винду git+wiki+кучу гнутых утилит не
 хочется.
Понятно.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d6e91.6070...@yandex.ru

Re: Среды разработки

16.10.2012 00:43, Alexander Danilov пишет:
 On 15.10.2012 21:19, Артём Н. wrote:
 15.10.2012 20:18, Oleksandr Gavenko пишет:
 On 2012-10-15, Alexander Danilov wrote:

 3. Редактор Emacs (если пишу в linux), Vim (если в win)
 Ну да, GVim в Windows не так удобен...
 Вполне удобен, если потратить полчаса на настройку и работать буду наскоками 
 2-3
 недели.
Ну да. Я пока ещё в винде проверку орфографии не прикручивал. Да и хочется иметь
один конфиг на все системы.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d6ee5.8050...@yandex.ru

Re: Среды разработки

15.10.2012 23:54, Иван Лох пишет:
On Mon, Oct 15, 2012 at 10:44:33PM +0400, Артём Н. wrote:
Иван Лох, подскажите как решить ещё несколько задач с Vim.

1. Я обнаружил несколько древних файлов, которые валялись, следующего
содержания:
` Vim Compiler File
Compiler: awk
Maintainer:Artiom N.
Last Change: Sun Aug 13 19:40:17 MSD 2006
каталогах в районе /usr/share/vim.
Куда положить эти файлы в Debian и как включить в конфиг?
~/.vim/compiler
Спасибо. А глобально: /etc/vim/compiler?

2. Есть ли где-то реализация проверки орфографии под windows?
Встроенная проверка орфографии в vim7 может компилироваться штатными
средствами в любой кодировке. О том как это делать есть туча мануалов.
В смысле, встроенный спеллчекер офиса или чего?
Я не знаю, как в винде организована встраиваемая проверка (например, та, что
используется в firefox) и с чем вместе она устанавливается.
Может Vim её там уже использует... Я не помню просто.
Сейчас у меня проверка орфографии в Vim сделана через asplell.
Потом, в общем, буду разбираться.

Re: Среды разработки

2012-10-16 Пенетрантность Sciko Good

16 октября 2012 г., 11:24 пользователь Victor Wagner
vi...@wagner.pp.ru написал:
 Еще очень полезно знать что стандартный виндовый интерпетатор команд
 cmd.exe не такой убогий, как обычно считают а практически представляет
 собой полноценный c-shell со встроенным awk. Синтаксис, конечно
 кривоватый и неудобный, но возможности есть.

А вы точно не путаете cmd.exe с command.com или PowerShell? Просто
ничего даже издали похожего на awk я не нашёл вот тут:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true

Re: Среды разработки

2012-10-16 Пенетрантность Sciko Good

16 октября 2012 г., 18:25 пользователь Артём Н. artio...@yandex.ru написал:
16.10.2012 00:54, Alexander Danilov пишет:
Под кросплатформенным понимается то, что можно собрать под win32, linux и тд
из
одного дерева исходников:
make win = soft.exe
make linux = soft.elf
make all = make win32 linux
Что соберётся в итоге?

Один виндовый бинарник и один эльфийский.

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.
GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.

А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
времени нет.
На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.

Неужели в c++11 добавили автоматические управление памятью? Каюсь, не
нашёл. По крайней мере сборки мусора там нет точно.

Re: Среды разработки

2012-10-16 Пенетрантность Иван Лох

On Tue, Oct 16, 2012 at 06:32:14PM +0400, Артём Н. wrote:
  каталогах в районе /usr/share/vim.
  Куда положить эти файлы в Debian и как включить в конфиг?
  ~/.vim/compiler
 Спасибо. А глобально: /etc/vim/compiler?

Например

/usr/local/share/vim/compiler

Вопрос только, зачем

  2. Есть ли где-то реализация проверки орфографии под windows?
  Встроенная проверка орфографии в vim7 может компилироваться штатными
  средствами в любой кодировке. О том как это делать есть туча мануалов.
 Может Vim её там уже использует... Я не помню просто.
 Сейчас у меня проверка орфографии в Vim сделана через asplell.
Ну и зря
 Потом, в общем, буду разбираться.

vim7 имеет свой спелчеккер
Я понимаю, конечно, что пользоваться гуглем неспортивно

http://www.opennet.ru/base/X/vim_orfo.txt.html

-- 
Иван Лох


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012101612.ga2...@nano.ioffe.rssi.ru

Re: Среды разработки

16.10.2012 11:24, Victor Wagner пишет:
On 2012.10.15 at 20:58:20 +0400, Артём Н. wrote:

Краткое знакомство с тем, что есть, показало наличие нормальных сред.

Потому что разрабтаывать софт для
кофеварок можно, но использовать кофеварку в качестве рабочего места
программиста - глупо.
Логично. Да и удобнее мне здесь (а название и ТРУЪ меня не волнует: была бы
винда мне удобнее (в разных смыслах), сидел бы там). Но обычные люди (другой
вариант, который иногда слышу, - нормальные люди) используют windows. И как-то
их не привлекает перспектива изучения другой ОС. Потому и спрашиваю про кросс.

Кстати, в Debian есть еще пакет nsis, который
позволяет создавать полнокровыне виндовые инсталляторы.
Знаю. Пользовался. Достаточно удобный инсталлятор. Один из лучших.
Небольшой минус (он же и плюс) - каждый инсталляционный пакет - сценарий. Если в
Smart install maker возможно всё сделать несколькими кликами, то, при
использовании NSIS, приходиться чуть думать.

Кстати, он из под Linux может создавать виндовые инсталляторы (я почему-то
думал, что под Linux - только для Linux)?
Ему нужен MinGW?

Впрочем, если вы собираетесь программировать под Windows, неплохо было
бы вам эту систему освоить. И разобраться что в комплект Microsoft
visual studio входит полноценный командно-строчный компилятор cl.exe,
кривоватый но работоспособный make (nmake.exe) и так далее.
Которые не нужны нафиг. Потому что, среда всё обеспечивает сама. Особенно такая
монструозная фигня, как MSVS 2012, которая поддерживает всё, что навыпускал
микрософт (в плане языков и библиотек), содержит встроенную поддержку VCS,
работу с СУБД и какую-то фигню для взаимодействия в команде (я в ней особо не
разбирался, просто чуть потыкал) и кучу ещё лишнего.
Какие, нафиг, make и консольные компиляторы?

Еще очень полезно знать что стандартный виндовый интерпетатор команд
cmd.exe не такой убогий, как обычно считают а практически представляет
собой полноценный c-shell со встроенным awk. Синтаксис, конечно
кривоватый и неудобный, но возможности есть.
Как-бы, вы в будущем?
На данный момент (в win-7, поскольку о 8 я не знаю), стандартный cmd.exe от Awk
не имеет НИЧЕГО.
Если вы имеете ввиду расширения команды set, то подстановки не дотягивают даже
до уровня csh, не говоря уж о Bash.
Другое дело, что есть нехило навороченный PowerShell, который в плане
навороченности (судя по сравнению в вики) обгоняет даже *nix оболочки.

А интерфейсы писать?
А интерфейсы надо именно писать. Язык выраженный в виде plain text -
существенно более мощный инструмент, чем любая рисовалка.
Да, вот только писать сложнее, чем картинки двигать.

Re: Среды разработки

16.10.2012 00:51, Sciko Good пишет:
Не думаю, что моё мнение кому-то будет интересно, но всё же...

Я пишу в основном расчётные консольные приложения, а когда к ним нужна
графическая морда, использую GTK, т.к. считаю Qt фактически является
одной большой библиотекой, да и последние тенденции к превращению её
во фрейморк для JavaScript не радуют.
Не слежу. Не знаю. В смысле?

Мой набор такой: vim+git+glade(только для GUI)+gcc. Но кроме C, я
использую в проектах и другие языки. Иногда бывает проще идею
реализовать на том же Haskell или Perl, чем тупить с C.

Code::Blocks вообще ужасен.
Вот здесь возможно сильно подробнее?

Netbeans требует таких плясок с бубуном, что убивает
всё желение с ним работать.
Что там не так?

Eclipse страшно тормозит. Именно после него я поверил, что Java тормозит.
Серьёзно? Eclipse, вроде бы, не на Java написан? И не исключительно для Java?
Где тормозит? На какой системе?

Lazarus представляет из себя копию Delphi со всеми его минусами.
И плюсами.

А их хватает, ведь не зря Dephi называют принцем быдлокодерских IDE.
Штамп. RAD и разработка от интерфейса позволяют быстро наклепать прототип.
Причём, в виде скомпилированной программы. Это делает низким порог вхождения.
Следовательно, его могут использовать люди, которые не знают, что есть
проектирование.
Причём, ещё использование в школах/институтах тоже налагает свой отпечаток.
И среднее качество кода, считается, гораздо ниже, чем у MSVS (которая считается
сложной в освоении).

Реально, достаточно удобные IDE.

Пытался уйти от make на Cmake, но никаких преимуществ перед make для
себя не нашёл. Но для ТС они несомненно есть: создаёт проект для
компиляции в M$ Visual Studio.
Посмотрю.

Я же, когда пишу под вантуз, использую кросскомпиляцию через MinGW и
тестирую в wine, т.к. принципиально не хочу использовать вантуз.
Понятное дело: виртуальную машину грузить и затем переключаться туда-обратно, не
очень-то приятно.

Re: Среды разработки

16.10.2012 18:44, Иван Лох пишет:
On Tue, Oct 16, 2012 at 06:32:14PM +0400, Артём Н. wrote:
каталогах в районе /usr/share/vim.
Куда положить эти файлы в Debian и как включить в конфиг?
~/.vim/compiler
Спасибо. А глобально: /etc/vim/compiler?
Например
/usr/local/share/vim/compiler
Вопрос только, зачем
Затем, чтобы пользоваться возможно было от любого пользователя (например, я по
рутом иногда что-то правлю).
Но в /usr/share, понятно, - не вариант.

2. Есть ли где-то реализация проверки орфографии под windows?
Встроенная проверка орфографии в vim7 может компилироваться штатными
средствами в любой кодировке. О том как это делать есть туча мануалов.
Может Vim её там уже использует... Я не помню просто.
Сейчас у меня проверка орфографии в Vim сделана через asplell.
Ну и зря
Потом, в общем, буду разбираться.
vim7 имеет свой спелчеккер
Интерфейс к спеллчекеру?

Я понимаю, конечно, что пользоваться гуглем неспортивно
Знать бы ещё что гуглить. :-) Руки не доходят.

http://www.opennet.ru/base/X/vim_orfo.txt.html
Спасибо. :-)

Re: Среды разработки

15.10.2012 23:57, Aleksey Andreev пишет:
 15.10.2012 21:27, Артём Н. пишет:
 15.10.2012 21:15, Aleksey Andreev пишет:
 Да. после ознакомления с awesome
 Что-то хвалят его последнее время...
 Но как-то пока не очень ясно что это такое и чем он так хорош...
 В сети много инфы по awesome, ознакомьтесь.
Займусь потом. Пока сижу под KDE. :-) Или LXDE, если KDE обновляют.

 luakit
 Хм...
 Странная штука.
 Есть очень лёгкий links2 -g.
  Но не поддерживает JS и Flash.
 Да что вы говорите?! Почему у меня все работает?
В links2? Может, я просто отстал и не запускал его долго... Проверил: у меня там
JS нет.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d772f.7010...@yandex.ru

Re: Среды разработки

15.10.2012 23:48, Aleksey Andreev пишет:
Небольшой код и небольшие скрипты правлю тем редактором что под рукой,
обычно это vim. С IDE в таких случаях не заморачиваюсь.
Кстати, к vim тоже есть некоторые примочки и плагины, позволяющие
превратить его
почти в IDE (помимо подсветок, поддержки tags, make, контроля ошибок и
прочего).
Но что-то с GUI там делать - не лучший вариант.
Да. после ознакомления с awesome и luakit все чаще задумываюсь о vim как
замене KDevelop. Но в виду моей природной лени (можно назвать это
наличием умеренного консерватизма) пока откладываю этот шаг.
Но создание GUI..?
Если на создание GUI тратится времени столько же или больше чем на
кодинг, значит я делаю что то не так. Утрирую, конечно.
Если понадобится, мне не сложно запустить дизайнер отдельно, благо не
злоупотребляю диалогами и формачками.
Тоже GLADE?

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d77bd@yandex.ru

Re: Среды разработки

16.10.2012 18:25, Sciko Good пишет:
 16 октября 2012 г., 8:31 пользователь Ivan Shmakov
 oneing...@gmail.com написал:
 Для несложных GUI я бы использовал Tk для Perl.
 
 А у него есть аналог Glade? Просто моих коллег, использующих вантуз, я
 заставляю на нём рисовать желаемый GUI. Мне остаётся проверить и
 прикрутить его к коду. Как бонус, нет проблем с претензиями типа Куда
 ты засунул эту очень нужную опцию? и при желании можно быстро
 переделать GUI без пересборки.
А GLADE только для GTK?
Как оно вообще используется и где,
Что там под windows?

 Примерно вот так выглядит интерфейс половины программ.
Нативный интерфейс... Жаль, скриншотов под Linux нет.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d7834.5080...@yandex.ru

Re: Среды разработки

16.10.2012 18:41, Sciko Good пишет:
Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.
GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И
GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.
Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.
C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а
спрашивать про его поддержку какими-либо средами, думаю не стоит).
C++ - почти стандарт.

Re: Среды разработки

16.10.2012 18:44, Иван Лох пишет:
 vim7 имеет свой спелчеккер
Посмотрел.
Здорово, конечно, но хотелось использовать штатный спеллчекер с его словарями, а
не устанавливать словари персонально для Vim.
И обойтись без /usr/share...


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d7c54.8010...@yandex.ru

Re: Среды разработки

2012-10-16 Пенетрантность Aleksey Andreev



 luakit
 Хм...
 Странная штука.
 Есть очень лёгкий links2 -g.
  Но не поддерживает JS и Flash.
 Да что вы говорите?! Почему у меня все работает?
 В links2? Может, я просто отстал и не запускал его долго... Проверил: у меня 
 там
 JS нет.
Извиняюсь, невнимательно прочитал. links2 не использовал.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d7ec6.9010...@mail.ru

Re: Среды разработки

2012-10-16 Пенетрантность Aleksey Andreev

 Но создание GUI..?
 Если на создание GUI тратится времени столько же или больше чем на
 кодинг, значит я делаю что то не так. Утрирую, конечно.
 Если понадобится, мне не сложно запустить дизайнер отдельно, благо не
 злоупотребляю диалогами и формачками.
 Тоже GLADE?
Нет.

 В данном случае я хочу
 оптимизировать работу там, где вижу возможность оптимизации. Смена
 редактора кода реально мне может помочь в плане производительности.
 Понятно.
 Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
 Переключиться между cpp и h я могу через Ctrl+F6.
 А в vim?
Я же писал что только задумываюсь о переходе. По теме сильно еще не
копал. Но раз люди пользуются, наверно не все так страшно.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d804d.4040...@mail.ru

Re: Среды разработки

On 16.10.2012 18:25, Артём Н. wrote:

16.10.2012 00:54, Alexander Danilov пишет:

Итог: занимает мало места, можно уложить на usb (при необходимости), на выходе
один бинарник под нужную платформу + файлы данных или упакованный инсталлятор.

Но с Tk интерфейсом.

Под кросплатформенным понимается то, что можно собрать под win32, linux и тд из
одного дерева исходников:
make win = soft.exe
make linux = soft.elf
make all = make win32 linux

Что соберётся в итоге?
Насколько я понял, кроссплатформенность, в случае с tclkit, обеспечивается
каким-то подобием виртуальной машины?

Будет 1(один) .exe файл с интерпретатором и моей программой внутри. Работает,
кушать не просит.
Впрочем для python/perl/ruby есть такие же способы упаковки в один файл, но там всё равно надо
какую-то библиотеку для gui использовать, что в итоге раздувает размер программы и увеличивает
количество проблем при развёртывании.

Так проще под cygwin собрать, и скорость выше будет.

Для GUI скорость в 99.99% не важна - пользователь всё равно медленнее.
А в тех случаях, когда она важна, есть способы улучшить скорость выполнения.

К тому же, небольшое отступление: я писал, что C++ - обязателен.

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.

GUI не причём. Просто C++ используется везде, где ни попадя, поэтому привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И GUI
тут не при чём.

Если уж сильно приспичит, то можно использовать ffidl - расширение для tcl,
загружающее произвольную разделяемую библиотеку и вызывающую все нужные функции,
или самостоятельно написать расширение на c/c++ и вызывать из tcl. А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
времени нет.

На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.

Да? Это как раз с Си дела обстоят лучше, на мой взгляд, но спорить не буду, ибо
на C++ не пишу вообще.

Re: Среды разработки

On 16.10.2012 19:11, Артём Н. wrote:

16.10.2012 18:41, Sciko Good пишет:

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.

Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.
На Delphi написано очень много поделок,которые до сих пор эксплуатируются на производстве и заменить
их нечем.

C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а
спрашивать про его поддержку какими-либо средами, думаю не стоит).
C++ - почти стандарт.

Стандарт чего? Стандартная глупость при выборе среды разработки для почти
любого проекта? Согласен.

А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
времени нет.

На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.

Зато есть библиотеки с умными указателями, коллекциями и прочим. И классы, в
которых очистку возможно произвести в деструкторе. В отличие от C, где нет
вообще ничего.

На Си написана куча языков, которые просто не имеют проблем с памятью.
libtcl.so - это просто хорошая библиотека на Си, в которой помимо множества полезных функций ещё
есть и интерпретатор простого и мощного языка.

Re: Среды разработки

On 16.10.2012 19:05, Артём Н. wrote:

15.10.2012 23:48, Aleksey Andreev пишет:

Небольшой код и небольшие скрипты правлю тем редактором что под рукой,
обычно это vim. С IDE в таких случаях не заморачиваюсь.

Кстати, к vim тоже есть некоторые примочки и плагины, позволяющие превратить его
почти в IDE (помимо подсветок, поддержки tags, make, контроля ошибок и прочего).
Но что-то с GUI там делать - не лучший вариант.

Да. после ознакомления с awesome и luakit все чаще задумываюсь о vim как
замене KDevelop. Но в виду моей природной лени (можно назвать это
наличием умеренного консерватизма) пока откладываю этот шаг.

Но создание GUI..?

Если на создание GUI тратится времени столько же или больше чем на
кодинг, значит я делаю что то не так. Утрирую, конечно.
Если понадобится, мне не сложно запустить дизайнер отдельно, благо не
злоупотребляю диалогами и формачками.

Тоже GLADE?

glade хорош для того, чтобы прикинуть, как должен выглядеть результат,

В данном случае я хочу
оптимизировать работу там, где вижу возможность оптимизации. Смена
редактора кода реально мне может помочь в плане производительности.

Понятно.
Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
Переключиться между cpp и h я могу через Ctrl+F6.
А в vim?

Я могу и обратную ситуацию промоделировать.

Вот в нормальной среде (язык+редактор) я это сделаю, а в продуктах от Борланда
можно долго
[ *** любой понравившийся вам матерный эквивалент*** ]

Re: Среды разработки

16.10.2012 21:03, Alexander Danilov пишет:
On 16.10.2012 19:11, Артём Н. wrote:
16.10.2012 18:41, Sciko Good пишет:
Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.
GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И
GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.
Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.
На Delphi написано очень много поделок,которые до сих пор эксплуатируются на
производстве и заменить их нечем.
Да, согласен.
В любом случае, для них есть Lazarus.

А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на
это
времени нет.
На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.
Неужели в c++11 добавили автоматические управление памятью? Каюсь, не
нашёл. По крайней мере сборки мусора там нет точно.
Зато есть библиотеки с умными указателями, коллекциями и прочим. И классы,
в
которых очистку возможно произвести в деструкторе. В отличие от C, где нет
вообще ничего.
На Си написана куча языков, которые просто не имеют проблем с памятью.
libtcl.so - это просто хорошая библиотека на Си, в которой помимо множества
полезных функций ещё есть и интерпретатор простого и мощного языка.
И? В чём мораль? Я ж вам не говорю, что невозможно управлять памятью на C.
Просто из средств для управления там только malloc, free и коды возврата.
Ни исключений, ни стандартных библиотек, ни нормальной типизации.
И, естественно, что проблем с управлением памятью там больше.
В C++ с этим хоть немного лучше.

Re: Среды разработки

16.10.2012 20:58, Alexander Danilov пишет:
 Да? Это как раз с Си дела обстоят лучше, на мой взгляд, но спорить не буду, 
 ибо
 на C++ не пишу вообще.
Чем лучше-то?
Ровно так же хорошо, как в нормальном диалекте ассемблера.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d96e8.3080...@yandex.ru

Re: Среды разработки


On 16.10.2012 18:41, Sciko Good wrote:

16 октября 2012 г., 11:24 пользователь Victor Wagner
vi...@wagner.pp.ru  написал:

Еще очень полезно знать что стандартный виндовый интерпетатор команд
cmd.exe не такой убогий, как обычно считают а практически представляет
собой полноценный c-shell со встроенным awk. Синтаксис, конечно
кривоватый и неудобный, но возможности есть.


А вы точно не путаете cmd.exe с command.com или PowerShell? Просто
ничего даже издали похожего на awk я не нашёл вот тут:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true


в cmd.exe кое-что есть, и сделать при должной фантазии кое-что можно,
но за это время дешевле поискать awk, tcl или lua, они и для dos есть.
Зато потом поддерживать будет проще.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d96d2.7000...@gmail.com

Re: Среды разработки

On 16.10.2012 18:47, Артём Н. wrote:

16.10.2012 11:24, Victor Wagner пишет:

On 2012.10.15 at 20:58:20 +0400, Артём Н. wrote:

[skip]

А интерфейсы писать?

А интерфейсы надо именно писать. Язык выраженный в виде plain text -
существенно более мощный инструмент, чем любая рисовалка.

Да, вот только писать сложнее, чем картинки двигать.

pack [buttok .ok -text Quit -command exit]

Сложнее?

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

И? Мне нужно это для форм GUI?

Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.

А проектировать?

А для этого существует понятия mind mapping и сoncept mapping.

Скриптовые языки и есть такая среда.

Re: Среды разработки

On 16.10.2012 21:17, Артём Н. wrote:

16.10.2012 21:03, Alexander Danilov пишет:

On 16.10.2012 19:11, Артём Н. wrote:

16.10.2012 18:41, Sciko Good пишет:

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.

GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.

Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.

На Delphi написано очень много поделок,которые до сих пор эксплуатируются на
производстве и заменить их нечем.

Да, согласен.
В любом случае, для них есть Lazarus.

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

Стандарт чего? Стандартная глупость при выборе среды разработки для почти любого
проекта? Согласен.

И что вы мне хотите сказать?
Есть факт: C++ считается необходимым языком, как бы вы к нему не относились.
Написано на нём всего дохрена.

Во первых он не необходимый, я вот периодически пишу разный софт, и вот как-то ни разу он мне не
понадобился, ни для GUI, ни для firmware, ни для посчитать, ни для web, вот даже не знаю, для чего
он может мне понадобится.

А вот всякие манагеры, которые в институтах что-то такое про C++ слышали и может быть на пару лаб
ходили, а теперь руководят командами программеров, вот они С++ знают :) , он им необходим, они
другого ничего не слышали и дураками выглядеть не хотят.

А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ - на это
времени нет.

На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.

На Си написана куча языков, которые просто не имеют проблем с памятью.
libtcl.so - это просто хорошая библиотека на Си, в которой помимо множества
полезных функций ещё есть и интерпретатор простого и мощного языка.

И? В чём мораль? Я ж вам не говорю, что невозможно управлять памятью на C.
Просто из средств для управления там только malloc, free и коды возврата.
Ни исключений, ни стандартных библиотек, ни нормальной типизации.
И, естественно, что проблем с управлением памятью там больше.
В C++ с этим хоть немного лучше.

Мораль - расширяй кругозор.

Re: Среды разработки

16.10.2012 21:14, Alexander Danilov пишет:
Тоже GLADE?
glade хорош для того, чтобы прикинуть, как должен выглядеть результат,
Вообще не имею о нём представления.

Есть набор полей с подписями и разными типами данных и разными фильтрами,
пусть
их положим штук 30, часть их них опциональна и зависит от других полей,
берётся
всё это описание из внешнего источника данных, который может меняться.
Задание:
покажите через Ctrl+F6 эту формочку.
Вот в нормальной среде (язык+редактор) я это сделаю, а в продуктах от Борланда
можно долго
[ *** любой понравившийся вам матерный эквивалент*** ]
Так а что сделать-то надо?
Графический интерфейс пользователя?
И как вы сделаете это в нормальной среде?

Задача не очень ясна, но, раз уж упомянули эту RAD, применительно к данному
случаю.
Я бы выделил группы полей, зависящих друг от друга.
И сделал мастера (или появляющиеся вкладки, в зависимости от выбора
пользователя, например TTabControl или как-то так, не помню).
Внешний источник, например, XML или БД?
Как реализовать построение интерфейса зависит от структуры источника.
Если есть транзитивные зависимости, то мастера там подойдут лучше всего.
Фильтры и тип предоставляются источником.
Возможно использовать что-то типа TMaskEdit (да, я согласен, он не особо, но
возможно написать и своё) и списки для представления наборов значений.
Размещать элементы интерфейса на формах придётся программно.

Непонятно одно: в чём, в данном случае, отличие этой RAD от нормального языка?

Re: Среды разработки

16.10.2012 21:18, Alexander Danilov пишет:
On 16.10.2012 18:41, Sciko Good wrote:
16 октября 2012 г., 11:24 пользователь Victor Wagner
vi...@wagner.pp.ru написал:
Еще очень полезно знать что стандартный виндовый интерпетатор команд
cmd.exe не такой убогий, как обычно считают а практически представляет
собой полноценный c-shell со встроенным awk. Синтаксис, конечно
кривоватый и неудобный, но возможности есть.

А вы точно не путаете cmd.exe с command.com или PowerShell? Просто
ничего даже издали похожего на awk я не нашёл вот тут:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true
в cmd.exe кое-что есть, и сделать при должной фантазии кое-что можно,
но за это время дешевле поискать awk, tcl или lua, они и для dos есть.
Зато потом поддерживать будет проще.
Да, это должна быть весьма извращённая фантазия. :-)
Проще взять cygwin.

Re: Среды разработки

16.10.2012 21:22, Alexander Danilov пишет:
On 16.10.2012 18:47, Артём Н. wrote:
16.10.2012 11:24, Victor Wagner пишет:
On 2012.10.15 at 20:58:20 +0400, Артём Н. wrote:

[skip]

pack [buttok .ok -text Quit -command exit]
Сложнее?
Не вижу, где у вас кнопка на форме.
Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой
границе с верхней кнопкой, причём находиться чуть выше нижней границы воон того
бевела, выделяющего группу контролов.

Re: Среды разработки

2012-10-16 Пенетрантность Alexander Galanin

16.10.2012 21:28, Alexander Danilov пишет:
On 16.10.2012 21:17, Артём Н. wrote:
16.10.2012 21:03, Alexander Danilov пишет:
On 16.10.2012 19:11, Артём Н. wrote:
16.10.2012 18:41, Sciko Good пишет:
Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.
GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант.
И
GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.
Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению
с
C++.
На Delphi написано очень много поделок,которые до сих пор эксплуатируются на
производстве и заменить их нечем.
Да, согласен.
В любом случае, для них есть Lazarus.

В том смысле, что можно и дальше продолжать писать не задумываясь о качестве?
1. Писать что-то интерфейсное там возможно и качественно.
2. Если есть исходники (а, они есть?) этой давно написанной помойки и что-то, к
сожалению, надо поправить, или, не дай бог, куда-то перенести, то проще сделать
это, используя Lazarus, не переписывая с нуля.

C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а
спрашивать про его поддержку какими-либо средами, думаю не стоит).
C++ - почти стандарт.
Стандарт чего? Стандартная глупость при выборе среды разработки для почти
любого
проекта? Согласен.
И что вы мне хотите сказать?
Есть факт: C++ считается необходимым языком, как бы вы к нему не относились.
Написано на нём всего дохрена.
Во первых он не необходимый, я вот периодически пишу разный софт, и вот как-то
ни разу он мне не понадобился, ни для GUI, ни для firmware, ни для посчитать,
ни
для web, вот даже не знаю, для чего он может мне понадобится.
Никто не заставляет исключительно на нём писать (хотя, когда как), но знать его
желательно.
И очень желательно, чтобы среда его поддерживала.
С этим тоже поспорите?

А вот всякие манагеры, которые в институтах что-то такое про C++ слышали и
может
быть на пару лаб ходили, а теперь руководят командами программеров, вот они
С++
знают :) , он им необходим, они другого ничего не слышали и дураками выглядеть
не хотят.
Ага, а программеры работают манагерами и получают за это немалое бабло. :-(

А тратить
время на вылавливание ошибок при работе с указателями/памятью на c++ -
на
это
времени нет.
На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше.
Неужели в c++11 добавили автоматические управление памятью? Каюсь, не
нашёл. По крайней мере сборки мусора там нет точно.
Зато есть библиотеки с умными указателями, коллекциями и прочим. И
классы, в
которых очистку возможно произвести в деструкторе. В отличие от C, где нет
вообще ничего.
На Си написана куча языков, которые просто не имеют проблем с памятью.
libtcl.so - это просто хорошая библиотека на Си, в которой помимо множества
полезных функций ещё есть и интерпретатор простого и мощного языка.
И? В чём мораль? Я ж вам не говорю, что невозможно управлять памятью на C.
Просто из средств для управления там только malloc, free и коды возврата.
Ни исключений, ни стандартных библиотек, ни нормальной типизации.
И, естественно, что проблем с управлением памятью там больше.
В C++ с этим хоть немного лучше.
Мораль - расширяй кругозор.
До куда?
Не понял вашей логической цепочки: как вытекло Расширяй кругозор из вопроса о
управлении памятью в C и C++?

Re: Среды разработки

On Tue, 16 Oct 2012 21:34:34 +0400
Артём Н. artio...@yandex.ru wrote:

pack [buttok .ok -text Quit -command exit]
Сложнее?
Не вижу, где у вас кнопка на форме.
Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой
границе с верхней кнопкой, причём находиться чуть выше нижней границы воон
того
бевела, выделяющего группу контролов.

Вот это условие как раз лучше описывается именно словами, а не языком
жестов для глухонемых. К примеру, большинство набросанных в визуальном
редакторе сибилдера формочек начинает съезжать при изменении размеров
окна или шрифта.

Разбивай построение интерфейса на отдельные небольшие функции с внятными
названиями. Рисовалка такой возможностив принципе не предоставляет.

И? Я-то спрашивал про среду, которая объединяет разрозненные инструменты,
чтобы
не учить тысячу и одну опцию разных компиляторов и не придумывать
велосипеды,
самостоятельно всё это объединяя.
Скриптовые языки и есть такая среда.
И? Прийти к написанию IDE На скриптовом языке?

Зачем? Зачем эта глупая привязка к IDE? Задачи прекрасно решаются и так.

--
Alexander Galanin

Re: Среды разработки

2012-10-16 Пенетрантность Alexander Galanin

On Tue, 16 Oct 2012 20:58:21 +0400
Alexander Danilov alexander.a.dani...@gmail.com wrote:

  Насколько я понял, кроссплатформенность, в случае с tclkit, обеспечивается
  каким-то подобием виртуальной машины?
 
 Будет 1(один) .exe файл с интерпретатором и моей программой внутри. Работает, 
 кушать не просит.
 Впрочем для python/perl/ruby  есть такие же способы упаковки в один файл, но 
 там всё равно надо 
 какую-то библиотеку для gui использовать, что в итоге раздувает размер 
 программы и увеличивает 
 количество проблем при развёртывании.

В общем-то tclkit с включенным Tk и так больше мегабайта весит. Зато не
требует vcl60.bpl, borlndmm.dll и т.д. :)

-- 
Alexander Galanin


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121016214614.5e968d3a6b1a53ee18c66...@galanin.nnov.ru

Re: Среды разработки

16.10.2012 21:42, Alexander Galanin пишет:
On Tue, 16 Oct 2012 21:34:34 +0400
Артём Н. artio...@yandex.ru wrote:

pack [buttok .ok -text Quit -command exit]
Сложнее?
Не вижу, где у вас кнопка на форме.
Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой
границе с верхней кнопкой, причём находиться чуть выше нижней границы воон
того
бевела, выделяющего группу контролов.

Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.
Ну да, естественно.
Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.
Разбивай построение интерфейса на отдельные небольшие функции с внятными
названиями. Рисовалка такой возможностив принципе не предоставляет.
Ну, думаю, предполагается, что пользователь может удержать не очень большое
число элементов в фокусе внимания. И надо создавать интерфейс так, чтобы он не
был перегружен. Он сам разбивается на отдельные компоненты.

К примеру, конкретно.

Мне надо:
1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс.
2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при
добавлении модуля).
3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не на
warning).
4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто
Segmentation fault).
5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
дизассемблерный листинг.
6. Проверить модуль с разными наборами данных.
7. Проверить программу на утечки, использование неиниц. переменных, обращения за
границы и прочее. Мне нужна строка, где происходит обращение. И подсказка: куда
и кем.
8. Сохранить изменения и записать версию.

Я уж не говорю о интеграции с какой-то CASE-фигнёй или штукой уровня выше (тут
как-то писали про cucumber)...
И ещё много что.

Да, всё решается так. Но не слишком ли это..? Если бы всё было так славно и
удобно, вообще, IDE бы придумывали?

Re: Среды разработки

16.10.2012 21:46, Alexander Galanin пишет:
On Tue, 16 Oct 2012 20:58:21 +0400
Alexander Danilov alexander.a.dani...@gmail.com wrote:

Насколько я понял, кроссплатформенность, в случае с tclkit, обеспечивается
каким-то подобием виртуальной машины?

Будет 1(один) .exe файл с интерпретатором и моей программой внутри.
Работает, кушать не просит.
Впрочем для python/perl/ruby есть такие же способы упаковки в один файл, но
там всё равно надо
какую-то библиотеку для gui использовать, что в итоге раздувает размер
программы и увеличивает
количество проблем при развёртывании.

В общем-то tclkit с включенным Tk и так больше мегабайта весит. Зато не
требует vcl60.bpl, borlndmm.dll и т.д. :)
Ага. Хотите срач, скажите tkabber?
Вы пишите про весьма частный случай:
1. Конкретную IDE.
2. Конкретную библиотеку (VCL).
3. Конкретный тип компоновки. Скомпонуйте статически, тоже ничего требовать не
будет. И весит меньше.

Re: Среды разработки


On 16.10.2012 21:30, Артём Н. wrote:

16.10.2012 21:14, Alexander Danilov пишет:

Тоже GLADE?

glade хорош для того, чтобы прикинуть, как должен выглядеть результат,

Вообще не имею о нём представления.


В данном случае я хочу
оптимизировать работу там, где вижу возможность оптимизации. Смена
редактора кода реально мне может помочь в плане производительности.

Понятно.
Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder).
Переключиться между cpp и h я могу через Ctrl+F6.
А в vim?

Я могу и обратную ситуацию промоделировать.

Есть набор полей с подписями и разными типами данных и разными фильтрами, пусть
их положим штук 30, часть их них опциональна и зависит от других полей, берётся
всё это описание из внешнего источника данных, который может меняться. Задание:
покажите через Ctrl+F6 эту формочку.
Вот в нормальной среде (язык+редактор) я это сделаю, а в продуктах от Борланда
можно долго
[ *** любой понравившийся вам матерный эквивалент*** ]

Так а что сделать-то надо?
Графический интерфейс пользователя?
И как вы сделаете это в нормальной среде?

Задача не очень ясна, но, раз уж упомянули эту RAD, применительно к данному 
случаю.
Я бы выделил группы полей, зависящих друг от друга.
И сделал мастера (или появляющиеся вкладки, в зависимости от выбора
пользователя, например TTabControl или как-то так, не помню).
Внешний источник, например, XML или БД?
Как реализовать построение интерфейса зависит от структуры источника.
Если есть транзитивные зависимости, то мастера там подойдут лучше всего.
Фильтры и тип предоставляются источником.
Возможно использовать что-то типа TMaskEdit (да, я согласен, он не особо, но
возможно написать и своё) и списки для представления наборов значений.
Размещать элементы интерфейса на формах придётся программно.


Цитата: Размещать элементы интерфейса на формах придётся программно.
Вывод: Использовать эти самые рисующие RAD имеет смысл только для простых формочек, состоящих из 
фиксированного небольшого количества заранее известных элементов. В противном случае размещать 
придётся программно, а это проще делать на языках, умеющих более шибко манипулировать данными.





Непонятно одно: в чём, в данном случае, отличие этой RAD от нормального языка?




А вы попробуйте передать в процедуру на паскале массив сложных структур данных - за то время, что 
будете описывать все типы, из которых состоит эта структура и массив и параметры функции и прочее, 
на нормальном языка (Haskell/Lisp/Tcl/Python/Ruby/Perl,... зал, помогайте!) уже можно будет написать 
всю программу. Вот на C++ можно будет исхитрится и объявить параметр как void*, а потом, когда 
наступит очередная полоса невезения, сидеть в отладчике и удивляться:  как же так, ну что тут 
сложного, подумаешь, *(++(*p)-[*++i])+***p++, чего он глючит?!



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507d9f8b.1090...@gmail.com

Re: Среды разработки

On 16.10.2012 21:30, Артём Н. wrote:

16.10.2012 21:18, Alexander Danilov пишет:

On 16.10.2012 18:41, Sciko Good wrote:

16 октября 2012 г., 11:24 пользователь Victor Wagner
vi...@wagner.pp.ru написал:

в cmd.exe кое-что есть, и сделать при должной фантазии кое-что можно,
но за это время дешевле поискать awk, tcl или lua, они и для dos есть.
Зато потом поддерживать будет проще.

Да, это должна быть весьма извращённая фантазия. :-)
Проще взять cygwin.

А пробовали брать? Я пробовал, пользуюсь mingw только когда долго в винде
приходится сидеть,
а так проще какой-нибудь однофайловый интерпретатор взять.

Re: Среды разработки

On 16.10.2012 21:34, Артём Н. wrote:

16.10.2012 21:22, Alexander Danilov пишет:

On 16.10.2012 18:47, Артём Н. wrote:

16.10.2012 11:24, Victor Wagner пишет:

On 2012.10.15 at 20:58:20 +0400, Артём Н. wrote:

[skip]

А интерфейсы писать?

Да, вот только писать сложнее, чем картинки двигать.

pack [buttok .ok -text Quit -command exit]
Сложнее?

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

Не туда смотрите - wish /usr/share/tcltk/tk8.5/demos/widget
А всё перечисленное делается так pack ... -fill ... -expand .. -side ... и тд.

И? Мне нужно это для форм GUI?

Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.

Ну да, естественно.
Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.

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

А проектировать?

А для этого существует понятия mind mapping и сoncept mapping.

Скриптовые языки и есть такая среда.

И? Прийти к написанию IDE На скриптовом языке?

Не IDE, а конечного продукта, а таких IDE уже есть
Emacs и Vim - это юниксовые IDE, так есть встроенные языки, с помощью которых процесс
программирования автоматизируется. Vim до 5-й версии был просто редактором, а сейчас это уже IDE.

Emacs до какого-то времени был просто редактором с набором макросов, а сейчас
это конструктор IDE.

Re: Среды разработки

16.10.2012 21:55, Alexander Danilov пишет:
Цитата: Размещать элементы интерфейса на формах придётся программно.
Вывод: Использовать эти самые рисующие RAD имеет смысл только для простых
формочек, состоящих из фиксированного небольшого количества заранее известных
элементов. В противном случае размещать придётся программно, а это проще
делать
на языках, умеющих более шибко манипулировать данными.
В принципе, там богатая библиотека классов контролов.
И нет большой разницы на каком языке вы задаёте класс, заголовок и координаты.
А простые формочки, так или иначе придётся делать. Они же, как составные
элементы.
Вообще, что вы-то используете?

Непонятно одно: в чём, в данном случае, отличие этой RAD от нормального
языка?
А вы попробуйте передать в процедуру на паскале массив сложных структур
данных -
за то время, что будете описывать все типы, из которых состоит эта структура и
массив и параметры функции и прочее, на нормальном языка
(Haskell/Lisp/Tcl/Python/Ruby/Perl,... зал, помогайте!) уже можно будет
написать
всю программу. Вот на C++ можно будет исхитрится и объявить параметр как
void*, а потом, когда наступит очередная полоса невезения, сидеть в
отладчике и удивляться: как же так, ну что тут сложного, подумаешь,
*(++(*p)-[*++i])+***p++, чего он глючит?!
Это больше похоже на C. :-)
Это что: -[*++i] ? o.O Перегруженный оператор?

Ну без проблем. Сложные структуры данных, которые тяжело описать на
вышеперечисленных языках (а часто такое попадается?), я буду описывать на
чём-либо другом. Или постараюсь отойти от таких структур.
Главное, чтобы IDE это поддерживала.

Причём тут эта RAD? Я, кажется, её не защищаю. Да и в Linux её нет.

Re: Среды разработки

On 16.10.2012 21:53, Артём Н. wrote:

16.10.2012 21:42, Alexander Galanin пишет:

On Tue, 16 Oct 2012 21:34:34 +0400
Артём Н.artio...@yandex.ru wrote:

pack [buttok .ok -text Quit -command exit]
Сложнее?

Вот это условие как раз лучше описывается именно словами, а не языком
жестов для глухонемых.

А когда таких слов очень много?
Может, проще посмотреть на интерфейс?
Лучше один раз увидеть, не?

А поведение будет видно из картинки? Нет, не будет.
Встречают по одёжке, ...

К примеру, большинство набросанных в визуальном
редакторе сибилдера формочек начинает съезжать при изменении размеров
окна или шрифта.

Это ошибка не среды, а кривые руки и непредусмотрительность дизайнера
интерфейсов.
Есть такое свойство, как Anchors. И ничего не съезжает.

Съезжает, ибо никто не устанавливает anchor для всех элементов формы, чаще всего делают окно
фиксированного размера, и чуть увеличенный шрифт убивает интерфейс.

Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.

Ну да, естественно.
Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.

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

Скриптовые языки и есть такая среда.

И? Прийти к написанию IDE На скриптовом языке?

Зачем? Зачем эта глупая привязка к IDE? Задачи прекрасно решаются и так.

Почему глупая?
Ну а что решается так?

К примеру, конкретно.

Если стреляешь в ногу, то отчего боль вызывает удивление?

5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
дизассемблерный листинг.

Заняться чтоль больше нечем?

6. Проверить модуль с разными наборами данных.
7. Проверить программу на утечки, использование неиниц. переменных, обращения за
границы и прочее. Мне нужна строка, где происходит обращение. И подсказка: куда
и кем.
8. Сохранить изменения и записать версию.

Да, всё решается так. Но не слишком ли это..? Если бы всё было так славно и
удобно, вообще, IDE бы придумывали?

Re: Среды разработки

On 16.10.2012 21:41, Артём Н. wrote:

16.10.2012 21:28, Alexander Danilov пишет:

On 16.10.2012 21:17, Артём Н. wrote:

16.10.2012 21:03, Alexander Danilov пишет:

On 16.10.2012 19:11, Артём Н. wrote:

16.10.2012 18:41, Sciko Good пишет:

Небольшое отступление: для написания gui c++, мягко говоря, совсем не
обязателен.

GUI не причём. Просто C++ используется везде, где ни попадя, поэтому
привыкать к
среде, в которой нормальной его поддержки нет - не самый лучший вариант. И
GUI
тут не при чём.

Вы отстали от жизни. Даже на вантузе сейчас используется как минимум
C++, Pascal/Delphi и C#.

Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с
C++.

На Delphi написано очень много поделок,которые до сих пор эксплуатируются на
производстве и заменить их нечем.

Да, согласен.
В любом случае, для них есть Lazarus.

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

1. Писать что-то интерфейсное там возможно и качественно.
2. Если есть исходники (а, они есть?) этой давно написанной помойки и что-то, к
сожалению, надо поправить, или, не дай бог, куда-то перенести, то проще сделать
это, используя Lazarus, не переписывая с нуля.

Стандарт чего? Стандартная глупость при выборе среды разработки для почти любого
проекта? Согласен.

Во первых он не необходимый, я вот периодически пишу разный софт, и вот как-то
ни разу он мне не понадобился, ни для GUI, ни для firmware, ни для посчитать, ни
для web, вот даже не знаю, для чего он может мне понадобится.

Никто не заставляет исключительно на нём писать (хотя, когда как), но знать его
желательно.
И очень желательно, чтобы среда его поддерживала.
С этим тоже поспорите?

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

Re: Среды разработки

16.10.2012 22:03, Alexander Danilov пишет:
Не туда смотрите - wish /usr/share/tcltk/tk8.5/demos/widget
А всё перечисленное делается так pack ... -fill ... -expand .. -side ... и тд.
О, мои глаза. :-) Давайте хотя бы тут без Tk. Я понимаю: он хорош и всё такое,
но хвалите его в другой теме: мне более нативный интерфейс интересен или, хотя
бы, Qt.

Потому что
язык позволяет оперировать в терминах если ... то .. иначе и повторять
... до ..., не говоря уж о рекурсии и функциональной декомпозиции, а
рисовалки - нет.
И? Мне нужно это для форм GUI?
Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.
Ну да, естественно.
Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.
А это как описание сделать, а вот передвигать 100 элементов мышкой, чтобы
воткнуть 101-й - это надо быть ..., я даже затрудняюсь правильно подобрать
эпитет.
А зачем вам на одной форме 100 несгруппированных элементов?

А проектировать?
А для этого существует понятия mind mapping и сoncept mapping.
И? Я-то спрашивал про среду, которая объединяет разрозненные инструменты,
чтобы
не учить тысячу и одну опцию разных компиляторов и не придумывать
велосипеды,
самостоятельно всё это объединяя.
Скриптовые языки и есть такая среда.
И? Прийти к написанию IDE На скриптовом языке?
Не IDE, а конечного продукта, а таких IDE уже есть
Emacs и Vim - это юниксовые IDE, так есть встроенные языки, с помощью которых
процесс программирования автоматизируется. Vim до 5-й версии был просто
редактором, а сейчас это уже IDE.
Emacs до какого-то времени был просто редактором с набором макросов, а сейчас
это конструктор IDE.
Ага, а ещё говорят, что где-то там всё-таки есть рукомойник.
И нафига мне конструктор IDE, когда мне нужна IDE?
Vim - это отдельный разговор, тут не про него (и я об этом писал в начале темы).

Re: Среды разработки

On 16.10.2012 21:46, Alexander Galanin wrote:

On Tue, 16 Oct 2012 20:58:21 +0400
Alexander Danilovalexander.a.dani...@gmail.com wrote:

Будет 1(один) .exe файл с интерпретатором и моей программой внутри. Работает,
кушать не просит.
Впрочем для python/perl/ruby есть такие же способы упаковки в один файл, но
там всё равно надо
какую-то библиотеку для gui использовать, что в итоге раздувает размер
программы и увеличивает
количество проблем при развёртывании.

В общем-то tclkit с включенным Tk и так больше мегабайта весит. Зато не
требует vcl60.bpl, borlndmm.dll и т.д. :)

Я тут не так давно пытался упаковать pdfshuffle (python+gtk) для винды, так вот tclkit имеет до
неприличия скромный размер :) . Ничего меньше для написания gui и кроссплатформенное я припомнить не
могу.

Re: Среды разработки

16.10.2012 22:08, Alexander Danilov пишет:
On 16.10.2012 21:53, Артём Н. wrote:
16.10.2012 21:42, Alexander Galanin пишет:
On Tue, 16 Oct 2012 21:34:34 +0400
Артём Н.artio...@yandex.ru wrote:

pack [buttok .ok -text Quit -command exit]
Сложнее?
Не вижу, где у вас кнопка на форме.
Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой
границе с верхней кнопкой, причём находиться чуть выше нижней границы воон
того
бевела, выделяющего группу контролов.

Вот это условие как раз лучше описывается именно словами, а не языком
жестов для глухонемых.
А когда таких слов очень много?
Может, проще посмотреть на интерфейс?
Лучше один раз увидеть, не?
А поведение будет видно из картинки? Нет, не будет.
Поведение описывается языком. Но внешний вид проще нарисовать, чем написать.

Встречают по одёжке, ...
По интерфейсу Tk. :-D

К примеру, большинство набросанных в визуальном
редакторе сибилдера формочек начинает съезжать при изменении размеров
окна или шрифта.
Это ошибка не среды, а кривые руки и непредусмотрительность дизайнера
интерфейсов.
Есть такое свойство, как Anchors. И ничего не съезжает.
Съезжает, ибо никто не устанавливает anchor для всех элементов формы, чаще
всего
делают окно фиксированного размера, и чуть увеличенный шрифт убивает
интерфейс.
Никто - это кто?

К примеру, конкретно.

Если стреляешь в ногу, то отчего боль вызывает удивление?
Причём здесь это?
Выстрелить возможно, просто забыв перевести предохранитель.

5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть
дизассемблерный листинг.
Заняться чтоль больше нечем?
Замечательный аргумент.
Мне это как-то поможет?

Как раз есть чем. Поэтому и не хочется выполнять самому то, что может сделать
компьютер.

Очень бы помогло расписывание каждого пункта, применительно к конкретным средам
(пусть даже к Vim).

Re: Среды разработки

16.10.2012 22:11, Alexander Danilov пишет:
 Никто не заставляет исключительно на нём писать (хотя, когда как), но знать 
 его
 желательно.
 И очень желательно, чтобы среда его поддерживала.
 С этим тоже поспорите?
 Я не спорю, он не нужен вообще ни для чего, я ему применение найти не могу, 
 это
 как старый разваливающийся шкаф в однокомнатной квартире, положить в него 
 ничего
 нельзя, отремонтировать невозможно, его надо выкинуть и забыть.
И что дальше?
Нужно перечислять, где и кем он используется и какие проекты на нём реализованы?
Или, всё-таки, смысла не имеет?


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507da55f.70...@yandex.ru

Re: Среды разработки

On 16.10.2012 22:06, Артём Н. wrote:

16.10.2012 21:55, Alexander Danilov пишет:

Цитата: Размещать элементы интерфейса на формах придётся программно.
Вывод: Использовать эти самые рисующие RAD имеет смысл только для простых
формочек, состоящих из фиксированного небольшого количества заранее известных
элементов. В противном случае размещать придётся программно, а это проще делать
на языках, умеющих более шибко манипулировать данными.

В принципе, там богатая библиотека классов контролов.
И нет большой разницы на каком языке вы задаёте класс, заголовок и координаты.

Есть разница - она в количестве и качестве кода, который приходится читать и
поддерживать.

А простые формочки, так или иначе придётся делать. Они же, как составные
элементы.
Вообще, что вы-то используете?

Для GUI - Tcl/Tk, остальное - от задачи.

Непонятно одно: в чём, в данном случае, отличие этой RAD от нормального языка?

А вы попробуйте передать в процедуру на паскале массив сложных структур данных -
за то время, что будете описывать все типы, из которых состоит эта структура и
массив и параметры функции и прочее, на нормальном языка
(Haskell/Lisp/Tcl/Python/Ruby/Perl,... зал, помогайте!) уже можно будет написать
всю программу. Вот на C++ можно будет исхитрится и объявить параметр как
void*, а потом, когда наступит очередная полоса невезения, сидеть в
отладчике и удивляться: как же так, ну что тут сложного, подумаешь,
*(++(*p)-[*++i])+***p++, чего он глючит?!

Это больше похоже на C. :-)
Это что: -[*++i] ? o.O Перегруженный оператор?

Да какая разница, я на С++ с шаблонами такое видел, что после этого всякого, утверждающего что C++ -
это просто, а Haskell - это сложно, считаю умственно неполноценным родственником Джорджа Буша
младшего, на котором природа не то, что отдохнула, она даже и не напрягалась.

Причём тут эта RAD? Я, кажется, её не защищаю. Да и в Linux её нет.

Re: Среды разработки

On 16.10.2012 22:14, Артём Н. wrote:

16.10.2012 22:03, Alexander Danilov пишет:

Не туда смотрите - wish /usr/share/tcltk/tk8.5/demos/widget
А всё перечисленное делается так pack ... -fill ... -expand .. -side ... и тд.

О, мои глаза. :-) Давайте хотя бы тут без Tk. Я понимаю: он хорош и всё такое,
но хвалите его в другой теме: мне более нативный интерфейс интересен или, хотя
бы, Qt.

И? Мне нужно это для форм GUI?

Чем больше и сложнее становится форма, тем труднее пользоваться рисовалкой.
Проверено.

Ну да, естественно.
Но, при сложной форме, в текстовом описании интерфейса ещё проще запутаться.

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

А зачем вам на одной форме 100 несгруппированных элементов?

А сгруппированные двигать будет ещё сложнее. Пробовал :)

Re: Среды разработки