dmz wrote:
> C>Про сборку через ssh все у нас знают, не беспокойтесь. Вот только > C>неудобно это. > Чем?
На локальной машине удобнее по файлам прыгать.
> C>Покажите мне работающий FAR и OLE под Линуксом (и не внутри > C>vmware/wine), а потом хоть в Антарктиду. > Нету. И верите — нафиг не вперлось. Который год. Видимо, не вперлось > большинству, > иначе бы сделали. Что касается работы с ssh / ftp / samba (ну или как > там называются виндовые шары) — > файловые системы ssfs, lufs, smbfs настолько удобны, что мне больше и > не надо.
Мне приходится регулярно под root'ом прибивать повисшие шары в каталогах
пользователей. В Винде с этим все проще — прибил повисший FAR и
работаешь дальше.
> Удобная консоль если привыкнуть — заруливает файловый менеджер в > минуса. Под юникс он просто особенно > не нужен.
Ага, конечно. Я консолями разных Юниксов (Linux, Free/Open/NetBSD,
Solaris, AIX, HP-UX) уже пользуюсь больше 10 лет — крутости по сравнению
с FARом что-то не замечаю.
> Что касается OLE. Если он вам для автоматизации и скриптования — то > просто надо привыкнуть, что это > делается здесь по другому.
Точнее, обычно не делается никак, или делается на скриптах конечных
приложений.
Cyberax wrote:
>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> зависимости от составителя дистрибутива сильно варьируется потребность >> в ковырянии внутри скриптов. > > И везде она != 0.
В винде она тоже != 0. Только там со скриптами, в которых можно
поковыряться, туго...
C>На локальной машине удобнее по файлам прыгать.
Мы же говорили о сборке. Зачем при этом прыгать по файлам?
(вопрос, зачем по ним вообще прыгать, мы пока оставим)
C>Мне приходится регулярно под root'ом прибивать повисшие шары в каталогах C>пользователей. В Винде с этим все проще — прибил повисший FAR и C>работаешь дальше.
Ну, тогда попробовать fuse. Опять же, в настройках smbfs, sshfs можно
прописать таймауты — я точно этим пользовался.
C>Ага, конечно. Я консолями разных Юниксов (Linux, Free/Open/NetBSD, C>Solaris, AIX, HP-UX) уже пользуюсь больше 10 лет — крутости по сравнению C>с FARом что-то не замечаю.
А я после юникса фаром пользоваться под виндой практически перестал. Висит,
конечно, по застарелой привычке, но 99% времени простаивает.
>> Что касается OLE. Если он вам для автоматизации и скриптования — то >> просто надо привыкнуть, что это >> делается здесь по другому.
C>Точнее, обычно не делается никак, или делается на скриптах конечных C>приложений.
Большинство приложений — опенсорсные. Большинство приложений имеют библиотеки, на которых
они построены. Многие библиотеки имеют биндинги в скриптовых языках. Так что да, автоматизация
делается примерно так. Плюс я не вижу ничего плохого в "скриптах конечных приложений".
Здравствуйте, raskin, Вы писали:
R>Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие
Да я, в общем, не настолько религиозен. R>расширения типа tabbed editing для ViM. Я готов от этого на время R>отказаться, если есть перспектива большего удобства и инструментария.
ИМХО, цель — в эффективном выполнении поставленных задач имеющимся инструментарием. Сам стараюсь изучать и то, и другое. Попробовать поработать стоит однозначно, однако помнить, что learning curve у эмакс недетский.
Здравствуйте, Cyberax, Вы писали:
>> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >> т.к. там из функциональности — джентельменский набор. C>Людям, переходящим с WinXP — не легче.
В данном вопросе полностью поддерживаю Э. Дейкстру. Людям, начавших с Basic и WinXP, необходима помощь окружающих в перестройке мышления и отказе от навязанной психологии. С WinXP будет трудно переходить вообще куда-либо, не только на Линукс.
C>Чем? Почему тогда файловая система и драйверы устройств не работают вне C>ядра? Чем графика фундаментально отличается?
Тем, что графика не является непременным атрибутом компьютера. И в разных семействах компьютеров графическая подсистема может радикально отличаться. >> Ну как такое ядро потом переностиь на другую архитектуру? C>Ну так графику тоже надо будет переносить. Какя разница: переносить C>ядерные модули или user-level код?
Дzен в том, что вероятнее всего графику вообще не потребуется переносить. По ненадобности. Впрочем, не факт. А факт в том, что Хы в Unix вторичны. Принципиальной разницы в работе с ними и без них я не вижу (хотя картинки смотрю, да ) >> А если там графика вообще не нужна? C>Ну так не вкомпиливать ее просто (выключить модуль в конфигурялке) и все C>дела.
Ну так и не вкомпилена на сегодняшний день. Разве не так?
C>Хорошо: не Линукс, а GNU/Linux.
Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, насколько мне известно, не завершено. >> в ковырянии внутри скриптов. C>И везде она != 0.
Можно подумать, в свежеустановленном Windows'е не надо ничего подкручивать полдня.
Вам не кажется, что скоро это будет Great Holy War II? Может, вернемся к конструктивным вопросам?
Здравствуйте, raskin, Вы писали:
R>Для справедливости признаем, что там скрипты есть в обоих приложениях. R>Правда в каждом приложении свои. И я не умею пользоваться ни теми, ни R>другими, но вроде бы они не сложны.
Про фотошоп говорить не буду. Но подобного рода задачу для Оффиса решать ну очень скучно. Причем средствами не вполне очевидными.
C>var theApp=new ActiveXObject("Word.Application");
C>//Используется наш компонент, который позволяет красиво создавать
C>// выборку файлов. По желанию заменяется на что-нибудь другое.
C>var filez=new ActiveXObject("EleWise.FileEnumerator");
C>filez.showSelectionDialog();
C>for(var f=filez.enum();!e.atEnd();e.moveNext())
C> theApp.OpenDocument(f.name()). ....; //Ну и делайте все, что вам там
C>нужно...
C>
C>Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о C>формате файлов и т.п. А вот вам придется с этим разбираться.
Да я МСДН в общем, не вчера увидел. Только вот МСДН, к сожалению, с системой не поставляется. Значит, по логике, чтобы узнать о таком способе, мне надо быть разработчиком.
Но довольно об этом...
glyph wrote:
> C>Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о > C>формате файлов и т.п. А вот вам придется с этим разбираться. > Да я МСДН в общем, не вчера увидел. Только вот МСДН, к сожалению, с > системой не поставляется. Значит, по логике, чтобы узнать о таком > способе, мне надо быть разработчиком.
Объектная модель Ворда описана в документации к VBA, который идет вместе
с самим Вордом.
> Но довольно об этом...
Это не частная проблема Windows. Это общая проблема GUI в стиле Windows.
-- это я писал. 8) C>Объектная модель Ворда описана в документации к VBA, который идет вместе C>с самим Вордом. >> Но довольно об этом... C>Угу.
Последние 5 копеек.
Поставленный вопрос Вами решен эффективно и, следовательно, верно. Однако... сделан он был не с помощью GUI, а той самой командной строкой.
Чистый Unix-way.
Следовательно, и я показал, что даже ярые приверженцы GUI подсознательно пользуются CLI.
Здравствуйте, Cyberax, Вы писали:
С>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>раз ищу инструменты для разработки под Юниксами. В проекте используется C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>(уровня VisualStudio+VAssist)?
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Cyberax, Вы писали:
С>>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>>раз ищу инструменты для разработки под Юниксами. В проекте используется C>>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>>(уровня VisualStudio+VAssist)?
A>Во. Какая-то новая среда (я о ней ничего не слышал до этого). Может она A>лучше чем все остальное? http://upp.sourceforge.net/index.html
Не знаю, как насчет среды, а вот найти бы время и ознакомится с из GUI библиотекой было бы интересно (с учетом того, что Qt4, имхо, слишком дорогая) см. так же: Re[2]: С++ вперёд!
eao197 wrote:
> A>Во. Какая-то новая среда (я о ней ничего не слышал до этого). Может она > A>лучше чем все остальное? http://upp.sourceforge.net/index.html > Не знаю, как насчет среды, а вот найти бы время и ознакомится с из GUI > библиотекой было бы интересно (с учетом того, что Qt4, имхо, слишком > дорогая) см. так же: Re[2]: С++ вперёд! > <http://rsdn.ru/forum/Message.aspx?mid=1312620&only=1>
Уже посмотрел — ничего особо выдающегося, полного MVC так и нет, а
лэйауты весьма посредственные. Сам подход к созданию лэйаутов тоже мне
абсолютно не нравится.
glyph wrote: > R>Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие > Да я, в общем, не настолько религиозен.
Но Вы знаете его преимущества. О них я и спрашиваю.
> R>расширения типа tabbed editing для ViM. Я готов от этого на время > R>отказаться, если есть перспектива большего удобства и инструментария. > ИМХО, цель — в эффективном выполнении поставленных задач имеющимся > инструментарием. Сам стараюсь изучать и то, и другое. Попробовать > поработать стоит однозначно, однако помнить, что learning curve у эмакс > недетский.
Я имел удовольствие любоваться, как человек, читая справку по ViM, не
мог выйти из такового. Так что меня не запугать learning curve. Ну и у
ViM я по ней далеко прошёл. И с EDWIN я поигрался (~Scheme Emacs). Как я
учился работать в Linux — промолчу. Так что этот аспект меня не пугает.
Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому
как, по-моему, машина с Emacs, но без ViM встречается нечасто.
Кстати, map в Emacs можно делать (ценно именно с любой непечатной
клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если
нет — не буду выпендриваться, останусь на ViM.
glyph wrote: > C>Хорошо: не Линукс, а GNU/Linux. > Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, > насколько мне известно, не завершено.
Пять копеек: GNU OS — это когда все мелкие утилиты+несколько главных
библиотек (в общем, POSIX) от GNU. GNU/Linux — это GNU OS, построенная
поверх ядра "Linux". GNU kernel — это, вероятно, GNU Hurd. Существует
Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно
запустить и приемлемо работать в командной строке.
raskin wrote:
> glyph wrote: >> C>Хорошо: не Линукс, а GNU/Linux. >> Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, >> насколько мне известно, не завершено. > Пять копеек: GNU OS — это когда все мелкие утилиты+несколько главных > библиотек (в общем, POSIX) от GNU. GNU/Linux — это GNU OS, построенная > поверх ядра "Linux". GNU kernel — это, вероятно, GNU Hurd. Существует > Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно > запустить и приемлемо работать в командной строке.
GNU/Linux это то, как Stallman предпочитает называть Линукс. Причем в
собирательном смысле, а не какой-то там дистрибутив.
Ему обидно, что весь user space был написан (на момент становления
популярности Линуха) в рамках проекта GNU, а стоило Торвальдсу
изготовить ядро, конечный продукт назвали почем-то Линухом. А слово GNU
как-то забыли.
Здравствуйте, raskin, Вы писали:
R>Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому
Если честно — не вижу. Я выбрал эмакс из-за Lisp. Кроме того, он достаточно требовательный к памяти. ViM мне не нравистя с точки зрения эстетики, в остальном нормально. Так что моя связка emacs + vi. R>как, по-моему, машина с Emacs, но без ViM встречается нечасто.
It depends on админ. У меня все машинки такие. 8) R>Кстати, map в Emacs можно делать (ценно именно с любой непечатной R>клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если
Ээээ, да. Просто не везде комбинации работают как положенно, например в терминале М == ESC. R>нет — не буду выпендриваться, останусь на ViM.
Можно попробовать пройти туториал. И дальше смотреть по субъективному восприятию. Если честно, делать из эмакса ИДЕ начал совсем недавно. До этого это был просто текстовый редактор.
Здравствуйте, raskin, Вы писали:
R>Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно R>запустить и приемлемо работать в командной строке.
Истинная правда. Еще HURD называется математическим ядром. На чем оно написано, интересно? Неужно на FORTRAN'e?
glyph wrote: > R>Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому > Если честно — не вижу. Я выбрал эмакс из-за Lisp. Кроме того, он > достаточно требовательный к памяти. ViM мне не нравится с точки зрения
Память мне жалко не всегда, мой уровень в ViM достаточен, чтобы если что
обойтись. Lisp, в принципе, оно, конечно, неплохо. Или и правда EDWIN
помучить? Но там всё самому настраивать, не у кого стащить. Зато язык —
Scheme. R4RS/R5RS. > эстетики, в остальном нормально. Так что моя связка emacs + vi.
Эстетика мне безразлична. > R>как, по-моему, машина с Emacs, но без ViM встречается нечасто. > It depends on админ. У меня все машинки такие. 8)
Возможно всё... > R>Кстати, map в Emacs можно делать (ценно именно с любой непечатной > R>клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если > Ээээ, да. Просто не везде комбинации работают как положенно, например в > терминале М == ESC.
Кому Вы это рассказываете? После старта в mc мне это очевидно.. Хотя да,
для читающих ветку новичков это будет полезно. > R>нет — не буду выпендриваться, останусь на ViM. > Можно попробовать пройти туториал. И дальше смотреть по субъективному > восприятию. Если честно, делать из эмакса ИДЕ начал совсем недавно. До > этого это был просто текстовый редактор.
Да я тоже ViM начал настраивать, когда понадобилось только.
glyph wrote:
> C>Угу. > Последние 5 копеек. > Поставленный вопрос Вами решен эффективно и, следовательно, верно. > Однако... сделан он был не с помощью GUI, а той самой командной строкой.
Можно и без командной строки — попробуйте на досуге нажать alt-f11 в Ворде.
> Чистый Unix-way. > Следовательно, и я показал, что даже ярые приверженцы GUI > подсознательно пользуются CLI.
Так кто спорит, что скриптабельность — это плохо? В Юниксе плохо совсем
другое — _обязательная_ скриптабельность, даже когда она не нужна.
Здравствуйте, Cyberax, Вы писали: C>Можно и без командной строки — попробуйте на досуге нажать alt-f11 в Ворде.
Вчера, на досуге (точнее, на клавиатуре) нажал M — F11. Много думал. Не сразу понял, как мышкой набрать макрос.
Ну конечно же я подозревал о существовании редактора макросов в Word'e! Тем более, что эти самые макросы немало кровушки попили в свое время. >> Чистый Unix-way. >> Следовательно, и я показал, что даже ярые приверженцы GUI >> подсознательно пользуются CLI. C>Так кто спорит, что скриптабельность — это плохо? В Юниксе плохо совсем C>другое — _обязательная_ скриптабельность, даже когда она не нужна.
Никто и не спорил. Пример бы приведен не в доказательство необходимости "скриптабельности", а в демонстрации слабого места GUI. И на мой взгляд крайностей быть не должно. Короче, ратую за разумное сочетание и GUI, и CLI.
Насчет обязательной скриптабельности не могу согласиться. Первые полгода работал в обсуждаемом emacs'е вообще без собственных скриптов. Просто пользуясь документацией.
Похоже, что конструктив закончился парой десятков постов назад. Я предлагаю или прекратить обсуждение, или переехать в "Священные войны".