Elfy 0 Report post Posted December 10, 2004 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. Share this post Link to post Share on other sites
AngelsHolocaust 0 Report post Posted December 10, 2004 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 Share this post Link to post Share on other sites
dandv 0 Report post Posted December 10, 2004 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 Share this post Link to post Share on other sites
AngelsHolocaust 0 Report post Posted December 10, 2004 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 Share this post Link to post Share on other sites
Elfy 0 Report post Posted December 11, 2004 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 :) Share this post Link to post Share on other sites
AngelsHolocaust 0 Report post Posted December 11, 2004 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 Share this post Link to post Share on other sites
Elfy 0 Report post Posted December 11, 2004 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 Share this post Link to post Share on other sites
AngelsHolocaust 0 Report post Posted December 12, 2004 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 Share this post Link to post Share on other sites
Elfy 0 Report post Posted December 13, 2004 >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. Share this post Link to post Share on other sites
AngelsHolocaust 0 Report post Posted December 13, 2004 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 Share this post Link to post Share on other sites