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

[Michael Van Canneyt]

On Tue, 16 May 2017, fredvs wrote:


Michael Van Canneyt wrote

On Tue, 16 May 2017, fredvs wrote:


Michael Van Canneyt wrote
What can be misunderstood about adding --gc-sections to the linker 
options if -XX is used on the command-line ?


Ha, the way you present it seems to show that you did understand it ;-)

OK, maybe is it time to add a feature request...


Before filing a request, you can already check yourself what happens with
form data if you compile a lazarus form into the library.

Michael.


Huh, with all the respect that I have for LCL, I was never able to compile a
Lazarus form into library (even without --gc-sections or -XX) .
On the other side, with forms from fpGUI or MSEgui, no form data loosed
while compiling forms into library with --gc-sections.


As far as I know, they don't use FPC resources for this ?



PS: Re-huh, the libraries that I compile do not store form-data (even no
data at all).


Possibly, but this is something that must be checked before implementing
such an option...

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]

Marco van de Voort wrote
> In our previous episode, Michael Van Canneyt said:
>> > Does it work for all situations?  I remember a bug for the rust
>> compiler
>> > that broke libraries when --gc-sections was used, because it removed
>> the
>> > metadata that rust needed to load the library.  One of the fpc devs can
>> > probably say whether fpc may have a similar problem.
>> 
>> You risk losing e.g. resources. 
>> This is typically what needs to be investigated.
> 
> That also goes for the main application. Such sections should be marked
> with
> KEEP() in the linker script.
> ___
> fpc-pascal maillist  -  

> fpc-pascal@.freepascal

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

Yes and it is valable too for programs compiled with -XX.

Fre;D



-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728617.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 16.05.2017 16:10 schrieb "Jon Foster" :
> There are only two software projects in the world that continue to
impress me with each new release: the Linux Kernel and FPC, which amuses me
since I remember the first version of FPC I saw. '99 I think it was. I
laughed and moved on. I wish I had the time provide some concrete info on
where Graeme's problem is because I'd really like to see FPC shine here
too. But it will probably be a while before I can give it proper treatment.

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

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-15 17:27, Graeme Geldenhuys wrote:

On 2017-05-15 22:50, nore...@z505.com wrote:

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


I'll try and clarify... I believe FPC generates slow (or slower than
Delphi, GCC and Java) code no matter what. The saving grace is that
you don't really notice it on normal event-based desktop applications.
Writing a game is a whole different story. Games are way more
sensitive to performance.

Now the game I wrote, was a desktop GUI application. It was slow under
Linux, FreeBSD and Windows. So the results were consistent, no matter
what GUI API was used Be that fpGUI (via GDI), fpGUI (via X11) or
LCL-GTK2. In all cases, game rendering was to a memory image, then
once done, that memory image was bitblit to the Window Canvas.

The Java and GCC versions did the same, but were faster.

That's all I can say about. Make your own assumptions - read into it
any conspiracy theories or what-not. ;-) At this point I don't really
care, as I already moved on with that project, using OpenGL instead
(both for Java and Object Pascal).



But any game ends up using opengl anyway, doesnt' it? Sorry I'm not a 
big game programmer. Want to be, some day.


i.e. if you end up using opengl, or its successor, why does it even 
matter if FPC pure games without any libs are slow?


AFAIR the doom and quake ports ran pretty fast, but I'm not sure, as I 
didn't play them much. Can't remember.

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

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

[Sven Barth via fpc-pascal]

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

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

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

Re: [fpc-pascal] FPC Graphics options?

[noreply]

On 2017-05-16 09:10, Jon Foster wrote:


I think the key word in Graeme's complaint is "game". And I'm willing
to bet that most of his envisioned gaming scenarios deal with a lot of
floating point math and the more advanced math functions. A quick
glance over his example code and I'm willing to bet that the "math"
unit providing the sqrt(), cos(), sin() and others is the bottle neck.
But that's just a knee-jerk reaction. Seems to me I read a while back
that a ton of effort had not gone into them.



Could those math routines just be written in assembly with a FastXXX 
unit? i.e. FastMM is a fast memory manager, so you could have a FastCRT, 
fastWhatever, FastMath...


At one time the fpc system units or sysutils was written in a lot of 
assembly, then they changed it to more pascal so it was more readable 
for people like me who stay away from assembly :-)  Not because assembly 
is bad or anything, I just like living in high level procedural land, 
instead of low level assembly machine land.

___
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 17:37, 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.



So it can't be an fpc problem, but a unit module problem that someone 
didn't spend time optimizing which has little to do with fpc but more to 
do with the way the units were written?


Or is the ptcgraph/ptccrt in assembly code to avoid FPC mode objcfpc 
compilation and use assembly instead? Sorry I have not looked at it.. 
don't know.

___
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-16 03:15, fredvs wrote:

noreply wrote

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



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


It works for all situations, so I propose that fpc add --gc-sections as
parameter for the linker if the user has used -XX parameter to compile 
a

library.

Fre;D


Okay hold on. All situations.
Either you are a serious Edsgar Dijkstra fan, and you have proven it to 
be correct (unlikely) or you have all the test cases of the entire 
universe and are a unit testing nutcase..
All the chess board peices and positions on the game board have all been 
tested in all situations...

No..

But, seriously... if it works in many many many situations I guess that 
is "good enough"

:-)
___
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 09:00 AM, Sven Barth via fpc-pascal wrote:


Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" >:
>> 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.


Hmm? But he only wants to change the tttle of the window. Even on 
Windows that should work from a different thread. However a platform 
independent SetWindowTitle() for ptcgraph would be rather useful I guess.



I can easily add this option to ptcgraph. I'll do it tonight.


Though I'd like to know why he needs ShowWindow()...

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

[Nikolay Nikolov]

On 05/16/2017 01:27 PM, James Richters wrote:


> Hmm? But he only wants to change the title of the window. Even on 
Windows that should work from a different thread. However a platform 
independent SetWindowTitle() for ptcgraph would be rather useful I guess.


I did a quick test and ran one program that did a writeln of it’s 
handle, then put that handle in another program and ran it and I was 
able to change the window title of the first program with the second 
program.   So if ptcgraph also had the graphwindow : handle variable I 
think it would work.


>Though I'd like to know why he needs ShowWindow()...

My application is purposefully designed not to use a mouse…  It’s CNC 
control software and mice, even optical ones out in dusty shops are 
tedious and difficult… it’s often difficult to even find a place to 
put a mouse, nevermind seeing a pointer when the screen is full of 
sawdust.   So I have keyboard commands that get me back to the console 
window where I can look at some things like the contents of some 
variables, then when I’m done I hit another key and it puts me back on 
the graphics window.   I just use both crt and pctcrt  and do things 
like crt.readkey and pctcrt.readkey to know which screen got the 
input.   I can get by without ShowWindow() because I can alt-tab 
between the windows without a mouse, and admittedly there isn’t a huge 
use for the console window, but it is a lot nicer for the program to 
put the correct window on top by itself.


It would be nice if I could:

 1. The above mentioned ShowWindow()
 2. Make the graph window full screen always, it normally does not
come up full screen it’s the correct size for full screen but
mispositioned.. I can probably fix this in a shortcut that starts
it but would be nice if the program itself forced full screen


Yes, you can do this, if you set:

  FullscreenGraph := true;

In the beginning of your program (before InitGraph). Tonight I'll also 
add the option for changing the title bar text, when in windowed mode.


1.
 2. Get rid of the windows titlebar all together, I could just draw my
own.   I was able to shut the title bar off with the graph unit,
but the window would still be the size of the screen minus the
bar.   I believe if the titlebar was defined to be shut off before
the window was created, or shortly after then I could have
completely full screen with no title bar. But I don’t know where
or how the window is created to do that.
 3. If I can’t get rid of the titlebar, then setting a custom window
title would be nice, preferably after my program was running so I
could put status information up there, but if not possible then a
one time custom title bar name would be great.

James

*From:* fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] 
*On Behalf Of *Sven Barth via fpc-pascal

*Sent:* Tuesday, May 16, 2017 2:00 AM
*To:* FPC-Pascal users discussions 
*Cc:* Sven Barth 
*Subject:* Re: [fpc-pascal] FPC Graphics options?

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" >:
>> 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.


Hmm? But he only wants to change the tttle of the window. Even on 
Windows that should work from a different thread. However a platform 
independent SetWindowTitle() for ptcgraph would be rather useful I guess.


Though I'd like to know why he needs ShowWindow()...

Regards,
Sven



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


___
fpc-pascal maillist  -  

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

[leledumbo via fpc-pascal]

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

Google for prefix tree (or radix tree or trie) implementation. I believe
I've seen one in either Blaise Pascal Magazine or Pascal Gamer Magazine, the
topic is about building autocomplete combobox if I'm not mistaken.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Partial-text-search-in-a-dictionary-tp5728562p5728601.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] Partial text search in a dictionary

[Torsten Bonde Christiansen]

On 2017-05-16 10:26, leledumbo via fpc-pascal wrote:

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.

Google for prefix tree (or radix tree or trie) implementation. I believe
I've seen one in either Blaise Pascal Magazine or Pascal Gamer Magazine, the
topic is about building autocomplete combobox if I'm not mistaken.


Exactly... couldn't remeber the name of the trees... :)

thanks
___
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 ?

[Maciej Izak]

2017-05-16 10:15 GMT+02:00 fredvs :

> It works for all situations, so I propose that fpc add --gc-sections as
> parameter for the linker if the user has used -XX parameter to compile a
> library.
>

for features requests please use https://bugs.freepascal.org .

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

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

[fredvs]

Maciej Izak wrote
> 2017-05-16 10:15 GMT+02:00 fredvs 

> fiens@

> :
> 
>> It works for all situations, so I propose that fpc add --gc-sections as
>> parameter for the linker if the user has used -XX parameter to compile a
>> library.
>>
> 
> for features requests please use https://bugs.freepascal.org .
> 
> -- 
> Best regards,
> Maciej Izak
> 
> ___
> fpc-pascal maillist  -  

> fpc-pascal@.freepascal

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

Thanks but before to ask for that (essential) feature: ---> advices, ideas,
warnings are welcome.

Also, as you can see, it is important to be sure that the request is
perfectly understood (and, sorry, but I have lot of doubt about this).

Fre;D

Fre;D





-
Many thanks ;-)
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library-tp5718200p5728604.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 Tue, 16 May 2017, fredvs wrote:


Maciej Izak wrote

2017-05-16 10:15 GMT+02:00 fredvs 



fiens@



:


It works for all situations, so I propose that fpc add --gc-sections as
parameter for the linker if the user has used -XX parameter to compile a
library.



for features requests please use https://bugs.freepascal.org .

--
Best regards,
Maciej Izak

___
fpc-pascal maillist  - 



fpc-pascal@.freepascal



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


Thanks but before to ask for that (essential) feature: ---> advices, ideas,
warnings are welcome.

Also, as you can see, it is important to be sure that the request is
perfectly understood (and, sorry, but I have lot of doubt about this).


And why is that ?

What can be misunderstood about adding --gc-sections to the linker 
options if -XX is used on the command-line ?


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 ?

[Henry Vermaak]

On Tue, May 16, 2017 at 01:15:34AM -0700, fredvs wrote:
> It works for all situations, so I propose that fpc add --gc-sections
> as parameter for the linker if the user has used -XX parameter to
> compile a library.

Does it work for all situations?  I remember a bug for the rust compiler
that broke libraries when --gc-sections was used, because it removed the
metadata that rust needed to load the library.  One of the fpc devs can
probably say whether fpc may have a similar problem.

I know with gcc you will need -ffunction-sections and -fdata-sections if
you want --gc-sections to do anything, and there are warnings attached
to those (see the gcc man page).

Henry
___
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 Tue, 16 May 2017, Henry Vermaak wrote:


On Tue, May 16, 2017 at 01:15:34AM -0700, fredvs wrote:

It works for all situations, so I propose that fpc add --gc-sections
as parameter for the linker if the user has used -XX parameter to
compile a library.


Does it work for all situations?  I remember a bug for the rust compiler
that broke libraries when --gc-sections was used, because it removed the
metadata that rust needed to load the library.  One of the fpc devs can
probably say whether fpc may have a similar problem.


You risk losing e.g. resources. 
This is typically what needs to be investigated.


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 ?

[Marco van de Voort]

In our previous episode, fredvs said:
> Nobody uses fpc library here ?

Yes, but I don't care about size unless it is outrageous.
 
___
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
> What can be misunderstood about adding --gc-sections to the linker 
> options if -XX is used on the command-line ?

Ha, the way you present it seems to show that you did understand it ;-)

OK, maybe is it time to add a feature request...

Fre;D 




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

[Marco van de Voort]

In our previous episode, Michael Van Canneyt said:
> > Does it work for all situations?  I remember a bug for the rust compiler
> > that broke libraries when --gc-sections was used, because it removed the
> > metadata that rust needed to load the library.  One of the fpc devs can
> > probably say whether fpc may have a similar problem.
> 
> You risk losing e.g. resources. 
> This is typically what needs to be investigated.

That also goes for the main application. Such sections should be marked with
KEEP() in the linker script.
___
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 Tue, 16 May 2017, fredvs wrote:


Michael Van Canneyt wrote
What can be misunderstood about adding --gc-sections to the linker 
options if -XX is used on the command-line ?


Ha, the way you present it seems to show that you did understand it ;-)

OK, maybe is it time to add a feature request...


Before filing a request, you can already check yourself what happens with
form data if you compile a lazarus form into the library.

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

[Michael Schnell]

On 12.05.2017 16:37, Michael Van Canneyt wrote:


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


For event processing in a not threaded project or in the main thread of 
a threaded project you at best use the Event Queue provided by some 
Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes 
sense, if you don't want to use one of those. (mse and an enhanced NoGui 
LCL "Widget Type", I have done a working draft for, can provide a 
message queue even with no binding to a GUI Widget Set).


But when using SimpleIPC for signaling to another process (executable, 
e.g.  a Lazarus "Application" ) I suppose, you  need a thread to avoid 
latency and/or huge CPU demand by polling to transfer the event to the 
Main Thread via the Event Queue (e.g. by Application.QueueAsyncCall or 
TTherad.Queue).


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

[Sven Barth via fpc-pascal]

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" :
>> 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.

Hmm? But he only wants to change the tttle of the window. Even on Windows
that should work from a different thread. However a platform independent
SetWindowTitle() for ptcgraph would be rather useful I guess.

Though I'd like to know why he needs ShowWindow()...

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

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

> Hmm? But he only wants to change the title of the window. Even on Windows 
> that should work from a different thread. However a platform independent 
> SetWindowTitle() for ptcgraph would be rather useful I guess.

I did a quick test and ran one program that did a writeln of it’s handle, then 
put that handle in another program and ran it and I was able to change the 
window title of the first program with the second program.   So if ptcgraph 
also had the graphwindow : handle variable I think it would work.

 

>Though I'd like to know why he needs ShowWindow()...

 

My application is purposefully designed not to use a mouse…  It’s CNC control 
software and mice, even optical ones out in dusty shops are tedious and 
difficult… it’s often difficult to even find a place to put a mouse, nevermind 
seeing a pointer when the screen is full of sawdust.   So I have keyboard 
commands that get me back to the console window where I can look at some things 
like the contents of some variables, then when I’m done I hit another key and 
it puts me back on the graphics window.   I just use both crt and pctcrt  and 
do things like crt.readkey and pctcrt.readkey to know which screen got the 
input.   I can get by without ShowWindow() because I can alt-tab between the 
windows without a mouse, and admittedly there isn’t a huge use for the console 
window, but it is a lot nicer for the program to put the correct window on top 
by itself.

 

It would be nice if I could: 

1.  The above mentioned ShowWindow()
2.  Make the graph window full screen always, it normally does not come up 
full screen it’s the correct size for full screen but mispositioned.. I can 
probably fix this in a shortcut that starts it but would be nice if the program 
itself forced full screen
3.  Get rid of the windows titlebar all together, I could just draw my own. 
  I was able to shut the title bar off with the graph unit, but the window 
would still be the size of the screen minus the bar.   I believe if the 
titlebar was defined to be shut off before the window was created, or shortly 
after then I could have completely full screen with no title bar. But I don’t 
know where or how the window is created to do that.
4.  If I can’t get rid of the titlebar, then setting a custom window title 
would be nice, preferably after my program was running so I could put status 
information up there, but if not possible then a one time custom title bar name 
would be great.

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sven Barth via fpc-pascal
Sent: Tuesday, May 16, 2017 2:00 AM
To: FPC-Pascal users discussions 
Cc: Sven Barth 
Subject: Re: [fpc-pascal] FPC Graphics options?

 

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov"  >:
>> 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.

Hmm? But he only wants to change the tttle of the window. Even on Windows that 
should work from a different thread. However a platform independent 
SetWindowTitle() for ptcgraph would be rather useful I guess.

Though I'd like to know why he needs ShowWindow()...

Regards,
Sven

___
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]

noreply wrote
> 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@.freepascal

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

It works for all situations, so I propose that fpc add --gc-sections as
parameter for the linker if the user has used -XX parameter to compile a
library.

Fre;D



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

[Jon Foster]

On 05/15/2017 03:27 PM, Graeme Geldenhuys wrote:

On 2017-05-15 22:50, nore...@z505.com wrote:

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


I'll try and clarify... I believe FPC generates slow (or slower than 
Delphi, GCC and Java) code no matter what. The saving grace is that you 
don't really notice it on normal event-based desktop applications. 
Writing a game is a whole different story. Games are way more sensitive 
to performance.


Now the game I wrote, was a desktop GUI application. It was slow under 
Linux, FreeBSD and Windows. So the results were consistent, no matter 
what GUI API was used Be that fpGUI (via GDI), fpGUI (via X11) or 
LCL-GTK2. In all cases, game rendering was to a memory image, then once 
done, that memory image was bitblit to the Window Canvas.


The Java and GCC versions did the same, but were faster.

That's all I can say about. Make your own assumptions - read into it any 
conspiracy theories or what-not. ;-) At this point I don't really care, 
as I already moved on with that project, using OpenGL instead (both for 
Java and Object Pascal).


I think the key word in Graeme's complaint is "game". And I'm willing to 
bet that most of his envisioned gaming scenarios deal with a lot of 
floating point math and the more advanced math functions. A quick glance 
over his example code and I'm willing to bet that the "math" unit providing 
the sqrt(), cos(), sin() and others is the bottle neck. But that's just a 
knee-jerk reaction. Seems to me I read a while back that a ton of effort 
had not gone into them.


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


--
Sent from my Debian Linux laptop
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] Size of program vs library ?

[fredvs]

Michael Van Canneyt wrote
> On Tue, 16 May 2017, fredvs wrote:
> 
>> Michael Van Canneyt wrote
>>> What can be misunderstood about adding --gc-sections to the linker 
>>> options if -XX is used on the command-line ?
>>
>> Ha, the way you present it seems to show that you did understand it ;-)
>>
>> OK, maybe is it time to add a feature request...
> 
> Before filing a request, you can already check yourself what happens with
> form data if you compile a lazarus form into the library.
> 
> Michael.

Huh, with all the respect that I have for LCL, I was never able to compile a
Lazarus form into library (even without --gc-sections or -XX) .
On the other side, with forms from fpGUI or MSEgui, no form data loosed
while compiling forms into library with --gc-sections.

PS: Re-huh, the libraries that I compile do not store form-data (even no
data at all).

Fre;D






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

[Nikolay Nikolov]

On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:



Tonight I'll also add the option for changing the title bar text, when 
in windowed mode.
Unfortunately, I didn't have the time to do it tonight (I'm kinda bad at 
time estimates ;-) ), but I'll probably implement it during the weekend.


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

[fpc-pascal] List pre-defined defines

[Jon Foster]

I've looked several times over the years for a way to get fpc to dump all 
of the predefined "defines" for the target selected. Things like "fpc", 
"linux", "unix", "android", "cpuarm", "cpui386", ... and who knows what 
else. Seems like there ought to be an "-i?" switch for this. Have I just 
missed it? Is there something to dump all of the built in defines for the 
current target?


I have a couple of needs for this:

1. A "menu" of sorts to figure out which is the best define to make my code 
adapt to a given target, like when I wrote something for i386 and then 
discover I need to do something different for x64 or arm.


2. I have tools to extract code sections from Pascal sources. but I don't 
always know which ifdefs to follow.


3. Just 'cause I'm curios... I guess that's more than 2. :-)

TIA - Jon

--
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] List pre-defined defines

[Mattias Gaertner]

On Tue, 16 May 2017 14:45:42 -0700
Jon Foster  wrote:

> I've looked several times over the years for a way to get fpc to dump all 
> of the predefined "defines" for the target selected. Things like "fpc", 
> "linux", "unix", "android", "cpuarm", "cpui386", ... and who knows what 
> else. Seems like there ought to be an "-i?" switch for this. Have I just 
> missed it? Is there something to dump all of the built in defines for the 
> current target?

touch mytest
fpc -vc mytest

 
> I have a couple of needs for this:
> 
> 1. A "menu" of sorts to figure out which is the best define to make my code 
> adapt to a given target, like when I wrote something for i386 and then 
> discover I need to do something different for x64 or arm.

Lazarus completion box inside an $IFDEF shows the above macros.

 
> 2. I have tools to extract code sections from Pascal sources. but I don't 
> always know which ifdefs to follow.

Lazarus source editor shows inactive $IFDEF regions.

 
> 3. Just 'cause I'm curios... I guess that's more than 2. :-)

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

Re: [fpc-pascal] List pre-defined defines

[Michael Van Canneyt]

On Tue, 16 May 2017, Jon Foster wrote:

I've looked several times over the years for a way to get fpc to dump all 
of the predefined "defines" for the target selected. Things like "fpc", 
"linux", "unix", "android", "cpuarm", "cpui386", ... and who knows what 
else. Seems like there ought to be an "-i?" switch for this. Have I just 
missed it? Is there something to dump all of the built in defines for the 
current target?


-vc does this. You'll need a source file, though.

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]

>Yes, you can do this, if you set:

>  FullscreenGraph := true;

 

I tried this and it does make a full screen graphics window without the windows 
title bar on top, which I like, however if I task switch out of the graphics 
window, then task switch back to it, my keyboard no longer responds via ptccrt. 
 I do this quite often, even launching things from within my program that I 
expect to be on top of it, for example I will launch a text editor and wait for 
it to be closed before my program continues.  

 

For non-full screen use, are there any variable I can set that would specify 
the graph windows position on the screen, or force the window to be maximized?

 

I was able to switch back and forth to the ptcgraph window by doing the 
following:

  {$H+}

   SetConsoleTitle(ConsoleTitle); //Change name of Console window so it’s not 
the same as the graph window

   Sleep(60); //give windows some time to make the change

   GraphWindow:=FindWindow(nil,Pchar(paramstr(0)+#0#0));  //Figure out handle 
for graph window with FindWindow()

  // the following all work with the handle obtained for the ptcgraph window 
with the above method

   setwindowtextA(graphwindow,GraphTitle); 

   ShowWindow(graphwindow,SW_show);

   SetActiveWindow(graphwindow);

   SetForegroundWindow(graphwindow); 

 

It would be handy if GraphWindow was set to the ptcgraph window handle to make 
it compatible with the graph unit

 

Thanks for the help with this, I really appreciate it

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Nikolay Nikolov
Sent: Tuesday, May 16, 2017 7:45 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] FPC Graphics options?

 

 

 

On 05/16/2017 01:27 PM, James Richters wrote:

> Hmm? But he only wants to change the title of the window. Even on Windows 
> that should work from a different thread. However a platform independent 
> SetWindowTitle() for ptcgraph would be rather useful I guess.

I did a quick test and ran one program that did a writeln of it’s handle, then 
put that handle in another program and ran it and I was able to change the 
window title of the first program with the second program.   So if ptcgraph 
also had the graphwindow : handle variable I think it would work.

 

>Though I'd like to know why he needs ShowWindow()...

 

My application is purposefully designed not to use a mouse…  It’s CNC control 
software and mice, even optical ones out in dusty shops are tedious and 
difficult… it’s often difficult to even find a place to put a mouse, nevermind 
seeing a pointer when the screen is full of sawdust.   So I have keyboard 
commands that get me back to the console window where I can look at some things 
like the contents of some variables, then when I’m done I hit another key and 
it puts me back on the graphics window.   I just use both crt and pctcrt  and 
do things like crt.readkey and pctcrt.readkey to know which screen got the 
input.   I can get by without ShowWindow() because I can alt-tab between the 
windows without a mouse, and admittedly there isn’t a huge use for the console 
window, but it is a lot nicer for the program to put the correct window on top 
by itself.

 

It would be nice if I could: 

1.  The above mentioned ShowWindow()
2.  Make the graph window full screen always, it normally does not come up 
full screen it’s the correct size for full screen but mispositioned.. I can 
probably fix this in a shortcut that starts it but would be nice if the program 
itself forced full screen

Yes, you can do this, if you set:

  FullscreenGraph := true;

In the beginning of your program (before InitGraph). Tonight I'll also add the 
option for changing the title bar text, when in windowed mode.



3.   
4.  Get rid of the windows titlebar all together, I could just draw my own. 
  I was able to shut the title bar off with the graph unit, but the window 
would still be the size of the screen minus the bar.   I believe if the 
titlebar was defined to be shut off before the window was created, or shortly 
after then I could have completely full screen with no title bar. But I don’t 
know where or how the window is created to do that.
5.  If I can’t get rid of the titlebar, then setting a custom window title 
would be nice, preferably after my program was running so I could put status 
information up there, but if not possible then a one time custom title bar name 
would be great.

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sven Barth via fpc-pascal
Sent: Tuesday, May 16, 2017 2:00 AM
To: FPC-Pascal users discussions   

Cc: Sven Barth   

Subject: Re: [fpc-pascal] FPC Graphics options?

 

Am 16.05.2017 02:46 schrieb "Nikolay Nikolov"  >:
>> I also no longer 

Re: [fpc-pascal] FPC Graphics options?

[James Richters]

Join the bad time estimate club! The help is very much appreciated and 
whatever time you can allow for it great.

James

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



On 05/16/2017 02:45 PM, Nikolay Nikolov wrote:
>
>
> Tonight I'll also add the option for changing the title bar text, when 
> in windowed mode.
Unfortunately, I didn't have the time to do it tonight (I'm kinda bad at time 
estimates ;-) ), but I'll probably implement it during the weekend.

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] List pre-defined defines

[Jon Foster]

On 05/16/2017 02:53 PM, Mattias Gaertner wrote:

On Tue, 16 May 2017 14:45:42 -0700
Jon Foster  wrote:


I've looked several times over the years for a way to get fpc to dump all
of the predefined "defines" for the target selected. Things like "fpc",
"linux", "unix", "android", "cpuarm", "cpui386", ... and who knows what
else. Seems like there ought to be an "-i?" switch for this. Have I just
missed it? Is there something to dump all of the built in defines for the
current target?

touch mytest
fpc -vc mytest


Thanks fellas! I guess I always figured that was source code specific 
information. Works good, even without source. Just have to ignore the exit 
code. :-D


THX!

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