Рассуждения на тему: X++ компилируемый или интерпретируемый язык?

[sukhanchik]

******* Выделено отсюда DAX40 #if.never в LedgerBondServer_RU ********

Цитата:

Сообщение от DSPIC

Да, увидел, но только после перезапуска клиента (40sp2).

Хм... А я увидел сразу.... Та же самая версия - 4.0 SP2. Безо всяких там перезапусков.

Цитата:

Сообщение от DSPIC

Цитата:

Сообщение от sukhanchik

При попытке удаления и создания метода - вызов saveLast() все равно "разрешается" в любом методе - что приводит к выводу - что этот метод в откомпилированном коде сохраняется при самом объекте (метод saveLast и только он был скопирован с родителя, но не был удален при отвязке родителя).

Это скорее догадка, чем вывод.

Да, скорее догадка, но факт остается фактом.

Цитата:

Сообщение от DSPIC

Проверить не получилось, в UtilElements методы базового класса не добавляются. Возможно они привязываются в откомпилированном коде, но при этом компилятор X++ уверенно прыгает в исходник базового класса (Lookup definition). Но и это можно объяснить...

Не... исходный код никто и не трогает. Я просто провожу параллель со сборкой exe-шника. При сборке из командной строки - в exe-шник копируются куча библиотек, причем можно задать - копировать их, либо использовать только ссылки (в последнем случае exe-шник не запустится без наличия библиотек).
Если взглянуть - сколько всего "пихается" в простой exe-шник на С++ Builder в простой программе Hello world... - то невольно подумаешь - что тут тоже самое. Ведь братья дамгарды не писали с нуля свой компилятор - они (насколько мне рассказывали) - взяли некие заготовки - ведь почему X++ так удивительно похож на Java и С++, а не на бейсик, паскаль, фортран и т.д.

Для отладчика добавляется специальная отладочная информация (и это тоже одна из опций компилятора) - поэтому на нее нельзя ориентироваться. Кстати - перед финальной сборкой exe-шника эту отладочную информацию обязательно удаляют (выполняют сборку без указания спецключика) для того, чтобы не давать легкую возможность дизассемблировать + уменьшить размер файла.

Цитата:

Сообщение от DSPIC

Если я правильно понял, то каждый откомпилированный метод хранит код родителя+свой код. Точнее сказать UtilElements хранит. А Вы к этому как пришли? Это общий механизм компиляторов? По крайней мере, UtilElements.source содержит код 1:1 как в AOT.

Как я уже описал выше - я пришел к выводу на основе работы C++-ного компилятора еще в досе. Плюс пообщался на эту тему еще со своими приятелями (разработчиками в аксапте, которые видели исходные сишные коды ax32.exe) - которые независимо от меня пришли к такому же мнению. А т.к. 2 абсолютно независимых человека пришли к одинаковым выводам - я обрел некоторую уверенность в своей гипотезе.

Тем более, что внешние симптомы не позволяют в ней сомневаться.

Цитата:

Сообщение от DSPIC

Я таки залез в \Classes\xRefUpdate. Оказывается, не в перекрёстных ссылках дело, а в банальном

Dictionary::aodFlush();

А вот это вот здравая мысль. Аксапта (4-ка) сбрасывает все напрограммированные изменения в axapd.aoi. И только после рестарта АОСа - видно как изменились размеры aod-шников. Хотя я сам видел такой эффект, что после выхода всех пользователей из приложения - приложение копируейтся со всеми изменениями и без рестарта АОСа. Но изменение aod-шников происходит только после рестарта аоса (посмотрите размер и дату изменения файлов)
В данном случае - происходит видимо какая-то перечитка (возможно из axapd.aoi перечитывается UtilElements - не знаю) , после чего все становится в норме.

Цитата:

Сообщение от DSPIC

Т.е. для автора темы: попробуйте просто обновить AOD (Tools->DevelopmnetTools->ApplicationObjects->Refresh AOD), затем откомпилировать класс.

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

Не думаю, что ее пофиксят. Мне кажется - это больше фича... Тем более - что я к примеру за весь свой стаж с этой проблемой ни разу не сталкивался.
Плюс - предлагаемая методология ведения разработки исключает как правило эти грабли.

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

Поэтому - думаю, что на это просто надо обратить внимание при разработке. Но не более.

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

[DSPIC]

1.

Цитата:

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

Тем не менее, это осталось гипотезой

2. Вы уверены что сравнение компилятора С++ и "компилятора" X++ является корректным?
Я склонен считать, что С++,Паскаль относится к компилируемому языку. А X++, Java, Бэйсик и т.п. относятся к интерпретируемым. А по сему и откомпилированный код у них выглядит немного по-разному и строится по другим принципам.
3. По теме. Относительно рестарта АОСа. Я рестартовал, эффекта не дало. Только запуск Refresh AOD дал эффект.

[sukhanchik]

2DSPIC:
1. Да, гипотезой. В общем-то нельзя сказать - что официальная информация лежит на поверхности. Поэтому много чего приходится принимать как гипотезу, но когда видишь что гипотеза работает - вселяется уверенность что так оно и есть.

2. Уверен. А чем они должны отличаться? И Х++ и С++ используют понятие наследования (мы же сейчас это обсуждали). Оба транслируют исходный код в нечто бинарное и нечитабельное При этом - еще раз повторюсь - Дамгарды не писали с нуля свой компилятор - а значит их X++ был взят откуда-то (с С++?). И идеи новые не привносили.

Вот сравнивать компилятор Х++ с Дельфевым (паскалевым) было бы действительно некорректно. Как минимум - разные языки, разные подходы. Про бейсик я вообще молчу.

Про Java - не знаю. Поэтому и не сравниваю.

А.... так вот... Вы относите его к интерпретатируемым.... Вот тут наши представления расходятся.
Безо всяких вики - под интерпретатируемым языком я подразумеваю такие языки, изменения в программе которых во время ее выполнения изменяет ход программы.
Пример. Зайдите в бейсик (VBA для простоты) и запустив отладчик измените код. И у вас изменится ход программы.

Такого в Х++ не получить. Тот VB, который генерит exe-шник - тот логично использует компилятор ...

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

[DSPIC]

Цитата:

А чем они должны отличаться?

Отличаются они принципиально и кардинально: Язык программирования, раздел "Компилируемые и интерпретируемые языки"

Цитата:

...а значит их X++ был взят откуда-то (с С++?)

Это вы зря. Уж точно С++ и X++ ничего общего не имеют, кроме принципов ООП и похожего синтаксиса.

Цитата:

И Х++ и С++ используют понятие наследования

Это есть один из принципов ООП. ООП это исключительно ЛОГИЧЕСКИЙ принцип построения исходного кода. А то, как он компилируется и исполняется системой - это уже чуть другое измерение.

[sukhanchik]

Чем отличаются интерпретируемые и компилируемые языки программирования - это понятно.

Вопрос лишь в том, к каким относить X++.

Я все время считал (и считаю) - что любой код, который создает промежуточный код - является компилируемым. Пусть даже тот же бейсик. Отсутствие exe-шника не дает право относить язык к интерпретируемым.
Напишите Hello world в VBA. И все может измениться в режиме исполнения. В отличие от Х++

По Х++ - я за "компилируемый". Ибо я не вижу ситуации - когда можно поменять программу "на лету" и она изменит свое выполнение.
Более того - я с маркетинговой т.з. вообще бы исключил термин компиляция из аксапты - не будь язык компилируемым. Лишний термин - которым незачем загружать головы людям

[DSPIC]

Цитата:

По Х++ - я за "компилируемый"

А я категорически против. Термин "компиляция"
может и не совсем подходит к X++. X++ это скорее скриптовый язык. Его "компиляция" скорее всего сводится к проверке синтаксиса, подстановке и вычислению макросов и ещё чего-нить в этом духе. Скорее всего, на выходе "компилятора X++" получается некий оптимизированный, не читабельный код, понятный интерпретатору X++, но никак не ассемблер, как в C++.

Иначе бы, каждый раз, при компилировании какого-нить метода\класса в X++ происходилы бы глобальная компиляция, и на выходе получался бы самомоятельный *.exe файл, ну или м.б. dll... Да, и скорость исполнения бизнес логики была бы в разы выше...

[RumataEstor]

Цитата:

Сообщение от sukhanchik

Чем отличаются интерпретируемые и компилируемые языки программирования - это понятно.

Вопрос лишь в том, к каким относить X++.

По приведенной вами ссылке python приводится как интерпретируемый. X++ нисколько не отличается в этом плане от питона.

[sukhanchik]

Цитата:

Сообщение от DSPIC

Его "компиляция" скорее всего сводится к проверке синтаксиса, подстановке и вычислению макросов и ещё чего-нить в этом духе. Скорее всего, на выходе "компилятора X++" получается некий оптимизированный, не читабельный код, понятный интерпретатору X++, но никак не ассемблер, как в C++.

Ну с этой точки зрения - да - компилятор Х++ скорее правильно назвать транслятором - т.к. он не транслирует в ассемблер или машинный код.

Хорошо. Но факт остается фактом. Аксапта исполняет некий код, который она предварительно до этого оттранслировала в некий свой промежуточный.

То есть - формально - да, наверное этот язык интерпретируемый. НО! И это самое главное. Для разработчика - язык проявляет все свойства компилируемого. И поэтому ожидать от языка фич и особенностей следует как от языка компилируемого.

[belugin]

Цитата:

Сообщение от RumataEstor

По приведенной вами ссылке python приводится как интерпретируемый. X++ нисколько не отличается в этом плане от питона.

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

трансляторы делятся на интерпретаторы и компиляторы

интерпретаторы обрабатывают программу по мере выполнения

компиляторы всю целиком.

наличия делезхной реализации машины, под которую происходит трансляция не является определяющей.

Таким образом есть компилятор X++ -> байткод и интерпретатор байткод -> машкод

[DSPIC]

Цитата:

Ну с этой точки зрения - да - компилятор Х++ скорее правильно назвать транслятором - т.к. он не транслирует в ассемблер или машинный код.

Это единственная точка зрения, которая однозначно приравнивает X++ к интерпретируемому языку.

Цитата:

Для разработчика - язык проявляет все свойства компилируемого

Это как? Например? С моей т.з. как раз наоборот: проявляет все свойства интерпретируемого, ведь функцией "Глобальная компиляция" мы пользуемся крайне редко, в то время как в C++ весь код (кроме самостоятельных библиотек) мы билдим после каждого телодвижения.

Цитата:

И поэтому ожидать от языка фич и особенностей следует как от языка компилируемого.

Да, но только от интерпретируемого. На мой взгляд, в C++ возникшая ситуация принципиально невозможна (хотя, можно подумать). А вот для X++ она как раз не удивительна.

[RumataEstor]

Цитата:

Сообщение от belugin

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

CPython считывает скрипт, формирует его AST и лишь затем его выполняет. Это называется "интерпретатор компилирующего типа". Даже если X++ строит AST, назвать его компилятором нельзя. Достаточно сравнить быстродействие программ, на них написанных.

[sukhanchik]

Цитата:

Сообщение от DSPIC

ЭЭто как? Например? С моей т.з. как раз наоборот: проявляет все свойства интерпретируемого, ведь функцией "Глобальная компиляция" мы пользуемся крайне редко, в то время как в C++ весь код (кроме самостоятельных библиотек) мы билдим после каждого телодвижения.

А вот тут как посмотреть. Представьте себе, что уже откомпилированный (в терминах аксапты) код Х++ представляют собой самостоятельные библиотеки. Прям вот каждый класс - свой Obj-файл.

Компиляция - это превращение класса, в который вносятся изменения в свой obj-файл. Сборка - это слив всех obj-файлов в один exe-шник.

В аксапте - сборка отсутствует. Т.е. ядро аксапты исполняет уже имеющиеся "obj-файлы".
Что есть "глобальная компиляция"? Это пересоздание уже всех obj-файлов.

Что есть "компиляция" или "инкрементная компиляция"? Это пересоздание одного или нескольких obj-файлов.

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

[belugin]

Цитата:

Сообщение от RumataEstor

CPython считывает скрипт, формирует его AST и лишь затем его выполняет. Это называется "интерпретатор компилирующего типа". Даже если X++ строит AST, назвать его компилятором нельзя. Достаточно сравнить быстродействие программ, на них написанных.

http://polishlinux.org/apps/cli/comp...tual-machines/

[RumataEstor]

Цитата:

Сообщение от belugin

http://polishlinux.org/apps/cli/comp...tual-machines/

И что? Да, питон - это интерпретатор. С этим я не спорю. И в нем есть "... -> байткод и интерпретатор байткод -> машкод".

Не верится, что X++ - это компилятор. Если MS сказала, что это компилятор, то это не обязательно так. Потому что даже у питона быстродействие выше.

[sukhanchik]

Цитата:

Сообщение от RumataEstor

Если MS сказала, что это компилятор, то это не обязательно так.

Только это не MS сказала... А еще дамгарды. Просто под понятием компиляции в аксапте подразумевается выполнение некоего действия, после сохранения кода, но до его выполнения.

[DSPIC]

Цитата:

Представьте себе, что уже откомпилированный (в терминах аксапты) код Х++ представляют собой самостоятельные библиотеки. Прям вот каждый класс - свой Obj-файл.

Несомненно, примерно так оно и должно быть. Иначе, если бы был один "Obj", происходила бы его постоянная "перекомпиляция". Но это не библиотеки в классическом представлении. Это проверенный и преобразованный, оптимизированный... но почти исходник.

Цитата:

В аксапте - сборка отсутствует. Т.е. ядро аксапты исполняет уже имеющиеся "obj-файлы".

Ключевое словосочетание - "ядро аксапты исполняет", а не "процессор исполняет".

Цитата:

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

Но это не есть обязательное действие. Я, например, не пользуюсь.

Уфф, к чему мы всё это? Предлагаю мир!

[belugin]

http://en.wikipedia.org/wiki/Compiler

A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code).

Вы называете компилятором, только компилятор в машкод.

[sukhanchik]

Я за мир!
Я просто представил себе X++ как полноценный компилируемый код, а классы как полноценные obj-библиотеки.
Не спорю что это не так. Но именно это представление мне помогло ответить на вопрос - а где искать грабли (и в чем вероятная причина грабель)

[RumataEstor]

Цитата:

Сообщение от belugin

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

PHP код:

s = raw_input("Enter: ")
print "You entered:"
print s 


PHP код:

>python inter.py
Enter: Test
You entered:
Test 


Еще раз запускаем, ждем приглашения ввести текст, между 2мя принтами в исходнике добавляем "print "Interpret"", сохраняем. Вывод не меняется. Значит ли это, что питон скомпилировал исходный код перед выполнением в байт-код? Может быть. Почему же тогда его называют интерпретатором?

[DSPIC]

Цитата:

Вы называете компилятором, только компилятор в машкод.

http://en.wikipedia.org/wiki/Compiler

A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code).

Да, в контексте данной темы именно это мною и предполагается. (Stop explosion )