and everything should work fine again though at least I lost some mails when it came back because it ate some mails while the mail system wasn't properly configured ...

Problem with real parameters in overloaded procs:

When defining an operator P with a CURRENCY parameter, and overloading that operator with a DOUBLE parameter, the compiler cannot decide which one to take when it is called with an EXTENDED actual parameter. The same seems to be true for overloaded procs/funcs.

I suggest the following change:
the sort order for searching the appropriate routine should be done as follows:

1. exact match (as it is done now);
2. extending the precision upward;

3. shrinking the precision downward.

This search for a "similar" real parameter should only be done for SINGLE/DOUBLE/EXTENDED; COMP and CURRENCY are too special. (I know that formally COMP and CURRENCY are reals; but I consider them too special for automatic conversions).

The neccessary code can be found in the appendices.

I'm sorry, I have my problems with SVN, I tried to download with "svn -co", but in the middle somewhere (in the directory tests) it stopped (it didn't really stop, the internet connection was busy, but no more files were transmitted). After that "svn -cleanup" didn't even work, the only thing that did work was to throw away the subdirectory and retry. But the retry came to the same result, and after the 3rd time I gave up.

So the code comes in pieces in the appendix.

"" is the is_real function in defutils.pas

"" is the new function in htypechk.pas

"" is the changed function in htypechk.pas; the old function shows the parameters in the debug info in reverse order

Would be nice if this could be incorporated in the compiler.

Gerhard

When did you test this? Recently we'd trouble with a hard disk in the server hosting svn. svn is completly back now.

about two weeks ago

This repairs two bugs concerning macros:

1.
There is a check that the macro name is not a reserved keyword. If the macro name starts not with a letter (with other words: starts with an underline), the compiler fails (when it is compiled with $R+).

2.
The check should be done when it is clear that the macro is of the form

    {$DEFINE x := something}

When the define has the standard form

    {$DEFINE x}

no check should be done, as before, and as now if you have {$MACRO off]

The attached code pieces, when inserted into scanner.pas, will repair the situation.

My changes in the code are marked with #gs#0#, at three locations.

Gerhard

Next time please supply diffs (svn diff > mypatch.diff) of the changes that you make. And also don't change the sourcecode style. If makes huge diffs and applying of patches will take a lot of manual work and time.

The attached code pieces, when inserted into scanner.pas, will repair the situation. My changes in the code are marked with #gs#0#, at three locations.

Patches applied

See his other mail, he had trouble with svn :)

-----Ursprüngliche Nachricht-----
Von: "Peter Vreman"
An: "FPC developers' list"
Gesendet: Mittwoch, 29. Juni 2005 17:05
Betreff: Re: [fpc-devel] {$DEFINE x := something}

...

Next time please supply diffs (svn diff > mypatch.diff) of the changes that you make.

It seems SVN runs now here. So, next time.

And also don't change the sourcecode style. If makes huge diffs and applying of patches will take a lot of manual work and time.

Sorry; I have a program for that upcasing/lowcasing. Next time I will reverse the changes before supplying.

Thanks, patch applied.

There is a reason why the whole compiler sources are lower case: the sources are rather complex with a lot of nested ifs etc. so we use a very high screen resolution to edit the source. I use usually 70 lines on a 17" TFT or 19" CRT and such high resolutions are much easier to read if everything is lower case because it makes the distance between lines bigger.

...

There is a reason why the whole compiler sources are lower case: the

sources are

rather complex with a lot of nested ifs etc. so we use a very high screen resolution to edit the source. I use usually 70 lines on a 17" TFT or 19"

CRT

and such high resolutions are much easier to read if everything is lower

case

because it makes the distance between lines bigger.

[I use usually 70 lines on a 17" TFT or 19" CRT...]: autsch, I wouldn't be able to read anything. With that resolution the screen is a collection of some coloured or grey points. Where did you get your eagle eyes?

In future I will lowcase my patches.

Hi Florian,

Florian wrote

There is a reason why the whole compiler sources are lower case: the sources are rather complex with a lot of nested ifs etc. so we use a very high screen resolution to edit the source. I use usually 70 lines on a 17" TFT or 19" CRT ...

A 17" TFT has usually a resolution of 1280x1024. To get 70 lines, you need a 7pt font, not really readable. On the other side, than the source have only 25% of the screen wide. You should use a rotatable screen, then you can use a readable font and use more than 25% of the screen.

... and such high resolutions are much easier to read if everything is lower case because it makes the distance between lines bigger.

Maybe using lower case only make the text easier to read, but not the contents.

wkr Peter.

1280/16 = 80.

16 is normal vga font iirc.

Clearly, the only right choise is FixedSys :-)

I've always wanted to find the most compact and readable font myself. Just never spent the time looking.

Well today I did a bit of searching, and found some fonts that are more compact than at least Courier New

http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Compact-Readable-Fonts

Save about twice as much screen space if you just choose the right compact font. Courier new seems to waste a lot of space between lines.

| > > There is a reason why the whole compiler sources are lower case: the | > > sources are rather complex with a lot of nested ifs etc. so we use a | > > very high screen resolution to edit the source. I use usually 70 | > > lines on a 17" TFT or 19" CRT ...
| >
| > A 17" TFT has usually a resolution of 1280x1024. To get 70 lines, you | > need a 7pt font, not really readable. On the other side, than the | > source have only 25% of the screen wide. You should use a rotatable | > screen, then you can use a readable font and use more than 25% of the | > screen.
|
| 1280/16 = 80.
|
| 16 is normal vga font iirc.
|
| _______________________________________________
| fpc-devel maillist -
| http://lists.freepascal.org/mailman/listinfo/fpc-devel

Yes and a console IDE :) It does 120x70 easily :)

Hehe, sounds sweet ;-)

Please move this thread to fpc-other. This has nothing todo with pascal. Everybody needs to decide for himself what he prefers to use: commandline, TUI or GUI.

Have you guys heard of something called the GUI? I just heard about it yesterday :-(

Common guys, the command line is useful but let's give Lazarus a run for it's money here. Err... a run for it's code.

I find the GUI based tools more powerful over the command line in many cases. Especially if the command line is there in the background for you at your fingertips.

For example midnight commander can't do anything, compared to what Total Commander can do. Midnight commander has absolutely no chance compared to Total commander. I also find for example Apititude for Debian just sucks rocks.. the command line fixed font just limits you so much. Scrolling through aptitude to try and find my installed packages on Linux is a pain in the neck. Kpackage is better visual wise, but it's written in bloaty python code so it also sucks rocks. (more freepascal based GUI management tools are needed on Linux)

But command tools are useful as a back up, especially when X-windows crashes. I use midnight commander to FTP files up to websites in emergency. But still, GUI things like total commander kick its arse in the end. I think Linux needs more compiled GUI programs, and less bloaty ones like Mozilla and Open Office.

Sometimes I want to use the command line on Linux just because their GUI programs are slow and basically suck. I'm sorry, but windows with it's tacky Windows 2000 look still beats GTK for screen space. I think that's why some guys still use the command line too much on Linux... because many of the GUI programs on Linux suck, and are slow. This will change though, as people figure it out.

Florian, what system do you run your IDE in? Linux in an Xterm window? or a Dos windoh in Windohs?

I do use the console fp-ide on my slower Linux computers and servers who don't have X-windows installed. If I want to compile something directly on the server I just fire up the IDE in a TTY. Which is convenient.. but on the desktop, for the main bulk of work.. I ditch many of the command tools.

My view is that the command line is extremely useful, but not so much in the ways most Linux users see it as useful. I like it especially if you can build a GUI program that wraps right around the command line (i.e. lazarus and the compiler), so that if in emergency the GUI crashes, you still have the command line as your back up. I love the networking available in linux for Apt-Get installs and emergencies too. Dos sucks in this area.That and the fact that you can't even boot to Dos anymore with Windohs.

Well I get 79 lines in FP-IDE

http://z505.com/images/fonts/FPvsLaz.png

| Please move this thread to fpc-other. This has nothing todo with pascal.

Neither did Florian's or Christians font related posts, and neither do the smiley's we posted have anything to do with Pascal. :o)

I think the effeciency of your development environment and setup you are using to create pascal code does have everything to do with FPC-devel and even FPC-users.

| Everybody needs to decide for himself what he prefers to use: commandline, | TUI or GUI.

Everyone does not need to decide for himself in a lonesome, cold world. We can research the facts and information together, before making a decision about TUI or GUI. Which is why I went ahead and offered downloads and screenshots of the fonts that will make FPC development more effecient for many fpc and lazarus users.

As I have indicated, I am very happy to have 83-88 lines of Pascal code on my screen versus even 70 or 55. And if it makes Pascal coding more effecient, then it should be posted for other -developers- and users to see.

Regards,
Lars

p.s.
I almost went ahead and removed all my contributed units from the FPC website, with fear of some of the source code comments even being partially off topic and non-pascal related. However, I realize this is just the internet and I do sometimes have a stronger pulse than usual when reading my email.

L505 wrote

As I have indicated, I am very happy to have 83-88 lines of Pascal code on my screen versus even 70 or 55.

Doesn't matter. One function at a time is enough to see. ;-)

I have 72x30 (yes, that's width & height in chars). All function not fitting into that window need refactoring. :-> Are we done with the dicksize war now?

Vinzent.