On Thu, Jan 2, 2020 at 1:07 AM Ondrej Pokorny wrote:
> But still adding an overload just to omit one line for changing some
> property is nonsense. You can do so in a class helper if you want.
I did not even consider that option.
May indeed be the better choice.
--
Bart
___
On Thu, Jan 2, 2020 at 12:36 AM Ozz Nixon via fpc-devel
wrote:
> Just make your own descendent - jeez.
That is noy going to solve my problem.
An addition like suggested would have made adjusting code inside
Lazarus a bit easier.
There are a multitude of TStrings descendants there, I would have t
On Wed, Jan 1, 2020 at 1:00 PM Bart wrote:
Meanwhile, can anybody who has a recent Delphi version comment on this:
> B.t.w. Am I correct in understanding that when TStrings.SaveTo*()
> without an encoding parameter (so, the 1 parameter version) will NOT
> write the BOM if Encoding = nil, whereas
On Thu, 2 Jan 2020, Bart via fpc-devel wrote:
On Wed, Jan 1, 2020 at 1:00 PM Bart wrote:
Meanwhile, can anybody who has a recent Delphi version comment on this:
B.t.w. Am I correct in understanding that when TStrings.SaveTo*()
without an encoding parameter (so, the 1 parameter version) wil
On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt
wrote:
> In Delphi it doesn't matter where the encoding comes from.
> If writeBOM is true and there is a preamble for the encoding (whatever it
> is), it is used.
I think I have to rephrase my question.
In fpc TStrings.SaveToStream(AStream) doe
Hi,
Why does TEncoding.ANSI.IsSingleByte return False (and so does
TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and
850)?
According to
http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.IsSingleByte
:
"TEncoding.IsSingleByte specifies whether the current e
On Thu, 2 Jan 2020, Bart via fpc-devel wrote:
On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt
wrote:
In Delphi it doesn't matter where the encoding comes from.
If writeBOM is true and there is a preamble for the encoding (whatever it
is), it is used.
I think I have to rephrase my ques
On Thu, Jan 2, 2020 at 12:57 PM Bart wrote:
> Why does TEncoding.ANSI.IsSingleByte return False (and so does
> TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and
> 850)?
It's not Delphi compatible (tested on Dutch Delphi Forum with Delphi XE3.
Filed a bugreport: https://bugs.freep
On 02.01.2020 14:58, Michael Van Canneyt wrote:
On Thu, 2 Jan 2020, Bart via fpc-devel wrote:
On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt
wrote:
In Delphi it doesn't matter where the encoding comes from.
If writeBOM is true and there is a preamble for the encoding
(whatever it
is),
On Thu, Jan 2, 2020 at 7:15 PM Ondrej Pokorny wrote:
> Should be fixed in r43839. Please report any issues.
That was quick!
Thanks.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinf
On 27.12.2019 12:01, Ondrej Pokorny wrote:
On 27.12.2019 10:40, Michael Van Canneyt wrote:
Yes, indeed. Therefore I suggested
* TEncoding.Default for the DefaultSystemCodePage variable
and
* TEncoding.ANSI for the system encoding.
Currently we have
* TEncoding.SystemEncoding for the DefaultSyst
Hi,
After revision 43841 make all in the root fails:
make[3]: Leaving directory `C:/devel/fpc/trunk/rtl'
make -C fpmkunit bootstrap FPC=C:/devel/fpc/trunk/compiler/ppc386.exe
make[3]: Entering directory `C:/devel/fpc/trunk/packages/fpmkunit'
C:/devel/fpc/3.0.4/bin/i386-Win32/gmkdir.exe -p units_b
On 02.01.2020 20:34, Bart via fpc-devel wrote:
After revision 43841 make all in the root fails
Thanks - I fixed this one. But there seems to be another problem. I am
on it now.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https
On Thu, Jan 2, 2020 at 8:34 PM Bart wrote:
> fpmkunit.pp(4850,16) Error: Incompatible types: got "TStrings"
> expected "TStringsOptions"
> fpmkunit.pp(9524) Fatal: There were 1 errors compiling module, stopping
If I fix that
( on line 4850 change
Options:=OptionsToStringList(Values[KeyOptions]
On Thu, Jan 2, 2020 at 8:42 PM Ondrej Pokorny wrote:
> Thanks - I fixed this one. But there seems to be another problem. I am
> on it now.
Yeah, saw that too ...
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepas
It should be fixed with r43846. You may need to delete fpmake.exe and
fpmake.o to make sure they are recompiled.
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi everyone,
So one of my patch suggestions sought to give a small efficiency boost
to the post-peephole optimiser stage, since it is only designed to
convert instructions into abbreviated forms but which would likely
damage the peephole optimizer if done sooner.
https://bugs.freepascal.org/v
On Thu, Jan 2, 2020 at 9:42 PM Ondrej Pokorny wrote:
> It should be fixed with r43846.
Yes, thanks.
> You may need to delete fpmake.exe and
> fpmake.o to make sure they are recompiled.
Yes, it failed before that.
Good thing you wrote it here.
Isn't make clean or make distclean supposed to take
Am 02.01.2020 um 20:10 schrieb Ondrej Pokorny:
TStrings.SaveTo*() writes BOM by default. Formerly the BOM was not
written.
There is also the problem that currently it is not possible, without
further action, to retain the BOM state of a file loaded into a
stringlist, modified and written back
Bart via fpc-devel schrieb am Fr., 3. Jan.
2020, 02:26:
> On Thu, Jan 2, 2020 at 9:42 PM Ondrej Pokorny wrote:
>
> > It should be fixed with r43846.
> Yes, thanks.
>
> > You may need to delete fpmake.exe and
> > fpmake.o to make sure they are recompiled.
>
> Yes, it failed before that.
> Good th
20 matches
Mail list logo
