The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для ядра Linux предложен драйвер GPIO, написанный на Rust, opennews (ok), 20-Июл-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


43. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +4 +/
Сообщение от Dzen Python (ok), 20-Июл-21, 16:55 
Как в машинке "Вятка-Автомат". Жизнь-то закрутится, завертится.
Ответить | Правка | Наверх | Cообщить модератору

60. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +11 +/
Сообщение от _hide_ (ok), 20-Июл-21, 17:17 
А чем растовый вариант драйвера лучше сишного? Без стёба?
Ответить | Правка | Наверх | Cообщить модератору

72. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +8 +/
Сообщение от Аноним (-), 20-Июл-21, 17:26 
> А чем растовый вариант драйвера лучше сишного? Без стёба?

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

Ответить | Правка | Наверх | Cообщить модератору

245. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Михаил (??), 21-Июл-21, 08:33 
Из основного я заметил использование правил ownership (проверяемых на этапе компиляции) при использовании lock-ов.
Что невозможно ни в C ни в С++.
Ответить | Правка | Наверх | Cообщить модератору

247. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –4 +/
Сообщение от Michael Shigorinemail (ok), 21-Июл-21, 09:05 
> Что невозможно ни в C ни в С++.

Вам знаком термин "машина Тьюринга"?
Вы пытались посмотреть, на чём написан транслятор Rust?..
(изучали ли в школе или вообще логику -- не спрашиваю)

Ответить | Правка | Наверх | Cообщить модератору

281. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Аноним (-), 21-Июл-21, 13:36 
>> Что невозможно ни в C ни в С++.
> Вам знаком термин "машина Тьюринга"?
> Вы пытались посмотреть, на чём написан транслятор Rust?..

И? Без ограничения семантики - будет вам задача из области NP-hard (самое то для сферическо-вакуумной недетерминированной машины Тьюринга).
Вменяемое время проверки - именно то, во что все еще упираются ЯП с попытками формальной верификации и "глубоких" проверок.

Ответить | Правка | Наверх | Cообщить модератору

307. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –2 +/
Сообщение от BorichL (ok), 21-Июл-21, 15:33 
Михаил, вы такими вопросами разрушаете радужный мир розовых пони растоманов! Они привыкли, что за них Гниль думает, самим нынче думать не в моде, некогда...
Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

389. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от yet another anonymous (?), 22-Июл-21, 23:29 
Не, не разрушает. Тьюринг свою машину возле них не парковал.
Ответить | Правка | Наверх | Cообщить модератору

425. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (425), 25-Июл-21, 22:00 
Вам знаком термин сложность алгоритма? Вы пытались написать проверку во всех местах, где это делает Rust-компилятор? Изучали ли в университете дискретную математику или вообще математику - не спрашиваю)
Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

427. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (427), 02-Авг-21, 23:08 
> Вам знаком термин "машина Тьюринга"?

Хм, но ведь и CSS считается Тьюринг-полным языком, однако никтопочему-то там не пытается накостылять ownership.

Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

76. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +4 +/
Сообщение от Аноним (76), 20-Июл-21, 17:28 
Тем что большее количество UB отловлено на этапе компиляции. У кода появляются формальные гарантии
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

135. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +2 +/
Сообщение от _hide_ (ok), 20-Июл-21, 20:18 
Вы вообще пример драйвера на смотрели?
Ответить | Правка | Наверх | Cообщить модератору

93. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Dzen Python (ok), 20-Июл-21, 17:49 
Если говорить серьезно - ничем.

За кодера прошел borrow checker, спаянный со парой слизанных из статических анализаторов фич, засунутых зачем-то в конпелятор. После чего бывший js-макак, он же гуру реакта, повелитель вуе, а ныне - разраб на русте, над которым завис красномордый дядька-начальник и под угрозой увольнения заставил напилить код, расправил крылья и ходит с лыбой от уха до уха, что теперь "супир бишапашно".

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

Ах, да, забыл. Руст же полностью исключает dll hell^W^W UB. Запомните, дети, UB, это такие казуистические случаи, вроде

    j = i++ + ++i;

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

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

136. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –4 +/
Сообщение от Ananimasss (?), 20-Июл-21, 20:34 
Простите экс вебмакаку, но что казуистического в примере?
Прибавится единичка к  i до сложения, выполнится сложение и запишется в j, после прибавится 1 к i.
Где-то это не так?
Ответить | Правка | Наверх | Cообщить модератору

158. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –6 +/
Сообщение от ананим.orig (?), 20-Июл-21, 21:24 
> Прибавится единичка к  i до сложения, выполнится сложение и запишется в j, после прибавится 1 к i.

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

Ответить | Правка | Наверх | Cообщить модератору

191. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +2 +/
Сообщение от Урри (ok), 20-Июл-21, 23:08 
Два неуча.

В С не регламентирован порядок вычисления большинства операндов выражений (за исключением && и ||). Поэтому выражение i++ + ++i может быть вычислено как слева направо, так и справа налево, так еще и результат i++ может быть записан в i после вычисления всего выражения.

Аналогичная беда с выражением func(i++, i++);

Ответить | Правка | Наверх | Cообщить модератору

200. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Anonymoustus (ok), 20-Июл-21, 23:21 
На PDP тоже так было, великий гуру?
Ответить | Правка | Наверх | Cообщить модератору

328. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Урри (ok), 21-Июл-21, 17:37 
> На PDP тоже так было, великий гуру?

Да. Например, можно глянуть http://mim.update.uu.se/manuals/layered/pdp11c3.pdf (PDP-11 C Guide to PDP-11 C)

Цитирую:
When using the increment and decrement operators, do not
depend on the order of evaluation of expressions. Consider
the following ambiguous expression:
k = x[j] + j++;

Is the value of variable j in x[j] evaluated before or after the
increment occurs? Do not assume which expressions the
compiler will evaluate first. To avoid ambiguity, increment
the variable in a separate statement.

Ответить | Правка | Наверх | Cообщить модератору

343. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Anonymoustus (ok), 21-Июл-21, 22:11 
>> На PDP тоже так было, великий гуру?
> Да. Например, можно глянуть http://mim.update.uu.se/manuals/layered/pdp11c3.pdf (PDP-11
> C Guide to PDP-11 C)
> Цитирую:

Убедил.

Ответить | Правка | Наверх | Cообщить модератору

357. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 22-Июл-21, 03:25 
Откуда ж вы лезете, знатоки C++ по учебникам C лохматых 90-х?
Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

372. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от adolfus (ok), 22-Июл-21, 13:20 
А причем тут C++? Речь идет о C, который очень жестко стандартизован и, кстати, именно в 90-х, вернее, в 1998. Просто почитайте стандарт ISO/IEC 9899 и сравните с "учебниками лохматых 90-х". Ну и последний 2011-го года гляньте. А потом сравните с ISO/IEC 14882 -- откроете много удивительного.
Ответить | Правка | Наверх | Cообщить модератору

280. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Аноним (280), 21-Июл-21, 13:28 
Для ядра важно, как это делает конкретно gcc.
Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

319. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 21-Июл-21, 16:37 
Для неуча:

https://ru.wikipedia.org/wiki/%D0%A2%D0%...

Проблема в значительной мере устарела.

Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

329. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Урри (ok), 21-Июл-21, 17:41 
> Для неуча:

Иногда лучше молчать и слыть болваном, чем заговорить и развеять все сомнения. (с)
Ты сам свою ссылку то читал? Там ровно то, что написал я.

> Проблема в значительной мере устарела.

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

Вообще ничего не изменилось за 30 лет, прикинь?

Ответить | Правка | Наверх | Cообщить модератору

344. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 22-Июл-21, 00:05 
Полистай: https://en.cppreference.com/w/cpp/language/eval_order
Текст ты вряд ли поймешь, но комментарии к примерам типа:

i = i++ + 2; // undefined behavior until C++17

возможно, заставят заподозрить, что в C++17 что-то изменилось.

Ответить | Правка | Наверх | Cообщить модератору

345. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 22-Июл-21, 00:23 
А в целом, придирка к неопределенному порядку вычислений выражений сама по себе дурацкая донельзя: порядок вычислений не фиксировали в стандарте не потому, что нешмагли, а для того, чтобы не наступать на горло оптимизирующему компилятору, который может сгенерировать более эффективный код, изменив порядок вычислений.
Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

361. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от freecoder (?), 22-Июл-21, 08:10 
Ага, в этом автомобиле нет ремней безопасности да и вообще нет кресел не потому, что "не шмогли", а потому, что лишний вес мешает разгоняться.
Ответить | Правка | Наверх | Cообщить модератору

363. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Совершенно другой аноним (?), 22-Июл-21, 09:15 
Вы, как мне кажется, забываете контекст, в каких условиях создавался и стандартизировался C, а в каких - Rust. То, что там машины были на порядки медленее, это пол беды, а то, что в комитет входили разные корпорации, производящие аппаратное обеспечение, которые тянули в свою сторону - это совсем беда. Думаю поэтому в стандарте C куча UB, которые кажутся странными - зартачилась какая-нибудь Sun, или там DEC - вот у нас в процессоре это сделано не так, как у всех остальных, давайте сделаем это UB, чтобы мы там по месту сами разбирались, как это делать. Тем более, что тогда в C, не так как сейчас в Rust - куча аппаратных контор писала свои компиляторы для C для своих аппаратных архитектур.
Ответить | Правка | Наверх | Cообщить модератору

373. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 22-Июл-21, 13:47 
Дело даже не в древних архитектурах, как раз наоборот. Простой пример: вполне можно представить себе гипотетическую ситуацию, когда компилятор, обнаружив, что вычисление аргументов функции не требует синхронизации, на современном многоядерном процессоре запустит оное в параллельных потоках по числу аргументов. Порядок вычисления не определен в принципе? Да. Это ускорит выполнение? Да. Противоречит это стандарту? Нет, всё в порядке. Если вспомнить про транспьютерные архитектуры, то там это тем более актуально.
Ответить | Правка | К родителю #361 | Наверх | Cообщить модератору

397. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от n00by (ok), 23-Июл-21, 06:57 
> Дело даже не в древних архитектурах, как раз наоборот. Простой пример: вполне
> можно представить себе гипотетическую ситуацию, когда компилятор, обнаружив, что вычисление
> аргументов функции не требует синхронизации, на современном многоядерном процессоре запустит
> оное в параллельных потоках по числу аргументов.

И у этих параллельных потоков будет общий стек. Ага. Представил. =)

Ответить | Правка | Наверх | Cообщить модератору

197. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Anonymoustus (ok), 20-Июл-21, 23:20 
Как там у вас?


let a = 1
undefined


Так?

Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

362. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от freecoder (?), 22-Июл-21, 08:11 
Нет, не так. Что спросить-то хотел?
Ответить | Правка | Наверх | Cообщить модератору

194. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от None (??), 20-Июл-21, 23:18 
Когда мы видим одну операцию присваивания, а реально их три - да, фигня получается.
Зато удобно автоинкрементную/автодекрементную индексацию как бы описывать.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

226. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Аноним (226), 21-Июл-21, 02:40 
> j = i++ + ++i;

Если i было равно 1 до начала этой операции, то по-моему после нее будет i = 3 и j = 4
Постинкремент самая приоритетная операция за ней прединкремент, потом сложение, потом присвоение. Операция сложения работает слева направо, но выражение разбирается справа налево.

Прединкремент сработает первым, поэтому i станет сразу равным двум. Потом сработает постинкремент и вернет 2. За ним сложение 2+2=4. Потомпосле завершения присвоения результата в j постинкремент увеличит i на 1. Я где-то ошибаюсь?

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

330. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Урри (ok), 21-Июл-21, 17:45 
> Я где-то ошибаюсь?

Везде в своем комментарии.

Немножечко лонгрид, но весь по делу, без воды и с цитатами стандарта (а еще и на русском) - https://habr.com/ru/post/216189/

Ответить | Правка | Наверх | Cообщить модератору

235. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от px (??), 21-Июл-21, 04:59 
Вы, батенька, чушь сморозили. UB — это и вполне тривиальное ```int a[] = {1,2}; int b = a[2]``` и вообще до черта всего, особенно в многопоточном коде. Про статические анализаторы, то же ерунда какая-то получилась: статические анализаторы по-разным эвристикам пытаются угадать очепятки, в то время как rust имеет систему типов, которая даёт вполне определённые гарантии, без всяких вероятностных допущений (конечно опуская вероятность ошибок в самом компиляторе). Unsafe, хоть и является вынужденным злом, но позволяет локализировать наиболее опасные места, а не размазывать их по всему коду. В реальном коде unsafe используется достаточно редко. Возможно, вам было бы комфортнее комментировать что-то, в чём вы разбираетесь. Но на всякий случай, вы можете почитать https://en.wikipedia.org/wiki/Undefined_behavior — в английской версии статьи есть много менее «казуистических» примеров неопределённого поведения. Спасибо за внимание.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

246. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Совершенно другой аноним (?), 21-Июл-21, 09:02 
> В реальном коде unsafe используется достаточно редко.

Есть какая-нибудь статистика? а то походив по некоторым проектам крейтов Rust на github, увидел, что unsafe-ов используется довольно много, и даже начало складываться впечатление, что сделать что-либо нетривиальное без unsafe не очень получается.

Ответить | Правка | Наверх | Cообщить модератору

364. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Anonimus (??), 22-Июл-21, 09:17 
```int a[] = {1,2}; int b = a[2]```

Умышленно выходить за пределы выделенного массива. В чем смысл такого "тривиального" кода?

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

404. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от px (??), 23-Июл-21, 22:11 
Можно выходить и неумышленно, к примеру аллоцировав буфер, и взяв смещение в нём из какого-нибудь заголовка кого-нибудь пакета не проверив...
Ответить | Правка | Наверх | Cообщить модератору

379. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Кир (?), 22-Июл-21, 14:39 
Для начала, при попытке скомпилировать


int a[] = {1,2}; int b = a[2];

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

Во-вторых, на актуальном C++ такое пишется так:


array a = {1, 2}; auto b = a.at(2);

и приводит к выбросу исключения с внятным сообщением о причине ошибки. Не уверен -- не обгоняй ;)

Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

109. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +4 +/
Сообщение от Ordu (ok), 20-Июл-21, 18:25 
Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядре, нежели тот первый пример модуля, который ничего полезного не делал.

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

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

134. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от _hide_ (ok), 20-Июл-21, 20:17 
Да, но это же не показательный вариант. Никаких фишек раста не использовано. Давайте ещё на паскале, го, свифте и чистом llvm asm будем модули писать и выставлять их? Причем на первых 3х это уже давно делают.
Ответить | Правка | Наверх | Cообщить модератору

138. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Линус (?), 20-Июл-21, 20:39 
Сделай.
Ответить | Правка | Наверх | Cообщить модератору

181. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +2 +/
Сообщение от Аноним (181), 20-Июл-21, 22:48 
> Причем на первых 3х это уже давно делают.
> ...уже давно делают...
Ответить | Правка | Наверх | Cообщить модератору

153. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Ordu (ok), 20-Июл-21, 21:12 
> Да, но это же не показательный вариант. Никаких фишек раста не использовано.

Это что за фишки такие?

#[derive(Default)] -- это не такая фишка?

А Ref<T>, для работы с ref_count -- это не такая фишка? Между прочим в списке рассылки трындец обсуждение, ядрёным C программистам объясняют, как это может работать. Ты, кстати, тоже можешь почитать просветиться. Вопросы к коду задают серьёзные люди, а не анонимы опеннета, и отвечают серьёзно, а не как я тут.

impl amba::Driver for PL061Device
...
impl power::Operations for PL061Device
...
module_amba_driver! {
    type: PL061Device,
    name: b"pl061_gpio",
    author: b"Wedson Almeida Filho",
    license: b"GPL v2",
}

Это не те фишки раста, которые ты ищешь? Если нет, то каких фишек ты ждёшь от раста? Чтобы он скомпилировал код вида "please, rustc, compile this line into a real kernel driver"?

> Давайте ещё на паскале, го, свифте и чистом llvm asm будем
> модули писать и выставлять их? Причем на первых 3х это уже
> давно делают.

Пиши, тебе что кто-то запрещает?

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

201. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –5 +/
Сообщение от Урри (ok), 20-Июл-21, 23:24 
Ух ты, в расте, оказывается, есть ref_count, который в С существует... дайте вспомнить сколько... да уже лет 30, наверное. Если не больше.

Одна из библиотек, которые я давно использую:
https://github.com/Snaipe/libcsptr

Наслаждайся:

struct log_file *open_log(const char *path) {
    smart struct log_file *log = shared_ptr(struct log_file, {0}, close_log);
    if (!log) // failure to allocate
        return NULL; // nothing happens, destructor is not called

    log->fd = open(path, O_WRONLY | O_APPEND | O_CREAT, 0644);
    if (log->fd == -1) // failure to open
        return NULL; // log gets destroyed, file descriptor is not closed since fd == -1.

    return sref(log); // a new reference on log is returned, it does not get destoyed
}

int main(void) {
    smart struct log_file *log = open_log("/dev/null");
    // ...
    return 0; // file descriptor is closed, log is freed
}


---
они изобрели смарт-поинтеры, ухахахахахахахах.

Ответить | Правка | Наверх | Cообщить модератору

209. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Ordu (ok), 20-Июл-21, 23:44 
> Ух ты, в расте, оказывается, есть ref_count, который в С существует... дайте
> вспомнить сколько... да уже лет 30, наверное. Если не больше.

ref_count существовал до всех этих ваших C, не надо его недооценивать.

> Одна из библиотек, которые я давно использую:
> https://github.com/Snaipe/libcsptr

И чё?

> они изобрели смарт-поинтеры, ухахахахахахахах.

Демонический смех у тебя ничё так выходит, мне понравилось. Я б рекомендовал басов немного добавить, хотя в районе 3кГц очень неплохое присутствие. Но, и всё же, мне неясно, каким таким образом тебе удалось придти к выводу об изобретении смарт-поинтеров разработчиками rust?

Ответить | Правка | Наверх | Cообщить модератору

332. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Урри (ok), 21-Июл-21, 17:53 
> ref_count существовал до всех этих ваших C, не надо его недооценивать.

Само собой существовал, еще в лиспе, например. А кто его недооценивает?

>> они изобрели смарт-поинтеры, ухахахахахахахах.
> и всё же, мне неясно, каким таким образом тебе удалось придти
> к выводу об изобретении смарт-поинтеров разработчиками rust?

Цитирую тебя же:

>> Никаких фишек раста не использовано.

Ordu: > А Ref<T>, для работы с ref_count -- это не такая фишка?

Уникальная фишка раста - смарт поинтер, который минимум как 30 лет есть в С, который раст пытается заменить.

Ответить | Правка | Наверх | Cообщить модератору

338. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Ordu (ok), 21-Июл-21, 18:35 
> Цитирую тебя же:
>>> Никаких фишек раста не использовано.
> Ordu: > А Ref<T>, для работы с ref_count -- это не такая
> фишка?

Ты тред читал? Человек выше задаёт вопрос, почему никаких фишек раста не использовано. Я задаю ему вопросы о том, что он подразумевает под фишками раста. Привожу потенциальные примеры, которые могут быть примерами фишек раста, спрашиваю каких других фишек раста он ждал.

Не надо выдирать цитаты из контекста. Если ты знаешь каких фишек раста не хватает в том драйвере -- я с интересом тебя выслушаю. Доказывать же мне, что Ref<T> -- это фишка раста, или что это не фишка раста бессмысленно. Не, то есть, я б выслушал твоё мнение, потому что ты меня заинтриговал реально, я не могу понять считаешь ли ты Ref<T> фишкой раста, или ты считаешь его заурядностью из середины XX века, которая настолько общее место, что не стоит упоминания. Или может ещё что?

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

Если же тебе интересно моё мнение, то сводить раст к фишкам -- плюс-минус бессмысленное занятие. Раст -- это комплексное решение, и любая фишка по отдельности не заслуживает внимания, интересно как они переплетаются во единое целое в коде.

Ответить | Правка | Наверх | Cообщить модератору

239. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –2 +/
Сообщение от Аноним (239), 21-Июл-21, 07:28 
>который в С существует...

"To compile the library, GCC 4.6+ is needed."

Ох уж эти сказочки, ох уж эти сказочники ...

Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

331. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от Урри (ok), 21-Июл-21, 17:49 
>>который в С существует...
> "To compile the library, GCC 4.6+ is needed."
> Ох уж эти сказочки, ох уж эти сказочники ...

Растоманчик не видит разницу между конкретной сторонней библиотекой и всеми другими реализациями?

Впрочем, ничего удивительного. Не ты ли плакался там выше, что что не включено в STL, то у него не получается в с++ использовать?

Я писал, что конкретно эту библиотеку сейчас использую, и использую уже давно. Gcc 4.6 уже больше 10 лет.

Ответить | Правка | Наверх | Cообщить модератору

341. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (239), 21-Июл-21, 20:57 
>Растоманчик не видит разницу между конкретной сторонней библиотекой и всеми другими реализациями?

Растоманчик видит разницу между С и GCC c кучей расширений, и даже деструкторами.

>Впрочем, ничего удивительного

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

Зато так смело клеймит оппонентов, переходит на личности.

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

Ответить | Правка | Наверх | Cообщить модератору

308. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от нах.. (?), 21-Июл-21, 15:39 
module_amba_driver! {
    type: PL061Device,
    name: b"pl061_gpio",
    author: b"Wedson Almeida Filho",
    license: b"GPL v2",
}

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

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

333. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –2 +/
Сообщение от Урри (ok), 21-Июл-21, 17:59 
>     name: b"pl061_gpio",
> Тоесть вот это это типа очень удобно и понятно? Ну ладно, яссно
> с вами ржавыми, как язык назовеш так и поплывет... или утонет.

Подожди, у них же аджайл, они щас еще такого наворотят...

Тут недавно добавили возможность идентификаторы писать в юникоде (боже, как я ржал, как я ржал... - эта "фишка" даже в боже прости 1С почти 20 лет назад была, чуть не в каждом языке есть - но растаманчики наконец подвезли и себе такую важную мегавозможность).

Так через два месяца они добавят специальный префикс _ для идентификаторов, которые в юникоде, но надо читать не в юникоде. И _& для тех, что в юникоде, но читаются не в юникоде, а надо в расширенном юникоде. А потом и letmut &hui __go__ для тех, которые в юникоде, но надо бы изменить для совместимости с С, который вызывать через ансейф и через два месяца вместо hui утвердят jui.

В общем все как всегда, плана нет, целостного видения нет, заплатка на заплатке и технический долг все похоронит.

Ответить | Правка | Наверх | Cообщить модератору

144. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Аноним (144), 20-Июл-21, 20:55 
>Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядре

Осталось только написать остальные более реалистичные примеры: работу с VFS на примере реализации ФС, работу с потоками, сетью, памятью и т.д.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

147. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +/
Сообщение от Ordu (ok), 20-Июл-21, 21:05 
>>Он сделан не для того, чтобы быть лучше. Он создан для того, чтобы посмотреть на более реалистичный пример rust'а в ядре
> Осталось только написать остальные более реалистичные примеры: работу с VFS на примере
> реализации ФС, работу с потоками, сетью, памятью и т.д.

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

Ответить | Правка | Наверх | Cообщить модератору

182. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –3 +/
Сообщение от Аноним (181), 20-Июл-21, 22:50 
Растаманы пытались всё это сделать, но редох начал течь... Поэтому переключились на линух.
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

199. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  –1 +/
Сообщение от None (??), 20-Июл-21, 23:21 
redox течёт? Ахаха, вот и цена этому продукту. Только вот уже несколько языков (D и nim точно) зашкварились, начав тащить к себе эту дрянь - "концепцию владения".
Ответить | Правка | Наверх | Cообщить модератору

206. "Для ядра Linux предложен драйвер GPIO, написанный на Rust"  +1 +/
Сообщение от Аноним (-), 20-Июл-21, 23:31 
> redox течёт?

Нет, в оригинале 4 года назад было:
> The Redox kernel does not have the structures in place to allow freeing memory.
> The userspace allocator can free, and then reuse, but anything allocated with sbrk from the kernel will be lost.

просто местные экспертусы - не умеют в разработку и/или английский ...

> Ахаха, вот и цена мнению местных экспертусов

пофиксил.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру