Состоялся (https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html) релиз языка системного программирования Rust 1.30 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).
В подготовке нового выпуска приняли участие 178 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...):
- Добавлена поддержка двух новых видов процедурных макросов (https://doc.rust-lang.org/book/procedural-macros.html): макросы похожие на атрибуты и макросы похожие на функции. Атрибутоподобные макросы напоминают ранее доступные произвольные макросы на базе механизма "derive", но кроме генерации кода только для атрибута "#[derive]" позволяют создавать собственные произвольные атрибуты, а также не ограничены работой только со структурами и перечислениями (enums). Макросы похожие на функции дают возможность определить макрос в форме вызова функции (например, "let sql = sql!(SELECT * FROM posts WHERE id=1);").- Добавлена (https://github.com/rust-lang/rust/pull/50911/) возможность выноса макроса в текущую область видимости (scope) по аналогии функциями при помощи ключевого слова "use", без использования специальной аннотации "#[macro_use]";
- Стабилизирован пакет (crate) proc_macro, предоставляющий API для упрощения создания макросов. В proc_macro также значительно расширен API для обработки ошибок, который уже задействован в пакетах подобных syn и quote;
- Началась работа по упрощению системы создания модулей. Добавлена возможность использования ключевого слова "crate" в пути для отсылки к корню иерархии модулей, например, "crate::foo" ссылается на модуль "foo", размещённый в "src/lib.rs". При использовании внешних пакетов отныне не требуется указание префикса "::", например, вместо "json = ::serde_json::from_str(foo);" теперь можно писать "let json = serde_json::from_str(foo);". Логика разбора пути "a::b::c" выглядит следующим образом: если "a" является именем пакета, то в этом пакете осуществляется поиск "b::c"; если в "a" указано ключевое слово "crate", то поиск "b::c" осуществляется относительно корня иерархии модулей; иначе
"a::b::c" извлекается из текущей позиции в иерархии модулей;- Добавлена возможность использования ключевых слов в качестве идентификаторов. Например, для создания локальной переменной с именем "for" можно указать "let r#for = true;", а для создания функции с именем "for" - "fn r#for() {". При вызове подобной функции следует использовать признак raw-идентификатора - "r#for();";
- Добавлен атрибут "#[panic_handler]", предоставляющий возможность определения функции для обработки сбоев (panic) в Rust runtime. Подобное может оказаться полезным для сборки приложения без стандартной библиотеки, используя режим no_std;
- Реализована возможность определения в макросах видимости ключевых слов, таких как "pub", используя спецификатор "vis";
- Стабилизированы атрибуты для инструментов Rust (https://github.com/rust-lang/rust/pull/53459/), таких как rustfmt и clippy. Например, "#[rustfmt::skip]" может применяться отключения форматирования следующего элемента;
- В разряд стабильных переведена новая порция API, в том числе
Ipv4Addr::{BROADCAST, LOCALHOST, UNSPECIFIED}, Ipv6Addr::{BROADCAST, LOCALHOST, UNSPECIFIED}, Iterator::find_map;
- Из-за неверной трактовки в функциях "trim_*" понятий "лево" и "право" для RTL-языков, данные функции переименованы: trim_left в trim_start, trim_right в trim_end, trim_left_matches в trim_start_matches, trim_right_matches в trim_end_matches;
- В пакетный менеджер Cargo добавлен индикатор прогресса выполнения операций.
URL: https://blog.rust-lang.org/2018/10/25/Rust-1.30.0.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=49503
>Добавлена возможность использования ключевых слов в качестве идентификаторов. Например, для создания локальной переменной с именем "for" можно указать "let r#for = true;", а для создания функции с именем "for" - "fn r#for()А я думал ХРУСТ сильнее испохабить уже невозможно, ан нет.
Они начали на полном серьезе воспроизводить мемы времен младенчества языков программирования, когда можно было писать:
IF = TRUE
define THEN goto X:
define ELSE goto Y:IF IF THEN THEN ELSE ELSE
У вас FFI с библиотекой, имя символа в которой такое же, как какое-то ключевое слово в языке, что будете делать?
>У вас FFI с библиотекой, имя символа в которой такое же, как какое-то ключевое слово в языке, что будете делать?- Мама, что такое Name mangling???
Name mangling? В си? Да вы эстет!
Причём здесь манглинг, дебик. Как ты напишешь в принципе в языке Функцию или любой другой символ, чьё имя есть ключевое слово? Никак. Напиши в сях переменную с именем register.
>Из-за неверной трактовки в функциях "trim_*" понятий "лево" и "право"Как можно неверно трактовать понятие "Лево"??? Разработчки языка страдают аутизмом?
>данные функции переименованы: trim_left в trim_startФЕЙСПАЛМ. Вместо того что бы ДОБАВИТЬ функции trim_start и trim_end они их ПЕРЕИМЕНОВАЛИ. А если мне нужно обрезать строку имменно слева, вне зависимости от содержания, например для сериализации, что мне использовать?
Ответ прост. Нужно использовать язык программирования разработанный не 15летними аутистами.
Скорее всего это про языки с письмом справа налево
У Арабов ЛЕВО это не ЛЕВО?
А если человек двуязычный?
Как только он начинает писать по Арабски у него руки меняются местами?А что по поводу языков с письмом сверху вниз? Руки с ногами меняются?
Разгадка то проста. Программисты мозиллы жопоруки, но тупы. Или тупы но жопоруки, в зависимотси от того что у них сейчас ЛЕВО.
> Разгадка то проста. Программисты мозиллы жопоруки, но тупы. Или тупы но жопоруки,И только анонимы опеннета в шляпах, плащах и со шпагами …
Причем, каждый второй аноним - правая рука Линуса (или левая рука Горшечника), каждый третий - тайный консультант и вдохновитель Кнута и Шнайера.
>Из-за неверной трактовки в функциях "trim_*" понятий "лево"Я знаю где лево. Это делает меня умнее всех программистов мозиллы.
А вам есть чем похвастаться?
>>Из-за неверной трактовки в функциях "trim_*" понятий "лево"
> Я знаю где лево.И? Вместо простых и понятных "start/end" будем продолжать использовать зависящих от отобажения/языка left/right? Т.е. встроим в trim_left и trim_right еще и распозновалку выводимого языка, до кучи.
> Это делает меня умнее всех программистов мозиллы.Нет, всезнание и всеумение делает анонима опеннета анонимом опеннета.
> А вам есть чем похвастаться?
А я сумел в английский:
> For (readers/users of) RTL languages, trim_right is hinting that it will be
> trimming the prefix, but this is of course not the case (and similarly for
> _left).
>зависящих от отобажения/языка left/right?Вы в мозилле работаете?
ЛЕВО и ПРАВО от языка не зависят!
А вот start/end от языка зависят.
Вы путаете не только лево и право, но и причину со следствием и зад и перед.
>Нет, всезнание и всеумение делает анонима опеннета анонимом опеннета.
>Анонимный пользователь 4chan решил задачу, над которой математики думали 25 летИ так бывает. Анонимы сила!
>А я сумел в английский:То что вы смогли прочитать их кривую отмазку не делает ее менее кривой.
> RTL languages, trim_right is hinting that it will be
> trimming the prefixLOLNO.
Контр пример:
Вы генерируете сессию пользователя.
Вам нужно добавить к имени пользователя соль и захешировать.
Вы тримите имя пользователя справа, а "умный" раст вдруг распознал LTR язык и тримит слева.
В итоге в результирующей строке куча пробелов и энтропия около нуля
Подбор в течении дней, а не ста тысяч лет.Такая ошибка была в фейсбуке с сесиями - https://www.youtube.com/watch?v=O5xRRF5GfQs
>>зависящих от отобажения/языка left/right?
> Вы в мозилле работаете?
> ЛЕВО и ПРАВО от языка не зависят!Для анонимов поясняю: лево/право в отображаемом выводе и представление байтиков в памяти это две большие разницы.
Поэтому, для _корректного_ выполнения trim_left/right нужна дополнительная распозновалка, так как в зависимости от отображения резать придется или с конца или с начала. Ну или можно громко и пафосно объявить, что trim относится к общепринятой репрезентации строки в памяти, поэтому trimleft режет всегда с начала.> А вот start/end от языка зависят.
> Вы путаете не только лево и право, но и причину со следствием
> и зад и перед.Ага, ага. "Вся рота идет не в ногу. Один подпоручик в ногу!"
В общем -- сам придумал, сам оспорил, сам победил и сам доволен … даже немного завидно.>>Нет, всезнание и всеумение делает анонима опеннета анонимом опеннета.
>>Анонимный пользователь 4chan решил задачу, над которой математики думали 25 лет
> И так бывает. Анонимы сила!Особенно мощно и сильно у опеннетовски анонимов ЧСВ.
>> RTL languages, trim_right is hinting that it will be
>> trimming the prefix
> LOLNO.
> Контр пример:
> Вы генерируете сессию пользователя.
> Вам нужно добавить к имени пользователя соль и захешировать.
> Вы тримите имя пользователя справа, а "умный" раст вдруг распознал LTR язык
> и тримит слева.
> В итоге в результирующей строке куча пробелов и энтропия около нуля
> Подбор в течении дней, а не ста тысяч лет.Т.е. вы или не поняли, о чем речь или сознательно опять что-то притянули за уши, чтобы тут же, гордо, опровергнуть?
>Для анонимов поясняю: лево/право в отображаемом выводе и представление байтиков в памяти это две большие разницы.
>Поэтому, для _корректного_ выполнения trim_left/right нужна дополнительная распозновалка, так как в зависимости от отображения резать придется или с конца или с начала.Нет не нужна. Вася ты понимаешь что строка мажет содержать и арабский и ASCII и японский традиционный одновременно? Что ты будешь резать в ней?
" معايير الويب World! " например.trim_left должен резать СЛЕВА(Ака со стороны старших байтов/Code point). Как делает большинство стандартных библиотек.
А вот если нужно корректная работа с UTF-8, то этим должна заниматься выделенная, подключенная библиотека.
Которая проведет токинизацию, нормирование, разбитие на значимые области и тд.
Который ты передашь в параметрах, что, откуда и куда тебе резать надо, и как поступать в проблемных случаях.
Тащить в стандартную библиотеку это не нужно.
> Нет не нужна. Вася ты понимаешь что строка мажет содержать и арабскийПоздравляю, ты наконец начал понимать.
> trim_left должен резать СЛЕВА(Ака со стороны старших байтов/Code point). Как делает большинство
Не должен. Он вообще там нафиг не нужен.
Дело в том что начало строки всегда начало, но в зависимости от языка строки которая хранится начало может быть справа или слева, поэтому и переименовали trim_left в trim_start а trim_right в trim_end.
>>А вот start/end от языка зависят.старт и энд вообще-то - палка о двух концах. логичнее лэфт, райт использовать
> У Арабов ЛЕВО это не ЛЕВО?Лево у них лево. Для них нулевой символ строки слева. У них всё то же самое, но ментальная модель строки перевёрнутая, из-за чего "left" и "right" не работает. А вот "start" и "end" будучи гендерно-нейтральными словами, работают и с твоей ментальной моделью строки, и ментальной моделью араба.
> Или тупы но жопоруки, в зависимотси от того что у них сейчас ЛЕВО.
Это у тебя опыта недостаточно. Когда-то я впервые столкнулся с текстом, который RAM рисовал снизу-вверх, и бОльшие адреса там оказывались выше чем меньшие. И, что хуже, это сказывалось на тексте, например, стек там рос вниз, а не вверх. Вот тогда я понял, как это бывает плохо.
> А что по поводу языков с письмом сверху вниз?
А ничего. RAM в компьютере представляют либо горизонтально, либо вертикально, когда это вертикальное представление то адреса могут расти либо вверх, либо вниз. Легко и непринуждённо можно переходить от горизонтального представления к вертикальному, но вот от адресов растущих вверх к адресам растущим вниз -- это боль. Тебе говорят "стек растёт вверх", и ты представляешь себе операцию push(x) как *(stack_ptr++) = x, но через две страницы закрадывается подозрение, что вверх это *(stack_ptr--) = x. И это кошмар, перечитываешь текст по несколько раз, только чтобы убедиться, что понял его правильно. Точно так же, я подозреваю, переход от вертикальных строк к горизонтальным не будет представлять никаких проблем. А вот от горизонтальных строк к зеркально-отражённым строкам -- тут ты убъёшься отслеживать, что в данном контексте означает лево или право.
Я тебе скажу вот что, в мышлении человека очень активно используется зрительная кора, в ней проскакивают зрительные/геометические образы, без которых мышление может быть крайне затруднительным. Все эти "слева" "справа" возникают не случайно, но именно описывают те самые зрительные образы. Вот ты работаешь со строкой, которая суть последовательность байт, у которой есть начало и конец, но нет какой-либо протяжённости с севера на юг или с запада на восток, но и тем не менее ты мыслишь о строке как о геометрическом объекте. Строка _не_ геометрический объект, но в твоей голове она имеет геометрические свойства. Это выглядит ненужным усложнением, но это не мешает, до тех пор пока ты не начинаешь общаться с человеком, в чьей голове образ строки иной, который, говоря о левом конце строки, имеет в виду конец строки, потому что его образ строки простирается слева-направо. И наилучшая стратегия организации общения с таким человеком -- перейти к гендерно-нейтральным терминам, говорить не "лево"/"право", а "начало"/"конец" (или "конец"/"начало", в зависимости от того, что именно ты имел в виду). Это не более чем смена используемых слов, но такая смена позволяет обойти несовместимости кодера и декодера слов без дополнительных этапов процессинга.
> А если человек двуязычный?
Сложно сказать. Думаю он может использовать любую из моделей на выбор, но переключения между ними могут вызывать проблемы.
> Бегом читать ISO стандарт на с++. Особенно раздел memory model.Зачем? Если кто-то пользуется дурацкими моделями, почему я должен? Есть меньшие адреса, есть большие адреса, а лево и право -- это уже как получится. Если я храню в памяти растр, то у растра есть "лево"/"право", "верх" и "низ", зачем мне нужны ещё лево право у памяти? Чтобы я как и ты в случае с utf8 путался бы в словах?
> Вы запутались совсем.
> Нет ничего зазорно в том что бы называть тупых тупыми.Я тебе скажу более прямо, без прозрачных намёков. Если ты не понимаешь другого человека, то тупой, скорее всего -- ты.
> А что представляют собой данные в памяти компьютера как не цифры?
Память компьютера -- это биты, объединённые в адресуемые группы по восемь бит, называемые байтами. На некоторых архитектурах отдельные байты неадресуемы, можно адресовать только двойные байты или четверные.
На некоторых архитектурах структура памяти сложнее. Скажем на x86 блоки по 64 байта образуют кеш-линию, и эти кеш-линии кешируются в более быстрой ассоциативной памяти. Иногда добавляют ещё слоёв кешей.
Если глянуть на кристалл памяти DRAM, то геометрически память представляет собой множество прямоугольничков с прямоугольной сеткой, в узлах сетки хранятся отдельные биты.
Но если тебя интересует удобная для программирования модель памяти, то я предлагаю тебе линейную модель, где байты расположены последовательно от меньших адресов к большим. Ты можешь представлять такую память как отрезок, один конец которого соответствует адресу 0, а второй максимальному адресу.
Тут единственная проблема встаёт -- это бывают архитектуры high-endian, бывают low-endian. Это о том, как хранятся многобайтовые целочисленные значения в памяти. Можно располагать старшие байты по младшим адресам, можно располагать их по старшим адресам. Кстати, именно работая с этими различиями я и понял, что идея приписывать памяти "лево" и "право" ущербна, она лишь путает и сбивает с толку. Если ты думаешь не о лево и право, а о меньших/больших адресах, и вербализуя свои мысли в голове не используешь слов "лево"/"право", но используешь "меньшие"/"большие" адреса, то проблема испаряется и даже не возникает.
Правда эта модель будет работать только с линейной памятью, в x86 же с её виртуальными адресными пространствами, и страничной трансляцией этой модели не всегда достаточно, и там подчастую приходится держать в голове линейную память, виртуальную память и трансляцию из второй в первую. На x86 которые ещё 32-битные, там было ещё веселее, там были сегменты, которые превращали всё это в такую лапшу, что ничего не поймёшь пока не напишешь собственную ОС.
Я так и вижу, как ты, дочитав до сюда, опять потерял нить и ничего не понимаешь, и поэтому думаешь что все вокруг тупые. Поэтому я тебе дам основной вывод из всего вышесказанного в готовом виде: то, что ты называешь памятью компьютера -- это условность, это не память, но какая-то модель памяти, и в зависимости от задачи, тебе следует использовать разные модели памяти. Некоторые из этих моделей даже типизированные модели, который позволяют говорить, как ты говоришь: память содержит цифры. Но тебе никогда не следует забывать, что то, как тебе память видится в данный момент -- это не более чем один из способов её видеть. И не факт, что это лучший способ. Лучшего вообще не существует, и на всякий случай всегда следует использовать две-три модели одновременно: есть психологические теории мышления, которые говорят, что мышление возможно только тогда, когда проблема имеет в психике два разных описания на разных "языках". Например, это может быть геометрическое описание в виде визуальных образов, символьное описание в виде формул, словесное описание на естественном языке. Процесс "перевода" с одного языка на другой критично важен для процесса мышления, и без него мышление не работает.
Вам что, помандеть негде?
> Вам что, помандеть негде?В самом деле: форум, как и парламент, не место для дискуссий!
слева и справа - природные однозначные понятия.
меньшие или большие адреса о которых ты говоришь - всё верно, так все и устроенно, но скажи мне -
слева ли на той же "линейной РАМ" будет находится ячейка памяти с меньшим адресом?
> слева и справа - природные однозначные понятия.А линейная память, о которой ты говоришь, не природное понятие -- это искусственная абстракция.
натуральный ряд чисел тоже искуственное понятие?пс: даже в теории о больше-меньше, есть понятие слева и справа. Число в натуральном ряду стоящее слева всегда меньше того, которое справа. И именно из-за природного понятия слева или справа, в натуральном ряду приняли понятие большего и меньшего.
*сс
> натуральный ряд чисел тоже искуственное понятие?Конечно же. Число -- это абстракция. Чисел не существовало пока люди не придумали их.
> Число в натуральном ряду стоящее слева всегда меньше того, которое справа.
facepalm.jpg
Ты троллишь что ле? Или ты действительно веришь в то, что написание натурального ряда слева-направо -- это фундаментальный закон природы, а не рандомно закрепившееся культурное правило?
> Ты троллишь что ле?Ну тогда докажи почему 1<2 истина.
По определению. Я может своё математическое образование и забыл за 15 прошедших лет, но не настолько же.
> По определению. Я может своё математическое образование и забыл за 15 прошедших
> лет, но не настолько же.на досуге - Готлоб Фреге, Рене Декарт
>> Чисел не существовало пока люди не придумали их.Того чего не существует - не придумаешь.
пс: придумай мне тут новую геометрическую фигуру.
> Того чего не существует - не придумаешь.Да ладно! Всё ровно наоборот, ты не сможешь придумать то, что существует.
Смотри сюда, следи за руками, и не говори что не видел, я тебе сейчас разъясню всё. Если ты что-то придумываешь, то результатом процесса придумывания является что? Правильно: психический образ. Ты придумал квадрат? Значит у тебя в голове появилась идея квадрата, и именно она и является результатом. Но идея квадрата (равно как и любая идея) может существовать только в психике. И в то же время, когда ты говоришь "квадрат существует" ты имеешь в виду, что квадрат существует вне твоей психики. Таким образом мы получаем, что результат придумывания внутри психики, а предполагаемое существование снаружи, значит это разные вещи, и то что ты придумал не существует, а то что существует ты не придумал.
>[оверквотинг удален]
> Смотри сюда, следи за руками, и не говори что не видел, я
> тебе сейчас разъясню всё. Если ты что-то придумываешь, то результатом процесса
> придумывания является что? Правильно: психический образ. Ты придумал квадрат? Значит у
> тебя в голове появилась идея квадрата, и именно она и является
> результатом. Но идея квадрата (равно как и любая идея) может существовать
> только в психике. И в то же время, когда ты говоришь
> "квадрат существует" ты имеешь в виду, что квадрат существует вне твоей
> психики. Таким образом мы получаем, что результат придумывания внутри психики, а
> предполагаемое существование снаружи, значит это разные вещи, и то что ты
> придумал не существует, а то что существует ты не придумал.Такс начнём по-порядку, про квадрат было ожидаемо))) так вот напряги психику и придумай "круглый квадрат"
> пс: придумай мне тут новую геометрическую фигуру.Я не буду придумывать, я приведу чужие придумки, ок? Тебе двух хватит?
1. Бутылка Клейна.
2. Любой фрактал (попробуй воспроизвести его в реальности, с размерами элементов стремящимися к нулю).
>> пс: придумай мне тут новую геометрическую фигуру.
> Я не буду придумывать, я приведу чужие придумки, ок? Тебе двух хватит?
> 1. Бутылка Клейна.
> 2. Любой фрактал (попробуй воспроизвести его в реальности, с размерами элементов стремящимися
> к нулю).ясно, не придумал
> пс: придумай мне тут новую геометрическую фигуру.Хотя если подумать чуть глубже, то выходит как в первом моём комменте: любая геометрическая фигура -- не более чем абстракция и плод воображения. Видел ли ты когда-нибудь точку, размер которой равен нулю? Видел ли ты когда-нибудь бесконечную прямую? Квадрат -- ты видел его? Абсолютно плоский, квадрат со сторонами, которые абсолютно прямые и без зазоров между атомами? Ты хоть какую-нибудь геометрическую фигуру встречал в реальности, или как и все сталкивался лишь с предметами, которые похожи на геометрические абстракции до некоторой степени. Если не всматриваться пристально.
> Видел ли ты когда-нибудь точкукакими свойствами обладает твоё понятие "точка", опиши и я скажу - видел или нет.
> ты когда-нибудь бесконечную прямую?
аналогично точке
>Ты хоть какую-нибудь геометрическую фигуру встречал в реальности
всюду
>> Видел ли ты когда-нибудь точку
> какими свойствами обладает твоё понятие "точка", опиши и я скажу - видел
> или нет.Как неловко признавать свою неправоту, да? Будем теперь крутиться ужом на сковородке, лишь бы не признать себя неправым. Речь идёт о геометрической точке, открой учебник по геометрии и почитай определения.
>>Ты хоть какую-нибудь геометрическую фигуру встречал в реальности
> всюдуВри-ври, да не завирайся. Ты не видел ни одной геометрической фигуры, а то что тебе казалось геометрической фигурой было не геометрической фигурой, а сложной квантовой системой из многих частиц.
>>Речь идёт о геометрической точке, открой учебник по геометрии и почитай определения.Открой Основания Геометрии Гильберта и узнай что есть геометрическая точка!!!
>>а сложной квантовой системой из многих частиц
ага которая нарушает геометрии Эвклида, Лобачевского, Римана?
>Видел ли ты когда-нибудь точку, размер которой равен нулю?самое интересное пропустил)), а будет ли существовать то, у чего размер равен "нулю", при условии, что "нуль" - есть ничто?
пс: хотя у физиков фотоны с "нулевой" массой покоя :)
>>Видел ли ты когда-нибудь точку, размер которой равен нулю?
> самое интересное пропустил)), а будет ли существовать то, у чего размер равен
> "нулю", при условии, что "нуль" - есть ничто?Если не будет существовать, то ты слил в споре: геометрическая точка придумана человеком, но не существует в реальности.
> пс: хотя у физиков фотоны с "нулевой" массой покоя :)
Толку-то от их нулевой массы покоя, если они никогда не находятся в покое?
>>геометрическая точка придумана человеком, но не существует в реальности.Читай Гильбертово определение точки!!!
>>если они никогда не находятся в покое?
не говори никогда никогда))) а типа фотон остановить нельзя?
> не более чем абстракция и плод воображения.Декарт ясно сказал, мыслю - значить существую.
Поправлю его, всё что мыслимо (то есть "плод воображения") - существует (сама эта "идея", "мысль", "бред", "реакция мозга" уже существует) и это факт, остаётся доказать факт значимости, и далее истинности, а истина собственно бывает приемлемой (абсолютной истиной) и не приемлемой (ложь).>и без зазоров между атомами
про "зазоры" не понял, но если атомы представить в виде элемента (кусочка) "пазла", у которого есть вход и выход (мама-папа), то в случае если соединить эти "пазлы" - там "зазоров" не будет. На этом ограничусь.
>> не более чем абстракция и плод воображения.
> Декарт ясно сказал, мыслю - значить существую.
> Поправлю его...Если ты правишь Декарта, то тогда научись сначала пользоваться языком как следует. Идея вещи и вещь -- это разные вещи. Если существует идея вещи, из этого не вытекает существование вещи. Если существует вещь, из этого не вытекает существование идеи вещи. Хотя второе можно оспорить с позиций близких к солипсизму.
>>и без зазоров между атомами
> про "зазоры" не понял,Теперь тебе надо вспомнить школьную физику: между атомами вещества куча пустого места. Даже внутри атома больше пустоты, чем вещества. Идея непрерывного объекта, заполняющего часть пространства полностью, возникает в голове у человека только как иллюзия, вызванная несовершенством органов чувств.
>>Идея вещи и вещь -- это разные вещи.выйди сначала из порочного круга, "Все критяне лжецы, сказал критянен"!
>>Если существует идея вещи, из этого не вытекает существование вещи.
Не идея вещи и вещь, а идея и вещь - разные понятия. И когда мы говорим о существовании идеи мы не говорим о существовании вещи. Единороги как идея существуют, как вещи в "твоем" реальном мире может и нет.
>>Если существует вещь, из этого не вытекает существование идеи вещи.
игра с modus ponens
>>между атомами вещества куча пустого места.
ага они круглые, и если три окружности поставить рядом, то меж ними всегда "пустота" - так вот, пустота - пустое слово. Пустоты в природе не существует!!!
>>Даже внутри атома больше пустоты, чем вещества.
Ага по учению Рыбникова))))
>>Идея непрерывного объектаЕсли спрошу, что есть непрерывность - думаю ответа не последует
>>заполняющего часть пространства полностью
а про пространство вообще помолчу, Эйнштейн тупо выкинул слово эфир и заменил его понятием пространства-времени, и в чём разница, если точного определения нет.
>>возникает в голове у человека только как иллюзия, вызванная несовершенством органов чувств.
опять используем утверждения смысла которого не знаем, что есть иллюзия? и что мы постигли уже в совершенстве наши органы чувств, чтобы судить об их несовершенстве?
>>>Идея непрерывного объекта
> Если спрошу, что есть непрерывность - думаю ответа не последуетИ как всегда ошибаешься
> а про пространство вообще помолчу,
> Эйнштейн тупо выкинул слово эфир и заменил его понятием пространства-времени,
> и в чём разница, если точного определения нет.Ну что за глупость!
Понятие пространство-время не заменило эфир!
Это понятие _изменилось_. В теориях "до Эйнштейна" пространство и время не зависили ни от чего,
в теориях Эйнштейна пространство и время зависят друг от друга и от объектов "внутри них".
И эти теории подтверждаются экспериментами.А теории использующие эфир не подтвердились экспериментами, поэтому и были отброшены.
> Ну что за глупость!Вот с такого утверждения начинает дискуссию всякий глупец.
> Понятие пространство-время не заменило эфир!
Вам в школе проходили про понятия эфира? Думаю нет, как и моему деду в начале 20 века.
> Это понятие _изменилось_.
Понятие чего? и что изменилось? в моём утверждении - заменилось. Если вы понятия не имеете, что есть эфир, как можно его изменить или заменить?
>>В теориях "до Эйнштейна" пространство и время не зависили ни от чего
Эфир со временем никто не связывал, чтобы они были зависимы.
> в теориях Эйнштейна пространство и время зависят друг от друга и от объектов "внутри них".
У Эйнштейна нет понятия пространства и понятие времени, есть одно понятие пространства-времени, которое и есть понятие эфира.
> И эти теории подтверждаются экспериментами.
Экспериментами какими? До сих пор экспериментально не доказано было существование гравитационных волн (стоит заметить якобы в конце прошлого года было зафиксированы гравитационные волны), о каких экспериментах доказывающих пространства-времени может идти речь?
> А теории использующие эфир не подтвердились экспериментами, поэтому и были отброшены.
Уверен, что ни про эфир, и не про какие-то попытки экспериментов вы не в курсе.
>>>В теориях "до Эйнштейна" пространство и время не зависили ни от чего
> Эфир со временем никто не связывал, чтобы они были зависимы.Ну как не связывал... В доэйнштейновской классике Эфир, как и всё прочее, существовал во времени и пространстве. Так с ними и связывался...
> Ну как не связывал...не вижу примера связи времени с эфиром...
Юноша не застал холивары на тему, на карте распределения памяти адрес 0 размещать сверху или снизу...
вы у нас тут застали холивар о "палке о двух концах"
> Лучшего вообще не существует,Почему же, с точки зрения железа лучше всего если софт работает так как оно реально устроено - чтобы не было дурных уровней трансляции. Другое дело что это не всегда удобно програмеру.
Но вот захочешь ты быстрый алгоритм написать - и как миленький узнаешь и про выравнивание структур, и про кэши, и про то что по 8 байты таскать быстрее чем по 1, и чего там еще. Или будешь радоваться тормозному коду.
>>Но вот захочешь ты быстрый алгоритм написать"быстрота алгоритма" определяется Колмогоровской сложностью, а не железом.
> Лево у них лево. Для них нулевой символ строки слева. У них всё то же самое, но ментальная модель строки перевёрнутая, из-за чего "left" и "right" не работает. А вот "start" и "end" будучи гендерно-нейтральными словами, работают и с твоей ментальной моделью строки, и ментальной моделью араба.Вы здесь перепутали всё с точностью до наоборот.
Как Вы (и прочие высказавшиеся ранее) сказали - лево и право у всех одинаковые.
А вот как раз «"start" и "end" будучи гендерно-нейтральными словами» работают по разному - у европейцев старт слева, а у арабов спарава.
> Вы здесь перепутали всё с точностью до наоборот.А, да вы правы. Это у нас нулевой байт слева, у них он справа.
> А вот как раз «"start" и "end" будучи гендерно-нейтральными словами» работают по разному - у европейцев старт слева, а у арабов спарава.
А это совершенно не важно слева ли старт или справа, потому что "слева" и "справа" -- это термины из ментальной модели, не из реальности. Суть в том, что и у тех и у этих start -- находится в начале, там где нулевой байт, а end находится в конце -- это последний байт.
Говоря start/end разные культуры ссылаются на одно и то же, хотя при этом в голове представляют разные образы. Образы же, хоть и разные, но они одинаковы с точностью до изоморфизма. Отказ от использование "left"/"right" прячет этот изоморфизм с глаз долой, и можно делать вид, что образы просто одинаковы.
Щас найдёлся еще один, который начнёт утверждать что все на самом деле не правы, и вероятно кто-то считает нулевой символ концом строки.
> А, да вы правы. Это у нас нулевой байт слева, у них
> он справа.Да нет. Нулевой байт и у них и у нас справа. Только у нас нулевой байт равен нулю, а у них имеет нулевое смещение... >:-)
>:-)
>:-)
>> А, да вы правы. Это у нас нулевой байт слева, у них
>> он справа.
> Да нет. Нулевой байт и у них и у нас справа. Только
> у нас нулевой байт равен нулю, а у них имеет нулевое
> смещение... >:-)Я никогда не думал, что люди настолько не в состоянии отличать реальность от иллюзий. Это бывает непросто, но не в столь тривиальных случаях. Приятно осознавать себя одарённым, ЧСВ летит в небеса.
выше написал - все споры ведут к палке о двух концах!!!
Старт у строки там где символ с индексом "0".
Конец у строки - там индекс будет длина-1.
А Лево и право - это скорее к вопросу отображения локали.Всё правильно сделали. А вы зря расходуете свои нервы по пустякам
нарисуйте на бумаге ряд ячеек, и поставьте в начальной (стартовой) ячейке индекс 0, она будет слева или справа?пс: у англосакса (или немца), который проектировал линейную модель памяти как по вашему где стоял бы индекс 0?
> Скорее всего это про языки с письмом справа налевоА что, есть взаимосвязь между порядком символов в строке и порядком их отображения на экране?
> Как можно неверно трактовать понятие "Лево"??? Разработчки языка страдают аутизмом?Нет, но есть подозрение, что анонимы не умеют в аглицкий:
https://github.com/rust-lang/rust/issues/30459
str's trim_left and trim_right implicitly assume LTR text #30459
Closed
huonw opened this Issue on 18 Dec 2015 · 18 commentsThese functions and their _matches variants operate on the start and end of the string, which are only the left and right (respectively) of the displayed text when rendered left-to-right like English. For (readers/users of) RTL languages, trim_right is hinting that it will be trimming the prefix, but this is of course not the case (and similarly for _left).
> Добавлена поддержка двух новых видов процедурных макросовНаконец-то они вынесли это из nighly. Ряд проектов теперь сможет перейти на stable rust.
> Ряд проектовОба?
>> Ряд проектов
> Оба?Я сталкивался с этим, действительно в двух проектах. Но они позволяют определять специфические типы, вокруг которых иначе приходится писать кучу boilerplate, и поэтому я полагаю, что таких проектов гораздо больше двух.
Один из этих проектов -- это API к табличным базам данных. Ты объявляешь struct в rust'е, который автоматически мапится на запись в табличке бд. После чего ты можешь использовать эту структурку как для создания данных в памяти, так и для получения их из бд, так и для создания соответствующей таблички, при этом все замороки типа преобразования типов из БДшных в rust'овые берёт на себе библиотечный код, ты об этом даже не думаешь.
Для такого, с типом надо увязать всякие атрибуты, типа имя таблицы, например, в которой хранятся записи такого типа, и это очень удобно делается через процедурные макросы. Прячет кучу сложности под капотом, лишая возможности совершать тупые ошибки.
> Наконец-то они вынесли это из nighly. Ряд проектов теперь сможет перейти на
> stable rust.Судя по всему теперь у плюсов появился наконец достойный конкурент. В нечитаемом коде который никто не понимает. Собственно фирменная проблема плюсов - многие програмеры сперва делают себе кучу абстракций а потом на этом наворачивают. Это было бы ничего, если бы не один нюанс: остальные люди могут и не въехать в эти абстракции, понять их неверно, или убить массу времени на это понимание. Поэтому я видал проекты на плюсах сдохшие по причине того что автор забил а остальные вообще не способны понять столь "гени(т)альный" код.
Ну а растовики похоже решили помочь в превращении исходников в что-то подобное и у себя. Ну вон тот пример с скулем - как раз самое то. Навернуть такого и побольше - и потом хрен кто кроме програмера писавшего это вообще поймет что за код и что он делает.
Я не очень понимаю о каком нечитаемом коде в rust'е говорят люди. От тебя я слышу это не в первый раз, но до сих пор мне не приходилось сталкиваться с кодом на rust'е, который не был бы прозрачен. Поэтому я очень приветствую конкретные ссылки на код. Любопытно посмотреть.
https://github.com/antoyo/relm/blob/7e1baa6a62b2db5917720a1d...Простой пример: Не обращаясь к документации найдите объявление структуры Counter.
Вообще, макросы это очень плохая практика, так как стимулируют к написанию несамодокументируемого кода. Ну нельзя просто перейти в определение структуры. Так же автодополнение внутри макросов не работает
"Не обращаясь к документации" -- это искусственное ограничение в случае rust'а, поскольку документация генерируется автоматически, и изучение кода идёт именно через документацию. Если ты выкидываешь этот инструмент, и берёшь взамен IDE, которая тебе не находит нужный сорец, то кто тут ССЗБ?Но вопрос был в том, где нечитаемый код. Код Counter'а нечитаемый? Где ссылка на него? Код использующий Counter нечитаем? Да не, читаем. Кристалльно прозрачен и понятен.
Растовые макросы читаются глазами как текст на естественном языке, не сложнее. Даже проще, чем lisp'овые макросы. Ну да, из документации ссылка ведёт на файл, а не на конкретную строчку файла, но... и чё?
> макросы это очень плохая практика
Академический буллшит. Макросы сложно писать. Хорошие макросы писать ещё сложнее. Но хороший макрос может сделать твой код гораздо короче и понятнее. Макрос может позволить тебе сделать то, что иначе ты не сделаешь. Статическая проверка SQL синтаксиса, сопутствующих преобразований типов, экранирования/деэкранирования значений? Ты этого никогда не сделаешь без макроса. Без макроса ты закончишь тем, что будешь для составления SQL запросов конкатенировать строчки вручную, а потом с пылающим пердаком закрывать SQL-инъекции на работающем сервере. Или вместо SQL синтаксиса для запросов ты получишь долбаный ООП интерфейс, который позволит написать прототип, а потом, в погоне за производительностью, ты будешь заменять использования этого ООП интерфейса на составление запросов вручную, а потом с пылающим пердаком закрывать SQL-инъекции на работающем сервере.
Если бы макросы были бы безусловно плохой практикой, то макросов бы не было. Вообще ни один язык не поддерживал бы макросов. Но мы видим макросы в C и, между прочим, активное их использование в коде ядра. Мы видим макросы в lisp'е, в rust'е. Мы видим макросы в C++. И знаешь почему? Потому что все блестящие идеи самого блестящего языка имеют ограниченную применимость. И иногда ты сталкиваешься с ситуацией, когда средства языка не позволяют тебе избежать копипастов десяти строк кода в два десятка мест. И вот тогда ты понимаешь, что либо ты скопипастишь эти десять строк, а потом когда что-то изменится, ты будешь править каждый копипаст (ещё бы не забыть куда копипастил), либо ты напишешь макрос, и в случае необходимости изменений будешь менять только макрос.
Rust, по сравнению с C, позволяет гораздо больше вещей делать без макросов. Но, как я сказал выше, любая самая блестящая модель программирования имеет свои границы. Rust'овая не исключение. И слава богу, потому что попытка сделать исключение из этого правила приведёт к такому оверинженерингу, что чертям станет тошно, а в результате всё равно будут возникать edge-cases, в которых этого оверинженеринга будет недостаточно.
> Так же автодополнение внутри макросов не работает
Да и плевать на него. Бесполезная вещь, создающая видимость ускорения написания кода. Но это иллюзия, а не ускорение. Тем более что использование макросов реально упрощает написание кода. Гораздо больше чем все эти ваши автодополнения.
> "Не обращаясь к документации" -- это искусственное ограничение в случае rust'а, поскольку
> документация генерируется автоматически, и изучение кода идёт именно через документацию.
> Если ты выкидываешь этот инструмент, и берёшь взамен IDE, которая тебе
> не находит нужный сорец, то кто тут ССЗБ?
> Но вопрос был в том, где нечитаемый код. Код Counter'а нечитаемый? Где
> ссылка на него? Код использующий Counter нечитаем? Да не, читаем. Кристалльно
> прозрачен и понятен.Ну так как, нашли? Нет его, опредления этой структуры на уровне обчычного кода. Она сгенерирована с помощью атрибута. Или макроса в зависимости от используемой версии раста.
То есть, за место того, чтобы просто кликнуть пару раз в требуемое место, чтобы "пощупать" эту структуру, Вам нужно проломиться сквозь слой абстракции макроса и предположить (!) что именно он нагенерирует. А затем, основываясь на этом предположении писать код.
> Без макроса ты закончишь тем, что будешь для составления SQL запросов конкатенировать строчки вручную, а потом с пылающим пердаком закрывать SQL-инъекции на работающем сервере.
Простые вещи легко реализуются на чём угодно. Хоть на макросах, хоть IQueryable.
Сложные запросы в любом случае будете писать руками> И иногда ты сталкиваешься с ситуацией, когда средства языка не позволяют тебе избежать копипастов десяти строк кода в два десятка мест. И вот тогда ты понимаешь, что либо ты скопипастишь эти десять строк, а потом когда что-то изменится, ты будешь править каждый копипаст
Иногда копипаст - это не так уж и плохо по сравнениею с сложно устроенным "общим" механизмом, который часто модифицируют. Вообще, ищите золотую середину и всё у вас будет хорошо
>> "Не обращаясь к документации" -- это искусственное ограничение в случае rust'а, поскольку
>> документация генерируется автоматически, и изучение кода идёт именно через документацию.
>> Если ты выкидываешь этот инструмент, и берёшь взамен IDE, которая тебе
>> не находит нужный сорец, то кто тут ССЗБ?
>> Но вопрос был в том, где нечитаемый код. Код Counter'а нечитаемый? Где
>> ссылка на него? Код использующий Counter нечитаем? Да не, читаем. Кристалльно
>> прозрачен и понятен.
> Ну так как, нашли?И не искал.
> Нет его, опредления этой структуры на уровне обчычного
> кода. Она сгенерирована с помощью атрибута. Или макроса в зависимости от
> используемой версии раста.Я представляю о чём речь.
> То есть, за место того, чтобы просто кликнуть пару раз в требуемое
> место, чтобы "пощупать" эту структуру, Вам нужно проломиться сквозь слой абстракции
> макроса и предположить (!) что именно он нагенерирует. А затем, основываясь
> на этом предположении писать код.macroexpand. Используй macroexpand, Luke, если макросы читать не получается.
>> Без макроса ты закончишь тем, что будешь для составления SQL запросов конкатенировать строчки вручную, а потом с пылающим пердаком закрывать SQL-инъекции на работающем сервере.
> Простые вещи легко реализуются на чём угодно. Хоть на макросах, хоть IQueryable.
> Сложные запросы в любом случае будете писать рукамиВопрос в том как я буду их писать, буду ли я вручную экранировать строки, или не экранировать их. Буду ли я вручную разбираться ответом и преобразовывать типы как надо. Или всё это за меня сделает макрос, да ещё и SQL-синтасис проверит.
>> И иногда ты сталкиваешься с ситуацией, когда средства языка не позволяют тебе избежать копипастов десяти строк кода в два десятка мест. И вот тогда ты понимаешь, что либо ты скопипастишь эти десять строк, а потом когда что-то изменится, ты будешь править каждый копипаст
> Иногда копипаст - это не так уж и плохо по сравнениею с
> сложно устроенным "общим" механизмом, который часто модифицируют. Вообще, ищите золотую
> середину и всё у вас будет хорошоОй, не надо мне тут советы давать. Я ходил по граблям макросов в lisp'е, я делал обе ошибки -- писал макросы, когда их не надо писать, и не писал тогда, когда их надо писать. Если речь идёт о крупном проекте, то просто не позволяйте писать макросы рядовым разработчикам. Для них это должно быть запретно. Нужду в макросе должен увидеть умудрённый опытом разработчик, и он же должен написать макрос. Вот и всё.
> macroexpandГде же вы раньше были. пойду читать, что за зверь такой
>> macroexpand
> Где же вы раньше были. пойду читать, что за зверь такойФункция в lisp'е. Она есть в emacs'е и её можно использовать не только с lisp'овым объектом. Хотя, если честно, я не пробовал использовать её с rust-mode, может она там и нереализована? Ну, мне не приходилось сталкиваться в rust'е с реально зубодробительными макросами, типа макросов, реализующих CLOS или типа того. Всё что я видел -- это вроде "давайте сгенерим impl MyCoolTrait для типа, через кодогенерацию, чтобы его не надо было бы писать для каждого типа вручную". Эти вещи легко читаются глазами в сорцах.
Да, это хороший пример, как использование атрибута может запутать, так как частично код генерируется в процедурном макросе. Однако мне потребовалось 5 минут, чтобы на Гитхабе отыскать то место, где создается структура. При этом я в своей жизни только один раз сам писал процедурный макрос и чтение кода особого труда мне не составило.
> let r#for = true;Но зачем? Чем это отличется от "my_for", например, если в коде это всеравно будет везде с приставкой "r#". Или нет?
Видимо, в талицу идетификаторов при трансляции все же занесется "for", но прогоаммисту-то до этого какое дело? Он с этим разве что в каком-нибудь gdb встретится, наверно.
Или я чего-то не знаю?
Для интеграции с другими языками (с тем же Си, например). То есть, к примеру, надо из Rust вызвать функцию match(), которая на C, а просто так это не сделаешь: в Rust match - ключевое слово (а в Си - нет).
Другие языки уже лет сорок используют или
import Cc.match()
или
c_match()
c_getc()
Зачем изобретать уродливую конструкцию
fn r#match()
я не понимаю. Мания NIH?
Кстати это несовместимое изменение языка и оно потребует переписывания всех анализаторов, lint-еров, и компилятора. Тогда как выше предложенные варианты обходятся без этого.
Затем, что с новым инструментом cargo fix не сможет добавлять везде префикс my_ так как он у тебя в коде может уже быть использован, а сканировать всю базу кода на обнаружение конфликтов не имён и потом добавлять что-то вроде my1_ или my2_ не представляется очень разумным. + к этому же добавляется проблема с вызовами между языками. r# выглядит наиболее адекватным решением.
Ответ был дан в блогпосте, анонсирующем выпуск:"Пока не так много случаев, когда вам это пригодится. Но однажды вы попытаетесь использовать пакет для Rust 2015 в проекте для Rust 2018 или наоборот, тогда набор ключевых слов у них будет разным."
https://habr.com/post/428073/
>В пакетный менеджер Cargo добавлен индикатор прогресса выполнения операций.Знаете почему в GOLANG при компиляции нет индикатора прогресса?
А в го компилятор собирает средний проект менее секунды. Стандартную библиотеку - 5 секунд.
>>В пакетный менеджер Cargo добавлен индикатор прогресса выполнения операций.
> Знаете почему в GOLANG при компиляции нет индикатора прогресса?
> А в го компилятор собирает средний проект менее секунды. Стандартную библиотеку - 5 секунд.
> https://i.imgur.com/qfli0f7.pngЕсли бы еще достигалось не экономией на оптимизации результата и не сливало ржавчине по времени выполнения и потребления памяти, то разработчики го (к которым несомненно относятся и некоторые консультирующие их анонимы опеннета!) могли бы гордиться:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
regex-redux
source secs mem gz cpu cpu load
Rust
2.44 194,804 765 3.87 85% 41% 20% 16%
Go
28.69 407,444 802 60.43 46% 51% 68% 46%
binary-trees
source secs mem gz cpu cpu load
Rust
4.14 175,692 721 15.18 90% 90% 91% 100%
Go
28.90 471,068 654 110.50 96% 95% 95% 97%
...
pidigits
source secs mem gz cpu cpu load
Rust
1.74 4,520 1366 1.74 1% 3% 0% 99%
Go
2.04 8,976 603 2.04 1% 0% 100% 0%
Но чего нет, того нет.
Синтетические тесты это хорошо.
Но потребление памяти и быстродействие я бы предпочел сравнить на реальных проектах.
К сожалению не знаю никого кто бы использовал Раст в продакшене.
А вы?
> Синтетические тесты это хорошо.
> Но потребление памяти и быстродействие я бы предпочел сравнить на реальных проектах.Юлеж это хорошо! Можно сравнить время загрузки или запуска браузера или доступа/записи данных на ФС
https://www.redox-os.org/
Что там у ГОшников есть для сравнения?
Никто не будет писать ОС на урезанном куске языка в 2018
Go пока сливает по тестам даже Java (если внимательно посмотреть на тайминги), но этот язык простой, как угол дома. Годков через пять допилят оптимизцию так, что уделает всех, а вот Rust все усложняется и стабильных спек на горизонте не видать, скоро плюсы по сложности переплюнет (если уже не).
FreePascal смеется над golang по времени сборки проекта.
а зеленые треды там есть? без них микросервисы не сильно попишешь.
Паскаль собирает быстро, для институтских поделок сойдет да и ладно:) Для всего остального есть C/Cpp/C#/Java.
Ну очевидно для этого пришлось чем-то пожертвовать. Создатели Go пожертвовали итоговой оптимизацией программы. Или вы думаете там применяется какая-то магия 60 уровня, которая не доступна другим программистам?
За два года компиляцию в Rust уже не раз ускоряли. Так что не все так плохо.
Для этого всего лишь стоит прочитать оригинальную новость в блоге Rust. При миграции между изданиями языка возможно, что в одном из следующих изданий будет добавлено слово, которое испльзуется уже в проекте как идентификатор. Что бы избежать конфликта с переименованием и сохранить семантику проекта необходимо будет просто добавить везде r#.Данная возможность является подготовкой к Rust 2018 Edition.
>Rust 2018 Edition.История с Python2/3 никого ничему не научила.
Ну почему же. В Rust 2018 насколько знаю просто в проекте будет прописана версия.
И Компилятор может использовать как до 2018 библиотеку, так и 2018 библиотеку.
Такого разрыва быть не должно.
Звучит интересно. Я никогда не понимал все эти "extern crate..."
Дополнительная прокладка к режиму компиляции Firefox и Tunderbird.
> Дополнительная прокладка к режиму компиляции Firefox и Tunderbird.Ну чо, изя, будет у тебя штук 5 компилеров, дюжина интерпретаторов, 20 гигатонн библиотек и 10 - хидеров. Про вспомогательное добро типа мезонавтотулсмэйков даже и вспоминать неудобно.
А потом со всей этой фигней мы попробуем взлететь...
> А потом со всей этой фигней мы попробуем взлететь...Перед "взлётом" можно сделать "pkg autorevove":
% pkg autoremove
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 62 packages:Installed packages to be REMOVED:
rarian-0.8.1_4
gtk-doc-1.29
bash-4.4.23
bison-3.1,1
libgit2-0.27.5
rust-1.30.0
c-ares-1.14.0_1
cmake-3.12.3
cppunit-1.14.0_5
dmake-4.12.20150309
docbook-xsl-1.79.1,1
docbook-1.5
docbook-sgml-4.5_1
docbook-xml-5.0_3
vigra-1.11.0_24
fftw3-float-3.3.8_1
getopt-1.1.6
gettext-tools-0.19.8.1
groff-1.22.3
gmake-4.2.1_2
gperf-3.0.3_1
vala-0.40.7,1
graphviz-2.40.1_6
gsed-4.2.2_1
gsfonts-8.11_8
gts-0.7.6_5
hdf5-1.10.2
hdf-szip-2.1_2
help2man-1.47.8
highlight-3.43_2,3
openexr-2.3.0
ilmbase-2.3.0
intltool-0.51.0_1
iso8879-1986_3
itstool-2.0.2_2
jade-1.2.1_10
jsoncpp-1.8.1_4
libgd-2.2.5,1
libssh2-1.8.0,3
libtool-2.4.6
libuv-1.23.2
ruby-2.4.5,1
libyaml-0.2.1
scons-3.0.1
m4-1.4.18,1
mdds-1.3.1
meson-0.48.0
nasm-2.13.03,1
ninja-1.8.2,2
p5-Locale-gettext-1.07
p5-XML-Parser-2.44
patch-2.7.6
psutils-1.17_5
py27-libxml2-2.9.7_1
rhash-1.3.5
sdocbook-xml-1.1_2,2
texinfo-6.5,1
ucpp-1.3.2,1
unixODBC-2.3.7
xmlcharent-0.3_2
yasm-1.3.0
zip-3.0_1Number of packages to be removed: 62
The operation will free 560 MiB.
Proceed with deinstalling packages? [y/N]:
на Haiku OS пойдёт?
Макросы — зло.
макросы для машин, а не для человека
> макросы для машин, а не для человекаСудя по синтаксису - для боевых человекоподобных роботов.
>> макросы для машин, а не для человека
>
> Судя по синтаксису - для боевых человекоподобных роботов.Судя по синтаксису - для боевых паукоподобных роботов.
Вот подскажите пожалуйста. Если учить php, то чтоб взяли программистом, нужно знать MySQL, html, css, js.. и какой-то фреймворк.А в случае с растом, какие еще будут зависимости на собеседовании?
> А в случае с растом, какие еще будут зависимости на собеседовании?Спросят, почему решил устраиваться именно в Мозиллу.
> А в случае с растом, какие еще будут зависимости на собеседовании?MySQL, html, css, js.. и какой-то фреймворк.
Надо не учить, а жить этим.
TCP/IP стек и блокчейны.
очередной убийца с++ скатился
Аргументы?
Аргументы что не скатился?
А что значит "скотился"?
А есть кто-нибудь, кто шарит в этой библиотеке?
http://relm.ml/relm-intro
> А есть кто-нибудь, кто шарит в этой библиотеке?
> http://relm.ml/relm-introЕсть. Но я их не знаю.
Ваше чувство юмора просто зашкаливает.
Может кто из растаманов пояснить нафига это "Добавлена возможность использования ключевых слов в качестве идентификаторов."?
Rust-1.31 на FreeBSD занимает 320 МБ в распакованном виде, в архиве пакета - rust-1.31.0.txz 104,1 МБ. На Ryzen 5 2600 собирается из исходников за 45 минут.
Это всё, что нужно знать об инфраструктуре этого языка.
> Rust-1.31 на FreeBSD занимает 320 МБ в распакованном виде, в архиве пакета
> - rust-1.31.0.txz 104,1 МБ. На Ryzen 5 2600 собирается из исходников
> за 45 минут.
> Это всё, что нужно знать
>об инфраструктуре этого языка.Ты забыл, или тебе просто не надо, указать, что каждая следующая версия обязятельно собирается предыдущей, и, чтобы собрать этот свой "1.31" таки из исходников, включая инструменты сборки! ddg://trusting+trust+compiler+attack, станцевать придётся с версии, кажется, 1.19 и какого-то "mrust"-а, собирая _каждую_ из них предыдущей -- в диапазоне 19..31, соответственно.
На досуге можешь посчитать диск и время. Это тоже интересно публике.
