Кто в чём пишет
 

Я в Perl Builder 2.0 (Русский понимает) , а синтаксис проверяю в DzSoft Perl Editor (Русский не понимает).

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

Notepad- prosdto klass! ;)

И русский понимает :D

Нееее, какой нафиг Notepad?
Far+Colorer - и русский понимает, и синтаксис умеет подсвечивать.

2(3) А если серьёзно. Неужели все паряться с Far'ом? Неверю.

А почему паряться?
Far+Colorer нормально работают. Синтаксис подсвечивают, парные скобки, кавычки и прочую лабуду выделяют. Поиск там удобный.
Синтаксис тебе сам Perl и проверит, подскажет в какой строке ошибка.
А еще я себе навесил ассоциацию на расширения *.pl и *.cgi - и теперь пускаю Perl скрипты из Far как обычные exe файлы - Enter нажал и все.

А что за Colorer?

Плагин для Far.
Помимо подсветки имеет еще кучу полезных функций.
Кстати, в его состав входит специальная библиотека, которая позволяет реализовать все свойства Colorerа для практически любых внешних редакторов. Как заявляет автор, этой библиотекой можно пользоваться и в редакторах для Linux. Но я сам не проверял.

А ссылочку слабо?

http://www.mxlab.com/ftp/win/utils/far
Тебе нужны файлы colorer4ever.far.rar и colorer4ever.lib.rar
Ну или на плагинринге возьми. В хелпе к Фару есть его адрес

Спасибо. Сейчас скачаю.

Даже страшно подумать, в чем редактрируют перловый код программеры, незнакомые с рулезным редактором vim... :)

Ничего ужаснее vim-а я не видел. BG - большой дурак, если придумал Vusual Studio.

А какая связь между vim и BG с его Visual Studio? :)

Они оба являются редакторами, но только в VS можно писать программы, а в VIM нужно ещё разбираться 10 лет.
P.S. С командной строки работать не привык . Извините.

VS не является редактором. Ты его с чем-то путаешь. К примеру, одним из штатных использований vim является его интеграция внутрь VS. :)

Не огорчайся, не всем дано познать Истинное Дао. Я, к примеру, в свое время освоил vim за неделю. :D

Уже первые часы медитации над vim позволяют познать малую истину: не хочешь работать с командной строкой -- и не надо. :)

VS - в смысле VC, VB или InterDev.

VS -- В смысле Visual Studio.

А ты что подумал?

Письмом выше это написано. :D

А до этого.

До этого все также написано достаточно ясно и подробно.

Наверное я тормоз. Это бывает. А давно на Перле пишешь? и под чем.

Лет пять. Что же до "под чем" -- а есть разница? :)

Тогда наверное по UNIX-ом. Я прав?

И под виндами тоже. Виндовая версия vim работает не хуже юниксовой. :)

А не скажешь, правильно ли реализовывать поиск по большому сайту (10000 стр.) спомощью полнотекстового индексирования средствами MySQL. Т.е. весь контент храниться в базе и создаются FULLTEXT индексы, по которым и идёт поиск.

Я обычно делаю иначе: отдельно хранится контент -- и отдельно поисковый индекс. Простейший вариант таков:

1. Таблица всех слов (id и текст слова).
2. Индекс использования (id слова и ссылка на документ, обычно тоже некоторый идентификатор)

Это не самый оптимальный вариант, но хорошо переносится на любые реляционные БД.

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

(что-то мы от темы ушли... :) )

Я об этом думал. Но мне кажется, что таблицы слов получаться большие? Да и как определять релевантность? И ещё одно отступление от темы нити. У кого ты обычно хостишься? А то я тут залетел с 350mb.ru и больше не хочется подобных проблем.
P.S. Рад, что здесь есть люди с кем можно предметно поговорить.

А что часто люди переходят с MySQL на MSSQL или наоборот?

Словарный запас современных авторов не особо велик. Так что все не так страшно. Из поисковой базы прошлогоднего проекта, заполнявшейся около двух лет:

Всего слов (во всех формах): 246,940
Суммарная длина: 2,251,335 символов

Т.е. это, в принципе, даже в RAM можно было бы держать при правильной организации.

Никак. :(

А я у себя хостюсь. Увы. :)

Я как раз сейчас переношу один проект с MS SQL на MySQL -- возникла потребность хостить его на чужой площадке, а там кроме MySQL ничего не предлагают. :)
Не так уж редко встречается перенос между MySQL и Postgre, но лично мне не приходилось.

Ты не ответил чем плох FULLTEXT в MySQL он ведь делает тоже самое+релевантность+скорость+ещё что-нибудь в 4-ой версии.
А где можно посмотреть на твой поиск?

1. Эта фича MySQL относительно свежая и не везде стоит достаточно новая версия сервера.

2. Фича не до конца отлажена.

3. Нет уверенности, что она всегда корректно работает с русским языком. Был такой слух, но я не проверял.

4. Задолбаешься привинчивать к этому морфологический поиск если того протребует задача.

А как ты привинчиваешь морфологический поиск к своим поисковым движкам?

Простейший вариант таков:

1. Помимо списка слов заводим список производных слов (два поля: id базового слова и текст слова). В список слов, упомянутый ранее, заносим только базовые формы.

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

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

Вроде списки синонимов (кошка = кошке = у кошки и т.д.) будут и в Mysql 4

...и это приятно.

Лично я пользуюсь Mastak Absolute Perl (раньше mPS)
рулит!

А в чем конкретно он рулит?