Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-02

Can't compile trunk with fpc 2.4.5 under ubuntu

49 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Max Vlasov

Hi,

can't make clean all for trunk version under ubuntu with fpc 2.4.5

  gtk2winapi.inc(3403,73) Error: Identifier not found
"pango_font_family_is_monospace"

I also see that in gtk2extrah.inc the inclusion of this symbol is optional depending on the fpc version. Is this something wrong with my sources paths or 2.4.5 is no longer sufficient?

Thanks,

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/e911ce69/attachment.html>

Reply by email

Juha Manninen
to Max Vlasov

2012/2/25 Max Vlasov

Show quoted text 9 lines
can't make clean all for trunk version under ubuntu with fpc 2.4.5 gtk2winapi.inc(3403,73) Error: Identifier not found "pango_font_family_is_monospace" I also see that in gtk2extrah.inc the inclusion of this symbol is optional depending on the fpc version. Is this something wrong with my sources paths or 2.4.5 is no longer sufficient?

Zeljan fixed it so it compiles with FPC 2.4.4. Maybe the IFDEF is wrong.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/f53be999/attachment.html>

Reply by email

zeljko
to Max Vlasov: can't make clean all for trunk version under ubuntu with fpc 2.4.5…
Max Vlasov wrote 10 lines
Hi, can't make clean all for trunk version under ubuntu with fpc 2.4.5 gtk2winapi.inc(3403,73) Error: Identifier not found "pango_font_family_is_monospace" I also see that in gtk2extrah.inc the inclusion of this symbol is optional depending on the fpc version. Is this something wrong with my sources paths or 2.4.5 is no longer sufficient?

fixed in r35593

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/53c90ef8/attachment.html>

Reply by email

zeljko
to Juha Manninen: 2012/2/25 Max Vlasov Zeljan fixed it so it compiles with FPC 2.4.4. Maybe the IFDEF is…
Juha Manninen wrote 13 lines
2012/2/25 Max Vlasov > can't make clean all for trunk version under ubuntu with fpc 2.4.5 > > gtk2winapi.inc(3403,73) Error: Identifier not found > > "pango_font_family_is_monospace" > > I also see that in gtk2extrah.inc the inclusion of this symbol is > optional depending on the fpc version. Is this something wrong with my > sources paths or 2.4.5 is no longer sufficient? Zeljan fixed it so it compiles with FPC 2.4.4. Maybe the IFDEF is wrong.

Yep, ifdef was for fpc < 20405 , now it's < 20501 so it should work.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/146bbb1e/attachment.html>

Reply by email

Max Vlasov
to zeljko
zeljko wrote 14 lines
** On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote: > 2012/2/25 Max Vlasov > > > can't make clean all for trunk version under ubuntu with fpc 2.4.5 Yep, ifdef was for fpc < 20405 , now it's < 20501 so it should work.

Thanks, can't check right now, but hope it will work

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/03fbbfa7/attachment.html>

Reply by email

Max Vlasov
to Max Vlasov
Max Vlasov wrote 21 lines
On Sat, Feb 25, 2012 at 5:36 PM, zeljko wrote: > ** > > On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote: > > > 2012/2/25 Max Vlasov > > > > > > > can't make clean all for trunk version under ubuntu with fpc 2.4.5 > > Yep, ifdef was for fpc < 20405 , now it's < 20501 so it should work. > > > Thanks, can't check right now, but hope it will work Max

Tried make it from scratch on a machine without fpc and lazarus. Download both trunk, but 35594 can't compile with

dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected
"AnsiString"

The error appears 4 times.
Sorry if it's something wrong with my particular configuration

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120225/953aff0b/attachment-0001.html>

Reply by email

zeljko
to Max Vlasov
Max Vlasov wrote 20 lines
On Sat, Feb 25, 2012 at 6:48 PM, Max Vlasov wrote: > On Sat, Feb 25, 2012 at 5:36 PM, zeljko wrote: >> ** >> >> On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote: >> > 2012/2/25 Max Vlasov >> > >> > > can't make clean all for trunk version under ubuntu with fpc 2.4.5 >> >> Yep, ifdef was for fpc < 20405 , now it's < 20501 so it should work. > > Thanks, can't check right now, but hope it will work > > Max Tried make it from scratch on a machine without fpc and lazarus. Download both trunk, but 35594 can't compile with dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected "AnsiString"

That have nothing to do with problem you've mentioned. Probably somebody commited code which works on 2.6/2.7 but not on 2.4.5. Anyway, I'm suspicious about that since Juha tested builds with 2.4.4 and it was ok.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120226/44c835d6/attachment.html>

Reply by email

Max Vlasov
to zeljko
zeljko wrote 55 lines
** On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote: > On Sat, Feb 25, 2012 at 6:48 PM, Max Vlasov wrote: > > On Sat, Feb 25, 2012 at 5:36 PM, zeljko wrote: > >> ** > >> > >> On Saturday 25 of February 2012 14:04:17 Juha Manninen wrote: > >> > 2012/2/25 Max Vlasov > >> > > >> > > can't make clean all for trunk version under ubuntu with fpc 2.4.5 > >> > >> Yep, ifdef was for fpc < 20405 , now it's < 20501 so it should work. > > > > Thanks, can't check right now, but hope it will work > > > > Max > > Tried make it from scratch on a machine without fpc and lazarus. Download > both trunk, but 35594 can't compile with > > dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected > "AnsiString" That have nothing to do with problem you've mentioned. Probably somebody commited code which works on 2.6/2.7 but not on 2.4.5. Anyway, I'm suspicious about that since Juha tested builds with 2.4.4 and it was ok.

Just yesterday this line didn't produce any search results in Google, today it leads at least to two bug reports in the tracker )

Don't know whether it would lead to anything, but I exlained by steps :
- Installed stocked binary from Ubuntu (2.4.0)
- Downloaded trunk fpc, compiled it (make clean all install INSTALL_PREFIX=/usr/local)
- Uninstalled stock fpc
- After fpc complaining about ppc386 did a symlink to /usr/local.. ppc386
- Modified /etc/fpc.cfg, three lines pointing now to /usr/local...
- Tried make clean all in lazarus
- (ERROR) Stopped on the following line about dbgrids.
- Tried to recompile fpc using now the only fpc (trunk)
- Tried to rebuild packages (make clean all .., make install... inside fpc/packages)
- (ERROR) the same error.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120226/646d5abf/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 7 lines
[...] Just yesterday this line didn't produce any search results in Google, today it leads at least to two bug reports in the tracker ) Don't know whether it would lead to anything, but I exlained by steps : - Installed stocked binary from Ubuntu (2.4.0) - Downloaded trunk fpc

The mail subject says 2.4.5.
Just making sure: You mean fpc trunk 2.7.1, right?

Show quoted text 11 lines
, compiled it (make clean all install INSTALL_PREFIX=/usr/local) - Uninstalled stock fpc - After fpc complaining about ppc386 did a symlink to /usr/local.. ppc386 - Modified /etc/fpc.cfg, three lines pointing now to /usr/local... - Tried make clean all in lazarus - (ERROR) Stopped on the following line about dbgrids. - Tried to recompile fpc using now the only fpc (trunk) - Tried to rebuild packages (make clean all .., make install... inside fpc/packages) - (ERROR) the same error.

Mattias

Reply by email

Marco van de Voort
to zeljko: That have nothing to do with problem you've mentioned. Probably somebody commited code…
zeljko wrote 9 lines
On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote: > Tried make it from scratch on a machine without fpc and lazarus. Download > both trunk, but 35594 can't compile with > > dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected > "AnsiString" That have nothing to do with problem you've mentioned. Probably somebody commited code which works on 2.6/2.7 but not on 2.4.5.

No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an abstract type for compat of D2006+. The idea is to merge this back to 2.6.1 too. (so fix with fullversion>20600)

I only noticed the lazarus breakage later, and wanted to wait what the laz devels thought of it. If needed I can revert it for a while, so they can work and test first.

I found no way to fix it under the hood.

Reply by email

zeljko
to Marco van de Voort
Marco van de Voort wrote 20 lines
On Sun, Feb 26, 2012 at 08:15:13AM +0100, zeljko wrote: > On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote: > > Tried make it from scratch on a machine without fpc and lazarus. > > Download both trunk, but 35594 can't compile with > > > > dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected > > "AnsiString" > > That have nothing to do with problem you've mentioned. Probably somebody > commited code which works on 2.6/2.7 but not on 2.4.5. No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an abstract type for compat of D2006+. The idea is to merge this back to 2.6.1 too. (so fix with fullversion>20600) I only noticed the lazarus breakage later, and wanted to wait what the laz devels thought of it. If needed I can revert it for a while, so they can work and test first. I found no way to fix it under the hood.

Yes, but original post is about 2.4.5 NOT about 2.7.1, also somebody opened issue at lazarus mantis about it.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120226/638432aa/attachment-0001.html>

Reply by email

Martin Schreiber
to Marco van de Voort: No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an abstract type…
Marco van de Voort wrote 15 lines
On Sun, Feb 26, 2012 at 08:15:13AM +0100, zeljko wrote: > On Saturday 25 of February 2012 20:20:51 Max Vlasov wrote: > > Tried make it from scratch on a machine without fpc and lazarus. > > Download both trunk, but 35594 can't compile with > > > > dbgrids.pas(1991,31) Error: Incompatible types: got "Pointer" expected > > "AnsiString" > > That have nothing to do with problem you've mentioned. Probably somebody > commited code which works on 2.6/2.7 but not on 2.4.5. No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an abstract type for compat of D2006+. The idea is to merge this back to 2.6.1 too. (so fix with fullversion>20600)

How does the memory release work? With tbookmarkstr it was done automatically by the compiler.

Martin

Reply by email

Max Vlasov
to zeljko: Yes, but original post is about 2.4.5 NOT about 2.7.1, also somebody opened issue at…
zeljko wrote 12 lines
** Yes, but original post is about 2.4.5 NOT about 2.7.1, also somebody opened issue at lazarus mantis about it. zeljko

Sorry about the confusion, my initial plan was testing the fix by zeljko about lazarus behaviar under linux. First I tried this on a machine with fpc 2.4.5. When this was fixed I had no chance to do this on the same machine and tried to install fpc/lazarus on a computer without both so ended up trying installing trunk/trunk that wasn't possible because of this error.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120226/e897cd9b/attachment-0001.html>

Reply by email

Marco van de Voort
to Martin Schreiber: How does the memory release work? With tbookmarkstr it was done automatically by the…
Martin Schreiber wrote 6 lines
> No. 2.7.x changed tbookmark from binary-data-encoded-in-an-ansistring to an > abstract type for compat of D2006+. The idea is to merge this back to 2.6.1 > too. (so fix with fullversion>20600) > How does the memory release work? With tbookmarkstr it was done automatically by the compiler.

TDataset.freerecord. That Delphi compatible though in current delphi's that is probably empty, since tbookmark is tbytes there.

Reply by email

Martin Schreiber
to Marco van de Voort
Marco van de Voort wrote 7 lines
> > How does the memory release work? With tbookmarkstr it was done > automatically by the compiler. TDataset.freerecord. That Delphi compatible though in current delphi's that is probably empty, since tbookmark is tbytes there.

There is no TDataset.freerecord() procedure in FPC trunk AFAIK.

Please add TDataset.BookmarkStr property:
"
public

    property BookmarkStr: TBookmarkStr read GetBookmarkStr write

SetBookmarkStr;
"
so in user code we can have a bookmark type with automatic memory management.

Thanks, Martin

Reply by email

Marco van de Voort
to Martin Schreiber
Martin Schreiber wrote
> TDataset.freerecord. That Delphi compatible though in current delphi's that > is probably empty, since tbookmark is tbytes there. > There is no TDataset.freerecord() procedure in FPC trunk AFAIK.

Sorry, freebookmark.

Show quoted text 7 lines
Please add TDataset.BookmarkStr property: " public property BookmarkStr: TBookmarkStr read GetBookmarkStr write SetBookmarkStr; " so in user code we can have a bookmark type with automatic memory management.

I'll study if the normal tbookmark can change to tbytes short term. If not, I'll add the bookmarkstr as deprecated property for time being.

Reply by email

Martin Schreiber
to Marco van de Voort
Marco van de Voort wrote 12 lines
> Please add TDataset.BookmarkStr property: > " > public > property BookmarkStr: TBookmarkStr read GetBookmarkStr write > SetBookmarkStr; > " > so in user code we can have a bookmark type with automatic memory > management. I'll study if the normal tbookmark can change to tbytes short term. If not, I'll add the bookmarkstr as deprecated property for time being.

Using TBytes as TBookmark everywhere (especially internally in TDataset) probably introduces unnecessary overhead.

Martin

Reply by email

Marco van de Voort
to Martin Schreiber
Martin Schreiber wrote 11 lines
> > property BookmarkStr: TBookmarkStr read GetBookmarkStr write > > SetBookmarkStr; > > " > > so in user code we can have a bookmark type with automatic memory > > management. > > I'll study if the normal tbookmark can change to tbytes short term. If not, > I'll add the bookmarkstr as deprecated property for time being. > Using TBytes as TBookmark everywhere (especially internally in TDataset) probably introduces unnecessary overhead.

Internally afaik tbookmark is not used but getbookmarkdata. Only in the getters and setters of the bookmark property the data is copied to the TBytes variable.

Reply by email

Marco van de Voort
to Martin Schreiber: Using TBytes as TBookmark everywhere (especially internally in TDataset) probably…
Martin Schreiber wrote 6 lines
> > I'll study if the normal tbookmark can change to tbytes short term. If not, > I'll add the bookmarkstr as deprecated property for time being. > Using TBytes as TBookmark everywhere (especially internally in TDataset) probably introduces unnecessary overhead.

Btw, didn't know you use fcl-db as base for MSE. If so, please also note the other interface related change:

http://wiki.freepascal.org/User_Changes_Trunk

Reply by email

Martin Schreiber
to Marco van de Voort
Marco van de Voort wrote 8 lines
On Mon, Feb 27, 2012 at 12:48:29PM +0100, Martin Schreiber wrote: > > I'll study if the normal tbookmark can change to tbytes short term. If > > not, I'll add the bookmarkstr as deprecated property for time being. > > Using TBytes as TBookmark everywhere (especially internally in TDataset) > probably introduces unnecessary overhead. Btw, didn't know you use fcl-db as base for MSE.

MSEgui uses db.pas so it is possible to use non MSE DB components in MSEgui projects.

Show quoted text 5 lines
If so, please also note the other interface related change: http://wiki.freepascal.org/User_Changes_Trunk

Thanks. The problem with some of the recent "Delphi compatibility" changes is that it breaks Delphi 7 compatibility. MSEide+MSEgui version 2.6 is compilable and runs with Delphi 7, a good benchmark for FPC. BTW, does current Delphi return pointer or tbytes in TDataset.Bookmark? Does it allow pointer arithmetic with the new TDateset buffer type pbyte? Delphi 7 can do pointer arithmetic with pchar and pwidechar only. A side mark: I don't think using the old ansistring as combined binary and character buffer is such a bad thing. TByte could replace such buffers only if Pascal string indexing would be zero based. Consequently with all these changes Delphi string indexes should be zero based too, same as dynamic array indexes.

Martin

Reply by email

Marco van de Voort
to Martin Schreiber
Martin Schreiber wrote 7 lines
> If so, please also note > the other interface related change: > > http://wiki.freepascal.org/User_Changes_Trunk > Thanks. The problem with some of the recent "Delphi compatibility" changes is that it breaks Delphi 7 compatibility.

Well, if that is a "problem" is a matter of taste. In reality, I think that D7 was wrong here, stuffing binary data into an ansistring.

True, if D2009 didn't change to unicodestring, it would probably be the most minor issue, but still, wrong is wrong.

MSEide+MSEgui version 2.6 is compilable and runs with Delphi 7, a good benchmark for FPC. BTW, does current Delphi return pointer or tbytes in TDataset.Bookmark?

TBytes. Afaik it returned pointer from D2006..2007.

Does it allow pointer arithmetic with the new TDateset buffer type pbyte?

D2009 does not allow this in default mode, but it does allow overindexing like FPC when {$POINTERMATH ON} is added. In my work Delphi code, this is default :-)

Delphi 7 can do pointer arithmetic with pchar and pwidechar only. A side mark: I don't think using the old ansistring as combined binary and character buffer is such a bad thing.

I do think that is bad. If you start using ansistring in mixed encoding environments (e.g. utf16 aka widestring/unicodestring), there is a danger of mutilation.

This is currently not very noticable in FPC because the default type is still ansistring[OS default 1-byte encoding], but we might not want to be stuck with that forever.

TByte could replace such buffers only if Pascal string indexing would be zero based.

No, since tbookmark afaik never represented a true string, character access would be meaningless, and would be a code smell indicating bad code.

Consequently with all these changes Delphi string indexes should be zero based too, same as dynamic array indexes.

IMHO this is not one of the differences that is significant enough to perpetuate workarounds till eternity. So I'm willing to entertain workarounds with a scope of a FPC release or two, but not beyond.

Reply by email

Hans-Peter Diettrich
to Martin Schreiber: MSEgui uses db.pas so it is possible to use non MSE DB components in MSEgui projects.…
Thanks. The problem with some of the recent "Delphi compatibility" changes is that it breaks Delphi 7 compatibility.

+1 :-(

IMO at least a stable D7 compatible version/branch is required, which may be extended to the last Delphi AnsiString version (D2007?). This branch doesn't deserve any further features or interface changes of the newer Unicode versions.

A side mark: I don't think using the old ansistring as combined binary and character buffer is such a bad thing.

+1

Following the many complaints in the Embarcadero groups, much code still relies on the use of AnsiString even for binary data. Another argument for a *really* D7 compatible Lazarus version.

DoDi

Reply by email

Marco van de Voort
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 11 lines
Martin Schreiber schrieb: > Thanks. The problem with some of the recent "Delphi compatibility" changes is > that it breaks Delphi 7 compatibility. +1 :-( IMO at least a stable D7 compatible version/branch is required, which may be extended to the last Delphi AnsiString version (D2007?). This branch doesn't deserve any further features or interface changes of the newer Unicode versions.

Afaik all serious merge requests to the 2.4 branch were honoured:-)

Show quoted text 8 lines
> A side mark: I don't think using the old ansistring as combined binary and > character buffer is such a bad thing. +1 Following the many complaints in the Embarcadero groups, much code still relies on the use of AnsiString even for binary data. Another argument for a *really* D7 compatible Lazarus version.

Like with Delphi, the problem for FPC is the same. Who will foot the bill for such sentiments.

Reply by email

Paul Breneman
to Martin Schreiber: MSEgui uses db.pas so it is possible to use non MSE DB components in MSEgui projects.…

Martin Schreiber wrote:
...

A side mark: I don't think using the old ansistring as combined binary and character buffer is such a bad thing.

I completely agree and was surprised to read opposite opinions here. Since 1985 I've been telling people this is my favorite feature so I can use strings as binary communication buffers and let the compiler deal with everything and it all just works... :)

Reply by email

Michael Schnell
to Hans-Peter Diettrich: +1 :-( IMO at least a stable D7 compatible version/branch is required, which may be…
Hans-Peter Diettrich wrote
a stable D7 compatible version/branch is required,

IMHO a compiler switch (Lazarus Project menu option) should be provided ("D7 compatibility" or "non-Unicode" or something like this)

There are decent projects for which a user interface is of little or no importance. Here it should be possible to prevent including all the RTL (and LCL) code necessary for Unicode.

-Michael

Reply by email

Michael Schnell
to Martin Schreiber: MSEgui uses db.pas so it is possible to use non MSE DB components in MSEgui projects.…
Martin Schreiber wrote
A side mark: I don't think using the old ansistring as combined binary and character buffer is such a bad thing.

+ 1/2

It would be better to have a type that 1:1 allows for all the well known string operations, replacing "Character" by "Byte":

MyByte := MyByteString[n]
MyByteString := MyByteString + MyByte;
MyByteString2 := copy(MyByteString, 10, 100);
p:= pos(MyByteString2, MyByteString)
MyByteString := MyByteString + MyByteString2;

...

In my projects I usually do something like "Type ByteString = AnsiString" for a future migration :) .

Michael

Reply by email

Michael Schnell
to Paul Breneman: ... I completely agree and was surprised to read opposite opinions here. Since 1985 I've…
Paul Breneman wrote
so I can use strings as binary communication buffers and let the compiler deal with everything and it all just works... :)

Yep. There is no logical reason to think other, but the fear that "string" is a moving target regarding the unavoidable upcoming of Unicode.

So a dedicated type for this with all features "AnsiString" offers but with no Unicode threat would be appropriate for this.

We very often do need flexible easy to use code-ignorant byte buffers.

-Michael

Reply by email

Sven Barth
to Michael Schnell: IMHO a compiler switch (Lazarus Project menu option) should be provided ("D7…
Michael Schnell wrote 8 lines
On 02/28/2012 12:00 AM, Hans-Peter Diettrich wrote: > a stable D7 compatible version/branch is required, IMHO a compiler switch (Lazarus Project menu option) should be provided ("D7 compatibility" or "non-Unicode" or something like this) There are decent projects for which a user interface is of little or no importance. Here it should be possible to prevent including all the RTL (and LCL) code necessary for Unicode.

A switch in the Project options won't help you here, because switching String from AnsiString to UnicodeString (or back) would basically mean to recompile the complete RTL and FCL. The change of the default string is no easy matter and only recently there was a lengthy discussion on core about this topic and its technical and organisational problems.

Regards,
Sven

Reply by email

Sven Barth
to Michael Schnell: + 1/2 It would be better to have a type that 1:1 allows for all the well known string…
Michael Schnell wrote 25 lines
On 02/27/2012 09:51 PM, Martin Schreiber wrote: > A side mark: I don't think using the old ansistring as combined binary > and character buffer is such a bad thing. + 1/2 It would be better to have a type that 1:1 allows for all the well known string operations, replacing "Character" by "Byte": MyByte := MyByteString[n] MyByteString := MyByteString + MyByte; MyByteString2 := copy(MyByteString, 10, 100); p:= pos(MyByteString2, MyByteString) MyByteString := MyByteString + MyByteString2; ... In my projects I usually do something like "Type ByteString = AnsiString" for a future migration :) .

You know that this is already possible in FPC?

=== source begin ===

program bytearraytest;
{$mode objfpc}
type
   TByteArray = array of Byte;
operator + (aLeft, aRight: TByteArray): TByteArray;
begin
   SetLength(Result, Length(aLeft) + Length(aRight));
   if Length(aLeft) > 0 then
     Move(aLeft[0], Result[0], Length(aLeft) * SizeOf(Byte));
   if Length(aRight) > 0 then
     Move(aRight[0], Result[Length(aLeft)], Length(aRight) * SizeOf(Byte));
end;
var
   arr1, arr2, arr3: TByteArray;
   b: Byte;
   i: LongInt;
begin
   SetLength(arr1, 5);
   for i := 0 to 4 do
     arr1[i] := i + 1;
   SetLength(arr2, 5);
   for i := 0 to 4 do
     arr2[i] := i + 6;
   arr3 := arr1 + arr2;
   for b in arr3 do
     Write(b, ' ');
   Writeln;
   arr3 := Copy(arr2, 2, 2);
   for b in arr3 do
     Write(b, ' ');
   Writeln;
end.

=== source end ===

=== output begin ===
PS P:\tests\oneshots> .\bytearraytest.exe
1 2 3 4 5 6 7 8 9 10
8 9
=== output end ===

I only didn't implement Pos, but as this does not use any compiler magic you can do that yourself ;)

Regards,
Sven

Reply by email

Michael Schnell
to Sven Barth
Sven Barth wrote 9 lines
Am 28.02.2012 08:22, schrieb Michael Schnell: > > > In my projects I usually do something like "Type ByteString = > AnsiString" for a future migration :) . type TByteArray = array of Byte;

???

array of Byte AnsiString.

You can't do "+", there is not TByteArrayList, ...

-Michael

Reply by email

Sven Barth
to Michael Schnell
Michael Schnell wrote 13 lines
On 02/28/2012 10:24 AM, Sven Barth wrote: > Am 28.02.2012 08:22, schrieb Michael Schnell: >> >> >> In my projects I usually do something like "Type ByteString = >> AnsiString" for a future migration :) . > > type > TByteArray = array of Byte; > ??? array of Byte AnsiString.

Yes, but you wrote this:

It would be better to have a type that 1:1 allows for all the well known string operations, replacing "Character" by "Byte":

And I simply demonstrated that this is already possible in FPC today (with TByteArray being the replacement for AnsiString).

You can't do "+", there is not TByteArrayList, ...

Did you even look at my code? All the remarks you wrote in your last mail except "Pos" I had tackled in there. And writing a TByteArrayList shouldn't be that hard either...

Regards,
Sven

Reply by email

Michael Schnell
Sven Barth wrote
This might be, but this shows that we do not need to extend the compiler with yet another managed type when all we need is already available.

Of course you are quite right, but before the Unicode transition this was available out of the box as "String" and used in multiple projects, but after the Unicode this is not so sure.

ANSIString supposedly still can be used, but to me the name "String" _sounded_ as if no encoding is necessary to be taken into account, and thus simply storing Bytes is not a bad idea, while ANSIString sounds as if the encoding has to be ANSI and this is essential for the internal proceedings. I do know that the contrary is true: "ANSISting" can happily be used for everything while in Delphi XE "String" imposes one of several encoding schemes. To me this naming is extremely ambiguous.

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120228/be30b7ac/attachment-0001.html>

Reply by email

Sven Barth
to Michael Schnell: Sorry, I did not want to be rude, but I understand that this is in fact _your_ code and…
Michael Schnell wrote 9 lines
On 02/28/2012 02:13 PM, Sven Barth wrote: > Did you even look at my code? Sorry, I did not want to be rude, but I understand that this is in fact _your_ code and not supplied by the RTL which is what this part of the discussion was about. Thanks anyway, -Michael

This might be, but this shows that we do not need to extend the compiler with yet another managed type when all we need is already available. In theory I could stuff that code into a unit together with a TBytesList (as the base type should then be TBytes) and then one could propose this unit to be added to fcl-base...

Regards,
Sven

Reply by email

Sven Barth
to Michael Schnell: Of course you are quite right, but before the Unicode transition this was available out…
Michael Schnell wrote 16 lines
On 02/28/2012 02:24 PM, Sven Barth wrote: > This might be, but this shows that we do not need to extend the > compiler with yet another managed type when all we need is already > available. Of course you are quite right, but before the Unicode transition this was available out of the box as "String" and used in multiple projects, but after the Unicode this is not so sure. ANSIString supposedly still can be used, but to me the name "String" _sounded_ as if no encoding is necessary to be taken into account, and thus simply storing Bytes is not a bad idea, while ANSIString sounds as if the encoding has to be ANSI and this is essential for the internal proceedings. I do know that the contrary is true: "ANSISting" can happily be used for everything while in Delphi XE "String" imposes one of several encoding schemes. To me this naming is extremely ambiguous.

Before Delphi 2009 you might have been right, but with that version Embarcadero did a cut and we now need to adapt and live with that. Also String in Delphi 2009+ is a UnicodeString, so it has only one encoding.

And with the way I described we can at least provide a type that handles similar to good old AnsiString, but will continue to work even if String should be changed to UnicodeString in the future.

Regards,
Sven

Reply by email

Martin Schreiber
to Sven Barth: And instead of introducing yet another type or another special encoding we could just…
Sven Barth wrote 14 lines
Am 28.02.2012 15:40, schrieb Hans-Peter Diettrich: > Sven Barth schrieb: > >> Before Delphi 2009 you might have been right, but with that version >> Embarcadero did a cut and we now need to adapt and live with that. > > I dare to disagree. A "ByteString" only requires a dedicated encoding > (value), which makes it incompatible with other encodings, and thus > disables all conversions. Such an encoding doesn't break Delphi > compatibility, but allows to use all stringhandling functions with it. And instead of introducing yet another type or another special encoding we could just leverage the features FPC has today and use TBytes.

Or even better, use FPC 2.6 AnsiString and UnicodeString and drop the encoding aware FPC 2.7 AnsiString. ;-)

BTW, please have a look into the different string concatenation compilerproc, it is probably not so easy to model that with equal or better performance with TBytes and operator overloading. Is it possible with operator overloading to combine different types? "
<TBytes>:= <TBytes> + 'stringconstant' + <TBytes> + <AnsiString>; "

Martin

Reply by email

Hans-Peter Diettrich
to Sven Barth: Before Delphi 2009 you might have been right, but with that version Embarcadero did a cut…
Before Delphi 2009 you might have been right, but with that version Embarcadero did a cut and we now need to adapt and live with that.

I dare to disagree. A "ByteString" only requires a dedicated encoding (value), which makes it incompatible with other encodings, and thus disables all conversions. Such an encoding doesn't break Delphi compatibility, but allows to use all stringhandling functions with it.

DoDi

Reply by email

Sven Barth
to Hans-Peter Diettrich: I dare to disagree. A "ByteString" only requires a dedicated encoding (value), which…
Hans-Peter Diettrich wrote 9 lines
Sven Barth schrieb: > Before Delphi 2009 you might have been right, but with that version > Embarcadero did a cut and we now need to adapt and live with that. I dare to disagree. A "ByteString" only requires a dedicated encoding (value), which makes it incompatible with other encodings, and thus disables all conversions. Such an encoding doesn't break Delphi compatibility, but allows to use all stringhandling functions with it.

And instead of introducing yet another type or another special encoding we could just leverage the features FPC has today and use TBytes.

Regards,
Sven

Reply by email

Sven Barth
to Martin Schreiber: Or even better, use FPC 2.6 AnsiString and UnicodeString and drop the encoding aware FPC…
Martin Schreiber wrote 22 lines
Am 28.02.2012 16:13, schrieb Sven Barth: > Am 28.02.2012 15:40, schrieb Hans-Peter Diettrich: >> Sven Barth schrieb: >> >>> Before Delphi 2009 you might have been right, but with that version >>> Embarcadero did a cut and we now need to adapt and live with that. >> >> I dare to disagree. A "ByteString" only requires a dedicated encoding >> (value), which makes it incompatible with other encodings, and thus >> disables all conversions. Such an encoding doesn't break Delphi >> compatibility, but allows to use all stringhandling functions with it. > > And instead of introducing yet another type or another special encoding > we could just leverage the features FPC has today and use TBytes. > Or even better, use FPC 2.6 AnsiString and UnicodeString and drop the encoding aware FPC 2.7 AnsiString. ;-) BTW, please have a look into the different string concatenation compilerproc, it is probably not so easy to model that with equal or better performance with TBytes and operator overloading. Is it possible with operator overloading to combine different types?

Did you look at the 2.7.1 or 2.6.0 implementation of these procs? If the 2.6.0 one then I suggest you to look at the 2.7.1 ones and reconsider your statement ;)

Nevertheless I'll try to do a speed measurement with TBytes and AnsiString both in 2.6 and 2.7.1. If we can improve the performance of FillChar (which would also benefit class creation btw) then this might be a rather performant alternative ;)

" <TBytes>:= <TBytes> + 'stringconstant' + <TBytes> + <AnsiString>; "

I quickly adjusted my test program:

=== source begin ===

program bytearraytest;
{$mode objfpc}
type
   TBytes = array of Byte;
operator + (aLeft, aRight: TBytes): TBytes;
begin
   SetLength(Result, Length(aLeft) + Length(aRight));
   if Length(aLeft) > 0 then
     Move(aLeft[0], Result[0], Length(aLeft) * SizeOf(Byte));
   if Length(aRight) > 0 then
     Move(aRight[0], Result[Length(aLeft)], Length(aRight) * SizeOf(Byte));
end;
operator + (aLeft: TBytes; aRight: AnsiString): TBytes;
begin
   SetLength(Result, Length(aLeft) + Length(aRight));
   if Length(aLeft) > 0 then
     Move(aLeft[0], Result[0], Length(aLeft) * SizeOf(Byte));
   if Length(aRight) > 0 then
     Move(aRight[1], Result[Length(aLeft)], Length(aRight) * SizeOf(Char));
end;
operator + (aLeft: AnsiString; aRight: TBytes): TBytes;
begin
   SetLength(Result, Length(aLeft) + Length(aRight));
   if Length(aLeft) > 0 then
     Move(aLeft[1], Result[0], Length(aLeft) * SizeOf(Char));
   if Length(aRight) > 0 then
     Move(aRight[0], Result[Length(aLeft)], Length(aRight) * SizeOf(Byte));
end;
var
   arr1, arr2, arr3: TBytes;
   b: Byte;
   i: LongInt;
   s: AnsiString;
begin
   SetLength(arr1, 5);
   for i := 0 to 4 do
     arr1[i] := i + 1;
   SetLength(arr2, 5);
   for i := 0 to 4 do
     arr2[i] := i + 6;
   arr3 := arr1 + arr2;
   for b in arr3 do
     Write(b, ' ');
   Writeln;
   arr3 := Copy(arr2, 2, 2);
   for b in arr3 do
     Write(b, ' ');
   Writeln;
   s := 'Hello World';
   arr3 := arr1 + 'stringconstant' + arr2 + s;
   for b in arr3 do
     Write(b, ' ');
   Writeln;
end.

=== source end ===

And here is what it prints:

=== source begin ===

PS P:\tests\oneshots> .\bytearraytest.exe
1 2 3 4 5 6 7 8 9 10
8 9
1 2 3 4 5 115 116 114 105 110 103 99 111 110 115 116 97 110 116 6 7 8 9 10 72 101 108 108 111 32 87 111 114 108 100

=== source end ===

Regards,
Sven

Reply by email

Sven Barth
to Martin Schreiber: True. :-) Do you think 2.7.1 FPC string handling is an improvement compared with FPC…
Martin Schreiber wrote 9 lines
Am 28.02.2012 16:52, schrieb Sven Barth: > > Did you look at the 2.7.1 or 2.6.0 implementation of these procs? If the > 2.6.0 one then I suggest you to look at the 2.7.1 ones and reconsider > your statement ;) > True. :-) Do you think 2.7.1 FPC string handling is an improvement compared with FPC 2.6.0? ;-)

Maybe not performance wise (though Sergei did quite some clean up there already and maybe will also do so in the future), but feature/internationalization wise. But I never used the code page awareness yet, so I won't comment on this ;)

Regards,
Sven

Reply by email

Michael Schnell
to Sven Barth: Before Delphi 2009 you might have been right, but with that version Embarcadero did a cut…
Sven Barth wrote
And with the way I described we can at least provide a type that handles similar to good old AnsiString, but will continue to work even if String should be changed to UnicodeString in the future.

I just did a component using Delphi < 2009 (as I don't have a greater version) and gave it to a colleague that uses XE2 who will implement it in his project.

I did

Type
   ByteString = ANSIString.
   {$if UNICODE}
     TByteStringList = TANSIStringList;
    {$else}
     TByteStringList = TStringList;
   {$endif}

So it works for both and I can happily use the type ByteString for storing uncoded 8 bit entities.

To me here the Term "ANSI" is extremely ugly, but it can be confined to a few lines on the top :) .

I do suppose that this will work in Lazarus as well (at least when adding some more ifdefs).

-Michael

Reply by email

Michael Schnell
to Hans-Peter Diettrich: I dare to disagree. A "ByteString" only requires a dedicated encoding (value), which…
Hans-Peter Diettrich wrote 5 lines
"ByteString" only requires a dedicated encoding (value), which makes it incompatible with other encodings, and thus disables all conversions. Such an encoding doesn't break Delphi compatibility, but allows to use all stringhandling functions with it.

The colleague I mentioned told me that with Delphi XE2 (but maybe nit with Delphi versions < XE2 and >= 2009) "ANSIString" _is_ exactly the "pre 2009" string type, while "String" (and friends" is the new style dynamically encode string type. As I don't have any Delphi >= 2009, I can't verify this, but at least using the assumptions produced a project workable with both our versions.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120229/2a863936/attachment.html>

Reply by email

Michael Schnell
to Sven Barth: And instead of introducing yet another type or another special encoding we could just…
Sven Barth wrote
And instead of introducing yet another type or another special encoding we could just leverage the features FPC has today and use TBytes.

I agree, if all features are in place:
- its available out of the box (in the RTL)
- it has all string functions in fully compatible way:
- can do "+" (via operator overload)
- can do pos(), copy(), delete() and friends via overloaded functions
- conversion from and to Unicode String (via operator overload ? )
- conversion to pchar (how ? )
- does reference counting, lazy copy and auto re-alloc on resizing operations.
- TByteStringList (are there more relevant string handling objects) is provided out of the box in a fully compatible and equally versatile way
- no performance degradation.

If this is not possible I vote for simply doing ByteString = ANSIString (and TByteStringList = TANSIStringList) (provided that "ANSIString" _is_ the pre 2009 String type as seemingly done in DXE).

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120229/dbeadcf0/attachment.html>

Reply by email

Martin Schreiber
to Michael Schnell
Michael Schnell wrote 18 lines
On 02/28/2012 04:13 PM, Sven Barth wrote: > And instead of introducing yet another type or another special > encoding we could just leverage the features FPC has today and use > TBytes. I agree, if all features are in place: - its available out of the box (in the RTL) - it has all string functions in fully compatible way: - can do "+" (via operator overload) - can do pos(), copy(), delete() and friends via overloaded functions - conversion from and to Unicode String (via operator overload ? ) - conversion to pchar (how ? ) - does reference counting, lazy copy and auto re-alloc on resizing operations. - TByteStringList (are there more relevant string handling objects) is provided out of the box in a fully compatible and equally versatile way - no performance degradation.

- conversion to AnsiString without move().
- conversion from AnsiString without move().

Martin

Reply by email

Marco van de Voort
to Michael Schnell: The colleague I mentioned told me that with Delphi XE2 (but maybe nit with Delphi…
Michael Schnell wrote 7 lines
> it incompatible with other encodings, and thus disables all > conversions. Such an encoding doesn't break Delphi compatibility, but > allows to use all stringhandling functions with it. > The colleague I mentioned told me that with Delphi XE2 (but maybe nit with Delphi versions < XE2 and >= 2009) "ANSIString" _is_ exactly the "pre 2009" string type

Not exactly. It has a codepage added to the record.

while "String" (and friends" is the new style dynamically encode string type.

No that is ansistring, with various values filled in for codepage. The default codepage can be set to the system 1-byte encoding (ansi), and then it is the same as the D7 one.

"string" is unicodestring, and that is always utf16.

Reply by email

Michael Schnell
to Marco van de Voort
Marco van de Voort wrote
No that is ansistring, with various values filled in for codepage. The default codepage can be set to the system 1-byte encoding (ansi), and then it is the same as the D7 one. "string" is unicodestring, and that is always utf16.

Taking a brief look at the XE2 internals you seem to be right and he he was mistaken.

Maybe he would be better off using ANSIString(0) or ANSIString($FFFF) to be sure that his doing will not be influenced by the locale setting of the system the code is compiled on or runs on.

Just _hoping_ that the code generated by XE2 for "ANSIString" will not be a lot slower that that generated by Delphi < 2009 for "String".

-Michael

Reply by email

Hans-Peter Diettrich
to Michael Schnell
Maybe he would be better off using ANSIString(0) or ANSIString($FFFF) to be sure that his doing will not be influenced by the locale setting of the system the code is compiled on or runs on.

AnsiString(0) should be okay, but other encodings may require overloaded string functions - or the string will be converted automatically.

Just _hoping_ that the code generated by XE2 for "ANSIString" will not be a lot slower that that generated by Delphi < 2009 for "String".

The XE code is the same for AnsiString(0). Other encodings are either ignored, when functions with RawByteString arguments are present, or are converted automatically what most probably causes wrong results.

DoDi

Reply by email

Michael Schnell
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 5 lines
The XE code is the same for AnsiString(0). Other encodings are either ignored, when functions with RawByteString arguments are present, or are converted automatically what most probably causes wrong results.

RawByteString = ANSIString($FFFF)

Same can't get converted to any predefined coding, as it's coding is not known.

The other part of (e.g.) a "+" can't get converted either (as there is no point in converting it to $FFFF.

No Idea what the result looks like, if it's defined by type $FFFF. If it gets some other dynamic encoding tag but $FFFF this could be considered contradicting it's type (which is ANSIString($FFFF) ), otherwise ANSIString($FFFF) could be considered "truly dynamically typed" which I remember you denied in another discussion.

Sorry that I can't test this with XE2 :( .

-Michael

Reply by email