Re: [fpc-pascal] fpc-pascal Digest, Vol 167, Issue 39

2018-05-20 Thread Ingemar Ragnemalm

On Sun, 20 May 2018, Sven Barth via fpc-pascal wrote:


I'm pleased to announce that after nearly a year various extensions for
dynamic arrays have been finished. This includes the following features:

- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)
The dynamic array constructors sound absolutely wonderful! I have code 
with rather awkward workarounds that will benefit a lot by these features.


/Ingemar


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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Maciej Izak
2018-05-21 0:52 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> The thing is that I can easily imagine the Delphi devs to be so stoned to
> use the "[...]" for static arrays inside dynamic arrays as well which could
> lead to constructs like the following because they forget that dynamic
> arrays could be part of static arrays as well:
>
> === code begin ===
>
> var
>   v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5,
> 6]], [], [[7, 8, 9]]);
>
> === code end ===
>
> Yes, I have absolutely no confidence in the Delphi developers.
>

Sometimes they have fantasy ^^. Don't underestimate them, I am sure they
can do something more unexpected ;) For NewPascal mode I see this like :

var
  v: array[0..2] of array of array[0..2] of LongInt = ([(1, 2, 3), (4, 5,
6)], [], [(7, 8, 9)]);


> I don't want to use a modeswitch for every tiny little bit of feature.
> What we could do however would be a modeswitch for a strict Delphi mode
> that prohibits extensions and code that does not work in Delphi (like
> global operators and global generic functions). This could be used for code
> that is shared with Delphi to avoid potentially breaking compilability with
> Delphi if one is mainly using FPC for testing.
>

IMO potentially breaking compatibility is better than lock/prohibition for
missing features in Delphi (or waiting for Delphi implementation).
Programmers are not stupid and most of Delphi users knows what Delphi have
and what can be potentially risky. We have tons of examples which should be
disabled in Delphi mode but it works for comfort. r39045 is for sure not
comfortable IMO without real important reason, but this is just my opinion.


> The gain is consistency with static array constants. You don't need to
> care about whether it's a dynamic array or a static one, you simply use the
> same syntax.
> Also what do you care about mode ObjFPC anyway? One purpose of the mode
> *is* that it can go a different route than those modes that copy existing
> implementations.
>

I am worried about all Pascal modes including ObjFPC and Delphi mode. :)

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Sven Barth via fpc-pascal
Maciej Izak  schrieb am So., 20. Mai 2018, 23:32:

> 2018-05-20 22:50 GMT+02:00 Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org>:
>
>> I prohibited it because Delphi does not support it correctly and I don't
>> know whether they'd use the usual "(...)"-syntax for the static arrays or
>> switch to the dynamic array one. To avoid potential backwards compatibility
>> problems I decided to simply disallow it.
>>
>
> I do not buy this ;) no one knows what they will use (if ever), but still
> I see no real reason for blocking this. Following yours logic any of
> management operators should be also prohibited in Delphi mode because some
> similar feature for nullable types is planned for Delphi (but no one knows
> the final form of their Initialize/Finalize equivalent). Code in r39045 is
> IMO too strict.
>

The thing is that I can easily imagine the Delphi devs to be so stoned to
use the "[...]" for static arrays inside dynamic arrays as well which could
lead to constructs like the following because they forget that dynamic
arrays could be part of static arrays as well:

=== code begin ===

var
  v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5,
6]], [], [[7, 8, 9]]);

=== code end ===

Yes, I have absolutely no confidence in the Delphi developers.


>
>> I had not tested that one. In consequence that should indeed be
>> disallowed as well. Though here the syntax probably wouldn't provide
>> problems in the future.
>>
>
> and the same sentence is true for the syntax for static array constants
> inside dynamic array constants, the more Delphied syntax for arrays
> probably wouldn't provide problems in the future too :)
>
> If you like very strict approach and you want to make our life simpler
> probably you should implement some "modeswitch" for allowing both examples
> (example with records and arrays).
>

I don't want to use a modeswitch for every tiny little bit of feature. What
we could do however would be a modeswitch for a strict Delphi mode that
prohibits extensions and code that does not work in Delphi (like global
operators and global generic functions). This could be used for code that
is shared with Delphi to avoid potentially breaking compilability with
Delphi if one is mainly using FPC for testing.


> btw. the problem for different syntax between Delphi and ObjFpc is still
> valid. I don't see any real gain for different syntax. It was consulted
> with community or this is just individual decision? (and here sorry if I
> overlooked something)
>

The gain is consistency with static array constants. You don't need to care
about whether it's a dynamic array or a static one, you simply use the same
syntax.
Also what do you care about mode ObjFPC anyway? One purpose of the mode
*is* that it can go a different route than those modes that copy existing
implementations.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Maciej Izak
2018-05-20 22:50 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> I prohibited it because Delphi does not support it correctly and I don't
> know whether they'd use the usual "(...)"-syntax for the static arrays or
> switch to the dynamic array one. To avoid potential backwards compatibility
> problems I decided to simply disallow it.
>

I do not buy this ;) no one knows what they will use (if ever), but still I
see no real reason for blocking this. Following yours logic any of
management operators should be also prohibited in Delphi mode because some
similar feature for nullable types is planned for Delphi (but no one knows
the final form of their Initialize/Finalize equivalent). Code in r39045 is
IMO too strict.


> I had not tested that one. In consequence that should indeed be disallowed
> as well. Though here the syntax probably wouldn't provide problems in the
> future.
>

and the same sentence is true for the syntax for static array constants
inside dynamic array constants, the more Delphied syntax for arrays
probably wouldn't provide problems in the future too :)

If you like very strict approach and you want to make our life simpler
probably you should implement some "modeswitch" for allowing both examples
(example with records and arrays).

btw. the problem for different syntax between Delphi and ObjFpc is still
valid. I don't see any real gain for different syntax. It was consulted
with community or this is just individual decision? (and here sorry if I
overlooked something).

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Sven Barth via fpc-pascal
Maciej Izak  schrieb am So., 20. Mai 2018, 21:49:

> Why you decide to prohibit static array constants inside dynamic array
> constants for Delphi modes in r39045? I do not understand this decision. It
> is some punishment for using Delphi mode? -,- IMO bad decision.
>

I prohibited it because Delphi does not support it correctly and I don't
know whether they'd use the usual "(...)"-syntax for the static arrays or
switch to the dynamic array one. To avoid potential backwards compatibility
problems I decided to simply disallow it. And to be fair: how often do you
declare dynamic arrays that consist of static arrays?

For the consequence the following code
>
> var
>   f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];
>
> should be also prohibited in Delphi mode, because it not works in Delphi
> like static array constants inside dynamic array constants...
>

I had not tested that one. In consequence that should indeed be disallowed
as well. Though here the syntax probably wouldn't provide problems in the
future.

Regards,
Sven

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Maciej Izak
2018-05-20 20:44 GMT+02:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Anthony Walter  schrieb am So., 20. Mai 2018, 19:09:
>
>> By the way, what's the reason for differences in () / [] syntax between
>> objpas and delphi mode?
>>
>
> For the non-Delphi modes I decided to keep consistency with static array
> constants (which use the same syntax in Delphi btw!). For the Delphi modes
> I followed what Delphi does. And for some reason the Delphi devs thought it
> better to use a different syntax than that for static arrays. 路‍♀️
>

Gratz, seems that I will need to update NewPascal soon to get this fresh
feature :).

They decide for [] probably because it is similar syntax like for open
arrays. IMO "[]" syntax has more dynamic meaning/nature so looks more
proper for this feature (as you said "()" syntax is used for static
arrays), but this is probably individual taste.

"[]" also might be better for something like this :

var
  f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];

instead of

var
  f: array of TSomeRec = ((a: 10; b: ('1', '2')), (a: 20; b: ('6')));

The main gain of different syntax between Delphi and ObjFpc is more
troubles for Pascal Programmers. :(

Why you decide to prohibit static array constants inside dynamic array
constants for Delphi modes in r39045? I do not understand this decision. It
is some punishment for using Delphi mode? -,- IMO bad decision.

For the consequence the following code

var
  f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];

should be also prohibited in Delphi mode, because it not works in Delphi
like static array constants inside dynamic array constants...

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Jesus Reyes A.
En Sun, 20 May 2018 07:23:25 -0500, Sven Barth via fpc-pascal  
 escribió:



Hello together!

I'm pleased to announce that after nearly a year various extensions for  
dynamic arrays have been finished. This includes the following features:


- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)



Wow!
Thanks :)

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Sven Barth via fpc-pascal
Mattias Gaertner  schrieb am So., 20. Mai 2018,
17:58:

> >[...]
> > === code end ===
> >
> > For constants the dynamic array constants adhere to the writable
> > constants switch $J. E.g. the following will result in an exception:
> >
> > === code begin ===
> >
> > {$J-}
> > const
> >Test1: array of LongInt  = (1, 2, 3);
> > begin
> >Test1[1] := 42;
> > end.
>
> This seems to be inconsistent with
>
> procedure Test(const a: TStringDynArray);
> begin
>   a[1]:='42';
> end;
>
> Isn't it?
>

But it is consistent with static array constants and that is what counts...

Regards,
Sven

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Sven Barth via fpc-pascal
Anthony Walter  schrieb am So., 20. Mai 2018, 19:09:

> By the way, what's the reason for differences in () / [] syntax between
> objpas and delphi mode?
>

For the non-Delphi modes I decided to keep consistency with static array
constants (which use the same syntax in Delphi btw!). For the Delphi modes
I followed what Delphi does. And for some reason the Delphi devs thought it
better to use a different syntax than that for static arrays. 路‍♀️

Regards,
Sven

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Anthony Walter
Never mind, I found the problem.

program hello;

{$mode delphi}

procedure Test;
var
  Data: array of Integer = [0, 15, 24];
  I: Integer;
begin
  WriteLn('Testing new array features');
  for I in Data do
WriteLn(I); // fixed
end;

begin
  Test;
end.

Outputs:

Testing new array features
0
15
24
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Anthony Walter
I just got fpc from svn trunk (http://svn.freepascal.org/svn/fpc/trunk/)
and tested. Before I submit to Mantis, can you tell me if I made a mistake
here?

program hello;

{$mode delphi}

procedure Test;
var
  Data: array of Integer = [0, 15, 24];
  I: Integer;
begin
  WriteLn('Testing new array features');
  for I in Data do
WriteLn(Data[I]);
end;

begin
  Test;
end.

Outputs:

Testing new array features
0
0
-2235258
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Anthony Walter
Holy crap Sven. This is so awesome! I was going to write a request last
week to allow for a simplified array constant declaration, and you've
already got it done.

Thanks for your work. I'll test it momentarily and report any actual
problems to Mantis.

By the way, what's the reason for differences in () / [] syntax between
objpas and delphi mode?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Michael Van Canneyt



On Sun, 20 May 2018, Mattias Gaertner wrote:


On Sun, 20 May 2018 14:23:25 +0200
Sven Barth via fpc-pascal  wrote:


Hello together!

I'm pleased to announce that after nearly a year various extensions for 
dynamic arrays have been finished. This includes the following features:


- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)


:)

I hope 3.2 is coming soon.



[...]
=== code end ===

For constants the dynamic array constants adhere to the writable 
constants switch $J. E.g. the following will result in an exception:


=== code begin ===

{$J-}
const
   Test1: array of LongInt  = (1, 2, 3);
begin
   Test1[1] := 42;
end.


This seems to be inconsistent with

procedure Test(const a: TStringDynArray);
begin
 a[1]:='42';
end;

Isn't it?


The const in the parameters indicates that the pointer a cannot be assigned,
but the contents can be assigned when inside the procedure.
(we can discuss whether this behaviour is logical, but I suppose we
inherited this from Delphi)

Whereas a constant is something that is eternally constant throughout the
application. Normally, a constant is something that is replaced by its
value when the compiler encounters it the sources.

So in a sense, it does not exist at runtime, hence you cannot assign to it
either.

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

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Mattias Gaertner
On Sun, 20 May 2018 14:23:25 +0200
Sven Barth via fpc-pascal  wrote:

> Hello together!
> 
> I'm pleased to announce that after nearly a year various extensions for 
> dynamic arrays have been finished. This includes the following features:
> 
> - support for array constructors using "[...]" syntax
> - support for Insert(), Delete() and Concat()
> - support for "+" operator
> - support for dynamic array constants (and variable initializations)

:)

I hope 3.2 is coming soon.


>[...]
> === code end ===
> 
> For constants the dynamic array constants adhere to the writable 
> constants switch $J. E.g. the following will result in an exception:
> 
> === code begin ===
> 
> {$J-}
> const
>    Test1: array of LongInt  = (1, 2, 3);
> begin
>    Test1[1] := 42;
> end.

This seems to be inconsistent with

procedure Test(const a: TStringDynArray);
begin
  a[1]:='42';
end;

Isn't it?
 
Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Michael Van Canneyt



On Sun, 20 May 2018, Sven Barth via fpc-pascal wrote:


Hello together!

I'm pleased to announce that after nearly a year various extensions for 
dynamic arrays have been finished. This includes the following features:


- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)



Congratulations, job well done. This makes life a lot easier !

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

[fpc-pascal] Feature announcement: Dynamic array extensions

2018-05-20 Thread Sven Barth via fpc-pascal

Hello together!

I'm pleased to announce that after nearly a year various extensions for 
dynamic arrays have been finished. This includes the following features:


- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)

In the following the features will be explained in detail:

## Array Constructors

It is now possible to initialize a dynamic array variable or parameter 
using the "[...]" which is also known from open array parameters. Unlike 
the ArrayType.Create() syntax which had been introduced with 3.0 this 
also works with unnamed array types. Nested dynamic arrays are also 
supported.


=== code begin ===

var
  t: array of LongInt;
  t2: array of array of LongInt;
begin
  t := [1, 2, 3, 4];
  t2 := [[1, 2, 3], [4, 5]];
end.

=== code end ===

## Insert(), Delete(), Concat()

The intrinsics Insert(), Delete() and Concat() can now be used with 
dynamic arrays as well.


Insert() allows to insert a single element, a dynamic array or a static 
array into a dynamic array at a specific index (zero based). If the 
dynamic array is empty it will simply contain the content to be 
inserted. If the index to insert is larger than the array's High() then 
the content will be added at the end.


Delete() allows to remove a range of elements from a dynamic array (the 
start index is zero based). The range will be capped to the array's 
boundaries.


Concat() allows to concatenate two (or more) dynamic arrays together. 
The second array content starts directly after the first and those of 
the third after the second and so on.


## "+" operator

The compiler now implements a "+" operator for arrays which is the same 
as if Concat() would be called on the arrays.


Note regarding backwards compatibility: existing "+" operator overloads 
for dynamic arrays no longer compile.


## Dynamic array constants

It is now possible to initialize dynamic array constants and variables 
with concrete contents in contrast to merely Nil. The syntax for this is 
the same as for static array constant and variable initializations.


=== code begin ===

const
  Test1: array of LongInt = (1, 2, 3);
var
  Test2: array of String = ('Alpha', 'Beta', 'Gamma');

=== code end ===

For constants the dynamic array constants adhere to the writable 
constants switch $J. E.g. the following will result in an exception:


=== code begin ===

{$J-}
const
  Test1: array of LongInt  = (1, 2, 3);
begin
  Test1[1] := 42;
end.

=== code end ===

It is possible to nest dynamic and static array constants.

Delphi compatibility:

- in Delphi modes the syntax for dynamic array constant and variable 
initialization is "[...]" instead of "(...)"
- Delphi does not adhere to the writable constants switch regarding the 
array's contents (so the example above - when adjusted for Delphi's 
syntax - will not result in an exception)
- Delphi does not correctly parse static array constants inside dynamic 
arrays; as we don't know what the syntax would be for Delphi then, this 
is prohibited in Delphi modes


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

Re: [fpc-pascal] TJSFloat32Array casting

2018-05-20 Thread Ryan Joseph
Sorry, I didn’t intend to post to this list. Please disregard.

> On May 20, 2018, at 3:23 PM, Ryan Joseph  wrote:
> 
> Did something change? I just tried this and it didn’t work. Casting “arr” to 
> TJSObject didn’t work either. I could swear that used to work a few days ago. 
> Maybe an overload is missing? If TJSArray = TJSObject then should “array of 
> single” = TJSObject?
> 
> var
>  arr: array of single;
> begin
> 
> TJSFloat32Array.new(TJSArray(arr)); // Incompatible type arg no. 1: Got 
> "TJSArray", expected “TJSArrayBuffer”
> TJSFloat32Array.new(TJSObject(arr)); // Illegal type conversion: "array type" 
> to "class TJSObject"
> 
> 
> 
> Regards,
>   Ryan Joseph
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Regards,
Ryan Joseph

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

[fpc-pascal] TJSFloat32Array casting

2018-05-20 Thread Ryan Joseph
Did something change? I just tried this and it didn’t work. Casting “arr” to 
TJSObject didn’t work either. I could swear that used to work a few days ago. 
Maybe an overload is missing? If TJSArray = TJSObject then should “array of 
single” = TJSObject?

var
  arr: array of single;
begin

TJSFloat32Array.new(TJSArray(arr)); // Incompatible type arg no. 1: Got 
"TJSArray", expected “TJSArrayBuffer”
TJSFloat32Array.new(TJSObject(arr)); // Illegal type conversion: "array type" 
to "class TJSObject"



Regards,
Ryan Joseph

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

Re: [fpc-pascal] LongBool True = -1

2018-05-20 Thread Sven Barth via fpc-pascal
Dmitry Boyarintsev  schrieb am So., 20. Mai
2018, 04:38:

> On Thu, May 17, 2018 at 5:26 PM, Anthony Walter  wrote:
>
>> I am working with some a glib library that expects gboolean to be
>> positive 1 for true, yet FPC emits -1 for true.
>>
>
> I'd think that pascal defines true as
>   true = not false;
> In case of unsigned integers "-1" is not an option
>

FPC defines True as 1 for Boolean, Boolean16, Boolean32 and Boolean64 and
as "-1" aka "all bits 1" for Byte Book, WordBool, LongBool and QWordBool.

And for unsigned integers "-1" is converted to "all bits 1" as well though
one needs to use a typecast (see the declaration of INVALID_HANDLE_VALUE
for example).

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