Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 20:19

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - SREAD-LINE перестает видеть переводы строк
Автор Сообщение
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
makrus
http://www.nncron.ru/forums/viewtopic.php?f=5&t=13237
Сообщение Добавлено: Пт авг 07, 2015 13:44
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
VoidVolker писал(а):
Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся )
Большущее спасибо :poklon; за проделанную работу.
Я, к сожалению, понял еще меньше, но главное работает! :D

gudleifr, тоже спасибо за активное участие!
Сообщение Добавлено: Чт авг 06, 2015 14:27
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
VoidVolker писал(а):
Но если честно, я сам не все понял тут и возможно данное решение неправильно и я где-то ошибся )

Все правильно. Я тупо искал, где в асм-е пропущено "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 и добавление префикса).
Сообщение Добавлено: Ср авг 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
Сообщение Добавлено: Вт авг 04, 2015 21:26
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
makrus писал(а):
Я все никак не могу понять, что мешает тебе скачать два файлика, добавить в кронтаб задачу, подкорректировать пути к скаченным файлам, запустить ее и сообщить результат: совпадает с моим, не совпадает с моим но считает не все строки, считает все строки.

Дык а ссылка-то где на файлы? Давно бы уже скачал их.
Сообщение Добавлено: Вт авг 04, 2015 20:44
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
makrus писал(а):
Нет, открыв в текстовом редакторе
Значит, никакой гарантии, что программа остановилась именно на этой строке, у нас нет. Нужно проверять. И, в случае неудачи - "каждый десятый".
makrus писал(а):
у меня есть неподтвержденные пока догадки, что переводы строк перестают видеться после прочтения определенного объема данных в строках.
Логично. Первая версия - что-то где-то переполняется.
makrus писал(а):
То что в этих двух файлах SREAD-LINE "слепнет" на разных по счету строках можно объяснить тем, что файлы с рандомной длиной строки и не все строки строго длиной 6 байт, есть и меньше.
Тоже логично.
makrus писал(а):
Боюсь, тут надо уже посмотреть на определение слова SEARCH с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле
Пока рано.
Сообщение Добавлено: Вт авг 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 с точки зрения использования им памяти при многократных (десятки тысяч) вызовах в цикле - может там используется область памяти кодофайла (который ограничен в кроне) или еще что-то из области работы с памятью.
Жаль для меня все еще и ассемблер и использование Фортом памяти - слабо освоенные области :(
Сообщение Добавлено: Вт авг 04, 2015 16:57
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
makrus писал(а):
т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же.

Это не важно, FORTH-специфика работы с памятью часто дает воспроизводимый мусор.
makrus писал(а):
Строка №13817 в файле "TestFile.txt" содержит строку "243154"
Строка №13839 в файле "TestFile2.txt" содержит строку "693725"
Это ваша программа выдала? Или в файле посмотрели? Размер "считанной части" примерно 100kb. Вроде, "ни о чем", тем более, Вы говорите, файл нормально влезает целиком. Что дает положение этой строки в памяти (относительно других блоков?).
makrus писал(а):
доработаю задачку, проверю.
Раз Вы подтвердили, что точная точка останова определена, уже не надо. Поиграть имеет смысл с другими размерами файлов. Например, не 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 они вроде нигде не используются, а в этом слове она одна и нужна для подсчета. Если намек на повторное использование этого слова в пределах одной задачи, то насколько я знаю, при повторном вызове одного слова они "обнуляются" (а фактически каждый вызов слова работает со своими локальными переменными), но в конкретно данном случае - это не важно, т.к. при своих первоначальных тестах этой задачи, я за каждый запуск задачи обрабатывал только один файл, результаты были те же.

В СПФ (а значит в кроне) для локальных перменых используется стек возвратов и они всегда инициализируются нулем.
Сообщение Добавлено: Вт авг 04, 2015 08:38
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
Мне уже становится интересно, кто же будет ТОТ, кто первым ответит на мой первый вопрос - воспроизводится или нет? :D

gudleifr
0. Про какие локальные переменные идет речь, кроме как в слове 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
что это значит - не понял :shuffle;

О, код! :)
Проверил у себя, результат тот же - 18 тыс. строк.
Попробуй увеличить их количество в 6 раз (объем прочитанных строк, как мне кажется, каким-то образом влияет на их максимальное количество). Я сделал это, в твоем слове, вот так:
Код:
18000 6 * 2* VALUE /buf
и получил следующий результат
Код:
2015 04 Aug 00:41:00 15624- Количество найденных строк: 9697

Переполнение счетчика?
Сообщение Добавлено: Вт авг 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
Сообщение Добавлено: Пн авг 03, 2015 17:08
  Заголовок сообщения:  Re: SREAD-LINE перестает видеть переводы строк  Ответить с цитатой
makrus писал(а):
Все источники возникновения данной проблемы я, насколько мне позволяют мои знания, уже отсеял
Значит, начинаем с нуля:
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. Нет, нужна обработка каждой полученной строки.
Сообщение Добавлено: Пн авг 03, 2015 14:41

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB