(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
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
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 sourc
ed := $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
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, h
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.freepa
ColorNameToFPColorMap 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
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.freepas
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 j
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
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
appens 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
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.freepasca
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
m 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
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
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
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
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-de
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.or
0 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
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/strin
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
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
___
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
:( '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?
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
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 prog
0 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
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 m
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
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
_
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
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
_
('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
B
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
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 till OK.
(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
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
t; 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 com
s (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
; 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
_
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
y 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
ariants 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
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 righ
se 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
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
uot;
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
___
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
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
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.
--
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
ting 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
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
.
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
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
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.
ks 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
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 f
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
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
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
--
-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 f
onspecialization" 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
f 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
?id=35271
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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.freepas
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
h
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
e 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
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
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 mail
> 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
___
fp
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
h
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.
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
g 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
n: 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 applie
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 to b
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
__
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
hat 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.
--
B
able 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
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 m
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
ther.)
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
_
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
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
s 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.
Ba
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 la
t.
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
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
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
1 - 100 of 309 matches
Mail list logo
