one_eight_seven

Что бы это пустое изречение могло значить?

Сначала верификация . Функциональная, интеграционная - это гоняют в симуляторе. Очень активно используется корректировка тестов по результатам сбора покрытия. Формальная верификация, статический анализ кода. После идёт прототипирование. Наиболее близко к тому, что вы называете "заливают прошивку в FPGA". Только не совсем FPGA и не так просто. Погуглите Synopsys HAPS для примера. Ну и да, не всегда получается с первого раза, поэтому, осуществляют в том числе и перезапуск кристалла. (те самые silicon revision)

1. Нет, не провоцирует. 2. Есть известное изречение о том, что языки, призванные бороться с идиотией, очень быстро сами становятся идиотскими.

На выходных поищу. Но только они не делают из vim'а eclipse, а присобачивают эклипсий движок (по сути - установленный eclipse) к vim'у.

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

Вы вообще, знаете что такое полный по Турингу язык? Судя по заявлениям - нет. Вопрос в том, что имеет смысл делать в виме, а что не стоит. Весь функционал эклипса, например, можно к нему прикрутить, но это повлечёт за собой весь эклипсий шлак. В этом случае проще и разумнее эклипсом обмазаться.

Матлаб уже OpenSource?

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

Скачайте gcc для любого микроконтроллера и посмотрите, как это сделано там. Обычно это файл mcu.h там заголовочные файлы для конкретных моделей MCU обмазаны толстым слоем директив препроцессора. Эти директивы основаны на макроопределениях. Макроопределения эти передаются компилятору как параметр командной строки (даже если вы гуй удовлетворяете, мышкой тыкая, в конечном итоге это вызов консольной команды). Т.е. вы это макро явно определяете при настройке инструмента сборки.

Тонких нет. Но компилятор смотрит по полному пути файла. Итак, если у вас один и тот же файл каким-то образом лежит в нескольких местах, то макро будет определено при первом включении файла, и переназначений не произойдёт, прагма же попытается включить код второй раз (файл-то другой). Более того, symlink'и и hardlink'и ещё сильнее усложняют задачу определения того, что файл на самом деле один и тот же. Ну и используя макроопределения можно строить условные компиляции. Как абстрактрый пример, у вас есть несколько разных версий драйвера, которые требуют разного кода для своего использования. С помощью директив условной компиляции вы можете их разделить, в случае pragma, тоже можете. но только тем же самым способом, и у вас к прагме прибавится инклюдгард, и плюсы прагмы уже перестанут быть актуальными. Потому, стандартный путь, классический - это инклюдгарды. Прагма - не хуже, но непонятно зачем. Появись она сразу, возможно, она была бы основным методом, но сегодня уже очень-очень много когда сделано другим способом, и к нему все привыкли. Так что плюсы - иллюзорны.

да, некоторые ещё и оптимизировать это умеют. Этот способ не однозначно лучше, чем метод сиклюдгардами. Что это за последовательность? Что она призвана прояснить?

В разных: у меня на всех машинах одинаковый файл .vimrc, соответственно, в vim всё тоже одинаково. Ну а так в разное время использовал на cygwin, ubuntu, rhel, centos, fedora. Ну а стартовое о чём должно сказать? Давайте будем сравнивать сравнимые вещи и сравним стартовое окно Vim с ярлыком запуска VisualStudio. Что будет более информативно? Разговор шёл о работе в редакторе, а не о любовании на стартовое окно.

Ну и каша. Что в коде, что в этой теме. В общем-то как написано, так и работает. Объявление должно быть раньше, чем использование. Зачем вы делаете определение внутри файла исходников (*.c), если оно используется за пределами этого файла? Такие объявления должны быть в заголовочниках (.h). В файле, где что-то используется, оно тоже должно быть сначала объявлено, да, при этом файл может быть включён в код много раз (#include "somefile.h") и могут произойти переопределения, именно для борьбы с этим в заголовочниках и ставят инклюдгарды (#ifndef FILENAME_H ...)

Всю жизнь и ещё три дня : ) Можно быстро начать с vim-bootstrap (в гугеле ищется на раз-два). Дальше, когда закончится первоначальное обучение, всегда будет возникать желание сделать что-то быстрее, лучше, и тут если умеете бороться с перфекционизмом, то всё достаточно быстро. Берёте рабочий пример, смотрите имеющиеся плагины и выбираете, то, что больше нужно. Скачивание и установка плагинов напрямую из гитхаба, добавлением имени пользователя и названия репо в конфиг файле, достаточно быстро (секунды). Больше времени уходит на поиск в гугле. Также, как выше - дело секунд. Больше времени - поиск, тестирование, как оно - удобно/неудобно в работе, в режиме сравнения. Могу сразу посоветовать vendetta, molokai, большинству нравится одно или второе. Есть. Когда привыкаешь, начинаешь автоматически это делать везде. В Vim есть командный режим, и, в итоге ловишь себя за тем, что где-то в тесктовом редакторе общего назначения появляется :w, :wqa, diw, и постоянно жмякаешь на Esc.

О вас. Ваши рассуждения не согласуются даже с формальной логикой. А это математика уровня средней школы. Вы не освоили. Речь идёт про вим, а вы, ничего не зная о нём говорите о том, что этого в нём нет (это невежество). В качестве того, что вам кажется аргументом, вы приводите то, что этого нет в SlickEdit. Мне неизвестно, есть там это или нет, но это не важно, поскольку SlickEdit - это не Vim. Это нарушение формальной логики (необразованность). Я вам пишу, что важно перемещение по коду, топикстартер в первом посте написал, что ему это важно. Значит, нам это важно. То, что вам это неважно - это не аргумент для всех. Один размер не всем подходит. Вы пишете, что важен хороший парсинг, а с фиговым всё плохо. Ну и что? Пользуйтесь хорошим парсером, с Vim - это не проблема. Естественно, есть языки, на которых программировать в vim - плохая идея - это C#, Java, и другие языки, в которых больше генерируются конструкции, а не пишется код, те, в которых работа с текстом отходит если не на второй, то на третий и четвёртый планы.