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

https://www.youtube.com/watch?v=Xkpey2JoU78

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

Причем, созданнные диаграммы надо будет отправлять ТСу через «редактор диаграм с сетевым функционалом», чтобы он на из них на лабвью в виртуалке с виндой сгенерил сишный код. Причем, большей части того же ЛОРа его диаграммы непонятны.

Как, интересно, он попытается привлечь людей для совместной работы? Если никто не сможет прочитать, как работать с его разработкой?

Документировать буду уже ближе к релизу

Ну и будет пилить до скончания века, а релиза так и не будет (ну это мое ИМХО, в одно рыло такое запилить очень трудно, а как автор пытается, т.е. сразу с самораскруткой наверно невозможно).

1 - сначала описание идеи (было); 2 - документ, который черновик, и который описывает все основы, причем, поскольку это черновик, он может в процессе разработки 25 раз поменяться; 3 - прототип на любом ЯП, который тоже может 25 раз переделываться.

у тебя с твоим паскалем совсем уже крышняк сорвало. вобщем то слово у*бунту (глючный дистр для мышевозов) в нике как бы намекает о твоём уровне.

https://github.com/eddieh/libuv-echo-server/blob/master/echo-server.c

Как передавать данные колбекам? Через глобальные переменные?

gio не очень хочется из-за того же ООП, но если libuv плохо зайдет можно будет попробовать.

https://github.com/joyent/libuv/issues/173

Пытаюсь въехать... в чем суть драмы, если коротко и по-русски?

Данные в колбек передаются в телах структур?

Да.

А пример есть?

http://docs.libuv.org/en/v1.x/stream.html#public-members

Читаю книгу документацию - вижу фигу:)

Нашел член void* data в типе uv_stream_t. Оно ли?))

Да!

Почему его тогда нет в документации как публичного члена?

http://docs.libuv.org/en/v1.x/stream.html http://docs.libuv.org/en/v1.x/tcp.html

В uv_handle_t есть.

в libuv практически тот же уровень ООП что и в gio кста.

Оно же под джаваскрипт пилилось. Но все же выглядит удобнее либевента и по факту ООП нет, только касты, как в sockaddr.

А в GIO есть? %)

Кастовать все к нему?

В GIO можно обходиться обычными сишными кастами или придется макросы использовать, как в гтк?))

Нет, uv_stream_t наследует uv_handle_t, то есть содержит все что и uv_handle_t. Это написано в документации ж.

Дык макросы это не про ООП вообще. Можешь и кастовать вроде.

Почему в подобных случаях не используют юнионы?

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

Вот есть семейство структур sockaddr. Можно же объявить юнион из этих структур и записать в юнион айпи и порт как в sockaddr_in или sockaddr_in6, а для функции bind вытащить из юниона sockaddr?

Ну можешь, если я правильно понял.

А почему так не делают в либах типа того же libuv? Чтобы разные структуры не кастовать, а дергать из юниона по надобности.

Кастовать удобнее, и оверхеда нет.

Доброжелателей я уже и так убедил, а недоброжелателей я уже и так послал в жопу.

Очень сомнительно. Убедил ты пока одного Котечку. А между доброжелателями и недоброжелателями есть огромная прослойка людей, которые, возможно, и заинтересовались бы проектом, но им не хватает информации. По факту, отсутствием документации ты посылаешь в жопу именно их.

О предупреждениях

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

Предупреждения о структурах действительно исчезли. Зато появились новые (а может, они и были, за той стеной вполне могли потеряться):

main.c: В функции «main»:
main.c:31:78: предупреждение: overflow in conversion from «int» to «char» changes value from «208» to «-48» [-Woverflow]
 char metaprog_instance_0complex_array_array_pointer_5555219860667822081[] = {208,178,209,150,208,186,208,189,208,190,0};
                                                                              ^~~
main.c:31:82: предупреждение: overflow in conversion from «int» to «char» changes value from «178» to «-78» [-Woverflow]
 char metaprog_instance_0complex_array_array_pointer_5555219860667822081[] = {208,178,209,150,208,186,208,189,208,190,0};
                                                                                  ^~~

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

При запуске программы на экране появляется пустое «вiкно», которое через несколько секунд само исчезает. Так и должно быть?

Выхлоп валгринда на сей раз чистый.

Среда: GCC 8.3.1, Fedora 29, Nuklear вчерашний из гита.

У меня, кстати, этот overflow in conversion был в doublecontact, а именно, в коде, портированном из NBUExplorer. Но там изначально были не читаемые символы, а байтовые сигнатуры для разбора файла NBU. Предупреждение победил, заменив тип элемента массива на беззнаковый.

Я инициализирую массив как char[]. Какие еще к черту конверсии из int? Или надо еще в инициализаторе специально прописать, что это байты, а не инты?

При запуске программы на экране появляется пустое «вiкно», которое через несколько секунд само исчезает. Так и должно быть?

Да. Но это старый пример из прошлой темы. Возьми из этой поновее. Тут уже цикл, можно менять размер окна и оно корректно закрывается.

Кстати, я сделал цикл for и даже условия (пока что только if), но пример показывать пока что лень.

Кстати, char знаковый?

Пока Котечки хватает, об остальных позабочусь позже, когда будет готов хотя бы метапроговский редактор схем «сам на себе».

Зависит от платформы, может быть знаковым, а может быть и нет.

Какие еще к черту конверсии из int?

Ты инициализируешь массив интами же.

Возьми из этой поновее. Тут уже цикл

Это который по ссылке после слов «Наконец-то нормально работают циклы»?

Как Котечка выше написал — зависит от платформы. Хочешь предсказуемости — используй unsigned char.

А как инициализировать чарами?

И тогда инициализация будет беззнаковыми 8-битными?

Поновее был выложен в начале этой темы, читай заголовок.

Где ты живёшь?

Он говорил про Украину, город не уточнял

В Скале оператор match-case очень годный.

Проблема не в этом, а в том что ты устанавливаешь значение чарам больше их размера, 220 там, хотя знаковый чар (который на x86) меньше вмещает...

Не совсем анонче, можешь некоему регистранту спасибо высказать :) И кстати, там ещё примеры «кода» есть.

То есть, надо писать unsigned char? Чтобы был 8-битный беззнаковый, с 256 значений?

Да.

Да уж, одно слово char (и не только?) может иметь несколько разных значений... гуманитарщина епта.

сделай #define uchar char, или typedef. стандарт C не указывает должен быть просто 'char' signed или unsigned в связи с чем компиляторы могут делать так как им удобнее в том числе в зависимости от архитектуры процессора. когда же ты явно указываеть signed/unsigned это гарантированно будет трактоваться одинаково на всех архитектурах и компиляторах. кстати про big/little endian ты уже знаешь?

про big/little endian ты уже знаешь?

Порядок битов в байте, верно? Или порядок байтов в многобайтовом типе?