Re: [fpc-pascal] C translation question

[Ryan Joseph]

I just got back to this problem now. Yes, changing it to a while loop fixed the 
little bug and cleans things up in the translation for sure. Thanks for the tip.

> On Oct 24, 2016, at 3:20 AM, Bernd Oppolzer  
> wrote:
> 
> int pnpoly (int nvert, float *vertx, float *verty, float testx, float testy)
> {
>  int i, j, c = 0;
> 
>  i = 0, j = nvert-1;
> 
>  while (i < nvert)
>  {
>if (((verty [i] > testy) != (verty [j] > testy)) &&
> (testx < (vertx[j] - vertx[i]) * (testy - verty [i])
>  / (verty [j] - verty [i]) + vertx [i]))
>   c = !c;
> 
>j = i;
>i = i + 1;
>  }
> 
>  return c;
> }

Regards,
Ryan Joseph

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

Re: [fpc-pascal] C translation question

[Lars]

On Mon, October 24, 2016 5:20 am, José Mejuto wrote:
> El 24/10/2016 a las 1:40, Lars escribió:
>
>
>> Hi, what is the status of automated conversion tools? Last I remember
>> reading about them was when I read a delphi page on how to convert
>> header files. Are you saying that nowadways you can actually convert
>> plain C code to fpc, not just header files but all C code? Just certain
>> types of C code?  Are there any competing tools or everyone uses just
>> one main tool?
>
> Hello,
>
>
> I don't know, wrote this tool to help me in the past to translate Zint
> barcode source

...

> It is far away from a real code translator,

...

> It uses GoldParser so maybe it only works in Windows :-?, only very
> basic "C" is handled and is mostly function by function oriented.
>
> If you want to test it I can provide .exe or source code, but do not
> expect it to translate anything far than some trivial functions.
>

Do you have github account... or sourceforge, I think a few other people
may find it useful...

My dream is some day to convert this:
http://duro.sourceforge.net/

to freepascal or GoLang, however I don't really feel like doing it all
manually, would rather automate a lot of it.

AFAIK it's plain C, been a while since I looked at it.

There is more C code I'd like to convert too, and I'm sure others would be
interested in your source... But it is up to you, I don't know if you just
don't feel like making it public on github or sourceforge
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] C translation question

[Lars]

I previously wrote:
>
>> Are you saying that nowadways you can actually convert
>> plain C code to fpc,

Found this too:

http://c2pas.sourceforge.net/

It says it can convert a large portion, but not all, obviously
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] C translation question

[Lars]

On Mon, October 24, 2016 8:00 pm, Lars wrote:
> I previously wrote:
>
>>
>>> Are you saying that nowadways you can actually convert
>>> plain C code to fpc,
>
> Found this too:
>
>
> http://c2pas.sourceforge.net/
>


And there is also this interesting find:

http://cc.embarcadero.com/item/26951

(C to Pascal Converter 2.1.7.2015)

Looks as though there are multiple efforts, too bad these people didn't
combine forces and create a github account and work together on these
tools.

There is also this:
http://www.astonshell.com/freeware/c2pas32/


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

Re: [fpc-pascal] importtl tool

[LacaK]

Dňa 24.10.2016 o 13:10 José Mejuto napísal(a):

El 24/10/2016 a las 8:17, LacaK escribió:


I'm not "sure" because if the flag does not tell us nothing (no IN, no
OUT) I do not know if there is a "default behavior" except the "ByRef"
flag and both "constref" and "var" are "ByRef".

I have found:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx 


"The*[in]*attribute is applied to a parameter by default when no
directional parameter attribute is specified."


Hello,

I was not aware about that "default" so, yes you are right.


Take a look in you TLB looking for a widestring that should return
information, if with this code is marked as "var" everything should be
ok, if it will be marked as "constref" something in the logic is wrong.

? I do not understand what do you mean
When I use Microsofts OLEView to look at TLB I see only:
  long ScGetStringValue(long Type, BSTR* Value);
There is no attribute [in],[out],... specified


I'm quite sure that using "var" in both cases is safe in 99.9% of the 
cases.


OLEView will not show you the "attributes", only in the IDL source.


According to:
https://msdn.microsoft.com/en-us/library/cc237804.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx 



*"PARAMFLAG_NONE: *The behavior of the parameter is not specified."
I guess, that my case is PARAMFLAG_NONE so patch should look like:
  case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN
or PARAMFLAG_FOUT) of
  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
  *PARAMFLAG_NONE,*
  PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
I leave 'var ' for Delphi compatibility ...


Yes.
Thank you. Patch attached. I will attach it to bug report 30764, but 
there is now new comment about using "constref" ... :-)

-Laco.

--- typelib.pas.ori Thu Oct 20 14:46:27 2016
+++ typelib.pas Mon Oct 24 13:15:54 2016
@@ -641,9 +641,10 @@
   sPar:='';
   if bParamByRef then
 case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and 
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of
-PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
-PARAMFLAG_FOUT:sPar:='out ';
-PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
+  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
+  PARAMFLAG_FOUT:sPar:='out ';
+  PARAMFLAG_NONE, // [in] is default when no 
directional parameter attribute is specified
+  PARAMFLAG_FIN:sPar:='var '; // constref in safecall? TBD
 end;
   if not MakeValidId(GetName(k+1),sVarName) then
 AddToHeader('//  Warning: renamed parameter ''%s'' in %s.%s to 
''%s''',[GetName(k+1),iname,sMethodName,sVarName],True);
@@ -1835,6 +1836,7 @@
 end;
   if (L<>'  ') then
 UnitSource.Add(L);
+  UnitSource.Add('');
   UnitSource.addStrings(InterfaceSection);
   UnitSource.addStrings(ImplementationSection);
   UnitSource.Add('end.');
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] C translation question

[José Mejuto]

El 24/10/2016 a las 1:40, Lars escribió:


Hi, what is the status of automated conversion tools? Last I remember
reading about them was when I read a delphi page on how to convert header
files. Are you saying that nowadways you can actually convert plain C code
to fpc, not just header files but all C code? Just certain types of C
code?  Are there any competing tools or everyone uses just one main tool?


Hello,

I don't know, wrote this tool to help me in the past to translate Zint 
barcode source from C to pascal, in special the maths involving "++", 
"--" and other funny "C" expressions.


It is far away from a real code translator, and it is dummy as it does 
not analyze the type of each variable, instead it uses them as a 
variable of any type and it simply try to put it in the same context as 
the "C" one. When it finds things like:


if (a) { ...

It will convert it to

if IsTrue(a) then ...

So you must provide an IsTrue function for that case (integer, char, 
byte...) and many times you need to manually adjust some lines.


Or if it finds:

a++;

It will output:

PostInc(a);

Where PostInc is:

function PostInc(var aValue: integer): integer;
begin
  Result:=aValue;
  aValue:=aValue + 1;
end;

It uses GoldParser so maybe it only works in Windows :-?, only very 
basic "C" is handled and is mostly function by function oriented.


If you want to test it I can provide .exe or source code, but do not 
expect it to translate anything far than some trivial functions.


--

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

Re: [fpc-pascal] importtl tool

[José Mejuto]

El 24/10/2016 a las 8:17, LacaK escribió:


I'm not "sure" because if the flag does not tell us nothing (no IN, no
OUT) I do not know if there is a "default behavior" except the "ByRef"
flag and both "constref" and "var" are "ByRef".

I have found:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx
"The*[in]*attribute is applied to a parameter by default when no
directional parameter attribute is specified."


Hello,

I was not aware about that "default" so, yes you are right.


Take a look in you TLB looking for a widestring that should return
information, if with this code is marked as "var" everything should be
ok, if it will be marked as "constref" something in the logic is wrong.

? I do not understand what do you mean
When I use Microsofts OLEView to look at TLB I see only:
  long ScGetStringValue(long Type, BSTR* Value);
There is no attribute [in],[out],... specified


I'm quite sure that using "var" in both cases is safe in 99.9% of the cases.

OLEView will not show you the "attributes", only in the IDL source.


According to:
https://msdn.microsoft.com/en-us/library/cc237804.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx

*"PARAMFLAG_NONE: *The behavior of the parameter is not specified."
I guess, that my case is PARAMFLAG_NONE so patch should look like:
  case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and (PARAMFLAG_FIN
or PARAMFLAG_FOUT) of
  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
  *PARAMFLAG_NONE,*
  PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
I leave 'var ' for Delphi compatibility ...


Yes.

--

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

Re: [fpc-pascal] importtl tool

[LacaK]

To note that both "constref" are intentional.

Ok I can create patch if we (you ;-)) are sure that it is okay ?
-Laco.



I'm not "sure" because if the flag does not tell us nothing (no IN, no 
OUT) I do not know if there is a "default behavior" except the "ByRef" 
flag and both "constref" and "var" are "ByRef".


I have found:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367051(v=vs.85).aspx
"The*[in]*attribute is applied to a parameter by default when no 
directional parameter attribute is specified."




Take a look in you TLB looking for a widestring that should return 
information, if with this code is marked as "var" everything should be 
ok, if it will be marked as "constref" something in the logic is wrong.


? I do not understand what do you mean
When I use Microsofts OLEView to look at TLB I see only:
  long ScGetStringValue(long Type, BSTR* Value);
There is no attribute [in],[out],... specified

According to:
https://msdn.microsoft.com/en-us/library/cc237804.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221019(v=vs.85).aspx
*"PARAMFLAG_NONE: *The behavior of the parameter is not specified."
I guess, that my case is PARAMFLAG_NONE so patch should look like:
  case FD^.lprgelemdescParam[k].paramdesc.wParamFlags and 
(PARAMFLAG_FIN or PARAMFLAG_FOUT) of

  PARAMFLAG_FIN or PARAMFLAG_FOUT:sPar:='var ';
  PARAMFLAG_FOUT:sPar:='out ';
  *PARAMFLAG_NONE,*
  PARAMFLAG_FIN:sPar:='var '; //constref in safecall? TBD
end;
I leave 'var ' for Delphi compatibility ...

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