История изменений

LabView Runtime ставится.

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

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

Ну это уже про другое, будет описание, будет. И документация.

Про какое другое? Это то, что минимально возможно сделать учитывая упорин автора в выборе и политике ведения проекта. Но он и этого не хочет делать, при этом хочет донатов и предлагает ему помочь, но он ведь ничего толком не делает для того чтобы ему могли помочь. Увы недостаточно выкинуть непонятно что, непонятно куда, при этом на целевом ресурсе который по факту не является целевым ресурсом для выбранной им целевой платформы своего софта. Правовые вопросы тоже так и не решены, что еще больше отталкивает от лабвью и прототипа. Тут реально только описать форматы и контракты и принимать dll-ки от сочувствующих проекту или просто в виде кода на С для подкладывания и линковки внутрь трансляций.

Я так не думаю…

но это не меняет сути, все структуры данных и подходы выверены годами разработки и обоснованы математически, а то что лепит ТС наивные реализации на эмпирических показателях, которые под один вариант использования одни, под другой оказываются другими. И вместо того чтобы все-таки ознакомиться с теорией, мы придумываем то, чо давно придумано, и по 10 раз переписываем реализацию потому как оказывается что она неоптимальна, неудобна и просто не работает как надо. Уже 150 раз говорилось о том, что тс требуется как минимум аст или аналог, любое древовидно-узловое представление разбора или аналогичное пусть не на графах, с хорошими показателями по вставке, доступу и выборке, но ведь там поди как были массивы так они и есть и он продолжает с ними страдать, продолжает страдать со своими сувтвариантами хотя в любой литературе настоятельно не рекомендуют их активно использовать, но ТС пошел еще дальше и пытается выдумать в рамках этих вариантов какое-то свое поведение завязанное на представление в пределах своего графического велосипеда, уж точно не понимая ничего в теории эффективности вычислений и разработке трансляторов и компиляторов, а потом мы сидим месяцами отлавливая баги в реализации которая сделана на инструменте для написания конфиругаций для аппаратных решений лабвью, казалось бы очень высокоуровневом решении, где почти невозможно сделать аппаратных ошибок, только логических.

Кстати вопрос об отладке тоже весьма актуальный, ведь отладка в лабвью это убожество в чистом виде, даже текстовый gdb дает на порядки больше возможностей отлаживать приложения. А лабвью это какой-то конфуз с красными от стыда точками.

LabView Runtime ставится.

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

Ну это уже про другое, будет описание, будет. И документация.

Про какое другое? Это то, что минимально возможно сделать учитывая упорин автора в выборе и политике ведения проекта. Но он и этого не хочет делать, при этом хочет донатов и предлагает ему помочь, но он ведь ничего толком не делает для того чтобы ему могли помочь. Увы недостаточно выкинуть непонятно что, непонятно куда, при этом на целевом ресурсе который по факту не является целевым ресурсом для выбранной им целевой платформы своего софта. Правовые вопросы тоже так и не решены, что еще больше отталкивает от лабвью и прототипа. Тут реально только описать форматы и контракты и принимать dll-ки от сочувствующих проекту или просто в виде кода на С для подкладывания и линковки внутрь трансляций.

Я так не думаю…

но это не меняет сути, все структуры данных и подходы выверены годами разработки и обоснованы математически, а то что лепит ТС наивные реализации на эмпирических показателях, которые под один вариант использования одни, под другой оказываются другими. И вместо того чтобы все-таки ознакомиться с теорией, мы придумываем то, чо давно придумано, и по 10 раз переписываем реализацию потому как оказывается что она неоптимальна, неудобна и просто не работает как надо. Уже 150 раз говорилось о том, что тс требуется как минимум аст или аналог, любое древовидно-узловое представление разбора или аналогичное пусть не на графах, с хорошими показателями по вставке, доступу и выборке, но ведь там поди как были массивы так они и есть и он продолжает с ними страдать, продолжает страдать со своими сувтвариантами хотя в любой литературе настоятельно не рекомендуют их активно использовать, но ТС пошел еще дальше и пытается выдумать в рамках этих вариантов какое-то свое поведение завязанное на представление в пределах своего графического велосипеда, уж точно не понимая ничего в теории эффективности вычислений и разработке трансляторов и компиляторов, а потом мы сидим месяцами отлавливая баги в реализации которая сделана на инструменте для написания конфиругаций для аппаратных решений лабвью, казалось бы очень высокоуровневом решении, где почти невозможно сделать аппаратных ошибок, только логических.

Кстати вопрос об отладке тоже весьма актуальный, ведь отладка в лабвью это убожество в чистом виде, даже текстовый gdb дает на порядки больше возможностей отлаживать приложения. А лабвью это какой-то конфуз с красными от стыда точками.

LabView Runtime ставится.

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

Ну это уже про другое, будет описание, будет. И документация.

Про какое другое? Это то, что минимально возможно сделать учитывая упорин автора в выборе и политике ведения проекта. Но он и этого не хочет делать, при этом хочет донатов и предлагает ему помочь, но он ведь ничего толком не делает для того чтобы ему могли помочь. Увы недостаточно выкинуть непонятно что, непонятно куда, при этом на целевом ресурсе который по факту не является целевым ресурсом для выбранной им целевой платформы своего софта. Правовые вопросы тоже так и не решены, что еще больше отталкивает от лабвью и прототипа. Тут реально только описать форматы и контракты и принимать dll-ки от сочувствующих проекту или просо в виде кода на С для подкладывания и линковки внутрь трансляций.

Я так не думаю…

но это не меняет сути, все структуры данных и подходы выверены годами разработки и обоснованы математически, а то что лепит ТС наивные реализации на эмпирических показателях, которые под один вариант использования одни, под другой оказываются другими. И вместо того чтобы все-таки ознакомиться с теорией, мы придумываем то, чо давно придумано, и по 10 раз переписываем реализацию потому как оказывается что она неоптимальна, неудобна и просто не работает как надо. Уже 150 раз говорилось о том, что тс требуется как минимум аст или аналог, любое древовидно-узловое представление разбора или аналогичное пусть не на графах, с хорошими показателями по вставке, доступу и выборке, но ведь там поди как были массивы так они и есть и он продолжает с ними страдать, продолжает страдать со своими сувтвариантами хотя в любой литературе настоятельно не рекомендуют их активно использовать, но ТС пошел еще дальше и пытается выдумать в рамках этих вариантов какое-то свое поведение завязанное на представление в пределах своего графического велосипеда, уж точно не понимая ничего в теории эффективности вычислений и разработке трансляторов и компиляторов, а потом мы сидим месяцами отлавливая баги в реализации которая сделана на инструменте для написания конфиругаций для аппаратных решений лабвью, казалось бы очень высокоуровневом решении, где почти невозможно сделать аппаратных ошибок, только логических.