для первого инта зато можно диапазон подобрать

если null-terminated

да, или последний

тогда там будет урезанный int

но поскольку он у нас номер чанка в аллокаторе, то урезанность это нормально

а вообще сколько у нас символов получается?

8*3 - 1

23 - для этой задачи даже хватит

если какие-то csv парсить то куча строк будет попадать инплейс

а для внешнего можно тоже что-то умное сделать

и выровняное

@voidlizard 1) куча имплементаций анбоксед массивов - это несколько массивов, но она вообще произвольная это не сторабл, где все последовательно обычно. 2) ну да, скопирует

но у вектора нету штатного интерфейса увеличения длины

сделал в common lisp буферизацию, но вроде не сильно спасло

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

и рантайма

смотришь на пачку импортов на хаскеле, и на 100 вариантов одного и того же, и что-то как-то

главная фишка pypy jit?

да

ладн попробую ещё на эликсире

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

@voidlizard самое противное что все из этих 100 вариантов не очень

и вот этот гадский один способ - работает довольно хорошо в итоге

чот с буферизацией получилось в полтора раза медленнее, чем без нее

в принципе, это решается каким-то добровольцем, который сделает норм альтернативный prelude

для повседневных нужд

и этот prelude путем каких-то обсуждений? дискуссий? голосований? формировать

и прилагать усилия к его оптимизации

в принципе решается даже без переделки языка

в девнулл пишет с той же скоростью, что и в файл. Хреновый из меня лиспер 8)

наверное, задача даже решаемая. и даже инкрементально решаемая

Уже мильёны прелюдий есть, мне все не нравятся

да. но почему?

нельзя вот сделать какие-нить строки - достаточно хорошие для повседневных нужд?

То всё на тайпклассах, то неймспейс засран какими-то кондуитами

про кондуиты мы тут надысь видели бенчмарки

Так есть Text. Но повсюду лезут String

Text тоже тормоз

но может, с UTF лучше и нельзя

так что наверное, иметь Text для UTF и ByteString для байтов - это ок

вопрос надо ли иметь набор всего для ленивых и энергичных

В Питоне можно не боятся застать неймспейс. Байтстринги и текст добавят всего 2 имени. В хаскеле не канает

потому что этот фактор и порождает значительный разброд

@A64m_qb0 кстати больше места

а не, оно выравнено...

ну, не боятся и правильно, а чего бояться? у нас вообще компилятор это проверяет

но вообще можно выравнивать по 32

Я считаю что надо переименовать ByteString.Lazy и Text.Lazy в .Stream

тогда у нас 3 char * полных есть или 31 символ

Избавиться от строгих строк/байтсрингов мне кажется не выйдет.

+

а нельзя сделать строки - строгими, а для чанкования - оставить билдер?

билдер это чанкование в сторону записи

А если выпилить ленивые то, то любой стриминг придётся делать руками

LBS это в сторону чтения

ну сделать какой-нить Writer, Reader

вот какие-нить удобные стримы общего вида было бы хорошо

Dmitry ну а как разрулить три lenght например? Тайпклассы? Префиксы?

но сейчас тут такой разброд и одно решение хуже другого

ты не того Дмитрия пнул

readFile Handle -> (chunk -> IO Writer) -> IO Writer

все эти pipes, machines, conduit, streaming

хорошо хотя бы с типов Pipe вроде устаканилось

Черт, дурной телеграмм

чт бы, короче, файлы не "якобы-одним-шматком" читать, а по кускам

но для меня все ещё не очевидно что все это лучше iteratee старого доброго

или сделать явные врайтеры - "все целиком" или "по кускам"

@voidlizard возможно вы имели ввиду hReadBuf ?

в base

ну или ридеры, наоборот

возможно, что-то такое

поидее все для этого есть даже в стандартной либе

но low level

а почему-то все эти дурные conduit от этого уводят далеко

кондуит / итерати превращают код в черти-что

в итоге заюзать дешевый интерфейс нереально

ну не говоря о том, что еще и тормозят

iteratee ваще для сильных духом

У меня с пайпами никаких особых пробле не было. Но я был CPU-bound да и логика довольно простая была

они делают код сложным и пайпо-специфичным. вот их проблема