ну а как вы деплоите?

ну и вообще, ассеты же временные файлы как по мне, им не место в репозитории

ну и вообще, ассеты же временные файлы как по мне, им не место в репозитории

да, скопмиленные ассеты не стоит хранить в репе

зачем??

что зачем?

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

просто у меня капистрано при деплое ассеты рекомпилит

просто у меня капистрано при деплое ассеты рекомпилит

так и я об этом

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

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

Например, чтобы сервер такими делами не занимать, вдруг, у тебя одна нода за 200 рублей и та на ладан дышит? :)

тогда тебе не нужна рельса

через rails r воспроизводится? Без рельс воспроизводится? Если StringIO закрывать, воспроизводится?

Я некрофил, но раньше не мог. Короче стринг IO не причем, хоть закрывай, хоть без него в консоли проблема та же. По логике метод отработал и должен был GC собрать все данные локальные верно?

должен, но не факт что сразу после окончания метода

А принудительный GC.start не влияет, я даже дамп всего делал, там все данные помечены mark =true , что по логике норм. Не могу понять никак) Я byebug юзал делал там ObjectSpace.each_object и выводил в блоке всех кто больше 10мб вешает, в итоге там был только мой объект yml после дампа и все. Это было в контексте модели

в контроллере уже эти объекты исчезли

Пробовал еще через Thread.new, думал после отработки треда убьются все данные, но опять фиаско

Где то пробел у меня в знаниях)

так может вынести это безобразие в отдельный воркер на отдельную логическую машину?

Тут уже советовали сайдкик например или рейк такс

Еще не пробовал, думал здесь разберусь

вопросы про rails r и иже всё ещё в силе.

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

раннер еще ниразу не юзал

консоль тут вообще лучше не использовать, ибо в ней время жизни объектов будет сильно отличаться от оного в приложении

Ок раннер еще попробую, только данные попадали же через params, тут еще не смотрел, пошел тестить

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

Это локалхост серсис) Точнее он будет у меня на работе, могу хоть 10гб озу дать, но это не дело вообще, а мб даже придется виртуалбокс в филиалы отправлять, т.к. инет не стабильный у них. Соотвественно сервис должен быть простой и без лишних заморочек. Если бы был cvs было бы норм. Кстати это твой любимый socit

С их проги выгрузка в dbf в cp866 еще кодировке

я ваще не могу с них

тогда может предподготовку сделать не рубями?

Думал уже, на крайний случай оставил. Есть вариант в программе dbf commander экспортировать в cvs, но они выпенидриваться будут, т.к. усложняется процесс хотя и не много. Щас они макросами в excel делают, но они с этими макросами уже всех достали, смотреть на них не могу. Есть вариант еще на crystal переписать предподготовку, вот там жумаю будет ап раз в пять)

Сделал GC.start после загрузки файла и нифига... Иногда хочется вручную памятью управлять

а нельзя

вручную управлять памятью

вручную управлять памятью

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

нет

у тебя код хуёвый

1) YAML.dump <-

2) parse_document

1) зачем делать IO#write когда YAML умеет сам работать с IO?

2) зачем делать огромную строку, когда можно сделать enumerable объект

2) зачем делать огромную строку, когда можно сделать enumerable объект

А по подробнее, если можно

1) зачем делать IO#write когда YAML умеет сам работать с IO?

В смысле не делать File.open?

2) ты берёшь и сразу всю таблицу конвертируешь в хеш

зачем?

http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy

Это потому что я не научился еще делать по другому. Я в голове понимаю, надо взять сразу и писать в файл верно?

потом я не понимаю зачем читать файл целиком

и потом сливать его в DBF

тебе надо открыть файл на чтение, но не читать и передать IO объект в конструктор твоего DBF

Я не могу его считать не целиком

почему?

Там в доках ничего нет про стрим, а вручную там же не csv , а хренов дбф, там внутри он unpack делает, потом получается уже наша строка длинная и там уже разбивает по колонкам

Я бы конечно взял бы одну колонку, сразу ее спарсил

потом сохранил

и по кругу

https://github.com/infused/dbf/blob/master/lib/dbf/table.rb#L249

всё оно нормально умеет через seek/rewind читать

Эти понятния для меня новые)

ну вот надо начать с базовых вещей

читать весь файл в память это тупая идея

и это корень твоей проблемы, а не управление памятью

Я согласен, я хочу научится уже стримингу

это не стримниг, господи

короче, я направление тебе указал, разбирайся

Ок, тяжело в учении - легко в бою

чото я сомневаюсь что память тратится именно на этот File.read

чото я сомневаюсь что память тратится именно на этот File.read

ну и плохо

ERROR: S client not available

там 1 огромная строка для DBF, здоровый хеш и здоровый кусок yaml

А стриминг тогда что это?)) В моем понимании всегда было типа того: file.each_line { |line| do_somethind(line); save_to_file(line) }

по размеру скорее всего ~4x от размера dbf файла в итоге

File.read не мого съед, 400-500мб на хэш мой вышло и остатки на yaml

файл дбф 90мб

ну вот не надо делать огромный хеш

надо сделать lazy enumerable и последовательно читать файл

dbf умеет each

там курсороподбная констуркция

Поправь если не так(про ленивый енум пока не прочитал): 1) Делаем each первая строка 2) Парсим to_yaml 3) IO.write yaml_line 4) Начинаем с первого пункта

В конце IO.close, если это было сделано не вблоке

нет

чото я не очень понимаю как предполагается лениво дампить Enumerable в yaml

Если не извращаться с Psych::Emitter

вот его и надо

afaik, YAML класс его и использует

Ок, спс буду курить, с меня пиво или ночлег если будите в моей деревне)

будить в твоей деревне я конечно могу

вот его и надо

сомнительной полезности оптимизация, если единственная проблема — не освобожление памяти после обработки, ибо с Psych::Emitter очень просто сделать невалидный yaml, например.

И мб есть какая-то книга по таким тонкостям, а то стандартные только основную работу с руби описывают. Даже в бест практикс не видел такого кажется

сомнительной полезности оптимизация, если единственная проблема — не освобожление памяти после обработки, ибо с Psych::Emitter очень просто сделать невалидный yaml, например.

500мб хеш

в этом проблема

он решается генерацией нод on demand вместо запихивания целого хеша в память

потому что хеш целиком не нужн

если этот yaml предполагается потом читать — подразумевается что память под целый хеш есть, почему бы не заюзать

если не предполагается — нафиг вообще нужен yaml?

Ну после чистки yml в 3 раза меньше оригинала. Потом считывание много не отнимает

я тут в коде новый смайлик нашел (:[]=)

@TurnaviotovNikolay

пропал парень

вышел из руби чатиков

доебали своими тестами