(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
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
isions generate lineinfo
as expected.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
e 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
'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;
FPColo
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'
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 ma
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, hcnAq
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.freepasc
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 ...
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
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/
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 comm
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
s 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
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
ack.
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
t 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.fre
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
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
_
.
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 maillis
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/lis
iteln('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
VarIsOrd
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
;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
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 overl
t 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
;;
> 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
__
hat 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
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 maillis
; // 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 t
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
ill 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 ('
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-
ned 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
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 mailli
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
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
lts.
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
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 ma
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
__
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.o
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
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.freepasc
6) - 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
(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
try
> 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
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 curi
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/vie
#x27;,[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
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-
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
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/lis
opic=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
x 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 usi
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 Rando
this part of the proposal).
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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.
.
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
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
h
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
genera
f 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
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.freepasc
valent 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
that Lazarus relies on it.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
x27;t give up..
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ne 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
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
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-b
r
- 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
stry 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 i
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
___
String 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
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
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
eaving 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
___
(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
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 appli
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-de
thing.
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
nicodestring. (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
__
ram 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
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/c
sion 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
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.
er 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
eln('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@list
codestring;
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 O
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
he 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
tf8Encode 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-dev
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
_
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
vant 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
ing it (on
Windows that is).
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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.
ng 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.freep
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 TR
rk 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-deve
1 - 100 of 331 matches
Mail list logo
