Lazarus
Free Pascal => General => Topic started by: jamie on September 07, 2020, 07:55:27 pm
-
Example
Uses Graphics, Graphics32;
=
"graphics32 searched but Graphics found"
what kind of a response is that ?
shouldn't it be
"fatal: Can't fine unit graphics32 used by unit1" for example.
Do you now how hard that is to determine what is really going on here? Obviously it should of generated the second message but I've found that with any name in the list that has same starting names but different endings, one valid and the other isn't will give you the first error message.
Does that really make sense ?
It's eluding me..
-
It might be an 8.3 leftover thing.
-
Do you now how hard that is to determine what is really going on here? Obviously it should of generated the second message but I've found that with any name in the list that has same starting names but different endings, one valid and the other isn't will give you the first error message.
This error occurs if the compiler looks for unit X, finds a compiled unit X, but the found PPU is in fact for a unit Y.
I've just tested that myself: I had a program tunitname using a unit uunitname. I then renamed the created PPU file for uunitname to uunitname2 and changed the used unit in tunitname to uunitname2. The result was this error message.
So you should probably check what might be wrong with your setup. Using the option to output tried units (-vt) might help.
-
I figured u would push it off on the user.
Its a bug and it exist in every version I have.
Np. I'll file bug report although I know it will get squashed.
-
Np. I'll file bug report although I know it will get squashed.
We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".
-
Np. I'll file bug report although I know it will get squashed.
We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".
Unbelievable
:-[
-
We need a way to reproduce it. If we can't it will be resolved with "can't reproduce".
Unbelievable
:-[
What is your alternative?
-
I don't know what to tell you?
I made what I thought as a very clear explanation of the confusing message but what I get is answers like no one believes me, even after they admit to performing some test that shows something is strange, but to say there must be something wrong on my end.. ?
A bare bones console uses SysUtils, SysUtils32 in the uses list will do the same thing..
This does not happen with all units. For example If I try to do this with a FORMS unit doing like for example FORMS32 , it then just reports not finding forms32 ..
I don't have any of those source files or compiled units on my PC's so why the strange message?
To me, it looks like an issue with HASH table searches where at some point the end results landed elsewhere and a cryptic message was put there instead.. Because not all Tag names force this to happen.
WIth a GUI project I can even do it with Controls unit, Controls32 will report finding Controls instead ..
This isn't a deal breaker, just a cosmetic issue..
It almost looks like a debug message for a DEV that never got removed.
-
Jamie, simply provide working or failing complete code.
You know the drill..
Otherwise either shutup or close. And listen to Marco.
This is impossible to test because of lack of information. You do that all the time.
-
LAZ trunk / FPC 3.0.4
Compile message :
Fatal: Unit Graphics32 searched but Graphics found
-
It may not mean anything but thus far I can only produce this with 8 letter long names.
For example
Systutils is 8 long and any added letters or numbers to that name that does not exist will produce the message.
This is why I suggested a symbol table lookup (hash) could be at fault.
EDIT:
Ok, I've got some more details.. you do not need to include a 8 character count unit name that does exist in the USES list and then include one with extra letters for this to happen.
Apparently this is at the file search level.
For example..
I include "FileUtils" in the list that does not exist without even including the one that does exist, that would be "FileUtil"
If I try this with shorter file names of existing units and add something to it to make it a non existing unit, it property reports the error.
I haven't tested unit names larger than 8 characters that exist.
-
For example, in the following error message:
`Fatal: Unit FileUtils searched but FileUtil found` as reported by the compiler, the problems would be the following:
1. There is a missing comma that should have been put after "searched". This is quite important when reading the error message because it helps the mind observe the separation of the two distinct subproblems at a glance: 1) that the unit `FileUtils` has been searched; 2) that *another* similarly named unit, `FileUtil` has actually been found;
2. jamie suggested a few examples of error messages on IRC which from a syntactical point of view make it for the eyes to more easily flow on the text and better intuit what the message is about from its first few words:
"Searching for xxxxx, but found xxxx. Did you mean Xxxxx?"
"Failed to find xxxxx, did you mean XXXXX?"
The punctuation marks and taxis make a big difference in textual communication and it seems that this remains available on how the compiler communicates with the programmer.
It might be annoying what is mentioned here, but it is of good intention for a better understanding of the error message and to make it easier to read.
-
But a point I made earlier is this is only happening with 8 letter long unit names.
shorter names like Forms, and if you search for Formss, will report not being able to find it without inserting the "Forms" found.
So either way, there is something wrong with this, its not consistent with all variations of unit length names.
-
Yes, it seems that if fpc cannot find "unit_with_long_name" it will start searching for a unitname that matches the first 8 characters.
uses
nonexistingunit;
begin
end.
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vut test.pas
...
(PROGRAM) Registering new unit NONEXISTINGUNIT
(PROGRAM) Load from PROGRAM (implementation) unit NONEXISTINGUNIT
(NONEXISTINGUNIT) Loading unit NONEXISTINGUNIT
Unitsearch: nonexistingunit.ppu
Unitsearch: nonexistingunit.pp
Unitsearch: nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.ppu
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pp
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pas
Unitsearch: nonexist.ppu
Unitsearch: nonexist.pp
Unitsearch: nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.ppu
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.ppu
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexist.pas
Unitsearch: nonexistingunit.pp
Unitsearch: nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexistingunit.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexistingunit.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexistingunit.pas
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexistingunit.pas
Unitsearch: nonexist.pp
Unitsearch: nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\httpd22\nonexist.pas
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.pp
Unitsearch: C:\devel\fpc\3.2.0\units\i386-win32\rtl\nonexist.pas
...
Unitsearch: C:\devel\fpc\3.2.0\bin\i386-win32\nonexist.pas
test.pas(2,3) Fatal: Can't find unit nonexistingunit used by Program
Fatal: Compilation aborted
And then if you create a nonexist.pp unit (and don't change the main program):
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas
Free Pascal Compiler version 3.2.0 [2020/06/04] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
Compiling nonexist.pp
nonexist.pp(1,14) Error: Illegal unit name: nonexist (expecting NONEXISTINGUNIT)
nonexist.pp(3,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Bart
-
I have read this thread multiple times now and I can't seem to find any flaw :-[
as stated (https://www.freepascal.org/docs-html/user/usersu7.html)
Also, unit names that are longer than 8 characters will first be looked for with their full length. If the unit is not found with this name, the name will be truncated to 8 characters, and the compiler will look again in the same directories, but with the truncated name.
So, unless the unit (with the long name) actually exists (still unclear for me from this thread) and the compiler produces such an error, I can't seem to determine what's is actually wrong....
The case as presented by user Bart seems to make sense as the unit should have the correct/corresponding unit header ? (but also there things are not clear enough).
shorter names like Forms, and if you search for Formss, will report not being able to find it without inserting the "Forms" found.
And also there things seems explained ambiguous. Forms is a standard (existing) unit, so it can be found while formss is not ?
Please feel free to enlighten me on something that would most certainly be something I (clearly) missed in all of this...
-
The filesearching cache is afaik in compiler/cfileutl.pas. For dos and win32 there is short filename (8.3) generation there + tests. For Linux no such thing exists.
But it could also be that in the unitname to search there are multiple calls to the filecache, so that the difference is somewhere else.
-
For history reasons, the compiler searches also the 8 char name if a ppu with the full name cannot be found. The full name of a unit is always stored in the ppu. So if graphics32.ppu is missing, the compiler searches graphics.ppu: when loading this ppu, the full name is known and it is graphics instead of the graphics32 that the compiler expects in the mentioned case. As I understand the error message maybe somebody can suggest an improvement :)
-
But since we don't support win9x anymore, how long should we hold on to this?
Since this (graphics32 vs graphics) is a Delphi compatibility violation as much as the other thing is a TP compat problem.
-
But since we don't support win9x anymore, how long should we hold on to this?
But we do support DOS...
Bart
-
But since we don't support win9x anymore, how long should we hold on to this?
But we do support DOS...
Sure. So keep it for DOS hosts. And require are parameter to enable it for the rest. But don't force this anachronism as a default for everybody.
p.s. how much dos development is actually still hosted on pure dos nowadays ?
-
I'm tempted to give it a try.
I have a "pure DOS" as a VM, just to run TP6 as a reference for possible bugs.
I failed to set up XMM memory (which some of my old programs used to swap out the program when executing another program) though.
Bart
-
I am glad someone is taking some interest here.
:)
-
As I understand the error message maybe somebody can suggest an improvement :)
I have talked to a friend that is specialized in UX Design & UX Writing and have presented to him the issue related to the error message. He sent me two articles covering the problems that UX Writing is covering that I will post below and have extracted a few paragraphs that seem to be related to the issue discussed in this topic.
https://www.nngroup.com/articles/ten-usability-heuristics/ (https://www.nngroup.com/articles/ten-usability-heuristics/)
#9: Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
https://careerfoundry.com/en/blog/ux-design/ux-writing-what-does-a-ux-writer-actually-do/ (https://careerfoundry.com/en/blog/ux-design/ux-writing-what-does-a-ux-writer-actually-do/)
as these digital products become more a part of our daily lives, we as users seek out those that give us the most natural and fluid experience. These changes in the way we interact with technology have led to the creation of UX writing as a discipline in its own right.
Finally, in a more philosophical sense, UX writers must fight for their users. So whenever a designer, developer, or product manager suggests something that might be unclear to the user, the UX writer must stand up and say how that feature, task, or project can and should be communicated more clearly.
I am no UX designer, nor UX writer, but it is quite helpful for everbody to get a grasp of the idea that user interface and text messages have their purpose that computer programmers tend to overlook. This happens because of many reasons amongst which probably the first one that comes to mind is that a programmer is interested mainly in the technical aspects and there is a lot of work to do already in that spot.
Talking about the taxis of an error message seems at first ridiculous when compared to the technically challenging problems within a compiler. At the same time, these small unnoticeable problems piled up together have the ability to degrade software overall by being perceived as unkempt, something that Delphi hasn't managed to resolve not even today with all its annoying tiny slips.
So this has nothing to do with ego, but more with what it says in the following quote from the article pointed by the second link:
Working in UX requires that you put your ego aside and remain open to different ideas and suggestions. It’s not about you—it’s about the alignment of user needs and business goals. This means you must be able to put your ego aside, listen to feedback, and remain open to new ideas.
-
But since we don't support win9x anymore, how long should we hold on to this?
But we do support DOS...
Sure. So keep it for DOS hosts. And require are parameter to enable it for the rest. But don't force this anachronism as a default for everybody.
+1
Besides, when truncating LFN to 8.3, shouldn't short name of MyLongFileName.ppu look like MYLONG~1.PPU or similar? That can be differentiated from MYLONGFI.PPU in code.