Re: [fpc-pascal] Happy tickets benchmark

2016-03-01 Thread Jeppe Johansen 

On 03/02/2016 12:48 AM, vfclists . wrote:



On 14 February 2016 at 10:06, Serguei TARASSOV > wrote:


Hello,

thank all for assistance!

Sorry, I was not clear, the series should be ran with all tests
_on the same computer_ regardless its hardware capacity and on the
_same OS_. That's why I cannot compare with Delphi.

So if you have modern Delphi, FPC and maybe .NET on your Windows
computer please compare them with about 5-10 runs to get average time.

Thank you for the Inc() hint, I added it to the comments, it gains
about 10% for me.
However, in Delphi Inc() is faster until you turn on the checking
overflow.

Another strange effect in FPC.
Only longint shows correct result. With the integer type the
optimizer seems to replace type with shortint (16-bits) and I see
31902 instead of 4816030.



Is there a reason for this, or is it a bug?
The Integer type depends on what compiler mode you are in, and what 
operating system. Sometimes it's 32bit and other times it's 16bit.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

2016-03-01 Thread vfclists . 
On 14 February 2016 at 10:06, Serguei TARASSOV  wrote:

> Hello,
>
> thank all for assistance!
>
> Sorry, I was not clear, the series should be ran with all tests _on the
> same computer_ regardless its hardware capacity and on the _same OS_.
> That's why I cannot compare with Delphi.
>
> So if you have modern Delphi, FPC and maybe .NET on your Windows computer
> please compare them with about 5-10 runs to get average time.
>
> Thank you for the Inc() hint, I added it to the comments, it gains about
> 10% for me.
> However, in Delphi Inc() is faster until you turn on the checking overflow.
>
> Another strange effect in FPC.
> Only longint shows correct result. With the integer type the optimizer
> seems to replace type with shortint (16-bits) and I see 31902 instead of
> 4816030.
>
>
>
Is there a reason for this, or is it a bug?


-- 
Frank Church

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

Re: [fpc-pascal] Wiki (image) uploading temporarily disabled

2016-03-01 Thread Jonas Maebe 

On 29/02/16 17:53, Jonas Maebe wrote:


The tech support scammers discovered that mediawiki's antispam regex
doesn't get applied to image descriptions, so they're now attacking us
that way. I hope to find a way to block this new attack angle tonight or
tomorrow, but until then I've disabled uploading to the wiki for now.


It's enabled again.


Jonas

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

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Constantine Yannakopoulos 
On Tue, Mar 1, 2016 at 3:59 PM, Mazola Winstrol 
wrote:

>
> Can you send me?
>

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

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Mazola Winstrol 
2016-03-01 10:07 GMT-03:00 Constantine Yannakopoulos :

>
> The only solution I have found is to implement ALL operators for
> TNullableType by defining a generic interface INullableOperatiors
> that contains methods for all operators, then implement for each type by
> means of manual interface implementation and then delegate each class
> operator implementation to the corresponding implementation using RTTI of
> the generic parameter T like in Delphi's Generics.Defaults and
> IComparer/IEqualityComparer. This way the implementation of an
> operator not supported for a specific type (e.g. negation for strings) will
> raise an exception.
>
> It's a rather tedious task though and I abandoned it half way and I'm sure
> Sven would object to such an implementation as it involves manual
> interfaces. I can send you the unfinished Delphi unit via private email if
> you want.
>
>

Can you send me?

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

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Constantine Yannakopoulos 
On Mon, Feb 29, 2016 at 5:13 PM, Mazola Winstrol 
wrote:

> I have noticed that, by using generics, we can't overload arithmetic
> operators.
>
> E.g.:
>
> ...
> class operator Negative(A: TNullableType): T;
> ...
>
> class operator TNullableType.Negative(A: TNullableType): T;
> begin
> Result := -1 * A;
> end;
> 
>
> wouldn't compile with the error "Operator not applicable to this operand
> type".
>
> Is there any workaround to overcome this?
>

The only solution I have found is to implement ALL operators for
TNullableType by defining a generic interface INullableOperatiors
that contains methods for all operators, then implement for each type by
means of manual interface implementation and then delegate each class
operator implementation to the corresponding implementation using RTTI of
the generic parameter T like in Delphi's Generics.Defaults and
IComparer/IEqualityComparer. This way the implementation of an
operator not supported for a specific type (e.g. negation for strings) will
raise an exception.

It's a rather tedious task though and I abandoned it half way and I'm sure
Sven would object to such an implementation as it involves manual
interfaces. I can send you the unfinished Delphi unit via private email if
you want.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Mazola Winstrol 
2016-03-01 1:48 GMT-03:00 :

> On 02/29/2016 10:08 PM, Mazola Winstrol wrote:
>
>> There is a problem in my design. The code won't compile if i try to
>> specialize with a type which doesn'y supports arithmetic operators e.g
>> String
>> types.
>>
>
> apparently i'm missing something... why should arithmetic operators be
> recognized for strings? that doesn't make sense? arithmetic operators are
> for numerics not strings...
>
>
The operator shouldn't be recognized for strings. The problem is that we
are using a generic record for defining a nullable type. So, we can't make
a subclass to define operators applicable only for numeric types.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Mazola Winstrol 
2016-03-01 9:13 GMT-03:00 Sven Barth :

> Am 01.03.2016 04:08 schrieb "Mazola Winstrol" :
> > Is there any way to overcome this? Is there any way to tell the compiler
> to ignore some operators depending on the specialization type?
>
> No, there is not. Better not use operators other than the assignment ones
> or provide different Nullable types for different purposes (that maybe can
> be assigned to each other).
>

The problem is type the same structures for the various nullable types.
Perhaps, a "ugly" solution would be:


= code =

{$mode delphi}

{$DEFINE typename:=TSimpleNullableType}
typename = record
strict private
   {$INCLUDE commonprivatedefinition.inc}
public
   {$INCLUDE commonprivatedefinition.inc}
end;

{$DEFINE typename:=TArithmeticNullableType}
typename = record
strict private
   {$INCLUDE commonprivatedefinition.inc}
public
   {$INCLUDE commonprivatedefinition.inc}
   class operator Negative(A: TArithmeticNullableType): T;
end;

 code ==

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

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Sven Barth 
Am 01.03.2016 04:08 schrieb "Mazola Winstrol" :
> Is there any way to overcome this? Is there any way to tell the compiler
to ignore some operators depending on the specialization type?

No, there is not. Better not use operators other than the assignment ones
or provide different Nullable types for different purposes (that maybe can
be assigned to each other).

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

Re: [fpc-pascal] Primitive Record Wrappers

2016-03-01 Thread Rainer Stratmann 
 On Wednesday 17 February 2016 18:40:52 you wrote:
> Hello list,
> 
> In some situations, would be very interesting to determine whether the
> value of a primitive variable is initialized or not. For example, fields in
> database records can contain null values. By implementing an ORM, it would
> be interesting to represent these null values in the properties of objects.
> 
> Java has the so called Primitives Class Wrappers, where each primitive type
> (int, boolean ...) has a corresponding wrapper class (Integer, Boolean
> ...). By using class wrappers you can represent null values in primitive
> types through null class instances references.
> 
> Using class wrappers in FPC is not feasible due to memory management issues
> (the programmer needs to worry about the lifetime of the instances and free
> the instances manually).
> 
> Perhaps, a solution in FPC would be using primitive record wrappers with
> custom records operators.
> 
> What do you think about it? Is there any other solution?
> 
> Regards 

I did not read everything. But it seems, that you want to have a function you 
also can program by yourself.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal