Re: [fpc-devel] property cam access private symbol from class in other unit

2012-01-04 Thread Pete Cervasio 
On Wednesday, January 04, 2012 01:26:52 pm Martin wrote:
 
TForm1 = class(TForm)
public
  FFoo: TFoo;
  property Num: Integer read FFoo.FBar;
end;

Just a 'for your info' note: Kylix doesn't allow the above.  Nor does it allow 
accessing the property FFoo.Bar as a parameter to the read.  This makes sense 
to me, though, because FFoo may very well be nil when code tries to read 
Form1.Num.

Here are my foo and form units, as well as the command line compiler's 
complaint about them:

~/tmp/k3tests/access_private_class_member $dcc Project1.dpr
Borland Delphi for Linux Version 14.5
Copyright (c) 1983,2002 Borland Software Corporation
main_unit.pas(13) Error: Record, object or class type required
main_unit.pas(25) 
Project1.dpr(6) Fatal: Could not compile used unit 'main_unit.pas'

Sorry if this is old news.  :)  Here are the files:

unit foo_unit;

interface

uses
  Classes;

type
  TFoo = class
  private
FBar : Integer;
  public
property Bar : Integer read FBar write FBar;
  end;

implementation

end.

unit main_unit;

interface

uses
  SysUtils, Types, Classes, Variants, QTypes, QGraphics, QControls, QForms, 
  QDialogs, QStdCtrls, foo_unit;

type
  TForm1 = class(TForm)
  public
Foo : TFoo;
property Num: Integer read Foo.Bar;
  end;

var
  Form1: TForm1;

implementation

{$R *.xfm}

end.

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Problem with Now() and time changed by ntpd

2011-11-03 Thread Pete Cervasio 
On Thursday, November 03, 2011 11:03:36 am Hans-Peter Diettrich wrote:
 Sven Barth schrieb:
  And functions like DateTimeToStr don't care whether a time value is
  local or UTC and in my opinion they even MUST NOT.
 
 Splitting the TDateTime into year, month etc. is done by a DecodeDate...
 function, that *assumes* that TDateTime contains a local time. When you
 feed it an UTC time, the result is unusable.

What?  How does it assume it's in local time?  It assumes it has received the 
value you want decoded.  The value 40850.5 treated as a TDateTime is 03 NOV 
2011 @ 12:00.  No matter what time zone it's expressed in, the result is the 
same, but in that zone.  If you want a different zone, you have to add in the 
offset before decoding.

How is that unusable?

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Problem with Now() and time changed by ntpd

2011-11-03 Thread Pete Cervasio 
On Thursday, November 03, 2011 03:11:37 pm Hans-Peter Diettrich wrote:
 Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a
DecodeDate...

function, that *assumes* that TDateTime contains a local time. When
you

feed it an UTC time, the result is unusable.
  
  What? How does it assume it's in local time? It assumes it has received
  the value you want decoded. The value 40850.5 treated as a TDateTime is
  03 NOV 2011 @ 12:00.
 
 How do you get the starting date and time of the epoch?

With the constant UnixDateDelta.  Help says that it Specifies the difference 
between TDateTime and TIME_T values.

Here's how I use it.  My main software project does all its work in UTC so I 
use this utc_now rather than the built-in now.  Conversion to local time is 
done only for display or logging purposes.

function utc_now: TDateTime;
var
  TimeVal: TTimeVal;
  TimeZone: PTimeZone;
begin
  TimeZone := nil;
  GetTimeOfDay (TimeVal, TimeZone);
  Result := (TimeVal.tv_Sec / SecsPerDay) 
  + ((TimeVal.tv_usec / 1000.0) / MSecsPerDay)
  + UnixDateDelta;
end;

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] IO checks across packages

2011-07-25 Thread Pete Cervasio 
On Monday 25 July 2011 08:07:22 Martin wrote:
 
 The following demo project enables and disables IO checks to simulate
 the situation.
 
 program Project1;
 {$mode objfpc}{$H+}
 begin
{$I+}
writeln('1');
{$I-}
chdir('c:\IDoNotExist');

You have to check IOResult at this point, since you told the compiler not to 
do it for you.  If you don't, then the error will propagate, as you've seen.  
This behavior has existed forever (since Turbo Pascal 3.0 at the least, maybe 
2.0 had it as well).

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Semicolon before else

2010-01-29 Thread Pete Cervasio 
On Friday 29 January 2010 01:52:59 Juha Manninen wrote:

 For Graeme and others: the problem is not the amount of typing. The problem
 is that you can easily forget this semicolon

It's not like you have to drop off your punch cards and come back tomorrow 
afternoon, is it?  I usually don't even have time to take a -sip- of coffee 
before the compiler's done finding my mistakes, let alone getting up to go 
chat with the other developers for a couple of minutes.  I sometimes miss the 
days of

What are you doing?  Get to work.
Compiling.
Oh, ok.

 when you for example add ELSE 
 to an existing IF. First there had to be a semicolon and then there must
 not be semicolon... Non-intuitive.

Wait, what?  It's absolutely intuitive.  To use a bad analogy, there had to be 
a semicolon because you were at the end of the sentence.  When you add 
the 'else foo' part to that sentence, it's going between the words that were 
already there and the semicolon that was already there because it's part of 
that same sentence.  It's just like you're adding a , and then more stuff 
to an english language sentence.

 So, the goal is to make the language more intuitive and
 programmer-friendly.

But above that you wrote:

 Anyway, there are some weird cases when it's difficult to
 tell which IF the ELSE belongs to.

That's neither intuitive nor friendly to me.  But if it works for you and 
makes your programming better, then I'm glad you came up with it.

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: makeskel fails to parse file

2006-09-14 Thread Pete Cervasio 
On Thursday 14 September 2006 07:06, Graeme Geldenhuys wrote:

 Still not sure what in the IFDEF LINUX caused the problem though...
 Does makeskel and FPC support the If Declared(...) syntax?

This might not be a big help with your specific problem, but the set if IFDEFs 
doesn't quite work the way it looks like it's expected to, at least not in my 
copy of Kylix 3.

   {$IFDEF CompilerVersion}

I believe this should be  {$IF DECLARED (CompilerVersion) } instead.  If I use 
the above $IFDEF, I always get the result that it's undefined unless I define 
it myself.

I hope this is helpful,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: makeskel fails to parse file

2006-09-14 Thread Pete Cervasio 
On Thursday 14 September 2006 09:18, Graeme Geldenhuys wrote:
 I haven't used Kylix 3 Pro for over a year. I had my copy of Kylix
 fully patched - not sure if that made a difference.  The IFDEF's did
 work at that stage though. Strange I guess, seeing that yours doesn't.

Yeah, that's definitely strange.  I think it shouldn't have worked, according 
to the docs.  In the Kylix help they say:

 Conditional symbols are not Delphi identifiers and cannot
 be referenced in actual program code.  Similarly, Delphi
 identifiers cannot be referenced in any conditional directives
 other than $IF and $ELSEIF.

Oh, you were right about where you found that - The Indy components shipped 
with Kylix 3 had that exact bit of code.  It's moot now, since you took all 
the Kylix stuff out of your project, but Indy 10 has changed how that check 
is made, eschewing $IFDEF for $IF.

Best regards,
Pete C.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] resolve.pp in ver 2.0.4 (and a fix)

2006-08-31 Thread Pete Cervasio 
Greetings.

I had been using version 2.0.2 (under Linux, if it matters) and noticed a 
problem with the THostResolver component.  It was giving incorrect (reversed) 
addresses for anything that had to come from DNS.  Entries out of /etc/hosts 
would work fine, though.  After fixing the problem here locally, I figured I 
ought to share.

In the process of getting ready to do that, I wound up upgrading to the latest 
stable version (2.0.4) and was happy to see that some attempt had already 
been made to fix that bug.  Unfortunately, it appears that the problem has 
been reversed instead of fixed.  Now lookups that come through DNS are 
showing up properly but the ones from /etc/hosts are not.

The fix is further down, but for reference here is a test program which will 
show the problem in action.  The original purpose of this test program was to 
develop/test a generic Lookup() function that would deal with short and full 
host names, which it does.  Feel free to use it, if it's helpful to you. :)

program resolver_test;
uses
  SysUtils, resolve, netdb;

function Lookup (WhatHost: String): String;
var
  TheHost: THostResolver;
begin
  Result := '';
  TheHost := THostResolver.Create(nil);
  try
// First, attempt lookup using the name as given to us
if TheHost.NameLookup(WhatHost) then
  Result := TheHost.AddressAsString;

// If not found, and no dot in the name, tack on default domain
if (Result = '') and  (pos('.', WhatHost) = 0) then
  if TheHost.NameLookup(WhatHost + '.' + DefaultDomainList) then
Result := TheHost.AddressAsString;

  finally
TheHost.free;
  end;
end;

procedure testlookup (What, Where, Expected: String);
var
  Res : String;
begin
  Res := Lookup (What);
  Write (Format('Lookup %-19s from %-10s : %-15s ', 
 [What, Where, Res]));
  if Res = Expected then
writeln ('Success!')
  else
writeln ('Failure!');
end;

begin
  Writeln ('default domain is ', DefaultDomainList);
  testlookup ('localhost', '/etc/hosts', '127.0.0.1');
  testlookup ('host85', 'dns', '192.168.1.85');
  testlookup ('delenn', '/etc/hosts', '192.168.1.92');
  testlookup ('www.freepascal.org', 'dns', '62.166.198.202');
end.

The expected values were all determined by getent hosts as follows:

for a in localhost host85 delenn www.freepascal.org ; do getent hosts $a; done

The where part comes from me knowing that there are only two non-comment 
lines in my /etc/hosts file.  :)

The incorrect results, as given by the above program compiled with the 2.0.4 
binary distribution:

default domain is sbcglobal.net
Lookup localhost   from /etc/hosts : 1.0.0.127   Failure!
Lookup host85  from dns: 192.168.1.85Success!
Lookup delenn  from /etc/hosts : 92.1.168.192Failure!
Lookup www.freepascal.org  from dns: 62.166.198.202  Success!

As you can see, the addresses that came from /etc/hosts are in the wrong 
order.  The problem is in the routines THostResolver.NameLookup and 
THostResolver.SaveHostEntry in resolve.pp.

In THostResolver.SaveHostEntry there are several calls of NetToHost(), as 
follows:

Procedure THostResolver.SaveHostEntry(Entry : Pointer);

Var
  PH : ^THostEntry;
  I : Integer;

begin
  PH:=ENtry;
  FName:=PH^.Name;
  FHostAddress:=NetToHost(PH^.Addr);
  FAddressCount:=1;
  GetMem(FAddresses,SizeOf(THostAddr));
  FAddresses[0]:=NetToHost(PH^.Addr);
  FAliases.CommaText:=PH^.Aliases;
end;

This is incorrect behavior, as some of the addresses passed to SaveHostEntry 
may already be in host order.  The two NetToHost() calls should be removed 
from this function, and instead, one should be added to the 
THostResolver.Namelookup function immediately after the ResolveHostByName() 
call, which returns addresses in network order.  Like so:


{$ifdef usenetdb}
Function THostResolver.NameLookup (Const S : String) : Boolean;

Var
  H : THostEntry;

begin
  Result:=Inherited NameLookup(S);
  If Result then
begin
Result:=GetHostByName(S,H);
if not Result then
begin
  Result:=ResolveHostByName(S,H);
  if Result then
H.Addr:=NetToHost(H.Addr);
end;
If Result then
  SaveHostEntry(@H);
end;
end;

... and the other fix, further down ...

Procedure THostResolver.SaveHostEntry(Entry : Pointer);

Var
  PH : ^THostEntry;
  I : Integer;

begin
  PH:=ENtry;
  FName:=PH^.Name;
  FHostAddress:=PH^.Addr;
  FAddressCount:=1;
  GetMem(FAddresses,SizeOf(THostAddr));
  FAddresses[0]:=PH^.Addr;
  FAliases.CommaText:=PH^.Aliases;
end;

After this change, the proper results are obtained:

~/devel/temp $./resolver_test
default domain is sbcglobal.net
Lookup localhost   from /etc/hosts : 127.0.0.1   Success!
Lookup host85  from dns: 192.168.1.85Success!
Lookup delenn  from /etc/hosts : 192.168.1.92Success!
Lookup www.freepascal.org  from dns: 62.166.198.202  Success!

I have not looked at any of the other T{foo}Resolver classes at all,