Заменить микроконтроллер? Это очень вряд ли. Вот из микроконтроллера к FPGA обращаться для решения нестандартных задач - вот это должно быть очень востребовано
У нас бизнес-аналитики вполне себе понимают смысл получающихся диаграмм. И по клику на любой шаг диаграммы тут же оказываешься в коде класса, который его реализует. Обычно этот код уже сам по себе не сложный. И потом технические решения пишут с учетом этого. Т.е. формулируют задачи так, чтобы логика процесса была разбита на похожие отдельные шаги. После реализации ТР разработчиком аналитик может зайти и посмотреть во это всё превратилось и при необходимости уточнить как само решение, так и исходное ТР.
В обсуждениях всплывал недавно Temporal, но обсуждали не фреймворк в целом, а какое у него будет узкое место. В частности, реализацию очередей для обработки тех же самых процессов. Это похоже на общую боль таких систем.
В первой части я как раз рассказал что у нас уже была некоторая рабочая кодовая база, но она стала пугать нас своей сложностью. Мы стали работать с процессами, описывая каждое устойчивое состояние. В итоге это явное указание в какое состояние переходить тоже стало пугать сложностью и мы смогли перейти на декларативное описание того же самого кода. И тут получился редактор, который не требует никаких знаний каких-то фреймворков. Но его назначение только обучение, считайте.
Можно сказать, что у вас тут упрощенный вариант задачи 16 в этом году на AOC: https://adventofcode.com/2024/day/16 Только там еще требуется учитывать стоимость смены направления, что гораздо ближе к реальности в случае нахождения именно более быстрого пути, а не короткого. Кстати, почему решаете задачу не рекурсией?
Заказать печать на Али десятка плат вместе с доставкой - 15$. Стоит ли после этого дома вообще всё это разводить? А еще за 15$ напаяют мелочовку по SMT. Уровень и доступность готовности работать с мелкими партиями поражает.
У нас поход от практики. Сделали нечто, увидели что решает наши задачи, стали убирать обнаруженные проблемы и подводить под описание автомата, которое будет обладать нужными нам свойствами (валидация, читабельность, лаконичность). И дальше то, что в статье описано.
Кстати, хороший вариант подкрепления знаний. Я так делаю с появлением у меня первого сотового телефона и до сих пор. И все приложения на компе только англоязычные, начиная с операционки.
Занимался переписыванием кода с Delphi на ассемблер для ускорения вычислений. Получал где-то двухкратное ускорение. И наблюдал ускорение вычислений по мере появления новых версий компилятора. Потом был долгий перерыв с Delphi. И теперь поставил Community Edition - скорость работы кода стала примерно равна моим примитивным оптимизациям на ассемблере. Т.е. в новом коде я уже этого делать не буду)
procedure TForm1.DisplayButtonClick(Sender: TObject);
var
MS: TMemoryStream;
begin
MS:=TMemoryStream.Create;
try
h[5]:=horiz; h[6]:=vert;
a:=horiz; if (a and 3<>0) then a:=(a+4) and $FFFFFFFC; h[9]:=a*vert; h[1]:=h[9]+1078;
//assign(f,'Mandelbrot.bmp'); rewrite(f,1);
MS.Write(h, 2);
MS.Write(h[1], 52);
//blockwrite(f,h,2); blockwrite(f,h[1],52);
for a:=0 to 254 do
begin
pal[a][0]:=round(127+127*cos(2*pi*(a+16)/255)); pal[a][1]:=round(127+127*sin(2*pi*(a+16)/255)); pal[a][2]:=q[a]; pal[a][3]:=0
end;
for a:=0 to 2 do pal[255][a]:=255; pal[255][3]:=0;
//blockwrite(f,pal,1024);
MS.Write(pal, 1024);
step:=size/horiz;
absc2:=absc-step*(horiz-1)/2; ordi2:=ordi-step*(vert-1)/2;
for b:=0 to vert-1 do
begin
n:=ordi2+b*step;
for a:=0 to horiz-1 do
begin
m:=absc2+a*step;
c:=m; d:=n; t:=4081;
repeat cc:=c*c; dd:=d*d; d:=(c+c)*d+n; c:=cc-dd+m; dec(t) until (t=0) or (cc+dd>1000000.0);
if (t=0) then s[a]:=255 else s[a]:=t mod 255;
end;
MS.Write(s, h[9] div vert);
//blockwrite(f,s,h[9] div vert);
//write('Done: ',b+1,chr(13))
end;
MS.Position:=0;
Image1.Picture.LoadFromStream(MS);
finally
MS.Free;
end;
//close(f)
end;
procedure TForm1.ZoomInButtonClick(Sender: TObject);
begin
size := size-size*0.2;
DisplayButtonClick(Sender);
end;
Всё же так удобнее оценивать ваши труды. Бросил на форму две кнопки и контейнер для изображений, по клику наблюдаем результат, а не появившийся в папке файл :-)
Если брать существующие целые типы и просто масштабировать значения, типа хранить значения, умноженные на 10000 или на 2^8 или сколько нужно - то разве нельзя обойтись существующими возможностями компилятора? Объявить только отдельный тип чтобы случайно не сложить масштабированное значение с не масштабированным и всё? Тут, конечно, нужно еще понимать для чего всё это делается.
Посмотрел код и вспомнил как в школе программировал. Даже стиль тот же. Тогда был важен только результат. И чтобы работало быстро...
Репозиторий на github не завели? Ну и сделайте GUI-приложение. Раз у вас получается сформировать файл BMP- пишите его в память и загружайте в TImage. А по клику на изображение делайте масштабирование. Или по таймеру.
На каком языке описывать SM, нам не так важно, как иметь такой принцип построения этой SM, который обеспечит простую поддержку того, что уже сделано. Описание SM у нас строится просто, основную ценность для нас представляет код, ассоциированный с этой SM, который решает бизнес-задачи. Там кода многократно больше, но теперь он не перемешан с кодом логики SM. И это облегчает написание логики на любом языке программирования.
Перейти в нужное состояние после получения некоторого результата на конкретном шаге - не проблема. Для этого каждый шаг заранее объявляет возможные типы результата выполнения шага, на основании значения которого выбирается следующий шаг. Если говорить о том, что при этом показывается пользователю, то у нас для процесса есть метод, который транслирует текущее содержимое контекста процесса (вместе с текущим шагом) в ответ, который видит пользователь. Пока мы находимся на некотором промежуточном шаге - мы возвращаем Операция в обработке, когда же мы оказываемся на одном из финальных шагов - то начинает глубже анализировать контекст процесса и сообщаем об успехе или причине ошибки (причина не является шагом, хранится отдельно в контексте, т.к. от нее не зависит топология процесса).
Необычная у вас задача. Посмотрели ваш код, больше похоже на функциональный подход. Если бы там можно было увидеть примеры использования то, возможно, мы бы даже взяли себе какие-то идеи.
Каждый процесс выполняется в отдельном потоке, перед началом выполнения захватывается глобальный лок, чтобы процесс не начал выполняться в каком-то другом экземпляре приложения. Все данные процесса локальны для выполняемого потока, поэтому проблем с многопоточностью при обработке множества разных процессов нет.
Заменить микроконтроллер? Это очень вряд ли. Вот из микроконтроллера к FPGA обращаться для решения нестандартных задач - вот это должно быть очень востребовано
Уже принят https://datatracker.ietf.org/doc/rfc9562/
У нас бизнес-аналитики вполне себе понимают смысл получающихся диаграмм. И по клику на любой шаг диаграммы тут же оказываешься в коде класса, который его реализует. Обычно этот код уже сам по себе не сложный.
И потом технические решения пишут с учетом этого. Т.е. формулируют задачи так, чтобы логика процесса была разбита на похожие отдельные шаги. После реализации ТР разработчиком аналитик может зайти и посмотреть во это всё превратилось и при необходимости уточнить как само решение, так и исходное ТР.
В обсуждениях всплывал недавно Temporal, но обсуждали не фреймворк в целом, а какое у него будет узкое место. В частности, реализацию очередей для обработки тех же самых процессов. Это похоже на общую боль таких систем.
В первой части я как раз рассказал что у нас уже была некоторая рабочая кодовая база, но она стала пугать нас своей сложностью. Мы стали работать с процессами, описывая каждое устойчивое состояние. В итоге это явное указание в какое состояние переходить тоже стало пугать сложностью и мы смогли перейти на декларативное описание того же самого кода.
И тут получился редактор, который не требует никаких знаний каких-то фреймворков. Но его назначение только обучение, считайте.
Можно сказать, что у вас тут упрощенный вариант задачи 16 в этом году на AOC: https://adventofcode.com/2024/day/16
Только там еще требуется учитывать стоимость смены направления, что гораздо ближе к реальности в случае нахождения именно более быстрого пути, а не короткого.
Кстати, почему решаете задачу не рекурсией?
Да, они разных размеров бывают, вот небольшая совсем.
Срочные но простые схемки я на макетке собираю. Но от готовых фабричных плат другие ощущения, конечно.
Заказать печать на Али десятка плат вместе с доставкой - 15$. Стоит ли после этого дома вообще всё это разводить? А еще за 15$ напаяют мелочовку по SMT. Уровень и доступность готовности работать с мелкими партиями поражает.
Посмотрите https://smc.sourceforge.net/ как пример результата варианта разработки такой методологии. Сравните со своей.
Да, видно что вы примерно те же проблемы решали.
У нас поход от практики. Сделали нечто, увидели что решает наши задачи, стали убирать обнаруженные проблемы и подводить под описание автомата, которое будет обладать нужными нам свойствами (валидация, читабельность, лаконичность). И дальше то, что в статье описано.
Кстати, хороший вариант подкрепления знаний. Я так делаю с появлением у меня первого сотового телефона и до сих пор. И все приложения на компе только англоязычные, начиная с операционки.
Занимался переписыванием кода с Delphi на ассемблер для ускорения вычислений. Получал где-то двухкратное ускорение. И наблюдал ускорение вычислений по мере появления новых версий компилятора. Потом был долгий перерыв с Delphi. И теперь поставил Community Edition - скорость работы кода стала примерно равна моим примитивным оптимизациям на ассемблере. Т.е. в новом коде я уже этого делать не буду)
Всё же так удобнее оценивать ваши труды. Бросил на форму две кнопки и контейнер для изображений, по клику наблюдаем результат, а не появившийся в папке файл :-)
Если брать существующие целые типы и просто масштабировать значения, типа хранить значения, умноженные на 10000 или на 2^8 или сколько нужно - то разве нельзя обойтись существующими возможностями компилятора? Объявить только отдельный тип чтобы случайно не сложить масштабированное значение с не масштабированным и всё? Тут, конечно, нужно еще понимать для чего всё это делается.
Посмотрел код и вспомнил как в школе программировал. Даже стиль тот же. Тогда был важен только результат. И чтобы работало быстро...
Репозиторий на github не завели? Ну и сделайте GUI-приложение. Раз у вас получается сформировать файл BMP- пишите его в память и загружайте в TImage. А по клику на изображение делайте масштабирование. Или по таймеру.
И будет у вас видео как на YouTube.
Удачи!
На каком языке описывать SM, нам не так важно, как иметь такой принцип построения этой SM, который обеспечит простую поддержку того, что уже сделано. Описание SM у нас строится просто, основную ценность для нас представляет код, ассоциированный с этой SM, который решает бизнес-задачи. Там кода многократно больше, но теперь он не перемешан с кодом логики SM. И это облегчает написание логики на любом языке программирования.
Перейти в нужное состояние после получения некоторого результата на конкретном шаге - не проблема. Для этого каждый шаг заранее объявляет возможные типы результата выполнения шага, на основании значения которого выбирается следующий шаг.
Если говорить о том, что при этом показывается пользователю, то у нас для процесса есть метод, который транслирует текущее содержимое контекста процесса (вместе с текущим шагом) в ответ, который видит пользователь. Пока мы находимся на некотором промежуточном шаге - мы возвращаем Операция в обработке, когда же мы оказываемся на одном из финальных шагов - то начинает глубже анализировать контекст процесса и сообщаем об успехе или причине ошибки (причина не является шагом, хранится отдельно в контексте, т.к. от нее не зависит топология процесса).
Необычная у вас задача. Посмотрели ваш код, больше похоже на функциональный подход. Если бы там можно было увидеть примеры использования то, возможно, мы бы даже взяли себе какие-то идеи.
Каждый процесс выполняется в отдельном потоке, перед началом выполнения захватывается глобальный лок, чтобы процесс не начал выполняться в каком-то другом экземпляре приложения. Все данные процесса локальны для выполняемого потока, поэтому проблем с многопоточностью при обработке множества разных процессов нет.