Re: [fpc-devel] Closures / anonymous methods
Am 26.10.2016 00:58 schrieb "Maciej Izak" : > Many users likes more modern Pascal (for example oxygene mode is also one of NewPascal targets), FPC core team likes more old fashioned Pascal... I do not believe that core team would accept oxygene mode/patch. Anyway... As long as it's really a separate mode (plus maybe modeswitches for selected features, that other modes might profit from) I don't see a problem with adding an Oxygene mode. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On Wed, 26 Oct 2016, Sven Barth wrote: Am 26.10.2016 00:58 schrieb "Maciej Izak" : Many users likes more modern Pascal (for example oxygene mode is also one of NewPascal targets), FPC core team likes more old fashioned Pascal... I do not believe that core team would accept oxygene mode/patch. Anyway... As long as it's really a separate mode (plus maybe modeswitches for selected features, that other modes might profit from) I don't see a problem with adding an Oxygene mode. Indeed. This is the reason modes were invented. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in passing WideString parameters to dispinterface function ?
FYI: Reported as bug #30792
I can simplify it by this demo program (only compileable not runable):
type
Tintf = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
function wStr(const str1: WideString; const str2: WideString):
Integer; dispid 3;
end;
function wStr(const str1: widestring; const str2: widestring): integer;
begin
writeln(str1, str2);
end;
function aStr(const str1, str2: AnsiString): integer;
var intf: Tintf;
begin
Result := wStr(str1, str2);
// wStr in this case HERE1 and HERE2 are diferent:
// movl $0x0,-0x3c(%ebp)
// lea-0x3c(%ebp),%edx <--- HERE1
// mov-0x8(%ebp),%eax
//call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea-0x40(%ebp),%edx <--- HERE2
//mov-0x4(%ebp),%eax
//call 0x405b50
Result := intf.wStr(str1, str2);
// wStr in this case HERE3 are equal:
// movl $0x0,-0x40(%ebp)
// lea -0x40(%ebp),%edx <--- HERE3
// mov-0x8(%ebp),%eax
// call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea -0x40(%ebp),%edx <--- HERE3
//mov-0x4(%ebp),%eax
//call 0x405b50
end;
var
as1, as2: AnsiString;
begin
as1 := 'abc';
as2 := 'def';
aStr(as1, as2);
end.
Hi,
look please at this. I have imported OCX type library which result in
pascal unit with "dispinterface" defined like this:
_DSamlight_client_ctrl_ocx = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
...
function ScChangeTextByName(const EntityName:WideString; const
Text_:WideString):Integer;dispid 3;
...
In my program I have another method which takes AnsiString parameters:
function TSamLightClient.ChangeTextByName(const Name, Text_:
AnsiString): boolean;
In this method I do nothing except, that I call COM object interface:
Result := FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
All seems to work, but OCX behaves like Name and Text_ params are equal!
When I look at assembler:
VyrobaLaser.pas:324 Result :=
FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
0042A986 bac8e15b00 mov$0x5be1c8,%edx
0042A98B 8d45b0 lea-0x50(%ebp),%eax
0042A98E e82d26feff call 0x40cfc0
0042A993 8d5da8 lea-0x58(%ebp),%ebx
0042A996 8d45a4 lea-0x5c(%ebp),%eax
0042A999 e8b2dafdff call 0x408450
0042A99E c745a4 movl $0x0,-0x5c(%ebp)
0042A9A5 8d55a4 lea-0x5c(%ebp),%edx
0042A9A8 8b45f8 mov-0x8(%ebp),%eax
0042A9AB e840dcfdff call 0x4085f0
0042A9B0 8b45a4 mov-0x5c(%ebp),%eax
0042A9B3 8903 mov%eax,(%ebx)
0042A9B5 8d5da8 lea-0x58(%ebp),%ebx
0042A9B8 83c304 add$0x4,%ebx
0042A9BB 8d45a4 lea-0x5c(%ebp),%eax
0042A9BE e88ddafdff call 0x408450
0042A9C3 c745a4 movl $0x0,-0x5c(%ebp)
0042A9CA 8d55a4 lea-0x5c(%ebp),%edx
0042A9CD 8b45fc mov-0x4(%ebp),%eax
0042A9D0 e81bdcfdff call 0x4085f0
0042A9D5 8b45a4 mov-0x5c(%ebp),%eax
0042A9D8 8903 mov%eax,(%ebx)
0042A9DA 8d45a8 lea-0x58(%ebp),%eax
0042A9DD 50 push %eax
0042A9DE b920365c00 mov$0x5c3620,%ecx
0042A9E3 8d45b0 lea-0x50(%ebp),%eax
0042A9E6 8b55f4 mov-0xc(%ebp),%edx
0042A9E9 8b5204 mov0x4(%edx),%edx
0042A9EC e8ff05feff call 0x40aff0
0042A9F1 8d45b0 lea-0x50(%ebp),%eax
0042A9F4 e8b71ffeff call 0x40c9b0
0042A9F9 83f801 cmp$0x1,%eax
It seems to me like there is used twice before
is called same address:
movl $0x0,-0x5c(%ebp)
lea-0x5c(%ebp),%edx
Isn't it wrong ? (I guess that it is address of any temporary local
variable used to store result of ansistr->widestr)
I can workaround this by using intermediate local variable:
var wText: WideString;
wText := Text_;
Result := FSamLightClientCtrl.ScChangeTextByName(Name, wText)=1; //
use wText instead of Text_
It is so in FPC 2.6.4 in FPC 3.0.0 is assembler different, but result
is still wrong.
Is it something known?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-26 11:56 GMT+02:00 Michael Van Canneyt : > As long as it's really a separate mode (plus maybe modeswitches for >> selected features, that other modes might profit from) I don't see a >> problem with adding an Oxygene mode. >> > > Indeed. This is the reason modes were invented. This is obvious. I won't touch the holy OBJFPC mode ;). Ever. I am worried about the speed of reviewing patches and integrations. For example: Management operators are key feature for many elements in Oxygene mode. Today I am 28 years old. I think that maybe before my 40th birthday FPC team decide to merging Management Operatos into trunk -,- . If Oxygene patch is next, which relay on MO... 80th birthday? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On Wed, 26 Oct 2016, Maciej Izak wrote: 2016-10-26 11:56 GMT+02:00 Michael Van Canneyt : As long as it's really a separate mode (plus maybe modeswitches for selected features, that other modes might profit from) I don't see a problem with adding an Oxygene mode. Indeed. This is the reason modes were invented. This is obvious. I won't touch the holy OBJFPC mode ;). Ever. I am worried about the speed of reviewing patches and integrations. For example: Management operators are key feature for many elements in Oxygene mode. Today I am 28 years old. I think that maybe before my 40th birthday FPC team decide to merging Management Operatos into trunk -,- . If Oxygene patch is next, which relay on MO... 80th birthday? I am happy to report that you are wrong. They are currently under discussion. Some valid concerns were raised. By the looks of it, they may be integrated before long. Please understand: Free Pascal is a team project. This means you cannot expect to have all patches integrated here-and-now. Specially when they are as invasive as yours. You are in essence converting pascal to a C++ clone with this MO patch. Is it so bad that this is discussed thoroughly first ? I understand your youthful impatience, just have a little more patience :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On Wed, Oct 26, 2016 at 12:48 PM, Michael Van Canneyt < mich...@freepascal.org> wrote: > > > On Wed, 26 Oct 2016, Maciej Izak wrote: > > 2016-10-26 11:56 GMT+02:00 Michael Van Canneyt : >> >> As long as it's really a separate mode (plus maybe modeswitches for >>> selected features, that other modes might profit from) I don't see a problem with adding an Oxygene mode. >>> Indeed. This is the reason modes were invented. >>> >> >> >> This is obvious. I won't touch the holy OBJFPC mode ;). Ever. I am >> worried about the speed of reviewing patches and integrations. For example: >> Management operators are key feature for many elements in Oxygene mode. >> Today I am 28 years old. I think that maybe before my 40th birthday FPC >> team decide to merging Management Operatos into trunk -,- . If Oxygene >> patch is next, which relay on MO... 80th birthday? >> > > > Specially when they are as invasive as yours. You are in essence > converting pascal to a C++ clone with this MO patch. Is it so bad that this > is discussed thoroughly first ? > > +1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and the next 10 years' Christmases rolled together! I disagree that modernizing Pascal is making it into a C++ clone. Why not take the best features of C++ while keeping Pascal readable? (FPC did that allready with I+=2, not that I'm arguing this is more readable. A better example would be ** vs. Power() - a no-brainer if you ask me, though I'd prefer ^ which was in Algol). Allowing EMB to dictate the future of Pascal is just wrong. Look what they've done with parallelism compared to Oxygene's clean (Pascal-like) approach. How is TParallel.For Pascallish? The difference seems to be that Pascal purists don't want to add keywords, while Oxygene adds many new keywords (eg. nullable, future, async, for parallel, is not, etc). And then for some flame-bait: I like declaring variables inside begin..end; ;-) To me it looks perfectly Pascallish if it starts with var.. and it is necessary anyway for duck typing, nullable types, etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On Wed, 26 Oct 2016, Paul van Helden wrote: Specially when they are as invasive as yours. You are in essence converting pascal to a C++ clone with this MO patch. Is it so bad that this is discussed thoroughly first ? +1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and the next 10 years' Christmases rolled together! I disagree that modernizing Pascal is making it into a C++ clone. It depends on how you do it. What is being introduced with management operators is RAII. (Resource Acquisition Is Initialization) This concept (using copy/clone constructors etc.) comes from C++. Javascript doesn't have it. Python also not (to my knowledge). And these are so-called 'modern' languages. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics: issue with double inline specialization
Am 25.10.2016 08:07 schrieb "Martok" : > Before submitting this to the bugtracker, 3 questions: does this look sane in > general? I'll try to take a look at it this weekend. But at work we're currently rather busy (shortly before a new release of our main software), so no promises though... (As I'd really like to have a relaxing weekend for once ;) ) > We reuse internalerror 200602061 as this is raised for the exact same > error cause, is this style okay or should it get a fresh number? Please use a new one. The idea of the internal errors is that the error location can be easily found even without a callstack. > To transform > the example project into a testsuite test, what would be required? If the bug report already has an example that should be fine, except you have other cases that aren't covered by that one. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
On 26.10.2016 13:33, Paul van Helden wrote: +1 for Oxygene mode. An Oxygene mode to me will be like early Christmas and the next 10 years' Christmases rolled together! Hmmm, Oxygene introduces several new concept. To me, parallel loops seem most interesting (and "modern" as modern multi-core chips can be decently used). But Oxygene can use the underlying Framework for the dirty work, while FPC would need to build the support (thread pool)for this completely new in the RTL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
