Hi,

Movie:
=====
For those who did not try MSEide yet, here is a movie teaser. http://users.pandora.be/Jan.Van.hijfte/qtforfpc/mse01.html

Wiki:
===
http://www.freepascal.org/wiki/index.php/MSEide_&_MSEgui

Can someone provide a more appropriate entry in the wiki for this page. I cannot modify all pages, but did not find an appropriate page either.
Perhaps there should be some page: fpc related projects.

kind regards,

Den Jean

MSEgui has a distinct advantage over Lazarus. It compiles under Delphi. Just tried it. Fiddled with one or two lines in the code, but I got the IDE to compile and run and then built a small hello world app that also ran. Pretty impressive really.

M

MSEgui has a distinct advantage over Lazarus. It compiles under Delphi. Just tried it. Fiddled with one or two lines in the code, but I got the IDE to compile and run and then built a small hello world app that also ran. Pretty impressive really.

And the exe's/elf's it generates are reasonable in size. Going to check it out today, again.

That's always the trade off. MSEgui is something really different from lazarus: Lazarus/lcl is vcl compatible and uses the native widget set. MSEgui uses a complete pascal only approach: no compatibility, no default gui elements from the OS, this leads to little overhead, high speed and small executables. Both approaches can't be combined unfortunately.

Smaller than FPC ? That shouldn't differ too much, I think.

I don't really see why ability to compile with Delphi is so big an advantage ("distinct") ?

Micha

It can see the advantages and they should not be diminished:
- having different compilers to confirm or exclude a compiler bug.
- The cycle, code, compile, run, debug, code is quicker on Delphi, (if you are on windows)
- I haven't used Delphi lately, but I think the debugger is better than what Lazarus offers. For example stepping through Lazarus code is slow, if the Call Stack view is opened, because the Lazarus listview doesn't implement BeginUpdate and EndUpdate optimally.

Vincent

Micha Nelissen wrote

Smaller than FPC ? That shouldn't differ too much, I think.

From public.mseide-msegui.talk (news.dxmachine.com): "
Some more exe sizes on linux, MSEide+MSEgui V0.8a, FPC V2.0.3:

mseide without DB support: ziped
Kylix 3 1.6 MB 672 KB
FPC with smart linked units (-CX) 1.8 MB 708 KB
FPC without smart linked units 2.1 MB 777 KB

mseide with DB support:
FPC with smart linked units (-CX) 2.2 MB 832 KB
FPC without smart linked units 2.4 MB 899 KB
"
and
"
I got the following exe sizes with apps/demo/demo.pas:

compiled with Delphi 7: 400kB
compiled with Kylix 3: 495kB
FPC with -O2Gp3 without smartlinked libraries:
FPC win32 600kB
FPC linux 940kB
"
Compile time with Delphi/Kylix is much faster.

Martin

Vincent Snijders wrote

It can see the advantages and they should not be diminished: - having different compilers to confirm or exclude a compiler bug.

Debugging FPC by using Lazarus is stupid and overkill IMHO ;-).

- The cycle, code, compile, run, debug, code is quicker on Delphi, (if you are on windows)

True, but we have the command line and crosscompiling from linux :-)

- I haven't used Delphi lately, but I think the debugger is better than what Lazarus offers. For example stepping through Lazarus code is slow, if the Call Stack view is opened, because the Lazarus listview doesn't implement BeginUpdate and EndUpdate optimally.

That's a GUI bug in Lazarus then. Having used BCB and GDB, I think the Delphi (7) debugger sucks or I am doing something wrong. When walking up the stack, how can I see the contents of variables of those frames ? I always get an error when trying to view the variable, contents not available or so (I believe this works in BCB, but that's a long time ago, and I'm sure it works in GDB). GDB also has its weak points though; but nothing that Lazarus would (theoretically) not be able to "hide".

Micha

Martin Schreiber wrote

mseide without DB support: ziped

Are you afraid to draw conclusions?

Kylix 3 1.6 MB 672 KB FPC with smart linked units (-CX) 1.8 MB 708 KB FPC without smart linked units 2.1 MB 777 KB

So 30% if not smartlinking. Acceptable IMHO.

So, 50% and 90% respectively? Or what should we compare here? 90% is quite a lot, agreed.

Compile time with Delphi/Kylix is much faster.

Again, how much ? Win32 is probably a lot slower, but nevertheless you should give some reproduceable figures.

Micha

FPC db units do not compile with Delphi/Kylix, in MSEgui I use FPC db units -> MSEide with db support can only be compiled with FPC.

I think also.

Delphi7/Kylix smart linked units FPC 2.0.2 not smart linked units. My systems crash if I try to build smart linked units with FPC 2.0.2.

About factor 5..10.
No problem if you don't need to recompile the hole project in code-compile-run-debug-code cycle.
Compiling and starting of application in MSEide after modifying a form is about 2..3 seconds on a Linux AMD XP 3000+, 1GB ram system and FPC 2.0.3. I have some units in MSEide which let the compiler crash without -B option.

It is not possible to debug projects in MSEide which are compiled with Delphi, with Kylix it is eventual possible because of stabs debuginfo (I never tried it).

Martin

Smaller than FPC ? That shouldn't differ too much, I think.

Delphi's optimizer is superior to FPC currently. Delphi has another 10 - 15 years and paid developers on top of FPC, so this can be expected, I guess. And the compiler is just sooo fast.

Delphi 2005 gives 1.48MB for the mside.exe uncompressed. That is probably without DB support. I just complied the main unit with no changes other than to a couple of properties.

I don't really see why ability to compile with Delphi is so big an advantage ("distinct") ?

For all the reasons others have stated.

Also, Delphi's debugger alone makes it worthwile. If you don't like the debugger, fine. However do not blame your dislike of the Delphi debugger on your personal debugging preferences. I've been using Delphi commercially since 1998, or there abouts, and the debugger is perfectly acceptable. The debugger is the thing I always miss in other IDE's, especially VS.NET 2003.

M

The FPC _compiler_ is just as fast.

The linking stage is the problem; It's currently being worked on.

You could make the FPC compiler even faster by not letting it release memory, as delphi does... Just compile & debug several times in Delphi: Memory usage goes up with each compile...

Michael.

I don't see why the IDE should delphi compilable for that. It's about the applications!?!?

(of course, that is indeed a problem with lazarus. the dfm<->lfm and src conversions should get more bidirectional and reliable for that to work)

Matt Emson wrote

> Smaller than FPC ? That shouldn't differ too much, I think. Delphi's optimizer is superior to FPC currently.

2.0.2 and Delphi are equal on average.

Delphi has another 10 - 15 years and paid developers on top of FPC, so this can be expected, I guess. And the compiler is just sooo fast.

No, it's because it's technology of the 90s and no significant further development of the compiler has been done. No 64 bit support so far, the optimizer is only reasonable good for a pentium (just compare other commercial compilers with Delphi).

> Compile time with Delphi/Kylix is much faster. Again, how much ? Win32 is probably a lot slower, but nevertheless you should give some reproduceable figures.

As discussed in another thread, with FPC 2.x, we put a lot of effort into a maintainable and portable compiler because of rare time. Just give you an example: I ported fpc 2.1.1 to win64 within the last 4 weeks besides my daily job, preparing a PhD and looking for a new appartment and preparing moving. I think this gives a good impression how maintainable and portable fpc got with 2.x.

This could be caused by Kylix being able to some
more advanced types of smartlinking due to own linker. (e.g. vtable optimization)

If your binaries use libc, recompiling FPC with dFPC_USE_LIBC might bring -the size down a further 10-40k.

But I think these size differences are irrelevant and peanuts. I don't see what advantage 200k brings.

Compile time with Delphi/Kylix is much faster.

True, and much more important. This and debugging will remain for some time. Internal linker will improve this somewhat mid-long term.

On win32 the internal linker really matters a lot. Still slower than Delphi, but a full magnitude better.

I've now merged the fix for the property loading crash from 2.1.1 to 2.0.3. I didn't do it before because I wasn't sure at first whether it wouldn't have any bad side-effects, and later forgot to merge it.

Jonas

This argument is based on a (IMHO) common misconception of the Lazarus environment:

It assumes that one and the same project should be switchable at any time between Delphi and Lazarus.

This is not the intention of Delphi (obviously) nor of Lazarus.

Lazarus tries to be compatible to Delphi in the sense that you should be able to take a vanilla Delphi program, and compile it - with reasonable modifications - in Lazarus, and then possibly continue development in Lazarus.

Any tools that Lazarus provides to convert .DFM to .lfm are one-way, and intended to help in porting a Delphi application to Lazarus, 1 time.

Providing 2-way conversions requires help from both sides, otherwise it will never work transparant. Somehow I don't think the Delphi devels will assist in making the conversion easier.

So, if you want 2-way compatibility: you are on your own.

Look at OpenOffice vs MS-Office. The conversions are always far from perfect, and you always get a message that 'Some formatting may be lost' etc. And OpenOffice is the only one doing the conversion...

Michael.

And I suspect RTTI info.

Agreed.
And if compressed the difference is only some per cent .

Martin

I do neither use Lazarus, nor MSEide, but if executable size is really important, there is something called KOL (I didn't use it either). As I have read, it's currently compilable by FPC.

Speaking of bigger applications, I don't see much difference between 6 or 30 Mb executables...

???? ??????????? wrote

I do neither use Lazarus, nor MSEide, but if executable size is really important, there is something called KOL (I didn't use it either). As I have read, it's currently compilable by FPC. Speaking of bigger applications, I don't see much difference between 6 or 30 Mb executables...

Try downloading them over a 56k modem ;-)

Michael.

Try downloading a 6M one using a trained parrot (read: 300 baud). Where do you put the border of what is "normal"?

The point I was trying to make was that although harddisk space is relatively cheap, distribution size is a factor to take into consideration... Not everybody has broadband, I assume.

Michael.

I know, see the faq about binary sizes

http://www.freepascal.org/wiki/index.php/Size_Matters

"modem distribution"

No, it's because it's technology of the 90s and no significant further development of the compiler has been done. No 64 bit support so far, the optimizer is only reasonable good for a pentium (just compare other

commercial

compilers with Delphi).

If it ain't broke, don't fix it.

L505 wrote: >> MSEgui has a distinct advantage over Lazarus. It compiles under Delphi.

Just

>> tried it. Fiddled with one or two lines in the code, but I got the IDE to >> compile and run and then built a small hello world app that also ran.

Pretty

>> impressive really. > > And the exe's/elf's it generates are reasonable in size. Going to check it

out

> today, again. Smaller than FPC ? That shouldn't differ too much, I think.

I mean smaller than lazarus generated ones.

BTW How does borland put the debug info into the exe without increasing the exe size? Not to mention, there is no such thing as a smartlinking option in my delphi compiler. They just assume you always need smartlinking - why would you not need it. As for how their compiler/linker is so fast with smartlinking on and debugging on... mystery.

debugger, fine. However do not blame your dislike of the Delphi debugger on your personal debugging preferences. I've been using Delphi commercially since 1998, or there abouts, and the debugger is perfectly acceptable. The

So can you confirm that looking at variables that are "up the stack" does not work for you as well?

debugger is the thing I always miss in other IDE's, especially VS.NET 2003.

Hmm, from what I've heard, the debugger in Visual Studio (6?) is *way* more advanced than the one in BCB, and that one's better than Delphi's. I don't assume they've removed the debugger from 2003 ?

Micha

Linking stabs debugging is slow. Every .stab section must be merged and updated. Compare the linking time differences with linking lazarus.exe (50Mb of stabs) with -Xi and with -Xis.

In the future fpc will use dwarf and the size will me much lower and linking will be faster. But we are partly dependent on the debugger (gdb) to support it. At least the standard is enough to implement all pascal features. But for example gdb only implements what is needed for C/C++.

Peter

KOL GUI stuff is not cross platform. But I have made a project for us all which allows you to compile all the KOL non-GUI stuff on linux. https://opensvn.csie.org/pspcgi/psp-1.6.0-release/Extras/CompactUtils/CompactUtils.pas

Very nice compact stringlist in there to use...
Standard Classes stringlist adds about 60K-70K to your exe/elf while CompactUtils PStrList only adds maybe 1-5KB.

But for those people who think classes are just so superiour to old Pascal objects and for those who only do pure object oriented programming (whatever the heck that is) .. please ignore this project. This compactutils project is definitely not for you.

And I personally don't like buying a new hard drive and CPU every year.. first thing I do when looking for space on my hard drive is find all exes/elfs that are bigger than 5MB, then I strip them. A few 30MB lazarus exes/elfs take up a lot of space. Especially when you have to compile two executables. One for linux, one for windows. That adds up to 60MB for each program, if you support two OS's on one hard drive.

I buy a computer every 5 or so years, not every 6 months to support the latest bloat. A $2000 computer each year could add up to a small downpayment on a house. $2000 X 5 - $10,000 dollars. Not to mention laptop and LCD upgrades, and motherboard failures. For those who say it is cheaper just to buy hardware - then please tell me one advantage of using a compiled language. Speed and memory are not important - because you can buy hardware. So give me one reason to use a compiled language. No advantages. Source is more closed with binary files than it is scripts.

(I'm playing devil's advocate. Personally, I like small compiled programs in one package that I can choose to ship with or without sources. )

> On Wed, 19 Apr 2006, ???? ??????????? wrote: > > > I do neither use Lazarus, nor MSEide, but if executable size is really important,

there is something called KOL (I didn't use it either). As I have read, it's currently compilable by FPC.

> > > > Speaking of bigger applications, I don't see much difference between 6 or 30 Mb

executables...

I ask, why are we promoting compiled languages then? It sounds like interpretters would suit us better. Because
1. hardware is so cheap
2. size and memory are not all that important any more.

Since we are not in the DOS/640K memory days any more - tell me one advantage of a compiled language, if size/footprint/etc are not important any longer? "With today's new hardware at low prices, who needs FPC or any other compiler?".

I think this is poor marketing for FPC: telling people that size/bloat is not an issue. Then what good is FPC for us? FPC is a compiled language! The whole point of a compiled language, is to have SOME advantage over an interpreted language. What is this advantage, if not size/memory/footprint? I don't see any advantages.

Well, compared with other commercial compilers it is broken ;)

Please compare what is comparable:

The Classes unit contains more than just the TStringlist and TList.

It contains a whole lot of other classes as well: streams, collections, components, threads, and the whole streaming system. All things which are commonly used in Object Pascal programs.

I'm sure that if you lifted out TStringlist, removed the stream stuff (or replaced with regular files) the size would be comparable.

Whether you use classes or objects is not really relevant to the size issue.

Michael.

The memory footprint of a good interpreter is lower than that one of a compiled program. Guess why a lot of programs in the 80s were written in interpreted basic :) Only the bad design of most interpreters cause big memory footprint.

KOL contains Streams, Threads, Stringlists, TLists (actually PList) and almost every single function implmented in the Classes unit. They are pretty comparable. (CompactUtils doesn't contain threads yet because I didn't work on that area - just not enought time.).

There was also USCD pascal .. but people complained it was too slow?

> debugger, fine. However do not blame your dislike of the Delphi debugger

on

> your personal debugging preferences. I've been using Delphi commercially > since 1998, or there abouts, and the debugger is perfectly acceptable.

The

So can you confirm that looking at variables that are "up the stack" does not work for you as well?

Was is supposed to work? I can't say that is does because I don't generally debug that way. As I said, you blame the debugger when, in fact, it is the style of debugging you employ that is causing you problems. Delphi promotes a break often style of debugging. Utilise the call stack to trace the code path, but set break points to inspect variables. This is how I have always worked and this is how I feel comfortable working. F7/F8/F9, the Evaluate/Modify and the call stack is all that is needed.

> debugger is the thing I always miss in other IDE's, especially VS.NET

2003.

Hmm, from what I've heard, the debugger in Visual Studio (6?) is *way*

more

advanced than the one in BCB, and that one's better than Delphi's. I don't assume they've removed the debugger from 2003 ?

It is sloooow as hell to step through code. Slooooooower on a PDA for example.

Yes. That's the drawback :) Ever had a look at the executable size of the Intel C compiler if you optimize for speed?

KOL isn't comparable with the FCL. KOL has no real error handling just one example:

//[function TList.Get]
function TList.Get( Idx: Integer ): Pointer;
begin
   Result := nil;
   if Idx < 0 then Exit;
   if Idx >= fCount then Exit;
   Result := fItems[ Idx ];
end;
function TFPList.Get(Index: Integer): Pointer; {$ifdef CLASSESINLINE}
inline; {$endif CLASSESINLINE}
begin
  If (Index < 0) or (Index >= FCount) then
    RaiseIndexError(Index);
  Result:=FList^[Index];
end;

KOL simply exits, the FCL throws a proper exception with an error message with a text. The error message probably adds more size to the executable than the whole get function. KOL doesn't offer the same functionality as the FCL. It's the price for the smaller size.

When buying hardware, you can only get two of the three: speed, quality, price
When writing a compiler, you can get only two of the three: speed, little memory usage, maintainability
When writing a library, you've to choose two of
speed, size, function
It's always a trade off. Neither KOL nor FCL is better, they are simply designed different and comparsion is useless.

This is certainly true, but your statement is that:

"Standard Classes stringlist adds about 60K-70K to your exe/elf while CompactUtils PStrList only adds maybe 1-5KB."

This 1-5k of CompactUtils does not have a quarter of the functionality included in the 60k you compare it with. That's intellectually not correct. You should compare the size of the classes unit with the total size of all KOL (or whatever) units that implement the same functionality as classes.

Comparing the size of a PC with the size of a wristwatch can be done, but does not say anything useful, except that you might not attract a lot of women with a PC wrapped around your wrist when going to a party ;-)

Michael.

> If it ain't broke, don't fix it. Well, compared with other commercial compilers it is broken ;)

Heh, well when I can do what I am currently able to do in Delphi in an FPC based IDE, we'll talk again, yes? ;-)

This won't never happen, you miss one important point: the main goal of the current FPC developers is to implement functionality which Delphi doesn't have. For things, Delphi can do, you don't need FPC. But Delphi can't do things FPC can do :) Or ever tried to use one of the best debugging tools available (valgrind) with Kylix/Delphi :)? Because of the superior functionality valgrind offers, I've installed vmware at my pc at work and compile sometimes my programs with gcc (usually developed with MSVC) to find memory leaks, dangling pointers etc.

> > > I do neither use Lazarus, nor MSEide, but if executable size is really important,

L> there is something called KOL (I didn't use it either). As I have read, it's currently L> compilable by FPC.

It's in russian, this is my first source of information about KOL http://phantom.atspace.com/kolforfpcru.html
(I got message about it from russian mail list about FPC.)

Me again:

> > > Speaking of bigger applications, I don't see much difference between 6 or 30 Mb

L> executables...

> > Try downloading them over a 56k modem ;-) > Try downloading a 6M one using a trained parrot (read: 300 baud). Where do > you put the border of what is "normal"?

I. Downloads.

Well, I download via one of three ways: (well, almost)
1. <= 3Mb --- from office (paid traffic)
2. 3Mb <= <=100Mb --- from home overnight (I have 33600 baud modem and don't plan to upgrade:)
3. 100 Mb <= --- from friends' one or another unlimited traffic broadband connection (256 Kb --- 100 Mb)

In the third case I have to change my route (to visit them) or wait for occasion (parties included) (to get burned DVD with what I asked them to download).

I really do download 6-30 Mb packages in similar way. I really do use for this range even more slow connection than 56K.

II. Hard disk.

Home computer: one photo is 3-12 Mb (compressed). I have thousands and don't think it's very uncommon or something.

Office: no photos. Plenty of free space.

L> I ask, why are we promoting compiled languages then? L> It sounds like interpretters would suit us better. Because L> 1. hardware is so cheap
L> 2. size and memory are not all that important any more.

L> I think this is poor marketing for FPC: telling people that size/bloat is not an issue. L> Then what good is FPC for us? FPC is a compiled language! The whole point of a compiled L> language, is to have SOME advantage over an interpreted L> language. What is this advantage,
L> if not size/memory/footprint? I don't see any advantages.

I like speed.

I can only kinda quote/repeat: look at good commercial compiler binaries optimized for speed.

It's always a trade off. Neither KOL nor FCL is better, they are simply designed different and comparsion is useless.

The intention is purely to be compact, and I didn't mean to compare or compete with FCL.

I was just mentioning that those who need a convenient compact StringList without the bloat of 60-70K being hauled in compactutils is there for you. Free for your usage.

p.s. There is err.pas for KOL exception handling. Adds a few kilobytes. Still not comparable to FCL exception handling probably. But that's not the intention is purely to be compact, not to compete with classes.pp.

Because of the superior functionality valgrind offers, I've installed vmware at my pc at work and compile sometimes my programs with gcc (usually developed with MSVC) to find memory leaks, dangling pointers etc.

Hmmm... so GCC produces the exact same output as MSVC now? I don't think so. All you'll find are syntactical errors mainly.

No, why should this be necessary? By default program is built with MSVC, to do error testing of the non gui part which is the biggest part, the non gui stuff is compiled with gcc on linux and tested with valgrind.

I don't think so. All you'll find are syntactical errors mainly.

Maybe you. Not me. Doesn't seem that you ever used valgrind.

Jonas Maebe wrote

I've now merged the fix for the property loading crash from 2.1.1 to 2.0.3. I didn't do it before because I wasn't sure at first whether it wouldn't have any bad side-effects, and later forgot to merge it.

Thanks.
The next problem (fixes_2_0 rev.3303, MSEide+MSEgui 0.8b: [...]
Linking mseide
151568 Lines compiled, 128.2 sec
Free Pascal Compiler version 2.0.3 [2006/04/21] for i386 Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for i386
Compiling mseide.pas
Compiling /home/mse/test/msegui/lib/common/kernel/msegui.pas Compiling /home/mse/test/msegui/lib/common/kernel/msegui.pas Compiling /home/mse/test/msegui/lib/common/kernel/msegui.pas Compiling /home/mse/test/msegui/lib/common/kernel/msegui.pas Compiling /home/mse/test/msegui/lib/common/kernel/msegui.pas msegui.pas(2592,31) Error: No member is provided to access property msegui.pas(2603,31) Error: No member is provided to access property msegui.pas(9913) Fatal: There were 2 errors compiling module, stopping msegui.pas(89,46) Fatal: Compilation aborted

Martin