НК
сделать_красиво()''' Быстро_Качественно_Дешего'''
Size: a a a
2020 March 06
OK
Пусть откроет для себя touch designer, займётся виджейством и больше никогда пусть не занимается программированием
У него, кстати, на сях есть проект, в котором с помощью библиотеки allegro имитируется интерфейс win 3.11(и кто ему мешал qt/gtk посмотреть?)
O
Никита Кучеренко
''' Быстро_Качественно_Дешего'''
Ладно, сойдёмся на "красиво", можно без "сделать"
НК
#ТЫЖпрограаммист
KK
developer.do_hren_fast_high_quality_cheap(hren).money_in_half()
/¯
сделать_красиво()static HRESULT STDMETHODCALLTYPE d2d_device_context_MakeBeautiful(ID2D1DeviceContext *iface)
{
FIXME("iface % stub!\n", iface);
return E_NOTIMPL;
}O
static HRESULT STDMETHODCALLTYPE d2d_device_context_MakeBeautiful(ID2D1DeviceContext *iface)
{
FIXME("iface % stub!\n", iface);
return E_NOTIMPL;
}Во-первых, это красиво...
W
Прост это для меня дико как-то. Когда писал на GAS под arm, и тут вспоминаешь, что какой-то сайтик весит раз в десять больше твоей прошивки...
W
Ведь раньше помнил это, когда безопасником подрабатывал.
ох уж эти дыры в ассоциативных связях...
ох уж эти дыры в ассоциативных связях...
TW
не замечал
попробуй вызвать
void test(){
test();
}
попробуй вызвать
void test(){
test();
}
Ну у меня gcc с o3 оптимизацией это в простые jmp скомпилил. То есть никакого стэк оверфлоу нет
TW
Ну и желательно иметь условие выхода, чтобы это можно было однозначно в 'цикл' развернуть
АВ
>> protobuf и другие не подошлиНа этом моменте уже по-подробнее нужно, пожалуйста. Если мне не подходит
protobuf и другие — тут уже не инструмент искать, а плакать...>> библиотеку-рантайм языкаТ.е. первый шаг == интеграционные проблемы
>> за 15 минутВ идеальном мире. В реальном же откинут твою библиотеку по причинам: не нашли в гугле, джун, которому поручили эту ерунду, запутался в readme, Буст уже и так подключен, регулярки для парсинга бинарных данных всё ещё интуитивнее кому-то. Как продвигать?
>> И библиотека сделает всё самаТ.е. либо неэффективно, либо совершенно нет точек кастомизации
>> написать 10 строк описанияПредварительно изучив тысячи строк readme
>> просто поменять его описаниеКто ответственный, когда мы в коде сделаем hard reset на несколько коммитов назад и у нас структура изменится на предыдущий вариант, а мы уже в прод залили?
>> соблюдать несколько правил обратной совместимостиТ.е. ручное версионирование? А чем... лучше?
Где есть возможность хранить массивы значений произвольной битности? Например, есть временной ряд с миллионом целочисленных значений параметра в интервале от 0 до 15, для хранения одного значения достаточно 4 бит. В protobuf нет, в flatbuffers тоже, а мне такое нужно было недавно на работе, чтобы уменьшить объём данных, передаваемых через Интернет. А ещё нужно было паковать вместе несколько разных параметров разной битности и слать с самолёта по спутниковой связи, где один килобайт стоит больше доллара.
Если бы у меня была реализация моего языка, я бы это сделал за 15 минут. А так пришлось пилить свой протокол с ручной упаковкой бит и дебажить всё это неделями. Потом протокол менялся и приходилось дебажить снова.
Никаких интеграционных проблем. При наличии биндинга пишешь две строчки на хостовом языке программирования, и в твоя структура автоматически сериализуется и десериализуется в твой формат.
Если твоя структура данных в программе совпадает с той, которая в файле, файл просто замапится в память или скопируется через memcpy. Будет не медленнее, чем flatbuffers. Если структура не совпадает, то всё автоматически сконвертится и это будет не медленнее, чем код, который делает это вручную.
Не будет в ReadMe тысячи строк. Будет онлайн редактор, в котором можно написать описание формата и проверить прямо в браузере, а потом вставить себе готовое решение. А писать можно, взяв за основу примеры. Специально делаю синтаксис с минимальным количеством правил без подводных камней и синтаксического сахара.
С откатом кода назад проблем быть не должно. Если в новой версии кастомного формата появились новые поля, старая версия программы всё равно сможет прочитать этот файл, проигнорировав эти новые поля. Если изменить тип существующего поля, например @int16 на @int32 или наоборот, библиотека сама всё сконвертит. Если каких-то старых полей не хватает, то да, она их не увидит. Но в новом формате можно это предусмотреть и прописать константу, алиас или формулу для вычисления старых полей через новые. То есть при желании можно создавать версии формата, совместимые в обе стороны. И не нужно никаких ручных номеров версий в заголовке файла - с моим языком такой подход уйдёт в прошлое.
Если бы у меня была реализация моего языка, я бы это сделал за 15 минут. А так пришлось пилить свой протокол с ручной упаковкой бит и дебажить всё это неделями. Потом протокол менялся и приходилось дебажить снова.
Никаких интеграционных проблем. При наличии биндинга пишешь две строчки на хостовом языке программирования, и в твоя структура автоматически сериализуется и десериализуется в твой формат.
Если твоя структура данных в программе совпадает с той, которая в файле, файл просто замапится в память или скопируется через memcpy. Будет не медленнее, чем flatbuffers. Если структура не совпадает, то всё автоматически сконвертится и это будет не медленнее, чем код, который делает это вручную.
Не будет в ReadMe тысячи строк. Будет онлайн редактор, в котором можно написать описание формата и проверить прямо в браузере, а потом вставить себе готовое решение. А писать можно, взяв за основу примеры. Специально делаю синтаксис с минимальным количеством правил без подводных камней и синтаксического сахара.
С откатом кода назад проблем быть не должно. Если в новой версии кастомного формата появились новые поля, старая версия программы всё равно сможет прочитать этот файл, проигнорировав эти новые поля. Если изменить тип существующего поля, например @int16 на @int32 или наоборот, библиотека сама всё сконвертит. Если каких-то старых полей не хватает, то да, она их не увидит. Но в новом формате можно это предусмотреть и прописать константу, алиас или формулу для вычисления старых полей через новые. То есть при желании можно создавать версии формата, совместимые в обе стороны. И не нужно никаких ручных номеров версий в заголовке файла - с моим языком такой подход уйдёт в прошлое.
АВ
У мну тут товарищ все пропагандирует идею всемирной библиотеки модулей, благодаря которой можно было бы строить приложения посредством перетаскивания мышью всяких блоков (таких, как "кнопка, которая делает FFT")
Я нечто похожее планирую в своём языке, но в текстовом виде. Сделать как можно больше различных обобщённых алгоритмов, а потом собирать из них программу как конструктор в декларативном виде.
Я даже когда-то делал нечто вроде декларативного конструктора шейдеров в своём графическом движке как альтернативу убершейдерам. Такая идея мне очень нравилась и круто работала, и я нигде не видел ничего подобного.
Я даже когда-то делал нечто вроде декларативного конструктора шейдеров в своём графическом движке как альтернативу убершейдерам. Такая идея мне очень нравилась и круто работала, и я нигде не видел ничего подобного.
O
Где есть возможность хранить массивы значений произвольной битности? Например, есть временной ряд с миллионом целочисленных значений параметра в интервале от 0 до 15, для хранения одного значения достаточно 4 бит. В protobuf нет, в flatbuffers тоже, а мне такое нужно было недавно на работе, чтобы уменьшить объём данных, передаваемых через Интернет. А ещё нужно было паковать вместе несколько разных параметров разной битности и слать с самолёта по спутниковой связи, где один килобайт стоит больше доллара.
Если бы у меня была реализация моего языка, я бы это сделал за 15 минут. А так пришлось пилить свой протокол с ручной упаковкой бит и дебажить всё это неделями. Потом протокол менялся и приходилось дебажить снова.
Никаких интеграционных проблем. При наличии биндинга пишешь две строчки на хостовом языке программирования, и в твоя структура автоматически сериализуется и десериализуется в твой формат.
Если твоя структура данных в программе совпадает с той, которая в файле, файл просто замапится в память или скопируется через memcpy. Будет не медленнее, чем flatbuffers. Если структура не совпадает, то всё автоматически сконвертится и это будет не медленнее, чем код, который делает это вручную.
Не будет в ReadMe тысячи строк. Будет онлайн редактор, в котором можно написать описание формата и проверить прямо в браузере, а потом вставить себе готовое решение. А писать можно, взяв за основу примеры. Специально делаю синтаксис с минимальным количеством правил без подводных камней и синтаксического сахара.
С откатом кода назад проблем быть не должно. Если в новой версии кастомного формата появились новые поля, старая версия программы всё равно сможет прочитать этот файл, проигнорировав эти новые поля. Если изменить тип существующего поля, например @int16 на @int32 или наоборот, библиотека сама всё сконвертит. Если каких-то старых полей не хватает, то да, она их не увидит. Но в новом формате можно это предусмотреть и прописать константу, алиас или формулу для вычисления старых полей через новые. То есть при желании можно создавать версии формата, совместимые в обе стороны. И не нужно никаких ручных номеров версий в заголовке файла - с моим языком такой подход уйдёт в прошлое.
Если бы у меня была реализация моего языка, я бы это сделал за 15 минут. А так пришлось пилить свой протокол с ручной упаковкой бит и дебажить всё это неделями. Потом протокол менялся и приходилось дебажить снова.
Никаких интеграционных проблем. При наличии биндинга пишешь две строчки на хостовом языке программирования, и в твоя структура автоматически сериализуется и десериализуется в твой формат.
Если твоя структура данных в программе совпадает с той, которая в файле, файл просто замапится в память или скопируется через memcpy. Будет не медленнее, чем flatbuffers. Если структура не совпадает, то всё автоматически сконвертится и это будет не медленнее, чем код, который делает это вручную.
Не будет в ReadMe тысячи строк. Будет онлайн редактор, в котором можно написать описание формата и проверить прямо в браузере, а потом вставить себе готовое решение. А писать можно, взяв за основу примеры. Специально делаю синтаксис с минимальным количеством правил без подводных камней и синтаксического сахара.
С откатом кода назад проблем быть не должно. Если в новой версии кастомного формата появились новые поля, старая версия программы всё равно сможет прочитать этот файл, проигнорировав эти новые поля. Если изменить тип существующего поля, например @int16 на @int32 или наоборот, библиотека сама всё сконвертит. Если каких-то старых полей не хватает, то да, она их не увидит. Но в новом формате можно это предусмотреть и прописать константу, алиас или формулу для вычисления старых полей через новые. То есть при желании можно создавать версии формата, совместимые в обе стороны. И не нужно никаких ручных номеров версий в заголовке файла - с моим языком такой подход уйдёт в прошлое.
>> Где есть возможность хранить массивы значений произвольной битности
Важнее другое, сколько раз в жизни это понадобится в современном мире, где JS засовывают в микроконтроллеры? Т.е. этот пункт уже относится к крайне узкому применению>> дебажить всё это неделями
Целый язык дебажить, конечно же, не нужно>> на хостовом языке программирования
Можно пример для C++, желательно без макросов?>> Если твоя структура данных в программе совпадает с той, которая в файлеТак мы ещё и анализ содержимого файла делаем? Мы на шаблонах научились эмулировать контракты, можно ли на твоей реализации сериализатора поиграть в крстики-нолики)
>> Будет онлайн редакторНадеюсь, не только он, безопасность же и NDA
>> библиотека сама всё сконвертит
Можно где-то почитать про анализ бинарных даннх и то, как это длжно работаь?А если серьёзно — я не говор, что дея плохая. Она просто... Недостаточна нужна твоей ЦА. Точнее, ЦА слишком узкая
O
Я нечто похожее планирую в своём языке, но в текстовом виде. Сделать как можно больше различных обобщённых алгоритмов, а потом собирать из них программу как конструктор в декларативном виде.
Я даже когда-то делал нечто вроде декларативного конструктора шейдеров в своём графическом движке как альтернативу убершейдерам. Такая идея мне очень нравилась и круто работала, и я нигде не видел ничего подобного.
Я даже когда-то делал нечто вроде декларативного конструктора шейдеров в своём графическом движке как альтернативу убершейдерам. Такая идея мне очень нравилась и круто работала, и я нигде не видел ничего подобного.
* шёпотом * Python!
KK
Питонисты вон на юльку не горят желанием пересаживаться даже
KK
Лол, яндекс карты не по маячкам ориентируются, а по расписанию
KK
И отрисовывают интерполяцией
KK
Я про транспорт
C
Лол, яндекс карты не по маячкам ориентируются, а по расписанию
Когда как.