Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
"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
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
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
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
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
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
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
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
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
"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
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
Committed with String -> UnicodeString. Let me know if I missed any.
Original comment by zar...@gmail.com
on 24 Oct 2011 at 8:16
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
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
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
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
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
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
"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
Committed PChar->PWideChar and Char->WideChar
Original comment by zar...@gmail.com
on 31 Oct 2011 at 7:53
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
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
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
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
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
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
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
not so far, I use trunk version for dwscript.
Original comment by alexv...@mail.ru
on 4 Jan 2012 at 1:54
Original issue reported on code.google.com by
alexv...@mail.ru
on 20 Oct 2011 at 12:37