REGEXP

[Elfy 0]

Regexp seems to be unusable at all. (Maybe not so many bugs, but enough to made it useless.)

 

Is anybody using it? Bugs are hard to reproduce on small files (regexp that didn't work on real big file work ok on copied part of that file) and I'm not sure about necessity of detailed bugreports. Too strange, too obvious and too hard to describe. The code about regexps needs hard testing with debugger and sources.

[AngelsHolocaust 0]

hi!

 

i am using RegEx

and i just made some little tests with a 550k/17000 line file

 

give me at least a hint of what to look for

 

there are only a few things left that do not work

Multiline Search f.ex.

 

RegEx is pretty bugfree from my point of view

 

Stefan / AH

[dandv 0]

Hi Elfy, a bug report will always help. If you have a large file, feel free to e-mail it to me, if you can't upload it somewhere.

 

Aside from that, I haven't used regexps much. Maybe regexes didn't work for you because they contained spaces, which are ignored? (BTW AH, this is a bit strange; are regexps by default "Extended"? I.e. do they ignore spaces?

 

Example:

In a file containing "a b xxxxxx", search for "a b" with "Regular expressions" checked. NDN won't find anything. You have to escape the space for NDN to find the string: "a\ b".)

 

Dan

[AngelsHolocaust 0]

Hi!

 

yes, i set the extended flag by default because it enables comments inside RegEx' statements

 

i may disable this by default if anyone of you prefers it

....hm, i will disable it anyway

 

this remindes me...

besides adding new code i need to update the help file(s)

any volunteers for the english part? :P

 

Stefan / AH

[Elfy 0]

Ok. I do some testing.... It seems to be reincarnation of bug when some part of text in viewer was not searched at all. In some old version odd 32kb blocks don't searched :) Maybe this bug is of same type.

 

rxtest

 

search for "\sWCHAR;"

 

And don't tell me that this works :)

[AngelsHolocaust 0]

hi

 

VIEWER!!!

of course, look at ah_news.txt

 

- problems with regex results display and advancing (Dandv) []

 

i thought we talked about editor

 

the bug you describe (and DanDv did before in previous posts) has to do with the size of the buffer used to load the file

at the moment it is fixed at $10000 (look in viewer setup), try setting it to $8000 and im sure you will have the same problems with 32k blocks again

(what old version do you mean, my versions? or even before mine? because old NDNs used $8000 as standard size)

i even think there are some problems with non-regex searches at this 'barrier'

 

i need to work on viewer, but first i want to finish syntax highlight (elfy, the head13.htm loading problem is fixed)

because there are some more issues

i hope i can make the viewer working well

for the xmas release

 

sorry, i hope you will still use NDN :P

 

Stefan / AH

[Elfy 0]

AH> what old version do you mean, my versions? or even before mine?

 

Before.

 

>try setting it to $8000 and im sure you will have the same problems

>with 32k blocks again

 

Problem exist with $8000 buffer, with $10000 buffer, with $1000 buffer, with $20000... Are you sure it's matter?

 

> (elfy, the head13.htm loading problem is fixed)

 

He-he, are you agreed that problem exist? :)) Good. Maybe you will do some explanation? It's curious.

 

thanks

[AngelsHolocaust 0]

hi nick!

 

> Problem exist with $8000 buffer, with $10000 buffer, with $1000 buffer, with $20000... Are you sure it's matter?

 

yes, because it always exists at the buffer size, yes?

im quite sure this is a part of the problem

 

>He-he, are you agreed that problem exist? ) Good. Maybe you will do some explanation? It's curious.

 

the answer is simple, but the solution isn't:

HTML.HGL-File: Comment <! >

 

MULTILINECOMMENTS in NDN are all parsed at loading time of the file, so all needed parts of comments (and of course all other highlight parts) can be handled as fast as possible when you edit the file

 

now, in HTML files EVERY tag ends with '>' (in your bug report you already found the reason why NDN takes so long to load), and there are LOADS of them in big files, so NDN stored EVERY tag in it's list for comments

and this takes a lot of time

i have solved this problem by only counting actual parts of bracket pairs (only if a <! was found, include the next >)

in the case of your HEAD13.HTM there are 16040 '>' tags

 

but, bigger files (like Virtual Pascals windows.pas,550k,17000 lines) still need some seconds to load, because every line must be parsed

this is the only place where i can make future optimizations i think

 

hope this is enough explanation?

 

thanks

Stefan / AH

[Elfy 0]

>yes, because it always exists at the buffer size, yes?

 

I don't understand... It exist but I don't see any connections with buffer size.

I try find same pattern on original file (matched string not in the beginning) at various buffer sizes and bug reproduced repeatedly.

 

>hope this is enough explanation?

 

I'm suspecting dependance from tags count... But problem was not in dependance but in exponential (presumably) dependance. It must be polynomial, or better linear. I can be wrong with estimation of algorithm's complexity but it seems so.

 

>but, bigger files (like Virtual Pascals windows.pas,550k,17000 lines) still need some seconds to load, because every line must be parsed

 

And this suggest to problem not solved... Just optimization done, but algorithm still the same. Am I right?

 

I suppose problem is in memory manager.

[AngelsHolocaust 0]

I don't understand... It exist but I don't see any connections with buffer size.

I try find same pattern on original file (matched string not in the beginning) at various buffer sizes and bug reproduced repeatedly.

 

don't worry, the problem has been solved

i hope without any side effects

 

I'm suspecting dependance from tags count... But problem was not in dependance but in exponential (presumably) dependance. It must be polynomial, or better linear. I can be wrong with estimation of algorithm's complexity but it seems so.

 

>but, bigger files (like Virtual Pascals windows.pas,550k,17000 lines) still need some seconds to load, because every line must be parsed

 

And this suggest to problem not solved... Just optimization done, but algorithm still the same. Am I right?

 

I suppose problem is in memory manager.

 

i am always trying to solve problems as good as possible, and indeed, the problem is not completely solved

i will investigate the internals of the problem when i have solved other heavier issues

 

Stefan / AH