теги: i_will_be_back, оно_шевелицца

много лет назад с удовольствием юзал jEdit, но IMHO, не вижу в нем более необходимости

Good news.

На что перешел?

> На что перешел?

меня netbeans полностью устраивает, а когда в нем появилась интеграция с меркуриалом, стало совсем шоколадно.

>меня netbeans полностью устраивает,

Бууээээээээеэеэее

Идея же есть, зачем это?

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

> Бууээээээээеэеэее

Идея же есть, зачем это?

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

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

> меня netbeans полностью устраивает, а когда в нем появилась интеграция с меркуриалом, стало совсем шоколадно

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

>но крайние релизы идеи стали уже не торт.

да, что-то в этом есть. глючноватенько... и тормознутенько...

>А как сделать так чтобы у NetBeans интерфейс не запаздывал на пол секунды с моими действиями?

Переписать все на Си. Именно Си, а не Си++. Это важно.

На попытку поиска все так же плюётся эксепшинами?

> А как сделать так чтобы у NetBeans интерфейс не запаздывал на пол секунды с моими действиями?.. Очень нравится NetBeans, но все же очень раздражает что даже на самые простые задачи как нарисовать крошечную менюшку - оно долго думает...

я гуем честно говоря не занимаюсь и тормозов не испытываю, хотя дело скорее в том, что мало кто правит /что/то/netbeans/etc/netbeans.conf по поводу параметров jvm. По дефолту их ставят, как обычно, что бы у всех всегда хоть как то запустилось.

Дак в том то и дело. Иначе бы все давно сидели уже на Нетбинс. Момент этот принципиальный и ничо так просто не получится. Чтоб багато как в жабе и быстро как в виме. Пилить надо вирутальную машину.

> Чтоб багато как в жабе и быстро как в виме.

вим - это второй главный инструмент ;))

> Переписать все на Си. Именно Си, а не Си++. Это важно.

провоцируешь, толстячок

Эх, у меня нетбинс тормозит :( даже автодополнение. работать невозможно.

Ну, вообще-то есть и видимые изменения. Например, появился многострочный режим поиска, сглаживание шрифтов, обновились иконки (теперь, они основаны на наборе Tango). Но, самое главное - Слава Пестов бесменный лидер проекта с его основания и до версии jEdit 4.3 Pre2 оставил проект и отдал лидерство команде из нескольких разработчиков во главе с Alan Ezust. Увы, качество плагинов с того времени стало постепенно снижаться (особенно с точки зрения юзабилити и грамотной проработки интерфейса).

Я тут погуглик чуток насчет хардварных реализаций жабы. В конце концов лисп машина была, почему Sun не сделал ни одной пробной жаба машины? Странно как то это.

> Эх, у меня нетбинс тормозит :( даже автодополнение

может поможет (цитаты из доков)

для клиентского запуска очень полезны: -Xbatch, -client, а также:

-J-XX:PermSize=20m - уменьшает время запуска. Этот параметр задает размер «permanent area», где хранятся классы и пул строк. Так как мы знаем, что все классы занимают определенное количество памяти, мы указываем JVM, какое количество памяти потребуется для этих целей. Этот параметр устраняет сборки мусора в течение запуска на многих системах.

-J-XX:+UseConcMarkSweepGC-J-XX:+UseParNewGC - тормоза при сборке мусора. Этот параметр заставляет JVM использовать различные алгоритмы для сборки мусора. Если вы используете параметр PermSize, то вы должны также добавить строку -J-XX:+CMSClassUnloadingEnabled в файл netbeans.conf для включения выгрузки классов. Замечание: пока не ясно, этот сборщик помогает или вредит работе на однопроцессорных машинах.

-J-XX:+UseParallelGC - для больших объемов памяти продолжительность незначительных уборок мусора уменьшается в два раза при использовании этого алгоритма сборки на однопроцессорных системах. Этот сборщик разработан для работы на многопроцессорных системах с гигабайтной кучей. При больших уборках мусора данных о влиянии этого параметра нет. Этот параметр взаимно исключает -J-XX:+UseConcMarkSweepGC.

>А как сделать так чтобы у NetBeans интерфейс не запаздывал на пол секунды с моими действиями?.. Очень нравится NetBeans, но все же очень раздражает что даже на самые простые задачи как нарисовать крошечную менюшку - оно долго думает...

Элементарно, собираешь low preemtible ядро с HZ=1000 и для нетбинса в etc/netbins.conf прописываешь -J-XX:+AggressiveOpts -J-XX:+TieredCompilation -J-XX:+DoEscapeAnalysis -J-XX:+UseAdaptiveSizePolicy -J-XX:+CMSClassUnloadingEnabled -J-XX:+UseConcMarkSweepGC -J-client

Да, когда ядро собираешь желательно патч bfs (если тачка smp) накатить и dynamics tics отключить.

поди спаяй. документация есть.

меня netbeans полностью устраивает, а когда в нем появилась интеграция с меркуриалом, стало совсем шоколадно.

NetBeans очень хорош (сами используем), однако jEdit в своё время доставил кучу положительных эмоций. Сейчас хочется отказаться от NetBeans по нескольким важным причинам, несмотря на все плюсы этой среды и очень-очень хорошее отношение к ней:

• Совершенно ненужная интеграция с Ruby-проектами, которая только мешает и занимает драгоценное место на экране;
• В случае с Rails-проектами та же ерунда: ручками в консоли всё делать на порядки проще, особенно в случае, если приложение не ограничивается одной работой с БД, а использует, ко всему прочему, Starling и некоторые свои особые хранилища данных;
• Убогий Output Window, который висит без дела;
• Отсутствие git-плагина (nbgit неюзабелен);
• Субъективно, я кроме Go to File, красивой подсветки синтаксиса (Dark Pastels) и автоформатирования кода (полезно при Copy-Paste) ничего там и не использую...

Так что ещё рано кричать, что jEdit не нужен. Никто не спорит, что в большинстве случаев IDE справляются с поставленными задачами лучше, чем обычные текстовые редакторы + терминал, однако порой слово Integrated в аббревиатуре реализовано на недостаточно юзабельном уровне.

Спасибо за внимание :)

> Я тут погуглик чуток насчет хардварных реализаций жабы. В конце концов лисп машина была, почему Sun не сделал ни одной пробной жаба машины?

А как же это:
http://en.wikipedia.org/wiki/Java_processor ?

Это типа емакс для жабофагов?

>Это типа емакс для жабофагов?

не только, там для С++ автокомплит хороший, лучше чем в эклипс

http://www.azulsystems.com/products/compute_appliance.htm

picoJava was originally designed to be used in consumer electronic products that run Java applications. Sun Microsystems never released a product based on this technology; however, Sun have licensed the technology to companies such as Fujitsu, NEC and Siemens. The Verilog code of picoJava was later released under open-source, but the download page is currently not available.

>Кстати, 9ая Идея есть в комьюнити едишене уже.

Обрезанная по самое нельзя

Чем оно лучше emacs, кроме того, что его можно перенести на мобилку?

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

Отлично!

jEdit отличный проект. Главное его достоинство это поиск замена.

результат замены может быть скрипт на BeanShell + можно подгрузить свой jar со своей функцией.

Редакторов с таким мощным поиском и заменой

У меня нетбинс не тормазит, и прекрасно работает.

переписать нетбинс на си это туфта полная.

вообще писать на си пора зарпетить и прировнять к анальному сексу при геморое.

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

Джава процесоры или акселераторы были созданы в 90х Последний, что я слышал реализовывал аппаратную сборку мусора без остановки выполнения кода.

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

За что я люблю jEdit, так это за подсветку синтаксиса XSLT. Ни одна IDE такого не умеет.

>вообще писать на си пора зарпетить

Пора запретить таким придуркам, как ты, выходить в интернеты.

> Редакторов с таким мощным поиском и заменой

а чем regex в поиске замене не устраивает? причем не в отдельном файле, а в любой ветке контекстно открытого дерева проектов/файлов?

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

> Элементарно, собираешь low preemtible ядро с HZ=1000 и для нетбинса в etc/netbins.conf прописываешь -J-XX:+AggressiveOpts -J-XX:+TieredCompilation -J-XX:+DoEscapeAnalysis -J-XX:+UseAdaptiveSizePolicy -J-XX:+CMSClassUnloadingEnabled -J-XX:+UseConcMarkSweepGC -J-client

И насколько это помогает? В разы быстрее?

> И насколько это помогает? В разы быстрее?

нет

все эти параметры (и то что я писал) рекомендации к действию, все зависит от кол-ва рамы которая у тебя обычно свободна, от L2 кэша проца, от кол-ва ядер и камней в машинке. В общем надо пробовать и подбирать параметры.

Отлично! Я уж и не надеялся. Лучше нетбинз тем, что он является именно расширяемым редактором, а не платформой для построения IDE. В результате работать получается оперативнее, не рефрешит все вокруг на каждый чих и т.п. Поиск стоит отметить, очень могуч. Вообще редактор можно охарактеризовать как mouse friendly emacs.

>И насколько это помогает? В разы быстрее?

Это помогает, проверено. У тебя сам netbeans не тормозит, у тебя gui netbeans реагирует с большой задержкой на твои действия.

>За что я люблю jEdit, так это за подсветку синтаксиса XSLT. Ни одна IDE такого не умеет.

толсто!
в идее даже XSLT-дебаггер есть

Наконец-то допилили.

Больше редакторов хороших и разных.

>кол-ва рамы которая у тебя обычно свободна, от L2 кэша проца, от кол-ва ядер и камней в машинке

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

Идея хорошая - кроссплатформенность, расширяемость.
Но мне Emacs съел мозг и глаза, и ни на что иное смотреть не могу :(

Кстати, по сравнению с вимом и эмаксом, жЕдит вполне органично смотрится на офтопике

>вообще писать на си пора зарпетить и прировнять к анальному сексу при геморое.

Посмотрю я на тебя как ты кернел на жавке похабной перепишешь. Получится монстр требующий 320 Гигобайт Озу и который надо будет постоянно рестартить из-за мемори иксепшенов. Удачи, живи и дальще в мире убогих язычков песочниц, созданных для обезьян без мозгов.

простой пример: -XX:+UseParallelGC + -XX:ParallelGCThreads=30 - тыч ситаешь, что дав 30 ниток под garbage на сингл процессоре, который может быть занят чем нибудь еще многонитевым (или само жаба приложения активно io юзает в нитях), ты не повлияешь на производительность системы?? уменьшится она адназначна.

или дав размер стэка более (или не кратно в 2-4 раза) L2 ты не повлияешь? опять же уменьшишь латенси.

p.s. я правда с серверной жабой пляшу с бубнами, а не с гуем.

p.p.s а для gui по моему всегда было простое правило, не юзать тришолды, ставить -batch и AggresiveOpts и обычно достаточно

p.p.p.s http://java.sun.com/performance/reference/whitepapers/tuning.html - как стартовая точка - вполне