RE : [fpc-pascal] How to translate this union ?

2011-04-30 Thread Ludo Brands 
Can you post the original c code? You point to a file that seems to be a
reworked output from h2pas. As it is now, it indeed doesn't make any sense.
I would think the su_len,su_family,su_port should make up a record but they
aren't.
 
I suggest you move the #defines inside the union declaration to somewhere
before the union declaration. It'll double up the ifdef's but make the code
so much more readable.
 
 
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de ik
Envoyé : vendredi 29 avril 2011 22:15
À : FPC-Pascal users discussions
Objet : [fpc-pascal] How to translate this union ?



Hello list,

I'm trying to translate the following
 union to
Pascal, but I do not understand it, and so does h2pas.
How to translate it ?

Thanks,

Ido



LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il




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

Re: RE : [fpc-pascal] How to translate this union ?

2011-04-30 Thread ik 
On Sat, Apr 30, 2011 at 10:18, Ludo Brands  wrote:

>  Can you post the original c code? You point to a file that seems to be a
> reworked output from h2pas. As it is now, it indeed doesn't make any sense.
> I would think the su_len,su_family,su_port should make up a record but they
> aren't.
>

Actually it's my own code :) But here is the original
header,
line 157. The question is how can I create this lines ?



>
> I suggest you move the #defines inside the union declaration to somewhere
> before the union declaration. It'll double up the ifdef's but make the code
> so much more readable.
>

Thanks,

Ido


>
>
>  -Message d'origine-
> *De :* fpc-pascal-boun...@lists.freepascal.org [mailto:
> fpc-pascal-boun...@lists.freepascal.org] *De la part de* ik
> *Envoyé :* vendredi 29 avril 2011 22:15
> *À :* FPC-Pascal users discussions
> *Objet :* [fpc-pascal] How to translate this union ?
>
>  Hello list,
>
> I'm trying to translate the following 
> unionto 
> Pascal, but I do not understand it, and so does h2pas.
> How to translate it ?
>
> Thanks,
>
> Ido
>
>
> LINESIP - Opening the source for communication
> http://www.linesip.com
> http://www.linesip.co.il
>
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

RE : RE : [fpc-pascal] How to translate this union ?

2011-04-30 Thread Ludo Brands 
Forget my previous reply. I found the original header file on sourceforge. 
 
I have alse a better understanding now of what the code is supposed to do:
in case DOCUMENTATION_ONLY is not defined,  a reference to, for example,
su_sockaddr_u.su_family will be subsstituted by
su_sockaddr_u.susa.sa_family. 
You could use macros and do a {$define su_family:=susa.sa_family} with the
following limitations:
- if you have variables or other record members named su_family, not part of
the su_sockaddr_u record, they will be renamed also. 
- it works only for the units that include your .inc file.
 

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Ludo Brands
Envoyé : samedi 30 avril 2011 09:18
À : 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] How to translate this union ?


Can you post the original c code? You point to a file that seems to be a
reworked output from h2pas. As it is now, it indeed doesn't make any sense.
I would think the su_len,su_family,su_port should make up a record but they
aren't.
 
I suggest you move the #defines inside the union declaration to somewhere
before the union declaration. It'll double up the ifdef's but make the code
so much more readable.
 
 
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de ik
Envoyé : vendredi 29 avril 2011 22:15
À : FPC-Pascal users discussions
Objet : [fpc-pascal] How to translate this union ?



Hello list,

I'm trying to translate the following
 union to
Pascal, but I do not understand it, and so does h2pas.
How to translate it ?

Thanks,

Ido



LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il




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

RE : RE : RE : [fpc-pascal] How to translate this union ?

2011-04-30 Thread Ludo Brands 
Using macros, the translation looks like
 
{$MACRO ON}
{$ifndef DOCUMENTATION_ONLY}
{$if SU_HAVE_SOCKADDR_SA_LEN <>0}
  {$define su_len:=su_sa.sa_len}
{$else}
  {$define su_len:=su_array[0]}
{$endif}
{$define su_family:=su_sa.sa_family}
{$define su_port:=su_sin.sin_port}
{$define su_scope_id:=su_array32[6]}
{$endif}
type
su_sockaddr_u = record
case longint of
  {$ifdef DOCUMENTATION_ONLY}
  0 : ( su_len : byte );
  1 : ( su_family : byte );
  2 : ( su_port : word );
  {$else}
  3 : ( su_dummy : smallint );
  {$endif}
  4 : ( su_array : array[0..31] of char );
  5 : ( su_array16 : array[0..15] of word );
  6 : ( su_array32 : array[0..7] of longword );
  7 : ( su_sa : sockaddr );
  8 : ( su_sin : sockaddr_in );
  {$if SU_HAVE_IN6 <>0}
  9 : ( su_sin6 : sockaddr_in6 );
  {$endif}
  {$ifdef DOCUMENTATION_ONLY}
  10 : ( su_scope_id : longword );
  {$endif}
end;


-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Ludo Brands
Envoyé : samedi 30 avril 2011 10:29
À : 'FPC-Pascal users discussions'
Objet : RE : RE : [fpc-pascal] How to translate this union ?


Forget my previous reply. I found the original header file on sourceforge. 
 
I have alse a better understanding now of what the code is supposed to do:
in case DOCUMENTATION_ONLY is not defined,  a reference to, for example,
su_sockaddr_u.su_family will be subsstituted by
su_sockaddr_u.susa.sa_family. 
You could use macros and do a {$define su_family:=susa.sa_family} with the
following limitations:
- if you have variables or other record members named su_family, not part of
the su_sockaddr_u record, they will be renamed also. 
- it works only for the units that include your .inc file.
 

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Ludo Brands
Envoyé : samedi 30 avril 2011 09:18
À : 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] How to translate this union ?


Can you post the original c code? You point to a file that seems to be a
reworked output from h2pas. As it is now, it indeed doesn't make any sense.
I would think the su_len,su_family,su_port should make up a record but they
aren't.
 
I suggest you move the #defines inside the union declaration to somewhere
before the union declaration. It'll double up the ifdef's but make the code
so much more readable.
 
 
-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de ik
Envoyé : vendredi 29 avril 2011 22:15
À : FPC-Pascal users discussions
Objet : [fpc-pascal] How to translate this union ?



Hello list,

I'm trying to translate the following
 union to
Pascal, but I do not understand it, and so does h2pas.
How to translate it ?

Thanks,

Ido



LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il




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

[fpc-pascal] How to get the offset of a record

2011-04-30 Thread Rainer Stratmann 
In Turbopascal it was possible with offs()

type
 rectype = record
  var1 : longint;
  var2 : longint;
  var3 : boolean;
 end;

var
 o : longint;
 recvar : rectype;

 o := offs( recvar.var1 );  // --> 0
 o := offs( recvar.var2 );  // --> 4
 o := offs( recvar.var3 );  // --> 8
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Aleksa Todorovic 
On Sat, Apr 30, 2011 at 14:30, Rainer Stratmann
 wrote:
> In Turbopascal it was possible with offs()
>
> type
>  rectype = record
>  var1 : longint;
>  var2 : longint;
>  var3 : boolean;
>  end;
>
> var
>  o : longint;
>  recvar : rectype;
>
>  o := offs( recvar.var1 );  // --> 0
>  o := offs( recvar.var2 );  // --> 4
>  o := offs( recvar.var3 );  // --> 8

o := PtrUInt( @recvar.var1 ) - PtrUInt( @recvar );
o := PtrIUnt( @recvar.var2 ) - PtrUInt( @recvar );
o := PtrInUt( @recvar.var3 ) - PtrUInt( @recvar );

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

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Florian Klämpfl 
> o := PtrUInt( @recvar.var1 ) - PtrUInt( @recvar );
> o := PtrIUnt( @recvar.var2 ) - PtrUInt( @recvar );
> o := PtrInUt( @recvar.var3 ) - PtrUInt( @recvar );

Actually even
o := PtrUInt(@(rectype(nil^).var1)));
is possible.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Rainer Stratmann 
Am Saturday 30 April 2011 14:54:22 schrieb Aleksa Todorovic:
> On Sat, Apr 30, 2011 at 14:30, Rainer Stratmann
>
>  wrote:
> > In Turbopascal it was possible with offs()
> >
> > type
> >  rectype = record
> >  var1 : longint;
> >  var2 : longint;
> >  var3 : boolean;
> >  end;
> >
> > var
> >  o : longint;
> >  recvar : rectype;
> >
> >  o := offs( recvar.var1 );  // --> 0
> >  o := offs( recvar.var2 );  // --> 4
> >  o := offs( recvar.var3 );  // --> 8
>
> o := PtrUInt( @recvar.var1 ) - PtrUInt( @recvar );
> o := PtrIUnt( @recvar.var2 ) - PtrUInt( @recvar );
> o := PtrInUt( @recvar.var3 ) - PtrUInt( @recvar );

var addrx : longint;

type
 rectype = record
  var1 : longint;
  var2 : longint;
  var3 : boolean;
 end;
 rectype_2 = record
  ofs1 : longint;
  ofs2 : longint;
  ofs3 : longint;
 end;

var
 recvar : rectype;

procedure t;
var o1 , o2 , o3 : longint;
begin
 // works
 o1 := ptruint( @recvar.var1 ) - ptruint( @recvar );
 o2 := ptruint( @recvar.var2 ) - ptruint( @recvar );
 o3 := ptruint( @recvar.var3 ) - ptruint( @recvar );
end;

const rec : rectype_2 = (
 // does not work! (illegal expression)
 ofs1 : ptruint( @recvar.var1 ) - ptruint( @recvar );
 ofs2 : ptruint( @recvar.var2 ) - ptruint( @recvar );
 ofs3 : ptruint( @recvar.var3 ) - ptruint( @recvar );
 );


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


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

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Jonas Maebe 

On 30 Apr 2011, at 14:30, Rainer Stratmann wrote:

> In Turbopascal it was possible with offs()
> 
> type
> rectype = record
>  var1 : longint;
>  var2 : longint;
>  var3 : boolean;
> end;
> 
> var
> o : longint;
> recvar : rectype;
> 
> o := offs( recvar.var1 );  // --> 0

That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the offset in 
the segment that contains the "recvar" variable. It does not return the 
relative offset of the field inside the record type.


Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Rainer Stratmann 
Am Saturday 30 April 2011 15:16:08 schrieb Jonas Maebe:
> On 30 Apr 2011, at 14:30, Rainer Stratmann wrote:
> > In Turbopascal it was possible with offs()
> >
> > type
> > rectype = record
> >  var1 : longint;
> >  var2 : longint;
> >  var3 : boolean;
> > end;
> >
> > var
> > o : longint;
> > recvar : rectype;
> >
> > o := offs( recvar.var1 );  // --> 0
>
> That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the offset
> in the segment that contains the "recvar" variable. It does not return the
> relative offset of the field inside the record type.

That are 2 different things.

There was a function which gives the relative offset of the field I am very 
sure of that. And I am very sure that it was offs (wich 2 "f").

>
> Jonas___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal


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

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Jonas Maebe 

On 30 Apr 2011, at 15:20, Rainer Stratmann wrote:

> Am Saturday 30 April 2011 15:16:08 schrieb Jonas Maebe:
>> That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the offset
>> in the segment that contains the "recvar" variable. It does not return the
>> relative offset of the field inside the record type.
> 
> That are 2 different things.
> 
> There was a function which gives the relative offset of the field I am very 
> sure of that. And I am very sure that it was offs (wich 2 "f").

I'm quite sure it's not, see attachment. The only thing that existed was the 
"offset" operator, but it only worked in assembler blocks (and afaik it also 
works in FPC assembler blocks).


Jonas

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

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Rainer Stratmann 
Am Saturday 30 April 2011 15:28:03 schrieb Jonas Maebe:
> On 30 Apr 2011, at 15:20, Rainer Stratmann wrote:
> > Am Saturday 30 April 2011 15:16:08 schrieb Jonas Maebe:
> >> That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the
> >> offset in the segment that contains the "recvar" variable. It does not
> >> return the relative offset of the field inside the record type.
> >
> > That are 2 different things.
> >
> > There was a function which gives the relative offset of the field I am
> > very sure of that. And I am very sure that it was offs (wich 2 "f").
>
> I'm quite sure it's not, see attachment. The only thing that existed was
> the "offset" operator, but it only worked in assembler blocks (and afaik it
> also works in FPC assembler blocks).
>
>
> Jonas

Hello Jonas,

then it was the offset() method or somehow else...
But it was possible.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

RE : [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Ludo Brands 
This is ages ago, but IIRC getmem would allocate memory on segment
boundaries (offset 0). In a dynamically allocated record ofs(record.member)
(one f) would give you the offset to the start of record. This was obviously
a special case. I'm not sure if large/huge memory model was part of it.
Otherwise, conceptually, I can't imagine a function that would return an
offset to the start of a structure by only giving a reference to a member of
that structure. Even Florians solution contains the starting point: nil.

Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Jonas Maebe
Envoyé : samedi 30 avril 2011 15:28
À : FPC-Pascal users discussions
Objet : Re: [fpc-pascal] How to get the offset of a record



On 30 Apr 2011, at 15:20, Rainer Stratmann wrote:

> Am Saturday 30 April 2011 15:16:08 schrieb Jonas Maebe:
>> That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the 
>> offset in the segment that contains the "recvar" variable. It does 
>> not return the relative offset of the field inside the record type.
> 
> That are 2 different things.
> 
> There was a function which gives the relative offset of the field I am 
> very
> sure of that. And I am very sure that it was offs (wich 2 "f").

I'm quite sure it's not, see attachment. The only thing that existed was the
"offset" operator, but it only worked in assembler blocks (and afaik it also
works in FPC assembler blocks).


Jonas


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

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Rainer Stratmann 
Am Saturday 30 April 2011 15:15:21 schrieb Florian Klämpfl:
> > o := PtrUInt( @recvar.var1 ) - PtrUInt( @recvar );
> > o := PtrIUnt( @recvar.var2 ) - PtrUInt( @recvar );
> > o := PtrInUt( @recvar.var3 ) - PtrUInt( @recvar );
>
> Actually even
> o := PtrUInt(@(rectype(nil^).var1)));
> is possible.

But
const o : longint = PtrUInt(@(rectype(nil^).var1)));
unfortunately is not possible.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get the offset of a record

2011-04-30 Thread Mark Morgan Lloyd 

Jonas Maebe wrote:

On 30 Apr 2011, at 14:30, Rainer Stratmann wrote:


In Turbopascal it was possible with offs()

type
rectype = record
 var1 : longint;
 var2 : longint;
 var3 : boolean;
end;

var
o : longint;
recvar : rectype;

o := offs( recvar.var1 );  // --> 0


That's incorrect. In TP, Ofs(recvar.var1) (with one "f") returns the offset in the 
segment that contains the "recvar" variable. It does not return the relative offset of 
the field inside the record type.


But in at least some cases Ofs() was normalised to always contain 0..15, 
so it would be easy to (mis)interpret it as an offset into an allocated 
block.


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

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

Re: [fpc-pascal] Generics feature status

2011-04-30 Thread Sven Barth 

On 30.04.2011 03:15, Paul Ishenin wrote:

30.04.2011 3:28, leledumbo wrote:

I see now that generics have improved a lot since latest release, we even
have Delphi compatible syntax in Delphi mode. Recursive generic type is
supported as well now (finally, I can continue my data structure library
:)). Seeing these facts, what's the status of this feature now? Is it
considered stable?--

No, they are not stable. FPC generic syntax may change. But you can rely
on delphi syntax (as we can't change it) with few limitations at the
moment:
- no multiply generics with the same identifier and different amount of
type parameters [1],
- no generic methods,
- no type constraints.

Also I may forgot something.

About [1] - in delphi it is possible to define different generics with
the same identifier and different amount of type parameteres (even in
the same unit). E.g.
TList = class ...; TList = class ...; TList = class ...;

Then you can declare variables with any of that types. E.g.
var
L: TList;
LI: TList;
LIO: TList

As I know Sven will work to support this and other missing generics
features.


Point 1 is already on a good way - with backwards compatible FPC syntax 
:) The only thing that still scares me are those nasty inline 
declarations -.-


Type constraints (at least non-interface ones) should be rather easy to 
do. The hardest part might be the parsing.


Regarding generic methods: I've already found the points where I'll need 
to hook in and keep those in mind while extending/adjusting the existing 
code, but that's it currently.


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

Re: RE : RE : RE : [fpc-pascal] How to translate this union ?

2011-04-30 Thread Sven Barth 

Question:

In case of DOCUMENTATION_ONLY not defined, does

su_sockaddr_u = record
(...)
  1 : ( su_sa.sa_family : byte )
(...)
end;

really compile?
(From what I know about Pascal I would say: no)

Regards,
Sven

On 30.04.2011 10:53, Ludo Brands wrote:

Using macros, the translation looks like
{$MACRO ON}
{$ifndef DOCUMENTATION_ONLY}
{$if SU_HAVE_SOCKADDR_SA_LEN <>0}
{$define su_len:=su_sa.sa_len}
{$else}
{$define su_len:=su_array[0]}
{$endif}
{$define su_family:=su_sa.sa_family}
{$define su_port:=su_sin.sin_port}
{$define su_scope_id:=su_array32[6]}
{$endif}
type
su_sockaddr_u = record
case longint of
{$ifdef DOCUMENTATION_ONLY}
0 : ( su_len : byte );
1 : ( su_family : byte );
2 : ( su_port : word );
{$else}
3 : ( su_dummy : smallint );
{$endif}
4 : ( su_array : array[0..31] of char );
5 : ( su_array16 : array[0..15] of word );
6 : ( su_array32 : array[0..7] of longword );
7 : ( su_sa : sockaddr );
8 : ( su_sin : sockaddr_in );
{$if SU_HAVE_IN6 <>0}
9 : ( su_sin6 : sockaddr_in6 );
{$endif}
{$ifdef DOCUMENTATION_ONLY}
10 : ( su_scope_id : longword );
{$endif}
end;

-Message d'origine-
*De :* fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] *De la part de*
Ludo Brands
*Envoyé :* samedi 30 avril 2011 10:29
*À :* 'FPC-Pascal users discussions'
*Objet :* RE : RE : [fpc-pascal] How to translate this union ?

Forget my previous reply. I found the original header file on
sourceforge.
I have alse a better understanding now of what the code is supposed
to do: in case DOCUMENTATION_ONLY is not defined, a reference to,
for example, su_sockaddr_u.su_family will be subsstituted by
su_sockaddr_u.susa.sa_family.
You could use macros and do a {$define su_family:=susa.sa_family}
with the following limitations:
- if you have variables or other record members named su_family, not
part of the su_sockaddr_u record, they will be renamed also.
- it works only for the units that include your .inc file.

-Message d'origine-
*De :* fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] *De la part de*
Ludo Brands
*Envoyé :* samedi 30 avril 2011 09:18
*À :* 'FPC-Pascal users discussions'
*Objet :* RE : [fpc-pascal] How to translate this union ?

Can you post the original c code? You point to a file that seems
to be a reworked output from h2pas. As it is now, it indeed
doesn't make any sense. I would think the
su_len,su_family,su_port should make up a record but they aren't.
I suggest you move the #defines inside the union declaration to
somewhere before the union declaration. It'll double up the
ifdef's but make the code so much more readable.
-Message d'origine-
*De :* fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] *De la part de* ik
*Envoyé :* vendredi 29 avril 2011 22:15
*À :* FPC-Pascal users discussions
*Objet :* [fpc-pascal] How to translate this union ?

Hello list,

I'm trying to translate the following union

to Pascal, but I do not understand it, and so does h2pas.
How to translate it ?

Thanks,

Ido


LINESIP - Opening the source for communication
http://www.linesip.com
http://www.linesip.co.il




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


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

Re: [fpc-pascal] nested macros in C headers

2011-04-30 Thread Bernd 
2011/4/24 Paulo Costa :

> Probably you are right. Let me know how does it works for you. Historically,
> we had a V4L unit for Kylix that was used with a Bt878 Frame Grabber and we
> had to build the new component when we wanted to use the USB cameras. Back
> then, some drivers were not available as V4L2.

I had some more time to look into this now, read some more
documentation and looked into the 5dpo sources.

Actually it really seems to be a full featured v4l2 implementation,
unfortunately I have only one v4l2 device to test it and the driver of
this device itself seems broken/incomplete. This diver will accept a
lot of different format settings without complaining but send its data
always as the same (probably jpeg) that I was not yet able to decode.
Other Applications have problems with this diver too.

The problem with v4l as I see it now is that it does not really define
a nice standard that could be easily used by the application. Only the
handshaking and camera settings are standardized, the actual data is
allowed to be transmitted in any of a myriad of possible formats, the
kernel guys don't like (don't allow) format conversion in kernel
space, so the driver just pumps the raw data from the camera to the
application. The application itself must be able to handle a zillion
of different video formats and encodings. Therefore it seems (from
what I understand so far) there exists a set of libraries that can (or
should) be used to wrap the raw v4l device into something that is
more application friendly and attempts to solve this problem.

This is what I will investigate next.

Currently I have an old v4l1 device with no existing v4l2 driver, so I
needed some way to access a v4l1 device. The units from 5dpo do not
contain the needed definitions to use v4l1, only v4l2.

So I wrote a bare bones minimal v4l1 unit from scratch, manually
translating the headers from the FreeBSD (better documentation)
videodev.h file, that contains only the absolute minimum that is
needed to open a v4l1 camera, set the image settings (brightness, etc)
and grab frames. Fortunately my camera outputs uncompressed RGB24
data.

I am attaching the unit for documentation purposes (its really legacy
stuff, no new devices use v4l1 nowadays but there are still some old
cameras around needed for special purposes), maybe somebody else will
stumble over this while searching for the same problem. It also
contains a class with some methods that demonstrates how to open the
cam and grab images, I have used it in this current form to
sucessfully grab streaming images from an old QuickCam Express that
uses the qc-usb driver on kernel  2.6.24.

Bernd
{ Implements the bare minimum of v4l (NOT v4l2), just enough
  to open the webcam, set the picture settings and grab images.
  It does not contain anything regarding Tuners, Audio, etc.

  Copyright 2011 Bernd Kreuss 

  License: Not sure, probably the same as FreeBSD because it
  is entirely derived from their re-implementation of videodev.h,
  the original file is attached at the end.

  If you find some missing "r" chracters in my source code
  comments then this is because my keyboard is broken. }

unit v4l1;

{$mode objfpc}{$H+}

interface

const
  // these are used in the TVideo_Capability record
  VID_TYPE_CAPTURE = 1 ; { Can capture }
  VID_TYPE_TUNER = 2 ; { Can tune }
  VID_TYPE_TELETEXT = 4 ; { Does teletext }
  VID_TYPE_OVERLAY = 8 ; { Overlay onto frame buffer }
  VID_TYPE_CHROMAKEY = 16 ; { Overlay by chromakey }
  VID_TYPE_CLIPPING = 32 ; { Can clip }
  VID_TYPE_FRAMERAM = 64 ; { Uses the frame buffer memory }
  VID_TYPE_SCALES = 128 ; { Scalable }
  VID_TYPE_MONOCHROME = 256 ; { Monochrome only }
  VID_TYPE_SUBCAPTURE = 512 ; { Can capture subareas of the image }
  VID_TYPE_MPEG_DECODER = 1024 ; { Can decode MPEG streams }
  VID_TYPE_MPEG_ENCODER = 2048 ; { Can encode MPEG streams }
  VID_TYPE_MJPEG_DECODER = 4096 ; { Can decode MJPEG streams }
  VID_TYPE_MJPEG_ENCODER = 8192 ; { Can encode MJPEG streams }

  // these are used in the TVideo_Picture record
  VIDEO_PALETTE_GREY = 1; { Linear greyscale }
  VIDEO_PALETTE_HI240 = 2; { High 240 cube (BT848) }
  VIDEO_PALETTE_RGB565 = 3; { 565 16 bit RGB }
  VIDEO_PALETTE_RGB24 = 4; { 24bit RGB }
  VIDEO_PALETTE_RGB32 = 5; { 32bit RGB }
  VIDEO_PALETTE_RGB555 = 6; { 555 15bit RGB }
  VIDEO_PALETTE_YUV422 = 7; { YUV422 capture }
  VIDEO_PALETTE_YUYV = 8;
  VIDEO_PALETTE_UYVY = 9; { The great thing about standards is ... }
  VIDEO_PALETTE_YUV420 = 10;
  VIDEO_PALETTE_YUV411 = 11; { YUV411 capture }
  VIDEO_PALETTE_RAW = 12; { RAW capture (BT848) }
  VIDEO_PALETTE_YUV422P = 13; { YUV 4:2:2 Planar }
  VIDEO_PALETTE_YUV411P = 14; { YUV 4:1:1 Planar }
  VIDEO_PALETTE_YUV420P = 15; { YUV 4:2:0 Planar }
  VIDEO_PALETTE_YUV410P = 16; { YUV 4:1:0 Planar }
  VIDEO_PALETTE_PLANAR = 13; { start of planar entries }
  VIDEO_PALETTE_COMPONENT = 7; { start of component entries }

  // used in TVideo_Mbuf
  VIDEO_MAX_FRAME = 32;

type
  { will be filled b