Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3

[Bo Berglund]

On Mon, 29 May 2017 23:28:47 +0200, Bo Berglund
 wrote:

>make install OPT=-dFPC_ARMHF PREFIX=/home/pi

I noticed the "command not found" error and realized that the command
did not specify the ppcarm location. Since this is a barebones RPi3
there is no path to ppcarm yet. FPC needs to be specified.

It should have read:

make install OPT=-dFPC_ARMHF PREFIX=/home/pi
FPC="/home/pi/dev/fpc/ppcarm"

I have stepped through the remaining lines in the script and manually
entered the commands with proper expansion of the config variables and
it seems like it does work now.


-- 
Bo Berglund
Developer in Sweden

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

Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3

[Tomas Hajny]

On Mon, May 29, 2017 23:28, Bo Berglund wrote:
> I have bought and initialized a new RPi3 today. It runs Raspbian
> Jessie PIXEL latest version.
> To install FPC I use a script file which sets up the Pi for FPC
> development with FPC3.0.2 and Lazarus 1.6.4.
> It automatically downloads all needed fpc and lazarus files using svn
> and it also updates the system with the dependencies before starting
> the download.
>
> The script can be found here:
> http://blog.boberglund.com/install_lazfpc_local_pi.sh
>
> Before running the script I have prepared the system as follows:
> 1) Created directory /home/pi/bin
> 2) Logged off, then on again to make the bin dir appear in $PATH
> 3) Edited the script config to reflect the wanted version FPC 3.0.2
> and Lazarus 1.6.4
> 4) Then started the script
>
> The script runs fine for about 19 minutes when it exits with a bunch
> of error messages I don't understand. Last time I installed on a brand
> new RPi3 it sucessfully ran all the way to the end.
>
> The command that fails after a long time is:
>
> make install OPT=-dFPC_ARMHF PREFIX=/home/pi
>
> What can be done about this and what is causing it?
> I do not understand what -iVSPTPSOTO is...

These are FPC command line options used in the Makefile to gather
information about your environment. Apparently, the compiler binary was
not found, which is the reason why it's missing before the parameters.



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

Re: [fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3

[leledumbo via fpc-pascal]

> I do not understand what -iVSPTPSOTO is... 

That's what happened when the compiler cannot be called by make. Watch:

> make: -iVSPTPSOTO: Command not found

it's a parameter list for fpc to get (from fpc -h):

  -i Information
...
  -iSO   Return compiler OS
  -iSP   Return compiler host processor
  -iTO   Return target OS
  -iTP   Return target processor
  -iVReturn short compiler version
...




--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Error-building-FPC-3-0-2-from-svn-sources-on-RPi3-tp5728941p5728942.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Error building FPC 3.0.2 from svn sources on RPi3

[Bo Berglund]

I have bought and initialized a new RPi3 today. It runs Raspbian
Jessie PIXEL latest version.
To install FPC I use a script file which sets up the Pi for FPC
development with FPC3.0.2 and Lazarus 1.6.4.
It automatically downloads all needed fpc and lazarus files using svn
and it also updates the system with the dependencies before starting
the download.

The script can be found here:
http://blog.boberglund.com/install_lazfpc_local_pi.sh

Before running the script I have prepared the system as follows:
1) Created directory /home/pi/bin
2) Logged off, then on again to make the bin dir appear in $PATH
3) Edited the script config to reflect the wanted version FPC 3.0.2
and Lazarus 1.6.4
4) Then started the script

The script runs fine for about 19 minutes when it exits with a bunch
of error messages I don't understand. Last time I installed on a brand
new RPi3 it sucessfully ran all the way to the end.

The command that fails after a long time is:

make install OPT=-dFPC_ARMHF PREFIX=/home/pi

What can be done about this and what is causing it?
I do not understand what -iVSPTPSOTO is...

Here is the error output:
--
/usr/bin/ld: warning: ./link.res contains output sections; did you
forget -T?
make[2]: Leaving directory '/home/pi/dev/fpc/3.0.2/installer'
make[1]: Leaving directory '/home/pi/dev/fpc/3.0.2'
/bin/echo Build > build-stamp.arm-linux
/bin/echo Build > base.build-stamp.arm-linux
make: -iVSPTPSOTO: Command not found
make compiler_cycle RELEASE=1
make[1]: Entering directory '/home/pi/dev/fpc/3.0.2'
make[1]: -iVSPTPSOTO: Command not found
make -C compiler cycle
make[2]: Entering directory '/home/pi/dev/fpc/3.0.2/compiler'
make[2]: -iVSPTPSOTO: Command not found
make tempclean ppc3.exe
make[3]: Entering directory '/home/pi/dev/fpc/3.0.2/compiler'
make[3]: -iVSPTPSOTO: Command not found
/bin/rm -f ppcross ppc ppc1.exe ppc2.exe ppc3.exe ./msg2inc.exe
pp1.wpo pp2.wpo
make 'OLDFPC=' next CYCLELEVEL=1
make[4]: Entering directory '/home/pi/dev/fpc/3.0.2/compiler'
make[4]: -iVSPTPSOTO: Command not found
make rtlclean rtl
make[5]: Entering directory '/home/pi/dev/fpc/3.0.2/compiler'
make[5]: -iVSPTPSOTO: Command not found
make -C  clean
make[6]: Entering directory '/home/pi/dev/fpc/3.0.2/compiler'
make[6]: *** clean: No such file or directory.  Stop.
make[6]: Leaving directory '/home/pi/dev/fpc/3.0.2/compiler'
Makefile:4078: recipe for target 'rtlclean' failed
make[5]: *** [rtlclean] Error 2
make[5]: Leaving directory '/home/pi/dev/fpc/3.0.2/compiler'
Makefile:3967: recipe for target 'next' failed
make[4]: *** [next] Error 2
make[4]: Leaving directory '/home/pi/dev/fpc/3.0.2/compiler'
Makefile:3972: recipe for target 'ppc1.exe' failed
make[3]: *** [ppc1.exe] Error 2
make[3]: Leaving directory '/home/pi/dev/fpc/3.0.2/compiler'
Makefile:3984: recipe for target 'cycle' failed
make[2]: *** [cycle] Error 2
make[2]: Leaving directory '/home/pi/dev/fpc/3.0.2/compiler'
Makefile:2779: recipe for target 'compiler_cycle' failed
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory '/home/pi/dev/fpc/3.0.2'
Makefile:2811: recipe for target 'build-stamp.-' failed
make: *** [build-stamp.-] Error 2
install_lazfpc_local_pi.sh: 150: Cannot make install! Aborting


-- 
Bo Berglund
Developer in Sweden

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

Re: [fpc-pascal] GLM library alternative?

[Anthony Walter]

Thanks for posting those LookAt and Perspective routines. They're kind of
needed with OpenGL ES 2.0, as it no longer has matrix modes. You need to
build your own perspective and model view matrices and pass them to your
vertex shaders as uniforms.

uniform mat4 modelview; // modelview matrix uniform
uniform mat4 projection; // projection matrix uniform

attribute vec3 xyz; // vertex position attribute
attribute vec2 uv; // uv texture coordinate attribute

varying vec2 texcoord; // varying texture coordinate

void main()
{
vec4 vertex = modelview * vec4(xyz, 1.0); // transform vertex with
modelview matrix uniform
gl_Position = projection * vertex; // project the transformed vertex
and write it to gl_Position
texcoord = uv; // assign the uv texture coordinate to the varying
}

By the way, what's stopping you guys from using OpenGL ES 2.0? It works on
most all Windows, Mac, and Linux systems, and it's the only 3D graphics API
on Raspberry Pi and most smart phones/tablets.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] named parameter

[Sven Barth via fpc-pascal]

Am 29.05.2017 10:26 schrieb "Ryan Joseph" :
>
>
> > On May 29, 2017, at 1:01 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > If anything like this would be implemented, then the already existing
syntax (for variant dispatch calls) would be used which uses ":=".
> >
> >
>
> What are variant dispatch calls? Maybe something from Delphi I’m not
familiar with.

It's usually used in the context of OLE automation though one could also
use this with independently of OLE/COM.
For an example see here:
https://www.freepascal.org/~michael/articles/word/word.pdf

> That’s too bad, a single colon matches the declaration better and looks
nice.

An assignment is the logical choice cause you're assigning a value to a
parameter. A colon is used for a declaration, which is a completely
different kind of "operation".

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

Re: [fpc-pascal] GLM library alternative?

[Reimar Grabowski]

On Sat, 27 May 2017 16:52:21 +0700
Ryan Joseph  wrote:

> Not having glm::perspective or glm::lookAt is enough to really stop you in 
> your tracks and running off to Google for hours.

Then perhaps you have to improve your google skills. ^^

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluPerspective.xml
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml

Has all the info you need to implement them.

Unoptimized pascal versions (but fast enough for general use):

function TCamera.LookAt(Eye, Center, Up: TVector3): TMatrix4x4;
var
  View, Right: TVector3;
  TransMatrix: TMatrix4x4;
begin
  View:=Normalized(fCoV-Position);
  Right:=Normalized(CrossProduct(View, Up));
  Up:=CrossProduct(Right, View);

  Result[0][0]:=Right.X;
  Result[1][0]:=Right.Y;
  Result[2][0]:=Right.Z;
  Result[3][0]:=0;

  Result[0][1]:=Up.X;
  Result[1][1]:=Up.Y;
  Result[2][1]:=Up.Z;
  Result[3][1]:=0;

  Result[0][2]:=-View.X;
  Result[1][2]:=-View.Y;
  Result[2][2]:=-View.Z;
  Result[3][2]:=0;

  Result[0][3]:=0;
  Result[1][3]:=0;
  Result[2][3]:=0;
  Result[3][3]:=1;

  Result:=MultglMatrix(IdentityMatrix4x4, Result);
  TransMatrix:=IdentityMatrix4x4;
  TransMatrix[3][0]:=-Eye.X;
  TransMatrix[3][1]:=-Eye.Y;
  TransMatrix[3][2]:=-Eye.Z;
  Result:=MultglMatrix(Result, TransMatrix);
end;


function TScene.BuildPerspectiveMatrix(FoV, AspectRatio, NearPlane,
  FarPlane: GLfloat): TMatrix4x4;
var
  XYMax, XMin, YMin, Width, Height, Depth: GLfloat;

begin
  XYMax:=NearPlane*tan(FoV*pi/360);
  YMin:=-XYMax;
  XMin:=-XYMax;
  Width:=XYMax-XMin;
  Height:=XYMax-YMin;
  Depth:=FarPlane-NearPlane;

  Result[0][0]:=(2*NearPlane/Width)/AspectRatio;
  Result[0][1]:=0;
  Result[0][2]:=0;
  Result[0][3]:=0;

  Result[1][0]:=0;
  Result[1][1]:=2*NearPlane/Height;
  Result[1][2]:=0;
  Result[1][3]:=0;

  Result[2][0]:=0;
  Result[2][1]:=0;
  Result[2][2]:=-(NearPlane+FarPlane)/Depth;
  Result[2][3]:=-1;

  Result[3][0]:=0;
  Result[3][1]:=0;
  Result[3][2]:=-2*(FarPlane*NearPlane)/Depth;
  Result[3][3]:=0;
end;

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

Re: [fpc-pascal] GLM library alternative?

[Mattias Gaertner]

On Mon, 29 May 2017 15:29:24 +0700
Ryan Joseph  wrote:

> > On May 29, 2017, at 12:58 PM, Anthony Walter  wrote:
>[...]
> It’s buried now but look at the “FPC Graphics options” thread from a few days 
> ago and spanning back weeks I think. After all that I still failed to get a 
> clear answer I could understand well but some poor loop optimization and 
> floating point division was causing a ray caster example written in Java to 
> get low single digit frame rates where the same code ran 40+fps in Java and 
> C. There seems to be some changes in FPC 3.1.1 but I’m not sure what changed. 
> Some one else may correct what I said but feel free to take a loop. Bottom 
> line for me is I’m nervous about loops in highly optimized low level code now 
> but that may be unfounded.

I will try to summarize the thread:

Jonas told that the benchmark program contains a number of bugs/wrong
translation from the C code:
1) casting a floating point number to an int in C does not round
2) The usage of floor in the test program is wrong.
3) The Pascal version uses longword instead of int32...getting evaluated as 64 
bit on 32 bit
4) frac() is only used to get a monotonous increasing value...

C compilers know what "floor" is doing and optimizes it.

FPC default config does not use optimal settings for todays machines.
Java does, C libs do. I didn't find what Graeme used for his C version.

Some pointed out that the Math unit misses some SSE and double
versions of functions.

Florian improved FPC 3.1.1 boosting the speed from 8 to 23FPS.

Martin used MSELang with LLVM backend, fixed some bugs in the code and
used some optimization flags to get 41 FPS, which looks similar to
Graeme's numbers for the C and Java version.

There were various suggestions for optimizations, which C compilers are
doing and could be added to FPC, but they would be specific to these
benchmarks. Including some loop optimizations.

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

Re: [fpc-pascal] named parameter

[Mark Morgan Lloyd]

On 29/05/17 05:15, Ryan Joseph wrote:

On May 28, 2017, at 5:22 PM, Mark Morgan Lloyd  wrote:> >> IMO 
though it does improve readability in long functions with lots of>> parameters, like windows api style 
procedures that have 5 or more>> parameters and you can't figure out which param is>> which>

You mean like this?
function Foo (theString: string; options: set of TFoo): boolean;beginend;
Foo(theString: 'foo', options: []);
Objective-C has this mandatory and it made for stupidly long method names that 
just looked terrible but it was optional Pascal makes it look nicer. The 
declaration syntax is already the same as the label for the calling syntax so 
that seems like a nice fit.


Except that there's no provision for setting a parameter passed as a set 
element to true if it's not given explicitly. Sometimes you want that, 
and simply inverting the meaning of a parameter results in values which 
appear contrived in the context of the "real world" problem being solved.


The example I gave was from a terminal emulator, where "echo", 
"loopback" and so on are well-accepted concepts in the industry. And 
having a parameter "any_character_set_as_long_as_its_not_apl" is 
downright silly :-)


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[Ryan Joseph]

> On May 29, 2017, at 12:58 PM, Anthony Walter  wrote:
> 
> I'm curious, what's the problem with fpc and loops? Also, from my OpenGL 
> experience the limiting factor in speed (frames per second) is usually the 
> pixel complexity and not whatever method is used to feed vertex data or 
> shader uniforms.
> 

It’s buried now but look at the “FPC Graphics options” thread from a few days 
ago and spanning back weeks I think. After all that I still failed to get a 
clear answer I could understand well but some poor loop optimization and 
floating point division was causing a ray caster example written in Java to get 
low single digit frame rates where the same code ran 40+fps in Java and C. 
There seems to be some changes in FPC 3.1.1 but I’m not sure what changed. Some 
one else may correct what I said but feel free to take a loop. Bottom line for 
me is I’m nervous about loops in highly optimized low level code now but that 
may be unfounded.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] named parameter

[Ryan Joseph]

> On May 29, 2017, at 1:01 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> If anything like this would be implemented, then the already existing syntax 
> (for variant dispatch calls) would be used which uses ":=".
> 
> 

What are variant dispatch calls? Maybe something from Delphi I’m not familiar 
with. 

That’s too bad, a single colon matches the declaration better and looks nice. 

Regards,
Ryan Joseph

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

Re: [fpc-pascal] named parameter

[Sven Barth via fpc-pascal]

Am 29.05.2017 07:13 schrieb "Ryan Joseph" :
>
>
> > On May 28, 2017, at 5:22 PM, Mark Morgan Lloyd <
markmll.fpc-pas...@telemetry.co.uk> wrote:
> >
> >> IMO though it does improve readability in long functions with lots of
> >> parameters, like windows api style procedures that have 5 or more
> >> parameters and you can't figure out which param is
> >> which
> >
>
> You mean like this?
>
> function Foo (theString: string; options: set of TFoo): boolean;
> begin
> end;
>
> Foo(theString: 'foo', options: []);
>
> Objective-C has this mandatory and it made for stupidly long method names
that just looked terrible but it was optional Pascal makes it look nicer.
The declaration syntax is already the same as the label for the calling
syntax so that seems like a nice fit.

If anything like this would be implemented, then the already existing
syntax (for variant dispatch calls) would be used which uses ":=".

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

Re: [fpc-pascal] GLM library alternative?

[Anthony Walter]

I'm curious, what's the problem with fpc and loops? Also, from my OpenGL
experience the limiting factor in speed (frames per second) is usually the
pixel complexity and not whatever method is used to feed vertex data or
shader uniforms.

Wet rock example: http://glslsandbox.com/e#20806.1
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal