/cafechan/ - Кафе

Сегодня добавил возможность обращаться к элементам структуры, которая находится в другой структуре. То есть рекурсия. Но и оно может работать не понятно, кроме того, при импортировании лайси-библиотек (в будущем) мне придётся подправить, так как имя члена будет состоять из больше чем одного субимени.

То есть вот такой код:

proc (s32,[s8* path,s32 flags,s32 mode := 0]) open;
proc (s32,[s32 fd]) close;
proc (ssize,[s32 fd,u8* buf,u64 count]) write;
proc (ssize,[s32 fd,u8* buf,u64 count]) read;
proc (ssize,[s32 fd,ssize off,s32 whence]) lseek;

s8* s := &'Hello, World!\n';



@define teststr as struct {
	u8 a;
	u8 b;
};

@define stream as struct {
	s32 fd;
	u8* buf;
	usize seek;
	usize size;
	
	teststr tst;
};

proc (s32,[s32 argc,s8** argv]) main {
	stream file;
	file.tst.b := 1;
	write(file.fd,s,14);
	return 0;
};

Компилируется в такой лайси-байткод:

struct {
        u8 a;
        u8 b;
} teststr;

struct {
        s32 fd;
        u8* buf;
        u64 seek;
        u64 size;
        teststr tst;
} stream;

proc (s32,[s8* %0,s32 %1,s32 %2]) @0 'open';

proc (s32,[s32 %0]) @1 'close';

proc (s64,[s32 %0,u8* %1,u64 %2]) @2 'write';

proc (s64,[s32 %0,u8* %1,u64 %2]) @3 'read';

proc (s64,[s32 %0,s64 %1,s32 %2]) @4 'lseek';

s8* @5 's' := &'Hello, World!\x0a';

proc (s32,[s32 %0,s8** %1]) @6 'main' {
.0:
        alloca stream %2;
        %2.4.1 := 1;
        %3 := @2 'write' call [%2.0, @5 's', 14];
        return 0;
};

или в такой LLVM IR:

; ModuleID = "module"
target triple = "x86_64-unknown-linux-gnu"
target datalayout = ""

%"teststr" = type {i8, i8}
%"stream" = type {i32, i8*, i64, i64, %"teststr"}
declare i32 @"open"(i8* %".1", i32 %".2", i32 %".3") 

declare i32 @"close"(i32 %".1") 

declare i64 @"write"(i32 %".1", i8* %".2", i64 %".3") 

declare i64 @"read"(i32 %".1", i8* %".2", i64 %".3") 

declare i64 @"lseek"(i32 %".1", i64 %".2", i32 %".3") 

@"s" = global [14 x i8] c"Hello, World!\0a"
define i32 @"main"(i32 %".1", i8** %".2") 
{
.4:
  %".5" = alloca i32
  store i32 %".1", i32* %".5"
  %".7" = alloca i8**
  store i8** %".2", i8*** %".7"
  %".9" = alloca %"stream"
  %".10" = getelementptr %"stream", %"stream"* %".9", i32 0, i32 4
  %".11" = getelementptr %"teststr", %"teststr"* %".10", i32 0, i32 1
  %".12" = trunc i32 1 to i8
  store i8 %".12", i8* %".11"
  %".14" = getelementptr %"stream", %"stream"* %".9", i32 0, i32 0
  %".15" = load i32, i32* %".14"
  %".16" = getelementptr [14 x i8], [14 x i8]* @"s", i32 0, i32 0
  %".17" = zext i32 14 to i64
  %".18" = call i64 @"write"(i32 %".15", i8* %".16", i64 %".17")
  ret i32 0
}

Надеюсь нигде ничего не перепутал. Думаю, пора уже начинать вводить поддержку лайси-библиотек.

Это реальный разработчик или шуточки чьи-то?

>>68121

Просто если реальный разработчик то это круто, желаю удачи в разработке :о

>>68121

Да, я реально разрабатываю Лайси и его компилятор-интерпретатор Иколайси.

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

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

Из последних моих мыслей насчёт Лайси:

Я думал добавить в стуктуры что-то типа псевдонимов. Чтобы можно было написать:

struct {
	fsignle[3] : {x,y,z}; v; 
}

(fsignle в Лайси обычно соответствует float в Си, он же IEEE 754 single)

Чтобы можно было обращаться к элементам не только v[0], но и x, это повысило бы читабельность кода и уменьшило бы бойлерблейт.

Но в последнее время я изучал GLSL и заметил там интересную фичу, что можно написать .xy к переменной типа vec3 и тогда будет возвращён vec2, содержащий x и y.

Так я и подумал, а может делать так?:

struct {
	fsingle[3] v;
	
	x -> v[0];
	y -> v[1];
	z -> v[2];
	
	xy -> vec2_t(x,y);
	yz -> vec2_t(y,z);
	xz -> vec2_t(x,z);
	
	xyz -> vec3_t(x,y,z);
	#...
}

Но по сути это будет чем-то типа методов или я даже не знаю. Получится, что можно сделать псевдонимом вызов функции без аргументов и это может выглядеть немного неявно для программиста, но с другой стороны пусть он читает стандарт и вообще это добавит столько удобства! А если ввести всякие крутые препроцессинговые штуки, то можно будет даже автоматизировать генерацию псевдонимов в структуре, чтобы можно было указывать кроме xyz и rgb, зачем лишний раз писать одинаковые псевдонимы для x,y,z и r,g,b?. Кроме того, вопрос, разрешать ли "чтением" псевдонима изменять содержимое структуры? Думаю, это не надо разрешать.

>>68141

Я в ахуе,погуглить решил, нашел твои треды на других бордах… Мне кажется, ты очень хороший специалист.

Это у тебя хобби такое, ты сам программистом работаешь где-то в компании, да?

>>68163

Спасибо.

>Мне кажется, ты очень хороший специалист.

Интересное мнение, хотя я программирую только чуть больше трёх лет.

Программистом я неработаю. Хобби в виде создания софта? Это да, я хочу создать очень много софта, прежде всего для себя, но и другим дам исходники, чтобы они тоже использовали мои продукты, а по возможности, и помогли.

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

Кроме Лайси мне очень важно создать некоторые другие продукты, напрямую связанные с Лайси. Например, свой веб. Мне очень не нравится HTML, CSS и JS, я, прежде всего, не понимаю их и не хочу понимать. Они рудиментарны и стары, пора вводить что-то новое. Я хочу свой веб с виджетами и Лайси-скриптами. Он будет состоять из нескольких систем:

0. Моей системы ГУИ (она уже разрабатывается, но пока только на си)

1. markdown language, с помощью которого можно будет описывать страницы и виджеты

2. Embedded Laisi — лайси с немного изменёнными правилами, будет использоваться в качестве скриптов. Что важно, можно не обязательно лайси-код использовать, но и лайси-байткод, который можно будет скомпилировать из LLVM IR, соответственно, писать скрипты на любом или почти любом компилируемом ЯП. Си, C++, Rust, etc.

3. Моей системы сетевых запросов. Всмысле GET, POST и другие. Может и не стоит, а может и стоит добавлять. Можно использовать и HTTP, но даж незнаю.

Ещё продукты, которые я задумал это новый формат видео и картинок, а также интерактивных медиа. Он будет заключаться в том, что он есть по сути embedded Laisi, где в специальные функции пишутся данные, какую картинку поставить. А сама картинка вычисляется кодом. Можно, чтобы программист её писал и будет что-то типа того, что можно увидеть на https://www.shadertoy.com/. А можно, чтобы автоматически кодек генерировал код. У такого формата есть свои плюсы и минусы, но первый плюс я уже указал (шейдертой) и его достаточно.

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

Вот так может выглядить вектор из библиотеки math в будущем (тут показаны некоторые фичи, которых нет в стандарте нынешней версии v0.7.5):

@define vec!n!(T) as struct {
	@if n == 0
		@assert "Vector size is zero"
	@end
	
	T[n] v;
	
	@if n > 0
		x -> v[0];
	@end
	@if n > 1
		y -> v[1];
		xy -> vec2(T)([.v[0] := x,.v[1] := y]);
	@end
	@if n > 2
		z -> v[2];
		xyz -> vec3(T)([.v[0] := x,.v[1] := y,.v[2] := z]);
	@end
	@if n > 3
		w -> v[3];
		xyzw -> vec4(T)([.v[0] := x,.v[1] := y,.v[2] := z,.v[3] := w]);
	@end
};

@define __add__(vec,[vec,vec]) as func (vec out,[vec v0,vec v1]) {
	@if typeof(v0).n != typeof(v1).n
		@assert "Vector sizes doesn't match"
	@end
	
	out.v[:] := v0.v[:] + v1.v[:];
}

Выглядит страшно, зато использовать удобно. Но как это парсить?!

Не путать с std.vector из будущей библиотеки std.

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

Запушил. Исходники есть. Вы можете скомпилировать через icolaisi test.lic -o out.ll; clang out.ll -o out

@import io;

s8* s := &'Hello, World!\n';

proc (s32,[s32 argc,s8** argv]) main {
	io.stream file;
	file.fd := 0;
	write(file.fd,s,14);
	return 0;
};

io:

proc (ssize,[s32 fd,u8* buf,ssize count]) write;

@define stream as struct {
	s32 fd;
	u8 mode;
};

Тут требуется некоторое пояснения, я сам только наткнулся на это. Видите, write? Он пишется не io.write, а write. Если функция объявлена без инициализации (как write выше), то она считается external. А значит, она предполагается для линковки с бинарной библиотекой или чем-то подобным, соответственно, её имя менять нельзя. Если бы это была функция с кодом или просто числовая переменная, то надо было бы обращаться через префикс 'io.'.

Ещё чутка про name mangling в Laisi. Лайси предназанчен для исполнения из исходников, соответственно, нет нужды придумывать замысловатые имена символов как в C++ с его неймспейсами и перегрузкой функций. Так что в скомпилированном бинарнике в зависимости от импортивания функции могут иметь разные имена. Если скомпилировать просто код с импортированным io, то все функции из io будут назваться io.X. А если скомпилировать саму библиотеку io, то будут использоваться имена самих функций.

Что насчёт компиляции Лайси-кода в бинарную библиотеку, пригодную для Си и других ЯП, то тут есть проблемка. Ведь в Си нельзя в названиях переменных использовать точку, а именно с ними и называются символы в библиотеках. Есть вариант вместо точки ставить '_' или '__', а можно делать отдельные имена через строкове имя переменной. Только раньше я не предполагал, что к нему не надо будет подставлять префиксы, но теперь знаю. То есть можно сделать библиотеку MyImageDecode и в ней прописать:

func (rett,[s32 a,s32 b]) decode 'midDecode' ...

и тогда из Лайси-кода можно будет обращаться к MyImageDecode.decode, а если скомпилить бинарную библиотеку, то midDecode.

Добавил немного поддержки дженериков.

Например:

@define vec!n! as struct {
	s32[n] v;
};

proc (s32,[s32 argc,s8** argv]) main {
	vec2 var0;
	vec3 var1;
	vec2 var2;
	return 0;
};

в

struct {
        s32[2] v;
} vec2;

struct {
        s32[3] v;
} vec3;

proc (s32,[s32 %0,s8** %1]) @0 'main' {
.0:
        alloca vec2 %2;
        alloca vec3 %3;
        alloca vec2 %4;
        return 0;
};

Но этого не хватает, мне надо ещё чтобы можно было настоящие аргументы макроса кидать.

Вот что мне надо ещё сделать для выпуска icolaisi первой версии:

0. Приравнивания в аргументах в определении макроса.

1. @undef

2. @for

3. Темплейты.

4. Улучшенное импортирование.

5. Улучшенный препроцессинг.

6. Включение бинарных файлов.

7. Вызов сайдэффектфри функций препроцессором.

8. Тип auto (автоопределение типа).

9. Энумерация чисел (рандж).

10. Оператор возведения в степень.

11. Поддержку float-чисел (хотя бы single и double).

12. Многомерные массивы.

13. Энумерации (как структуры).

14. func-тип.

15. vp (void pointer) тип.

16. Обращение по референсу (->). Как раз занимаюсь этим.

17. self-аргумент.

18. Аттрибуты переменных.

19. Видимость глобальных переменных.

20. Перегрузка операторов.

21. Инкремент, декремент.

22. Преобразование типов.

23. Операции сравнения.

24. Оператор in.

25. Исключения.

26. Перечисление элементов в массиве.

27. Псевдонимы для элементов структур.

28. Перечисление элементов структур.

29. lenof.

30. sizeof.

31. dup.

32. Списковые данные, их передача в функциях для перегрузки операторов.

33. Null, True, False.

34. Аллокатор памяти в куче.

35. Дефолтные исключения.

36. switch.

37. for.

38. each-конструкция.

39. abs, max, min.

40. Вывод ошибок синтаксиса

Добавил поддержку -> но дополнительно мог что-то сломать.

Можно скомпилировать такой:

@define vector<T> as struct {
	T[] elms;
	usize num;
};

proc (s32,[s32 argc,s8** argv]) main {
	vector<s32> v;
	
	vector<s32>* vecp := &v;
	
	vecp->num := 5;
	
	return 0;
};

код.

Эта борда загружается медленно и очень много нод побанено. Буду сюда реже писатб.

>>67660

>Си, но этот язык устарел

а что это значет?

>>68175

>Мне очень не нравится HTML, CSS и JS

в обшем согласен.

>не понимаю их и не хочу понимать.

но как тогда избежать и не повторить те же самые ошибки?

а какие в общем иновации в этом новом языке? пока что я вижу обычый C-like language

просто со своеобразным синтаксом. что на нём можно (будет) выразить более удобно или понятно?

>>69419

>а что это значет?

Он подошёл бы для разработки под древние микроконтроллеры, но сейчас вся инфраструктура поменялась и он стал очень неудобным.

>но как тогда избежать и не повторить те же самые ошибки?

Их надо поверхностно просмотреть!

Но в общих чертах мой markdown language задумывается как одновременно и язык для описания ГУИ, и язык для описания гипертекста, что-то типа того.

Второе — собирался сделать тщательную проработку для виджетов. Если посмотреть на HTML или Qt, то там есть формы и кнопочки и как кастомизировать их — непонятно! В моей библитоеке ГУИ я планирую сделать 2 уровня виджетов — низкоуровневые и набор высокоуровневых. Низкоуровневые это всякие квадраты, полигоны, фигуры из кривых Безье. На них можно хукнуть события типа клика, нажатия, отпускания, набора текста, двойного нажатия и всё такое. Высокоуровневые (я начал вводить их в свою текстовую библиотеку совсем недавно) ­— кнопочки, слайдеры, менюшки, строки и подобное. И чтобы сделать виджет кнопки, то надо будет вызвать функцию для создания кнопки и явно указать дочерние виджеты. Таким образом можно будет лекго сделать кнопку, состоящую из одноцветного ректангла, например, при наведении фокуса будет показываться другой виджет (можно полупрозрачный ректангл), хукнуть простые нажатия (у меня есть непростые нажатия и там много бойлерблейтить надо, если создавать свой виджет с нуля). И для слайдера можно выбрать отдельный виджет для поля и виджет для слайдящей пимпочки.

Третье — отсутсвие скачущего ГУИ. Я офигеть как ненавижу, когда ГУИ скачет (ещё ненавижу, когда какая-то менюшка появляется через N времени. Особенно ужасно, когда её поведение не понятно. Этим страдает xfce). Загружаю страницу — кортинки прогружаются, читаю комментарии, картинка загрузилась — комментарии уехали. Вроде бы из-за скачущего ГУИ в прошлом или позапрошлом году на Гаваях была объявлена ракетная атака и все попрятались.

>какие в общем иновации в этом новом языке

Векторные сложения. Можно сложить сразу все элементы в массиве. each-конструкция (её нет в стандарте, я её временно удалял, но теперь решил, что надо вернуть), она позволяет выполнять код параллельно (не как потоки, а как SIMD, но задействуются потоки). Темплейты, дженерики. Подобное есть в C++. Псевдонимы для структур (не помню, я их добавил в стандарт или нет). Подобие частного случая есть в GLSL, когда у вектора можно сделать .x, а можно и .xy.

Алсо, в Лайси есть и исключения, но я пока с ними полностью не разобрался как их реализовать.

>>69419

Вспомнил ещё, я собираюсь сделать возможность исполнения сайд-эффект-фри лайси-кода во время препроцессирования (во время компиляции) для получения значений. Можно, например, генерировать значения констант на стадии компиляции.

Тем временем я добавил некоторую поддержку темплейтов.

Например, такой код:

@import io;

func ([s32 argc,s8[][] argv]) main {
	io.print(0x20,67,68);
	io.print(0x0A,69,0xA);
	io.print(72,0xA);
};

io.lic:

func (ssize,[s32 fd,u8[] buf,ssize count]) write;
func (ssize,[s32 fd,u8[] buf,ssize count]) read;
func (ssize,[s32 fd,ssize offset,s32 whence]) lseek;
func (s32,[u8* path,s32 flags,s32 mode]) open;
func (s32,[s32 fd]) close;

@template func ([...]) print {
	@for N in ...
		write(1,&N,1);
	@end
};

Он преобразуется в следующий Лайси-байткод (который пока и не байткод):

func (ssize,[s32 %0,u8[] %1,ssize %2]) @0 'write';

func (ssize,[s32 %0,u8[] %1,ssize %2]) @1 'read';

func (ssize,[s32 %0,ssize %1,s32 %2]) @2 'lseek';

func (s32,[u8* %0,s32 %1,s32 %2]) @3 'open';

func (s32,[s32 %0]) @4 'close';

func ([s32 %0,s32 %1,s32 %2]) @6 'io.print.s32_s32_s32' {
.0:
        %3 = addrof %0;
        %4 = @0 'write' call [1, %3, 1];
        %5 = addrof %1;
        %6 = @0 'write' call [1, %5, 1];
        %7 = addrof %2;
        %8 = @0 'write' call [1, %7, 1];
};

func ([s32 %0,s32 %1]) @8 'io.print.s32_s32' {
.0:
        %2 = addrof %0;
        %3 = @0 'write' call [1, %2, 1];
        %4 = addrof %1;
        %5 = @0 'write' call [1, %4, 1];
};

func ([s32 %0,s8[][] %1]) @5 'main' {
.0:
        %2 = @6 'io.print.s32_s32_s32' call [32, 67, 68];
        %3 = @6 'io.print.s32_s32_s32' call [10, 69, 10];
        %4 = @8 'io.print.s32_s32' call [72, 10];
};

Ну а там дальше в LLVM IR.

Пример есть на гитлабе. ./icolaisi test.lic -o out.ll; clang out.ll -o out; ./out

С библиотекой ГУИ я почти ничего не делал. (она написана на C++, но потом перепишу на Лайси). Она использует одну мою графическую библиотеку, у этой библиотеки уже 2 бекенда для отрисовки. Графическая библиотека тоже написана на C++, потом перепишу на Лайси. Бекенды есть софтрендер и глсл. Вы только не лольте, но но в обоих случаях используется рейтрейсинг, да, я рейтрейсю 2D-фигуры. В софтерендерном бекенде всё вычисляется как есть, а в глслном для каждой сцены генерируется шейдер, в который потом каждый фрейм пересылаются вертексы, положения, данные мешей и текстура, содержащая все текстуры (так как опенгл не разрешает за раз использовать больше одной текстуры, индексируя в ГЛСЛ. Можно сделать glAmctiveTepxture, gzhBimpdTexutr, if (0) {texture1} if ()1 {texut2}, но так не надо. Минус есть в том, что в ряде машин максимальная текстура небольшая — 16384x16384, где-то ещё меньше. Ну а что хотели, опенглогулаг на дворе).

Для Лайси надо сделать поддержку перегрузки операторов и начать писать библиотеку dapa (data parsing), чтобы парсить код и переписать Иколайси на Лайси.

Недавно добавил некоторый функционал, например мультивекторные вычисления, но не полностью.

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

Во время своих размышлений я прихожу к выводу, что Лайси должен быть как бы гибридным — с препроцессорной стороны динамическая типизация (дженерики типы, дженерики темплейты, генерация кода через @for, генерация кода через компиляцию и вызов реального кода), а с вычислительной стороны статическая типизация. Только как бы это облагородить? Мне не очень нравится, что в препроцессорной части надо ставить @ перед директивами.

Недавно я решил, что вместо конструкций типа alloc N, ptr vary N, del ptr следует ввести просто функции. И я придумал, что пусть это будет в библиотеке liblaisi. Но есть проблемка, она требует мьюетексов, так что будет включать в себя библиотеку thread, наверное, да. В общем, так будет легче, чем встроенные аллоки-маллоки.

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

Пример таков:

@template with T generator (vector<vector<T>>,[vector<T> str,T d]) split {
	usize old_i = 0;
	
	for i,elm in str {
		if (elm == d) {
			@yield vector<T>(str[old_i:i]);
			old_i = i + 1;
		}
	};
	
	@return;
};

Он должен разложиться в что-то типа такого:

(использую u8 в качестве T)

@define split_struct as struct {
	usize old_i;
	usize i;
	
	bool end;
}

func (vector<u8>,[vector<u8> str,u8 d,split_struct* data]) split_blablablainfo {
	usize i = data->i;
	usize old_i = data->old_i;
	
	while i < lenof(str) : {i++} {
		if (str[i] == d) {
			data->i = i;
			data->old_i = old_i + 1;
			
			return vector<u8>(str[old_i:i]);
		}
	}
	
	data->end = True;
	return vector<u8>;
};

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

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

Почему важны генераторы? Я не знаю, но в некоторых ситуациях они могут сэкономить память. Например, пишешь for a in superfunction(), которая выдаёт 1024 структур по 5 МБ и ведь не нужно же 5 гигов копировать, можно по-одному обрабатывать. Хотя, в таком случае, программист может просто написать while (i < …) {a = superfunction(i); …}

В общем, пока не буду ничего с генераторами думать. У меня сейчас версия Лайси v0.7.X. Это туманная, шизофреническая версия. Когда доделаю Иколайси, выпущу Лайси v0.8. И уже генераторы, возможно, добавлю в v0.9, вместо с кучей крутых фич, которые я пока не придумал.

Пока Лайси не делается, снова делаю ГУИ-библиотеку. (да, так медленно)

Я её переписал (опять же на C++ кстати, уже почти научился использовать new и delete вместо malloc/calloc и free).

Взялся за реализацию высокоуровневых виджетов, в общем вот кнопка. Эта кнопка может быть одновременно и чекбоксом, и кнопкой со сменяемыми значениями (как в майнкрафте, где выбор между несколькими тайтлами кнопок в некоторых опциях), и просто кнопкой. Она может вызывать коллбек по отпусканию (при этом проверятся, курсор остался на той же кнопке или нет) или при нажатии. Когда курсор попадает на неё, вызывается коллбек FocusIn и делает видимым blink_hover. В данном случае это полупрозрачный белый квадратик. При нажатии рисуется press_blink виджет, это полупрозрачный синий квадратик.

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

Кубик сзади это просто декорация.

[i]Извините, не смог видео отправить, так как эта борда мне не дала![/i]

Когда доделаю Лайси, хотел эту библиотку переписать на Лайси, чтобы мои будущие пользователи Лайси и Я могли сразу юзать ГУИ (хоть её и придётся заново учить, это не Qt и GTK+). Потом сделать биндинг для Си, а из него для остальных ЯП (в частности, питона), но я недавно понял, что мне придётся в сишные хедеры преобразовывать почти все структуры данных Лайси. То есть и вектора из mem, хеш-таблицы и всё-всё-всё, что я там понапишу в первых библиотеках. Это, конечно, можно сделать, но я не думал что будет так сложно, мдех.

Кстати, так как моя ГУИ-либа использует мой графический движок, а у него планируются целых 4 бекенда: opengl, glsl-рейтрейсинг, softrender-рейтрейсинг, софтрендер-растеризатор, то его можно будет использовать хоть для микроконтроллеров и прочего bare metal. Надо будет просто немного повелосипедить с циклом отрисовки и обработки событий, а также вручную генерировать эти самые события.

Что насчёт событий, то в этой ГУИ-библиотеке устройства смогут передавать:

0. Указатели. Вектор "курсоров", которые имеют расположение, N кнопок, возможность нажимать и отжимать кнопки, с разным усилием и поворотом. Как я понимаю, это покрывает и мышки (кроме колёсиков, но они отдельно), и графический планшет со стилусом (усилие нажатия и даже поворот), и сенсорный экран (надо учесть, что курсор как бы пропадает после отжатия).

Нажатие, кстати, может быть двойным, тройным и т.д. Желаемый период между одинарными щелчками настраиваемый.

1. Клавиши. Это клавиатура и подобное. В отличие от указателей, тут доступен только номер клавиши и усилие. Незнаю, стоит ли вводить поворот. Вряд ли кому-то понадобится матрица из энкодеров, чтобы юзать её в качестве нормальной клавы, а вот клавиатуры с определением усилия уже сущетсвуют.

2. Колёса. Колёсики мыши. Имеют номер и флоатское значение поворота. Первое и единственное колёсико на мышке имеет номер 0, но иногда же встречаются мышки и с двумя колёсиками. Одним можно вертикально скроллить, а другим горизонтально., вот оно и будет иметь номер 1.

3. Ввод. Ввод текста, ввода других данных из буфера обмена и всё такое.

4. Драг-н-Дроп. Иконки, файлы и прочее можно графически переносить из одного окна в другое, так пусть будет же в моей ГУИ-либе это из-коробки. Есть проблемка. В SDL2 драг-н-дроп содержит просто путь к файлу, а мой драг-н-дроп должен быть пошире. Им заниматсья я буду потом, может быть.

5. FileDialog. Видел такую библиотеку на гитхабе, называется https://github.com/mlabbe/nativefiledialog NativeFileDialog. Может быть, попробую её и если понравится, то включу в состав моей ГУИ-библиотеки. Я сам не собираюсь писать велосипедный и неудобный встроенный файловый менеджер, пусть пользователи используют нативный!

6. Также совсем недавно вспомнил, что в смартфонах есть такие события/кнопки как ◁, ⃞ и ◯. Если ⃞ это просто "свернуть", то ни ◁, ни ◯ в стандартных ПК-приложениях нет. Пусть будут события навигации туда-сюда и событие вызова меню настроек/контексткого меню. Вот такие высокоуровневые события, да.

Конечно, есть ещё всякие экзотические джойстики и прочая шелуха, но пусть автор ПО сам реализует взаимодействие с ними.

>>71127

P.S.: Загрузил видео на сторонний ресурс, раз этот запретил.

http://videonwcswhrqynk.onion/video/gui-test-button

>Social networks prohibit posting your video content?

По моему я тебя на мочефоксе видел. Чтож, здравствуй опять.

>>71263

Есть не по программированию, а просто по компьютерам.

Таненбаум Архитектура Компьютеров.

Таненбаум Современные операционные системы.

Таненбаум OS Design and Implementation (но это скорее, если интересуешься осдевом)