Discussion:
Congrats on the new project options screen
(too old to reply)
Reinier Olislagers
2013-08-04 08:38:05 UTC
Permalink
Guys,

I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.

Thanks a lot!

Reinier

--
Juha Manninen
2013-08-04 11:34:05 UTC
Permalink
On Sun, Aug 4, 2013 at 11:38 AM, Reinier Olislagers
Post by Reinier Olislagers
I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.
How about the new GUI for all available compiler options? Comments anybody?

Juha

--
Paul Ishenin
2013-08-04 11:51:32 UTC
Permalink
Post by Juha Manninen
How about the new GUI for all available compiler options? Comments anybody?
I prefere a property grid instead of creation of 100+ controls.

Best regards,
Paul Ishenin

--
Juha Manninen
2013-08-04 15:48:36 UTC
Permalink
Post by Paul Ishenin
I prefere a property grid instead of creation of 100+ controls.
Hi
I may change the GUI for a grid later. Now I try to get the parser to
work etc. Many of the problems are not related to GUI controls
directly.

Juha

--
Ludo Brands
2013-08-04 12:07:19 UTC
Permalink
Post by Juha Manninen
On Sun, Aug 4, 2013 at 11:38 AM, Reinier Olislagers
Post by Reinier Olislagers
I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.
How about the new GUI for all available compiler options? Comments anybody?
Just installed it. Here is how it looks on Kubuntu 12.04 default
settings:
Loading Image... :(
The debugging panels are better organized but the bottom one is clearly
too short: Loading Image...


Ludo

--
Ludo Brands
2013-08-04 13:30:59 UTC
Permalink
Post by Ludo Brands
Post by Juha Manninen
On Sun, Aug 4, 2013 at 11:38 AM, Reinier Olislagers
Post by Reinier Olislagers
I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.
How about the new GUI for all available compiler options? Comments anybody?
Just installed it. Here is how it looks on Kubuntu 12.04 default
https://dl.dropboxusercontent.com/u/61365485/compiler%20options.png :(
The debugging panels are better organized but the bottom one is clearly
too short: https://dl.dropboxusercontent.com/u/61365485/debugging.png
After Mattias' comments, figured out that you are clearly talking about
a different window. Thanks for letting knowing that. For those
interested, the window in question can be found by going to "Project
Options"/"Compiler Options"/"Other" and then click on "All Options ..."
button in the Custom Options panel.

Comments:
- there is a horizontal scroll bar but several strings are simply cut off
- can't specify multiple -Oo optimizations.
- -Oo options disappear when clicking on "All Options ..." again.
Independent if you leave the [No] in the option or not
- no support for spaces in the -o, -l options or any other option taking
a path or filename. Adding quotes doesn't change this behavior.
- FreeBSD is missing from the targets
- you can check mutually exclusive settings such as all the -M options
- for one reason or another, vertical scrolling with the scroll bar is
very jumpy. As if the cpu is running at 100%. This is not the case
though, "only" 2 cores of an i7 at 40%.
- -Cf options are not split up, you can only select
-CfSSE64,SSE3,SSSE3,SSE41,SSE42,AVX

Ludo



--
Mattias Gaertner
2013-08-04 13:51:38 UTC
Permalink
On Sun, 04 Aug 2013 15:30:59 +0200
Post by Ludo Brands
Post by Ludo Brands
Post by Juha Manninen
On Sun, Aug 4, 2013 at 11:38 AM, Reinier Olislagers
Post by Reinier Olislagers
I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.
How about the new GUI for all available compiler options? Comments anybody?
Just installed it. Here is how it looks on Kubuntu 12.04 default
https://dl.dropboxusercontent.com/u/61365485/compiler%20options.png :(
The debugging panels are better organized but the bottom one is clearly
too short: https://dl.dropboxusercontent.com/u/61365485/debugging.png
After Mattias' comments, figured out that you are clearly talking about
a different window. Thanks for letting knowing that. For those
interested, the window in question can be found by going to "Project
Options"/"Compiler Options"/"Other" and then click on "All Options ..."
button in the Custom Options panel.
- there is a horizontal scroll bar but several strings are simply cut off
- can't specify multiple -Oo optimizations.
- -Oo options disappear when clicking on "All Options ..." again.
Independent if you leave the [No] in the option or not
- no support for spaces in the -o,
The -o option should not be listed there. It interferes with the IDE.
Same for -v* and -T.
The -i options are useless here.
Post by Ludo Brands
-l options or any other option taking a path or filename.
Funny, that you mention the -l option as example for that.
Post by Ludo Brands
Adding quotes doesn't change this behavior.
- FreeBSD is missing from the targets
- you can check mutually exclusive settings such as all the -M options
- for one reason or another, vertical scrolling with the scroll bar is
very jumpy. As if the cpu is running at 100%. This is not the case
though, "only" 2 cores of an i7 at 40%.
- -Cf options are not split up, you can only select
-CfSSE64,SSE3,SSSE3,SSE41,SSE42,AVX
Mattias

--
Juha Manninen
2013-08-04 17:24:24 UTC
Permalink
On Sun, Aug 4, 2013 at 4:51 PM, Mattias Gaertner
Post by Mattias Gaertner
The -o option should not be listed there. It interferes with the IDE.
Same for -v* and -T.
The -i options are useless here.
Post by Ludo Brands
-l options or any other option taking a path or filename.
Funny, that you mention the -l option as example for that.
Ok, -o must go, and -T, and -M, and -i, and many others, but most -v*
should be safe. I already removed the dangerous ones earlier.
The all-options GUI will finally have much less options than I
thought, but that is OK. New options in future FPC versions will be
shown which is important.

Juha

--
Mark Morgan Lloyd
2013-08-04 18:09:32 UTC
Permalink
Post by Juha Manninen
On Sun, Aug 4, 2013 at 4:51 PM, Mattias Gaertner
Post by Mattias Gaertner
The -o option should not be listed there. It interferes with the IDE.
Same for -v* and -T.
The -i options are useless here.
Post by Ludo Brands
-l options or any other option taking a path or filename.
Funny, that you mention the -l option as example for that.
Ok, -o must go, and -T, and -M, and -i, and many others, but most -v*
should be safe. I already removed the dangerous ones earlier.
The all-options GUI will finally have much less options than I
thought, but that is OK. New options in future FPC versions will be
shown which is important.
Does this yet address non-x86 targets? If so I'd better start testing on
SPARC, PPC etc. (what FPC version does Lazarus trunk currently assume)?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mattias Gaertner
2013-08-04 18:25:45 UTC
Permalink
On Sun, 04 Aug 2013 18:09:32 +0000
Post by Mark Morgan Lloyd
Post by Juha Manninen
On Sun, Aug 4, 2013 at 4:51 PM, Mattias Gaertner
[...]
Post by Juha Manninen
Ok, -o must go, and -T, and -M, and -i, and many others, but most -v*
should be safe. I already removed the dangerous ones earlier.
The all-options GUI will finally have much less options than I
thought, but that is OK. New options in future FPC versions will be
shown which is important.
Does this yet address non-x86 targets? If so I'd better start testing on
SPARC, PPC etc. (what FPC version does Lazarus trunk currently assume)?
It addresses all targets. That's the idea of parsing the fpc output
instead of maintaining our own list.

Mattias

--
Mark Morgan Lloyd
2013-08-04 21:09:45 UTC
Permalink
Post by Mattias Gaertner
On Sun, 04 Aug 2013 18:09:32 +0000
Post by Mark Morgan Lloyd
Post by Juha Manninen
On Sun, Aug 4, 2013 at 4:51 PM, Mattias Gaertner
[...]
Post by Juha Manninen
Ok, -o must go, and -T, and -M, and -i, and many others, but most -v*
should be safe. I already removed the dangerous ones earlier.
The all-options GUI will finally have much less options than I
thought, but that is OK. New options in future FPC versions will be
shown which is important.
Does this yet address non-x86 targets? If so I'd better start testing on
SPARC, PPC etc. (what FPC version does Lazarus trunk currently assume)?
It addresses all targets. That's the idea of parsing the fpc output
instead of maintaining our own list.
OK, I'll try to test on at least SPARC and PPC. What version of FPC does
trunk require these days?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mattias Gaertner
2013-08-04 21:31:34 UTC
Permalink
On Sun, 04 Aug 2013 21:09:45 +0000
Post by Mark Morgan Lloyd
Post by Mattias Gaertner
On Sun, 04 Aug 2013 18:09:32 +0000
[...]
Post by Mattias Gaertner
It addresses all targets. That's the idea of parsing the fpc output
instead of maintaining our own list.
OK, I'll try to test on at least SPARC and PPC.
Thanks.
Post by Mark Morgan Lloyd
What version of FPC does trunk require these days?
To compile the IDE you need the last release (2.6.2) or trunk. 2.6.0
might also work, but that is rarely tested.
The compiler options should work even with old fpc.

Mattias

--
Mark Morgan Lloyd
2013-08-07 08:28:50 UTC
Permalink
Post by Mattias Gaertner
Post by Mark Morgan Lloyd
Post by Mattias Gaertner
It addresses all targets. That's the idea of parsing the fpc output
instead of maintaining our own list.
OK, I'll try to test on at least SPARC and PPC.
To compile the IDE you need the last release (2.6.2) or trunk. 2.6.0
might also work, but that is rarely tested.
The compiler options should work even with old fpc.
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked out. I
can't currently test ARM, MIPS etc.

Lazarus trunk doesn't run on SPARC,
http://bugs.freepascal.org/view.php?id=23703 plus at least one other.

The new options form looks OK on PPC (32-bit) Linux.

I think there are some options which could be usefully filtered out, at
the very least -?.

I imagine it's going to be "fun" reconciling any options modified on the
"All Options" form with the existing "Config and Target"
http://bugs.freepascal.org/view.php?id=20311
http://bugs.freepascal.org/view.php?id=20310 etc.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
martin
2013-08-07 09:14:44 UTC
Permalink
Post by Mark Morgan Lloyd
Post by Mattias Gaertner
Post by Mark Morgan Lloyd
Post by Mattias Gaertner
It addresses all targets. That's the idea of parsing the fpc output
instead of maintaining our own list.
OK, I'll try to test on at least SPARC and PPC.
To compile the IDE you need the last release (2.6.2) or trunk. 2.6.0
might also work, but that is rarely tested.
The compiler options should work even with old fpc.
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked out.
I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and work
on ppc



btw, what OS? and are there any good instructions how to get it/them
going under qemu?

--
Mark Morgan Lloyd
2013-08-07 11:05:18 UTC
Permalink
I must add that real SPARC systems are cheap, even relative to how much
cash I'm able to throw at this sort of thing.
..although it would be great if I had something a bit faster for big
jobs. I've got a pile of 25 1U servers downstairs (cost £5 but we had to
collect), having an FPC equivalent of distcc would be really smart :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mark Morgan Lloyd
2013-08-07 09:43:52 UTC
Permalink
Post by martin
Post by Mark Morgan Lloyd
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked out.
I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and work
on ppc
I'll check and report back later. I think that the last Lazarus version
I had running was 1.0.4, which predates those components.
Post by martin
btw, what OS? and are there any good instructions how to get it/them
going under qemu?
Linux, Debian, in most cases "Lenny" + KDE + gtk2. A word of explanation
there before I'm accused of wilfully using obsolete operating systems:
there are outstanding bugs that have remained unfixed for several years
in Debian SPARC, which affect not only KDE but also XFCE etc. I'm happy
enough to use newer versions headless (i.e. no graphical stuff on them
at all), but the triage principle has forced me to draw a line for
desktop systems.

I've never tried running SPARC or PPC on Qemu, since I've got real
hardware (I'm expecting to get my hands on some more Macs tomorrow,
which will give me more chance of testing OS X occasionally). However
I've generally found that the notes I put at
http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators are tolerant
of different guest systems, some of the stuff is a bit of a non-standard
hack but it works for me.

I must add that real SPARC systems are cheap, even relative to how much
cash I'm able to throw at this sort of thing.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mark Morgan Lloyd
2013-08-07 12:47:55 UTC
Permalink
Post by martin
Post by Mark Morgan Lloyd
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked out.
I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and work
on ppc
This on Linux PPC, something similar on Linux SPARC:

make[2]: Entering directory
`/usr/local/share/lazarus-trunk/components/PascalScript/Source'
/bin/rm -f lib/powerpc-linux/pascalscript.ppu
/usr/local/bin/ppcppc -MObjFPC -Scghi -O1 -g -gl -vewni -l -dLCL
-dLCLgtk2 -Fu../../../packager/units/powerpc-linux
-Fu../../lazutils/lib/powerpc-linux -Fu../../../lcl/units/powerpc-linux
-Fu../../../lcl/units/powerpc-linux/gtk2 -Fu.
-Fu/usr/local/lib/fpc/2.6.2/units/powerpc-linux/rtl -FE.
-FUlib/powerpc-linux -k-t -k--stats -dpowerpc pascalscript.pas
Free Pascal Compiler version 2.6.2 [2013/08/06] for powerpc
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Linux for PowerPC
Compiling pascalscript.pas
Compiling uPSRuntime.pas
Compiling uPSUtils.pas
Writing Resource String Table file: uPSUtils.rst
Assembling upsutils
uPSRuntime.pas(1860,17) Warning: Conversion between ordinals and
pointers is not portable
..
uPSRuntime.pas(8717,8) Warning: Converting pointers to signed integers
may result in wrong comparison results and range errors, use an unsigned
type instead.
powerpc.inc(5,4) Fatal: User defined: This code is Darwin specific at
the moment!
Fatal: Compilation aborted
make[2]: *** [pascalscript.ppu] Error 1
make[2]: Leaving directory
`/usr/local/share/lazarus-trunk/components/PascalScript/Source'
make[1]: *** [bigide] Error 2
make[1]: Leaving directory `/usr/local/share/lazarus-trunk/components'
make: *** [bigidecomponents] Error 2
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
martin
2013-08-07 14:47:15 UTC
Permalink
Post by Mark Morgan Lloyd
Post by martin
Post by Mark Morgan Lloyd
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked
out. I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and
work on ppc
...
Post by Mark Morgan Lloyd
uPSRuntime.pas(8717,8) Warning: Converting pointers to signed integers
may result in wrong comparison results and range errors, use an
unsigned type instead.
powerpc.inc(5,4) Fatal: User defined: This code is Darwin specific at
the moment!
Fatal: Compilation aborted
try to replace the {$fatal ... } directive, with a
raise exception.create('not supported on ...');

the IDE checks on start, and will permanently disable


--
Mark Morgan Lloyd
2013-08-07 15:03:19 UTC
Permalink
Post by martin
Post by Mark Morgan Lloyd
Post by martin
Post by Mark Morgan Lloyd
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build on
SPARC or PPC unless PascalScript and EditorMacroScript are hacked
out. I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and
work on ppc
...
Post by Mark Morgan Lloyd
uPSRuntime.pas(8717,8) Warning: Converting pointers to signed integers
may result in wrong comparison results and range errors, use an
unsigned type instead.
powerpc.inc(5,4) Fatal: User defined: This code is Darwin specific at
the moment!
Fatal: Compilation aborted
try to replace the {$fatal ... } directive, with a
raise exception.create('not supported on ...');
the IDE checks on start, and will permanently disable
Sorry to sound dense, but where should I be doing this? I'd add that I
was building from a shell session with make bigide rather than from
inside the IDE.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
martin
2013-08-07 15:40:23 UTC
Permalink
Post by Mark Morgan Lloyd
Post by martin
Post by Mark Morgan Lloyd
Post by martin
Post by Mark Morgan Lloyd
Using 2.6.2 on Linux, trunk (with bigide) currently doesn't build
on SPARC or PPC unless PascalScript and EditorMacroScript are
hacked out. I can't currently test ARM, MIPS etc.
what errors does the compiler give? IIRC they used to compile and
work on ppc
...
Post by Mark Morgan Lloyd
uPSRuntime.pas(8717,8) Warning: Converting pointers to signed
integers may result in wrong comparison results and range errors,
use an unsigned type instead.
powerpc.inc(5,4) Fatal: User defined: This code is Darwin specific
at the moment!
Fatal: Compilation aborted
try to replace the {$fatal ... } directive, with a
raise exception.create('not supported on ...');
the IDE checks on start, and will permanently disable
Sorry to sound dense, but where should I be doing this? I'd add that I
was building from a shell session with make bigide rather than from
inside the IDE.
powerpc.inc should be in components/PascalScript/Source

line 269, start of
function TPSExec.InnerfuseCall
(after the nested ...)


and remove BOTH $fatal at the top of file

--
Mark Morgan Lloyd
2013-08-08 10:00:56 UTC
Permalink
Post by martin
Post by Mark Morgan Lloyd
Post by martin
try to replace the {$fatal ... } directive, with a
raise exception.create('not supported on ...');
the IDE checks on start, and will permanently disable
Sorry to sound dense, but where should I be doing this? I'd add that I
was building from a shell session with make bigide rather than from
inside the IDE.
powerpc.inc should be in components/PascalScript/Source
line 269, start of
function TPSExec.InnerfuseCall
(after the nested ...)
and remove BOTH $fatal at the top of file
That fixes it on PPC, with the side effect that there's a warning
dialogue during the first startup. I'll take a look at the Sparc
situation later.

Should I Mantis this with the fix?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Juha Manninen
2013-08-07 09:42:20 UTC
Permalink
On Wed, Aug 7, 2013 at 11:28 AM, Mark Morgan Lloyd
I think there are some options which could be usefully filtered out, at the
very least -?.
Oops, the filtering out code was broken. Now it works again in r42367.
I imagine it's going to be "fun" reconciling any options modified on the
"All Options" form with the existing "Config and Target"
http://bugs.freepascal.org/view.php?id=20311
http://bugs.freepascal.org/view.php?id=20310 etc.
I am not sure if we want that. The idea of parsing the fpc's help
output is to support all available options, including the future ones
added by fpc developers. It does not make sense to analyze their
meaning much.

Important options must have their own dedicated and intelligent GUIs.
The bugs you listed must be fixed obviously.
If someone sets the same option using both a dedicated GUI and the all
options GUI, no problem, the compiler accepts it.

I improved the parser so that -Oo, -OW and -Ow options are selectable
individually instead of a drop-down list.
Only the quoted strings must be handled better, otherwise the parser is OK.
The GUI may be changed to a grid but that is another thing.

Dimitry is working on a competing solution with self made JSON config
files. They are easier to parse but they must be maintained for every
fpc version and architechture. Forgetting the maintenance undermines
the whole idea.
IMO the right place for such info is the fpc project itself.

Juha

--
Juha Manninen
2013-08-07 09:58:11 UTC
Permalink
One more thing:
FPC could give much better and consistent info about the options than
what the current "fpc -i" and "fpc -h" do.
For example the help refers to "fpc -i" for possible values for
selection lists but does not mention which list to look for. I had to
make a hard-coded mapping which again undermines the idea of a generic
parser.
Also, -Oo, -OW and -Ow options must be hard-coded to show individual options.

Can somebody please verify that my guesses were right. I hope in
future fpc help will be more exact and consistent. It would benefit
not only my parser but also human readers.

Juha

--
Sven Barth
2013-08-07 10:00:30 UTC
Permalink
Post by Juha Manninen
I hope in
future fpc help will be more exact and consistent.
Considering that the current help output of FPC is subject to human
error => no.

Regards,
Sven


--
Juha Manninen
2013-08-07 10:05:17 UTC
Permalink
Considering that the current help output of FPC is subject to human error =>
no.
What does that mean?
Any human activity is subject to human error.

Juha

--
Sven Barth
2013-08-07 10:09:53 UTC
Permalink
Post by Juha Manninen
Considering that the current help output of FPC is subject to human error =>
no.
What does that mean?
Any human activity is subject to human error.
Yes, but the help output is especially evolved with human activity (e.g.
if one adds a new target one needs to remember to add the new target to
the help output as well) and considering that the help output is rather
easily forgotten it's in my opinion rather unlikely that the help output
is kept more precise/up to date than it is currently.

Though as usual patches to improve the situation are welcome ;)

Regards,
Sven

--
Mattias Gaertner
2013-08-07 10:24:47 UTC
Permalink
Post by Sven Barth
Post by Juha Manninen
Considering that the current help output of FPC is subject to human error =>
no.
What does that mean?
Any human activity is subject to human error.
Yes, but the help output is especially evolved with human activity (e.g.
if one adds a new target one needs to remember to add the new target to
the help output as well) and considering that the help output is rather
easily forgotten it's in my opinion rather unlikely that the help output
is kept more precise/up to date than it is currently.
At least the outdated state is consistent. Both the IDE and fpc -h will show the
same bug.
And as far as I know the help is updated before any fpc release, so it should be
accurate for the fpc releases.
Post by Sven Barth
Though as usual patches to improve the situation are welcome ;)
Mattias

--
Juha Manninen
2013-08-07 10:40:44 UTC
Permalink
On Wed, Aug 7, 2013 at 1:24 PM, Mattias Gaertner
Post by Mattias Gaertner
At least the outdated state is consistent. Both the IDE and fpc -h will show the
same bug.
And as far as I know the help is updated before any fpc release, so it should be
accurate for the fpc releases.
Yes, I believe the release versions don't have wrong or missing options.
I was writing about other missing info. Especially the mapping between
"fpc -i" and "fpc -h" for selection lists is missing. I myself am not
sure if I got them right. Any new user will have to guess them.
There are other weird inconsistencies. For example FPC trunk changed
the FPU selection list to a comma separated list while all other lists
are separated with a newline.

Juha

--
Juha Manninen
2013-08-07 10:17:53 UTC
Permalink
On Wed, Aug 7, 2013 at 1:05 PM, Mark Morgan Lloyd
Would there be any mileage in having the compiler output this sort of thing
in XML or some similar formal markup?
Yes, that would be ideal. We discussed it with Lazarus devels.
In July 26 Mattias asked it in FPC devel list. Subject is "compiler
switches machine readable".
Jonas answered that it requires manual maintenance for new options and
I understood he is not happy with the idea. I am planning to write
there later myself.
What happens if the compiler emits any language other than English?
Nothing good I guess. There are some English key-words the parser looks for.

Juha

--
Mattias Gaertner
2013-08-07 10:31:16 UTC
Permalink
Post by Juha Manninen
On Wed, Aug 7, 2013 at 1:05 PM, Mark Morgan Lloyd
Would there be any mileage in having the compiler output this sort of thing
in XML or some similar formal markup?
Yes, that would be ideal. We discussed it with Lazarus devels.
In July 26 Mattias asked it in FPC devel list. Subject is "compiler
switches machine readable".
Jonas answered that it requires manual maintenance for new options and
I understood he is not happy with the idea. I am planning to write
there later myself.
What happens if the compiler emits any language other than English?
Nothing good I guess. There are some English key-words the parser looks for.
The non English message files have various encodings, which are not documented.
So using them x-platform is difficult. I suggest to use the English message file
by default and maybe add an option to show a one of the translations.

Mattias

--
Mark Morgan Lloyd
2013-08-07 10:46:44 UTC
Permalink
Post by Juha Manninen
On Wed, Aug 7, 2013 at 1:05 PM, Mark Morgan Lloyd
Would there be any mileage in having the compiler output this sort of thing
in XML or some similar formal markup?
Yes, that would be ideal. We discussed it with Lazarus devels.
In July 26 Mattias asked it in FPC devel list. Subject is "compiler
switches machine readable".
Jonas answered that it requires manual maintenance for new options and
I understood he is not happy with the idea. I am planning to write
there later myself.
Noting that you mentioned JSON elsewhere in the thread, I'd have hoped
that something like a -hh option which formalised the various levels of
output text (and also used untranslated English) wouldn't have been too
difficult, the current freeform output could be a derivative.

I'm no great enthusiast of "JSON (or XML) for everything", but I
occasionally have to make remote diagnostic connections to equipment
where things like line-ending/prompt consistency vary by firmware version.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Juha Manninen
2013-08-07 11:01:50 UTC
Permalink
On Wed, Aug 7, 2013 at 1:46 PM, Mark Morgan Lloyd
Noting that you mentioned JSON elsewhere in the thread, I'd have hoped that
something like a -hh option which formalised the various levels of output
text (and also used untranslated English) wouldn't have been too difficult,
the current freeform output could be a derivative.
We could offer the JSON format that Dimitry is working on for FPC as a
patch, once it is tested well.
-hh or -j could be used to get it.
Dimitry's idea now is to maintain the config inside Lazarus project
but IMO it really should be maintained inside FPC project. It is a
more logical place and then it has a better chance to be updated in
the long run.

Juha

--
Sven Barth
2013-08-07 11:14:11 UTC
Permalink
Post by Juha Manninen
-hh or -j could be used to get it.
Single letter options are not accepted anymore as they restrict the
available parameter space too much.

Regards,
Sven

--
Sven Barth
2013-08-07 11:14:50 UTC
Permalink
Post by Sven Barth
Post by Juha Manninen
-hh or -j could be used to get it.
Single letter options are not accepted anymore as they restrict the
available parameter space too much.
*New* single letter options (...)

Regards,
Sven

--
Mark Morgan Lloyd
2013-08-07 10:05:30 UTC
Permalink
Post by Juha Manninen
FPC could give much better and consistent info about the options than
what the current "fpc -i" and "fpc -h" do.
For example the help refers to "fpc -i" for possible values for
selection lists but does not mention which list to look for. I had to
make a hard-coded mapping which again undermines the idea of a generic
parser.
Also, -Oo, -OW and -Ow options must be hard-coded to show individual options.
Can somebody please verify that my guesses were right. I hope in
future fpc help will be more exact and consistent. It would benefit
not only my parser but also human readers.
Would there be any mileage in having the compiler output this sort of
thing in XML or some similar formal markup?

What happens if the compiler emits any language other than English?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Ludo Brands
2013-08-05 05:45:40 UTC
Permalink
Post by Mattias Gaertner
On Sun, 04 Aug 2013 15:30:59 +0200
Post by Ludo Brands
-l options or any other option taking a path or filename.
Funny, that you mention the -l option as example for that.
I need new spectacles. There is only one pixel difference between I en l
with the default font used for the IDE on Kubuntu :)

Ludo


--
Juha Manninen
2013-08-04 17:15:53 UTC
Permalink
Post by Ludo Brands
- there is a horizontal scroll bar but several strings are simply cut off
Resizing the options window should help. (?)
Post by Ludo Brands
- can't specify multiple -Oo optimizations.
- -Oo options disappear when clicking on "All Options ..." again.
Independent if you leave the [No] in the option or not
If multiple -Oos are needed then we must have a different GUI for them.
Post by Ludo Brands
- no support for spaces in the -o, -l options or any other option taking
a path or filename. Adding quotes doesn't change this behavior.
Right. I will look at that.
Post by Ludo Brands
- FreeBSD is missing from the targets
A bug in FPC. The options are parsed directly from "fpc -h".
This is a nasty situation because the all-options GUI now overwrites
the hand-written custom options.
Post by Ludo Brands
- you can check mutually exclusive settings such as all the -M options
This is also nasty. The idea is to offer options parsed from "fpc -h"
without analyzing their meaning. Important options still have their
dedicated GUIs. I think (also) -M must be left out from this
all-options GUI.
Post by Ludo Brands
- for one reason or another, vertical scrolling with the scroll bar is
very jumpy. As if the cpu is running at 100%. This is not the case
though, "only" 2 cores of an i7 at 40%.
Not here. Your Kubuntu has some config issues. The ScrollBars have
smooth scrolling enabled and it works well here, using both GTK2 and
QT.
Post by Ludo Brands
- -Cf options are not split up, you can only select
-CfSSE64,SSE3,SSSE3,SSE41,SSE42,AVX
I improved the parsed. This is also an inconsistency if FPC. All
categories in "fpc -i" output from FPC 2.6.2 are separated by newline.
FPC 2.7.1 changed FPU instruction sets to a comma separated list.

Dimitry (skalogryz) wanted to have external config files for options
for every FPC version, and even for other compilers. We had a
discussion in dev mailing list. I don't know if he will make code for
it.
It would be easier to parse but it needs more maintenance. Ideal would
be to have machine readable output from FPC directly, instead of the
inconsistent help output.

Regards,
Juha

--
waldo kitty
2013-08-04 17:48:56 UTC
Permalink
Post by Juha Manninen
Post by Ludo Brands
- FreeBSD is missing from the targets
A bug in FPC. The options are parsed directly from "fpc -h".
ahhhh... would that explain the one or two FPC windows i saw open and close on
my (older) w2k system when i went to look at the new screen?
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Mattias Gaertner
2013-08-04 18:22:43 UTC
Permalink
On Sun, 04 Aug 2013 13:48:56 -0400
Post by waldo kitty
Post by Juha Manninen
Post by Ludo Brands
- FreeBSD is missing from the targets
A bug in FPC. The options are parsed directly from "fpc -h".
ahhhh... would that explain the one or two FPC windows i saw open and close on
my (older) w2k system when i went to look at the new screen?
Fixed.

Mattias

--
waldo kitty
2013-08-05 03:35:38 UTC
Permalink
Post by Mattias Gaertner
On Sun, 04 Aug 2013 13:48:56 -0400
Post by waldo kitty
Post by Juha Manninen
Post by Ludo Brands
- FreeBSD is missing from the targets
A bug in FPC. The options are parsed directly from "fpc -h".
ahhhh... would that explain the one or two FPC windows i saw open and close on
my (older) w2k system when i went to look at the new screen?
Fixed.
:LOL: i didn't know anything was broken but i did wonder why it was taking so
long and why the HD light was flashing so much since i had just rebooted the
machine and waited on everything to settle down before starting Lazarus... i had
maybe a 5 or longer second wait before that screen drew... i pulled a new
revision from the repository earlier but i will pull another one and see how
that goes ;)

w2k-SP4 with all available updates
AMD Athlon XP 2800+
768M RAM
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
waldo kitty
2013-08-07 19:10:03 UTC
Permalink
Post by Mattias Gaertner
On Sun, 04 Aug 2013 13:48:56 -0400
Post by waldo kitty
Post by Juha Manninen
A bug in FPC. The options are parsed directly from "fpc -h".
ahhhh... would that explain the one or two FPC windows i saw open and close on
my (older) w2k system when i went to look at the new screen?
Fixed.
can we get a "please stand by while loading options list" window that pops up to
let us know that something is, indeed, happening?
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Juha Manninen
2013-08-07 19:48:59 UTC
Permalink
Post by waldo kitty
can we get a "please stand by while loading options list" window that pops
up to let us know that something is, indeed, happening?
How long it takes to load the options with your computer?
What kind of CPU (type and speed) does it have?
Hard-drive speed matters, too, because fpc executable is read from it.
Windows may also be slower in starting processes than Linux which I mostly use.

I have tested with a mini-laptop with Intel Atom CPU and loading the
options was really fast. The delay was barely noticeable and the
cursor indicated something was happening.
Maybe I should get some really old machine to test with.

This problem can be solved also by loading the options in a background thread.

Juha

--
waldo kitty
2013-08-07 20:18:45 UTC
Permalink
Post by Juha Manninen
Post by waldo kitty
can we get a "please stand by while loading options list" window that pops
up to let us know that something is, indeed, happening?
How long it takes to load the options with your computer?
What kind of CPU (type and speed) does it have?
Hard-drive speed matters, too, because fpc executable is read from it.
Windows may also be slower in starting processes than Linux which I mostly use.
as noted upstream in this thread...

w2k-SP4 with all available updates
AMD Athlon XP 2800+
768M RAM

and the HD is a WDC WD300BB (at this time)...
Post by Juha Manninen
I have tested with a mini-laptop with Intel Atom CPU and loading the
options was really fast. The delay was barely noticeable and the
cursor indicated something was happening.
the first time, when i noted seeing the two windows pop up as the data was
retrieved, it was around 5+ seconds... the second time, after mattias' fix to
hide the windows, it was just a little longer but that may be due to other
activities going on at the same time...
Post by Juha Manninen
Maybe I should get some really old machine to test with.
i resemble that remark! ;) O:)
Post by Juha Manninen
This problem can be solved also by loading the options in a background thread.
yes, that would work and shouldn't be noticeable... unless one goes directly to
those options which is rather doubtful...
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Juha Manninen
2013-08-07 20:45:00 UTC
Permalink
Post by waldo kitty
as noted upstream in this thread...
w2k-SP4 with all available updates
AMD Athlon XP 2800+
768M RAM
and the HD is a WDC WD300BB (at this time)...
Yes sorry.
Strange, AMD Athlon XP 2800+ should not be so terribly slow.
Something slows things down in your machine.
Post by waldo kitty
the first time, when i noted seeing the two windows pop up as the data was
retrieved, it was around 5+ seconds...
If you actually see the windows, it means calling "fpc -i" and "fpc
-h" takes a long time.
After that the GUI control creation takes more time.
Post by waldo kitty
Post by Juha Manninen
This problem can be solved also by loading the options in a background thread.
yes, that would work and shouldn't be noticeable... unless one goes directly
to those options which is rather doubtful...
It helps only loading the options, not generating the GUI. It would be
interesting to know which operation is slower in your computer.

Out of curiosity, how long does starting Lazarus take there?

Juha

--
waldo kitty
2013-08-09 00:25:16 UTC
Permalink
Post by Juha Manninen
Post by waldo kitty
as noted upstream in this thread...
w2k-SP4 with all available updates
AMD Athlon XP 2800+
768M RAM
and the HD is a WDC WD300BB (at this time)...
Yes sorry.
Strange, AMD Athlon XP 2800+ should not be so terribly slow.
Something slows things down in your machine.
after some investigation and time spent archiving, it seems that thunderbird
with some 40000+ messages in this lazarus folder plus having firefox open were
causing my system to consume too much memory and thus using swap... especially
when i would open lazarus to do some coding or checking things out from posts in
here... after archiving, it seems to have cut down on the amount of memory used
so we'll see what happens now...
Post by Juha Manninen
Post by waldo kitty
the first time, when i noted seeing the two windows pop up as the data was
retrieved, it was around 5+ seconds...
If you actually see the windows, it means calling "fpc -i" and "fpc
-h" takes a long time.
After that the GUI control creation takes more time.
yes... i will check again later... but in the mean time, on heavily loaded
systems, having a pop up "please wait" box would be a good idea...
Post by Juha Manninen
Post by waldo kitty
Post by Juha Manninen
This problem can be solved also by loading the options in a background thread.
yes, that would work and shouldn't be noticeable... unless one goes directly
to those options which is rather doubtful...
It helps only loading the options, not generating the GUI. It would be
interesting to know which operation is slower in your computer.
before the archiving and with my habits, loading from disk with loaded and
overused memory, loading from disk would likely take the longest... just
guessing, though... part of that loading time is also due to AVAST!'s file
system shield which scans files during access...
Post by Juha Manninen
Out of curiosity, how long does starting Lazarus take there?
i'm not sure as i did the above archiving before testing... with FF, TB, AVAST
(with all protections) running, it would take some 5+ seconds at least... closer
to 10 seconds... but that's from memory and not actually measured...

i did, however, find and implement a stopwatch type timer in my script for
compiling laz... when i ran a test after a clean boot (no TB or FF loaded) it
took about 20 minutes for the compilation run of the following steps...

1. make clean
2. TortoiseProc /command:update /path:"%myLAZpath%"
3. make OPT="-gl -gh -dHEAPTRC_WINDOW" lazbuild lcl basecomponents starter
bigidecomponents lhelp
4. lazbuild.exe --build-ide="-gl -gh -dHEAPTRC_WINDOW" --build-mode="debug ide"

which is my standard compile run for building lazarus from SVN... i'm using
trunk for both lazarus and FPC but FPC hasn't been pulled from SVN in a week or
two...
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Frederic Da Vitoria
2013-08-09 08:17:21 UTC
Permalink
Post by waldo kitty
Post by Juha Manninen
Post by waldo kitty
as noted upstream in this thread...
w2k-SP4 with all available updates
AMD Athlon XP 2800+
768M RAM
and the HD is a WDC WD300BB (at this time)...
Yes sorry.
Strange, AMD Athlon XP 2800+ should not be so terribly slow.
Something slows things down in your machine.
after some investigation and time spent archiving, it seems that
thunderbird with some 40000+ messages in this lazarus folder plus having
firefox open were causing my system to consume too much memory and thus
using swap... especially when i would open lazarus to do some coding or
checking things out from posts in here... after archiving, it seems to have
cut down on the amount of memory used so we'll see what happens now...
OT, I have found that TB archives are unreliable with large volumes. Not
that mails disappear (at least not that I know), but quick search tends to
not find all the mails it should.
--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
Lukasz Sokol
2013-08-09 09:03:38 UTC
Permalink
[...]
Post by waldo kitty
after some investigation and time spent archiving, it seems that
thunderbird with some 40000+ messages in this lazarus folder plus
having firefox open were causing my system to consume too much memory
and thus using swap... especially when i would open lazarus to do
some coding or checking things out from posts in here... after
archiving, it seems to have cut down on the amount of memory used so
we'll see what happens now...
OT, I have found that TB archives are unreliable with large volumes.
Not that mails disappear (at least not that I know), but quick search
tends to not find all the mails it should.
-- Frederic Da Vitoria (davitof)
Compact Folders option seems to also help a lot.

-L



--
Sven Barth
2013-08-09 09:54:50 UTC
Permalink
Post by Lukasz Sokol
[...]
Post by waldo kitty
after some investigation and time spent archiving, it seems that
thunderbird with some 40000+ messages in this lazarus folder plus
having firefox open were causing my system to consume too much memory
and thus using swap... especially when i would open lazarus to do
some coding or checking things out from posts in here... after
archiving, it seems to have cut down on the amount of memory used so
we'll see what happens now...
OT, I have found that TB archives are unreliable with large volumes.
Not that mails disappear (at least not that I know), but quick search
tends to not find all the mails it should.
-- Frederic Da Vitoria (davitof)
Compact Folders option seems to also help a lot.
Something to avoid is having lots of messages in the same folder with
the same subject line. We use INN here to archive stuff we send to our
customers, and we were able to improve local client (Netscape/Mozilla
and derivatives) performance a lot by appending a unique ID to each
[Lazarus]...) is mostly harmless.
In our company and I privately switched from Thunderbirds default mail
format MBox to MailDir which improved the situation a bit :)

Regards,
Sven

--
Mark Morgan Lloyd
2013-08-09 09:44:27 UTC
Permalink
Post by Lukasz Sokol
[...]
Post by waldo kitty
after some investigation and time spent archiving, it seems that
thunderbird with some 40000+ messages in this lazarus folder plus
having firefox open were causing my system to consume too much memory
and thus using swap... especially when i would open lazarus to do
some coding or checking things out from posts in here... after
archiving, it seems to have cut down on the amount of memory used so
we'll see what happens now...
OT, I have found that TB archives are unreliable with large volumes.
Not that mails disappear (at least not that I know), but quick search
tends to not find all the mails it should.
-- Frederic Da Vitoria (davitof)
Compact Folders option seems to also help a lot.
Something to avoid is having lots of messages in the same folder with
the same subject line. We use INN here to archive stuff we send to our
customers, and we were able to improve local client (Netscape/Mozilla
and derivatives) performance a lot by appending a unique ID to each
subject line. Having subject lines that only start the same (e.g. Re:
[Lazarus]...) is mostly harmless.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mark Morgan Lloyd
2013-08-07 20:52:43 UTC
Permalink
Post by waldo kitty
Post by Juha Manninen
Maybe I should get some really old machine to test with.
i resemble that remark! ;) O:)
Post by Juha Manninen
This problem can be solved also by loading the options in a background thread.
yes, that would work and shouldn't be noticeable... unless one goes
directly to those options which is rather doubtful...
Could it be done once, at the time that the configuration file reader
checks the compiler binary e.g. after a version change?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Mattias Gaertner
2013-08-07 20:00:30 UTC
Permalink
On Wed, 07 Aug 2013 15:10:03 -0400
Post by waldo kitty
[...]
can we get a "please stand by while loading options list" window that pops up to
let us know that something is, indeed, happening?
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
Something eats a lot of time. Probably the creation of hundreds of
controls.

Mattias


--
waldo kitty
2013-08-07 20:22:43 UTC
Permalink
Post by Mattias Gaertner
On Wed, 07 Aug 2013 15:10:03 -0400
Post by waldo kitty
[...]
can we get a "please stand by while loading options list" window that pops up to
let us know that something is, indeed, happening?
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
rough eyeball timing on this machine shows the first invocation of each to take
roughly 1 to 2 seconds before the text streams by...
Post by Mattias Gaertner
Something eats a lot of time. Probably the creation of hundreds of
controls.
that is one thing... another is active anti-virus and anti-malware protections
that scan executables as they are loaded to try to ensure that they have not
changed since the last (approved) execution... in this case AVAST! is the active
protection...
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Juha Manninen
2013-08-07 20:23:45 UTC
Permalink
On Wed, Aug 7, 2013 at 11:00 PM, Mattias Gaertner
Post by Mattias Gaertner
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
Something eats a lot of time. Probably the creation of hundreds of
controls.
Actually yes, creating the controls still takes longer than "fpc -i" + "fpc -h".
Its was very slow until I added the DisableAutoSizing /
EnableAutoSizing, but now it is fast in my machine.
I think it is directly proportional to CPU speed.
I must work on the grid GUI soon.

Juha

--
waldo kitty
2013-08-07 21:01:39 UTC
Permalink
Post by Juha Manninen
On Wed, Aug 7, 2013 at 11:00 PM, Mattias Gaertner
Post by Mattias Gaertner
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
Something eats a lot of time. Probably the creation of hundreds of
controls.
Actually yes, creating the controls still takes longer than "fpc -i" + "fpc -h".
Its was very slow until I added the DisableAutoSizing /
EnableAutoSizing, but now it is fast in my machine.
I think it is directly proportional to CPU speed.
as an aside, i've been working with another non-FPC/Lazarus project in the last
weeks... updating from an old no longer supported one to a forked and updated
one... in this case, it is a php based genealogy app... the import of data from
the old version to the new version took 15 hours to run on the dual PIII 800mhz
512M RAM server... part of the bottle neck there was the mysql config and coming
from the myisam format into the innodb format... the mysql config on that
machine was the defaults and so not optimized for any real work for innodb so it
was very slow... one of the comments i made when others were saying that it
should have gone a lot faster was that if one truly wants to ensure that their
applications are optimized and speedy is to run them on older slower machines...
if they can make them run fast on those boxes, they will be faster than greased
lightening on the newer stuff ;)
Post by Juha Manninen
I must work on the grid GUI soon.
it will be welcomed with open arms no matter what you come up with... as long as
it works and is fast enough :)

if i can find a way to time the process, i would like to add timing stats to my
scripted updatelaz routine... i prefer to use what is available in the system
but i'm not aware of anything for this... if i were able to get 4NT running the
way i want it to, i would have this capability... this comment being about
timing the entire "make clean, tortoise svn update, make all" run on this box...
just for grins, ya know? ;)
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.

--
Mark Morgan Lloyd
2013-08-07 20:49:03 UTC
Permalink
Post by Mattias Gaertner
On Wed, 07 Aug 2013 15:10:03 -0400
Post by waldo kitty
[...]
can we get a "please stand by while loading options list" window that pops up to
let us know that something is, indeed, happening?
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
Something eats a lot of time. Probably the creation of hundreds of
controls.
This is a 450MHz SPARC on my desktop, which is probably about as slow as
anybody will come across (note: unless running as a Qemu guest):

$ time fpc -i >/dev/null

real 0m0.028s

$ time fpc -h >/dev/null

real 0m0.137s

$ time ppcsparc -i >/dev/null

real 0m0.020s

$ time ppcsparc -h >/dev/null

real 0m0.112s
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
Sven Barth
2013-08-08 08:57:55 UTC
Permalink
Post by Mark Morgan Lloyd
Post by Mattias Gaertner
On Wed, 07 Aug 2013 15:10:03 -0400
Post by waldo kitty
[...]
can we get a "please stand by while loading options list" window
that pops up to let us know that something is, indeed, happening?
Running "fpc -i" and "fpc -h" takes on recent machines less than 30ms.
Something eats a lot of time. Probably the creation of hundreds of
controls.
This is a 450MHz SPARC on my desktop, which is probably about as slow
Once I've managed to get FPC with m68k running well again *cough* this
can be tested on a 200 MHz Coldfire ^^

Regards,
Sven

--
Ludo Brands
2013-08-05 07:11:51 UTC
Permalink
Post by Juha Manninen
Post by Ludo Brands
- for one reason or another, vertical scrolling with the scroll bar is
very jumpy. As if the cpu is running at 100%. This is not the case
though, "only" 2 cores of an i7 at 40%.
Not here. Your Kubuntu has some config issues. The ScrollBars have
smooth scrolling enabled and it works well here, using both GTK2 and
QT.
This slow scrollbar behavior is limited to TfrmAllCompilerOptions. All
other screens are fine. Made a small program with a TScrollbox, and it
doesn't have that behavior.

I see an OnIdle handler that seems to do quite a lot
(RenderAndFilterOptions). Wouldn't that intervene with the smooth
tracking of the scrollbar?

Ludo

--
Juha Manninen
2013-08-04 15:55:07 UTC
Permalink
Post by Ludo Brands
Just installed it. Here is how it looks on Kubuntu 12.04 default
https://dl.dropboxusercontent.com/u/61365485/compiler%20options.png :(
I improved the layout. I am still thinking what to do with some
options there. Probably I will delete heap and stack sizes as they can
be edited in all options GUI.
Post by Ludo Brands
The debugging panels are better organized but the bottom one is clearly
too short: https://dl.dropboxusercontent.com/u/61365485/debugging.png
Yes, AutoSize was missing. I had tested it with both GTK and QT
bindings on Mint 14 + KDE and it looked OK. I don't know what makes so
big difference.

Juha

--
Graeme Geldenhuys
2013-08-04 22:42:36 UTC
Permalink
Post by Ludo Brands
Just installed it. Here is how it looks on Kubuntu 12.04 default
https://dl.dropboxusercontent.com/u/61365485/compiler%20options.png :(
From a UI design point of view, that looks pretty terrible. Group boxes
are not aligned, no flow in reading it, headers are difficult to spot,
spacing and margins are uneven etc.

Regards,
Graeme


--
Mattias Gaertner
2013-08-04 12:28:22 UTC
Permalink
On Sun, 4 Aug 2013 14:34:05 +0300
Post by Juha Manninen
On Sun, Aug 4, 2013 at 11:38 AM, Reinier Olislagers
Post by Reinier Olislagers
I was looking at setting debug options etc and am happy to see the
checks section included in the debug screen, and a very nice way to deal
with build modes.
How about the new GUI for all available compiler options? Comments anybody?
When I type in the search edit the focus switches. I have to type one
character, then click with the mouse in the edit, type the next
character and so forth.

Mattias

--
Juha Manninen
2013-08-04 12:32:39 UTC
Permalink
On Sun, Aug 4, 2013 at 3:28 PM, Mattias Gaertner
Post by Mattias Gaertner
Post by Juha Manninen
How about the new GUI for all available compiler options? Comments anybody?
When I type in the search edit the focus switches. I have to type one
character, then click with the mouse in the edit, type the next
character and so forth.
Yes, this is the mysterious behavior I wrote about in devel mailing list.
I try to figure out the reason soon.

Juha

--
Continue reading on narkive:
Loading...