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

Reinier Olislagers wrote

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

04.08.13, 19:34, 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

Just installed it. Here is how it looks on Kubuntu 12.04 default settings:
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

Ludo

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

Yes, this is the mysterious behavior I wrote about in devel mailing list. I try to figure out the reason soon.

Juha

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

The -o option should not be listed there. It interferes with the IDE. Same for -v* and -T.
The -i options are useless here.

-l options or any other option taking a path or filename.

Funny, that you mention the -l option as example for that.

Mattias

Paul Ishenin wrote

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 wrote

Just installed it. Here is how it looks on Kubuntu 12.04 default settings: 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.

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

Ludo Brands wrote

Comments: - there is a horizontal scroll bar but several strings are simply cut off

Resizing the options window should help. (?)

- 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.

- 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.

- 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.

- 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.

- 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.

- -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

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

Juha Manninen wrote

On Sun, Aug 4, 2013 at 4:30 PM, Ludo Brands wrote: > - 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?

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)?

Fixed.

Mattias

It addresses all targets. That's the idea of parsing the fpc output instead of maintaining our own list.

Mattias

OK, I'll try to test on at least SPARC and PPC. What version of FPC does trunk require these days?

Thanks.

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

Ludo Brands wrote

Just installed it. Here is how it looks on Kubuntu 12.04 default settings: 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

: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

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

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

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.

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 wrote

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

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.

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.

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

Juha Manninen wrote

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

Sven Barth wrote

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

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?

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

Mark Morgan Lloyd wrote

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

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.

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

Mattias

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

Mattias Gaertner wrote

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

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 wrote

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

Mark Morgan Lloyd wrote

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 :-)

Juha Manninen wrote

-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 wrote

Am 07.08.2013 13:01, schrieb 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

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

...

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

can we get a "please stand by while loading options list" window that pops up to let us know that something is, indeed, happening?

waldo kitty wrote

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

[...] 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

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)...

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...

Maybe I should get some really old machine to test with.

i resemble that remark! ;) O:)

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...

rough eyeball timing on this machine shows the first invocation of each to take roughly 1 to 2 seconds before the text streams by...

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...

Mattias Gaertner wrote

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

Yes sorry.
Strange, AMD Athlon XP 2800+ should not be so terribly slow. Something slows things down in your machine.

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.

> 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

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

Could it be done once, at the time that the configuration file reader checks the compiler binary e.g. after a version change?

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 ;)

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? ;)

Once I've managed to get FPC with m68k running well again *cough* this can be tested on a 200 MHz Coldfire ^^

Regards,
Sven

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?

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...

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...

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...

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...

2013/8/9 waldo kitty

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 wrote

2013/8/9 waldo kitty <

[...]

Compact Folders option seems to also help a lot.

-L

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.

In our company and I privately switched from Thunderbirds default mail format MBox to MailDir which improved the situation a bit :)

Regards,
Sven