SP
а. 4кб. збс
arm-none-eabi-objcopy -O binary \
target/thumbv7m-none-eabi/release/stm32_blink stm32_blink.bin
Size: a a a
2020 July 17
SP
перестается правда шиться но я понял почему лол
NL
Вот поэтому у коммунистов никогда не будет частных инноваций
Если это шутка, то плохая. Это называлось "рацпредложение" и практика их внедрения активно поощрялась и была очень распространена.
Попробуй сейчас внедрить какой-нибудь улучшенный процесс шлифования деталей.
Попробуй сейчас внедрить какой-нибудь улучшенный процесс шлифования деталей.
H
кек
H
H
> Read the relevant RFCs and write it yourself. It's really not hard.
H
типикал си сообщество
DF
Но в кернеле есть iphdr же
DF
Или ему для юзерспейса?
DF
Я читал код lvs/ipvs там ядреные встроенные функции используются
DF
Кстати незаслуженно забытая технология
DF
L4 лод балансеры рулят
T1
Dollar Føølish
Но в кернеле есть iphdr же
+
T1
нахуй тебе это делать
T1
ты с TCP заебёшься это делать
T1
если валидное соединение захочешь сделать
T1
Dollar Føølish
Или ему для юзерспейса?
А в чем разница?
NL
@nlinker ты говорил что у меня код слишком КОНКРЕТНЫЙ, и нужно больше обобщенности. Но вопрос: а нафига она мне?? У меня в коде редко когда появляются обобщенные параметры, ибо нафига они нужны, если я пишу приложение а не библиотеку? Библиотека обязана быть обобщенной дабы возможно было использовать ее под разные кейсы, и чем более она обобщена, тем под большее количество кейсов подходит. А приложение пишется под конкретную задачу и логично там использовать конкретные типы данных.
Это бы ответ на то, что мол сигнатура выглядит чересчур страшно.
Возьмём пример:
Этот код плох, потому что трудно читаемый, трудно тестируемый, содержит слишком много деталей (логирование, ошибки, логику) в одном месте, не говоря уже о других проблемах.
А правильный подход в данном случае -- взять подход с композабельными эффектами, (TF, FM, polysemy, трансформеры), выделить в отдельную алгебру весь REST, в отдельную -- весь логгинг, обернуть нужные алгебры в логгинг и бизнес логику сформулировать в терминах абстрактных операций.
Кстати, само то, что сигнатура какая-то большая не является проблемой сама по себе, а свидетельство неправильных абстракций. Если там просто много параметров, то это не проблема :-)
Возьмём пример:
saveFile :: Path -> Bytes -> IO Unit saveFile p f = do
log ("Saving file" ++ show (name p) ++ " to " ++ show (parentDir p))
r <- httpPost ("cloudfiles.fooservice.com/" ++ (show p)) f
if (httpOK r) then log ("Successfully saved file " ++ show p)
else let msg = "Failed to save file " ++ show p
in log msg *> throwException (error msg)
Этот код плох, потому что трудно читаемый, трудно тестируемый, содержит слишком много деталей (логирование, ошибки, логику) в одном месте, не говоря уже о других проблемах.
А правильный подход в данном случае -- взять подход с композабельными эффектами, (TF, FM, polysemy, трансформеры), выделить в отдельную алгебру весь REST, в отдельную -- весь логгинг, обернуть нужные алгебры в логгинг и бизнес логику сформулировать в терминах абстрактных операций.
Кстати, само то, что сигнатура какая-то большая не является проблемой сама по себе, а свидетельство неправильных абстракций. Если там просто много параметров, то это не проблема :-)
NL
