LINUX.ORG.RU

На чем лучше делать програмку, которая за файлами следит?

 ,


1

1

Сделал крутой компилятор/сборщик для файлов, то есть файлы coffee транслируются в js в другой папке, styl в css в другой папке, и внутри файлов могут быть комменты //= require_tree ... | require_dir ... | require ... и все это волшебным образом работает. Потому что переписывал раз 5 и кучу времени потратил. Работает благодаря библиотеке chokidar, спасибо ей большое, но! Черт но! Она не годится, иногда вместо кода node.js выдает пустой файл, хотя код есть. Решил обойтись без chokidar и своими силами соорудить горку костылей для fs.watch. Проблему с пустыми файлами обойтись удалось, это прекрасно. Но fs.watch слишком неадекватная, слишком адовая функция, с ней невозможно работать, с трудом верится что нельзя было нормально сделать. Например, слежу за папкой /ko, в обработчик идет событие rename и filename 'ko', и невозможно понять: сама папка удалилась, или она переименовалась, или одноименная подпапка удалилась или переименовалась. gulp-watch использует chokidar, который не подходит так как глючит. Думаю, chokidar самый нормальный враппер и все его используют, но он глючит. Врядли я осилю это все переписывать на что-то другое, скорее от отчаяния и любопытства очередной глупый пост постчю. Скажите: на других языках настолько же проблемно за папками/файлами следить или разработчики node.js правда кретины? Уверен, для многих языков есть вотчеры вроде chokidar. Например, sublime text на питоне вполне нормально заметит, если файл изменится или папка добавится, файлменеджеры тоже вполне нормально на это реагируют.


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

KivApple ★★★★★
()
Ответ на: комментарий от EXL

Ну так это второй! А теперь найди точную информацию по третьему, 3.3114-1 который, и тогда уж пряник с полки.

Romaboy
() автор топика
Ответ на: комментарий от xSudo

Точно уверен: он опирается на fs.watch, который дважды реагирует на события (в моем случае, по крайней мере). На одном из этих событий размер файла нормальный, на другом нулевой, и нужно из двух выбирать ненулевой и тогда все хорошо. А chokidar видимо делает это как-то иначе. Я ни в коем случае не виню chokidar, что они не смогли полностью справится с безумием fs.watch

Romaboy
() автор топика
Ответ на: комментарий от Romaboy

Зачем? Судя по тому, что скорость работы третьей ветки Sublime Text нисколечко не понизилась, он всё так же написан на C++.

EXL ★★★★★
()
Ответ на: комментарий от EXL

А вдруг на си переписали часть для ещё большей скорости и крутости. Кто их знает, проприеритарщиков

Romaboy
() автор топика
Ответ на: комментарий от KivApple

Проблема в том, что fs.stat в один момент времени может выдать размер 0, в другой момент времени нормальный размер, и этому нет никаких оправданий, и подобные жуткие костыли для 16-го года - они даже не помогут при этом.

Romaboy
() автор топика

Вот такой вот костыль для chokidar:

.on 'change', (p, stat) ->
	if stat.size is 0
		tries = 10
		cb = ->
			size = fs.statSync(p).size
			if size and not --tries
				changeHandler p
			else setTimeout cb, 10
		setTimeout cb, 10
	else changeHandler p
Если chokidar говорит, что размер файла 0, то мы 10 раз с промежутком в 10мс это проверяем, в сумме 100мс, этого вполне достаточно чтобы нода дала правдивый ответ. В итоге все не так страшно.

Romaboy
() автор топика
Ответ на: комментарий от Romaboy

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

Romaboy
() автор топика

Простите за нескромный вопрос, а вас не смущает что последний релиз кофе был 11 месяцев назад?

makoven ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.