Re: [fpc-pascal] Is there a smart way to save/restore NotifyEvents and objects?

[Dennis Poon]

Sven Barth via fpc-pascal wrote:
Am 02.02.2018 17:53 schrieb "Dennis" >:


I have list of objects which contains references to other objects.
I need to save all these objects to harddisk to be restored on a
latter day.

I know how to stream the data fields of these objects to a
TFileStream but the tricky part is these how to restore the object
references.

The only way I can think of is to assign unique IDs to each
objects and store these IDs to file.
When these objects are later restored, I used these IDs find the
actual objects and re-assign them back to the object references.

It is tedious. Is there a smarter way?

Also, there are some TNotifyEvent fields  e.g. OnClick, OnClose
etc.  How do I save and restore them from file?

Many thanks in advance.


If your objects inherit from TComponent and you use published 
properties you can use the streaming screen of the RTL.


I am curious how TComponent save and restore TnotifyEvent fields. Can 
you explain a little bit?

Also, what is 'streaming screen' of RTL? How to use it?

Thanks.

Dennis

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

Re: [fpc-pascal] Is there a smart way to save/restore NotifyEvents and objects?

[Sven Barth via fpc-pascal]

Am 02.02.2018 17:53 schrieb "Dennis" :

I have list of objects which contains references to other objects.
I need to save all these objects to harddisk to be restored on a latter day.

I know how to stream the data fields of these objects to a TFileStream but
the tricky part is these how to restore the object references.

The only way I can think of is to assign unique IDs to each objects and
store these IDs to file.
When these objects are later restored, I used these IDs find the actual
objects and re-assign them back to the object references.

It is tedious. Is there a smarter way?

Also, there are some TNotifyEvent fields  e.g. OnClick, OnClose etc.  How
do I save and restore them from file?

Many thanks in advance.


If your objects inherit from TComponent and you use published properties
you can use the streaming screen of the RTL.

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

Re: [fpc-pascal] question about _fpc_local_unwind

[Sven Barth via fpc-pascal]

Am 02.02.2018 18:12 schrieb "Matias Vara" :

Hello,

2018-02-02 17:17 GMT+01:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Am 02.02.2018 15 <02%2002%2020%2018%2015>:50 schrieb "Matias Vara" <
> matiasev...@gmail.com>:
>
> Thanks for the answer, I will imitate in Toro the behavior of Win64.
>
>
> Maybe it wound be better if you try to use the i386-embedded or
> x86_64-embedded targets. The non-embedded targets are simply not geared
> towards usage on a bare platform
>
>
Thanks for the suggestion, I don't think I am able to do that since the
whole kernel  compiles well by using the Win64 target. So I am not planing
to change the target. I notice that the code is in rtl/win64/seh64.inc so I
am starting to try to understand it.

Most of the exception handling and unwinding is done by Windows, relying on
specific sections in the binary. You essentially picked one of the worst
targets to implement your kernel with...
Another plus of the embedded target: you can disable RTL features that you
don't need (e.g. RTTI, threading, etc.).

Regards,
Sven

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

Re: [fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Hello,

2018-02-02 17:17 GMT+01:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

> Am 02.02.2018 15 <02%2002%2020%2018%2015>:50 schrieb "Matias Vara" <
> matiasev...@gmail.com>:
>
> Thanks for the answer, I will imitate in Toro the behavior of Win64.
>
>
> Maybe it wound be better if you try to use the i386-embedded or
> x86_64-embedded targets. The non-embedded targets are simply not geared
> towards usage on a bare platform
>
>
Thanks for the suggestion, I don't think I am able to do that since the
whole kernel  compiles well by using the Win64 target. So I am not planing
to change the target. I notice that the code is in rtl/win64/seh64.inc so I
am starting to try to understand it.

Matias



> 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

[fpc-pascal] Is there a smart way to save/restore NotifyEvents and objects?

[Dennis]

I have list of objects which contains references to other objects.
I need to save all these objects to harddisk to be restored on a latter day.

I know how to stream the data fields of these objects to a TFileStream 
but the tricky part is these how to restore the object references.


The only way I can think of is to assign unique IDs to each objects and 
store these IDs to file.
When these objects are later restored, I used these IDs find the actual 
objects and re-assign them back to the object references.


It is tedious. Is there a smarter way?

Also, there are some TNotifyEvent fields  e.g. OnClick, OnClose etc.  
How do I save and restore them from file?


Many thanks in advance.

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

Re: [fpc-pascal] question about _fpc_local_unwind

[Sven Barth via fpc-pascal]

Am 02.02.2018 15:50 schrieb "Matias Vara" :

Thanks for the answer, I will imitate in Toro the behavior of Win64.


Maybe it wound be better if you try to use the i386-embedded or
x86_64-embedded targets. The non-embedded targets are simply not geared
towards usage on a bare platform.

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

Re: [fpc-pascal] libc and math.h on Linux

[Adriaan van Os]

Marco van de Voort wrote:

In our previous episode, Adriaan van Os said:

Long double is probably 10-byte extended, but verify that by compiling and
running a small C program for your distro.

I assume that the FPC clongdouble type has the right size ?


Define "right".


Well, a cxxx type is "right" if FPC cxxx and GCC xxx have the same size, which after all is the 
purpose of having these types in FPC.





I checked on OS X (x86) where FPC longdouble is 10-byte, FPC clongdouble
is 16-byte and GCC long double is 16 byte too.


Maybe a heritage of PPC that did have a 128-bit fp type. But x86/x86_64 to my
knowledge doesn't have such type, and I just tested and Linux


When I look at the source of GCC and GPC for OS X, I believe it is a 10-byte extended stuffed into 
a 16-byte type. Calling e.g. sinl works fine on OS X when declared either "wrong" with 10-byte or 
"right" with 16-byte parameters.



glibc might have changed from ye old days when it was 80-bit. Which is why I 
recommended to double check in the first place.


Will do so.

Regards,

Adriaan van Os

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

Re: [fpc-pascal] libc and math.h on Linux

[Marco van de Voort]

In our previous episode, Adriaan van Os said:
> > Long double is probably 10-byte extended, but verify that by compiling and
> > running a small C program for your distro.
> 
> I assume that the FPC clongdouble type has the right size ?

Define "right".

> I checked on OS X (x86) where FPC longdouble is 10-byte, FPC clongdouble
> is 16-byte and GCC long double is 16 byte too.

Maybe a heritage of PPC that did have a 128-bit fp type. But x86/x86_64 to my
knowledge doesn't have such type, and I just tested and Linux

uses unixtype;

begin
  writeln(sizeof(clongdouble));
end.

writes "10".

Afaik some work has gone in softfloat in the last years, and maybe there is
an emulated 128-bit type now, but that is news for me. (Florian,Jonas: ?)

>  So, as long as I use clongdouble for the external declarations, there
> should be no problem (I hope).

glibc might have changed from ye old days when it was 80-bit. Which is why I
recommended to double check in the first place.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] question about _fpc_local_unwind

[Matias Vara]

Thanks for the answer, I will imitate in Toro the behavior of Win64.

Matias


2018-02-01 20:49 GMT+01:00 Jonas Maebe :

> On 01/02/18 16:24, Matias Vara wrote:
>
>> I partial answered my question by reading https://www.freepascal.org/doc
>> s-html/ref/refse114.html. So I think _fpc_local_unwind() is used to call
>> the finally section when "Exit" is executed in the "Try" section. It is not
>> clear yet what the parameters "frame,target: Pointer" are meant to. I
>> checked the code generated in Linux and is a bit different. It is base on
>> the functions FPC_PUSHEXCEPTADDR and FPC_POPADDRSTACK, which It seems much
>> more clear. Is it possible to generate a similar code in the case of Win64?
>> In other words, is it possible to tell the compiler "generate the
>> 'try-finally-end' block as in Linux"? I don't think so but It is worth to
>> ask.
>>
>
> No, it is not possible. On Win64 the compiler and RTL use so-called
> structured exception handling (SEH), which is required to interoperate with
> code generated by other compilers. See https://msdn.microsoft.com/en-
> us/library/windows/desktop/ms680657(v=vs.85).aspx for more information.
>
>
> Jonas
> ___
> 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] libc and math.h on Linux

[Adriaan van Os]

Marco van de Voort wrote:

Long double is probably 10-byte extended, but verify that by compiling and
running a small C program for your distro.


I assume that the FPC clongdouble type has the right size ? I checked on OS X (x86) where FPC 
longdouble is 10-byte, FPC clongdouble is 16-byte and GCC long double is 16 byte too. So, as long 
as I use clongdouble for the external declarations, there should be no problem (I hope).


Thanks for the reply regarding the other issues.

Regards,

Adriaan van Os

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

Re: [fpc-pascal] libc and math.h on Linux

[Marco van de Voort]

In our previous episode, Adriaan van Os said:
> I have to import the math.h libc functions listed here
> .  What is the
> recommended way to do this for general Linux compatibility ? 

Not do this ? :-)

>  Simply declare them external ?  Load them from libc dynamically ?

Just declare them external in a separate unit, mathc or so and keep them in
your project.

>  Anything else ? 

Macros, structured constants etc, obviously might require extra work(and
mathh has some, like the is* functions are typically macros)

Long double is probably 10-byte extended, but verify that by compiling and
running a small C program for your distro.

> I know that the FPC runtime lib itself jumps through some hoops to be as
> independent of libc (or a specific version of libc) as possible.

The FPC RTL can use libc (compile with -DFPC_USE_LIBC), but this is nowadays
little tested outside of OS X, and maybe a couple of smaller targets.

The libc policy is due a multitude of small issues, some of which might be
historic, and the idea was to allow the maintainer to chose what approach
fits his target best.

Anyway it only touches redistributable code to be merged with FPC to keep
the .tar somewhat distribution indepedent. For your private stuff you don't
have to worry about it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Problem with file descriptors when doing fork on linux

[Luca Olivetti]

El 02/02/18 a les 11:33, Michael Van Canneyt ha escrit:




Or more generally do exists in fpc some other way how to deal with this
problem - to create new process but without copied file descriptors?


No, currently not.




Why doesn't the unix implementation take into account the InheritHandles 
property?


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

Re: [fpc-pascal] libc and math.h on Linux

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 2 Feb 2018, Adriaan van Os wrote:

> I have to import the math.h libc functions listed here
> . What is the
> recommended way to do this for general Linux compatibility ? Simply
> declare them external ? Load them from libc dynamically ? Anything else
> ? I know that the FPC runtime lib itself jumps through some hoops to be
> as independent of libc (or a specific version of libc) as possible.

We actually link against libc and pthreads when multithreading is involved
on Unices. You need to declare all functions cdecl; external;

See the cmem unit in the RTL for example, which provides simple
link-against-C examples for a number of platforms, both dynamic and static
linking case (pick the option which fits best your usecase):

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/cmem.pp?view=markup

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

[fpc-pascal] libc and math.h on Linux

[Adriaan van Os]

I have to import the math.h libc functions listed here 
. What is the recommended way to do this 
for general Linux compatibility ? Simply declare them external ? Load them from libc dynamically ? 
Anything else ? I know that the FPC runtime lib itself jumps through some hoops to be as 
independent of libc (or a specific version of libc) as possible.


Regards,

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

Re: [fpc-pascal] Problem with file descriptors when doing fork on linux

[Michael Van Canneyt]

On Fri, 2 Feb 2018, Ko Paka wrote:


Hello,

I would like to ask advice. My colleague run into a problem, when he had
used TProcess to spawn other process. Because of fork nature, file
descriptors was copied into newly created process.
He found that for such cases CLOEXEC flag exists to be used when open file.
I found flag declared in various units inside fpc, but nowhere to be used.
So when I need to use it I need to make some own routine?


I have added it to the linux unit:

Const
  O_CLOEXEC = $8;

If you want to use it today, you'll need to add it to your own units
manually.


Or more generally do exists in fpc some other way how to deal with this
problem - to create new process but without copied file descriptors?


No, currently not.

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

[fpc-pascal] Problem with file descriptors when doing fork on linux

[Ko Paka]

Hello,

I would like to ask advice. My colleague run into a problem, when he had
used TProcess to spawn other process. Because of fork nature, file
descriptors was copied into newly created process.
He found that for such cases CLOEXEC flag exists to be used when open file.
I found flag declared in various units inside fpc, but nowhere to be used.
So when I need to use it I need to make some own routine?
Or more generally do exists in fpc some other way how to deal with this
problem - to create new process but without copied file descriptors?

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