[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
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, Bart <bartjun...@gmail.com> 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 <mich...@freepascal.org> 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, Ondrej Pokorny <laza...@kluug.net> 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 <bartjun...@gmail.com> 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 <laza...@kluug.net> 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
Re: [fpc-devel] HTML string to TFPColor
On 7/23/17, ListMember <listmem...@letterboxes.org> 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 <laza...@kluug.net> 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 <laza...@kluug.net> 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] Request for an interim release of the 3.0 branch
On 4/26/17, Marco van de Voort <mar...@stack.nl> 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
[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] Different results of random(int32) and random(int64) for negative limit value
On 5/20/17, Jonas Maebe <jo...@freepascal.org> 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] How does one request new features?
On Mon, Dec 4, 2017 at 9:58 PM, J. Gareth Moreton <gar...@moreton-family.com> 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
[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 Tue, Dec 5, 2017 at 10:07 AM, Mark Morgan Lloyd <markmll.fpc-de...@telemetry.co.uk> 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] 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] Broken frac function in FPC3.1.1 / Windows x86_64
On Wed, Apr 25, 2018 at 11:04 AM, <i...@wolfgang-ehrhardt.de> 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] Broken frac function in FPC3.1.1 / Windows x86_64
On Wed, Apr 25, 2018 at 11:04 AM, <i...@wolfgang-ehrhardt.de> 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] Case of string
On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel <fpc-devel@lists.freepascal.org> 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 <fpc-devel@lists.freepascal.org> 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
Re: [fpc-devel] Debugging Loop Unroll Optimization
On Thu, May 17, 2018 at 6:01 PM, Martok <list...@martoks-place.de> 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 <mar...@stack.nl> 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
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] 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
[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
[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
[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 <nc-gaert...@netcologne.de> 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] FloatHelper bugs (Issue #32837)
On Thu, Jan 11, 2018 at 11:59 PM, Ondrej Pokorny <laza...@kluug.net> 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
Re: [fpc-devel] FloatHelper bugs (Issue #32837)
On Thu, Jan 11, 2018 at 11:13 PM, Michael Van Canneyt <mich...@freepascal.org> 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
[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] End of support for Win XP?
On Tue, Jan 30, 2018 at 10:40 PM, Florian Klämpfl <flor...@freepascal.org> 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
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:34 PM, Michael Van Canneyt <mich...@freepascal.org> 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
[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
[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
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 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] 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] 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
Re: [fpc-devel] Wrong docs: not initialized global variables
On Thu, Apr 5, 2018 at 4:22 PM, Karoly Balogh (Charlie/SGR)
<char...@scenergy.dfmk.hu> 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 <fpc-devel@lists.freepascal.org> 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
Re: [fpc-devel] Abs(Variant) unexpected result
On Sun, Feb 25, 2018 at 5:34 PM, Michael Van Canneyt <mich...@freepascal.org> 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
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 <jo...@freepascal.org> 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 3:40 PM, Michael Van Canneyt <mich...@freepascal.org> 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
On Sun, Feb 25, 2018 at 1:01 PM, Michael Van Canneyt <mich...@freepascal.org> 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 5:59 PM, Michael Van Canneyt <mich...@freepascal.org> 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
[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
[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] 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] 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] 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] 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
[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] [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
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
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
[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
Re: [fpc-devel] TRegistry and Unicode
On Sun, Mar 17, 2019 at 1:16 PM Bart wrote: > I attached registry.unicode.part5.diff for review to > https://bugs.freepascal.org/view.php?id=35213 . ... > I would appreciate a review and feedback. ... > I propose to continu the discussion in the bugtracker then, unless > there are fundamental objections agains my proposed patch. Bump? -- 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 23, 2019 at 2:27 PM Bart wrote: > > I will look at it tomorrow. It has been a busy week. Thanks for applying. Thanks to all of you for your advice and patience. Should the changes be documented at http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Units ? Bart -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpcmkcfg and fpc.cfg questions
Hi, First problem: I tried to build lazarus trunk with fpc trunk. Lazarus r60747, fresh checkout Fpc r41788, installed from source in C:\PP It failed with: C:\devel\laztrunktrunk\packager\registration\fcllaz.pas(11,3) Fatal: (10022) Can't find unit db used by fcllaz I took a look at my fpc.cfg files. Extract from fpc.cfg from 3.0.4 (created by offcial installer) # searchpath for units and other system dependent things -FuC:\devel\fpc\3.0.4/units/$fpctarget -FuC:\devel\fpc\3.0.4/units/$fpctarget/* -FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl Extract from fpc.cfg from fpc trunk: created with fpcmkcfg.exe (from trunk) # searchpath for units and other system dependent things -Fu/units/$fpctarget -Fu/units/$fpctarget/* -Fu/units/$fpctarget/rtl Notice all paths are relative (to what?) How does fpc know that, in relation to fpc.exe this must be translated to: ..\..\units\$fpctarget ? === output of make === make distclean make bigide OPT="-vut" make -C packager/registration make[1]: Entering directory `C:/devel/laztrunktrunk/packager/registration' C:/devel/fpc/3.0.4/bin/i386-win32/rm.exe -f ../units/i386-win32/fcllaz.ppu C:/pp/bin/i386-win32/ppc386.exe -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu. -Fuc:/pp/units/i386-win32/rtl -FE. -FU../units/i386-win32 -g -gl -vut -di386 fcllaz.pas Configfile search: fpc.cfg Configfile search: C:\Users\Bart\fpc.cfg Configfile search: C:\ProgramData\fpc.cfg Configfile search: C:\pp\bin\i386-win32\fpc.cfg (11026) Reading options from file C:\pp\bin\i386-win32\fpc.cfg Hint: (11030) Start of reading config file C:\pp\bin\i386-win32\fpc.cfg Path "C:\units\i386-win32\" not found Path "C:\units\i386-win32\*\" not found Path "C:\units\i386-win32\rtl\" not found Path "C:\units\i386-win32\httpd22\" not found Path "C:\Users\Bart\AppData\Local\FreePascal\fppkg\units\i386-win32\*\" not found Path "C:\lib\i386-win32\" not found Hint: (11031) End of reading config file C:\pp\bin\i386-win32\fpc.cfg Free Pascal Compiler version 3.3.1 [2019/03/17] for i386 Copyright (c) 1993-2018 by Florian Klaempfl and others (1000) Compiler: C:\pp\bin\i386-win32\ppc386.exe (1002) Target OS: Win32 for i386 (1003) Using executable path: C:\pp\bin\i386-win32\ (1004) Using unit path: .\ (1004) Using unit path: C:\pp\units\i386-win32\rtl\ (1004) Using unit path: C:\pp\bin\i386-win32\ (1006) Using library path: .\ (1006) Using library path: C:\pp\units\i386-win32\rtl\ (1006) Using library path: C:\pp\bin\i386-win32\ (1007) Using object path: .\ (1007) Using object path: C:\pp\units\i386-win32\rtl\ (1007) Using object path: C:\pp\bin\i386-win32\ (3104) Compiling fcllaz.pas Searching file fcllaz.pas... found (PROGRAM) (10057) Registering new unit SYSTEM (PROGRAM) (10027) Load from FCLLAZ (interface) unit SYSTEM (SYSTEM) (10055) Loading unit SYSTEM (1) Unitsearch: system.ppu (1) Unitsearch: ..\units\i386-win32\system.ppu (1) Unitsearch: system.pp (1) Unitsearch: system.pas (1) Unitsearch: system.ppu (1) Unitsearch: system.pp (1) Unitsearch: system.pas (1) Unitsearch: C:\pp\units\i386-win32\rtl\system.ppu (10001) PPU Loading C:\pp\units\i386-win32\rtl\system.ppu (SYSTEM) (10002) PPU Name: C:\pp\units\i386-win32\rtl\system.ppu (SYSTEM) (10005) PPU Time: 2019/03/17 12:28:14 (SYSTEM) (10003) PPU Flags: 225409 (SYSTEM) (10004) PPU Crc: D0EC42A2 (SYSTEM) (10004) PPU Crc: 5CA0AD90 (intfc) (SYSTEM) (10004) PPU Crc: 5B736799 (indc) (SYSTEM) Number of definitions: 2746 (SYSTEM) Number of symbols: 8557 (SYSTEM) (10011) PPU Source: system.pp not available (SYSTEM) (10011) PPU Source: systemh.inc not available (SYSTEM) (10011) PPU Source: sysosh.inc not available (SYSTEM) (10011) PPU Source: rtldefs.inc not available (SYSTEM) (10011) PPU Source: filerec.inc not available (SYSTEM) (10011) PPU Source: textrec.inc not available (SYSTEM) (10011) PPU Source: innr.inc not available (SYSTEM) (10011) PPU Source: cpuh.inc not available (SYSTEM) (10011) PPU Source: cpuinnr.inc not available (SYSTEM) (10011) PPU Source: mathh.inc not available (SYSTEM) (10011) PPU Source: currh.inc not available (SYSTEM) (10011) PPU Source: ustringh.inc not available (SYSTEM) (10011) PPU Source: wstringh.inc not available (SYSTEM) (10011) PPU Source: setjumph.inc not available (SYSTEM) (10011) PPU Source: rttih.inc not available (SYSTEM) (10011) PPU Source: objpash.inc not available (SYSTEM) (10011) PPU Source: varianth.inc not available (SYSTEM) (10011) PPU Source: dynarrh.inc not available (SYSTEM) (10011) PPU Source: compproc.inc not available (SYSTEM) (10011) PPU Source: heaph.inc not available (SYSTEM) (10011) PPU Source: threadh.inc not available (SYSTEM) (10011) PPU Source: dynlibh.inc not available (SYSTEM) (10011) PPU Source: sysdlh.inc not available (SYSTEM) (10011) PPU Source: resh.inc not available (SYSTEM) (10011) PPU Source: excepth.inc not available (SYSTEM) (100
Re: [fpc-devel] implicit generic specialization modeswitch name
On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel
wrote:
> I agree with Florian that a better name is needed for the modeswitch
> ("implicitgenerics" as a different meaning in my opinion). But I don't
> have a better idea than "implicitfunctionspecialization" either...
implicitgenericfunctions?
Just a little bit shorter.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 7:50 AM Sven Barth via fpc-devel wrote: > Well, to be fair, the "\bla" ones are called "drive relative paths" as > they're always relative to the root drive of the current directory. Well if fpc treats -Fu/bla as drive relative paths, it makes even less sense that: 1. fpcmkcfg creates it that way 2. fpc is able to find anything at all. I rather was hoping for a more substantive answer ;-( Why the difference between the 2 fpc.cfg's (3.0.4 vs trunk; I assume both used fpcmkcfg tool)? More important: why does builing Lazarus only succeed if I put in fully qualified paths? (If it cannot find db.ppu, why can it find system.ppu?) - Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 10:45 AM Joost van der Sluis wrote: > ERhm... I can not think of any design that makes this logical. I'm not > the one who builds and maintains the windows installers, though. So it's > a bug, I would say. Reported as https://bugs.freepascal.org/view.php?id=35271 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 10:45 AM Joost van der Sluis wrote:
> To create a working fpc.cfg, you have to provide the %basepath% on the
> command-line. (There are a few build-in macro's, you can see them using
> 'fpcmkcfg -m')
fpcmkcfg -d does not show the existence of a build-in BASPEPATH though.
C:\pp\bin\i386-win32>fpcmkcfg -m
BUILDDATE=25-3-2019
BUILDTIME=11:45:25
COMPILERCONFIGDIR={LocalRepository}config/
FPCBIN=fpc
FPCTARGET=i386
FPCTARGETOS=Win32
FPCVERSION=3.3.1
LOCALBASEPATH=$LOCAL_APPDATA\FreePascal\fppkg //odd name for fppkg
specific folder?
LOCALREPOSITORY={AppConfigDir}
NEEDCROSSBINUTILSIFDEF=#IFNDEF CPUI386
#IFNDEF CPUAMD64
#DEFINE NEEDCROSSBINUTILS
#ENDIF
#ENDIF
#IFNDEF Win32
#DEFINE NEEDCROSSBINUTILS
#ENDIF
PWD=C:\pp\bin\i386-win32
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 11:48 AM Bart wrote: > fpcmkcfg -d does not show the existence of a build-in BASPEPATH though. Yeah, -m of course (as the line below that correctly showed)... ___ 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 25, 2019 at 7:48 AM Sven Barth via fpc-devel wrote: >> Should the changes be documented at >> http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Units ? > > > Would be good, yes. Are you going to do it? I'll have a go at it. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 11:25 AM Sven Barth via fpc-devel wrote: > I replied to wkitty42's statement regarding relative paths, not your problem > per se. I know, but the discussion gets side-tracked this way. The main questions are: 1. Why can fpc find all rtl files if -Fu parameters are like /bla 2. Why cannot find fpc db.ppu if -Fu parameters are like /bla (they need to be c:\actual\path\to\units\) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 10:45 AM Bart wrote: > Why the difference between the 2 fpc.cfg's (3.0.4 vs trunk; I assume > both used fpcmkcfg tool)? Joost answered that while I was typing -- 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 23, 2019 at 12:02 AM Michael Van Canneyt wrote: > > Bump? > > I will look at it tomorrow. It has been a busy week. Thank you, it got a bit silent here... I'll await comments in the bugtracker then. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg and fpc.cfg questions
On Mon, Mar 25, 2019 at 1:55 PM Joost van der Sluis wrote: > That's correct. That's why it should be provided on the command-line. > > fpcmkcfg only shows the values of all defined macro's. For example, try > 'fpcmkcfg -d foo=jojo -m'. As an end user howvere I do not even know that such a thing like BASEPATH can be set at all. The only way to know is to study the sourcecode (fpccfg.inc). IMO to should show all macro's it uses, even if it is empty: eg.: BASEPATH= > > LOCALBASEPATH=$LOCAL_APPDATA\FreePascal\fppkg //odd name for fppkg > > specific folder? > > It's being used for ages... You mean the 'FreePascal' part? I meant that LOCALFPPKGBASEPATH would have made more sense to me. LOCALBASEPATH to me suggests what BASEPATH seems to be... (I really hop I make myself clear.) -- 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 25, 2019 at 10:37 AM Bart wrote: > I'll have a go at it. First draft at http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Registry_unit -- 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
[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 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 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 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 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
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 Wed, Mar 13, 2019 at 6:51 PM Michael Van Canneyt wrote: > What you could do is > > TUniCodestringArray = Array of UniCodeString; > > Function GetKeyNames : TUniCodestringArray; > Function GetValueNames : TUniCodestringArray; > > The TStringList versions can call these and do the conversion. I have already declared TUnicodeStringArray in the Registry unit and use it for Read/WriteStringList. I was about to implement GetKeyNames/GetValueNames this way, but hit a snag. The type TUnicodeStringArray must then be know to the XMLReg unit as well, since these functions call TXMLRegistry functions (in non-windows implementation). I can declare the type there as well, but for the compiler these will be 2 different types. Also I need conversion from TStrings to/from TUnicodeStringArray more then once. I made them private methods of TRegistry, but I could use them in XMLReg unit as well. It is not absolutely necessary, but would make for better code maintenance. XMLReg could have Registry in it's uses clause (must be in Interface section). Registry has uses XMLReg in th eimplementation section. I have some recollection that we rather would not do it that way, because the compiler does not like it very much? The alternative would be to define TUnicodeStringArray either somewhere in RTL or in a new unit that both Registry and XMLReg unit use. (And then probably re-declare it in at least TRegistry (type TUnicodeStringArray = NewUnit.TUnicodeStringArray), so you can use the type in your program.) Which way to go? -- 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 16, 2019 at 4:36 PM Michael Van Canneyt wrote: > > I can declare the type there as well, but for the compiler these will > > be 2 different types. > > In Delphi yes, but normally not in FPC. If the base type is the same, 2 > array definitions will be assignment-compatible. Thanks for pointing that out. I implemented it that way now. I attached registry.unicode.part5.diff for review to https://bugs.freepascal.org/view.php?id=35213 . === All public and protected methods now default to UnicodeString. Overloaded versions with String parameters use implicit conversion to/from UnicodeString. Introduced new methods that read/write TUnicodeStringArray parameters. All methods using TStrings now uses the methods using TUnicodeStringArray. (In XMLReg unit I did not remove the existing implementation using TStrings, because AFAIK this unit can be used stand alone, and it would therefore not be backwards compatible.) ReadStringList/WriteStringList have optional parameter to control if the Strings are encodes as UTF8. GetKeyNames and GetValueNames with TStrings parameter encode the resulting strings as UTF8. (I did not include an optional paramter as for Read/WriteStringList, because then the signature is no longer Delphi compatible. If so desired this paramter can be added. It's a trivial change.) As discussed: in XMLReg WriteStringList now writes UnicodeStrings to the reg.xml file, which the previous implementation (trunk only) did not. It was judged to be acceptable. TXMLRegistry internally now uses UnicodeString everywhere (except for the Filename property and HexToBuf/BufToHex, where it seemed to make no sense to convert this to UnicodeString). There are still warnigs about implicit UnicodeString to String conversions, but they are in codepaths that are not used by TRegistry. I changed some existing $ifdefs to make it easier to use and test the XML implementation under Windows. (Simplye defining XMLREG would not compile under Windows) I added some conditional compilation to XMLReg unit for the same reason. When reading Reg_Multi_SZ data, trailing zero's are deleted regardless of value of StringSizeIncludesNull, because (by Windows definition) this data cannot contain empty strings. In the XMLReg implementations I did some Explicit UnicodeString to String conversions in places where the string in question can only contain '0'..'9','A'..'Z'. It suppresses a warning and it is safe by definition in those places. I had to fix TXmlRegistry.HexToBuf. The fact that it worked before was by pure luck. = It builds on Win32, Win64 and WinCe. I can now read/write Unicode keys, names in both XMLREG and Windows implementation. I attached a reg.xml with Unicode Keys and Values as an example. I tested reading and writing all the default types (string, multistring, integer, int64, float, date, time, datetime). There are still several debug writeln statements (all commented out) in the source code, they shall be removed at some point in time of course. The patch file is 2063 lines I would appreciate a review and feedback. Especially function TRegistry.GetKeyNames: TUnicodeStringArray; and function TRegistry.GetValueNames: TUnicodeStringArray; in the Windows implementation: where I assign u:=lpName (u=UnicodeString, lpName=LPWSTR), maybe a UniqueString is needed?? It does not crash here, but that may also be pure luck. I propose to continu the discussion in the bugtracker then, unless there are fundamental objections agains my proposed patch. -- Bart Value 1 003DE540 1378FFA874DAED3F 37BAE7FF9F40E540 182D4454FB210940 2147483647 %PATH% 310032003300 310032003300 ∫∬∭ ∫∬∭ ___ 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 14, 2019 at 8:22 AM Cyrax wrote: > If your computer have enough RAM and have support for hardware > virtualization (motherboard, its firmware and CPU) then I would > recommend that you set up a VM for testing. I would recommend to you to > use VirtualBox. That is not really the issue. My machine is Win10 on i5 with 8GB memory. I run Mint in aVirtualBox VM (a bit sluggish, but do-able). I don't have a Windows installable medium with license that I can install into a VM. And I'm not gonna buy it, nor am I gonna use some pitate copy. 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 Wed, Mar 13, 2019 at 6:43 PM Bart wrote: > That was the easy part. TXMLRegistry does not seem to support Int64. Any reason for that? If it's an oversight (support for that was only recently added for Windows) should I try and implement it as well in the unicode patch or implement it later? -- 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 14, 2019 at 7:50 PM Sven Barth via fpc-devel wrote: > Support for 64-bit values in the registry was only added a few weeks ago, so > I'd say that was an oversight. > If you implement it, then please as a separate patch, maybe also with a > separate bug report. OK https://bugs.freepascal.org/view.php?id=35227 -- 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
