В API операционной системы должна быть команда fsync которая форсирует сохранение буферизованного
IO в файл. Я-бы почитал есть ли в GoLang вызов этой функции.
Но беря во внимание очень большой размер файла мне кажется что дело не в этом.
Скорее всего у автора баг в оригинальной программе. И надо его искать.
Но автор пишет что всё ненужное выбросил и поэтому сложно делать суждение.
Этож для тебя одноразовая задача? Тебе проще нанять студентов чтоб они тебе сделали скрейпер.
А дальше у тебя будет база и наверное на этом все.
Если ты хочешь изучать скрепинг - то это другое дело но и сроки тогда будут другие и наверное
надо начать с более простого. С библиотеки Мошкова например.
Странный вопрос. Это больше к автору. Сможет ли он сделать break-down этой непростой задачи на части.
Написать правильные промпты. И главное написать правильные тесты чтобы проверить что результат
- такой как ожидалось.
numpy использовал? Я не запрещаю тебе пользоваться AI. Ты можешь спрашивать его сколько угодно.
Только проверяй. И если ты ушел от теоретической математики в область численных методов
то будь готов решать проблемы Python performance.
Нагрузка на CPU, Memory. Ты должен в этом тоже разбираться иначе твоя работа бесполезна.
Забегая вперед я бы ппредложил тебе сразу делать эту задачу на С++.
Тебе не надо вообе писать все позитивные сценарии а БД. В этом нет смысла. Тебе для
опровержения теоремы нужен только один негативный и после этого приложение можно прервать.
И я сам базовик по професии здесь не нахожу применения базе аж вообще. Короче я третий
раз прошу тебя не включать в исходники эти бесполезные процедуры потому что для нас
обсуждающих вопрос математикики надо фокусироваться только на математике. Это вообще
правила хорошего тона. Отвечающие желают видеть суть вопроса а не шумящий код.
Я не отказывал в помощи. Я просто устал ходить по кругу.
Да пожалуйста проверяй. Но тебе сколько тысяч лет надо чтоб проверить Пифагора, Ферма и Эйлера?
Занялся бы лучше практической криптографие. Разложением RSA например.
Это нормально. Это в принципе ничем не отличается от повторного использования библиотек
в своем софте. В данном случае хромиум сыграл роль такой повторяемой библиотеки.
Кто от этого пострадал? В перспективе - только сам разработчик. Он завязался на очень сложный
софт и в случае резкой эволюции железа или технологий такой техно-стек скорее всего будет
выброшен на свалку. Но наверное это будет как в байке про осла и султана.
IO в файл. Я-бы почитал есть ли в GoLang вызов этой функции.
Но беря во внимание очень большой размер файла мне кажется что дело не в этом.
Скорее всего у автора баг в оригинальной программе. И надо его искать.
Но автор пишет что всё ненужное выбросил и поэтому сложно делать суждение.