Re: [fpc-pascal] Memoryleak in SQLite3db.TSqlite?
Am 11.03.2013 16:27, schrieb Michael Van Canneyt: Can anybody apply this patch to the trunk? Done. Thank you. Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
Ewald wrote: Once upon a time, Mark Morgan Lloyd said: No, because the elements in a set are dictated by their position. A set that can contain anything between 0 and 256 elements occupies 8 bytes in memory with the (bit representing the) 0 element at one end and the (bit representing the) 256 element at the other, a set to contain up to (say) 257 elements would require more space and that's not supported. Probably a typo, but 8 bit * 8 bytes = 64 elements. So I suppose you mean `[...] occupies 32 bytes in memory [...]`? Just so nobody gets confused :-) Definitely a typo, or rather the fingers running ahead of the brain. I was thinking of various compilers I'd come across that ordered things differently and how best to not imply that [0] invariably mapped onto $0001. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting C macro
Flávio Etrusco schreef op 12 mrt '13: On 3/11/13, Darius Blaszyk dhkblas...@zeelandnet.nl wrote: I'm stuck porting a macro from C. Below is the original define. The part I'm struggeling with is the right most part after the - sign. #define GETNEXT(x) ((LList *)(((char *) x) - ((char *) (((LList *)0)^.next Does anyone know what is meant with the define? Obviously LList is a linked list struct that has a prev and next variable. But what does the and 0 mean? Appreciate any help. Regards, Darius AFAICS they mean address and nil, respectively, so that part will return the offset of next inside and item of LList. -Flávio So here is what I made based on your and Henry's mail. However still it does not seem to work, although other ported code might be at fault of course :) //#define GETNEXT(x) ((LList *)(((char *) x) - ((char *) (((LList *)0)-.next function GETNEXT(x: pLList): pLList; inline; begin exit(pLList(pchar(x) - pchar(pLList(nil)^.next))); end; And let LList be declared as: LList = record len: integer; next, prev: pLList; name: PChar; nextname: PChar; flag: integer; end; Then I still don't understand what this does: if list^.next nil then list^.nextname := GETNEXT(list^.next)^.name; Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fcl-xml
Hi, working with fcl-xml some questions came together. Every hint is appreciated. 1. No matter what I do and which (short valid) xml file I use - getElementById is always nil (tested with trunk and latest stable 2.6.2) and the same applies to TXMLDocument.IDs. I tried with ReadXMLFile and TDOMParser with different options - but the result is always the same. Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? 2. Is there a way to tell WriteXMLFile *not* to use indentation? 3. What is the state of XPath? The readme says 'Should be fairly completed' - can I assume it works for simple tasks? Many thanks for any hint, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] JSON me - blind again?
Hi list,
(FPC 2.6.0 or trunk)
Been fiddling a bit too long and strongly suspect PEBKAC/PICNIC (and my
seemingly perennial refusal to adapt to Object Pascal's way of dealing
with object references).
Thanks for your suggestions!
See the === marks below
var
CurrentPage: integer;
RequestResult: THttpResult;
CommJSON: TJSONObject;
begin
result:=INVALIDID;
CommJSON:=TJSONObject.Create;
try
try
// do an HTTP request and get a JSONData back.
//
RequestResult:=HttpRequestWithData(CommJSON,FCGIURL+'document/',rmPost);
if RequestResult.Code200 then
begin
//snip error handling
end
else
begin
//=== the line below works - so CommJSON is a valid object, right?
if Assigned(CommJSON) then
begin
// however, the next line gives a runerror(210): no vmt found
if (CommJSON.JSONType=jtObject) then
begin
if (CommJSON.IndexOfName('documentid',false)-1) then
result:=CommJSON.Integers['documentid'];
end;
end;
end;
I'm not confident about
function HttpRequestWithData(AData: TJSONData; const AUrl: string;
const AMethod: TRequestMethod; const AContentType: string): THttpResult;
...
FreeAndNil(AData);
VData.Position := 0;
VParser := TJSONParser.Create(VData);
try
try
AData := VParser.Parse;
// so it destroys the object passed to it and recreates it
// but AData.JSONType does seem to be JSONObject...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] JSON me - blind again?
On Tue, 12 Mar 2013, Reinier Olislagers wrote:
Hi list,
(FPC 2.6.0 or trunk)
Been fiddling a bit too long and strongly suspect PEBKAC/PICNIC (and my
seemingly perennial refusal to adapt to Object Pascal's way of dealing
with object references).
Thanks for your suggestions!
See the === marks below
var
CurrentPage: integer;
RequestResult: THttpResult;
CommJSON: TJSONObject;
begin
result:=INVALIDID;
CommJSON:=TJSONObject.Create;
try
try
// do an HTTP request and get a JSONData back.
//
RequestResult:=HttpRequestWithData(CommJSON,FCGIURL+'document/',rmPost);
if RequestResult.Code200 then
begin
//snip error handling
end
else
begin
//=== the line below works - so CommJSON is a valid object, right?
if Assigned(CommJSON) then
It is assigned, but not necessarily valid. If you freed CommJSON but did not
nil it, it is still'assigned'.
begin
// however, the next line gives a runerror(210): no vmt found
if (CommJSON.JSONType=jtObject) then
begin
if (CommJSON.IndexOfName('documentid',false)-1) then
result:=CommJSON.Integers['documentid'];
end;
end;
end;
I'm not confident about
function HttpRequestWithData(AData: TJSONData; const AUrl: string;
const AMethod: TRequestMethod; const AContentType: string): THttpResult;
Ehm. This must be
function HttpRequestWithData(OUT AData: TJSONData; const AUrl: string;
const AMethod: TRequestMethod; const AContentType: string): THttpResult;
Because you are passing BACK a reference!
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013, dev.d...@gmail.com wrote: Hi, working with fcl-xml some questions came together. Every hint is appreciated. 1. No matter what I do and which (short valid) xml file I use - getElementById is always nil (tested with trunk and latest stable 2.6.2) and the same applies to TXMLDocument.IDs. I tried with ReadXMLFile and TDOMParser with different options - but the result is always the same. Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? It should be filled ? The XMLTextReader creates the map, and passes it on to the final document. 2. Is there a way to tell WriteXMLFile *not* to use indentation? No. 3. What is the state of XPath? The readme says 'Should be fairly completed' - can I assume it works for simple tasks? This I do not know. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013 10:39:35 +0100 dev.d...@gmail.com wrote: Hi, working with fcl-xml some questions came together. Every hint is appreciated. 1. No matter what I do and which (short valid) xml file I use - getElementById is always nil (tested with trunk and latest stable 2.6.2) and the same applies to TXMLDocument.IDs. I tried with ReadXMLFile and TDOMParser with different options - but the result is always the same. Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? It seems to be started, but not finished. I have not written it, just looked at the implementation. 2. Is there a way to tell WriteXMLFile *not* to use indentation? No. 3. What is the state of XPath? The readme says 'Should be fairly completed' - can I assume it works for simple tasks? Yes. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013 11:52:06 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: [...] Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? It should be filled ? The XMLTextReader creates the map, and passes it on to the final document. Normally getElementById should work in the DOM, not only when reading a xml document. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013, Mattias Gaertner wrote: On Tue, 12 Mar 2013 11:52:06 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: [...] Is getElementById supposed to work properly or is it something that needs to be implemented? Trying to understand what the parser does (not that easy), I got the feeling that no Hashtable for the IDs is created - can someone with more insight comment on that? It should be filled ? The XMLTextReader creates the map, and passes it on to the final document. Normally getElementById should work in the DOM, not only when reading a xml document. Correct, but since OP was using the read methods, it should work ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: JSON me - blind again?
On 12-3-2013 11:44, Michael Van Canneyt wrote: Thanks for the help, Michael. On Tue, 12 Mar 2013, Reinier Olislagers wrote: //=== the line below works - so CommJSON is a valid object, right? if Assigned(CommJSON) then It is assigned, but not necessarily valid. If you freed CommJSON but did not nil it, it is still'assigned'. Understood. Then it has a pointer pointing to whatever (probably the object's former memory location). I'm not confident about function HttpRequestWithData(AData: TJSONData; const AUrl: string; const AMethod: TRequestMethod; const AContentType: string): THttpResult; Ehm. This must be function HttpRequestWithData(OUT AData: TJSONData; const AUrl: string; const AMethod: TRequestMethod; const AContentType: string): THttpResult; Because you are passing BACK a reference! Sorry. What I hadn't attached is the first part where the request is built up: if Assigned(AData) then begin VHttp.RequestBody := TMemoryStream.Create; VJSON := AData.AsJSON; VHttp.RequestBody.Write(Pointer(VJSON)^, Length(VJSON)); VHttp.RequestBody.Position := 0; end; ... changing the parameter to var... function HttpRequestWithData(var AData: TJSONData; const AUrl: string; const AMethod: TRequestMethod; const AContentType: string): THttpResult; ... and changing the calling objects from TJSONObject to TJSONData seemed to do the trick. Thanks a lot. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: JSON me - blind again?
On Tue, 12 Mar 2013, Reinier Olislagers wrote: On 12-3-2013 11:44, Michael Van Canneyt wrote: Thanks for the help, Michael. On Tue, 12 Mar 2013, Reinier Olislagers wrote: //=== the line below works - so CommJSON is a valid object, right? if Assigned(CommJSON) then It is assigned, but not necessarily valid. If you freed CommJSON but did not nil it, it is still'assigned'. Understood. Then it has a pointer pointing to whatever (probably the object's former memory location). I'm not confident about function HttpRequestWithData(AData: TJSONData; const AUrl: string; const AMethod: TRequestMethod; const AContentType: string): THttpResult; Ehm. This must be function HttpRequestWithData(OUT AData: TJSONData; const AUrl: string; const AMethod: TRequestMethod; const AContentType: string): THttpResult; Because you are passing BACK a reference! Sorry. What I hadn't attached is the first part where the request is built up: if Assigned(AData) then begin VHttp.RequestBody := TMemoryStream.Create; VJSON := AData.AsJSON; VHttp.RequestBody.Write(Pointer(VJSON)^, Length(VJSON)); VHttp.RequestBody.Position := 0; end; Yes, but as per your code: you free and rebuild: FreeAndNil(AData); VData.Position := 0; - so you change the parameter, and thus you need a var/out Anyway, glad it is fixed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
Hi, The XMLTextReader creates the map, and passes it on to the final document. // Trunk procedure TLoader.ProcessXML(ADoc: TDOMDocument; AReader: TXMLTextReader); begin [...] doc.IDs := reader.IDMap; reader.IDMap := nil; end; // 2.6.2 === snip === doc.IDs := FIDMap; FIDMap := nil; == Just rechecked again... The debugger clearly says, that reader.IDMap / FIDMap is nil... [Before the second assignement - of course :) ] It seems to be started, but not finished. If so, what needs to be done? Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013 12:21:10 +0100 dev.d...@gmail.com wrote: [...] Just rechecked again... The debugger clearly says, that reader.IDMap / FIDMap is nil... [Before the second assignement - of course :) ] It seems to be started, but not finished. If so, what needs to be done? Maybe the bug is that it checks case sensitive: procedure TXMLTextReader.ParseAttlistDecl; ... Found := FSource.Matches(AttrDataTypeNames[dt]); ... function TXMLCharSource.Matches(const arg: WideString): Boolean; begin Result := False; if (FBufEnd = FBuf + Length(arg)) or Reload then Result := CompareMem(Pointer(arg), FBuf, Length(arg)*sizeof(WideChar)); if Result then begin Inc(FBuf, Length(arg)); if FBuf = FBufEnd then Reload; end; end; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] [OT] Sven, don't defect to the dark side!
Permitting myself a small tongue-in-cheek interruption of the regular activities on this mailing list: Sad enough that you're almost no student anymore (presumably equals having to do real work instead of improving FPC and incidentally studying), but this is really going to far ;) : http://www.reactos.org/archives/public/ros-dev/2013-March/016063.html Don't leave us - rather leave these C people to do whatever they do ;) Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
Maybe the bug is that it checks case sensitive:
procedure TXMLTextReader.ParseAttlistDecl;
...
Found := FSource.Matches(AttrDataTypeNames[dt]);
ParseAttlistDecl isn't called a single time...
- to me it sounds like Parse Attribute *declaration* - and I don't have a
DTD (the file is actually HTML).
When switching Validate *on*, there are lot of DoError calls - but don't know
if this is related...
From what I see: (trunk)
AddId is only called from ValidateAttrValue
ValidateAttrValue is only called from ValidateCurrentNode
and this is only when the parser does validation...
For me there is missing something in ParseAttribute(ElDef: TElementDecl);
===
if Assigned(ElDef) then
begin
AttDef := ElDef.GetAttrDef(attrName);
// mark attribute as specified
if Assigned(AttDef) then
FAttrDefIndex[AttDef.Index] := FAttrTag;
end
else
AttDef := nil;
===
ElDef is not assigned, so AttDef is nil...
AttDef holds TAttrDataType which should be recognised as dtId...
I hope I got it right so far - but still don't know what the actual problem
is...
-
That't what I'm currently testing with:
=== test.xml ===
?xml version=1.0 encoding=UTF-8?
html
div id=testTest/div
/html
=== test.pas ===
program test;
{$mode objfpc}{$H+}
Uses
Classes, XMLRead, DOM;
Var
Doc : TXMLDocument;
Parser : TDOMParser;
Source : TXMLInputSource;
List : TStringList;
begin
List := TStringList.Create;
List.LoadFromFile('test.xml');
Parser := TDOMParser.Create;
try
Parser.Options.IgnoreComments := true;
//Parser.Options.Validate := true;
Source := TXMLInputSource.Create(List.Text);
try
Parser.Parse(Source, Doc);
finally
Source.Free;
end;
finally
Parser.Free;
end;
WriteLn(assigned(Doc.IDs)); // output: false
List.Free;
end.
==
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
A little side note to my statement: and I don't have a DTD In this case the behaviour of the parser is even right... W3C: Note: Attributes with the name ID or id are not of type ID unless so defined -- http://stackoverflow.com/questions/3423430/java-xml-dom-how-are-id-attributes-special But that's not the solution to my problem... :( d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
Using Xpath I believe would be something like this:
function ElementById(id: string; doc: TXMLDocument): TDOMElement;
var
v: TXPathVariable;
begin
result:=nil;
try
v:=EvaluateXPathExpression('//*[@id=' + QuotedStr(id)+']',
doc.DocumentElement);
result:=TDOMElement(v.AsNodeSet[0]);
finally
FreeAndNil(v);
end;
end;
On Tue, Mar 12, 2013 at 10:42 AM, dev.d...@gmail.com wrote:
A little side note to my statement:
and I don't have a DTD
In this case the behaviour of the parser is even right...
W3C:
Note: Attributes with the name ID or id are not of type ID unless so
defined
--
http://stackoverflow.com/questions/3423430/java-xml-dom-how-are-id-attributes-special
But that's not the solution to my problem... :(
d.l.i.w
___
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] [OT] Sven, don't defect to the dark side!
Reinier Olislagers wrote: Permitting myself a small tongue-in-cheek interruption of the regular activities on this mailing list: Sad enough that you're almost no student anymore (presumably equals having to do real work instead of improving FPC and incidentally studying), but this is really going to far ;) : Studying isn't over until the examiner's sung :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, Mar 12, 2013 at 11:17 AM, Daniel Gaspary dgasp...@gmail.com wrote:
Using Xpath I believe would be something like this:
I was missing an If:
function ElementById(id: string; doc: TXMLDocument): TDOMElement;
var
v: TXPathVariable;
begin
result:=nil;
try
v:=EvaluateXPathExpression('//*[@id=' + QuotedStr(id)+']',
doc.DocumentElement);
with v.AsNodeSet do
begin
if Count0
then
result:=TDOMElement(Items[0]);
end;
finally
FreeAndNil(v);
end;
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
Using Xpath I believe would be something like this: I was missing an If: function ElementById(id: string; doc: TXMLDocument): TDOMElement; var v: TXPathVariable; begin [..] end; This does indeed work - thank you :) It's an acceptable solution for me, as I will need XPath anyway. Still I think that TDOMDocument.getElementById is better performance-wise - and I don't see a reason why it shouldn't work if TDOMDocument is created by the XMLParser - even if no definition is given... Is this worth a feature request / bug on mantis? d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
On Tue, 12 Mar 2013, dev.d...@gmail.com wrote: Using Xpath I believe would be something like this: I was missing an If: function ElementById(id: string; doc: TXMLDocument): TDOMElement; var v: TXPathVariable; begin [..] end; This does indeed work - thank you :) It's an acceptable solution for me, as I will need XPath anyway. Still I think that TDOMDocument.getElementById is better performance-wise - and I don't see a reason why it shouldn't work if TDOMDocument is created by the XMLParser - even if no definition is given... Is this worth a feature request / bug on mantis? Yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-xml
Is this worth a feature request / bug on mantis? Yes. Issue #24032 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] Sven, don't defect to the dark side!
First and foremost: this is very offtopic, so I'm moving this over to fpc-other. If someone answers to my mail, then please ensure that you only answer to fpc-pascal. Thank you. On 12.03.2013 13:57, Reinier Olislagers wrote: Sad enough that you're almost no student anymore (presumably equals having to do real work instead of improving FPC and incidentally studying), I'm really looking forward to the time I'm no student anymore. First I'm finally able to earn a nice amount of money and second I'll have regulated worktimes and don't need to use my free time (aka FPC time) to do homework or other things for university. This will finally be the time when the *real* fun on FPC development starts. :D but this is really going to far ;) : http://www.reactos.org/archives/public/ros-dev/2013-March/016063.html Don't leave us - rather leave these C people to do whatever they do ;) Where did I wrote that I'd leave FPC? If you'd read the ReactOS forums as well you'd know that I'm happily promoting that I'm a FPC developer when there is the chance... [Note: I'm aware that you're joking around, so don't take the tone of the previous paragraph to personally ^^] Nevertheless I like ReactOS very much. I'm a huge fan of the NT kernel (just in case: I'm not talking about the Win32 API here) and one of my dreams would be a new NT subsystem written in FPC with an as much as possible Pascal userland (why do you think I implemented the NativeNT target?). And if you look at the projects they are suggesting for GSOC 2013 there are very nice ones between them. The ones I personally would consider myself able to implement (the SSH server and the GUI installer) could even be implemented in Pascal (though this wouldn't help the ReactOS devs). So while this leaves out the GUI installer a SSH server for Windows and ReactOS could nevertheless be implemented independently of GSOC and the ReactOS project as a Pascal open source project... Things that I'd also like to see for ReactOS would be a port of DDEkit which would allow the usage of Linux drivers (compiled from source) on a NT system and just because I could a port of ReactOS to m68k (this would need some more work though than just porting the OS, e.g. patching the binutils and maybe gcc...). But there is also another side of the story though this is not related to the mail linked above: As my current company has (again) decided to move away from Delphi (to .Net with C#) I myself will very likely change my workplace at the end of my study as well. And the company I plan to work for is developing their own realtime microkernel operating system though they are working with C++. But they are also supportive of my work with FPC. The boss originally developed in Pascal as well and during the time I wrote my bachelor thesis for them two years ago I managed to port FPC natively to their POSIX layer as the first compiler ever. :) And I'll at least try if I could get a bit of time a week to be paid for work on FPC. And who knows... maybe I'll someday rewrite their kernel in Pascal :P Also it might be useful to use a different language for work than for hobby: you learn to appreciate your main language more (or in case of C++ more importantly the IDE...). And to close this mail I'll misuse the famous quote of an even more famous half-Vulcan: I was and always shall be: a Pascal programmer. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
