Re: [fpc-pascal] Implicit Operator Overloading

2016-03-06 Thread Sven Barth
Am 06.03.2016 22:09 schrieb "Mazola Winstrol" :
>
> Hello,
>
> Fpc: 3.0
>
> Should the compiler to allow the definition of two operator overloading
with the same parameters and diferent result types?
>
> e.g:
>
>  code 
>
>   TMyRecord record
>  class operator Implicit(A: TMyRecord): Real;
>  class operator Implicit(A: TMyRecord): Integer;
>   end;
>
>  end 
>
> The code above doesn't compile. Error: function is already declared
Public/Forward operator.

Would you please test with trunk? I thought I had fixed that... If it
doesn't work there either then please report as well.

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

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

2016-03-06 Thread Mazola Winstrol
2016-03-06 19:48 GMT-03:00 Mazola Winstrol :


> Done. Issued as #0029792. 
>
>
The link is wrong. =)

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

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

2016-03-06 Thread Mazola Winstrol
2016-03-06 17:45 GMT-03:00 Sven Barth :

> Yes, that's a bug. Please report.
>
> Regards,
> Sven
>
>
Done. Issued as #0029792. 

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

[fpc-pascal] Implicit Operator Overloading

2016-03-06 Thread Mazola Winstrol
Hello,

Fpc: 3.0

Should the compiler to allow the definition of two operator overloading
with the same parameters and diferent result types?

e.g:

 code 

  TMyRecord record
 class operator Implicit(A: TMyRecord): Real;
 class operator Implicit(A: TMyRecord): Integer;
  end;

 end 

The code above doesn't compile. Error: function is already declared
Public/Forward operator.


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

Re: [fpc-pascal] Fpc Bug: Type specialization with Generics and Operator Overloading in Diferent Units

2016-03-06 Thread Sven Barth
Am 06.03.2016 19:55 schrieb "Mazola Winstrol" :
>
> Hello,
>
> Fpc version: 3.0 (the same included with lazarus 1.6).
>
>
> Please confirm if it is a bug:
>
> If i declare a generic record with overloaded add operation, i need to
specialize the type in the same unit for the compiler recognize the
overloading.

Yes that's a bug, maybe even the same as the other one. Please report
nevertheless, but please test the examples you post, as nowhere
"NullableInteger" is declared (I know what you meant, but when hunting bugs
I don't want to hunt bugs in the example code as well).

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

Re: [fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

2016-03-06 Thread Sven Barth
Am 06.03.2016 19:42 schrieb "Mazola Winstrol" :
>
> Hello,
>
> Fpc version: 3.0 (the one included with Lazarus 1.6).
>
> Please confirm if it is a bug: it seems the compiler doesn't handle
operator overloading properly when using generic record with local
specializations.

Yes, that's a bug. Please report.

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

Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

2016-03-06 Thread Sven Barth
Am 06.03.2016 17:00 schrieb "Serguei TARASSOV" :
> >> So in my taste the {$MODE DELPHI} should have been support not only
> >> language
> >> features but all common libraries too, at least RTL/DB. All FPC
> >> extension/modifications could be added in FPC mode. Not easy but
> >> reliable.
> >
> > It's simply not possible as long as you allow to mix modes on a per-unit
> > basis.
> >
> > I have said it before:
> > {$MODE XYZ} says something about available language constructs when
> > compiling. Not about available identifiers in units that you use.
> > This is a fundamental difference.
> >
> > Not to mention the maintenance nightmare 2 sets of units would present
us
> > with.
> >
> > Michael.
>
> {$MODE DELPHI} could switch to {$IFDEF DELPHI} conditional compilation or
> something similar with the defines corresponding of Delphi compiler
version
> compatibility, i.e. D15 or so.
> I see that supporting two version of units is hard much less the units
> interfaces was never copied from earlies version of Delphi AFAIK. It's a
> little easier when starting from fork.
> Actually I should support D7/FPC and XE10 compilation of few dozen units
and
> and despite the fact that they started with a fork it's not easy at all.

You can't influence precompiled units. Also I wouldn't even remotely want
to maintain such a mess.

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

[fpc-pascal] Fpc Bug: Type specialization with Generics and Operator Overloading in Diferent Units

2016-03-06 Thread Mazola Winstrol
Hello,

Fpc version: 3.0 (the same included with lazarus 1.6).


Please confirm if it is a bug:

If i declare a generic record with overloaded add operation, i need to
specialize the type in the same unit for the compiler recognize the
overloading.

=== Code ===

unit MyRecordDefinition;

{$mode delphi}

interface

type
  TMyRecord = record
 class operator Add(A,B: TMyRecord): TMyRecord;
  end;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin

end;

end.

..


Unit MyRecordSpecialization;

{$mode delphi}

interface

uses
  MyRecordDefinition;

type
  TInteger = TMyRecord;

implementation

procedure TestIfCompiles;
var
  N1, N2: NullableInteger;
begin
  N1 := N2 + N2; // DOESN'T COMPILE: Operator is not overloaded: TMyRecord
+ TMyRecord
end;


end.


 END 



To get this code compiled, i need to move the specialized type TInteger to
the same unit where the generic type TMyRecord is declared.



 code ===

unit MyRecordDefinition;

{$mode delphi}

interface

type
  TMyRecord = record
 class operator Add(A,B: TMyRecord): TMyRecord;
  end;

  TInteger = TMyRecord;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin

end;

end.

..


Unit MyRecordSpecialization;

{$mode delphi}

interface

uses
  MyRecordDefinition;

implementation

procedure TestIfCompiles;
var
  N1, N2: NullableInteger;
begin
  N1 := N2 + N2; // DOESN'T COMPILE: Operator is not overloaded: TMyRecord
+ TMyRecord
end;


end.


=== END 


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

[fpc-pascal] Fpc Bug 3.0: Generics and Operator Overloading

2016-03-06 Thread Mazola Winstrol
Hello,

Fpc version: 3.0 (the one included with Lazarus 1.6).

Please confirm if it is a bug: it seems the compiler doesn't handle
operator overloading properly when using generic record with local
specializations.


= Code =

unit Test;

{$mode delphi}

type
  TMyRecord = record
class operator Add(A,B: TMyRecord): TMyRecord;
  end;

implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin
// add implementation
end;


procedure TestIfCompiles;
type
  TInteger = TMyRecord;
var
  N1, N2: TInteger;
begin
  N1 := N2 + N2;  /// DOES NOT COMPILE: Operator is not overloaded:
TMyRecord + TMyRecord
end;

 END =



To compile this code, move the declarion of the type TInteger to the global
scope, as follows:



= Code =

unit Test;

{$mode delphi}

type
  TMyRecord = record
class operator Add(A,B: TMyRecord): TMyRecord;
  end;

   TInteger = TMyRecord;


implementation

class operator TMyRecord.Add(A,B: TMyRecord): TMyRecord;
begin
// add implementation
end;


procedure TestIfCompiles;
var
  N1, N2: TInteger;
begin
  N1 := N2 + N2;
end;

 END =


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

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Bls: Bug in FPC 3.0.0

2016-03-06 Thread Jürgen Hestermann

Am 2016-03-06 um 17:00 schrieb Serguei TARASSOV:
> You're right there are many language specific forums but English 
became these
> standard "in fact". I see the trend of last 10 years when Russian 
developers

> who lived in Russia write yours blogs in English only.
> Sad but c'est la vie...

Why is this sad?

I like it that there is meanwhile a common sense
about which language to use as an international language
and that more and more people all over the planet
know at least a little bit English so that I can
communicate with them.

I would even vote for dropping other foreign languages at school
and invest the saved time to improve English.
This way a global communication will become much easier.
Those who like other languages can learn them in their spare time
if they want and have talent but it should not be forced on everybody.

If the audience is restricted to one country only then of course the
native language of these people can/should be used.
But with globalisation this becomes more and more unlikely.

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


Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

2016-03-06 Thread Serguei TARASSOV
Michael Van Canneyt wrote
> Tut ti vibral plohoi primer, po-moemu... :)
> 
> A bad example. Plenty of language-specific forums exist. 
> They live, and no-one denies them their existence.

Ты прав, есть много локализованных форумов, но...
You're right there are many language specific forums but English became the
standard "in fact". I see the trend of last 10 years when Russian developers
who lived in Russia write yours blogs in English only.
Sad but c'est la vie...


>> So in my taste the {$MODE DELPHI} should have been support not only
>> language
>> features but all common libraries too, at least RTL/DB. All FPC
>> extension/modifications could be added in FPC mode. Not easy but
>> reliable.
> 
> It's simply not possible as long as you allow to mix modes on a per-unit
> basis.
> 
> I have said it before:
> {$MODE XYZ} says something about available language constructs when
> compiling. Not about available identifiers in units that you use.
> This is a fundamental difference.
> 
> Not to mention the maintenance nightmare 2 sets of units would present us
> with.
> 
> Michael.

{$MODE DELPHI} could switch to {$IFDEF DELPHI} conditional compilation or
something similar with the defines corresponding of Delphi compiler version
compatibility, i.e. D15 or so.
I see that supporting two version of units is hard much less the units
interfaces was never copied from earlies version of Delphi AFAIK. It's a
little easier when starting from fork.
Actually I should support D7/FPC and XE10 compilation of few dozen units and
and despite the fact that they started with a fork it's not easy at all.



-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724463.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] How do I test the testfppdf on Windows?

2016-03-06 Thread Luca Olivetti

El 06/03/16 a les 10:15, Michael Van Canneyt ha escrit:


Strange, because if I recall correctly it was tested with Cyrillic, and
that worked ?


Later I will try with other readers.


Please do, I'd welcome any hints as to what could be wrong !

(evince is one of the readers that was used to test, BTW)


With okular I see this at the bottom of the first page


http://ctrlv.in/722862


These are the details of my okular:
versió 0.23.2
S'utilitza la «KDE Development Platform» 4.14.15

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


Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

2016-03-06 Thread Michael Van Canneyt



On Sun, 6 Mar 2016, Serguei TARASSOV wrote:


I don't blame someone at all.
My point is only the regret about the absent of standards on the language
and common libraries like in C/C++.
When there is no standards in law "de jure", the most popular implementation
becomes the "standard" in fact. I suppose, that Delphi is the standard in
fact the last 15 years because of the large community and the large
developers base (1M at least).

The same reason we use English in mailing lists but not French or Russian
regardless the wide Russian Delphi community.


Tut ti vibral plohoi primer, po-moemu... :)

A bad example. Plenty of language-specific forums exist. 
They live, and no-one denies them their existence.



So in my taste the {$MODE DELPHI} should have been support not only language
features but all common libraries too, at least RTL/DB. All FPC
extension/modifications could be added in FPC mode. Not easy but reliable.


It's simply not possible as long as you allow to mix modes on a per-unit basis.

I have said it before:
{$MODE XYZ} says something about available language constructs when
compiling. Not about available identifiers in units that you use.
This is a fundamental difference.

Not to mention the maintenance nightmare 2 sets of units would present us with.

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


Re: [fpc-pascal] Bls: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

2016-03-06 Thread Serguei TARASSOV
Michael Van Canneyt wrote
>> The Delphi way is less poor but both are risky.
> Oh, why is that ?

I.e. because of third-party frameworks.
When programmer stays with FPC and its libraries only, the support and the
compatibility are not a big problem (but some libraries become abandoned or
some bugs stay in state "fix it yourself"). For "real world programs" many
third-party frameworks are used and even the source code doesn't solve the
problem. The case with UniDAC is in the start of this topic but we have
about 20 other third-party libraries in our codebase. Any responsible
engineer should minimize such technical risks.
So the Delphi way is a less risky IMO.


>> The absence of standards is the most weak point of Object Pascal/Delphi
>> and
>> its "standard" libraries.
> We could not be more in agreement.
> 
> However, I wish to point out that FPC here is always in the disadvantage:
> 
> Borland/Inprise/Embarcadero/Idera has consistently denied to cooperate on
> this. 
> (whether or not this is a company policy, or because they simply ignore
> us, I do not know).
> 
> When FPC implemented a language feature first, they later implemented it
> differently.
> 
> To give an example:
> When Jonas designed the objective C classes for Mac OS X, he explicitly
> mailed them to ask
> what they were going to do. He got a noncommittal answer.
> 
> By contrast, when we implement a feature that Delphi has, we always
> implement it in a 
> compatible way in $MODE Delphi. 
> When doing base classes, we make sure that we provide all identifiers that
> Delphi 
> provides, so your code compiles.
> 
> If someone reports a missing identifier, we always attempt to implement
> it.
> 
> I don't see what we can do more ?

I don't blame someone at all.
My point is only the regret about the absent of standards on the language
and common libraries like in C/C++.
When there is no standards in law "de jure", the most popular implementation
becomes the "standard" in fact. I suppose, that Delphi is the standard in
fact the last 15 years because of the large community and the large
developers base (1M at least).

The same reason we use English in mailing lists but not French or Russian
regardless the wide Russian Delphi community.

So in my taste the {$MODE DELPHI} should have been support not only language
features but all common libraries too, at least RTL/DB. All FPC
extension/modifications could be added in FPC mode. Not easy but reliable.




-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724460.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] How do I test the testfppdf on Windows?

2016-03-06 Thread Michael Van Canneyt



On Sat, 5 Mar 2016, silvioprog wrote:



Hm. This is strange, the code does not use interfaces at all.
The compilation hints/warnings do not really present me with a hint as to
what could be wrong.



Attached patch to fix warns/hints. (need to test it with FPC 2.6, I tested
only in 3.0)


Applied in rev. 33176. 
I added a fix for 2.6 compilation: no Default() intrinsic.


Thanks for the patch.

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


Re: [fpc-pascal] How do I test the testfppdf on Windows?

2016-03-06 Thread Michael Van Canneyt



On Sun, 6 Mar 2016, Graeme Geldenhuys wrote:


On 05/03/2016 19:30, silvioprog wrote:

Attached patch to fix warns/hints. (need to test it with FPC 2.6, I
tested only in 3.0)


Incidently, fppdf was only developed and tested with FPC 2.6.4 (FPC 3.0 was 
never used).


I did some fixes for 3.0 prior to committing, and the test suites ran fine 
after that.

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


Re: [fpc-pascal] How do I test the testfppdf on Windows?

2016-03-06 Thread Graeme Geldenhuys

On 05/03/2016 19:30, silvioprog wrote:

Attached patch to fix warns/hints. (need to test it with FPC 2.6, I
tested only in 3.0)


Incidently, fppdf was only developed and tested with FPC 2.6.4 (FPC 3.0 
was never used).



Regards,
  Graeme

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


Re: [fpc-pascal] How do I test the testfppdf on Windows?

2016-03-06 Thread Michael Van Canneyt



On Sat, 5 Mar 2016, Jesus Reyes A. wrote:

On Sat, 05 Mar 2016 14:03:49 -0600, Michael Van Canneyt 
 wrote:




This is what I get with the normal test font:
http://www.freepascal.org/~michael/test.pdf

Can you please try with the original font too, please ?
(freesans is freely available)

If that works, it would mean there is something wrong with the Arial font 
handling.


Michael.


your file looks like the one I produced here when using "Visor de documentos" 
which happen to be evince, this is what it looks http://ctrlv.in/722669 the 
only change I did was adding JRAXX at the end of every P.WriteText'd string 
where XX is the index of each instance. Seems only latin text is working.


Strange, because if I recall correctly it was tested with Cyrillic, and that 
worked ?


Later I will try with other readers.


Please do, I'd welcome any hints as to what could be wrong !

(evince is one of the readers that was used to test, BTW)

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


Re: [fpc-pascal] How do I test the testfppdf on Windows?

2016-03-06 Thread Graeme Geldenhuys

On 05/03/2016 20:30, silvioprog wrote:

"The font 'Times' contains a bad /BBox."

Can you please try with the original font too, please ?
(freesans is freely available)


Yes. Do you downloaded it from
http://ftp.gnu.org/gnu/freefont/freefont-ttf.zip ?

If so, even using this file above I get same problem (Windows 7 64
bits). :-/


I don't have the code with me so can't check now. But if the issue is 
with Times related text, then FreeFont-ttf.zip should have nothing to do 
with the issue you are experiencing. From memory, the FreeFont font is 
used for the Unicode text only.


I'll take a look on my return in a week's time (if Michael doesn't beat 
me to it). I'll retest with the latest Adobe Reader - clearly it is more 
strict than older Adobe Reader versions.


If anybody knows of a online PDF validator (not a PDF Achive format 
validator), that would help a huge amount.


Regards,
  Graeme

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


Re: [fpc-pascal] Bitcounting

2016-03-06 Thread David W Noon
On Sat, 5 Mar 2016 19:03:24 +0100, Bart (bartjun...@gmail.com) wrote
about "[fpc-pascal] Bitcounting" (in
):

> Does FreePascal have a routine for counting bits?
[snip]
> Surely this can be done better?

If you don't mind a bit of C, attached is what I use. It is blazingly
fast compared to examining each bit.

It uses ASCIIZ strings, but can easily be converted to Pascal and
AnsiStrings (or whatever). However, I'll leave that to you.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
#ifndef BIT_COUNT_H_INCLUDED
#define BIT_COUNT_H_INCLUDED

/* Functions to count how many 1-bits or 0-bits are in a buffer area.
 *
 * Copyright (C) 2015, David W. Noon.  All rights reserved.
 * This code is released under the Berkeley License.
 *
 */

#ifdef __cplusplus
#include 
#include  /* Requires C++11 or later. */
#else
#include 
#include  /* Requires C99 or later. */
#endif

/* Function to count the number of 1 bits in a buffer. */
static uint32_t count_ones(const void * buffer, size_t bytes_count)
{
	static const uint8_t ONES[256] = {
			0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4,
			1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
			1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
			1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
			2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
			3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
			3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
			4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8 };
	uint32_t result = 0U;
#ifdef __cplusplus
	const uint8_t * byte_ptr = reinterpret_cast(buffer);
#else
	const uint8_t * byte_ptr = (const uint8_t *) buffer;
#endif

	for (size_t ctr = bytes_count; ctr > 0; --ctr)
	{
		result += ONES[*byte_ptr];
		++byte_ptr;
	}

	return result;
}

/* Function to count the number of 0 bits in a buffer. */
static uint32_t count_zeroes(const void * buffer, size_t bytes_count)
{
	static const uint8_t ZEROES[256] = {
			8, 7, 7, 6, 7, 6, 6, 5, 7, 6, 6, 5, 6, 5, 5, 4,
			7, 6, 6, 5, 6, 5, 5, 4, 6, 5, 5, 4, 5, 4, 4, 3,
			7, 6, 6, 5, 6, 5, 5, 4, 6, 5, 5, 4, 5, 4, 4, 3,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			7, 6, 6, 5, 6, 5, 5, 4, 6, 5, 5, 4, 5, 4, 4, 3,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			5, 4, 4, 3, 4, 3, 3, 2, 4, 3, 3, 2, 3, 2, 2, 1,
			7, 6, 6, 5, 6, 5, 5, 4, 6, 5, 5, 4, 5, 4, 4, 3,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			5, 4, 4, 3, 4, 3, 3, 2, 4, 3, 3, 2, 3, 2, 2, 1,
			6, 5, 5, 4, 5, 4, 4, 3, 5, 4, 4, 3, 4, 3, 3, 2,
			5, 4, 4, 3, 4, 3, 3, 2, 4, 3, 3, 2, 3, 2, 2, 1,
			5, 4, 4, 3, 4, 3, 3, 2, 4, 3, 3, 2, 3, 2, 2, 1,
			4, 3, 3, 2, 3, 2, 2, 1, 3, 2, 2, 1, 2, 1, 1, 0 };
	uint32_t result = 0U;
#ifdef __cplusplus
	const uint8_t * byte_ptr = reinterpret_cast(buffer);
#else
	const uint8_t * byte_ptr = (const uint8_t *) buffer;
#endif

	for (size_t ctr = bytes_count; ctr > 0; --ctr)
	{
		result += ZEROES[*byte_ptr];
		++byte_ptr;
	}

	return result;
}
#endif /* BIT_COUNT_H_INCLUDED */
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How do I test the testfppdf on Windows?

2016-03-06 Thread Jesus Reyes A.
On Sat, 05 Mar 2016 14:03:49 -0600, Michael Van Canneyt  
 wrote:




This is what I get with the normal test font:
http://www.freepascal.org/~michael/test.pdf

Can you please try with the original font too, please ?
(freesans is freely available)

If that works, it would mean there is something wrong with the Arial  
font handling.


Michael.


your file looks like the one I produced here when using "Visor de  
documentos" which happen to be evince, this is what it looks  
http://ctrlv.in/722669 the only change I did was adding JRAXX at the end  
of every P.WriteText'd string where XX is the index of each instance.  
Seems only latin text is working.


Later I will try with other readers.

Jesus Reyes A.


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


Re: [fpc-pascal] Bitcounting

2016-03-06 Thread Jesus Reyes A.

En Sat, 05 Mar 2016 12:03:24 -0600, Bart  escribió:


Hi,

Does FreePascal have a routine for counting bits?
So that e.g. BitCount(%100110011) gives 5 (number of bits that are  
1)?


I came up with (extracted from IntToBin()):

function BitCount(N: Int64): Integer;
var
  Q: QWord;
  i: Integer;
begin
  Result := 0;
  Q := QWord(N);
  for i := 0 to (8 * SizeOf(N) - 1) do
  begin
if ((Q and 1) = 1) then Inc(Result);
Q := Q shr 1;
  end;
end;

Surely this can be done better?

Bart



function BitCount(N: Int64): Integer;
var
  i: Integer;
begin
  Result := 0;
  if N=0 then
exit;
  for i := 0 to (8 * SizeOf(N) - 1) do
  begin
if (N and (1 shl i)) <> 0 then Inc(result);
  end;
end;

not tested :D

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