Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 00:08

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 58 ]  На страницу Пред.  1, 2, 3, 4  След.

Нужны ли Форту нововведения?
Да 94%  94%  [ 17 ]
Нет 6%  6%  [ 1 ]
Всего голосов : 18
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 01, 2006 22:07 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Функционалы можно добавить. Отображение, свертка. Все это при реализации на Форте требует постоянных манипуляций с адресами на стеке, и при реализации в ассемблере существенно ускорит дело.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Сб июл 01, 2006 23:35 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
Kamikaze писал(а):
Вторая задача, тоже затронутая на форуме,- об изменениях устаревших положений форт-системы. Здесь тоже просьба - список!

Я бы вариант ColorLessColorForth предложил как основу семейства похожих диалектов.
Это покрывает (с точностью до синтаксиса и набора встроенных примитивов) - и MachineForth и colorForth.

Основные отличия от стандарта я уже перевел. Примеры использования тоже сделаю.

Что это дает?
Программа на Форте даже вручную легко переводится в ассемблер.

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

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс июл 02, 2006 10:13 
Не в сети

Зарегистрирован: Чт май 04, 2006 18:18
Сообщения: 456
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
cleg писал(а):
да, хорошую реализацию списков и лямбды в форте было бы неплохо иметь "из коробки" :-)


http://spf.cvs.sourceforge.net/spf/deve ... b/lambda.f

_________________
http://forth.org.ru/~ygrek


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн июл 03, 2006 00:03 
Я бы не сказал, что форту сильно нужны заимствования из других языков!
По-моему скорее речь должна идти о модификации ядра форт-системы, например, создание более удобного интерфейса для работы со словарями, то есть поддрержка динамических словарей, файловых систем и прочего - то есть модификации словарей форта в своеобразную VFS - COM похожую структуру, при этом желательно без сильного утяжеления кода. Так же, векторизации всех интерфейсных слов, а так же методов работы со словарями, улучшения доступа к полям словарной статьи.
Кроме того я действительно считаю, что стоит разбить набор слов не совсем согласно 94 стандарта, а как то более логично, то есть хотя бы на три уровня: VFM, минимальный интерпретатор на ее основе, набор библиотек для поддержания того же ansi94 стандарта или 83 :) И избавиться от слов типа ?DUP ?DROP :) А то частенько встречается код BEGIN ?DUP WHILE ... REPEAT вместо BEGIN DUP WHILE ... REPEAT DROP особенно мне нравится ?DUP внутри разнообразных тестов на быстродействие.

То есть о повышении гибкости форта - все остальное решается в рамках уже существующих систем.


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 04, 2006 12:13 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
1. О компилирующей стороне Форта. Недостатком подавляющего большинства Форт-систем является неспособность автоматически сохранять исполняемый файл (например *.exe в Windows) минимального объема(без ненужных словарей), ориентированного на исполнение только главного слова.
2. Идея многопроходности при компиляции напрочь исключена из Форта, что приводит к низкому быстродействию
программ написанных на Форте(мы сравниваем быстродействие Форт-программ с программами на С, а нужно сравнивать с программами написанными на Ассемблере).
3. Форт (процедурный язык) не заточен на формирование процедур, зависящих от контекста их использования в программе.
4. Документация на Форт может быть выполнена на порядок лучше чем документация по другим системам программирования всвязи со сквозной концепцией виртуальной машины, но дальше стековой нотации дело как правило не идет.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 04, 2006 12:54 
Не в сети

Зарегистрирован: Сб май 06, 2006 12:01
Сообщения: 959
Откуда: Украина, Харьков
Благодарил (а): 2 раз.
Поблагодарили: 7 раз.
chess писал(а):
1. О компилирующей стороне Форта. Недостатком подавляющего большинства Форт-систем является неспособность автоматически сохранять исполняемый файл (например *.exe в Windows) минимального объема(без ненужных словарей), ориентированного на исполнение только главного слова.

Автоматически и не нужно. Обычно Форт-системы используются с идеей дальнейшего расширения и задача минимальности не актуальна. Более того, даже система "во всей красе" обычно меньше, чем специальная прога, но сделанная обычным С-компилятором.

chess писал(а):
2. Идея многопроходности при компиляции напрочь исключена из Форта, что приводит к низкому быстродействию
программ написанных на Форте(мы сравниваем быстродействие Форт-программ с программами на С, а нужно сравнивать с программами написанными на Ассемблере).

Оптимизация в Форте делается на более раннем этапе. Сначала часть решений принимается при проектировании, потом часть решений принимается на этапе компиляции (тут Форт может провести часть вычислений, например, построить таблицы), эти 2 этапа и обеспечивают основную часть оптимизации. Чтобы уменьшить размер проги и увеличить быстродействие - лучше всего сменить алгоритм! Это даст наибольший эффект! И Форт-системы обычно рассчитаны на интерактивную работу. Можно не тратить время на оптимизацию того, что тут же будем переделывать. А для многопроходности можно использовать целевые компиляторы, только я их мало видел и сам обычно не пользовался. Мне они обычно не нужны.

chess писал(а):
3. Форт (процедурный язык) не заточен на формирование процедур, зависящих от контекста их использования в программе.

Контексты процедур определяются параметрами. Использование побочных эффектов - не очень хорошо, затрудняется работа с исходниками! Но иногда это единственный приемлемый вариант... ;)

chess писал(а):
4. Документация на Форт может быть выполнена на порядок лучше чем документация по другим системам программирования всвязи со сквозной концепцией виртуальной машины, но дальше стековой нотации дело как правило не идет.

А можно более конкретные примеры, как это должно быть?

_________________
With best wishes, in4.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 04, 2006 13:33 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
in4 писал(а):
Обычно Форт-системы используются с идеей дальнейшего расширения и задача минимальности не актуальна.

Речь идет о законченных программах для пользователей(которым все равно на чем написаны эти программы)
in4 писал(а):
Более того, даже система "во всей красе" обычно меньше, чем специальная прога, но сделанная обычным С-компилятором.

При подключении оптимизатора по объему это вряд-ли.
Оптимизация на уровне алгоритма это само собой а также и процесс отладки. Речь идет об оптимальности
реализации машинного кода(оптимальные коды команд условных ветвлений и т.д.).
in4 писал(а):
А для многопроходности можно использовать целевые компиляторы, только я их мало видел и сам обычно не пользовался.

Значит я и говорю о необходимости целевой компиляции(для форта на PC например целевым процессором будет P4).
in4 писал(а):
Контексты процедур определяются параметрами.

Процедуры бывают и без параметров.
in4 писал(а):
Но иногда это единственный приемлемый вариант...

Эта фраза как раз и подчеркивает трудности при использовании Форта иногда.

Про документацию: Всегда легче излагать внутренне связанный материал(связь через концепцию виртуальной машины) чем набор ортогональных понятий. А насчет примеров-их то как раз и мало.
Есть конечно книга Баранова и Ноздрунова и ее можно взять за основу для выпуска документации по тому-же СПФ или ColorForth.
_______________________
С уважением chess

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт авг 04, 2006 22:16 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
chess писал(а):
2. Идея многопроходности при компиляции напрочь исключена из Форта, что приводит к низкому быстродействию
программ написанных на Форте(мы сравниваем быстродействие Форт-программ с программами на С, а нужно сравнивать с программами написанными на Ассемблере).

Очень старнные утверждения 8(
Сравнивать форт с си не корректно уже по той причине, что форт- язык высокого уровня, а си - это как бы прослойка между ассемблером и яп высокого уровня и для него придумали понятия языка среднего уровня - то есть и от низкого уровня ушли но до высокго не доросли. А уж если сравнивать - то с бейсиком!!!
Тоже интепретатор в определенной мере. Тже яп высокого уровня.
Ну и кто более тормозной???
А многопроходность форту нужна как козе баян. Меня скорее отпугнет форт система, про которую будет написано, что компиляция в ней многопроходная...

chess писал(а):
3. Форт (процедурный язык) не заточен на формирование процедур, зависящих от контекста их использования в программе.

Посмотри в тот же СПФ 8) Там слово такое есть NOTFOUND. Опровержение твоего высказывания. Кроме того мне недавно дали ссылки на библиотеку в SPF4.017 devel\~ac\lib\ns\*.f - тоже опровержение твоего высказывания. И еще есть работы Ганасаенко в ту же сторону. И вроде T32 тоже в ту сторону развивался.

chess писал(а):
4. Документация на Форт может быть выполнена на порядок лучше чем документация по другим системам программирования всвязи со сквозной концепцией виртуальной машины, но дальше стековой нотации дело как правило не идет.

Большинство слов форта работают только со стеком.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 12:14 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
oleg писал(а):
Очень старнные утверждения 8(
Сравнивать форт с си не корректно уже по той причине, что форт- язык высокого уровня, а си - это как бы прослойка между ассемблером и яп высокого уровня и для него придумали понятия языка среднего уровня - то есть и от низкого уровня ушли но до высокго не доросли. А уж если сравнивать - то с бейсиком!!!
Тоже интепретатор в определенной мере. Тже яп высокого уровня.
Ну и кто более тормозной???

Я сравниваю по быстродействию конечный результат работы Форт-системы (исполняемый файл) с аналогичным результатом работы других трансляторов и подчеркиваю, что из-за отсутствия многопроходности в процессе компиляции именно для Форта происходит замедление работы этого исполняемого файла по сравнению с исполняемыми файлами других трансляторов, у которых многопроходная компиляция есть. Речь идет о том, что принципиально невозможно сделать исполняемый код близким к максимально быстрому за один проход компиляции.
oleg писал(а):
А многопроходность форту нужна как козе баян. Меня скорее отпугнет форт система, про которую будет написано, что компиляция в ней многопроходная...

Компилятор в части оптимизации исполняемого кода должен работать независимо от программиста и быть ориетированным на конкретную платформу(программист может и не знать ее особенности).
oleg писал(а):
Посмотри в тот же СПФ Там слово такое есть NOTFOUND. Опровержение твоего высказывания. Кроме того мне недавно дали ссылки на библиотеку в SPF4.017 devel\~ac\lib\ns\*.f - тоже опровержение твоего высказывания. И еще есть работы Ганасаенко в ту же сторону. И вроде T32 тоже в ту сторону развивался.

Это все идет через словари. Чтобы было понятно о какой зависимости от контекста идет речь приведу пример:
При интерпретации одно и то же слово может компилироваться или исполняться в зависимости от состояния переменной STAT. Состояние переменной STAT - это контекст.
При программировании аппаратуры, которая работает в реальном времени контекстом например будет состояние аппаратуры. Действие взависимости от состояния аппаратуры будет разным.

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 13:10 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
chess писал(а):
Речь идет о том, что принципиально невозможно сделать исполняемый код близким к максимально быстрому за один проход компиляции.


Это почему? Можно пример? (небольшой).

Цитата:
Компилятор в части оптимизации исполняемого кода должен работать независимо от программиста и быть ориетированным на конкретную платформу(программист может и не знать ее особенности).


В СПФ так и есть. В крайнем случае, оптимизацию можно отключить.

Цитата:
приведу пример:
При интерпретации одно и то же слово может компилироваться или исполняться в зависимости от состояния переменной STAT. Состояние переменной STAT - это контекст.
При программировании аппаратуры, которая работает в реальном времени контекстом например будет состояние аппаратуры. Действие взависимости от состояния аппаратуры будет разным.


Невъезжаю в проблему. Можно пример по конкретнее?
Вообще, для Форта слова нельзя нет.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 13:26 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
Mihail писал(а):
Вообще, для Форта слова нельзя нет.

Дык, можно же его определить! :)) Через двоеточние, например

: нельзя возможно все ;

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 14:41 
Не в сети
Аватара пользователя

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Mihail писал(а):
chess писал(а):
Речь идет о том, что принципиально невозможно сделать исполняемый код близким к максимально быстрому за один проход компиляции.



Это почему? Можно пример? (небольшой).


Пример на знакомой вам платформе MCS51
Конструкция IF .... THEN
возможные варианты реализации ветвления if then в зависимости от величины кода между if и then и места этого куска в ROM
1. fif ?a!=0(.) lj(then) .|-----then
2. fif ?a!=0(.) aj(then).|-----then
3. fif ?a=0(then)|------------then
где fif - подпрограмма - заносит в аккумулятор False или True если на стеке 0 или не 0
?a!=0, ?a=0, lj, aj соответственно команды jnz, jz, ljmp, ajmp,
а теперь покажите как за один проход скомпилировать минимальный по объему и максимальный по быстродействию код и еще учтите, что эта конструкция будет вложена в несколько таких же конструкций

_________________
С уважением, chess


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 15:15 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
chess писал(а):
Конструкция IF .... THEN
возможные варианты реализации ветвления if then в зависимости от величины кода между if и


В x86 тоже зависимость от дальности перехода.
С помощью команды SEE можно посмотреть результат
работы оптимизатора в СПФ.

Код:

>: xx dup 0= if then ;
Ok
>see xx

58B740 0BC0      OR      EAX , EAX
58B742 7500      JNE     58B744
58B744 C3      RET     NEAR
END-CODE   Ok
>: yy dup 0= if ." zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz" then ;
Ok
>see yy

58B770 0BC0      OR      EAX , EAX
58B772 0F853D000000   JNE     58B7B5  ( yy+45  )
58B778 E8376AFBFF   CALL    5421B4  ( _CLITERAL-CODE )
58B77D   31 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A 1zzzzzzzzzzzzzzz
58B78D   7A 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A zzzzzzzzzzzzzzzz
58B79D   7A 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A  7A 7A 7A 7A zzzzzzzzzzzzzzzz
58B7AD   7A 7A 00 E8  3B AC FB FF  C3 55 55 00  00 00 00 00 zz.ø;ìv +UU.....
58B7B0 E83BACFBFF   CALL    5463F0  ( (.") )
58B7B5 C3      RET     NEAR
END-CODE   Ok
>


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 15:27 
chess писал(а):
oleg писал(а):
Очень старнные утверждения 8(
Сравнивать форт с си не корректно уже по той причине, что форт- язык высокого уровня, а си - это как бы прослойка между ассемблером и яп высокого уровня и для него придумали понятия языка среднего уровня - то есть и от низкого уровня ушли но до высокго не доросли. А уж если сравнивать - то с бейсиком!!!
Тоже интепретатор в определенной мере. Тже яп высокого уровня.
Ну и кто более тормозной???

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

А оно надо это "максимальное быстродействие" которое в частности к IBM-совместимым выглядит как "максимальное быстродействие для P4 при максимальных тормозах для Р1" :shuffle; ? Кроме того, в SPF по умолчанию с учетом оптимизатора как минимум двухпроходная компиляция.
Кроме того, как назвать компиляцию компилирующих слов? Ведь при компиляции того-же банального IF происходит возврат и докомпиляция уже откомпилированного кода. Не говоря уже про всевозможные циклы которые без "компиляции назад" вообще не выполнимы.
Ну и последнее - а как Вы представляете сравнивание "аналогичных результатов"? Ведь разные языки это не просто разные компиляторы. Они невольно НАВЯЗЫВАЮТ программисту стиль программирования.
Я с этим столкнулся при сравнении результатов программирования на Си и Асме под АВР. Писал мой коллега (владеет свободно обеими языками, но ему показалось, что на Си будет "понятнее"). После завершения проекта оказалось, что даже при максимальной оптимизации по объему Си-код раза в полтора больше "аналогичных" Асм-программ. Причем после просмотра полученного кода притензий к качеству компилируемого кода к компилятору НЕБЫЛО - в каждом отдельно взятом кусочке код был практически идеальным. Вот только результат получился значительно больше :? . Вывод был таков - программа на Асме практически НИКОГДА-бы так не писалась как программа на Си - это было-бы раза в два больше текста (жаба просто задавила так работать с памятью, как это предоставляет Си) и наоборот - по той-же причине на Си жаба не дает писать такие-же проги как на Асме.
Цитата:
oleg писал(а):
А многопроходность форту нужна как козе баян. Меня скорее отпугнет форт система, про которую будет написано, что компиляция в ней многопроходная...

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

Вот здесь и кроется главный недостаток такой "оптимизации" - программист зная особенности платформы может увеличить быстродействие более чем на порядок чего НИКОГДА не сделает компилятор. В этом смысле в тему анекдот "С какой скоростью должна писать свои продукты Microsoft, что-бы увеличение быстродействия ПК было незаметно? :D "

Цитата:
oleg писал(а):
Посмотри в тот же СПФ Там слово такое есть NOTFOUND. Опровержение твоего высказывания. Кроме того мне недавно дали ссылки на библиотеку в SPF4.017 devel\~ac\lib\ns\*.f - тоже опровержение твоего высказывания. И еще есть работы Ганасаенко в ту же сторону. И вроде T32 тоже в ту сторону развивался.

Это все идет через словари.

А чем разделение контекста словарями не нравится? В зависимости от места в программе "одинаковые" процедуры по-разному себя ведут.
Цитата:
Чтобы было понятно о какой зависимости от контекста идет речь приведу пример:
При интерпретации одно и то же слово может компилироваться или исполняться в зависимости от состояния переменной .

Не уточните, о КАКОМ языке речь. Насколько я помню, в Си "при интерпритации" тобишь в рантайме работа со STAT ложиться ПОЛНОСТЬЮ на плечи программиста.
Цитата:
Состояние переменной STAT - это контекст.
При программировании аппаратуры, которая работает в реальном времени контекстом например будет состояние аппаратуры. Действие взависимости от состояния аппаратуры будет разным.

Насколько я помню в Си это решается большим SWITCH-СASE-ом. Или для более продвинутых программистов набором IF-ов. Назовите другие способы и Вам будут предоставлены их "аналоги" в Форте. 8)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн авг 07, 2006 16:16 
chess писал(а):
Пример на знакомой вам платформе MCS51
Конструкция IF .... THEN
возможные варианты реализации ветвления if then в зависимости от величины кода между if и then и места этого куска в ROM
1. fif ?a!=0(.) lj(then) .|-----then
2. fif ?a!=0(.) aj(then).|-----then
3. fif ?a=0(then)|------------then
где fif - подпрограмма - заносит в аккумулятор False или True если на стеке 0 или не 0
?a!=0, ?a=0, lj, aj соответственно команды jnz, jz, ljmp, ajmp,
а теперь покажите как за один проход скомпилировать минимальный по объему и максимальный по быстродействию код и еще учтите, что эта конструкция будет вложена в несколько таких же конструкций
В связи с тем, что х51 это "наследство тяжелого прошлого 80-й серии", то для этой задачи придется поступать методами тех времен - вести таблицу переноса - таблицу JMP-ов в которых при сдвиге кода надо менять метки.
В общем работа муторная и неблагодарная - результат никто не заметит :oops: ...


Вернуться к началу
  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 58 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB