[fpc-devel]Port of JUnit to Free Pascal
Hi, A couple of weeks ago I've started a port of the JUnit framework to fpc as I needed a run some tests over the fresh port of our EOS framework to Free Pascal (http://camelos.sourceforge.net). I've tried to adhere as much as possible to the original JUnit design to preserve it's ease of use and allow the most recent endoscopic testing techniques using Mock Objects. I've seen in the DUnit mailing list that Johannes Berg has enabled the Juanco's DUnit framework to work in fpc and other people are engaged in similar projects. It seems that we all nead a robust and easy to use testing framework for fpc, so I think we could collaborate a little more to exchange ideas. My first code, for those interested, is available here: http://prdownloads.sourceforge.net/camelos/fpcEOS20031201.tar.gz?download Ciao, Dean ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]timer with a resolution of a microsecond ?
In my current project, a port of JUnit to fpc, I need to calculate the execution time of the tests. My target platform is Linux/i386, but I would like it to work on other platforms too. Any suggestion? Another question, what's the correct way to provide functions in a fpc unit that are platform specific? Looking at the RTL source it seems that you prefer to put this function in an .inc file, right? I don't like my code being messed up with ifdefs. Thank you, Dean ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]timer with a resolution of a microsecond ?
Thank you John, > I always use Tomas Schatzl's cpu stuff available from > http://members.yline.com/~tom_at_work/cpudist.zip. It's available for > go32v2, linux, win32 & maybe others too...hth Regards John Indeed a great library with a good documentation! Regards, Dean ___ fpc-devel maillist - [EMAIL PROTECTED] 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
Re: [fpc-devel] TList slowness in classes
> > Talking about TList slowness: > > In the last years TList and TStringList became slower and slower. > > Are there any alternatives in classes.pp? A simple TList providing only > > the very basics, less checks, no notifications, less virtuals, reordered > > IFs ... ? > > TList has almost no virtuals, so I doubt you will find anything to > change there. The notifications can be optimized, Dean Zobec wanted to > try this. This is as far as I'm concerned the biggest showstopper. unnecessary things have been added to TList to accomodate descendants (very bad OOP design decision IMHO), like the notification to be used in the only descendant, TObjectList, that transformed the Clear operation from an O(1) to an O(n) operation. Here is what Delphi designer Danny Thorpe says about TList in his book Delphi component design (1997): "You'll almost always wind up using a TList in a component, but you'll never create descendants of TList. TList is a worker drone, not a promiscuous ancestor class." Unfortunately the programmers of Delphi 5 seem not to have read his book :-) another explanation from Danny: "If you want to create a list of a particular kind of item and that list is used only in the private or protected sections of your component implementation, then just use a plain TList and typecast the list's raw pointers into the type you put into the list to begin with. If the list is exposed in the public interface of your component, typecasting is not an option. You cannot require a component user to typecast a list item appropriately in order to access it. You should create a simple wrapper class (derived from TObject, not TList) that exposes only the property and function equivalents of TList that you need and whose function and whose function return types and method parameter types match the type of data that the list contains. The wrapper class then contains a TList instance internally and uses that for actual storage." So TObjectList should have been designed as a wrapper around TList, with no need to add the notification mechanisms in TList. I've began writing a tutorial for fpcunit and have chosen this refactoring of TList and TObjectList as a subject of unit testing for my tutorial. Hope to finish it in the next two weeks. >> Are there >> any alternatives in classes.pp? A simple TList providing only the very >> basics, less checks, no notifications, less virtuals, reordered IFs ... ? >> If this TBaseList (or TSimpleList or TQuickList or THumbleList) would be >> the ancestor of TList, see above, composition is a better solution then inheritance in this case IMHO Ciao, Dean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] error in the proposed patch for bug nr.3873
My proposed patch in the submission of bug 3873 for the problem I've
discovered in typinfo with setters/getters of currency properties
contains a problem, it does not check for {$ifdef HASCURRENCY} and would
give problems with version 1.0.10 if applied.
So the proposed patch should be as the one attached to this mail.
Sorry for the inconvenience.
Dean
Index: typinfo.pp
===
RCS file: /FPC/CVS/fpc/rtl/objpas/typinfo.pp,v
retrieving revision 1.42
diff -u -r1.42 typinfo.pp
--- typinfo.pp 3 Apr 2005 11:50:58 - 1.42
+++ typinfo.pp 4 Apr 2005 21:35:23 -
@@ -1272,6 +1272,13 @@
Result:=TGetExtendedProc(AMethod)()
else
Result:=TGetExtendedProcIndex(AMethod)(PropInfo^.Index);
+ {$ifdef HASCURRENCY}
+ ftCurr:
+if ((PropInfo^.PropProcs shr 6) and 1)<>0 then
+ Result:=TGetCurrencyProc(AMethod)()
+else
+ Result:=TGetCurrencyProcIndex(AMethod)(PropInfo^.Index);
+ {$endif HASCURRENCY}
end;
end;
end;
@@ -1338,6 +1345,13 @@
TSetExtendedProc(AMethod)(Value)
else
TSetExtendedProcIndex(AMethod)(PropInfo^.Index,Value);
+ {$ifdef HASCURRENCY}
+ ftCurr:
+if ((PropInfo^.PropProcs shr 6) and 1)<>0 then
+ TSetCurrencyProc(AMethod)(Value)
+else
+ TSetCurrencyProcIndex(AMethod)(PropInfo^.Index,Value);
+ {$endif HASCURRENCY}
end;
end;
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some thoughts about TFPList
Michael Van Canneyt wrote: On Mon, 2 May 2005, pascalive wrote: I noticed that TFPList class was added in cvs version as a way to get rid of Notify performance penalty. I suggest to remove TFPList.Grow method since its only for Delphi compability (but Delphi doesnt have TFPlist) and AFAIK virtual methods add some degree of performance hit. I'd prefer to make it a normal static routine. But it does nothing and does not get called. When introducing TFPList it slipped through when I copied the interface from TList. So I think in TFPList could be safely removed. Otherwise it could be misleading. 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.1&view=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] 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] 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] 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: > > [SETUP] Persistence layer not loaded > > or a more common one. > > Failed on 4 expected: <$ 0.01> but was: <$ 0.00> > > > 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] 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 demo error
> 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. The attached patch fixes the console test runner demo. To be applied from the fpc/fcl/fpcunit/demo/consolerunner directory. It simply copies over the Vincent's console runner from the lazarus/test directory. Regards, Dean consolerunner_patch.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 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] last change to xmlreporter.pas (part of fpcUnit) not working
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. Dean > > --- > snip > > > TTestTIUtils.tiFloatToCurrency: Failed on 4 expected: > <$ 0.01> but was: <$ 0.00> > EAssertionFailedError > Failed on 4 expected: <$ 0.01> but was: > <$ 0.00> > > > > > TTestTIUtils.tiFloatToCurrencyHide0: Failed on 4 > expected: <$ 0.01> but was: <$ 0.00> > EAssertionFailedError > Failed on 4 expected: <$ 0.01> but was: > <$ 0.00> > > > > > TTestTIUtils.tiGetComputerName: Access violation > EAccessViolation > Access violation > ./include/lclintf.inc > 213 > GETCONTROLCONSTRAINTS > > > TTestTIUtils.tiGetTempDir: Access violation > EAccessViolation > Access violation > ./include/lclintf.inc > 213 > GETCONTROLCONSTRAINTS > > > TTestTIUtils.tiGetUserName: Access violation > EAccessViolation > Access violation > ./include/lclintf.inc > 213 > GETCONTROLCONSTRAINTS > > snip > --- > > Regards, > - Graeme - > > ___ 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] [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] Base64 decoding stream in the FCL
>>> If you test it, please try adding tests in fpcunit format. >> What would be a good starting point to learn about how to use fpcunit? (I >> haven't used it before) > > The sources and examples :-) In particular the fcl/fpcunit/exampletests/moneytest.pp testing the money.pp example classes is a translation of the original JUnit examples from Kent Beck and Erich Gamma, found in the original paper about unit testing, JUnit Test Infected: Programmers Love Writing Tests : http://junit.sourceforge.net/doc/testinfected/testing.htm And if you have particular questions you can ask :) > I once wrote an article about it (for beginners) if you want I can send it > to you. It's still here: http://www.freepascal.org/docs-html/fpcunit.pdf 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] 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?
Graeme Geldenhuys pravi: >> This is not quite correct. The only part which should be in Lazarus >> is the GUI stuff. The console testrunner can perfectly be integrated >> in FPC. (as stated by Vincent) > > I agree about the console testrunner. That should move to FPC. > My argument for submitting updates still hold. What if I submit > something in FPCUnit (core) that would break the GUI TestRunner. I > have to submit the FPCUnit core changes first. Wait till it's been > applied, then submit the Lazarus updates. Radical changes in FPCUnit core are rare, and if they happen they would reside in the latest svn trunk. The lag you mention about the Lazarus svn update was a day or two usually, no big problem. >While the Lazarus updates > have not been applied the GUI TestRunner is broken. This would have > happened again a few weeks ago, but my patch still hasn't been applied > in either project. :-( I'll take a look at them this evening. > >> >> The best that can be done is move the console runner to the FCL, >> and leave only the GUI part in Lazarus. > > This must definitely be done! I can live with the GUI Runner being > broken, but Console Runner not. > > > Please note: > I'm just raising some questions Darius had. I'm still happily > sitting on the fence. :-) > I can see positive and negative things either way. No problem, I'm sure that the best solution is to keep fpcunit in the fcl, I'll have more time to dedicate to the project this summer and quite sure that all the possible problems will be resolved as usual, with no need to complicate things. Hope we'll achieve together some big improvements. Big thanks to you and Darius for the discussion, it's needed sometimes. 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
[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 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
