Re: [fpc-devel] FPCUnit problem - do we fix or rewrite?
Graeme Geldenhuys pravi: Hi, I use FPCUnit extensively at work and in open source projects like tiOPF, but I hit a bit of a snag - actually a bug in FPCUnit which causes many tests to fail for the wrong reasons. Here is one such case - in the tiOPF project many database tests fail do to Setup Once issues: http://opensoft.homeip.net/tiopf/fpcunit/index.html Michael van Canneyt has also hit this bug before, but now I'm not sure what exactly to do about it. The bug has to do with running a setup or teardown only once. Yes FPCUnit has the TestDecorator which adds this support, but if you have a nested test hierarchy, the running once falls over. When doing unit tests that share DB connections this issues becomes a major pain. Michael had a more in-depth look at the issue and told me that the problem lies in the heart of FPCUnit's design and is not very easy to solve. So much so, that he recommends it is better to simply rewrite FPCUnit than try and patch the existing code. I have not taken such a close look to the issue, but had to modify my test hierarchy to get around the problem (which should really not have been needed in the first place). Michael, do you still feel the same way about this issue? Dean Zobec, are you still around? FPCUnit was your baby to start with. Do you have any comments? FPCUnit was a port of JUnit, actually a clone in Free Pascal. The Setup and Teardown run only once for a set of tests goes against the philosophy of unit testing actually, as violates the priciple that all the unit tests should be independent from each other. The feature was added as a decorator in JUnit for some marginal cases, with a very use with care labeled on it. Where the class under test has strong dependencies on other classes or the other classes are heavy to construct in the usual Setup run for every test, I think it's about time to use Mock Objects. Anyway the code is quite old, JUnit evolved with the use of interfaces and annotations and fpcunit stood still. I think annotations (in NUnit and JUnit 4) were a big improvement as the tests can be inserted in any class, without a need of inheriting from a TTestcase. I'm sorry but I have no spare time at the moment to participate in any serious development process, so I can only take a look from time to time to give some suggestions and recommendations. Dean I'm at cross-roads now. Do I try and solve the problem using the current code, or do I collaborate with Michael and Dean (and anybody else interested) and start a rewrite? If a rewrite is the preferred option, I have a few questions * how will this affect all the existing FPCUnit users? * will (or must) the new design have a similar API so our existing test suites will continue to run. * Do we make it more DUnit compatible? I already created many DUnit compatibility methods, but some things are not possible. * DUnit2 (hosted in the tiOPF code repository and written by the late Peter McNab) has some major improvements over the existing DUnit. Do we incorporate/port that, or merge the DUnit2 code into a new testing framework that is FPC and Delphi compatible? * Obviously a timeframe is also important * Do we use Interfaces (like DUnit and DUnit2) or do we use abstract classes like FPCunit currently does. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [patch] small fpcunit patch from Graeme
Graeme Geldenhuys writes: I can't remember the details - the patch was submitted a while back. Basically running the GUI, it always writes to the console as well, which I think is wrong. So while the tests run, the console gets filled up as well as the XML test results tab. I'm attaching your little patch for fpcunit so that somebody can commit it (it has to be applied from fpc/packages/fcl-fpcunit/). For Michael: I've sent you this patch by pm two days ago, but maybe the mail was lost. Regards, Dean fpcunitpatch.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPCUnit as a separate project from FPC?
2007/5/22, Graeme Geldenhuys [EMAIL PROTECTED]: Hi everybody, Darius Blaszijk, Vincent Snijders and myself had a discussion off the mailing list about the possibility of moving FPCUnit out of FPC as a separate project. I thought it to be important that we get the opinions of others as well. In summary: Darius is all for it. Vincent is against it. I'm on the wire, but leaning towards the move. :-) Dean is absolutely against it Some points that where raised in our discussion (please add more if I left some out): * As it stands now, FPCUnit is split between two repositories. The FPC one and the Lazarus one. This make it really hard to submit updates. The FPC one must be done first otherwise it breaks the Lazarus GUI TestRunner (or Console TestRunner). FPCUnit is in fpc repository, the gui test runner is only a frontend. The various listeners were refactored to remove dependencies from unnecessary libraries so that fpcunit could have the minimum requirements in terms of libraries. E.g.the plain text and latex reports could be used avoiding unnecessary dependencies from the XML Dom units. All this to be able to use fpcunit in the new package system (the vision is to be able to download a package with the system, build it and then run automatically the tests included in the package). This is strategic, whereas the gui stuff is of second importance imho. Besides this I'm using the console to run the tests with plain text output usually, and find it very practical :) . Maybe a simplified version of Vincent's consoletestrunner could be moved to the fpcunit package as well, moving it out of the Lazarus repository. * FPC versions are a issue as the release cycles is very different for the FPC and Lazarus projects. Apparently the FPCUnit is broken in the previous release of Lazarus, due to this. There's only some gui problem I guess. * Vincent likes the idea of the testing framework being part of FPC. One simple checkout. I think this point is moot because SubVersion support Externals Definitions for exactly this purpose and I think will actually work better than the current setup. We can link FPCUnit to FPC as an external link - and even link it to a specific revision of FPCUnit to always guarantee it pulls in a stable version of FPCUnit for use in FPC's test cases. Most of us work with fresh fpc svn checkout code, I see no problem: if a change is needed in fpc we can add it promptly in the fpc svn and use the svn version. What is your thoughts on this? Please keep it where it is now. I see no valid reason for the move. Regards, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPCUnit as a separate project from FPC?
Florian Klaempfl pravi: If it helps, I see no problem to give Dean write access to the FPC repository. I guess the same applies for lazarus. Thank you for the offer. I think it's not necessary for now, I get along very well with MvC's mentorship and like to discuss with the core team every single step I take, a day or two in the svn update won't make any difference I guess. Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Base64 decoding stream in the FCL
Bram Kuijvenhoven pravi: Hi, Attached is a patched base64 unit and a unit with FPCUnit tests. I zipped it to save space; I think my previous attempt has been rejected because the message was too big. Changes: - Added support for a MIME and a Strict mode for TBase64DecodingStream A very nice and simple way of making testcases with different input parameters! Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] - fpcUnit testreport.pp
Graeme Geldenhuys ha scritto: Hi Thanks for that, I didn't know about that function. Attached is the patch using the new StringOfChar. Incidently the speed increase is not much, but yes it is faster. Maybe my test cases are just not big enough. ;-) I did 4 test runs with the old trSpace function and did 4 test runs with the new trSpace function outputing 80 lines of text each with varied levels of indentation. The huge speed increase was:0.00145 seconds Thanks, that really cut down on my coffee break. :-) There's another benefit, 7 lines of code less. Btw, thank you for your constant work. Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] last change to xmlreporter.pas (part of fpcUnit) not working
Dean Zobec ha scritto: Graeme Geldenhuys ha scritto: Hi, I got an update of FPC 2.1.1 today, and my fpcUnit test results are not correct anymore. The XML test listener (xmlreporter.pas) is not writing the Failures correctly. It keeps creating new (duplicate) list nodes for each Failure. The Error nodes are working fine. See a snippet of my output (tested both under the GUI Test Runner and the Text Test Runner). Notice that there are duplicate ListOfFailures nodes, when there should only be one. The errors are correct, because their is only one ListOfErrors node created. Sorry for that, but I'm unable to reproduce the problem, seems that my code is working ok. The change in xmlreporter was so simple that I didn't even bother to write tests for it, I will write them now! :) Can you send me the source of the runner you are using as well as a simple suite of tests that creates the problem, so that I can run them and see what's happening? I need to reproduce the bug to be able to fix it. Ok, I've got it, finally I've been able to reproduce it. Now let's see how to fix it. Thank you again, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcUnit demo error
Leonardo M. Ramé ha scritto: Sorry, i thought frameworktest was the correct one. No problem, my fault, lack of documentation :) Thank you for reporting, Regards, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcUnit demo error
Hi Graeme While on the subject of fpcUnit... Have you submitted the patch for GUI Runner with checkbox support? I remeber you email a select few to test it, but can't remember if it was officially submitted and maybe got missed in all the mail traffic. Reason I noticed, is because my work PC has it running and got so used to it. good, so at least it's tested ;) In the last week I setup a development pc at home, got the latest from SubVersion and the checkbox support wasn't there... If you haven't had time yet, no problems, I can always grab the patches from my work pc. No, I just waited for the Lazarus release with 2.0.4 fpc as it needs the last changes in the fpc tree (the list of skipped tests) and I hate ifdefs :). I've discussed with Vincent for another addition: an Ignore(const aMessage: string); method that will enable a temporary ignore of a test (at compile time) and send a message to remind the future need of implementation, coloring the tests yellow as in NUnit. I'll probably implement it this weekend. Regards, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcUnit demo error
Leonardo M. Ramé ha scritto: People, just found an error in the consolerunner/testrunner.pp demo application. It's constructor and destrutor differs from the frameworktest sample in the tests directory. The correct methods are: constructor TTestRunner.Create(AOwner: TComponent); begin inherited Create(AOwner); FXMLResultsWriter := TXMLResultsWriter.Create; FSuite := TTestSuite.Create; FSuite.TestName := 'Framework test'; FSuite.AddTestSuiteFromClass(TAssertTest); FSuite.AddTest(TSuiteTest.Suite()); end; destructor TTestRunner.Destroy; begin FXMLResultsWriter.Free; FSuite.Free; end; No, this is not an error, the test runner in the tests directory runs the tests of fpcunit itself, so it intentionally does not use the fpcunit automation to build the testcases through the methods in the testregistry unit. In fact in the constructor the TTestSuite is built manually. Sometimes you have to act this way (e.g. where you need some parameterized test cases). Whereas the test runner in the demo directory uses the registration mechanism to build the test cases. But there IS an error in the testrunner in the demo directory, the unit testreport was substituted with the new xmlreporter that lacks some methods used by the runner. For Vincent: what if we simply use here your text test runner in the lazarus/test directory? I'll prepare a patch. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcUnit generates invalid XML
Graeme Geldenhuys wrote: Hi Dean and others, I have setup a nightly build server for the tiOPF framework and want to generate a Last Build Status page on my web server. I started by creating a XSL file that will translate the XML file generated by the Text Runner, when I noticed that the XML generated is not valid as it contains reserved charaters in the node text. Example: message[SETUP] Persistence layer not loaded TAB/message or a more common one. messageFailed on 4 expected: $ 0.01 but was: $ 0.00/message The and characters are not allowed, so I can't parse it with XSLT. I can see thee solutions for this. 1) I have a Resevered Character Translator for XML, CSV and TAB files that I used in another project that I can build into the TestReport unit. It has no other dependencies, but gives us a option to output test results to CSV or TAB files without having to worry about reserved words as well. 2) Use the XMLWrite unit (that comes with FPC) which automatically generates the correct text when resevered characters are detected. The bonus, is that it generates indented XML as well which makes it easier to read for humans (though this is not a major issue). We will have added dependency on the XML units, but is that such a bad thing as the XML units come with FPC as well. 3) Wrap all node text in CDATA tags, but I really don't like this idea! I think the best option is to use option 2. What do others think. Either way, I am willing to make the changes required. Option 2 is the most appropriate I guess. Anyway you can also remove the characters that give problems and substitute them with others. I'll also read some material about the automation of execution of tests in JUnit to be able to build a good framework for the batch execution of tests. I've seen a lot of material available. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR: What sites to spam for 2.0.2 release?
Daniël Mantione wrote: Hi guys, Speaking of PR, we have a 2.0.2 to announce within a very short time and we better do it well. We won't be able to do a Slashdot or OSnews announcement, nevertheless we should take these opportunities to promote FPC. So, any ideas what sites we should spam? I'm looking for developer focused sites. Pascal/Delphi related sites are welcome, but remember we are already quite famous in that world. We need generic open source related sites. Daniël http://lwn.net/ ? http://lwn.net/op/FAQ.lwn Please tell us when the announcement is available in the svn or the wiki, to be able to translate it in other languages and post on specific local forums or websites. I'm considering sending a news announcement on some Slovenian or Italian website related to open source and IT news. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Marco van de Voort wrote: Better finish decal. DeCal is good and comfortable for most cases, and trying to speed it up will kill the ease of use. Then we can collect some other set of routines over time for more performance dependant stuff. You are right, it will be probably the easier way. For this, I implemented dirty, but very fast maps and sets. These are not generic, but fast, and with FPC they can really fly due to inline capabilities. See http://www.stack.nl/~marcov/lightcontainers.zip Thank you, I'll take a look in the next few days. Maybe we could build on this instead. It's not as friendly ;-) Ouch, it bites, ehmmm or should I say it bytes ;) Very interesting stuff, but not for mere mortals like me :) Really out of my reach. I'll try to play with it, just to try to see how it works (even if I doubt I'll be able to understand the compiler god's code :) Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
John Briggs wrote: This is a repost of an earlier response to another thread. I did not recieve any response so I am posting this in its own thread. I have several old books (circa 1991), including source code, covering TP6 in my library. I still remember the Algorithms + Data Structures = Programming book from Niklaus Wirth back in 1976, it was a masterpiece. I'll try to find it in a library to reread it :-) Perhaps the most interesting one covers generic programming. It covers modelling generic data stuctures including: Generic Stacks Generic Queques Generic Arrays Generic Virtual Arrays Generic Matrices Generic Jagged Matrices Generic Internal Hash Tables Generic Singly Linked Lists Generic Doubly Linked Lists Generic AVL Trees Generic Graphs If any of these are of interest, please respond because I will have to rework the code for it to compile cleanly using FPC. Regards John As you've probably heard from Florian, FPC needs a good containers library. I've started looking at Decal this week, the code has been ported to fpc by Marco Van de Voort and now compiles with FPC. It's based on the TVarRec and open array construction (array of const) to be able to add to the containers even the base types as integers, floats, chars, etc. The generic functions are very powerful and model closely the C++ STL library (as fpc does not have generics yet a sort of typecast is still required when fetching the items from the container). The library was not designed for speed though, from the first test the DArray class is twice as slow then the TFPList for example). Anyway, I think it's a good start, since as I've seen from the wiki, we'll not have generics in fpc available soon (I would be glad to contribute to the generics implementation, but this but is still beyond my current poor fpc knowledge :( ) . When our compiler will support generics, if Decal will be fully covered by unit tests I think it will be easier to convert to it. The code is available in the old fpc cvs under the directory projects/contrib/decal. I've began to clean the unit to make it more readable, moving the comments in a fpdoc xml file and restoring a proper indentation. Then I'm planning to pin down the code with unit tests with FPCUnit to begin a refactoring in case there are potential speed improvements and to remove possible bugs (I've seen a lot of strange comments in the code that does not smell very good). The unit is quite big, more or less 9.000 lines of code, and quite complicated, so I'll surely need help. In any case I'm very interested on the subject of container classes so I'm glad to discuss it with other people interested in it. As the project looks like a long term one and I think that fpc urgently needs a optimized hash table I'll also work on a streamlined hash table with a chaining technique as a collision resolution scheme and a paging for the allocation of the nodes in the chains, to have an associative container that would easily beat the TStringList in search speed when the number of items added is more than 100.000 (the IndexOf() function in an unordered TStringList does a linear search). I would be glad to receive opinions on the container classes implementation in FPC and of course we'll surely need help (I'm not working as a professional programmer, I even do not work in the IT field, so my programming work as an hobby is limited to the evenings), so feel free to get in contact with me even in private if you prefer. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Michael Van Canneyt wrote: Depends how the hash is parametrized. If you've a big hash array and a good hash function accessing has a complexity of O(1) while for a binary search it's O(log(n)) But I assume that calculating the hash becomes harder for 'better' hashes ? Not always, it depends on the type of the input, different hash functions have to be used for different key types, a hash function good for numerical keys will be different from the hash function used for the string keys. My idea is to add to the hash table a method for statistical data about the table: number of collisions, i.e. length of the chains and the number of void buckets in the hash array, to be able to choose the right hash function and the right dimension for the hash array in the specific case. Of course speed comes always at an expense: memory usage, the trick is to find a good compromise. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Michael Van Canneyt wrote: What is the performance difference between a hash() and a binary search on an ordered list ? I've also been working with an 'associative' stringlist, but I was using an ordered stringlist to keep the data, so a binary search is done. The TStringList is a very fast class, if you worked with less than 100.000 items you would not notice any difference. But a Hash Table is also very fast in insertion, while to keep a list ordered only for searching may be not convenient and slows down insertion. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Marco van de Voort wrote: The generic functions are very powerful and model closely the C++ STL library (as fpc does not have generics yet a sort of typecast is still required when fetching the items from the container). The library was not designed for speed though, from the first test the DArray class is twice as slow then the TFPList for example). Anyway, I think it's a good start, since as I've seen from the wiki, we'll not have generics in fpc available soon (I would be glad to contribute to the generics implementation, but this but is still beyond my current poor fpc knowledge :( ) . When our compiler will support generics, if Decal will be fully covered by unit tests I think it will be easier to convert to it. At work, I have found out that decal is too bulky and too slow for some purposes (I've lists with millions of objects in memory). _each_ entry in a decal container eats 78 byte (with D6 memory manager, but will only be equal or larger with FPC) I can immagine, the DObject is a TVarRec. The problem with speed and memory usage are the things that I don't like in Decal and it still makes me wonder if it would be better to reimplement a containers library from scratch, if we had generics to add type checking at compile time... I'm looking at all the options (time is a limited resource :). For this, I implemented dirty, but very fast maps and sets. These are not generic, but fast, and with FPC they can really fly due to inline capabilities. See http://www.stack.nl/~marcov/lightcontainers.zip Thank you, I'll take a look in the next few days. Maybe we could build on this instead. projects/contrib/decal. I've began to clean the unit to make it more readable, moving the comments in a fpdoc xml file and restoring a proper indentation. I have a tex version of the decal docs somewhere. http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files) Thank you, I had your pdf but not the tex file. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Marco van de Voort wrote: Dean Zobec wrote: As the project looks like a long term one and I think that fpc urgently needs a optimized hash table I'll also work on a streamlined hash table with a chaining technique as a collision resolution scheme and a paging for the allocation of the nodes in the chains, to have an associative container that would easily beat the TStringList in search speed when the number of items added is more than 100.000 (the IndexOf() function in an unordered TStringList does a linear search). A good hash class is even a candidate for the classes unit imo. Something variants based is not though, at least IMHO. I did not mention variants, I do not intend to use them. I'll try to streamline and polish a class I've used in a previous project: See the TDZNotOwnerHashTable at the end of the unit: http://cvs.sourceforge.net/viewcvs.py/camelos/EOS/fpcEOS/dzcontain.pp?rev=1.1view=markup Note that the Technetium people (Flawless and Aison on IRC) have several of such routines. At least all the algo's are there and tested, only class wrapper would be needed. Thank you, I'll get in contact with them. Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic Programming Units
Bram Kuijvenhoven wrote: Besides using TVarRecs, we could also use pointers (as in classes.TList) or objects. Pointers like in TList were the things I had in mind. This would perhaps be a bit like it is in java.util. Then we would also need container classes for basic types such as boolean, integer, string and float. I'm not sure whether this is indeed a good plan, but I'm just mentioning it because you said you want to look at 'all the options' :) Yes, the containers for basic types could be constructed as wrappers, the pointer based containers would be incapsulated. Anyway, I'm very interested in a library with commonly used generic data structures and algorithms, and I think there are many more such developers. So I'd say: keep up the goods plans work! Good to know that are many people interested in the subject. I'm sure I'll learn a lot of things from them, as always in this great community :) Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]decal
Alle 20:30, martedì 13 aprile 2004, Marco van de Voort ha scritto: I ported the Delphi library Decal (used to be called SDL, by Soletta) to FPC 1.9.[2? 3!]+. Thank you for the porting, it was one of the most needed libraries in fpc IMHO (I consider the cntnrs unit in Delphi a simple joke in comparison :-) . I'm planning to use Decal in a free accounting project that I started developing with fpc on linux. Hope I'll be able to provide some useful feedbacks. I'm currently correcting a quick conversion of the manual to LaTeX, which I hope to put in CVS end of the week. It's the original manual from Soletta? Something about 80 pages I guess, a huge work indeed... Let's hope that it would contribute to form a community of DeCAL users to renew the interest in this great library (I've seen that the Source Forge page was surprisingly inactive in the last years in terms of cvs commits, but I'm quite sure fpc will make the difference now). Thank you again, Dean ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
