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

[Michael Van Canneyt]

On Mon, 15 May 2017, nore...@z505.com wrote:


On 2017-05-12 09:37, Michael Van Canneyt wrote:
Obviously "avoid threads where possible" but only if there is a 
simpler mechanism not reinventing a thread. So it seems to me onidle 
in fpgui is a simpler way than creating a new separate thread 
yourself, but how to do it in a program that has no fpgui onidle?


Check manually. What else is left ? There is no message queue, so no
loop in which to check at regular basis.



What's left is possibly something like apache 1.3 source code which 
somehow, AFAIR avoids using threads by using some other obscure strange 
thing, which I have forgotten. Possibly something like old dos programs 
used (sorry, not a Dos programmer, don't know.. not old enough).


They use select (or poll) and fork. So the equivalent of threads.
mpm = multi process module.

select is basically what peekmessage does.

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you for the explanation.  For now I can live without the windows API 
calls,  It does work to manually switch back and forth to the text console 
window, and I'm really the only one who does that as I sometimes perform some 
diagnostic functions in there.  The performance gains are worth it.   

Is there a way to just turn off the windows title bar when the window is 
created, or change the initial name of the window?

I'll just stick with my BGI fonts for now, if I want to move into true type 
fonts I'll look into doing something as  you suggest with the buffer.

I did figure out what my 217 error was,  it just happened to be the only time I 
right justified something, but it was actually in a unit where I neglected to 
change graph to ptcgraph, and that caused the error.

Thanks again for the help, this is a great quick fix and huge performance gain.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Monday, May 15, 2017 8:46 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/16/2017 01:37 AM, James Richters wrote:
> I have managed to get ptcgraph and ptccrt to work with my program and I can 
> report that there is an AMAZING increase in graphics performance!   It is 
> pretty much a drop in replacement and I did not change any compiler settings. 
>  I did have to make a few minor changes to get it to work, not enough to 
> change the speed of anything.
>
> I am getting an error 217 access violation when I try to use outtextXY after 
> a  SetTextJustify(2,2);  (Top, Right justify)  but with the graph unit my 
> text was in the correct place and not off the screen.
Can you send me a small program that demonstrates the problem, so I can try to 
reproduce it and fix it?
>
> I also no longer have the 'graphwindow' handle variable so I had to 
> comment out anything that was using it like
>
> SetWindowTextA(graphicwindow,graphwindowtext);
> And
> ShowWindow(graphwindow, SW_SHOW);
> So I just commented them out for now.I'm hoping there is a way to get 
> around the graphwindow variable because I was using the above 2 functions and 
> I don't know how else to determine the graphic window handle... but the 
> performance gain and ease of implementation will make working out any other 
> issues worth the effort.  Any advice on how I can capture the graph window 
> handle would be appreciated
Unfortunately, you can't do that and it's actually the main reason why ptcgraph 
is fast. Even if you modify the ptcgraph source, so that you get the window 
handle, it would do you no good, because the window is created in a different 
thread and this means that you cannot draw to the window from your program's 
thread. In fact, all the ptcgraph drawing routines actually render to an 
internal software buffer and issue no winapi drawing calls at all. That's the 
reason ptcgraph is fast and the regular graph unit is slow - the winapi drawing 
routines are really the bottleneck in this case and not the speed of the code, 
generated by FPC.

I know this is not ideal, but probably the easiest option is to find a suitable 
bgi .chr font pack or try a ttf to .chr conversion tool. If you own a copy of 
Turbo Pascal (or Turbo C/C++), you can use the .chr fonts that came with it. 
Unfortunately, other solutions are hard - they involve e.g. linking the 
freetype library, using it to render to a software buffer, and then blitting 
this buffer to the ptcgraph canvas with PutImage. Or doing a similar thing with 
winapi functions, but by drawing the text on a DIB (device independent bitmap, 
basically a memory buffer, holding an image) that you created, instead of on 
the window directly, then reading from the DIB and blitting it with PutImage 
once again.

Best regards,
Nikolay
___
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] FPC Graphics options?

[Nikolay Nikolov]

On 05/16/2017 01:37 AM, James Richters wrote:

I have managed to get ptcgraph and ptccrt to work with my program and I can 
report that there is an AMAZING increase in graphics performance!   It is 
pretty much a drop in replacement and I did not change any compiler settings.  
I did have to make a few minor changes to get it to work, not enough to change 
the speed of anything.

I am getting an error 217 access violation when I try to use outtextXY after a  
SetTextJustify(2,2);  (Top, Right justify)  but with the graph unit my text was 
in the correct place and not off the screen.
Can you send me a small program that demonstrates the problem, so I can 
try to reproduce it and fix it?


I also no longer have the 'graphwindow' handle variable so I had to comment out 
anything that was using it like

SetWindowTextA(graphicwindow,graphwindowtext);
And
ShowWindow(graphwindow, SW_SHOW);
So I just commented them out for now.I'm hoping there is a way to get 
around the graphwindow variable because I was using the above 2 functions and I 
don't know how else to determine the graphic window handle... but the 
performance gain and ease of implementation will make working out any other 
issues worth the effort.  Any advice on how I can capture the graph window 
handle would be appreciated
Unfortunately, you can't do that and it's actually the main reason why 
ptcgraph is fast. Even if you modify the ptcgraph source, so that you 
get the window handle, it would do you no good, because the window is 
created in a different thread and this means that you cannot draw to the 
window from your program's thread. In fact, all the ptcgraph drawing 
routines actually render to an internal software buffer and issue no 
winapi drawing calls at all. That's the reason ptcgraph is fast and the 
regular graph unit is slow - the winapi drawing routines are really the 
bottleneck in this case and not the speed of the code, generated by FPC.


I know this is not ideal, but probably the easiest option is to find a 
suitable bgi .chr font pack or try a ttf to .chr conversion tool. If you 
own a copy of Turbo Pascal (or Turbo C/C++), you can use the .chr fonts 
that came with it. Unfortunately, other solutions are hard - they 
involve e.g. linking the freetype library, using it to render to a 
software buffer, and then blitting this buffer to the ptcgraph canvas 
with PutImage. Or doing a similar thing with winapi functions, but by 
drawing the text on a DIB (device independent bitmap, basically a memory 
buffer, holding an image) that you created, instead of on the window 
directly, then reading from the DIB and blitting it with PutImage once 
again.


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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Yes, I did get the test.png file..  I understand the concept now.  Aggpas 
figures out what the status of the pixels should be then you update the screen 
with those pixels.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 6:05 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 20:50, James Richters wrote:
> see it is going into aggpas units, but I do not get any graphical 
> window, I don't get any errors either, it just runs and exits.

The example is a pure console application with no output to any display. 
Instead it generates a "test.png" file as its output. If you ran the 
Agg2DConsole binary from a command line, there should be a "test.png" 
image in that same directory.

As I mentioned, AggPas can use allocated memory, array, a memory image etc as 
its rendering buffer. If you want a graphical console program
(eg: using Linux Console Framebuffer) using AggPas, then render your 
application output via AggPas to a memory image, then bitblit that image to the 
console graphics output in whatever paint event you have available.

Using AggPas with desktop GUI applications works pretty much identical as 
above, except it bitblit's the memory image to the Window Canvas.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] Best way to check SimpleIPC for messages

[noreply]

On 2017-05-12 09:37, Michael Van Canneyt wrote:
Obviously "avoid threads where possible" but only if there is a 
simpler mechanism not reinventing a thread. So it seems to me onidle 
in fpgui is a simpler way than creating a new separate thread 
yourself, but how to do it in a program that has no fpgui onidle?


Check manually. What else is left ? There is no message queue, so no
loop in which to check at regular basis.



What's left is possibly something like apache 1.3 source code which 
somehow, AFAIR avoids using threads by using some other obscure strange 
thing, which I have forgotten. Possibly something like old dos programs 
used (sorry, not a Dos programmer, don't know.. not old enough).


Quote from some slashdot comment:
"There is an Apache2 mpm, called "prefork", which isn't threaded and 
basically makes Apache2 look like Apache1. But hey, we have a very good 
server already that looks like Apache1."


Some people have magically figured out how to avoid threads using 
possibly bizarre techniques..


Quote " It handles requests in a manner similar to Apache 1.3. It is 
appropriate for sites that need to avoid threading for compatibility 
with non-thread-safe libraries. It is also the best MPM for isolating 
each request, so that a problem with a single request will not affect 
any other."


I looked into the apache 1.3 sources before to figure out what they 
used, but long forgotten now.

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I have managed to get ptcgraph and ptccrt to work with my program and I can 
report that there is an AMAZING increase in graphics performance!   It is 
pretty much a drop in replacement and I did not change any compiler settings.  
I did have to make a few minor changes to get it to work, not enough to change 
the speed of anything.

I am getting an error 217 access violation when I try to use outtextXY after a  
SetTextJustify(2,2);  (Top, Right justify)  but with the graph unit my text was 
in the correct place and not off the screen.

I also no longer have the 'graphwindow' handle variable so I had to comment out 
anything that was using it like

SetWindowTextA(graphicwindow,graphwindowtext);
And 
ShowWindow(graphwindow, SW_SHOW);
So I just commented them out for now.I'm hoping there is a way to get 
around the graphwindow variable because I was using the above 2 functions and I 
don't know how else to determine the graphic window handle... but the 
performance gain and ease of implementation will make working out any other 
issues worth the effort.  Any advice on how I can capture the graph window 
handle would be appreciated

Thank you for the help with this.

Jim

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
nore...@z505.com
Sent: Monday, May 15, 2017 5:50 PM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 01:02, Sven Barth via fpc-pascal wrote:
>>> 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).
> 


Graeme will need to clarify whether he was trying to be harsh on FPC entirely, 
or just specifically in some areas.. :-)

But Nikolay Nikolov's replacement unit should tell if fpc is as fast as 
turbopascal, as he claims it is a direct replacement and is super fast Then 
it's not fpc's fault but some problem in the default unit that was not 
optimized?  I don't know, never tried Nikolay's unit. But that also depends on 
whether Graeme was using that code from that unit too.

Any claims that something is slow depends entirely on 1 million parameters...
Then there are even those projects out there like FastMM but that's probably 
another aside unrelated ___
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] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-15 20:50, James Richters wrote:

see it is going into aggpas units, but I do not get any graphical
window, I don't get any errors either, it just runs and exits.


The example is a pure console application with no output to any display. 
Instead it generates a "test.png" file as its output. If you ran the 
Agg2DConsole binary from a command line, there should be a "test.png" 
image in that same directory.


As I mentioned, AggPas can use allocated memory, array, a memory image 
etc as its rendering buffer. If you want a graphical console program 
(eg: using Linux Console Framebuffer) using AggPas, then render your 
application output via AggPas to a memory image, then bitblit that image 
to the console graphics output in whatever paint event you have available.


Using AggPas with desktop GUI applications works pretty much identical 
as above, except it bitblit's the memory image to the Window Canvas.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-15 01:02, Sven Barth via fpc-pascal wrote:

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).




Graeme will need to clarify whether he was trying to be harsh on FPC 
entirely, or just specifically in some areas.. :-)


But Nikolay Nikolov's replacement unit should tell if fpc is as fast as 
turbopascal, as he claims it is a direct replacement and is super 
fast Then it's not fpc's fault but some problem in the default unit 
that was not optimized?  I don't know, never tried Nikolay's unit. But 
that also depends on whether Graeme was using that code from that unit 
too.


Any claims that something is slow depends entirely on 1 million 
parameters...
Then there are even those projects out there like FastMM but that's 
probably another aside unrelated

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

Re: [fpc-pascal] Size of program vs library ?

[Michael Van Canneyt]

On Mon, 15 May 2017, nore...@z505.com wrote:


On 2017-05-15 04:19, Michael Van Canneyt wrote:

If you want to compare today, you need to add the sizes of all the C
libraries that are loaded during execution of a C program with the
size of an FPC program.

I think you'll find that the sizes of FPC programs are not so different 
then.


Just check the size of libc:

ls /lib/x86_64-linux-gnu/libc-2.19.so -l



But if FPC also uses libc, in units like unix/linux/other .pp units, 
that means FPC is using C libs too..


Unless the user specifically includes it: It does not.

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

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-15 04:26, fredvs wrote:

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX 
paramer

for libraries ? (Bug ?) /



Hopefully that's all there is to it, but how do you know that this 
doesn't just work for your current code and is not reliable for all 
situations?


If that's all there is too it, that's cool! But maybe fpc left it out 
for a reason: like it only works in some test cases of libraries, but 
not all test cases?

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

Re: [fpc-pascal] Size of program vs library ?

[noreply]

On 2017-05-15 04:19, Michael Van Canneyt wrote:

If you want to compare today, you need to add the sizes of all the C
libraries that are loaded during execution of a C program with the
size of an FPC program.

I think you'll find that the sizes of FPC programs are not so different 
then.


Just check the size of libc:

ls /lib/x86_64-linux-gnu/libc-2.19.so -l



But if FPC also uses libc, in units like unix/linux/other .pp units, 
that means FPC is using C libs too..


This also was a claim made by Golang that it doesn't use C code so you 
are comparing apples to Women, but in fact, the women eat apples and 
oranges and See (C) too.

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you, I will try that version and also change to ptcgraph.

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Monday, May 15, 2017 4:32 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?



On 05/15/2017 11:25 PM, Nikolay Nikolov wrote:
>
>
> On 05/15/2017 01:51 PM, James Richters wrote:
>> Thanks for the help and advice with this. I've been trying to figure 
>> out how a lot of this works.  Here's where I'm at
>>
>>> You could try the units ptcgraph or sdlgraph as alternatives (both 
>>> are part of FPC).
>> These seemed like the easiest things to start with.
>>
>> ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem 
>> to get it to be completely full screen 1280x1024 seems to be the 
>> largest I can make it.   2, The graphics window created by ptcgraph 
>> does not respond with wincrt.
> 1. use ptcgraph from fpc trunk, that supports resolutions higher than
> 1280x1024
Sorry, I still haven't updated it in fpc trunk. Use the trunk version from the 
ptcpas sourceforge repo:

https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

Nikolay
___
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] FPC Graphics options?

[Nikolay Nikolov]

On 05/15/2017 11:25 PM, Nikolay Nikolov wrote:



On 05/15/2017 01:51 PM, James Richters wrote:
Thanks for the help and advice with this. I've been trying to figure 
out how a lot of this works.  Here's where I'm at


You could try the units ptcgraph or sdlgraph as alternatives (both 
are part of FPC).

These seemed like the easiest things to start with.

ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem 
to get it to be completely full screen 1280x1024 seems to be the 
largest I can make it.   2, The graphics window created by ptcgraph 
does not respond with wincrt.
1. use ptcgraph from fpc trunk, that supports resolutions higher than 
1280x1024
Sorry, I still haven't updated it in fpc trunk. Use the trunk version 
from the ptcpas sourceforge repo:


https://sourceforge.net/p/ptcpas/code/HEAD/tree/trunk/

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

Re: [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/15/2017 01:51 PM, James Richters wrote:

Thanks for the help and advice with this.  I've been trying to figure out how a 
lot of this works.  Here's where I'm at


You could try the units ptcgraph or sdlgraph as alternatives (both are part of 
FPC).

These seemed like the easiest things to start with.

ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem to get it 
to be completely full screen 1280x1024 seems to be the largest I can make it.   
2, The graphics window created by ptcgraph does not respond with wincrt.
1. use ptcgraph from fpc trunk, that supports resolutions higher than 
1280x1024

2. use ptccrt instead of wincrt

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I put freetype.dll in with the sample program and I was able to successfully 
compile it, and I can even run it without any errors, but I never get any 
graphics display.. am I missing some obvious step?I am compiling and 
running it with the Free Pascal text mode IDE, I added the paths to aggpas to 
my directories so it is finding them and using them.  I can trace into the 
program and I see it is going into aggpas units, but I do not get any graphical 
window, I don't get any errors either, it just runs and exits.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 11:57 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 16:28, James Richters wrote:
> Agg2dconsole.exe - System Error The Program can't start because 
> freetype.dll is missing from your computer. Try reinstalling the 
> program to fix the problem
>
> Any ideas?

Sorry about that. AggPas uses the FreeType library (preferred - more features 
that GDI) or Windows GDI for font support. Seeing as that demo doesn't output 
text, I really should have disabled font support via

   {$DEFINE AGG2D_NO_FONT}

at the top of the unit, but I forgot to do that. So, you can do the above and 
recompile or...

Alternatively, simply copy the freetype.dll into the same directory as the 
executable, or in your Windows System path. You can find a copy included with 
fpGUI's code repository in a ZIP file located at:

   /extras/freetype_windows/freetype.zip



Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] FPC 64bit for windows

[Graeme Geldenhuys]

On 2017-05-15 18:19, James Richters wrote:

Could you please give me a link to download 3.0.2 source archive?
I'm on the FPC sourceforge page but I'm very confused as to what is
what.



All downloads can be found from here:

  https://sourceforge.net/projects/freepascal/files/

From there you click "Source" and then "3.0.2".  ;)

  https://sourceforge.net/projects/freepascal/files/Source/3.0.2/

For Windows you probably want the .zip file so look for:

   fpc-3.0.2.source.zip

For Linux/FreeBSD/*nix you probably want the .tar.gz file so look for:

   fpc-3.0.2.source.tar.gz

But in actual fact, the FPC compiler will compile either of them without 
problems. I ofter share a source archive between my Linux and Windows VMs.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Jon Foster]

On 05/13/2017 12:24 PM, Graeme Geldenhuys wrote:

On 2017-05-13 18:02, Jon Foster wrote:

Speaking of Java ... that's a hard comparison to make. There are so many
Java implementations.


Doesn't IBM, Linux, FreeBSD etc use OpenJDK? I was also under the 
impression that Oracle now also uses OpenJDK as the base for their 
releases - with some of their own additions. If this is all correct, it 
means they all pretty much use the same Java VM and Compiler 
implementations.


I can't really speak for most of those as I'm not interested in the Java 
platform. The language is too inflexible and on some, if not many platforms 
its interpreted. As you saw in my chart that hurts. Linux doesn't use Java. 
Its just another piece software installed by the user when they want it. 
Which means they are free to install whatever derivative of Java they 
choose. I imagine that most distributions will provide OpenJDK as a default 
Java solution, because its Open Source. For FreeBSD OpenJDK may be the only 
option.


But I suppose my point was more for things that are off the typical 
desktop. There are others, like Google, that provide Java implementations 
that are free to do whatever the author wishes so long as they adhere to 
the byte-code standard. The short of it is: when developing for various 
platforms Java performance is likely to vary more widely than expected. 
There are probably a number of platforms that still use or fallback to 
interpretation and other implementation details will vary. Just as using M$ 
C, GCC, ... for a windoze platform may produce different performance 
results. But Java has the potential for a much broader range of variance.


So to say, "Java is fast." Is not necessarily true depending on who's 
implementation you're using. I tested OpenJDK 1.6.0 on Linux. I didn't test 
anyone else's implementation. Would be interesting to compare OpenJDK on 
the ARM powered CHIP vs. Dalvik on a similarly spec'd Android device. :-)


--
Sent from my Debian Linux workstation -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
j...@jfpossibilities.com

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

Re: [fpc-pascal] FPC 64bit for windows

[Graeme Geldenhuys]

On 2017-05-15 16:57, James Richters wrote:

I'm not quite following your batch file.  I have no 'src' directory,
where is that supposed to be?


If you want the FPC 3.0.2 version, then download the official source 
archive for the 3.0.2 release from FPC's SourceForge page.




Here is where I am at: I have just downloaded your repo at
https://github.com/graemeg/freepascal  and I have it saved at


That repo only tracks the Trunk (unstable) branch. So if you want the 
source code of a stable release, download the archive from SourceForge.



'J:\Programming\FreePascal'   Is there a better place to download the
x86 64bit source?


I normally order my directories as follows:

  c:\FPC
   \2.6.4\
  \src
  \i386-win32
 \bin
 \lib
 \share
  \x86_64-win64
 \bin
 \lib
 \share
   \3.0.2\
  \src
  \i386-win32
 \bin
 \lib
 \share
  \x86_64-win64
 \bin
 \lib
 \share

So a source archive will be unpacked in the correct "src" directory. 
This setup also allows me to have a single global fpc.cfg file for all 
FPC versions. The paths in that fpc.cfg file uses FPC's macros to expand 
to the correct versions.


My Linux and FreeBSD systems have a similar layout.



What directory do I put 'go.bat'


It will go in the c:\fpc\\ directory.  But it doesn't really 
matter, as long as you adjust the paths inside the patch file to match 
your environment.



 Where am I setting Install_prefix?

Is that where I put the source code or where I want the compiled
version to go?


That's where the new compiled version will go. So if you use FPC 2.6.4 
to build a new 3.0.0 compiler, then the install prefix will translate to 
the path:  c:\fpc\3.0.0\x86_64-win64\



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 64bit for windows

[James Richters]

I'm not quite following your batch file.  I have no 'src' directory, where is 
that supposed to be?

Here is where I am at:
I have just downloaded your repo at https://github.com/graemeg/freepascal  and 
I have it saved at 'J:\Programming\FreePascal'   Is there a better place to 
download the x86 64bit source?

My existing 32bit freepascal compiler I have been using is installed at 
'J:\Programming\FPCWin' I believe it's V3.0.0

What directory do I put 'go.bat' 
Where am I setting Install_prefix?  Is that where I put the source code or 
where I want the compiled version to go?

Thanks for the help!

Jim


=[ go.bat ]
set TARGET=x86_64-win64
set COMPILER=J:\Programming\FPCwin\fpc.exe
set NEWFPC=3.0.2

cd src
make clean

make all FPC=%COMPILER%
rem OPT="-Fl/usr/local/lib"

make install INSTALL_PREFIX=c:\lazarus\fpc\%NEWFPC%\%TARGET% FPC=%COMPILER%
cd ..
==

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 7:41 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC 64bit for windows

On 2017-05-15 11:59, James Richters wrote:
> When I try to install 64 bit windows
> version, I don't have this anymore

The Free Pascal project, for some weird reason, only ships a 64-bit Windows 
cross-compiler. So you need both the 32-bit and 64-bit installs. 
I don't know why they do this.

Simply compile your own _full_ 64-bit FPC, by installing a previous or current 
stable 32-bit release. Download the latest stable release source code. And then 
build a new 64-bit target compiler and tools.

It might sound complicate, but the process is pretty easy. Here is a batch file 
I normally use to do this for me.


=[ go.bat ]
set TARGET=x86_64-win64
set COMPILER=c:\lazarus\fpc\2.6.2\bin\x86_64-win64\fpc.exe
set NEWFPC=2.6.4

cd src
make clean

make all FPC=%COMPILER%
rem OPT="-Fl/usr/local/lib"

make install INSTALL_PREFIX=c:\lazarus\fpc\%NEWFPC%\%TARGET% FPC=%COMPILER%

cd ..
==

Adjust the paths and versions to match your environment.

But again, I don't know why the FPC team doesn't make an official full 
64-bit Windows release??

Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-15 16:28, James Richters wrote:

Agg2dconsole.exe - System Error The Program can't start because
freetype.dll is missing from your computer. Try reinstalling the
program to fix the problem

Any ideas?


Sorry about that. AggPas uses the FreeType library (preferred - more 
features that GDI) or Windows GDI for font support. Seeing as that demo 
doesn't output text, I really should have disabled font support via


  {$DEFINE AGG2D_NO_FONT}

at the top of the unit, but I forgot to do that. So, you can do the 
above and recompile or...


Alternatively, simply copy the freetype.dll into the same directory as
the executable, or in your Windows System path. You can find a copy
included with fpGUI's code repository in a ZIP file located at:

  /extras/freetype_windows/freetype.zip



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

I am trying to run your sample program.  I am able to compile it, but when I 
try to run it I get:

Agg2dconsole.exe - System Error
The Program can't start because freetype.dll is missing from your computer. Try 
reinstalling the program to fix the problem

Any ideas?


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 10:52 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 15:45, James Richters wrote:
> I did appreciate how much better 1 pixel wide lines and curves appear 
> with the anti-aliasing and sub-pixel accuracy provides.

Indeed, AGG (and AggPas) does a fantastic job and high quality line and text 
rendering with sub-pixel accuracy.

Here is the output of a fpGUI + AggPas example. Everything seen, is rendered 
via AggPas’s API - no bitmaps have been used.

   http://fpgui.sourceforge.net/images/full/fpgui_agg-powered.png


Anyway, I hope you find a suitable solution to your problem. I think you have 
ample choice now. ;-)

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-15 15:45, James Richters wrote:

I did appreciate how much better 1 pixel wide lines and curves appear
with the anti-aliasing and sub-pixel accuracy provides.


Indeed, AGG (and AggPas) does a fantastic job and high quality line and 
text rendering with sub-pixel accuracy.


Here is the output of a fpGUI + AggPas example. Everything seen, is 
rendered via AggPas’s API - no bitmaps have been used.


  http://fpgui.sourceforge.net/images/full/fpgui_agg-powered.png


Anyway, I hope you find a suitable solution to your problem. I think you 
have ample choice now. ;-)


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thank you for the console example.  I really don't have anything too 
complicated, just basic 1 pixel wide lines, arcs and simple text the most 
complex shapes are outlines of ellipses. I don't have any surfaces or textures 
or anything really complicated.  I did appreciate how much better 1 pixel wide 
lines and curves appear with the anti-aliasing and sub-pixel accuracy provides.



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Monday, May 15, 2017 7:33 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

On 2017-05-15 11:51, James Richters wrote:
ication to be a 64bit
> application.  I have installed
> 'fpc-3.0.2.i386-win32.cross.x86_64-win64.exe'  but I don't see any 
> fp.exe to run so I'm a bit lost with it.

Yes, I don't know why the Free Pascal team doesn't make official 64-bit 
versions of FPC. I always end up having to compile my own full 64-bit FPC - 
which is very easy by the way.


> AggPas looks awesome, but can I use it with my console application?

Yes, you definitely can. I use AggPas in multiple headless servers too as 
console or CGI applications.


> I downloaded it and can't even run the sample programs included with
> it.. maybe they are Delphi examples or something?

Correct, unfortunately the demos are all GUI based demos at this time, 
but any of the actual drawing code inside those demos will be exactly 
the same for a console application.

Probably the easiest way to get your feet wet with AggPas is to use the 
agg_2D.pas (for non-GUI apps) unit. It doesn't give you the full power 
of AggPas, but presents you with a Agg2D object where you simply need to 
make graphic drawing method calls.

For example:
   // Star shape
   agg^.LineCap(CapRound);
   agg^.LineWidth(5);
   agg^.LineColor($32 ,$cd ,$32 );
   c1.Construct(0, 0 , 255, 200);
   c2.Construct(0, 0, 255, 50);
   agg^.FillLinearGradient(100, 100, 150, 150, c1, c2);
   agg^.Star(100 ,150 ,30 ,70 ,55 ,5 );


Attached is a console app example using the agg_2D.pas unit. It also 
uses the FPImage units (included with FPC) to generate a "test.png" 
image as output. You could use Memory Images too, depending on your 
application needs.

Compile the example with the following command

   $ fpc -FUunits -Fu../ -Fi../ Agg2DConsole.dpr

Adjust the -Fu and -Fi paths to match your environment, or simply save 
the Agg2DConsole.dpr into the "agg-demos" directory and compile with the 
above command.



Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

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

Re: [fpc-pascal] FPC 64bit for windows

[Michael Van Canneyt]

On Mon, 15 May 2017, wkitt...@windstream.net wrote:


On 05/15/2017 07:41 AM, Graeme Geldenhuys wrote:
But again, I don't know why the FPC team doesn't make an official full 

64-bit

Windows release??


IIRC, they say it is because 32bit winwhatever stuff will run on 64bit 
winwhatever stuff and because of that there's no real reason to build 64bit 
only... kinda makes one wonder what will happen when m$ remove 32bit 
capability  like they have 16bit capability...


Then we'll simply ship 64-bit executables.

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

Re: [fpc-pascal] FPC 64bit for windows

[wkitty42]

On 05/15/2017 07:41 AM, Graeme Geldenhuys wrote:

But again, I don't know why the FPC team doesn't make an official full 64-bit
Windows release??


IIRC, they say it is because 32bit winwhatever stuff will run on 64bit 
winwhatever stuff and because of that there's no real reason to build 64bit 
only... kinda makes one wonder what will happen when m$ remove 32bit capability 
like they have 16bit capability...



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

Re: [fpc-pascal] Partial text search in a dictionary

[duilio foschi]

a pointer is - after all - just an integer.

See
http://delphi.cjcsoft.net/viewthread.php?tid=44049

Instead of TStringLIst use a SQLite (open source) in-memory table to
store your data.

The table can be indexed and searched using function Locate with
option loPartialKey.

Just my 2c

Peppe



2017-05-15 14:19 GMT+02:00 Jürgen Hestermann :
> Am 2017-05-15 um 13:14 schrieb Torsten Bonde Christiansen:
>> however I was hoping someone might know of an implementation that works
>> more or less out of the box.
>
> To me it was very seldom that an existing solution
> severed all my needs. Either not all requirements were
> complied from the beginning or, even worse, I invested time
> using an existing "solution" only to find out much later
> that some detail does not work so I had to write my own solution anyway.
> I wasted time in understanding an (often poorly
> documented) existing routine, fighting with bugs in it
> and then had to write it more or less from cratch anyway.
>
> If I understand your requirements correctly it should not be
> too much work to write your own solution.
> You would also have the freedom to exactly adapt it to your needs
> without fiddling with parameters and adjustments of an existing
> library which are superfluous for your purpose.
>
>
> ___
> 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] Partial text search in a dictionary

[Jürgen Hestermann]

Am 2017-05-15 um 13:14 schrieb Torsten Bonde Christiansen:
> however I was hoping someone might know of an implementation that 
works more or less out of the box.


To me it was very seldom that an existing solution
severed all my needs. Either not all requirements were
complied from the beginning or, even worse, I invested time
using an existing "solution" only to find out much later
that some detail does not work so I had to write my own solution anyway.
I wasted time in understanding an (often poorly
documented) existing routine, fighting with bugs in it
and then had to write it more or less from cratch anyway.

If I understand your requirements correctly it should not be
too much work to write your own solution.
You would also have the freedom to exactly adapt it to your needs
without fiddling with parameters and adjustments of an existing
library which are superfluous for your purpose.

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

Re: [fpc-pascal] FPC 64bit for windows

[Graeme Geldenhuys]

On 2017-05-15 11:59, James Richters wrote:

When I try to install 64 bit windows
version, I don't have this anymore


The Free Pascal project, for some weird reason, only ships a 64-bit 
Windows cross-compiler. So you need both the 32-bit and 64-bit installs. 
I don't know why they do this.


Simply compile your own _full_ 64-bit FPC, by installing a previous or 
current stable 32-bit release. Download the latest stable release source 
code. And then build a new 64-bit target compiler and tools.


It might sound complicate, but the process is pretty easy. Here is a 
batch file I normally use to do this for me.



=[ go.bat ]
set TARGET=x86_64-win64
set COMPILER=c:\lazarus\fpc\2.6.2\bin\x86_64-win64\fpc.exe
set NEWFPC=2.6.4

cd src
make clean

make all FPC=%COMPILER%
rem OPT="-Fl/usr/local/lib"

make install INSTALL_PREFIX=c:\lazarus\fpc\%NEWFPC%\%TARGET% FPC=%COMPILER%

cd ..
==

Adjust the paths and versions to match your environment.

But again, I don't know why the FPC team doesn't make an official full 
64-bit Windows release??


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

On 2017-05-15 11:51, James Richters wrote:
ication to be a 64bit

application.  I have installed
'fpc-3.0.2.i386-win32.cross.x86_64-win64.exe'  but I don't see any
fp.exe to run so I'm a bit lost with it.


Yes, I don't know why the Free Pascal team doesn't make official 64-bit 
versions of FPC. I always end up having to compile my own full 64-bit 
FPC - which is very easy by the way.




AggPas looks awesome, but can I use it with my console application?


Yes, you definitely can. I use AggPas in multiple headless servers too 
as console or CGI applications.




I downloaded it and can't even run the sample programs included with
it.. maybe they are Delphi examples or something?


Correct, unfortunately the demos are all GUI based demos at this time, 
but any of the actual drawing code inside those demos will be exactly 
the same for a console application.


Probably the easiest way to get your feet wet with AggPas is to use the 
agg_2D.pas (for non-GUI apps) unit. It doesn't give you the full power 
of AggPas, but presents you with a Agg2D object where you simply need to 
make graphic drawing method calls.


For example:
  // Star shape
  agg^.LineCap(CapRound);
  agg^.LineWidth(5);
  agg^.LineColor($32 ,$cd ,$32 );
  c1.Construct(0, 0 , 255, 200);
  c2.Construct(0, 0, 255, 50);
  agg^.FillLinearGradient(100, 100, 150, 150, c1, c2);
  agg^.Star(100 ,150 ,30 ,70 ,55 ,5 );


Attached is a console app example using the agg_2D.pas unit. It also 
uses the FPImage units (included with FPC) to generate a "test.png" 
image as output. You could use Memory Images too, depending on your 
application needs.


Compile the example with the following command

  $ fpc -FUunits -Fu../ -Fi../ Agg2DConsole.dpr

Adjust the -Fu and -Fi paths to match your environment, or simply save 
the Agg2DConsole.dpr into the "agg-demos" directory and compile with the 
above command.




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
{
  This is a console application demo. It uses the Agg2D object,
  which has a much friendlier API, to do all the drawing. We then
  save the image buffer to a JPG, using the fcl-image package,
  which comes standard with the Free Pascal Compiler.

// Paths: ..\;..\svg;..\util;expat-wrap
}
program console_aggpas_2;

{$mode objfpc}{$H+}

uses
  sysutils,
  FPimage,
  FPWritePNG,
  agg_2D,
  agg_basics;

const
  ImageWidth = 800;
  ImageHeight = 480;
  RGBA_Width = 4;
  LineCount = 30;
  {$IFDEF Unix}
  FontFile = '../../arial.ttf';
  {$ENDIF}
  {$IFDEF Windows}
  FontFile = 'Arial';
  {$ENDIF}

type
  TPainter = class(TObject)
  public
procedure HandlePlug;
procedure DrawStuff(agg: Agg2D_ptr);
  end;


procedure TPainter.HandlePlug;
var
  agg: Agg2D_ptr;
  buf: array of int8;
  image: TFPMemoryImage;
  writer: TFPWriterPNG;
  x, y: Integer;
  c: TFPColor;
  time, totalTime: TDateTime;
  function getBufItemAsWord(aDelta: byte): Word;
  var
actualY: Integer;
  begin
actualY := ImageHeight - y - 1;
result :=
  Word(buf[x * RGBA_Width + actualY * ImageWidth * RGBA_Width + aDelta] shl 
8)
  or Word(128);
  end;
begin
  totalTime := Now;
  time := Now;
  SetLength(buf, ImageWidth * ImageHeight * RGBA_Width);
  New(agg, Construct);
  agg^.attach(@(buf[0]), ImageWidth, ImageHeight, -(ImageWidth * RGBA_Width));
  DrawStuff(agg);
  Dispose(agg, Destruct); // not necessary to keep it after rendering is 
finished
  time := Now - time;
//  Logger.Emit('Draw: time spent: ' + TimeStampToString(time));
  time := Now;
  image := TFPMemoryImage.create(ImageWidth, ImageHeight);
  for x := 0 to ImageWidth - 1 do
for y := 0 to ImageHeight - 1 do
begin
  c.red := getBufItemAsWord(2);
  c.green := getBufItemAsWord(1);
  c.blue := getBufItemAsWord(0);
  c.alpha := getBufItemAsWord(3);
  image.Colors[x, y] := c;
end;
  time := Now - time;
//  WriteLn('Image copy: time spent: ' + DateTimeToString(time));
  time := Now;
  writer := TFPWriterPNG.Create;
  image.SaveToFile('test.png', writer);
  image.Free;
  writer.Free;
  time := Now - time;
//  WriteLn('Image encode: time spent: ' + DateTimeToString(time));
  totalTime := Now - totalTime;
//  WriteLn('Total time: ' + DateTimeToString(totalTime));
end;

procedure TPainter.DrawStuff(agg: Agg2D_ptr);
var
  i: Integer;
  x, y, px, py, d: Double;
  c1, c2: Color;
begin
  // draw a full screen graph with grid
  agg^.clearAll(0, 0, 0);
  agg^.lineColor(0, 0, 0, 255);
  agg^.lineWidth(3);
  agg^.rectangle(0, 0, ImageWidth, ImageHeight);
//  agg^.font(fontfile, 16);
  d := ImageWidth / LineCount;
  agg^.lineColor(0, 0, 0, 100);
  agg^.lineWidth(1);
  for i := 1 to LineCount - 1 do
  begin
x := i * d;
agg^.line(x, 0, x, ImageHeight);
  end;
  for i := 1 to trunc(ImageHeight / d) do
  begin
y := i * d;
agg^.line(0, y, ImageWidth, y);
  end;
  x := 0;
  y := ImageHeight / 2;
  px := x;
  py := y;
  

[fpc-pascal] Partial text search in a dictionary

[Torsten Bonde Christiansen]

Hi list.

I am looking for a class/list/map... that allows me to store string data 
paired with an object.


However i would like to be able to do a partial text search on the 
strings, prefeably with a result as a list of matching string/object 
pairs but getting an index to the first matching pair would be fine. The 
match only has to be done from the first character of both strings, so a 
complex solution like Regex search is not needed.


I know i can use a sorted TStringList with a straight forward search 
method, however I was hoping someone might know of an implementation 
that works more or less out of the box.


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

[fpc-pascal] FPC 64bit for windows

[James Richters]

I am wondering if it's possible to compile my windows console app
specifically for 64bit machines running windows?  I am currently compiling
it as a win32 console application because I cannot figure out how to compile
it as a 64bit program.  I normally run bin\i386-win32\FP.EXE and use the
text based IDE to compile my program.   When I try to install 64 bit windows
version, I don't have this anymore, is It possible to use the text based IDE
to compile 64 bit programs or do I need to learn how to do it from the
command line?   Any advice is appreciated

 

James

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Thanks for the help and advice with this.  I've been trying to figure out how a 
lot of this works.  Here's where I'm at

>You could try the units ptcgraph or sdlgraph as alternatives (both are part of 
>FPC).

These seemed like the easiest things to start with.

ptcgraph: I'm having 2 issues trying ptcgraph,  1, I can't seem to get it 
to be completely full screen 1280x1024 seems to be the largest I can make it.   
2, The graphics window created by ptcgraph does not respond with wincrt.  

Sdlgraph:I have not been able to successfully execute with SDLgraph, I can 
compile it, but when I try to run it I get "The application was unable to start 
correctly (0xc07b) Click Ok to close the Application"  I have no idea what 
this even means or how to do anything about it... maybe I am missing some 
component to use sdlgraph

>Porting them to Lazarus (GUI) is not an option?
I have tried to port to Lazarus but that would be a monumental task, these are 
not little programs, they are over 25,000 lines of code and to change the 
project over to a windows GUI would require an entire re-write which I don't 
have time for.   A Console application with using graph and wincrt is suitable 
for everything else but I just have this screen performance issue

>   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.

This may be a general processing issue and I'm just noticing it on screen 
performance.   The target computers for this application are 64bit windows 10 
PC's with integrated graphics on motherboard (no separate GPU), however I am 
running with win32 because I cannot figure out how to compile my console 
application to be a 64bit application.  I have installed 
'fpc-3.0.2.i386-win32.cross.x86_64-win64.exe'  but I don't see any fp.exe to 
run so I'm a bit lost with it.  

>  I highly recommend you take a look as AggPas. It is a 100% high
>  quality sub-pixel rendering engine

AggPas looks awesome, but can I use it with my console application?  I 
downloaded it and can't even run the sample programs included with it.. maybe 
they are Delphi examples or something?  I think I'm a bit over my head with 
that unless I can find an example of how to make a console application with it.



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

Re: [fpc-pascal] Size of program vs library ?

[Michael Van Canneyt]

On Mon, 15 May 2017, fredvs wrote:


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


Ha, news, finally.

Huh, did you read my post ?


I did.

I responded to the statement that fpc libraries are big and "unusable".


It talk about smartlinking of libraries that does not work.

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX paramer
for libraries ? (Bug ?) /


Not providing an option is not a bug. 
At best, providing this option is a feature request on your part.


Why it does not provide the option?
For the same reason that it doesn't strip binaries by default, I suppose.
Or maybe this option didn't exist when the FPC library support was
implemented ? Maybe there are even other reasons I am not aware of.

But even when you do the --gc-sections, your library will still be bigger than
corresponding C libraries for the reasons I outlined in my initial response.

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

Re: [fpc-pascal] Size of program vs library ?

[fredvs]

Michael Van Canneyt wrote
> On Mon, 15 May 2017, fredvs wrote:
> 
>> fredvs wrote
>>> Hello.
>>> 
>>> Sorry to come back with this story but there are (good) news.
>>> 
>>> Using 
>> *
>>> --gc-sections
>> *
>>>  makes the library smartlinked.
>>> 
>>> So the question is:
>>> 
>>> Why FPC does not provide 
>> *
>>> --gc-sections
>> *
>>>  to the linker with the -XX paramer for libraries ? (Bug ?)
>>> 
>>> Fre;D
>>
>> Nobody uses fpc library here ?
>>
>> Strange that a (big) problem with maybe a solution does not interest
>> anybody.
> 
> There is no problem.
> 
>> The size of fpc libraries makes fpc-libraries not usable in a real world.
> 
> Why ?
> 
>>
>> I use some audio C libraries and a fpc library (that only link headers of
>> that C libraries) is 10 times bigger than the C libraries !
>>
>> And when a solution (or bug) is found ---> only silence as answer.
> 
> There is no bug. You are comparing apples with pears.
> 
> A C library in the traditional unix sense is a set of routines that
> requires
> other libraries to run - ultimately requiring libc.
> 
> A FPC library - due to it's windows origings heritage - is more like a
> static program. 
> It's almost 100% standalone, and does not require other libraries to
> function 
> (except the ones you explicitly link in). Inevitably, it is bigger.
> 
> Once dynamic packages are implemented, we can start comparing apples with
> apples, and pears with pears. a dynamic package is more like a C library
> in
> the unix sense. It makes sense to compare those.
> 
> If you want to compare today, you need to add the sizes of all the C
> libraries that are loaded during execution of a C program with the size 
> of an FPC program.
> 
> I think you'll find that the sizes of FPC programs are not so different
> then.
> 
> Just check the size of libc:
> 
> ls /lib/x86_64-linux-gnu/libc-2.19.so -l
> 
> -rwxr-xr-x 1 root root 1853216 Mar 21 20:24
> /lib/x86_64-linux-gnu/libc-2.19.so*
> 
> That is almost 2Mb that is linked in to every C library and program.
> 
> Michael.
> ___
> fpc-pascal maillist  -  

> fpc-pascal@.freepascal

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

Ha, news, finally.

Huh, did you read my post ?

It talk about smartlinking of libraries that does not work.

After lot of fight, there is a solution: using -*-gc-sections*.

And the question was :

/Why FPC does not provide --gc-sections to the linker with the -XX paramer
for libraries ? (Bug ?) /

Fre;D





-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728558.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

Re: [fpc-pascal] Size of program vs library ?

[Michael Van Canneyt]

On Mon, 15 May 2017, fredvs wrote:


fredvs wrote

Hello.

Sorry to come back with this story but there are (good) news.

Using 

*

--gc-sections

*

 makes the library smartlinked.

So the question is:

Why FPC does not provide 

*

--gc-sections

*

 to the linker with the -XX paramer for libraries ? (Bug ?)

Fre;D


Nobody uses fpc library here ?

Strange that a (big) problem with maybe a solution does not interest
anybody.


There is no problem.


The size of fpc libraries makes fpc-libraries not usable in a real world.


Why ?



I use some audio C libraries and a fpc library (that only link headers of
that C libraries) is 10 times bigger than the C libraries !

And when a solution (or bug) is found ---> only silence as answer.


There is no bug. You are comparing apples with pears.

A C library in the traditional unix sense is a set of routines that requires
other libraries to run - ultimately requiring libc.

A FPC library - due to it's windows origings heritage - is more like a static program. 
It's almost 100% standalone, and does not require other libraries to function 
(except the ones you explicitly link in). Inevitably, it is bigger.


Once dynamic packages are implemented, we can start comparing apples with
apples, and pears with pears. a dynamic package is more like a C library in
the unix sense. It makes sense to compare those.

If you want to compare today, you need to add the sizes of all the C
libraries that are loaded during execution of a C program with the size 
of an FPC program.


I think you'll find that the sizes of FPC programs are not so different then.

Just check the size of libc:

ls /lib/x86_64-linux-gnu/libc-2.19.so -l

-rwxr-xr-x 1 root root 1853216 Mar 21 20:24 /lib/x86_64-linux-gnu/libc-2.19.so*

That is almost 2Mb that is linked in to every C library and program.

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

Re: [fpc-pascal] Size of program vs library ?

[fredvs]

fredvs wrote
> Hello.
> 
> Sorry to come back with this story but there are (good) news.
> 
> Using 
*
> --gc-sections
*
>  makes the library smartlinked.
> 
> So the question is:
> 
> Why FPC does not provide 
*
> --gc-sections
*
>  to the linker with the -XX paramer for libraries ? (Bug ?)
> 
> Fre;D

Nobody uses fpc library here ?

Strange that a (big) problem with maybe a solution does not interest
anybody.

The size of fpc libraries makes fpc-libraries not usable in a real world.

I use some audio C libraries and a fpc library (that only link headers of
that C libraries) is 10 times bigger than the C libraries !

And when a solution (or bug) is found ---> only silence as answer.


Fre;D






-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728556.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

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