[fpc-pascal] Re: Fatal error "Executable image size is too big for wince target"

2011-05-18 Thread Björn Schreiber

Jonas Maebe wrote:


What you can try is to compile the LCL without debug information (add
the option -g- for the LCL compilation)


  Thank you for your answer, I will give it a try.


Greetings
--
Björn Schreiber, DRIGUS GmbH
news...@drigus.de
Bei Email NOSPAM in den Betreff aufnehmen.
Put NOSPAM in subject to reach me by email.

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


[fpc-pascal] URIParser

2011-05-18 Thread ik
Hello,

I have tried to use the URIParser on a structure like so:

sip:ik@10.0.0.2:5060;name=test?header=something

That's the most complicated SIP URI according to the RFC (3261).

But the record was able to just return to me the protocol (sip) and nothing
else.
Does the unit implement it according to the URI RFC ? if so, what version of
that (2396 or 3986) ?


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] Re: URIParser

2011-05-18 Thread ik
I've created a more simple example:

program uri_test;
uses URIParser;

var
  URI : TURI;

begin

  URI := ParseURI('sip:b...@example.com');

  writeln('URI:');
  writeln(#9'Protocol: ', URI.Protocol);
  writeln(#9'Username: ', URI.Username);
  writeln(#9'Password: ', URI.Password);
  writeln(#9'Host: ', URI.Host);
  writeln(#9'Port: ', URI.Port);
  writeln(#9'Path: ', URI.Path);
  writeln(#9'Document: ', URI.Document);
  writeln(#9'Params: ', URI.Params);
  writeln(#9'Bookmark: ', URI.Bookmark);
  writeln(#9'HasAuthority: ', URI.HasAuthority);
end.

The output is:
URI:
Protocol: sip
Username:
Password:
Host:
Port: 0
Path:
Document: b...@example.com
Params:
Bookmark:
HasAuthority: FALSE

Ido

On Wed, May 18, 2011 at 15:25, ik  wrote:

> Hello,
>
> I have tried to use the URIParser on a structure like so:
>
> sip:ik@10.0.0.2:5060;name=test?header=something
>
> That's the most complicated SIP URI according to the RFC (3261).
>
> But the record was able to just return to me the protocol (sip) and nothing
> else.
> Does the unit implement it according to the URI RFC ? if so, what version
> of that (2396 or 3986) ?
>
>
> 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: [fpc-pascal] Re: URIParser

2011-05-18 Thread michael . vancanneyt



On Wed, 18 May 2011, ik wrote:


I've created a more simple example:

program uri_test;
uses URIParser;

var
 URI : TURI;

begin


You don't specify the protocol.

a URI starts always with "protocol://"

so http://sip:b...@example.com/

The URIParser unit expects the protocol to be in place.

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


Re: [fpc-pascal] Re: URIParser

2011-05-18 Thread ik
On Wed, May 18, 2011 at 15:50,  wrote:

>
>
> On Wed, 18 May 2011, ik wrote:
>
>  I've created a more simple example:
>>
>> program uri_test;
>> uses URIParser;
>>
>> var
>>  URI : TURI;
>>
>> begin
>>
>
> You don't specify the protocol.
>
> a URI starts always with "protocol://"
>
> so http://sip:b...@example.com/
>

The problem is that the SIP URI (
http://tools.ietf.org/html/rfc3261#section-19.1 and
http://tools.ietf.org/html/rfc3261#section-19.1.1)
are more like the mailto: URI then the HTTP URI.

RFC 3986  does talk about such structure
of URI as well.


>
> The URIParser unit expects the protocol to be in place.
>
> Michael.
>

Thanks,

Ido


> ___
> 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] Re: URIParser

2011-05-18 Thread michael . vancanneyt



On Wed, 18 May 2011, ik wrote:


On Wed, May 18, 2011 at 15:50,  wrote:




On Wed, 18 May 2011, ik wrote:

 I've created a more simple example:


program uri_test;
uses URIParser;

var
 URI : TURI;

begin



You don't specify the protocol.

a URI starts always with "protocol://"

so http://sip:b...@example.com/



The problem is that the SIP URI (
http://tools.ietf.org/html/rfc3261#section-19.1 and
http://tools.ietf.org/html/rfc3261#section-19.1.1)
are more like the mailto: URI then the HTTP URI.

RFC 3986  does talk about such structure
of URI as well.


Hmmm.

How can code distinguish between

protocol:something@somesite

and
password:something@somesite

?

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


RE : [fpc-pascal] Re: URIParser

2011-05-18 Thread Ludo Brands
>> a URI starts always with "protocol://"

RFC 2396 (http://tools.ietf.org/html/rfc2396 ) specifies that an URI has to
start with the protocol and a colon. The // depends on the protocol scheme.
Valid URI's are for example mailto:mdue...@ifi.unizh.ch or
news:comp.infosystems.www.servers.unix. The SIP URI is
sip:user:password@host:port;uri-parameters?headers and
sips:user:password@host:port;uri-parameters?headers for secure sip
(http://tools.ietf.org/html/rfc3261#page-148). 

Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de
michael.vancann...@wisa.be
Envoyé : mercredi 18 mai 2011 14:50
À : FPC-Pascal users discussions
Objet : Re: [fpc-pascal] Re: URIParser




On Wed, 18 May 2011, ik wrote:

> I've created a more simple example:
>
> program uri_test;
> uses URIParser;
>
> var
>  URI : TURI;
>
> begin

You don't specify the protocol.

a URI starts always with "protocol://"

so http://sip:b...@example.com/

The URIParser unit expects the protocol to be in place.

Michael.
___
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] Re: URIParser

2011-05-18 Thread Marco van de Voort
In our previous episode, michael.vancann...@wisa.be said:
> >
> > RFC 3986  does talk about such structure
> > of URI as well.
> 
> Hmmm.
> 
> How can code distinguish between
> 
> protocol:something@somesite
> 
> and
> password:something@somesite
> 
> ?

The second is not an uri ?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


RE : [fpc-pascal] Re: URIParser

2011-05-18 Thread Ludo Brands
> How can code distinguish between
>
> protocol:something@somesite
> 
> and
> password:something@somesite

Protocol is missing from the last one = not an URI. A protocol is asumed.
Browsers assume http:, mailers mailto:, telnet assumes telnet:,  etc

Ludo


-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de
michael.vancann...@wisa.be
Envoyé : mercredi 18 mai 2011 15:12
À : FPC-Pascal users discussions
Objet : Re: [fpc-pascal] Re: URIParser




On Wed, 18 May 2011, ik wrote:

> On Wed, May 18, 2011 at 15:50,  wrote:
>
>>
>>
>> On Wed, 18 May 2011, ik wrote:
>>
>>  I've created a more simple example:
>>>
>>> program uri_test;
>>> uses URIParser;
>>>
>>> var
>>>  URI : TURI;
>>>
>>> begin
>>>
>>
>> You don't specify the protocol.
>>
>> a URI starts always with "protocol://"
>>
>> so http://sip:b...@example.com/
>>
>
> The problem is that the SIP URI ( 
> http://tools.ietf.org/html/rfc3261#section-19.1 and
> http://tools.ietf.org/html/rfc3261#section-19.1.1)
> are more like the mailto: URI then the HTTP URI.
>
> RFC 3986  does talk about such 
> structure of URI as well.

Hmmm.

How can code distinguish between

protocol:something@somesite

and
password:something@somesite

?

Michael.
___
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] Re: URIParser

2011-05-18 Thread ik
On Wed, May 18, 2011 at 16:08, Marco van de Voort  wrote:

> In our previous episode, michael.vancann...@wisa.be said:
> > >
> > > RFC 3986  does talk about such
> structure
> > > of URI as well.
> >
> > Hmmm.
> >
> > How can code distinguish between
> >
> > protocol:something@somesite
> >
> > and
> > password:something@somesite
> >
> > ?
>
> The second is not an uri ?
>

It is, but as far as I understand, you can not have a password without a
user according to RFC3986 

Ido

> ___
> 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] Re: URIParser

2011-05-18 Thread michael . vancanneyt



On Wed, 18 May 2011, ik wrote:


On Wed, May 18, 2011 at 16:08, Marco van de Voort  wrote:


In our previous episode, michael.vancann...@wisa.be said:


RFC 3986  does talk about such

structure

of URI as well.


Hmmm.

How can code distinguish between

protocol:something@somesite

and
password:something@somesite

?


The second is not an uri ?



It is, but as far as I understand, you can not have a password without a
user according to RFC3986 


So, how to distinguish between the two ?

sip:mysec...@mydomain.com

Is "sip" the protocol or the user name for a HTTP address ?

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


Re: [fpc-pascal] Re: URIParser

2011-05-18 Thread ik
On Wed, May 18, 2011 at 16:49,  wrote:

>
>
> On Wed, 18 May 2011, ik wrote:
>
>  On Wed, May 18, 2011 at 16:08, Marco van de Voort 
>> wrote:
>>
>>  In our previous episode, michael.vancann...@wisa.be said:
>>>

> RFC 3986  does talk about such
>
 structure
>>>
 of URI as well.
>

 Hmmm.

 How can code distinguish between

 protocol:something@somesite

 and
 password:something@somesite

 ?

>>>
>>> The second is not an uri ?
>>>
>>>
>> It is, but as far as I understand, you can not have a password without a
>> user according to RFC3986 > >
>>
>
> So, how to distinguish between the two ?
>
> sip:mysec...@mydomain.com
>
> Is "sip" the protocol or the user name for a HTTP address ?
>

sip is the protocol, mysecrect is the user name

sip::mysecr...@mydomain.com

according to the RFC is the proper way to have
1. Protocol
2. Empty user name
3. Password
4. Domain


>
> Michael.
>
>
Ido


>  ___
> 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] Re: URIParser

2011-05-18 Thread Felipe Monteiro de Carvalho
It should assume that sip is a protocol, like it does now.

I think that:

  URI := ParseURI('sip:b...@example.com');

Should output this:

Protocol: sip
Username: bob
Password:
Host: example.com
Port: 0
Path:
Document:
 Params:
Bookmark:
HasAuthority: FALSE

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: URIParser

2011-05-18 Thread michael . vancanneyt



On Wed, 18 May 2011, ik wrote:


On Wed, May 18, 2011 at 16:49,  wrote:



So, how to distinguish between the two ?

sip:mysec...@mydomain.com

Is "sip" the protocol or the user name for a HTTP address ?



sip is the protocol, mysecrect is the user name

sip::mysecr...@mydomain.com

according to the RFC is the proper way to have
1. Protocol
2. Empty user name
3. Password
4. Domain


I will check the implementation.

As far as I know, it was never meant to be RFC compliant, but we can change
that of course.

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


[fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Tue, May 17, 2011 at 5:04 PM, Marcos Douglas  wrote:
>
> Hi,
> I would like to use the TET[1] in FPC on Windows.
> There are 2 options:
> 1- Translate C header to use libtet.dll (I prefer);
> 2- Use the COM object (TET_com.dll);
>
> I can use COM in Delphi 7 easily. There is a Wizard to translate call
> from COM object to Object Pascal... But I would like to use FPC!
>
> Somebody can help me to use h2pas tool to translate the C header in 
> attachment?
>
> [1] http://www.pdflib.com/download/tet/

Anyone?
At least tell me why h2pas can not parse this header file, please.

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


Re: [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Felipe Monteiro de Carvalho
The file is not big, why don't you just convert it manually?

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


RE : [fpc-pascal] Re: URIParser

2011-05-18 Thread Ludo Brands
Problem is that the RFC definition for the URI doesn't specify the
individual protocol scheme. So every protocol can specify it's own stuff. 

Take the general sip URI:
sip:user:password@host:port;uri-parameters?headers. User can be a telephone
number with folowing definition: global-phone-number   = "+"
base-phone-number [isdn-subaddress]
[post-dial] *(area-specifier /
service-provider / future-extension)
Or
local-phone-number= 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[post-dial] area-specifier
*(area-specifier / service-provider /
future-extension)
This definitely will require custom processing.
Also both uri-parameters and headers are name=value pairs. The first are
separated by ";" and the second by "&"...

I'm afraid a universal URI decoder isn't possible. 

Ludo
  


-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de
michael.vancann...@wisa.be
Envoyé : mercredi 18 mai 2011 16:14
À : FPC-Pascal users discussions
Objet : Re: [fpc-pascal] Re: URIParser




On Wed, 18 May 2011, ik wrote:

> On Wed, May 18, 2011 at 16:49,  wrote:

>> So, how to distinguish between the two ?
>>
>> sip:mysec...@mydomain.com
>>
>> Is "sip" the protocol or the user name for a HTTP address ?
>>
>
> sip is the protocol, mysecrect is the user name
>
> sip::mysecr...@mydomain.com
>
> according to the RFC is the proper way to have
> 1. Protocol
> 2. Empty user name
> 3. Password
> 4. Domain

I will check the implementation.

As far as I know, it was never meant to be RFC compliant, but we can change
that of course.

Michael.
___
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] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 11:26 AM, Felipe Monteiro de Carvalho
 wrote:
> The file is not big, why don't you just convert it manually?

There are 2 reasons:
1- I do not know C very well.
2- Because the first reason, maybe I expended much time to do this. I
would like the help of h2pas tool.

Thanks,

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


Re: [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Felipe Monteiro de Carvalho
If you have any question about translating manually I can help.

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 11:37 AM, Felipe Monteiro de Carvalho
 wrote:
>
> If you have any question about translating manually I can help.
>

OK, thank you!
Answer me: if you were to use this lib, which way do you choose?
ActiveX (Delphi or FPC), translate header or use another language with
support (Java, .NET, Pyhon, Perl, etc... see here
http://www.pdflib.com/products/tet/how-to-use-tet/ ).

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


Re: RE : [fpc-pascal] Re: URIParser

2011-05-18 Thread michael . vancanneyt



On Wed, 18 May 2011, Ludo Brands wrote:


Problem is that the RFC definition for the URI doesn't specify the
individual protocol scheme. So every protocol can specify it's own stuff.

Take the general sip URI:
sip:user:password@host:port;uri-parameters?headers. User can be a telephone
number with folowing definition: global-phone-number   = "+"
base-phone-number [isdn-subaddress]
   [post-dial] *(area-specifier /
   service-provider / future-extension)
Or
local-phone-number= 1*(phonedigit / dtmf-digit /
   pause-character) [isdn-subaddress]
   [post-dial] area-specifier
   *(area-specifier / service-provider /
   future-extension)
This definitely will require custom processing.
Also both uri-parameters and headers are name=value pairs. The first are
separated by ";" and the second by "&"...

I'm afraid a universal URI decoder isn't possible.


Great. 
In that case I just declare that URIParser will only work for ftp and http

protocols :-)

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


RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Ludo Brands
In this case:
1) because h2pas doesn't use pascal macro's. A construct like
#if defined(WIN32) && !defined(PDFLIB_CALL)
#define PDFLIB_CALL __cdecl
#endif
can not be translated using pascal constants or functions. Cdecl is a
calling convention modifier.
2) afaik pascal doesnt support widestring constants. Therefor h2pas doesn't
understand 
#define IFILTER_WCHAR_LONG_VERSIONSTRINGL"4.0p7". In this case, the
string doesn't contain non-ascii characters and pascal will assign (convert)
correctly a ascii string to a widechar string. So you can just solve the
problem by 
const IFILTER_WCHAR_LONG_VERSIONSTRING=IFILTER_LONG_VERSIONSTRING; 

Ludo 



-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Marcos
Douglas
Envoyé : mercredi 18 mai 2011 16:24
À : FPC-Pascal users discussions
Objet : [fpc-pascal] Re: PDFlib TET - convert using h2pas


On Tue, May 17, 2011 at 5:04 PM, Marcos Douglas  wrote:
>
> Hi,
> I would like to use the TET[1] in FPC on Windows.
> There are 2 options:
> 1- Translate C header to use libtet.dll (I prefer);
> 2- Use the COM object (TET_com.dll);
>
> I can use COM in Delphi 7 easily. There is a Wizard to translate call 
> from COM object to Object Pascal... But I would like to use FPC!
>
> Somebody can help me to use h2pas tool to translate the C header in 
> attachment?
>
> [1] http://www.pdflib.com/download/tet/

Anyone?
At least tell me why h2pas can not parse this header file, please.

Marcos Douglas
___
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] Re: URIParser

2011-05-18 Thread ik
On Wed, May 18, 2011 at 17:56,  wrote:

>
>
> On Wed, 18 May 2011, Ludo Brands wrote:
>
>  Problem is that the RFC definition for the URI doesn't specify the
>> individual protocol scheme. So every protocol can specify it's own stuff.
>>
>> Take the general sip URI:
>> sip:user:password@host:port;uri-parameters?headers. User can be a
>> telephone
>> number with folowing definition: global-phone-number   = "+"
>> base-phone-number [isdn-subaddress]
>>   [post-dial] *(area-specifier /
>>   service-provider / future-extension)
>> Or
>> local-phone-number= 1*(phonedigit / dtmf-digit /
>>   pause-character) [isdn-subaddress]
>>   [post-dial] area-specifier
>>   *(area-specifier / service-provider /
>>   future-extension)
>> This definitely will require custom processing.
>> Also both uri-parameters and headers are name=value pairs. The first are
>> separated by ";" and the second by "&"...
>>
>> I'm afraid a universal URI decoder isn't possible.
>>
>
> Great. In that case I just declare that URIParser will only work for ftp
> and http
> protocols :-)


I think it is possible. You can also add another field to the record of
"Extra data" and allow others to parse it.
the headers are like the HTTP URI (even the encoding of it is the same), and
the params are like the HTTP Post more or less but divided by a semicolon.
But I can work with parsing it myself imho, because that part is either
starting with question mark or by semicolon.


>
>
> Michael.
>

Ido


> ___
> 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] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Felipe Monteiro de Carvalho
On Wed, May 18, 2011 at 4:43 PM, Marcos Douglas  wrote:
> Answer me: if you were to use this lib, which way do you choose?
> ActiveX (Delphi or FPC), translate header or use another language with
> support (Java, .NET, Pyhon, Perl, etc... see here
> http://www.pdflib.com/products/tet/how-to-use-tet/ ).

I would translate the headers manually and use that.

I am sending back what I translated in 2 minutes of work. You can use
as a model.

-- 
Felipe Monteiro de Carvalho


tetlib.pas
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

RE : RE : [fpc-pascal] Re: URIParser

2011-05-18 Thread Ludo Brands
The differences I mentioned are just the tip of the iceberg. Another
example: the RFC definition for URI permits for every scheme to define their
own character escape sequence for special and non ascii-characters. Guess
what: sip allows reserved characters in the user field :
sip:+1-212-555-1212:1...@gateway.com;user=phone. Another one?
sip:alice;day=tues...@atlanta.com is allowed and means
user="alice;day=tuesday". (both from
http://tools.ietf.org/html/rfc3261#section-19.1.23)
An "extra" field is not going to be enough to get around these differences
I'm afraid.
 
Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de ik
Envoyé : mercredi 18 mai 2011 17:03
À : FPC-Pascal users discussions
Objet : Re: RE : [fpc-pascal] Re: URIParser


On Wed, May 18, 2011 at 17:56,  wrote:




On Wed, 18 May 2011, Ludo Brands wrote:



Problem is that the RFC definition for the URI doesn't specify the
individual protocol scheme. So every protocol can specify it's own stuff.

Take the general sip URI:
sip:user:password@host:port;uri-parameters?headers. User can be a telephone
number with folowing definition: global-phone-number   = "+"
base-phone-number [isdn-subaddress]
  [post-dial] *(area-specifier /
  service-provider / future-extension)
Or
local-phone-number= 1*(phonedigit / dtmf-digit /
  pause-character) [isdn-subaddress]
  [post-dial] area-specifier
  *(area-specifier / service-provider /
  future-extension)
This definitely will require custom processing.
Also both uri-parameters and headers are name=value pairs. The first are
separated by ";" and the second by "&"...

I'm afraid a universal URI decoder isn't possible.



Great. In that case I just declare that URIParser will only work for ftp and
http
protocols :-)


I think it is possible. You can also add another field to the record of
"Extra data" and allow others to parse it.
the headers are like the HTTP URI (even the encoding of it is the same), and
the params are like the HTTP Post more or less but divided by a semicolon.
But I can work with parsing it myself imho, because that part is either
starting with question mark or by semicolon.
 



Michael.



Ido
 

___
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] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Ludo Brands
>From your question COM or header, I assumed you are only interested in
windows. I also assume that you don't want to export functions defiend. So,
I did the following: 
- removed PDFLIB_API and PDFLIB_CALL (point 1 in my previous message)
- replaced the L".." defines by one to the char version (point 2)

The result from h2pas is attached. What needs to be done:
- add stdcall; behind all functions that had PDFLIB_API. Both in interface
and implementation part.
- if you are linking dynamically replace in the functions that had
PDFLIB_CALL in the implementation part
  begin
{ You must implement this function }
  end;
with
  external 'name of the lib';
- as always, review the translation

Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Ludo Brands
Envoyé : mercredi 18 mai 2011 16:51
À : 'FPC-Pascal users discussions'
Objet : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas


In this case:
1) because h2pas doesn't use pascal macro's. A construct like #if
defined(WIN32) && !defined(PDFLIB_CALL)
#define PDFLIB_CALL __cdecl
#endif
can not be translated using pascal constants or functions. Cdecl is a
calling convention modifier.
2) afaik pascal doesnt support widestring constants. Therefor h2pas doesn't
understand 
#define IFILTER_WCHAR_LONG_VERSIONSTRINGL"4.0p7". In this case, the
string doesn't contain non-ascii characters and pascal will assign (convert)
correctly a ascii string to a widechar string. So you can just solve the
problem by 
const IFILTER_WCHAR_LONG_VERSIONSTRING=IFILTER_LONG_VERSIONSTRING; 

Ludo 



-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Marcos
Douglas Envoyé : mercredi 18 mai 2011 16:24 À : FPC-Pascal users discussions
Objet : [fpc-pascal] Re: PDFlib TET - convert using h2pas


On Tue, May 17, 2011 at 5:04 PM, Marcos Douglas  wrote:
>
> Hi,
> I would like to use the TET[1] in FPC on Windows.
> There are 2 options:
> 1- Translate C header to use libtet.dll (I prefer);
> 2- Use the COM object (TET_com.dll);
>
> I can use COM in Delphi 7 easily. There is a Wizard to translate call
> from COM object to Object Pascal... But I would like to use FPC!
>
> Somebody can help me to use h2pas tool to translate the C header in
> attachment?
>
> [1] http://www.pdflib.com/download/tet/

Anyone?
At least tell me why h2pas can not parse this header file, please.

Marcos Douglas
___
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


tetlib.pp
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 12:05 PM, Felipe Monteiro de Carvalho
 wrote:
>
> On Wed, May 18, 2011 at 4:43 PM, Marcos Douglas  wrote:
> > Answer me: if you were to use this lib, which way do you choose?
> > ActiveX (Delphi or FPC), translate header or use another language with
> > support (Java, .NET, Pyhon, Perl, etc... see here
> > http://www.pdflib.com/products/tet/how-to-use-tet/ ).
>
> I would translate the headers manually and use that.
>
> I am sending back what I translated in 2 minutes of work. You can use
> as a model.

WHAT? 2 minutes?!
Oh.. you just begun the translate... hehe  =)

Thanks!
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 1:28 PM, Ludo Brands  wrote:
> >From your question COM or header, I assumed you are only interested in
> windows. I also assume that you don't want to export functions defiend. So,
> I did the following:
> - removed PDFLIB_API and PDFLIB_CALL (point 1 in my previous message)
> - replaced the L".." defines by one to the char version (point 2)

Yeah!
I did the 2 points above, like you... but I can't compile yet. Other
errors occurred.

> The result from h2pas is attached. What needs to be done:
> - add stdcall; behind all functions that had PDFLIB_API. Both in interface
> and implementation part.
> - if you are linking dynamically replace in the functions that had
> PDFLIB_CALL in the implementation part
>  begin
>    { You must implement this function }
>  end;
> with
>  external 'name of the lib';
> - as always, review the translation

Can you send the tetlib.h that you modified? With it I can run h2pas
again with others parameters, like external lib, stdcall, type
conversion, etc.

Thank you.

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


RE : RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Ludo Brands
Here you go,

Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Marcos
Douglas
Envoyé : mercredi 18 mai 2011 19:37
À : FPC-Pascal users discussions
Objet : Re: RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas


On Wed, May 18, 2011 at 1:28 PM, Ludo Brands  wrote:
> >From your question COM or header, I assumed you are only interested 
> >in
> windows. I also assume that you don't want to export functions 
> defiend. So, I did the following:
> - removed PDFLIB_API and PDFLIB_CALL (point 1 in my previous message)
> - replaced the L".." defines by one to the char version (point 2)

Yeah!
I did the 2 points above, like you... but I can't compile yet. Other errors
occurred.

> The result from h2pas is attached. What needs to be done:
> - add stdcall; behind all functions that had PDFLIB_API. Both in 
> interface and implementation part.
> - if you are linking dynamically replace in the functions that had 
> PDFLIB_CALL in the implementation part
>  begin
>    { You must implement this function }
>  end;
> with
>  external 'name of the lib';
> - as always, review the translation

Can you send the tetlib.h that you modified? With it I can run h2pas again
with others parameters, like external lib, stdcall, type conversion, etc.

Thank you.

Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
/*---*
 |  Copyright (c) 2002-2010 PDFlib GmbH. All rights reserved.|
 +---+
 |This software may not be copied or distributed except as expressly |
 |authorized by PDFlib GmbH's general license agreement or a custom  |
 |license agreement signed by PDFlib GmbH.   |
 |For more information about licensing please refer to www.pdflib.com.   |
 *---*/

/* $Id: tetlib.h,v 1.165.2.13 2011/01/31 13:20:32 rjs Exp $
 *
 * TET public function declarations
 *
 */

/*
 * --
 * Setup, mostly Windows calling conventions and DLL stuff
 * --
 */

#ifndef TETLIB_H
#define TETLIB_H

#include 
#include 

#if defined(WIN32) && !defined(PDFLIB_CALL)
#define PDFLIB_CALL __cdecl
#endif

#undef PDFLIB_API

#ifndef PDFLIB_CALL
#define PDFLIB_CALL /* */   /* default: no special calling conventions */
#endif

#ifndef PDFLIB_API
#define PDFLIB_API /* */ /* default: generate or use static library */
#endif

/* Make our declarations C++ compatible */
#ifdef __cplusplus
extern "C" {
#endif

/*
 * There's a redundant product name literal elsewhere that needs to be
 * changed with this one!
 */
#define IFILTER_PRODUCTNAME "TET PDF IFilter"
#define IFILTER_WCHAR_PRODUCTNAME IFILTER_PRODUCTNAME
#define IFILTER_PRODUCTDESCR"PDFlib TET PDF IFilter"
#define IFILTER_COPYRIGHT \
"(c) 2002-2010 PDFlib GmbH  www.pdflib.com  sa...@pdflib.com\n"

#define IFILTER_MAJORVERSION4
#define IFILTER_MINORVERSION0
#define IFILTER_REVISION0

/* Patched by the dist/ifilter/version.pl script */
#define IFILTER_SHORT_VERSIONSTRING "4"
#define IFILTER_WCHAR_SHORT_VERSIONSTRING   IFILTER_SHORT_VERSIONSTRING
#define IFILTER_LONG_VERSIONSTRING  "4.0p7"
#define IFILTER_WCHAR_LONG_VERSIONSTRINGIFILTER_WCHAR_LONG_VERSIONSTRING

#define TET_PRODUCTNAME "TET"
#define TET_PRODUCTDESCR"PDFlib Text Extraction Toolkit"
#define TET_COPYRIGHT \
"(c) 2002-2010 PDFlib GmbH  www.pdflib.com  sa...@pdflib.com\n"

#define TET_MAJORVERSION4
#define TET_MINORVERSION0
#define TET_REVISION0
/* ALWAYS change all version strings in the same way */
#define TET_SHORT_VERSIONSTRING  "4"
#define TET_WCHAR_SHORT_VERSIONSTRING   TET_SHORT_VERSIONSTRING
#define TET_LONG_VERSIONSTRING   "4.0p7"
#define TET_WCHAR_LONG_VERSIONSTRINGTET_LONG_VERSIONSTRING

/* Opaque data type for the TET context. */
#if !defined(TET) || defined(ACTIVEX)
typedef struct TET_s TET;
#endif

/* The API structure with function pointers. */
typedef struct TET_api_s TET_api;

/*
 * --
 * pCOS-specific enums and defines
 * --
 */

/*
 * Guard against multiple definition of pcos_mode and pcos_object_type for the
 * case that multiple PDFlib products are used in the same program.
 */
#ifndef PDF_PCOS_ENUMS

/* document access levels.
*/
typedef enum
{
pcos_mode_minimum= 0, /* encrypted doc (opened w/o password)  */
pcos_mode_

Re: RE : RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 2:43 PM, Ludo Brands  wrote:
>
> Here you go,

Now I can learn a bit more about C language, comparing your header
file with my (incomplete) header file.

Thanks,
Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


RE : RE : RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Ludo Brands
Remember, what I did was just educated "arm twisting" the input file so that
h2pas could understand the input and do the bulk of the work. There is still
quite some work to do after on the pp file. Some can be done from looking at
the header file only, others need a better knowledge of the API.

Ludo

-Message d'origine-
De : fpc-pascal-boun...@lists.freepascal.org
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Marcos
Douglas
Envoyé : mercredi 18 mai 2011 19:54
À : FPC-Pascal users discussions
Objet : Re: RE : RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas


On Wed, May 18, 2011 at 2:43 PM, Ludo Brands  wrote:
>
> Here you go,

Now I can learn a bit more about C language, comparing your header file with
my (incomplete) header file.

Thanks,
Marcos Douglas
___
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 : RE : RE : RE : [fpc-pascal] Re: PDFlib TET - convert using h2pas

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 3:12 PM, Ludo Brands  wrote:
>
> Remember, what I did was just educated "arm twisting" the input file so that
> h2pas could understand the input and do the bulk of the work. There is still
> quite some work to do after on the pp file. Some can be done from looking at
> the header file only, others need a better knowledge of the API.

Yes, I understand.

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


Re: RE : [fpc-pascal] Redirecting input to a child process

2011-05-18 Thread Anton Shepelev
A little update on the subject.

Ludo Brands wrote:

> If  you  run  'more'  in  a  cmd window you'll notice that
> 'more' echoes the input but only sends to  stdout  when  a
> return   is  entered.  I  modified  the  program  to  send
> 'Anton'#10 and the program reads back 'Anton'#10 from std-
> out.

After  fixing an error in my WinApi program, it is no longer
needed to terminate input with #10. Now that  the  write-end
of  the  child  process's  input handle is correctly closed,
more.com echoes whatever has been written to it requiring no
additional terminal symbols.

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


[fpc-pascal] Re: ERROR compile revision 17494 /fixes_2_4

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 4:24 PM, Marcos Douglas  wrote:
> Hi,
> I updated my FPC to revision 17494, a couple minutes ago.
> In attachment there is a log of erros.

In trunk is OK...
Can you help?

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


Re: [fpc-pascal] Re: ERROR compile revision 17494 /fixes_2_4

2011-05-18 Thread Marco van de Voort
In our previous episode, Marcos Douglas said:

> > I updated my FPC to revision 17494, a couple minutes ago.
> > In attachment there is a log of erros.
> 
> In trunk is OK...
> Can you help?

here is something wrong with your path statements, and a MAKE of a different
toolchain (Microsoft, borland) is found.

It is a problem with the installation of FPC, not the FPC checkout
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Re: ERROR compile revision 17494 /fixes_2_4

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 4:53 PM, Marco van de Voort  wrote:
>
> In our previous episode, Marcos Douglas said:
>
> > > I updated my FPC to revision 17494, a couple minutes ago.
> > > In attachment there is a log of erros.
> >
> > In trunk is OK...
> > Can you help?
>
> here is something wrong with your path statements, and a MAKE of a different
> toolchain (Microsoft, borland) is found.
>
> It is a problem with the installation of FPC, not the FPC checkout

OK, I will see that.
The trunk has the same BAT (just change version) but works.

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


Re: [fpc-pascal] Re: ERROR compile revision 17494 /fixes_2_4

2011-05-18 Thread Marcos Douglas
On Wed, May 18, 2011 at 4:57 PM, Marcos Douglas  wrote:
> On Wed, May 18, 2011 at 4:53 PM, Marco van de Voort  wrote:
>>
>> In our previous episode, Marcos Douglas said:
>>
>> > > I updated my FPC to revision 17494, a couple minutes ago.
>> > > In attachment there is a log of erros.
>> >
>> > In trunk is OK...
>> > Can you help?
>>
>> here is something wrong with your path statements, and a MAKE of a different
>> toolchain (Microsoft, borland) is found.
>>
>> It is a problem with the installation of FPC, not the FPC checkout
>
> OK, I will see that.
> The trunk has the same BAT (just change version) but works.

Sorry Marco, you're right.
Had an error in BAT. Below is the correct:
--
set myroot=%cd%
set myFPC=%myroot%\compiler\2.4.5
set mybinutils=%myroot%\binutils
set PATH=%myFPC%\bin\i386-win32;%PATH%
set PATH=%mybinutils%\i386-win32;%myFPC%\bin\i386-win32< this
line  >

cd %myFPC%
rd /s /q  %myfpc%\examples

make clean all install INSTALL_PREFIX=%myFPC% PP=%mybinutils%\ppc386.exe
--

Thanks for your time.

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


Re: [fpc-pascal] Redirecting input to a child process

2011-05-18 Thread Anton Shepelev
Ludo Brands:

> You can file a bug at http://bugs.freepascal.org/.

This is bug #0019325.

...
I thought about writing a patch, but it seems that it is not
enough to modify the implementation of the  Windows-specific
pipes.inc.

The correct way to create pipes for the three channels (out,
in and err) on Windows is to create non-inheritable  handles
and  duplicate  only  the  child process's ends of them into
inheritable ones, which  means  that  the  CreatePipeHandles
function  must accept a third parameter indicating which end
should be inherited: for OUT and ERR channels it will be the
write-end and for IN -- the read-end.

Here is a possible implementation:

{--- changes to pipes.inc -}
Interface
   {...}
   type
  TDupOpt  = (dupIn, dupOut);
  TDupOpts = Set of TDupOpt;

Implemenation
   {...}
   function DuplicateHandleFP(var handle: THandle): Boolean;
   var
  oldHandle: THandle;
   begin
  oldHandle := handle;
  Result := DuplicateHandle
  (  GetCurrentProcess(),
 oldHandle,
 GetCurrentProcess(),
 @handle,
 0,
 true,
 DUPLICATE_SAME_ACCESS
  );
  if Result then
 Result := CloseHandle(oldHandle);
   end;

   Function CreatePipeHandles
   (Var Inhandle,OutHandle : THandle; DupOpts: TDupOpts) : Boolean;
   begin
  Result := CreatePipe (Inhandle,OutHandle,@piNonInheritablePipe,0);
  if Result and (dupIn in DupOpts) then
 Result := DuplicateHandleFP(Inhandle);
  if Result and (dupOut in DupOpts) then
 Result := DuplicateHandleFP(OutHandle);
   end;

   {--- process.inc -}
   {CreatePipes will have these calls:}
   begin
 CreatePipeHandles(SI.hStdInput ,HI, [dupIn ]);
 CreatePipeHandles(HO,Si.hStdOutput, [dupOut]);
 if CE then
   CreatePipeHandles(HE,SI.hStdError, [dupOut])
   {...}

Unfortunately,  the third parameter will have to be added to
this  function  in  all  other  platform-specific  pipes.inc
files, but these will just ignore it and work as before.

If  it is preferable to keep the interface of the pipes unit
unchanged, the windows-specific part could just be chaged to
create  non-inheritable  pipes, and the duplication could be
moved into the windows-specific process.inc.

Will you accept one of such patches?

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


Re: [fpc-pascal] Redirecting input to a child process

2011-05-18 Thread Michael Van Canneyt



On Thu, 19 May 2011, Anton Shepelev wrote:


Ludo Brands:


You can file a bug at http://bugs.freepascal.org/.


This is bug #0019325.

...
I thought about writing a patch, but it seems that it is not
enough to modify the implementation of the  Windows-specific
pipes.inc.

The correct way to create pipes for the three channels (out,
in and err) on Windows is to create non-inheritable  handles
and  duplicate  only  the  child process's ends of them into
inheritable ones, which  means  that  the  CreatePipeHandles
function  must accept a third parameter indicating which end
should be inherited: for OUT and ERR channels it will be the
write-end and for IN -- the read-end.

Here is a possible implementation:

{--- changes to pipes.inc -}
Interface
  {...}
  type
 TDupOpt  = (dupIn, dupOut);
 TDupOpts = Set of TDupOpt;

Implemenation
  {...}
  function DuplicateHandleFP(var handle: THandle): Boolean;
  var
 oldHandle: THandle;
  begin
 oldHandle := handle;
 Result := DuplicateHandle
 (  GetCurrentProcess(),
oldHandle,
GetCurrentProcess(),
@handle,
0,
true,
DUPLICATE_SAME_ACCESS
 );
 if Result then
Result := CloseHandle(oldHandle);
  end;

  Function CreatePipeHandles
  (Var Inhandle,OutHandle : THandle; DupOpts: TDupOpts) : Boolean;
  begin
 Result := CreatePipe (Inhandle,OutHandle,@piNonInheritablePipe,0);
 if Result and (dupIn in DupOpts) then
Result := DuplicateHandleFP(Inhandle);
 if Result and (dupOut in DupOpts) then
Result := DuplicateHandleFP(OutHandle);
  end;

  {--- process.inc -}
  {CreatePipes will have these calls:}
  begin
CreatePipeHandles(SI.hStdInput ,HI, [dupIn ]);
CreatePipeHandles(HO,Si.hStdOutput, [dupOut]);
if CE then
  CreatePipeHandles(HE,SI.hStdError, [dupOut])
  {...}

Unfortunately,  the third parameter will have to be added to
this  function  in  all  other  platform-specific  pipes.inc
files, but these will just ignore it and work as before.

If  it is preferable to keep the interface of the pipes unit
unchanged, the windows-specific part could just be chaged to
create  non-inheritable  pipes, and the duplication could be
moved into the windows-specific process.inc.

Will you accept one of such patches?


Yes.

The interface of the pipes unit can be changed with a parameter with 
a default value, so existing code continues to work.


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


[fpc-pascal] 64 bit ?

2011-05-18 Thread Terry A. Haimann
I have a desktop with a 64bit AMD x4 Phenom processor.  I have noticed 
that FreePascal programs perform worse on this computer then they do on 
my 32 bit laptop.  Integer performance seems to be about 3 times worse 
then on the laptop.  Now if I convert the pascal source to c and compile 
that as follows:


gcc -O3 -funroll-all-loops -o MyExecutable MySource.c

The performance is many times better then with FreePascal.  I assume 
that gcc is compiling to 64 bit here and generating an optimizing for 
the AMD processor.  Is there a way to do something similar with Free Pascal?


Thanks,Terry

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


[fpc-pascal] DateTimeToFileDate

2011-05-18 Thread Carsten Bager
If I do this on a Linux machine

(Free Pascal Compiler version 2.4.2 [2010/11/08] for i386)

  WriteLn(DateTimeToFileDate(Now));
  WriteLn(trunc((now-EncodeDate(1970,1,1))*86400));

I get this
1305786833
1305794033

There is a difference of 7200= 2 hours. 

Is this correct?

I would not expect a difference of 2 hours (the deference from UTC).

Regards
Carsten

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