Ну пайпоспецифичность неизбежна. Как только стриминг делается явно — мы привязываемся к его API

мне кажется, можно написать что-то может не такое универсальное, как кондуиты, но намного более простое в использовании и внедрить это в стандартную библиотеку (которая вообще что такое?)

Стандартная библиотека для написания факториалов

ну т.е подход s <- readFile приводит сразу к тому, что все надо обкладывать регрессионными тестами

И тут сразу возникает проблема интеропа между простым решением и условными пайпами

на го не приходя в сознание написал что-то, но чет мд5 не сходится там кие-то подводные камни есть? типа в конце не надо \n или еще чего?

обычная ошибка - \r в конце сроки или префик с суффиксом перепутал

сейчас streaming самый простой

@quetzal \r надо вырезать

там \r\n переносы

в оригинальном файле \r\n переносы?

да, там \r

а в выхлопе - \n должны быть

@PineappleZombie если сделать нормальный дизайн IO библиотеки - то эти все пайпы может не нужны будут

ага сходится теперь

2.74

кстати

но это прям ВООБЩЕ не думая о каких-то оптимизациях там

в веткорах сейчас стриминг не факт что использует блоки

@PineappleZombie у меня на сях обычный подход size_t readFile(int file, void *cc, bool (*consumer(void*, size_t len, char *data))

и ничо, жить можно.

и копирует по символу, поидее можно улучшить используя этот новый интерфейс

@quetzal давай у себя запущу

у меня самый тормозной ноут на нём прогоняем

ну или запусти у себя pypy версию и относительно неё смотри

я боюсь, что я не представляю как иметь разумные гарантии и не говорить о потоках явно

https://gist.github.com/quetz/4f9358724c70f4d92773e4a3714dce2e

go build spol.go time ./spol 49zGQ6Zt.txt > /dev/null

вообще я очень хочу осилить тапл с примерами кода и написанием компилятора и запилить какой-нить язычок где вот все эти стримы хорошо пишутся

@quetzal stdin - requirement

@quetzal как это на линуксах быстрее всего собрать?

На сях прихдится делать явно всё

читать из stdin - писать в stdout обязательно

ну в стдаут и пишет

ща, чтение

@quetzal 3.58

так, где там моя ставка

@voidlizard nix-shell -p go

/stat@combot

combot.org/chat/-1001043143583

лучше pypy

не, ну что - как наивная версия на расте

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

combot.org/chat/-1001043143583

ну вы олимпийцы

в общем я придумал 3 улучшения для си, но я не буду их делать

у нас community health аж 40% в статах =)

https://gist.github.com/quetz/4f9358724c70f4d92773e4a3714dce2e

go это фронтенд к gcc ?

ну вот stdin

go это фронтенд к gcc ?

там есть gccgo но оно нишевое

для тех архитектур где гугловый компилятор не заводится

dmz@zen ~/tmp/bsfuck $ time ./spol < 49zGQ6Zt.txt > /dev/null real 0m3.628s user 0m3.616s sys 0m0.012s

как у первого варианта на расте

не ужасно короч

учитывая что пишется за 5 минут

и ваще без включения мозга

синт. мусора поменьше, чем в расте, но в целом синтаксис странноватый

но не сильно

а давай тупую буферизацию еще?

он одну большую строку делает?

https://gist.github.com/quetz/4f9358724c70f4d92773e4a3714dce2e

а не

вот haskell-ным либам не хватает bufio

синт. мусора поменьше, чем в расте, но в целом синтаксис странноватый

но и гц побольше

аж целый один)

LBS.putStr $ toLazyByteString $ builder более дорогая абстракция

dmz@zen ~/tmp/bsfuck $ time ./spol < ./49zGQ6Zt.txt > /dev/null real 0m3.622s user 0m3.620s sys 0m0.004s

на luajit не вышло сделать быстрее pypy ((

тупо буферизация не помогла

да даже hPutBulder builder

хотя добавляется легко

кстати, надо почитать исходники hPutBuilder что там тормозит

у меня помогла и вместо строчки newline делать символом тож https://gist.github.com/quetz/4f9358724c70f4d92773e4a3714dce2e оттак

у меня 2.35 в итоге

собирать - вот так: go build ./spol.go ?

или есть хитрости?

а, уже написали на го?

не, прям так го 1.9

а, уже написали на го?

да чо там писать-то