Compiling under Lazarus trunk applications which were written under Lazarus 1.4.x, I find a lot of unresolved symbols. All the xxxUTF8 procedures in fileutil such as FileExistsUTF8, FileOpenUTF8 GetEnvironmentVariableUTF8 etc have disappeared. They are hidden behind an $IFDEF EnableWrapperFunctions. By the way those procedures were generated by the conversion of Delphi code under Lazarus 1.4.

I understand that the widestring manager is not needed in most cases, and therefore those functions are pretty much useless outside Windows, (they have always been btw?) but an $ELSE clause preserving the names, and redirecting as appropriate, would be the only acceptable solution by an end user POV.

FPC goes to one extreme, keeping stone age old constructs to maintain compatibility with the source code of TP, Lazarus should at least attempt to keep source code compatibility within 1.x!

End of rant.

Giuliano

If you read the information after the deprecated key word at every function, you would get to know that those units have been moved to LazFileUtils or LazUTF8 units.

Note: we need an incompatibility information about it in http://wiki.freepascal.org/index.php?title=Lazarus_1.8.0_release_notes . Juha, did you do this change?

Ondrej

Il 13/07/2016 12:22, Ondrej Pokorny ha scritto:

If you read the information after the deprecated key word at every function, you would get to know that those units have been moved to LazFileUtils or LazUTF8 units.

One can read the information after the "deprecated" keyword only if he knows where to look, because the code explorer will not find it. A "normal" user is only confused. An $ELSE clause would be the only way to provide somehow a minimal hint.

Giuliano

Those functions have been marked as deprecated in version 1.6 with the same information - they still exists there. They were removed in 1.7 trunk for the coming 1.8 stable.

So a normal user that updates from 1.4 to 1.6 gets exactly this information. He updates his uses clauses and when he updates to the future 1.8 version, there won't be no problem.

So your problem is that you moved from 1.4 to 1.7 trunk without the 1.6 intermediate step. Your rant is not valid and completely unnecessary.

Ondrej

Il 13/07/2016 12:46, Ondrej Pokorny ha scritto:

So your problem is that you moved from 1.4 to 1.7 trunk without the 1.6 intermediate step. Your rant is not valid and completely unnecessary.

Do you have an idea of how many users and distros may happen to skip one step?

Giuliano

13.07.2016 14:19, Giuliano Colla пишет:

It does not matter. Every user should read all release notes even for skipped versions. In your case this would be 1.6 and 1.8.

Ondrej Pokorny wrote

Note: we need an incompatibility information about it in http://wiki.freepascal.org/index.php?title=Lazarus_1.8.0_release_notes . Juha, did you do this change?

I deprecated the functions before 1.6.
After the release Bart, according to plan, turned condition {$IFnDEF DisableWrapperFunctions} into {$IFDEF EnableWrapperFunctions}. Apparently he forgot some places. I finished the job in r52678.

I updated both 1.6 and 1.8 release notes now with the relevant info.

Giuliano, you can still use the wrappers by defining EnableWrapperFunctions. However I recommend using the correct units. It is not a very big change in your code.

Juha

Il 13/07/2016 15:40, Juha Manninen ha scritto:

Giuliano, you can still use the wrappers by defining EnableWrapperFunctions. However I recommend using the correct units. It is not a very big change in your code.

I don't complain about the change in code. It has always happened and it will happen in future.

I know that those procedures are in the Fileutils unit, I gave a look and I understood what had happened. But what of unaware users?

I complain about making things more obscure and difficult than necessary for a plain average user. If a symbol, name procedure, whatever is marked as deprecated, it's easily understood by anybody. If it generates a compiler error telling what he should do instead, or that one should read the release notes, it's again easy to handle. If it simply "undefined" with no other clue, it just generates user frustration.

Giuliano

Giuliano Colla wrote

whatever is marked as deprecated, it's easily understood by anybody.

They were deprecated for a long time in trunk and also in the 1.6 release. They will be deprecated forever in the fixes_1_6 branch and in 1.6.x dot releases.

Juha

Why not make the old functions simply call the new ones? Why break user code?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160717/ebee219b/attachment.html>

Kostas Michalopoulos wrote

Why not make the old functions simply call the new ones?

The "old functions" were wrappers and indeed called the actual functions in proper units.

Why break user code?

Sometimes code must be cleaned.
The breakage was not bad, it only required to change or add units in uses section.
This was a proper time for a cleanup because the whole UTF-8 support was revamped which also broke some code.
The wrapper functions were mostly UTF-8 helper functions, many of which are not needed any more.
Removing the wrappers can be seen as a hint to clean up your code even more. In practice you can replace most UTF8...() and ...UTF8() functions with their Delphi compatible versions without the "UTF8" part.
See:
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus

Juha

Il 17/07/2016 15:27, Kostas Michalopoulos ha scritto:

Why not make the old functions simply call the new ones? Why break user code?

This was exactly my point. Developers often fail to realize that users very often must simply maintain old code. Anything requiring to modify the source code implies extra work and extra possibility of errors.

Giuliano

"Giuliano Colla" wrote

Il 17/07/2016 15:27, Kostas Michalopoulos ha scritto: > Why not make the old functions simply call the new ones? Why break user

code?

This was exactly my point. Developers often fail to realize that users

very often must simply maintain old code. Anything requiring to modify the source code implies extra work and extra possibility of errors.

IMO, if objective is just maintaning old code the best approach is to stick with the same dev enviroment. This will avoid the extra work.

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160717/5bbaa966/attachment.html>

Il 17/07/2016 16:26, Luiz Americo Pereira Camara ha scritto:

IMO, if objective is just maintaning old code the best approach is to stick with the same dev enviroment. This will avoid the extra work.

But if the objective is both maintaining old and developing new, then either you end up with myriads of VM's or try to maintain old with recent tools.
We're not speaking of stone age code, just of one year old code!

Giuliano

Please explain me how updating the uses sections with correct unit names can cause extra errors.
You should also realize that the new UTF-8 system breaks some code, thus you should go through your code in any case when updating to Lazarus 1.6+. When maintaining old codebase it makes sense to stick with the old Lazarus version. However if you anticipate any substantial changes then I recommend updating Lazarus because of all its improvements.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160717/50c68447/attachment.html>

Giuliano, please don't maintain your production code with Lazarus trunk. It is NOT recommended for obvious reasons.
Use the latest release 1.6, or the soon to be released Lazarus 1.6.2 update. The wrapper functions you complained about are usable there, although deprecated.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160717/91a22123/attachment-0001.html>

Il 17/07/2016 19:33, Juha Manninen ha scritto:

Giuliano, please don't maintain your production code with Lazarus trunk. It is NOT recommended for obvious reasons.

You're right. Thank you.

Giuliano