Am 01.12.2018 um 09:09 schrieb fpc-devel-requ...@lists.freepascal.org:
That sounds as if you have an implementation ready ?
If so, please submit a patch to the bugtracker. I'll evaluate it and
if it
is indeed simple, as you claim, I will apply the patch.
Michael.
Havent programmed it yet,
> On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel
> wrote:
>
> Please report as a bug.
I don’t get a bug on this in the trunk version I’m using. Maybe it was fixed?
Regards,
Ryan Joseph
___
fpc-devel maillist -
On Sat, December 1, 2018 22:24, Franz Müller wrote:
.
.
> BTW.: @ Tomas Hyjny: What made you think that I am not subscribed to the
> mailing list?
The fact that all your posts sent from the e-mail address used for sending
them (@focusdata.at) are held in the moderation queue waiting for
Hi,
The LLVM code generator is more or less ready, including Dwarf-EH-based
exception handling support. It's currently only supported on
Darwin/x86-64 and Linux/x86-64, but it can do a "make all" and the
testsuite can be finished as well. There are still some extra failures
that do not
Am Sa., 1. Dez. 2018, 08:44 hat Simon Jackson
geschrieben:
> GENERIC GHandle = CLASS
> PROTECTED
> it: Array [R] of T;
> FUNCTION readIt(p: R): T; VIRTUAL;
> PROCEDURE WriteIt(p: R; what: T); VIRTUAL;
> PUBLIC
> PROPERTY gimmeIt[p: R] READ ReadIt WRITE Writeit; DEFAULT; (* does this
> work? x.y
Am So., 2. Dez. 2018, 10:50 hat Ryan Joseph
geschrieben:
>
>
> > On Dec 2, 2018, at 4:00 PM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> >
> > Please report as a bug.
>
> I don’t get a bug on this in the trunk version I’m using. Maybe it was
> fixed?
>
Could be, I
Thanks for the feedback. Do you have a reproducible case, and does it
fail on Linux or Windows? I'll have a look for the infinite loops in the
meantime.
Gareth aka. Kit
On Sun 02/12/18 20:54 , "Marģers ." margers.ro...@inbox.lv sent:
> I've had problems testing it under Linux due to
That's interesting. Thanks for that. Time to get fixing.
In the meantime I'm also fixing up the buggy optimisation that caused the
original crash on Linux... nothing against the contributor, but it looks
like some badly-copied code from the MovXX routine... it even still
mentions "movsx" in the
Just an idea.
Class variables. If generics are used, then the same code can be used for
differing pointer types. (Classes) as long as a specifier on the "generic class
variable" and no generic specialize or <> is in the
class generic x: TObject;
Can it be shared across all generics of a kind?
> On Dec 3, 2018, at 6:33 AM, Simon Jackson wrote:
>
> Just an idea.
>
> Class variables. If generics are used, then the same code can be used for
> differing pointer types. (Classes) as long as a specifier on the "generic
> class variable" and no generic specialize or <> is in the
>
>
Am Mo., 3. Dez. 2018, 00:33 hat Simon Jackson
geschrieben:
> Just an idea.
>
> Class variables. If generics are used, then the same code can be used for
> differing pointer types. (Classes) as long as a specifier on the "generic
> class variable" and no generic specialize or <> is in the
>
>
> On Dec 2, 2018, at 5:26 PM, Jonas Maebe wrote:
>
>
> The LLVM code generator is more or less ready, including Dwarf-EH-based
> exception handling support. It's currently only supported on Darwin/x86-64
> and Linux/x86-64, but it can do a "make all" and the testsuite can be
> finished as
12 matches
Mail list logo
