[fpc-pascal]class methods in FPC version 1.9.0
When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've encountered this small problem using class methods: When I pass an object instance as parameter in class methods I have a sigsev like in this example program TestFail; uses SysUtils; Type TMyObject = Class private FNome: string; published Property Nome: string read FNome write FNome; end; TMyTestObject = class(TObject) public class function OutputParticularClass(AObj: TObject):string; end; var obj: TMyObject; class function TMyTestObject.OutputParticularClass(AObj: TObject): string; begin Result := AObj.ClassName; Writeln(Result); end; begin obj := TMyObject.Create; TMyTestObject.OutputParticularClass(obj); obj.Free; end. The above program compiles with no warnings in FPC, but at runtime it sigsevs. I've run this in Kylix/Delphi and works as expected. On the other hand I've seen that class methods work ok if the parameter passed are integers for example class function TMyTestObject.OutputNumber(aNumber: integer):string; begin Result := 'Number is ' + intToStr(aNumber); Writeln(Result); end; begin TMyTestObject.OutputNumber(12345); end. works ok in FPC Am I doing something wrong or is a bug I've found? Any ideas? Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparing version numbers
Jilani Khaldi wrote: > >> Learn to code with UnitTests (process is called Test Driven >> Development). > > Never used. How does this work? I found only a unit called > "UnitTests.pp" and nothing else. > Thank you. The first article that started the practice, written by Kent Beck and Erich Gamma: http://junit.sourceforge.net/doc/testinfected/testing.htm See also the JUnit website http://www.junit.org/index.htm for more articles on the subject. To get you started with unit testing with FPC: http://www.freepascal.org/docs-html/fpcunit.pdf Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit testing Exceptions
Graeme Geldenhuys wrote:
> Hi,
>
> Is it possible to test the code below using the AssertException()
> call? I am sure it must be, I am just not sure how to use it.
>
> This is the work-around I have now, untill I can figure out how to use
> AssertException() correctly.
>
> try
>si.SetSlideName('006~sa.swf');
>si.SlideTypeDB; { <<== method raises an error if type unknown }
> except
>on E: exception do
>begin
> AssertEquals('Failing on 3', EUnknownSlideType.ClassName,
> E.ClassName);
>end;
> end;
>
>
> I tried the following, but got a compiler error on each one.
>
> -
> si.SetSlideName('006~sa.swf');
> { none of the following worked... }
> AssertException('Failing on 3', EUnknownSlideType, @si.SlideTypeDB);
> AssertException('Failing on 3', EUnknownSlideType, [EMAIL PROTECTED]);
> AssertException('Failing on 3', EUnknownSlideType, si.^SlideTypeDB);
> -
from the FPCUnit code:
class procedure AssertException(const AMessage: string; AExceptionClass:
ExceptClass; AMethod: TRunMethod); overload;
where
TRunMethod = procedure of object;
How is SlideTypeDB defined?
the correct way should be
AssertException('Failing on 3', EUnknownSlideType, @si.SlideTypeDB);
provided SlideTypeDB is a simple procedure with no parameters
and you are using
{$mode objfpc}
See the examples and the tests in the fcl/fpcunit directory on how to
use AssertException
Btw, there is an elegant way to test that a proper exception is raised
without using AssertException e.g. (from fcl/fpcunit/tests/asserttest.pp):
procedure TAssertTest.TestAssertNull;
var
obj: TObject;
begin
AssertNull(nil);
obj := TObject.Create;
try
AssertNull(obj);
except
on E: EAssertionFailedError do
begin
obj.Free;
Exit;
end;
end;
obj.Free;
Fail('failure: obj is not null!');
end;
Ciao,
Dean
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit testing Exceptions
Graeme Geldenhuys wrote: > > I think the problem is the SlideTypeDB which is a property! I will > change it to a standard function returning a string and try > @si.SlideTypeDB again. I guess it won't work, since assertException expects a procedure (TRunMethod = procedure of Object). I would create a procedure in the TTestCase class that would internaly access this property and pass this procedure instead. Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] data driven fpc unit tests
Vincent Snijders pravi:
> Hi,
>
> Suppose I have a component TMyDataProcessor with the following declaration:
>
> type
> TMyDataProcessor = class
> function process(const s: string) : string;
> end;
>
> Now I want to test it with different strings, but instead of hard coding
> them I put them in a inifile, so I can easily extend the test.
>
> [test 1]
> Input=Test
> Output=tEST
>
> [test 2]
> Input=1234
> Output=1234
>
> Now I write a fpcunit test that reads those tests input/output pairs
> from the ini file and executes them, see following (psuedo) code:
>
> procedure TMyTestCase.TestOutputs;
> var
> MyDataProcessor: TMyDataProcessor;
> begin
> for each section in the ini-file do begin
> MyDataProcessor := TMyDataProcessor.Create;
> Load Input, Load Output
> AssertEquals(SectionName + 'failed. ',
> Output, MyDataProcessor(Input));
> MyDataProcessor.Free;
> end;
> end;
>
> As far as I can see, the drawback of using this method is that if there
> is a failure in test 1, test 2 won't run at all. I will loose
> information about what could have been wrong.
>
> A solution would be to have different test methods for each test in the
> ini file, but I want to avoid that, because then adding a test, will
> mean that I need to change the code (after having created the data).
>
> Do you know how I can create data driven tests, so that it will display
> the test results of the second test, even if the first test fails.
>
> Vincent
Yes, there is an elegant solution. Joost has already asked me the same
question two months ago and I've prepared in that occasion a small
example of parameterized testcase that can be used for data driven
tests. The file with a short comment is attached.
HTH,
Dean
unit paramstests;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, fpcunit, testutils, testregistry;
type
{sometimes the different tests to run have a lot of common functionality
and they differ only for the presence of a different parameter, or a different
property of the class under test. To remove duplication and unnecessary code
there is the possibility to manually build a parameterized test suite, see the
following example that can be used as a template. The steps are simple, create
a new constructor for the testcase that has the parameters you'll want to pass
in the tests (in the following examples the parameters are a string input parameter
and an integer parameter to use for the testing of the results). In this constructor
you have to call the inherited CreateWithName constructor passing the name of the
actual test (in the following code the actual test is the DoTest procedure that
performs a simple test of the lenght function for the string passed as parameter to
the testcase). The parameters are then stored in some private fileds of the testcase.
Then you'll have to construct the test suite manually, see the
Suite class function, passing the constructor of the testcase with the wanted parameters.
Finally you'll add the constructed test to the test registry using the
GetTestRegistry.AddTest function in the initialization section.
In this example you'll see that four isolated different tests with the same name (DoTest)
will be created. The only drawback is in the fact that in case of failure it's not
immediate to see which test went wrong, as the tests have the same name. I suggest
to pass some information in the string description of the extended assertequals function
as a hint (in the DoTest example below I've inserted the parameter that was passed into the test)
The same parameterized testcase could be constructed by loading the parameters
from an xml file or from an ini file instead of storing them in the private fields
of the testcase. I leave this simple implementation as an exercise for the reader :)
{ TParameterizedTestCase }
TParameterizedTestCase = class(TTestCase)
private
aParam: string;
aOut: integer;
public
constructor Create(const aParameter: string; aOutput: integer); virtual; overload;
class function Suite: TTestSuite;
published
procedure DoTest;
end;
implementation
{ TParameterizedTestCase }
constructor TParameterizedTestCase.Create(const aParameter: string; aOutput: integer);
begin
//create a new DoTest testcase
inherited CreateWithName('DoTest');
//store the parameters
aParam := aParameter;
aOut := aOutput;
end;
class function TParameterizedTestCase.Suite: TTestSuite;
begin
//manually create the test suite
Result := TTestSuite.Create('TParameterizedTestCase');
Result.AddTest(TParameterizedTestCase.Create('', 0));
Result.AddTest(TParameterizedTestCase.Create('o', 1));
Result.AddTest(TParameterizedTestCase.Create('two', 3));
Result.A
Re: [fpc-pascal] presenting fpunit test results
Graeme Geldenhuys ha scritto: > Hi Vincent, > > Is is easy to add the list of executed tests (5 min job), but the > missing feature I believe you are looking for is the timing results. > Currently none of the fpcunit results contain timing values. This is > something I wanted to add long ago. The GUI TestRunner does show the > total time taken, but that is only displayed, not saved anywere. > > I will see how far I get with adding timing result today... if done, I > will submit a patch in fpc-devel. > > Regards, > - Graeme - At first sight, it seems that the methods StartTest and EndTest of the listeners are the right place where to place the code to do the timings. I guess the right approach would be to add an option at command line or otherwise to add the timing result. Same for the list of the run tests. Successive steps that are natural is the automation of fpcunit testing: a daemon that checks some svn directories periodically to find if there are changes in the tests, does the update, compiles the tests and publishes the tests (as an html page or sends the results to some registered users via e-mail, irc or othere means). I'm investigating how to best achieve this, I would use lnet for the networking part. Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Book....
bajrang soni ha scritto: > Hello. I just downloaded you Free Pascal software. I haven't programmed in > PASCAL for about 12 years. I am looking for a book or e-book that will > teach > me how to use the NEW pascal. What is the best reference material that you > can think of, consider me a beginner again! > > I need to get up to speed with pascal so that I can use the Delphi OOP > interface, and have a clue as to what I am doing. > > I suggest you to read this online chapter of Delphi in a Nutshell related to Delphi Object Model, most of it applies to Free Pascal as well: http://www.oreilly.com/catalog/delphi/chapter/ch02.html IMO It's the best short guide on the Pascal oop model. Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] THashedStringList vs TFPHashTable
Graeme Geldenhuys ha scritto:
> Hi,
>
> Is TFPHashTable the same as Delphi's THashedStringList?
>
> I am looking for a List class that can hold large amounts of objects
> with a ID string associated for quick lookups.
>
> Regards,
> - Graeme -
Yes, similar to a THashedStringList, but with a special implementation
The TFPHashTable was highly optimized with a lot of profiling, while
trying to achieve the ease of use through object orientation and ease of
maintainance. It's a hash table with a customizable hash function (to
achieve constant performance in searches), chaining is used as a
collision resolution scheme. Some statistics are also provided to be
able to choose the appropriate hash function and the appropriate hash
table size.
The difference in performance with respect to a simple ordered
TStringList is evident when more then 100.000 elements are added to the
container, the number of elements the container can hold is huge
(longword, and obviously ram size, is the limit :). I have another idea
to further improve the performance of searches and I'm planning to
further profile it in the next weeks to see if there are other speed gains.
Be aware that the version in 2.0.4 and before contains a bug that was
solved by Marco in 2.1.1. and merged in 2.0.5 (an AV if the insertion is
made after a clear) due to the use of longwords in the for cycles.
I'm attaching the fpcunit tests for you to see how to use it, and I'll
give you all the assistance that you need. I'll be glad to receive some
feedback as usual.
Regards,
Dean
unit testfphashtable;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, fpcunit, testutils, testregistry, contnrs;
type
{ TTestHtNode }
TTestHtNode = class(TTestCase)
published
procedure TestNodeCreation;
procedure TestKeyComparison;
end;
//inherited to be able to get access to protected methods
TMyHashTable = class(TFPHashTable)
end;
{ TTestFPHashTable }
TTestFPHashTable= class(TTestCase)
private
ht: TMyHashTable;
FSum: integer;
protected
procedure SetUp; override;
procedure TearDown; override;
procedure SumTest(Item: Pointer; const Key: string;
var Continue: Boolean);
procedure SumTestUntilFound100(Item: Pointer; const Key: string;
var Continue: Boolean);
published
procedure TestCreate;
procedure TestCreateWith;
procedure TestIsEmpty;
procedure TestAdd;
procedure TestAddSimpleSyntax;
procedure TestGetData;
procedure TestChainLength;
procedure TestDelete;
procedure TestClear;
procedure TestForEachCall;
procedure TestForEachCallBreak;
procedure TestHashTableGrow;
procedure TestVoidSlots;
//test for bug 0007292 fixed by marco guard all for loops with unsigned
//loopcounter against overflow (rev.4507)
procedure TestAddAfterClear;
end;
implementation
procedure TTestFPHashTable.SetUp;
begin
ht := TMyHashTable.CreateWith(9973, @RSHash);
AssertEquals(12289, ht.HashTableSize);
end;
procedure TTestFPHashTable.TearDown;
begin
ht.Free;
end;
procedure TTestFPHashTable.TestAdd;
begin
ht.Add('1', pointer(1));
ht.Add('2', pointer(2));
ht.Add('nil', nil);
AssertEquals('wrong number of items', 3, ht.Count);
end;
procedure TTestFPHashTable.TestAddSimpleSyntax;
begin
ht['1'] := pointer(1);
ht['2'] := pointer(2);
ht['nil'] := nil;
AssertEquals('wrong number of items', 3, ht.Count);
end;
procedure TTestFPHashTable.TestGetData;
var
i: integer;
begin
for i := 0 to do
ht.Add(intToStr(i), pointer(i));
AssertEquals(1, ht.Count);
for i := 0 to do
AssertEquals(i, integer(ht[PChar(IntToStr(i))]));
for i := downto 0 do
AssertEquals(i, integer(ht[PChar(IntToStr(i))]));
end;
procedure TTestFPHashTable.TestChainLength;
var
i: integer;
sum: int64;
begin
sum := 0;
for i := 0 to do
ht.Add(intToStr(i), pointer(i));
AssertEquals(1, ht.Count);
for i := 0 to ht.HashTableSize-1 do
if Assigned(ht.HashTable[i]) then
Sum := Sum + ht.ChainLength(i);
AssertEquals(1, sum);
end;
procedure TTestFPHashTable.TestDelete;
var
i: DWord;
begin
for i := 0 to do
ht.Add(intToStr(i), pointer(i));
ht.Delete('994');
AssertEquals('Wrong number of items after delete', , ht.Count);
AssertNull('Item not deleted', ht.Find('994'));
end;
procedure TTestFPHashTable.TestClear;
var
i: integer;
begin
for i := 0 to do
ht.Add(intToStr(i), pointer(i));
ht.Clear;
AssertTrue('container not empty', ht.IsEmpty);
end;
procedure TTestFPHashTable.TestHashTableGrow;
var
i: integer;
begin
for i := 0 to do
ht.Add(intToStr(i), pointer(i));
ht.HashTableSize := ht.HashTableSize + 1;
AssertEquals(24593, ht.HashTableSize);
AssertEquals(1, ht.Count);
Re: [fpc-pascal] THashedStringList vs TFPHashTable
Graeme Geldenhuys ha scritto: > Thanks to all that replied. The string that is going to be stored in > the List (with associated object) is a GUID string, so is very random > by nature. Would this have any negative affects in the hash table? > > I will try it out anyway, I can always swap the internal list out if > needed. What I am creating is a Flyweight (design pattern) to store > all common objecs I use. I will be fetching the objects based on the > OID (GUID) string. It's a typical use. Choose an appropriate HashTableSize when creating the container (approx.the number of the elements you are going to store or more), you can test it with different hash functions and see through the statistics which one is better (the longer the chains i.e. more void slots, the longer the fetch times). Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpUnit - AssertEquals gives Access violation
Graeme Geldenhuys ha scritto: > Here is the backtrace. I removed all other Assert tests, so only the > one that causes the problem is executed. > > What is strange though, is that I created a new test that only creates > the object and then tests the ObjectState. It it works, but all the > other actual tests don't. I hate such problems! :-) > > Graeme. > > > -- Start --- > [New Thread -1216787536 (LWP 20619)] > [Switching to Thread -1213515552 (LWP 20607)] > > Breakpoint 1, 0x0805f036 in fpc_raiseexception () > (gdb) bt > #0 0x0805f036 in fpc_raiseexception () > #1 0x082189d9 in FPCUNIT_TASSERT_$__FAIL$ANSISTRING () > #2 0xb7f04ac0 in ?? () > #3 0xb7a69200 in ?? () > #4 0x082189ff in FPCUNIT_TASSERT_$__ASSERTTRUE$ANSISTRING$BOOLEAN () > #5 0xb7f04ac0 in ?? () > #6 0x08218b45 in > FPCUNIT_TASSERT_$__ASSERTEQUALS$ANSISTRING$ANSISTRING$ANSISTRING () > #7 0x080a0202 in TNODEDATATEST__ASSERTEQUALS (PMESSAGE=0x8350cf0, >PEXPECTED=POSDELETED, PACTUAL=POSCLEAN, this=0xb7a77a68) >at NodeData_test.pas:89 > #8 0x080a1cb7 in TNODEDATATEST__TESTNODECOMPOUND_SAVE2 (this=0xb7a77a68) >at NodeData_test.pas:408 > #9 0x0821abf1 in FPCUNIT_TTESTCASE_$__RUNTEST () > #10 0x0821ab38 in FPCUNIT_TTESTCASE_$__RUNBARE () > #11 0x0821ba67 in FPCUNIT_PROTECTTEST$TTEST$TTESTRESULT () > #12 0x0821bb61 in FPCUNIT_TTESTRESULT_$__RUNPROTECTED$TTEST$TPROTECT () > #13 0x0821ba9e in FPCUNIT_TTESTRESULT_$__RUN$TTESTCASE () > #14 0xb7a77a68 in ?? () > #15 0xb7a7cb68 in ?? () > #16 0x0821aaeb in FPCUNIT_TTESTCASE_$__RUN$TTESTRESULT () > #17 0x0821b4f1 in FPCUNIT_TTESTSUITE_$__RUNTEST$TTEST$TTESTRESULT () > #18 0x083ee660 in _$FPCUNIT$_Ld19 () > ---Type to continue, or q to quit--- > #19 0x0821b4cb in FPCUNIT_TTESTSUITE_$__RUN$TTESTRESULT () > #20 0x0007 in ?? () > #21 0xb7a7cb68 in ?? () > #22 0xb7a77808 in ?? () > #23 0x0000 in ?? () > (gdb) > Hmm, no idea where the problem is, can you send me the example that shows the av, maybe with the code I can find it. Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implementing a true Singleton - Can we decrease the visibility of a method?
>> Try this. >> http://bdn.borland.com/article/22576 NewInstance/FreeInstance is what I would have recommended as well. > Maybe we should include an implementation in FPC by default ? How ? The article works as-is AFAIK. Btw, I think singletons are nonsense too. Why is a global variable evil, and a singleton class not ? You are right, beware of singletons. Being a simple pattern to implement it's often misused and sometimes creates more problems than it solves, it's a global variable after all, and you should put an extra effort to try to avoid it as you would avoid a global variable. It was one of the things I've learnt through unit testing, using a singleton breaks the independency between tests, because the singleton carries state with it that lasts as long as the program runs. In this case thinking about how to make tests independent of each other and trying to introduce a mock object for the singleton, you can get rid of it in a lot of cases. The best thing is usually to think about how we can substitute a singleton in the client class with a parameter in the constructor of the client class. See this article for further explanation: http://www-128.ibm.com/developerworks/library/co-single.html Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Graeme, I spoke to Dean the other day and he mentioned a new update for FPCUnit will be sumbitted shortly. I didn't want to start on the new XSLT stylesheet before I know what format the XML is in. Dean, if you can confirm that the new xml format with nested test suits are still as is, then I'll go ahead and modify the XSLT file. Vincent produced the new results.xml example with the new report writer: http://www.hu.freepascal.org/lazarus/testresults/results.xml (he already added the missing xsl tag ) The new writer is this: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/fcl/fpcunit/xmltestreport.pp?rev=6311&view=markup There's a new structure for the fpcunit reports, descending from TCustomResultsWriter. There are two other report writers for text and latex output (you can find an example of the two other output formats in fpcunit/example_output directory, the pdf is produced using pdflatex from the latex output). Note that we moved the essential fpcunit units to fcl/inc, the reports and other utils remain in the fpcunit directory. Ciao, Dean Regards, - Graeme - On 2/3/07, Vincent Snijders <[EMAIL PROTECTED]> wrote: > Hi, > > Dean Zobec created a new xmlreportwriter for fpcunit. Among others it > supports nested test suites. Does anybody have a stylesheet for showing > such a report. Maybe somebody is willing to create one. > > Examples of the old xml format+ style sheet (slightly modified): > http://www.hu.freepascal.org/lazarus/testresults/monitor.xml > > Example of the new xml format: > http://www.hu.freepascal.org/lazarus/testresults/results.xml > > Vincent > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New stylesheet for fpcunit xml reports
Graeme, Ok, I'll bite.. ;-) I spoke to Dean the other day and he mentioned a new update for FPCUnit will be sumbitted shortly. I didn't want to start on the new XSLT stylesheet before I know what format the XML is in. Dean, if you can confirm that the new xml format with nested test suits are still as is, then I'll go ahead and modify the XSLT file. I think a treeview layout is a way to go. Googling around I've found a link to a nice article, hope it's of any help: http://rollerjm.free.fr/pro/Treeview/Treeview.html Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sqldb firebird on linux can't find client lib
Michael Van Canneyt pravi:
>
> On Thu, 15 Feb 2007, Bisma Jayadi wrote:
>
>>> Run your application under 'strace' and send me the output, please.
>>> (Zip, please, because it can be rather big)
>> Done. Please check your email. I've made the program to the most simplest
>> shape just to produce the error, so it isn't too big and hopefully easier to
>> analyze. For the help, I thank you in advance.
>
>>From the strace, you can see that it does find the library:
>
> open("/usr/lib/libgds.so", O_RDONLY)= 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\271"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0555, st_size=548504, ...}) = 0
> old_mmap(NULL, 585172, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)=
> 0xee4000
> old_mmap(0xf5a000, 65536, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x76000) = 0xf5a000
> old_mmap(0xf6a000, 36308,
> PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf6a000
> close(3)= 0
>
> The fact that it still reports it as 'not loaded', I conclude that the
> dlopen operation failed. Why this would be so I cannot say.
> Seems like some version incompatibility, because it again tries to load libm
> etc, when it has already loaded it.
It may be a firebird client installation problem. Last week I tried to
do a client-only installation, by installing on the client machine only
the relevant libs and making the softlinks as explained in the Firebird
docs. But I was not able to connect with sqldb. Then I did a full
Firebird install and then the connection was ok.
Dean.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reduce size in binary generated by ppc
Jose Pascual pravi: > Hi everyone, > > How is it possible to reduce the size for binary generated by ppc? > http://wiki.freepascal.org/Size_Matters Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit: TestSuiteName vs TestName
Graeme, > Hi, > > When would you use TestSuiteName and when TestName? TestSuiteName is the name of the TestSuite (parent) that contains the Test > > For example, the following I think is wrong. > > constructor TTestSuite.Create(AName: string); > begin > Create(); > FName := AName; > end; > > Shouldn't this set the FTestSuiteName field? No, FTestSuiteName is set only when the Suite is added to another TestSuite: we have procedure TTestSuite.AddTest(ATest: TTest); begin FTests.Add(ATest); if ATest.TestSuiteName = '' then ATest.TestSuiteName := Self.TestName; end; The ATest parameter can be a TTestCase or a TTestSuite > Now if I do a TestSuite.TestSuiteName it doesn't return FName, instead > it returns FTestSuiteName. If I do a TestSuit.TestName it returns the > FName. > > This problem seems to be confirmed with the following code: > > constructor TTestSuite.Create(AClass: TClass; AName: string); > begin > Create(AClass); > FName := AName; > end; > > > This is getting very confusing. When are we supposed to use > TestSuiteName and when do we use TestName? > > > For example in DUnit you can register a test as follows: > RegisterTest(cSuiteNameNonPersistentTests, ATestCaseClass.Suite); FSuiteName is handled automatically when the TTest descendent is added to a TestSuite, you don't have to set it manually. > So if I want to implement this in FPCUnit, what name am I supposed to set? > > Maybe I'm just getting confused with the difference between TTest, > TTestCase and TTestSuite. I go read some more on this in the DUnit web > page (do we have FPCUnit docs explaining this?). FPCUnit has a different structure then DUnit, is a literal port of the JUnit test framework, with only some changes that were required to adapt the Java code (callbacks instead of inner classes in some places iirc). TTest is an abstract class, TTestSuite is a composite pattern. Just look at the JUnit documentation, here you can find a UML diagram: http://junit.sourceforge.net/doc/cookstour/cookstour.htm and there is a good chapter available as an MIT Lecture on OOP and patterns that takes the JUnit framework as a Case Study: http://courses.csail.mit.edu/6.170/old-www/2001-Fall/lectures/lecture-17.pdf I choose to adhere strictly to the JUnit framework as it was a standard when the FPCUnit port was created, and no additional documentation of the framework was needed (you could always refer to the JUnit documentation and practice, a lot of articles and books were written on the subject). Still, it's not a good excuse for lack of documentation :) Regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit: TestSuiteName vs TestName
Graeme Geldenhuys pravi: > Looking into the DUnit code I found the reason for passing in the > name. It's actually a Suite Path used to automatically create > TTestSuites for you so you can better group you tests case in a > hierarchy. You would use it if you don't want the registered test > case to appear in a top level node (like in the GUI Runner). Yes, the registration unit in FPCUnit is very simple, I've actually included it as an example on how to add the test suites more than a set of utility classes. In fact you get the root test suite through GetTestRegistry function and then you add any hierarchy you wish just by creating other suites and building the tree. So your unit is very handy for this and spares some typing. > I have implemented the same functionality for FPCUnit (a overloaded > RegisterTest method) today. See my other message to this mailing > list. I'll create a patch for it tomorrow and see if it will make it > into 2.2 branch but I doubt - which will be a pitty as it is very > useful and helps a lot in a huge test suite like tiOPF has. > Yes, if it wasn't for your huge test suite, FPCUnit would not have been improved. The first time I've heard from you, some two years ago I didn't even believe it could handle such a suite gracefully. There is still many improvements that can be made, but my spare time is quite scarce lately. I'm waiting for my vacations :) > DUnit is also based on JUnit. They just followed the path using > Interfaces instead of abstract classes. In the end they are very > similar I think. I agree, the differences are not many, and not important, except for the assert methods that are class methods in JUnit and FPCUnit. > >> TTest is an abstract class, TTestSuite is a composite pattern. Just look >> at the JUnit documentation, here you can find a UML diagram: > > Thanks, I'll take a look at those links. I'm sure they will come in handy. You need them if you want to understand the internals. JUnit is a live demonstration that flexibility in OOP design leads to code that is very difficult to understand, due to the many indirections. But I guess in this case it's justified by the fact that the framework had to be also easy to use and had to spare on typing by the end user. Only when I wrote myself the framework in pascal, following the java code, I was able to understand it completely (and still I'm convinced that after so much refactoring on the junit side, some indirections were redundant). regards, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit: TestSuiteName vs TestName
Michael Van Canneyt pravi: > > The good news is that fpcunit is scheduled for documentation after fcl-base > and before fcl-db. The bad news is that there are still 12 units to be > documented in fcl-base. Which is about 1/3 of the total number of units > in fcl-base. > > We'll get there. Slowly but surely. I had no doubt. It's a good news for me, as there's still hope I'll be able to help then! :) Thank you, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcunit documentation?
Tom Verhoeff pravi: > I know FreePascal includes the fpcunit unit testing framework > (the compiler knows where to find it), but I can't seem to find any > documentation via the regular www.freepascal.org, or the fpc wiki, > or on the lazarus site? > > Michael's fpcunit.pdf seems hidden. Google tells me it is here > > <http://www.freepascal.org/docs-html/fpcunit.pdf> > > but that directory does not list it. > > That is a pity. > > Can someone educate me (or update the site)? > > Is there any more up-to-date documentation. I know some people > enhanced fpcunit after Michael's article from 9 October 2005. > > Tom I can send you an article I wrote about fpcunit two years ago but I never had time to rewrite with some more interesting examples of test driven development. The overall functionality has not changed at all since that, and the article is a good tutorial about unit testing using the fpcunit framework. Anyway, just ask here if you have specific questions about fpcunit and well'answer you as always. Thank you, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RE: fpc-pascal Digest, Vol 34, Issue 53
> No, it won't, "test" here refers to the function result variable. Is that the correct behaviour? I thought scope would be applied outwards so, first it would look at local procedures, then methods of the same class and lastly global routines. Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Specifying a Interface type via $Interfaces
2007/10/11, Cesar Romero <[EMAIL PROTECTED]>: > Graeme, > > Hi, > > > > > Hi > > I want to start learning the use of Interfaces. It's a language > > feature I have by-passing for some time now. From what I have read > > this seems to be a handy language feature to learn. > > > > In the FPC documentation in mentions I can have COM or CORBA (Java) > > interface types. Could somebody please explain the difference. And > > why would I use one over the other? > > > Im not sure, but I think that the one difference is about time life: > COM uses ref count > CORBA should be somethink like garbage collection There's no garbage collection, you have to free the object instance explicitly with the Corba type of interfaces in FPC. Corba interfaces do not descend from IUnknown. Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Specifying a Interface type via $Interfaces
2007/10/11, Graeme Geldenhuys <[EMAIL PROTECTED]>: > Hi, > > I want to start learning the use of Interfaces. It's a language > feature I have by-passing for some time now. From what I have read > this seems to be a handy language feature to learn. > > In the FPC documentation in mentions I can have COM or CORBA (Java) > interface types. Could somebody please explain the difference. And > why would I use one over the other? Corba interfaces are not reference counted as they don't descend from IUnknown For a good tutorial about the reasons to use interfaces from an OOP point of view see this chapter of Delphi in a Nutshell by By Ray Lischner: http://www.oreilly.com/catalog/delphi/chapter/ch02.html In particular see this explanation: Quoting: "The most important use of interfaces is to separate type inheritance from class inheritance. Class inheritance is an effective tool for code reuse. A derived class easily inherits the fields, methods, and properties of a base class, and thereby avoids reimplementing common methods. In a strongly typed language, such as Delphi, the compiler treats a class as a type, and therefore class inheritance becomes synonymous with type inheritance. In the best of all possible worlds, though, types and classes are entirely separate. Textbooks on object-oriented programming often describe an inheritance relationship as an "is-a" relationship, for example, a TSavingsAccount "is-a" TAccount. You can see the same idea in Delphi's is operator, where you test whether an Account variable is TSavingsAccount. Outside of textbook examples, though, simple is-a relationships break down. A square is a rectangle, but that doesn't mean you want to derive TSquare from TRectangle. A rectangle is a polygon, but you probably don't want to derive TRectangle from TPolygon. Class inheritance forces a derived class to store all the fields that are declared in the base class, but in this case, the derived class doesn't need that information. A TSquare object can get away with storing a single length for all of its sides. A TRectangle object, however, must store two lengths. A TPolygon object needs to store many sides and vertices. The solution is to separate the type inheritance (a square is a rectangle is a polygon) from class inheritance (class C inherits the fields and methods of class B, which inherits the fields and methods of class A). Use interfaces for type inheritance, so you can leave class inheritance to do what it does best: inheriting fields and methods. In other words, ISquare inherits from IRectangle, which inherits from IPolygon. The interfaces follow the "is-a" relationship. Entirely separate from the interfaces, the class TSquare implements ISquare, IRectangle, and IPolygon. TRectangle implements IRectangle and IPolygon." > > COM sounds very Windows specific, so should I rather use CORBA > interface types. All my software target multiple platforms. I mostly > develop under Linux though. No it's mainly a matter of reference counting > > > Anybody got some good links on information about Interfaces? I'm > looking for some nice tutorials if possible. I'll try to find some old links about articles I've read years ago. Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Specifying a Interface type via $Interfaces
2007/10/11, Graeme Geldenhuys <[EMAIL PROTECTED]>: > On 11/10/2007, Dean Zobec <[EMAIL PROTECTED]> wrote: > > > interface types. Could somebody please explain the difference. And > > > why would I use one over the other? > > Corba interfaces are not reference counted as they don't descend from > > IUnknown > > So other than that, COM interfaces and CORBA interfaces share the same > features? > As for reference counting - that just means that as soon as the > reference count for an Interfaces reaches zero, it gets automatically > freed? for a good example of refcounting interfaces you can take a look at the money.pp fpcunit example and the relative tests. fcl-fpcunit/src/exampletests/money.pp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Specifying a Interface type via $Interfaces
2007/10/11, Graeme Geldenhuys <[EMAIL PROTECTED]>: > On 11/10/2007, Dean Zobec <[EMAIL PROTECTED]> wrote: > > > interface types. Could somebody please explain the difference. And > > > why would I use one over the other? > > Corba interfaces are not reference counted as they don't descend from > > IUnknown > > So other than that, COM interfaces and CORBA interfaces share the same > features? yes IIRC > As for reference counting - that just means that as soon as the > reference count for an Interfaces reaches zero, it gets automatically > freed? yes, though you have to pay much attention to memory leaks and possible problems when dealing a lot with interfaces, memory leaks should be monitored closely. CORBA then rather treats them like classes - you can have no > other objects referencing the class, yet it stays in memory. You > always need to free it off manually. Yes, like dealing with normal objects. > > point of view see this chapter of Delphi in a Nutshell by By Ray > > Lischner: > > http://www.oreilly.com/catalog/delphi/chapter/ch02.html > > Thanks for the link and quote. It already makes more sense. Hopefully > more reading about the topic will strengthen the knowledge when to use > Interfaces and when to use Class Inheritance. > > > I'll try to find some old links about articles I've read years ago. > > That will be very much appreciated. Thanks. Time has deleted a lot of web links, funny how much data and knowledge gets lost when the webspace is gone. I'm sure I'll be able to find something shuffling from the old delphi CDs or papers. A good article about the use of interfaces in free pascal is really needed. I think interfaces are a very powerful oop feature. If only I had time :( regards, Dean > > Regards, > - Graeme - > > > ___ > fpGUI - a cross-platform Free Pascal GUI toolkit > http://opensoft.homeip.net/fpgui/ > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]class methods in FPC version 1.9.0
> Hmm, here it returns > > -bash-2.05b$ ./bugtest > TMyObject > -bash-2.05b$ > > with > > Free Pascal Compiler version 1.9.1 > > Compiler Date : 2003/11/11 > Compiler Target: i386 > > on FreeBSD > So it could be it that is already fixed after 1.9.0 Great, :-) One more question, where can I find the version 1.9.1 ? What would you suggest me as the best way to be up to date ? I just checked out the cvs tree, should I update it once in a while and build the compiler? Any instructions available? Thanks again to all of you at Free Pascal, you are great! Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]class methods in FPC version 1.9.0
> See also http://www.stack.nl/~marcov/buildfaq.pdf for some pointers about
> building the FPC cvs.
Thank you for the tutorial, it helped me a lot. It was exciting to see the
compiler building process on the screen :-) So now I have a 1.9.1 for i386
Linux!
I have encountered a problem when doing a "make all" from the cvs tree
(checked out yesterday) that maybe is worth mentioning:
when compiling pipes.pp i've got an error in pipes.inc
(/usr/local/src/fpc/devel/fpc/fcl/unix/pipes.inc)
got longint expected boolean
Uses
{$ifdef ver1_0}
Linux
{$else}
Unix
{$endif}
;
Function CreatePipeHandles (Var Inhandle,OutHandle : Longint) : Boolean;
begin
Result := AssignPipe (Inhandle,OutHandle);
end;
{
$Log: pipes.inc,v $
Revision 1.5 2002/09/07 15:15:29 peter
* old logs removed and tabs fixed
}
I did a simple typecast:
Result := Boolean(AssignPipe (Inhandle,OutHandle));
and all went well in the next "make all"
Hope I didn't broke something else with this typecast.
Thank you again for all the help. Hope to be able to make up some day with a
humble contribution to the project. :-)
Btw I was thinking about beginning a port of the JUnit testing framework to
Free Pascal, as I'm no longer feeling safe without a unit testing net when
programming. Could it be interesting? Or it's been already done?
Ciao, Dean
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]class methods in FPC version 1.9.0
> The typecast is incorrect. It should be > > Result:=(AssignPipe(..)<>-1); Thank you. > I'll fix this later this morning, thanks for reporting. It's a pleasure :-) Thank you for the fix. >Delphi port of JUnit called DUnit, but I doubt it will work, > it meddles too much with the internals of objects. I've used it for a year or so, the Juanco's DUnit http://dunit.sourceforge.net/ it's good but maybe too complicated and differs from the JUnit framework in some important parts to leverage the potential of Delphi against Java. I'm not quite sure of the real benefits. I think it misses the good idea of Assert class methods that makes it easy to use Mock Objects. Another more recent version is xUnit4Delphi, written more closely to the original design. And finally a visual testing suite written by a friend of mine, Mike Johnson http://www.bigattichouse.com/qtest.php, but I'm much more oriented towards a console testing framework. I'll try to study all of the designs more closely. Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]class methods in FPC version 1.9.0
> I am trying to port the DUnit test framework to fpc and lazarus, see for > more info > http://lazarus-ccr.sourceforge.net/index.php?wiki=DunitProject. I'll take a look > The testframework unit compiles I was able to compile it too, but I have still a lot of work to make it work I guess ;-) > and I don't see to many troubles with > the text test runner. yes that's the easy part > library a command line argument. I have to do some research to find out > to what level fpc supports libraries. From what I've seen in the first three days with fpc, I think you'll have no problems. :-) Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]problem linking with c
Hi,
i tried to link a c function but had some problems:
a simple example:
in file cwrite.c
#include
void writestringinc(void);
void writestringinc(void) {
puts("This string is written using c");
fflush( stdout );
}
compiled with c using
g++ -c cwrite.c
now, this is a test program in fpc:
Program testc;
{$linklib c}
{$L cwrite.o}
Procedure writestringinc; cdecl; external;
begin
writeln ('Written with Pascal');
writestringinc();
end.
both cwrite.o and testc.pp reside in the same directory.
compiling with fpc gives me this:
[EMAIL PROTECTED] c++progs]$ fpc testc.pp
Free Pascal Compiler version 1.9.1 [2003/11/14] for i386
Copyright (c) 1993-2002 by Florian Klaempfl
Target OS: Linux for i386
Compiling testc.pp
Linking testc
testc.o(.text+0x4a): In function `main':
: undefined reference to `writestringinc'
testc.pp(11,1) Error: Error while linking
Closing script ppas.sh
What am I doing wrong?
Another question: is fpc compatible with C++?
Thanks in advance,
Ciao, Dean
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]problem linking with c
Michalis and Peter, ok, now it works :-), thank you! > You can view generated object file with nm or objdump commands - e.g. call >nm cwrite.o > and you will see that cwrite.o does not contain 'writestringinc' Thank you for the complete explanation, I didn' know for this tools. You know, I'm coming from Delphi and Kylix, one of the 'click and run' newbies ;) and every day I'm discovering a new world. Merry Christmas, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]TObjectList.free
Alle 12:25, domenica 15 febbraio 2004, [EMAIL PROTECTED] ha scritto: > > > I fixed this. The problem was that the behaviour of Borland's TList > > changed > > > - it got (a lot!) slower. In older TList implementations TList.Clear > > didn't > I understand their reasons, but it's not so cool if you don't care about > this event and have a list of 1 elements. It's a serious performance > penalty in such case. It would have been better if this behaviour had been > optional (remember, it appeared only in later Delphi versions). As soon > as I figure out how, I will change the FPC implementation so this doesn't > happen unless really needed. I really appreciate that you noticed the problem. To avoid the problem and gain in speed in Delphi I was using a clone of TList without the notification mechanism. Indeed the way TObjectList was introduced with Delphi 5 was not a clever move IMHO. In that occasion the TList was changed to accomodate the need of the one and only descendant TObjectList, which is against any object-oriented design rule. And worse, as I see it, TObjectList should not be a descendant of TList at all. TList was not designed to be an ancestor class like TStrings for example. They would be better off creating TObjectList (derived from TObject and not TList) as a wrapper class around the TList. I'm happy I can count on you for things like that. The more I work with fpc, the more I like it. Thank you for the great work you are doing. Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]no refcounted interfaces
I've talked with some friends of mine about the use of Interface base classes without reference counting in Delphi like this type TNoRefCount = class(TObject, IUnknown) protected function QueryInterface(const IID:TGUID; out Obj):HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; end; function TNoRefCount.QueryInterface(const IID:TGUID; out Obj): HResult; begin if GetInterface(IID, Obj) then Result := 0 else Result := Windows.E_NoInterface; end; function TNoRefCount._AddRef: Integer; begin Result := -1 end; function TNoRefCount._Release: Integer; begin Result := -1 end; We are all experiencing the same kind of problems: 1) there's no easy way to obtain a TObject from an interface (whereas there's no particular reason not to have it. A solution proposed was to implement an AsObject method in all the interfaces used. 2) there's no FreeAndNil function that would free the interface and the object instance. It would be nice to be able to do something like this in an abstract factory: var MyRef: ISomeInterface; begin MyRef := SomeFactory.CreateObject as ISomeInterface; try ...use MyRef... finally MyRef.AsObject.Free; MyRef := nil; end; end; Any Idea of a solution in free pascal? Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Delphi "9" language features...
Matt Emson wrote: Exactly, which is why I prefer the idea Borland has gone for. The STL is not a good idea. Delphi doesn't have a decent containers library. TObjectList is derived from TList instead as being designed as a wrapper (if Borland had read the Danny Thorpe's book they would not implement it this way :-). TStringList is a cute class (I like it very much) and is an swiss army knife for Delphi, but nothing more, there are cases where other containers could do better. Where are Hash Tables, B-Trees, etc? A simple interface for lists is not an innovation IMHO. Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] problems with MethodAddress (objpas) fresh cvs build
I'm using some code in objpas to get the names and the addresses of published
methods. Lately, in the cvs build, I encountered some problems. See the
results of the MethodAddress function in the latest cvs build for example:
it cannot get the address of methods (it worked with previous versions):
program prova;
type
{$M+}
TTestCaseTest = class(TObject)
published
procedure TestSetUp;
procedure TestAsString;
end;
procedure TTestCaseTest.TestSetup;
begin
writeln('TestSetup');
end;
procedure TTestCaseTest.TestAsString;
begin
writeln('TestAsString');
end;
begin
writeln('Address of TestSetUp : ',
longint(TTestCaseTest.MethodAddress('TestSetUp')));
writeln('Address of TestAsString : ',
longint(TTestCaseTest.MethodAddress('TestAsString')));
end.
Architecture:
[EMAIL PROTECTED] dean]$ uname -rs
Linux 2.6.3-7mdk
Results:
[EMAIL PROTECTED] dean]$ cvs/fpc/compiler/ppc386 -Sd tmp/prova
Free Pascal Compiler version 1.9.5 [2004/10/17] for i386
Copyright (c) 1993-2004 by Florian Klaempfl
Target OS: Linux for i386
Compiling tmp/prova.pp
Linking tmp/prova
24 Lines compiled, 0.1 sec
[EMAIL PROTECTED] dean]$ tmp/prova
Address of TestSetUp : 0
Address of TestAsString : 0
[EMAIL PROTECTED] dean]$ /usr/lib/fpc/1.9.4/ppc386 -Sd tmp/prova
Free Pascal Compiler version 1.9.4 [2004/05/30] for i386
Copyright (c) 1993-2004 by Florian Klaempfl
Target OS: Linux for i386
Compiling tmp/prova.pp
Linking tmp/prova
24 Lines compiled, 0.2 sec
[EMAIL PROTECTED] dean]$ tmp/prova
Address of TestSetUp : 134582816
Address of TestAsString : 134582896
I'll try to investigate further to find the reason (any changes in the
management of the method table?), meanwhile, if someone has some ideas about
what's wrong with it, I'll be grateful for any suggestion
Regards,
Dean
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal soom will land in Italy!
Jilani Khaldi, > Hi All, > In the next issue of Linux&C n.42 (http://www.oltrelinux.com) there will > be the first article (Special) about Free Pascal (8 pages for this > article, never happened before with other cool languages) Good news, I've known a lot of fpc fans here in Italy (I'm from Trieste). > Linux&C is > the number one magazine in Italy dedicated to Linux with nearly 50.000 > readers monthly. I've read your articles on FirebirdSQL you wrote for Linux&C, very clear and well written. > I am looking for a cool application (already written or > to be written) to show to our readers (in the next articles) the power > and the elegance of Free Pascal for serious development. I agree with Florian, FPC itself! imho is sufficient to look at the fpc documentation to find enough examples of elegance and power. Anyway, a bunch of good Delphi libraries have been successfully ported to fpc (Synapse, ICS, Decal, Abbrevia,...), almost anything you can do with Delphi could be done in fpc as well. I've converted the EOS code (http://sourceforge.net/projects/camelos) to fpc in a couple of days with only minor changes from Delphi and translated the Junit core testing framework from Java in a day or too: http://camelos.sourceforge.net/fpcUnit.html , so, no doubt for me that FPC is mature for serious programming. If you need help for your article or you need a review, just ask (you can get in contact with me in private). Ciao, Dean Zobec ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] how to locate address of method name table (cvs build)
Using the recent cvs builds of the compiler I was unable to locate the address
of the method name table. Here is a test that works with version 1.9.4 but
does not work in 1.9.5 anymore:
program prova;
uses
classes;
type
{$M+}
TTestCaseTest = class(TObject)
published
procedure TestSetUp;
procedure TestAsString;
end;
procedure TTestCaseTest.TestSetup;
begin
writeln('TestSetup');
end;
procedure TTestCaseTest.TestAsString;
begin
writeln('TestAsString');
end;
function GetMethodNameTableAddress(AClass: TClass): Pointer;
type
TMethodNameRec = packed record
name : pshortstring;
addr : pointer;
end;
TMethodNameTable = packed record
count : dword;
entries : packed array[0..0] of TMethodNameRec;
end;
pMethodNameTable = ^TMethodNameTable;
var
methodTable : pMethodNameTable;
vmt: TClass;
begin
vmt := aClass;
if assigned(vmt) then
begin
methodTable := pMethodNameTable((Pointer(vmt) + vmtMethodTable)^);
Result := methodTable;
end;
end;
begin
writeln('Address of TestSetUp : ',
longint(TTestCaseTest.MethodAddress('TestSetUp')));
writeln('Address of TestAsString : ',
longint(TTestCaseTest.MethodAddress('TestAsString')));
writeln(Assigned(GetMethodNameTableAddress(TTestCaseTest)));
end.
The function GetMethodNameTableAddress allways returns nil. Any idea about how
to fix it?
Ciao,
Dean
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to locate address of method name table (cvs build)
Alle 16:03, domenica 24 ottobre 2004, Peter Vreman ha scritto: > At 17:55 22-10-2004, you wrote: > >Using the recent cvs builds of the compiler I was unable to locate the > >address > >of the method name table. Here is a test that works with version 1.9.4 but > >does not work in 1.9.5 anymore: > > It was a recently introduced bug, Fixed > > Peter Thank you for the prompt fix Peter. I've just rebuilt the compiler and it's all ok now. Ciao, Dean ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] memory leaks with com interfaces?
I have some problems with com interfaces (refcounted):
in this simple program heaptrc reports a memory leak even if the destructor
was correctly called:
{$mode objfpc}{$H+}
{$interfaces com}
program moneyleak;
type
IMoney = interface
['{AAD734A1-6F35-D911-9C73-C6AC7996EDD0}']
function Add(aMoney: IMoney): IMoney;
end;
TMoney = class(TInterfacedObject, IMoney)
private
FAmount: Int64;
FCurrencyUnit: string;
public
function Add(aMoney: IMoney): IMoney;
constructor Create(aAmount: int64; aCurrencyUnit: string);
destructor Destroy; override;
end;
function TMoney.Add(aMoney: IMoney): IMoney;
begin
Result := nil;
end;
constructor TMoney.Create(aAmount: int64; aCurrencyUnit: string);
begin
Inherited Create;
FAmount := aAmount;
FCurrencyUnit := aCurrencyUnit;
end;
destructor TMoney.Destroy;
begin
FCurrencyUnit := '';
writeln('Destroyed');
inherited Destroy;
end;
procedure TestLeak;
var
a: IMoney;
begin
a := TMoney.Create(12, 'EUR');
end;
begin
TestLeak;
end.
The compilation and the results:
[EMAIL PROTECTED] demo]$ fpc -gh -gl moneyleak.pp
Free Pascal Compiler version 1.9.5 [2004/10/24] for i386
Copyright (c) 1993-2004 by Florian Klaempfl
Target OS: Linux for i386
Compiling moneyleak.pp
Linking moneyleak
50 Lines compiled, 0.1 sec
[EMAIL PROTECTED] demo]$ ./moneyleak
Destroyed
Heap dump by heaptrc unit
1 memory blocks allocated : 32/32
0 memory blocks freed : 0/0
1 unfreed memory blocks : 32
True heap size : 557056 (16 used in System startup)
True free heap : 556944
Should be : 556952
Call trace for block $404C size 32
$08052F26
$08053922
$0805C456 TMONEY__CREATE, line 28 of moneyleak.pp
$0805C60C TESTLEAK, line 45 of moneyleak.pp
What am I doing wrong?
Thank you in advance for any help,
Regards,
Dean Zobec
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit testing framework for fpc
Michael Van Canneyt wrote: >>Where can I find it? >> >> > >It's included with FPC by default. Sources are in fcl/fpcunit. >Just include fpcunit in your source. See the examples for a console demo. > >Lazarus has a special package that allows you to create either a GUI or >a console test application. Compile and install lazfpcunit (or fpcunitlaz ?) > > to be more precise: the Lazarus package is in lazarus/components/fpcunit To install it you have to compile the package fpcunittestrunner.lpk and install the package lazarus/components/fpcunit/ide/fpcunitide.lpk Then you can create a new unit test application with the menu: File>New>Project>FPCUnit Application(or FPCUnit Console application) You can add a new test case template by selecting File>New>File>FPCUnit TestCase Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit article/tutorial online.
;s easier). It keeps my productivity stable even when the code is getting complex and it even helps me to isolate a reported bug in my code. Now I'm really having fun in coding. Hoping the answers are no, yes, no yes, yes, yes. The answer was quite more articulated and subjective :) there's no use in saying that unit testing is good for everyone. If the developer enjoys doing it, as I do, it's a good thing in my opinion. But I'm convinced that there's not one true way of writing good quality software, every one has to find the one best suited to his needs. Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit article/tutorial online.
Alan Mead ha scritto: Hello, The Editor of Toolbox Magazine has allowed me to put an article about FPCUnit online. [...] I found the article and the discussion on this list very helpful. Thanks for writing it and making it available. These are probably stupid questions, but all the examples I've read about use silly tests like 1+1=2 or checking that a list is empty. I'm having trouble seeing how I would write tests for my code. Take a look at some real world tests to see how they were written and then try to write yours to make practice. When writing test you should learn to identify the border conditions (strange cases that could give problems to your code), you know, bugs generally live in the edges :) like wrong input values, badly formatted data, values in excess of any reasonable expectation, empty of missing values (null, 0, ""), unordered values passed in input where the routine expects ordered items ... Ask yourself some questions as Does the value conform to my expected format? Is the value within a reasonable range of values? Is something happening in the right order in time? Are there exactly enough parameters? Some methods can be tested by applying their inverse: like the result of y=sqrt(x) could be tested applying y^2 to see if it equals to x. To see if an item was deleted from a list you perform a search after the deletion. For some examples of more complex unit tests with fpcunit you can look at the tests we wrote for the EOS framework: a sort of simple xml object persistence framework that automatically saves the published properties of objects and complex structures of objects to xml and automatically recreates the objects from the xml text (it was used to transport those objects over http from the server to the client and vice versa) Here you can find the code: http://cvs.sourceforge.net/viewcvs.py/camelos/EOS/fpcEOS/ and here are the related tests: http://cvs.sourceforge.net/viewcvs.py/camelos/EOS/fpcEOS/tests/ I have an ugly little hack that reads some logged data and counts certain things. The code is fragile so I'd love to add unit testing... But the code is mostly procedures for reading and parsing the log data. Would the unit tests create fake input and compare it to known output? (How do I fake reading data from disk?) For that matter, how do I test the data-reading procedures? (Write fake data and then see if the routine reads it correctly?) Yes exactly, obviously you'll also write strange faked data to see how your procedures and functions respond. It is much more difficult to write tests when all the code is already written, so begin with writing tests for low level simple methods first and when they pass you can begin to test higher level methods. This is the natural way of proceeding when you write tests at the same time that you write the code . You'll see that the tests you'll find here http://cvs.sourceforge.net/viewcvs.py/camelos/EOS/fpcEOS/tests/ are testing functionality very similar to your case hope you'll find them useful. Some where even written over legacy code like in your case. If you have specific questions you can even write me in private mail, I'll try to help you if I can (here we would be off-topic). Or, I've been messing around with SQLite... to add unit tests for this code, would I need to create fake databases? And what about the GUI code? How can that be tested? This are two of the cases where testing is most difficult. Some suggest writing mock objects that mock the real behaviour http://www.mockobjects.com . But is generally difficult to implement in case of databases. For the GUI I'm against testing it using unit testing, it's a waste of time. If you should need a book to learn more about the testing techniques from a very practical point of view, with many examples, I suggest this: Pragmatic Unit Testing in Java with JUnit by Andy Hunt and Dave Thomas Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus and FPC integration
Agustin Barto wrote: What bad designs does it impose the programmer?? I have a big interest to know because I like to make a as reusable as possible code. Are you talking about the form designer?? Software that's designed starting from the user interface to the behavioral parts of the program leads to some pretty nasty design bias. We usually call this the "visual basic syndrome" :) It's true, but you don't have to use a RAD approach if you don't want to :) The RAD approach is handy for prototyping or for the quick development of small utilities. When it comes to bigger projects, to avoid the inclusion of the domain code in the GUI interface code, that leads to unmaintainable projects, you can choose a different design. One approach is the use of the RTTI - aware controls to link them to the published properties of your Business Objects or, better, use a more complex but more flexible bridge pattern to decouple the link between the business objects and the GUI without even using the RTTI metadata. You only need a powerful editor to be productive in this case, and Lazarus has a indeed a good one. You told us about the lack of some refactoring tools: Lazarus has a wonderful object oriented framework for writing plugins, so we all can feel free to contribute to add them. It's not a Lazarus limit imho. Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for..in loops?
Lukas Gebauer wrote: foreach ... in ... do adds no additional abstraction layer. I consider foreach usefull if it allows to create own iterators which are as fast as walking a linked list with p:=p^.next; Especially since it then allows e.g. to write iterators with data prefetching. Just my two cents: For-in loops is standard part of Delphi-2006 pascal language. (Not only for .NET, it is for Win32 too!) I think, if Freepascal wish to stay Delphi compatible, then is good idea to implement this features too. Look to next Pascal language enhancements in Delphi-2006... (like operator overloads or class variables...) I don't see it as a high priority. It takes some minutes to change the code implemented with a for-in loop if it's needed. What does Free Pascal need is a good type safe containers library and probably this is the reason why the compiler team is concentrated on the implementation of generics: provide strong type safety on containers in the spirit of pascal. And using a containers library you can allways use iterators, it's not a language feature. I'm happy that the compiler guys do not waste their precious time over sintactic sugar issues. Look to next Pascal language enhancements in Delphi-2006... (like operator overloads or class variables...) we already have them in free pascal for a couple of years iirc and I've never used them. Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] for..in loops?
Marco van de Voort wrote: Lukas Gebauer wrote: Look to next Pascal language enhancements in Delphi-2006... (like operator overloads or class variables...) we already have them in free pascal for a couple of years iirc and I've never used them. That's because they are quite limited if you have dynamic, non garbage collected objects. For .NET that is no problem, since the objects are GCed, and for C++ they are static. But for native Delphi, there is no good solution to do OO without a thick helper layer. I remember I've successfully used them with refcounted interfaces in a demo see http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/fcl/fpcunit/exampletests/money.pp but still doing a + b or a.add(b) it's not that different and maybe the second is clearer; Ciao, Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
