Visual Basic в Gnumeric

Ну, все... А я думал, что из этого что-то получится... Мда... Даешь бейсик в качестве скриптового языка... Я уж думал, что все таки в юниксах у нас, следуя примера Emacs и прочих нормальных вещей, скриптовый язык - Lisp... Оказывается нет... Visual Basic... %-(

Главное - чтобы софт был скриптабелен (то есть был заточен для этого). А конкретный язык скриптовый язык - это лишь оболчка, которую легко можно заменить. То есть не составит больших трудов (таких как переписывания с нуля всего gnumeric) сделать внутренним скриптом gnumeric'a python или perl или что-то еще. Ну и с точки зрения совместимости - Excel юзает VB. Поэтому если бы скриптовым языком был не VB, были бы проблемы испорта файлов с макросами в Excel. И еще - OpenOffice тоже юзает Basic. Поэтому пока лучше доделать поддеркжу VB.
У тебя типичная реакция - "ну все, царапина на двери шестисотого мерса - придется его выкинуть на свалку и ездить на троллейбусе. Или пойти застрелиться".

2GreyCat: Ну по-поводу не любви к VB мы совпадаем...:) Но вот Lisp... имхо это не лучший вариант для скриптового языка электронной таблицы, текстового процессора и прочего... Имхо оптимален был бы Forth, но этот язык имхо незаслуженно забыт...:(
К слову - лиспоподобная, VB-подобная и прочие надстройки над Forth либо уже есть, либо пишутся с пол-пинка... Вообще Forth обладает одной приятной особенностью - при решении на нем некой задачи ты практически автоматически получаешь скриптовый язык, заточенный под решении задачь этого класса...:)

Мнда, шум на пустом месте, честно говоря... На текстовый и табличный редактор перл идеален. И вообще, аналога приличного для него просто нет.

2anonymous: если ты не знаешь приличных аналогов, то это не значит что их нет...:)
Впрочем я не удивляюсь что выбрали именно VB... имхо многие последние разработки не что иное как попытки тупо копировать решения мелкософта...

Слушай, Irsi, есть такое понятие - "совместимость". Чтобы gnumeric мог открывать и писать excel файлы с макросами, он должен в идеале поддерживать VB. Я тоже не торчу от VB (и думаю, и остальные). Но поливать грязью разработчиков gnumeric за то что они еще не сдалали perl bindings - просто не хорошо. Если у тебя есть время и возможности - сделай их сам или оплати эту работу кому-нибудь.

Тут перл не идеален. С типами напряги...

2hvv: имхо я никого грязью не поливал... И не радовался чужим проблемам в отличае от некоторых...
А по-поводу тупого, в смысле не творческого, копирования технологий мелкософта многими разработчиками GPL-софта я разве не прав? Посмотрите внимательно на кде, гнома, fvwm95 и софт под них... ничего не напоминает? :)
Нет я не против - у мелкософта есть очень неплохие нароботки в области гуевого междумордия... Но зачем передерать не только достоинства, но и явные промахи? :(
Еще раз, внимательно - применение такого языка как FORTH позволит легко и просто добится совместимости с чем угодно - хоть с VB, хоть с перлом, хоть с чертом лысым...:)

IMO опять ты гонишь. Если автомобили двух фирм похожи тем, что у каждой из них 4 колеса или что двери не в крыше - что - следует заявлять о плагиате? Тоже самое и gnome/kde vs Win* - коль у них есть какой-то аналог таксбара - значит это полная копия Win*? Чушь. Панели KDE и Gnome на порядок гибче и круче и удобнее панели винды. И вообще, интерфейс MS стянула у Apple, а она у Xerox.

2hvv: внимательно смотрим на интерфейс - он отличается от мелкомягкого гораздо меньше чем мелкомягкий от маковского... Ну впрочем спорить бессмыслено имхо, да и не о том речь... Тебе были сказаны четкие претензие и мое имхо как надо было делать - ты переводишь все на флейм... Впрочем чего еще можно ждать от поставщика подобных заметок...

Ну я не знаю чем ты смотришь. Посмотри повнимательнее на gnome panel. Их можно иметь несколько на экране. Они могут занимать не всю размерность экрана. Они могут блокироваться в свернутом состоянии. Можно убать/добавить taskbar. Есть достаточно много всяких мониторов (типа память, кол-во писем). IMO это намного функциональнее чем в винде. Может в дефолтовой конфигурации он немного похож. Про панель КДЕ - не помню.
Насчет удобности гуев - почитай архивы gtk-list-devel@gnome.org как они полируют gtk - они рассматривают тонну виджетсетов и советы профессиональных гуи-дизайнеров. Есть ли у виндов tab-completion в файловых диалогах? Ты можешь раскрасить каждую кнопку в свой цвет в данном окне данного софта?
Попробуй в своей винде поставить размер шрифта 14 пунктов и темный цвет фона. Ты ей не сможешь пользоваться - все имеет фиксированные позиции и размеры. Сделай то же в gnome - все будет нормально.
Короче, чем больше с тобой общаюсь, тем больше понимаю что ты об[ективно - нихрена ни что не знаешь (по крайне мере порог выпендрежь/знания превышает пределы приличия).
А то что новость запостил я - просто хотел чтобы на данном сайте где мне легко флеймиться была запощена качественно переведенная и сформулированная новость, а не, что на linux.ru.net или на linuxnews.ru (там вообще ее нет - сайт совсем куплен).

>Попробуй в своей винде поставить размер шрифта 14 пунктов и темный цвет фона.
>Ты ей не сможешь пользоваться -
>все имеет фиксированные позиции и размеры.
>Сделай то же в gnome - все будет нормально.

У меня есть сильное подозрение, что в Gnome будет тоже все довольно
плохо. Во многих приложениях русские надписи (которые обычно длиннее
английских) вылезают за расчитанные под них ячейки и обрубаются. Не знаю
как в новых версиях Gtk+, а в старых времен Gnome 0.20 все размеры
и расположение в диалогах задавалось статически в пикселах.

2hvv: вот о чем и я - содрали костяк с мелкософта, навесили кучу ненужных фичь, а ничего действительно полезного не добавили... Например возможность легко и просто назначить любому файлу любую иконку или установить цветовые метки...:) Впрочем это я слишком многого захотел - на линуксе это в принципе невозможно адекватно реализовать...:(
Про панели - в виндах есть нечто аналогичное, и еще больше реализуется с помошью доп. прог третих фирм, но это тоже не важно...
Короче - в интерфейсе гнома нет изюминки, нет той фичи, которая делала бы его _принципиально_ отличным от мелкомягкого... Нет, я не спорю - при первом взгляде он может быть похожим на виндовый... Вон AQUA тоже при первом взгляде похожа... а ты покапайся и увидиш ну очень существенные отличия в концепции...

Еще раз - речь шла о другом! Я считаю что прикручивать VB к Gnumeric это неправильно! И сказал что имхо надо было прикручивать - FORTH. Возразить что-то по существу можешь? :)

>2hvv: вот о чем и я - содрали костяк с мелкософта, навесили кучу
>ненужных фичь, а ничего действительно полезного не добавили...
>Например возможность легко и просто назначить любому файлу любую
>иконку или установить цветовые метки...:) Впрочем это я слишком
>многого захотел - на линуксе это в принципе невозможно адекватно
>реализовать...:(
Наутилус (который в бетах пока ходит) позволяет ассоциировать коментарий с любым файлом. Насчет иконки - кому это надо? (Хотя если файл - картинка - то будет создан thumbnail и использован как иконка). Я не понял что такое цветовая метка. Но сырцы у тебя есть - это прикруть за день можно (вся инфраструктура есть).
А ты, коль считаешь себя умным, попробуй про себя порассуждать, что вообще нужно на панели и как должны вести себя виждеты (а то ты просто хочешь иметь "десктоп от MS" несмотря на то что он сам гниловат как десктоп). Можешь свои измышления послать командам гнома и КДЕ. Ты увидишь, что скорее все все это уже реализовано и добавить собственно нечего.
>Про панели - в виндах есть нечто аналогичное, и еще больше реализуется
>с помошью доп. прог третих фирм, но это тоже не важно...
Я бы побоялся их. Очень трудно писать такой более-менее системный софт для виндов - нет документации.. И поставишь - а потом ворд запускаться не будет или что-нить такое.
>Короче - в интерфейсе гнома нет изюминки, нет той фичи, которая делала
>бы его _принципиально_ отличным от мелкомягкого...
Предназначение десктопа - быть удобным, а не быть коренным образом отличным от чего-либо. Есть идеи - делись или сам воплощай.
>Еще раз - речь шла о другом! Я считаю что прикручивать VB к Gnumeric
>это неправильно! И сказал что имхо надо было прикручивать - FORTH.
>Возразить что-то по существу можешь? :)
Я уже начал сомневаться в твоей способности понимать русский язык и просто мыслить. Выше я уже 2 раза сказал, что VB в гнумерик необходим для преджоставления совместимости с Excel'ом.

>У меня есть сильное подозрение, что в Gnome будет тоже все довольно
>плохо. Во многих приложениях русские надписи (которые обычно длиннее
>английских) вылезают за расчитанные под них ячейки и обрубаются. Не
>знаю
>как в новых версиях Gtk+, а в старых времен Gnome 0.20 все размеры
>и расположение в диалогах задавалось статически в пикселах.
В принципе gtk позволяет размещать виджеты и в фиксированных позициях. Но этим не рекомендуется пользоваться под страхом смертной казни (и этим действительно неудобно пользоваться программерам). Для размещения виджетов следует юзать его умные контейнеры типа таблица или коробка. Тот софт, который ты имеешь ввиду либо написан ламерами, либо это версия 3х летней давности. Если надписи обрубаются на полбуквы в коротких надписях (типа "файл") то это ты нарвался на ошибку в gdk (бери у меня мой патч где-то на http://www.hippo.ru/~hvv/projects.html и все будеть ОК). Симптомы ошибки следующие: при изменении размера шрифта скажем с 10 до 14, размер показанной надписи пропорционально (ну или хоть как-то) увеличивается но хвост остается усеченным - то это она (тупой способ исправления - вернуть /etc/gtk/gtkrc.ru на место и ты не сможишь ставить шрифт через gnome control center, умный - наложить мой патч). Если че - пиши мылом.

Предпоследнее сообщение от anonymous dated 2000-10-30 23:03:26.0 - тоже мое. Забыл имя воткнуть.

2hvv: уххх... еслиб имел такую возможность - понял бы как это бывает удобно, назначить произвольную иконку на произвольный файл...
Цветовые метки это когда файл просто выделяется цветом, тоже весьма удобно...
К сожалению все эти возможности очень тяжело реализовать без многопоточной FS, а ext2 насколько я помню таковой не является... Да и вообще - возможность иметь несколько потоков файла очень облегчает жизнь разработчикам GUI...
По поводу удобства - к сожалению я не могу сказать что гном или кде в плане удобства сильно лучше или хуже мелкомягкого - имхо один черт. Что-то сделано хуже, что-то лучше... Но увы эти отличия непринципиальны - и там и там нет действительно нужных и удобных вещей... Да, гном и кде гибче в настройке, но увы - удобства им это не добавляет.

По поводу скриптового языка - как я понял это у Вас проблемы с русским...:) Почему? Цитирую себя любимого: "К слову - лиспоподобная, VB-подобная и прочие надстройки над Forth либо уже есть, либо пишутся с пол-пинка..." Итак использование FORTH позволяет без особых проблем добиться совместимости по скриптам с Exel и не только с ним.

> Цветовые метки это когда файл просто выделяется цветом, тоже весьма
> удобно...
По какому критерию файл должен выделяться цветом? Если для всех файлов данного типа - то это просто - назначить иконку расширению или типу, который отвечает 'file' на этот файл. Но цвет - это тупо так как может конфликтовать с твоей темой.
> К сожалению все эти возможности очень тяжело реализовать без
> многопоточной FS, а ext2 насколько я помню таковой не является... Да и
> вообще - возможность иметь несколько потоков файла очень облегчает
> жизнь разработчикам GUI...
Вообще-то гном и кде - не чисто для линукса, поэтому они обязаны юзать только стандартный unix API. Поэтому ассоциирование информации с файлом (например комментарий) происходит посредством базы данных. Многопоточность - тоже не на всех fs. Но ты говоришь о нескольких потоках файла. Это как в винде что-ли с OLE сделано? Bonobo позволяет делать это. И не на уровне файловой системы. Возможно аналог этого есть и в KDE.
> По поводу удобства - к сожалению я не могу сказать что гном или кде в
> плане удобства сильно лучше или хуже мелкомягкого - имхо один черт.
> Что-то сделано хуже, что-то лучше... Но увы эти отличия
> непринципиальны - и там и там нет действительно нужных и удобных
> вещей... Да, гном и кде гибче в настройке, но увы - удобства им это не
> добавляет.
Ты прям как девочка - это не нравиться, то не нравится, хочу как у Оли и все - а почему - не знаю. Об[ясни, что ты имеешь ввиду под "нужными и удобными вещами"? Только не надо говорить - "ты сам когда-нить поймешь".. Держу пари ты ничего внятного не скажешь.
> По поводу скриптового языка - как я понял это у Вас проблемы с
> русским...:) Почему? Цитирую себя любимого: "К слову - лиспоподобная,
> VB-подобная и прочие надстройки над Forth либо уже есть, либо пишутся
> с пол-пинка..." Итак использование FORTH позволяет без особых проблем
> добиться совместимости по скриптам с Exel и не только с ним.
Приятно, что ты перешел на "Вы" :) Допустим что ты хоть немного прав. Есть ли гнушные реализации forth'а? Есть ли возможность сделать эту VB-подобную настройку 100% совместимой (именно 100%-но) с VB? Я дико сомневаюсь. (Всякие там исключения, модули и пр. - врядли это можно симитировать на этом форте.) Так что не надо ля-ля.

Нет, хайлантинг по типу файла это не интересно... Именно для отдельно взятого файла - очень удобно, делаешь какой-то документ, потом надо бежать... пометил его чтоб он к примеру красным выделялся и все...:) Очень удобно имхо...
На счет многопоточности - это как в NTFS, HFS (там всего два потока - data fork & resorce fork), BFS, HPFS... В последних двух это зовется Extended attributes...
К слову - использование БД вместо потоков это конечно выход... Правда тоже не лучший имхо...:(
Имхо я сказал что мне хотелось - цветовые метки, произвольные иконки... Ну и что-нибуть типа трекера: http://www.opentracker.org

Гнутые реализации форта есть. Подробней - начни с http://www.forth.org.ru ;)
На счет 100% совместимости - ну если начать с этого то имхо такой совместимости с мелкомягкими продуктами никогда добиться не удасться, да и не нужно это...:) Дальше - почему это на С++ это все "симитировать" можно, а на форте - нет? :)) Можно, все можно...:) Форт уникальный язык, правда если тебя не пугает польская нотация и вообще стековые машины...:)

Ну насчет произволных иконок и цветов - это будет совершенно нетрудно добавить в Nautilus. Но я для пометки файлов бы завел каталог типа tofinish и делал в нем симлинки на доки которые я бы доделал. Такой подход дает категоризировать файл по несольким критериям сразу (а цвет - он ведь только один), собирает файлы в одном месте и такая "маркировка" будет видна не только файл-менеджеру но и утилитам коммандной строки.
Про многопоточные файлы по твоей терминологии: это получается 2х поточные файлы. Это нестандартно для юниксов. Неоднозначна логика обработки таких файлов (что делать при копировании, симлинкинге, etc). По NFS не работает. Короче, без EA легче чем с ними. И использование БД дает per-user storage (так как все дерьмо лежит в одном файле базы данных (или в двух -системной БД и пользовательской БД) и исчезает вместе с каталогом юзера. Это удобнее.
>На счет 100% совместимости - ну если начать с этого то имхо такой
>совместимости с мелкомягкими продуктами никогда добиться не удасться,
Однозначно и без проблем можно добиться 100% совместимости с синтаксисом VB от MS.

2hvv: цвет - не один...:) В фингере предопределено для этой цели 8 цветов...:) Этого вполне хватает, хотя конечно наверно сделать это расширяемым...:) Ааа... написал и понял о чем ты... нет - вот это какраз будет излишнее усложнение имхо, здесь уже надо будет применять иные методы... в конце-концов есть системы управления документами...
На счет утилит командной строки - а что мешает и их научить понимать эти метки и отображать их? Имхо ничего кроме ч/б экрана...:) Но разумеется только в том случае если это будет реализовано на уровне FS...
Многопоточные файлы - это те которые содержат больше одного потока...:) EA и df+rf это всего лищь частный случай от более общего понятия - многопоточная FS. Как меня учили - есть всего три значения: ни одного, один и много...:)
Логика обработки - однозначна имхо, вон Darwin нормально с ними управляется... а это тоже юникс... BeOS - тоже нормально управляется, а и в ней от юникса очень много...
NFS - да проблема, надо модернизировать... Но с другой стороны во-первых можно приспособить и не модернизируя, правда хммм... кривовато... С другой стороны - NFS мало кто использует, обычно использую самбу, а она умеет, точнее научить можно это 100%...:) По крайней мере при передачи многопоточного файла между двумя w2k потоки не теряются...
А насчет per-user storage - хммм... а зачем? Юзер назначает метки и иконки на _свои_ файлы, в _своем_ каталоге... так что так же исчезнет вместе с каталогом...:)

>Однозначно и без проблем можно добиться 100% совместимости с синтаксисом VB от MS.
Ну тогда однозначно все равно на каком языке этого добиваться...:)
А если учесть что форт реализуется очень просто - ядро эээ... форт-системы, интерпретатора, форт-машины (как больше нравится так и называй) занимает 4-16Kb и программы на нем исполняются просто фантастически быстро... Имхо решение на основе фортн при немножко большей трудоемкости имеет очень много преимуществ... да и трудоемкость здесь вопрос спорный...

Люди, речь о чем была первочально? О поддержки VB в Gnumeric. Моя точка зрения: почему это плохо. Плохо это потому, что язык бейсика сам по себе крайне ущербный, изначально построенный на куче противоречивых и довольно расплывчатых концепций. Хорошая его реализация достаточно трудна (хороших я пока не видел), а то, как его делают обычно накладывает кучу ограничений на программу, стиль программирование и в конце концов вообще на функциональность. А самый большой сакс заключается в том, что гномовцы якобы "для совместимости" взяли его за основу всей скриптовой системы Gnome Basic. Я практически уверен, что идеальной реализации бейсика у них не получится, а получится опять "нечто", призванное косить под VB. А "для совместимости" надо было делать не основным языком бейсик, а быстрый и простой враппер или проще даже - конвертор с VB на другой избранный язык. Каким этому языку быть - наверное тут действительно надо бы было посидеть-подумать, а не кидаться писать... Наверное, что-то абстрактное с биндингами на C-like, Lisp-like и Python/Perl/т.п...

2GreyCat: можно подумать... только сначала имхо стоит сформулировать требования к языку... Попробую начать:
1. Интерпретируемый.
2. Высокая скорость выполнения.
3. Легкость адаптации к разным классам задачь.
4. Невысокие требования к ресурсам.

Что еще хочется?

Как я сказал, bonobo поддерживает многопоточные докумнеты (иначе object emedding нельзя реализовать).
> Логика обработки - однозначна имхо, вон Darwin нормально с ними
> управляется... а это тоже юникс... BeOS - тоже нормально управляется,
> а и в ней от юникса очень много...
Все равно это гниловато. Еще надо проверить, что у них многопоточность файлов прямо реализована. Да и по-любому, многопоточность это IMO все-таки это свойство framework которую ты юзаешь (и их может быть несколько). Поэтому выносить это на уровень fs/ядра глупо. Скорее всего что в beos/darwin это реализовано не в ядре тоже. Хотя Линус заверил что многопоточная fs будет и в линусе (но не все с ним согласились :).
> NFS - да проблема, надо модернизировать... Но с другой стороны
> во-первых можно приспособить и не модернизируя, правда хммм...
> кривовато... С другой стороны - NFS мало кто использует, обычно
> использую самбу, а она умеет, точнее научить можно это 100%...:) По
Это в совке юзают в основном Самбу. А вот в корпорации Сан я думаю что содержимое домашнего каталога лежит на дико больком NFS (или AFS) сервере и люди юзают автомонтер чтобы можно было логиниться с любой машины в конторе и автоматически иметь в привычном месте свой каталог со всеми своими файлами и настройками (по-крайне мере есть конторы которые черезвычайно активно юзают nfs таким образом).
> 2GreyCat: можно подумать... только сначала имхо стоит сформулировать
> требования к языку... Попробую начать:
> 1. Интерпретируемый.
> 2. Высокая скорость выполнения.
> 3. Легкость адаптации к разным классам задачь.
> 4. Невысокие требования к ресурсам.
> Что еще хочется?
Да блин. Представляю, что здесь будет обсуждаться через пару дней :) Не уж-то bsd rules linux sucks? :)
> А насчет per-user storage - хммм... а зачем? Юзер назначает метки и
> иконки на _свои_ файлы, в _своем_ каталоге... так что так же исчезнет
> вместе с каталогом...:)
Пользователь должен иметь право комментировать файлы в любом каталоге (и даже read-only для него и на read-only fs), не так ли?

Ладно Irsi, с логикой у тебя хреново. Мне надоело с тобой поэтому пустым трепом заниматься (ты не пытаешься толком обсуждать предмет обсуждения потому что не хочешь нормально думать или не знаешь предмет обсуждения). Я тебе отвечать на твой треп не буду.

Опять бредовое обсуждеие Линуксойдов. Начали с выбора языка, кончили непонятно чем..

1) Про Бейсик:
Как язык он вполне неплохой, особенно для создания прикладных приложений. Если можно будет писать проги для Linux на VB, то я Линукс стану немного уважать. Лично я многое пишу на бейсиках (АСП, vB) и не жалуюсь. А вообще, если честно, не за рубежом, не у нас никому не нужны программисты приложений под Линукс. Perl, PHP - нужны, а прикладные нет.
2) Про сдир
ДА! Все оболочки Линукс - это откровенный сдир с Windows. После успеха WIn 3.1 и Win95 в 96 году стали разрабатывать CDE, а потом и Гном с КДЕ. Про Гном ничего не могу сказать, потому что это полная фигня, а КДЕ - неудавшиеся и тормознутая попытка улучшить интерфейс Windows.
3) Всем писавшим
Если в вашу систему хотят добавить что-то стоящее, то не надо противится этому, а наоборот радоваться. Может когда-нибудь такими темпами Linux до уровня Winды дорастет.

Ребяты, ну что мы опять обсуждаем ? Windows vs Linux ? Или же действительно тему ? Я вот считаю, что поддержка Бейсика нужна именно для совместимости, чтобы сделать переход от Win к Lin нормальным. С документами-то особых проблем уже нет, в вот с таблицами... Ну почему у нас компутерные конторы любят Excel ??? Какой-то скриптовый язык все рано нужен. Пусть это будет Бейсик, раз уж так пошло. Но я бы предпочел какой-нибудь Perl.

>2) Про сдир
>ДА! Все оболочки Линукс - это откровенный сдир с Windows.
А WindowMaker и AfterStep? Для справки: NeXT, с которого они
содраны появился в 1989 году, когда Win 3.* еще не было.

2hvv:
"Еще надо проверить, что у них многопоточность файлов прямо реализована."
"Скорее всего что в beos/darwin это реализовано не в ядре тоже."

Понятно - про многопоточность Вы от меня впервые в жизни услышали...:)

Про NFS - не слушаем, есть возможность использовать многопоточные файлы over NFS без ее модернизации...:)

"Пользователь должен иметь право комментировать файлы в любом каталоге (и даже read-only для него и на read-only fs), не так ли?"
Однозначно не так! Если хочет - нехай создает на него линк и комментирует _его_. Почему? Ну положим админ положил некий файл ридонли для остальных юзверей и закотел привесить к нему публичные комментарии...

"Ладно Irsi, с логикой у тебя хреново. Мне надоело с тобой поэтому пустым трепом заниматься (ты не пытаешься толком обсуждать предмет обсуждения потому что не хочешь нормально думать или не знаешь предмет обсуждения). Я тебе отвечать на твой треп не буду."

Имхо это про тебя...:) Я-то над подобными проблемами давно думаю, а ты явно о них только что от меня услышал...:)

2eliterr: еще раз, использование FORTH позволяет убить нескольких зайцев сразу:
1. Поиметь быстрый и нормальный скриптовый язык.
2. Легко и просто добиться совместимости с VB, lisp, perl и вообще с чем пожелаешь...:)

2Elohim: AfterStep и близко не лежал к NextStep по функциональности, просто внешний вид содран и не более того... многопоточная FS нужна...

2Irsi: спорить ни о чем не буду - что же такое многопоточные FS по твоему мнению? Это ведь тоже что и в MS OLE - что-то типа structured storage? Однозначно это не fs с просто extended attributes.
Будет мне интересно посмотреть, как ты будешь всю семантику перла (включая поддержку rx) на форте симулировать...

2hvv: многопоточная FS это когда _один_ файл может представляться _несколькими_ i-узлами. Т.е. практически создание многопоточной FS заключается в небольшой модернизации формата записи в каталогах...:)
RX для форта реализованы давно...:) Да и перлоподобная надстройка - тоже...:)

> 2hvv: многопоточная FS это когда _один_ файл может представляться
> _несколькими_ i-узлами.
А в чем кайф всего этого - для чего это полезно? Как делать симлинк и хардлинк на такой файл? Владелец у всех этих потоков может быть только один? Все равно это не портабельно и посему надо воспринимать как экзотику.
> RX для форта реализованы давно...:) Да и перлоподобная надстройка -
> тоже...:)
Ну сами rx это ежику понятно для всех языков реализованы. А вот 100% совместимость с перлом по семантике вряд ли ты получишь не дублируя перл целиком (да я думаю даже here-documents конструкцию ты не сделаешь для перла на форте (в смысле никто не сделает) ).

В чем полезно? Ну я вроде уже объяснял... это позволяет упростить реализацию GUI. Сам смотри - во втором и т.д. потоках можно хранить ресурсы (иконки и т.д.), наличае/отсутствие меток, комментарии и т.д.
Линки это разве не просто запись в фале каталога? :) Не забыл что мы изменили ее формат? :)
Поскольку информация о владельце и правах доступа хранится в i-node, то в общем случае они могут быть разными...
Ещк раз - на чем реализован интерпретатор перла? Какие _принципиальные_ сложности в том чтоб его реализовать на другом языке, например на форте?
И вообще нелогично - сделать свою 100% совместимую реализацию _закрытого_ VB ты считаешь вполне возможным, а _открытого_ перла - нет...:))

> И вообще нелогично - сделать свою 100% совместимую реализацию
>_закрытого_ VB ты считаешь вполне возможным, а _открытого_ перла -
> нет...:))
Очевидно что ты не знаешь перл :) Да, если и можно его симулировать на форте, то чтобы написать симуляцию, надо убить лет 5. А перл ценен не только самим собой но и содержимым CPAN - а в них бывают порой такие хаки..
> В чем полезно? Ну я вроде уже объяснял... это позволяет упростить
> реализацию GUI. Сам смотри - во втором и т.д. потоках можно хранить
> ресурсы (иконки и т.д.), наличае/отсутствие меток, комментарии и т.д.
> Линки это разве не просто запись в фале каталога? :) Не забыл что мы
> изменили ее формат? :)
Зачем тогда явно оговаривать, что под это дерьмо будут выделяться еще иноды? Если не оговаривать, от получаются просто EA. Ведь вся эта дополнительная инфа - просто адресуется с помощью ключа, не так ли? По NFS всю эту доп. инфу не расшаришь - надо изменять протокол. Для кластерных fs - эта метаинформация тоже - кость в горле (ну короче, дико портит стройность модели данных). Короче, однозначно многопоточных fs не будет в Singe Unix Specification в ближайшие 100 лет. А по сему на них можно забить как нисколько не рапространенную экзотику. Точка.

Да, на перле писать не приходилось...:) Впрочем ты явно не знаешь VB - он тоже ценен наработками, а там хаков боюсь поболее будет...:)
Выделение i-node позволит лучше структурировать эту инфу, облегчит с ней работу, не даст возможность ограничить ее размер, облегчит обеспечение совместимости с более ранними вещами, например с той же NFS. Ибо для тех прог/протоколов что не знают о существование многопоточности можно будет отдавать каждый поток как отдельный файл.
На счет "адресуется с помощью ключа" - не понял... Т.е. по-твоему если файлу назначается некая иконка, то в потоке хранится только ссылка на нее? Не верно - в доп. потоке в общем случае может хранится сама иконка ... Оптимально имхо было бы в случае иконки по умолчанию хранить только ссылку на нее, а если юзверь назначил свою иконку, то ее саму...
"Короче, однозначно многопоточных fs не будет в Singe Unix Specification в ближайшие 100 лет."
Не думаю... В большинстве ОС многопоточная FS уже реализована в том или ином виде... Отсутствует как класс только в 9x & linux... Достойная компания...:)

> Впрочем ты явно не знаешь VB -
> он тоже ценен наработками, а там хаков боюсь поболее будет...:)
Да, я на простом бейсике в глубокой молодости писал. С тех пор к бейсикам не прикасался. Но не думаю что там хаки такие полезные как на CPAN.
> На счет "адресуется с помощью ключа" - не понял... Т.е. по-твоему если
> файлу назначается некая иконка, то в потоке хранится только ссылка на
> нее?
Я предполагал, что это есть системный вызов, которому говоришь ключ (ну название потока, например ICON-NAME) а тебе в буфер пишут данные и длину данных (то есть ты адресуешь метаданные по ключу как в БД - или как?). О том, что храниться в потоке решает тот, кто его создавал, так что наверно не имеет смысле говорить о том, как хранить иконки и пр.
> Не думаю... В большинстве ОС многопоточная FS уже реализована в том
> или ином виде... Отсутствует как класс только в 9x & linux...
> Достойная компания...:)
Даже если у других все это есть то API не стандартизирован. Способ хранения (инод под каждый поток или все вместе) тоже не стандартизирован. Нет стандарта на семантику - то есть что будет с потоками если ты копируешь файл? chown/chmod? Есть ли понятия owner& permissions для каждого потока? Что делать с форматом tar? IMO ответы зависят от предметной области и поэтому к единому соглашению никогда не придут. И что, они в UFS (то есть BSD и солярке) тоже есть? С одним инодом на каждый поток? В гноме уже есть функции gnome_metadata_* которые позволяют ассоциировать метаданные не только с конкретным файлом, но и с файлом, имя которого отвечает rx или типу mime. При запросе метаданных для файла будут учтены все эти источники инфы. Это куда мощнее чем назначать что-то для каждого файла по отдельности.

"Но не думаю что там хаки такие полезные как на CPAN."
Ээээ... смотря для кого - боюсь что если сравнивать важность хаков VB для программера на нем и важность хаков на CPAN для программера на перле, то боюсь в первом случае значимость будет больше. К слову - чем больше кол-во жизненонеобходимых хаков, значит тем хуже система...:) Имхо в идеальной системе нет необходимости в хаках вообще...:)

Ну начнем.
1. "API не стандартизирован"
Это так. Но не боги горшки обжигают. :)
Имхо потребуется небольшая модификация уже существующего API для работы с файлами, а конкретно - добавление необязательного параметра "номер потока". Если этот параметер не указан всегда используется нулевой (или первый - как считать) поток, в котором и хранится "традидиционный" файл.
К слову такой подход позволяет легко добиться обратной совместимости...
2. Способ хранения (инод под каждый поток или все вместе) тоже не стандартизирован.
Ээээ... еще раз - многопоточная FS это та где одному файлу может соответствовать более одной i-node.
Соответственно - каждая i-node на файл образует поток. Файл определенный одной i-node это однопоточный, "классический" файл, двумя i-node - двухпоточный (ну как в HFS к примеру), три i-node - три потока и т.д. Имхо это очевидно...:)

3. Нет стандарта на семантику - то есть что будет с потоками если ты копируешь файл?
Есть стандарт - при копирования средствами знающих о существование многопоточности копируется все потоки (одна логическая еденица - файл), при копировании средствами не знающих о существовании оных копируется только нулевой поток. См. ответ на тему API. При копирование на однопоточную FS многопоточной тулзой получается несколько файлов, нулевой поток имеет то же имя, к именам доп. потоков добавляетс .ft[n] где n - номер потока.

4. Есть ли понятия owner& permissions для каждого потока?
См. ответ на п.2 Поскольку эта информация хранится в i-node имхо ответ очевиден.

5. Что делать с форматом tar?
См. п.3 в части про однопоточные FS и многопоточные тулзы.

6. функции gnome_metadata_*
Это не противоречит многопоточным FS и не делает их ненужными. Имхо эти средства прекрасно дополняют друг-друга. См. реализацию работы с mime-type в BeOS.

Короче - все перечисленные тобой проблемы давно решены в рамках проектов по обеспечению совместимости MacOS & Win/Dos... С незначительными доработками эти принципы с успехом применимы и в мирк *nix.

Ну BSD и солярка не самые новые ОС, согласись...:) К слову - в Darwin (основан на FreeBSD) они есть...

Так я тебя и не понял - многопоточна ли UFS которая идет с бздями и соляркой?
А на CPAN лежат не хаки, а достаточно общие библиотеки (и большинство из них - не врапперы, а реализации чего-то на перле - например протокола ftp). Некоторые из них (типа профайлер кода) используют некоторые хаки (или типа с загрузкой модулей) чтобы мочь работать.
Насчет fs - короче, все равно они в 99% случаев нужны только для файлового менеджера (в смысле, он их создает и редактирует и удаляет). Реализация многопоточности в fs нужна только для того, чтобы не переписывать целиком cp, rm, mv и пр. :) - и пользовательским софтом многопоточность fs не юзается (ну может только когда файл создается указывается тип файла или программа обработчик). Все. Лично я не планирую писать софт только для Beos или Darwin или NT. Поэтому я благополучно забуду обо всем этом.
Правда меня все-же интересует вопрос - как потоки идентифицируются - у них же должны же быть имена (или их надо перебирать все?). Вот скажем, хочет менеджер файлов узнать иконку для данного файла. Что именно он сделает чтобы узнать ее на ФС с потоками? Вариант1: он знает, что иконка (или имя) лежит в потоке с ключем ICONNAME (то есть потоки идентифицируются по ключу-строке). Вариант2: потоки идентифицируются по индексу (таким образом потоку с иконкой всегда на данной ОС соотв. поток номер 7. IMO это верх тупости (EA в HPFS по-моему по ключу реализованы все-таки).
ЗЫ: щас с тобой возможно даже приятно общаться стало - от ответов не уходишь, темы придерживаешься. Так деражть :)

2hvv: я понял - это ты не понял...:) нет, не многопоточна, но кто сказал что это современная FS? Это раз... Два - многопоточные FS в основном нужны на десктопе (впрочем если подумать и на сервере им место найдется, например мне кажется что они окажутся полезны для БД, впрочем там еще полезней RAW-device...;), а фот фря _никогда_ не претендовала на роль десктопа.
Про CPAN я немного в курсе, спасибо...:) Еще раз - если модуль без хака, то проблем нет так? Если с хаком - некоторые есть, ноимхо решаемые, да и вы сами говорите что таких немного...:) Мы опять немного не понимает друг-друга - я утверждаю что достаточно полная реализация перла на форте не проблема. Блин, да почитайте Вы про форт и попробуйте пару задачь на нем решить - сразу понятней станет о чем я говорю...:)
Теперь вернемся к многопоточности. Я понял Ваш вопрос. В принципе это решается по-разному. Имхо самое хорошее решение это как в BeOS - там есть центральная БД, которая содержит описание доп. потоков и их формата для каждого mime-type.
"пользовательским софтом многопоточность fs не юзается"
Еще как юзается! например почтовая программа может хранить некоторые поля в EA и/или иначе в доп.потоке. Очень удобно для поиска сортировки - нет необходимости каждый раз распарсивать заголовки.
В мр3 в ЕА хранится mp3-tag что тоже облегчает поиск и т.д.
К _любому_ документу в ЕА хранится инфа об авторе, краткое резюме и т.д. Информация для системы управления документами (версия и все что потребуется) тоже упихивается туда же...
Все это гораздо удобней, надежней и быстрее работает чем при других решениях... И это только что пришло в голову сразу, не задумываясь... если чуть-чуть подумать то становится очень трудно жить без многопоточной FS...;)

P.S. Ага... я немного поборолся с собой и проигнорировал наезды...:) Ибо здесь был шанс на нормальны разговор...;) К слову - весь нашь спор о необходимости многопоточности в FS дико мне напоминают другие споры - о необходимости тредов в программах и убеждения упертых досовцев зачем им многозадачность...:)
Ну в тех спорах время раставило точки над i... Угадай за что выступал я...:)

>2Elohim: AfterStep и близко не лежал к NextStep по функциональности, просто внешний вид содран и не более
>того... многопоточная FS нужна..

Так я и говорил о внешнем виде. Сравнивать window manager и ОС (кстати, действительно интересную) я и не собирался.

2Elohim: хммм... непонятка вышла - я-то имел ввиду и то и то... только согласись - функциональность гуя и функциональность всей ОС это немного разные вещи... а вот функциональность некого гуя и vw это уже вполне сравнимые вещи...

2Irsi: По теме. Проведи небольшой соцопрос среди твоих знакомых, причем не только среди пальцастых программистов/администраторов. Я сильно удивлюсь, если ты получишь что-то намного отличающееся от следующего: ~90% готовы практически сразу писать на Бейсике, ~30% _слышали_, что есть такое чудо как форт, ~6% что-то писали на форте. Останется ли после этого вопрос, что же из них использовать в качестве скриптового языка, если Gnumeric - для пользователей? А если он для программистов, то на кой он вообще нужен, пара сотен скриптов на чем попало собственного изобретения, и _твои_ задачи решаются именно так, как надо. Ну не нужна в скриптах общего назначения фантастическая производительность форта. Там наглядность нужна, быстрота написания и удобство. Форт, ты извини меня, ни тем, ни другим, ни третьим не отличается. Некогда тем же бухгалтерам изучать его,они лучше купят компутер помощнее и будут писать на Бейсике. Итак, если Gnumeric ориентирован на конецного пользователя, не желающего становиться программистом, Basic - то, что надо, в Microsoft тоже не дураки сидят.

2Anonimous

Нужны программисты под Linux, нужны, успокойся. Иди спать.

2Irsi

Насчет forth
А чем scheme плох? Скорости guile (далеко не самый быстрый scheme)
под gnumeric должно хватить, IMHO.

Насчет многопоточности:
Кинь пару линков о теории ентого дела, если есть, по моему имплементация не тривиальна

О интерфейсе:
"Панелька" в GNOME, KDE и прочих - не имеет никакой связи с MS-овской.
В свою очередь, MS-овская содрана вчистую с Lotus SmartCenter восемдесят мохнатого года (пользователи OS/2 Warp4 могли её созерцать в практически неизменном виде - WarpCenter). И то, что новоламеры считают это изобретением МС...
Ещё об интерфейсе - Nautilus... Это достаточно неплохая концепция. Мне нравится.
О файловых системах:
Реализация "многопоточности" в NTFS - тоже далеко не сахар.
Сервиса ОС для работы с "потоками" (то, что у нормальных людей называется member) явно недостаточно.
Это вам не OS/400 - единственная (и только) ОС, где с этим всё в порядке.
И вообще, издайте df -i.
Если под Linux увидите что-то про i-node - значит всё плохо, т.к. работает ext2fs вместо Reiserfs.
О скриптовых языках:
Может и имело бы смысл ориентироваться на Форт, да вот только мигранты с форточек не поймут...
А интересы клиента - превыше всего.
Если бы выбор языка делал я - то это был бы ObjectREXX.

Rgds!
Affreux Chien.

2 hvv В NTFS потоки именованы. Адресация - ":" типа echo stream1 > file1.txt:str1

На счет "VB привычней для юзера" - не спорю... но еще раз - VB, perl и все остальное очень легко реализуется на форте и работает быстро... то есть каждый может получить тот язык, который хочет и писать на нем. Имхо это дает большую гибкость...
По поводу scheme увы ничего сказать не могу - прошло мимо меня...:(
ObjectREXX - тоже не знаю, сталкивалься с Regina REXX и если честно не впечатлился... впрочем REXX-образная надстройка для форта тоже есть...
Яб взял за основу форт, благо реализуется легко и просто и начал бы к нему прикручивать надстройки, в первую очередь VB, perl & lisp...

2Affreux Chien: кто у кого содрал - вопрос сложный...:) имхо панелька в гноме (и не только она) имеет гораздо большего с мелкософтом, чем с полуосью... В теории даже можно попытаться это строго доказать, но сразу предупреждаю - из-за высокой трудоемкости и имхо полной бессмысленности оного процесса я этим заниматься не буду...:)
Про реализацию потоков в NTFS - ну может не лучший вариант... но очень не плохой имхо... Назовите ОС общего назначения где лучше? :)
И еще не забывайте что использование потоков в NTFS очень жестко ограниченно требованиями совместимости с FAT/FAT32...:( Т.е. с тем что нтя не использует возможностей потоков даже на 10% я и не спорю...:( Может как помрет 9х (а это еще года два-три имхо ждать) то полегчает...
ext2fs vs Reiserfs - ну пока ext2fs является "стандартной" для линукса... К тому же - разве Reiserfs построена не на основе b-tree? А если это так то там должны быть аналоги i-node... Я если честно про нее мало что знаю, может кините в меня кратким описанием? :)

2omerm: посмотри на документацию по HFS (MacOS, на www.apple.com есть описание), BFS (BeOS, www.be.com, ключевое слово BeBook) ну и NTFS...:) А какие по-твоему проблемы будут?

> Reiserfs построена не на основе b-tree?
Угу. Но способы хранения данных там несколько совершеннее. В частности, в отличие от ext2 нет проблемы нехватки i-node, сам объект сидит в записи каталога...
Много там всего хорошего.
Кратко описать вряд ли получится... Лучше посмотреть описание на сайте ReiserFS.

2anonymous: посмотрю... но имхо многопоточность в ней реализовать будет несложно... особенно если нет проблем с нехваткой i-node...:) Сам понимаешь - многопоточность обязательно обострит эту проблему...

До сих пор не пойму, чем ext2fs лучше ufs/ffs