VoidVolkerЦитата:
Я сделал то же самое - код выше.
Нет, твой код только считает найденные символы перевода строк, к данным между ними он доступа не предоставляет, а о том что он мне нужен - я говорил.
Цитата:
На файле из моего кода (код 2) результат проверки содержимого совпадает в обоих случаях (два разных кода - а результат один). Какой из этого можно сделать вывод? Файл создается невалидным.
Из этого можно сделать два вывода, оба про невалидность файла:
- твой вывод, что мои файлы невалидны
- мой вывод, что твой файл невалиден, потому что мне не нужен
правильный файл что бы на нем
SREAD-LINE работало нормально, мне надо, что бы это слово нормально работало на всех файлах, в том числе и на моих.
Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки.
А уже после этого можно логически искать ошибку дальше: в файлах, в моих кронах, в
SREAD-LINE или еще где...
А сейчас получается ты мне доказываешь что я неправильные файлы делаю, что на мой взгляд выглядит немного странно.
Касательно правильности файлов и проверки содержимого третьими инструментами - у меня таким инструментов выступает известный тебе
SciTE. Открыв в нем оба эти файла, перейдя на последнюю строку слева я вижу его номер 180 000, перевод строки настроен виндовый.
Цитата:
Выдает строку с числами данного диапазона (с бинарной точки зрения на строку).
угу, теперь понял, что имелся ввиду диапазон кодов чисел, спс.
Цитата:
Какого счетчика? Крон - 32 битный. Переполнение 32 битного счетчика происходит на числе 2147483647. Кроме того, крон может использовать числа двойной длины.
Угу, все верно, но другого объяснения появления в логе этого числа я навскидку придумать не смог.
gudleifrЦитата:
Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор.
В данном случае важно, т.к. меняя файлы для запуска я комментировал одну строку и раскомментировал вторую с последующим сохранением кронтаба и, самое главное, перечитыванием кронтабов кроном, при этом обнуляются вообще ВСЕ переменные, не говоря уже об локальных.
Цитата:
Это ваша программа выдала? Или в файле посмотрели?
Нет, открыв в текстовом редакторе эти файлы и перейдя на соответствующие, по номеру, строки я скопировал их содержимое.
Цитата:
Что дает положение этой строки в памяти (относительно других блоков?).
Если я правильно понял суть этого вопроса, то скажу следующее - у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках. То что в этих двух файлах
SREAD-LINE "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше.
Сделаю еще подобные файлы гарантированной длины в 6 байт и проверю на них - на каких по счету строках это слово будет "слепнуть".
Цитата:
Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 80000, а только 40000. Другими числами - убрать по цифре из первого десятка-сотни слов.
Боюсь, тут надо уже посмотреть на определение слова
SEARCH с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле - может там используется область памяти кодофайла (который ограничен в кроне) или еще что-то из области работы с памятью.
Жаль для меня все еще и ассемблер и использование Фортом памяти - слабо освоенные области