Some bugs

[Basil/2 0]

NDN 2.15.0000, Win 2000 SP4 Rus.

 

1. Editor option "Default code page" doesn't work: I have it "WIN", but all files I create (by Shift-F4) creates in DOS codepage.

 

2. Backward search (in viewer) can't be cancelled.

(sorry for annoying with this, but I have to analyze large log files (over 100Mb) from end to start, so I have to kill NDN-process always if search string is not in file)

 

3. Sometimes in editor, after pressing Enter, the cursor jumps to the next line at row-position not of the current line, but of the previous. Sorry, it sounds har to understand, there is an example:

 

normal ('_' means space):

---------

___test

 

my string1

2

---------

 

Being at 1, cursor jumps to 2 after Enter. It's correct. But sometimes, after enter

 

wrong:

---------

___test

 

my string1

___3

---------

 

Cursor jumps to 3 - not to the start of line. And this behaviour, once happend, CONTINUES until file is editing.

If I press Esc, and then F4, bug disappers fro some time.

 

 

P.S. AH, what about some unit-tests for editor? I do understand it's very hard to make them for an editor; but this will be VERY useful in fighting against bugs, I guess.

[AngelsHolocaust 0]

hi!

 

1. ok

2. this is fixed for the new version (as well as tons of other viewer stuff)

 

3. noticed that too -> to the list

 

i am not sure what you mean with unit test

 

Stefan / AH

[Basil/2 0]

About "unit-tests" (and "regression" tests, and NDN).

 

This is a relatively modern way to test your programs, or rather, your procuderes and functions. The main thing of this is: write tests for your functions before writing these functions (or immediately after). Example:

assume that you plan to write function Square(). Before this, you write tests (in C):

------

; TestEquals(p1,p2,p3) - procedure which compares p1 and p2 and prints "error: p3" if they are different.

 

; Common cases

TestEquals(Square(2), 4, "test1");

TestEquals(Square(3), 9, "test2");

 

; Border cases

TestEquals(Square(0), 0, "test3");

TestEquals(Square(MAX_INT), 0, "test4"); // there may be overflow - depends on compiler

TestEquals(Square(-3), 9, "test5");

------

Than, you compile these tests. Certainly, all of them will fail if Square() is empty. And your task is to write such Square(), that completely PASSED ALL TESTS. If you have good and full tests, it means you created a good function indeed.

 

After writing tests, you combine their to packages, and than combine packeges to a test program. If even one test in package fails, whole package is failed. If even any package fails, the entire test program is failed.

 

During development, you sometimes (and always - before release) launch this test program to make sure all your procedures and units are correct. This is very useful, if you corrupt the old code during adding features or fixing. This corrupted code unit-tests will fail, so you can detect that you just now "added some bugs" to program instead of fixing it.

If some user told you about any bug, you write test (or tests) which detects this bug, and then make your program to pass this test normally.

 

The second benefit is reducing time you spend on testing, because tests are automatical.

 

But, it's VERY difficult, to add unit-tests to program without them.

 

For more information, you can see http://xprogramming.com/xpmag/whatisxp.htm#test

 

 

Now, "Regression tests".

The technology is simple:

1. You launch your program; program make some results

2. You check these results manually and save it to safe place

3. Sometimes (and always - you already now when :) ) you launch your program and COMPARE it's result with saved, correct result.

 

 

As for NDN?

I offer the following. Any change or fix of editor easily adds some bugs to it or just change it's behaviour. If we made some regression tests for editor, we:

- can make sure editor's behaviour is STABLE from beta to beta

- describe errors in terms of tests

 

How can it be implemented? NDN has a very good thing - HGL-file MACROS (Macro 1..9); and most editor bugs (or uncomfortable behaviours) AFFECT these macros! So you can create small program which receive 2 files:

- one with macro-commands

- second with text, on which these commands should be applyed

As a result, program creates 3rd file with processing result.

 

Then, we can use bat-file (or self-written program) to compare these result-files with hand-made correct files. If editor change it's behaviour, the program change result files (certainly, program use NDN sources for editor). I can make several test files for NDN-editor behaviour which is importanf for me.

 

 

No doubt, it's VERY difficult too. Moreover, I am not sure that macros can COMPLETELY cover all editor's behaviour and features. But, I guess, one time implemented, it will be a great step in program stability and for you as a programmer.

 

P.S. All I wrote is my opinion and it may be wrong.

[AngelsHolocaust 0]

hi!

 

extreme programming is basically what describes NDN's development history best (at least since RITLabs released the source code)

 

unit tests (or prototypical testing, as i know it) are a cool thing, especially before you add a new function or procedure to NDN

 

i AM testing every new code thoroughly (when it is INSIDE NDN, because this is easier for me than to write an own program to test... and dont forget i have to test some code for 3 operating systems at the moment)

 

i cannot do a EDITOR unit test, i need whole NDN around it

 

but, at some point (when i haven't found any problems anymore) i must end the work on this bugfix or new feature and trust my tests

 

sometimes i don't find new bugs i introduced

but, that is what BETA versions are there for

 

the problem is not a single new function or a couple of bugfixes, but the whole structure of the 'fixed' part of NDN, where bugs are hard to spot especially using unit-tests (f.ex. EDITOR, with tons of different options for every aspect...)

 

i will not spend time to make unit-tests because i will be able to use the time better to fix more bugs or add new features

 

if you want to write me unit-tests for the SHITLOAD of functions in NDN, you are welcome, i rather spend my time on fixing the bugs on the list (and most of them are not my fault)

 

about regression...

to compare my current version of NDN to older versions, i have 10 different versions of my source code on HD (which i save from time to time when a good branch is existing)

 

i have an archive of all the releases i made starting from dec/03

additionally i have following programs installed to compare with

 

DN 1.51 (RITLabs)

DNOSP

DNOSPW

NDN 2.11 d/w

NDN 2.12 d/w (the versions i compiled from the first source code i got from Necromancer)

NDN 2.13 d/w (Chemodun)

 

a little suggestion:

i would like everyone who reads this to download and compare the current NDN to the last public version 2.11

http://ndn.sourceforge.net/

 

i am very satisfied with the development of NDN in the past 18 months (i started work in june 2003)

so i don't see a reason to change my developing style

 

any other opinions?

 

your opinion can never be wrong :)

 

Stefan / AH

[Basil/2 0]

Ok. :)