Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 28.05.06 20:22
Оценка:
Здравствуйте, VladD2, Вы писали:

FR>>Форт вполне высокоуровневый язык.


VD>По примерам на нем этого не заметно.


Если привык к стеку то все просто.

VD>С увдовольствием прочел бы про него статью, особенно если она будет на нашем сайте/в нашем журнале. Но копать специально желания нет. Думаю, что со мной согласятся очень многие.


http://www.forth.org.ru/

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


А как же теперешняя мода на DSL? вот пожалуйста есть первопроходец.

FR>>В общем если смотреть с позиции метапрограмминга немерле гораздо ближе к форту (и наверно к лиспу) чем к C++.


VD>Возомжно. Но тогда и сравнивать их нужно по разному. Что сравнивать одинаковые черты? Вевь смысл сравнивать разное, но нацеленное на решение одних задач. Или как в случае моей статьи сравнения реализации лознгов.


Там только идея одинаковая а реализации совершено разные, и смысл их сравнить есть.
Re[13]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: IT Россия linq2db.com
Дата: 28.05.06 20:38
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Но в мэйнстрим он не пройдет.


Почему?

FR>Даже если пройдет, то очень большая вероятность что я на нем писать не буду.


Нам будет тебя не хватать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Re[14] + Аккерман на C/C++, Forth, Lisp и Nemerle
От: FR  
Дата: 28.05.06 20:50
Оценка: -1 :)
Здравствуйте, IT, Вы писали:

FR>>Но в мэйнстрим он не пройдет.


IT>Почему?


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

FR>>Даже если пройдет, то очень большая вероятность что я на нем писать не буду.


IT>Нам будет тебя не хватать


Но вы не сдавайтись боритесь за светлое будущее и мир во всем мире
Re[15]: Зачем нужен Немерле
От: Андрей Хропов Россия  
Дата: 28.05.06 21:14
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, IT, Вы писали:


FR>>>Но в мэйнстрим он не пройдет.


IT>>Почему?


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

Ответил здесь
Автор: Андрей Хропов
Дата: 21.05.06
.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 05:14
Оценка: +1
FR,

FR>Ты про генерацию GUI никогда ни слышал?

FR>И про декларативное описание GUI тоже?

Таак, с этого места можно поподробнее. Меня интересуют следующие вопросы:

1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.

2. Что в декларативном описании GUI предлагается декларативно описывать? (Начальное состояние и так без проблем декларативно описывается в ресурсах: button1.color = clRed, а вот декларативно описать поведение — ).

3. Что генерируется в случае "генерации GUI"? Код соответствующего модуля, который рисует форму? На основании чего генерируется? Какое поведение будет у сгенерированного GUI? Как будет отладка и тестирование выглядеть?

+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).

Ну в-общем, если тебе есть чем поделиться, милости прошу.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[16]: Зачем нужен Немерле
От: FR  
Дата: 29.05.06 06:05
Оценка: +1
Здравствуйте, Андрей Хропов, Вы писали:

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

АХ>Ответил здесь
Автор: Андрей Хропов
Дата: 21.05.06
.


И что?
Ну введут в C# 3 некторые минимальные функциональные возможности, для использования которых не надо перестраивать мышление и плюс встроят пару специализированных DSL, это же как небо и земля по сравнение с Nemerle.
Взять тот же C++, большинство не пользуются метопрограммированием, в лучшем случае используют готовые библиотеки написанные с его использованием. И вообще здесь по моему переоценивают важность метопрограммирования.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 06:05
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>FR,


FR>>Ты про генерацию GUI никогда ни слышал?

FR>>И про декларативное описание GUI тоже?

LCR>Таак, с этого места можно поподробнее. Меня интересуют следующие вопросы:


LCR>1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.


Сложный GUI не генерировал, так что не совсем понимаю вопрос, генерировал только простой но объемный.

LCR>2. Что в декларативном описании GUI предлагается декларативно описывать? (Начальное состояние и так без проблем декларативно описывается в ресурсах: button1.color = clRed, а вот декларативно описать поведение — ).


В тех же tcl/tk или python/Tkinter сам код построения GUI вполне декларативен, и по объему часто меньше чем он же в XML. Обработчики конечно декларативно не делаются.

LCR>3. Что генерируется в случае "генерации GUI"? Код соответствующего модуля, который рисует форму? На основании чего генерируется? Какое поведение будет у сгенерированного GUI? Как будет отладка и тестирование выглядеть?


Генерируется код, например на питоне, некторые обработчики также генерирются, генерируется или на основании декларативного описания(которое тоже программа на том же целевом языке) или просто класса с данными. Отладка и тестирование ничем ни отличается от рукописного кода. Ну и конечно отдельно тестируется генератор.

LCR>+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).


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

LCR>Ну в-общем, если тебе есть чем поделиться, милости прошу.


Вряд ли то что нормально в tcl или python подойдет для java.
Re[9]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 06:21
Оценка:
FR,

LCR>>1. Как сделать сложный GUI без миллиона обработчиков onNthF_ckingComponentEvent? Пока я видел только три альтернативных подхода: www.drools.org, подход в ФЯ типа Эрланга, и конечно web с явным графом переходов, но имхо web приложения делать тяжелее (особенно без фреймворков), чем обычные окна.


FR>Сложный GUI не генерировал, так что не совсем понимаю вопрос, генерировал только простой но объемный.


Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :
True Unix GUI
Автор: McSeem2
Дата: 04.04.06


LCR>>+: я тоже считаю, что умный layout лучше, чем умное ёрзание мышкой, но с автоматическими генераторами GUI по спецификациям всё довольно мрачно как раз из-за последнего пункта (мы использовали Java+XSLT).


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

Согласен, это плюс.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 06:49
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :

LCR>True Unix GUI
Автор: McSeem2
Дата: 04.04.06


Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.
Re[11]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 07:49
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR>>Я о том, что при классических подходах (типа onNthF_ckingComponentEvent) сложность реализации возрастает очень быстро. Максим об этом хорошо написал :

LCR>>True Unix GUI
Автор: McSeem2
Дата: 04.04.06


FR>Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.


Подожди, ты хочешь сказать, что я пишу некий конфиг (скажем к sendmail), и потом запускаю этот конфиг под питоном, и оно чудом выдаёт формочку соответствующие этому конфигу? Причём уже с валидацией, layout-ом и т.п. И всё что мне остаётся — это написать мясцо для обработки этих данных?

Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 29.05.06 08:26
Оценка: 9 (1)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:


FR>>Так он же вроде про тоже самое что и я, что динамические языки при построении GUI одновременно могут использоватся и как декларативные языки для описания так и как код выполняющий обработку.


LCR>Подожди, ты хочешь сказать, что я пишу некий конфиг (скажем к sendmail), и потом запускаю этот конфиг под питоном, и оно чудом выдаёт формочку соответствующие этому конфигу? Причём уже с валидацией, layout-ом и т.п. И всё что мне остаётся — это написать мясцо для обработки этих данных?


Да только конфиг уже не будет произвольным, у него будет особый формат, чтобы он одновременно был и программой на питоне (или tcl) и вполне декларативным описанием.

LCR>Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?


Ну немного не дотягивает, хотя принцип вроде тот же, данные это одновременно и код.
Re[4]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 29.05.06 09:09
Оценка: 14 (1)
Здравствуйте, IT, Вы писали:

IT>Демонстрация лёгкого построения ГУИ. Рабочий код приводить совсем не обязательно, генерируемый радакторами код тоже. Просто хотя бы идею обозначить.


Тк тем и хорош, что позволяет описывать логику ГУИ

IT>Для примера, для такого простого диалога, поддерживающего валидацию и подсветку изменённых полей


подсветка добавляется парой команд. (только нафига она нужна?)

# функция валидации
proc test {val} {
    tk_messageBox -message $val
    return 1
}

# toplevel окно. не обязательно.
set w {}

# фрейм с информацией о человеке
set info $w.info
# пакуем сверху, растягиваем по горизонтали
pack [frame $info -padx 2 -pady 2] -side top -fill x 

#растягиваем 2-й столбец на всю длину
grid columnconfigure $info 1 -weight 1
#вставляем нужные поля
foreach row {{n1 "First Name"} {n2 "Middle Name"} {n3 "Last Name"}} {
#для каждого entry можно прибиндить переменную, которая будет изменяться в соответствии с вводом
    grid [label $info.l[lindex $row 0] -text [lindex $row 1] -anchor w] [entry $info.[lindex $row 0] -text [lindex $row 1]] -sticky we
}

# определяем функцию валидации для 2-го поля
$info.n2 config -validate key -vcmd {test %P}

# добавляем радиобуттон
set radio $w.radio
pack [labelframe $radio -text "Gender" -pady 2 -padx 2] -side top
foreach item {Female Male Unknown Other} {
    radiobutton $radio.the$item -text $item -variable gender -relief flat -anchor w -value $item
    pack $radio.the$item -side top -fill x
}

# снизу добавляем фрейм с кнопками
pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
pack [button $w.action.save -text Save -width 10] -side left
pack [button $w.action.cancel -text Cancel -width 10 -command exit] -side right


IT>


картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)

IT>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.
Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 29.05.06 09:10
Оценка: +1
FR,

FR>Да только конфиг уже не будет произвольным, у него будет особый формат, чтобы он одновременно был и программой на питоне (или tcl) и вполне декларативным описанием.


Да, понял.

LCR>>Чую, что до "code is data is code" картинка всё же не дотягивает... Или я не прав?


FR>Ну немного не дотягивает, хотя принцип вроде тот же, данные это одновременно и код.


Ладно, мне всё понятно (Мне эта идея, кстати, очень нравится (я имею ввиду "code is data is code")).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[5]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 29.05.06 14:22
Оценка: +1 -1 :)
Здравствуйте, night beast, Вы писали:

NB>Тк тем и хорош, что позволяет описывать логику ГУИ


ГУИ надо рисовать, а не описывать.

NB>подсветка добавляется парой команд. (только нафига она нужна?)


Это ты у пользователей спроси

NB>
NB>pack [frame $info -padx 2 -pady 2] -side top -fill x 
NB>pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
NB>

А почему в одном случае 2, а в другом 10?

IT>>[img]http://www.rsdn.ru/File/1/CsUIDemo.gif[/img]


NB>картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)


Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет

IT>>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


NB>Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.


Редактроы форм нужны не для того, чтобы что-то там генерировать. Как раз генерация — это побочный эффект реализации. Редакторы форм, как это ни странно, нужны, чтобы не заниматься рутинной стрельбой по пикселям, пристреливая контролы к форме. В том же веб, например, многие имеют все эти дизайнеры ввиду, т.к. проще и быстрее набить html ручками. Но это лишь потому, что лэйаут html контролов подчиняется своим, не связанным с абсолютным позиционированием правилам. Эта причина не единственная, конечно, но одна из основных.

NB>Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.


Да это без проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Tcl как обоснование ненужности поддержки компонентности в С++
От: night beast СССР  
Дата: 30.05.06 04:26
Оценка:
Здравствуйте, IT, Вы писали:

NB>>Тк тем и хорош, что позволяет описывать логику ГУИ


IT>ГУИ надо рисовать, а не описывать.


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

NB>>
NB>>pack [frame $info -padx 2 -pady 2] -side top -fill x 
NB>>pack [frame $w.action -padx 10 -pady 10] -side bottom -fill x
NB>>

IT>А почему в одном случае 2, а в другом 10?

да просто так

NB>>картинки вставлять не умею, уж извини. (если интересно, могу прислать по маилу)


IT>Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет


с самими тегами проблем нет. картинку куда-то на рсдн заливать надо...
то-ли дело в гугл-группах.

IT>>>Остальное — это редактор форм и библиотеки. Вот мне и интересно, насколько проще это можно сделать на Tcl.


NB>>Для тк этот код может генерировать кто угодно. никакие редакторы форм не обязательны.


IT>Редактроы форм нужны не для того, чтобы что-то там генерировать. Как раз генерация — это побочный эффект реализации. Редакторы форм, как это ни странно, нужны, чтобы не заниматься рутинной стрельбой по пикселям, пристреливая контролы к форме.


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

IT>В том же веб, например, многие имеют все эти дизайнеры ввиду, т.к. проще и быстрее набить html ручками. Но это лишь потому, что лэйаут html контролов подчиняется своим, не связанным с абсолютным позиционированием правилам. Эта причина не единственная, конечно, но одна из основных.


в этом смысле хтмл ничем не отличается от любого другого нормального гуи (тк например )

NB>>Ты можешь вставить в форму едитбокс и в реальном времени изменять эту форму.


IT>Да это без проблем.


допустим, нахаляву получаешь возможность в писать

walk $player dx dy
hit $player $enemy
...

и видеть все изменения в реальном времени.
Re[12]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.05.06 11:34
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#".


Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.

IT> Всё чего я хочу, так это увидеть хотя бы аналогичный моему пример, диалог, который умеет редактировать внешний объет. Если это так просто на Tcl, то тебе всего лишь надо привести пример из максимум 7-ми строчек кода. Код, генерируемый RAD и код библиотек я тебе приводить не предлагаю. Меня интересует заявленная тобой простота их использования, выраженная в количестве рукописного кода. В примере, который я привёл — это ровно 1 строка, вот эта:


IT>
IT>binder.Object = person;
IT>

IT>Всё что она делает, инициализирует форму переданным объектом. После твоих заявлений я ожидал чего-то подобного. Но видимо не судьба

Давно не юзал tcl, но "чего-то подного" есть:

set form [editPerson $object]


И что с того? Пример то куцый. Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 30.05.06 12:38
Оценка: :)
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>Ты сделал громкое заявление, что ГУИ на Tcl делать, цитирую "проще чем в C#".


ANS>Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.


Тут было безапелляционно заявлено, что C# отдыхает, рулит в гуях сегодня tcl. Вот это не соответствующее истине заявление я и попытался развеять.

ANS>Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.


Так это всё тоже в дизайнере задаётся или как в данном примере автоматически библиотечным/один-раз-написанным кодом.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Tcl как обоснование ненужности поддержки компонентности в С++
От: IT Россия linq2db.com
Дата: 30.05.06 12:46
Оценка:
Здравствуйте, night beast, Вы писали:

IT>>А почему в одном случае 2, а в другом 10?


NB>да просто так


Т.е. пристреливаем контролы к форме

IT>>Ну вот, в таком птичьем языке разобрался, а с простейшими тегами форматирования нет


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


В профиле есть ссылка на файлы.

NB>то-ли дело в гугл-группах.


А как там сделано, может и мы идейку потырим.

NB>тк (и тех) предоставляет возможность описать -- где расположить элементы, а не задавать вручную размеры.


Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Tcl как обоснование ненужности поддержки компонентности в С++
От: FR  
Дата: 30.05.06 13:13
Оценка: +2
Здравствуйте, IT, Вы писали:


NB>>тк (и тех) предоставляет возможность описать -- где расположить элементы, а не задавать вручную размеры.


IT>Где бы посмотреть скриншотик образцово показательной картинки таких гуёв. А то что-то меня мучают смутные подозрения.


Так он не обязывает делать вручную, есть и RAD'ости, например:
http://vtcl.sourceforge.net/
http://vtcl.sourceforge.net/?x=screen
Re[14]: Tcl как обоснование ненужности поддержки компонентности в С++
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 30.05.06 13:27
Оценка: +4
Здравствуйте, IT, Вы писали:

ANS>>Если гуй ограничить только тем, что можно накидать в визуальном редакторе на формы, то, конечно, проще врядли где получится. Правда, сложнее тоже сделать тяжело. Но, только шаг в лево, шаг в право... А вот виджеты в Tcl/Tk это нечто вроде xhtml+css+dom+JavaScript.


IT>Тут было безапелляционно заявлено, что C# отдыхает, рулит в гуях сегодня tcl. Вот это не соответствующее истине заявление я и попытался развеять.


У тебя не получилось.

ANS>>Ты лучше покажи код, который в виджете для редактирования текста при наведении мышки на слово выведет некую подсказку.


IT>Так это всё тоже в дизайнере задаётся или как в данном примере автоматически библиотечным/один-раз-написанным кодом.


Вот хочу я прикрутить спел-чекер. Движок есть. Что я должен задать в дизайнере, чтобы RichTextBox начал с ним работать? А в Tk уже всё (я вверху выделил) написано. Вот и вся разница.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.