Re: [fpc-pascal] Re: SqlDB fails under Windows to create a newFirebird database

[Graeme Geldenhuys]

On Wednesday 30/10/2013 at 15:37, Michael Van Canneyt  wrote:
AFAIK: Windows doesn't know single quotes, you need to use double 
quotes.


Thanks Michael, you are correct. When using double quotes Windows was 
happy. Even if the path had spaces in, using double quotes still 
worked.


Regards,
 Graeme
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 02:45, schrieb Xiangrong Fang:
2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be 
mailto:jonas.ma...@elis.ugent.be



This is not equivalent. A private type declaration in a class adds
a new identifier that is visible inside that class. You then use
it, still in that class, to declare the return type of a function.
Next, in a scope where that type identifier is no longer visible,
you call the function.

My example is a complete match to that scenario as far as
identifier visibility is concerned (you use a type in a scope
where it is visible to declare a function return type, and then
call the function in a scope where it is not visible). In your
example, the type is not visible in the place where the function
is declared but only where it is defined
.


This is logically WRONG. Because to the machine, any function return 
value can be seen as an array of bytes, for example, a pointer is 
array[0..3] of Byte on a 32-bit machine.  The purpose of type system 
is to explain what these bytes stands for. So, if a type is 
out-of-scope, how do you interpret the data?


The current delphi compatible implementation IS using the type 
information to compile the program, i.e. although it is not visible, 
it is indeed used by the compile, which, in my opinion, violates 
visibility rules.


Standing on your view point, if a type is no longer visible, but a 
variable (function return value) of that type is in current scope, and 
understood by the program, this means, this value itself carries type 
information!  Is is kind of meta data available in Pascal? If so, I 
think RTTI should work for ANY kind of primitive data types.


For unit interfaces there is indeed the point that if unit A uses unit B 
then the program which uses unit A will be able to access types used by 
unit A. E.g.:


=== unit A ===

unit A;

interface

type
  TTest = class
procedure Test;
  end;

implementation

procedure TTest.Test;
begin
  Writeln('Foobar');
end;

end.

=== unit A ===

=== unit B ===

unit B;

interface

uses
  A;

function SomeTest: TTest;

implementation

function SomeTest: TTest;
begin
  Result := TTest.Create;
end;

end.

=== unit B ===

=== program ===

program test;

uses
  B;

begin
  // there won't be an error here
  SomeTest.Test;
end.

=== program ===

It's this way at least since Turbo Pascal (though without classes then ;) ).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Argument evaluation order in Free Pascal and Delphi

[Sven Barth]

Am 31.10.2013 09:45, schrieb Michael Schnell:

On 10/28/2013 02:47 PM, Dmitry Pribysh wrote:
As it is written in Free Pascal wiki 
http://wiki.freepascal.org/Code_Conversion_Guide#Order_of_parameter_evaluation, 
order of parameter evaluation is not defined in FPC, but it is 
defined in Delphi (Delphi guarantees left-to-right evaluation order).



IMHO =in fact evaluation of a parameter should not be guaranteed at all.

The compiler should be free to inline a function, detect that the 
parameter is not necessary for the evaluation of the function result 
and drop the evaluation of the parameter (maybe giving a warning or 
error message if that might trigger side-effects).

1. FPC does not guarantee evaluation order exactly for this reason
2. The compiler already does this inlining already in that way (at least 
partially).

Take this code:

=== code begin ===

program tinlinetest;

{$mode objfpc}

function GetStr1: String; inline;
begin
  Result := 'Hello World';
end;

function GetStr2: String;
begin
  Result := 'Hello World';
end;

function Test(aArg1: Integer; aArg2: String): Integer; inline;
begin
  Result := aArg1 * 42;
end;

begin
  Writeln(Test(42, 'Hello World'));
  Writeln(Test(42, GetStr1));
  Writeln(Test(42, GetStr2));
end.

=== code end ===

this will produce this output in the main function (2.7.1 and compiled 
with -O2):


=== assembler begin ===

PASCALMAIN:
.globl_main
_main:
# Temps allocated between esp+0 and esp+512
# [20] begin
pushl%ebx
addl$-512,%esp
callFPC_INITIALIZEUNITS
# [21] Writeln(Test(42, 'Hello World'));
  // No usage of 'Hello World' constant here
callfpc_get_output
movl%eax,%ebx
movl%ebx,%edx
movl$1764,%ecx
movl$0,%eax
callfpc_write_text_sint
callFPC_IOCHECK
movl%ebx,%eax
callfpc_writeln_end
callFPC_IOCHECK
# [22] Writeln(Test(42, GetStr1));
  // here this might be a bug... the compiler inlines GetStr1, but does 
not detect that its result is constant and not used...

callfpc_get_output
movl%eax,%ebx
movl$_$TINLINETEST$_Ld1,%ecx
leal256(%esp),%eax
movl$255,%edx
callfpc_shortstr_to_shortstr
leal256(%esp),%ecx
movl%esp,%eax
movl$255,%edx
callfpc_shortstr_to_shortstr
movl$1764,%ecx
movl%ebx,%edx
movl$0,%eax
callfpc_write_text_sint
callFPC_IOCHECK
movl%ebx,%eax
callfpc_writeln_end
callFPC_IOCHECK
# [23] Writeln(Test(42, GetStr2));
  // here it can not inline GetStr2, because it can not detect whether 
GetStr2 is sideeffect free

callfpc_get_output
movl%eax,%ebx
leal256(%esp),%eax
callP$TINLINETEST_$$_GETSTR2$$SHORTSTRING
leal256(%esp),%ecx
movl%esp,%eax
movl$255,%edx
callfpc_shortstr_to_shortstr
movl$1764,%ecx
movl%ebx,%edx
movl$0,%eax
callfpc_write_text_sint
callFPC_IOCHECK
movl%ebx,%eax
callfpc_writeln_end
callFPC_IOCHECK
# [24] end.
callFPC_DO_EXIT
addl$512,%esp
popl%ebx
ret

=== assembler end ===

So case 2 could be improved a bit.
And for case 3 it might be interesting to have the compiler mark 
functions with additional flags to check whether they are e.g. 
constant or access memory (aside from parameters) in a writing way, 
etc. This *might* improve some optimizations...


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: SqlDB fails under Windows to create a newFirebird database

[Sven Barth]

Am 30.10.2013 15:34, schrieb Graeme Geldenhuys:

On Wednesday 30/10/2013 at 15:37, Michael Van Canneyt wrote:

AFAIK: Windows doesn't know single quotes, you need to use double quotes.


Thanks Michael, you are correct. When using double quotes Windows was 
happy. Even if the path had spaces in, using double quotes still worked.



Something different, Graeme: can it be that you did some change to your 
e-mail setup? Since some days your answers mess up the threading by 
appearing as top level messages...


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

2013/10/31 Sven Barth pascaldra...@googlemail.com

  Am 31.10.2013 02:45, schrieb Xiangrong Fang:

  2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be


  This is not equivalent. A private type declaration in a class adds a new
 identifier that is visible inside that class. You then use it, still in
 that class, to declare the return type of a function. Next, in a scope
 where that type identifier is no longer visible, you call the function.

 My example is a complete match to that scenario as far as identifier
 visibility is concerned (you use a type in a scope where it is visible to
 declare a function return type, and then call the function in a scope where
 it is not visible). In your example, the type is not visible in the place
 where the function is declared but only where it is defined
 .


  This is logically WRONG. Because to the machine, any function return
 value can be seen as an array of bytes, for example, a pointer is
 array[0..3] of Byte on a 32-bit machine.  The purpose of type system is to
 explain what these bytes stands for. So, if a type is out-of-scope, how do
 you interpret the data?

  The current delphi compatible implementation IS using the type
 information to compile the program, i.e. although it is not visible, it is
 indeed used by the compile, which, in my opinion, violates visibility rules.

  Standing on your view point, if a type is no longer visible, but a
 variable (function return value) of that type is in current scope, and
 understood by the program, this means, this value itself carries type
 information!  Is is kind of meta data available in Pascal? If so, I think
 RTTI should work for ANY kind of primitive data types.

For unit interfaces there is indeed the point that if unit A uses unit
 B then the program which uses unit A will be able to access types used by
 unit A. E.g.:

 === unit A ===

 unit A;

 interface

 type
   TTest = class
 procedure Test;
   end;

 implementation

 procedure TTest.Test;
 begin
   Writeln('Foobar');
 end;

 end.

 === unit A ===

 === unit B ===

 unit B;

 interface

 uses
   A;

 function SomeTest: TTest;

 implementation

 function SomeTest: TTest;
 begin
   Result := TTest.Create;
 end;

 end.

 === unit B ===

 === program ===

 program test;

 uses
   B;

 begin
   // there won't be an error here
   SomeTest.Test;
 end.

 === program ===

 It's this way at least since Turbo Pascal (though without classes then ;)
 ).


Yes, I agree this is the TP/Delphi way, and as such should be kept at least
in DELPHI mode. But is this really good? Doesn't this contradict the Pascal
philosophy? Borland did a few questionable things (look at how you used the
semicolons in you examples above ;-) ), and it took some decisions when
implementing units. But how is this handled in Modula?

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Efficient String concatenation

[Antonio Fortuny]

Hi All.

Based upon the code into the post, I've driven a test case:
three platforms and Delphi 5, Delphi XE, Lazarus 1.0.12 (FPC 2.6.2)
For a comparison purpose, the main specific code has been written in a 
classical way, using implicit string and the optimized code uses the 
function result as explicit intermediate string.
All tests have been run the same way: the program has been reloaded for 
everyy run either classic or optimized

times shown are in minutes(always zero):seconds.ms
Two loops have been done: 10 meg loops and 100 meg.
There are the results:

Platform Vista 32
Delphi 5
10,000,000 iterations classic 00:05.735 - optimized 00:04.374
100,000,000 iterations classic 00:57.881 - optimized 00:44.386
Lazarus 1.0.12 Win32
10,000,000 iterations classic 00:02.487 - optimized 00:01.498
100,000,000 iterations classic 00:25.121 - optimized 00:16.528
Delphi XE on Vista32
10,000,000 iterations classic 00:01.757 - optimized 00:01.233
100,000,000 iterations classic 00:18.524 - optimized 00:13.204

Platform W7 x64 (virtual machine into Esxi4)
Delphi 5
10,000,000 iterations classic 00:05.491 - optimized 00:04.773
100,000,000 iterations classic 00:57.143 - optimized 00:49.780
Lazarus 1.0.12 Win32
10,000,000 iterations classic 00:03.213 - optimized 00:02.465
100,000,000 iterations classic 00:33.290 - optimized 00:25.21
Lazarus 1.0.12 Win64
10,000,000 iterations classic 00:03.962 - optimized 00:03.136
100,000,000 iterations classic 00:42.495 - optimized 00:34.523
Delphi XE w32
10,000,000 iterations classic 00:02.886 - optimized 00:02.153
100,000,000 iterations classic 00:31.013 - optimized 00:24.102

Platform Linux x64 (virtual machine into Esxi4)
Lazarus 1.0.12
10,000,000 iterations classic 00:03.348 - optimized 00:02.727
100,000,000 iterations classic 00:37.081 - optimized 00:28.810

Enjoy.

Antonio

object fMain: TfMain
  Left = 209
  Height = 337
  Top = 109
  Width = 376
  Caption = 'Concaténation de strings'
  ClientHeight = 337
  ClientWidth = 376
  LCLVersion = '1.0.12.0'
  object Panel1: TPanel
Left = 0
Height = 122
Top = 0
Width = 376
Align = alTop
ClientHeight = 122
ClientWidth = 376
TabOrder = 0
object Label1: TLabel
  Left = 10
  Height = 14
  Top = 7
  Width = 48
  Caption = 'Itérations'
  ParentColor = False
end
object EIterations: TEdit
  Left = 60
  Height = 21
  Top = 4
  Width = 80
  TabOrder = 0
  Text = '10'
end
object BtnClassique: TButton
  Left = 14
  Height = 25
  Top = 37
  Width = 75
  Caption = 'Classique'
  OnClick = BtnClassiqueClick
  TabOrder = 1
end
object BtnOptimise: TButton
  Left = 111
  Height = 25
  Top = 37
  Width = 75
  Caption = 'Optimisé'
  OnClick = BtnOptimiseClick
  TabOrder = 2
end
object BtnClose: TButton
  Left = 294
  Height = 25
  Top = 2
  Width = 75
  Caption = 'Fermer'
  OnClick = BtnCloseClick
  TabOrder = 3
end
  end
  object Memo1: TMemo
Left = 0
Height = 215
Top = 122
Width = 376
Align = alClient
Lines.Strings = (
  'Memo1'
)
TabOrder = 1
  end
end
unit StrConcatMain;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls, 
StdCtrls;

type

  { TfMain }

  TfMain = class(TForm)
Panel1: TPanel;
Memo1: TMemo;
Label1: TLabel;
EIterations: TEdit;
BtnClassique: TButton;
BtnOptimise: TButton;
BtnClose: TButton;
procedure BtnClassiqueClick(Sender: TObject);
procedure BtnOptimiseClick(Sender: TObject);
procedure BtnCloseClick(Sender: TObject);
  private
{ private declarations }
function Classique(const Iterations: Integer): String;
function Optimise(const Iterations: Integer): String;
  public
{ public declarations }
  end;

var
  fMain: TfMain;

implementation

{$R *.lfm}

{ TfMain }

procedure TfMain.BtnClassiqueClick(Sender: TObject);
var
  Debut: TDateTime;
  Fin: TDateTime;
  Ecart: TDateTime;
  Iterations: Integer;
  Index: Integer;
begin
  Iterations := StrToIntDef(EIterations.Text, -1);
  if Iterations = -1 then begin
MessageDlg('Erreur','Du numérique SVP', mtError, [mbOK], 0, mbOK);
EIterations.SetFocus;
Exit
  end;
  Debut := now;
  for Index := 0 to Iterations do
Classique(Iterations);
  Fin := now;
  Ecart := Fin - Debut;
  Memo1.Lines.Add(Format('%d itérations en mode classique en %s', [Iterations, 
FormatDateTime('nn:ss.zzz', Ecart)]));
end;

procedure TfMain.BtnOptimiseClick(Sender: TObject);
var
  Debut: TDateTime;
  Fin: TDateTime;
  Ecart: TDateTime;
  Iterations: Integer;
  Index: Integer;
begin
  Iterations := StrToIntDef(EIterations.Text, -1);
  if Iterations = -1 then begin
MessageDlg('Erreur','Du numérique SVP', mtError, [mbOK], 0, mbOK);
EIterations.SetFocus;
Exit
  end;
  Debut := now;
  for Index := 0 to Iterations do
Optimise(Iterations);
  

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:
2013/10/31 Sven Barth pascaldra...@googlemail.com 
mailto:pascaldra...@googlemail.com


Am 31.10.2013 02:45, schrieb Xiangrong Fang:

2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be
mailto:jonas.ma...@elis.ugent.be


This is not equivalent. A private type declaration in a class
adds a new identifier that is visible inside that class. You
then use it, still in that class, to declare the return type
of a function. Next, in a scope where that type identifier is
no longer visible, you call the function.

My example is a complete match to that scenario as far as
identifier visibility is concerned (you use a type in a scope
where it is visible to declare a function return type, and
then call the function in a scope where it is not visible).
In your example, the type is not visible in the place where
the function is declared but only where it is defined
.


This is logically WRONG. Because to the machine, any function
return value can be seen as an array of bytes, for example, a
pointer is array[0..3] of Byte on a 32-bit machine.  The purpose
of type system is to explain what these bytes stands for. So, if
a type is out-of-scope, how do you interpret the data?

The current delphi compatible implementation IS using the type
information to compile the program, i.e. although it is not
visible, it is indeed used by the compile, which, in my opinion,
violates visibility rules.

Standing on your view point, if a type is no longer visible, but
a variable (function return value) of that type is in current
scope, and understood by the program, this means, this value
itself carries type information!  Is is kind of meta data
available in Pascal? If so, I think RTTI should work for ANY kind
of primitive data types.


For unit interfaces there is indeed the point that if unit A uses
unit B then the program which uses unit A will be able to access
types used by unit A. E.g.:

=== unit A ===

unit A;

interface

type
  TTest = class
procedure Test;
  end;

implementation

procedure TTest.Test;
begin
  Writeln('Foobar');
end;

end.

=== unit A ===

=== unit B ===

unit B;

interface

uses
  A;

function SomeTest: TTest;

implementation

function SomeTest: TTest;
begin
  Result := TTest.Create;
end;

end.

=== unit B ===

=== program ===

program test;

uses
  B;

begin
  // there won't be an error here
  SomeTest.Test;
end.

=== program ===

It's this way at least since Turbo Pascal (though without classes
then ;) ).


Yes, I agree this is the TP/Delphi way, and as such should be kept at 
least in DELPHI mode. But is this really good? Doesn't this contradict 
the Pascal philosophy? Borland did a few questionable things (look at 
how you used the semicolons in you examples above ;-) ), and it took 
some decisions when implementing units. But how is this handled in Modula?
Undoing this even for only non-TP/Delphi modes would mean adjusting very 
much code out there. So no, this is how Object Pascal works.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

2013/10/31 Sven Barth pascaldra...@googlemail.com

  Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:

  2013/10/31 Sven Barth pascaldra...@googlemail.com

  Am 31.10.2013 02:45, schrieb Xiangrong Fang:

  2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be


  This is not equivalent. A private type declaration in a class adds a
 new identifier that is visible inside that class. You then use it, still in
 that class, to declare the return type of a function. Next, in a scope
 where that type identifier is no longer visible, you call the function.

 My example is a complete match to that scenario as far as identifier
 visibility is concerned (you use a type in a scope where it is visible to
 declare a function return type, and then call the function in a scope where
 it is not visible). In your example, the type is not visible in the place
 where the function is declared but only where it is defined
 .


  This is logically WRONG. Because to the machine, any function return
 value can be seen as an array of bytes, for example, a pointer is
 array[0..3] of Byte on a 32-bit machine.  The purpose of type system is to
 explain what these bytes stands for. So, if a type is out-of-scope, how do
 you interpret the data?

  The current delphi compatible implementation IS using the type
 information to compile the program, i.e. although it is not visible, it is
 indeed used by the compile, which, in my opinion, violates visibility rules.

  Standing on your view point, if a type is no longer visible, but a
 variable (function return value) of that type is in current scope, and
 understood by the program, this means, this value itself carries type
 information!  Is is kind of meta data available in Pascal? If so, I think
 RTTI should work for ANY kind of primitive data types.

 For unit interfaces there is indeed the point that if unit A uses
 unit B then the program which uses unit A will be able to access types used
 by unit A. E.g.:

 === unit A ===

 unit A;

 interface

 type
   TTest = class
 procedure Test;
   end;

 implementation

 procedure TTest.Test;
 begin
   Writeln('Foobar');
 end;

 end.

 === unit A ===

 === unit B ===

 unit B;

 interface

 uses
   A;

 function SomeTest: TTest;

 implementation

 function SomeTest: TTest;
 begin
   Result := TTest.Create;
 end;

 end.

 === unit B ===

 === program ===

 program test;

 uses
   B;

 begin
   // there won't be an error here
   SomeTest.Test;
 end.

 === program ===

 It's this way at least since Turbo Pascal (though without classes then ;)
 ).


  Yes, I agree this is the TP/Delphi way, and as such should be kept at
 least in DELPHI mode. But is this really good? Doesn't this contradict the
 Pascal philosophy? Borland did a few questionable things (look at how you
 used the semicolons in you examples above ;-) ), and it took some decisions
 when implementing units. But how is this handled in Modula?

 Undoing this even for only non-TP/Delphi modes would mean adjusting very
 much code out there. So no, this is how Object Pascal works.


Ah, you mean that this is too much intricately mixed with the compiler code
and it would be much too much work to change? OK, this I understand :-)

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: SqlDB fails under Windows to create a newFirebird database

[waldo kitty]

On 10/30/2013 10:34 AM, Graeme Geldenhuys wrote:

On Wednesday 30/10/2013 at 15:37, Michael Van Canneyt wrote:

AFAIK: Windows doesn't know single quotes, you need to use double quotes.


Thanks Michael, you are correct. When using double quotes Windows was happy.
Even if the path had spaces in, using double quotes still worked.


can't help but to wonder if it still works as desired in linux... i know that 
quotes have different meanings and uses over there...


--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[waldo kitty]

On 10/31/2013 7:38 AM, Frederic Da Vitoria wrote:

2013/10/31 Sven Barth pascaldra...@googlemail.com

[...]

It's this way at least since Turbo Pascal (though without classes then ;) ).


Yes, I agree this is the TP/Delphi way, and as such should be kept at least in
DELPHI mode.


and TP mode, of course ;)


But is this really good? Doesn't this contradict the Pascal
philosophy? Borland did a few questionable things (look at how you used the
semicolons in you examples above ;-) ),


i can't see anything untoward with their use... they are statement separators, 
after all ;)



and it took some decisions when
implementing units. But how is this handled in Modula?


:)

--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 14:42, schrieb Frederic Da Vitoria:
2013/10/31 Sven Barth pascaldra...@googlemail.com 
mailto:pascaldra...@googlemail.com


Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:

2013/10/31 Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com

Am 31.10.2013 02:45, schrieb Xiangrong Fang:

2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be
mailto:jonas.ma...@elis.ugent.be


This is not equivalent. A private type declaration in a
class adds a new identifier that is visible inside that
class. You then use it, still in that class, to declare
the return type of a function. Next, in a scope where
that type identifier is no longer visible, you call the
function.

My example is a complete match to that scenario as far
as identifier visibility is concerned (you use a type in
a scope where it is visible to declare a function return
type, and then call the function in a scope where it is
not visible). In your example, the type is not visible
in the place where the function is declared but only
where it is defined
.


This is logically WRONG. Because to the machine, any
function return value can be seen as an array of bytes, for
example, a pointer is array[0..3] of Byte on a 32-bit
machine.  The purpose of type system is to explain what
these bytes stands for. So, if a type is out-of-scope, how
do you interpret the data?

The current delphi compatible implementation IS using the
type information to compile the program, i.e. although it is
not visible, it is indeed used by the compile, which, in my
opinion, violates visibility rules.

Standing on your view point, if a type is no longer visible,
but a variable (function return value) of that type is in
current scope, and understood by the program, this means,
this value itself carries type information!  Is is kind of
meta data available in Pascal? If so, I think RTTI should
work for ANY kind of primitive data types.


For unit interfaces there is indeed the point that if unit A
uses unit B then the program which uses unit A will be able
to access types used by unit A. E.g.:


...



It's this way at least since Turbo Pascal (though without
classes then ;) ).


Yes, I agree this is the TP/Delphi way, and as such should be
kept at least in DELPHI mode. But is this really good? Doesn't
this contradict the Pascal philosophy? Borland did a few
questionable things (look at how you used the semicolons in you
examples above ;-) ), and it took some decisions when
implementing units. But how is this handled in Modula?

Undoing this even for only non-TP/Delphi modes would mean
adjusting very much code out there. So no, this is how Object
Pascal works.


Ah, you mean that this is too much intricately mixed with the compiler 
code and it would be much too much work to change? OK, this I 
understand :-)


It's not about being mixed with the compiler code it's about too many 
legacy code relying on this behavior, because it's a given since TP times.


Regartds,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

2013/10/31 waldo kitty wkitt...@windstream.net

 On 10/31/2013 7:38 AM, Frederic Da Vitoria wrote:

 But is this really good? Doesn't this contradict the Pascal
 philosophy? Borland did a few questionable things (look at how you used
 the
 semicolons in you examples above ;-) ),


 i can't see anything untoward with their use... they are statement
 separators, after all ;)


Not when they are placed before a end since end is not a statement.
Some Pascal compilers would even completely refuse a semicolon before a
end.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 15:41, schrieb Frederic Da Vitoria:
2013/10/31 Sven Barth pascaldra...@googlemail.com 
mailto:pascaldra...@googlemail.com


Am 31.10.2013 14:42, schrieb Frederic Da Vitoria:

2013/10/31 Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com

Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:

2013/10/31 Sven Barth pascaldra...@googlemail.com
mailto:pascaldra...@googlemail.com

Am 31.10.2013 02:45, schrieb Xiangrong Fang:

2013/10/30 Jonas Maebe jonas.ma...@elis.ugent.be
mailto:jonas.ma...@elis.ugent.be


This is not equivalent. A private type declaration
in a class adds a new identifier that is visible
inside that class. You then use it, still in that
class, to declare the return type of a function.
Next, in a scope where that type identifier is no
longer visible, you call the function.

My example is a complete match to that scenario as
far as identifier visibility is concerned (you use
a type in a scope where it is visible to declare a
function return type, and then call the function in
a scope where it is not visible). In your example,
the type is not visible in the place where the
function is declared but only where it is defined
.


This is logically WRONG. Because to the machine, any
function return value can be seen as an array of bytes,
for example, a pointer is array[0..3] of Byte on a
32-bit machine.  The purpose of type system is to
explain what these bytes stands for. So, if a type is
out-of-scope, how do you interpret the data?

The current delphi compatible implementation IS using
the type information to compile the program, i.e.
although it is not visible, it is indeed used by the
compile, which, in my opinion, violates visibility rules.

Standing on your view point, if a type is no longer
visible, but a variable (function return value) of that
type is in current scope, and understood by the
program, this means, this value itself carries type
information!  Is is kind of meta data available in
Pascal? If so, I think RTTI should work for ANY kind of
primitive data types.


For unit interfaces there is indeed the point that if
unit A uses unit B then the program which uses unit A
will be able to access types used by unit A. E.g.:


...


It's this way at least since Turbo Pascal (though
without classes then ;) ).


Yes, I agree this is the TP/Delphi way, and as such should
be kept at least in DELPHI mode. But is this really good?
Doesn't this contradict the Pascal philosophy? Borland did a
few questionable things (look at how you used the semicolons
in you examples above ;-) ), and it took some decisions when
implementing units. But how is this handled in Modula?

Undoing this even for only non-TP/Delphi modes would mean
adjusting very much code out there. So no, this is how Object
Pascal works.


Ah, you mean that this is too much intricately mixed with the
compiler code and it would be much too much work to change? OK,
this I understand :-)


It's not about being mixed with the compiler code it's about too
many legacy code relying on this behavior, because it's a given
since TP times.


...and this modification would only become relevant for new code, so 
quite probably not worth the compiler extra code. Yes, I can 
understand this too. But my question was not about changing the 
behavior of fpc (not any more). This was a theoretical question. In 
other words, if you had been in a position to create TP back in 
nineteen something, and if one of your main concerns had been about 
respecting the Pascal philosophy, how would you have handled this? The 
way it has been done? Or do you agree this was not quite orthodox 
(although efficient)?

I honestly don't know what I would have done...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] private type and type compatibility

[Martin]

On 31/10/2013 14:41, Frederic Da Vitoria wrote:


...and this modification would only become relevant for new code, so 
quite probably not worth the compiler extra code. Yes, I can 
understand this too. But my question was not about changing the 
behavior of fpc (not any more). This was a theoretical question. In 
other words, if you had been in a position to create TP back in 
nineteen something, and if one of your main concerns had been about 
respecting the Pascal philosophy, how would you have handled this? The 
way it has been done? Or do you agree this was not quite orthodox 
(although efficient)?




Well, that depends on how you see a type.

If a type is something that I can use to declare a variable, then the 
type-information (for lack of another term) that is part of a typed 
variable is not a type. Because I can not use it to declare a variable..


So if you differ between type, and type-information then there is no 
conflict.


A typed variable has type info (never mind RTTI, it may just be avail at 
compile time). this type info can be accessed through the variable.


---
Also where is the problem with it?
By making a variable or function's result) public, you declare, that it 
should be usable. So you should expect all indirect requirements to be 
made available too.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Github mirror repositories will be down for a few days

[Graeme Geldenhuys]

Hi,

I'm relocating the server that manages the [unofficial] Github mirror 
repositories for FPC and Lazarus to the UK (from South Africa). The 
whole process should be done by Tuesday or Wednesday next week.


Sorry for the inconvenience an long downtime.

Regards,
 - Graeme -


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: SqlDB fails under Windows to create a newFirebirddatabase

[Graeme Geldenhuys]

On Thursday 31/10/2013 at 11:50, Sven Barth  wrote:



Something different, Graeme: can it be that you did some change to 
your e-mail setup? Since some days your answers mess up the 
threading by appearing as top level messages...


Yes, I'm accessing my emails remotely for the last 3 weeks via a 
crappy web interface. I also keep forgetting to set the messages to 
plain text (it keeps defaulting to HTML). I'm back to normal from 
Tuesday onwards. :)


Regards,
 Graeme


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Powtils: lightwebserver, lightwebserver2 or lightwebserver3?

[Juha Manninen]

On Mon, Oct 28, 2013 at 3:22 PM, Graeme Geldenhuys
gra...@geldenhuys.co.uk wrote:
 Having recently (and currently still) doing extensive work with embedded
 HTTP servers, I tested many (Powtils, Indy, tiWebServer, FPC, nYume etc). I
 must agree with Michael, fphttpserver is a good choice. There is a bit of a
 learning curve [compared to some others], but nothing major. Overall, I'm
 very happy with the final choice on fphttpserver.

Out of curiosity, how is its performance compared to Indy based web server.
My current employer has a highly optimized data system with custom web
server and custom DB. No SQL sentences and no SQL DBs obviously. The
load it can handle is quite impressive.
It manages information for schools: personnel, students, courses,
exams, timetables, messaging etc.

I understood Graeme's system is also for schools but handles the
actual learning material which makes it different.
Yet I believe it also has high performance requirements and must
handle heavy load.

My employer (StarSoft, Finland) system is compiled with both Delphi
and FPC, on Windows and Linux.
Porting the code for Unicode so it still works with both Delphi and
FPC is a challenge. Uhhh!
I will not tell more or I will reveal company secrets.

Regards,
Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal