Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
[b]makrus[/b] http://www.nncron.ru/forums/viewtopic.php?f=5&t=13237
|
|
|
|
Добавлено: Пт авг 07, 2015 13:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
VoidVolker писал(а): Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся ) Большущее спасибо за проделанную работу. Я, к сожалению, понял еще меньше, но главное работает! gudleifr, тоже спасибо за активное участие!
[quote="[color=#FF0000]VoidVolker[/color]"]Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся )[/quote]Большущее спасибо :poklon; за проделанную работу. Я, к сожалению, понял еще меньше, но главное работает! :D
[b][color=#FF0000]gudleifr[/color][/b], тоже спасибо за активное участие!
|
|
|
|
Добавлено: Чт авг 06, 2015 14:27 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
VoidVolker писал(а): Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся ) Все правильно. Я тупо искал, где в асм-е пропущено "E", но JCXZ просмотрел.
[quote="VoidVolker"]Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся )[/quote] Все правильно. Я тупо искал, где в асм-е пропущено "E", но JCXZ просмотрел.
|
|
|
|
Добавлено: Ср авг 05, 2015 14:30 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
Проверка файлов в текстовых и HEX редакторах потдверждает корректность файлов и всех переводов строк. Итак, тестовый код (добавлены стековые комментарии для SREAD-LINE): Код: : CRLF-Count \ ( a u -- ) 0 >R BEGIN \ a u DUP \ a u u IF 2DUP \ a u a u CRLF \ a u a u a1 u1 SEARCH \ a u a u a2 u2 ? 0= \ a u a u a2 u2 -? IF \ a u a u a2 u2 2DROP \ a u a u 2DUP \ a u a u a u + \ a u a u a+u 0 \ a u a u a+u 0 2SWAP \ a u a+u 0 a u ELSE \ a u a u a2 u2 2DUP \ a u a u a2 u2 a2 u2 2>R \ a u a u a2 u2 R: a2 u2 NIP \ a u a u u2 R: a2 u2 - \ a u a u-u2 R: a2 u2 2R> \ a u a u-u2 a2 u2 2 \ a u a u-u2 a2 u2 2 /STRING \ a u a u-u2 a2+2 u2-2 2SWAP \ a u a2+2 u2-2 a u-u2 THEN TRUE ELSE 2DUP FALSE \ a u a u ? THEN OK WHILE 2DROP \ R@ . . . CR R> 1+ >R REPEAT 2DROP 2DROP R> . CR ;
: crlfCounterTest 0 -ROT OVER + SWAP DO I C@ 0x0D = I 1+ C@ 0x0A = AND IF 1+ THEN LOOP . CR ;
И результат у меня такой получается: Код: S" TestFile.txt" FILE crlfCounterTest 180000
И вот такой: Код: S" TestFile.txt" FILE CRLF-Count ... Ok ( 83732948 1310720 83732940 6 4294967295(-1) ) Ok ( 85043668 0 83732948 1310720 4294967295(-1) ) Ok ( 85043668 0 85043668 0 0 ) 13817 SREAD-LINE Возвращает флаг, найденную строку и следующую строку. 83732948 1310720 - следующая строка 83732940 6 - найденная строка Очевидно, что именно на этой найденной строке и происходит остановка поиска. Посмотрим что там внутри: Код: 99789268 32 DUMP 5F2A9D4 32 34 33 31 35 34 0D 0A 34 34 35 36 37 35 0D 0A 243154..445675.. 5F2A9E4 35 35 30 39 30 39 0D 0A 33 33 38 34 34 31 0D 0A 550909..338441.. Ok Как видно - в строке все хорошо. Проверим результат поиска: Код: 99789268 1310720 CRLF SEARCH . . . 0 1310720 99789268 Ok
Опаньки! Как это так? Попробуем еще раз: Код: 99789268 1310720 S" 445675" SEARCH . . . 0 1310720 99789268 Ok 99789268 1310720 S" 243154" SEARCH . . . 0 1310720 99789268 Ok Хмм... Все становистя еще интереснее. А если вот так: Код: 99789268 1310719 CRLF SEARCH . . . -1 1310713 99789274 Ok 99789268 1310721 CRLF SEARCH . . . -1 1310715 99789274 Ok
99789267 1310720 CRLF SEARCH . . . 0 1310720 99789267 Ok 99789269 1310720 CRLF SEARCH . . . 0 1310720 99789269 Ok Очевидно, проблема в длине строки - именно эту длину строки поиск не принимает. Интересно, почему же? Посмотрим-ка что это за число более внимательно: Код: 1310720 .H 00140000 Ok 1310720 .B 0000 0000 0001 0100 0000 0000 0000 0000 Ok Интересное число, не правда ли? Проверим-ка одну теорию: Код: 99789267 65535 CRLF SEARCH . . . -1 65528 99789274 Ok Работает. И еще разок: Код: 99789267 65536 CRLF SEARCH . . . 0 65536 99789267 Ok Не работает. Теперь причина такого поведения поиска вполне очевидна: Код: 65535 = 0xFFFF = 0b 0000 0000 0000 0001 0000 0000 0000 0000 65536 = 0x10000 = 0b 0000 0000 0000 0001 0000 0000 0000 0000 Поиск шестандцатибитный. Т.е., максимальная длина строки, в которой производится поиск составляет 65535. Тот же самый код в SPF4 ведет себя как ожидается - поиск там 32-х битный: Код: S" E:\TEMP\Count\TestFile.txt" FILE CRLF-Count 180000 Ok Проблема в команде JCXZ @@1 - её надо заменить на JECXZ @@1 и поиск будет работать на 32 битных строках. Исправленный поиск: Код: CODE SEARCH ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 flag ) \ 94 STRING Произвести поиск в строке, заданной c-addr1 u1, строки, заданной c-addr2 u2. Если флаг "истина", совпадение найдено по адресу c-addr3 с оставшимися u3 символами. Если флаг "ложь", совпадения не найдено, и c-addr3 есть c-addr1, и u3 есть u1. PUSH EDI CLD MOV EBX, [EBP] OR EBX, EBX JZ @@5 MOV EDX, 8 [EBP] MOV EDI, 0x0C [EBP] ADD EDX, EDI @@4: MOV ESI, 4 [EBP] LODS BYTE MOV ECX, EDX SUB ECX, EDI JECXZ @@1 REPNZ SCAS BYTE JNZ @@1 \ во всей строке нет первого символа искомой строки CMP EBX, # 1 JZ @@2 \ искомая строка имела длину 1 и найдена MOV ECX, EBX DEC ECX MOV EAX, EDX SUB EAX, EDI CMP EAX, ECX JC @@1 \ остаток строки короче искомой строки PUSH EDI REPZ CMPS BYTE POP EDI JNZ @@4 @@2: DEC EDI \ нашли полное совпадение SUB EDX, EDI MOV 0x0C [EBP], EDI MOV 8 [EBP], EDX @@5: MOV EAX, # -1 JMP @@3 @@1: XOR EAX, EAX @@3: ADD EBP, # 4 MOV [EBP], EAX POP EDI RET END-CODE Для применения исправления необходимо подключить ассемблер из дистрибутива SPF4. Либо воспользоваться простым хаком (достаточно один раз вызвать в nncron.ini или в подключенном плагине): Код: 0x90 ' SEARCH 29 + C! Если я правильно понял ман по асму, то по этому адресу находится префикс для команды (0x66/0x67) JECXZ, который переключает разрядность данных, с которыми работает данная команда. Данный хак просто заменяет префикс на команду NOP. Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся ) (Не совсем понятна логика ассемблера СПФ для команд JECXZ и JCXZ и добавление префикса).
Проверка файлов в текстовых и HEX редакторах потдверждает корректность файлов и всех переводов строк.
Итак, тестовый код (добавлены стековые комментарии для SREAD-LINE): [code]: CRLF-Count \ ( a u -- ) 0 >R BEGIN \ a u DUP \ a u u IF 2DUP \ a u a u CRLF \ a u a u a1 u1 SEARCH \ a u a u a2 u2 ? 0= \ a u a u a2 u2 -? IF \ a u a u a2 u2 2DROP \ a u a u 2DUP \ a u a u a u + \ a u a u a+u 0 \ a u a u a+u 0 2SWAP \ a u a+u 0 a u ELSE \ a u a u a2 u2 2DUP \ a u a u a2 u2 a2 u2 2>R \ a u a u a2 u2 R: a2 u2 NIP \ a u a u u2 R: a2 u2 - \ a u a u-u2 R: a2 u2 2R> \ a u a u-u2 a2 u2 2 \ a u a u-u2 a2 u2 2 /STRING \ a u a u-u2 a2+2 u2-2 2SWAP \ a u a2+2 u2-2 a u-u2 THEN TRUE ELSE 2DUP FALSE \ a u a u ? THEN OK WHILE 2DROP \ R@ . . . CR R> 1+ >R REPEAT 2DROP 2DROP R> . CR ;
: crlfCounterTest 0 -ROT OVER + SWAP DO I C@ 0x0D = I 1+ C@ 0x0A = AND IF 1+ THEN LOOP . CR ;
[/code] И результат у меня такой получается:
[code]S" TestFile.txt" FILE crlfCounterTest 180000 [/code] И вот такой: [code]S" TestFile.txt" FILE CRLF-Count ... Ok ( 83732948 1310720 83732940 6 4294967295(-1) ) Ok ( 85043668 0 83732948 1310720 4294967295(-1) ) Ok ( 85043668 0 85043668 0 0 ) 13817[/code] [b]SREAD-LINE[/b] Возвращает флаг, найденную строку и следующую строку. 83732948 1310720 - следующая строка 83732940 6 - найденная строка Очевидно, что именно на этой найденной строке и происходит остановка поиска. Посмотрим что там внутри: [code]99789268 32 DUMP 5F2A9D4 32 34 33 31 35 34 0D 0A 34 34 35 36 37 35 0D 0A 243154..445675.. 5F2A9E4 35 35 30 39 30 39 0D 0A 33 33 38 34 34 31 0D 0A 550909..338441.. Ok[/code] Как видно - в строке все хорошо. Проверим результат поиска: [code]99789268 1310720 CRLF SEARCH . . . 0 1310720 99789268 Ok [/code] Опаньки! Как это так? Попробуем еще раз: [code]99789268 1310720 S" 445675" SEARCH . . . 0 1310720 99789268 Ok 99789268 1310720 S" 243154" SEARCH . . . 0 1310720 99789268 Ok[/code] Хмм... Все становистя еще интереснее. А если вот так: [code]99789268 1310719 CRLF SEARCH . . . -1 1310713 99789274 Ok 99789268 1310721 CRLF SEARCH . . . -1 1310715 99789274 Ok
99789267 1310720 CRLF SEARCH . . . 0 1310720 99789267 Ok 99789269 1310720 CRLF SEARCH . . . 0 1310720 99789269 Ok[/code]
Очевидно, проблема в длине строки - именно эту длину строки поиск не принимает. Интересно, почему же? Посмотрим-ка что это за число более внимательно: [code]1310720 .H 00140000 Ok 1310720 .B 0000 0000 0001 0100 0000 0000 0000 0000 Ok[/code] Интересное число, не правда ли? Проверим-ка одну теорию: [code]99789267 65535 CRLF SEARCH . . . -1 65528 99789274 Ok[/code] Работает. И еще разок: [code]99789267 65536 CRLF SEARCH . . . 0 65536 99789267 Ok[/code] Не работает. Теперь причина такого поведения поиска вполне очевидна: [code]65535 = 0xFFFF = 0b 0000 0000 0000 0001 0000 0000 0000 0000 65536 = 0x10000 = 0b 0000 0000 0000 0001 0000 0000 0000 0000[/code] [i]Поиск шестандцатибитный.[/i] Т.е., максимальная длина строки, в которой производится поиск составляет 65535. Тот же самый код в SPF4 ведет себя как ожидается - поиск там 32-х битный: [code]S" E:\TEMP\Count\TestFile.txt" FILE CRLF-Count 180000 Ok[/code]
Проблема в команде [i]JCXZ @@1[/i] - её надо заменить на [i]JECXZ @@1[/i] и поиск будет работать на 32 битных строках. Исправленный поиск: [code]CODE SEARCH ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 flag ) \ 94 STRING Произвести поиск в строке, заданной c-addr1 u1, строки, заданной c-addr2 u2. Если флаг "истина", совпадение найдено по адресу c-addr3 с оставшимися u3 символами. Если флаг "ложь", совпадения не найдено, и c-addr3 есть c-addr1, и u3 есть u1. PUSH EDI CLD MOV EBX, [EBP] OR EBX, EBX JZ @@5 MOV EDX, 8 [EBP] MOV EDI, 0x0C [EBP] ADD EDX, EDI @@4: MOV ESI, 4 [EBP] LODS BYTE MOV ECX, EDX SUB ECX, EDI JECXZ @@1 REPNZ SCAS BYTE JNZ @@1 \ во всей строке нет первого символа искомой строки CMP EBX, # 1 JZ @@2 \ искомая строка имела длину 1 и найдена MOV ECX, EBX DEC ECX MOV EAX, EDX SUB EAX, EDI CMP EAX, ECX JC @@1 \ остаток строки короче искомой строки PUSH EDI REPZ CMPS BYTE POP EDI JNZ @@4 @@2: DEC EDI \ нашли полное совпадение SUB EDX, EDI MOV 0x0C [EBP], EDI MOV 8 [EBP], EDX @@5: MOV EAX, # -1 JMP @@3 @@1: XOR EAX, EAX @@3: ADD EBP, # 4 MOV [EBP], EAX POP EDI RET END-CODE[/code] Для применения исправления необходимо подключить ассемблер из дистрибутива SPF4. Либо воспользоваться простым хаком (достаточно один раз вызвать в nncron.ini или в подключенном плагине): [code]0x90 ' SEARCH 29 + C![/code] Если я правильно понял ман по асму, то по этому адресу находится префикс для команды (0x66/0x67) JECXZ, который переключает разрядность данных, с которыми работает данная команда. Данный хак просто заменяет префикс на команду [b]NOP[/b]. Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся ) (Не совсем понятна логика ассемблера СПФ для команд JECXZ и JCXZ и добавление префикса).
|
|
|
|
Добавлено: Ср авг 05, 2015 13:49 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
Ааа, так вот они где. Подчеркивания у ссылки нет - вот и не заметил.
Ааа, так вот они где. Подчеркивания у ссылки нет - вот и не заметил.
|
|
|
|
Добавлено: Ср авг 05, 2015 12:02 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
VoidVolker писал(а): makrus писал(а): Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки. Дык а ссылка-то где на файлы? Давно бы уже скачал их. Да в первом же сообщении... Цитата: ... Файлы TestFile.txt и TestFile2.txt можно взять тут, либо сделать самим по аналогии. Воспроизведение 100% на 2х машинах с XP и Win7. ... "тут" ссылка на http://rghost.net/69hZMtdnc
[quote="VoidVolker"][quote="makrus"]Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки.[/quote] Дык а ссылка-то где на файлы? Давно бы уже скачал их.[/quote] Да в первом же сообщении... [quote]... Файлы TestFile.txt и TestFile2.txt можно взять тут, либо сделать самим по аналогии. Воспроизведение 100% на 2х машинах с XP и Win7. ...[/quote] "тут" ссылка на http://rghost.net/69hZMtdnc
|
|
|
|
Добавлено: Вт авг 04, 2015 21:26 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки. Дык а ссылка-то где на файлы? Давно бы уже скачал их.
[quote="makrus"]Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки.[/quote] Дык а ссылка-то где на файлы? Давно бы уже скачал их.
|
|
|
|
Добавлено: Вт авг 04, 2015 20:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): Нет, открыв в текстовом редакторе Значит, никакой гарантии, что программа остановилась именно на этой строке, у нас нет. Нужно проверять. И, в случае неудачи - "каждый десятый". makrus писал(а): у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках. Логично. Первая версия - что-то где-то переполняется. makrus писал(а): То что в этих двух файлах SREAD-LINE "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше. Тоже логично. makrus писал(а): Боюсь, тут надо уже посмотреть на определение слова SEARCH с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле Пока рано.
[quote="makrus"]Нет, открыв в текстовом редакторе[/quote]Значит, никакой гарантии, что программа остановилась именно на этой строке, у нас нет. Нужно проверять. И, в случае неудачи - "каждый десятый". [quote="makrus"]у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках.[/quote]Логично. Первая версия - что-то где-то переполняется. [quote="makrus"]То что в этих двух файлах [b]SREAD-LINE[/b] "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше.[/quote]Тоже логично. [quote="makrus"]Боюсь, тут надо уже посмотреть на определение слова [b]SEARCH[/b] с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле[/quote]Пока рано.
|
|
|
|
Добавлено: Вт авг 04, 2015 17:31 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
VoidVolkerЦитата: Я сделал то же самое - код выше. Нет, твой код только считает найденные символы перевода строк, к данным между ними он доступа не предоставляет, а о том что он мне нужен - я говорил. Цитата: На файле из моего кода (код 2) результат проверки содержимого совпадает в обоих случаях (два разных кода - а результат один). Какой из этого можно сделать вывод? Файл создается невалидным. Из этого можно сделать два вывода, оба про невалидность файла: - твой вывод, что мои файлы невалидны - мой вывод, что твой файл невалиден, потому что мне не нужен правильный файл что бы на нем SREAD-LINE работало нормально, мне надо, что бы это слово нормально работало на всех файлах, в том числе и на моих. Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки. А уже после этого можно логически искать ошибку дальше: в файлах, в моих кронах, в SREAD-LINE или еще где... А сейчас получается ты мне доказываешь что я неправильные файлы делаю, что на мой взгляд выглядит немного странно. Касательно правильности файлов и проверки содержимого третьими инструментами - у меня таким инструментов выступает известный тебе SciTE. Открыв в нем оба эти файла, перейдя на последнюю строку слева я вижу его номер 180 000, перевод строки настроен виндовый. Цитата: Выдает строку с числами данного диапазона (с бинарной точки зрения на строку). угу, теперь понял, что имелся ввиду диапазон кодов чисел, спс. Цитата: Какого счетчика? Крон - 32 битный. Переполнение 32 битного счетчика происходит на числе 2147483647. Кроме того, крон может использовать числа двойной длины. Угу, все верно, но другого объяснения появления в логе этого числа я навскидку придумать не смог. gudleifrЦитата: Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор. В данном случае важно, т.к. меняя файлы для запуска я комментировал одну строку и раскомментировал вторую с последующим сохранением кронтаба и, самое главное, перечитыванием кронтабов кроном, при этом обнуляются вообще ВСЕ переменные, не говоря уже об локальных. Цитата: Это ваша программа выдала? Или в файле посмотрели? Нет, открыв в текстовом редакторе эти файлы и перейдя на соответствующие, по номеру, строки я скопировал их содержимое. Цитата: Что дает положение этой строки в памяти (относительно других блоков?). Если я правильно понял суть этого вопроса, то скажу следующее - у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках. То что в этих двух файлах SREAD-LINE "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше. Сделаю еще подобные файлы гарантированной длины в 6 байт и проверю на них - на каких по счету строках это слово будет "слепнуть". Цитата: Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 80000, а только 40000. Другими числами - убрать по цифре из первого десятка-сотни слов. Боюсь, тут надо уже посмотреть на определение слова SEARCH с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле - может там используется область памяти кодофайла (который ограничен в кроне) или еще что-то из области работы с памятью. Жаль для меня все еще и ассемблер и использование Фортом памяти - слабо освоенные области
[b][color=#FF0000]VoidVolker[/color][/b] [quote] Я сделал то же самое - код выше.[/quote]Нет, твой код только считает найденные символы перевода строк, к данным между ними он доступа не предоставляет, а о том что он мне нужен - я говорил. [quote]На файле из моего кода (код 2) результат проверки содержимого совпадает в обоих случаях (два разных кода - а результат один). Какой из этого можно сделать вывод? Файл создается невалидным.[/quote]Из этого можно сделать два вывода, оба про невалидность файла: - твой вывод, что мои файлы невалидны - мой вывод, что твой файл невалиден, потому что мне не нужен [i]правильный[/i] файл что бы на нем [b]SREAD-LINE[/b] работало нормально, мне надо, что бы это слово нормально работало на всех файлах, в том числе и на моих.
Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки. А уже после этого можно логически искать ошибку дальше: в файлах, в моих кронах, в [b]SREAD-LINE[/b] или еще где...
А сейчас получается ты мне доказываешь что я неправильные файлы делаю, что на мой взгляд выглядит немного странно. Касательно правильности файлов и проверки содержимого третьими инструментами - у меня таким инструментов выступает известный тебе [color=#008000]SciTE[/color]. Открыв в нем оба эти файла, перейдя на последнюю строку слева я вижу его номер 180 000, перевод строки настроен виндовый.
[quote]Выдает строку с числами данного диапазона (с бинарной точки зрения на строку).[/quote] угу, теперь понял, что имелся ввиду диапазон кодов чисел, спс.
[quote] Какого счетчика? Крон - 32 битный. Переполнение 32 битного счетчика происходит на числе 2147483647. Кроме того, крон может использовать числа двойной длины.[/quote]Угу, все верно, но другого объяснения появления в логе этого числа я навскидку придумать не смог.
[b][color=#FF0000]gudleifr[/color][/b][quote]Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор.[/quote]В данном случае важно, т.к. меняя файлы для запуска я комментировал одну строку и раскомментировал вторую с последующим сохранением кронтаба и, самое главное, перечитыванием кронтабов кроном, при этом обнуляются вообще ВСЕ переменные, не говоря уже об локальных.
[quote]Это ваша программа выдала? Или в файле посмотрели?[/quote]Нет, открыв в текстовом редакторе эти файлы и перейдя на соответствующие, по номеру, строки я скопировал их содержимое. [quote]Что дает положение этой строки в памяти (относительно других блоков?).[/quote]Если я правильно понял суть этого вопроса, то скажу следующее - у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках. То что в этих двух файлах [b]SREAD-LINE[/b] "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше. Сделаю еще подобные файлы гарантированной длины в 6 байт и проверю на них - на каких по счету строках это слово будет "слепнуть".
[quote]Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 80000, а только 40000. Другими числами - убрать по цифре из первого десятка-сотни слов.[/quote] Боюсь, тут надо уже посмотреть на определение слова [b]SEARCH[/b] с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле - может там используется область памяти кодофайла (который ограничен в кроне) или еще что-то из области работы с памятью. Жаль для меня все еще и ассемблер и использование Фортом памяти - слабо освоенные области :(
|
|
|
|
Добавлено: Вт авг 04, 2015 16:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же. Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор. makrus писал(а): Строка №13817 в файле "TestFile.txt" содержит строку "243154" Строка №13839 в файле "TestFile2.txt" содержит строку "693725" Это ваша программа выдала? Или в файле посмотрели? Размер "считанной части" примерно 100kb. Вроде, "ни о чем", тем более, Вы говорите, файл нормально влезает целиком. Что дает положение этой строки в памяти (относительно других блоков?). makrus писал(а): доработаю задачку, проверю. Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 80000, а только 40000. Другими числами - убрать по цифре из первого десятка-сотни слов. P.S. Дело не в том, что мои "рецепты" к чему-то ведут, а к тому, что я пытаюсь Вас заставить посмотреть на код "с другой стороны". Проверяйте все, что придет в голову.
[quote="makrus"]т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же.[/quote] Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор. [quote="makrus"]Строка №13817 в файле "TestFile.txt" содержит строку "243154" Строка №13839 в файле "TestFile2.txt" содержит строку "693725"[/quote]Это ваша программа выдала? Или в файле посмотрели? Размер "считанной части" примерно 100kb. Вроде, "ни о чем", тем более, Вы говорите, файл нормально влезает целиком. Что дает положение этой строки в памяти (относительно других блоков?). [quote="makrus"]доработаю задачку, проверю.[/quote]Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 80000, а только 40000. Другими числами - убрать по цифре из первого десятка-сотни слов. P.S. Дело не в том, что мои "рецепты" к чему-то ведут, а к тому, что я пытаюсь Вас заставить посмотреть на код "с другой стороны". Проверяйте все, что придет в голову.
|
|
|
|
Добавлено: Вт авг 04, 2015 09:59 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): По-моему ты торопишься!!! Давай начнем с самого начала - откуда вообще берется файл, да еще с 180 тыс. строк, если показана одна строка без какого-либо сохранения в файл?! Ну, а если серьезно, то я же говорил, что эти файлы созданы специально, специально добавлены в конце каждой строки виндовые переводы строк, после этого строка сохранялась в файл и таким образом в этих файлах содержится по 180 тыс. строк. Предлагаю немножко распутать узелок логики. 1. Создается некий файл, при этом утверждается, что его содержимое известно со 100% точностью. 2. Файл считывается и проверяется его содержимое (код 2). 3. Результат не соответствует ожиданиям. Так? Так. Так вот. Я сделал то же самое - код выше. И проверил каждый этап. На файле из моего кода (код 2) результат проверки содержимого совпадает в обоих случаях (два разных кода - а результат один). Какой из этого можно сделать вывод? Файл создается невалидным. Следовательно, надо проверять код создания файла, а так же проверять содержимое файла третьим инструментом. makrus писал(а): что это значит - не понял Код: CHAR 0 . 48 CHAR 9 . 57 Т.е., код, вида Код: 1000000 RANDOM N>S Выдает строку с числами данного диапазона (с бинарной точки зрения на строку). makrus писал(а): Попробуй увеличить их количество в 6 раз (объем прочитанных строк, как мне кажется, каким-то образом влияет на их максимальное количество). Я сделал это, в твоем слове, вот так: Код: 2015 04 Aug 00:41:00 15624- Количество найденных строк: 9697 А где второй результат? И где сам файл? Код: 1800000 2* VALUE /buf ... crlfCounterTest 0x0D0A counted: 1800000 makrus писал(а): Переполнение счетчика? Какого счетчика? Крон - 32 битный. Переполнение 32 битного счетчика происходит на числе 2147483647. Кроме того, крон может использовать числа двойной длины. makrus писал(а): Про какие локальные переменные идет речь, кроме как в слове CRLF-Count они вроде нигде не используются, а в этом слове она одна и нужна для подсчета. Если намек на повторное использование этого слова в пределах одной задачи, то насколько я знаю, при повторном вызове одного слова они "обнуляются" (а фактически каждый вызов слова работает со своими локальными переменными), но в конкретно данном случае - это не важно, т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же. В СПФ (а значит в кроне) для локальных перменых используется стек возвратов и они всегда инициализируются нулем.
[quote="makrus"]По-моему ты торопишься!!! Давай начнем с самого начала - откуда вообще берется файл, да еще с 180 тыс. строк, если показана одна строка без какого-либо сохранения в файл?! Ну, а если серьезно, то я же говорил, что эти файлы созданы специально, специально добавлены в конце каждой строки виндовые переводы строк, после этого строка сохранялась в файл и таким образом в этих файлах содержится по 180 тыс. строк.[/quote] Предлагаю немножко распутать узелок логики. 1. Создается некий файл, при этом утверждается, что его содержимое известно со 100% точностью. 2. Файл считывается и проверяется его содержимое (код 2). 3. Результат не соответствует ожиданиям. Так? Так. Так вот. Я сделал то же самое - код выше. И проверил каждый этап. На файле из моего кода (код 2) результат проверки содержимого совпадает в обоих случаях (два разных кода - а результат один). Какой из этого можно сделать вывод? Файл создается невалидным. Следовательно, надо проверять код создания файла, а так же проверять содержимое файла третьим инструментом. [quote="makrus"]что это значит - не понял[/quote] [code]CHAR 0 . 48 CHAR 9 . 57[/code] Т.е., код, вида [code]1000000 RANDOM N>S[/code] Выдает строку с числами данного диапазона (с бинарной точки зрения на строку).
[quote="makrus"]Попробуй увеличить их количество в 6 раз (объем прочитанных строк, как мне кажется, каким-то образом влияет на их максимальное количество). Я сделал это, в твоем слове, вот так: [code]2015 04 Aug 00:41:00 15624- Количество найденных строк: 9697[/code] [/quote] А где второй результат? И где сам файл? [code] 1800000 2* VALUE /buf ... crlfCounterTest 0x0D0A counted: 1800000[/code]
[quote="makrus"]Переполнение счетчика?[/quote] Какого счетчика? Крон - 32 битный. Переполнение 32 битного счетчика происходит на числе 2147483647. Кроме того, крон может использовать числа двойной длины.
[quote="makrus"]Про какие локальные переменные идет речь, кроме как в слове CRLF-Count они вроде нигде не используются, а в этом слове она одна и нужна для подсчета. Если намек на повторное использование этого слова в пределах одной задачи, то насколько я знаю, при повторном вызове одного слова они "обнуляются" (а фактически каждый вызов слова работает со своими локальными переменными), но в конкретно данном случае - это не важно, т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же.[/quote] В СПФ (а значит в кроне) для локальных перменых используется стек возвратов и они всегда инициализируются нулем.
|
|
|
|
Добавлено: Вт авг 04, 2015 08:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
Мне уже становится интересно, кто же будет ТОТ, кто первым ответит на мой первый вопрос - воспроизводится или нет? gudleifr0. Про какие локальные переменные идет речь, кроме как в слове CRLF-Count они вроде нигде не используются, а в этом слове она одна и нужна для подсчета. Если намек на повторное использование этого слова в пределах одной задачи, то насколько я знаю, при повторном вызове одного слова они "обнуляются" (а фактически каждый вызов слова работает со своими локальными переменными), но в конкретно данном случае - это не важно, т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же. 1. Что подразумевается под "моей процедурой вывода"? Что выведет строка S" Количество найденных строк: " 80000 N>S S+ CRON-LOG ? Проверил, вывела 2015 04 Aug 00:11:03 14292- Количество найденных строк: 80000Все в порядке? 2. Открывается, после прочтения файла в память его последующее сохранение в другой файл дает полную копию прочитанного 3. Строка №13817 в файле "TestFile.txt" содержит строку "243154" Строка №13839 в файле "TestFile2.txt" содержит строку "693725" 4. Завтра, ну т.е. сегодня , но по-позже доработаю задачку, проверю. Просьба сразу сообщить кратность каким числам еще надо будет проверять? VoidVolkerЦитата: А откуда тогда уверенность в том, что в этом файле с рандомным набором чисел именно 18000 строк и именно с 0x0D0A? И откуда там вообще возмутся переводы строк, если содержимое одни только числа диапазона 48-57? По-моему ты торопишься!!! Давай начнем с самого начала - откуда вообще берется файл, да еще с 180 тыс. строк, если показана одна строка без какого-либо сохранения в файл?! Ну, а если серьезно, то я же говорил, что эти файлы созданы специально, специально добавлены в конце каждой строки виндовые переводы строк, после этого строка сохранялась в файл и таким образом в этих файлах содержится по 180 тыс. строк. Цитата: ...только числа диапазона 48-57 что это значит - не понял О, код! Проверил у себя, результат тот же - 18 тыс. строк. Попробуй увеличить их количество в 6 раз (объем прочитанных строк, как мне кажется, каким-то образом влияет на их максимальное количество). Я сделал это, в твоем слове, вот так: Код: 18000 6 * 2* VALUE /buf и получил следующий результат Код: 2015 04 Aug 00:41:00 15624- Количество найденных строк: 9697 Переполнение счетчика?
Мне уже становится интересно, кто же будет ТОТ, кто первым ответит на мой первый вопрос - воспроизводится или нет? :D
[b][color=#FF0000]gudleifr[/color][/b] [b]0.[/b] Про какие локальные переменные идет речь, кроме как в слове [b]CRLF-Count[/b] они вроде нигде не используются, а в этом слове она одна и нужна для подсчета. Если намек на повторное использование этого слова в пределах одной задачи, то насколько я знаю, при повторном вызове одного слова они "обнуляются" (а фактически каждый вызов слова работает со своими локальными переменными), но в [u]конкретно данном случае[/u] - это не важно, т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же.
[b]1.[/b] Что подразумевается под "моей процедурой вывода"? Что выведет строка [i]S" Количество найденных строк: " 80000 N>S S+ CRON-LOG[/i] ? Проверил, вывела [i]2015 04 Aug 00:11:03 14292- Количество найденных строк: 80000[/i] Все в порядке?
[b]2.[/b] Открывается, после прочтения файла в память его последующее сохранение в другой файл дает полную копию прочитанного
[b]3.[/b] Строка №13817 в файле "TestFile.txt" содержит строку "243154" Строка №13839 в файле "TestFile2.txt" содержит строку "693725"
[b]4.[/b] Завтра, ну т.е. сегодня ;) , но по-позже доработаю задачку, проверю. Просьба сразу сообщить кратность каким числам еще надо будет проверять?
[b][color=#FF0000]VoidVolker[/color][/b] [quote]А откуда тогда уверенность в том, что в этом файле с рандомным набором чисел именно 18000 строк и именно с 0x0D0A? И откуда там вообще возмутся переводы строк, если содержимое одни только числа диапазона 48-57?[/quote]По-моему ты торопишься!!! Давай начнем с самого начала - откуда вообще берется файл, да еще с [u]180 тыс.[/u] строк, если показана одна строка без какого-либо сохранения в файл?! ;) Ну, а если серьезно, то я же говорил, что эти файлы созданы специально, специально добавлены в конце каждой строки виндовые переводы строк, после этого строка сохранялась в файл и таким образом в этих файлах содержится по [u]180 тыс.[/u] строк.
[quote]...только числа диапазона 48-57[/quote] что это значит - не понял :shuffle;
О, код! :) Проверил у себя, результат тот же - 18 тыс. строк. Попробуй увеличить их количество в 6 раз (объем прочитанных строк, как мне кажется, каким-то образом влияет на их максимальное количество). Я сделал это, в твоем слове, вот так:[code]18000 6 * 2* VALUE /buf[/code] и получил следующий результат[code]2015 04 Aug 00:41:00 15624- Количество найденных строк: 9697[/code] Переполнение счетчика?
|
|
|
|
Добавлено: Вт авг 04, 2015 02:11 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): Все переводы строки в обоих тестовых файлах - виндовые. Оба файла сгенерированы специально для локализации данной ошибки - каждая строка представляет собой результат от Код: 1000000 RANDOM N>S А откуда тогда уверенность в том, что в этом файле с рандомным набором чисел именно 18000 строк и именно с 0x0D0A? И откуда там вообще возмутся переводы строк, если содержимое одни только числа диапазона 48-57? Код: 0 VALUE buf 18000 2* VALUE /buf : crlfCounterTest /buf CELL+ ALLOCATE THROW TO buf buf /buf + buf DO 0x0D I C! 0x0A I 1+ C! 2 +LOOP buf /buf S" C:\crlf.txt" FWRITE 0 S" C:\crlf.txt" FILE OVER + SWAP DO I C@ 0x0D = I 1+ C@ 0x0A = AND IF 1+ THEN LOOP ." 0x0D0A counted: " . CR ; Код: crlfCounterTest 0x0D0A counted: 18000 Код: S" C:\crlf.txt" FILE CRLF-Count 16:10:37 1932 Количество найденных строк: 18000
[quote="makrus"]Все переводы строки в обоих тестовых файлах - виндовые. Оба файла сгенерированы специально для локализации данной ошибки - каждая строка представляет собой результат от [code]1000000 RANDOM N>S[/code] [/quote] А откуда тогда уверенность в том, что в этом файле с рандомным набором чисел именно 18000 строк и именно с 0x0D0A? И откуда там вообще возмутся переводы строк, если содержимое одни только числа диапазона 48-57? [code]0 VALUE buf 18000 2* VALUE /buf : crlfCounterTest /buf CELL+ ALLOCATE THROW TO buf buf /buf + buf DO 0x0D I C! 0x0A I 1+ C! 2 +LOOP buf /buf S" C:\crlf.txt" FWRITE 0 S" C:\crlf.txt" FILE OVER + SWAP DO I C@ 0x0D = I 1+ C@ 0x0A = AND IF 1+ THEN LOOP ." 0x0D0A counted: " . CR ;[/code] [code] crlfCounterTest 0x0D0A counted: 18000[/code] [code]S" C:\crlf.txt" FILE CRLF-Count 16:10:37 1932 Количество найденных строк: 18000[/code]
|
|
|
|
Добавлено: Пн авг 03, 2015 17:08 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
makrus писал(а): Все источники возникновения данной проблемы я, насколько мне позволяют мои знания, уже отсеял Значит, начинаем с нуля: 0. Обнуляются ли локальные переменные? 1. Выводит ли в принципе Ваша процедура вывода число 80000? 2. Открывается ли вообще файл для чтения? 3. Какая строка считывается из файла последней? 4. Что будет, если считать каждую десятую строку? Не потому "это все раньше нормально работало", а тупо вбить контрольные выводы!
[quote="makrus"]Все источники возникновения данной проблемы я, насколько мне позволяют мои знания, уже отсеял[/quote]Значит, начинаем с нуля: 0. Обнуляются ли локальные переменные? 1. Выводит ли в принципе Ваша процедура вывода число 80000? 2. Открывается ли вообще файл для чтения? 3. Какая строка считывается из файла последней? 4. Что будет, если считать каждую десятую строку? Не потому "это все раньше нормально работало", а тупо вбить контрольные выводы!
|
|
|
|
Добавлено: Пн авг 03, 2015 15:07 |
|
|
|
|
|
Заголовок сообщения: |
Re: SREAD-LINE перестает видеть переводы строк |
|
|
Спасибо всем откликнувшимся. Коллеги, обращаю ваше внимание, что первое что я прошу - проверить воспроизводится ли у вас данная проблема. VoidVolker, думаю тебе это будет точно не сложно, т.к. крон у тебя, по идее, должен стоять. Просьба по прежнему в силе gudleifr, листинг тестовой задачи я привел для упрощения и "стандартизации" проверки воспроизводимости данной проблемы. Листинги слов - для того что бы облегчить Вам оказание мне помощи. Все источники возникновения данной проблемы я, насколько мне позволяют мои знания, уже отсеял, и локализовал как смог - дальше сам не могу, поэтому и обращаюсь за помощью к тем кто в этом лучше меня разбирается. Hishnik, из моей, далеко не разовой практики использования этого слова, оно вполне корректно делает то, что требуется - за каждый проход выдает au-строку между двумя символами перевода строк. Если между двумя символами перевода строк нет других символов, то au-строка будет нулевой длины. VoidVolker. 1. Все переводы строки в обоих тестовых файлах - виндовые. Оба файла сгенерированы специально для локализации данной ошибки - каждая строка представляет собой результат от Код: 1000000 RANDOM N>S 2. Да, плагин отличный, но постепенно перешел от построкового чтения из файла к построковому чтению из памяти (если объем свободной оперативки позволяет) 3. Нет, нужна обработка каждой полученной строки.
Спасибо всем откликнувшимся.
Коллеги, обращаю ваше внимание, что первое что я прошу - проверить воспроизводится ли у вас данная проблема. [b][color=#FF0000]VoidVolker[/color][/b], думаю тебе это будет точно не сложно, т.к. крон у тебя, по идее, должен стоять. Просьба по прежнему в силе ;)
[b][color=#FF0000]gudleifr[/color][/b], листинг тестовой задачи я привел для упрощения и "стандартизации" проверки воспроизводимости данной проблемы. Листинги слов - для того что бы облегчить Вам оказание мне помощи. Все источники возникновения данной проблемы я, насколько мне позволяют мои знания, уже отсеял, и локализовал как смог - дальше сам не могу, поэтому и обращаюсь за помощью к тем кто в этом лучше меня разбирается.
[b][color=#FF0000]Hishnik[/color][/b], из моей, далеко не разовой практики использования этого слова, оно вполне корректно делает то, что требуется - за каждый проход выдает au-строку между двумя символами перевода строк. Если между двумя символами перевода строк нет других символов, то au-строка будет нулевой длины.
[b][color=#FF0000]VoidVolker[/color][/b]. [b]1.[/b] Все переводы строки в обоих тестовых файлах - виндовые. Оба файла сгенерированы специально для локализации данной ошибки - каждая строка представляет собой результат от[code]1000000 RANDOM N>S[/code] [b]2.[/b] Да, плагин отличный, но постепенно перешел от построкового чтения из файла к построковому чтению из памяти (если объем свободной оперативки позволяет) [b]3.[/b] Нет, нужна обработка каждой полученной строки.
|
|
|
|
Добавлено: Пн авг 03, 2015 14:41 |
|
|
|
|