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
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
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
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.
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
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
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
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
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
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
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
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
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:
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
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
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)
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)
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,
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
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
20 matches
Mail list logo
