Re: [fpc-pascal] How __FPC_specific_handler() is invoked
El mar., 24 jul. 2018 a las 13:57, Sven Barth via fpc-pascal (< fpc-pascal@lists.freepascal.org>) escribió: > Matias Vara schrieb am Di., 24. Juli 2018, 11:04: > >> Hello, >> >> I am writing my own __FPC_specific_handler() but I can't figure out when >> this function is registered. I guess this function is registered to the OS >> to be invoked when an exception happens. In the assembler code I have >> something like: >> >> .seh_handler __FPC_specific_handler,@unwind >> >> But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked >> > > To understand the .seh_*-pseudo instructions it's probably best to look at > their initial check-in in the GNU assembler: > https://sourceware.org/ml/binutils/2009-08/msg00193.html > > The handler function is invoked by Windows when an exception happens > inside the code that is governed by the surrounding (implicit) > .seh_(end)proc directives. > > Why are you writing your own handler? > > Thanks for the answer, I am trying to make work the exceptions handling in Toro kernel. Currently Toro is based on Win64 rtl. I think I will give up with the Win64 RTL and move to a simpler RTL. Matias > Regards, > Sven > >> ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How __FPC_specific_handler() is invoked
Matias Vara schrieb am Mi., 25. Juli 2018, 12:55: > > El mar., 24 jul. 2018 a las 13:57, Sven Barth via fpc-pascal (< > fpc-pascal@lists.freepascal.org>) escribió: > >> Matias Vara schrieb am Di., 24. Juli 2018, 11:04: >> >>> Hello, >>> >>> I am writing my own __FPC_specific_handler() but I can't figure out when >>> this function is registered. I guess this function is registered to the OS >>> to be invoked when an exception happens. In the assembler code I have >>> something like: >>> >>> .seh_handler __FPC_specific_handler,@unwind >>> >>> But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked >>> >> >> To understand the .seh_*-pseudo instructions it's probably best to look >> at their initial check-in in the GNU assembler: >> https://sourceware.org/ml/binutils/2009-08/msg00193.html >> >> The handler function is invoked by Windows when an exception happens >> inside the code that is governed by the surrounding (implicit) >> .seh_(end)proc directives. >> >> Why are you writing your own handler? >> >> > Thanks for the answer, I am trying to make work the exceptions handling in > Toro kernel. Currently Toro is based on Win64 rtl. I think I will give up > with the Win64 RTL and move to a simpler RTL. > I think I suggested some time ago already that you should use the embedded targets for writing a kernel. That's what they're there for after all. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How __FPC_specific_handler() is invoked
El mié., 25 jul. 2018 a las 14:33, Sven Barth via fpc-pascal (< fpc-pascal@lists.freepascal.org>) escribió: > Matias Vara schrieb am Mi., 25. Juli 2018, 12:55: > >> >> El mar., 24 jul. 2018 a las 13:57, Sven Barth via fpc-pascal (< >> fpc-pascal@lists.freepascal.org>) escribió: >> >>> Matias Vara schrieb am Di., 24. Juli 2018, >>> 11:04: >>> Hello, I am writing my own __FPC_specific_handler() but I can't figure out when this function is registered. I guess this function is registered to the OS to be invoked when an exception happens. In the assembler code I have something like: .seh_handler __FPC_specific_handler,@unwind But I am puzzled by "@unwind". How is __FPC_specific_handler() invoked >>> >>> To understand the .seh_*-pseudo instructions it's probably best to look >>> at their initial check-in in the GNU assembler: >>> https://sourceware.org/ml/binutils/2009-08/msg00193.html >>> >>> The handler function is invoked by Windows when an exception happens >>> inside the code that is governed by the surrounding (implicit) >>> .seh_(end)proc directives. >>> >>> Why are you writing your own handler? >>> >>> >> Thanks for the answer, I am trying to make work the exceptions handling >> in Toro kernel. Currently Toro is based on Win64 rtl. I think I will give >> up with the Win64 RTL and move to a simpler RTL. >> > > I think I suggested some time ago already that you should use the embedded > targets for writing a kernel. That's what they're there for after all. > > You are right but I was a bit strong headed. Thanks > Regards, > Sven > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Il 23/07/2018 18:11, Ryan Joseph ha scritto: The spirit of the language is really hard to define in my opinion. To the contrary, in an Open Source project, it is the easiest thing to define. It is what the core developers deem to be the spirit of the language. That's all. One should never forget what Open Source is: one or more persons, because of their personal motivations (fun, technical interest, altruism, egoistic desire to appear, whatever) decide to develop some software in their free time, without getting any money for that, and to share it with whomever is interested. One should understand that it is *their* toy, not *our* toy. We may suggest them to include new features, to modify existing ones, but to accept or to reject them it is just their choice. You cannot force them neither to spend their free time developing something they don't like, nor to accept a patch which in their judgement would taint their toy. It's as simple as that. Open Source however provides an easy way out. If they don't like it, but you do need it or just want it, you are free to implement whatever you like on top of the existing project. Then you may just keep it for your personal usage, or share it, giving rise to another OS project. That's what Maciej Izak has done with its NewPascal. If you don't know how to implement it, then you're in a worse situation, because you cannot judge the implications of what you request, which might require an effort not proportionate to the result, might conflict with a lot of other things, etc. etc. You have no other choice than to rely on core developers' judgement. For those reasons I believe that this thread has become too long, and that it would be reasonable to end it. Just my 2 cents. Giuliano -- Do not do unto others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Generics - extending TFPGObjectList
Hello,
I needed to extend TFPGObjectList and I found two wierd things (FPC 3.1.1
r39507):
program project1;
{$mode objfpc}{$H+}
uses
Classes, FGL;
type
TBaseClass = class (TObject)
end;
TIDClass = class (TBaseClass)
ID: Integer;
end;
TNameIDClass = class (TIDClass)
Name: string;
end;
generic TFPGObjectListEx = class (specialize
TFPGObjectList) //1 A
function GetItemByID(AID: Integer): T;
end;
TNameIDList = class (specialize TFPGObjectListEx)
end;
{$R *.res}
function TFPGObjectListEx.GetItemByID(AID: Integer): T;
begin
{...}
Result:=nil; //2
end;
var NameIDList: TNameIDList;
NameID: TNameIDClass;
begin
NameID:=NameIDList.Items[0]; //1 B
end.
The demo does not compile because of two errors:
1) project1.lpr(38,21) Error: Incompatible types: got "TBaseClass" expected
"TNameIDClass" at comment //1 B
It is caused by declaration at //1 A. Class TFPGObjectListEx can be really
generic only if it is declared like this:
generic TFPGObjectListEx = class (specialize TFPGObjectList) //1
A, otherwise you must retype TNameIDClass(Items[0]) and it is against the philosophy of generics.
Isn't it meaningless? Why there must be specialize to when in fact it is no
specialization at all.
2) project1.lpr(32,11) Error: Incompatible types: got "Pointer" expected
"$gendef4" at comment //2
The line must be changed to
Result:=T(nil);
which seems bizarre to me, I've never seen retyping "nil". Even more, both TFPGObjectList and
TFPGObjectListEx are constrained to TObject and to TIDClass so there is safety, TFPGObjectListEx can be only
specialized with types that have "nil" ( can never be , for example).
Thanks,
Vojtěch.
PS: The demo crashes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics - extending TFPGObjectList
Am 26.07.2018 um 02:31 schrieb Vojtěch Čihák:
Hello,
I needed to extend TFPGObjectList and I found two wierd things (FPC
3.1.1 r39507):
program project1;
{$mode objfpc}{$H+}
uses
Classes, FGL;
type
TBaseClass = class (TObject)
end;
TIDClass = class (TBaseClass)
ID: Integer;
end;
TNameIDClass = class (TIDClass)
Name: string;
end;
generic TFPGObjectListEx = class (specialize
TFPGObjectList) //1 A
function GetItemByID(AID: Integer): T;
end;
TNameIDList = class (specialize TFPGObjectListEx)
end;
{$R *.res}
function TFPGObjectListEx.GetItemByID(AID: Integer): T;
begin
{...}
Result:=nil; //2
end;
var NameIDList: TNameIDList;
NameID: TNameIDClass;
begin
NameID:=NameIDList.Items[0]; //1 B
end.
The demo does not compile because of two errors:
1) project1.lpr(38,21) Error: Incompatible types: got "TBaseClass"
expected "TNameIDClass" at comment //1 B
It is caused by declaration at //1 A. Class TFPGObjectListEx can be
really generic only if it is declared like this:
generic TFPGObjectListEx = class (specialize
TFPGObjectList) //1 A, otherwise you must retype
TNameIDClass(Items[0]) and it is against the philosophy of generics.
Isn't it meaningless? Why there must be specialize to when in fact
it is no specialization at all.
You are not overriding the Items property, thus it will still be the
Items property of TFPGObjectList and thus the compiler will
rightfully complain at location 1 B. Using generics does not absolve you
from usual inheritance problems.
2) project1.lpr(32,11) Error: Incompatible types: got "Pointer"
expected "$gendef4" at comment //2
The line must be changed to
Result:=T(nil);
which seems bizarre to me, I've never seen retyping "nil". Even more,
both TFPGObjectList and TFPGObjectListEx are constrained to TObject
and to TIDClass so there is safety, TFPGObjectListEx can be only
specialized with types that have "nil" ( can never be ,
for example).
Well, no one said that the generics are completely bug free...
Especially in special situations that involve either Nil or type
constraints (or in this case both). Please provide a simple example and
open a bug report.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
