freepascal support

[GoogleCodeExporter]

I've started porting dwscript to freepascal/lazarus. Version 2.1 already ported 
(but does not stable). Is it possible to integrate changes to mainline? 

Original issue reported on code.google.com by alexv...@mail.ru on 20 Oct 2011 at 12:37

[GoogleCodeExporter]

You mean the unstable 2.1?

At this point it's probably preferable to concentrate on 2.2, which is just 
around the corner, and has a much more extensive test suite.

I had a quick look at Lazarus/FreePascal sometime ago, but couldn't find a 
version with generics support (FPC 2.5?), and the main Lazarus download 
wouldn't compile at all. What version would you be targeting?

Also in terms of integration, the design goal is to to have no $ifdef outside 
of the CrossPlatform unit (and that includes support for cross-delphi 
versions). Most of the specifics should already be there (except a hard one for 
constant unification).

Original comment by zar...@gmail.com on 20 Oct 2011 at 1:17

• Changed state: NeedMoreInfo

[GoogleCodeExporter]

I'll concentrate on 2.2. 2.1 port is finished, but however has some bugs that I 
couldn't catch.

Generics implementation in 2.5 is more delphi compatible, but generic methods 
and generic constraints are not supported. 

No ifdefs outside CrossPlatform might be problem. After a brief look: fpc 
doesn't support record constructors, generic methods and constraints, function 
references and has different declaration of IUnknown. RTTI and VMT structure is 
also incompatible with delphi.

FPC targer version will is 2.5.1+. 

In case of 2.2 I preserve unicode support for FPC (it will require at least to 
explicitly set strings as UnicodeStrings). COM support for fpc is not planned 
for now.

Original comment by alexv...@mail.ru on 20 Oct 2011 at 2:44

[GoogleCodeExporter]

First, is there a working version of Lazarus+FPC 2.5.1+ somewhere I could 
download to have a look at too?

Generic constraints shouldn't be present in DWScript core.
I'm not sure about generic methods, I don't think there are many of them 
though, and may be simple to eliminate.
Function references, you mean anonymous methods? If yes, there shouldn't be any 
in DWScript core.
Record constructors can be replaced by record class methods if FPC supports 
that, and I don't think there are many of them in DWScript in the first place, 
though.

IUnknown is AFAIK unnecessary in DWScript (I've been removing some of them 
already).
The COMConnector should be an optional unit, so no requirement to port.
The RTTI stuff should be restricted to RTTIExposer & RTTIConnector, both being 
optional units.

Ending up with Delphi and FPC-specific on the incompatible portions (COM, RTTI) 
isn't a problem, as long as the core units fallback on CrossPlatform.

How similar are Variants? (TVarData, etc.) No problems from that direction?

For unicode strings, does FPC support aliasing the String type? If yes, it 
could be aliased in CrossPlatform unit.

Original comment by zar...@gmail.com on 20 Oct 2011 at 3:30

[GoogleCodeExporter]

I use Lazarus trunk from svn and fpc_fixes (2.5.1) from svn too. Snapshots are 
ftp://ftp.freepascal.org/pub/lazarus/snapshots/. 

Generic constraints: few classes in "dwsUtils.pas" at least
Anonymous methods used as callbacks to TThread.Synchronize
Record construtors: I used record class methods.

IUnknown: any _AddRef, _Release, QueryInterface custom implementation has to 
use ifdefs to support fpc.

Declaration in fpc:
       IUnknown = interface
         ['{00000000-0000-0000-C000-000000000046}']
         function QueryInterface({$IFDEF FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} iid : tguid;out obj) : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
         function _AddRef : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
         function _Release : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
       end;

I had no problems with variants. Seems to be they are nearly completely 
compatible.

Aliasing String itself AFAIK is not possible. We have to define smth like 
"dwsString" and use it everywhere or use UnicodeString. 

Original comment by alexv...@mail.ru on 20 Oct 2011 at 4:16

[GoogleCodeExporter]

Got the 0.9.3.1 with FPC 2.5.1, I've tried to convert the unit tests project, 
but when compiling, it complains that it can't find "Forms", while it appears 
to be able to find "Forms" when I start a new project. Anything to switch or 
adjust?

Original comment by zar...@gmail.com on 21 Oct 2011 at 8:24

[GoogleCodeExporter]

"Forms" is a part of package LCL add it to dependencies. (OTOH I think that 
it's better to remove dependency on VCL/LCL from dwscript core). May be you 
should to have a look on my port first? https://github.com/alexvins/dwscript. 

Original comment by alexv...@mail.ru on 21 Oct 2011 at 2:22

[GoogleCodeExporter]

The issue isn't on DWScript itself, but when trying to compile the unit tests 
project.
I took your version of the units tests project, but it doesn't work any better, 
and I get the same error on Forms when compiling your lang_tests.lpr

You mentioned "fpc_fixes" above, what is that? Is it a separate install? could 
it be the cause of the issue?

Original comment by zar...@gmail.com on 21 Oct 2011 at 3:34

[GoogleCodeExporter]

fpc_fixes - is svn branch for upcoming 2.6 release, but "forms" is a part of 
LCL, and LCL is a part of lazarus. There is smth wrong with your Lazarus 
installation or with settings. Open "Project/Project Options" then click "Show 
parameters", what is the output?

Original comment by alexv...@mail.ru on 21 Oct 2011 at 4:01

[GoogleCodeExporter]

After a couple of reinstalls, it works (Forms at least).

I've committed a few changes which gets compilation to the hard part 
(generics), by constraints I had thought about the extended constraints, but 
apparently "class" isn't supported. Which means, how do you make a generic 
object collection in FPC? One where you can .Free as well as use = and <> 
operators?

It seems that there may be quite some work to bridge the gap on other things 
(even TStringList f.i.), I guess it may be wiser to have 2.2 out of the door 
before making more changes :)

Original comment by zar...@gmail.com on 21 Oct 2011 at 8:06

[GoogleCodeExporter]

About generics look info unit fgl. In fpc you can call .Free on generic 
paramter, all checks will be performed during specialization. 

Original comment by alexv...@mail.ru on 22 Oct 2011 at 6:21

[GoogleCodeExporter]

I think that changing string to unicodestring in trunk will be enough to port 
with unicode support and to preserve port in synch w/o conflicts. 

Original comment by alexv...@mail.ru on 22 Oct 2011 at 11:04

[GoogleCodeExporter]

And yes TUnicodeStringList and may be smth else will be necessary but it may 
stay in my fork for a while and likely will be included in next fpc release 
(uncicode delphi compatibility is one of the targets in current fpc 
developement)

Original comment by alexv...@mail.ru on 22 Oct 2011 at 12:26

[GoogleCodeExporter]

The other case is to revert UnicodeString to string, but treat them as UTF8 in 
fpc. This will require less changes.

Original comment by alexv...@mail.ru on 22 Oct 2011 at 12:34

[GoogleCodeExporter]

With FPC generics I get an error when comping objects (in IndexOf f.i., it 
complains on the '=')

Using UTF8 in FPC might reduce the distance, but it would also fork the 
language, as all string operations and functions that take an index or a length 
would then behave differently. Especially if FPC gets Unicode string as 
standard in the future.

Original comment by zar...@gmail.com on 24 Oct 2011 at 6:48

[GoogleCodeExporter]

"With FPC generics I get an error when comping objects" in which code?

Original comment by alexv...@mail.ru on 24 Oct 2011 at 7:58

[GoogleCodeExporter]

In TObjectList<T>.IndexOf, it complains on the "=" in "FItems[i]=anItem".

Original comment by zar...@gmail.com on 24 Oct 2011 at 8:04

[GoogleCodeExporter]

Committed with String -> UnicodeString. Let me know if I missed any.

Original comment by zar...@gmail.com on 24 Oct 2011 at 8:16

[GoogleCodeExporter]

Closing this issue. Please open new ones on specific issues that will arise.
Also let me know when/if you want me to announce your conversion.

Original comment by zar...@gmail.com on 27 Oct 2011 at 12:39

• Changed state: Done

[GoogleCodeExporter]

Ok. I merged changes from your trunk and in progress of making workarounds to 
fpc bugs.
In announce please add a link to http://wiki.freepascal.org/DelphiWebScript.

Original comment by alexv...@mail.ru on 27 Oct 2011 at 12:49

[GoogleCodeExporter]

Ok, I've added the link here, and I'll announce post 2.1 along with other 
things being worked on.
Just to know, what target are you aiming at with FPC? Linux/MacOS? I may be 
interested in the Java target, though I guess the distance to bridge could be 
higher.

Original comment by zar...@gmail.com on 27 Oct 2011 at 2:48

[GoogleCodeExporter]

FPC has crossplatform nature, so I don`t plan to limit to any particular 
targets. windows, linux, xBSD, MasOS (including iOS). As for java, it is WIP. 
When JVM support will be committed to freepascal mainline will be a time to 
think of supporting it.
(it at least will require to throw away all assembler and pointer manipulations)

Original comment by alexv...@mail.ru on 27 Oct 2011 at 2:59

[GoogleCodeExporter]

ASM can be turned off by defining PUREPASCAL.
Apart from internal use in collections, pointers are used to access variant 
structures, I guess that'll be the other area that will have seen change for 
the JVM

Original comment by zar...@gmail.com on 27 Oct 2011 at 3:14

[GoogleCodeExporter]

Yes current problems are generic issues, just now i`m working on them. I plan 
to fix dwscript core compilation today.

Original comment by alexv...@mail.ru on 27 Oct 2011 at 3:41

[GoogleCodeExporter]

"Committed with String -> UnicodeString. Let me know if I missed any"
Same changes needed in tests and (P)Char -> (P)WideChar (or UnicodeChar - they 
identical in fpc)

Original comment by alexv...@mail.ru on 28 Oct 2011 at 11:37

[GoogleCodeExporter]

Committed PChar->PWideChar and Char->WideChar

Original comment by zar...@gmail.com on 31 Oct 2011 at 7:53

[GoogleCodeExporter]

I has made some progress with porting to trunk version of fpc, but there are 
some problems. F.e. assigning widechar to variant makes it be of type varolestr 
but should be varustring, how this can be forced? 

Original comment by alexv...@mail.ru on 10 Nov 2011 at 6:21

[GoogleCodeExporter]

You mean in FPC? What about forcing the cast with a 
"variant:=UnicodeString(wideChar)"?
Other than that, maybe assigning to a temporary variable of type UnicodeString 
(which is going to exist anyway, implicitly or explicitly)

Original comment by zar...@gmail.com on 10 Nov 2011 at 7:15

[GoogleCodeExporter]

The problem is that I don`t know the exact place where this typecast performed. 
Could you specify the possible locations? 

One of the buggy scripts is "vigenere.pas" on line 26 srcA is already 
varolestr. But where in compiler source is it defined so?

Original comment by alexv...@mail.ru on 10 Nov 2011 at 7:34

[GoogleCodeExporter]

The most direct way to catch the issue would be to place a breakpoint in the 
FPC RTL function that performs the assignment of a character to a variant, in 
Delphi there are compiler magic functions for that, so that's assuming FPC has 
a similar approach.

If that fails, you could work by elimination: since you know the issue is 
triggered by vigenere.pas, comment out portions of it until the issue no longer 
occurs, then reactivate, etc. up to the point where you find the line(s) that 
trigger the issue.

Original comment by zar...@gmail.com on 10 Nov 2011 at 8:00

[GoogleCodeExporter]

Yes this is RTL function and this is FPC bug. (I found that all unicodestrings 
become  widestrings when assigning to variants). To be discussed with fpc 
developers. 

Original comment by alexv...@mail.ru on 14 Nov 2011 at 3:07

[GoogleCodeExporter]

dwscript is good test-suite :) nearly each merge reveals few more bugs with 
generics. 

Original comment by alexv...@mail.ru on 3 Jan 2012 at 6:09

[GoogleCodeExporter]

You mean each merge from the DWS SVN or each FPC update? 

I saw FPC 2.6 was recently released, how far does it goes now? Any progress on 
UnicodeString/Variant?

Original comment by zar...@gmail.com on 4 Jan 2012 at 7:18

[GoogleCodeExporter]

not so far, I use trunk version for dwscript.

Original comment by alexv...@mail.ru on 4 Jan 2012 at 1:54