перепиши.

>Где я возьму столько памяти? НЕНАВИСТЬ!

Это что же ты такое конвертируешь?

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

Это что же ты такое конвертируешь?

Файлы. Большие. Гига по три.

патч@отправляй
._.
btw, так, емнип, все coreutils'ы поступают.

3 гига в текстовом файле это какой-то нонсенс

Уже говорили: перепиши. Т.к. для детального анализа доминирующей кодировки, все-таки, надо просмотреть весь файл. А как-то не предполагается, что бывают текстовые файлы гигабайтных размеров. Я вообще не представляю, что в таком файле может быть?

Зато в сжатом виде - 200 метров всего ._.

Уже говорили: перепиши. Т.к. для детального анализа доминирующей кодировки, все-таки, надо просмотреть весь файл.

вообще-то, я её явно указываю

А как-то не предполагается, что бывают текстовые файлы гигабайтных размеров. Я вообще не представляю, что в таком файле может быть?

текст

и кстати, я видно чего-то не понимаю, но мой иконв не грузит весь файл в память перед конвертацией.

iconv --version

iconv (GNU libiconv 1.13)
Copyright (C) 2000-2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

http://motivpic.com/users_data/pics/1/18/original-ha-ha.jpg

file1: data
1.2G file1
Mem: 568M Active, 275M Inact, 731M Wired, 21M Cache, 360M Free
свопа нету.
все нормально проходит и файл конвертируется.
единственный минус - файл взят из /dev/random.

> Оказывается, оно перед тем, как начать конвертировать, загоняет весь файл в оперативку.

Файлы. Большие. Гига по три.

Может хватит уже заниматься пермутацией Торы? :)

Хм, у меня iconv из eglibc вообще. Вот кого надо пинать )

>Файлы. Большие. Гига по три.

Сурово

> файл взят из /dev/random.

точно из /dev/random? быстро там гигабайт набежал?)

Переконвертируй в потоке

Переконвертируй в потоке

Так он не посмотрит на размер файла и будет считывать поток, пока не съест всю память. Потом ругнётся и вывалится.

Скорее всего, дело в простенькой реализации в eglibc

А если enca заюзать?

Кстати, гугль выдает костыли по запросу «iconv large file», так что дерзай.

s/enca/enconv/

>> Это что же ты такое конвертируешь?

Файлы. Большие. Гига по три.

не представляю, что в таком файле может быть?

текст

КЭП конвертирует файлы

чуть больше двух минут.

Кстати, гугль выдает костыли по запросу «iconv large file», так что дерзай.

Да там и свои недолго написать. Это нытик-тред же, тег забыл просто. Ваш линукс не готов для десктопа и все дела )

чуть больше двух минут.

удивительно. по-хорошему, для таких целей urandom надо использовать, не?

>Ваш линукс не готов для десктопа и все дела )
Попробовал бы ты в винде такую же проблему обойти в гуевой проге какой нибудь, посмотрел бы я на тебя :D

костыль уже есть — piconv

не знал.

А вот и не угадал. Тот же utf8 под такое пустить нельзя.

ну побьется у тебя пару символов =)

Можно резать по строкам или пробелам - но их тоже может не быть. Так что написать хороший костыль не так уж и легко.

ну или по строкам разбить.

А ты хорошо мыслишь )

[3970] [neko][1]%time dd if=/dev/urandom of=/dev/null bs=4M count=250 [part2/null]
250+0 records in
250+0 records out
1048576000 bytes transferred in 13.241987 secs (79185699 bytes/sec)
dd if=/dev/urandom of=/dev/null bs=4M count=250 0.00s user 13.24s system 99% cpu 13.244 total
[3971] [neko][0]%time dd if=/dev/random of=/dev/null bs=4M count=250 [part2/null]
250+0 records in
250+0 records out
1048576000 bytes transferred in 13.241083 secs (79191105 bytes/sec)
dd if=/dev/random of=/dev/null bs=4M count=250 0.00s user 13.24s system 99% cpu 13.244 total

а может и такое быть

dan@dan-desktop:~$ dd if=/dev/urandom of=/dev/null bs=4M count=25
25+0 записей считано
25+0 записей написано
скопировано 104857600 байт (105 MB), 21,6888 c, 4,8 MB/c
dan@dan-desktop:~$ dd if=/dev/random of=/dev/null bs=4M count=25
^C0+8 записей считано
0+8 записей написано
скопировано 80 байт (80 B), 21,2269 c, 0,0 kB/c

да что уж там, вот http://ru.wikipedia.org/wiki//dev/random_и_/dev/urandom

Это в каком-таком дистрибутиве такой говно-/dev/random ?

Или просто очень много шумов

Нет, их просто не может быть так много >_<

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

FreeBSD, по документации разница между random и urandom такая же, как и в линуксах
алсо, скорее всего urandom должен быстрее random'а обрабатываться, однако скорость их обработки упирается в потолок где-нибудь в более другом месте, нежели cpu.

Конечно решаемо. Я думал, что iconv примерно так и написан )

Когда он был задуман, наверно думали, что 640Кб (или сколько там) хватит всем =)

Как можно замерить сколько памяти занял процесс при выполнении?

NekoExMachina> FreeBSD, по документации разница между random и urandom такая же, как и в линуксах

Гонишь:

The FreeBSD operating system implements a 256-bit variant of the Yarrow algorithm to provide a pseudorandom stream — this replaced a previous Linux style random device. Unlike the Linux /dev/random, the FreeBSD /dev/random never blocks. It is similar to the Linux /dev/urandom, intended to serve as a cryptographically secure pseudorandom number generator rather than based on a pool of entropy (FreeBSD links urandom to random).

Когда он был задуман, наверно думали, что 640Кб (или сколько там) хватит всем =)

Думаешь, лишние проходы прибавляют производительности? Это ведь настолько очевидно, что нужно посимвольно обрабатывать ._.