Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-11

Lazarus IDE searching units overwiev inquire (issue#10176 successor)

22 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrey Gusev

Is somebody (the kind people), who can explain to me about IDE searching units process details ?

More concrete:
which IDE tunables affects to searching units by IDE (or codetools) ?

And problem, that was not cosidered as bug:
Why IDE cannot find LCL and others-but-by-path-available units, when i open form, placed to other than project directory (that also included in paths) ?
This phenomenon is strongly obstruct to developing process in few aspects.

Thanks to anybody, who make respond.

Reply by email

Andrey Gusev
to Andrey Gusev

* Andrey Gusev [Thu, 15 Nov 2007 01:22:33 +0300]:

Why IDE cannot find LCL and others-but-by-path-available units, when i open form, placed to other than project directory (that also included

in

paths) ?

And why lazarus IDE have builded with FPC 2.2.0 (thanks to Vincent Snijders for hint) don't have such problem ?

I think, is that, nevertheless, must considered as bug!

Reply by email

Mattias Gaertner
to Andrey Gusev
* Andrey Gusev [Thu, 15 Nov 2007 01:22:33 +0300]: > Why IDE cannot find LCL and others-but-by-path-available units, > when i open form, placed to other than project directory (that also > included in paths) ?

It should.

And why lazarus IDE have builded with FPC 2.2.0 (thanks to Vincent Snijders for hint) don't have such problem ?

Either there is a bug in fpc 2.3.1 or a function changed its behaviour.

I think, is that, nevertheless, must considered as bug!

Yes.

Mattias

Reply by email

Mattias Gaertner
to Andrey Gusev: Is somebody (the kind people), who can explain to me about IDE searching units process…
Show quoted text 10 lines
Is somebody (the kind people), who can explain to me about IDE searching units process details ? More concrete: which IDE tunables affects to searching units by IDE (or codetools) ? And problem, that was not cosidered as bug: Why IDE cannot find LCL and others-but-by-path-available units, when i open form, placed to other than project directory (that also included in paths) ?

I may have misunderstood your descriptions in the bug tracker. It was not clear to me, that you added the units to the project, because the example showed no package dependency and a lot absolute paths.

This phenomenon is strongly obstruct to developing process in few aspects.

Many problems were solved by using fpc 2.2.0.
What questions are left?

Mattias

Reply by email

Andrey Gusev
to Mattias Gaertner: On Thu, 15 Nov 2007 01:22:33 +0300 I may have misunderstood your descriptions in the bug…

* Mattias Gaertner [Thu, 15 Nov 2007
00:13:03 +0100]:

I may have misunderstood your descriptions in the bug tracker. It was not clear to me, that you added the units to the project, because the example showed no package dependency and a lot absolute paths.

Exactly thus: some units, used in project, not included to project explicitly.
I do not see, why that not good.

Show quoted text 5 lines
> This phenomenon is strongly obstruct to developing process in few > aspects. Many problems were solved by using fpc 2.2.0. What questions are left?

fpc 2.3.1 implements automation, interfaces and so on - they needs to me in my work.
I have many of Delphi sources (both my own and foreign), that i would to port to FPC.

Reply by email

Andrey Gusev
to Andrey Gusev: Is somebody (the kind people), who can explain to me about IDE searching units process…

from issue comments (by Mattias Gaertner):

Show quoted text 5 lines
The codetools are not as strict as the compiler, can skip some simple syntax errors, and only reads what is needed, but it needs at least the units. Of course it would be theoretically possible to write some heuristics to guess what might be right, but every heuristic can guess wrong and this would create wrong code,

often without notice.

It will be fairy, when IDE will create at any manner (and at any price for IDE itself) the event procedure
(with strictly calculated parameters, guessed parameters, or, at all, stupidly, without any parameters) -
what to do with that, i will solve later: edit code by hands, correct the uses list, or correct project settings
(and after last two recreate the procedure with IDE). It seems the sentence is too complex to my English grammar knowledge... In present IDE behave itself as old bore, or as accountant, it's more clever in expectations.

Reply by email

Mattias Gaertner
to Andrey Gusev: * Mattias Gaertner [Thu, 15 Nov 2007 00:13:03 +0100]: Exactly thus: some units, used in…
Show quoted text 10 lines
* Mattias Gaertner [Thu, 15 Nov 2007 00:13:03 +0100]: > I may have misunderstood your descriptions in the bug tracker. > It was not clear to me, that you added the units to the project, > because the example showed no package dependency and a lot absolute > paths. Exactly thus: some units, used in project, not included to project explicitly. I do not see, why that not good.

You don't need to add every unit to a project or package. It is sufficient to add the the directories to the unit search path. But for update checks, and quick searches it is recommended to assign every unit to a specific project or package.

If a directory is not in the unit search path, then it will not get the project settings.
Every package and project has their own settings (search paths and compiler flags).

Because the IDE does not apply the project settings to everything (like Delphi), the developer finds dangling units quickly and the units can use only those units, that they should use. This reduces version conflicts, accidental auto rebuilds and context switches.

Show quoted text 8 lines
> > This phenomenon is strongly obstruct to developing process in few > > aspects. > > Many problems were solved by using fpc 2.2.0. > What questions are left? fpc 2.3.1 implements automation, interfaces and so on - they needs to me in my work.

I'm pretty sure, if the FPC team gets some good test examples, they can fix these things quickly.

I have many of Delphi sources (both my own and foreign), that i would to port to FPC.

Mattias

Reply by email

Mattias Gaertner
to Andrey Gusev: from issue comments (by Mattias Gaertner): often without notice. It will be fairy, when…
Show quoted text 19 lines
from issue comments (by Mattias Gaertner): > The codetools are not as strict as the compiler, > can skip some simple syntax errors, and only reads what is needed, > but it needs at least the units. Of course it would be theoretically > possible to write some heuristics to guess what might be right, > but every heuristic can guess wrong and this would create wrong > code, often without notice. It will be fairy, when IDE will create at any manner (and at any price for IDE itself) the event procedure (with strictly calculated parameters, guessed parameters, or, at all, stupidly, without any parameters) - what to do with that, i will solve later: edit code by hands, correct the uses list, or correct project settings (and after last two recreate the procedure with IDE). It seems the sentence is too complex to my English grammar knowledge... In present IDE behave itself as old bore, or as accountant, it's more clever in expectations.

Can you give an example?

Mattias

Reply by email

Vincent Snijders
to Mattias Gaertner: On Thu, 15 Nov 2007 01:44:22 +0300 It should. Either there is a bug in fpc 2.3.1 or a…
Mattias Gaertner wrote 17 lines
On Thu, 15 Nov 2007 01:44:22 +0300 Andrey Gusev wrote: > * Andrey Gusev [Thu, 15 Nov 2007 01:22:33 +0300]: >> Why IDE cannot find LCL and others-but-by-path-available units, >> when i open form, placed to other than project directory (that also >> included in paths) ? It should. > And why lazarus IDE have builded with FPC 2.2.0 (thanks to Vincent > Snijders for hint) don't have such problem ? Either there is a bug in fpc 2.3.1 or a function changed its behaviour.

Yiu can compile the IDE with fpc 2.2.0 and develop applications with fpc 2.3.1.

Vincent

Reply by email

Andrey Gusev
to Andrey Gusev: Is somebody (the kind people), who can explain to me about IDE searching units process…

I have ask to all at once.
==========================

* Mattias Gaertner [Thu, 15 Nov 2007

You don't need to add every unit to a project or package. It is sufficient to add the the directories to the unit search path. But for update checks, and quick searches it is recommended to assign every unit to a specific project or package

AG: i.e. with project->add unit ?

----------------

If a directory is not in the unit search path, then it will not get

the

project settings.

AG: From which (search) paths, have a few tunables ?

----------------

Because the IDE does not apply the project settings to everything

(like

Delphi), the developer finds dangling units quickly and the units can use only those units, that they should use. This reduces version conflicts, accidental auto rebuilds and context switches.

AG: That is all fine, but the full control ability (of search process) interested to me !

----------------

AG> ... AG> knowledge... In present IDE behave itself as old bore, or as AG> accountant, it's more clever in expectations.

Mattias> Can you give an example?

AG: What example?, that IDE behaviour remember to me an old bore ? :)

----------------

Vincent Snijders>Yiu can compile the IDE with fpc 2.2.0 and develop applications with fpc

2.3.1.

AG: You right, for my production-critical tasks i will have deed just so.

=====================
and last

A have construct a quite simple sample, that demonstrates FPC231<=>Lazarus lacks.
It is only simplified exposition of #10176 issue. I will bring new issue, as soon as
manits will available. As was supposed by me, the presence of my own form ancestor
is essential to "unit-read-error" revealing (the IDE-old-bor'ity :) )

A think, that discuss subject "Must IDE editor be such intelligent (in syntax comprehension sense) as compiler, or syntax highlighting is enough ?"
would be useful.
What thoughts developers respected about this ?

Reply by email

Mattias Gaertner
to Andrey Gusev
Show quoted text 10 lines
I have ask to all at once. ========================== * Mattias Gaertner [Thu, 15 Nov 2007 > You don't need to add every unit to a project or package. It is > sufficient to add the the directories to the unit search path. > But for update checks, and quick searches it is recommended to > assign every unit to a specific project or package AG: i.e. with project->add unit ?

Yes. Or Project Inspector / Add / Add files.

Show quoted text 7 lines
---------------- > If a directory is not in the unit search path, then it will not get the > project settings. AG: From which (search) paths, have a few tunables ?

Sorry, my english is not good enough. What do you mean?

Show quoted text 10 lines
---------------- > Because the IDE does not apply the project settings to everything (like > Delphi), the developer finds dangling units quickly and the units > can use only those units, that they should use. This reduces version > conflicts, accidental auto rebuilds and context switches. AG: That is all fine, but the full control ability (of search process) interested to me !

What do you mean with interested in full control ability? Do you want to know all places/flags that control the final unit search path? Or do you want one more possibility to control/setup the unit search path?

Show quoted text 8 lines
---------------- >AG> ... >AG> knowledge... In present IDE behave itself as old bore, or as >AG> accountant, it's more clever in expectations. Mattias> Can you give an example? AG: What example?, that IDE behaviour remember to me an old bore ? :)

An example how to improve it.

Show quoted text 19 lines
---------------- Vincent Snijders>Yiu can compile the IDE with fpc 2.2.0 and develop applications with fpc > 2.3.1. AG: You right, for my production-critical tasks i will have deed just so. ===================== and last A have construct a quite simple sample, that demonstrates FPC231<=>Lazarus lacks. It is only simplified exposition of #10176 issue. I will bring new issue, as soon as manits will available. As was supposed by me, the presence of my own form ancestor is essential to "unit-read-error" revealing (the IDE-old-bor'ity :) )

The IDE now skips silently missing units when searching for ancestor forms.

Show quoted text 5 lines
A think, that discuss subject "Must IDE editor be such intelligent (in syntax comprehension sense) as compiler, or syntax highlighting is enough ?" would be useful. What thoughts developers respected about this ?

Mattias

Reply by email

Andrey Gusev
to Mattias Gaertner

* Mattias Gaertner [Thu, 15 Nov 2007
19:16:55 +0100]:

> > If a directory is not in the unit search path, then it will not

get

> > the project settings. > > AG: From which (search) paths, have a few tunables ? Sorry, my english is not good enough. What do you mean?

The "Other sources (used only by IDE)..." tunable - that setting, what "will not get" ?

Show quoted text 7 lines
> AG: That is all fine, but the full control ability (of search > process) interested to me ! What do you mean with interested in full control ability? Do you want to know all places/flags that control the final unit search path? Or do you want one more possibility to control/setup the unit search path?

I must precisely knows how tune project settings to all my units be found (i already knew it, thanks to ours disscussions). That sense: if whatever fundamental don't works properly, then secondary things is unimportant.
apropos: "--debug-out" is usable to penetrate into units searching process ?

(about bad IDE behaviour)

An example how to improve it.

I have a few (the two) ideas, but at first i must explore sources and do some experiments with it.

The IDE now skips silently missing units when searching for ancestor

forms.
I have redirect dialog messages (the first simple idea) form dialogprocs.LoadCodeBuffer() to my own logger window. Thanks for your respond. It will be reflect to bugtracker ?

The second idea - about event reactors insertion, but she is not complete.

Reply by email

Mattias Gaertner
to Andrey Gusev
Show quoted text 11 lines
* Mattias Gaertner [Thu, 15 Nov 2007 19:16:55 +0100]: > > > If a directory is not in the unit search path, then it will not get > > > the project settings. > > > > AG: From which (search) paths, have a few tunables ? > Sorry, my english is not good enough. What do you mean? The "Other sources (used only by IDE)..." tunable - that setting, what "will not get" ?

The compiler.

Show quoted text 14 lines
> > AG: That is all fine, but the full control ability (of search > > process) interested to me ! > > What do you mean with interested in full control ability? > Do you want to know all places/flags that control the final unit > search path? Or do you want one more possibility to control/setup > the unit search path? I must precisely knows how tune project settings to all my units be found (i already knew it, thanks to ours disscussions). That sense: if whatever fundamental don't works properly, then secondary things is unimportant. apropos: "--debug-out" is usable to penetrate into units searching process ?

--debug-out is mainly for windows, where the normal hints to stdout are hidden. With --debug-out=log.txt you can save the IDE hints to a file. Normally the IDE only writes some basic hints.
The IDE can be compiled with various flags to get a lot more output, but this only usable to hunt bugs and hardly used, so this is not documented. See for example the header of
components/codetools/finddeclarationtool.pas for a list of possible verbosity flags.
Normal users (including developers not used to these parts of the IDE) should use the Source Editor / Popup Menu / Unit Info.

Show quoted text 11 lines
(about bad IDE behaviour) > An example how to improve it. I have a few (the two) ideas, but at first i must explore sources and do some experiments with it. > The IDE now skips silently missing units when searching for > ancestor forms. I have redirect dialog messages (the first simple idea) form dialogprocs.LoadCodeBuffer() to my own logger window. Thanks for your respond. It will be reflect to bugtracker ?

Please give feedback in the bug tracker, what part of the bug is still open.

The second idea - about event reactors insertion, but she is not complete.

Mattias

Reply by email

Andrey Gusev
to Mattias Gaertner

* Mattias Gaertner [Fri, 16 Nov 2007
00:29:26 +0100]:

Please give feedback in the bug tracker, what part of the bug is still open.

How i can make give back the previous "read units" behaviour, with last 12893 revision ?
That to my logging patch will efficient.
Sample project, published in #10182 issue now loads cleanly, but with my combat project
i have continue get "Unable to find unit of component class...". It was tried --debug-out but
without result.

Reply by email

Mattias Gaertner
to Andrey Gusev
Show quoted text 12 lines
* Mattias Gaertner [Fri, 16 Nov 2007 00:29:26 +0100]: > Please give feedback in the bug tracker, what part of the bug is > still open. How i can make give back the previous "read units" behaviour, with last 12893 revision ? That to my logging patch will efficient. Sample project, published in #10182 issue now loads cleanly, but with my combat project i have continue get "Unable to find unit of component class...". It was tried --debug-out but without result.

Can you send me the debug log and tell me the file structure?

Mattias

Reply by email

Andrey Gusev
to Mattias Gaertner

* Mattias Gaertner [Fri, 16 Nov 2007
11:44:26 +0100]:

Can you send me the debug log and tell me the file structure?

The --debug-out result is empty (i.e. namely the log file was not created).
File with form ancestor (fetched from my combat project) has publised in #10176
issue.

It seems somewhat pulled what was not included to paths... So full silence also is not good.

Reply by email

Mattias Gaertner
to Andrey Gusev: * Mattias Gaertner [Fri, 16 Nov 2007 11:44:26 +0100]: The --debug-out result is empty…
Show quoted text 6 lines
* Mattias Gaertner [Fri, 16 Nov 2007 11:44:26 +0100]: > Can you send me the debug log and tell me the file structure? The --debug-out result is empty (i.e. namely the log file was not created).

There is always some output. Are you sure, that you used the --debug-log=C:\lazlog.txt parameter correctly?

File with form ancestor (fetched from my combat project) has publised in #10176 issue.

Yes, but this example works here (linux,fpc 2.3.1) without errors (except for invalid UTF-8 strings), so I need more information.

It seems somewhat pulled what was not included to paths... So full silence also is not good.

Mattias

Reply by email

Andrey Gusev
to Mattias Gaertner

* Mattias Gaertner [Fri, 16 Nov 2007
12:35:26 +0100]:

There is always some output. Are you sure, that you used the --debug-log=C:\lazlog.txt parameter correctly?

Sorry, mistyped.
The log is attached.

Yes, but this example works here (linux,fpc 2.3.1) without errors (except for invalid UTF-8 strings), so I need more information.

I cannot convey all sources - it is official production material. So will have collaborative investigation.

Reply by email

Mattias Gärtner
to Andrey Gusev

Zitat von Andrey Gusev :

Show quoted text 8 lines
Some units cannot be found by IDE (in editor), as earlier. --- (from message box) C:\Works-FContr\Contracts\gen\gen2\WaybillG.pas(13,50) Error: unit not found: darrInt --- but, corresponding directory is correctly prescibed to both compiler and IDE paths (first and third boxes in compiler options window, paths tab).

The IDE uses the first plus the third box. So, no need to add it to both. See
http://wiki.lazarus.freepascal.org/index.php/IDE_Window:_Compiler_Options

What shows Source Editor / Popup menu / Unit Info as "unit paths" and "source paths" for the WaybillG.pas?

Mattias

Reply by email