On 02/02/2020 04:22, fredvs via fpc-pascal wrote:
Hello everybody.
Good time to go back with that problem and fix it forever the right way!
The problem is isolated and is fixed "hardcoded".
From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
t
Hello everybody.
Good time to go back with that problem and fix it forever the right way!
The problem is isolated and is fixed "hardcoded".
From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
the result is always = 0.
This function is used in ad
Of course precedence of the operator also must be informed by the operator
author to the compiler in some ways. Operator has different purpose and
workflow from function/method. If not, then everything can be just a method, no
operator needed.
However, if this is not practically possible in FPC,
Why doesn't this compile? IClassName2 descends from IClassName1 so shouldn't
TClassName be compatible with IClassName1?
{$mode objfpc}
{$interfaces corba}
program test;
type
IClassName1 = interface
end;
IClassName2 = interface(IClassName1)
end;
Mr Bee via fpc-pascal schrieb am So., 2.
Feb. 2020, 02:11:
> Hi all,
>
> Besides overloading available operators, could we make our own custom
> operator(s) in FPC?
>
> For example, I want to use ∑ to sum array values? Also other Unicode
> characters such as ≥, ≤, ±, ≠, etc as custom operators? I
Hi all,
Besides overloading available operators, could we make our own custom
operator(s) in FPC?
For example, I want to use ∑ to sum array values? Also other Unicode characters
such as ≥, ≤, ±, ≠, etc as custom operators? I think such feature is important
in this unicode era.
Is it possible?
Th
Hello Michael,
as the bugtracker is still not reachable, I'll send you my patch via the
mailing list.
As you suggested, there is a new option jroIgnoreExtraFields to ignore
extra fields in the parameter objets.
Objects in arrays are now validated against ParamDefs the same way a
single object is
Agreed, the rtl should definitely divide by pagesize if MMAP2 is defined. I've run into this discrepancy before on ARM at work Original message From: Jonas Maebe Date: Sat, 1 Feb 2020, 17:46To: Fabio Luis Girardi via fpc-pascal Subject: Re: [fpc-pascal] fpmmap arm-linux issueOn 31/
Ok. I'll fill out a bug report.
Em Sáb, 1 de fev de 2020 13:47, Jonas Maebe escreveu:
> On 31/01/2020 22:17, Fabio Luis Girardi via fpc-pascal wrote:
> > In C:
> >
> > CM_BaseAddr = mmap(NULL, 0x4000, PROT_READ | PROT_WRITE,
> > MAP_SHARED, devmemfd, *0x44e0*);
> >
> > to get the "s
On 31/01/2020 22:17, Fabio Luis Girardi via fpc-pascal wrote:
> In C:
>
> CM_BaseAddr = mmap(NULL, 0x4000, PROT_READ | PROT_WRITE,
> MAP_SHARED, devmemfd, *0x44e0*);
>
> to get the "same" code working in FPC I have to change some constants.
>
> CM_BaseAddr := Fpmmap
10 matches
Mail list logo
