В Ruffle, эмулятор Adobe Flash Player, написанный на языке Rust, добавлена поддержка декодировщика формата сжатия видео H.263, позволяющая воспроизводить встроенные в swf-файлы видеопотоки (пока без поддержки формата flv). Декодировщик H.263 написан с нуля на языке Rust и не является обёрткой вокруг FFmpeg. Изначально реализация кодека была предложена для включения в состав Ruffle ещё в январе, но долго не принималась из-за анализа рисков, связанных с патентными претензиями. Реализация нового открытого кодека H.263 опубликована в форме отдельного проекта h263-rs, который можно использовать не только в Ruffle. Код поставляется под лицензиями MIT и Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55675
слышите? это его победная поступь
Его - это кого? Флеша? так его закопали уже официально же.
> В 2012 году Adobe объявила о завершении поддержки технологии Flash(прошло 9 лет)
2021: растаманы пилят эмулятор флэша...
Надо бы подсказать растаманам, что в прошлом веке была ещё такая Деньди.
Им уже подсказали что в прошлом веке был gnu utils, до сих пор пишут 10005000 бесполезных клонов.
Может я и находил... Да, много эмуляторов nes на rust.
ржавого Саурона?
угу, у этого неудачного клона - кольца не только на всех пальцах, включая ног, но и в носу сразу два.
Несовместимые между собой, поэтому каждые пол-года новое добавляется.Зато никакой хоббитец не опасен - всю эту гору ржавых колец до вулкана даже на тачке не допереть.
Но, тем не менее, можно восхититься работоспособностью и целеустремленностью kmeisthax. Я уже почти был уверен что не взлетит по тридцатитрем причинам.
Вы правы.
Раст - эволюция Си, которая к слову, диТЧайше задержалась и это было уже всем очевидно. Отшлифуют язык и компилятор, в отличие от требования шлифовать руки и допускать банальные ошибки в Си, и всё пойдёт дальше.
Айфончико-хипстеры как всегда хрень несут, кто за кто против, по абсолютно идиотским причинам и более аргументам. А прогресс не остановить. Но да, этот идиотский синтаксис, к которому нужно либо привыкнуть либо свыкнуться.. это да. Такая же хрень испортила некогда Луа.
Си есть везде. На любой платформе. Раст зависит от LLVM, количество доступных платформ сильно ограничено. Вот и всё. А так да
На расте вроде уже и линукс "переписали" и даже успешно для дебюта. Приняли в ядро.
На этом фоне не понимаю вашего аргемента. Почему это не помешало Линусу сказать "да"? Вы знаете то чего он не знает? Поделитесь.
Заканчивал бы ты уже с растоманией.
Зелененькие полосочки в правой части окошка, под кругленькими портретиками.
https://github.com/torvalds/linux
Это не то что ты подумал.
Это не совсем так. Более верно "си может быть на любой платформе, но далеко не факт". Если разраб это не закладывал и не наставил туеву кучу ifdef под все мыслимые и немыслимые платформы, то ничего не выйдет. А много кто не хочет - и правильно делает - тратить свое время на бессмысленную фигню.
> Си есть везде. На любой платформеИ откуда же он там возьмётся?
> Раст зависит от LLVM, количество доступных платформ сильно ограничено. Вот и всё. А так да
Современный Си - это тот же LLVM. Ну или gcc, проект сравнимой сложности и портируемости. Что до поддержки платформ, то LLVM их поддерживает уйму, и добавление новой там делается с пол пинка. Так что с переносимостью у rust точно не хуже чем у C.
Необразованные растоманы (а других и не бывает) не в курсе такого термина, как "кросскомпиляция".Просвещаю: чтобы скомпилировать С код под вашу любимую экзотичную платформу не надо портировать под нее весь gcc. Можно спокойно сидеть под любимым дистрибутивчиком и под ним же компилировать для ведроида, винды, малинки, и т.д. и т.п.
Лично мой проект собирается одним скриптом сразу под 20 различных платформ. И под большую часть из них даже запускается для теста через qemu.
Можно код скрипта в студию? (Чисто научный интерес)
#include <stdio.h>
void main()
{
printf("Hello world\n");
}
да сборочный скрипт же ж просили, под стотыщ платформ, а не сам проект.
Я понял это когда уже отправил.. А скрипт не дам, он проприетарный копилефт клозетсорс.
> Я понял это когда уже отправил.. А скрипт не дам, он проприетарный
> копилефт клозетсорс.Ну блин, а проектов, собирающихся под стопиццот архитектур у нас у каждого своих есть. Примерно таких же, ага.
Таких же врят ли у вас есть. Это секретная разработка! Я сам его писал.
Клозетсорс, это значит его исходники надежно хранятся в клозете и используются по прямому назначению.
Оу, анонимы пробивают очередное дно?
Они даже не понимают разницы между сборочным скриптом и исходным кодом проекта?
Ответил выше
Он большой и вам не подойдет.Но ради научного интереса посмотрите на сборочную систему пакетов для void-linux. А именно раздел "Cross compiling packages for a target architecture" - https://github.com/void-linux/void-packages#cross-compiling.
Система уже заточена под безболезненную сборку без лишних телодвижений под aarch64, armv5tel, armv5te, armv6hf, armv6l, armv7hf, armv7l, i686, ppc64le, ppc64, ppcle, ppc и x86_64.
> Он большой и вам не подойдет.слив защитан.
> Но ради научного интереса посмотрите на сборочную систему пакетов для void-linux. Аизвините, васянский дистрибутив с нулевой юзербазой не настолько интересен науке чтобы разбираться в его деревенских сборочных системах.
> именно раздел "Cross compiling packages for a target architecture" - https://github.com/void-
If a source package has been adapted to be cross buildable xbps-src will automatically build the binary package(s) with a simple command:
а если не был вручную в ста местах подпилен и "adapted" - то will not. Васяну предлагается угадать, какой ему сегодня попался.
> Система уже заточена под безболезненную сборку без лишних телодвижений
васянами-ждунами ебилдов - безболезненную. Если дядя за них все сделал и готовые сложные скрипты подложил. Только непонятно зачем - дядя ж уже, наверное, и собрал за них тоже.
И вишенкой на тортике:
This utility requires these Linux kernel options:
CONFIG_NAMESPACES
CONFIG_IPC_NS
CONFIG_UTS_NS
CONFIG_USER_NS
This is the default method, and if your system does not support any of the required kernel options it will fail with EINVAL
ну зашибись. Вот весь этот лап4@тый мусор безусловно необходим для сборки хеловротов.
Пох, а чем ты на жизнь зарабатываешь? Судя по твоим комментариям - улицы метлой метешь?
> Пох, а чем ты на жизнь зарабатываешь?служебным собаководством. Видел табличку "объект охраняется собаками"? Ну вот.
Они охраняют, я на вышке пулемет смазываю.
вертухай, чтоле?
ну тогда не удивительно.
> Система уже заточена под безболезненную сборку без лишних телодвижений под aarch64, armv5tel,
> armv5te, armv6hf, armv6l, armv7hf, armv7l, i686, ppc64le, ppc64, ppcle, ppc и
> x86_64.Для тех, у кого мозгов больше чем у поха:
После развертывания сборочной среды по инструкции в пару шагов (все тулчейны, а их аж 29, ибо все дублируются к glibc и musl, займут 20 гиг на диске), кросс-сборка под ppc64le, например, запускается так:
"xbps-src -a powerpc64le-linux-gnu -C pkg ваш-пакет"
xbps-src сам скачает нужный тулчейн, если его не будет.
Войд ставить не надо, у меня основной минт и под ним я и собираю.
> Для тех, у кого мозгов больше чем у поха:нет, это не для них
> После развертывания сборочной среды по инструкции в пару шагов (все тулчейны, а
после скачивания полутора терабайт невменяемого мусора о начинке и внутренних механзмах которых клиент не имеет ни малейшего представления
> 20 гиг на диске), кросс-сборка под ppc64le, например, запускается так:
> "xbps-src -a powerpc64le-linux-gnu -C pkg ваш-пакет"пакет при этом тоже скачивается по инструкции в пару шагов. Уже бинарный, поэтому можно уже и не запускать. А если пакета почему-то не написали - то опаньки.
И да, разумеется, твоим хеловротам ничто не мешает собираться под "ppc64le".
Ты, наверное, даже знаешь что-нибудь кроме названия про эту архитектуру.
пох, ты мазорхист? Тебе доставляет удовольствие выставлять себя дураком?
пока что дураком выставил себя ты.
Когда выяснилось что и скрипт не скрипт, и вообще все за тебя делает void linux.
Причем очень навряд ли ты понимаешь, что и как он там делает.Осилятор кросскомпиляции ты наш...
> и вообще все за тебя делает void linux.Ну да, и ядро за меня написал линус с сообществом. И монитор спаял самсунг. И даже микропроцессор произвел интел.
Таки кретин, самый натуральный.
> Таки кретин, самый натуральный.ты-то - да. Написал хеловрот. Компилируется на мильенестотыщ архитектур. Горд до усрачки - пришел всех тут поучать кросскомпиляции и крякать что мы все лохи и не знаем дао.
P.S. в сторону: интересно, этот дурачок свой хеловрот отлаживать-то собирался? Впрочем, чего там в хеловроте отлаживать, действительно...
> что мы все лохи и не знаем дао.Не вы все, а лично ты. Не западло за спины других прятаться?
тебе ж не западло прятать свой давно не битый за хамство хлебальник за анонимным юзером?И нет, чушь про великое дао кросскомпиляции ты нес в ответ какому-то еще анониму.
и тем не менее моя кросскомпиляция прекрасно работает. в отличие от твоих мозгов, способных породить только тонны пустопорожнего трепа.
Рад за твой хеловрот. Жаль что мне-то твое прекрасноработает без надобности.
С чего ты решил, что я тебе что-то предлагаю? Пхах, размечтался.
необразованный сифилитики не в курсе, что кросскомпиляция не берется из воздуха?> Просвещаю: чтобы скомпилировать С код под вашу любимую экзотичную платформу не надо портировать
> под нее весь gcc.да, достаточно только переписать под нее кодогенератор, рантайм и, желательно, libc. Ну и все остальные библиотеки, которые обычно требуются программе посложнее хй-ловротов спортировать, не забыв про endianess, размеры long и int и так далее. Ну и там binutils по мелочи еще.
Правда, если это кто-то за тебя сделал, уже нет никакой проблемы собрать native gcc под эту платформу, это чисто механическая работа.
> Можно спокойно сидеть под любимым дистрибутивчиком и под ним же компилировать для ведроида,
> винды, малинки, и т.д. и т.п.только потому что за тебя эту работу уже сделали. Да-да, внезапно - спортировав "весь gcc" и еще немало всякого разного.
P.S. я поражаюсь безграмотности и безмозглости людей, называющих себя программистами.
я даже не знаю как этот бред комментировать - пох сетует, что каждый программист не пишет сам под себя все, включая компилятор и операционную систему.> P.S. я поражаюсь безграмотности и безмозглости людей, называющих себя программистами.
так не называй себя программистом и не придется поражаться.
> я даже не знаю как этот бред комментироватьникак. Твоей квалификации не хватило понять написанное - "это бред".
Нет - бред у тебя в черепной коробке.
> Правда, если это кто-то за тебя сделал, уже нет никакой проблемы собрать native gcc под эту платформу, это чисто механическая работа.Че, рили? Не звездишь, пох?
Давай ты соберешь gcc для amiga? Это ведь "чисто механическая работа"? А как насчет aviion (Motorola 881x0-based)? А может под pmax или pegasos?
Может пох просто не в курсе, что платформ больше трех, кроме его любимых х86_64, aarch64 и M1?
Ой, а я думал их 2: x86 и x64
А че за M1 такая?
Google: "M1 платформа".
А Танки на ней пойдут?
Не знаю, еще не щупал.
Отпишитесь. Мне главное-чтоб Танки шли.
Че, рили? Не звездишь, пох?И вот опять, сенйор С/С++ не осилил обычный русский.
Так вот, ЕЩЕ РАЗ, как для сенйор С/С++ повторяю, читай внимательно. внимание.
Механически gcc собирается под шо хош, ЕСЛИ (большими буквами для синйора-помидора), ЕСЛИ (еще раз, а то ведь непонятно, понял ли сенйор с первого раза) под платформу будут портированы кодогенератор языка, libc, и ДРУГИЕ необходимые библиотеки.
НУ ЧТО ? СИНЙОР, когда с капсом, немного понятней ?
Если снова не понял, ты не стесняйся, спрашивай.
> Механически gcc собирается под шо хош, ЕСЛИ (большими буквами для синйора-помидора), ЕСЛИну, не совсем - есть, в теории, микро-эмбедовка физически неспособная ничего кроме хеловротов запускать. Под нее не собирается потому что нечем - ни операционной системы, ни тулсета, ни достаточной мощности чтобы осилить сборку на самой себе, а кросс-компиляция типа все еще возможна. Правда, чаще всего и gcc для нее переусложнен и избыточен, и его рантайм там запускать нечем и не на чем.
> НУ ЧТО ? СИНЙОР, когда с капсом, немного понятней ?
Чорта с два он что поймет. это же ПРОГРАММИСТ, вы понимаете?
Ну и чудо-скрипта по сборке хеловрота под стопицот платформ мы тоже вряд ли увидим. В клозете храницца.
Впрочем, там ценность вряд ли в скрипте - скорее в конструкции стапиццот кроссбилд-сред. Но скорее всего дальше скачивания готовых комплектов от linaro и прочих там тоже дело не пошло.
Это понимать как отказ от сборки? Пох прозвездел и убежал в закат?С сотней ЕСЛИ и раст под чайники собирается. "Если", блин...
Пох. Да, этот поциент неизлечим.
> Лично мой проект собирается одним скриптом сразу под 20 различных платформ. И
> под большую часть из них даже запускается для теста через qemu.Ох, щи-. Если это ещё и один Макефиле, то, прям, уважение.
Не мейк, а шел скрипт. На базе сборочного инструментария void-linux и вызовов qemu.
Чуть выше ответил со ссылкой.
Всё ГОРАЗДО хуже. Лично для меня ржавый плох в endianess-unawareness. Не знаю как сейчас, но в своё время на mips'е было невозможно его использовать.
Он не только зависит от LLVM, но и прибит гвоздями к x86.
Айфончико-хипстеры уже давно пишут на swift, который по возможностям ничем не уступает расту, но имеет куда более адекватный синтаксис, так что поменьше бы ты хрень нес, коль не шаришь.
Ты прав малыш ) не всю же жизнь слыть рядовым кодером или тимлидом. Слава богу уже и не слежу за бесконечными новостями.Тем немменее, свифт тут не в тему, просто пук со стороны, раз уж раст упомянули. Мне понятны причины сего пассажа. Но если на свифт можно уже написать и под андроид, иос, винду, линукс без проблемм - будет интересно тебя послушать.
а что на раст все это уже можно?
Как только на свифте напишут ось с чистого листа, можно будет писать код для встраиваемых систем (уже работают вроде над этим), где могучий и столь красивый свифт посоревнуется с Си как в скорости так и в удобстве...
А пока, на это место проходит и подходит лишь раст. И ядро линукса как еще один, не самый простой, экзамен для нового языка.
Как-то вы невероятно ограниченно мыслите, сколько вам лет? Вот пока не используют там - вот и аргумент. Смотрите на картину более широким взглядом. Это же очевидные вещи.В свою очередь, я не 20 летний дебил, который против всего но лишь бы не своего любимого.
Пусть и свифт будет там. Будут подгонять друг друга, соревноваться, предлагать различные подходы к решению задач. Я лишь за, но пока это не так, да и будет ли..
А вы к тому моменту подрастёте )
"уже работают вроде над этим" - кто-то мне говорил что раст пытаются туда примостачить
> Как только на свифте напишут ось с чистого листа...О да, как-же
> А пока, на это место проходит и подходит лишь раст.
Ну ну, уже написали. Не работает, течёт и падает.
Не без проблем, но да - на свифте можно писать достаточно производительный код и под винду, и под андроид, и под линукс (без UI разумеется).Есть сложности с обертками - напр. на андроид приходится писать легковесные обертки в джава (если проект на ней) над свифтовыми примитивами, если проблемы в компиляторе, есть проблемы что некоторые вещи из Foundation (это некий аналог std lib, только для objc и swift) сделаны для других платформ ну скажем неоптимально. Но все решаемо.
Но то что оно уже несколько лет работает в проде на паре лямов пользователей - это факт. Много это или мало - каждый решает сам. А вот на вопрос стоит ли оно того, или нужно было сразу закладывать более простую переносимость кода, ответить не смогу.
Раст даже близко не эволюция си. Более того раст не эволюция. Раст забил на 30 лет развития языков и все свои силы сконцентрировал на чекерах, большая часть функциональности которых просто копирует функционал отдельных утилит и отдельных флагов компиляторов. А то немногое что раст добавил нового из проверок крайне спорные штуки работающие с жесткими ограничениями (unsafe), а решаемые им проблемы успешно решались и раньше. Объединение компилятора и анализатора-чекера это скорее деградация. А все остальное осталось на уровне си - синтаксис из 70х, многословность, зависимости, время компиляции. Или хуже - возросшая сложность как самого языка так и его компилятора и библиотеки. Из трёх качеств: просто, быстро, безопасно. Раст не вписывается ни в одно и только заявляет о безопасности. Если бы не мозилла то никогда никогда всерьёз его не воспринял. Но судя по всему маятник качнулся, мелкрософт и гугл будут его продвигать и активно допиливать (как это уже было с такими кусками !@#$%& как c#, js, go, php).
> Объединение компилятора и анализатора-чекера это скорее деградация.И пакетного менедежера, ты забыл о нем. И стандартных библиотек для всего на свете (как будто так бывает).
А все потому, что обезьянки не умеют пользоваться различными утилитами и не понимают как можно брать сторонние библиотеки - у них все должно быть в одном месте и от одних и тех же разработчиков.
Каргокульт, да. Кстати, это ведь фактически противопрложно философии не только linux, но всего unix(в т.ч. bsd) - небольшые программы делающие по одной вещи.
А в чем проблема карго? У него такая же идеология как и у обычных пакетных менеджеров - следит за зависимостями, затягивает либы соответствующих версий, проверяет конфликты и т.д. Но пакетные менеджеры это круто - хотя точно так же централизовано, а карго это фуфу?
Не хочешь им пользоваться - не пользуйся, пропиши в томл путь к своему гиту или локальный путь.
> А в чем проблема карго?в идеологии
> У него такая же идеология как и у обычных пакетных менеджеров - следит за зависимостями,
нет. Пакетные менеджеры - они в составе дистрибутива и поддерживают _синхронизированное_ состояние - одна библиотека одной версии, а не десять отличающихся.
И авторы дистрибутивов очень старались сделать так чтобы все это вместе - работало, и работало правильно. А при появлении критических ошибок - исправлялось ОДИН раз заменой библиотеки, а не всего дистрибутива.
И не скачивали весь интернет в хомяк чтобы собрать один хеловот. А потом еще раз - снова весь, потому что другой хеловрот написан на неделю позже и ему нужны другие версии ВСЕГО.
Причем вмешаться в это никакой майнтейнер уже не может - история с игогошечкой и тыщей зависимостей была показательна.
> Не хочешь им пользоваться - не пользуйся, пропиши в томл путь к
мы не хотим пользоваться поделками людей, ничего не понимающих в системном администрировании, вот в чем проблема. Но других разработчиков и другого софта скоро не будет вовсе.
Поэтому я выгуливаю собачек. Ну его на..й такое будущее.
> Поэтому я выгуливаю собачек. Ну его на..й такое будущее.пох., не думали рвануть в администрирование IBM Power Systems?
Lua, по сравнению с этим могилльным выкидышем -- божественна.
luajit. 5.1. Хотя вроде есть немного 5.2.
По синтаксисту и т.п?
> Раст - эволюция Си...этот идиотский синтаксис, к которому нужно либо привыкнуть либо свыкнуться..Нелёгкий выбор 😁
Не C, а C++. Извините, но четыре варианта макросов в C - это что-то за гранью.
Лол, что? Зачем несколько вариантов макросов?
мы уже кернел на расте пишем
Ресдох уже течь перестал? Может, даже за пределы гипервизора вылез и на произвольном железе запускается? "ПишИте, Жора, пишИте..."
Ре сдох уже
Мне противно находиться на сайте который написан не на языке Rust. Я и другие продвинутые граждане требуем переписать opennet на Rust к апрелю следующего года, иначе сайт будет удалён из закладок.
Напишии его на asm, получишь в подарок на rust )))
Где твой CoC? Как нам начать переписывать что-то на хрусте, если CoC нет?!
> сайт будет удалён из закладокНе надо откапывать.
Невозможно удалито то, чего нет. Да и с обратной стороны черепной коробки всё равно останется.
Теперь flash player обрёл ореол безопасности. Осталось ввести поддержку лгбтк+ и тогда он станет обязательным к установке.
>Осталось ввести поддержку лгбтк+ и тогда он станет обязательным к установке.Вы видимо имели ввиду лгбтк 4.4?
Лгбтк+ же уже история давно.
Какая безопасность может быть у байткода с житом? Адоба за 15 лет так и не смогла огородить эту вм, и дело тут вряд ли в языке.
Дело тут в криворукости и немотивированности индусов из Adobe.
> Какая безопасность может быть у байткода с житом?А у чего может быть, у байткода без жита, у жита без байткода, или может сразу у нативного кода?
Legacy на Rust интегрировано в ненужное Legacy на Rust. С этим нужно поздравить всех растаманов.
> Legacy на Rust интегрировано в ненужное Legacy на Rust, эмулирующее ненужное Legacy Adobe Flash.// completed
Теперь надо добавить поддержку avc и vp9 и наконец проблема с тормозами в браузерах будет решена.
Без ассемблера и булкана все равно будет тормозить
Бред.
> наконец проблема с тормозами в браузерах будет решена.Как Окончательное Решение? В целом верно - если браузер встанет намертво то сделать круче уже не выйдет.
Раст пропихивают прям сектантскими методами."Свидетели Rust"
"Адвентисты Rust дня"
"Rust синрикё"
"Rustибан" и "ШаRustиат"...
Да просто обычный хайп. Скоро уляжется, а этот переписанный хлам выбросят и забудут.
Да, конечно, самый любимый язык на протяжении шести лет по опросам на Stackoverflow, и скоро уляжется. Ну-ну...
Ты больше глупые рейтингов читай и тестов в женских журналах.
> самый любимый язык на протяжении шести лет по опросам на StackoverflowНе стыдно?
Ну php и c# до сих пор не улеглись, так что похоже ещё четверть жизни с этим !@$$% придётся встречаться
C# был почти умер, но МС решила его реанимировать и влила новую кучу бабла.
Он воскрес!
Кстати Java тоже была скорее мертва чем жива, но случился AndroidА C# взлетел следом за Unity и классным ASP.NET MVC
Android это логичное развитие J2ME
Нифига подобного, загугли за J2ME это кроссплатформенная среда(она была и на симбе и на самопальных мобильных ос тех лет, например Linux у мотороллы), а Java адроид навертво прибита к Android
Ты забыл пихон...
Cargo-культ забыл
Причём Rust синрикё раньше демострировала самые эффективные показатели помощи принятия Rust через дыхание во всех токийских ветках метро. Правда, участникам не повезло и их тоже заставили принять Rust и отправиться к Servo и Flash, поэтому популярность этого клуба помощи начала стремительно убывать.
RusTalib*, RustALib, Rust Audio Library
* - организация признана террористической на территории РФ
Дело не во Флэше. Дело в том, что кто-то переписал относительно полноценный и стандартный видеокодек (мало кто может это делать) на чём-то отличном от Ц. Хотя я сомневаюсь, что так ужэ переписал. Наверняка код там далёкий от безопасного и идеоматичного, просто конверсия вместе со всеми мозговыносными низкоуровневыми костылями.
$ git clone https://github.com/ruffle-rs/h263-rs
$ cd h263-rs
$ rg --count unsafe
$упс. Кажется, у кого-то ясновидение замутнилось.
Или может дьявол кроется в депендансах?
$ find . -name Cargo.toml -exec cat {} \;
[workspace]
members = [
"h263",
"yuv",
]
resolver = "2"# Don't optimize build scripts and macros.
[profile.release.build-override]
opt-level = 0[profile.dev]
panic = "abort"[profile.release]
panic = "abort"[profile.dev.package.h263-rs]
opt-level = 3[profile.dev.package.h263-rs-yuv]
opt-level = 3[package]
name = "h263-rs"
version = "0.1.0"
authors = ["Mike Welsh <mwelsh@gmail.com>"]
edition = "2018"
license = "MIT OR Apache-2.0"[dependencies]
bitflags = "1.3.2"
thiserror = "1.0"
num-traits = "0.2.12"
lazy_static = "1.4.0"[package]
name = "h263-rs-yuv"
version = "0.1.0"
authors = ["Mike Welsh <mwelsh@gmail.com>"]
edition = "2018"
license = "MIT OR Apache-2.0"bitflags, thiserror, num-traits, lazy_static... Чисто декларативные депендансы. Там в bitflags могут быть unsafe связанные с преобразованиями целочисленных типов, но скорее всего там тоже нет. В lazy_static... хз, может быть, но я подозреваю, что там на Mutex да RefCell всё сделано, и весь смысл существования этого lazy_static, чтобы объявление "безопасной" глобальной переменной укладывалось бы в две строки, а не в десять.
Но вот то, что они позволяют себе писать Cargo.toml, не добавляя lf в конец последней строки -- это, конечно, ай-яй-яй, как так можно, вывод в консоль перекосило из-за этого.
Вот к чему есть вопросы, так это к производительности этой реализации. Она ж небось на cpu декодирует, и моё ясновидение подсказывает, что использование всяких SSE и тп отдано на откуп компилятору -- если он справится соптимизировать в sse, значит будет, не справится, значит не будет. И вот тут реально встают вопросы, как быстро всё это работает.
Ну что касталеьно проиводительности - кодек достаточно старый, а процы - новые, вытянут и без оптимизаций. Это конечно не радует, но факт.
Кроме того, надо понимать что все эти прожекты по спасение Flash - по большей части временная блаж. Сабж умер и на данный момент если и подает признаки жизни то на правах зомби. А если так, зачем заморачиваться с особыми оптимизациями?
Вот недавний пример на который сам наткнулся - https://store.my.games/play/game/roa/
Какой-то мутный игоровой сервис (с российскими корнями), который вынужден крутить Flash игры в своей оболочке. Как долго они смогут гальванизировать труп, интересно?
> Ну что касталеьно проиводительности - кодек достаточно старый, а процы - новые,
> вытянут и без оптимизаций. Это конечно не радует, но факт.На мобиле это может быть не очень здорово. Хотя хз.
> Кроме того, надо понимать что все эти прожекты по спасение Flash -
> по большей части временная блаж.Вообще, если так смотреть, всё преходяще. Альтернатива флешу -- это wasm и всякие там opengl. Но железо пока не очень располагает к тому, чтобы на вебстраничку грузить полноценный игровой движок. Флеш умер по многим причинам, но одна из серьёзных -- это вся эта неопределённость с поддержкой, закрытостью, дырявостью. ruffle снимает первые две, и резко снижает последнюю, потому что полагается на песочницы предоставляемые браузерами, а не на какую-то там запиленную когда-то на коленке компанией, которая в принципе в безопасность не умеет.
> Какой-то мутный игоровой сервис (с российскими корнями), который вынужден крутить Flash
> игры в своей оболочке. Как долго они смогут гальванизировать труп, интересно?Я думаю до бесконечности. dosbox до сих пор живёт, хоть DOS и умер. Ностальгическое желание погонять древнюю игрушку вечно.
>это вся эта неопределённость с поддержкой, закрытостью, дырявостью.Уже забытый пункт, но на железе того времени флеш был тормозной. Теперь он будет таковым на современном железе.
>>это вся эта неопределённость с поддержкой, закрытостью, дырявостью.
> Уже забытый пункт, но на железе того времени флеш был тормозной.бредни впопеннетчиков, высасывают из пальца то, к чему опоздали родиться.
> Теперь он будет таковым на современном железе.
он на весьма посредственном современном железе вполне приемлемо работает. Ну, при условии либо native кода, либо современного браузера (то есть хрома).
_уже_ работает, высасыватель бредней из пальца.
Не 100% апи, но преизрядное количество swf можно просто взять и запустить, как раньше.
> Не 100% апи, но преизрядное количество swf можно просто взять и запустить,
> как раньше.https://github.com/lightspark/lightspark
Не 100% апи, но преизрядное количество swf можно просто взять и запустить,
как раньше.
нельзя. Нет больше никаких "browser plugins".
(ну и это не говоря уже о том что он не поддерживает as1-2, не поддерживает никаких видео и аудиокодеков, только спрайтовую анимацию)А ruffle пытается сохранить именно совместимость сайтов с модными браузерами, а не дать тебе возможность кое-как запустить в ручном режиме то что вообще способно в таком режиме а не встроенным в страницу запускаться. Такое прекрасно запустит родной адобовский air - он-то никуда не девался.
Проблема оказалась в том, что флэш - оказывается ОГРОМНЫЙ проект. И команда из трех человек на донейтах не может за год повторить то что компания с сотнями разработчиков на нехилых зарплатах делала десять лет. Даже на моднейших безопастных языках (я бы сказал - из-за, но у лайтcpака тож не очень-то взлетело - за сколько там его пилят, десять лет, больше?)
Автор? ты из какой нAры вылез, а ну влезай обратно))1. lazy_static крейт для безопасной инициализации статической переменной при обращении, да, там действительно есть проверка была ли инициализирована ранее переменная при обращении к самой переменной.
1. и нет, mutex там нет и refcell нет, еще че придумали, refcell работает безопасно лишь в однопотоке предоставляя безопасную изменчивую переменную да И ЗАЧЕМ ОНО ЗДЕСЬ...
2. lazy_static работает в многопотоке ИСКЛЮЧИТЕЛЬНО на атомарных значениях, он не предоставляет гарантий гонок изменчивости переменной, только на атомарах гарантию одноразовой инициализации в многопотоке.
Да и автоматическую инициализацию статической переменной можно убрать сделав стоимость ваще 0zero, для этого используем крейт once_cell (там типы исключительно для одноразовой безопасной инициализации без прозрачности). Да и вообще можно пометить unsafe static и просто не предоставлять никаких гарантий безопасности)
Итого все написано до нас, просто бери и используй, данные крейты нужны лишь для безопасной одноразовой инициализации статических значений не более, да и стоимость их использования КРАЙНЕ мала (а на once_cell ваще 0).
"Но вот то, что они позволяют себе писать Cargo.toml, не добавляя lf в конец последней строки -- это, конечно, ай-яй-яй, как так можно, вывод в консоль перекосило из-за этого."Автор, какой if?:) Случаем toml формат знаете? INI ближний формат, какой там if?:)
"Вот к чему есть вопросы, так это к производительности этой реализации."
?:) Тоесть ваших знаний не хватило на элементарное в rust, но при этом вы делаете такие выводы?:)
> Автор? ты из какой нAры вылез, а ну влезай обратно))
> 1. lazy_static крейт для безопасной инициализации статической переменной при обращении,
> да, там действительно есть проверка была ли инициализирована ранее переменная при
> обращении к самой переменной.
> 1. и нет, mutex там нет и refcell нет, еще че придумали,
> refcell работает безопасно лишь в однопотоке предоставляя безопасную изменчивую переменную
> да И ЗАЧЕМ ОНО ЗДЕСЬ...
> 2. lazy_static работает в многопотоке ИСКЛЮЧИТЕЛЬНО на атомарных значениях, он не предоставляет
> гарантий гонок изменчивости переменной, только на атомарах гарантию одноразовой инициализации
> в многопотоке.У тебя нумерация поехала. Но, может быть. И чё? Это всё что ты тут написал, как-то отменяет выводы сделанных мною?
> "Но вот то, что они позволяют себе писать Cargo.toml, не добавляя lf
> в конец последней строки -- это, конечно, ай-яй-яй, как так можно,
> вывод в консоль перекосило из-за этого."
> Автор, какой if?:) Случаем toml формат знаете? INI ближний формат, какой там
> if?:)Ты очки давно протирал? i от l не отличаешь? toml, INI или что там, но если это текстовый формат, то последним символом файла должен быть lf, то есть line feed. Запомни это.
> "Вот к чему есть вопросы, так это к производительности этой реализации."
> ?:) Тоесть ваших знаний не хватило на элементарное в rust, но при
> этом вы делаете такие выводы?:)Ох-ох-ох. Какие интересные личные атаки. Ты не стесняйся, продолжай хвастаться своими познаниями, всем очень интересно, все внимательно слушают.
"У тебя нумерация поехала"
И это весь ваш ответ, да? Яснопонятно.
Нет, не поехала нумерация, так и должно.Отменяет ли это неуклюжие выводы автора? Если анализировать, а не тупо втыкать, то 10000% из 100 да.
"но если это текстовый формат, то последним символом файла должен быть lf, то есть line feed"
Смешно, не требуется. Адекватным парсерам всеРавно на наличие конечного /n, если у вас парсер тупо складывается из разделений по /n и потом лишь декодинг то это не парсер, а так.. халтура школьника.
Парсер который и парсит этот файл подтверждает то что наличие конечного /n или множественных /n/n не существено.
"хвастаться своими знаниями"
Автор.., где ты увидел "хвастаться", в этом последнем предложении???..
Тоесть указание на то что ваши выводы высосаны из пальца это "хвастаться"??
С вами все хорошо?...
Если хотите по существенному спросить про раст то приходите к нам в русский чат в телеге, на все ваши странные вопросы ответим.
> Но вот то, что они позволяют себе писать Cargo.toml, не добавляя lf в конец последней строки --
> это, конечно, ай-яй-яй, как так можно, вывод в консоль перекосило из-за этого.а у них в виндовой консоли - ничего не перекашивается. Как думаешь, кому надо свою консоль поменять на адекватную?
> Вот к чему есть вопросы, так это к производительности этой реализации. Она
точно такая же как во флэше до-mp4й эпохи. Без всяких аппаратных ускорений и прочей чуши - кодек не ресурсоемок а битрейты того контента невелики.
Если твой компьютер и браузер (последнее немаловажно есил ты собираешься использовать веб-версию) вообще тянут ruffle - видео-вставки тоже потянут.
Эта ветка уже больше года активно используется теми, кому надо было флэшовой порнухи с видео-элементами. Сейчас ее просто влили, наконец-то, в основной проект.
Так уже делали даже avi на хрусте, вот только производительность все равно оставляла желать лучшего. А тут про неё как раз не слова. Ну и видеокодек такая весч что можешь на некоторые вещи забить и оно все равно будет работать. Не так хорошо как полноценный кодек, но кого волнуют такие мелочи.
> кто-то переписал относительно полноценный и стандартный видеокодек (мало кто может это делать) на чём-то отличном от ЦВо-первых, только ДЕКОДЕР. Попрошу не путать ДЕКОДЕР и ЭНКОДЕР, который в десятки раз сложнее.
Во-вторых, за почти 30 лет на чем только его не переписывали. Разве что на брейнфаке, и то не факт.
> Во-первых, только ДЕКОДЕР. Попрошу не путать ДЕКОДЕР и ЭНКОДЕРА кто путает?
>который в десятки раз сложнее.Если реализуют и его, то я напишу, что это бутафория, ибо копирование алгоритма сойдёт только для бенчмарка. Вот если сделают как zophli для DEFLATE, только их энкодер для h.263, то может и гляну.
Нафига этот кодек, если аппаратное декодирование было уже более 10 лет назад. А AV1 - говно какое-то, 5 секундное видео час на CPU закодировать не смогла реализация в FFMPEG.
Только вот основные видеосервисы Youtube и Netflix переходят на AV1
263? Аппаратное декодирование? Никогда не замечал его в va/vdpau, вы про какое аппаратное говорите?:) Несусветное?:))
AV1 оптимизируется для малого размера и более эффективного стриминга. Скорость кодирования на твоем пеньке никого не волнует, а вот стоимость места и стриминга с серверов ютуба и прочих -- очень даже.
Неиллюзорно плюсую!
> AV1 оптимизируется для малого размера и более эффективного стриминга.по-моему он оптимизировался исключительно чтоб денег за патенты никому не платить. А эффективный кодировщик сперва все обещали как только так сразу, а теперь уже и не перестали обещать. Наверное, хруст ему тоже не поможет.
> Скорость кодирования на твоем пеньке никого не волнует, а вот стоимость места и
наоборот, большинство вменяемых людей волнует исключительно скорость кодирования на их железе. А не проблемы ютуба и ютуба. Которому все желают только счастливого банкротства.
> стриминга с серверов ютуба и прочих -- очень даже.Поэтому он и нах никому не нужен - кроме борцунов за стоимость места на серверах ютуба.
Которые тоже давно уже пришли к выводу, что нужен не av1 а изменить ToS, чтобы "удалять контент пользователей, не приносящий коммерческой выгоды".Что мега-фермы по перекодированию обходятся в этом свете дешевле чем просто линейное расширение хранилок - в общем-то тоже совершенно неочевидно - даже в масштабах гугля. Гугль не раз и не два замечен в глупом хайпе, не имеющем ни малейших экономических обоснований.
Надо переписать на ADA и COBOL
И на PL/1.
Хмммм...Prolog! Хватит это терпеть!
Между прочим на Аде до сих пор пишут
Да, кое что пишут. И лучше бы уж на Аде, чем на расте. А ещё лучше для флеша: штурман, да закопайте уже стюардессу.
> Rust
> FlashДвойное ненужно в одном проекте
Нужно было писать на китайском.
Rust это C++ курильщика, а не замена C
>курильщикаДезоморфинщика
В Rust нет полноценного ООП, это какая то лютая смесь Си и Go, только с отвратительным синтаксисом
> нет полноценного ООПВы хотели написать - привычного? Полноценного - по-Вашему это какого, такого как в С++/Java/...?
Это не то полноценное ООП, которое задумывалось изначально.
Расскажи за наследование
Rust - это вообще даже близко не C++ в любом виде, и это его несомненный плюс. Одного C++ вполне достаточно, чтобы превратить любой проект в кучу нечитабельного хлама, в котором 30% - boilerplate (всякие конструкторы копирования и т.п.) или баги в маскхалатах, второй такой монстр не нужен. Я уже молчу про размер стандарта, который не влезает ни в один череп homo sapiens. Что касается синтаксиса Rust, он выглядит нечитабельным только для тех, кто не хочет учиться, и у кого стокгольмский синдром после многолетнего насилия над мозгом со стороны таких прекрасных синтаксисов, как у C++, а у остальных людей такая мелочь проблем не вызывает. Местные синтаксические страдальцы выглядят так же глупо, как казах, жалующийся, что грамматика итальянского языка не такая, как в русском.
Тем не менее, Rust уже очень сильно разросся.> Что касается синтаксиса Rust, он выглядит нечитабельным только для тех, кто не хочет учиться, и у кого стокгольмский синдром после многолетнего насилия над мозгом со стороны таких прекрасных синтаксисов, как у C++
Да нет, после С++ он как раз читаем. Он нечитаем после Ocaml, Haskell и Python'а.
Что до читабельности Haskell, это нивелируется обилием операторов и попыткой имитации синтаксического сахара посредством комбинации ФП и ленивых вычислений. Вторая проблема присуща всем диалектам Lisp: красиво звучит в теории, а на практике абсолютно нечитабельно, потому что при первом взгляде на конструкцию совершенно непонятно, что это - встроенная фича языка или макрос, содержимое которого тебе придётся прочитать, прежде чем появится хотя бы намёк на понимание сути.
А вот и очередной неосилятор с++ подъехал.
Он не понимает что такое конструктор копирования и зачем нужен. Поэтому ушел зубрить let mut ^<kokoko>.А впрочем, может оно и к лучшему. Неспособные понять элементарных алгоритмических конструктов действительно должны сидеть в каком-то тихом уголке и страдать, а не мешать людям работать.
> А вот и очередной неосилятор с++ подъехал.А вот и очередной "делаю выводы по одной фразе" подъехал.
> Он не понимает что такое конструктор копирования и зачем нужен. Поэтому ушел
> зубрить let mut ^<kokoko>.Я знаю, зачем он нужен, но не понимаю, за каким чёртом в нормальном языке его нужно объявлять, чтобы запретить его использование. Видимо, ещё недостаточно нейронов отмерло, чтобы такое решение выглядело логично. Зато понимаю, почему это нужно в С++ (потому что язык прекрасен, как толстая кишка Афродиты). И причём тут вообще let mut? Просто так сболтнул, чтобы показать, что видел синтаксис издалека? Аналог в Rust - трейт Clone.
> А впрочем, может оно и к лучшему. Неспособные понять элементарных алгоритмических конструктов
> действительно должны сидеть в каком-то тихом уголке и страдать, а не
> мешать людям работать.Ну да, куда мне до местных экспертов, у которых C++ - это эталон ЯП, а конструктор копирования - не синтаксическая условность, обусловленная устаревшей семантикой C++, а "алгоритмический конструкт", правда не имеющий ровно никакого отношения к алгоритмам, которые реализуемы в любом другом ЯП без конструктора копирования.
TL;DR
Я тупой, а ты - нет. Наслаждайся превосходством.
> не понимаю, за каким чёртом в нормальном языке его нужно объявлять, чтобы запретить его использованиеЭмммм, а вы хотели бы, чтобы компилятор С++ телепатически связывался с вами, без декларации вашего намерения? Или как? Хочешь что-то объявить - объявляесь пальчиками в текстовом файле.
А то, что вы не понимаете, зачем эти конструкторы нужны и зачем их переопределяют (да-да, в 99,99999999% случаев их переопределяют, а не запрещают) - лишнее подтверждение моей интуитивной догадки выше.
> C++ - это эталон ЯП
Не эталон ни разу.
> у которых C++ - это эталон ЯП, а конструктор копирования - не синтаксическая условность, обусловленная устаревшей семантикой C++, а "алгоритмический конструкт"
А-ха-ха-ха-ха-ха.
Ну вот и еще одно признание в том, что вы не умеете в алгоритмизацию. Эта "синтаксическая условность, обусловленная устаревшей семантикой C++" есть во многих других языках.> устаревшей семантикой C++
Лучше пока еще не придумали.
>Эмммм, а вы хотели бы, чтобы компилятор С++ телепатически связывался с вами, без декларации вашего намерения? Или как? Хочешь что-то объявить - объявляесь пальчиками в текстовом файле.Совсем уже мозги сгнили с плюсовыми шаблонами? Уже русский не понимаешь?
Человек выше, как раз, не хочет никакой телепатии от компилятора. Он как раз хочет что б все прописывалось явно. Не прописал программист конструктора копирования - и все, нет у класса никакого конструктора копирования.
> Он как раз хочет что б все прописывалось явно.а ему противостоит толпа людей, которые этого не хотят и C++ здесь ни при чем. Мне даже стало интересно в каком языке сделано как человек хочет, без этих всяких конструкторов по умолчанию и чего-то типа copy/deepcopy с поведением по умолчанию
> Мне даже стало интересно в каком языке сделано как человек хочет, без этих всяких конструкторов по умолчанию ...такое сделано в расте. Есть только то, о чем программист явно написал. Ничего не неписал - ничего и нет.
> а ему противостоит толпа людей, которые этого не хотят и C++ здесь ни при чем.
Да, С++ тут нипричем. Причем тут местные юродивые, у которых при слове "раст" падает планка и они начинают спорить со своими больными фантазиями.
> такое сделано в расте. Есть только то, о чем программист явно написал. Ничего не неписал - ничего и нет.Че, рили? Хотите сказать, раст не умеет копировать объекты?
Так вы еще и растонеосилятор?
Раст умеет копировать объекты. Глубокое копирование (Clone) нужно писать самому. Не делай вид, что не понял, выглядит крайне глупо.
Ну вы, анонимы, совсем того... даже гнить нечему, как видно.Есть всего три возможных варианта копирования объектов:
1.
В С++: если надо скопировать объект, он копируется побитно (shallow-copy). Код, который это делает, называется "конструктор копирования по умлочанию". Ничего писать не надо.В расте: если надо скопировать объект, он копируется побитно (shallow-copy). Код, который это делает, никак не называется. Ничего писать не надо.
2.
В С++: если надо скопировать объект рекурсивно (deep-copy), для этого надо написать свой код. Код, который это делает, называется "конструктор копирования".В расте: если надо скопировать объект рекурсивно (deep-copy), для этого надо написать свой код. Код, который это делает, никак не называется.
С единственным отличием - если этот объект из вашего хелловорлд и не содержит ничего сложнее парочки стандартных базовых типов, то для этого для макак в расте уже заготовили конструкт под названием "Trait std::clone::Clone".
3.
В С++: если надо скопировать объект кастомно (custom-copy), для этого надо написать свой код. Код, который это делает, называется "конструктор копирования".В расте: если надо скопировать объект кастомно (custom-copy), для этого надо написать свой код. Код, который это делает, никак не называется.
--
Ну так в чем проблема, мартышка? Не можешь осилить элементарных алгоритмических конструкций? Так иди на джаваскрипте пиши, там такие тысячами нужны.
> В расте: если надо скопировать объект, он копируется побитно (shallow-copy). Код, который это делает, никак не называется. Ничего писать не надо.https://doc.rust-lang.org/nightly/core/marker/trait.Copy.html
By default, variable bindings have ‘move semantics.’ In other words:
#[derive(Debug)]
struct Foo;let x = Foo;
let y = x;
// `x` has moved into `y`, and so cannot be used
// println!("{:?}", x); // error: use of moved value
However, if a type implements Copy, it instead has ‘copy semantics’
move
Ну так в чем проблема, мартышка? Не осилил документацию? Или не отличаеш копирования(copy) от перемещения(move) ?
Ты всё ещё не привёл обоснования того, как конструктор копирования связан с алгоритмами. Для людей с плохой памятью напоминаю, что алгоритмы прекрасно реализуются на любом Тюринг-полном ЯП, большинство из которых не имеют такого понятия, как "конструктор копирования". Ну, так какая тогда связь?
Вообще-то имеют, только называются по разному.
1. Не вижу примеров.
2. Ты так и не ответил на вопрос: какое отношение конструктор копирования имеет к алгоритмам? Это уже какой, третий раз, как я задаю этот вопрос, а ты уклоняешься от ответа?
Я тебе ответил, несколько раз. Повторить?
Повтори, а то я найти не могу ни в одном твоём сообщении ответа на конкретно этот вопрос. А я, на всякий случай, повторю вопрос, чтобы ты случайно не начал отвечать на другой: какое отношение конструктор копирования имеет к алгоритмам?
у тебя короновирус выявили?
И ты сейчас такой весь в белом, покажеш нам свои супероптимизированные и супернужные проекты, на этом лаконичном и простом языке? Нет? Ну... как всегда.
А ты уже показал свои супероптимизированные и супернужные проекты?
Или так просто языком мелешь?
Аа, ну как всегда, метание стрелок и увиливание, любители ржавого во всей красе.
На всякий случай, для особо приплюснутых, поясню: в Rust тривиальный "конструктор копирования" за тебя тоже сгенерит компилятор, а если нужно глубокое копирование, то ты реализуешь трейт Clone для своего типа. Соответственно, если оно не нужно, то и делать ничего не нужно, в отличие от C++.
Ну да, чудо компилятор, слышали... знаем
Бессмысленный ответ, единственная цель которого - накинуть на вентилятор. По сути-то есть, что сказать?
Есть, где ООП?
Структуры и трейты. Или ты думаешь, что ООП - это только то, что в C++ и Java? В том же чистом C вообще нет синтаксиса для этого, но в нём тоже можно делать ООП, что наглядно демонстрируют, например, Linux и Glib.А вообще, при чём тут ООП? Можно подумать, это единственный способ писать понятный код, без которого ЯП априори бесполезен.
> А вообще, при чём тут ООП? Можно подумать, это единственный способ писать понятный код, без которого ЯП априори бесполезен.Для хелловорлда - нет, не единственный. Для сложных проектов, к сожалению, единственный.
ООП позволяет создать максимально сложную архитектуру софта максимально понятной и гибкой для ее дальнейшего расширения... а для статичного хеллруворлда ООП как сказано выше не требуется
И да структуры и трейты это лютый костыль, рушащий инкансуляцию
Каким образом они рушат инкапсуляцию?
В ООП одна сущность это класс в котором инкапсулирован весь код отвечающий за поведение классаВ расте какая то мазня кода между трейтами и структурами
В парадигме ООП нигде не сказано, как конкретно должен быть организован код. Структуры есть, наследование делегацией есть, методы у структур и трейтов есть. Если, по-вашему, этого и всего остального функционала Rust недостаточно для ООП, у вас какое-то своё определение ООП, созданное для удобства аргументации вашего мнения или по ошибке.
Без стеба почитай за ООП хотя бы Сенди или Вайсфельда... обьект это сущность, то есть единое целое или пакетИнкапсуляция это не только про права доступа private/public
Во-первых, я нигде ни слова не сказал про private/public, это лишь проекция твоих предрассудков на мои аргументы, а вовсе не мои аргументы.Во-вторых, инкапсуляция может достигаться разными методами - в том числе, трейтами и модулями. В Rust базовая единица инкапсуляции - модуль, в рамках которого организуется и сокрытие данных, и привязка методов к структурам. Модуль - это и есть "пакет" в твоей терминологии.
Что ты несешь?
Я несу знамя просвещения. Только, судя по всему, не туда.
Кроме того, инкапсуляция вообще ортогональна расположению методов. Абсолютно неважно, находятся они в классах или трейтах. Почитайте определение инкапсуляции, что ли. Вообще, у вас какая-то каша в голове. Нахватались терминов, а их истинного значения не понимаете, если судить по вашей писанине.
Что за истинное значение? Истиннное ООП, истинное значение... что ты скрываешь?
Есть открытые источники определений тех терминов, вокруг которых разгорелась эта дискуссия - та же Википедия, для начала. Прочитай определения и дай ссылку на то, по которому Rust не умеет ООП.
Конкретизируем, где наследование?
Наследование делается делегацией трейтов. То есть, вместо того, чтобы наследовать всё поведение базовой структуры, ты выбираешь, какие трейты реализовать для производной, и делегируешь их базовой. В Rust вообще поведение определяется трейтами, если брать конкретно парадигму ООП. То есть, поведение чётко отделяется от объекта. В идеальном ООПшном мире у структуры будет только "конструктор" и реализации трейтов. Это гибче, чем наследование, и, на мой взгляд, правильнее.
Это не наследование, это костыли "собери из трейтов новый объект".
Допустим на минуту, что ты прав, и это костыли. Даже если и так, это всё равно позволяет реализовать наследование, а значит, удовлетворяет критериям ООП, что ты изначально пытался оспорить.
Не, ну с тем, что "позволяет реализовать наследование [а так же инкапсуляцию и полиморфизм - Урри], а значит, удовлетворяет критериям ООП" я спорить, конечно, не буду.Только толку в этом? Если ООП даже в жабоскрипте есть. Почти такой же костыльный, но правда хуже.
> Есть, где ООП?Вот ты сам и ответил на свой вопрос. Полагаю, дискуссию на этом можно завершить.
Оу, а вы у нас не только С++ неосилятор, но еще и Rust неосилятор?"This trait can be used with #[derive] if all fields are Clone."
И тут внезапно оказывается, что в расте тоже надо вручную описывать конструкторы копирования в любом, мало-мальски более сложном чем хелловорлд проекте. Какой обломс...
Зато если тебе не нужен Clone, ты его просто не реализуешь - и всё. В С++ же ты должен конструктор копирования объявить, даже если он не то что не нужен, но и нежелателен. При этом есть ещё оператор присвоения, который обычно идёт в паре и делает то же самое, и его тоже нужно объявить в private, если хочешь его запретить.Л - логика!
> В С++ же ты должен конструктор копирования объявитьЯ же говорил неосилятор. Не должен.
> но и нежелателен
А вот если он именно что НЕ нужен - то ты открыто говоришь "я запрещаю копировать эти объекты" с помощью "= delete". В чем проблема?
p.s.
> не то что не нужен, но и нежелателенПогроммист детектед. У него есть "нежелательное поведение кода". Ну, типа - "пускай оно работает, но не очень хотелось бы".
Жалкие попытки придираться к словам, лишённые сути.
Скорее это как C++, но по сути это C:) Итого вкусно.
В этом весь раст. Пилить никому не нужное кривое поделье. Ну и конечно так и не закончить.
Наконец-то что-то написали на расте. Фанатики ликуют.
написали эмулятор того, что выкинули 9 лет назад за ненадобностью...
Ну не совсем так не выкинули за ненадобностью, а вытеснил W3C постепенным перетаскиванием в браузер всех функций из Flash, а сегодня еще и WebAssembly запилил (окнчательно перетащив функции Flash в браузер). В целом-то я считаю, что тут обычная конкуренция... С другой стороны Macromedia и Adobe могли бы в самом начале раскрыть стандарт и разрешить всем использовать его на добровольной основе. Тогда бы сейчас WebAssembly был бы просто тупо ActionScript-ом.А что касаемо реализации если бы кто-то довел до нормлаьного уровня, то мог бы получиться еще один .NET, Java и т.п. с прицелом на десктопные приложения. Хотя зачем еще одна витуальная машина непонятно.
Только кому нужен Flash? Наверно тем что воют о поддержке их 80386
Тем временем шёл 51-й год использования языка Си.
Хороший аргумент. Латынь тоже давно используют.
Да, хороший. Латынь действительно используют там, где нужна точность формулировок.
А неосиляторы используют пиджин.
Вижу, у тебя мир чёрно-белый и разрабы делятся на осиляторов и неосиляторов. Между прочим, я не пытался сравнить С и латынь, а лишь указал на абсурдность аргумента "давно используется".
Да я так, уже совершенно откровенно троллю. В этой теме по делу же уже совсем нечего обсуждать.
А если бинарник скачать, то там будет? Или надо собирать с флагом I_DONT_CARE_ABOUT_PATENTS
Походу, не будет - во всяком случае моя попытка хоть к какому делу приспособить эту хрустоподелку - опять закончилась фейлом с руганью на "неизвестный видеокодек".Учитывая что там swf с фотками из под лайтрума (то есть 2008й какой-то год - умел тогда лайтрум в "фотоальбом" на флэше, кстати, работало даже на тех компьютерах без всяких тормозов) - вряд ли мог быть еще какой-то еще более неизвестный кодек.
(где уж он там _видео_ использовал - хз, я всегда думал что он только рамочки вокруг жпегов рисует. Ну, в общем, рамочки хрустоподелка мне и отрисовала. Фоток не показала.)В общем, escopeta.swf ее единственное применение, ныне, присно и вовеки...а, хотя нет. Через пару лет уже и не собрать будет.
Flash... Rust...но зачем? В чем смысл?
Нужно же что-то делать.
Смысла в жизни как такового нет вообще.
Исповедь растомана
Запускать flash в wasm:) Тоесть в браузере)
Когда собаке делать нечего -- она это самое лижет.
Новость попахивает желтухой, как можно реализовать кодек на чистом расте с приемлемой производительностью без задействования ассемблерных инструкций аппаратного ускорения проца хотя бы? Даже сишные либы на треть обмазаны ассемблерными вставками, но вот раст не такой, да? он особенный, каким то чудом сам все ускоряет и умеет... хм...
1) не стоит верить в ассемблер, как могучую лампу Аладина
2) это старый кодек 1996-2005 года
Растоманы отменяют ассемблер? Хм интересно... сразу в машинных кодах пишите? Или машинные коды тоже отменить? И запустить раст сразу в мянямирке растомана?
Я здесь, лампу не дам.
А когда-то и mp3 не каждый компьютерный процессор тянул...
Сейчас в это трудно поверить.
Только вот музон за последнии годы не особо потяжелел даже во FLAC, а вот 4К видео это тебе не 320×240
> а вот 4К видео это тебе не 320×240Так а сабж причём? Не причём. Там во всяких флешках пятнадцатилетней давности такого и не будет.
Притом что такие жирная операция как декодирование напрямую зависит от аппаратной поддержки проца(тобишь его сопроцессора AVX/SSE/MMX) доступ к которому можно получить только из мненомик машинных команд... из ЯП будь то Си или C++ доступ к возможностям конкректного процессора закрыт
> Притом что такие жирная операция как декодирование напрямую зависит от аппаратной поддержки
> проца(тобишь его сопроцессора AVX/SSE/MMX) доступ к которому можно получить только из
> мненомик машинных команд... из ЯП будь то Си или C++ доступ
> к возможностям конкректного процессора закрытКакой же ты все-таки балабол ...
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/X86-Built-in-Fu...
> The following built-in functions are available when -mavx is used. All of them generate the machine instruction that is part of the name.
v4df __builtin_ia32_addpd256 (v4df,v4df)
v8sf __builtin_ia32_addps256 (v8sf,v8sf)
v4df __builtin_ia32_addsubpd256 (v4df,v4df)
Васян ты конечно огонь, то есть факел потухший, а ниче что выбор расширений поддерживаемых на конечном проце происходит на стадии исполнения, а не компиляции? Или ты ванга которая заранее знает какой набор инструкций поддерживает проц конечного пользователя? Вот он удивится неработающей программе оптимизированной компилятором под AVX при том что его проц поддерживает SSE... жги дальше
> Или ты ванга которая заранее знает какой набор инструкций поддерживает
> проц конечного пользователя? Вот он удивится неработающей программе оптимизированной
> компилятором под AVX при том что его проц поддерживает SSE... жги дальшеБалаболка, ты бы вместо неуклюжего юлежа и надувания щечек - по ссылке бы сходил, носом в пример там же ткнулся бы:
> — Built-in Function: void __builtin_cpu_init (void)
> This function runs the CPU detection code to check the type of CPU and the features supported.
> This built-in function needs to be invoked along with the built-in functions to check CPU type and features,...
> The CPU detection code is automatically executed in a very high priority constructor.
>static void (*resolve_memcpy (void)) (void)
{
// ifunc resolvers fire before constructors, explicitly call the init
// function.
__builtin_cpu_init ();
if (__builtin_cpu_supports ("ssse3"))
return ssse3_memcpy; // super fast memcpy with ssse3 instructions.
else
return default_memcpy;
}
void *memcpy (void *, const void *, size_t)
__attribute__ ((ifunc ("resolve_memcpy")));
Что тебе даст вызов CPUID если у тебя нет нескольких меток ассемблерного кода, чтобы перейти на нужный адрес SSE или AVX инструкций?
> Что тебе даст вызов CPUID если у тебя нет нескольких меток ассемблерного
> кода, чтобы перейти на нужный адрес SSE или AVX инструкций?Что тебе дает чтение жопой?
if (__builtin_cpu_supports ("ssse3"))
return ssse3_memcpy; // super fast memcpy with ssse3 instructions.
else
return default_memcpy;
...
The following built-in functions are available when -msse3 is used. All of them generate the machine instruction that is part of the name.v2df __builtin_ia32_addsubpd (v2df, v2df)
v4sf __builtin_ia32_addsubps (v4sf, v4sf)
v2df __builtin_ia32_haddpd (v2df, v2df)
Глаза на жопе отрастил?
Раскажи как будут выполняться AVX на проце который AVX не поддерживает или не поддерживает более новую версию AVX? Совместимость то обратная пупсик
1. Пошлет пользователя нафиг (что и произойдет при старте игры)
2. Иногда в прогах за счет runtime условий можно задействовать определенный набор функций (как раз ваш AVX), но это сложно в плане оптимальности, но возможно.
2. Это уже JIT/AoT
Кто мешает скомпилировать несколько dll/so объектов (для процов с SSE/AVX и для генериковского условного i686...x64 проца с дефолтной "неоптимальной" обработкой), а в начале работы программы проверить все флаги и подгрузить/слинковать динамически только нужные библиотеки? Код ядра программы в таком случае даже не будет внутри всякие проверки на архитектуру проца делать ( не нужны if(_есть_SSE3){...}... ), будет дергать импортированные функции.
>> Иногда в прогах за счет runtime условий можно задействовать определенный набор функций
> 2. Это уже JIT/AoT"Когда думаешь, что дно пробито - Хан стучит снизу ..."
man ifunc
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...
extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
23 extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
24 extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
25 extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
26
27 static inline void *
28 IFUNC_SELECTOR (void)
29 {
30 const struct cpu_features* cpu_features = __get_cpu_features ();
31
32 if (CPU_FEATURE_USABLE_P (cpu_features, AVX2)
33 && CPU_FEATURE_USABLE_P (cpu_features, BMI2)
34 && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
35 {
36 if (CPU_FEATURE_USABLE_P (cpu_features, AVX512VL)
37 && CPU_FEATURE_USABLE_P (cpu_features, AVX512BW))
38 return OPTIMIZE (evex);
39
40 if (CPU_FEATURE_USABLE_P (cpu_features, RTM))
41 return OPTIMIZE (avx2_rtm);
42
43 if (!CPU_FEATURES_ARCH_P (cpu_features, Prefer_No_VZEROUPPER))
44 return OPTIMIZE (avx2);
45 }
46
47 return OPTIMIZE (sse2);
48 }
Ого научился считывать в структуру CPUID? Я просто похлопаю... но есть одно но, а на кой черт тебе инфа о CPUID если ты не используешь ассемблерные вставки отдавая все на откуп компилятора?Короче 1 сентября уже близко школьник
> Ого научился считывать в структуру CPUID? Я просто похлопаю... но есть одно но, а на кой черт тебе инфа о CPUID если ты не используешь ассемблерные вставки отдавая все на откуп компилятора?Память как у балаб^W рыбки?
Ну, смотри:
> (Балабол) декодирование напрямую зависит от аппаратной поддержки проца(тобишь его сопроцессора AVX/SSE/MMX) доступ к которому можно получить только из мненомик машинных команд... из ЯП будь то Си или C++ доступ к возможностям конкректного процессора закрыт
> (Аноним) The following built-in functions are available when -mavx is used. All of them generate the machine instruction that is part of the name.
> v4df __builtin_ia32_addpd256 (v4df,v4df)
В общем, даже для тебя слишком неуклюжий спрыг.
> Короче 1 сентября уже близко школьник
Эк тебя расперло. Смотри, лужа уже закипать начала, обваришься ...
Сишные обертки для неосиливших ассемблер, которые генерируют хрен пойми какой машинный код? Это сильно, от такого ужаса не приведи господь и обделаться можно
> Сишные обертки для неосиливших ассемблер,Не, это не для тебя.
> "All of them generate the machine instruction that is part of the name."
> _builtin_ia32_addpd256
> которые генерируют хрен пойми какой машинный код?Т.е. ты ни в асм, ни в английский не умеешь. И почему я не удивлен.
> Это сильно, от такого ужаса не приведи господь и обделаться можно
Да мне вообще-то все равно, от чего ты обделался.
> из ЯП будь то Си или C++ доступ к возможностям конкректного процессора закрытОткуда на опеннете такие "эксперты" плодятся? Современные компиляторы умеют в векторизацию кода. Они несовершенны, конечно, и не всё, что можно напилить вручную ассемблерным кодом, удастся получить программой на чистом C. Но тем не менее компилятор может иногда удивлять. Даже C'шный, иногда даже когда он работает без подсказок, навроде const и restrict. Особенно агрессивный инлайн всего помогает таким оптимизациям: компилятор сам без подсказок начинает видеть всё, что надо.
Доступ к векторным инструкциям открыт, но ограничен а) способностями оптимизирующего компилятора, б) способностями программиста писать код, на котором способности компилятора раскроются.
Ага, вот оно что михалыч... компилятор видимо скайнет писал и ассемблер не нужон? Только один вопрос друг мой, компилятор обладает даром провидения на каком проце запустится сгенерированный им код или тупо фигачит под условный x86 с минимальной версией SSE, а если у тебя более крутой AVX? И че тогда? AVX который при должном подходе производительнее SSE в разы не нужон? Или ты все таки вкорячишь в свой код ассемблерные вставки под разные поколения архитектуры x86 с проверкой на том же асссемблере того что поддерживает проц а что нет?
> Ага, вот оно что михалыч... компилятор видимо скайнет писал и ассемблер не
> нужон?Ты читать умеешь? Где ты, нет, вот скажи мне, где ты увидел, что я сказал, что ассемблер не нужен? Хан, где я сказал, что ассебмлер не нужен, а Хан?
Нет, я серьёзно говорю: не надо больше писать свой бред. Ты остановись, выдохни, успокойся. Выпей таблетки, подожди пару часов (или у тебя долгоиграющие? подожди пару суток тогда). И после этого, спокойно, не спеша, выбери цитату меня вместе с контекстом, где я это сказал, и оставь её ответом на это сообщение.
Не спеши ни в коем случае, не позволяй скакунам твоих мыслей забегать вперёд черепахи твоего рационального мышления и улитки твоей способности к ведению дискуссию. Нет причин спешить: я никуда не денусь отсюда. Дискуссия -- это не блиц в шахматы, где тебе даётся 10 минут, и ещё по 5 секунд за каждый ход накидывается. В дискуссии ты можешь остановится, подумать, подумать ещё раз, лечь поспать, и ответить назавтра, когда наконец додумаешь все мысли. Не спеши, успокойся.
> компилятор видимо скайнет писал и ассемблер не нужонВот это ты реально убогонький. Ты же в терминологии путаешься.
Что такое компилятор, что такое ассемблер. Что божий дар а что яишница.Так что компилятору с языка С, например, ассемблер может быть нужон, а может и не нужон. Это как решат разработчики компилятора.
И вот еще штука какая, асссемблеру то самому компилятор нужОн, валенок. Ассемблер - это тоже ЯП.
И он (компилятор ассемблера), тоже не скайнет, и не знает на каком проце бинарь будут запускать, потому он генерит бинарь так как ему написали в исходниках, указали через опции компиляции.
Ты сейчас а каком классе информатику проходишь? Школота...Ассемблер состоит из мнемоник которые имеют однозначный эквивалент в машинных кодах, так что ЯП он чисто номинально, хотя для деток перед 1 сентября поясню что все что не 010101100 это уже технически ЯП, но фактически это мнемоническое представление машинных команд в масштабе 1:1
Ассемблеру нужен компилятор? Вот те на, а я то думал что процессор напрямую может текст читать, прям неожиданность какая-то, ты че капитан очевидность?
Последнее решается включением в код CPUID, условного перехода и двух меток SSE или AVX
Вообще садись за парту тебе два, завтра родителей в школу
ути пути, хан обосpамшись, пытается перейти на личности.
Но не боись, я еще в том возрасте когда маразма еще нет, как у тебя, болезного.Мне вот не приходит на ум сравнивать компилятор с ЯП.
Всем побоку в каком ты возрасте, растодырка
> Ты сейчас а каком классе информатику проходишь? Школота...
> Ассемблер состоит из мнемоник которые имеют однозначный эквивалент в машинных кодах
> фактически это мнемоническое представление машинных команд в масштабе 1:1З-знаток.
NASM
%macro sz 2
jmp %1_after_def ; jump over the string that we define
%1 db %2, 0 ; declare the string
%1_after_def: ; continue on
%endmacroFASM
; display directive displays the message at the assembly time.
bits = 16
display 'Current offset is 0x'
repeat bits/4
d = '0' + $ shr (bits-%*4) and 0Fh
if d > '9'
d = d + 'A'-'9'-1
end if
display d
end repeat
display 13,10MASM
entry_point proc
call Select_Option
.if choice == IDYES
void = MsgBox(0,"You chose YES","Result",MB_OK)
.else
void = MsgBox(0,"You chose NO","Result",MB_OK)
.endif
.exit
ret
entry_point endp
> Школота...
> для деток перед 1 сентября
> завтра родителей в школуСудя по всему, об ассемблере ты в последний раз слышал в школе ...
Он отменил ассемблер, теперь ассемлер не нужон, расходимся
Хан, я, как человек, который писал гуглу глубокие оптимизации кода, ответственно заявляю - вы болван. Все, что вы написали выше - это дилетантсткие рассуждения, имеющие под собой только недостаточную образованность в вопросе.Лучше бы загуглили то, что вам поотписывали и подняли свой уровень. После чего сами бы могли легко и с апломбом садить в лужу подобных вам сейчас.
--
Львиную долю всех возможных "ассемблерных" оптимизаций полностью закрывают интринсики. С абсолютно достаточным доступом до низкоуровневых процессорных команд.Причем закрывают очень хорошо, много лучше и быстрее, чем ручная оптимизация ассемблерными инструкциями, позволяя организовывать дополнительную оптимизацию компилятором не вычисляя больше ручками конкретные нужные в данный момент регистры.
Единственное, для чего в последнюю пятилетку пришлось использовать ассемблерный код - это реализацию кастомного ffi (по некоторым причинам libffi не подошла).
И это просто адовая работа, я вам скажу. Потому как для разных arm32, например, приходится писать разный, хотя один и тот же самый, код, разбавляя его ифдефами вроде __ARM_ARCH_4T__ и тыкая где пары mov/bx, а где blx. В то время как соответствующие интринсики подобный вопрос бы закрыли.--
Не верите? Попробуйте сами. Напишите idct (благо примеров в сети море) на асме и чистыми сишными интринсиками.
Счетчики, для начала, можно снимать с помощью "sudo perf stat". Вот такие:45,93 msec task-clock # 0,960 CPUs utilized
5 context-switches # 0,109 K/sec
0 cpu-migrations # 0,000 K/sec
639 page-faults # 0,014 M/sec
136 701 189 cycles # 2,976 GHz
345 410 549 instructions # 2,53 insn per cycle
52 325 735 branches # 1139,209 M/sec
448 248 branch-misses # 0,86% of all branches
Хаха о даааа... какой я дилетант мне говорит чел который ассемблера боится и юзает сишные оберточки от компилятора и советует забить на ручную оптимизацию ведь компилятор сделает все сам? Чем ты там занимался в гугле? Оптимизациями без оптимизаций? Хмммм....
С чего ты взял, что я боюсь ассемблера?А вообще, у меня появилась идея... Как насчет на деле тестануть ручную оптимизацию против машинной? Ну ты такой уверенный, и я такой уверенный - может решим спор не словами а делом?
Мое предложение взять нужную всем и каждому числодробилку. Например, idct.
Я выложу на пейстбин кусок idct на SSE4 или AVX интринсиках в виде теста "запустил, оно поколбасилось, сравнило результат с нужным и вышло". А ты волен собрать его с "-S -O2", получить ассемблерный дамп и оптимизировать, чтобы он выполнялся быстрее на, скажем, 15% (но ты можешь сначала оценить дамп и предложить свои адекватные проценты).
После чего мы сравним глубокий вывод "perf stat" и если у тебя получится вытянуть больше, я прямо здесь напишу "Извини меня, Хан. Я, Урри, ошибался, а ты был прав.". Если же не получится - то "Извини меня, Урри. Я, Хан, ошибался, а ты был прав." напишешь ты.
Подходит? Это не игра в одни ворота - мне тоже придется писать код, выдирать функцию и писать обвязку, которая ее дергает и тестирует.
Ну и польза тоже - если ты сможешь сделать лучше, то предложим твой код в libvpx. Я как раз недавно в ней копался, никак не мог понять как работает одна штука.
Судя по тому как ты завелся, я понял за чем тебе аж 10 бутылок понадобилось... ненасытный
И крипту отмени че мелочиться, компилятор же за тебя все подумает
И каким ты компилятором будешь компилить? GCC, LLVM или Intel-овским? Каждый из них оптимизирует по своему... по итогу отдавая на откуп компилятору особо требовательные к производительности части кода ты даже знать не будешь толком что он там наоптимизировал, а следовательно твой конечный продукт будет уровня студенческой поделки на GitHub
> ты даже знать не будешь толком что он там наоптимизировалДля этого у компиляторов есть специальные ключи. У gcc это, например, "-S".
Опции "-S -O2 -g3" позволят спокойно читать сгенерированный ассемблерный релизный дамп.А есть еще удобный сайт https://godbolt.org/ который все это делает за тебя, предоставляя удобный ассемблер сишного кода для почти сотни компиляторов (с версиями) под различные платформы.
Я им, например, регулярно пользуюсь.Учись, студент (с)
Просто нет слово... воистину дураки и дороги это бичь этой страны...Твоя логика
1. Нафигачить в код сишных оберток ассемблерных комманд
2. Перечитывать релизный дамп после компиляцииМоя логика
1. Сразу писать на ассемблере и точно знать чего ждать на выходеОдно действие, против двух как минимум, не находишь?
А если тебя не устраивает набор машинных команд сгенерированных компилятором, к твоему пример добавляется еще третий шаг а именно переписывание заново ручками
Тут уже соотношение 1 к 3
> Моя логика
> 1. Сразу писать на ассемблере и точно знать чего ждать на выходеИ получить непортабельное г0вно на палочке. Прекрасная логика, да.
--
Слушай, Хан, ты на васме успел потусоваться? Или уже не застал? А на flatassembler.net зарегистрирован?
Расскажи поподробнее какой оптимизацией ты занимался в гугл?
Ага, щас. Может еще и деанонимизироваться сразу заодно?
Под всеми моими коммитами стоят мои настоящие имя и фамилия, "git blame" и опа, я больше не смогу безоглядно нести пургу буде то мне захочется.Не-а, не скажу.
--
В любом случае это к делу не относится. Все, что тебе сказали ты можешь быстро проверить в гугле.
Все с тобой ясно
> Все с тобой ясноАхахахахах. Хан побоялся разрушить свой милый манямирок приведенными фактами, поэтому спрятался за "оппонент врун и вообще, поэтому я ничего не слышу и не вижу".
Хочешь меня деанонимизировать? Сильно?
10 бутылок бурбона Bulleit и я предоставлю тебе ссылку на свой линкедин. А сам перерегистрируюсь под другим ником.
Что за гэнбэнг ты хочешь устроить с 10-тью бутылками? Тебе что одной мало? Фу я на такое не подписывался
"слив засчитан" (с)
Бутылку я тебе не дам и не мечтай даже
Ну мы уже договорились, что моя деанонимизация тебе не так важна, чтобы на нее тратиться. Так что проехали.Как насчет предложенной проверки на практике кто из нас прав, на которую ты не ответил?
Примерно такое разрешение у видео 20 летней давности и есть
> Новость попахивает желтухой, как можно реализовать кодек на чистом расте с приемлемой
> производительностью без задействования ассемблерных инструкций аппаратного ускорения
> проца хотя бы? Даже сишные либы на треть обмазаны ассемблерными вставками,
> но вот раст не такой, да? он особенный, каким то чудом сам все ускоряет и умеет... хм...Коммент попахивает махровым Хановским ламеризмом и невежественностью.
Придумал хрень, оспорил хрень, написал с умным видом очередную ... да-да, хрень.
Интринсики? Не, не слышал ...
Я знаю, знаю... точно знать что получаешь на выходе это верх ламерства....Верить в сгенерированный код компилятором это верх профессионализма
P.S. только крокодилы спасут эту страну от мудаков
>> Интринсики
>> The following built-in functions are made available by -mmmx. All of them generate the machine instruction that is part of the name.
>> v8qi __builtin_ia32_paddb (v8qi, v8qi)
>> v4hi __builtin_ia32_paddw (v4hi, v4hi)
>> v2si __builtin_ia32_paddd (v2si, v2si)
> Я знаю, знаю... точно знать что получаешь на выходе это верх ламерства....
> Верить в сгенерированный код компилятором это верх профессионализмаВерх ламерства - быть опеннетным Ханом.
> как можно реализовать кодек на чистом расте с приемлемой производительностьюТам только декодер. А его с приемлемой производительностью можно и на вижуалбейсике из-под джаваскрипта написать.
Ачо сирвелайт не перепишут на раст? И еще парочку мертвых технологий
Ну, флеш это история интернета, огромное количество софта, мультов, игр..Выбросить тупо флеш это означает использование его древней версии лишь для того чтобы насладиться всем тем что когда-то было, а тут и сразу новый флеш, и сразу в браузере можно, и на андроиде и ваще.. чем плохо?
Вы назовите еще такие же технологии которые бы как-то походили на ушедший флеш.
Старый адобовский флэш все так же доступен в сети
Но устарел, вы в каком браузере его запустите?
А вот в wasm запустили бы и без установки этого вашего адоб флеша.
> Вы назовите еще такие же технологии которые бы как-то походили на ушедший
> флеш.ну вот silverlite был как раз попыткой сделать похожее. NiH синдром MS. В результате одна платформа, и та полуфункциональная по сравнению с флэшем, а кому надо было именно под нее - писали activeX.
Поэтому в отличие от флэша ни разу и не жалко, и вряд ли кому понадобится настолько чтоб воспроизводить с нуля.
Я даже скажу, что ранее существовали и Java Applets, но нет.. это все неизмеримо с flash по количеству контента.
Я вот не могу вспомнить никаких _полезных_ аплетов. В моей памяти жаба в вебе осталась исключительно для дурацких дрыгающихся картинок.(загружаемые standalone ява-программы отдельная грустная история. Но, в принципе, ВСЕ то же самое можно было делать флэшом и не жрать ресурсы как не в себя.)
> Вы назовите еще такие же технологии которые бы как-то походили на ушедший
> флеш.По дырам?
Вы мне прямо сейчас перечислите все уязвимости флеш плеера и мы сравним с великой таблицой уязвимостей в других проектах?
ЧтОоо?? Нет??, даже не кинете ВЕЛИКО популярную любительскую статью в интернете?Чттооо? Тоже нет?) Так как же так..
> Вы мне прямо сейчас перечислите все уязвимости флеш плеера и мы сравним
> с великой таблицой уязвимостей в других проектах?а чего это у вас Другой Проект во множественном числе? Хром, хром, хром, хром и хром.
Поскольку именно этот прожект уничтожил флэш сознательно и со всей индусячьей прытью.
Не мурзила-три-процента же.Разумеется, под сказочки о безопастносте-безопастносте. Теперь все те же самые уязвимости в нем самом, причем, в отличие от флэша, у пользователя нет возможности ограничить весь этот пирдуха исключительно двумя-тремя доверенными сайтами. Бебебезопастность!
Как там вебsql апи поживает? Аааа, это другое?
> ЧтОоо?? Нет??, даже не кинете ВЕЛИКО популярную любительскую статью в интернете?Наслаждайся: https://www.cvedetails.com/product/6761/Adobe-Flash-Player.h...
--
какие-то совсем тупые анонимы пошли...
Тебе надо ты и перепиши
Я тут попытался записаться на cisco курсы для интереса а они там флеш просят... так что сабж может иметь смысл.
Беги с этих курсов, а то тебя там научат настраивать frame relay и dialup pool'ы.
И X.25
> И X.25не, ну эт вряд ли все же. Те курсы на кассетные магнитофоны должны были быть записаны. В крайнем случае - на vhs.
Курсы от васяна... читай книги по коммутации и маршрутизации... благо Cisco их понавыпускало овер 9000
Многие гос видеочаты досихпор требуют флеша
Что за видеочаты такие? Чат рулетка чтоли?
Ага. С Пу. "Прямая линия" зовется
Вообщем смотрю я такой рофлы над фемками на ютубчике и внезапно фемка говорит что она является частью комьюнити... меня это так оскорбило... воруют даже исконно наши расово айтишные термины... хватит это терпеть!
Любопытный проект, но на данный момент код совсем академический, IDCT выполняется "в лоб"
https://github.com/ruffle-rs/h263-rs/blob/ce3d3c798190be1c78...
"зато понятно и без конструкторов копирования" (с)
Эта функция очень хорошо векторизуется компилятором, а все циклы в ней полностью убираются (заменяются на последовательность однотипных операций).
Или вы имели ввиду возможность использования какого-то более хитрого алгоритма?
Забавно, что проигрывает по скорости около 20%
> Забавно, что проигрывает по скорости около 20%на какой платформе-то? native extension скорее всего не отличим от оригинала с точностью до погрешностей измеризма.
А webasm ну например в palemoon - только повиснуть может. А на v8 движке - ну может чему и проигрывает, но эскопета стреляет, педики набигают, если разницу все равно не видно пользователю - то что и с чем сравниваем - бесполезные синтетические тесты?Эх... кто бы допилил поддержку flv - была бы у меня хоть одна полезная программа на модном языке.
> Flash Player ... Rust ...Две очень нужные технологии...
Как минимум решающие ряд проблем, а на сколько нужные время покажет. Флеш то мог бы стать полезным, но его авторы распорядились правами на стандарт так что его не хахотели использовать спустя пять лет после его создания.