[fpc-devel] Array of random integers
Hi,
Would a function that returns an array of unique (=non-repeating)
random integers in a certain range be accepted as a contribution to
e.g. the math unit?
I had the following function prototypes in mind:
{
Returns an array of aSize random integers without duplicates ranging from
aFrom (inclusive) to aTo (exclusive).
- aFrom and aTo must be positive integers
- aTo must be > aFrom
- aSize must be <= aTo - aFrom
- if either of these conditions is not met, an empty array will be returned.
}
function RandomArray(aFrom, aTo, aSize: Integer): TIntegerDynArray; overload;
function RandomArray(aFrom, aTo: Integer): TIntegerDynArray; overload;
function RandomArray(Range: Integer): TIntegerDynArray; overload;
function RandomArray(aFrom, aTo, aSize: Int64): TInt64DynArray; overload;
function RandomArray(aFrom, aTo: Int64): TInt64DynArray; overload;
function RandomArray(Range: Int64): TInt64DynArray; overload;
( TInt64DynArray = array of Int64)
My current implementation builds such an array of size 1 million
32-bit integers in 59 msec (on a 7 year old laptop with an i5 CPU M
430 @ 2.27 GHz with 4 GB Ram).
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Request for an interim release of the 3.0 branch
Hi, The 3.0.2 release has a serious regression: it does not generate lineinfo, at least on linux i386/x86-64. See: http://bugs.freepascal.org/view.php?id=31629 and this discussion on this ML: http://lists.freepascal.org/pipermail/fpc-devel/2017-April/037695.html The issue makes the 3.0.2 compiler almost useless for development on the affected platforms. The issue is fixed by merging r33007, 33008, 33561 and 34384 (unit exeinfo). Probably r35886 should be merged as well. I would propose to release a 3.0.2a version for the affected platforms which includes the above revisions (and probably nothing else, since AFAIK this is the only major regression). Personally I have solved it by rebuilding fpc from the 3.0.2 source with exeinfo patched. Not everybody is able to do so though, nor should we insist that an average user (let alone a novice) does so. There has been a long time period between the release of 3.0.0 (sep 2015) and 3.0.2 (feb 2017). A 3.0.4 release does not seem to be scheduled yet. Further more Lazarus also ships with the 3.0.2 release (since the Lazarus 1.6.4 release). Not being able to have proper debugging info might reflect poorly on both FreePascal and Lazarus and scare away new users, especially if it would take a long time to release a fix. The only alternative would be to advise *nix users to use the 3.0.0 release instead. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Request for an interim release of the 3.0 branch
On 4/26/17, Marco van de Voort wrote: > These revs ( but not 35886) are merged in the fixes branch a few days back > when I saw the bugreport about the issue, please test. I have tested exeinfo of r33007,33008,33561,34384 (I left all other sourcecode of 3.0.2 as is) and all these revisions generate lineinfo as expected. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
On 5/20/17, Jonas Maebe wrote: > random(x) is undefined for negative parameters. It should have had an > unsigned parameter, like in Turbo Pascal (where it is word). Delphi > defines it as always returning a positive value, but I don't know what > happens if you pass a negative parameter there. I already reported that the documentation is a bit "off": https://bugs.freepascal.org/view.php?id=31642 Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Ondrej Pokorny wrote:
> Great, I will!
My try ...
{ Try to translate HTML color code into TFPColor
Supports following formats
'#rgb'
'#rrggbb'
W3C Html color name
}
function TryHtmlToFPColorDef(const S: String; out FPColor: TFPColor;
Def: TFPColor): Boolean;
function TryHexStrToWord(const Hex: String; out W: Word): Boolean;
var
Code: Integer;
begin
Val('$'+Hex, W, Code);
Result := (Code = 0);
if not Result then W := 0;
end;
begin
Result := False;
FPColor := Def;
if (Length(S) = 0) then
Exit;
if (S[1] = '#') then
begin
if Length(S) = 4 then
begin // #rgb
Result := (TryHexstrToWord(S[2]+S[2], FPColor.red) and
TryHexstrToWord(S[3]+S[3], FPColor.green) and
TryHexstrToWord(S[4]+S[4], FPColor.blue));
end
else if Length(S) = 7 then
begin // #rrggbb
Result := (TryHexstrToWord(S[2]+S[3], FPColor.red) and
TryHexstrToWord(S[4]+S[5], FPColor.green) and
TryHexstrToWord(S[6]+S[7], FPColor.blue));
end;
end
else
begin
case LowerCase(S) of
'white' : begin Result := True; FPColor.red := $ff;
FPColor.green := $ff; FPColor.blue := $ff; end;
'silver' : begin Result := True; FPColor.red := $c0;
FPColor.green := $c0; FPColor.blue := $c0; end;
'gray' : begin Result := True; FPColor.red := $80;
FPColor.green := $80; FPColor.blue := $80; end;
'black' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $00; end;
'red': begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $00; end;
'maroon' : begin Result := True; FPColor.red := $80;
FPColor.green := $00; FPColor.blue := $00; end;
'yellow' : begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $00; end;
'olive' : begin Result := True; FPColor.red := $80;
FPColor.green := $80; FPColor.blue := $00; end;
'lime' : begin Result := True; FPColor.red := $00;
FPColor.green := $ff; FPColor.blue := $00; end;
'green' : begin Result := True; FPColor.red := $00;
FPColor.green := $80; FPColor.blue := $00; end;
'aqua' : begin Result := True; FPColor.red := $00;
FPColor.green := $ff; FPColor.blue := $ff; end;
'teal' : begin Result := True; FPColor.red := $00;
FPColor.green := $80; FPColor.blue := $80; end;
'blue' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $ff; end;
'navy' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $80; end;
'fuchsia': begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $ff; end;
'purple' : begin Result := True; FPColor.red := $80;
FPColor.green := $00; FPColor.blue := $80; end;
end;
end;
end;
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Bart wrote:
> My try ...
Forget previous post...
This should make more sense.
resourcestring
SInvalidHtmlColor = '"%s" is not a valid Html color';
{ Try to translate HTML color code into TFPColor
Supports following formats
'#rgb'
'#rrggbb'
W3C Html color name
}
function TryHtmlToFPColor(const S: String; out FPColor: TFPColor): Boolean;
function TryHexStrToWord(const Hex: String; out W: Word): Boolean;
var
Code: Integer;
begin
Val('$'+Hex, W, Code);
Result := (Code = 0);
if not Result then W := 0;
end;
begin
Result := False;
FPColor.red := 0;
FPColor.green := 0;
FPColor.blue := 0;
FPColor.alpha := alphaOpaque;
if (Length(S) = 0) then
Exit;
if (S[1] = '#') then
begin
if Length(S) = 4 then
begin // #rgb
Result := (TryHexstrToWord(S[2]+S[2], FPColor.red) and
TryHexstrToWord(S[3]+S[3], FPColor.green) and
TryHexstrToWord(S[4]+S[4], FPColor.blue));
end
else if Length(S) = 7 then
begin // #rrggbb
Result := (TryHexstrToWord(S[2]+S[3], FPColor.red) and
TryHexstrToWord(S[4]+S[5], FPColor.green) and
TryHexstrToWord(S[6]+S[7], FPColor.blue));
end;
end
else
begin
case LowerCase(S) of
'white' : begin Result := True; FPColor.red := $ff;
FPColor.green := $ff; FPColor.blue := $ff; end;
'silver' : begin Result := True; FPColor.red := $c0;
FPColor.green := $c0; FPColor.blue := $c0; end;
'gray' : begin Result := True; FPColor.red := $80;
FPColor.green := $80; FPColor.blue := $80; end;
'black' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $00; end;
'red': begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $00; end;
'maroon' : begin Result := True; FPColor.red := $80;
FPColor.green := $00; FPColor.blue := $00; end;
'yellow' : begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $00; end;
'olive' : begin Result := True; FPColor.red := $80;
FPColor.green := $80; FPColor.blue := $00; end;
'lime' : begin Result := True; FPColor.red := $00;
FPColor.green := $ff; FPColor.blue := $00; end;
'green' : begin Result := True; FPColor.red := $00;
FPColor.green := $80; FPColor.blue := $00; end;
'aqua' : begin Result := True; FPColor.red := $00;
FPColor.green := $ff; FPColor.blue := $ff; end;
'teal' : begin Result := True; FPColor.red := $00;
FPColor.green := $80; FPColor.blue := $80; end;
'blue' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $ff; end;
'navy' : begin Result := True; FPColor.red := $00;
FPColor.green := $00; FPColor.blue := $80; end;
'fuchsia': begin Result := True; FPColor.red := $ff;
FPColor.green := $00; FPColor.blue := $ff; end;
'purple' : begin Result := True; FPColor.red := $80;
FPColor.green := $00; FPColor.blue := $80; end;
end;
end;
end;
function HtmlToFPColorDef(const S: String; out FPColor: TFpColor; Def:
TFPColor): TFPColor;
begin
if not TryHtmlToFPColor(S, Result) then
Result := Def;
end;
function HtmlToFpColor(const S: String): TFPColor;
begin
if not TryHtmlToFpColor(S, Result) then
raise EConvertError.CreateFmt(SInvalidHtmlColor, [S]);
end;
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Michael Van Canneyt wrote: > Can you refactor the huge case to use a local proc? > it hurts my eyes... Yes I can. But obviously it will keep hurting your eyes, but just in a different place in the sourcecode? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Bart wrote:
Hopefully less eye-sorrow ...
resourcestring
SInvalidHtmlColor = '"%s" is not a valid Html color';
type
THtmlColorName = (
hcnWhite, hcnSilver, hcnGray, hcnBlack,
hcnRed, hcnMaroon, hcnYellow, hcnOlive,
hcnLime, hcnGreen, hcnAqua, hcnTeal, hcnBlue,
hcnNavy, hcnFuchsia, hcnPurple);
const
HtmlColorNameToFPColorMap: array[THtmlColorName] of TFPColor = (
(red: $ff; green: $ff; blue: $ff; alpha: alphaOpaque), //hcnWhite
(red: $c0; green: $c0; blue: $c0; alpha: alphaOpaque), //hcnSilver
(red: $80; green: $80; blue: $80; alpha: alphaOpaque), //hcnGray
(red: $00; green: $00; blue: $00; alpha: alphaOpaque), //hcnBlack
(red: $ff; green: $00; blue: $00; alpha: alphaOpaque), //hcnRed
(red: $80; green: $00; blue: $00; alpha: alphaOpaque), //hcnMaroon
(red: $ff; green: $ff; blue: $00; alpha: alphaOpaque), //hcnYellow
(red: $80; green: $80; blue: $00; alpha: alphaOpaque), //hcnOlive
(red: $00; green: $ff; blue: $00; alpha: alphaOpaque), //hcnLime
(red: $00; green: $80; blue: $00; alpha: alphaOpaque), //hcnGreen
(red: $00; green: $ff; blue: $ff; alpha: alphaOpaque), //hcnAqua
(red: $00; green: $80; blue: $80; alpha: alphaOpaque), //hcnTeal
(red: $00; green: $00; blue: $ff; alpha: alphaOpaque), //hcnBlue
(red: $00; green: $00; blue: $80; alpha: alphaOpaque), //hcnNavy
(red: $ff; green: $00; blue: $ff; alpha: alphaOpaque), //hcnFuchsia
(red: $80; green: $00; blue: $80; alpha: alphaOpaque) //hcnPurple
);
function TryStrToHtmlColorName(const S: String; out AName:
THtmlColorName): Boolean;
begin
Result := False;
case LowerCase(S) of
'white' : begin Result := True; AName := hcnWhite; end;
'silver' : begin Result := True; AName := hcnSilver; end;
'gray' : begin Result := True; AName := hcnGray; end;
'black' : begin Result := True; AName := hcnBlack; end;
'red': begin Result := True; AName := hcnRed; end;
'maroon' : begin Result := True; AName := hcnMaroon; end;
'yellow' : begin Result := True; AName := hcnYellow; end;
'olive' : begin Result := True; AName := hcnOlive; end;
'lime' : begin Result := True; AName := hcnLime; end;
'green' : begin Result := True; AName := hcnGreen; end;
'aqua' : begin Result := True; AName := hcnAqua; end;
'teal' : begin Result := True; AName := hcnTeal; end;
'blue' : begin Result := True; AName := hcnBlue; end;
'navy' : begin Result := True; AName := hcnNavy; end;
'fuchsia': begin Result := True; AName := hcnFuchsia; end;
'purple' : begin Result := True; AName := hcnPurple; end;
end;
end;
{ Try to translate HTML color code into TFPColor
Supports following formats
'#rgb'
'#rrggbb'
W3C Html color name
}
function TryHtmlToFPColor(const S: String; out FPColor: TFPColor): Boolean;
function TryHexStrToWord(const Hex: String; out W: Word): Boolean;
var
Code: Integer;
begin
Val('$'+Hex, W, Code);
Result := (Code = 0);
if not Result then W := 0;
end;
var
AName: THtmlColorName;
begin
Result := False;
FPColor.red := 0;
FPColor.green := 0;
FPColor.blue := 0;
FPColor.alpha := alphaOpaque;
if (Length(S) = 0) then
Exit;
if (S[1] = '#') then
begin
if Length(S) = 4 then
begin // #rgb
Result := (TryHexstrToWord(S[2]+S[2], FPColor.red) and
TryHexstrToWord(S[3]+S[3], FPColor.green) and
TryHexstrToWord(S[4]+S[4], FPColor.blue));
end
else if Length(S) = 7 then
begin // #rrggbb
Result := (TryHexstrToWord(S[2]+S[3], FPColor.red) and
TryHexstrToWord(S[4]+S[5], FPColor.green) and
TryHexstrToWord(S[6]+S[7], FPColor.blue));
end;
end
else
begin
Result := TryStrToHtmlColorName(S, AName);
if Result then
FPColor := HtmlColorNameToFPColorMap[AName];
end;
end;
function HtmlToFPColorDef(const S: String; out FPColor: TFpColor; Def:
TFPColor): TFPColor;
begin
if not TryHtmlToFPColor(S, Result) then
Result := Def;
end;
function HtmlToFpColor(const S: String): TFPColor;
begin
if not TryHtmlToFpColor(S, Result) then
raise EConvertError.CreateFmt(SInvalidHtmlColor, [S]);
end;
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Ondrej Pokorny wrote: > +Btw. there are much more name constants: > https://www.w3schools.com/colors/colors_names.asp My set is W3C compliant ... Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Ondrej Pokorny wrote: > Ah, I see you use only the W3C basic colors > https://www.w3.org/wiki/CSS/Properties/color/keywords https://www.w3.org/TR/css3-color/#colorunits Actually, adding more colornames is fine with me, itś just a tedious job ... Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, ListMember wrote: > How about this. To me it is more readable. > > type >THtmlColorName = ( > *hcnUnknown*, hcnWhite, hcnSilver, hcnGray, hcnBlack, I dismissed that idea, becuase now you would have to have an entry in HtmlColorNameToFPColorMap for hcnUnknown, which makes no sense to me. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Ondrej Pokorny wrote: > Thank you Bart & Michael! I am building FPC trunk right now :) My pleasure. It was on my private ToDo list anyway. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 37555 (Florian)
Hi,
Just nitpicking here on a Sunday evening.
"ports unit does not depend on objpas anymore", so {$Mode ObjFpc} was
removed, but the comment one line above weas left intact. It states:
{ this unit uses classes so
ObjFpc mode is required PM }
Maybe also remove the comment?
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How does one request new features?
On Mon, Dec 4, 2017 at 9:58 PM, J. Gareth Moreton wrote: > I have a little question to ask. If one wishes to request new features for a > future version of Free Pascal, > how does one go about it and what is the process of determining if it is a > good idea or should be dropped, as > well as any cross-platform and language nuances that need sorting out? ML, http://wiki.lazarus.freepascal.org/Feature_Ideas ? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How does one request new features?
On Tue, Dec 5, 2017 at 10:07 AM, Mark Morgan Lloyd wrote: > But please make sure that any wiki page is marked as being for the > discussion of a suggestion, and that it's deleted if not adopted. The wiki's > already got a maintenance problem with outmoded examples etc. As pinted out, there already is a wikipage for this kind of proposals. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FloatHelper bugs (Issue #32837)
Hi, See: https://bugs.freepascal.org/view.php?id=32837 TFloatHelper gives incorrect results for Mantissa and Exponent, also BuildUp fails. I posted a patch in the bugtracker. Can I get some feedback from a devel please? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FloatHelper bugs (Issue #32837)
On Thu, Jan 11, 2018 at 11:13 PM, Michael Van Canneyt wrote: > Patience, please. > I have seen the bugreport, but I need time to check everything. I do have patience. It took me quite some time to try and understand how all the different types of floats are stored in memory and how they work, so I don't expect you to apply my patch just on face value. Also, probably some more comparison against Delphi is needed, which I cannot do (I can't keep asking other people to build and run Delphi programs for me). But I do think it would be nice if issues with patches would get some feedback. The issue had not been acknowledged, nor confirmed or monitored by any of the devels. This is rather discouraging for people supplying patches (especially if they have enjoyed the road it took to get there). Please note that this is not meant as criticism, but as constructive feedback. Also please note that I'm currently writing in a language that is not native to me, so nuances may get lost in translation, so to speak. > I have assigned the bugreport to myself, so I won't forget. Thanks. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FloatHelper bugs (Issue #32837)
On Thu, Jan 11, 2018 at 11:59 PM, Ondrej Pokorny wrote: > IIRC, the Delphi starter edition is free of charge. It should be sufficient > for such simple tests. License for use until your individual revenue from Delphi applications or company revenue reaches $1,000 US or your development team expands to more than 5 developers My development team is the Lazarus development team, so definitely more than 5 people ;-) Does it (D Starter) behave "nice" alongside fpc? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 38008 : log entry
Hi, The log entry for revision 38008 reads: "fcl-passrc: renamed bsMethodCallChecks to bsOverflowChecks" This should be: "fcl-passrc: renamed bsMethodCallChecks to bsObjectChecks" Can someone fix the log message? Bart (I currently have nothing better to do than nitpicking over this ...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revision 38008 : log entry
On Fri, Jan 19, 2018 at 5:23 PM, Mattias Gaertner wrote: > Fixed. Nice. >> (I currently have nothing better to do than nitpicking over this ...) > > Want to help? I'll try to do whatever I can with my mediocre programming skills. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] End of support for Win XP?
On Tue, Jan 30, 2018 at 10:40 PM, Florian Klämpfl wrote: > Probably yes, at least with the release of 3.2.0. After all, Win XP is almost > for 4 years out of > support. But if somebody decides to stick with Win XP, he can stick also with > FPC 3.0.x, it will not > stop working. Just out of curiosity: is thei library loaded dynamically or statically? I expect Lazarus will want to continue support for XP for some time, if possible also with the 3.2.x version of fpc as compiler back-end. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Extended syntax and internproc?
Hi,
fpc 3.0.4 32-bit on win10.
{$mode objfpc}
{$h+}
{$EXTENDEDSYNTAX ON}
program Project1;
var
i: integer;
d: double;
begin
{i:=}sqr(i);
{i:=}sqr(d); //ilegal expression
{d:=}sin(i); //ilegal expression
{d:=}sqrt(i); //illegal expression
end.
Am I correct in assuming that internproc's do not allow dropping
function results?
Sqr(integer) is defined as internconst, sqr(valreal) as internproc.
If so, why?
Just curious.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Abs(Variant) unexpected result
Hi,
See: http://forum.lazarus.freepascal.org/index.php/topic,40223.msg277657/
This seems rather unexpected.
Is it a bug?
program v;
{$ifdef windows}
{$apptype console}
{$endif}
uses
variants;
var
X: Variant;
B: Boolean;
begin
X := -1.5;
writeln('X = ',X);
B := VarIsFloat(X);
writeln('VarIsFloat : ',B);
B := VarIsNumeric(X);
writeln('VarIsNumeric: ',B);
B := VarIsOrdinal(X);
writeln('VarIsOrdinal: ',B);
X := Abs(X);
writeln('After Abs()');
writeln('X = ',X);
B := VarIsFloat(X);
writeln('VarIsFloat : ',B);
B := VarIsNumeric(X);
writeln('VarIsNumeric: ',B);
B := VarIsOrdinal(X);
writeln('VarIsOrdinal: ',B);
end.
Outputs:
C:\Users\Bart\LazarusProjecten\bugs\Console\variants>v
X = -1,5
VarIsFloat : TRUE
VarIsNumeric: TRUE
VarIsOrdinal: FALSE
After Abs()
X = 2
VarIsFloat : FALSE
VarIsNumeric: TRUE
VarIsOrdinal: TRUE
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 1:01 PM, Michael Van Canneyt wrote: > The compiler does not know at compile time what type the variant is, how can > you expect it to choose the "right" overloaded version ? I would have expected that it will choose the right one @runtime . Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 3:40 PM, Michael Van Canneyt wrote: > Only if we add an > Abs(Variant) : Variant; which will then make the choice will this work. If the compiler accepts Abs(Variant), it should IMHO have a correct overload for this. (Maybe in the variants unit?) I don't know how Delphi behaves, but the official Delphi docs state that Abs() only has overloads for floats, integer and int64. If their compiler behaves as the docs say, Abs(Variant) would be a syntax error. I asked on Dutch Delphi forum if someone could test. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
Delphi 10.2 Tokyo: X = -1,5 VarIsFloat : TRUE VarIsNumeric: TRUE VarIsOrdinal: FALSE After Abs() X = 1,5 VarIsFloat : TRUE VarIsNumeric: TRUE VarIsOrdinal: FALSE I asked to test with "X := -1" to see if Delphi always chooses the float overload. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:01 PM, Jonas Maebe wrote: > As Michael said, overloads are selected at compile time. This is true for > both FPC and Delphi. We even have over a 100 unit tests that we ran under > Delphi to reverse engineer their selection priorities in case of variants: > https://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/variants/ > > Abs(), however, gets a forced conversion to float in Delphi: > https://bugs.freepascal.org/view.php?id=20551 Hmm, did not find that one (I searched bugtracker before posting here). Seems you are right: Delphi Tokyo 10.2 X = -1 VarIsFloat : FALSE VarIsNumeric: TRUE VarIsOrdinal: TRUE After Abs() X = 1 VarIsFloat : TRUE VarIsNumeric: TRUE VarIsOrdinal: FALSE So, would it be possible to have an overloaded Abs(V: Variant): Variant; function in the variants unit? To be clear. Personally I don't need it (at least not ATM), I'm just curious. Thanks for explaining. Bart Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:34 PM, Michael Van Canneyt wrote: >> So, would it be possible to have an overloaded Abs(V: Variant): >> Variant; function in the variants unit? > > > I advise against it. > > S : String; > > begin > S:='My very nice string'; > S:=Abs(S); > end; > > Will then compile and give a run-time error, as opposed to a compile-time > error now. Did not think about that. Yeah, that's really bad. So, all we can do is let the compiler pick the float version for Abs(Variant)? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:59 PM, Michael Van Canneyt wrote: >> So, all we can do is let the compiler pick the float version for >> Abs(Variant)? > > > It seems so. OK, for D compatibilty (untill they change that). > Better yet, don't use variants. They violate what Pascal stands > for: type safety. > > If you really _must_ use them, do any conversions explicitly. Point taken. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:34 PM, Michael Van Canneyt wrote: >> So, would it be possible to have an overloaded Abs(V: Variant): >> Variant; function in the variants unit? > > > I advise against it. > > S : String; > > begin > S:='My very nice string'; > S:=Abs(S); > end; > > Will then compile and give a run-time error, as opposed to a compile-time > error now. Suggestion from the forum: function Abs(var V: Variant): Variant; overload; begin; If (VarIsNumeric(V)) then begin if V< 0 then Result := -V else Result := V end else Raise EVariantBadVarTypeError.Create(SomeMessage); end; While this will give hints if you did not initialize V, it will not let you compile Abs(AString). Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong docs: not initialized global variables
On Thu, Apr 5, 2018 at 4:22 PM, Karoly Balogh (Charlie/SGR)
wrote:
> But again, it's zeroed out, not really "initialized". So for example if
> you have a type with say, 5..7 value range, it will still contain zero
> after start. Hence, uninitialized, therefore the warning is correct. (See
> below for examples.)
Never realized this...
> type
> qq = (foo, bar, klepp, mopp, fubb);
> q = klepp..fubb;
>
> var
> c: q;
>
> begin
> writeln(ord(c)); // will write 0;
> writeln(c); // will fail with runtime error (out of range)
> end.
>
>
> And:
>
> {$MODE OBJFPC}
>
> type
> qq = (foo, bar, klepp, mopp, fubb);
> q = klepp..fubb;
>
> type
> clfoo = class
> c: q;
> end;
>
> var
> x: clfoo;
>
> begin
> x:=clfoo.create;
> writeln(ord(x.c)); // write 0;
> writeln(x.c); // runtime error (out of range)
> end.
>
> Tested with FPC 3.0.4 32bit on macOS.
>
> I'd be interesting to know if Delphi behaved otherwise.
D7 behaves the same, except that in the 2nd example the line
writeln(x.c) cannot be compiled, so I could not test that, but the
line above prints 0.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Creating Generic Object
On Mon, Apr 16, 2018 at 7:53 AM, Sven Barth via fpc-devel wrote: >> This is very nice feature since I do not need define every Map/List/etc >> as a separate type. > Just declare a type for the specialization: The obvious (and correct answer) but, this is exactly what OP tries to avoid (if I understand OP correctly). Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Case of string
Hi,
Case of string evaluation seems to have changed from 3.0.4 to trunk.
program Project1;
{$mode objfpc}
{$h+}
var
s: string;
begin
repeat
readln(s);
case s of
'Hello', 'Hello2': writeln('In Hello');
'a'..'z': writeln('In ''a''..''z''');
else
writeln('In else');
end;
until (s = '');
end.
With 3.0.4 when the inout is 'qwerty' the output is 'In 'a'..'z'.
In trunk (r37889) the output will be:
'In Hello' for 'Hello' and 'Hello2'
'In 'a'..'z' only when the inout is 'a'
'In else' for every other input.
The 3.0.4 behaviour makes sense to me:( 'qwerty' > 'a') evaluates to
TRUE, as does ('qwerty' < 'z').
This might be unexpected to the programmer, but to me this indicates
using ranges with case of string is a bit dangerous.
The trunk behaviour makes no sense to me at all.
Is this a bug, or was it changed by design?
If the latter, why?
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64
On Wed, Apr 25, 2018 at 11:04 AM, wrote: > If you compile and run this 64-bit program on Win 64 you get a crash Confirmed on Win64 with r37885 . Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64
On Wed, Apr 25, 2018 at 11:04 AM, wrote:
> If you compile and run this 64-bit program on Win 64 you get a crash
And AFAICS your analysis of the cause (see bugtracker) is correct as well.
function fpc_frac_real(d: ValReal) : ValReal;compilerproc; assembler;
nostackframe;
asm
cvttsd2si %xmm0,%rax
{ Windows defines %xmm4 and %xmm5 as first non-parameter volatile registers;
on SYSV systems all are considered as such, so use %xmm4 }
cvtsi2sd %rax,%xmm4
subsd %xmm4,%xmm0
end;
CVTTSD2SI — Convert with Truncation Scalar Double-Precision
Floating-Point Value to Signed Integer
This should not be used to get a ValReal result.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case of string
On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel wrote: > It's a bug due to refactoring. I'll commit the fix once I got to run the > testsuite. So, I need not file a bugreport then? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Case of string
On Fri, Apr 27, 2018 at 11:05 PM, Sven Barth via fpc-devel wrote: > Nope, fixed in r38860. :) That's quick. Thanks. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Copyrighted material in bugtracker
Hi, Someone attached Delphi sourcecode to https://bugs.freepascal.org/view.php?id=33707 I think this should be removed? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On Thu, May 17, 2018 at 6:01 PM, Martok wrote: > If that gets unrolled, Result is undefined, and whatever it gets assigned to > receives the random content of r/eax. > >Grepping for "for result:=" over the FPC > source tree gives 10 matches, Lazarus has over 100 results. Can you report that to the bugtracker of Lazarus? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC trunk compiler slower than 3.0.4
On Mon, May 21, 2018 at 9:05 PM, Marco van de Voort wrote: > Afaik 3.0.x only has helpers for classes (structed types in general?), and > trunk also for other types. 3.0.4 at least has type helpers for integer/string etc. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Forbidden: https://www.freepascal.org/packages/
Hi, Not sure where to ask. I clicked on the link "Packages"on https://www.freepascal.org/ and got this: https://www.freepascal.org/packages/ Forbidden You don't have permission to access /packages/ on this server. Bug or feature? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forbidden: https://www.freepascal.org/packages/
On Mon, Jun 18, 2018 at 3:57 PM, Michael Van Canneyt wrote: > Time constraints moved this plan to > the bottom of my TODO list... :( Happens to all of us. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 39348 (Florian)
Hi Florian, I do nut really understand why you return a mantissa with the highest bit stripped off for type Extended. From what I have gathered about 80-bit extended type the mantissa of this type _is_ the full 64 bits, see http://rvelthuis.de/articles/articles-floats.html Does Delphi strip that bit off as well in TExtended80Rec.Mantissa? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revision 39348 (Florian)
On Sat, Jun 30, 2018 at 10:54 PM, Florian Klämpfl wrote: > Afaik the mantissa function is defined like this for the records, yes. They > do not include the hidden bit. Hmm, then Rudy Velthuis is wrong (or Delphi). I saw that my patch for the floathelpers caused a regression, see https://bugs.freepascal.org/view.php?id=33932. I attached a possible patch there, but I did not build a 64-bit compiler with FPC_SOFT_FPUX80 defined to see it would even compile. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function Wiki page
On Mon, Jul 9, 2018 at 6:59 PM, J. Gareth Moreton wrote: > out, not least because the answer will cause an overflow (e.g. the result of > A(4,2) has almost 20,000 decimal digits and, naïvely, takes longer than the > age > of the Universe to compute). Ackerman(4,2) = (2^65536) - 3 (it's explained int the follow up video), you can calculate that in less time than the age of the universe Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Test changes in e.g. a package
Hi, Sorry if this is a RTFM question. Whenever I make some changes to the sourcecode of e.g. a package or an RTL-file, in order to test these changes I do a make clean/make install in the root directory. (e.g. I change one line in packages/flc-registry/src/regini.inc) This takes several minutes (which especially sucks if I made a typo which leads to a syntax error). Is there a faster way to do this? Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Test changes in e.g. a package
On Wed, Jul 18, 2018 at 1:39 PM, Michael Van Canneyt wrote: > In general: no. OK I pity the compiler devels, especially in the past with slower hardware. > > But: > * if the package does not have dependencies, you can just recompile that > package. > cd packages/fcl-registry > make clean allOPT=-gl && sudo make install That failed with incompatible ppu version (make calls fpc 3.0.4) > * For units that can be tested directly, copy the unit to the directory > where your test program is, recompile&test till OK. Thanks for the explanation. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] SizeOf( const typcasted as shortstring)
Hi,
This came up in http://forum.lazarus.freepascal.org/index.php/topic,42179.0.html
const
x = ShortString('abc');
begin
writeln(SizeOf(x));
end.
Delphi (7) prints 256, fpc prints 3.
Is that a bug or an implementation detail?
Just curious.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Attn. Florian, r39759
Hi, > optimize (v>=x) and (v<=y) into (v-x)<(y-x) If the commit does what this says, it is incorrect for the case that x=v=y: (v>=x)=true, (v<=x)=true, (v-x)<(y-x) translates to (0<0) wich is false. See https://bugs.freepascal.org/view.php?id=34292 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] String.Split inconsitent behaviour if Separators is [chars] vs [strings]
Hi,
Consider this example:
program split;
{$mode objfpc}
{$h+}
uses
sysutils;
var
S: string;
A: TStringArray;
i: Integer;
begin
S := '1 2 3 4 5';
A := S.Split([#32],'"');
writeln('S = ',S,', Separators = #32');
for i := Low(A) to High(A) do writeln(format('%d: "%s"',[i,A[i]]));
writeln;
S := '1\n2\n3\n4\n5';
A := S.Split(['\n'],'"');
writeln('S = ',S,', Separators = \n');
for i := Low(A) to High(A) do writeln(format('%d: "%s"',[i,A[i]]));
end.
Output:
S = 1 2 3 4 5, Separators = #32
0: "1"
1: "2"
2: "3"
3: "4"
4: "5"
S = 1\n2\n3\n4\n5, Separators = \n
0: "1"
1: "2"
2: "3"
3: "4"
I would expect the output would be the same for both versions of split?
The "string" version misses the last one?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] String.Split inconsitent behaviour if Separators is [chars] vs [strings]
On Sat, Sep 29, 2018 at 11:22 PM Sven Barth via fpc-devel wrote: > Please report as bug. Done: https://bugs.freepascal.org/view.php?id=34359 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] String.Split inconsitent behaviour if Separators is [chars] vs [strings]
On Sun, Sep 30, 2018 at 11:15 AM Michael Van Canneyt wrote: > Fixed. Thanks for reporting it. Thanks for fixint it. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Issue #0034277: ptop put operators on different lines
Can somebody review my patch please? And while we're at is: also for issue #0034285: ptop: silence hint about unused parameter. Bart -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stringlist customsort
On Fri, Nov 30, 2018 at 2:29 PM Andrea Mauri wrote: > if TStringList sort will be changed, please take into account the issue > related to randomised pivot initialisation in TStringList sort and the > consequences to Random sequence > (http://forum.lazarus-ide.org/index.php?topic=43257.0). https://en.wikipedia.org/wiki/Quicksort#Choice_of_pivot suggest to either use a random value as pivot or the mean of the first, middle and last element. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux compilation question
On Fri, Nov 30, 2018 at 3:41 PM J. Gareth Moreton wrote: > /usr/bin/diff ppc3 ppcx64 > Binary files ppc3 and ppcx64 differ > > And then it drops out. I've tried the usual things of doing a "make > distclean", but am I missing something obvious? Preliminary Linux testing is > the only thing I'm missing before I'm ready to present a patch. Works for me here. svn co https://svn.freepascal.org/svn/fpc/trunk . make # after succesfull make: make clean all Fpc r40425, on Linux Mint 18.2 64-bit using fpc 3.0.4 as starting compiler. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: Re: fpc-devel Digest, Vol 175, Issue 29
On Sat, Dec 22, 2018 at 1:03 PM Franz Müller wrote: > But maybe there is an easy way to save the state of the random number > generator routine before sorting and to restore it when the sort is done? Save RandSeed and restore it after you're done with your calls to Random. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements
On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: > - If a case statement on an ordinal does not contain labels for all values of > the ordinal, and no else statement is given, raise a new warning (W6059). This > is actually defined as an error in ISO7185 and a dynamic-violation in > IEC10206. So now I will have to add a useless else statement for every case statement that uses e.g. integers, or rewrite them to if..then..else or if value in [...]? And how will I mage this when my code runs on different architecture where the full range of the ordinal may differ? Please no (to this part of the proposal). Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements
On Wed, Jan 2, 2019 at 11:22 AM Florian Klämpfl wrote: > Which ordinal changes in FPC its range depending on the architecture? Integer is not the same range on 16-bit platform IIRC? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpc calls crosscompiler from older version
Hi, All of this is of course of my own doing but is it expected? I built and installed fpc trunk, just the 32-bit version. I have 3.0.4 32-bit, and for that release I also have the win32-win64 cross-compiler installed. Having forgotten that I did not build the win32-win64 cross-compiler from trunk, I issued a fpc -TWin64 -Px86_64 test.pas. My path looks like C:\pp\bin\i386-win32;%oldpath% (Trunk resides in C:\pp\bin\i386-win32) And, as you can guess, the path to the 3.0.4 binaries is on %oldpath% And, lo and behold, fpc trunk executed the cross-compier from 3.0.4. I can understand why. But, is this desired behaviour? A message that no cross-compiler for the current version of the compiler was installed would make a little more sense to me. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc calls crosscompiler from older version
On Thu, Jan 3, 2019 at 6:36 PM Florian Klämpfl wrote: > The fpc executable has not to match with the real compiler executable. By design? I find that a bit odd. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc calls crosscompiler from older version
On Thu, Jan 3, 2019 at 7:06 PM Tomas Hajny wrote: > By design or not, the fpc executable holds no version information as of > now, IIRC. OK. > Obviously, it might be changed if needed. The question is if people really > want such a warning. Probably not, since I'm the first one to raise this ;-) > Note that it would work only if you rebuild the fpc > executable as well, so I'm not sure if it would make any difference in > your scenario. Well, I would think that make all, followed by make install would generate a new fpc.exe as well. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc calls crosscompiler from older version
On Fri, Jan 4, 2019 at 12:03 AM Tomas Hajny wrote: > In any case, _if_ doing it, I would do it by adding -Fu and -Fi pointing > to the upper (i.e. compiler) directory to the Makefile rule for building > the fpc executable, adding a possibility to pass the version information > from fpc to the respective compiler by adding something like '-V?' + > full_version_string to PPCCommandLine _if_ -V parameter has not been > passed to the fpc executable already (it wouldn't make much sense > otherwise), adding a new warning message to msg/errore.msg and adding > handling of the new parameter to options.pas in the compiler directory. > Obviously, it would only work for compiler versions having this > functionality included, i.e. you couldn't safeguard against having really > old versions invoked that way. That sounds like too much of a hassle. Thanks for explaining. I'll just try to remember to build and install the cross-compiler as well when I build trunk. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Compiler directives in getopts unit
Hi,
I'm trying to fix an issue in getopts unit.
I noticed some (ancient?) compiler directives:
{$IFNDEF FPC}
{$ifdef TP}
uses strings;
{$else }
uses SysUtils;
type PtrInt = Integer;
{$endif}
{$ENDIF FPC}
{$IF not Declared(argv)} //{$ifdef TP}
type
ppchar = ^pchar;
apchar = array[0..127] of pchar;
var
argc : longint;
argv : apchar;
{ create argv if running under TP }
{$ifndef FPC}
setup_arguments;
{$endif}
It seems this code at one time needed to be compilable with TP.
AFAIK TP however does not support {$IF CONDITION} nor the Declared()
macro(?), so the source should not be compilable anymore with TP?
The unit is still compileable with Delphi (7) though.
Question is: do we need to keep that in?
I don't think it is possible anymore to bootstrap the compiler with
anything other than FPC?
As for the {$IF not Declared(Argv)} part: does that apply to a target
that FPC supports or is also there just to be able to compile it with
Delphi?
If we keep it, then at least the comments should be updated.
Bart
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Detecting SSE and AVX compiler options
On Sun, Feb 3, 2019 at 7:28 AM J. Gareth Moreton
wrote:
> {$ASMMODE ATT}
> function floor64(x: float): Int64; assembler; nostackframe;
> asm
> roundsd %xmm0, %xmm0, $0b101 { Round towards negative infinity }
> cvttsd2si %xmm0, %rax { Convert to integer... equivalent to Trunc() }
> end;
I might be totaly wrong here, but wouldn't that (rounding towards
negative infinity) produce wrong results for negative floating point
numbers?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Issue 34851 (TBits.OpenBit)
Hi, Can some devel look at https://bugs.freepascal.org/view.php?id=34851 (and please ignore the input of Thaddy). Current implementation is not Delphi compatible. A sample project is available. Martok supplied a patch which seems to resolve this. It would be nice if it could go in 3.2.0, given that Lazarus relies on it. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue 34851 (TBits.OpenBit)
On Sun, Feb 3, 2019 at 3:08 PM Marco van de Voort wrote: > Checked,committed, merged. Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I'll be straight
On Sat, Feb 9, 2019 at 9:35 AM J. Gareth Moreton wrote: > I guess I can get a bit impatient, Reaction time on ptaches in the fpc part of the bugtracker is rather long (especially when compared to the lazarus part of the bugtracker), I find that discouraging as well. I have had patches (simple ones for RTL or packages) waiting there for months without feedback, even after asking for it on this ML. I can see that it must be even more frustrating when you supply lot's of ideas and possible patches (I only did a few, most likely less than 10). Also the bugtracker could do well with a little more active management (moving issues to another project, confirming a bug, setting relationships: in my experience it is lacking behind a bit). Anyhow, in my experience with this project so far, if keep you supplying good patches, you wil get feedback (and help if needed), so don't give up.. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I'll be straight
On Sat, Feb 9, 2019 at 6:33 PM Michael Van Canneyt wrote: > This is not intentional. It can happen we don't see bugs. Of course this can happen, it happens on the lazarus side as well. > And I recall distinctly saying several times that you can mail directly if > you see no-one is reacting. You very may have. That however feels a little bit to intrusive to me (I can't blame you for that now, can I?). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TRegistry fixes
Hi, The new (W-API based) TRegistry in trunk and 3.2 fixes has some problems on Windows, amongst which at least one regression. https://bugs.freepascal.org/view.php?id=35060 The use of Utf8Decode on strings that are not guaranteed to be CP_UTF8 is wrong. As a result Keys with unicode characters in their name cannot be read anymore (nor written to). (This is a regression) https://bugs.freepascal.org/view.php?id=34876 The implementation of ReadStringList/WriteStringList treats a sequence of Unicode chars (WideChar) as if they were AnsiChar (a.o.). https://bugs.freepascal.org/view.php?id=35022 TRegIniFile writes data to the wrong Key. All these issues have patches and sample programs attached. The patch for https://bugs.freepascal.org/view.php?id=35022 also resolves https://bugs.freepascal.org/view.php?id=35023 and https://bugs.freepascal.org/view.php?id=33980 Attached to https://bugs.freepascal.org/view.php?id=35022 is also a test, intended to be added to tests/test/packages/fcl-registry. (Currently the only test there is a trivial one.) I can try to write tests for the other issues as well, but verifying in code that WriteStringList yields the correct result may be a little tricky, because it would depend on ReadStringList. The patch for that issue will write a StringList and read that back again and regedit does not complain that data is wrong. It would be very nice if some devel who actually uses Windows (and has at least rudimentary knowledge of the use of TRegistry) can have a look at it and give some feedback. Especially since these bugs will be in the upcoming 3.2.0 if they are not fixed (and merged). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry fixes
Thanks for the respons (all of you). I'll wait for feedback in the bugtracker issues then. I'll inform frustrated parties on the forum as well. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem while using free pascal
On Thu, Feb 14, 2019 at 10:17 PM 陳悅(2018-19) 3E04 CHAN YUET wrote: > > Dear sir > I am sorry yo informed you that there is a problem while I am using the free > pascal app. While I try to open the app, it just flashes, while I click a few > more times it just keeps flashing. You are probably creating and running a console program (as opposed to a GUI program) and double-click on the executable in Windows Explorer to run it. This will open a console window, run the program and close the console window again. Either: - start cmd.exe and run the program from there, or - as the last statement add readln; (just before the final end.), the th eprogram will not teerminate until you press enter (and only aftre that the console window will get closed. There questions are better asked on the forum or on the fpc-pascal mailing list. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TRegistry and Unicode
Hi, I'm currently involved in some TRegistry bugs and regressions. Personally I don't use TRegistry in any of my programs. Also I mostly use Lazarus, so most most of the issues don't affect me. However I would like to share som observations and thoughts. TRegistry on Windows now (3.2+) uses Unicode API. String input parameters in the various methods get "promoted" to Unicode and then the API is called. Returned string values however are mostly encode in UTF8, by explicitely calling Utf8Encode(SomeUnicodeString). Is that (enforce UTF8 encoding) by design? (The Ansi to Unicode was done via UTF8Decode which is definitively wrong and is fixed by now.) On Lazarus, this no problem, since by default all strings are UTF8 encoded, so all conversions are lossless. In a plain fpc program though on Windows, default encoding is the current codepage (cp1252 in my case) and information will get lost when you process the result further. On non-Windows platforms all data in the registry is (supposed to be) UTF8-encoded in a XML file. Since the registry interfaces with a Unicode API (Windows) or UTF8 API (all other platforms), would it maybe make sense to use UnicodeString parameters throughout TRegistry? (UnicodeString because this is primarily used on Windows, otherwise I'ld suggest UTF8String.) Now all conversions from and to UnicodeString are hidden from the programmer, so he/she cannot know that dataloss due to conversion may occur. Using UnicodeString parameters will make the caller aware (if he/she uses AnsiStrings as parameters) that conversion will happen. Pro's - simpler and more consistent code in the Windows implementation of TRegistry - awareness of conversion for the programmer Con's - people will complain about the warnings - XMLReg implentation needs Utf8Encode/Utf8Decode (currently there is no conversion there: even if system codepage is not UTF8, the XML file claims it is, so this might be wrong as is) - UnicodeStrings are slower (my guess is that acessing the API itself is slower than the Pascal code in the registry methods) - We do not have a Unicode TStringList (for ReadStringList/WriteStringList methods) Whilst I know that hardly any fpc devel uses TRegistry, without getting your thoughts and opinions on this matter it makes no sense to suggest patches implementing such a big change. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Tue, Feb 26, 2019 at 11:04 AM Michael Van Canneyt wrote: > If I understood the OP correct, he wants to change the use of "string" > arguments in the public API to unicodestring. > > That changes a lot. And that's why I asked here first. > (See e.g. https://bugs.freepascal.org/view.php?id=35113 > for a similar situation where part of the error is that the lazarus > user must explicitly call Utf8Decode.) In Lazarus (with UTF8hack) assigning a UnicodeString to an AnsiString will call Utf16ToUtf8 on the implicit conversion. So, explicitely calling Utf8Encode should not be necessary. > So my proposal is to leave the public API as-is, using string, adding This leaves my initial "itch": input strings are CP_ACP (so can be anything), output strings are CP_UTF8 always. Why do we convert: SomeUnicodeString := SomeAnsiString (implicit conversion using WideStringManager) but SomeAnsiString := Utf8Encode(SomeUniCodeString) (explicit conversion bypassing WideStringManager) IMHO this is rather inconsistent and it makes no sense from the viewpoint of "pure" freepascal users. (Again: Lazarus users don't care one way or the other.) E.g. compare that to FindFirst with AnsiString: it implicitely converts Ansi- to UnicodeString and lets the WidestringManager handle the conversion back to AnsiString. > unicode string overloads where possible/useful. That would mean overloading almost all methods. Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Tue, Feb 26, 2019 at 2:12 PM Michael Van Canneyt wrote: > But inner workings can be made to use Unicode, because the underlying APIs > are using unicode: The *W registry calls on windows, XML DOM on other systems. Well, my argument is that since we interface explicitely with a UnicodeString API, then why not expose that to the programmer? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Is this a bug?
Reported in forum:
http://forum.lazarus.freepascal.org/index.php/topic,44466.msg312583.html#msg312583
{$mode objfpc} //same in mode delphi, did not test others
procedure DoIt(ar: array of const);
begin
try
exit;
finally
end
end;
begin
DoIt([]);
end.
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -gh -gl -TWin64
-Px86_64 test.pas
Free Pascal Compiler version 3.3.1 [2019/02/27] for x86_64
...
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
Marked memory at $000BD9E0 released
Call trace for block at $000BD9E0 size 0
$0001581B fpc_getmem, line 362 of ../inc/heap.inc
$00011668 DOIT, line 6 of test.pas
$000116E1 main, line 15 of test.pas
$000116F6 MAIN_WRAPPER, line 126 of system.pp
$0001A6D0 EXE_ENTRY, line 240 of system.pp
$000115F0 _FPC_MAINCRTSTARTUP, line 106 of sysinit.pp
$7FFF523F3DC4
$7FFF525A3691
was released at
freed again at
$0001C31D INTERNALFREEMEMSIZE, line 712 of ../inc/heaptrc.pp
$0001C5B4 TRACEFREEMEMSIZE, line 768 of ../inc/heaptrc.pp
$0001C676 TRACEFREEMEM, line 808 of ../inc/heaptrc.pp
$0001583B fpc_freemem, line 367 of ../inc/heap.inc
$00011622 fin$0002, line 12 of test.pas
$000116A0 DOIT, line 6 of test.pas
$000116E1 main, line 15 of test.pas
$000116F6 MAIN_WRAPPER, line 126 of system.pp
Heap dump by heaptrc unit of
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\test.exe
1057 memory blocks allocated : 136508/136560
1057 memory blocks freed : 136508/136560
0 unfreed memory blocks : 0
True heap size : 196608 (192 used in System startup)
True free heap : 196416
(It also crashes if heaptrace is not used)
It crashes with 64-bit fpc 3.0.4 and trunk.
It does not crash with 32-bit fpc (3.0.4 or trunk) on Windows, nor
does it crash with fpc 3.0.4 64-bit on Linux.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this a bug?
On Wed, Feb 27, 2019 at 5:24 PM Bart wrote: Tested with fpc r41352 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Tue, Feb 26, 2019 at 10:49 AM Marco van de Voort wrote: > If I look into e.g. registry.pp, the only use of utf8encode there is > like this: > > var s : string; > > u:unicodestring; > > s:=utf8encode(u); > > which, IF lazarus is used in the default utf8 mode is equivalent to > > > s:=u; > > So currently this utf8encode only frustrates the situation for people > that don't set the default codepage to utf8? Exactly. It also breaks backwards compatibility. Strings returned were encode in the systems codepage up to 3.0.4, now thy are not. There will be programs out there that access individual chars of those returned string parameters, and they will now fail for any character that is not lower ascii (7-bit ascii). Also it makes no sense to return strings in UTF8 and not require input strings to be encoded the same. The argument that reading a string is now unicode proof also makes no sense to me, since, unless your systemcodepage is UTF8, there is no way to write a unicode character back to registry. If we need that, we need overloaded methods with either Utf8String or UnicodeString parameters. I don't mind leaving the registry functions using plain ansistrings, but then let go of the idea it could support Unicode if your systemcodepage is not UTF8. B.t.w. enforcing UTF8 on the results rather complicates the code for returning a TStringList. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote: > The utf8encode should go, just like the utf8decode's that we fixed already. Shall I post a patch in the bugtracker? If so: instead of SomeAnsiString := UTf8Encode(SomeUnicodeString) do I make it an implicit conversion (SomeAnsiString := SomeUnicodeString), or an explicit typecast (suppressing warnings: SomeAnsiString = String(SomeUnicodeString))? As a side note: I now have several patches for the registry in the bugtracker, and it gets increasingly difficult to make new patches for each issue if the "previous" (as in: the ones I made earlier) don't get applied. Bart -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sat, Mar 2, 2019 at 5:53 PM Bart wrote: > As a side note: I now have several patches for the registry in the > bugtracker, and it gets increasingly difficult to make new patches for > each issue if the "previous" (as in: the ones I made earlier) don't > get applied. Applying the patch for this should if possible be done after applying the patch from https://bugs.freepascal.org/view.php?id=35022 (that patch references a line with Utf8Encode still in it, so it possibly can't be applied anymore if that line no longer exists). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sun, Mar 3, 2019 at 11:17 AM Yuriy Sydorov wrote: > This is good if you assign the result of ReadString() to a regular ansistring > var. But if you assign it to a > utf8string,unicodestring,widestring var - it will not return correct result > for chars that are missing in the current > system code page. This is bad for a user app which is using unicodestring > everywhere and don't bother with ansistrings > and their default code page. Did you actually read this entire thread? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 4, 2019 at 12:16 PM Marco van de Voort wrote: > There is no need to further change interfaces to provide yet another > option which does yet another option which is useful for only a limited > time. So, where to go now from here? 1. Leave all method signatures unchanged (use plain string variables) and cut out all the Utf8Encode(). Then wait for the time that string=unicodestring? 2. Cut out Utf8Encode(), overload all methods with ansistring parameters to accept either UTF8String or UnicodeString parameters? 3. Do nothing at all? Option 1: + easiest fix. + consistent with most other "interfaces" (for lack of a beter word). + no data los with Lazarus unicode hack. No dataloss on any system that has CP_UTF8 as it's sytem codepage (most *nix). + at least one person is willing to provide such a solution. - possible data loss on Windows in plain pascal programs. Option 2: + solves the issue of possible data loss cross-platform + makes no difference for Lazarus users. + at least one person is willing to provide such a solution. - clutters the interface - when string becomes unicodestring (like Delphi) (if ever?), the ansistring methods need to be removed (or parameters must explicitely typed as AnsiString) Option 3: + no change required - no problem solved - leaves inconsistent interface From my previous posts on this topic (here and in bugtracker) it will be clear that I am strongly opposed to solution 3. We should at least do something. As it is now, the registry has bugs and regressions (as compared to 3.0.4) If nothing is done, then most likely Lazarus will fork the TRegistry to at least be able to fix current issues. This is a situiation that should be avoided IMHO. A decision needs to be made... -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 12:59 PM Marco van de Voort wrote: > 1+2. Reverse manual enforced encoding, and honour the codepage in the > default string type. (2 sort of implies 1 as well...) > If unicode MUST be supported on windows without lazarus hack, convert > the interface to unicodestring. (or maybe overload, but I would just > convert it all) Well, convert to unicodestring was my initial proposol, but this was dismissed in this discussion. Overloading may make all users (except the maintainers of this code) happy? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt wrote: > Please add overloading using UTF8String. > Backwards compatibility is not an idle word. To be honest, that last sentence does not make sense to me. Before trunk TRegistry used (on Windows) the A-API and string parameters are just AnsiString(CP_ACP). Unicode caharcters were not supported in plain fpc programs using the default 1 byte encoded string type on Windows. Introducing Utf8Encode (and the plain wrong Utf8Decode) in TRegistry is backwards incompatible. Reverting this to using plain String does not introduce any backwards (compared to 3.0.4) incompatibilty AFAICS. (Unicode support in plain fpc programs simply is not there (unless you use the appropriate string type). There is a reason for the Lazarus UTF8-hack.) Introducing UnicodeString overloads does neither introduce regressions AFAICS. If it would have worked with A-API it certainly will work with UnicodeString, because the characters would have been inside the users codepage. It does however add unicode support for plain fpc programmers for those who need that. All would still be completely unicode-proof in Lazarus (with UTF8-hack). Using UTF8String would trigger 3 conversions instead of 1 (plain fpc programs): string->utf8string->unicodestring (the last conversion is inside the methods where we call the W-API). Using UnicodeString would trigger only 1 conversion: String->UnicodeString. For users using Utf8String inside there program calling the UnicodeString overload would also be just 1 conversion (lossless). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 12:59 PM Marco van de Voort wrote: > If unicode MUST be supported on windows without lazarus hack, convert > the interface to unicodestring. (or maybe overload, but I would just > convert it all) And then there is of course ReadStringList/WriteStringList. Unless your systemcodepage is UTF8, dataloss will occur with characters outside your codepage. There does not seem to be a proper solution for that without enforcing a UTF8 encoding on the individual strings (you cannot simply set Text property for that). AFAIK we don't have a TUnicodeStringList? In hindside, with this Unicode problem in mind, using a TStringArray would have been better. AFAIK Delphi does not implement a ReadStringList/WriteStringList. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 4:10 PM Michael Van Canneyt wrote: > So, what do you propose for maximum backwards compatibility ? > > By this I mean, for people that basically use plain strings and ASCII, they > should not get warnings about > 'conversion from widestring to ansistring' and vice versa. I see. If I have in unit registry: procedure TRegistry.A(S: String); var u: UnicodeString; begin u := S; A(u); end; procedure TRegistry.A(U: UniCodeString); begin ... end; and then in my program: var S: String; R: TRegistry; .. R.A(S); And given that the procedures A are part of fpc distribution, and the path to the source is NOT in your search path for the compiler (i.o.w. just a regular fpc user, not someone who builds fpc) then the end-user (the programmer) would not see that warning if I'm correct? When building fpc I get tons of conversion warnings that I don't get when I simply build my program. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 6:28 PM Michael Van Canneyt wrote: > Ideally, they should all be fixed. They are all potential sources of error. You can't have it both ways: use CP_ACP string and expect them to be able to handle Unicode outside of their codepage, unless your codepage is UTF8. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 8:39 PM Michael Van Canneyt
wrote:
> Not sure I follow you ?
>
> If somewhere there is a warning about conversion of unicodestring to
> ansistring (often abused as single-byte string) then this must be looked at
> and somehow
> fixed.
>
> This can mean changing the single-byte string type to UTF8String and doing a
> UTF8Decode/Encode.
> Needs to be checked on a case-by case basis.
Initially I replied to you saying it (have overloads with plain string
and unicodestring) wasn't backwards compatible.
I then tried to point out to you that the past (the back in backwards
compatibilty) was that string was a single byte enocded type and on
Windows each character was just one byte and since there are only 256
possible characters this way codepages exists and you cannot represent
e.g. a Russian character in a Wester European codepage.
The main point here being that each singe byte represented a character.
Now Lazarus from the start has treated AnsiString as if it were UTF8.
For people who are not used to this, this is a really big difference.
Using UTF8String in TRegistry instead of String forces users to
consider the fact that returned strings are Utf8Encoded now always,
even if they (probably most of them) do not need that because what
they retrieve from and put in the registry fits into their codepage.
And somebody out there will have code that checks if
ReturnedString[Index] = #$E4 ("ä" in my codepage), and have the
sourcefile in ANSI (system codepage), and now this will fail, because
that character will now be made up of 2 bytes.
All that lead me to say that you cannot have Unicode in (classic)
1-byte encoded, (using default system codepage) strings.
Using UnicodeString/String overloads means that "old style" programs
still function as the did before and anyone who needs it can use the
UnicdeString variant directly.
And if you system codepage happened to be UTF8 in the first place, you
don't care either way.
Anway, i am starting to repeat my previous arguments.
So either I am unable to make myself clear, or I'm just plain wrong.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote:
> If you declare a function result as utf8string instead of string (ansistring)
> then automatic conversion will be
> performed when you assign the result of the function to a variable of type
> string (ansistring). You will gen a classic
> 1-byte per character string if your current encoding is 1-byte encoding.
> I mentioned this earlier.
I know that, but you do not need to assign the functionresult to
another string to investigate it.
Stupid example:
program test;
function x: utf8string;
var
u: unicodestring;
begin
setlength(u,3);
word(u[1]) := $E4; //my editor is UTF8 so therefore this workaround
instead of u := 'äëï';
word(u[2]) := $EB;
word(u[3]) := $EF;
result := utf8encode(u); //äëï but now Utf8Encoded
end;
var
u8: utf8string;
begin
u8 := x;
if byte(u8[1]) = $E4 then writeln('OK') else writeln('Fail');
end.
It prints Fail, where it would have printed OK if x would have returned string.
This a corner case, but it definitely is a regression nevertheless.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Thu, Mar 7, 2019 at 6:30 PM Yuriy Sydorov wrote:
> Of course if "u8" is utf8string, then then first char will be encoded as a
> 2-byte pair. But if you change "u8" to be
> just "string" or "ansistring", then the first byte would contain "ä" if the
> current ansi code page supports it (eg cp1252).
> It is perfectly backward compatible.
Sorry, wrong example.
Querying the result without assigning it to a variable will fail (I
tried to say that in my previous post):
program test;
function x: utf8string;
var
u: unicodestring;
begin
setlength(u,3);
//00E4 00EB 00EF
word(u[1]) := $E4;
word(u[2]) := $EB;
word(u[3]) := $EF;
result := utf8encode(u);
end;
begin
if byte(x[1]) = $E4 then writeln('OK') else writeln('Fail');
end.
This would have written OK if x (e,g, TRegistry.ReadString()) returned
string instead of UTF8String.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote: > The utf8encode should go, just like the utf8decode's that we fixed already. > > Regards, > > Joost. I posted a patch in https://bugs.freepascal.org/view.php?id=35213. Again: please first aplply the patch from https://bugs.freepascal.org/view.php?id=35022 first, since that patch references code that has UTF8Encode in it. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
> No. > > Please, a single patch with full solution for unicode & ansistring. You misundersdtand me here, I think. The patch I mentioned does not concern the Unicode issue at hand. The patch file however has a chunk of unaltered code in it, and in _that_ code there is one Utf8Encode. If the patch to remove Utf8Encode (https://bugs.freepascal.org/view.php?id=35213) is applied before the patch in https://bugs.freepascal.org/view.php?id=35022 , that latter one becomes invalid, since it references a code-block that is no longer there. If however, OTOH, you do no want to apply the patch from https://bugs.freepascal.org/view.php?id=35213 because you want an "all containing" patch for that issue, I am a bit puzzled: 1. The proposed patch resolves a regression. This in itself is IMHO a reason to apply it as is. 2. Joost applied the patch to remove Utf8Decode. 3. From what I get from this discussion, there still is no communis opinio on how to implement full unicode support in TRegistry (use Utf8String or UnicodeString overloads for the TRegistry methods). 4. IMO breaking up this process in steps, will make it easier to see why a particular line of code was changed. (The "full solution" seems to be come a rather large and complicated diff. I have already written tests for this issue. I am willing to write more. > It becomes increasingly difficult to estimate the consequences of all this. For me it becomes increasingly difficult to work on the patches for the various TRegistry bugs in the bugtracker if none of the patches there get applied. This is frustrating since currently there seem to be only 2 persons who are prepared to write fixes for TRegistry (Serge Anvarov and me). I get the feeling this subject is just not "sexy" enough. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt wrote: > It does not resolve a regression. Yes, it does and I showed it here. > The current behaviour is a bugfix for a reported bug. And it did that the wrong way. Calling Utf8Decode on a string without checking it is indeed Utf8 encoded is plain and simply wrong. I may be totally wrong here, but form the discussion with you I get that you find the String <-> UnicodeString conversions are wrong, because they can cause data loss with strings not encode as UTF8. On the other hand you argue that "The use case of a non-lazarus command-line application is so minor that this can wait for a proper solution for unicode." The combination of these arguments does not make sense to me. Lazarus programs will not suffer from dataloss in the String<->UnicodeString conversions, because all strings in Lazarus are UTF8 encoded. The sample program in the bugreport that lead to this mess (https://bugs.freepascal.org/view.php?id=32185), would also have been solved without the Utf8Decode/Utf8Encode (the sample program is a Lazarus GUI program, so it includes the Lazarus Utf8-hack). AFAICS cutting out the Utf8Decode/Utf8Encode fixes a regression and does not introduce a new regression: all this when compared to behaviour in 3.0.4. The net result of all of this discussion is that I am getting frustrated. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt wrote: > I don't ever use the registry, so in that sense you are right it is indeed > not sexy enough to worry about it :-) Neither do I use it... Long time ago I wrote a patch for some other part of the RTL. The old behaviour was plain wrong and resulted in wrong data. When I wrote a patch that fixed the issue (string conversion into some other data type), I was told was that the old implementation was faster and therefor better. I'm kind of feeling the same way now. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 11, 2019 at 12:37 AM Michael Van Canneyt wrote: > What's the problem ? The problem is that you make me feel that evreything I do or think of is wrong. Most likely this would not be the case if we were in the same room and talked about it. Another practical problem is that we (as in the participants in this thread) still have not decided which way to go with this. Do we want overloads for all public/protected TRegistry methods that use UnicodeString or Utf8String, or both, or none of that? > For organizational reasons, I personally prefer a single patch that > implements what I consider correct, and not a series of incremental > patches each addressing part of the problem. I understand that, but ATM it is almos undo-able for me to work on the registry. Every time I work on one issue I have to revert all chages I made for other issues. This becomes very cumbersome, very fast. If I start writing the "all including" unicode patch for TRegistry it will include unrelated fixes, otherwise I cannot test what I'm doing. IMO, since this is trunk, patches need not be perfect in order to be apllied, they just need to be better than the old situation. Of course judging that is up to the devels. Apply and then gradualy better the code based on feedback. Once "good enough" merge all fixes to 3.2 branch. Another problem for me is the not-windows part of the registry. E.g. TRegIniFile in the XML implementation is totally broken for at least 6 years. Nobody has posted a bugreport about that in that period. Now that comes to bite me in the *** when I fix some bugs in the windows implementation of TRegIniFile. Fixing the XML implementation of that is currently beyond my capabilities. (In my personal opinion I'ld get rid of the not-windows implementation of TRegInifile. Yes it is backwards incompatible, but there cannot be users out there using it, otherwise bugreports would have been filed.) > So, please carry on. Someone will eventually apply the patches! I will try to. B.t.w. Michael: you unassigned yourself from https://bugs.freepascal.org/view.php?id=35213 and https://bugs.freepascal.org/view.php?id=35022 , but you forgot to change status to either new, acknowledged or confirmed. Now the issues are still "blue" in the bugtracker, so every other devel will think the issue is assigned to some other devel. Can you please adjust the status of the issues? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt wrote: > Sorry to hear this. > That was certainly not my intention, on the contrary: I am glad to see that > someone takes the time to look at some of these bugs in earnest. Thanks. > From my perspective: the public API is all that matters. > There I would opt for overloads that accept unicodestring. I can work on that. > Probably because no-one in his right mind uses TRegIniFile ? +1 > TRegIniFile is a component from Delphi 1 or 2, to facilitate the transfer > from ini -> registry which was relevant in 1995 or thereabouts. > > Maybe we should simply ditch it, or move it to a separate unit and mark it > deprecated. I agree. > > Can you please adjust the status of the issues? > > I did so. Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt wrote: > Probably because no-one in his right mind uses TRegIniFile ? Mind you, the reason I looked into it was that on the forum somone actually reported it not working as expected. So clearly there are (left-minded?) people out there using it (on Windows that is). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 11, 2019 at 8:17 PM Michael Van Canneyt wrote: > To keep things simple: A unit reginifile ? In the future perhaps. Let's first do the Unicode stuff. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, Mar 11, 2019 at 8:17 PM Michael Van Canneyt wrote: > > I can work on that. > > Great, thank you. Could you (or some other devel) change thus summary of https://bugs.freepascal.org/view.php?id=35213 from "TRegistry should not enforce UTF8 encoding on returned string variables." to something like "Unicode aware TRegistry"? It'll be more clear then that all unicode related fixes will go into that report, resulting (hopefully) in a single patch. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 13, 2019 at 1:58 PM Bart wrote: > Could you (or some other devel) change thus summary of > https://bugs.freepascal.org/view.php?id=35213 from "TRegistry should > not enforce UTF8 encoding on returned string variables." to something > like "Unicode aware TRegistry"? > > It'll be more clear then that all unicode related fixes will go into > that report, resulting (hopefully) in a single patch. And while you're at it: add a relationship to #0034876 ? (#0034876 could probably the be resolved as a duplicate of #0035213, once that one's title has changed.) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Wed, Mar 13, 2019 at 2:24 PM Michael Van Canneyt wrote: > Done and done. Thanks. I will report back here if I have something I think is worth applying. In the mean time ignore patches added to that bugreport. I'll attach intermediate diff's there, just because it eases my work flow. (And as backups of my work in progress, because I recently suffered a catastrofic failure on my Windows machine, because I mansged to f**k up the registry beyond repair. I don't have a VM where I do all my testing.) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
