Hi,

Is there already a wiki pages that lists features that Lazarus has, but Delphi doesn't? Or features that Lazarus had way before Delphi did?

I always get told that Lazarus is light years behind Delphi. I always disagree, but would like to point them to a web page to list those items.

eg:
* Lazarus has much better Packages than Delphi's dumb packages.
* Lazarus has much better alignment properties
* Lazarus had visual alignment queues in the form designer before Delphi did
* LCL's TStringGrid is *much* better that VCL's equivalent.
* Free Pascal generics before Delphi did.
* smarter use of include files.
* Free Pascal compiler modes feature.
etc...

I think you get the idea.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090220/59a932f3/attachment.pl

Hi Graeme,

This is not to start a flame war, but would you care to explain:

* Lazarus has much better Packages than Delphi's dumb packages.

I'd like to port a Delphi app wich uses package based plugins and as far as I know there is no way I can do that with FPC/Lazarus?

Best regards,

Gerard.

Indeed, because using packages as a plugin system is abusing packages: packages have no well defined and stable abi being usable from any language thus they are not the right choose for a good plugin system.

Florian Klaempfl wrote

Indeed, because using packages as a plugin system is abusing packages: packages have no well defined and stable abi being usable from any language thus they are not the right choose for a good plugin system.

How weird, your are replying to a post I haven't even received yet. :-) As soon as it arrives in my inbox, i'll add my comments.

As for what you said. I fully agree.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I think you get the idea.

Not really.
Why are you constantly trying to convince Delphi people to switch to Lazarus, even in the Embarcadero Forums?
That's indecent imho.
It's important for the Pascal Language that CodeGear is selling products. Please stop it. It helps nothing.

Regards Theo

theo wrote

Why are you constantly trying to convince Delphi people to switch to Lazarus, even in the Embarcadero Forums?

I'm not telling them to dump Delphi. As I stated over and over - a bit of competition is great! In the newsgroup, I was simply stating that other developers could target a whole new market for there products. Windows is NOT the only market out there. Plus markets like Linux are not nearly as saturated as the Windows market. Linux doesn't have 100's of different CD Writing software, 1000's of different Accounting packages etc... Targeting multiple markets has worked wonders for our company and I would like to share the experience with other like-minded developers. When Borland started talking about Kylix, it planted the seed that there are other markets. Just because Borland ran Kylix into the ground, doesn't mean developers can't continue with the idea of supporting multiple OS's. Free Pascal and Lazarus gives you that choice. In the end, YOU choose the best tool for the job.

It's important for the Pascal Language that CodeGear is selling products.

Don't blame me for Borland and now CoadGear doing badly with Delphi. If they stopped kissing Microsoft's ass and concentrated on there own ideas, they would still have had a brilliant product. Trying to create a Visual Studio clone is not going to get them far - as they noticed!!

Just limiting themselves to one platform and
embracing new ideas and innovating the whole time, they ended up having a brilliant product called Qt.

If you don't like what I have to say - STOP READING MY REPLIES.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Gerard, I still didn't receive your original post, but I'll reply to what I saw in Florian's quote.

What I meant by "dumb Delphi packages" is as follows. Lazarus Packages (*.lpk) are quite different to Delphi's package. I'm not talking about creating a plugin system or *.dll or *.so files. I'm talking about how Packages work with the IDE.

In Lazarus, packages are a collection of code you can add as a requirement to another project. It has it's own settings, paths, documentation etc... You setup the packages once and anybody or project using that package gets all the settings, paths etc.. all setup for them automatically. The Lazarus IDE does all that for you In Delphi, you have to go fiddle with the Directory Paths in the IDE's Environment options. That's not needed with Lazarus.

So as you can see, I'm not talking about a plug-in 'm talking about a collection of units called a "lazarus package" and how the Lazarus IDE manages it for you.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Gerard N/A wrote

This is not to start a flame war, but would you care to explain:

Hey, finally your original email got through.... How weird?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

So far, Delphi's system fills my needs, as long as I can access them from my Delphi apps, I don't care if other languages can access them or not.
It may not be perfect, but it works.
I'd really love to port that app to FPC/Lazarus, but if I understand correctly, there is no such thing.

Regards,

Gerard.

Why are you constantly trying to convince Delphi people to switch to Lazarus, even in the Embarcadero Forums?

I'm with Graeme in this regard because I rant about this in their forum once in a while.

No, we never try to convince them to switch. What we do was convincing them that they do have an alternative. They could keep their Delphi for Windows platform. Somehow I had a pity on them when they're asking when 64bit support will arrive, or when Delphi will support other platforms beside Windows, or when Delphi will support a true RAD for web application, or when Delphi will support mobile device, etc.

We're trying to tell them that Pascal as a language is *lot bigger than* Delphi, FPC, Lazarus, Morfik, Oxygene, or whatever Pascal-based compiler/IDE out there. Pascal is all of them combined. Thinking that "Pascal = Delphi" is a big mistake, IMO. In fact, if they don't stick their mind to Delphi, they would got plenty alternatives for what they need in Pascal. So, instead of begging to Delphi producer to provide what they need, I tried to open their mind by suggesting another alternative (FPC/Laz in this case) and asked them to look around. The solution is available out there if they dare to look.

I once got a friend who is a very fluent Delphi programmer (though mostly database app). When he got a project to build a web based application, he left Delphi behind and switch to PHP because all he knew Delphi is only for desktop application. He wrote millions LOC of the business logic in PHP from the scratch while actually he already got them all in Delphi. He finished the project in a few months. After I told him that Delphi actually can be used to build web application (using Powtils in this case), he regretted what he had done. If he knew this before, he could finish his project within a few weeks.

I don't want more Delphi programmers experience similar cases: abandon millions LOC simply because they don't know the power of Pascal. :(

-Bee-

Indeed, because using packages as a plugin system is abusing packages: packages have no well defined and stable abi being usable from any language thus they are not the right choose for a good plugin system.

Maybe for the start we could ignore accessibility factor from other languages. To me, having package that can be used as plugin system (as in Delphi) for my own application is more than enough. I don't care about other languages, because I speak Pascal. If someone else would like to make a plugin for my application, then s/he have to write it in Pascal.

If someday in the future we have solution for other languages, it'd be a good news for them. :-D

-Bee-

Well, he would also need exactly the same version of the compiler, rtl, fcl and lcl you're using.

Sadly Delphi just became a M$ database front-end.

http://www.embarcadero-events.eu/

Hope my assumption is not true but if it is then
Lazarus - we are about to get an influx of huge number of disillusioned Delphi developers
who do not work on enterprise database projects
or those who do work databases but want to work with Firebird or those who need a cross platform development tool. The great global strength applications, OpenOffice, GIMP, Firefox, Audacity etc,etc = cross-platform = not Delphi.

Lazar- we need a step change in the speed of code testing and applying contributed patches to get this show on the road and save "the Delphi language" to the next decade.

roll on v 1.0

regards
Leslie

That's okay in so far, as FPC and Lazarus are designed as platform extenders for Delphi.

The VS clone was an attempt to make people move from VS (and VB, VC...) to Delphi and Pascal.

IMO Borland/Inprise/CodeGear better had provided a Visual Pascal plugin for VS. Borland has been the leading IDE provider for Windows long ago, but nowadays MS has the better IDE, supporting more languages.

Hint: Lazarus also is a Delphi IDE clone.

Consequently Lazarus should not try to replace Delphi, IMO. The primary goal of Lazarus should be a Delphi (OPL/VCL) compatible back-end, with a platform independent component library.

DoDi

Hans-Peter Diettrich wrote

IMO Borland/Inprise/CodeGear better had provided a Visual Pascal plugin for VS.

I think they would have had more success with that - or at least put the Object Pascal language in a better light.

Hint: Lazarus also is a Delphi IDE clone.

As far as I know (from prior conversations on this mailing list), it was never the intention or goal to "clone" the Delphi IDE. The only goal was to clone the VCL. I personally don't consider Lazarus IDE a clone of Delphi IDE. They might look similar from a distance, but when you start working with them, they are quite different. I prefer Lazarus IDE a lot more - mostly because I can modify it to suit my needs.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Well, the look-and-feel has to be Delphi-like, so that newcomers don't have a too steep learning curve.

I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows.

DoDi

I also do not like LazSynEdit. If I had the time I would like to replace it with an editor based on scintilla (www.scintilla.org).

I really like the current editor (*really like it*), and don't really find any slowness (except when the variables methods gets displayed, and even then... it's pretty responsive)

But it could be that there is some lingering bug on the specific widgetset? For me, on linux and windows it works great, and makes my life much easier than scintilla would.

Well, that is the whole point of packages, a higher level (pascal) plugin concept.

Personally I think though that the Delphi like design time packages will never work for Lazarus. Why? Simply because Delphi has a controlled, small amount of versions.

Where exactly do you experience those speed issues?

If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid.

If it turns out that the slowdown is in code tools, no matter which editor it will be slow (maybe
http://bugs.freepascal.org/view.php?id=13039 ?)
Is it slow, with none pascal files too?

However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster).
The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like "begin")
For me it is not noticeable on 10000 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the "n". The rest of the typing is not slowed down.

If you have any other examples of slowness, please let me know.

Best Regards
Martin

In editing Controls.pp and the related include files.

The effect is not related to any settings, after startup the editor works fast. It may depend on the number of applied changes or jumps across files or bookmarks, or on the number of symbols in the units, i.e. size of the according (history) lists.

However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster).

Okay. I'll also try to close the fpdoc window, it may be related as well.

The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like "begin")

The effect is independent of keywords, perhaps it may be related to identifiers and the popup-hints.

For me it is not noticeable on 10000 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the "n". The rest of the typing is not slowed down.

The effect is boring, even if I only navigate through the source code with the cursor keys :-(

DoDi

If it builds up over time, I am a bit clueless.

2 things I can thing off:
- Codetools (but that should not affect scrolling), but Codetools can collect more and more info, using more memory. (AFAIK)
- Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). So it may re allocate a lot of Memory. That could upset the memory management.

Both are *not* very likely candidates...

You can try to reduce the amount of undo steps. Or compile with/withou heaptrc (leak checker) => some people reported that other apps gained speed *with* heaptrc.
(But I don't really think it's memory mgmt)

The effect is boring, even if I only navigate through the source code with the cursor keys :-(

This bit sounds like a problem with painting the window. Which OS / Widgetset are you using?

You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ?

Best Regards
Martin

Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time.

You remember my suggestion, to use an line-cache in the SynEdit component? Such a cache allows to bypass the block folding and other possibly time consuming actions, while only navigating through an file without editing.

Which OS / Widgetset are you using?

Windows 32 bit.

My repaired machine just has arrived, I'll retry under Linux when I've reinstalled the system and Lazarus.

You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ?

I've not really used Lazarus 0.9.26 or older, now I'm just following the SVN trunk.

DoDi

yes and no:
- vertical moves do repaint the gutter always, in case that the "every nth line number" is used.
- Any caret move that goes across a word boundary triggers the "highlight-current-word" (but it only set the timer, and only if you wait it does a search in the source), unless you checked "disable timer" (but this feature has only been added in 2009, hence my question)
- If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you).

Otherwise: it is true that moving the caret should cost no time. And I can't see where it would relay on anything that could amount over time. I'll keep it in the back of my head, in case I see anything.

Maybe I find some time to but some time measuring in.

Still having plans for that. (I also need to start working on a better data-model, for multi view stuff / since you progress on the docking :) ) Yet the current implementation of folding is very quick, and the risk to run out of memory, rather than CPU-time exists too.

I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot => that leads to fragments in the fpc mem-mgmt => and that could cause a slow down..

Hm, Windows should be the most efficient. GTK has a lot of code to the "in grid drawing" of the chars. Windows does it natively.

Best Regards
Martin

- Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient).

that's some kind of an urban legend.
But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code.

Martin

Okay, but it would be sufficient to repaint only the old and new line's numbers.

I think that I should disable all that eye-candy.

I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot => that leads to fragments in the fpc mem-mgmt => and that could cause a slow down..

Maybe, yes.

DoDi

Hi Martin, you're still around? :-)

You're right, the LCL became utterly bloated, without a good (discussed and documented) concept. But fortunately it doesn't contain assembler code :-)

Efficiency is not normally required in a GUI, the current machines have enough power for themes, transparent windows, and more. But the behaviour of LazSynEdit actually feels a bit like the initial RAD-Studio editor, which also tended to slow down, until a freeze.

DoDi

Which is what it does, just 2 line numbers.

Let me know, if any of that makes a diff.

yea.

Check the mem consummation, and swapping (page faults) when it slows.

The think is, even if no memory is needed, if it indeed is fragmented, then a lot of the allocate mem may be unusable small, and more be allocated.

This also would mean that data that should be together may be located across several pages, forcing more swapping.

there are some settings in fpc, top affect the mem mgmt . not sure....

Best Regards
Martin

I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot => that leads to fragments in the fpc mem-mgmt => and that could cause a slow down..

Now I could spot the trouble source: it's fpdoc!

DoDi

Why do you think so?

Mattias

Interesting, I'm just optimizing a part of that.

http://bugs.freepascal.org/view.php?id=12953

What exactly is slow in fpdoc?

I guess he meant the fpdoc editor in the IDE, not the "fpdoc" program.

Mattias

> Now I could spot the trouble source: it's fpdoc! Why do you think so?

When the fpdoc window is open, the task manager shows a CPU usage of up to 100%, and every caret move can take several seconds. You can check this behaviour yourself, my test case is the Controls unit with the related include files.

When I close the fpdoc window, navigation through the text is not delayed, CPU usage stays at a few percents.

Memory usage is constant in either case, swapping seems not to occur.

DoDi

IMO it's the search for documentation information about the current identifier in the edit window, started for almost every move of the caret.

If that's the reason for the excessive slowdown of the editor, the search should be performed by a background thread, so that the editor is not blocked. The search should be terminated immediately, when the caret moves to an different identifier.

DoDi

> What exactly is slow in fpdoc? I guess he meant the fpdoc editor in the IDE, not the "fpdoc" program.

Right.

DoDi

At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay.

Mattias

At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay.

Maybe. I'd suggest an thread, but I dunno about platform issues with threads.

I also had an crash of lazde, caused by an formatting error in the text. Bugreport submitted.

DoDi

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090225/6801bae1/attachment.pl

The problem is that many tools access the codetools (almost every file access and search).

Then a request manager might help, with a busy indication so that a client can skip and retry later. A threaded server will allow for higher throughput on multi-core machines.

DoDi