Re: [fpc-devel] A more fundamental problem Re: i36507
On Fri, Jan 3, 2020 at 11:30 AM J. Gareth Moreton wrote: > Oh right, okay. That explains things then. I would have thought though > that it would have been test-compiled before being pushed to the main > repository. No, the fpc devels are not responsible for Lazarus. The adding of TStrings.Options was mandatory (Delphi has it, so we must as well). > Sorry for the confusion - I assumed that Lazarus was > guaranteed to build from the trunk. This happens rather frequently, and cannot be really avoided, and if it happens we fix it in Lazarus trunk (and sometimes in Lazarus fixes as well). It's not a big deal. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()
On 03.01.2020 11:09, Michael Van Canneyt wrote: I also think it is very hypothetical, and not a problem unless you want to use the same stream in Delphi and FPC. Well, you have my blessing for the soPreserveBOM :) Added in r43848. I'll check how the FPC documentation works and try to add it there. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
Sorry, and I'm also misunderstanding that the class belongs to the RTL, not Lazarus. Not a good start to the day! Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
On 03/01/2020 10:19, Ondrej Pokorny wrote: There was no clash before. The Options property was introduced yesterday in r43841. FPC trunk is supported only in Lazarus trunk (and Lazarus stable branch if not forgotten :) ). Ondrej Oh right, okay. That explains things then. I would have thought though that it would have been test-compiled before being pushed to the main repository. Sorry for the confusion - I assumed that Lazarus was guaranteed to build from the trunk. Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
On 03.01.2020 11:00, J. Gareth Moreton wrote: This was not a new property or a recent change to the Lazarus sources though. It was a recent change in FPC RTL sources: r43841. I was using an old revision of Lazarus to test optimisations on, and had been doing fine with it until I discovered last night that it would no longer build. Updating to the latest repository didn't change the file in question. Something in the compiler was changed recently that caused it to break when it was able to handle the clash before. There was no clash before. The Options property was introduced yesterday in r43841. FPC trunk is supported only in Lazarus trunk (and Lazarus stable branch if not forgotten :) ). Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
On Fri, 3 Jan 2020, J. Gareth Moreton wrote: This was not a new property or a recent change to the Lazarus sources though. I was using an old revision of Lazarus to test optimisations on, and had been doing fine with it until I discovered last night that it would no longer build. Updating to the latest repository didn't change the file in question. Something in the compiler was changed recently that caused it to break when it was able to handle the clash before. I seriously doubt this. You probably updated the RTL when updating the compiler. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()
On Fri, 3 Jan 2020, Ondrej Pokorny wrote: On 03.01.2020 10:14, Michael Van Canneyt wrote: On Fri, 3 Jan 2020, Ondrej Pokorny wrote: On 03.01.2020 00:35, Werner Pamler wrote: 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 because the presence of a BOM is forgotten after reading - see the other discussion (https://lists.freepascal.org/pipermail/fpc-devel/2020-January/042363.html). Wouldn't it make sense to introduce a )Read)BOM property (a boolean parameter or an element of the new Options) which gets its value when the file is loaded or the strings are assigned? Then the user can set the StringList.WriteBOM equal to the StringList.BOM when he wants to keep the BOM for writing back. Yes, that is perfectly reasonable. I'd prefer a new element in Options but there is the risk that Delphi adds a new option in the future and then we'll have a problem. So maybe a "PreserveBOM" or "SetWriteBOMOnLoad" property will be better. When set to true, WriteBOM will be set in LoadFrom*() according to BOM presence of the loaded file. I don't see why a new option is a problem ? They are not streamed anyway. So I would do the opposite, add an option. soPreserveBOM. If you are fine with it, me as well. Yes, the problem is if somebody streams the property or uses Ord(soPreserveBOM) for something etc. I admit that it is a very hypothetical issue. I also think it is very hypothetical, and not a problem unless you want to use the same stream in Delphi and FPC. Well, you have my blessing for the soPreserveBOM :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
J. Gareth Moreton schrieb am Fr., 3. Jan. 2020,
10:45:
> Hi everyone,
>
> So I reported this morning that Lazarus no longer builds as of r43826.
> Ondrej was quick to update the Lazarus sources to allow it to build
> again and marking the issue as fixed, but the underlying regression in
> the Free Pascal Compiler still exists.
>
> Basically, the compiler failed on constructs like this
>
>with
> InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive)
>
> do begin
> Assign(ExecuteBeforeCommandComboBox.Items);
> Push(Options.ExecuteBefore.Command);
>end;
>
> The fix was to replace it with the following
> (ide/frames/compiler_compilation_options.pas - line 394):
>
>HL :=
>
> InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive);
>HL.Assign(ExecuteBeforeCommandComboBox.Items);
>HL.Push(Options.ExecuteBefore.Command);
>
> Given the "illegal qualifier" errors that appeared, I'm guessing the
> issue is that "Options" is also a property of the THistoryList class as
> well as a local variable. Technically speaking though, this is a
> regression unless it's to be documented (and hence break backward
> compatibility) that if you have a property and a local variable of the
> same name, the property takes precedence.
>
This is simply how "with" works and one of the reasons why it is not
considered good or safe by many.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
This was not a new property or a recent change to the Lazarus sources though. I was using an old revision of Lazarus to test optimisations on, and had been doing fine with it until I discovered last night that it would no longer build. Updating to the latest repository didn't change the file in question. Something in the compiler was changed recently that caused it to break when it was able to handle the clash before. Gareth aka. Kit On 03/01/2020 09:56, Ondrej Pokorny wrote: On 03.01.2020 10:45, J. Gareth Moreton wrote: Given the "illegal qualifier" errors that appeared, I'm guessing the issue is that "Options" is also a property of the THistoryList class as well as a local variable. Technically speaking though, this is a regression unless it's to be documented (and hence break backward compatibility) that if you have a property and a local variable of the same name, the property takes precedence. Nonsense. That would mean that adding any new property in any object is a breaking change because the same name can be used in any possible with-statement at any place in any program or any local variable etc. Short: every new property introduces a risk of clashes. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
On 03.01.2020 10:45, J. Gareth Moreton wrote: Given the "illegal qualifier" errors that appeared, I'm guessing the issue is that "Options" is also a property of the THistoryList class as well as a local variable. Technically speaking though, this is a regression unless it's to be documented (and hence break backward compatibility) that if you have a property and a local variable of the same name, the property takes precedence. Nonsense. That would mean that adding any new property in any object is a breaking change because the same name can be used in any possible with-statement at any place in any program or any local variable etc. Short: every new property introduces a risk of clashes. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()
On 03.01.2020 10:14, Michael Van Canneyt wrote: On Fri, 3 Jan 2020, Ondrej Pokorny wrote: On 03.01.2020 00:35, Werner Pamler wrote: 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 because the presence of a BOM is forgotten after reading - see the other discussion (https://lists.freepascal.org/pipermail/fpc-devel/2020-January/042363.html). Wouldn't it make sense to introduce a )Read)BOM property (a boolean parameter or an element of the new Options) which gets its value when the file is loaded or the strings are assigned? Then the user can set the StringList.WriteBOM equal to the StringList.BOM when he wants to keep the BOM for writing back. Yes, that is perfectly reasonable. I'd prefer a new element in Options but there is the risk that Delphi adds a new option in the future and then we'll have a problem. So maybe a "PreserveBOM" or "SetWriteBOMOnLoad" property will be better. When set to true, WriteBOM will be set in LoadFrom*() according to BOM presence of the loaded file. I don't see why a new option is a problem ? They are not streamed anyway. So I would do the opposite, add an option. soPreserveBOM. If you are fine with it, me as well. Yes, the problem is if somebody streams the property or uses Ord(soPreserveBOM) for something etc. I admit that it is a very hypothetical issue. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A more fundamental problem Re: i36507
P.S. The issue can be found here:
https://bugs.freepascal.org/view.php?id=36507
On 03/01/2020 09:45, J. Gareth Moreton wrote:
Hi everyone,
So I reported this morning that Lazarus no longer builds as of
r43826. Ondrej was quick to update the Lazarus sources to allow it to
build again and marking the issue as fixed, but the underlying
regression in the Free Pascal Compiler still exists.
Basically, the compiler failed on constructs like this
with
InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive)
do begin
Assign(ExecuteBeforeCommandComboBox.Items);
Push(Options.ExecuteBefore.Command);
end;
The fix was to replace it with the following
(ide/frames/compiler_compilation_options.pas - line 394):
HL :=
InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive);
HL.Assign(ExecuteBeforeCommandComboBox.Items);
HL.Push(Options.ExecuteBefore.Command);
Given the "illegal qualifier" errors that appeared, I'm guessing the
issue is that "Options" is also a property of the THistoryList class
as well as a local variable. Technically speaking though, this is a
regression unless it's to be documented (and hence break backward
compatibility) that if you have a property and a local variable of the
same name, the property takes precedence.
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] A more fundamental problem Re: i36507
Hi everyone,
So I reported this morning that Lazarus no longer builds as of r43826.
Ondrej was quick to update the Lazarus sources to allow it to build
again and marking the issue as fixed, but the underlying regression in
the Free Pascal Compiler still exists.
Basically, the compiler failed on constructs like this
with
InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive)
do begin
Assign(ExecuteBeforeCommandComboBox.Items);
Push(Options.ExecuteBefore.Command);
end;
The fix was to replace it with the following
(ide/frames/compiler_compilation_options.pas - line 394):
HL :=
InputHistories.HistoryLists.GetList('BuildExecBefore',true,rltCaseSensitive);
HL.Assign(ExecuteBeforeCommandComboBox.Items);
HL.Push(Options.ExecuteBefore.Command);
Given the "illegal qualifier" errors that appeared, I'm guessing the
issue is that "Options" is also a property of the THistoryList class as
well as a local variable. Technically speaking though, this is a
regression unless it's to be documented (and hence break backward
compatibility) that if you have a property and a local variable of the
same name, the property takes precedence.
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()
On Fri, 3 Jan 2020, Ondrej Pokorny wrote: On 03.01.2020 00:35, Werner Pamler wrote: 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 because the presence of a BOM is forgotten after reading - see the other discussion (https://lists.freepascal.org/pipermail/fpc-devel/2020-January/042363.html). Wouldn't it make sense to introduce a )Read)BOM property (a boolean parameter or an element of the new Options) which gets its value when the file is loaded or the strings are assigned? Then the user can set the StringList.WriteBOM equal to the StringList.BOM when he wants to keep the BOM for writing back. Yes, that is perfectly reasonable. I'd prefer a new element in Options but there is the risk that Delphi adds a new option in the future and then we'll have a problem. So maybe a "PreserveBOM" or "SetWriteBOMOnLoad" property will be better. When set to true, WriteBOM will be set in LoadFrom*() according to BOM presence of the loaded file. I don't see why a new option is a problem ? They are not streamed anyway. So I would do the opposite, add an option. soPreserveBOM. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()
On 03.01.2020 00:35, Werner Pamler wrote: 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 because the presence of a BOM is forgotten after reading - see the other discussion (https://lists.freepascal.org/pipermail/fpc-devel/2020-January/042363.html). Wouldn't it make sense to introduce a )Read)BOM property (a boolean parameter or an element of the new Options) which gets its value when the file is loaded or the strings are assigned? Then the user can set the StringList.WriteBOM equal to the StringList.BOM when he wants to keep the BOM for writing back. Yes, that is perfectly reasonable. I'd prefer a new element in Options but there is the risk that Delphi adds a new option in the future and then we'll have a problem. So maybe a "PreserveBOM" or "SetWriteBOMOnLoad" property will be better. When set to true, WriteBOM will be set in LoadFrom*() according to BOM presence of the loaded file. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)
On Fri, Jan 3, 2020 at 7:47 AM Sven Barth via fpc-devel wrote: >> Isn't make clean or make distclean supposed to take care of that? >> (Neither of them do) > > I think if you call "make clean" or "make distclean" a second time the fpmake > binaries will be cleaned up as well. No, it doesn't (that is: it didn't for me). I ran make clean twice Then I ran make distclean. It seems that make distclean invokes fpmake... (which then crashed). Bart -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
