Re: [fpc-pascal] INSTALL_PREFIX, INSTALL_LIBDIR

[Mattias Gaertner via fpc-pascal]

On Fri, 19 Oct 2018 16:40:19 +0200
christo  wrote:

> On 2018/10/18 09:26, Mattias Gaertner via fpc-pascal wrote:
> > How to control where 'make install' puts the libraries (e.g.
> > libpas2js.so)?
> >
> > I tried "INSTALL_LIBDIR=~/tmp/lib64", but that moves everything
> > *except* libraries to "~/tmp/lib64".
> >
> > See bug https://bugs.freepascal.org/view.php?id=34346  
> 
> In trunk (rev. 39838):
> 
> "make info FPC=[path to ppcx64]" gives:
> 
> Install base dir. /usr/local/lib/fpc/3.3.1
> Install binary dir... /usr/local/bin
> Install library dir.. /usr/local/lib
> Install units dir /usr/local/lib/fpc/3.3.1/units/x86_64-linux/fpc
> 
> "make info INSTALL_PREFIX=/xxx FPC=[path to ppcx64]" gives:
> 
> Install base dir. /xxx/lib/fpc/3.3.1
> Install binary dir... /xxx/bin
> Install library dir.. /xxx/lib
> Install units dir /xxx/lib/fpc/3.3.1/units/x86_64-linux/fpc
> 
> "make info INSTALL_PREFIX=/xxx INSTALL_LIBDIR=/yyy FPC=[path to
> ppcx64]" gives:
> 
> Install base dir. /xxx/lib/fpc/3.3.1
> Install binary dir... /xxx/bin
> Install library dir.. /yyy
> Install units dir /xxx/lib/fpc/3.3.1/units/x86_64-linux/fpc
> 
> This seems different to your case.  Which version of FPC are you
> using?

With FPC source 3.3.1 and installed fpc 3.0.4 I get:
make info INSTALL_PREFIX=~/tmp/fpc INSTALL_LIBDIR=~/tmp/lib64

Install base dir. /home/mattias/tmp/fpc/lib/fpc/3.0.4
Install binary dir... /home/mattias/tmp/fpc/bin
Install library dir.. /home/mattias/tmp/lib64
Install units
dir /home/mattias/tmp/fpc/lib/fpc/3.0.4/units/x86_64-linux/fpc
Install source dir... /home/mattias/tmp/fpc/share/src/fpc-3.0.4/fpc
Install doc dir.. /home/mattias/tmp/fpc/share/doc/fpc-3.0.4/fpc
Install example
dir.. /home/mattias/tmp/fpc/share/doc/fpc-3.0.4/fpc/examples Install
data dir. /home/mattias/tmp/fpc/lib/fpc/3.0.4

make install INSTALL_PREFIX=~/tmp/fpc INSTALL_LIBDIR=~/tmp/lib64

The ppu files of rtl are installed under
~/tmp/fpc/lib/fpc/3.3.1/units/x86_64-linux/rtl/

While all other ppu files are installed under
~/tmp/lib64/fpc/3.3.1/units/x86_64-linux/

libpas2jslib.so is installed under
~/tmp/fpc/lib/libpas2jslib.so

IMO that is not useful aka a bug.

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

[fpc-pascal] Uniform initialization?

[Ryan Joseph]

Since I’ve got a little more free time I wanted to see if there was a simple 
solution to issue in Pascal that causes quite a bit of friction for me, i.e. 
constructor boiler plate. In c++ there is “uniform initialization” for structs 
which uses the {} syntax. It’s basically identically to record consts in 
Pascal, i.e.

type
  tvec2 = record
x,y:integer;
  end;

var
  vec: tvec2 = (x:1;y1);

but it can be used at runtime (unlike Pascal which is compile time only). Many 
months ago I mentioned this and got a little positive response so I’d to ask 
again since I could probably implement it now.

Are any of these ideas appealing?

1) Simply move the typed const syntax down into blocks and use the type name 
like a function i.e.,

var
 vec:tvec2;
begin
 vec := tvec2(x:1;y1);

2) providing advanced records are on and perhaps a mode switch or some other 
kind of decorator, auto generate an implicit constructor, given no other 
constructors named “create" in the structure exist. i.e.,

{$something+}
type
  tvec2 = record
x,y:integer;
  end;
{$something-}

var
 vec:tvec2;
begin
  vec := tvec2.create(1,1); // tvec2 has no constructor defined so “create” 
with all public member fields as parameters is implicitly defined
  vec := tvec2.create;  // “create” is a static class function with default 
values so we can do this
end.

Here is the proposed implicit constructor for tvec2:

class function 
create(_x:integer=default(integer);y:integer=default(integer)):tvec2;static;

I prefer #2 because it’s easiest to type and looks most natural to Pascal. Not 
sure what the downsides are even???

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Uniform initialization?

[tobiasgiesen]

Hello,

Delphi 10.3 is going to support inline variable declarations like this:
begin
  var i : Integer := 22;
  WriteLn(i);
  end;

I would assume it can also be used with records. For details, please see
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

So maybe that's the route to go.

Cheers,
Tobias


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

Re: [fpc-pascal] Uniform initialization?

[Ryan Joseph]

> On Nov 11, 2018, at 10:03 PM, tobiasgie...@gmail.com wrote:
> 
> Hello,
> 
> Delphi 10.3 is going to support inline variable declarations like this:
> begin
>  var i : Integer := 22;
>  WriteLn(i);
>  end;
> 
> I would assume it can also be used with records. For details, please see
> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html
> 
> So maybe that's the route to go.

That’s interesting Delphi is breaking with the one of the oldest Pascal 
traditions. I have no idea what implications that would have for FPC or if it 
will be supported. If I recall this idea was shunned pretty thoroughly on the 
list a few months ago.

It’s still not a replacement for implicit constructors though since it’s tied 
to declaration time. Swift has implicit constructors for structs but uses the 
normal constructor syntax, unlike c++ which uses a special {} syntax. It really 
cuts down on boiler plate stuff when making new records. It’s a no-brainer for 
me and super easy to implement (already got most of it done today before I 
thought to ask) but lets see what people have to say.

Anonymous functions are still my biggest wish for FPC but they are considerably 
more complicated than what I can do currently.  

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Uniform initialization?

[Sven Barth via fpc-pascal]

Am 11.11.2018 um 16:03 schrieb tobiasgie...@gmail.com:

Hello,

Delphi 10.3 is going to support inline variable declarations like this:
begin
   var i : Integer := 22;
   WriteLn(i);
   end;

I would assume it can also be used with records. For details, please see
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

So maybe that's the route to go.

We've already decided internally that we are *not* going to support this.

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

Re: [fpc-pascal] Uniform initialization?

[Sven Barth via fpc-pascal]

Am 11.11.2018 um 12:59 schrieb Ryan Joseph:

Since I’ve got a little more free time I wanted to see if there was a simple 
solution to issue in Pascal that causes quite a bit of friction for me, i.e. 
constructor boiler plate. In c++ there is “uniform initialization” for structs 
which uses the {} syntax. It’s basically identically to record consts in 
Pascal, i.e.

type
   tvec2 = record
 x,y:integer;
   end;

var
   vec: tvec2 = (x:1;y1);

but it can be used at runtime (unlike Pascal which is compile time only). Many 
months ago I mentioned this and got a little positive response so I’d to ask 
again since I could probably implement it now.

Are any of these ideas appealing?

1) Simply move the typed const syntax down into blocks and use the type name 
like a function i.e.,

var
  vec:tvec2;
begin
  vec := tvec2(x:1;y1);

2) providing advanced records are on and perhaps a mode switch or some other kind of 
decorator, auto generate an implicit constructor, given no other constructors named 
“create" in the structure exist. i.e.,

{$something+}
type
   tvec2 = record
 x,y:integer;
   end;
{$something-}

var
  vec:tvec2;
begin
   vec := tvec2.create(1,1); // tvec2 has no constructor defined so “create” 
with all public member fields as parameters is implicitly defined
   vec := tvec2.create; // “create” is a static class function with default 
values so we can do this
end.

Here is the proposed implicit constructor for tvec2:

class function 
create(_x:integer=default(integer);y:integer=default(integer)):tvec2;static;

I prefer #2 because it’s easiest to type and looks most natural to Pascal. Not 
sure what the downsides are even???
I'm not convinced that this feature is really needed, because one can 
simply create a constant and assign that, would transport a clear name 
as well.
But *if* I had to decide I would pick #1, cause then there wouldn't be 
the chance to break existing code if a user decides to add a constructor 
to their record and some other code relies on there not being a 
constructor. Also due to the syntax 
TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's in principle 
possible to have the parser distinguish whether it's a typecast or a 
default constructor.


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

[fpc-pascal] Running tests with FPC units only

[luciano de souza]

Hello hall,
I am blind, so I don't use Lazarus. In pure Freepascal, I tried to run
an example test:

program tester;
{$mode objfpc}{$H+}

uses
fpcunit, testregistry;

type
TMyTest = class(TTestCase)
published
procedure TestSomething;
end;

procedure TMyTest.TestSomething;
begin
AssertEquals(1, 1);
end;

BEGIN
RegisterTest(TMyTest);
END.

This code compiles, but doesn't do anything. Here tests were only
registered, not run.
For this purpose, acording example I found in FPC examples directory,
I need the class TTestRunner.

BEGIN
with TTestRunner.create(nil) do
begin
try
initialize;
run;
finally
free;
end;
end;
END.

However, TTestRunner belongs to consoletestrunner, a non Freepascal unit.
I imagine there is a way to run tests only with Freepascal units. But
how to do this without consoletestrunner, a unit found in Lazarus?
Best regards,

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

Re: [fpc-pascal] Uniform initialization?

[leledumbo via fpc-pascal]

> But *if* I had to decide I would pick #1, cause then there wouldn't be 
> the chance to break existing code if a user decides to add a constructor 
> to their record and some other code relies on there not being a 
> constructor. Also due to the syntax 
> TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's in principle 
> possible to have the parser distinguish whether it's a typecast or a 
> default constructor. 

I would pick #1, too, seems more natural to me. There's no ambiguity as well
thanks to : in the syntax. I do wonder how often this would be used, though.
Despite being idiomatic in many languages, it doesn't really save much
typing that traditional way (if that's the main purpose).



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Running tests with FPC units only

[leledumbo via fpc-pascal]

> acording example I found in FPC examples directory, 

Check the one here instead:
$(fpcsrcdir)/packages/fcl-fpcunit/src/demo/consolerunner/testrunner.pp
It depends only on FPC units. I guess you're looking at examples from
Lazarus directory instead of FPC.



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Running tests with FPC units only

[luciano de souza]

What a shame! I shouldn't be so inattentive! Sorry, you are completely right!

2018-11-11 16:57 GMT-02:00, leledumbo via fpc-pascal
:
>> acording example I found in FPC examples directory,
>
> Check the one here instead:
> $(fpcsrcdir)/packages/fcl-fpcunit/src/demo/consolerunner/testrunner.pp
> It depends only on FPC units. I guess you're looking at examples from
> Lazarus directory instead of FPC.
>
>
>
> --
> Sent from: http://free-pascal-general.1045716.n5.nabble.com/
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: [fpc-pascal] Uniform initialization?

[Sven Barth via fpc-pascal]

Am 11.11.2018 um 19:29 schrieb leledumbo via fpc-pascal:

But *if* I had to decide I would pick #1, cause then there wouldn't be
the chance to break existing code if a user decides to add a constructor
to their record and some other code relies on there not being a
constructor. Also due to the syntax
TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's in principle
possible to have the parser distinguish whether it's a typecast or a
default constructor.

I would pick #1, too, seems more natural to me. There's no ambiguity as well
thanks to : in the syntax. I do wonder how often this would be used, though.
Despite being idiomatic in many languages, it doesn't really save much
typing that traditional way (if that's the main purpose).
Especially if you're using the same initialization values more often 
you'd safe more time by declaring a suitable constant and using that as 
the IDE can help you with code completion when using the constant.


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

Re: [fpc-pascal] Default record const values

[Sven Barth via fpc-pascal]

Am 10.11.2018 um 09:35 schrieb Ryan Joseph:

Should’t this work? This would be a good way to set default record values but 
it doesn’t seem to be supported.


type
TMyRecord = record
public
a: integer;
b: string;
const
default: TMyRecord = (a: 100; b: 'foo');
end;
The compiler now correctly rejects such declarations with a "Type is not 
completely defined error".


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

Re: [fpc-pascal] Uniform initialization?

[Vojtěch Čihák]

Very good.
 
V.
__

Od: "Sven Barth via fpc-pascal" 
Komu: fpc-pascal@lists.freepascal.org
Datum: 11.11.2018 18:22
Předmět: Re: [fpc-pascal] Uniform initialization?


Am 11.11.2018 um 16:03 schrieb tobiasgie...@gmail.com:
> Hello,
>
> Delphi 10.3 is going to support inline variable declarations like this:
> begin
>    var i : Integer := 22;
>    WriteLn(i);
>    end;
>
> I would assume it can also be used with records. For details, please see
> http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html 

>
> So maybe that's the route to go.
We've already decided internally that we are *not* going to support this.

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

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

Re: [fpc-pascal] Default record const values

[Ryan Joseph]

> On Nov 12, 2018, at 5:06 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> The compiler now correctly rejects such declarations with a "Type is not 
> completely defined error".

But this syntax worked if you assigned it within blocks. Why does it need to be 
removed? Since I discovered it I was planning on using it instead of class 
functions with default values which require an implementation and are much 
longer to write.



Regards,
Ryan Joseph

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

Re: [fpc-pascal] Default record const values

[Ryan Joseph]

> On Nov 12, 2018, at 8:08 AM, Ryan Joseph  wrote:
> 
> But this syntax worked if you assigned it within blocks. Why does it need to 
> be removed? Since I discovered it I was planning on using it instead of class 
> functions with default values which require an implementation and are much 
> longer to write.

Here’s an example of what I was doing before. A constant is so much better and 
doesn’t require the implementation and we still get the same . syntax, i.e., 
TPoint.Up. 

Instead of removing it maybe give the error unless it’s the last field of the 
record and in which case can assumed to be fully defined.

type
  TPoint = record
x: TFloat;
y: TFloat;
class function Up (_x: TFloat = 0; _y: TFloat = -1): TPoint; static; inline;

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Uniform initialization?

[Ryan Joseph]

> On Nov 12, 2018, at 12:25 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> I'm not convinced that this feature is really needed, because one can simply 
> create a constant and assign that, would transport a clear name as well.

This is for runtime though and necessarily for constants. It’s just a short 
hand for initializing records so you don’t need to make boiler plate 
constructors. Often time when you create a new record you add a constructor so 
you can init in one line. Swift and c++ both have this default constructor and 
it’s a nice time saver.

for example:

struct Vec2 {
float x,y;
};

int main() {
Vec2 v = {1,2};
v = {v.x + 1, v.y + 1}; 
return 0;
}

> But *if* I had to decide I would pick #1, cause then there wouldn't be the 
> chance to break existing code if a user decides to add a constructor to their 
> record and some other code relies on there not being a constructor. Also due 
> to the syntax TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's in 
> principle possible to have the parser distinguish whether it's a typecast or 
> a default constructor.

Yeah there could be name conflicts then. Maybe there should be some way to 
explicitly state you want the constructor with a certain name, i.e.,

type
TVec2 = record
x, y: integer;
constructor create; default;
end;

??? I don’t know, just an idea.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Default record const values

[Sven Barth via fpc-pascal]

Am Mo., 12. Nov. 2018, 02:56 hat Ryan Joseph 
geschrieben:

>
>
> > On Nov 12, 2018, at 8:08 AM, Ryan Joseph 
> wrote:
> >
> > But this syntax worked if you assigned it within blocks. Why does it
> need to be removed? Since I discovered it I was planning on using it
> instead of class functions with default values which require an
> implementation and are much longer to write.
>
> Here’s an example of what I was doing before. A constant is so much better
> and doesn’t require the implementation and we still get the same . syntax,
> i.e., TPoint.Up.
>
> Instead of removing it maybe give the error unless it’s the last field of
> the record and in which case can assumed to be fully defined.
>

No, that is too random for a language.
This change is not up for discussion as it could lead to incorrect code.

Regards,
Sven

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

Re: [fpc-pascal] Uniform initialization?

[Sven Barth via fpc-pascal]

Am Mo., 12. Nov. 2018, 03:12 hat Ryan Joseph 
geschrieben:

>
>
> > On Nov 12, 2018, at 12:25 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > I'm not convinced that this feature is really needed, because one can
> simply create a constant and assign that, would transport a clear name as
> well.
>
> This is for runtime though and necessarily for constants. It’s just a
> short hand for initializing records so you don’t need to make boiler plate
> constructors. Often time when you create a new record you add a constructor
> so you can init in one line. Swift and c++ both have this default
> constructor and it’s a nice time saver.
>
> for example:
>
> struct Vec2 {
> float x,y;
> };
>
> int main() {
> Vec2 v = {1,2};
> v = {v.x + 1, v.y + 1};
> return 0;
> }
>

The advantage of the typecast like syntax is that you can get compiler
errors if for whatever reason the order of the fields is changed as they
are all named.


> > But *if* I had to decide I would pick #1, cause then there wouldn't be
> the chance to break existing code if a user decides to add a constructor to
> their record and some other code relies on there not being a constructor.
> Also due to the syntax TYPENAME(FIELDNAME:VALUE[;FIELDNAME:VALUE[;…]]) it's
> in principle possible to have the parser distinguish whether it's a
> typecast or a default constructor.
>
> Yeah there could be name conflicts then. Maybe there should be some way to
> explicitly state you want the constructor with a certain name, i.e.,
>
> type
> TVec2 = record
> x, y: integer;
> constructor create; default;
> end;
>
> ??? I don’t know, just an idea.
>

That is a constructor that takes no arguments. How do you think that is
useful for a constructor that *does* take arguments? That is absolutely not
clear at all for the user.

Regards,
Sven

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