Really Disgusted

[Ñuño Martínez]

The other problem is native to the compiler, and foolish. Lazarus uses BGR notation in hexadecimal colors and doesn't tell you this anywhere. The only way you learn this is by trial and error. So my colors were flawed because they were in RGB notation, like you would expect to have used. RGB is the "standard" in other pascal compilers, so why not Lazarus? This deviation prevents any cross compiler reuse of syntax highlighter configuration for SynAnySyn.

May be it was written for a Motorola/PPC CPU so it does a bad conversion :?

If you want to download a working copy of SynAnySyn you may do so here.

Did you send a bug repport and the patch to the development team?

[Robert Kosek]

Yuriy, can you give me a working example of a binary search? I can't honestly compare it to one without knowing what it should look like. This is my best guess based off the Wikipedia definition of a binary search algorithm:

  First := 0;
  Last  := fKeywords.Count - 1;
  Token := UpperCase(AKeyword);
  while First <= Last do begin
    Mid &#58;= &#40;First + Last&#41; shr 1;
    Compare &#58;= CompareText&#40;fKeywords&#91;Mid&#93;, Token&#41;;
    if Compare <0> 0 then
      Last &#58;= Mid - 1
    else begin
      // Our result is true, force an exit.
      Result &#58;= True;
      exit;
    end;
  end;
  Result &#58;= False;

However the result is the same as the old, and certain keywords are omitted. If you binary search (case-insensitive) the keyword list that follows for END_RANDOM you will not find it, and if you reorder the list that position is always missed. So, I dunno what I'm doing wrong.

CREATE_CONNECT_ALL_LANDS
CREATE_CONNECT_ALL_PLAYERS_LAND
CREATE_CONNECT_TEAMS_LANDS
CREATE_ELEVATION
CREATE_LAND
CREATE_OBJECT
CREATE_PLAYER_LANDS
CREATE_TERRAIN
DEFINE
ELSE
ELSEIF
END_RANDOM
ENDIF
GIGANTIC_MAP
HUGE_MAP
IF
LARGE_MAP
MEDIUM_MAP
PERCENT_CHANCE
REPLACE_TERRAIN
SMALL_MAP
START_RANDOM
TERRAIN_COST
TERRAIN_SIZE
TINY_MAP

?ëu?±o, yes I have reported it this morning. I waited until I had greater patience with the developers, as I did not want to abuse them over this. The urge to do so was great. Issue 0010913.

EDIT: TStringList, when sorted, uses a binary search. I have now delegated the searching to this function. I would suggest any who downloaded the prior fix to redownload it and rebuild Lazarus again; now it uses the binary search instead of a linear search.

[masonwheeler]

Yeah, my experiences with Lazarus have been similar. I want to like it, really do! But they've been promising the new and improved linker just around the corner for... how long, now? And so many parts of the LCL just don't do what they should.

With all the nasty glitches, slowdowns, and memory leaks that Delphi subjects me to, I still use it and prefer it, because IT WORKS. The compiler produces good code, and the debugger traces lines and displays data properly, and that's more than I can say about Lazarus. The rest is just details.

[JernejL]

Lazarus uses BGR notation in hexadecimal colors and doesn't tell you this anywhere. The only way you learn this is by trial and error. So my colors were flawed because they were in RGB notation, like you would expect to have used. RGB is the "standard" in other pascal compilers, so why not Lazarus?

I bet it has soemthing to do with unix..

Aniway, Lazarus is a waste of a completely good compiler (FPC), too bad that there is no good standalone IDE for just the FPC, the odd default compiler settings of lazarus, and their stubborn effort to support all the various platforms and widgetsets without a single hack has produced a unstable unpolished ide, which has many bugs in the ide, which could be solved simply with a platform-dependant trick.

The lazarus code has also turned into a similar domino-lining effect which plagued delphi vcl and rtl, they just keep adding and using new unneccesary functions in the code, and at the end the linker barely has anything to strip away, you end up with a lot of rtl code that your app will never ever need, and most of this has to do with initializing code of each unit, they are the worst way to build a proper runtime library.

Not to mention the way they handle resources.. they are simply all converted into code files and linked into the app as large DATA CONSTANTS.. for crying out loud, how hard it is to use native os resources support (like win32) or maybe just use external files which are perhaps even manageable in a normal way by the programmer?

And don't get me even started on using GDB in lazarus.. i'd rather have NO debugger than that pile of poo.

Yes i sure am badmouthing lazarus a lot, perhaps i could help them solve these problems? but i don't have the time, i could probably put up a help lazarus bounty? maybe the lazarus team can try qualifying for help on the google summer of code event?

[Robert Kosek]

Aniway, Lazarus is a waste of a completely good compiler (FPC), too bad that there is no good standalone IDE for just the FPC, the odd default compiler settings of lazarus, and their stubborn effort to support all the various platforms and widgetsets without a single hack has produced a unstable unpolished ide, which has many bugs in the ide, which could be solved simply with a platform-dependant trick.

I thought of working on a pseudo-IDE for FPC. A pseudo-IDE because I'm not one to make an IDE. However, I am desirous of a nicer interface and code completion for vanilla FPC.

The main hook is how to catch console output of a launched DOS program and then redirect it into a Memo component. Maybe I'll figure that trick out some day.

Thing is, I couldn't afford to do it for free these days. And most folks don't want to pay for something that's little more than a graphical frontend to an existing compiler. :? Maybe if there were enough people willing to buy a $40 "frontend" I'd consider attempting it.

[cronodragon]

There is a guy in the FPC mailing list that have just started creating one, maybe you could join him, or "learn" from his work:

https://sourceforge.net/projects/skybuckode/

[Robert Kosek]

Thus far his work looks both basic and slightly bad. I've made plenty of editors, myself. Back when I worked with the A5 game engine I made an editor with syntax highlighting and built in script/level execution.

I've got the knowledge, but not the wherewithal to do it for free.

[masonwheeler]

Redirection of standard output is a very simple trick that's been around pretty much forever. The exact mechanism for it varies from platform to platform, but once you know how to do it, it's pretty easy.

Simple solution:
Redirect STDOUT to a file. Run compiler. When compiler is finished, read the text file to the memo component. You get all your output all at once.

More complicated solution:
Redirect STDOUT to a file. Run compiler. Continually check the file to see if it contains text. If it does, place this text into the memo component and clear the file.

There's probably even a way to redirect STDOUT to some sort of memory stream instead of to a file. Not certain, though.

[Robert Kosek]

I remembered the premise of the redirection, but not the implementation. So it'll take a bit of fiddling to get right. However, it'd be a little ways down the list. Proper highlighting, compilation, and project settings would come first. Then I could worry about the fancier appearance things and the nice redirections like that.

[JernejL]

Now.. at the end, you need to make a choice.. how to make such a ide? using fpc itself, lazarus, or.. delphi??

i would probably choose delphi, but how would such a project once compile itself? impossible.