Re: [fpc-devel] Closures / anonymous methods

2016-10-25 Thread Maciej Izak 
2016-10-26 0:03 GMT+02:00 :

> Now you have me confused.
> I thought you wanted to "take over" acceptance of this into FPC and doing
> further improvements.
> What is this NewPascal? How official is it? Are the changes ported to FPC?
> (Googling through the lists.freepascal.org did not help.)
>

NewPascal is official compiler for mORMot. NewPascal means tuned compiler
more Delphi compatible with additional support for mORMot framework, cross
compiling and early access for new features. More info about changes and
differences with comparison to official FPC:
http://newpascal.org/compass.html . All is reported on FPC bugtracker. I
can't do much in that matter.

... I also want acceptance of all important patches into FPC (that is why I
will work on your patch). We really need NewPascal fork, to get important
patches/modifications in reasonable time, for example merge for finished
Generics.Collections took 2 years...

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...

*NewPascal is and will be as close FPC trunk/bugtracker as possible*.

-- 
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

2016-10-25 Thread Blaise 

On 26.10.2016 0:36, Maciej Izak wrote:


your work (with my modifications and with regression tests) will become part of 
NewPascal release (for sure!) and I hope it makes you less frustrated :)


Now you have me confused.
I thought you wanted to "take over" acceptance of this into FPC and doing 
further improvements.
What is this NewPascal? How official is it? Are the changes ported to FPC? 
(Googling through the lists.freepascal.org did not help.)

--
βþ
___
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-25 Thread Maciej Izak 
2016-10-25 20:38 GMT+02:00 :
>
> 3) I have not abandoned this project (and I am as frustrated with the pace
> as you may be; although, the previous disruption was not my fault -- I had
> allocated last December to finally have this merged, but got no response
> from maintainers within a month).
>

... I understand ... :\


> TL;DR: while there may be nothing preventing you from just grabbing the
> feature-ready files and "taking over" from the legal standpoint (and I do
> not care to check), there are other implications to consider.
>

> The other reason I mentioned Scooter Software is that they may be
> interested in funding your further work. (The list does not reflect this,
> but I CC'ed my original message to them to keep them in the loop.)
>

that is very interesting for me. Thanks?

btw. your work (with my modifications and with regression tests) will
become part of NewPascal release (for sure!) and I hope it makes you less
frustrated :)

-- 
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

2016-10-25 Thread Blaise 

On 25.10.2016 20:57, Maciej Izak wrote:


What Scooter Software has to GPL licensed code?


It has to do with what is right.
Allow me to provide a little background:
1) I do not use FPC at all;
2) Essentially, I was "hired" by Scooter Software (they do use FPC, I presume) 
to implement the subj (after one other person failed to improve on my earlier work);
3) I have not abandoned this project (and I am as frustrated with the pace as 
you may be; although, the previous disruption was not my fault -- I had 
allocated last December to finally have this merged, but got no response from 
maintainers within a month).

TL;DR: while there may be nothing preventing you from just grabbing the feature-ready 
files and "taking over" from the legal standpoint (and I do not care to check), 
there are other implications to consider.

The other reason I mentioned Scooter Software is that they may be interested in 
funding your further work. (The list does not reflect this, but I CC'ed my 
original message to them to keep them in the loop.)

--
βþ
___
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-25 Thread Maciej Izak 
2016-10-25 16:09 GMT+02:00 :

> In theory, that is fine by me (the author).
>

Good to hear that


> However, if I were to formally pass the bucket to you, I would like to
> settle with Scooter Software on my work done thus far.
>

What Scooter Software has to GPL licensed code?

-- 
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

2016-10-25 Thread Maciej Izak 
2016-10-25 15:45 GMT+02:00 Michael Van Canneyt :

> One remark only: you should keep it independent of (or orthogonal to) the
> work you did on management operators. One should not depend on the other...


Yes I know and I agree :P One branch for Generics.Collections, one for
Management Operators, one for Smart Pointers, one for patches and new one
for Closures.

I hope that Github has enough space for all branches...

-- 
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

2016-10-25 Thread Blaise 

On 25.10.2016 18:30, wkitt...@windstream.net wrote:


if i/we may ask, what happened to your Patch/hg repository? why did it go away?


As I said to Sven back then: "I did some server maintenance on 27th June, and I have 
had no incentive to put that part back yet".
That is the only reason: lack of time.
(But, AFAIR, there has been only a couple of minor bug fixes since then.)

--
βþ
___
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-25 Thread wkitty42 

On 10/25/2016 10:09 AM, bla...@blaise.ru wrote:

On 25.10.2016 16:06, Maciej Izak wrote @
http://lists.freepascal.org/pipermail/fpc-devel/2016-October/037375.html :


I'd like to take over work on closures/anonymous methods


In theory, that is fine by me (the author).
However, if I were to formally pass the bucket to you, I would like to settle
with Scooter Software on my work done thus far.


if i/we may ask, what happened to your Patch/hg repository? why did it go away?

--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
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-25 Thread Blaise 

On 25.10.2016 16:06, Maciej Izak wrote @ 
http://lists.freepascal.org/pipermail/fpc-devel/2016-October/037375.html :


I'd like to take over work on closures/anonymous methods


In theory, that is fine by me (the author).
However, if I were to formally pass the bucket to you, I would like to settle 
with Scooter Software on my work done thus far.

--
βþ
___
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-25 Thread Michael Van Canneyt 



On Tue, 25 Oct 2016, Maciej Izak wrote:


Hi,

I'd like to take over work on closures/anonymous methods:

http://newpascal.org/compass.html (point #5).

Patch/hg repository from original author has gone away but I have made
copy. My working repository is here:

https://github.com/maciej-izak/freepascal/commits/closures

I sent here original patch.

I will rework this functionality according to all suggestions from Jonas
and Sven (reference to all informations avaible in NewPascal "compass"
listed above).

any objections?


None, on the contrary. Glad that someone is taking it up.

One remark only: you should keep it independent of (or orthogonal to) 
the work you did on management operators. 
One should not depend on the other...


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

[fpc-devel] Closures / anonymous methods

2016-10-25 Thread Maciej Izak 
Hi,

I'd like to take over work on closures/anonymous methods:

http://newpascal.org/compass.html (point #5).

Patch/hg repository from original author has gone away but I have made
copy. My working repository is here:

https://github.com/maciej-izak/freepascal/commits/closures

I sent here original patch.

I will rework this functionality according to all suggestions from Jonas
and Sven (reference to all informations avaible in NewPascal "compass"
listed above).

any objections?

-- 
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] Bug in passing WideString parameters to dispinterface function ?

2016-10-25 Thread LacaK 

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] Bug in passing WideString parameters to dispinterface function ?

2016-10-25 Thread LacaK 

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