_Loader_

What do you think about sharp blades, Alex?

Remember, pain is part of pleasure, Alex. ... ÷ÅÄØ ÐÏÌ-ÃÁÒÓÔ×Á ÎÅ ÄÅÌÉÔÓÑ ÎÁÄ×ÏÅ - ÞÅÔ×ÅÒÔØ ÕÖÅ ÎÅ Ú×ÕÞÉÔ...

What do you think about sharp blades, Yurij?

DO>> ôÁÍ, ÇÄÅ ÔÙ ×ÙÂpÏÓÉÛØ 'IF'. YS> ÷ ÓËpÉÐÔÏ×ÏÍ ÑÚÙËÅ Ó ó-ÐÏÄÏÂÎÙÍ ÓÉÎÔÁËÓÉÓÏÍ, ËÏÔÏpÙÊ Ñ ÎÅËÏÇÄÁ ÎÁ×ÁÑÌ, YS> ÏÐÅpÁÔÏpÏ× ÔÉÐÁ 'if' ÉÌÉ 'while' ÎÅ ÂÙÌÏ - ÂÙÌÉ ×ÓÔpÏÅÎÎÙÅ ÆÕÎËÃÉÉ YS> if(), while(), etc... Ó ÜÆÆÅËÔÏÍ, ÁÎÁÌÏÇÉÞÎÙÍ eval(). ðpÏÓÔÏ pÅÁÌØÎÏ üÔÏ ÎÉÞÅÇÏ ÎÅ ÍÅÎÑÅÔ -- ÓÅÍÁÎÔÉÞÅÓËÉ-ÔÏ ÏÎÉ ÂÙÌÉ. á × ×ÉÄÅ ÏÐÅÒÁÔÏÒÏ× ÉÌÉ ÆÕÎËÃÉÊ -- ÎÅ ×ÁÖÎÏ. íÏÊ ÌÀÂÉÍÙÊ ÐÒÉÍÅÒ ÎÁ ÜÔÕ ÔÅÍÕ -- ××ÅÄÅÎÉÅ ×ÅÔ×ÌÅÎÉÑ É ÁÒÉÆÍÅÔÉËÉ Ó ÐÏÍÏÝØÀ ÒÁÓÛÉÒÅÎÎÏÇÏ lambda-ÉÓÞÉÓÌÅÎÉÑ.

Remember, pain is part of pleasure, Yurij. ... æÉÇÁ ÌÅÖÉÔ × ËÁÒÍÁÎÅ ÐÏÓÌÅÄÎÉÍ ÏÒÕÖÉÅÍ ÄÕÒÁËÏ×...

Hello Lev.

LS> ëÓÔÁÔÉ, Language != Programming Language. LS> HTML == HyperText MARKUP LANGUAGE LS> PCL == Printer COMMON LANGUAGE

PCL == Printer Control Language (ñÚÙË ÕÐÒÁ×ÌÅÎÉÑ ÐÒÉÎÔÅÒÏÍ)

LS> ðÒÏ programming ÔÕÔ ÎÉ ÓÌÏ×Á...

Alexey

Hello, Lev!

YS> ÷ ÓËpÉÐÔÏ×ÏÍ ÑÚÙËÅ Ó ó-ÐÏÄÏÂÎÙÍ ÓÉÎÔÁËÓÉÓÏÍ, ËÏÔÏpÙÊ Ñ ÎÅËÏÇÄÁ YS> ÎÁ×ÁÑÌ, ÏÐÅpÁÔÏpÏ× ÔÉÐÁ 'if' ÉÌÉ 'while' ÎÅ ÂÙÌÏ - ÂÙÌÉ ×ÓÔpÏÅÎÎÙÅ YS> ÆÕÎËÃÉÉ if(), while(), etc... Ó ÜÆÆÅËÔÏÍ, ÁÎÁÌÏÇÉÞÎÙÍ eval().

LS> üÔÏ ÎÉÞÅÇÏ ÎÅ ÍÅÎÑÅÔ -- ÓÅÍÁÎÔÉÞÅÓËÉ-ÔÏ ÏÎÉ ÂÙÌÉ. á × ×ÉÄÅ ÏÐÅpÁÔÏpÏ× LS> ÉÌÉ ÆÕÎËÃÉÊ -- ÎÅ ×ÁÖÎÏ. íÏÊ ÌÀÂÉÍÙÊ ÐpÉÍÅp ÎÁ ÜÔÕ ÔÅÍÕ -- ××ÅÄÅÎÉÅ LS> ×ÅÔ×ÌÅÎÉÑ É ÁpÉÆÍÅÔÉËÉ Ó ÐÏÍÏÝØÀ pÁÓÛÉpÅÎÎÏÇÏ lambda-ÉÓÞÉÓÌÅÎÉÑ.

Best regards, // "÷ ÌÅÔÏ 6750 ÎÅ ÂÙÓÔØ ÎÉÞÔÏÖÅ" Yurij. // (Ó) éÐÁÔØÅ×ÓËÁÑ ÌÅÔÏÐÉÓØ

Hi Lev,

Tue Oct 21 2003 10:54, Lev Serebryakov wrote to Alex Kouznetsov:

LS> Добавлю -- там где ты выбросишь IF в любой его форме.

Мне кажется, ты будешь смеяться... Анекдот состоит в том, что в PDF есть операторы if и ifelse ;-)) Смотри таблицу 3.38 адобевского документа PDF Reference fourth edition

Пока, Алексей

Hello, Dima!

DO>> ÷ ÓËpÉÐÔÏ×ÏÍ ÑÚÙËÅ Ó ó-ÐÏÄÏÂÎÙÍ ÓÉÎÔÁËÓÉÓÏÍ, ËÏÔÏpÙÊ Ñ ÎÅËÏÇÄÁ ÎÁ×ÁÑÌ, DO>> ÏÐÅpÁÔÏpÏ× ÔÉÐÁ 'if' ÉÌÉ 'while' ÎÅ ÂÙÌÏ - ÂÙÌÉ ×ÓÔpÏÅÎÎÙÅ ÆÕÎËÃÉÉ DO>> if(), while(), etc... Ó ÜÆÆÅËÔÏÍ, ÁÎÁÌÏÇÉÞÎÙÍ eval(). ðpÏÓÔÏ pÅÁÌØÎÏ

DO> ÷ÏÔ ÅÓÌÉ ÉÈ ×ÙÂpÏÓÉÔØ, ÔÙ É ÐÏÌÕÞÉÛØ ÎÅ ÐpÏÇpÁÍÍÕ, Á ÎÁÂÏp ÄÁÎÎÙÈ.

Best regards, // óÏ×ÅÓÔØ - ÎÅÏÔßÅÍÌÅÍÙÊ ËÏÍÐÏÎÅÎÔ Yurij. // ÚÎÁÎÉÊ É ÏÐÙÔÁ.

Hello, Alex Mogilnikov !

HÕ ÎÅÕÄÏÂÎÏ ÕËÁÚÙ×ÁÔØ ÉÍÑ ÆÁÊÌÁ × ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÅ. éÎÔÅÒÆÅÊÓ Ó ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÏÊ ÕÄÏÂÅÎ ÄÌÑ ÉÎÔÅÇÒÉÒÏ×ÁÎÉÑ ÕÔÉÌÉÔÙ × ËÁËÕÀ-ÔÏ ÏÂÏÌÏÞËÕ, ÓÏÂÓÔ×ÅÎÎÏ ÉÎÔÅÒÆÅÊÓ É ÒÅÁÌÉÚÕÀÝÕÀ. HÏ É ÜÔÁ ÒÁÂÏÔÁ ÞÁÓÔÏ ÎÅ ÐÏÄ ÓÉÌÕ ÔÏÍÕ, ËÏÍÕ ÎÁÄÏ ÜÔÉÍ ÉÎÓÔÒÕÍÅÎÔÏÍ ÐÏÌØÚÏ×ÁÔØÓÑ.

HÅ ×ÅÓØ.

Hello, Vladislav Baliasov !

Tuesday October 21 2003 10:06, Lev Serebryakov wrote to Alexey Boyko:

LS>>> ôÏ, ÞÔÏ ÔÁÍ ÎÅÔ ÁÌÇÏÒÉÔÍÁ -- ÞÅÔËÉÈ ÏÄÎÏÚÎÁÞÎÙÈ ÉÎÓÔÒÕËÃÉÊ. LS>>> ïÄÉÎ É ÔÏÔ ÖÅ PDF ÂÕÄÅÔ ÐÏ-ÒÁÚÎÏÍÕ ×ÙÐÏÌÎÓÑÔÓÑ ÎÁ Acrobat'Å, LS>>> AcrobatReader'Å AB>> HÅÔ. LS>>> É GhosScript'Å. AB>> åÓÌÉ ÐÏÄÓÕÎÕÔØ ÅÍÕ ÛÒÉÆÔÙ ÏÔ Acrobat'Á, ÔÏ ÂÕÄÅÔ ×ÙÇÌÑÄÅÔØ ÔÁËÖÅ. LS>

LS> äÁ ÎÕ!? é Notes'Ù ÂÕÄÕÔ ÐÏËÁÚÁÎÙ, É Mark'É, É ÐÏÌÑ ÆÏÒÍ?! HÅ ÓÍÅÛÉ ÍÅÎÑ.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

Tue Oct 21 2003 09:38, Roman Khvatov wrote to Ilia Tarasov:

RK>>> Опять же, это ассемблер. IT>> ЯВУ или промежуточный код?

RK> Промежуточный код.

(*)

IT>> И gcc, на который тут так активно показывали, уже не сможет IT>> сгенерировать код для стековой машины?

RK> Может, как и для любого другого ассемблера :)

Итого, с учетом (*), получается, что на входе есть некое лексическое представление алгоритма, а как получится машинный код - дело десятое... И применение стековой машины с частью Форта в качестве ассемблера отнюдь не отменяет возможность дальнейшего использования "поверх" этих инструментов любого из современных ЯВУ.

RK>>> Только для неоптимизирующего компилятора, для оптимизируещего RK>>> придется писать оптимизирующий кодогенератор с этого 'ассемблера' IT>> См. TIGRE, например.

RK> Это система преобразования графов, оптимизировать код под конкретные RK> особенности конкретного стекового процессора она не сможет, она сможет RK> сделать некоторые алгоритмические оптимизации для обобщенного стекового RK> процессора.

Угу. В итоге на базе этого обобщенного представления окажется возможным сгенерировать систему команд для конкретной реализации стекового процессора. Иначе говоря, ввести аппаратную поддержку для _конкретного_ решения. Для регистровой модели я пока не вижу столь же эффективного и оперативного подхода. Правда, про MicroBlaze пишут, что методики построения компиляторов для его архитектуры "хорошо известны", но _систему_ (имея в виду System-On-Chip) на основе MicroBlaze я бы не стал делать вот так сразу...

IT>> Fixed. А теперь объясни этому же человеку, почему он должен писать IT>> _только_ на ассемблере с довольно низкой производительностью своего IT>> труда? Hикаких промежуточных инструментов уже не допускается?

RK> Эти промежуточные инструменты не должны раздувать полученный код. То есть RK> допускается только ассемблер в разных его вариантах - для стековой машины RK> это может быть Форт, для не стековой - не может.

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

IT>> Вот я применяю тулз, основанный на парсере, встроенном в IT>> Форт-транслятор, который генерирует коды для конечного автомата.

RK> Это хорошо, только тогда это уже не Форт, а именно 'тулз, основанный на RK> парсере, встроенном в Форт-транслятор'.

Ну и как прикажешь тогда его назвать? :) У меня фантазия на названия исчерпалась.... да и длинновато как-то.

IT>> Я все равно тебя не понимаю. Почему для использования разработки нужны IT>> миллионы ее пользователей вокруг?

RK> А кто ее будет использовать, если она никому не известна? С другой RK> стороны, если ею никто не пользуется, то и развиваться она не будет, так RK> мы и имеем Форт, практически не изменившийся за 30 лет с момента RK> возникновения.

А там нечему особо изменяться. Разве что клоны, диалекты, тот же Joy на основе стековой машины. Вот еще ассемблер стековой машины можно притянуть за уши как направление разработки. Но это не развитие исходной идеи, это реализации и функциональность надстроек...

IT>> говорю о рекламе, я не хочу, чтобы люди выбирали себе смоляное IT>> чучелко для битья... а то распространен Форт мало, но ругать его IT>> сбегаются целые толпы... :))))

RK> Так ругают за дело - у Форта есть _огромный_ недостаток в виде совершенно RK> нечитаемого синтаксиса (только не надо криков 'кому как, я отлично его RK> читаю' - можно и медведя научить ездить на велосипеде, но это не значит, RK> что медведи в лесу должны устраивать велогонки) и отсуствие каких либо RK> _реальных_ преимуществ по сравнению с _современными_ системами RK> програмирования (30 лет назад эти преимущества были, но прогресс не стоит RK> на месте, а Форт - стоит, и сегодня этих преимуществ _уже нет_)

Ты думаешь, мне он _нравится_? :) Я к нему _привык_, и научился быстро переходить к гораздо более читаемому представлению программ, которые пишу. Вот поговорить о практических методах синтаксических преобразований - дело. А преимущества действительно играли роль, пока памяти было мало и развернуться с оптимизирующими компиляторами было особо негде. Сейчас для PC есть более эффективные средства в качестве mainstream. И Форт язык далеко не первоочередной для изучения, хотя если программист собирается писать компиляторы (вообще), то написать транслятор Форта было бы ОЧЕНЬ полезно.

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

RK> Паяльник массово применяется в исследовательских лабораториях, причем RK> тоже в промышленных масштабах (_промышленные масштабы_ != _на заводе_)

Ну я написал "производства в промышленных масштабах"... т.е. имея в виду серийный выпуск изделий на одном предприятии. Что до исследовательских лабораторий, то я знаю подобные места, где именно Форт и используют, адаптировав его под свои потребности. Чтобы со вкусом развернуться в программировании на чем-то "красивом, правильном и современном", частенько времени не хватает, да и не оценят красоту текста, написанного для _лабораторной_ установки.

IT>> Именно что грамматика не изменится. После препроцессора полученный IT>> текст (в котором опять begin end) можно будет пропустить через IT>> компилятор Паскаля...

RK> Угу, только исходный текст уже не будет являтся программой на Паскале.

Исходный - не будет. После препроцессора - будет.

IT>> Какие дальше будут соображения? Как поделить орехи на кучки?

RK> Еще раз напомню, что мы пытались определить: отличие между _разными_ RK> языками и _диалектом_ одного и того же языка. RK> Заметь - _существующими_ языками, а не теми, которые можно придумать :) RK> Я знаю один диалект паскаля, где были введены лексемы _( и _) как RK> _аналоги_ соотвественно begin и end, заметь, не _заменили_ begin и end, а RK> ввели синонимы.

А это еще один вариант. Но все же, как тебе подход к делению языков, в котором основной упор делается не на возможности конкретных _реализаций_ компиляторов, а на возможность обойтись только лексическими преобразованиями?

RK> То есть это не помешало компилировать обычные Паскалевские программы, но RK> позволило сократить запись для разрабатываемых на этом диалекте программ. RK> То есть на лицо явный _диалект_. Если бы _( и _) были введены _вместо_ RK> begin и end, то _все_ Паскалевские программы перестали бы RK> компилироваться, то есть налицо новый язык (нафиг никому не нужный :)

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

RK> Правильно, для определения разницы между диалектами языка и разными RK> языками компиляторы и _должны_ рассматриваться как черный ящик. Причем RK> нас совершенно не интересует, что они генерируют на выходе, нас RK> интересует только смог ли данный компилятор (рассматриваемый как черный RK> ящик) откомпилировать исходный текст программы или не смог. Под смог/не RK> смог понимается получили мы в результате выходные данные от компилятора RK> (независимо от того, что это за данные - код, промежуточное RK> представление, текст на другом языке, и т.д. - это зависит только от RK> самого компилятора и входит в определение черного ящика как RK> успешная/неуспешная компиляция) или нет.

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

RK> Здесь я под граматикой исходной программы имел в виду совокупность ее RK> лексики, грамматики и семантики, то есть все вместе.

Точнее, лексики, синтаксиса и семантики. Грамматика - более объемлющее понятие.

IT>> Отсюда и можно выделить группу языков со схожим семантическим IT>> наполнением языковых конструкций.

RK> Схожим, но не одинаковым!

Ммм... в пределах понимаемости человеком?

IT>> Hаучился писать на одном - очень легко перейти к другому IT>> (Си -> Паскаль).

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

Компилировать - уровень _реализации_ инструментов. Писать - уровень разработки программы человеком. Здесь всегда можно пустить другой .exe, это-то как раз не проблема. Проблема с ходу перейти от Си к Прологу, например...

RK> Это компилятор, для компилятора неважен формат выходного результата, RK> важно, что он есть.

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

RK> (При определении разницы между _диалектами_ и _разными_ языками под RK> компиляторами можно понимать программу, читающую входной тест написанный RK> на этом языке вне зависимости от подробностей внутреннего устройства этой RK> программы, то есть фактически это может быть и классический компилятор, RK> препроцессор и даже интерпретатор)

С учетом предыдущей твоей фразы требуется очень существенное уточнение терминологии. Не проще ли компилятором называть "классический компилятор"?

IT>> VHDL - это _совершенно_ не код,

RK> Какая разница - это продукт деятельности первого компилятора.

"Неклассического"...

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

RK> Для данной дискусси - да.

Только с учетом твоих поправок к терминологии, которые только сейчас начали проясняться...

What do you think about sharp blades, Alexey?

LS>> ëÓÔÁÔÉ, Language != Programming Language. LS>> HTML == HyperText MARKUP LANGUAGE LS>> PCL == Printer COMMON LANGUAGE AB> PCL == Printer Control Language (ñÚÙË ÕÐÒÁ×ÌÅÎÉÑ ÐÒÉÎÔÅÒÏÍ) HÕ ÄÁ, ÏÛÉÂÓÑ. HÏ ÜÔÏ ÎÅ ÍÅÎÑÅÔ ÎÉÞÅÇÏ.

Remember, pain is part of pleasure, Alexey. ... ðÏÇÒÕÖÕ × ÔÒÀÍÙ Ñ ÓÔÁÌØÎÙÅ ÓÌÏ×Á/äÁ ÄÕÄÏÞËÕ ÕÇÒÀÍÕÀ - 7.62...

What do you think about sharp blades, Alexander?

LS>>>> ôÏ, ÞÔÏ ÔÁÍ ÎÅÔ ÁÌÇÏÒÉÔÍÁ -- ÞÅÔËÉÈ ÏÄÎÏÚÎÁÞÎÙÈ ÉÎÓÔÒÕËÃÉÊ. LS>>>> ïÄÉÎ É ÔÏÔ ÖÅ PDF ÂÕÄÅÔ ÐÏ-ÒÁÚÎÏÍÕ ×ÙÐÏÌÎÓÑÔÓÑ ÎÁ Acrobat'Å, LS>>>> AcrobatReader'Å AB>>> HÅÔ. LS>>>> É GhosScript'Å. AB>>> åÓÌÉ ÐÏÄÓÕÎÕÔØ ÅÍÕ ÛÒÉÆÔÙ ÏÔ Acrobat'Á, ÔÏ ÂÕÄÅÔ ×ÙÇÌÑÄÅÔØ AB>>> ÔÁËÖÅ. LS>>

LS>> äÁ ÎÕ!? é Notes'Ù ÂÕÄÕÔ ÐÏËÁÚÁÎÙ, É Mark'É, É ÐÏÌÑ ÆÏÒÍ?! HÅ LS>> ÓÍÅÛÉ ÍÅÎÑ. AT> á "ÎÁÈÒÅÎÁ ÏÎ ÔÏÇÄÁ ÎÕÖÅÎ, ÔÁËÏÊ "ÈÏÒÏÛÉÊ" ? ïÎ ÒÁÓÛÉÒÑÅÍÙÊ. âÁÚÁ (ÓÔÒÁÎÉÃÙ Ó ×ÅËÔÏÒÎÏÊ ÇÒÁÆÉËÏÊ É ÛÒÉÆÔÁÍÉ) ÂÕÄÕÔ ÐÏËÁÚÁÎÙ ×ÅÚÄÅ. ÷ÓÅ ÏÓÔÁÌØÎÏÅ ÄÅÌÁÅÔÓÑ ÐÌÁÇÉÎÓÁÍÉ ÎÁÂÁÚÅ /ÓÌÏ×ÁÒÅÊ/, É, × ÐÒÉÎÃÉÐÅ, ÔÙ ÍÏÖÅÛØ ÄÏÂÁ×ÌÑÔØ Ó×ÏÉ ÏÂßÅËÔÙ. åÓÔØ ÎÁÂÏÒ ÐÌÁÇÉÎÏ×, ÉÄÕÝÉÊ ÓÏ ÓÔÁÎÄÁÒÔÎÙÍ ðïìHùí ÁËÒÏÂÁÔÏÍ. ïÂßÅËÔÙ, ÓÏÚÄÁ×ÁÅÍÙÅ ÜÔÉÍÉ ÐÌÁÇÉÎÁÍÉ ÕÍÅÅÔ ÐÏËÁÚÙ×ÁÔØ É ÒÉÄÅÒ. HÏ ÎÉËÔÏ ÔÅÂÅ ÎÅ ÍÅÛÁÅÔ ÏÔÏÒ×ÁÔØ ÜÔÉ ÐÌÁÇÉÎÙ ÉÌÉ ÎÁÐÉÓÁÔØ Ó×ÏÉ. ëÁË ÔÙ ÐÏÎÉÍÁÅÛØ, ËÏÇÄÁ ÆÏÒÍÁÔ ÒÁÓÛÉÒÑÅÍÙÊ, ×ÓÅÇÄÁ ÅÓÔØ ÔÁËÁÑ ÐÒÏÂÌÅÍÁ. ðÒÏÇÒÁÍÍ, ÐÏËÁÚÙ×ÁÀÝÉÈ /×ÓÅ/ ×ÁÒÉÁÎÔÙ TIFF Ñ ÔÏÖÅ ÎÅ ÚÎÁÀ.

Remember, pain is part of pleasure, Alexander. ... ÷ Ú×ÏÎËÕÀ ÕÌÙÂËÕ - ËÁË × ÏÂÏÊÍÕ ÐÁÔÒÏÎ...

Hi Lev,

Tue Oct 21 2003 23:42, Lev Serebryakov wrote to Alexey Boyko:

LS>>> Кстати, Language != Programming Language. LS>>> HTML == HyperText MARKUP LANGUAGE AB>> PCL == Printer Control Language (Язык управления принтером)

Все же не совсем понятно. Скажем, функциональные языки - это языки программирования или нет? Классичекий пример

Quicksort in Haskell qsort [] = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x where elts_lt_x = [y | y <- xs, y < x] elts_greq_x = [y | y <- xs, y >= x]

Никаких if нет - значит, это не программа? А то же самое, написанное на С - это программа, потому что там будет использоваться if?

Или, например, в промышленности применяют язык релейно-контактных схем - это язык программирования, или просто язык? В нем, в отличие от PDF, вовсе нет никаких if. Получается, что PDF-файл - это программа (про что я и говорил с самого начала), а то, что исполняет какой-нибудь PLC, управляя станком, - не программа? С последним трудно согласиться...

Пока, Алексей

Hello, Alex Kouznetsov !

HÁ ÓËÏÌØËÏ Ñ ÐÏÍÎÀ, ËÒÁÊÎÅ ÇÏÒÂÁÔÙÊ ÑÚÙË ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ, ÈÏÔÑ ÏÎ ÐÏ ÓÕÔÉ Ó×ÏÅÊ ÇÏÒÁÚÄÏ ÂÌÉÖÅ Ë ÑÚÙËÁÍ ÏÐÉÓÁÎÉÑ ÐÒÏÇÒÁÍÍÉÒÕÅÍÏÊ ÌÏÇÉËÉ.

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Dima! You wrote to Alex Kouznetsov on Wed, 22 Oct 2003 17:24:00 +0600:

DO> HÁ ÓËÏÌØËÏ Ñ ÐÏÍÎÀ, ËÒÁÊÎÅ ÇÏÒÂÁÔÙÊ ÑÚÙË ÐÒÏÇÒÁÍÍÉÒÏ×ÁÎÉÑ, ÈÏÔÑ ÏÎ DO> ÐÏ ÓÕÔÉ Ó×ÏÅÊ ÇÏÒÁÚÄÏ ÂÌÉÖÅ Ë ÑÚÙËÁÍ ÏÐÉÓÁÎÉÑ ÐÒÏÇÒÁÍÍÉÒÕÅÍÏÊ DO> ÌÏÇÉËÉ.

With best regards, Serge.

Hello, Serge Eremenko !

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

Hello, Alex Mogilnikov !

ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.

DO> íÏÖÅÔ ÎÅ ÂÙÔØ if, ÎÏ ÅÓÌÉ ÎÅÔ ÎÉËÁËÉÈ ÓÒÅÄÓÔ× × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ×ÎÅÛÎÉÈ DO> ÄÁÎÎÙÈ ÉÚÍÅÎÉÔØ ÈÏÄ ×ÙÐÏÌÎÅÎÉÑ, ÜÔÏ ÎÅ ÐÒÏÇÒÁÍÍÁ, Á ÎÁÂÏÒ ÄÁÎÎÙÈ

With my best Wishes & Regards, Serg aka ¤€€¤_€ ·ƒƒ aka uncle_sem*mail.ru/tut.by [ëazÅÌ] [SPS] [LMD] [IMHO Sapiens] €€­ª€€ ­ … mobile: +375-296-27-47-24

24 Oct 03 07:14, Dima Orlov ÐÉÓÁÌ Alex Mogilnikov:

DO> õ ÌÀÂÏÇÏ ÐÏÄÏÂÎÏÇÏ ËÏÍÍÅÒÞÅÓËÏÇÏ ÕÓÔÒÏÊÓÔ×Á ÏÂÏÌÏÞËÁ ÂÙÔØ ÐÒÏÓÔÏ DO> ÏÂÑÚÁÎÁ, ÉÎÁÞÅ ÛÁÎÓÏ× Õ ÎÅÇÏ ÎÅ ÍÎÏÇÏ.

DO> ó ÞÅÇÏ ÔÙ ×ÚÑÌ?

avreal ÉÓÐÏÌØÚÕÅÔ ÍÎÏÇÏ ÌÀÄÅÊ, Á ÇÒÁÆÉÞÅÓËÕÀ ÏÂÏÌÏÞËÕ ÎÉËÔÏ ÎÅ ÓÄÅÌÁÌ.