Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 25965)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5120 кБ.
  • Ныне 3636 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
junior_developer_nene.png - (648.30KB, 720×720)
25965
No. 25965  
Здесь можно получить помощь и консультацию по любому языку программирования, в любой сфере разработки. Не важно, программируете ли вы собственного робота, пишете серверную приблуду, интегрируете чужие API, ковыряете игру, или пытаетесь сделать сайт на Wordpress - если аноним что-то об этом знает, он обязательно поможет.

Пополняемая база знаний: http://pastebin.com/AGhLZppH

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

Другие тематические нити (иногда обновляется): https://pastebin.com/psy43ibG

Примеры кода лучше выкладывать в виде ссылок на http://pastebin.com или http://ideone.com
Фронтендные вещи лучше выкладывать на http://jsfiddle.net

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

Чтобы не сбивать новичков с толку, а также не разбавлять полезную информацию мусором, беспредметные споры типа "какой язык / парадигма / библиотека / етц лучше" здесь запрещены. Для подобных вещей теперь есть отдельная диспутов нить >>/dev/21353

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

Архив нитей:
http://410chan.org/dev/arch/res/14160.html
http://410chan.org/dev/arch/res/15681.html
http://410chan.org/dev/arch/res/17424.html
http://410chan.org/dev/arch/res/19666.html
http://410chan.org/dev/arch/res/21641.html
http://410chan.org/dev/arch/res/23830.html

Прошлая нить пока тонет тут: >>/dev/23830
421 сообщений пропущено. Показаны 50 последних сообщений
No. 27322  
>>27321 Страшно. Индустрия превращается в говно из-за этого. Вместо 1-2 качественных мелких либ, которыми пользуются все и которые всё сообщество совместно улучшает, становится 100500 помоек, которые вызовут проблемы у всех, кроме хозяев этих помоек и нескольких недоумков, которые додумались взять помойки как зависимость потому что они у них уже установлены в системе для чего-то другого, помойные решения им подошли, а непомойные - лень искать и ставить.

А свой аргумент про flash-SSD-хлам откинь. Никогда не юзал SSD и не буду. Как минимум пока их не будут делать на магниторезистивной памяти, или прочей прорывной технологии.
No. 27323  
>>27319
На Unix-системах оно работает через POSIX shared memory objects, см. shm_open(3). В деструкторе происходит shmctl(id, IPC_STAT, &shmid_ds), после чего проверяется, равен ли shmid_ds.shm_nattch нулю. Если равен, то происходит удаление сегмента общей памяти. Таким образом, ссылки подсчитывает ядро ОС.

https://codebrowser.dev/qt5/qtbase/src/corelib/kernel/qsharedmemory_systemv.cpp.html#_ZN20QSharedMemoryPrivate6detachEv
No. 27325  
>>27322
> проблемы у всех
> flash-SSD-хлам
Судя по всему, чуть менее, чем на половину, это всё-таки лично твои тараканы.
No. 27326  
>>27310
Проц и памаять
No. 27331  
Тупой вопрос.

Дано: есть 3 системы: Windows XP, Linux + X11 + KDE + colord, и Apple iOS. На всех установлен монитор с широким гамутом, установлена видеокарта, установлены для неё драйвера, монитор подключён по DVI. В систему установлен цветовой профиль монитора и система как-то привела цвета sRGB в соответствие c тем, как они должны выглядеть, загрузив куда-то в видеокарту как-то посчитанные LUTы. В системе также предустановлены цветовые профили для различных цветовых пространств. Также у нас есть набор файлов с
1. кривыми чувствительности типов колбочек глаза к различным длинам волн;
2. CIE color matching functions.

Задача: написать кроссплатформенный код, с помощью OpenGL 3.0 рисующий квадрат цвета, максимально соответствующего тому, который увидит глаз, если в него посветить расходящимся лазерным пучком, имеющим задаваемую спинбоксом длину волны.

Мне кажется, что алгоритм такой:
1. как-то кроссплатформенно получить от системы цветовой профиль монитора
2. засунуть (у нас - на одной длине волны ненулевая интенсивность, для остальных - нулевая) спектр излучения в переменную OpenGL.
2. в фрагментном шейдере перевести спектр источника в цвета в пространстве LMS, посчитав скалярные произведения с кривыми чувствительностей колбочек.
3. в фрагментном шейдере перевести цвет из LMS в цветовое пространство монитора, задавемое профилем
4. как-то кроссплатформенно указать системе, что у нас OpenGL viewport не в sRGB, а в цветовом пространстве полученного профиля. Как-то заставить систему не применять загруженные LUT к нашему viewportу, но продолжать применять ко всем остальным окнам.
5. как-то отрендерить нашу картинку.

Я погуглил-погуглил, и только для винды+DirectX нашёл хоть какое-то API.
No. 27332  
Вернее для всего остального я и не искал, ведь писать некроссплатформенное решение смысла не имеет.
No. 27333  
Во что нашёл, но на вопрос это не отвечает. https://www.jcline.org/blog/fedora/graphics/hdr/2021/06/28/hdr-in-linux-p2.html
No. 27334  
Чиочан, мне надо в линуксе задать переменную отружения для всех юзеров, причем желательно из одного места. Пишут, что для этого надо прописать их в /etc/environment. Это работает для всех пользователей, кроме почему-то рута. В интернетах разное пишут: у кого-то работает это для рута, у кого-то нет.
Вопрос, что делать? Не хочется каждому пользователю индивидуально прописывать в .bashrc, это сложно будет менять в случае чего. Хотелось бы из одного места всем управлять.
No. 27340  
>>27331

Задача гораздо проще, чѣмъ интегрирование спектра лазера, матрично умноженного на массив откликов колбочек.

Цвѣтъ лазернаго луча — такой же видимый цвѣтъ, как и всякий другой.

Въ цвѣтовом пространстве CIE 1931 xy этому цвѣту соѿвѣтствуетъ единственная точка, расположенная на внешнем (подковообразном) периметре области видимых цвѣтовъ (диаграмму из Википедии прилагаю). Формулы, переводящие длину волны лазера в координаты CIE (сперва в XYZ, а затѣмъ — и в xy), извѣстны съ прошлаго вѣка и оттого буквально лежат по адресу https://en.wikipedia.org/wiki/CIE_1931_color_space#Color_matching_functions в Википедии.

Единственная оставшаяся трудность состоит в том, что эта точка располагается за предѣлами RGB-пространства экрана, поэтому её собственные RGB-координаты в этом пространстве напрямую использовать нельзя (величина как минимум одной из координат ожидается отрицательною), и наивно обрѣзать их до подходящих также нельзя (то движение точки вдоль координатной оси, которое получилось бы в результате тупого зануления отрицательной координаты, не только уменьшило бы ея цвѣтность, но и, в общем случае, исказило бы цвѣтовой тон, что недопустимо).

Правильное рѣшеніе задачи перевода произвольного цвѣта в наэкранный рассматривается по адресу https://www.w3.org/TR/css-color-4/#gamut-mapping (то есть в §13 спецификации CSS Color Module Level 4), рекомендуемым является (грубо говоря) снижение цвѣтности (по возможности не затрагивающее ни яркость, ни цвѣтовой тон), совершаемое въ цвѣтовомъ пространстве Oklch.

То есть задача раслагается на три послѣдовательных шага:

① Найти координаты цвѣта лазера в пространстве Oklch.

② Найти в том же пространстве координаты ближайшей точки области цвѣтовъ, способных отображаться на экране средствами OpenGL. (Это, по-видимому, цвѣта sRGB?)

③ Перегнать координаты найденной точки въ наэкранныя.

Так как CIE XYZ-координаты исходной точки извѣстны (по вышеупомянутым википедическим формулам), а перевод XYZ-координат в пространство Oklch — это задача, рѣшённая создателем пространства, то для первого шага достаточно использовать формулы, на странице https://bottosson.github.io/posts/oklab/ приведённыя (въ раздѣлѣ «Converting from XYZ to Oklab»).

Для третьего шага формулы для перевода из Oklch в линейное пространство sRGB лежат там же (чуть ниже). Здѣсь «линейное» означает, что передаточная функция (гамма) ещё не накладывалася (то есть, напримѣръ, цвѣтъ 444 всё ещё ровно вдвое тусклѣе, чѣмъ 888).

Для второго шага по адресу https://www.w3.org/TR/css-color-4/#binsearch изложен псевдокод двоичного поиска.
No. 27342  
>>27334
Что за дистрибутив-то? У меня вот Debian testing, /etc/environment работает и для рута и для остальных пользователей (при новом логине, конечно).

Вангую, что под рутом ты понимаешь получение привилегий рута с помощью sudo. С sudo у меня не работает. По умолчанию sudo убирает все переменные окружения, кроме PATH, кажется. Можно написать что-то вроде
Defaults env_keep += "MY_ENV_VAR"

в sudoers.
No. 27343  
>>27342
У меня, прости господи, Астра Линукс. Он на Дебиане основан.
Прописал переменные в /etc/profile, все стало работать, через sudo тоже.
No. 27344  
Я пытаюсь научиться использовать прекомпилированные заголовки через Qt.
Есть несколько проектов, test1, test2 и т.д. Они все используют заголовок pch.h, который лежит в общей папке.
Я добавляю в .pro файл одного из проектов следующее:
CONFIG += precompile_header
PRECOMPILED_DIR = $$DIR_SRC/Tools
PRECOMPILED_HEADER += $$DIR_SRC/Tools/dp_pch.h
После чего делаю qmake и затем make.
После чего в Tools появляется директория test1.gch, в которой лежит файл c++. Я так понимаю, это и есть прекомпилированный заголовок. Но, так как он лежит в отдельной директории, другие проекты его не видят.
Как сделать так, чтобы вместо этого рядом с pch.h создавался pch.gch?
No. 27345  
smush.webp - (47.94KB, 821×2337)
27345
Свою предшествующую рекомендацию >>27340 я желаю дополнить упоминанием того, что для перевода длины волны монохромнаго цвѣта (в том числе лазернаго) в координаты CIE XYZ можно воспользоваться не одними только формулами, но и табличными данными CIE, изложенными в четвёртой таблице документа https://web.archive.org/web/20170712203603/http://cie.mogi.bme.hu/cie_arch/kee/div1/tc148.pdf в Архиве Интернета.

Изложены они там с высокою точностью — до шестого знака опосля запятой.

Скриншот первых двух страниц этой таблицы (то есть без данных для 775 нанометров и 780 нанометров) прилагаю.
No. 27346  
>Цвѣтъ лазернаго луча — такой же видимый цвѣтъ, как и всякий другой.
>Въ цвѣтовом пространстве CIE 1931 xy этому цвѣту соѿвѣтствуетъ единственная точка, расположенная на внешнем (подковообразном) периметре области видимых цвѣтовъ
>Формулы, переводящие длину волны лазера в координаты CIE (сперва в XYZ, а затѣмъ — и в xy), извѣстны съ прошлаго вѣка

Пространство XYZ получено заданием 3х базовых цветов с длинами волн 700 nm, 546.1 nm и 435.8 nm и экспериментах на людях путём визуального сравнения. Отсюда возникают ограничения этого цветового пространства. Оно измеряет не цвет, не активации видов колбочек, а их отклики на заданные базовые длины волн. Color mapping functions не являются откликами колбочек на длины волн, а лишь интенсивностями источников базовых длин волн, вызвавших субъективно близкие ощущения у подопытных. Каждая из базовых длин волн, предоставляемых подопытным, активировала сразу несколько видов колбочек. Поэтому при самом измерении color mapping функций информация была потеряна. Поэтому при переходе от длин волн источника к CIE XYZ через color mapping functions мы теряем информацию. Так как измерения проводились путём подстройки живыми людьми реостатов по субъективным ощущениям, то промерить эти color matching functions с низкой погрешностью и высоким разрешением на практике невозможно.

В 90е годы спектральные отклики колбочек были измерены напрямую путём спектроскопии https://pubmed.ncbi.nlm.nih.gov/6140680/ . Отсюда появилось пространство LMS, в котором информация о цвете не теряется из-за невозможности активировать различные типы колбочек раздельно.

>Изложены они там с высокою точностью — до шестого знака опосля запятой.

Спасибо за ссылку на таблицу, но ограничения самого принципа формирования цветового пространства они не отменяют. Сама таблица скорее всего получена не измерениями на людях, а расчётом исходя из данных для LMS.

>Единственная оставшаяся трудность состоит в том, что эта точка располагается за предѣлами RGB-пространства экрана
> Правильное рѣшеніе задачи перевода произвольного цвѣта в наэкранный рассматривается по адресу https://www.w3.org/TR/css-color-4/#gamut-mapping

Всё гораздо хуже. Точка может быть в пределах гамута экрана, но RGB-значения, которые мы высчитываем в OpenGL, или в любом другом приложении - они в sRGB - в кастрированном стандартизированном гамуте. Поэтому придётся пересчитывать из LMS в sRGB и вносить искажения, отображая точки вне гамута sRGB внутрь него. После чего по LUTам, загруженным в видеокарту, карта пересчитает уже искажённый и отклипанный цвет в sRGB обратно в цветовое пространство монитора, опять внеся искажения.

В Линуксе, судя по ссылкам, вывод в цветовом пространстве монитора только планируется, причём только для вяленого и HDR-мониторов, подключённых по HDMI, и на деле нихрена не реализовано. И разумеется, ни о каких кроссплатформенных либах даже речи не идёт.
В Винде (которую я почти не использую, использую только хрюшу и на виртуалке) и макоси (которую я не использую совсем) по-видимому есть нужные механизмы и API управления цветом ещё начиная с 90х, когда ни HDR, ни HDMI не было, потому что иначе бы эти платформы не взлетели у художников. Налицо банкротство линуксного десктопа и всей "швабодной" экосистемы.

>① Найти координаты цвѣта лазера в пространстве Oklch.

Нахрена какой-то Oklch, если есть LMS?

>② Найти в том же пространстве координаты ближайшей точки области цвѣтовъ, способных отображаться на экране средствами OpenGL. (Это, по-видимому, цвѣта sRGB?)

У нас задача - максимально достоверно вывести цвет, соответствующий длине волны, на конкретном мониторе. То есть не в sRGB, а в пространстве с гамутом монитора.

>③ Перегнать координаты найденной точки въ наэкранныя.

Я под "наэкранным" понимаю то, которое соответствует пикселам монитора, а никак не sRGB. sRGB - это общий подгамут аппаратуры участников консорциума. Перевод туда из sRGB делается автоматически видеокартой, когда в неё загружены LUTы.
No. 27347  
Теперь пути решения.
1. X11 будет в пролёте, ибо типа старьё, зачем на подюержку старья ресурсы тратить, переходите на вяленый не смотря на то, что до сих пор всё через жопу работает, и наверное так будет ещё десятелетия, а к этому моменту и преемника для вяленого придумают и опять всё через жопу будет.
2. у меня есть подозрение, что в композиторах управление цветом реализуют как не-использование LUTов для всего экрана и пересчёт фрагментным шейдером каждого окна в цветовое пространство экрана.
3. у меня есть подозрение, что когда LUTы не загружены, то в линуксе RGB-значения будут уже в пространстве монитора.
4. загрузить/выгрузить LUT можно только от рута
5. отсюда костыльная идея:
а) запускается демон от рута, выгружающий/загружающий LUTы по запросу и слушающий сокет
б) при активации цветоуправляемого окна LUTы выгружаются и цвет всего нецветоуправляемого искажается
в) при деактивации цветоуправляемого окна LUTы опять загружаются.
г) костыльно и хрупко.

Насколько эта идея соответствует действительности?
No. 27348  
>>27344
>Я пытаюсь научиться использовать прекомпилированные заголовки через Qt.
>.pro файл

В Qt QBS давно дропнута в пользу CMake. Рекомендую не страдать фигнёй с этим хламом (QBS), а тоже переходить на CMake. Предкомпилированные заголовки не нужны, используй модули C++.
No. 27349  
>>27348
Модули это из 20 стандарта. Я ограничен 14-м. Использовать другую систему сборки возможности тоже нет.
No. 27350  
>>27349 Это кто решил? Насяльника? Ну так и пойди и поговори со своим насяльника на эту тему, что на говне 10летней давности без доступа к compile-time вычислениям и ranges он пусть сам пишет. Ещё бы на сишке без плюсов предложил написать. Или на algol68.
No. 27351  
>>27350
Мы на работе пишем на сишке. Проблемы?
No. 27352  
>>27350
Это решает не насяльника, а наличие огромной легаси-базы, которая должна работать в том числе и на железе и операционных системах, под которое новые фичи просто не реализованы, а реализованы никогда не будут. Это обычное дело, если ты пишешь что-то сложнее калькулятора для курчаса в универе.

А на сишке без плюсов успешно пишут и для микроконтроллеров, и драйвера, и ядро линкуса. И будут писать. Предлагаешь от всего этого отказаться? Тогда ты попадешь в каменный век, где твои compile-time вычисления и ranges тебе уже не пригодятся.
No. 27360  
>>27352
>Это решает не насяльника, а наличие огромной легаси-базы, которая должна работать в том числе и на железе и операционных системах, под которое новые фичи просто не реализованы

Your mileage may vary. PDP-11 Clang не поддерживает, да. К сожалению 8051 тоже не реализована, но в SDCC C++ вообще нет. В принципе можно реализовать бэкенд для llvm, но этим кто заниматься будет? Без конкретики сказать нельзя. Если в Clang есть поддержка архитектуры, то даже если нет C++, то проблема в принципе решается небольшими трудозатратами с огромным выигрышем в виде возможности писать на распоследнем C++.

>А на сишке без плюсов успешно пишут и для микроконтроллеров, и драйвера, и ядро линкуса.
А некоторые - и мышей едят.

>И будут писать. Предлагаешь от всего этого отказаться? Тогда ты попадешь в каменный век, где твои compile-time вычисления и ranges тебе уже не пригодятся.

Пока другие пердолятся с C++11 и Си, я пишу на C++26. Пришлось пропатчить пару хэдеров правда и наваять скрипт, компонующий тулчейн из двух разнородных, но ничего. Уже на отладочном выводе время, потраченное на налаживание тулчейна, себя окупило. Ну а если нравится кому-то пердолиться - ну пусть пердолятся со своим Си.
No. 27362  
>>27360
А потом выпустят C++29 и окажется, что со своим C++26 ты тоже пердолился, представляешь?

Программирование существует, чтобы решать задачи бизнеса. Какие задачи бизнеса ты решаешь своими «compile-time вычислениями» и «ranges»?
No. 27363  
>>27362
>А потом выпустят C++29 и окажется, что со своим C++26 ты тоже пердолился, представляешь?

Как в шланге появится - так и у меня появится :)

>Программирование существует, чтобы решать задачи бизнеса.

А рабы существуют - чтобы служить хозяину. Пшёл работать сверхурочно за плошку риса.

>Какие задачи бизнеса ты решаешь своими «compile-time вычислениями» и «ranges»?

Снижение издержек на поддержку кода.
No. 27364  
>>27363
Со смайликами, «пердоленьем», «рабами» и прочим вызывающе-хамским поведением, делающим затруднительной какую-либо разумную дискуссию, предлагаю пройти на другой ресурс (я не модератор).
No. 27365  
Я работал в Мотороле и в Нокии. Крупные конторы, выпускающие конкурентоспособные продукты на Запад. И нигде не гнались за использованием всего самого последнего только ради самого факта его использования. Как-то обходились без переписывания миллионов строк кодовой базы каждый раз, когда выходит новая фича. И издержки на поддержку кода всех устраивали. А итогом были клиенты, которые решали платить сотни миллионов долларов именно моей конторе, а не кому-то еще. И растущие каждый год зарплаты и годовые премии, потому что с каждым годом все больше денег зарабатывали.

>>27364
Поддерживаю этого Стива.
No. 27366  
>>27365 Вот поэтому рынок и просрали в том числе, что вместо полезной работы клиентов на бабло разводили, премии получали, да зряплаты увеличивали. Напоминает одного разработчика браузеров.
No. 27367  
>>27301-кун и вообще часто заглядывающий сюда вкатун на связи!

Я пилю свой проектик на .NET 7, который по сути выглядит как Web API для нейронки, которая распознаёт птиц ( https://github.com/kahst/BirdNET-Analyzer ).

Умеет:
1. Хранить и выдавать результаты распознанных аудиофайлов (SQLite + CRUDы)
2. Умеет работать стабильно долгое время (месяц беспрерывной работы и последующий парсинг результатов; это без перебоев питания - увы, автоматическое возобновление пока не сделал, на очереди).
3. Умеет записывать с нескольких микрофонов одновременно (общую очередь для 2<= микрофонов делаю прямо сейчас на работе) + можно выбирать нужное устройство ввода и для него свои настройки для нейронки.
Минусы:
1. Нет красивого Web UI.
2. Возможны баги
3. Не продолжает воспроизведение после перебоя питания
4. Нет логов и анализа производительности

Есть аналоги: https://github.com/mmcc-xx/BirdCAGE и BirdNET-Pi. Моей целью было сделать максимально легковесный с точки зрения ресурсов web API, т.к. стоять будет на бюджетных одноплатниках с 512мб RAM и 4 ядрами Cortex A-53. Ну и попрактиковаться, конечно.

Собственно, весной и летом буду тестить уже полностью, т.е. оставлю в деревне, раз в пару недель приезжать буду. Будет несколько микрофонов на одном одноплатнике, будет импровизированный бесперебойник на батарейках с алиэкспресса.

Пока что не сделал релиз, сегодня залью свежие собранные версии для linux-arm64, linux-arm, linux-x86_64.
https://github.com/okazaki0yumemi1/Bird-Box

Вопросов нет, хотел попросить примеры хороших readme на гитхабе. У меня с письменным английским туговато из-за отсутствия практики, но всё же допишу + сделаю на русском языке тоже.
No. 27368  
>>27366
Рынок мобилок - да. К счастью, я работал не с мобилками, а с базовыми станциями связи. Третье место по миру с 20% рынка она вполне себе держит много лет.
Эх, жаль, что из России им пришлось уйти. Менеджеры из финского офиса буквально плакали на созвоне, когда объявляли, что вынуждены закрыть наш филиал.
No. 27370  
>>27368 как будто ранок 5G базовых станций тоже не просрали Huaweю.
No. 27373  
share.png - (85.09KB, 950×489)
27373
>>27370
У Хуавея 30% мирового рынка, у Нокии - 20. Это не очень похоже на просирание.
No. 27374  
Как проверить, что предкомпилированные заголовки действительно используются при сборке?
Согласно документации https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html имеется возможность иметь несколько вариантов одного предкомпилированного заголовка. Для этого надо создать каталог с именем типа all.h.gch и указать на него компилятору, после чего он автоматически выберет подходящий.
Я, с помощью отдельных makefile, создаю в каталоге all.h.gch несколько заголовков тпа all1.h.gch, all2.h.gch, и т.д.
После этого, в makefile проекта, который должен использовать заголовок, я указываю путь до этого каталога: -I/path/to/all.h.gch.
Согласно документации, это должно привести к использованию предкомпилированного заголовка, но, судя по тому, что время компиляции изменяется в пределах статистической погрешности, этого не происходит.
Каким способом можно гарантированно проверить, компилируется ли заголовок каждый раз заново, либо же используется предкомпилированный, не измеряя время компиляции?
No. 27376  
>>27373
Ладно, вы правы, 150% - это ещё не полный просир.
No. 27377  
>>27376
Был бы у Хуавея рост до хотя бы до 50% за несколько - тогда можно было бы говорить о просере. Но доли рынка не меняются много лет. Тут уместнее говорить о том, что каждый занял свою нишу.
No. 27383  
Чиочан, а зачем нужен mutable? В чем смысл делать метод константным, а потом все равно в нем что-то менять? Это же не логично?
No. 27385  
>>27383
  • Какой-нибудь кэш элементарный:

private:
  mutable std::map<int, int> cache_;
public:
  int get(int key) const
  { 
    auto it = cache_.find(key);
    if (it != cache_.end()) {
      return it->second;
    }   
    return cache_[key] = get_value_for_key_costly_(key);
  } 


No. 27387  
Стив, привет! Что почитать / посмотреть / порешать по сетям и протоколам вонаби go бэкенду?
No. 27388  
Чиочан, такая ситуация. Собирается экзешник X, который зависит от самосборной статической библиотеки L1, которая зависит от самосборной статической библиотеки L2. Возможно ли так собрать L1, чтобы в нее включилась L2, и при сборке X надо было подключать только L1, не указывая L2?
No. 27389  
>>27388
ar r libL1.a l1.o l2.o

Объектник из libL2.a можно вытащить так, если надо:
ar x libL2.a
No. 27400  
Здесь кто-нибудь на ruby пишет?
У меня такой (нубский) вопрос:

Имеется, допустим, класс A, в нем метод foo. Имеется класс B, с классом A никак (кроме общих предков) не связанный. Задача — добавить в B точно такой же foo.

Ограничения.
1. Мы не можем редактировать исходный код классов A и B, только менять их динамически в результате выполнения нашего кода.
2. Более того, нам вообще неизвестен исходный код метода foo, поскольку на момент исполнения нашего кода он может быть произвольным образом изменен другим сторонним кодом.
3. Код метода foo никак не связан с другими методами и полями класса A. И вообще ему там не место, но рефакторить мы ничего не можем, см. п1. Вероятностью, что такая связь будет добавлена сторонним кодом, можно пренебречь.
4. Версия ruby — 1.9.2 (и нет, мы не можем поменять ее на более новую)

Пока что идеи такие:
1. Kак-то (как?) переместить текущее содержимое foo в отдельный модуль, после чего добавить его обоим классам в качестве миксина. Ну или вообще напрямую скопировать метод из одного класса в другой, как-то манипулируя с их внутренним устройством.
2. Kак-то подменить контекст вызова (скажем, в lua мы можем из B:foo вызвать A:foo как A.foo(self) — и контекст поменяется). В ruby есть UnboundMethod, но он требует близкородственных связей между классами, которых нет. (Их хваленая "утиная типология" не работает)
3. Как-то преобразовать содержимое A.foo в блок, который затем вызвать из B.foo. Есть Method.to_proc, но он жестко привязан к объекту (а нам объект класса A не нужен).

Поиск по stackoverlow не радует:
https://stackoverflow.com/questions/33708250/what-is-the-point-of-rubys-method-unbinding-mechanism
https://stackoverflow.com/questions/14132782/assign-a-method-from-one-class-to-an-instance-of-another
Возможно ли это вообще, или я слишком много хочу от этого языка?
No. 27403  
>>27400

> а нам объект класса A не нужен

Насколько это критично? Класс А настолько тяжелый?

Выглядит так, что совсем без аллокации объекта A не получится вытащить метод. Но можно избежать вызова A#initialize хотя бы:

A.allocate.method(:foo)

> (Их хваленая "утиная типология" не работает)

Иначе можно было бы взять нативный метод, типо Array#push, забиндить его на произвольный объект, и все, аварийный останов! Не типобезопасно... Думаю, это компромисс между утиной типизацией и строгой.
No. 27404  
faptcha_php.png - (4.47KB, 90×50)
27404
>>27403
>Но можно избежать вызова A#initialize хотя бы:
>A.allocate.method(:foo)
О, похоже, то что нужно. Вызов цепочки конструкторов был бы катастрофой, а всего лишь бессмысленное выделение памяти под фальшивый объект... некрасиво конечно (внутренний слаанешит плачет кровавыми слезами), но пережить можно.

Собственно, при таком подходе никакой перенос методов не нужен, хватит простого вызова
A.allocate.foo

Спасибо!
О, и пикрелейтед на капче
No. 27407  
И снова я, снова то же ruby 1.9.2 (RPGmaker VX ACE)

Наткнулся на странное поведение Exception.backtrace в случае наличия eval в цепочке вызовов. Имеем такой пример кода:
def foo

    raise "shit"
end
def bar
    foo
end
def baz
    eval('bar')
end

Перехватываем исключение, смотрим этот самый backtrace и видим такую хрень:
  • test.rb:10:in 'eval'
  • test.rb:6:in 'bar'
  • (eval):1:in 'baz'
  • test.rb:10:in 'eval'
  • test.rb:10:in 'baz'
Вместо верхней строчки стека — тот самый eval.
Если убрать eval и вызывать bar напрямую, то всё работает корректно:
  • test.rb:2:in 'foo'
  • test.rb:6:in 'bar'
  • test.rb:10:in 'baz'
Понимаю, что скорее всего это баг древней версии, с которым мне никто не поможет, но всё-таки... Может есть какой-нибудь известный способ вытащить верхнюю (и самую важную) строчку стека, которую этот eval собой затирает?

Движок, всё-таки, широко известен, игрушек на нем было сделано много, наверняка не я один в нем до сих пор копаюсь. И наверняка не я первый на этот баг наткнулся. Но в гугле, увы, ничего путного не нашел...
No. 27408  
>>27407 UPD
Костыльное решение (вполне очевидное, но весьма кривое): перехватывать исключения до того, как они прошли через в eval.

В листинге выше это можно сделать, например, в bar. Или даже внутри эвала, которой в baz.
Если обернуть передаваемый ему код в begin/rescue, то внутри этого rescue стек, пока еще, будет в порядке. И можно его где-нибудь сохранить или записать в лог.

А как исключение пройдет через eval, то всё, в стеке мусор.
No. 27409  
>>27407
А если

eval 'bar'

заменить на

instance_eval { bar }

то все равно поломанный бектрейс будет?
No. 27410  
>>27409
Не, с instance_eval, тьфу-тьфу, всё нормально.
Но, к сожалению, не всегда одно можно так просто заменить на другое.

По крайней мере я таких способов не вижу. Хотя может я просто не в курсе, язык пока знаю плохо.
Если нам пришел код в виде строки, то можно ли как-то сделать его блоком и запихать в этот instance_eval?
No. 27411  
>>27410

> Если нам пришел код в виде строки, то можно ли как-то сделать его блоком и запихать в этот instance_eval?

Так-то instance_eval принимает строку тоже. Еще мне пришли в голову две вещи:

1) Сделать процедуру из строки (чтоб отложить выкидывание исключения до исполнения процедуры) каким-нибудь таким образом:
block = &eval("proc {#{str}}")

instance_eval &block


2) Если у тебя там MRI руби, то поэксперементирвать с этим:
RubyVM::InstructionSequence.compile(str).eval


>Но, к сожалению, не всегда одно можно так просто заменить на другое.

А что за задача? Вообще, я очень редко пользовался eval, единственное место, где я его нашел у нас, так это в самодельном обфускаторе для руби.
No. 27412  
>>27411
Фикс:

block = eval("proc {#{str}}")

instance_eval &block

No. 27413  
>>27411
>Так-то instance_eval принимает строку тоже.
И в случае со строкой его поведение ничем не отличается от eval, т.е. имеем ту же проблему.
Что вообще-то логично, потому что код обе эти функции скорее всего используют один и тот же.

Пока что я использую вот такую вот затычку: https://pastebin.com/Fy5Uc82L
И соответственно, буду подключать этот EvalFixer во все места, где такая неоходиость возникнет. Их там не так много, вроде. Помимо этого Game_Interpreter еще 2-3.
Сперва хотел вообще глобальный eval переопределить, но полезли какие-то странные ошибки и я решил не связываться.
Кстати, на пастебине тоже фейлится подсветка синтаксиса. Сколько я бился, чтобы поправить ее у себя в редакторе, так до конца и не. Хотя сейчас уже гораздо реже, чем вначале.

>block = eval("proc {#{str}}")
Э... но какой в этом смысл, если мы всё равно вызываем тот самый эвал?

>RubyVM
Посмотрю, но кажется там такого нет.

>А что за задача?
Копаюсь в RPGmaker, если кратко.
Эвенты. Всё хрантся у него в базе, а потом обрабатывается этим самым Game_Interpreter (и еще в нескольких местах), если там код, то вызывается через этот самый эвал.
Привожу это всё к такому виду, чтобы можно было с ним нормально работать внешними средствами, потому что его внутренняя среда это тихий ужас. Соответственно, возникла задача логирования и обработки ошибок, в процессе которой это всё и вылезло.
Движок сильно недооценен, между прочем. Среда позволяет его использовать где-то на 10%. И абсолютное большинство игрушек на этом и останавлвается.

Вообще, то решение, к которому я сейчас пришел, меня пока устраевает. Так что, если в нем не обнаружится каких-нибудь подводных камней, то на этом видимо и остановлюсь.
No. 27414  
>>27413
>>block = eval("proc {#{str}}")
>Э... но какой в этом смысл, если мы всё равно вызываем тот самый эвал?

Хм... Смысл, похоже, есть. Потому что в таком исполнении оно, внезапно, работает правильно.

(немного подумав)
А, ну да. Мы же в эвале лишь создаём блок. Наши эксепшены через эвал не проходят. Всё понял, был неправ.
Это решение лучше, чем то, что я там нагромоздил.
Пошел переписывать EvalFixer.
No. 27416  
>>27413

Понятно.

>И соответственно, буду подключать этот EvalFixer во все места, где такая неоходиость возникнет. Их там не так много, вроде. Помимо этого Game_Interpreter еще 2-3. Сперва хотел вообще глобальный eval переопределить, но полезли какие-то странные ошибки и я решил не связываться.

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

До фикса, как я понимаю, исполнение скрипта 'def f; end' определяло метод Game_Interpreter#f. Однако же instance_eval создаст "собственный" метод f для инстанса Game_Interpreter. Разница проявится, если в RPGMaker создается несколько инстансов Game_Interpreter. В первом случае метод f будет доступен для всех инстансов, во втором - только для того конкретного инстанса, который выполнял скрипт с определением f.

Наверное, проблему можно будет решить созданием глобального объекта ctx, и исполнением ctx.instance_eval { ... } вместо просто instance_eval.

>>27414

>Мы же в эвале лишь создаём блок. Наши эксепшены через эвал не проходят.

Ага. Я еще пытался придумать такой str, чтобы "proc { #{str} }" сломанный код произвело, но не придумал.
Удалить сообщение []
Пароль  
[Mod]