Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью

Ну раз так, расскажите мне какое время вставки в список питоновский.

На то это и Си, а не Pascal.

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

Повторюсь. Си знают все инженеры связанные с электрикой

Вот только это не Си. Это другой язык, который имеет другую семантику. Вы примеры кода по ссылке читали?

TrapC это не Java, это форк диалекта Си c дополнительной степенью защиты. В середине статьи они беседуют как проверять границы массива за минимальное время.

По производительности это получится именно Java. А по остальным показателям, таким как выразительность или типобезопасность — хуже Java. Просраны две главных фичи Си без получения преимуществ других языков.

Ну раз так, расскажите мне какое время вставки в список питоновский.

Послушайте, спорщик. На контестах за 1.5 часа надо решить три задачи, одна из которых по сложности это реализация Динамического Программирования на двумерном массиве, с ответами хранящимися в трех мерном массиве.

Вы пытаеться ошеломить одномерным списком и азами BigO notation.

Вот только это не Си. Это другой язык, который имеет другую семантику. Вы примеры кода по ссылке читали?

Тоже поспорить хотите не о чём? С тыканье в цитаты и размусоливанием смысла первых двух абзацев.

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

Вы это по какой-то причине сделать не хотите. Ваше право.

«Вот смотри, Петька. В Rust нет буфер оверранов, и в TrapC нет буфер оверранов. Но есть нюанс.»

Это живое воплощение того самого анекдота, извините =))

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

Вот вообще ни разу. Веб - это обмен декларативными описаниями. Тогда как иксы это обмен сообщениями.

Веб:

браузер < сервер: страница элемент /элемент элемент элемент /элемент /элемент /страница.
браузер < сервер: добавить элемент /элемент в третий элемент страницы.
браузер > сервер: тут пользователь нажал кнопку, поэтому вот тебе запрос "таблица table, условие a > 100, первые 100 строк"
браузер < сервер: JSON [ {a:123, b:234},...{a:321,b:432} ]
....

иксы

server < client: создай окно
server > client: создал, ID такой-то
server < client: создай окно внутри окна c ID1
server > client: создал, ID такой-то
server < client: перемести окно ID2 в координаты
server > client: переместил
server < client: установи размер ID1
server > client: установил
server > client: нажали ПКМ в окне ID1
server < client: создай окно внутри окна с ID1
server > client: создал, ID такой-то.

Одно - декларативщина, другое - события. Одно описывает безусловный layout который надо как угодно отобразить, другое может зависеть от всяких условий на стороне сервера.

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

Ну вы на вопрос так и не ответили.

одна из которых по сложности это реализация Динамического Программирования на двумерном массиве, с ответами хранящимися в трех мерном массиве

Интересно, какой же Художественный Смысл вы вкладываете в динамическое программирование? Какой-то легкий контест. Даже на 1/8 ICPC задачи гораздо сложнее.

приложение может просто медленно исполняться, а может периодически подвисать. Это разные проблемы

Gtk просто создает OpenGL окно и рисует там. Xt вообще не является тулкитом, а платформой для создания виджетов. Виджеты на основе Xt это Motif, Xaw, в одном приложении ты можешь использовать два этих тулкита. FLTK виджет в GTK приложение скорее всего не встроить.

Виджеты это классы окон?, поэтому подозреваю что сначала регистрируются соответствующие классы, а потом действительно посылается команда создай окно определенного класса (кнопка) по x, y. Перемещение виджетов и всякие базовые операции точно производятся так. Нужно ли что то сверху?

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

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

Вот вообще ни разу. Веб - это обмен декларативными описаниями. Тогда как иксы это обмен сообщениями.

Веб — это как хочешь, так и будет. Потому что дисплейный сервер не просто блендит пиксмапы, а исполняет шейдеры произвольной сложности… то есть простите… скрипты =))

Так что всё правильно, проведена работа над ошибками, веб — это следующая ступень эволюции.

Правда как и предыдущая, слеплена из говна и палок. Но так уж у эволюции заведено.

Человеческий глаз вон вообще это эволюционно «дважды вывернутая наизнанку» штука с максимально всратым инженерным дизайном. А что делать…

Какой-то легкий контест. Даже на 1/8 ICPC задачи гораздо сложнее.

Возможно для спортсменов и легкий. Leetcode это не спорт, а тестирование инженеров которым не только алгоритмы щелкать.

Интересно, какой же Художественный Смысл вы вкладываете в динамическое программирование?

Поболтать захотелось. Тезис о безграмотности разработчиков на языках выского уровня не пролез. Но вы не унимаетесь.

Ну вы на вопрос так и не ответили.

Ну всё, вы сразили на повал. Нагуглить сложность работы с списком в Python невозможно. Победа.

Веб это скорее развитие идеи с PostScript. В иксах нету скриптования.

Gtk просто создает OpenGL окно и рисует там.

Зависит от параметров. Может и в X11 рисовать, и во фреймбуфере. В любом случае оно готовит картинку и отправляет её на экран.

Xt вообще не является тулкитом, а платформой для создания виджетов.

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

Виджеты это классы окон?,

Типа того. Это окна с отрисовкой содержимого на стороне сервера в зависимости от типа(класса) - кнопка, чекбокс, список, таблица и т.п.

поэтому подозреваю что сначала регистрируются соответствующие классы, а потом действительно посылается команда создай окно определенного класса (кнопка) по x, y.

Да. И потом если на стороне сервера пользовать мышом ткнул или набрал что-то, посылаются event’ы программе. Ну как в Win32 - WM_COMMAND/WM_NOTIFY и т.д. Механизм есть, нужно только расширение протокола для этих server-side виджетов.

Перемещение виджетов и всякие базовые операции точно производятся так. Нужно ли что то сверху?

Да, реализация классов виджетов на стороне сервера и протокол обмена сообщениями виджетов, типа «в окне ID=123 поменять текст на ‘OK’» или там «в окне ID=123 пользователь жмакнул кнопку выпадающего списка».

Пробовал я тот самый Cinepaint Профессора. Если кратко: не работает.

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

Должны? А есть реальные примеры таких реализаций?

Просто вот реально, если говорить серьёзно без шуток. Единственный такой пример, который приходит на ум, это как раз веб.

Да. И потом если на стороне сервера пользовать мышом ткнул или набрал что-то, посылаются event’ы программе. Ну как в Win32 - WM_COMMAND/WM_NOTIFY и т.д.

В Win32 контроллы реализованы на стороне приложения.

... и протокол обмена сообщениями виджетов, типа «в окне ID=123 поменять текст на ‘OK’» или там «в окне ID=123 пользователь жмакнул кнопку выпадающего списка».

Оно так и работает в случае с Motif, Xaw.

реализация классов виджетов на стороне сервера

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

А ведь обязательно захочется свои странные виджеты

https://www.softportal.com/scr/3824/victoria-big-6.png

https://habrastorage.org/getpro/habr/post_images/ed3/9e4/578/ed39e4578ae5b9e7...

Оно так и работает в случае с Motif, Xaw.

Картинко тут с вами не согласна: https://ru.wikipedia.org/wiki/Xaw

Кнопка это окно, поэтому клик по кнопке это сигнал клик по окну. Отдельный сигнал «Клик по кнопке и ничего кроме кнопки» Stanson думаю не имел виду. Если нужно отдельное события для клика по кнопке, то мне совершенно непонятно зачем оно нужно. https://tronche.com/gui/x/xlib/events/keyboard-pointer/keyboard-pointer.html

Текст в классических тулкитах всегда передавался текстом а не картинкой. https://en.wikipedia.org/wiki/X_Font_Server

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

Спросим у него.

Как бы тогда задавалась логика? Если подразумеваются сообщения, то видимо их можно использовать. В PostScript серверах понятно, там аналог JavaScript в браузере, в иксы получается тоже пришлось бы какой то байткод добавлять?

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

Должны? А есть реальные примеры таких реализаций?

В том и проблема что нету. Венда не в счёт, хоть там это и сделано в win32, т.к. там монолит а не клиент-сервер.

Единственный такой пример, который приходит на ум, это как раз веб.

Веб это костыль на костыле и костылём погоняет. Он неинтерактивен в своей основе, интерактивность достигается опять же костылями.

Win32 контроллы реализованы на стороне приложения.

Там и примитивы на стороне приложения реализованы. Монолит же, там нет ни клиента ни сервера. Поэтому контролы рисует приложение. Хотя внутренняя механика сообщений хорошо ложится на клиент-серверную архитектуру.

Т.е. в win32 не сделано разделение на клиент-сервер, зато есть контролы которые составляют 99% графики в гуйне. А в иксах есть разделение на клиент-сервер но в протоколе не реализованы контролы.

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

А примитивами в иксах должен заниматься сервер, а не клиент.

Если реализовать эти виджеты-контролы в сервере, то куча проблем иксов просто перестанет существовать. Всякие Qt,Gtk и пр. знатно полегчают. Вдобавок полностью исчезнет проблема с разным внешним видом разных тулкитов, при том, что server-side виджеты-контролы можно будет кастомизировать как угодно ничего не меняя в тулкитах.

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

Дело же не только в этом. У каждого контролла собственная логика ивент лупа. С фрагментами вида «кнопка в нажатом состоянии, кнопка в отжатом состоянии», «таймаут и дельта координат для регистрации даблклика», «правка текста в буфере текстового поля ввода» и т.п.

Если брать базовые контроллы HTML, то там эту логику обрабатывает именно аналог «дисплейного сервера», то есть браузер. Если брать кастомные контроллы, сделанные при помощи HTML, то там этот ивент луп тоже выносится в скриптовый код на стороне браузера.

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

Если с первого раза не открылся – значит, прыжки с парашютом программирование на C не для вас!!!

Оставьте уже сишку в покое, извращенцы. Ну максимум синтаксис менее мусорный запилить без изменения логики.

А вот если бы кто то сделал средне-высокий язык, на котором можно легко писать высокоуровневые вещи, а под ним только железо…

Не получится. Железо ведь достаточно высокоуровневым не сделаешь.

Ну кстати сказать.

Винда это пример того, как имея негибкую архитектуру графической подсистемы, но при этом кучу бабла и желание не срать на прикладную совместимость, можно сделать весьма гибкую систему, в которой можно, например, гонять RDP эффективно по сети и при этом тащить эту совместимость со старыми API 30 лет.

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

Если реализовать эти виджеты-контролы в сервере, то куча проблем иксов просто перестанет существовать. Всякие Qt,Gtk и пр. знатно полегчают. Вдобавок полностью исчезнет проблема с разным внешним видом разных тулкитов, при том, что server-side виджеты-контролы можно будет кастомизировать как угодно ничего не меняя в тулкитах.

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

но сегодня точно известно какие именно контролы составляют 99% гуйни и фактически являются такими же примитивами

Видел GNOME4 приложения? Там виджеты которых я никогда не видел, что то с мобилок притащили.

Да, еще я забыл добавить к предыдущему. Винду очень сильно спасает COM.

Кажущаяся цельность системы виндовых контроллов это на самом деле множество разных COM-классов, каждый со своими особенностями и костылями, но ОС как целое может позволить их себе тащить.

А в Linux, извините, so-hell с конфликтами версий тулкита между собой.

Оно так и работает в случае с Motif, Xaw.

Нет. Картинки виджетов рисуются на стороне клиента мотифом или xaw. Просто приложению оные предоставляют интерфейс, похожий на интерфейс исков, а сами рисуют всё через Xlib.

В исках нет расширения протокола для виджетов.

Для простых виджетов и приложений это будет хорошо работать.

И это 90% гуйни.

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

Либо ты рисуешь картинку сам и шлёшь её серверу, либо делаешь доп. класс виджета для сервера. Разницы никакой на самом деле. При установке приложения ставится бинарник приложения и библиотечка с серверным виджетом. Если нужно работать удалённо, то на сервер надо будет поставить только библиотечку с виджетом.

Например приложение для работы с USB-осциллографом несомненно будет иметь виджет рисующий кривулины измеряемого сигнала. Один хрен этот виджет придётся писать самому. Ничего не мешает написать этот виджет как серверное расширение. Если клиент и сервер на одной машине, то вообще никакой разницы. Если осциллограф надо подключить где-то вдалеке, а морду иметь на компе в комнате управления, то на него надо установить только этот доп. виджет. При этом при обновлении пересылаться будет вовсе не картинка которая может занимать мегабайты и будет представлять собой фактически видеопоток, а всего лишь. скажем, тысяча значений кривулины, килобайта 4 если 16 бит разрешение. Даже при обновлении в 100 кривулин в секунду (что дохерищи для цифрового осциллографа, на самом деле), это будет ничтожный поток данных по сравнению с видео или даже RDP каким-нибудь.

Если нужно работать удалённо, то на сервер надо будет поставить только библиотечку с виджетом.

Б - безопасность.

И стабильность))

Винду очень сильно спасает COM.

COM это DBUS.

Кажущаяся цельность системы виндовых контроллов это на самом деле множество разных COM-классов

Нет, виндовый контрол это просто реализованный в библиотечке user32 (или comctl32/comdlg32) WindowProc который рисует контрол, шлёт сообщения и перерисовывает его при получении сообщений. Обслуживает, в общем. Сообщения любого контрола, системного или из comctl32 даже обрабатываются циклом обработки сообщений приложения а не системой.

А в Linux, извините, so-hell с конфликтами версий тулкита между собой.

Ну так перенос виджетов в сервер решит как минимум большую часть проблем с совместимостью разных версий тулкитов и что важнее с совместимостью разных тулкитов. Чем плохо когда кнопка или чекбокс вынлядят и ведут себя абсолютно одинаково в GTK, Qt, FLTK и даже Xaw/Motif, т.к. это севрер её рисует и обслуживает?

Со стабильностью иксов я уже давно проблем не наблюдаю. А насчёт безопасности - кто-то запрещает пустить иксовые соединения через шифрованный туннель? Хотя смысл этого от меня ускользает, обычно оборудование и контрль и так соединены отдельной сетью без внешнего доступа.

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

COM это DBUS.

И близко нет.

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

То есть «в теории да, а на самом деле нет». DBUS это грубо говоря только буквы, которыми можно описать технологию. А к COM эта технология прилагается в виде конкретного стека классов, готовых подсистем и практик программирования.

Нет, виндовый контрол это просто реализованный в библиотечке user32 (или comctl32/comdlg32) WindowProc который рисует контрол, шлёт сообщения и перерисовывает его при получении сообщений.

Это только самые старые их них. Потом всё на объектную модель было переведено. Если ты запустишь Win95 и посмотришь на тулбар в Проводнике, то значит ты смотришь на работу COM-объекта, а не на процедурный контролл.

GDI тоже была «проапгрейжена». (Если память не изменяет, во времена Хрюши.)

Т.е. rc на каждый указатель и жирные указатели. Тут все вспоминали Go. Но тут получается, что это скорее Swift 2. Не понятно только пока зачем это нужно.

Я про идею запускать код произвольной прикладной библиотеки на стороне дисплейного сервера.

Вспоминается IE и его ActiveX компоненты, гореть им в аду =)

Тут либо скриптовый код в песочнице, либо хана всему.

Чего только не придумают лишь бы D’s betterC не использовать

Наконец-то они решили придумать Оберон.

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

Ты описываешь не COM а OLE. Object Linking and Embedding. И это такой геморрой, на самом деле… Микрософт ломал OLE например охвиса с пугающей периодичностью. У меня есть как минимум два примера промышленных софтин (контроль цвета на линии - EsWin и ритейловый расчёт рецептур для лакокраски - ColorMatch), которые используют Excel через OLE, и которые требуют установки спецефической версии офвиса чтобы это OLE работало. Причём когда софтины обновляют, то у кучи клиентов всё перестаёт работать потому что нужно ставить новый офис.

COM и DBUS похожи вплоть до представления типов данных. Типа все эти SafeArrayCreateVector и SafeArrayAccessData в COM и dbus_message_iter_open_container и dbus_message_iter_append_basic в DBUS. Очень характерные параллели. Вообще DBUS писали вендузятники, на самом деле.

Это только самые старые их них.

Нет, это 99% того что ты видишь. Проводник это вообще просто ListView, слегка отсубклассенный. Если его кто-то через OLE таскает в свою прогу, то этот кто-то просто отмороженный.

GDI тоже была «проапгрейжена». (Если память не изменяет, во времена Хрюши.)

Примитивы, соответствующие вендовому GDI, как раз рисует сервер X11. С этим в иксах всё отлично и прозрачно в смысле сети. А вот в венде, чтобы работал RDP приходится перехватывать вызовы соответствующих функций GDI при помощи костылей, чтобы суметь послать по сети что там рисуют на экране.

Путь вейланда показывает, как оно нынче бывает. Сидит куча разных визионеров и мешает друг другу.

Ага, ещё и Иксы попутно выпиливают.

Бета-выпуск Red Hat Enterprise Linux 10 и релиз RHEL 9.5

Из поставки удалён X.org Server и связанные с ним компоненты (в примечании к тестовому выпуску об этом не упомянуто, но это изменение было в планах). Возможность запуска X11-приложений в сеансе Wayland обеспечивается при помощи DDX-сервера XWayland.

Я про идею запускать код произвольной прикладной библиотеки на стороне дисплейного сервера.

А в чём проблема? Оно уже давно не под рутом умеет работать. Никакой разницы с запуском любого юзерского кода.

Вспоминается IE и его ActiveX компоненты, гореть им в аду =)

Так ActiveX выполняли что-то приезжающее из сети, без всякого контроля.

А библиотека с server-side виджетами ничем не отличается от уже существующих модулей X11 extensions.

Тут либо скриптовый код в песочнице, либо хана всему.

У тебя очень странные представления о том, как всё работает.

очередная таблетка от всех болезней?…и сколько их упало в эту бездну…

C рулит и никакой TrapC не нужен! Просто нужны прямые руки, плюс надо юзать инструменты проверки кода.

Хорошим тоном везде и всегда является, например, сразу поставить обе скобки или кавычки, а потом вписывать то, что должно быть между ними. Вот и с malloc() и free() аналогично. Если сразу вписать free(), то про него и не забудешь. А некоторые, видимо, вписывают malloc(), потом отвлекаются на другое, а про free() уже и не вспоминают. А потом, конечно, память утекает...

Ну ладно, не все так плохо. У явы есть ВМ, тут ВМ нет. Как я понял тут просто эдакий внешне вроде С, но под капотом что то плюсоподобное с защитой памяти и пр.свистелками.

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

Ты давно на экскурсии по исходникам ядра Линукса был? Ну так сходи, избавься от иллюзий :)

Ничего непонятно но очень интересно! Особенно интересно почему размерность массивов целая, а не дробная фрактальная по хаусдорфу, для динамического программирования (ничего что я его с маленькой буквы пишу?) это более естественный подход.

И это такой геморрой, на самом деле…

Давай сначала мне покажут пример, как запустить в рамках одного приложения компоненты, которые хотят gtk разных версий, а потом уже будем выяснять, какой геморрой в OLE. =)

Вообще DBUS писали вендузятники, на самом деле.

DBUS делали очень специальные люди, которые придумали «сетевую технологию», прибитую гвоздями к локалхосту.

Единственное, на что она сгодилась на практике — межсервисное IPC уровня «пользователь вставил флешку».

В отличие от этого, COM исходно решал совсем другую проблему. И он её решил. Винда имеет унифицированный механизм линковки и исполнения двоичных модулей, отвязанный от рантаймов конкретных ЯП, тулкитов и фреймфорков. А прикладной стек Линукса — не имеет.

Нет, это 99% того что ты видишь.

99% того, что я обычно вижу в винде по рабочим делам, это либо Проводник, построенный на архитектуре COM, либо MS Office, построенный на архитектуре COM, либо браузер, использующий свой собственный тулкит.

Проводник это вообще просто ListView, слегка отсубклассенный.

Предлагаю таки почитать какую-нибудь матчасть.

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

Это лишь демонстрирует, что при желании и наличии бабла можно и через жопу сделать хорошо. А можно 10 лет делать вейланд…

Ну ладно, не все так плохо. У явы есть ВМ, тут ВМ нет.

Я утрировал, но не сильно. С учётом JIT-компиляции, производительность в горячих точках программы может оказаться сопоставимой, если она касается перекладывания байтов по массивам и разыменования указателей. Потому что количество условных переходов окажется сопоставимым.

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

А если данная фича не нужна, то что мешало сразу взять более выразительный и безопасный ЯП?