Re: [fpc-pascal] TypeInfo question

[Sven Barth via fpc-pascal]

Am 24.03.2017 03:51 schrieb "Ryan Joseph" :
> Is there anyway I could push the type checking to runtime? I wanted to
using writeln also to perform some printing for debugging but I get stuck
at compile time again trying to mix, integers, strings, records, classes
etc… in the generic. I would use an interface but there are compiler types
and records involved so that’s not an option.
>
> type
> TLongIntMatrix = specialize TMatrix;
> TObjectMatrix = specialize TMatrix;
>
>
> function TMatrix.RetainValue (value: T): T;
> begin
> if typeKind = tkClass then
> TObject(value).Retain;
>
> result := value;
> end;
>

You could try to do it with a pointer:

PObject(@value)^.Retain;

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

Re: [fpc-pascal] Delphi for Linux is out

[Sven Barth via fpc-pascal]

On 23.03.2017 18:35, Florian Klämpfl wrote:
> Am 23.03.2017 um 16:47 schrieb Mattias Gaertner:
>> On Thu, 23 Mar 2017 16:08:20 +0100 (CET)
>> Michael Van Canneyt  wrote:
>>
>>> [...]
 When did FPC start to run on Linux? 1999?  
>>>
>>> I got the first "hello world" around 1995-1996, I think, 
>>> together with Mark May. (if memory serves well)
>>
>> Well, Delphi didn't start with a "Hello World". So that would be a
>> little unfair as comparison.
>> What about the time when FPC was able to compile itself?
> 
> 9th august 1996 :)
> 
> Mail from Michael:
[...]
>> I think we should synchronise our versions of the compiler. I've put a list
>> of changes at the end of this mail, so you can update your sources.
>> before you release the next version of the compiler, I think it would be
>> nice if you send me the sources, so I can try to compile them under Linux.
>> This way we can always keep the DOS and Linux version synchronised.

I take it this was before a version control system was used? :P

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

Re: [fpc-pascal] Delphi RTTI vs Free Pascal RTTI

[Sven Barth via fpc-pascal]

Am 24.03.2017 19:55 schrieb "Michael Van Canneyt" :
>
>
>
> On Fri, 24 Mar 2017, African Wild Dog wrote:
>
>> Hello,
>>
>> I need to write a code compatilble with both free pascal and delphi using
>> the old style RTTI.
>> What are the diferences between delphi's and free pascal's
approach/types?
>>
>> I took a look at delphi's and fpc's TypInfo unit and it looks like the
>> types/functions are compatible.
>
>
> They are. There is one dereference on Delphi which is not present in fpc,
> although in fpc trunk, this additional dereference is there. If you use
the
> standard functions you should not notice this.

The binary data of RTTI added before 3.1.1 now has the double indirection,
but the Delphi-compatible "field" names have only a single indirection for
backwards compatibility (they are properties to the double indirection
fields). RTTI data added in 3.1.1 only has the double indirection.
So this difference needs to be kept in mind and will always result in
ifdefs for RTTI code that handles both Delphi and FPC.

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

Re: [fpc-pascal] TypeInfo question

[Sven Barth via fpc-pascal]

Am 23.03.2017 16:29 schrieb "Ryan Joseph" :
>
> I have some generics which operate on multiple types and instead of
making subclasses for certain types and overriding methods I wonder if
using the RTTI like:
>
> PTypeInfo(TypeInfo(T))^.kind = tkClass
>
> would be a good idea. How is TypeInfo() implemented exactly? I’m curious
if there are any string comparing, allocating memory etc... that would
adversely affect performance since these classes need to perform fast data
lookups/insertions.

TypeInfo() simply inserts the load of a pointer value, so there's not even
a call.

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

Re: [fpc-pascal] Delphi for Linux is out

[Sven Barth via fpc-pascal]

Am 23.03.2017 13:05 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> Hi,
>
> Just thought I would mention, yesterday Delphi 10.2 was released which
> includes Linux support (I assume a cross-compiler). It is only available
> in the Enterprise edition product line though, and only Linux Server
> style apps are supported (no GUI/desktop apps).

In the end you'll just need the correct units to do GUI applications as
well though one would need to do everything by hand as there'd be no VCL or
FM :P

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

Re: [fpc-pascal] Forward Generic Type Declaration Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 23:27 schrieb "African Wild Dog" <paintedlyc...@gmail.com>:
>
> 2017-03-18 18:40 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:
>>
>> Forward declarations for generic types are not supported.
>
> Are there plans for add suport for this in fpc 3.2?

No, there are not.

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

Re: [fpc-pascal] Forward Generic Type Declaration Bug

[Sven Barth via fpc-pascal]

Am 19.03.2017 00:02 schrieb "Bart" <bartjun...@gmail.com>:
>
> On 3/18/17, Sven Barth via fpc-pascal <fpc-pascal@lists.freepascal.org>
wrote:
>
> > Forward declarations for generic types are not supported.
>
> But it should not give an internal error.

With that I agree. Would you please check with 3.1.1 and if it's still the
case there report a bug so that this isn't forgotten?

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

Re: [fpc-pascal] Interface Inheritance Bug

[Sven Barth via fpc-pascal]

Am 19.03.2017 05:07 schrieb "African Wild Dog" :
>
> Hello,
>
> Test env: debian jessie amd64 - fpc 3.0.2
>
> It seems free pascal have a bug when handling interface inheritance using
generics.
>
> When i try to compile the unit bellow, i get this error:
>
> "interface_bug.pas(41,44) Error: Incompatible types: got
"TImplementor" expected "IParentInterface""

I think this will happen with non-generic interfaces as well. So please
test with those and if possible also with 3.1.1 and report a bug if
necessary (preferable with a non-generic example, makes things easier to
debug ;) ).

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

Re: [fpc-pascal] Forward Generic Type Declaration Bug

[Sven Barth via fpc-pascal]

Am 19.03.2017 11:30 schrieb "Bart" <bartjun...@gmail.com>:
>
> On 3/19/17, Sven Barth via fpc-pascal <fpc-pascal@lists.freepascal.org>
wrote:
>
> >> But it should not give an internal error.
> >
> > With that I agree. Would you please check with 3.1.1 and if it's still
the
> > case there report a bug so that this isn't forgotten?
>
> A quick search in the bugtracker for this IE showed:
> http://bugs.freepascal.org/view.php?id=26452 (Internal error
> 2012101001 with forward template declaration).
> It's the same issue I guess?

Yes. Thank you for checking.

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

Re: [fpc-pascal] rtl-generics vs fgl

[Sven Barth via fpc-pascal]

Am 19.03.2017 10:10 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> Hi,
>
> Sorry if this is a silly question, I didn't really follow Generics
> discussions in the past. If the "rtl-generics" package a replacement for
> the fgl unit?

The fgl unit is more lightweight while rtl-generics might provide better
performance.

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

Re: [fpc-pascal] Interface Inheritance Bug

[Sven Barth via fpc-pascal]

Am 19.03.2017 17:55 schrieb "African Wild Dog" <paintedlyc...@gmail.com>:
>
> 2017-03-19 5:25 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:
>>
>> I think this will happen with non-generic interfaces as well. So please
test with those and if possible also with 3.1.1 and report a bug if
necessary (preferable with a non-generic example, makes things easier to
debug ;) ).
>
>
> With non-generic types there is a workaround: cast to parent interface:
>
> ...
>
> ParentImplementorInstance := TImplementor.Create as IParentInterface;

But without the cast you get the same error, yes?

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

Re: [fpc-pascal] Forward Generic Type Declaration Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 19:20 schrieb "African Wild Dog" :
>
> Hello,
>
> Please confirm if this is a bug.
>
> When I try to compile the unit below I get the error:
>
> "generics_bug.pas(14,43) Fatal: Internal error 2012101001"
>
> It seems the compiler has bug when handling forward generics declaration.

Forward declarations for generic types are not supported.

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

Re: [fpc-pascal] Generics Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 19:55 schrieb "African Wild Dog" :
>
> Hello,
>
>
> Please confirm this bug.
>
> The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
>
> "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<" found"
>
> === CODE  ===
>
> unit generics_bug;
>
> {$mode delphi}
>
> interface
>
> type
>
>   TPair = record
> Key: TKey;
> Value: TValue;
>   end;
>
>   TEnumerator = class
>   end;
>
>   TGenericClass = class(TEnumerator>)
>   end;
>
> implementation
>
> end.
>
> ===

Nested specializations are currently not supported though they *might* work
with 3.1.1.

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

Re: [fpc-pascal] Generics Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 22:41 schrieb "Sven Barth" :
>
> Am 18.03.2017 19:55 schrieb "African Wild Dog" :
> >
> > Hello,
> >
> >
> > Please confirm this bug.
> >
> > The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
> >
> > "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<"
found"
> >
> > === CODE  ===
> >
> > unit generics_bug;
> >
> > {$mode delphi}
> >
> > interface
> >
> > type
> >
> >   TPair = record
> > Key: TKey;
> > Value: TValue;
> >   end;
> >
> >   TEnumerator = class
> >   end;
> >
> >   TGenericClass = class(TEnumerator>)
> >   end;
> >
> > implementation
> >
> > end.
> >
> > ===
>
> Nested specializations are currently not supported though they *might*
work with 3.1.1.

Note: "they" in the sense of "this specific case".

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

Re: [fpc-pascal] Setting record values

[Sven Barth via fpc-pascal]

Am 04.04.2017 05:25 schrieb "Ryan Joseph" :
>
> Thanks for the tips, I appreciate it.
>
> This is all pretty trivial but it’s kind of annoying that using an inline
class function is more efficient than a constructor despite having
identical functionality. It's tempting to remove the constructors now and
replace them with inline functions but it seems like the compiler should be
smarter and make this optimization for me.

At least for classes and objects the constructor is a bit more complicated
(especially the former ones), so that may be the reason that nothing is
done there for record constructors either. I'll check whether I can at
least get them to paricipate in auto inlining so that they would at least
be automatically inlined at higher optimization levels.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 04.04.2017 06:55 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Apr 2, 2017, at 11:02 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > can be easily seen by looking at the implementation of SetLength() in
> > $fpcdir/rtl/inc/dynarr.inc, fpc_dynarray_setlength().
> > Especially since line 220 (at least in the current revision) contains a
> > call to FillChar(), the whole ordeal can only be *more* complex than
> > FillChar().
>
> That’s good to know about SetLength.
>
> Is it possible use FillChar on a multidimensional arrays?
>
> arr: array of array of array of integer.
> SetLength(arr, 3, 3, 3);
> FillChar(arr[0], (3*3*3)*sizeof(integer), false);
>
> I’m just getting crashes.

That does only work with static arrays as dynamic arrays are in reality
managed pointers, thus you override the pointers themselves with your
FillChar. Not to mention that you're overwriting the memory behind the
outermost array as that only has a size of Length(arr) * SizeOf(Pointer).

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 04.04.2017 12:52 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> On 02/04/17 10:00, Jonas Maebe wrote:
>
>> Allocating new memory via setlength also clears the memory (+ the
>> overhead of allocating the memory).
>
>
> Jonas, is it still the case that if SetLength() results in existing data
being moved that the original- which might be e.g. an unencrypted password-
isn't cleared?

The reallocation is delegated to the memory manager, thus SetLength() can
not know what is really done with the data area.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 04.04.2017 13:55 schrieb "Ryan Joseph" :
>
>
> > On Apr 4, 2017, at 4:58 PM, Howard Page-Clark via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > You can always use FillChar and its kin on specific 'nested' arrays
like this
> >
> > type
> >  TIntArray = array of Integer;
> >  TIntIntArray = array of TIntArray;
> >  TIntIntIntArray = array of TIntIntArray;
> >
> >  procedure FillArray(const anArray: TIntIntIntArray; aValue: DWord);
> >  var
> >x, y: integer;
> >  begin
> >for x:=0 to High(anArray) do
> >  for y:=0 to High(anArray[x]) do
> >FillDWord(anArray[x][y][0], Length(anArray[x][y]), aValue);
> >  end;
>
> Doesn’t iterating the array default the purpose of FillChar? The goal was
the most efficient way clear the array with zero’s. Even if the array if
nested 3 levels deep (anArray[x][y][z]) it should (I hope) be a contiguous
block of memory that was allocated (correct me if I wrong please).
>

As I wrote that isn't the case. Each dynamic array is allocated
independently (and thus you could also resize each subelement
independently).

If you want continuous memory areas you need to use static arrays or
develop your own dynamic data structure that uses array properties.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 04.04.2017 15:40, Ryan Joseph wrote:
> 
>> On Apr 4, 2017, at 7:17 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> If you want continuous memory areas you need to use static arrays or develop 
>> your own dynamic data structure that uses array properties.
>>
>>
> 
> I’m glad I asked because of arrays of pointers is bad news for performance. 
> Does SetLength on a single level dynamic array not even allocate a continuous 
> block of memory? I could use GetMem and array[0..0] but it seems like dynamic 
> arrays should do basically that anyways if they’re not nested.

SetLength() allocates a single block of memory, cause array access is
ordinary pointer arithmetic. However if you have an array of array then
the first array stores a pointer to each sub array.

E.g. the following would be valid, too:

=== code begin ===

var
  arr: array of array of Integer;
begin
  SetLength(arr, 10, 10);
  SetLength(arr[3], 5);
  arr[6] := Nil;
  SetLength(arr[8], 15);
end.

=== code end ===

Regards,
Sven

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 04.04.2017 15:40, Ryan Joseph wrote:
> 
>> On Apr 4, 2017, at 7:17 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> If you want continuous memory areas you need to use static arrays or develop 
>> your own dynamic data structure that uses array properties.
>>
>>
> 
> I’m glad I asked because of arrays of pointers is bad news for performance. 
> Does SetLength on a single level dynamic array not even allocate a continuous 
> block of memory? I could use GetMem and array[0..0] but it seems like dynamic 
> arrays should do basically that anyways if they’re not nested.

You could use something along these lines instead:

=== code begin ===

program tarrtest;

{$mode objfpc}
{$modeswitch advancedrecords}

type
  generic TTwoDimArray = record
  private
fData: array of T;
{ Note: Length1 and Length2 are not initialized by default, but you
could use trunk's management operators for that }
fLength1,
fLength2: LongInt;
function GetElement(Index1, Index2: LongInt): T; inline;
procedure SetElement(Index1, Index2: LongInt; aValue: T); inline;
  public
{ using SetLength() would lead to us needing to use
  "System.SetLength()" for the array which in turn would complain
  about usage of the static symtable; that's a problem that yet
  needs to be solved inside generics, for non-generics that would
  work however }
procedure AdjustLength(aLength1, aLength2: LongInt);
property Length1: LongInt read fLength1;
property Length2: LongInt read fLength2;
property Element[Index1, Index2: LongInt]: T read GetElement write
SetElement; default;
  end;

{ TTwoDimArray }

function TTwoDimArray.GetElement(Index1, Index2: LongInt): T;
begin
  { ToDo: Length check }
  Result := fData[Index1 * fLength1 + Index2];
end;

procedure TTwoDimArray.SetElement(Index1, Index2: LongInt; aValue: T);
begin
  { ToDo: Length check }
  fData[Index1 * fLength1 + Index2] := aValue;
end;

procedure TTwoDimArray.AdjustLength(aLength1, aLength2: LongInt);
begin
  SetLength(fData, aLength1 * aLength2);
  fLength1 := aLength1;
  fLength2 := aLength2;
end;

var
  arr: specialize TTwoDimArray;
  i: LongInt;
begin
  arr.AdjustLength(10, 5);
  i := arr[3, 2];
  arr[7, 1] := i;
end.

=== code end ===

Regards,
Sven

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 04.04.2017 16:54, Ryan Joseph wrote:
> 
>> On Apr 4, 2017, at 9:46 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> SetLength() allocates a single block of memory, cause array access is
>> ordinary pointer arithmetic. However if you have an array of array then
>> the first array stores a pointer to each sub array.
>>
>> E.g. the following would be valid, too:
>>
>> === code begin ===
>>
>> var
>>  arr: array of array of Integer;
>> begin
>>  SetLength(arr, 10, 10);
> 
> “then the first array stores a pointer to each sub array.”
> 
> Could you illustrate this is code? I don’t think I’m understanding this 
> exactly like it’s represented in memory. There’s only one “sub array” in this 
> 2x2 array so how does that look in memory?

Let's look at a smaller array, let's say 3 x 4, then it would look like
this:

arr = @arr[0], @arr[1], @arr[2]

arr[0] = 0, 0, 0, 0
arr[1] = 0, 0, 0, 0
arr[2] = 0, 0, 0, 0

Essentially you'd have four arrays, namely the outer array arr which
basically contains pointers to the other arrays, and the inner arrays
which are each three separate four element arrays. So all four of these
arrays could reside at completely different locations of the heap.

Is this clearer?

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 04.04.2017 16:27, Ryan Joseph wrote:
>>> Does SetLength on a single level dynamic array not even allocate a 
>>> continuous block of memory?
>>
>> Yes, it does (as explained in all the other mails).
>> A (dynamic) array of integer will be allocated as a single block by 
>> SetLength.
>> So if you only have one level of a dynamic array as in
>>
>> var MyArray : array of integer;
>>
>> then SetLength(MyArray,1000) will allocate a single block of 1000 integers.
>> But with
>>
>> var MyArray : array of array of integer;
>>
>> SetLength(MyArray,1000);
>>
>> will allocate a single block of 1000 pointers (to an array of integer each).
>> Then, SetLength(MyArray[0],1000) will allocate one (!) block of 1000 
>> integers.
>> SetLength(MyArray[1],1000) will allocate another block of 1000 integers and 
>> so on….
> 
> I was allocating using SetLength(MyArray, 3, 3, 3) for a 3x3x3 matrix for 
> example. Maybe it depends on the memory manager and the state of heap but if 
> you called early in the programs execution it should be allocate all that 
> memory in one block I would think. 

While your statement regarding allocation might be true you must not
forget that a dynamic array consists of a meta data block (length,
reference count) that is located directly in front of the data block. So
even if the memory blocks would be allocated consecutively then there'd
still be the meta data blocks inbetween.

If you already know that your dynamic arrays only have a specific size
(for matrices used in games that should usually be the case) then you're
better off with using a static array:

=== code begin ===

type
  TMatrix = array[0..2, 0..2, 0..2] of LongInt;

=== code end ===

There you can use FillChar() as much as you want as that is indeed a
single memory block containing 9 LongInt elements.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 04.04.2017 16:27, Ryan Joseph wrote:
>>> Does SetLength on a single level dynamic array not even allocate a 
>>> continuous block of memory?
>>
>> Yes, it does (as explained in all the other mails).
>> A (dynamic) array of integer will be allocated as a single block by 
>> SetLength.
>> So if you only have one level of a dynamic array as in
>>
>> var MyArray : array of integer;
>>
>> then SetLength(MyArray,1000) will allocate a single block of 1000 integers.
>> But with
>>
>> var MyArray : array of array of integer;
>>
>> SetLength(MyArray,1000);
>>
>> will allocate a single block of 1000 pointers (to an array of integer each).
>> Then, SetLength(MyArray[0],1000) will allocate one (!) block of 1000 
>> integers.
>> SetLength(MyArray[1],1000) will allocate another block of 1000 integers and 
>> so on….
> 
> I was allocating using SetLength(MyArray, 3, 3, 3) for a 3x3x3 matrix for 
> example. Maybe it depends on the memory manager and the state of heap but if 
> you called early in the programs execution it should be allocate all that 
> memory in one block I would think. 

Addendum: If you look at fpc_dynarray_setlength() again then you'll see
at line 289 that it's calling itself recursively for nested arrays.

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

Re: [fpc-pascal] Questions About Constructors

[Sven Barth via fpc-pascal]

Am 31.03.2017 19:27 schrieb "African Wild Dog" :
>
> 2017-03-30 4:25 GMT-03:00 Michael Van Canneyt :
>>
>>
>>
>> On Thu, 30 Mar 2017, African Wild Dog wrote:
>>
>>> Hello,
>>>
>>> 1 - What happens if my constructor raise an exception? Is my destructor
>>> automatically called?
>>
>>
>> Yes.
>>
>>>
>>> 2 - Are the class fields automatically initialized to Default(T) just
like
>>> in Delphi?
>>
>>
>> Yes. The're zeroed out when the memory for the class is allocated.
>>
>
> Thanks for the clarification.
> I've issued #0031619  to add these details in the documentation.

Keep in mind however that the second behavior can be changed by overriding
TObject.NewInstance (the default implementation allocates the memory of the
class and zeroes it).

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

Re: [fpc-pascal] Setting record values

[Sven Barth via fpc-pascal]

On 01.04.2017 09:59, Ryan Joseph wrote:
> 
>> On Apr 1, 2017, at 2:46 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> I haven't looked at it in detail, but it could be that both have similar 
>> efficiency. You could also add "inline" to the MakePoint function which 
>> should get rid of a potential temporary variable if the compiler doesn't do 
>> that already anyway.
>> Alternatively you could also declare a constructor "TPoint.Make" or so (that 
>> despite its name doesn't do any dynamic memory allocation either) which you 
>> can declare as inline as well.
> 
> How is the constructor any different from the function?

In case of constructor vs. global function the encapsulation is more clear.
In case of constructor vs. class function there isn't really that much
difference except that through the name alone ("constructor blabla")
it's clear what the purpose of the function should be.

(Though I now also noticed that you can't use "inline" with constructors...)

>>
>> In the end you can always check the assembler code.
> 
> Not sure how to do that or what to look for. It appears to me without knowing 
> how the compiler works that there would be some allocating and copying of 
> memory which is more overhead than assigning a value directly. Maybe it’s 
> totally trivial but if it is it’s something I should cut out of my design 
> going forward.

The compiler keeps the assembler code with line information around if
you pass "-al".

If you are so concerned about the differences in performance regarding
using a setter and a construction function you should really learn at
least in principle how typical assembler code generated by the compiler
looks like (same for your query about dynamic arrays by the way, though
there you should also take a look at the implementation of the RTL).

Here is an example compiled without optimizations aside from inline:

=== code begin ===

# [47] p.(42, 21);
movq$U_$P$TRECFUNCS_$$_P,%rax
movl$21,%edx
movl$42,%esi
movq%rax,%rdi
callP$TRECFUNCS$_$TPOINT_$__$$_SET$LONGINT$LONGINT
# [48] p := TPoint.Make(42, 21);
leaq-8(%rbp),%rdi
movl$21,%edx
movl$42,%esi
callP$TRECFUNCS$_$TPOINT_$__$$_MAKE$LONGINT$LONGINT$$TPOINT
movq-8(%rbp),%rax
movq%rax,U_$P$TRECFUNCS_$$_P
# [49] p := TPoint.Make2(42, 21);
movl$42,U_$P$TRECFUNCS_$$_P
movl$21,U_$P$TRECFUNCS_$$_P+4
# [50] p := MakePoint(42, 21);
movl$21,%esi
movl$42,%edi
callP$TRECFUNCS_$$_MAKEPOINT$LONGINT$LONGINT$$TPOINT
movq%rax,U_$P$TRECFUNCS_$$_P
# [51] p := MakePoint2(42, 21);
movl$42,U_$P$TRECFUNCS_$$_P
movl$21,U_$P$TRECFUNCS_$$_P+4

=== code end ===

"" is essentially your "SetPoint" method. "Make" is a constructor.
"Make2" is a static class function with "inline". "MakePoint" is your
creation function and "MakePoint2" is the same with an inline modifier.

As you can see the two inline variants ("Make2" and "MakePoint2") are
the most effective as there's no call and only the two loads of the values.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

On 02.04.2017 11:22, Ryan Joseph wrote:
> 
>> On Apr 1, 2017, at 9:25 PM, Jürgen Hestermann  
>> wrote:
>>
>> If you just need to reuse the same array and only need to zero its elements
>> then of course fillchar would be the fastest approach (it saves the memory
>> reallocation step).
> 
> Why is this “of course”? What’s the implementation of FillChar exactly? For 
> all I know it has to iterate over a range of bytes and this could be slower 
> than allocation of memory. Maybe some of the compiler people know these 
> details.

The question is not about the implementation of FillChar. It's about
reallocating a dynamic array as to reallocate it you'd need to do

=== code begin ===

SetLength(arr, 0);
SetLength(arr, newlen);

=== code end ===

And that this is more complex than

=== code begin ===

FillChar(arr, SizeOf(arr[0]) * Length(arr), 0);

=== code end ===

can be easily seen by looking at the implementation of SetLength() in
$fpcdir/rtl/inc/dynarr.inc, fpc_dynarray_setlength().
Especially since line 220 (at least in the current revision) contains a
call to FillChar(), the whole ordeal can only be *more* complex than
FillChar().

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 05:42 schrieb "Ryan Joseph" :
>
> As far as the compiler is concerned what’s the difference between
clearing an array using a for-loop vs. FillChar? It seems like iterating
the array would be slower but what does FillChar do exactly and is it
faster? The primary concern here is that the memory originally allocated
(using SetLength right?) remains in the same location.
>
> var
>   list: array of integer;
>
> SetLength(list, 10);
>
> for i := 0 to high(list) do
>   list[i] := 0;
>
> FillChar(list[0], Length(list) * sizeof(integer), 0);

It totally depends on the type. In case of primitive types like integers
there is indeed only the performance difference (though if you know that
the element size is four FillDWord could be even faster, depending on the
implementation in the RTL).
If you have managed types however or class instances the result of the
FillChar (or equivalent) would be memory leaks.

Plase also note that after a SetLength the new elements are already 0 (or
equivalent).

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

Re: [fpc-pascal] Setting record values

[Sven Barth via fpc-pascal]

Am 01.04.2017 05:59 schrieb "Ryan Joseph" :
>
> I’ve been using a design pattern in my code which I think is probably
pretty stupid so I’d like to make sure. Assume I have a type like TPoint
below and I want to set the value I’ll doing something like point :=
PointMake(x, y). How does the compiler handle this? It probably has to
allocate some memory on the heap so shouldn’t I always be setting values
using the alternative TPoint.SetPoint? It’s maybe not a big deal but it’s
something I’d like to clear up if it’s inefficient.

Records are only located on the stack (or in case of global variables the
data sections). If you want them on the heap then you'd need to explicitly
do that using pointers.

> function PointMake (_x, _y: integer): TPoint;
> begin
>   result.x := _x;
>   result.y := _y;
> end;
>
> procedure TPoint.SetPoint (_x, _y: integer);
> begin
>   x := _x;
>   y := _y;
> end;
>
> same outcome but which is more efficient?

I haven't looked at it in detail, but it could be that both have similar
efficiency. You could also add "inline" to the MakePoint function which
should get rid of a potential temporary variable if the compiler doesn't do
that already anyway.
Alternatively you could also declare a constructor "TPoint.Make" or so
(that despite its name doesn't do any dynamic memory allocation either)
which you can declare as inline as well.

In the end you can always check the assembler code.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 10:35 schrieb "Ryan Joseph" :
>
>
> > On Apr 1, 2017, at 2:50 PM, Ryan Joseph 
wrote:
> >
> > Yeah, I was concerned with just compiler types or weakly retained
classes where I’m just keeping the reference.
>
> Another question. Is it more efficient/faster to reallocate a new array
of the same size or call FillChar on the existing array?

I think that FillChar should be faster as reallocating would need setting
the array to Nil and recreating it (SetLength with the same length won't
touch the existing elements) thus loosing any gain of reallocate and then
there'd still be the internal FillChar of the array.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 13:31 schrieb "Jürgen Hestermann" :
>
> I am wondering what the purpose of filling all
> array elements with zero's could be.
> If I want to discard all elements I would simply delete
> the whole array (setlength(MyArray,0) ).
>
> But when should it be useful to keep all elements and
> just overwrite them all with zero's (which is also very time consuming)?
> If the exisiting values are no longer valid then why not
> simply delete these elements?
> It's the fastest way to get rid of them.
> If elements were zero before overwriting them with zero's
> I cannot even distinguish between original and overwritten elements.
>

If you wouldn't change the size of the array then merely doing FillChar (if
not working with managed types) is more performant then freeing the array
and allocating it again (which will also zero out the elements).
Normally the performance difference isn't *that* important, but sometimes
that difference can make or break something.

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

Re: [fpc-pascal] Constants in generics

[Sven Barth via fpc-pascal]

Am 12.04.2017 17:06 schrieb :
>
> On 2017-04-09 06:32, Ryan Joseph wrote:
>>>
>>> On Apr 9, 2017, at 6:13 PM, Maciej Izak  wrote:
>>>
>>> sure, but not directly. Try this:
>>
>>
>> Thanks, that’s a seriously funky hack but it works. :) The only
>> downside is you need to define types every time you need a different
>> size.
>>
>> Is this a known feature request or anything on the to-do list for the
>> compiler team? There’s no way to extend the functionality of static
>> arrays in Pascal and this would accomplish that well.
>>
>
> The only way I can think of extending the functionality of a array is to
put it into an old borland object (on the stack) but that may not be what
you are looking for. Then you can give the array methods, effectively,
possibly reinventing TStringList ;-) and that array can be fixed, dynamic,
whatever. But as for generics, no, old borland style objects are not going
to be generic - so this email of mine is likely completely and utterly
irrelavent to your problem  domain :-)
>

Generic TP-style objects are supported in FPC, but you can use advanced
records (which allow methods as well as management operators) as well.

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

Re: [fpc-pascal] WebAssembly Target

[Sven Barth via fpc-pascal]

Am 12.04.2017 16:10 schrieb :
> Why run webgl through javascript if you could just make something like a
flash plugin object (like youtube videos) that plays opengl scenes using
some native format similar to how flash uses SWF files, or whatever?

Because the point is not to need some strange, obscure plugin that works
only on a subset of the platforms the browser supports when the script
engine of the browser is powerful enough to do it itself.

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

Re: [fpc-pascal] sqldb create/free lifetime of object

[Sven Barth via fpc-pascal]

Am 12.04.2017 14:32 schrieb :
> In a way, this is a form of garbage collection or RAII sort of. And
reduces the obnoxious free's required in non garbage collected programming
languages... So it's a nice feature/trick to have ownership. But at the
same time you can think there is a memory leak since there is no
create/free pair easily visible...
>
> So you train your eyes to look for ownership.
>
> And similarly, delphi gui widgets you throw onto a form, don't need to be
freed yourself, even though the program created them - so in a way delphi
TForm's gui widgets are also garbage collected, sort of. Again a nice
feature/trick to avoid all the obnoxious free calls that bloat up the
source code with line noise.

Both are in fact using the same mechanism as you can put e.g. a
TSQLTransaction on a form as well.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 12.04.2017 16:51 schrieb "Ryan Joseph" :
>
>
> > On Apr 12, 2017, at 9:25 PM, Michael Van Canneyt 
wrote:
> >
> > Adding a pop/push requires compiler magic, and could be implemented;
but the question is whether it is worth it, given the plethora of other
> > options at your disposal.
>
> Why magic? It seems silly the operator += doesn’t exist or even a basic
operation set like “add”, “remove”, “insert” that every array
implementation in every language has. Aren’t those just function around the
existing dynamic array implementation in the compiler?

Delete() is already supported in trunk, Insert() and the +-operator (or
Concat()) are on the near term ToDo list (mainly out of Delphi
compatibility, though I definitely agree with their existence).

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

Re: [fpc-pascal] Out of scope method?

[Sven Barth via fpc-pascal]

Am 06.04.2017 11:58 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Apr 6, 2017, at 4:26 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > It's a difficult topic, cause in Object Pascal class instances are
always on the heap while in C++ they might be on the stack as well. Thus a
C++ compiler will insert calls to the destructor of such an object if it
goes out of scope.
> >
> > In Object Pascal currently only reference counted interfaces and (new
in trunk) records with management operators provide this feature.
>
> I see, but since there is a reference to an instance on the stack
wouldn’t it be trivial for the compiler to invoke a method on TObject
descendants when they go out of scope? If it does it for compiler types
like dynamic arrays I imagine it could do the same for classes.

Arrays are reference counted, class instances are not. So if the compiler
would blindly free the instance after it goes out of scope if might free
something that another code part still uses.

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

Re: [fpc-pascal] Get value of PPChar ?

[Sven Barth via fpc-pascal]

Am 17.04.2017 00:47 schrieb "fredvs" :
>
> Free Pascal - General mailing list wrote
> > According to the code it also returns 0 with icy_meta being Nil if there
> > is no corresponding data:
> >
https://github.com/georgi/mpg123/blob/master/src/libmpg123/libmpg123.c#L1384
>
> Ha, nice, you did find the only doc available : the source code (that
> contains no comment, of course ;-) )
>
> Yep, this would solve everything.
> In fact solve nothing because the code was ok then ;-)

No, your "var PPChar" was still wrong. It's either "var PChar" or "PPChar"
and nothing else.

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

Re: [fpc-pascal] Get value of PPChar ?

[Sven Barth via fpc-pascal]

On 16.04.2017 18:52, fredvs wrote:
> Free Pascal - General mailing list wrote
>> function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PChar): Integer;
>> cdecl;
> 
> Thanks for your answer.
> 
> I did try with this but :
> 
>  res := mpg123_icy(mph,theicytag);
>  
> if (res = 0) then writeln('resu = ' + inttostr(res));  // OK = 0
> 
> if Assigned(theicytag) then writeln('theicytag = assigned')
> else writeln('theicytag NOT assigned') ; /// always theicytag NOT assigned

According to the code it also returns 0 with icy_meta being Nil if there
is no corresponding data:
https://github.com/georgi/mpg123/blob/master/src/libmpg123/libmpg123.c#L1384

Regards,
Sven

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 13.04.2017 13:25 schrieb "MARCOU Gilles" :
>
> Regarding this code:
>
>> SetLength(Array,Length(Array)+1);
>> Array[High(Array)] := …
>
>
> as I understood from (http://wiki.freepascal.org/Dynamic_array),
SetLength will create a copy of the array and free the memory of the
shorter array. In this case, a lot of memory operations and copy operations
are performed thus degrading the performances of the code. Then it would be
unwise to use such strategy: better allocate the size of the array
correctly at the beginning of the run, or resize the array by block, to
decrease the frequency of such operation:
>
>> SetLength(Array,Length(Array)+N);
>
>
> Can somebody confirm (or invalidate) this?

SetLength() uses reallocation for the memory. So it *might* work without
copying though that is not guaranteed.
But in general it's recommended anyway not to do "SetLength(..., ... + 1)"
loops as that will lead to fragmentation of the heap.

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

Re: [fpc-pascal] Threading vs Parallelism ?

[Sven Barth via fpc-pascal]

Am 14.04.2017 09:23 schrieb "Michael Schnell" :
>
> On 12.04.2017 14:09, Lars wrote:
>>
>> If unix could just make processes even lighter weight or
>> faster loading, I might avoid threads and just use processes...
>
> in Unix/Linux processes are not less "light" then threads. You can create
a process by "fork". no "Loading" involved. it just creates the process. If
you want to have the new process execute any code that is not shared with
the you need to do another system call to replace the code with the new
one. Moreover even if "loading" new code - in case another process already
runs this file, no actual loading  takes place, either, as the memory
management just uses the code page already in RAM.
>
> This definitively is as light as it gets.

A process definitely is less "light" than threads even on Unix systems: a
process has its own address space (even if it shares all pages with its
parent process) and also structures keeping track of the used resources
(e.g. open file descriptors). A thread does not need all this as it always
shares the same address space and the same resources.
Why do you think the concept of threads was introduced in Unix? Early Unix
systems only had processes.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 13.04.2017 14:47 schrieb "Ryan Joseph" :
>
>
> > On Apr 13, 2017, at 7:08 PM, Mattias Gaertner 
wrote:
> >
> >> as I understood from (http://wiki.freepascal.org/Dynamic_array<
http://wiki.freepascal.org/Dynamic_array>), SetLength will create a copy of
the array and free the memory of the shorter array. In this case, a lot of
memory operations and copy operations are performed thus degrading the
performances of the code.
> >
> > Correct.
>
> Why is it copying the array and freeing instead of resizing the existing
block (realloc)? That sounds crazy but I don’t know how memory managers
work.

SetLength *does* use a reallocate for this, but since it doesn't give you
any guarantee for its success as its the task of the memory manager to deal
with this, it's easier to assume that the array is indeed copied.

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

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 13.04.2017 18:06 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Apr 13, 2017, at 10:29 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > SetLength *does* use a reallocate for this, but since it doesn't give
you any guarantee for its success as its the task of the memory manager to
deal with this, it's easier to assume that the array is indeed copied.
> >
>
> So the real point here is that ReAllocMem will copy and allocate a new
block if the old one can’t be resized, therefore this really isn’t about
SetLength as much as the memory manager itself.

Correct. And since the memory manager is changeable and might implement
whatever behavior it wants nothing fixed can be done for this.

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

Re: [fpc-pascal] Can class function used in specialized class use intristic functions Low, High with generic type ?

[Sven Barth via fpc-pascal]

Am 20.04.2017 13:02 schrieb "LacaK" :
>
> Hi *,
>
> I have some generic class:
>
> generic T2DNumericArray = object(specialize T2DArray)
> public
>   class function Truncate(Value: double): T; inline;
>   ...
>
> In class function Truncate I want check if supplied Value is in range of
T.
> T will be always ordinal type (byte, integer) ... (I know this, but
compiler does not of course)
>
> Can I use in :
>
> class function T2DNumericArray.Truncate(Value: double): T;
> begin
>   if Value > High(T) then
> Result := High(T)
>   else if Value < Low(T) then
> Result := Low(T)
>   else
> Result := Value;
> end;
>
> I understand, that from compiler POV T can be any type, so High() and
Low() can be invalid, but I wonder if there is any way how to solve this.

The compiler will use dummy values while parsing the generic, but during
specialization it will use the correct ones. Though it might be that you'd
need 3.1.1 for it (dont know right now when I had fixed that).

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

Re: [fpc-pascal] Use a procedural type for declare a procedure\function

[Sven Barth via fpc-pascal]

Am 20.04.2017 08:44 schrieb "Andrey M, Zubarev" :
>
> Hi All,
>
> Why can't use procedural type for declare a procedure\function?
> Why ever allow the exact same signature? It's uncomfortable
> Maybe it makes sense to introduce into the language such a possibility?

No, that makes no sense. Function/procedures/methods are independent of of
function/procedure/message types, maybe even declared indifferent units not
related to each other and used together only in a third unit.

Also it would be harder to see easily which parameters a routine takes as
you'd need to check the corresponding type first.
(And if you now say that an IDE can help with that, well 1) not everyone
uses one and 2) the same could be said about your original problem)

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

Re: [fpc-pascal] Get value of PPChar ?

[Sven Barth via fpc-pascal]

On 16.04.2017 16:58, fredvs wrote:
> Hello.
> 
> A C method is defined like this:
> 
> MPG123_EXPORT int mpg123_icy(mpg123_handle *mh, char **icy_meta);
> 
> and translated in Pascal with this:
> 
> function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PPChar): integer;
> cdecl;

This is wrong. "var" essentially results in a "char***".

What you want is either

function mpg123_icy(mh: Tmpg123_handle; icy_meta: PPChar): integer; cdecl;

or

function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PChar): Integer;
cdecl;

And how you'll need to use it will depend upon the function's
documentation: if the function will allocate the buffer then you simply
need to pass in a PChar variable (second case) or a pointer to one
(first case). If you need to allocate the buffer yourself then you first
need to do a GetMem with an appropriate size before you do the same.

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

Re: [fpc-pascal] Can class function used in specialized class use intristic functions Low, High with generic type ?

[Sven Barth via fpc-pascal]

Am 22.04.2017 08:18 schrieb "Cyrax" :
> I think that this was the bug report and which you did fix back then :


Indeed it is :)

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 04.03.2017 16:06 schrieb "fredvs" :
>
> Hello.
>
> Is it possible to add a array of float into ressource ?
>
> For example, there is myarray : array of cfloat.
>
> Is it possible to store that array myarray ressource and, when I want to
use
> it from ressource, I get also a array of float ?
>
> In wiki : http://wiki.freepascal.org/Lazarus_Resources tey speak only how
to
> add files into ressource.

No, you can't. Resources are not intended for this.

What are you trying to achieve?

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 06.03.2017 13:42 schrieb "fredvs" :
>
> > I don't know. By all logic, it should not work either.
>
> Yes, it is I think too.
>
> Some more explanation:
>
> I use  a "global" buffer of float to store data.
> Those data can be int16, int32 or float32.
>
> For example,
>
> If data are integer (16 or 32 bit), I do:
>
> bufferfloat[x] := 127.0 ; (for int16)
>
> bufferfloat[x] := 2147483646.0; (for int32)
>
> If data are float 32 bit, I do:
>
> bufferfloat[x] := 0.2147483646 ; (for float32)
>
> So it seems to me Sizeof(bufferfloat[x]) is the same in the 3 cases (alway
> sizeof(float)).

Of course it's always the same size as it's an array of cfloat after all
and no assignment will change that.

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

On 06.03.2017 19:31, fredvs wrote:
>> Or, quite comically maybe: use a text file
> 
> Or maybe, like in my second post, convert float32 ---> integer32
> 
> for x := 0 to length(floatbuffer) -1 do 
>   begin 
>floatbuffer[x] := round(floatbuffer[x] * 2147483647); 
>if floatbuffer[x] > 2147483647 then floatbuffer[x] := 2147483647; 
>if floatbuffer[x] < -2147483647 then floatbuffer[x] := -2147483647; 
>   end; 
> 
> And do the reverse when reading from the file ?

I don't know what you're doing wrong, but the following works:

=== code begin ===

program tfloatbuf;

{$mode objfpc}

uses
  SysUtils, Classes, ctypes;

var
  fbuf: array of cfloat;
  i: LongInt;
  fs: TFileStream;
begin
  SetLength(fbuf, 42);
  for i := Low(fbuf) to High(fbuf) do
fbuf[i] := 3.1415;

  Writeln('Writing data to ', ParamStr(1));
  fs := TFileStream.Create(ParamStr(1), fmOpenWrite or fmCreate);
  try
fs.WriteBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
  finally
fs.Free;
  end;

  SetLength(fbuf, 0);
  SetLength(fbuf, 42);

  Writeln('Reading data from ', ParamStr(1));
  fs := TFileStream.Create(ParamStr(1), fmOpenRead);
  try
fs.ReadBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
  finally
fs.Free;
  end;

  for i := Low(fbuf) to High(fbuf) do
Writeln(fbuf[i]);
end.

=== code end ===

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 06.03.2017 22:45 schrieb "fredvs" :
>
> > I don't know what you're doing wrong, but the following works:
>
> Huh, it is exactly what I (think to) do.
> And re-reading hundred times my code does not see any difference.
>
> OK, I will re-read thousand times the code, maybe I will find what is
wrong.

Then try to minimize your code as much as possible and then show it here
(an as small as possible compileable example that shows your problem).

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 06.03.2017 23:57 schrieb "fredvs" :
>
> Re-hello.
>
> Ok, I do not find yet the guilty in my code, I will re-try a other day.
> By the way, your code is working perfectly Sven.
>
> Now, last part of the question: how to convert that file stored into
> ressource but without to write to the disk (only memory stream)?
>
> A TFileStream could be used but it needs a path.
> And in ressource there is no path to use in
> TFileStream.Create('/the/path/filename', fmOpenRead);
>
> What could be the solution ?

To access a file stored as a resource you need to use TResourceStream.

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 07.03.2017 13:49 schrieb "fredvs" :
>
> > To access a file stored as a resource you need to use TResourceStream.
>
> Ho my Dog, I did not know this one.
> More than perfect, many thanks Sven.
>
> PS: About array of float into TFileStream, after Googling a while, it s
not
> possible to do directly like fpc does for C compilers.
> You need a conversion (like explained by Lukasz Sokol).
> And it is the reason why I am (once again) very impressed by fpc.

Huh? Of course you can do that rather similary in C as well.

> Many thanks Sven for your help.
> Do you agree if I add your name into the list of the "great contributors"
of
> uos (https://github.com/fredvs/uos) ?
>

I don't think that's necessary. I'm merely doing my "job"...

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

Am 05.03.2017 18:33 schrieb "fredvs" :
>
> Hello.
>
> I have saved the buffer into file with a TFileStream.
>
> With lot of success for array of cint16 and cint32.
>
> But for array of cfloat --> much less success.

Define "much less success". How are you writing the array and how are you
reading it?

> Could it be that TFileStream does accept only integers as data ?
> If yes, a conversion would be needed ?

One can write and read any blob of data with the stream classes if one
knows what one is doing.

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

On 07.03.2017 22:39, fredvs wrote:
> OK, Sven you win (and http://stackoverflow.com should follow fpc forum).
> But you will not convince me that c does better than fpc, maybe equal but
> surely not better. 

Despite me definitely favoring Object Pascal as well, I can't you have
spreading incorrect information on C, can I? ;)

Regards,
Sven

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

Re: [fpc-pascal] Adding a array of float in ressource and use it ?

[Sven Barth via fpc-pascal]

On 07.03.2017 16:30, fredvs wrote:
>>> Many thanks Sven for your help.
>>> Do you agree if I add your name into the list of the "great contributors"
>>> of
>>> uos (https://github.com/fredvs/uos) ?
>> I don't think that's necessary. I'm merely doing my "job"...
> 
> OK, I understand. (But I ask it always when I get great help, it is a matter
> of conscience and respect.)
> 
>>> Huh? Of course you can do that rather similary in C as well.
>> Indeed. You can do exactly the same. You can do this: 
> 
> Huh in C, in one shot, like fpc does, without conversion and working?

The following code reads the floatbuf.txt file that my Pascal example
code generated and correctly prints 3.141500 42 times:

=== code begin ===

#include 

int main()
{
float* floatbuf;
FILE* file;

file = fopen("floatbuf.txt", "rb");
if (!file)
{
printf("Failed to open file\n");
return 1;
}

floatbuf = malloc(sizeof(float) * 42);
if (fread(floatbuf, sizeof(float), 42, file) != 42)
{
printf("Failed to read data\n");
fclose(file);
free(floatbuf);
return 1;
}

for (int i = 0; i < 42; i++)
printf("%f\n", (double)floatbuf[i]);

fclose(file);
free(floatbuf);

return 0;
}

=== code end ===

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

Re: [fpc-pascal] Out of scope method?

[Sven Barth via fpc-pascal]

Am 06.04.2017 10:32 schrieb "Ryan Joseph" :
>
> Does it exist now or has it ever been discussed that a method in TObject
could be called when an instance of an object goes out of scope? It’s
common to clean up objects in a function body after the function exits and
calling a method would be a nice way to handle this. I think c++ has such a
feature but I never heard of it in Pascal.

It's a difficult topic, cause in Object Pascal class instances are always
on the heap while in C++ they might be on the stack as well. Thus a C++
compiler will insert calls to the destructor of such an object if it goes
out of scope.

In Object Pascal currently only reference counted interfaces and (new in
trunk) records with management operators provide this feature.

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

Re: [fpc-pascal] Coroutines and VirtualAlloc

[Sven Barth via fpc-pascal]

Am 19.04.2017 06:35 schrieb "Ryan Joseph" :
>
>
> > On Apr 19, 2017, at 2:34 AM, Daniel Gaspary  wrote:
> >
> > Using  SetJmp and LongJmp?
> >
> > I believe some months ago it was a discussion on the list on why this
> > was not really the way to implement coroutines.
> >
> > Searching for longjmp/setjmp you can find the thread, I guess.
>
> I never heard of those functions and I did find a thread about them but
it seemed inconslusive.

Those functions simply store (setjmp) and restore (longjmp) register values
(and setjmp also returns the value passed to longjmp if it had been reached
by a longjmp). Nothing more, nothing less. So while the stack register
while be changed, the contents on the stack will not.

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

Re: [fpc-pascal] Coroutines and VirtualAlloc

[Sven Barth via fpc-pascal]

Am 19.04.2017 11:26 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Apr 19, 2017, at 4:14 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > Those functions simply store (setjmp) and restore (longjmp) register
values (and setjmp also returns the value passed to longjmp if it had been
reached by a longjmp). Nothing more, nothing less. So while the stack
register while be changed, the contents on the stack will not.
>
> Why doesn’t “i” in my example increment? The value keeps going back to 1
even after I used += 1 so its like the old copy of the stack before the
jump got pushed back on top and it started over. I don’t understand how
assembly works but I thought it would just start over and the state of the
stack in that function would still be the same as before so I could keep
adding 1 every pass.

Ah, I didn't catch that earlier. Probably "i" is kept in a register due to
optimization. You should check the generated assembler code to be sure.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

[Sven Barth via fpc-pascal]

Am 30.07.2017 09:30 schrieb "Sven Barth" :
>
> Am 30.07.2017 02:01 schrieb "Marcos Douglas B. Santos" :
> >
> > Hi,
> >
> > FPC/Lazarus always tried stay compatible with Delphi... thus, why the
> > FPC XML classes is so different than Delphi classes?

Addendum: FPC's XML library probably also comes from a time when Delphi
didn't have a standard library to deal with XML.

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

Re: [fpc-pascal] XML: Differences between Delphi and FPC

[Sven Barth via fpc-pascal]

Am 30.07.2017 02:01 schrieb "Marcos Douglas B. Santos" :
>
> Hi,
>
> FPC/Lazarus always tried stay compatible with Delphi... thus, why the
> FPC XML classes is so different than Delphi classes?
>
> Delphi XML is interface-based. There exists IXMLDocument, IXMLNode and so
on.
> FPC has just classes.

Of I remember correctly IXMLDocument and the others are based on
Microsoft's XML library. The authors of FPC's XML library probably didn't
want to feel restricted by that.

> I have a FPC/Lazarus project that will be compatible with Delphi. I
> would like to know whether I need to create wrappers to encapsulate
> the differences between them or there is a simple way to do that.
>
> A 3rd lib could be an option too.

You could provide wrappers that provide the same interfaces as the Delphi
ones backed by FPC's library...

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

Re: [fpc-pascal] TInifile does not handle " " (space) as a value.

[Sven Barth via fpc-pascal]

Am 15.08.2017 11:57 schrieb "Michael Van Canneyt" <mich...@freepascal.org>:
>
>
>
> On Tue, 15 Aug 2017, Sven Barth via fpc-pascal wrote:
>
>> Am 15.08.2017 11:17 schrieb "Michael Van Canneyt" <mich...@freepascal.org
>:
>>>
>>>
>>>
>>>
>>> On Mon, 14 Aug 2017, Graeme Geldenhuys wrote:
>>>
>>>> On 2017-08-04 08:47, Michael Van Canneyt wrote:
>>>>>>
>>>>>>
>>>>>> Is this considered a bug or "by design"?
>>>>>
>>>>>
>>>>> This is by design.
>>>>> As you said, whitespace is not so well defined.
>>>>
>>>>
>>>>
>>>>
>>>> Torsten, if you can, maybe switch to JSON files for config setting
>>
>> instead. I have had fantastic success with JSON files in such a way. If
it
>> doesn't yet exist (it probably does), one could write a API wrapper
(think
>> Adapter design pattern) giving JSON files the same or very similar
>> interface to TINIFile - it could be handy for a transition period.
>>>
>>>
>>>
>>> You ask, we deliver. Revision 36913, package fcl-json.
>>>
>>> Unit jsonini.pp contains TJSONIniFile. It is a descendent of
>>
>> TCustomIniFile.
>>>
>>>
>>> Class method TJSONIniFile.ConvertIni will convert an .ini file to a
.json
>>
>> file.
>>>
>>> It attempts to use native types when possible.
>>>
>>> ini2json example program included.
>>>
>>> One item scratched off my long TODO list ;)
>>
>>
>> Not entirely: "make install" fails. It complains about missing
jsonini.rst
>> file :P
>
>
> Already fixed too :)

Thanks!

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

Re: [fpc-pascal] Defining sonames?

[Sven Barth via fpc-pascal]

Am 13.08.2017 17:42 schrieb "Fred van Stappen" :
>
> Hello Martin.
>
> Description of libx11-dev package (in /DEBIAN/control).
>
> Package: libx11-dev
> ...
> Description:
>
> This package contains the development headers for the library found in
libx11-6.
> Non-developers likely have little use for this package.
> ...
>
> Afaik, fpc does not use the C headers (I did not find it) nor fpc does
not develop/change anything inside the libX11 code.
> Maybe, but I have lot of doubt, fpc could need the C headers to compile
himself.
> But the compiled fpc should not need it.
>
> So, imho, in the case of fpc, they should not use libX11.so but
libX11.so.6 when linking things with the binary fpc.

The *-dev packages also contain the symbolic link from the library without
version to the versioned one. This *is* the way to do this as the names of
the library will change with every version.

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

Re: [fpc-pascal] TInifile does not handle " " (space) as a value.

[Sven Barth via fpc-pascal]

Am 15.08.2017 11:17 schrieb "Michael Van Canneyt" :
>
>
>
> On Mon, 14 Aug 2017, Graeme Geldenhuys wrote:
>
>> On 2017-08-04 08:47, Michael Van Canneyt wrote:

 Is this considered a bug or "by design"?
>>>
>>> This is by design.
>>> As you said, whitespace is not so well defined.
>>
>>
>>
>> Torsten, if you can, maybe switch to JSON files for config setting
instead. I have had fantastic success with JSON files in such a way. If it
doesn't yet exist (it probably does), one could write a API wrapper (think
Adapter design pattern) giving JSON files the same or very similar
interface to TINIFile - it could be handy for a transition period.
>
>
> You ask, we deliver. Revision 36913, package fcl-json.
>
> Unit jsonini.pp contains TJSONIniFile. It is a descendent of
TCustomIniFile.
>
> Class method TJSONIniFile.ConvertIni will convert an .ini file to a .json
file.
> It attempts to use native types when possible.
>
> ini2json example program included.
>
> One item scratched off my long TODO list ;)

Not entirely: "make install" fails. It complains about missing jsonini.rst
file :P

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

Re: [fpc-pascal] Subclassing generic records?

[Sven Barth via fpc-pascal]

Am 17.07.2017 18:24 schrieb "Ryan Joseph" :
>
> I’m trying to find a way to extend generic records since (as far as I
know) there is no subclassing of records. I could use variant records here
but these don’t work with generics so I tried record helpers and properties
to basically rename the x/y variables in TVec2 but I get errors on the
width/height properties. Is there a workaround for this?
>
> type
> generic TVec2 = record
> public
> x, y: T;
> end;
> type
> TSize = specialize TVec2;
> type
> TVec2Size = record helper for TSize
> property Width: TFloat read x write x;
> property Height: TFloat read y write y;
> end;

I'll need to check whether Delphi allows that for helpers (doesn't matter
whether the extended type is a specialization or not).

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

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 10.07.2017 15:46 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-07-10 13:34, Dmitry Boyarintsev wrote:
>>
>> are you referring to "Catching More Than One Type of Exception with One
>> Exception Handler" in
>> https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html
>
>
> Yes. You can have multiple catch blocks inside the same try block. You
can also have a single catch block with a comma separated list of exception
types.

You can catch multiple exception types in Object Pascal as well:

=== code begin ===

try
expect
  on e: EWhatever do ...;
  on e: EFoobar do ...;
  else ...
end;

=== code end ===

Though you can't use the same code block for multiple types.

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

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

On 06.07.2017 16:13, Graeme Geldenhuys wrote:
> Imagine if FPC had type inference and multi-line strings, neither very
> exotic features. The code then becomes:
> 
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''
> 
> FDQuery1.SQL.Add(query);
> =
> 
> 
> Easier to read, easier to edit, no need for a IDE wizard or external tools.

Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve
and finalize the $IncludeStringFile patch from issue #25536 (
https://bugs.freepascal.org/view.php?id=25536 ).
It has the advantage that it doesn't change the language and that the
include file can be viewed independently with an appropriate syntax
highlighter (especially with more complex SQL statements - to stick with
your example - that is something that I'd really welcome).
Of course it has the disadvantage that one can't easily add variables,
but for things like this one can always pass the included string to
Format() and friends which in my opinion would be more cleaned up anyway.

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

Re: [fpc-pascal] If vs case or something else?

[Sven Barth via fpc-pascal]

On 06.07.2017 18:33, James Richters wrote:
> I can use case statement with strings apparently now, but the thing is,  I 
> create this file myself in an earlier stage, so I do not need to create the 
> file with strings at all, I could use some codes and do something like this:

"case of String" is essentially the same as your chain of if-statements,
the compiler doesn't do any real optimization there.

> Const
>Thing1 = 1
> Another_Thing = 2
> Thing3 = 3
> Var
> Codenum: Word;
> 
> Case Codenum of
>Thing1: Begin
> DoSomethng()
> DoSomethingElse()
>End;
> Another_Thing: Begin
> ... etc ...
> 
> 
> I'm guessing that would be faster as I wouldn't have to keep evaluating all 
> the strings for every condition.   As I was searching for the best way to do 
> this, I came across something about making an Array of Procedures, or 
> something to that effect.   Does anyone know how to do that, and are there 
> performance advantages to doing that?  It's going to take a bit of work to 
> straighten all this out so it would be best if I just did it the best way 
> instead of doing it one way then finding out it could have been better 
> another way.   Any other ideas on how to handle this?
> 
> Any advice on this is greatly appreciated

If you aren't fixed on having to work on a string that would definitely
be best as you could then use a enum or something like that and you a
case statement. The compiler will try to pick a suitable implementation
then (jumptable, linear search), depending on the amount of labels.

Alternatively you can indeed use an array of procedures like this:

=== code begin ===

program tprocarray;

procedure Proc1;
begin
  Writeln('Proc1');
end;

procedure Proc2;
begin
  Writeln('Proc2');
end;

const
  Procs: array[0..1] of TProcedure = (
@Proc1,
@Proc2
  );

var
  proc: Longint;
begin
  proc := 1;
  Procs[proc]();
end.

=== code end ===

Of course you can also use an enum as the array index:

=== code begin ===

{$scopedenums on} // just for demonstrations

type
  TProcs = (
One,
Two
  );

const
  Procs: array[TProcs] of TProcedure = (
@Proc1,
@Proc2
  );

var
  proc: TProcs;
begin
  proc := TProcs.Two;
  Procs[proc]();
end.

=== code end ===

The variant with the enum has the advantage that the compiler will
complain about missing elements if you add one to the enum type.

Though in both cases you should ensure that your index is in range.

In case of many branches the variant with the array (any of the two
variants) should be faster than the case one.

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

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 10.07.2017 13:19 schrieb "Michael Van Canneyt" :
>
>
>
> On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote:
>
>> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt
>>  wrote:
>>>
>>> The code is definitely not the same. In each case, it was measured.
There is
>>> a 10% performance loss.
>>
>>
>> I'd love a source on this one. I guess you mean in Free Pascal?
>
>
> Obviously.
>
> The classes unit can be recompiled to use the fgl (well, that used to be
so)
> as a basis. When using the resulting list and stringlist, there was a 10%
> performance loss. The main reason - If I recall correctly - was that the
fgl needs to resort to move() operations instead of direct assignments.

The fgl classes don't use Move(), but they have a virtual method that does
the assignment between the specialized parameters that's inherited from the
non-generic parent list type.

You might want to test with the list provided by the rtl-generics package.

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

Re: [fpc-pascal] Static local variables available?

[Sven Barth via fpc-pascal]

Am 20.07.2017 13:01 schrieb "Bo Berglund" :
>
> On Thu, 20 Jul 2017 11:11:50 +0200, Maciej Izak
>  wrote:
>
> >2017-07-20 11:03 GMT+02:00 Bo Berglund :
> >
> >> So since I don't really want to use a global, is it possible to
> >> declare a local variable static in the sense that it retains its
> >> values across calls to the procedure?
> >> If so how is it done?
> >>
> >
> >procedure foo;
> >{$PUSH}
> >const{$J+}
> >  s : string ='';
> >{$POP}
>
> Thanks,
> but it looks a bit involved, probably better to use an object field
> variable instead only accessible from the internal methods.

If you don't want to use $push/$pop then you can also simply enable $J+ for
the whole unit. But this will also mean that global constants are writable.

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

Re: [fpc-pascal] Static local variables available?

[Sven Barth via fpc-pascal]

On 20.07.2017 11:11, Maciej Izak wrote:
> 2017-07-20 11:03 GMT+02:00 Bo Berglund  >:
> 
> So since I don't really want to use a global, is it possible to
> declare a local variable static in the sense that it retains its
> values across calls to the procedure?
> If so how is it done?
> 
> 
> procedure foo;
> {$PUSH}
> const{$J+}
>   s : string ='';
> {$POP}
> begin
>   writeln(s);
>   if s = '' then
> s := 'hello from static local variable';
> end;
> 
> begin
>   foo; // will print empty line
>   foo; // will print 'hello from static local variable'
>   foo; // will print 'hello from static local variable'
> end.

For completeness sake:
https://www.freepascal.org/docs-html/current/ref/refse10.html#x22-210002.2
, especially the remark at the end.

Regards,
Sven

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

Re: [fpc-pascal] Subclassing generic records?

[Sven Barth via fpc-pascal]

On 17.07.2017 19:20, Ryan Joseph wrote:
> 
>> On Jul 17, 2017, at 10:58 AM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> I'll need to check whether Delphi allows that for helpers (doesn't matter 
>> whether the extended type is a specialization or not).
>>
>>
> 
> Thanks Sven. Records/objects/classes in Pascal feel very confused right now. 
> Records are moving in the direction of legacy style “objects” which are 
> allocated on the stack so I wonder why objects just don’t replace records 
> already? Having said that why don’t classes just replace records/objects 
> except they allocate on the stack? These 3 distinct constructs don’t really 
> make sense more imo.

First of records can't replace objects, because objects have inheritance
and a VMT for virtual methods not to mention destructors. Secondly this
would lead to all kind of backwards compatibility problems.
Classes are not designed to be allocated on the stack. They are only on
the heap, thus they are a different kind of beast to records and objects.
And records - unlike objects and classes - can have operator overloads
*inside* of them which allows this operators to be used inside generic
specializations.

I have also another solution for your original problem. Take this code:

=== code begin ===

program trechelpfld;

{$mode objfpc}
{$modeswitch advancedrecords}

type
  TTest = record
x, y: Double;
  end;

  TTestHelper = record helper for TTest
  private
function GetWidth: Double; inline;
function GetHeight: Double; inline;
procedure SetWidth(aValue: Double); inline;
procedure SetHeight(aValue: Double); inline;
  public
property Width: Double read GetWidth write SetWidth;
property Height: Double read GetHeight write SetHeight;
  end;

function TTestHelper.GetWidth: Double;
begin
  Result := x;
end;

function TTestHelper.GetHeight: Double;
begin
  Result := y;
end;

procedure TTestHelper.SetWidth(aValue: Double);
begin
  x := aValue;
end;

procedure TTestHelper.SetHeight(aValue: Double);
begin
  y := aValue;
end;

var
  t: TTest;
  x, y: Double;
begin
  t.x := 42.0;
  t.y := 21.0;

  x := t.Width;
  y := t.Height;

  t.Width := y;
  t.Height := x;
end.

=== code end ===

Through the use of "inline" this results in code without calls as the
assembly output of the main procedure without any optimizations shows:

=== code begin ===

.section .text.n_main
.balign 16,0x90
.globl  PASCALMAIN
.type   PASCALMAIN,@function
PASCALMAIN:
.globl  main
.type   main,@function
main:
.Lc21:
# Temps allocated between rbp-16 and rbp+0
# [45] begin
pushq   %rbp
.Lc23:
.Lc24:
movq%rsp,%rbp
.Lc25:
leaq-16(%rsp),%rsp
callFPC_INITIALIZEUNITS
# [46] t.x := 42.0;
movq_$TRECHELPFLD$_Ld1,%rax
movq%rax,U_$P$TRECHELPFLD_$$_T
# [47] t.y := 21.0;
movq_$TRECHELPFLD$_Ld2,%rax
movq%rax,U_$P$TRECHELPFLD_$$_T+8
# [49] x := t.Width;
movsd   U_$P$TRECHELPFLD_$$_T,%xmm0
movsd   %xmm0,U_$P$TRECHELPFLD_$$_X
# [50] y := t.Height;
movsd   U_$P$TRECHELPFLD_$$_T+8,%xmm0
movsd   %xmm0,U_$P$TRECHELPFLD_$$_Y
# [52] t.Width := y;
movqU_$P$TRECHELPFLD_$$_Y,%rax
movq%rax,U_$P$TRECHELPFLD_$$_T
# [53] t.Height := x;
movqU_$P$TRECHELPFLD_$$_X,%rax
movq%rax,U_$P$TRECHELPFLD_$$_T+8
# [54] end.
callFPC_DO_EXIT
leave
ret
.Lc22:
.Le4:
.size   main, .Le4 - main

=== code end ===

It might be more to write, but it works...

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

Re: [fpc-pascal] Static local variables available?

[Sven Barth via fpc-pascal]

Am 21.07.2017 10:44 schrieb "Santiago A." <s...@ciberpiula.net>:
>
> El 20/07/2017 a las 15:50, Sven Barth via fpc-pascal escribió:
>>
>> Am 20.07.2017 13:01 schrieb "Bo Berglund" <bo.bergl...@gmail.com>:
>> >
>> > On Thu, 20 Jul 2017 11:11:50 +0200, Maciej Izak
>> > <hnb.c...@gmail.com> wrote:
>> >
>> > >2017-07-20 11:03 GMT+02:00 Bo Berglund <bo.bergl...@gmail.com>:
>> > >
>> > >> So since I don't really want to use a global, is it possible to
>> > >> declare a local variable static in the sense that it retains its
>> > >> values across calls to the procedure?
>> > >> If so how is it done?
>> > >>
>> > >
>> > >procedure foo;
>> > >{$PUSH}
>> > >const{$J+}
>> > >  s : string ='';
>> > >{$POP}
>> >
>> > Thanks,
>> > but it looks a bit involved, probably better to use an object field
>> > variable instead only accessible from the internal methods.
>>
>> If you don't want to use $push/$pop then you can also simply enable $J+
for the whole unit. But this will also mean that global constants are
writable.
>
> Well, I'm an old dog so I prefer old fashion ways. A variable that
retains its value is, from memory point of view, a global variable. I mean,
the memory is never freed, it's not freed when it goes out of scope. So,
the problem is what to do to limit the visibility to the procedure.

Writable constants *are* the old fashion way, cause this kind of usage
stems from Turbo Pascal and allowed to restrict the visibility of symbols.

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

Re: [fpc-pascal] Sistema grande em CGI

[Sven Barth via fpc-pascal]

Am 21.07.2017 13:33 schrieb "Rogério Martins" :
>
> Bom dia pessoal !
>
> Alguém aí já desenvolveu algum sistema grande em cgi ? (muitos acessos
simultâneos, etc)
>
> Queria saber se ele dá conta, ou até onde se pode ir.
> Eu só fiz aplicações pequenas.
>
> Obrigado

This is an English list, so please write in English.

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

Re: [fpc-pascal] Subclassing generic records?

[Sven Barth via fpc-pascal]

Am 21.07.2017 23:36 schrieb "Ryan Joseph" :
>
> Thanks Sven, that’s one way around it.
>
> So is it by design that records don’t have inheritance or is this planned?

Yes, that's by design and there are no plans to change this.

> and is it also by design that classes don’t allow operator overloads
inside them? That seems like an omission since the way they’re implemented
in records is much nicer imo.

There are two points you need to be aware of to understand why thinks are
the way they are:
First of global operator overloads were the first that were implemented in
FPC. Then Delphi came along and added record operator overloads, because
they needed them for generics. FPC followed, cause the global overloads are
useless in that case.
Secondly even for global operator overloads classes are not really that
suitable, cause in complex expressions (let's say "a * (b + c)") you'll
have the generation of temporary variables (in the example the result of "b
+ c"), but the compiler can't know whether it's really a temporary value
that it can free after the whole expression is handled or whether merely
the instance that had been passed in (let's say "b") had been modified and
passed as a result. Thus operator overloads for classes can easily lead to
memory leaks or other hard to debug problems. Yes, that's already possible
with global operators as well, but with operators that are part of the
class that would be much more inviting.

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

[Sven Barth via fpc-pascal]

Am 27.07.2017 17:18 schrieb :
>
> On 2017-07-25 11:00, Martok wrote:
>>>
>>> Ideally the function should be portable between FPC and Delphi XE5...
>>
>> You'd only need your own functions for Delphi, FPC's intrinsics such as
Insert()
>> can already work with arrays:
>>
>> var
>>   b, c: TBytes;
>> begin
>>   b:= TBytes.Create(1,2,3);
>>   c:= TBytes.Create(10,11);
>>   Insert(c,b,2);
>>
>> -> b is now [1,2,10,11,3]
>>
>>
>
> The fpc wiki should probably be updated?
>
> I cannot find "insert" on this page:
> http://wiki.freepascal.org/Array

Then update it.

> I cannot find it here either:
> https://www.freepascal.org/docs-html/ref/refsu14.html

The documentation is always for the latest release (currently 3.0.2, soon
3.0.4), but only trunk supports this as well as Delete() (Concat() is not
yet implemented however).

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

[Sven Barth via fpc-pascal]

Am 26.07.2017 10:59 schrieb "Martok" :
>
> > Ideally the function should be portable between FPC and Delphi XE5...
> You'd only need your own functions for Delphi, FPC's intrinsics such as
Insert()
> can already work with arrays:
>
> var
>   b, c: TBytes;
> begin
>   b:= TBytes.Create(1,2,3);
>   c:= TBytes.Create(10,11);
>   Insert(c,b,2);
>
> -> b is now [1,2,10,11,3]

But only in trunk. And Delphi XE8 and newer also support them.

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

Re: [fpc-pascal] Semaphores removed from the rtl?

[Sven Barth via fpc-pascal]

Am 19.07.2017 18:45 schrieb "Anthony Walter" :
>
> Nah thanks, I can implement them with native functions on windows, mac,
and linux easily enough and with $ifdefs. I am just surprised by the
thought process involved in removing them.

As Charlie said, that functionality was never intended for public use and
only available for a specific use case.

For cross platform use the Delphi compatible TSemaphore in the SyncObjs
unit should be implemented...

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

Re: [fpc-pascal] Delete and Add for TBytes?

[Sven Barth via fpc-pascal]

Am 12.07.2017 16:08 schrieb "Bo Berglund" :
> To remove Count processed bytes from the beginning:
>
> Buffer: AnsiString;
>
> Delete(Buffer, 1, Count)
> or worse:
> Buffer := Copy(Buffer, Count+1, Length(Buffer));

FPC trunk supports Delete() and Insert() on dynamic arrays (TBytes is
merely a dynamic array) and Copy() is supported for longer already. You
merely need to adjust the indices to 0-based instead of 1-based.
Delete() and Insert() are also supported by Delphi XE8 and newer I think.

> For adding new data (c: AnsiChar) to the end:
>
> Buffer := Buffer + c;

The + operator is not yet implemented by default on FPC (neither is
Concat()), but you can easily declare that yourself.

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

Re: [fpc-pascal] Running Freepascal programs on other computers

[Sven Barth via fpc-pascal]

Am 29.06.2017 23:27 schrieb "Bo Berglund" <bo.bergl...@gmail.com>:
>
> On Thu, 29 Jun 2017 11:08:40 +0200, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
>
> >- open "Internet Options"
>
> The wording on these option pages seem to indicate that they are for
> websites. That is all they talk about.

They are not only about websites, but also files in the local intranet
(e.g. network shares in your network or even local network shares)

> What about local files on the computer which are not part of any
> website?

*shrugs* Those settings are somewhere else. Most likely local security
policy...

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

Re: [fpc-pascal] Running Freepascal programs on other computers

[Sven Barth via fpc-pascal]

Am 28.06.2017 20:32 schrieb "James Richters" :
>
> >Are you by chance running it from a shared smb folder or something like
that?
>
> Yes I am running them on a network share… If I copy the file to my laptop
hard drive then I don’t get the warning anymore.  However I still get the
secutiy warning if the program is downloaded, even if I download it to the
original development pc.

To run programs without annoying prompt from a network share you need to
change the security settings on the computer you want to run the
application on (it's the same in Windows 7 by the way):
- open "Internet Options"
- go to tab "Security"
- select category "Local Intranet"
- click button "Sites"
- uncheck "automatically determine Intranet"
- check the other three checkboxes (or at least the one about network paths)
- confirm all dialogs

The dialog that occurs when you download a program is also controlled
somewhere, but it's cause is an alternate datastream that gets attached to
the downloaded file. I don't know right now whether signing the execuable
makes a difference here aside from the dialog looking less warning like...

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

Re: [fpc-pascal] Food for thought - language string improvement

[Sven Barth via fpc-pascal]

Am 06.07.2017 23:34 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-07-06 20:07, Dmitry Boyarintsev wrote:
>>
>> The thread of discussion:
>> http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html
>
>
>
> Thanks for the link. Seems this topic has already been discussed a year
and a bit ago.
>
> Anybody know if there was any movement on the $IncludeString idea?

See my message from yesterday night. :)

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

Re: [fpc-pascal] Record operator for assignment

[Sven Barth via fpc-pascal]

Am 28.04.2017 14:09 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
> Is there any way that the length of an array being used for that sort of
job can be defined by what's put into it, rather than having to be
predefined?

No, there is not. Though I already had the idea that such preinitialized
dynamic arrays (because that's what they'd need to be for consistency)
could be implemented. Alas that's another small point on my huge ToDo
list... :/

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

Re: [fpc-pascal] Record operator for assignment

[Sven Barth via fpc-pascal]

Am 28.04.2017 09:23 schrieb "Ryan Joseph" <r...@thealchemistguild.com>:
>
>
> > On Apr 28, 2017, at 1:06 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > No, I mean
> >
> > rec := (x + y) * 2;
> >
> > The compiler has to differentiate these two.
>
> I see. It’s the parenthesis that are problematic. I guess the solution
would be curly brackets:
>
> rec := {x: 1; y: 2; z: 1}

Curly brackets are comments!

> or some magic function like writeln:
>
> rec := TMyRec(x: 1; y: 2; z: 1)

That could be a possibility as the compiler could then correctly handle the
field names, however it would have an ambiguity with typecasts until the
colon.
Though that would be solvable...

> rec := @(x: 1; y: 2; z: 1)

@ would be nonsense as that would denote a pointer.

> etc…
>
> Anyway it could be achieved that would be nice to have a built in
constructor for records on the language level.
>

Well, feel free to develop a patch, maybe it'll be accepted. I have other
fish to fry in the meantime.

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

Re: [fpc-pascal] Record operator for assignment

[Sven Barth via fpc-pascal]

Am 28.04.2017 06:06 schrieb "Ryan Joseph" :
>
> Instead of making constructors and doing busy work It would be nice if
Free Pascal could let you assign records outside of type blocks like:
>
> rec := (x: 0; y: 0; z: 0);
>
> Why isn’t this possible btw? I saw some C++ code do this and it seems
like an obvious solution that should have existed 20 years ago. The feature
exists for type blocks so why not just enable it for other parts of code?

It would introduce an ambiguity as "(x" could also complete to other
expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older
Pascal compilers were geared towards the simplicity of the language and
thus they didn't add it. For FPC it simply never came up.

> I had another idea to make this a little simpler by using open arrays and
operator overloading. The compiler doesn’t permit this however. Is it a
bug, my code or just a limitation?
>
> 
>
>
> type
> TMyRec = record
> x, y, z: integer;
> class operator Explicit(v: array of integer): TMyRec;
> end;
>
> class operator TMyRec.Explicit(v: array of integer): TMyRec;
> begin
> result.x := v[0];
> result.y := v[1];
> result.z := v[2];
> end;
>
>
> var
> rec: TMyRec;
>
> rec := TMyRec([1, 2, 3]); // Illegal type conversion: "Set Of Byte" to
"TMyRec"

The compiler currently prefers to cast array constructors towards sets,
especially if they contain values that could be expressed as a set. That
will change once proper support for array constructors is added. Though I
don't know whether this would work then ;)

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

Re: [fpc-pascal] Record operator for assignment

[Sven Barth via fpc-pascal]

On 28.04.2017 08:01, Ryan Joseph wrote:
> 
>> On Apr 28, 2017, at 12:43 PM, Sven Barth via fpc-pascal 
>> <fpc-pascal@lists.freepascal.org> wrote:
>>
>> It would introduce an ambiguity as "(x" could also complete to other 
>> expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older 
>> Pascal compilers were geared towards the simplicity of the language and thus 
>> they didn't add it. For FPC it simply never came up.
> 
> I never thought about it either until I saw some c++ code doing it. Despite 
> having overlooked it, it’s basically a built in record constructor that’s 
> been in the language since forever. First it was making functions that paired 
> with records and now it’s constructors and "advanced record syntax" when the 
> more obvious and simpler solution was there all along. Maybe I’m crazy 
> though. ;)
> 
> You mean like: 
> 
> rec := (x: (x + y) * 2; y: 0; z: 0);

No, I mean

rec := (x + y) * 2;

The compiler has to differentiate these two.

> Why can’t everything between : and ; just be treated like a normal 
> assignment? “x” is already defined but it’s just a label and not part of the 
> assignment.

And that's another point. The compiler does not know what "x", "y" and
"z" are, cause it doesn't care about the left hand side of the
assignment until *after* the right hand side is parsed (in a var/const
section it knows the type; that's a different situation).
So a different syntax would be needed that would allow the compiler to
know that it's parsing a specific record type.

>>
>> The compiler currently prefers to cast array constructors towards sets, 
>> especially if they contain values that could be expressed as a set. That 
>> will change once proper support for array constructors is added. Though I 
>> don't know whether this would work then ;)
> 
> Huh, that syntax works in constructors, just not in the operator overloading. 
> Anyways I guess I’ll just assume that’s not implemented behavior.

Because in that case it knows that it's a parameter and handles that
differently. A type conversion is a different case.

Regards,
Sven

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

Re: [fpc-pascal] Const attributes

[Sven Barth via fpc-pascal]

On 30.07.2017 20:55, Marcos Douglas B. Santos wrote:
> On Sun, Jul 30, 2017 at 1:46 PM, Maciej Izak  wrote:
>> 2017-07-30 18:37 GMT+02:00 Marcos Douglas B. Santos :
>>>
>>> 1. Is this by design?
>>
>>
>> Yes. To disallow this you need to use {$J-} directive.
> 
> I know that we can use this "hack" in local functions/methods, but in
> an attribute... What is the goal to use it?

$J affects all kinds of constants no matter whether they are global,
inside a routine or inside a type. Though it seems that this is broken
as the compiler allows an assignment nevertheless... *sigh*

>>>
>>> 2. Is there a way to declare attributes "final" like Java does?
>>
>>
>> No for constants.
> 
> I would like to instantiate my attribute only once inside constructor
> and then it will be "const" or "final", I mean, immutable.
> Today it is not possible, right? Any thoughts to the future?

With the JVM platform support for final fields was added (modeswitch
finalfields), but that is currently only available for external classes
(which only exist for the JVM target) as the DFA can't handle that
correctly currently.
(though if one would restrict the assignments to the constructors itself
without any methods called by the constructor then we might be able to
implement that nevertheless, don't know what Java or other languages
with final fields allow here)

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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

[Sven Barth via fpc-pascal]

Am 30.07.2017 12:37 schrieb "Bo Berglund" <bo.bergl...@gmail.com>:
>
> On Sun, 30 Jul 2017 09:33:59 +0200, Sven Barth via fpc-pascal
> <fpc-pascal@lists.freepascal.org> wrote:
>
> >> The application was started back in Delphi7 times when "string"
> >> actually meant AnsiString and was a 1-byte per element container.
> >
> >You could always use RawByteString or a string with a fixed codepage
> >instead if plain AnsiString.
>
> I asked about this problem over at Embarcadero too, but was flamed for
> even thinking about using any kind of string for storing binary data.
> THeyn did suggest RawByteString too, though so I went over the
> application changing all buffers to RawByteString and it did work.
> I also tried to set a fixed codepage for the application, but it is
> hard to check if it actually does help.

Not a fixed codepage for the application, but a string with fixed codepage,
e.g. "String(CP_1242)" or so...

> The root problem is what happens with string conversions on different
> locales and some functions could not be easily modified to use
> RawByteString.
> So I decided to bite the bullet and convert the whole unit to TBytes
> instead. Some 7000 code lines to go over...
>
> It has taken a good many hours now and I still have some intricate
> problems to solve. It still won't compile without errors.
>
> >
> >Just declare a type alias so that you can keep it compatible with older
> >Delphi versions as well.
> >
>
> Do you mean:
> type
>   TMyString = RawByteString;

Yes.

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

Re: [fpc-pascal] inline callback functions?

[Sven Barth via fpc-pascal]

Am 09.08.2017 06:21 schrieb "Ryan Joseph" :
>
>
> > On Aug 7, 2017, at 1:47 PM, Mattias Gaertner 
wrote:
> >
> > What you mean are "anonymous functions" or "closures".
> >
> > State in FPC:
> > http://lists.freepascal.org/pipermail/fpc-devel/2016-August/037328.html
>
> Yes, closures. Seems like development may be abandoned but it’s a good
idea none the less.

The development is still in progress, albeit slowly.

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

Re: [fpc-pascal] Defining sonames?

[Sven Barth via fpc-pascal]

Am 17.08.2017 22:20 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-17 16:52, Martin Schreiber wrote:
>>
>> Exactly. So why not use the SONAME in the Pascal binding unit instead to
use
>> the base name as Free Pascal currently does in xlib.pp for example?
>
>
> I forked the xlib, xutils and x units from FPC and tried just that. It
made no difference. When I compiled the project with the -Cn command line
parameter I reviewed the ppas.sh and .res file. The .res file has
a INPUT section near the end listing all dependent libraries. They are
translated to the same as when you use GCC's -l command line parameter.
Only the base name of the library is used. Also, apparently the Unix/Linux
linker (FPC doesn't have it's own - only for Windows) doesn't support
versioned library names as command line parameters. So I don't think there
is much FPC can do - unless I'm still not understanding the whole compiling
and linking process, unless FPC implements their own linker under Unix-type
OSes too.

FPC does have its own, internal ELF linker, though that is not enabled by
default currently as it still has its shortcomings. But even then it would
follow the conventions of the target OS.

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

Re: [fpc-pascal] Defining sonames?

[Sven Barth via fpc-pascal]

On 14.08.2017 15:19, Fred van Stappen wrote:
> A concrete example.
> 
> A Linux/FreeBSD fpc release was compiled using the pascal headers for
> libX11.so.6 and using symlink libX11.so >> libX11.so.6.0.8.
> 
> This release was installed on a system (with libX11-dev too to make it
> work).
> 
> If, some time later, a system-update was done to the brand new version
> libX11.so.7.0.1,
> this will update also libX11-dev >> libX11.so >> libX11.so.7.0.1.
> 
> And using fpc, there will be a error because libX11.so does not point to
> a libX11.so.6 version.

Wrong. Take an empty program that includes the X unit:

=== code begin ===

program tsoname;

uses
  X;

begin

end.

=== code end ===

The X unit simply contains a "$linklib x11" which is equivalent to
importing specific functions using "external 'x11' name ...".

My system looks like this:

=== listing begin ===

lrwxrwxrwx 1 root root  15 27. Feb 17:54 /usr/lib/libX11.so ->
libX11.so.6.3.0
lrwxrwxrwx 1 root root  15 27. Feb 17:54 /usr/lib/libX11.so.6 ->
libX11.so.6.3.0
-rwxr-xr-x 1 root root 1306096 27. Feb 17:54 /usr/lib/libX11.so.6.3.0

=== listing end ===

And the resulting binary links this (objdump -x output)

=== listing begin ===

(...)
Dynamic Section:
  NEEDED   libX11.so.6
  NEEDED   libc.so.6
(...)

=== listing end ===

As you can see the program will work correctly as long as the
libX11.so.6 file exists (even though that is a symlink itself, but the
X11 project guarantees that different libX11.so.6.x.y are compatible to
eachother), because the linker picks the SONAME that is set inside the
binary. And the libX11.so.6 symlink is part of the non-devel package.

> But if the same Linux/FreeBSD fpc release was compiled using symlink
> libX11.so.6, there, no problem, it will use the still installed symlink
> libX11.so.6.
> 
> Or, if libX11.so.6 is no more installed, fpc could say "libX11.so.6 not
> found" (because fpc knows now what version of libX11 he needs).

Neither FPC nor the linker know anything about library versions. They
only know the filenames and the SONAMEs. If either can't find the
filename it needs than though luck. And the SONAME is the one that's
used for the real lookup, but the linker needs the file for that.

> Other thing.
> 
> If your way *is* the way to do, why fpc does not use libc6-dev (that
> will create symlink libc.so) but uses LIBC_SO = 'libc.so.6' instead of
> LIBC_SO = 'libc.so' ?

And did you even look at the code?

1. the libc unit is deprecated and only exists for Kylix compatibility
2. the LIBC_SO constant is used nowhere (the library constant is "clib"
and has the value 'c')

The only other use of "libc.so.6" is in iconvenc_dyn.pas, but that is
because it is loading the library dynamically and there the real file
*must* be used as the development symlink might not exist after all.

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

Re: [fpc-pascal] Defining sonames?

[Sven Barth via fpc-pascal]

Am 18.08.2017 01:17 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-17 21:47, Henry Vermaak wrote:
>>
>> You can use -l:libgreat.so.1 with gcc to link to a specific library
version
>> (iirc).
>
>
> I'll have to take your word for it Henry, as I don't know GCC much - only
the bare minimum to compile small C projects. I normally specify things
like -lpthreads -lX11 etc. I've never seen a versioned -l parameter being
used. I'll try it next time.

Passing a name with ":" to the linker works (on Linux at least). I used
that when I tested dynamic packages and wanted the linker to use
"librtl.ppl" instead of "librtl.so" ;)

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

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 22.08.2017 18:11 schrieb "Peter" :
>
> Hi James,
>
> Its unlikely that 999.999 has an EXACT representation in floating point.
>
> 999.999002  maybe the closest value at your chosen precision.
>
> Extended type has more precision, but still probably won't be exact.

Additionally Extended is not cross platform.

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 02:04 schrieb "Anthony Walter" :
>
> I just wanted to point out that revision 37023 Sven added type helper
support for interfaces.
>
> Good job and thank you Sven!

You're welcome. I wanted to add them for some time already :)

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

Re: [fpc-pascal] Check In Interface Type Helpers

[Sven Barth via fpc-pascal]

Am 23.08.2017 09:42 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 22 Aug 2017, Anthony Walter wrote:
>
>> I just wanted to point out that revision 37023 Sven added type helper
>> support for interfaces.
>>
>> Good job and thank you Sven!
>>
>
> I'm having trouble understanding why this could be useful (apart from
completeness).
> The only thing I can come up with is adding properties:
>
>   Property SomeProp : TSomeType Read GetSomeProp Write SetSomeProp;
>
> where GetSomeProp and SetSomeProp are part of the interface.
>
> Any other examples ?

It's the same as for the other kinds of helpers: being syntactic sugar.
E.g. if I have an interface that has two methods that both return a string,
but more often than not I need a combination of both results. The previous
solution would have been a global function, now I can also do a helper with
a method.

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

Re: [fpc-pascal] Defining sonames?

[Sven Barth via fpc-pascal]

Am 17.08.2017 15:49 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote:
>>
>> As you can see the program will work correctly as long as the
>> libX11.so.6 file exists (even though that is a symlink itself, but the
>> X11 project guarantees that different libX11.so.6.x.y are compatible to
>> eachother), because the linker picks the SONAME that is set inside the
>> binary. And the libX11.so.6 symlink is part of the non-devel package.
>
>
> Sven, now here is an interesting problem regarding the way FPC (or Object
Pascal in general) works with C based libraries. Martin pointed this out in
another mailing list, and he gave me permission to forward it here. What is
your answer or recommendation to this problem?

Write in your application's readme which versions it requires. It might be
true that the devel packages contain the C-headers, but there might
nevertheless be failures if the applications
is programmed against the interface of the older v1 library (maybe they
changed the memory management for v2 and the problem will only manifest at
runtime).

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

Re: [fpc-pascal] Vehicle management

[Sven Barth via fpc-pascal]

Am 12.05.2017 11:10 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017
>
>> 18:14 schrieb "Jon Foster" <jon-li...@jfpossibilities.com >
>> <mailto:jon-li...@jfpossibilities.com>>:> > Anyhow tips on the FPC->C++
>> front would be appreciated. I will probably > search the list archives
>> as I know this topic comes up repeatedly. I > don't understand how
>> ginormous an undertaking this might be but maybe I > can contribute
>> something on this front.>> I can't speak for other approaches to
>> interface with C++ code, but > patches to the compiler's cppclass
>> support are definitely welcome :D It > will never support everything
>> there is in C++, but if we'd manage to > interface with most library
>> code that would be something...
>
>
> Apologies for bad threading here. Sven, can I just go off on a slight
tangent before that part of the discussion adjourns to fpc-devel, since
this is a user rather than a developer question.
>
> What's the current situation with FPC interface to the Subversion support
libraries which I think is something you were looking at at one point?

Nope, I never looked at the Subversion libraries.

> In extremis, I suppose that it should be possible for a program written
in FPC to use Lua as a shim when calling C++.

Before that I'd say the Delphi support for the binding generator SWIG
should be checked (at least I thought it already had some).

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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 14.05.2017 23:18 schrieb :
>
> On 2017-05-11 18:57, Jon Foster wrote:
>>
>> On 05/11/2017 02:48 PM, Graeme Geldenhuys wrote:
>>>
>>> On 2017-05-11 19:43, James Richters wrote:

 Any Suggestions?
>>>
>>>
>>> Speed:
>>>   In recent graphics work I've done, I've noticed that FPC is fantastic
>>>   at created cross-platform applications. But the generated binaries
>>>   are NOT fast at all - no matter how many compiler parameters and
>>>   artificial speed optimisations we tried to implement. Sloppy Java
>>>   code ended up 3x faster than the best I could get out of FPC
>>>   generated binaries.
>>>
>>>   I'm not saying this is your performance problem (especially comparing
>>>   a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another
>>>   problem contributing to your speed issue.
>>
>> Wow, Graeme! That's harsh. One of the last set of benchmarks I did
>> that focused on integer math and procedure call speed came out as
>> follows:
>
>
> I think he specifically meant graphics apps, not general apps

While a raytracer is indeed a graphics app it's mainly about CPU
computation in this case and not interfacing with the GPU like OpenGL does
(of course one can write a raytracer to take advantage of the parallel
architecture of a GPU, but that's bot the case in this specific example).

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

Re: [fpc-pascal] Vehicle management

[Sven Barth via fpc-pascal]

Am 11.05.2017 18:14 schrieb "Jon Foster" :
> I should also throw out here that it would be *REALLY* nice, and even
somewhat needful on the Android front, if FPC could interface directly with
C++ libs and use their classes and objects. Besides Java, Google prefers to
use C++ (for obvious reasons) and their supplied native code libraries are
C++. If you look at Google's software architecture diagram they say they
use FreeType2. But, even rooted, if you search the Android file system you
won't find a FT2 lib anywhere. Digging through the AOSP source base it
turns out that FT2 is statically linked into Skia. Skia is a C++ library
used by Dalvik (and other places) to do the usual 2D text/graphics
rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did
find it exports a limited set FT2 functions in standard C style. But it
looks like, for full functionality, I'm going to have to bridge the C++
divide.
>
> Anyhow tips on the FPC->C++ front would be appreciated. I will probably
search the list archives as I know this topic comes up repeatedly. I don't
understand how ginormous an undertaking this might be but maybe I can
contribute something on this front.

I can't speak for other approaches to interface with C++ code, but patches
to the compiler's cppclass support are definitely welcome :D It will never
support everything there is in C++, but if we'd manage to interface with
most library code that would be something...

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

Re: [fpc-pascal] Call for testing: array constructors

[Sven Barth via fpc-pascal]

Am 08.05.2017 22:14 schrieb "Jonas Maebe" <jo...@freepascal.org>:
>
> On 08/05/17 17:34, Sven Barth via fpc-pascal wrote:
>>
>> Good to know. Any regressions with ordinary sets?
>
>
> There seems to be a problem with overload selection between dynamic and
open arrays for empty array parameters:
https://bugs.freepascal.org/view.php?id=31756
>

Why am I not surprised? -.- Thanks.

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

Re: [fpc-pascal] FPC Graphics options?

[Sven Barth via fpc-pascal]

Am 16.05.2017 16:10 schrieb "Jon Foster" :
> There are only two software projects in the world that continue to
impress me with each new release: the Linux Kernel and FPC, which amuses me
since I remember the first version of FPC I saw. '99 I think it was. I
laughed and moved on. I wish I had the time provide some concrete info on
where Graeme's problem is because I'd really like to see FPC shine here
too. But it will probably be a while before I can give it proper treatment.

Now if only there'd be a publicly visible "like" functionality in e-mails :D

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

Re: [fpc-pascal] Best way to check SimpleIPC for messages

[Sven Barth via fpc-pascal]

Am 17.05.2017 07:08 schrieb :
>
> On 2017-05-15 04:36, Michael Schnell wrote:
>>
>> On 12.05.2017 16:37, Michael Van Canneyt wrote:
>>>
>>>
>>> Check manually. What else is left ? There is no message queue, so no
loop in which to check at regular basis.
>>>
>> For event processing in a not threaded project or in the main thread
>> of a threaded project you at best use the Event Queue provided by some
>> Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes
>> sense, if you don't want to use one of those. (mse and an enhanced
>> NoGui LCL "Widget Type", I have done a working draft for, can provide
>> a message queue even with no binding to a GUI Widget Set).
>>
>
> Isn't that what the application onidle is for, a way to check messages
using the application code in the LCL
>
> But a question is (sorry I am not familiar with "onidle"), what happens
when the application is not idle, but sort of idle? What classifies an idle
state? i.e. what if the cpu is at 3 percent consumption, or 55 percent, or
2 percent? What classifies an onidle? this documented somewhere?
> Is onidle reliable or hit and miss where the app is not idle enough, in
some cases?

OnIdle() is called when there is no more event waiting in the widgetset's
event queue, basically meaning that the application has nothing better to
do anyway. It has nothing to do with CPU usage.

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