No.342
Каков исторический контекст у крайне мутной темы с указателями? 640Кб хватит всем? Или есть иные преимущества, недоступные начинающим быдлокодерам?
мимокрокодил
No.344
>>342>крайне мутной темы с указателямиА что там мутного? Вроде там всё просто.
No.345
>>344Зачем делать указатель, если можно сделать ещё одну переменную?
No.346
>>345Во-первых, да, память экономится, допустим если выделишь большой кусок и потом его копировать туда-сюда долго и прожорливо. Я понимаю, что сейчас можно всегда сказать чтобы пользователь докупил себе памяти, но в случае с всякими микроконтроллерами экономить приходится чаще.
Во-вторых (и я думаю что это главная причина зачем оно сделано), аргументы в функцию передаются через с стек. А стек у нас равен
>ulimit -s>81928 мегабайт в моём случае. Ну и опять же копировать из стека и обратно дело не быстрое.
В третьих, если тебе надо в функции изменить несколько аргументов, то без указателей не обойтись. Одно значение ты ещё можешь вернуть (опять же копирование через стек со всеми вытекающими), а вот больше уже придется запихивать в структуры.
No.347
>>345Очень странный вопрос! И не очень понятно, как это связано с количеством памяти.
Без указателей ты далеко не уйдешь? Как делиться памятью между несколькими потоками? Как писать большинство алгоритмов, построенных на указателях (листы, деревья и.. леса), как работать с массивами, как изменять аргументы функций, да как даже делиться самими функциями? А вот никак без указателей!
No.348
>>342Некоторые высокоуровневые языки вполне себе успешно скрывают указатели за слоем абстракций. Однако чем ниже мы опускаемся, тем это становится сложнее. Причина этому кроется, внезапно, в самом устройстве компьютеров: у тебя есть процессор (калькулятор на стероидах) и отдельно память (не важно какая). Для того, чтобы процессор мог считать любые данные из памяти, ему сперва нужно знать где они в ней находятся: том 1, страница 100500, пятое слово сверху. Вот подобное описание местоположения и есть указатель. И без них никак.
No.354
>>353Сначала ассемблер (ARM64 под малину), затем сишечка (K&R), потом схема (SICP).
Это ни разу не шутка, если что. No.357
>>353В зависимости от твоих желаний.
Если начнешь с раста, то будешь выделяться среди миллиона серых обезьянок на джаваскрипте и питоне.
Но в то же время найти работу будет сложнее (если найдешь, то будет работа куда лучше).
No.358
в чем прикол раста чем он лучше с++? первое сообщение на доброчане
No.359
>>358Ну если прям совсем вкратце:
1. Строгая типизация.
2. ADT + pattern matching.
3. Трекинг лайфтаймов.
4. Трекинг инвариантов.
5. Человеческий async.
6. Человеческий параллелизм.
No.360
>>359офигеть думал тут никого)
на 0 чане меня сразу послали, думаю учить Раст дл общего развития
No.361
>>360Если хоть немного знаешь C++, то советую изучать по
https://amazon.com/dp/1492052590 можно спиратить с libgen No.362
>>361А что там такого есть, чего не получить из официального раст бука и чтения парочки открытых проектов?
Я бы советовал не заморачивать голову книгами о языках и почитать вот это:
https://bfnightly.bracketproductions.com/https://rust-unofficial.github.io/too-many-lists/index.htmlhttps://rust-unofficial.github.io/patterns/intro.html No.363
>>362Мне официальный раст бук показался, честно говоря, довольно поверхностным: из него непонятно как трейты представлены в памяти, как сделать свой итератор, ни слова про async (да, я в курсе про недоделанный async book) и т.п. Полноценные книги обычно более системны, плюс из них часто можно понять мотивацию выбранных решений в дизайне языка. На самом деле, чем больше ресурсов, тем лучше: всегда можно пару минут полистать и понять нравится тебе подача и стиль изложения или нет.
No.364
>>363Думаю ты прав!
А я писал по своему опыту, потому что раньше "боялся" программировать и писать код; поэтому вместо этого я читал много книжек по языкам, операционным системам.. наверное я знаю практически каждый качественный блогпост по плюсам, расту, хаскелю и агде.
И практического опыта в итоге у меня почти не было, по сути многое пришлось переучивать с нуля. Поэтому я первую книжку и подсказал, ведь там придется самому код писать также.
No.393
>>353Зависит.
Lua - невероятно простой и эффективный, идеален для обучения. Питонисты завидуют, но быть на заработке в СНГ очень сложно, тк софта не делают почти, а язык не популярен.
Go - если хочешь получать деньги в бекэнде. Язык не плохой, опережает многие своей уникальностью и востребован, но с точки зрения дизайна нередко порицается - благо, на производительности и памяти (благодаря garbage collector) не сказывается.
Zig - язык будущего. Обожаем всеми кроме ржавых культистов, работу найти невозможно. Еще не дошел до 1.0, но уже опережает весь low-level по многим параметрам, будет востребован через 4 года
когда всех программистов заменят неиросети. Bun сейчас лучший рантайм в вебе, так что это будущее может быть даже не за горами.
Вообще программирование скоро перейдет в разряд самодеятельности нежели оплачиваемой профессии, лавочка потихоньку закрывается. Но сейчас рост технологий экспоненциальный и мы достигаем пика, так что сказать точно очень сложно.
No.395
>>393> опережает весь low-level по многим параметрамПо каким?
> кроме ржавых культистовВо-первых, Rust хорош не только для низкоуровневого кода, во-вторых у Zig нет никакого ответа на безопасную работу с памятью, отсюда и неуважение. А как по мне, то пусть занимаются языком, может что-то интересное и выйдет.
> скоро перейдет в разряд самодеятельности нежели оплачиваемой профессииГлупости, все эти модельки не думают, а стохастически подбирают ожидаемые ответы. На таком далеко не уедешь, только пузыри надуешь и, возможно, заработаешь.
А когда если они научатся в мышление, то любая инженерная работа "перейдет в разряд самодеятельности", поэтому и волноваться, что именно програмисты вдруг станут не нужными, нет смысла.
No.397
>>395>нет никакого ответаЧерно белый манямир, такой же как и картинка твоя, почитал бы хоть; у зига есть 4 build мода, которые можно друг с другом комбинировать в одном проекте: это build, ReleaseSafe(безопасность), ReleaseSmall(маленькость °-°) и ReleaseFast(скорость) под разные модули. Но суть не в этом.
Как ни крути, в low-level расту без unsafe не выкрутится и без него это нерабочий язык, а этот самый unsafe именно такой, как и предполагает имя - безопасность там не то что с алокаторами зига, она не может тягаться даже с плюсами 20+ годов (хотя синтаксис там напугал бы даже Ратлиффа). Безопасность зига осуществляется за счет отсуствием футганов и отстуствием скрытого "control flow", а не кастрированием и невменяемыми скоростями компиляции.
На высоком уровне раст же более менее себя прилично показывает, и если закрыть глаза на размеры бинарников, ужасное llwm-овское тульё и то какой кошмар он приносит мейнтейнерам в опенсорсе (не зря же в него микрософты амазоны и прочие сатанисты так много бабла вливали), очень даже неплохой. Только случаев выгорания от раста через чур (
http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html , очень много ожидал от проекта но получилось как получилось)
No.690
Почитал тред, кокой-то тред бесполезных советов послушал. Язык это вкусовщина и вторичен, учите как комплюктеры и оси работают, тогда со всем остальным будет 0 проблем
No.692
>>690Ну а если по теме языков, имхо, Си - лучший вариант для низкоуровщины и даже прикладного пользовательского софта, но только если ты уверен в себе и понимаешь что делаешь. Всякие расты-с++-зиги-гошки избыточны и ведут к другим проблемам, о которых почему-то любят замалчивать противники указателей и ручного руления памятью
No.697
>>692Почему не сосемблер??? Зиг более низкоуровневый и там ручное управление памятью, просто без футганов, зайди на сайт почитай, 5 минут займёт.
No.698
>>697Почитал
https://ziglang.org/ru/learn/why_zig_rust_d_cpp/ https://ziglang.org/ru/learn/overview/ и не нашёл каких-то прорывных преимуществ ради которых стоит всё бросить и учить зиг
хайль.
>Zig соперничает с Cвообще смехотура
Преимущества его перед сравненными языками сомнительны и выглядят натянутыми - перечисленными "фичами" обладает Си уже 50 лет как:
* Без скрытых потоков управления
* Без скрытых выделений памяти
* Первоклассная поддержка отсутствия стандартной библиотеки
* Встроенный статический анализатор для обнаружения потенциальных утечек памяти (берешь что-то типо pvs/valgrind и прогоняешь)
Теперь к минусам:
* Синтаксис объективно сложнее Сишного
* 0 востребованности на рынке - будущее языка сомнительно
* Вся мишура с
>отсутсвием выделений в куче без прямого указаниярассыпается как только подключаешь любую стороннюю библиотеку
Просто нинужно. Как альтернатива может быть, но профитов переход на него я абсолютно не вижу, а вот траханье с неудобным синтаксисом предстоит постоянное.
>Почему не сосемблерРовно по тем же причинам что и выше. Переход с ассемблера на Си - качественный переход. В местах где без ассемблера не обойтись он не оправдан, в остальных - более чем. Переход с Си на Зиг? Нету причин чтобы это делать
No.699
>>698> * Без скрытых потоков управления> * Без скрытых выделений памятиЯсно, на C ты не писал.
No.700
>>699> * Без скрытых потоков управления> * Без скрытых выделений памятиЯсно, на Си ты не писал
No.702
>>690ИМХО оси конечно хорошо знать в общих чертах но для реального вката достаточно команд Линукс.
No.704
>>703Таки я про С++ ничего в положительном ключе и не писал
:3, к чему это?
No.706
>>353Питон. Инфа сотка. Не обсуждается!
No.932
>>393>но быть на заработке в СНГ очень сложноКак и где угодно тащем-та, как самодостаточная технология он редко используется, в основном эмбеддится в сишное говно.
No.983
Растовички, что с мордочкой?
https://www.opennet.ru/opennews/art.shtml?num=61819
> Кроме того, можно отметить уход Уэдсона Алмейда Фильо (Wedson Almeida Filho) с поста сопровождающего проект Rust for Linux, занимающийся внедрением в ядро Linux средств для разработки на языке Rust. После ухода Уэдсона у проекта остались ещё два сопровождающих - Мигель Охеда (Miguel Ojeda), автор и основной разработчик проекта Rust-for-Linux, и Алекс Гейнор (Alex Gaynor), бывший директор организации Python Software Foundation, переключившийся на продвижение Rust. Ушедший сопровождающий, который подключился к проекту 4 года назад, является сотрудником компании Microsoft и автором экспериментального драйвера с реализацией ФС EXT2, написанного на языке Rust. Последнее время работа Алмейда была сосредоточена на создании средств для разработки файловых систем на языке Rust. В этом году Алмейда внёс в репозиторий Rust-for-Linux 17 коммитов (для сравнения Мигель Охеда добавил 53 коммита).В качестве причины ухода упоминается нехватка сил и энтузиазма, которые когда-то были для реагирования на некоторые бредни нетехнического характера (nontechnical nonsense). По мнению Алмейда, разработчики вынуждены тратить много сил на споры по несущественным вопросам, сводящим на нет более важную глобальную цель. Алмейда продолжает верить, что будущее ядер за использованием языков, обеспечивающих безопасную работу с памятью, и если сообщество разработчиков Linux не поймёт это, то Linux будет вытеснен каким-то другим ядром, как в своё время произошло с Unix.
Сторонники проекта Rust-for-Linux столкнулись с необходимостью преодолевать сопротивление со стороны маститых старых разработчиков ядра, которые не видят необходимости в изучении нового языка. В своём письме об отставке Алмейда в качестве примера приводит ссылку на дискуссию, которая состоялась во время выступления Алмейда и Кента Оверстрита (Kent Overstreet) на конференции "Linux Storage, Filesystem, Memory-Management, and BPF Summit" и была посвящена использованию Rust для разработки файловых систем. Деятельность по внедрению Rust раскритиковал Тед Цо (Ted Ts'o), автор файловых систем ext2/ext3/ext4, который сравнил инициативу Rust-for-Linux c попыткой заставить всех принять религию Rust.
В ответ на намерение Алмейда создать обвязку над написанными на языке Си интерфейсами файловых систем для их использования в коде на языке Rust, Тед Цо указал на то, что подобная обвязка неминуемо приведёт к проблемам, так как любое изменение Си-интерфейсов и проведение рефакторинга потребует изменения обвязки для Rust и он не хочет брать на себя лишней ответственности за исправление возникающих проблем в коде на Rust и отслеживании состояния Rust-обвязки. Код на Си постоянно развивается и если его изменение нарушит работу обвязки для Rust, это приведёт к нарушению работы и всех завязанных на эту обвязку файловых систем.
Тед также считает, что в обозримом будущем обвязка для Rust останется второстепенной и возникновение проблем в биндингах будет головной болью только для разработчиков Rust-for-Linux, а не для сообщества разработчиков файловых систем в ядре. Указано, что не все разработчики собираются изучать Rust и поэтому после внесения влияющих на другой код изменений, они смогут обновить только зависящий код на Си, но не смогут исправить Rust-обвязки, так как не знают Rust. К дискуссии также присоединился Джеймс Боттомли (James Bottomley), сопровождающий подсистему SCSI, который сказал, что чем больше семантики кодируется в обвязках, тем они становятся более ломкими с точки зрения обеспечения синхронизации.
No.986
>>690Ты бы хоть литературу соответствующую скинул.
No.1081
Когда я пишу на Си, Господь как бы приподнимает меня над землёй. Не так близко, чтобы поздороваться, но достаточно высоко, чтобы узнать вам, плюсовикам, цену. Вы, посмешища, выкидывающие по 10 исключений на каждой строке, ваши проекты сливаются в огромную ООП кашу, с тысячами абстракций, наследований и инкапсуляций. Человек без дисциплины кода есть низкая тварь, что даже утопая в реке, я не подам ему руку. Когда я пишу на Си, я слышу от Господа музыку жизни, а не
std::_Rb_tree_node<std::pair<const int, double> >*'
rtmap.cpp:20: initializing argument 1 of `std::_Rb_tree_iterator<_Val,_Ref,_Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val = std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
std::pair<const int, double>*]'
In member function `void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(_II,_II) [with _InputIterator = int, _Key = int, _Val = std::pair<const int, double>, _KeyOfValue = std::_Select1st<std::pair<const int, double> >, _Compare = std::less<int>, _Alloc = std::allocator<std::pair<const int, double> >]'
No.1083
>>1081Хаскель это, безусловно, высокий уровень абстракций. Но вот на нём как раз что-то похоже испытывал когда писал. Что-то на вроде того, словно не сам код пишешь, а он изливается каким-то потоком, проходящим через тело.
No.1087
> Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk[1] Такие заявления на самом деле очень сильно влияют. После того, как NSA[2] парочку лет назад заявили, что необходимо использовать Rust в safety critical системах, много автомобильных компаний начали с плюсов и сишки на него переходить (и это не догадки, а буквально их прямые слова).
[1]:
https://thenewstack.io/feds-critical-software-must-drop-c-c-by-2026-or-face-risk/[2]:
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/ No.1088
>>1087Rust не пробовал. В принципе против него ничего не имею, пока им не пытаются заменить именно сишку, плюсом отталкивает религиозное сообщество, любящее не писать новый софт, а переписывать старый. Плюсы, наверное, этим можно заменить.
Ещё что мне кажется минусом это время компиляции и cargo. Раздуто, раздуто, раздуто…
No.1089
>>1088Не пытаются, а заменяют[1][2]. А вообще во всех safety critical системах, написанных на Си, используют формально-верифицированные компиляторы 90-ых годов с ограниченным функционалом и cвоими кастомными валгриндами. Оно все на столько от стандартной сишки отличается, что и одним языком это считать нельзя.
> религиозное сообщество, любящее не писать новый софт, а переписывать старыйЛожь и провокации. Полно и нового софта, полно и модернизированного (не просто переписанного!) старого.
rg vs. grep
> время компиляции и cargoЯ на очень больших проектах не работал, и для меня это вообще проблемой не было.
А так в целом конечно есть в языке большие минусы, но обычно именно их никто нигде не обсуждает (кроме форумов самого языка), и вместо этого – обычная тягомотина с парочкой заученных всеми аргументов (включая скорость компиляции, религиозное коммьюнити и всякое другое).
[1]:
https://community.osr.com/t/microsoft-discloses-rust-framework-for-windows-drivers/58335[2]:
https://lwn.net/Articles/991062/ No.1090
>>1087Ну я так и предполагал, по наличию настолько раздутой рекламной компании трансвеститного раста, что NSA жиды его будут силком проталкивать через законы чтобы в каждой твоей софтине был бекдор на уровне компилятора. Когда обнаружится спустя года скажут ОЙ-ВЕЙ, произошла чудовищная ошибка, и заменят его на другой. Как с Pegasus было, после изобретения детекта Касперским которого, их попросили найух с штатов в ускоренном порядке. Это объясняет добавление раста в ядро. Поступила команда от жидов Торвальдсу добавить сРаст? Будет сделано! Куда же делся языковой, концептуальный и разработческий шовинизм, мистер Торвальдс? Приказа не поступало?
>>1089> Ложь и провокации. Полно и нового софта, полно и модернизированного (не просто переписанного!) старого.Ни одним софтом на чистом срасте написанном не пользуюсь и даже не слышал о таких, которые бы пригодились погроммисту или обычному петровичу.
В целом, я рад что в сообществе меентейнеров линукса, над растовичками посмеиваются за их "инновационные идеи", о которых деды лет 20 назад ещё рассуждали. Ну и попуски от Торвальдса за панику в аллокаторе при невозможности выделить память, попуски за интерфейсы, попуски за религиозную дрочню на memory-safety, при полном непонимании прикладной области их софта со стороны дедов. Вот как пример
https://youtu.be/WiPp9YEBV0Q?t=1529 .
Растовичок - инвазивный вид, который только и ждёт того, чтобы паразитировать на чужом успехе. Мемы про то, что разработчики на расте - трансвеститы, не просто стереотипы. Никаких претензий к ним бы не было, если бы они не лезли в чужие монастыри со своим уставом (прямо как трансы лезут в женские уборные). Причина распространения языка кроется не в его охуенности, а в лоббировании заинтересованными лицами, о чем в новостях пару постов назад сказано было. Видимо "убийцы Си" могут выживать только если обязать законадательно их использование, а не по причинам своей охуенности.
No.1092
>>1090Этот анон прав насчет NSA.
Даже сам C заложили в основы IT специально ради того, чтобы весь софт был дырявым. Заложили удачно, на заре массового распространения айтишки, и теперь все являются заложниками этой ситуации, а в выйгрыше те, кто способны собирать команды хацкеров и ломать инфраструктору конкурентов.
No.1095
Подскажите гайды по оформлению резюме. Больше года уже не работаю, никуда не берут из-за СБ. Хочу переписать резюме, чтобы HR снова стали написывать и на отклики на HH реагировать. Хоть куда-нибудь бы взяли, да без тестового задания желательно.
No.1097
>>1095А в чем проблема тестовое задание сделать?
Сделай свой собственный открытый проект и добавь его в свое резюме.
No.1098
>>1097Почему-то после тестового меня обычно отшивают, только время трачу и порчу себе настроение. Открытых проектов хватает на гитхабе, но это никому не интересно. Добавлять пет-проекты в список рабочих мест - оооочень странное решение.
No.1135
>>1098Тестовые задания это практически всегда наживка на лоха. А если оно ещё и неоплачиваемое, то на все 100%. Из тысячи кандидатов всегда найдётся терпила, который на "двухчасовое" задание
а по факту на пару дней за свой счёт угрохает неделю. Раз вместо резюме у тебя не пустой лист, то просто говори, что не будешь делать тестовое. Если откровенно на хуй при этом не слать, то кто-то нет-нет да и скажет "ок, приходи на собес".
No.1137
>>1135Давал людям тестовые задания. Очень хорошо помогают отбрасывать дураков без опыта (зато с какими CV!). И поэтому не согласен.
>>1132Присоединяйся!
No.1138
>>1137>Присоединяйся!Оки.
Пишу сейчас что-то типа онлайн-радио. Есть 2.5 варианта реализации в голове как отдать музыку на страницу.
1.1 - Выгрузить все в публичную папку, где хранятся иконки и прочее и туда js бы обращался, подставляя в тег аудио нужные аттрибуты с адресом к файлу и типом майм.
1.2 - То же самое, но файлы будут не в папке, а на CDN (не знаю только не прилетит ли страйк за пиратские файлы. Самый нежелательный вариант).
2 - Организовать потоковую передачу файла. Самое сложное и непонятное.
Единственное что известно, так это что нужно будет заморочиться с многопоточностью, а то на одном потоке все зависнет.
Кто как видит реализацию?
На сервере будут крутиться Rails 8. В 7й версии, как слышал, завезли передачу по веб-сокетам. Это можно как-то использовать?
No.1139
>>1138Использовать уже существующие решения а-ля SHOUTcast?
Я сам таким никогда не занимался, но смотрел бы в эту сторону.
https://www.azuracast.com/docs/https://www.tecmint.com/install-shoutcast-in-linux/Чтобы в итоге получить что-то подобное на это радио.
https://lainchan.org/radio.htmlПри чем тут многопоточность не очень понимаю.
No.1140
>>1139>Использовать уже существующие решенияТак это скучно. Хочется изобрести велосипед, используя максимум библиотеки или возможности фреймворка.
>При чем тут многопоточность не очень понимаю.В другом тредике, правда, обсуждающего php, мне сказали, что много обращений решение с потоком не вывезет.
No.1143
>>1142Логично, но цель не столько поднять радио, сколько разобраться со всем стеком. Радио - просто выдуманная задача из головы, чтобы поковырять все инструменты.
Это будет мое первое творение, по большому счету.
No.1169
>>1144>>1143Я сам, можно сказать, без опыта. Но на мой взгляд лучше обычно просто поглядеть как реализовано в открытых проекатах подобных, потом посмотреть как хочешь сделать.
Как сделаешь, то уже можно глянуть с готовыми вариантами что сравнить что сам накалякал и что люди пользуют. Апосля уже создавать новую финальную версию своими ручками.
Но это так. Рассуждения.
No.1177
>>1169Это как говорить людям посмотреть на реализацию движка дума. И с этого начать делать что-то свое.
Так это не работает!
Надо как иметь опыт в изучаемой сфере, так и иметь опыт с программированием в целом.
Но в целом конечно ты прав, что смотреть на такие вещи императивно. Просто делать это надо подготовленным.
No.1178
>>1177>Надо как иметь опыт в изучаемой сфере, так и иметь опыт с программированием в целом.Ну-с, я это подразумевал как само-собой разумеющееся.
No.1211
Мне сегодня друг сказал, что все работы на Джаве и ДжСкрипте только, это правда? Я со срынком не знаком совсем. Не хочу так жить.
No.1218
>>1211Тебе наврунькали. Твой друг скорее всего веб-макака, изолированный в своём информационном вакууме
No.1254
Есть знатоки?
Я вот тут подумал, обычно чтобы ускорить загрузку картинок в браузере хоть в текущие дни этот вопрос не особо релевантен обычно используют отображение миниатюр с последующем открытием полной картинки. Также использую разнообразные форматы изображений, которые уменьшают объём за счёт некоторого снижения качества.
А я тут подумал, сейчас же почти все сайты используют жабкаскрипт? Так почему бы просто не запилить такую библиотеку, которая будет хранить картинки на сервере в супер-архивированном пережатом формате, а уже в браузере на клиенте будет происходить силами его машины и браузера распаковка?
Или же всё же такое существует уже?
No.1255
>>1254По-моему, ты изобретаешь велосипед. Суть в том, что эти самые форматы изображений и есть супер-архивированные картинки, которые распаковываются браузером. Более того, эти форматы делаются с оптимизацией под картинки и результаты для изображений показывают обычно не хуже, чем архиваторы общего направления.
No.1256
>>1255Велосипед да, но не совсем.
Текущее представление картинки передаётся целостно и сразу же отображается пользователю, также как это бы хранилось на ПК и открывалось бы через любую смотрелку.
До того же что я предлагаю, работа будет иным образом. Представим утрировано и упрощённо. Например как сейчас картинка.jpg на сервере -> передача -> картинка.jpg у клиента в браузере. Моё же представление следующее картинка.zip на сервере -> передача -> картинка.zip принмается браузером клиента -> код выпоняет разархивацию на машине клинте -> картинка.png отображается у клиента в браузере. Имеется в вииду конечно же не zip буквально, но это для отображения смысла хранения сжатого файла на сервере.
No.1257
>>1256Ты не сожмешь картинки больше, чем они есть сжаты уже стандартными форматами.
Да и кеширование решает большинство проблем со скоростью (так еще в QUIC + HTTP/3 есть возможность предзагрузки изображений и контента в целом).
No.1258
>>1257Признаю, был глуп. Я не знал, что картинки архиватороами не пережимаются ещё более.
No.1261
>>1256>>1258Да, не пережимаются ещё больше. Ничего страшного, зато ты узнал что-то новое. Вот ещё на подумать. Сжатые картинки могут весить больше несжатых png, и даже иногда монохромное изображение будет больше оригинального. Вот посмотри на примере простой картинки серого цвета, размером 400 на 400. Оригинальный png, прикреплённый к посту весит 1,5 кб, jpg - 6,39 кб, что больше. Причина - слишком маленький размер картинки. Для больших пикч размер существенно снижается при использовании jpg или webp. В данном случае webp весит 4,47 Кб. Ну и монохромный bmp весит 20,3 кб. Наверное самым подходящим форматом для маленьких картинок можно считать не png, хотя и он хорошо справляется, а gif - 651 байт в данном случае. Почему gif по итогу весит меньше всех, предлагаю подумать самому.
No.1262
>>1261>Почему gif по итогу весит меньше всех, предлагаю подумать самому.Глянул описания на вики, но пока не вдавался. Секрет в том что gif использует малую палитру цветов и не модифицирует
градиентно пиксели цветов пытаясь сжать таким образом изображения?
Не знал, кстати, что jpeg такой изврат с цветопередачей делает. Надо будет ещё с jpeg-xl сравнить.
No.1263
>>1262У gif самый простой алгоритм сжатия - заливка цветом. А так как на фото только один цвет, то он просто все строки дублируется.
No.1269
Сап /u/. Можешь посоветовать какой-нибудь супералгоритм позволяющий отличить последовательность истинно случайных чисел от псевдослучайной?Я просто решил запилить свою криптовалюту которая будет отличаться от других тем что ее можно будет майнить только на аппаратных ГСЧ.
No.1276
>>1269Нет никакого супералгоритма, есть много всяких наборов тестов. Например, тесты diehard, TestU01, SP800-22
No.1277
>>1269Все ГПСЧ имеют некий период, после которых они повторяются. Так что можно использовать
https://ru.wikipedia.org/wiki/Нахождение_цикла No.1294
Вопрос по Microsoft Excel:
Есть таблица с колонкой значений в столбце «A».
Напротив них, в столбце «B», ряд ячеек содержит значения, а ряд — нет.
Нужно построить ещё одну колонку из значений из столбца «A», но только тех, ячейки в столбце «B» напротив которых не являются пустыми.
Можно ли это сделать через функции в ячейках, или нужно писать скрипт?
No.1295
>>1294Правильный вопрос это половина ответа или как-то так. Вроде всё как ты насал так и делать надо (под рукой только не локализованный офис, но думаю суть ясна)
IF(ISBLANK(B1);;A1)
&"" если надо чтобы прям пустые ячейки были.%%
No.1297
Сап, друзья. Хочу изучить сферу ИИ, но не знаю с чего начать. Может кто порекомендовать какой-нибудь материал к прочтению, просмотру? В математике шарю и опыт в программировании тоже имеется.
No.1299
>>1295Вопрос был в том, можно ли здесь обойтись без скрипта/макроса.
Я просто этим Экселем второй или третий раз в жизни пользуюсь.
No.1300
>>1299>Вопрос был в том, можно ли здесь обойтись без скрипта/макроса.Можно, это стандартный функционал формул. Собственно, пишешь в ячейку C1
=IF(ISBLANK(B1);;A1)&""
или если русскоязычный
=ЕСЛИ(ЕПУСТО(B1);;A1)&""
и растягиваешь её вниз.
>Я просто этим Экселем второй или третий раз в жизни пользуюсь.Я последний раз на школьной олимпиаде по информатике пользовался.
No.1301
>>1300Спасибо, завтра на работе попробую.
Для уточнения: список в столбце «C» должен быть без пропусков, то есть, короче исходного столбца «A».
No.1304
>>1303Сделай фильтр, там можно скрывать все строки с заданным значением, в том числе и пустым.
No.1305
>>1304Что такое в данном случае «фильтр»?
Для справки, я работаю с Excel 2003.
No.1319
>>1305P.S. В любом случае, я уже нашёл более простое решение. Спасибо за ответы.
No.1350
>>1319Так решение хоть какое напиши!
No.1351
>>1350Просто забить. Этот вопрос не стоит уже потраченного на него времени.
No.1359
>>1351Вот видишь, теперь следующий человвек, который будет искать решение потратит столько же времени в пустоту, а мог ему помочь!
No.1361
>>1359Этот пассаж, боюсь, просто не понял.
No.1378
Раст - кусок говна немытого
No.1405
>>1087Как же хорошо, что самый перспективный язык XXI века пушит АНБ. Ну, то самое, которое все любят и уважают.
Вообще, интересно, как язык продвигается в первую очередь не за технические доводы (которые есть, но не те, которые транслируют из каждого утюга), не за ещё что-то типа лёгкой параллелизации и ленивых алгоритмов с автообработкой ошибок (в противном случае, мы бы уже давно писали на хаскеле с окамлом), а за то, что кто-то из растокоманды вступил с кем-то в политическую или сексуальную связь, грамотно где-то пропиарил по майклодексоновски, забашлял одному виндотроллю, чтобы с утра до ночи постил раст на опеннете, переписал легаси с другого языка, вклинился кулуарно-нечестными методами в чужую кодовую базу и так далее. И ведь он продвинется чисто благодаря этому.
И вот это всё очень хорошо характеризует всю индустрию программной инженерии.
No.1406
>>1388Удваиваю вопрос. Лично я не могу прочитать, правда, даже одну функцию на асме, да и сигнатуры не умею.
Как мне кажется, что-то такое, на правах брейншторма, можно решить следующим образом:
- к сигнатурам (или что там в иде есть) приделать какие-нибудь широкие аннотации кода. Т.е. пишешь длинные комментарии на каждую инструкцию, функцию и так далее. Заставить подгружать. Возможно, ида это умеет.
- поиграть в ГРАМОТНОЕ ПРОГРАММИРОВАНИЕ дедушки Вирта и начать писать спеку-книгу (емнип, в относительно легальном линуксреверсе так и делают, одна команда анонимных трусов пишет спеку, а вторая пишет код по спеке), по функции описывая код и оставляя в книжке гиперссылки, которые будут управлять тулкитом для реверсинга. Бонус такого подхода будет в разбиении на файлы и относительно лёгком превращении книги в целевой проект и оно, если поделить на файлы, будет работать с VCS.
